From nobody Mon Feb 1 15:58:44 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DFF3A15C7; Mon, 1 Feb 2021 15:58:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <161222392165.17344.10387400542869169432@ietfa.amsl.com> Date: Mon, 01 Feb 2021 15:58:42 -0800 Archived-At: Subject: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-jwt-introspection-response-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 23:58:42 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sections 11.1.1 and 11.2.1 each appear to contain three registration actions, but they all blend together in a common bullet list. It might be nicer on IANA to separate them somehow, either into individual sub-subsections, or at least make them distinct lists. From nobody Mon Feb 1 18:08:53 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBE43A166F; Mon, 1 Feb 2021 18:08:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161223173167.23433.4946076825259074367@ietfa.amsl.com> Date: Mon, 01 Feb 2021 18:08:51 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 02:08:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : The OAuth 2.1 Authorization Framework Authors : Dick Hardt Aaron Parecki Torsten Lodderstedt Filename : draft-ietf-oauth-v2-1-01.txt Pages : 86 Date : 2021-02-01 Abstract: The OAuth 2.1 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 1 18:10:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE13A1674 for ; Mon, 1 Feb 2021 18:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9Ug_izoSNtw for ; Mon, 1 Feb 2021 18:10:26 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B614C3A1676 for ; Mon, 1 Feb 2021 18:10:25 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id e133so8828778iof.8 for ; Mon, 01 Feb 2021 18:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=04K5kaJ6Pn4Fjrgxh1HrSMpeX3C2JrVgQpaQ64SmIyg=; b=UxJuaNKivIwOKs9pohrYWRq9DIm+B5h1/dKUH14jvWlMIOUwmL4gzAgDy88wBSLx6w /VKx7efQBZ2iKIYit48B2FdZn/PO2d/JJNtHJ19PDVjERfQ63yKGEkMNggYKQs+Me4xr 8fD4P18jOzkUaCOh4iPHS11nrnWrUqTqG1HbmE1HOMwDQcsSJYQhIN4h2liinxqnivzF QkwhWLqMoJe7kXQ+o2pCOdd/b3sg1mJkSKGWvRam7TzEj2lvE1/R7Zc+Hc4o2PExpB0H Q/c2vcQMxi2uL3T4ZB7Bna9JXk+9NlN49mMi+oPcULAx+/SmG/jSwAupJ+GMCCz67rlY 5jXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=04K5kaJ6Pn4Fjrgxh1HrSMpeX3C2JrVgQpaQ64SmIyg=; b=skKSnl9lbPxbAXc58iA5J2m6xye0ZB14T39S804RHlboWRgOoqEBZUTFaWDvuDD9In uz+5qGEN5hM+bX8Q2go51M5fAep+UHcz9yFSPBWhM/331J9xMlZEd17Ngi+TPJACQrkg pUN4PfXuEfRF/5nAA82SoZmD3svqhocOEoI8kjj2WdmIE4cPhwkmokYaHh94C4HEpRH5 baYadb4aMr35rw6y8zbXbBLww2f4o1SOdT2H88I+Nuas+2qpZsO/ZBOHmTKa1eoxTyPy TGXuRvYraQyk5OduEQkeKF5icEZtVakg9CwK/RIiZ1wswPGMJysFrWcIOM6T0f/L4Xii AGnQ== X-Gm-Message-State: AOAM531pD6nx6gjIHwhOS1Cr4O100YX5b52w1Y81hz0CCM3bkn+bVIKd qscGiWR87yMW4TeH1ppuzVN4nqeJYrMUSw== X-Google-Smtp-Source: ABdhPJzm3+A7iVV4CDITCnciG4xxq42rUcR477djMx/gYNwreH7Q7Y9tht3BvgCc8QIgr4L3dKLOWQ== X-Received: by 2002:a05:6638:1928:: with SMTP id p40mr6215093jal.71.1612231823726; Mon, 01 Feb 2021 18:10:23 -0800 (PST) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id t7sm10159601ilf.41.2021.02.01.18.10.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Feb 2021 18:10:22 -0800 (PST) Received: by mail-io1-f45.google.com with SMTP id u17so19728966iow.1 for ; Mon, 01 Feb 2021 18:10:22 -0800 (PST) X-Received: by 2002:a02:3541:: with SMTP id y1mr17790627jae.66.1612231821860; Mon, 01 Feb 2021 18:10:21 -0800 (PST) MIME-Version: 1.0 References: <18b401d6cdb9$09cef410$1d6cdc30$@auth0.com> In-Reply-To: <18b401d6cdb9$09cef410$1d6cdc30$@auth0.com> From: Aaron Parecki Date: Mon, 1 Feb 2021 18:10:10 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Vittorio Bertocci , Justin Richer Cc: OAuth WG Content-Type: multipart/alternative; boundary="00000000000009aa9805ba50f992" Archived-At: Subject: Re: [OAUTH-WG] Detailed review of OAuth2.1 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 02:10:36 -0000 --00000000000009aa9805ba50f992 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you both for the detailed review! I'm responding inline to the things I've gone ahead and updated the draft to reflect. There's a lot going on here, so I'm only touching the introduction section for now. I've opened issues on the github repo to track the other items that will take some more discussion to work out. --- > =C2=A71.1 > In the RS definition, wondering whether including the word =E2=80=9CAPI= =E2=80=9D would > help to clarify what an RS is in practice. I agree, I added the sentence "The resource server is often accessible via an API." =C2=A71.3.1 > We don=E2=80=99t say anywhere here that the authorization code can be exc= hanged > for an access token. It can be somewhat inferred from 1.2, but it=E2=80= =99s a bit > of an intelligence test (one needs to infer from authorization grant). > Agreed, I've updated this with some language to clarify that the authorization code is later exchanged for an access token. > P2 > =E2=80=9Cobtains authorization=E2=80=9D could be more specific, to reinfo= rce that we are > doing a delegated flow. =E2=80=9CObtains=E2=80=9D seem to suggest that we= are talking about > consent, rather than AS side rules. If that=E2=80=99s the case, calling i= t out > might make the scenario clearer. > I'm not quite sure what you're getting at here, but I agree this paragraph could be improved, so I've added some context to it around consent and MFA/delegated accounts. > P3 > Both the benefits listed apply to confidential clients only. Not sure > whether calling it out here would help prevent confusion later on (eg > people thinking that public clients can prove their identity) or would > bring confusion on now (given that we didn=E2=80=99t differentiate betwee= n client > types yet). Either ways, formally we are OK here; I am just thinking how = to > make things clearer. Perhaps defining client types before grants might he= lp > being clearer here. I think this is fine as is, technically the access token doesn't go through the user agent in mobile apps since it's delivered directly to the native app code in response to an HTTP request (which may even use certificate pinning if you want to be really paranoid). =C2=A71.3.2 > A concrete example of credential (eg shared secret) might help clarify > things here. Also, the fact that client credentials indicate both a grant > in itself and an artifact (which participates in other grants) is a well > know source of confusion. Wondering if calling this out here might help. I've added this: "(e.g. a `client_secret` or a private key used to sign a JWT)" =C2=A71.4 > In general, we use =E2=80=9Caccess token=E2=80=9D and =E2=80=9Ctoken=E2= =80=9D interchangeably- perhaps > pedantic, but I would suggest we always use =E2=80=9Caccess token=E2=80= =9D to prevent > confusion with refresh tokens later on, and other token types in other > contexts (eg think ID tokens). I went through and updated every use of "token" that refers to an access token to actually mention access token. P1 > The client should treat the AT string as opaque, but that doesn=E2=80=99t > necessarily means it is: in some cases the client CAN see inside the toke= n, > and with the current language they might interpret it as =E2=80=9Cin this= case, > it=E2=80=99s OK to look- otherwise they would have made it opaque, per th= e spec=E2=80=9D. How about this: "The string is considered opaque to the client, even if it has a structure. Depending on the authorization server, the access token string may be parseable by the resource server." I didn't think it was appropriate to add a "MUST NOT" or something here given that this is still the introduction. =C2=A71.5 > The first phrase of P1 is wonderfully clear. We should have the equivalen= t > in =C2=A71.3.1 Yes! "An authorization code is a temporary credential used to obtain an access token." I've updated the rest of the paragraph as well. Not having defined a mechanism for requesting a RT here, leaving it to ASes > to decide when and where, created the situation in which some AS only > issues RTs when they get the offline_access scope, with all the unfortuna= te > consequences about RT lifetime vs session lifetime etc=E2=80=A6 I know we= can=E2=80=99t > really change this now as we don=E2=80=99t want to break existing AS > implementations, but wondering if there=E2=80=99s anything we can say to = further > clarify/give readers a headsup about the ambiguity/diversity of behaviors > they=E2=80=99ll encounter here. Yeah this is tricky, I've added this to emphasize all the different reasons why a RT may or may not be returned: "... and may be issued based on properties of the client, properties of the request, policies within the authorization server, or any other criteria." P2 > It=E2=80=99s odd that we say =E2=80=9Cusually opaque to the client=E2=80= =9D for the RT while we > decisively said opaque for the AT. Also, the client shouln=E2=80=99t do a= nything w > the RT content hence I think the same considerations done for =C2=A71.4P2= apply > here. Good catch. I'm fixing it the same way as the AT definition above. =E2=80=9CThe token denotes an identifier used to retrieve the authorization > information=E2=80=9D gets into the specifics of the implementation and it= =E2=80=99s not > universally true (some AS encrypt/sign the authz info in the RT itself an= d > have no server state whatsoever. Yep, how about: "The refresh token may be an identifier used to retrieve the authorization information or may encode this information into the string itself." Step 3 > Should we add a reference to RFC6750 here? RFC6750 is being folded into this spec, so no I don't think so. =C2=A72 > =E2=80=9Cend-user interaction with an HTML registration form=E2=80=9D is = oddly specific =F0=9F=98=8A > in particular, I think =E2=80=9Cend user=E2=80=9D might be misleading. We= can either say > =E2=80=9Cinteractive=E2=80=9D or refer =E2=80=9Cthe client app developer= =E2=80=9D or equivalent. > Overkill but I=E2=80=99ll mention it anyway. Should we say that typically= the > client registration in the non-dynamic scenario occurs in authenticated > settings? Not strictly necessary but might help the reader to tie what we > say in this section with their concrete experience. Yeah it does seem like it would be better to say "client developer" than "end user". Also "the client registers with the authorization server" is only true with dynamic client registration. I've updated the whole section to hopefully make more sense. I'm going to save processing the feedback from here out for a separate email. --- Now I'm going to respond to Justin's feedback on the introduction section in the same way here. =C2=A7Abstract > I think we should update =E2=80=9Cinteraction between the RO and the HTTP= Service=E2=80=9D > to be =E2=80=9Cthe RO and an authorization service=E2=80=9D or something = like that instead, > since =E2=80=9Cthe HTTP service=E2=80=9D referenced elsewhere in this par= agraph is more > precisely the RS and not the AS, yet the interaction and approval happens > at the AS. OAuth 2.0 allowed the AS and RS to be separate, and 2.1 should > go further to admit that in a lot of cases today, they are separate. I like it, it's a small change but I think it makes it clearer. =C2=A71: We should add a note on password use to this list: Thanks! This is a great consideration, I've added it to the list. =C2=B63/4 can probably be collapsed to read better, and some of the languag= e > cleaned up. Recommend: Thanks, looks great, I've incorporated this. =C2=B66: (and throughout document) avoid use of gendered pronouns in favor = of > singular =E2=80=9Cthey=E2=80=9D unless needed for clearer reading (such a= s an Alice and Bob > scenario) Thank you! I've replaced a few of them I found, and I will replace the rest if I find more later. =C2=A71.4: This section should mention introspection explicitly. Recommend > rewriting the intro to =C2=B63: Looks great, thanks. =C2=A71.5: =E2=80=9CThe string is usually opaque=E2=80=9D should be =E2=80= =9Cthe string is opaque" Updated to "the string is considered opaque" based on Vittorio's suggestion as well. =C2=A71.6: this should probably refer to the TLS BCP195 here instead of the= RFC > and version. Great, thanks. =C2=A71.8: This should have explicit links to introspection (RFC7662), > registration (RFC7591, RFC7592), and discovery (RFC8414) inline as they= =E2=80=99re > given as examples, instead of putting them all in the appendix. Perhaps > also bring up JWTs for token formats here as well. Great idea, thanks. =C2=A71.X: Suggest adding a section on compatibility with OAuth 2.0, either= as > part of =C2=A71.8 or in a new section injected right after it. Some sugge= sted > starter text: Great idea, I've incorporated your initial suggested and added a link to the existing "differences from OAuth 2.0" section. We can expand further later as well. --- I'm tracking the feedback that I didn't respond to here from the Introduction section 1 on GitHub, ( https://github.com/aaronpk/oauth-v2-1/issues) so feel free to continue the discussion in the appropriate thread there, or respond on the mailing list with a reference to the github issue so it's easier to manage. I'll continue working on this feedback from the next sections as well. Thanks! Aaron Parecki On Tue, Dec 8, 2020 at 3:22 PM wrote: > Dear authors, > > It took ages but I finally managed to go thru a full review of the curren= t > OAuth2.1 draft. Apologies for the delay. > > Metacomments: > > - The VAST majority of the comments are suggestions for improving > clarity, mostly on historical language coming from 2.0 that I found my= self > having to clarify to customers and colleagues over and over thru the y= ears. > None of those are critical. > - There are a few places where 2.1 requires a MUST I believe to be > unwarranted/too restrictive. For each of those I did my best to provid= e > context and concrete examples. > - A sizeable category of comments and disagreements on MUST come from > treating mobile and desktop apps as largely equivalent under the =E2= =80=9Cnative > app=E2=80=9D umbrella, despite of the vast gulf that separates the two= both in > terms of security posture and user experience. Again, I tried to be as > matter of fact as possible in there. > - The main reason for which I spoke up during the IETF interim on > oauth2.1 was the confusion the omission f the implicit grant caused am= ong > the devs using implicit in OIDC for obtaining ID_tokens. I suggested s= ome > language to pre-empt the issue, but I expect some iteration there. > > Thanks, > > V > > > > =C2=A71 > > I wonder whether we should take the opportunity offered by OAuth2.1 to > clarify frequent points of confusion about OAuth, by explicitly calling o= ut > in the introduction what is out of scope. > > For example: OAuth is not an identity protocol, as it doesn=E2=80=99t con= cern > itself with how resource owners are authenticated; OAuth isn=E2=80=99t me= ant to > address 1st party scenarios, although the reader is free to use it in > that context as well; and so on. > > I believe there is value in adding this in the introduction rather than > relegating it in some later considerations section, as the people who nee= d > this information the most rarely read past this point. > > > > =C2=A71.1 > > In the RS definition, wondering whether including the word =E2=80=9CAPI= =E2=80=9D would > help to clarify what an RS is in practice. > > > > =C2=A71.2 > > I always found this part extraordinarily difficult to decipher. I get tha= t > this is the first description and doesn=E2=80=99t have to be exhaustive a= nd > consider all cases (eg it=E2=80=99s ok if step 3 claims that the client > authenticates w the AS even tho that=E2=80=99s only for confidential clie= nts), but > I think it could be much clearer than it is today. > > Step 1 says > > The client requests authorization from the resource owner. The > authorization request can be made directly to the resource owner (as > shown), or preferably indirectly via the authorization server as an > intermediary. > > Besides the fact that =E2=80=9Crequests authorization=E2=80=9D is a bit v= ague, this step > and the corresponding diagram leg does not correspond at all to what > normally happens- to get a code, the client does need to hit the AS and t= he > mention in passing in the text isn=E2=80=99t enough to figure that out. A= lso, with > the omission of ROPG there really isn=E2=80=99t any way of asking anythin= g to the > RO directly (the client creds doesn=E2=80=99t involve the RO). > > I would recommend updating that diagram to be more descriptive of the > canonical scenario. > > Step 2 > > mentions the 2 grants defined in the spec, but only one of them represent= s > the RO=E2=80=99s authorization. Claiming that the client itself is the RO= is a > formalism that doesn=E2=80=99t meet the reader=E2=80=99s intuition at thi= s point. > > Step 5 > > The language here triggered multiple discussions, in particular on whethe= r > the AT can actually be used to ascertain the identity of the client =E2= =80=93 that > isn=E2=80=99t the case for public clients, for example; besides, that=E2= =80=99s not really > the highest order bit of the AT. If it is, it seems that the spec should = be > more explicit about how client identification from the RS by means of an = AT > works. If it isn=E2=80=99t, perhaps we should change the language to omit > authenticate. > > The last paragraph is emblematic IMO =E2=80=93 if the preferred method is= very > different from the diagram here, and if the abstraction presented here is > not terribly useful (given that we no longer have multiple RO based grant= s, > excluding the extension grants that are still too far at this point to > warrant a cognitive downpayment for the reader) I wonder whether we=E2=80= =99d be > better off doing the authz code diagram directly (and mention that we als= o > have the client creds grant separately). > > > > =C2=A71.3 > > I understand that we can=E2=80=99t really change this because we inherit = from > OAuth 2 but I=E2=80=99ll mention it anyway- modeling clients as ROs is pr= oblematic, > as it doesn=E2=80=99t often match what happens in practice. A confidentia= l client > might batch-read a user=E2=80=99s inbox searching for ad words, but the r= esource > owner remains the user. > > I know we straighten things up in 1.3.2, but the positioning here is > confusing. > > Also: isn=E2=80=99t the refresh token grant a core-specified grant as wel= l? I know > I am nitpicking. > > =C2=A71.3.1 > > We don=E2=80=99t say anywhere here that the authorization code can be exc= hanged > for an access token. It can be somewhat inferred from 1.2, but it=E2=80= =99s a bit > of an intelligence test (one needs to infer from authorization grant). > > P2 > > =E2=80=9Cobtains authorization=E2=80=9D could be more specific, to reinfo= rce that we are > doing a delegated flow. =E2=80=9CObtains=E2=80=9D seem to suggest that we= are talking about > consent, rather than AS side rules. If that=E2=80=99s the case, calling i= t out > might make the scenario clearer. > > P3 > > Both the benefits listed apply to confidential clients only. Not sure > whether calling it out here would help prevent confusion later on (eg > people thinking that public clients can prove their identity) or would > bring confusion on now (given that we didn=E2=80=99t differentiate betwee= n client > types yet). Either ways, formally we are OK here; I am just thinking how = to > make things clearer. Perhaps defining client types before grants might he= lp > being clearer here. > > > > =C2=A71.3.2 > > A concrete example of credential (eg shared secret) might help clarify > things here. Also, the fact that client credentials indicate both a grant > in itself and an artifact (which participates in other grants) is a well > know source of confusion. Wondering if calling this out here might help. > > > > =C2=A71.4 > > In general, we use =E2=80=9Caccess token=E2=80=9D and =E2=80=9Ctoken=E2= =80=9D interchangeably- perhaps > pedantic, but I would suggest we always use =E2=80=9Caccess token=E2=80= =9D to prevent > confusion with refresh tokens later on, and other token types in other > contexts (eg think ID tokens). > > P1 > > The client should treat the AT string as opaque, but that doesn=E2=80=99t > necessarily means it is: in some cases the client CAN see inside the toke= n, > and with the current language they might interpret it as =E2=80=9Cin this= case, > it=E2=80=99s OK to look- otherwise they would have made it opaque, per th= e spec=E2=80=9D. > > > > =C2=A71.5 > > The first phrase of P1 is wonderfully clear. We should have the equivalen= t > in =C2=A71.3.1 > > Not having defined a mechanism for requesting a RT here, leaving it to > ASes to decide when and where, created the situation in which some AS onl= y > issues RTs when they get the offline_access scope, with all the unfortuna= te > consequences about RT lifetime vs session lifetime etc=E2=80=A6 I know we= can=E2=80=99t > really change this now as we don=E2=80=99t want to break existing AS > implementations, but wondering if there=E2=80=99s anything we can say to = further > clarify/give readers a headsup about the ambiguity/diversity of behaviors > they=E2=80=99ll encounter here. > > P2 > > It=E2=80=99s odd that we say =E2=80=9Cusually opaque to the client=E2=80= =9D for the RT while we > decisively said opaque for the AT. Also, the client shouln=E2=80=99t do a= nything w > the RT content hence I think the same considerations done for =C2=A71.4P2= apply > here. > > =E2=80=9CThe token denotes an identifier used to retrieve the authorizati= on information=E2=80=9D gets into the specifics of the implementation and i= t=E2=80=99s not universally true (some AS encrypt/sign the authz info in th= e RT itself and have no server state whatsoever. > > Step 3 > > Should we add a reference to RFC6750 here? > > > > =C2=A71.8 > > Should we say rich **delegated** authorization framework? > > > > =C2=A72 > > =E2=80=9Cend-user interaction with an HTML registration form=E2=80=9D is = oddly specific =F0=9F=98=8A in particular, I think =E2=80=9Cend user=E2=80= =9D might be misleading. We can either say =E2=80=9Cinteractive=E2=80=9D or= refer =E2=80=9Cthe client app developer=E2=80=9D or equivalent. > > Overkill but I=E2=80=99ll mention it anyway. Should we say that typically= the client registration in the non-dynamic scenario occurs in authenticate= d settings? Not strictly necessary but might help the reader to tie what we= say in this section with their concrete experience. > > > > =C2=A72.1 > > P4 > > =E2=80=9CAuthorization servers SHOULD consider the level of confidence in= a client's identity when deciding whether they allow such a client access = to more critical functions, such as the Client Credentials grant type.=E2= =80=9D > > I don=E2=80=99t understand this sentence. Is the client credentials grant= type a =E2=80=9Cmore critical function=E2=80=9D? Or is it a level of confi= dence? Either ways, I think it needs clarifying. > > P5 > > IMPORTANT: this is going to break many OAuth implementations with signifi= cant adoption. Auth0 is fine (each client_id is tied to a single client typ= e) but I know of others that will break. > > I suggest softening to a SHOULD NOT. > > =E2=80=9Cbrowser-based application=E2=80=9D > > I am not convinced this is so much easier than the original =E2=80=9Cuser= -agent-based=E2=80=9D. I understand the advantages (dovetails w the BCP, mo= re precise given that apps can be user agent as wells nowadays, more famili= ar) however the break w 2.0 terminology is jarring. I don=E2=80=99t feel ve= ry strongly about it but enough to type it. > > > > =C2=A72.2 > > It=E2=80=99s a bit odd to define the client identifier like it=E2=80=99s = something brand new when =C2=A72.1 already introduced it. This language fro= m the original 2.0 might need to be revised to accommodate that change. > > Wondering whether a warning against structured client_ids (eg identifiers= assembled thru some string template, like developer name+region+serial) wo= uld be in order. Perhaps in the security considerations? > > > > =C2=A72.3 > > P1 > > That sounds vaguely circular, given that being assigned credentials might= be considered part of the =E2=80=9Cestablish a client authentication metho= d=E2=80=9D task listed there. I=E2=80=99d simply say =E2=80=9Cif the client= is confidential or credentialed=E2=80=9D. > > P2 > > I=E2=80=99d add =E2=80=9Cby the authorization server=E2=80=9D for good me= asure. > > P3 > > That sounds vague. Shouldn=E2=80=99t it be mandatory for the AS to requir= e client auth for the client types who have creds? =E2=80=9Cif possible=E2= =80=9D seem to open the possibility of circumstances where that=E2=80=99s n= ot he case. > > P5 > > I think that this idea of identifying the client will need to be fleshed = out more for people to fully understand it. Credentialed clients can prove = that they are the same client instance across multiple transactions, which = some might consider a weak form of identification. To rule that out, it has= to be mentioned upfront IMO. If not here, in some of the considerations se= ction=E2=80=A6 with a forward reference here. > > P6 > > Do we say why anywhere? If yes, we should reference it. If not, perhaps w= e should. > > > > =C2=A72.3.1 > > We no longer mentioned the empty client secret, but we don=E2=80=99t forb= id it either. What=E2=80=99s our stance? > > > > =C2=A72.3.2 > > In =C2=A72.3 we mention MTLS, private_key_jwt, but here we just point the= reader to IANA. It looks like echoing those methods here might help clarit= y. > > > > =C2=A73.1 > > Last paragraph > > I have been in discussions where readers interpreted this as =E2=80=9Cyou= cannot send custom parameters to the authorization server=E2=80=9D. To pre= empt that mistake, we mighr consider calling out that custom extensions _ar= e_ permitted as long as the AS supports them. I know that=E2=80=99s what th= e current language says already. > > > > =C2=A73.1.1 > > Wondering if referring to some specific, well known extensions (like OIDC= ) might help readers to better understand this point. > > > > =C2=A73.1.2 > > RFC3986 6.2.1 talks about character by character comparison, but doesn=E2= =80=99t mention case sensitivity. I am sure it does elsewhere in the spec, = but for clarify and readability I recommend specifying the desired behavior= directly here. > > > > =C2=A73.1.2.1 > > Personally, I would advocate for a MUST here. True, lots of people won=E2= =80=99t comply at development time, but I think that=E2=80=99s OK as long a= s they do use TLS when going in production. > > Also, SameSite changes are making the use of HTTPS at dev time more and m= ore common. If OAuth2.1 is about picking the best of the security practices= , this seems like a an obvious candidate. > > > > =C2=A73.1.2.2 > > P3 > > =E2=80=9Clack of requiring=E2=80=9D doesn=E2=80=99t sound proper. > > > > =C2=A73.2 > > P2 > > Should we also say that the spec doesn=E2=80=99t care about _when_ the cl= ient obtains the endpoint? > > Last P > > Same considerations as =C2=A73.1 > > > > =C2=A73.2.1 > > P1 > > That=E2=80=99s stricter than =C2=A72.3P3 =E2=80=93 I think the language t= here should be tweaked to be coherent with the one here. > > > > =C2=A73.3 > > Wondering if the =E2=80=9Cscope strings order does not matter=E2=80=9D po= int should be somehow emphasized or clarified. I know of implementations wh= o considered heuristics such as =E2=80=9Cif the scopes requested correspond= to multiple resources, I=E2=80=99ll show consent for all byt the token eve= ntually issued when redeeming the code will have as audience the resource c= orresponding to the FIRST requested scope=E2=80=9D, which would violate the= order invariant requirement. > > > > =C2=A74 > > Potentially VERY confusing. I would recommend to be more specific and sta= te that =E2=80=9COAuth *2.1* defines two grant types=E2=80=9D. > > > > =C2=A74.1 > > Diagram > > Not critical. But I want to point it out. The first time I saw this diagr= am I found it confusing. The fact that the same numeral is assigned to mult= iple legs is just odd for anyone not already familiar with the flow, possib= ly still struggling to understand the client as a service side component. > > Also, now that we have mighty SVG support, I would strongly advocate for = a modern version of this diagram (there lines perhaps don=E2=80=99t need to= be broken into segments). > > Step 5 > > =E2=80=9Coptionally, a refresh token=E2=80=9D is too vague IMO. I will lo= ok for opportunities to clarify later in the spec, given that this might no= t be the best place to go in details. > > > > =C2=A74.1.1 > > Overall: a high summary of the steps in this preamble might help. The cur= rent denormalization in subsection can be pretty hard to follow for someone= seeing this for the first time. > > Also: creating challenge and verifier BEFORE assembling the request seems= profoundly counterintuitive to me, as it emphasizes a security measure ove= r the core function of this leg of the flow. Unless there=E2=80=99s a crypt= o reason for this current sequencing that I can=E2=80=99t see, I recommend = first creating the core request (what=E2=80=99s now 4.1.1.3) and then attac= hing challenge and verifier. Also, sending the message can be its own subse= ction rathe than being conflated with the last message composition subsecti= on. > > P1 > > =E2=80=9Cto begin=E2=80=9D remains a bit suspended, given that there=E2= =80=99s no obvious segue on what constitutes the steps after the beginning. > > P2 > > =E2=80=9Clater use with the authorization code=E2=80=9D could be clearer,= e.g. =E2=80=9Cat authorization code redemption time=E2=80=9D. At this poin= t that might still not be obvious for the reader. > > Mentioning the provenance of properties (parameters?) code_challenge and = code_verifier without first having introduced them might confuse people not= already familiar with them and the request process in general, as their fu= nction will not be obvious not naturally map with the preceding sentencer. > > P3 > > Imposing a MUST before knowing what those this are yet is not as clear as= it would be if this would be stated after their use and function has been = explained. > > > > =C2=A74.1.1.3 > > On state. Given the change vs OAuth2, I think it might be helpful to call= out the relevant section on the appendix about differences to help people = familiar w 2.0 not to miss this important change and avoid doing work twice= . > > > > =C2=A74.1.2 > > P2 > > Should we say that the code should be opaque to the client, to discourage= the use of structured code templates that can be partially manufactured? > > P8 > > =E2=80=9Che server MUST NOT include the "code_challenge" value in client= requests=E2=80=9D, was that meant to be =E2=80=9Cresponses=E2=80=9D? > > Qualifying =E2=80=9Cother entities=E2=80=9D (anyone but the AS?) might ma= ke this point clearer. > > > > =C2=A74.3 > > We mentioned extension grants in passing, but I don=E2=80=99t recall seei= ng a definition/description of their function in the context of the framewo= rk. Even a short sentence to that effect here would help, given that the se= ction title names them explicitly. Also, stressing that the device flow is = just one example and other extensions might differ (for example in their lo= gic to establish whether an access token request is valid and authorized) w= ould go a long way in helping the reader put this section in better focus. > > > > =C2=A75.1 > > On the access_token parameter. Given the discussions we had for the JWT A= T profile draft, I am wondering whether it should be called out here that t= he AT recipient is the RS, that the client should not expect to be able to = parse the access_token, and that the AS is under no obligation to use a con= sistent AT encoding outside of what is negotiated with the RS. I don=E2=80= =99t feel very strongly about this, or about where in the spec this should = be called out, but it sure would have made life easier in those discussions= - hence the comment. > > On the refresh_token parameter. The lack of details in how OAuth2 describ= es how/when an AS returns refresh tokens led to today=E2=80=99s complicated= situation in which many implementations issue RTs only when OIDC=E2=80=99s= offline_access is received in the scopes, as it was the only mention in pu= blic specs describing a concrete behavior. See the associated online_access= discussion on the OIDC list, as RTs gain importance as session artifacts o= f sort for SPAs now that implicit is dead and ITP makes iframe renewals pro= blematic. > > Unfortunately it is too late to be prescriptive here, as we cannot break = compatibility with whatever choices existing AS implementations made. Howev= er we can be more descriptive and give the reader a better idea of what=E2= =80=99s the range of possibilities. Some nonnormative examples of how exist= ing AS determine whether to issue an RT or not (eg as an option determined = at client registration time, or any other heuristic you guys encountered in= the wild) might help people to better understand their options and the int= ent of the specification here. > > =C2=A75.2 > > It might help to remind the reader here that extensions to the core spec = might specify or further specialize circumstances in which the errors menti= oned here are returned (for example, see the validation errors in the JWT A= T profile). There=E2=80=99s a mention of that in =C2=A77.3.1 but that=E2=80= =99s pretty far, and having even brief language here might be handy for peo= ple reading the spec for reference rather than cover to cover. > > > > =C2=A76 > > P1 > > I think the risk assessment is just one of the factors an AS might use to= decide whether to issue an RT or not. The current language suggests risk i= s the only determinant in that decision and that doesn=E2=80=99t seem right= . > > Saying that one might refresh tokens using other grants seems odd. A new = authorization code grant gets me a new token and offers me the opportunity = to describe what token I want (scopes etc), the fact that I might choose to= ask the exact same things I asked in the original request is expediency. I= would rather phrase this as the fact that the client can simply repeat the= original request, and external factors such as cookies, sessions and other= auth method specific options may allow the client to do so without prompti= ng the user. > > P2 > > We might need to be more precise here. Do we mean the scopes consented by= the RO in the request that led to the issuance of the RT being used? Just = saying consented by the RO for the client does not exclude cases in which t= here are more instances of the client in operation. Say that I am running u= ber on phone 1 and I consent to read my google calendar, getting AT1 and RT= 1. Say that on phone 2 I also run the uber app, and this time I consent to = write my google calendar, obtaining AT2 and RT2 on this new device. Now con= sider the various combinations here. Should RT2 allow me to get calendar:re= ad too, given that it was already consented by RO for this client? Should R= T1 allow me to get AT1=E2=80=99 containing calendar:write, given that RO co= nsented for it when using a different instance of the same client? Whatever= is the answer you want to the questions above, I think the spec should hav= e language clear enough to unambiguously determine the desired behavior. > > > > =C2=A76.1 > > It=E2=80=99s a bit confusing that half of the RT use requirements is in = =C2=A76 (the requirement to authenticate confidential/credentialed clients)= and half is in here, with the only differentiator being the nature of the = client. This is pretty minor, but I think I would personally find clearer i= f all the requirements for the use of an RT would be consolidated in a sing= le place. It=E2=80=99s true that the public client reqs are a SHOULD, but s= till. > > Rotation. > > Wondering whether it would be wise to advise the reader to have their AS = revoke all the still valid ATs issued by the AS from the same session/famil= y of RTs upon detection of a RT reuse. It is not uncommon for clients to re= quest new ATs before their projected expiration. > > P6 > > I think the =E2=80=9CMAY=E2=80=9D here might be confusing when applied to= the rotation, as in either the AS does it, or the scenario won=E2=80=99t w= ork. I understand this is formally correct, but perhaps explicitly calling = out some cases in which the AS might decide to do otherwise and acknowledge= that in that case the client will be stuck might help clarify. Also, if th= e public client protection measures were in =C2=A76 instead of here, there = would be less opportunities for confusion as it would be easier to grok tha= t this doesn=E2=80=99t apply to the rotation case only (now adjacent) but t= o other RT reissuance cases as well (eg sliding expiration). > > On the identical scopes requirement. Say that after obtaining RT1, which = includes scopes s1 and s2 for client c1, the RO revokes authorization for c= 1 to use s2. Should the AS fail the RT redemption, or return an AT with onl= y s1 and a scopes parameter informing the client of the change? As develope= r I would prefer the latter, to preserve the experience: but if we are adam= ant about the current language, I think it might be useful to explicitly ca= ll out that any changes to the grant on the AS side should result in failur= e of the RT redemption. > > P7 > > Calling out deprovisioning of RO might be useful as well. > > On =E2=80=9Cthe logout at the AS=E2=80=9D event, that=E2=80=99s definitel= y a valid case but I worry about how presenting that alone might reinforce = misunderstandings that equate RTs with sessions. There are certainly times = where we want that (see mentions earlier of the online_access discussions) = but there are also cases where the ability of a client to refresh ATs needs= to survive session boundaries (offline_access) and confusing the two are p= roblematic. I don=E2=80=99t have a clear solution here, just pointing out a= potential point of confusion. Maybe there will be more opportunities to cl= arify later in the spec. > > > > =C2=A77 > > P1 > > An important case to call out is the AS-RS colocation, where neither intr= ospection nor token format agreements are necessary. I suggest mentioning i= t openly. > > > > =C2=A77.2 > > =E2=80=9Cbearer tokens may be extended to include proof-of-possession te= chniques by other specifications=E2=80=9D sounds like an oxymoron. Wouldn= =E2=80=99t PoP make the token no longer bearer by the very definition above= ? > > It looks like we might need a term for simply =E2=80=9Ctoken=E2=80=9D. > > > > =C2=A77.2.1 > > Do we also want to forbid two tokens in the same request, using different= methods? Current language only constraints the behavior of one token. > > > > =C2=A77.2.3 > > The =E2=80=9Cinsufficient_scope=E2=80=9D description here is problematic.= The privileges the AT carries/points to are not necessarily (or exclusivel= y) represented by the included scopes (eg the RO might have granted documen= t:read to the client, but RO might have no privileges for the particular do= cument being requested in this particular call). It might be useful to spec= ify that =E2=80=9Cinvalid_scope=E2=80=9D should be used for authorization e= rrors that can be actually expressed in terms of delegated authorization, l= eaving to RS implementers the freedom to handle other authorization issues = (eg user privileges, RBAC, etc) with a different error code. Or at least, w= e should be clear that authorization logic not expressed via scopes is out = of scope (pun not intended) for this specification. > > Note, this isn=E2=80=99t an abstract problem: there are SDKs out there th= at use =E2=80=9Cinvalid_scope=E2=80=9D for every permission issues. Very co= nfusing. > > > > =C2=A77.3.1 > > We rewrite portions of 6750 in oauth2.1, but here we refer to it as its o= wn spec=E2=80=A6 that could be confusing as it=E2=80=99s unclear which part= s of 6750 are overridden by oauth2.1 (eg no more querystring) and what part= s remain normative. Perhaps we can call those things out in the sections me= ant to replace the corresponding sections in 6750. > > > > =C2=A77.4.2 > > Pedantic: although the title of the section states it, wondering whether = every instance of =E2=80=9Ctoken=E2=80=9D here should be =E2=80=9Caccess to= ken=E2=80=9D instead. Think of cases in which the spec is quoted in discuss= ions and disputes, where snippets can be pasted and mentioned outside of th= e context of this section. > > P2 > > Referencing the JWT AT profile as an example of extension providing the i= nfo out of scope for the core might help the reader grok a concrete example= . > > > > =C2=A77.4.3.5 > > =E2=80=9Cone hour or less=E2=80=9D seems very arbitrary, and breaks step = in respect to what the spec does elsewhere (eg we don=E2=80=99t give any in= dication of how long an AS should wait to invalidate an RT for inactivity, = but we do say the AS should do so). I would actually not provide any refere= nce value here. > > > > =C2=A77.4.3.6 > > Another opportunity of referencing the JWT AT profile for a concrete exam= ple of detailed audience restriction guidance in ATs. > > > > =C2=A77.4.3.7 > > Besides the indications given to clients here, should we also give guidan= ce to an RS to ignore tokens passed that way? > > > > =C2=A77.4.5 > > Along the same lines of the comments about delegated authorization earlie= r for =C2=A77.2.3. I think it would be useful to acknowledge here that ATs = might carry, and RSs might expect, authorization information that go beyond= the delegated authorization for 3rd party API case that is core to OAuth- = and remind the reader that those mechanisms are out of scope for oauth henc= e they shouldn=E2=80=99t expect those aspects to be addressed/handled/regul= ated by this specification. > > > > =C2=A78 > > As mentioned earlier, it seems a potentially confusing to reference the s= ection of a document being superseded. I do see an issue in redefining here= something already established and in use, hence I am not expecting this to= change. Just wondering whether we need to provide a more explicit map of t= he sections in 6749 that are being updated by oauth2.1. > > > > =C2=A79 > > Should we also say something about the scenario being chiefly 3rd party c= lients? We know lots of people use OAuth2 for 1st party scenarios and some = considerations might differ. This might be an opportunity to finally make t= hat clear. > > > > =C2=A79.1 > > P1 > > Well, the AS doesn=E2=80=99t really use client auth... the active part he= re is the client itself. Perhaps the AS can require it, when possible. > > P2 > > Unclear. Are we saying that if it is possible to safely distribute keys t= o client, the AS MUST use client auth? That seems odd, there might be other= reasons coming into play (cost, security posture) making that choice not v= iable. Or is the intent to say that the AS should not use client auth if th= e key distribution cannot be trusted? That sounds far more realistic, but t= hen the language should be tweaked or the reader might pick the former inte= rpretation. > > P3 > > The AS can=E2=80=99t really PREVENT creds forwarding as the RO machine mi= ght still have funny business going on (eg DNS attacks). Some softer langua= ge might be more accurate there. > > P4 > > That sounds very abstract. What does it mean? That the AS should consider= to issuing RTs to public clients? If that=E2=80=99s the case, we should ju= st say so=E2=80=A6 tho without more details, I don=E2=80=99t know how actio= nable the guidance here will be. I can see BoFa requiring a user to reauth = in their iPhone app after inactivity, but I don=E2=80=99t see Uber doing so= for their app.. unless they produce long lived ATs, which isn=E2=80=99t wh= at we want either. > > P5 > > This could be clearer. The dynamic client registration case just flesh ou= t the confidence level an AS can have in its identity, but does not offer a= corresponding privilege level to it =E2=80=93 whereas the second case does= mention assigned privileges explicitly. Also, pitting =E2=80=9Cdynamically= registered client=E2=80=9D vs =E2=80=9Cweb application=E2=80=9D might sugg= est the app type is a factor, whereas AFAIK 7591 can be used for registerin= g web apps too (whether that s wise or not is immaterial here). > > =C2=A79.2 > > Should we say something about whether native clients should be allowed to= be =E2=80=9Cupgraded=E2=80=9D as confidential clients in the future, or th= e other way round? I know of scenarios where people did that to preserve co= nsent info, but that seem sketchy security wise. > > P3 > > The SHOULD here refers to a requirement that in 10.3.1 is a MUST. I don= =E2=80=99t think the MUST is warranted (more about that in the 10.3.1 comme= nts) but if we do keep it, it looks like the level should be coherent here. > > P4 > > That example is compatible with a SHOULD- works now, but would look odd i= f we=E2=80=99d upgrade P3 with a MUST for coherence with 10.3.1. > > P5 > > Inclusion where/how? We should be precise IMO. If it=E2=80=99s just regis= tration material (eg not part of the redirect URI), we should mention how w= e expect it to be used in the context of OAuth- and if we don=E2=80=99t kno= w, perhaps we should not mention it here. > > > > =C2=A79.3 > > P1 > > I know it becomes clearer later on, but I think it would help here to exp= licitly call out confidential and credentialed client as the subject of thi= s sentence. Those are the only client types with credentials, hence the cur= rent language is formally correct. This is just for clarity. > > P2 > > I thought we require redirect URI registration in all cases? This makes i= t sound it=E2=80=99s only for public clients. > > P3 > > I have been in various discussions where people were attempting to interp= ret what =E2=80=9Cexplicit RO authentication=E2=80=9D means in practice. Is= it a full credential prompt regardless of whether one session already exis= ts? A selection between existing sessions, if present? > > P4 > > This is unclear. As it currently reads it seems to prohibit things like g= etting a new authz code silently via iframe (and prompt=3Dnone or equivalen= t UX suppressing mechanism, please ignore the ITP complications for the sak= e of argument). > > > > =C2=A79.3.1 > > P1 > > I don=E2=80=99t follow this sentence. The client identity cannot be prove= d for public clients (see also next P), and the native apps are public clie= nts unless otherwise specified (eg credentialed). > > P2 > > I find this misleading. Client side measures such as claimed schemes, dom= ains etc might work to prevent an app impersonating another app on the same= device/OS, but they aren=E2=80=99t guaranteed to be honored on other opera= ting systems. The AS has no way of knowing whether those measures have been= enforced on the client, hence it should not accept them as proof. > > > > =C2=A79.4.1 > > This is another place where a reference to the JWT AT profile would provi= de a concrete example of the conditions set forth here (eg RS guidance for = audience validation). > > Also, as mentioned earlier, it might be useful to remind the reader that = the AS might include in the token authorization information that go beyond = the delegated authz scenario OAuth2.x concerns itself with, and that those = aspects are beyond the scope of this specification. That would truly go a = long way preventing people from abusing and overextending the spec on scena= rios it is not meant to address. > > And even for the canonical scenarios, it might be useful to remind the re= ader that the RS might have extra logic not described in this spec that det= ermines whether the call will be authorized or otherwise- to dispel the not= ion that the AS is always the sole source of truth for authorization. > > > > =C2=A79.4.2 > > P2 > > Clarifying that MTLS is one instance of the sender constraint methods jus= t mentioned would prevent some readers considering that an independent, add= itional constraint. > > > > =C2=A79.5 > > In =C2=A76.1 we give more details about protection, should we have a back= ward reference to that section here? > > P2 > > Is it worth to specify that it doesn=E2=80=99t matter how the AS tracks t= he binding? (eg server side or embedded in the RT bits themselves). > > > > =C2=A79.6 > > P1 > > This language makes the assumption that for client cred grants, the sub w= ill take on the client_id value. That it certainly possible, but not a give= n. As such, the language here should be explicit abouty the fact that it=E2= =80=99s what we are expecting to happen in this particular scenario. > > P2 > > Referring to the client as the actor here is confusing as soon as you mov= e beyond client_id. When you talk about rhe sub or any other value, it=E2= =80=99s not as much the client as it is the developer who owns the client. = The difference is subtle but might be a source of confusion. > > =C2=A79.7 > > P3 > > I thought that we were going to make PKCE or nonce the only two mandatory= alternatives? Nothing against supporting state as an accepted way to achie= ve this, just surprised as I recall people being quite adamant about pushin= g PKCE. > > P4 > > Looks like the iss response parameter might make the distinct redirect UR= Is unnecessary? > > > > =C2=A79.7.1 > > The guidance in this section isn=E2=80=99t likely to be widely followed, = but I understand the rationale behind it. > > > > =C2=A79.8 > > P2 > > That=E2=80=99s probably obvious, but I think we should specify that those= multiple attempts should come with the expected code verifier as well for = the revocation logic to be triggered- if it=E2=80=99s just the code without= verifier, it doesn=E2=80=99t look like the leak went far enough to warrant= that intervention. > > P4 > > If this holds, then the remark about the use of state for CSRF in =C2=A79= .7 P3 seems unnecessary. > > P9 > > The use of MUST here seems incompatible with the concession of using nonc= e instead of PKCE. Either we allow it or we don=E2=80=99t=E2=80=A6 > > =C2=A79.11 > > P1 > > Now that we no longer trade in RO passwords, should we mention them here?= Sure, if the AS uses passwords they do need protection, but so do lots of = other things the AS might use as part of auth that we don=E2=80=99t mention= here for Occam=E2=80=99s razor. > > P3 > > What other means are we referring to? > > > > =C2=A79.12 > > =E2=80=9Cservice providers=E2=80=9D occurs for the first time in the docu= ment here. Tying the guidance to entities already mentioned in the doc (cli= ents, AS) might make things clearer/more actionable. > > > > =C2=A79.13 > > I understand that some of the comments in this area should be done on the= BCP rather than here, but here we are. That said=E2=80=A6 > > Blanket comment: this section seems to assume native app =3D=3D mobile ap= p, and that=E2=80=99s not strictly the case. Desktop apps have different ch= aracteristics and desktop OSes different capabilities. Would be clearer to = make a distinction when relying on mobile OS capabilitesas we appear to do= here. > > P2 > > Embedded user-agent !=3D fake external user agent, but P2 uses that inter= changeably. A desktop app might use an embedded browser for UX reasons and = making no attempt whatsoever to disguise that as an external agent. And I w= ould be pretty surprised to see a malware remover get rid of google drive f= or Mac, or Adobe products, or Office- all native apps using embedded user-a= gents for authentication. > > P3 > > It=E2=80=99s unclear how the AS would do that, given that user agent stri= ngs can be faked. Google has its ML based secret sauce, but that might not = be accessible by everyone. > > P4 > > This is mobile specific, doesn=E2=80=99t apply to desktop apps as readily= . Also unclear how that would change for the end user, given that pixel per= fect replicas can easily include fake address bars. More details on how a u= ser would detect an actual browser (presence of an existing session, access= to bookmarks etc) might add enough color to help the reader truly understa= nd the extent of the remedy power (or its true limits). > > > > =C2=A79.14 > > There=E2=80=99s no action for the reader here. If that reflects the actua= l situation (none of the roles described in this spec can do anything to mi= tigate or contain the damage, and solutions to prevent the situation lie ou= tside its purview eg use MDM software on your corporate devices) we should = explicitly say so. > > > > =C2=A79.15 > > A bit odd that we used CSRF throughout the document assuming the reader w= as familiar with it, but here we attempt a definition. > > Still confused on how we admit state as a valid mechanism, as opposed to = limiting to nonce and PKCE. Also note the potential discrepancy called out = earlier in which at code redemption time we appear to require PKCE, in cont= rast to admitting nonce/state here. > > > > =C2=A79.18.2 > > Wondering if here we should go as far as recommending the AS keeps dynami= c client registration OFF when it=E2=80=99s not needed. That might provide = good secure by default guidance for AS SDKs and product developers. > > > > =C2=A79.19 > > I assume we=E2=80=99d add the =E2=80=9Ciss=E2=80=9D response parameter as= alternative to the requirements here? > > > > =C2=A79.20 > > P1, P2, P3 > > The security properties described here do not apply as is to desktop apps= using embedded browsers. > > As mentioned earlier, on the desktop the separation between apps isn=E2= =80=99t as stark as on mobile- the keystrokes message pump is potentially a= ccessible at the user session level, encompassing multiple applications. Al= though process separation mechanisms are in place, the circumstances of the= execution and the OS specific features in this respect determine the degre= e to which entering credentials in one process makes the data inaccessible = by another. We should not claim advantages we cannot guarantee, and we shou= ld be explicit about what measures specific to dekstops should be considere= d to mitigate risks eg not executing apps as admins, enable and use UAC at = the right level on Windows or equivalent on other OSes, use app sandboxing = when the OS supports it, etc. Not suggesting we call out specific technolog= ies like UAC, but at least point at the category of security measures. > > P4 > > As mentioned above, the presence of the address bar can be easily faked b= y pixel perfect replicas- relying on those is security theater. > > P5 > > This is a valid concern, but if we want to frame it in the context of the= security considerations section we need to add more color (eg minimizing t= he situations in which one needs to enter creds is good security practice). > > > > Another thing we might add as lowlight for embedded browsers: password ma= nagers might not work, making the user=E2=80=99s life difficult and possibl= y promoting insecure situations (eg placing a random pwd in the clipboard, = where other apps might later steal it from). > > =C2=A79.21 > > Do we need this here, given that we cover this in depth earlier? > > > > =C2=A710 > > I find this subdivision confusing. We have native clients considerations = scattered throughout the entire specification, but now we have a dedicated = section that somewhat repeats some of the points already made while interle= aving new ones. Perhaps having a more specific section title, one that bett= er characterizes the content and intent of this section, would avoid giving= the impression that if the reader is interested in native clients, this is= the only section they need to read. > > P2 > > See discussion so far on native vs desktop. > > Also: I have been in ferocious discussions where people thought the exter= nal user agent HAD to be the browser, which we know isn=E2=80=99t the case = (hero apps like the FB SDK or OS features like sign in w Apple work just as= well). Some language here giving a nod to those non-browser external user = agents might help clarify. > > P4 > > See previous discussion on mobile!=3Ddesktop. > > P5 > > I=E2=80=99d always qualify the =E2=80=9Cbrowser=E2=80=9D with system, ext= ernal, device etc given that some reader calls the embedded user-agent =E2= =80=9Cembedded browser=E2=80=9D, hence just saying =E2=80=9Cbrowser=E2=80= =9D without modifiers is ambiguous. > > User authentication state.. on the device. I think specifying it will cla= rify what this really means. > > > > =C2=A710.1 > > Unless you scope this statement to MOBILE apps, I think the MUST here sho= uld be a SHOULD. > > The security posture of the desktop is different enough, and the quality = of the user experience when using a system browser bad and disomogeneous en= ough, that a MUST isn=E2=80=99t justified here. > > > > =C2=A710.2 > > Beware of the native-mobile false equivalence here. > > P3 > > One or two examples of non-browser external user agents might help. > > P4 > > Text pasted here is technically not a best practice but core. > > I see there are examples here, so no need to add them in P3. > > It=E2=80=99s unclear why the external browser is RECOMMENDED here- if it= =E2=80=99s because we can=E2=80=99t go in details of the behavior of non br= owser apps, it seems like we should say that much rather than making a reco= mmendation. In other words, RECOMMENDED expresses a strong preference for i= t, but if I am on iOS and I want to sign in with Facebook I am actually bet= ter off using their SDK both for security and user experience reasons than = to use the system browser. > > > > =C2=A710.3 > > Requesting a MUST for all 3 methods seems restrictive=E2=80=A6 why not re= questing at least one? > > > > =C2=A710.3.1 > > P3 > > This seems unnecessarily restrictive. 3.8 in 7595 is mostly SHOULDs, and = it refers to organizations rather than individuals. Not every developer own= s a domain, not every app goes on an app store and is meant for general pub= lic consumption. An organization sideloading apps on managed devices should= not be forced to follow those constraints if they control the environment = and aren=E2=80=99t worried about other apps competing for the same schema, = but placing a MUST here might compel SDK developers to embed validation che= cks that would make developers on those circumstances deal with complexity = without any security upside. In fact, apps should not even be required to h= ave internet access in the general case but this requirement does impose th= at. > > I think this is an important best practice that should be encouraged, REC= OMMENDED or even SHOULDed , but it shouldn=E2=80=99t be a MUST in the core = specification. > > > > =C2=A710.3.2 > > P4 > > Like everything happening on the client, the AS cannot really take that a= s guarantee. What might be true for an app running on iOS might not apply i= f the requests are all manufactured via cURL on a Linux box. The scope of t= hose measures is really limited to one particular device or devices sharing= an OS, outside of that cohort there are no guarantees. > > > > =C2=A710.3.3 > > This section should come with glaring warnings, anything actively listeni= ng on the client extends the attack surface- an app listening on the loopba= ck might now get affected by exploits in the local HTTP driver/local networ= k stack and taken over, executing with the same privileges as the user (rem= ember https://www.rapid7.com/db/vulnerabilities/WINDOWS-HOTFIX-MS15-034/). = The fact that the loopback is only accessible locally only reduces the risk= but doesn=E2=80=99t eliminate it, a local process with lower privileges mi= ght use that exploit for elevation of privileges for example. We should at = least recommend that the app hosting the loopback adapter runs with low pri= vileges, reiterate the =E2=80=9Clisten only when you must=E2=80=9D and gene= rally warn about the extra attack surface. > > As AS I might not want to support this method at all, both for security r= easons and for the extra logic the wildcard port entails at registration an= d request serving times, but right now the spec forces me to- more reasons = for relaxing the MUST for all 3 methods as mentioned earlier.. > > > > =C2=A712 > > I am not exactly sure where to place the following- this section (or a su= bsection) might be the best fit. > > As mentioned during the interim meeting, the omission of the implicit flo= w in OAuth2.1 has already caused a lot of people to interpret this as an in= direct deprecation of the use of implicit flow by OpenID Connect for obtain= ing ID_tokens, either via traditional response_modes or via form_post. > > We already debated and concluded that the reasons that led to the omissio= n of the implicit grant in 2.1 do not apply to ID_tokens, hence there=E2=80= =99s no reason for people to stop using OpenID Connect that way. > > Formally we are in the clear, as OIDC is vased on 2.0 the omission of imp= licit here does not prevent it as extension grant in OIDC anyway- but the f= ormal stance doesn=E2=80=99t help in preventing the confusion and assuaging= the concerns of the developers who aren=E2=80=99t as well versed as the pe= ople on this list in all things specifications. > > Because of this, I recommend we add some language here that prevents that= confusion. Something like > > > > * The Implicit grant ("response_type=3Dtoken") is omitted from this > > specification as per Section 2.1.2 of[I-D.ietf-oauth-security-topic= s ] > > Please note: the omission of the implicit grant from this specification d= oes not automatically imply that other extension grants obtaining credentia= ls directly from the authorization endpoint should also be discarded. For e= xample, the implicit flow defined in Section 3.2 of [OIDC ] remains valid for = all the response_type values not including =E2=80=9Ctoken=E2=80=9D. > > > > Although it might be a bit unusual to refer to details of specs from othe= r entities, this spec already mentions OpenID 9 times even excluding =C2=A7= 14.2- and as soon as the browser apps section will be included, that number= is certain to rise. And the confusion on this point is truly widespread- a= dding language along the lines of the above directly in the core would go a= long way to save a lot of grief. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --00000000000009aa9805ba50f992 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you both for the detailed review! I'm responding= inline to the things I've gone ahead and updated the draft to reflect.= There's a lot going on here, so I'm only=C2=A0touching the introdu= ction section for now. I've opened issues on the github repo to track t= he other items that will take some more discussion to work out.

---


=C2=A71.1
In the RS definition, wondering whether including t= he word =E2=80=9CAPI=E2=80=9D would help to clarify what an RS is in practi= ce.


= I agree, I added the sentence "The resource server is often accessible= via an API."

=C2=A71.3.1
We don=E2=80=99t say anywhere here that t= he authorization code can be exchanged for an access token. It can be somew= hat inferred from 1.2, but it=E2=80=99s a bit of an intelligence test (one = needs to infer from authorization grant).

Agreed, I've updated this with some language to clarify that the aut= horization code is later exchanged for an access token.
=C2=A0
P2
=E2=80=9Cobtains= authorization=E2=80=9D could be more specific, to reinforce that we are do= ing a delegated flow. =E2=80=9CObtains=E2=80=9D seem to suggest that we are= talking about consent, rather than AS side rules. If that=E2=80=99s the ca= se, calling it out might make the scenario clearer.
I'm not quite sure what you're getting at here, but I = agree this paragraph could be improved, so I've added some context to i= t around consent and MFA/delegated accounts.
=C2=A0
P3
Both the benefits listed ap= ply to confidential clients only. Not sure whether calling it out here woul= d help prevent confusion later on (eg people thinking that public clients c= an prove their identity) or would bring confusion on now (given that we did= n=E2=80=99t differentiate between client types yet). Either ways, formally = we are OK here; I am just thinking how to make things clearer. Perhaps defi= ning client types before grants might help being clearer here.=


I= think this is fine as is, technically the access token doesn't go thro= ugh the user agent in mobile apps since it's delivered directly to the = native app code in response to an HTTP request (which may even use certific= ate pinning if you want to be really paranoid).

<= br>

=C2=A71.3.2
A c= oncrete example of credential (eg shared secret) might help clarify things = here. Also, the fact that client credentials indicate both a grant in itsel= f and an artifact (which participates in other grants) is a well know sourc= e of confusion. Wondering if calling this out here might help.
=


I've added this: "(e.g. a `client_secret` or a priv= ate key used to sign a JWT)"


=C2=A71.4
In general, we use = =E2=80=9Caccess token=E2=80=9D and =E2=80=9Ctoken=E2=80=9D interchangeably-= perhaps pedantic, but I would suggest we always use =E2=80=9Caccess token= =E2=80=9D to prevent confusion with refresh tokens later on, and other toke= n types in other contexts (eg think ID tokens).


I = went through and updated every use of "token" that refers to an a= ccess token to actually mention access token.

P1
The client sho= uld treat the AT string as opaque, but that doesn=E2=80=99t necessarily mea= ns it is: in some cases the client CAN see inside the token, and with the c= urrent language they might interpret it as =E2=80=9Cin this case, it=E2=80= =99s OK to look- otherwise they would have made it opaque, per the spec=E2= =80=9D.


How about this: "The string is consid= ered opaque to the client, even if it has a structure. Depending on the aut= horization server, the access token string may be parseable by the resource= server."


I d= idn't think it was appropriate to add a "MUST NOT" or somethi= ng here given that this is still the introduction.


=C2=A71.5
Th= e first phrase of P1 is wonderfully clear. We should have the equivalent in= =C2=A71.3.1


Yes! "An authorization code is a= temporary credential used to obtain an access token." I've update= d the rest of the paragraph as well.


Not having defined a mechanis= m for requesting a RT here, leaving it to ASes to decide when and where, cr= eated the situation in which some AS only issues RTs when they get the offl= ine_access scope, with all the unfortunate consequences about RT lifetime v= s session lifetime etc=E2=80=A6 I know we can=E2=80=99t really change this = now as we don=E2=80=99t want to break existing AS implementations, but wond= ering if there=E2=80=99s anything we can say to further clarify/give reader= s a headsup about the ambiguity/diversity of behaviors they=E2=80=99ll enco= unter here.


Yeah this is tricky, I've added this to emphasize all the different = reasons why a RT may or may not be returned: "... and may be issued ba= sed on properties of the client, properties of the request, policies within= the authorization server, or any other criteria."


<= /div>
P2
It=E2=80=99s o= dd that we say =E2=80=9Cusually opaque to the client=E2=80=9D =C2=A0for the= RT while we decisively said opaque for the AT. Also, the client shouln=E2= =80=99t do anything w the RT content hence I think the same considerations = done for =C2=A71.4P2 apply here.

Good catch= . I'm fixing it the same way as the AT definition above.

=
=E2=80=9CThe token = denotes an identifier used to retrieve the authorization information=E2=80= =9D gets into the specifics of the implementation and it=E2=80=99s not univ= ersally true (some AS encrypt/sign the authz info in the RT itself and have= no server state whatsoever.

Yep, how about= : "The refresh token may be an identifier used to retrieve the authori= zation information or may encode this information into the string itself.&q= uot;

Step 3
Should we add a reference to RFC6750 here?


RFC6= 750 is being folded into this spec, so no I don't think so.
<= br>
=C2=A72
=E2= =80=9Cend-user interaction with an HTML registration form=E2=80=9D is oddly= specific =F0=9F=98=8A in particular, I think =E2=80=9Cend user=E2=80=9D mi= ght be misleading. We can either say =E2=80=9Cinteractive=E2=80=9D or refer= =E2=80=9Cthe client app developer=E2=80=9D or equivalent.
Overkill but = I=E2=80=99ll mention it anyway. Should we say that typically the client reg= istration in the non-dynamic scenario occurs in authenticated settings? Not= strictly necessary but might help the reader to tie what we say in this se= ction with their concrete experience.

Yeah = it does seem like it would be better to say "client developer" th= an "end user". Also "the client registers with the authoriza= tion server" is only true with dynamic client registration. I've u= pdated the whole section to hopefully make more sense.

=
I'm going to save processing the feedback from here out for a sepa= rate email.

---

Now I'= ;m going to respond to Justin's feedback on the introduction section in= the same way here.

=C2=A7Abstract
I think we should update =E2=80=9Cinteract= ion between the RO and the HTTP Service=E2=80=9D to be =E2=80=9Cthe RO and = an authorization service=E2=80=9D or something like that instead, since =E2= =80=9Cthe HTTP service=E2=80=9D referenced elsewhere in this paragraph is m= ore precisely the RS and not the AS, yet the interaction and approval happe= ns at the AS. OAuth 2.0 allowed the AS and RS to be separate, and 2.1 shoul= d go further to admit that in a lot of cases today, they are separate.=C2= =A0

I like it, it's a small change but = I think it makes it clearer.

=C2=A71: We should add a note on password use to th= is list:

Thanks! This is a great considerat= ion, I've added it to the list.

=C2=B63/4 can probably be collapsed to rea= d better, and some of the language cleaned up. Recommend:
=
Thanks, looks great, I've incorporated this.
<= br>
=C2=B66: (and th= roughout document) avoid use of gendered pronouns in favor of singular =E2= =80=9Cthey=E2=80=9D unless needed for clearer reading (such as an Alice and= Bob scenario)

Thank you! I've replaced= a few of them I found, and I will replace the rest if I find more later.

=C2=A7= 1.4: This section should mention introspection explicitly. Recommend rewrit= ing the intro to =C2=B63:

Looks great, than= ks.

= =C2=A71.5: =E2=80=9CThe string is usually opaque=E2=80=9D should be =E2=80= =9Cthe string is opaque"

Updated to &q= uot;the string is considered opaque" based on Vittorio's suggestio= n as well.

=C2=A71.6: this should probably refer to the TLS BCP195 here instead = of the RFC and version.

Great, thanks.

=C2=A71.8= : This should have explicit links to introspection (RFC7662), registration = (RFC7591, RFC7592), and discovery (RFC8414) inline as they=E2=80=99re given= as examples, instead of putting them all in the appendix. Perhaps also bri= ng up JWTs for token formats here as well.

= Great idea, thanks.

=C2=A71.X: Suggest adding a section on compatibility with=C2= =A0OAuth=C2=A02.0, either as part of =C2=A7= 1.8 or in a new section injected right after it. Some suggested starter tex= t:

Great idea, I've incorporated your i= nitial suggested and added a link to the existing "differences from OA= uth 2.0" section. We can expand further later as well.

<= /div>
---

I'm tracking the feedback that I= didn't respond to here from the Introduction section 1 on GitHub, (https://github.com/aa= ronpk/oauth-v2-1/issues) so feel free to continue the discussion in the= appropriate thread there, or respond on the mailing list with a reference = to the github issue so it's easier to manage.=C2=A0

I'll continue working on this feedback from the next sections as = well.

Thanks!

Aaron Parec= ki



On Tue, Dec 8, 2020 at 3:22 PM = <vittorio.bertocci@auth0.= com> wrote:

Dear authors,

It took ages but I finally managed t= o go thru a full review of the current OAuth2.1 draft. Apologies for the de= lay.

Metacomments:

  • The VAST majority of t= he comments are suggestions for improving clarity, mostly on historical lan= guage coming from 2.0 that I found myself having to clarify to customers an= d colleagues over and over thru the years. None of those are critical.
  • There are a few places where 2.1 requires a MUST I b= elieve to be unwarranted/too restrictive. For each of those I did my best t= o provide context and concrete examples.
  • A sizea= ble category of comments and disagreements on MUST come from treating mobil= e and desktop apps as largely equivalent under the =E2=80=9Cnative app=E2= =80=9D umbrella, despite of the vast gulf that separates the two both in te= rms of security posture and user experience. Again, I tried to be as matter= of fact as possible in there.
  • The main reason f= or which I spoke up during the IETF interim on oauth2.1 was the confusion t= he omission f the implicit grant caused among the devs using implicit in OI= DC for obtaining ID_tokens. I suggested some language to pre-empt the issue= , but I expect some iteration there.

Thanks,

V

=

=C2=A0

=C2= =A71

I wonder whether we should tak= e the opportunity offered by OAuth2.1 to clarify frequent points of confusi= on about OAuth, by explicitly calling out in the introduction what is out o= f scope.

For example: OAuth is not = an identity protocol, as it doesn=E2=80=99t concern itself with how resourc= e owners are authenticated; OAuth isn=E2=80=99t meant to address 1st party scenarios, although the reader is free to use it in that context= as well; and so on.

I believe ther= e is value in adding this in the introduction rather than relegating it in = some later considerations section, as the people who need this information = the most rarely read past this point.

=C2=A0

=C2=A71.1

In the RS definition, wondering whether including = the word =E2=80=9CAPI=E2=80=9D would help to clarify what an RS is in pract= ice.

=C2=A0

=C2=A71.2

I always= found this part extraordinarily difficult to decipher. I get that this is = the first description and doesn=E2=80=99t have to be exhaustive and conside= r all cases (eg it=E2=80=99s ok if step 3 claims that the client authentica= tes w the AS even tho that=E2=80=99s only for confidential clients), but I = think it could be much clearer than it is today.

Step 1 says

The client requests authorization from the resource owner.=C2= =A0 The authorization request can be made directly to the resource owner (a= s shown), or preferably indirectly via the authorization server as an inter= mediary.

Besides the fact th= at =E2=80=9Crequests authorization=E2=80=9D is a bit vague, this step and t= he corresponding diagram leg does not correspond at all to what normally ha= ppens- to get a code, the client does need to hit the AS and the mention in= passing in the text isn=E2=80=99t enough to figure that out. Also, with th= e omission of ROPG there really isn=E2=80=99t any way of asking anything to= the RO directly (the client creds doesn=E2=80=99t involve the RO).<= u>

I would recommend updating that diagram to= be more descriptive of the canonical scenario.

Step 2

mentions the = 2 grants defined in the spec, but only one of them represents the RO=E2=80= =99s authorization. Claiming that the client itself is the RO is a formalis= m that doesn=E2=80=99t meet the reader=E2=80=99s intuition at this point.

Step 5

The language here triggered multiple discussions, in particular= on whether the AT can actually be used to ascertain the identity of the cl= ient =E2=80=93 that isn=E2=80=99t the case for public clients, for example;= besides, that=E2=80=99s not really the highest order bit of the AT. If it = is, it seems that the spec should be more explicit about how client identif= ication from the RS by means of an AT works. If it isn=E2=80=99t, perhaps w= e should change the language to omit authenticate.

The last paragraph is emblematic IMO =E2=80=93 if the prefe= rred method is very different from the diagram here, and if the abstraction= presented here is not terribly useful (given that we no longer have multip= le RO based grants, excluding the extension grants that are still too far a= t this point to warrant a cognitive downpayment for the reader) I wonder wh= ether we=E2=80=99d be better off doing the authz code diagram directly (and= mention that we also have the client creds grant separately).

=C2=A0

= =C2=A71.3

I understand that we can= =E2=80=99t really change this because we inherit from OAuth 2 but I=E2=80= =99ll mention it anyway- modeling clients as ROs is problematic, as it does= n=E2=80=99t often match what happens in practice. A confidential client mig= ht batch-read a user=E2=80=99s inbox searching for ad words, but the resour= ce owner remains the user.

I know w= e straighten things up in 1.3.2, but the positioning here is confusing.<= /u>

Also: isn=E2=80=99t the refresh token = grant a core-specified grant as well? I know I am nitpicking.=

=C2=A7= 1.3.1

We don=E2=80=99t say anywhere= here that the authorization code can be exchanged for an access token. It = can be somewhat inferred from 1.2, but it=E2=80=99s a bit of an intelligenc= e test (one needs to infer from authorization grant).

P2

=E2=80=9Cobta= ins authorization=E2=80=9D could be more specific, to reinforce that we are= doing a delegated flow. =E2=80=9CObtains=E2=80=9D seem to suggest that we = are talking about consent, rather than AS side rules. If that=E2=80=99s the= case, calling it out might make the scenario clearer.

P3

Both the ben= efits listed apply to confidential clients only. Not sure whether calling i= t out here would help prevent confusion later on (eg people thinking that p= ublic clients can prove their identity) or would bring confusion on now (gi= ven that we didn=E2=80=99t differentiate between client types yet). Either = ways, formally we are OK here; I am just thinking how to make things cleare= r. Perhaps defining client types before grants might help being clearer her= e.

=C2=A0

=C2=A71.3.2

A concre= te example of credential (eg shared secret) might help clarify things here.= Also, the fact that client credentials indicate both a grant in itself and= an artifact (which participates in other grants) is a well know source of = confusion. Wondering if calling this out here might help.

=

=C2=A0

=C2= =A71.4

In general, we use =E2=80=9C= access token=E2=80=9D and =E2=80=9Ctoken=E2=80=9D interchangeably- perhaps = pedantic, but I would suggest we always use =E2=80=9Caccess token=E2=80=9D = to prevent confusion with refresh tokens later on, and other token types in= other contexts (eg think ID tokens).

P1

The client should treat the A= T string as opaque, but that doesn=E2=80=99t necessarily means it is: in so= me cases the client CAN see inside the token, and with the current language= they might interpret it as =E2=80=9Cin this case, it=E2=80=99s OK to look-= otherwise they would have made it opaque, per the spec=E2=80=9D.=

=C2=A0

=C2=A71.5

The first phrase of P1= is wonderfully clear. We should have the equivalent in =C2=A71.3.1<= u>

Not having defined a mechanism for request= ing a RT here, leaving it to ASes to decide when and where, created the sit= uation in which some AS only issues RTs when they get the offline_access sc= ope, with all the unfortunate consequences about RT lifetime vs session lif= etime etc=E2=80=A6 I know we can=E2=80=99t really change this now as we don= =E2=80=99t want to break existing AS implementations, but wondering if ther= e=E2=80=99s anything we can say to further clarify/give readers a headsup a= bout the ambiguity/diversity of behaviors they=E2=80=99ll encounter here.

P2

It=E2=80=99s odd that we say =E2=80=9Cusually opaque to the client= =E2=80=9D=C2=A0 for the RT while we decisively said opaque for the AT. Also= , the client shouln=E2=80=99t do anything w the RT content hence I think th= e same considerations done for =C2=A71.4P2 apply here.

=E2=80=9CThe token denotes an identifier used to retrieve the auth= orization information= =E2=80=9D gets into the specifics of the implementation and it=E2=80=99s not univ= ersally true (some AS encrypt/sign the authz info in the RT itself and have= no server state whatsoever.

Step 3

Should we add a reference= to RFC6750 here?

=C2=A0<= /u>

=C2=A71.8

Should we say rich *delegated* authorization framework?<= u>

=C2=A0

=C2=A72

=E2=80=9Cend-user interaction wit=
h an HTML registration form=E2=80=9D is oddly specific =F0=9F=98=8A in particular, I think =E2=
=80=9Cend user=E2=80=9D might be misleading. We can either say =E2=80=9Cint=
eractive=E2=80=9D or refer =E2=80=9Cthe client app developer=E2=80=9D or eq=
uivalent.
Overkill but I=E2=80=99ll mention it anyway. Sh=
ould we say that typically the client registration in the non-dynamic scena=
rio occurs in authenticated settings? Not strictly necessary but might help=
 the reader to tie what we say in this section with their concrete experien=
ce.
=C2=A0
=C2=A72.1
=
P4
=E2=80=9CAuthorizat=
ion servers SHOULD consider the level of confidence in a client's ident=
ity when deciding whether they allow such a client access to more critical =
functions, such as the Client Credentials grant type.=E2=80=9D 
I don=E2=80=99t understand this sentence. Is the client credentials =
grant type a =E2=80=9Cmore critical function=E2=80=9D? Or is it a level of =
confidence? Either ways, I think it needs clarifying.<=
/pre>
P5<=
u>
IMPORTANT: this is going to break many OAuth implementati=
ons with significant adoption. Auth0 is fine (each client_id is tied to a s=
ingle client type) but I know of others that will break.
=
I suggest softening to a SHOULD NOT.
=E2=80=9Cbrowser-bas=
ed application=E2=80=9D
I am not convinced this is so muc=
h easier than the original =E2=80=9Cuser-agent-based=E2=80=9D. I understand=
 the advantages (dovetails w the BCP, more precise given that apps can be u=
ser agent as wells nowadays, more familiar) however the break w 2.0 termino=
logy is jarring. I don=E2=80=99t feel very strongly about it but enough to =
type it.
=C2=A0
=C2=A72.2=

It=E2=80=99s a bit odd to define the client identifier like it=E2=80=
=99s something brand new when =C2=A72.1 already introduced it. This languag=
e from the original 2.0 might need to be revised to accommodate that change=
.
Wondering whether a warning against structured client_i=
ds (eg identifiers assembled thru some string template, like developer name=
+region+serial) would be in order. Perhaps in the security considerations?<=
u>
=C2=A0
=C2=A72.3
P1
That sounds vaguely circular, given that being assigned cr=
edentials might be considered part of the =E2=80=9Cestablish a client authe=
ntication method=E2=80=9D task listed there. I=E2=80=99d simply say =E2=80=
=9Cif the client is confidential or credentialed=E2=80=9D.
P2
I=E2=80=99d add =E2=80=9Cby the authorization server=
=E2=80=9D for good measure.
P3
=

That sou=
nds vague. Shouldn=E2=80=99t it be mandatory for the AS to require client a=
uth for the client types who have creds? =E2=80=9Cif possible=E2=80=9D seem=
 to open the possibility of circumstances where that=E2=80=99s not he case.=

P5
I think that this idea of identifyi=
ng the client will need to be fleshed out more for people to fully understa=
nd it. Credentialed clients can prove that they are the same client instanc=
e across multiple transactions, which some might consider a weak form of id=
entification. To rule that out, it has to be mentioned upfront IMO. If not =
here, in some of the considerations section=E2=80=A6 with a forward referen=
ce here.
P6
Do we say why anywhere? If =
yes, we should reference it. If not, perhaps we should.
<=
u>=C2=A0
=C2=A72.3.1
We no longer mentione=
d the empty client secret, but we don=E2=80=99t forbid it either. What=E2=
=80=99s our stance?
=C2=A0
=C2=A72.3.2<=
u>
In =C2=A72.3 we mention MTLS, private_key_jwt, but here w=
e just point the reader to IANA. It looks like echoing those methods here m=
ight help clarity.
=C2=A0
=
=C2=A73.1<=
/u>
Last paragraph
I have been in discussions =
where readers interpreted this as =E2=80=9Cyou cannot send custom parameter=
s to the authorization server=E2=80=9D. To preempt that mistake, we mighr c=
onsider calling out that custom extensions _are_ permitted as long as the A=
S supports them. I know that=E2=80=99s what the current language says alrea=
dy.
=C2=A0
=C2=A73.1.1
Wondering if referring to some specific, well known extensions (like OIDC=
) might help readers to better understand this point.<=
/pre>
=
=C2=A0
=C2=A73.1.2
RFC3986 6.2.1 talks abo=
ut character by character comparison, but doesn=E2=80=99t mention case sens=
itivity. I am sure it does elsewhere in the spec, but for clarify and reada=
bility I recommend specifying the desired behavior directly here.=

=C2=A0
=C2=A73.1.2.1
<=
pre>Personall=
y, I would advocate for a MUST here. True, lots of people won=E2=80=99t com=
ply at development time, but I think that=E2=80=99s OK as long as they do u=
se TLS when going in production. 
Also, SameSite changes =
are making the use of HTTPS at dev time more and more common. If OAuth2.1 i=
s about picking the best of the security practices, this seems like a an ob=
vious candidate.
=C2=A0
=C2=A73.1.2.2
P3
=E2=80=9Clack of requiring=E2=80=9D d=
oesn=E2=80=99t sound proper.
=C2=A0<=
/pre>
=C2=
=A73.2
P2
Should we also say that the s=
pec doesn=E2=80=99t care about _when_ the client obtains the endpoint?
Last P
Same considerations as =C2=A73.1<=
/u>
=C2=A0
=C2=A73.2.1
P1=

That=E2=80=99s stricter than =C2=A72.3P3 =E2=80=93 I think =
the language there should be tweaked to be coherent with the one here.
=C2=A0
=C2=A73.3
=

Wonderin=
g if the =E2=80=9Cscope strings order does not matter=E2=80=9D point should=
 be somehow emphasized or clarified. I know of implementations who consider=
ed heuristics such as =E2=80=9Cif the scopes requested correspond to multip=
le resources, I=E2=80=99ll show consent for all byt the token eventually is=
sued when redeeming the code will have as audience the resource correspondi=
ng to the FIRST requested scope=E2=80=9D, which would violate the order inv=
ariant requirement. 
=C2=A0
=C2=A74<=
/u>
Potentially VERY confusing. I would recommend to be more spe=
cific and state that =E2=80=9COAuth 2.1 defines two grant types=E2=
=80=9D. 
=C2=A0
=C2=A74.1=

Diagram
Not critical. But I want to point it out. Th=
e first time I saw this diagram I found it confusing. The fact that the sam=
e numeral is assigned to multiple legs is just odd for anyone not already f=
amiliar with the flow, possibly still struggling to understand the client a=
s a service side component.
Also, now that we have mighty=
 SVG support, I would strongly advocate for a modern version of this diagra=
m (there lines perhaps don=E2=80=99t need to be broken into segments).
Step 5
=E2=80=9Coptionally, a refresh token=
=E2=80=9D is too vague IMO. I will look for opportunities to clarify later =
in the spec, given that this might not be the best place to go in details.<=
u>
=C2=A0
=C2=A74.1.1=

Ov=
erall: a high summary of the steps in this preamble might help. The current=
 denormalization in subsection can be pretty hard to follow for someone see=
ing this for the first time. 
Also: creating challenge an=
d verifier BEFORE assembling the request seems profoundly counterintuitive =
to me, as it emphasizes a security measure over the core function of this l=
eg of the flow. Unless there=E2=80=99s a crypto reason for this current seq=
uencing that I can=E2=80=99t see, I recommend first creating the core reque=
st (what=E2=80=99s now 4.1.1.3) and then attaching challenge and verifier. =
Also, sending the message can be its own subsection rathe than being confla=
ted with the last message composition subsection.
P1
=E2=80=9Cto begin=E2=80=9D remains a bit suspended, given tha=
t there=E2=80=99s no obvious segue on what constitutes the steps after the =
beginning. 
P2
=E2=80=9Clater use with =
the authorization code=E2=80=9D could be clearer, e.g. =E2=80=9Cat authoriz=
ation code redemption time=E2=80=9D. At this point that might still not be =
obvious for the reader.
Mentioning the provenance of prop=
erties (parameters?) code_challenge and code_verifier without first having =
introduced them might confuse people not already familiar with them and the=
 request process in general, as their function will not be obvious not natu=
rally map with the preceding sentencer.
P3<=
/span>
Imposing a MUST before knowing what those this are yet is not as clear =
as it would be if this would be stated after their use and function has bee=
n explained.
=C2=A0
=C2=A74.1.1.3
On state. Given the change vs OAuth2, I think it might be help=
ful to call out the relevant section on the appendix about differences to h=
elp people familiar w 2.0 not to miss this important change and avoid doing=
 work twice.
=C2=A0
=C2=A74.1.2<=
u>
P2
Should we say that the code should be opaqu=
e to the client, to discourage the use of structured code templates that ca=
n be partially manufactured?
P8
=E2=80=
=9Che server MUST NOT=C2=A0 include the "code_challenge" value in=
 client requests=E2=80=9D, was that meant to be =E2=80=9Cresponses=E2=80=9D=
? 
Qualifying =E2=80=9Cother entities=E2=80=9D (anyone bu=
t the AS?) might make this point clearer.
=C2=A0
=C2=A74.3
We mentioned extension grants in pass=
ing, but I don=E2=80=99t recall seeing a definition/description of their fu=
nction in the context of the framework. Even a short sentence to that effec=
t here would help, given that the section title names them explicitly. Also=
, stressing that the device flow is just one example and other extensions m=
ight differ (for example in their logic to establish whether an access toke=
n request is valid and authorized) would go a long way in helping the reade=
r put this section in better focus.
=C2=A0<=
/span>
=C2=A75.1
On the access_token parameter. Given the di=
scussions we had for the JWT AT profile draft, I am wondering whether it sh=
ould be called out here that the AT recipient is the RS, that the client sh=
ould not expect to be able to parse the access_token, and that the AS is un=
der no obligation to use a consistent AT encoding outside of what is negoti=
ated with the RS. I don=E2=80=99t feel very strongly about this, or about w=
here in the spec this should be called out, but it sure would have made lif=
e easier in those discussions- hence the comment.
On the =
refresh_token parameter. The lack of details in how OAuth2 describes how/wh=
en an AS returns refresh tokens led to today=E2=80=99s complicated situatio=
n in which many implementations issue RTs only when OIDC=E2=80=99s offline_=
access is received in the scopes, as it was the only mention in public spec=
s describing a concrete behavior. See the associated online_access discussi=
on on the OIDC list, as RTs gain importance as session artifacts of sort fo=
r SPAs now that implicit is dead and ITP makes iframe renewals problematic.=

Unfortunately it is too late to be prescriptive here, as=
 we cannot break compatibility with whatever choices existing AS implementa=
tions made. However we can be more descriptive and give the reader a better=
 idea of what=E2=80=99s the range of possibilities. Some nonnormative examp=
les of how existing AS determine whether to issue an RT or not (eg as an op=
tion determined at client registration time, or any other heuristic you guy=
s encountered in the wild) might help people to better understand their opt=
ions and the intent of the specification here.
 
=C2=A75.2
It might help to remind the reader he=
re that extensions to the core spec might specify or further specialize cir=
cumstances in which the errors mentioned here are returned (for example, se=
e the validation errors in the JWT AT profile). There=E2=80=99s a mention o=
f that in =C2=A77.3.1 but that=E2=80=99s pretty far, and having even brief =
language here might be handy for people reading the spec for reference rath=
er than cover to cover.
=C2=A0
=

=C2=A76<=
u>
P1
I think the risk assessment is just =
one of the factors an AS might use to decide whether to issue an RT or not.=
 The current language suggests risk is the only determinant in that decisio=
n and that doesn=E2=80=99t seem right.
Saying that one mi=
ght refresh tokens using other grants seems odd. A new authorization code g=
rant gets me a new token and offers me the opportunity to describe what tok=
en I want (scopes etc), the fact that I might choose to ask the exact same =
things I asked in the original request is expediency. I would rather phrase=
 this as the fact that the client can simply repeat the original request, a=
nd external factors such as cookies, sessions and other auth method specifi=
c options may allow the client to do so without prompting the user.<=
u>
P2
We might need to be more precise here. Do w=
e mean the scopes consented by the RO in the request that led to the issuan=
ce of the RT being used? Just saying consented by the RO for the client doe=
s not exclude cases in which there are more instances of the client in oper=
ation. Say that I am running uber on phone 1 and I consent to read my googl=
e calendar, getting AT1 and RT1. Say that on phone 2 I also run the uber ap=
p, and this time I consent to write my google calendar, obtaining AT2 and R=
T2 on this new device. Now consider the various combinations here. Should R=
T2 allow me to get calendar:read too, given that it was already consented b=
y RO for this client? Should RT1 allow me to get AT1=E2=80=99 containing ca=
lendar:write, given that RO consented for it when using a different instanc=
e of the same client? Whatever is the answer you want to the questions abov=
e, I think the spec should have language clear enough to unambiguously dete=
rmine the desired behavior.
=C2=A0
=C2=
=A76.1
It=E2=80=99s a bit confusing that half of the RT u=
se requirements is in =C2=A76 (the requirement to authenticate confidential=
/credentialed clients) and half is in here, with the only differentiator be=
ing the nature of the client. This is pretty minor, but I think I would per=
sonally find clearer if all the requirements for the use of an RT would be =
consolidated in a single place. It=E2=80=99s true that the public client re=
qs are a SHOULD, but still.
Rotation.
W=
ondering whether it would be wise to advise the reader to have their AS rev=
oke all the still valid ATs issued by the AS from the same session/family o=
f RTs upon detection of a RT reuse. It is not uncommon for clients to reque=
st new ATs before their projected expiration.
P6
I think the =E2=80=9CMAY=E2=80=9D here might be confusing when ap=
plied to the rotation, as in either the AS does it, or the scenario won=E2=
=80=99t work. I understand this is formally correct, but perhaps explicitly=
 calling out some cases in which the AS might decide to do otherwise and ac=
knowledge that in that case the client will be stuck might help clarify. Al=
so, if the public client protection measures were in =C2=A76 instead of her=
e, there would be less opportunities for confusion as it would be easier to=
 grok that this doesn=E2=80=99t apply to the rotation case only (now adjace=
nt) but to other RT reissuance cases as well (eg sliding expiration).
On the identical scopes requirement. Say that after obtaining =
RT1, which includes scopes s1 and s2 for client c1, the RO revokes authoriz=
ation for c1 to use s2. Should the AS fail the RT redemption, or return an =
AT with only s1 and a scopes parameter informing the client of the change? =
As developer I would prefer the latter, to preserve the experience: but if =
we are adamant about the current language, I think it might be useful to ex=
plicitly call out that any changes to the grant on the AS side should resul=
t in failure of the RT redemption.
P7
C=
alling out deprovisioning of RO might be useful as well.
=
On =E2=80=9Cthe logout at the AS=E2=80=9D event, that=E2=80=99s definitely =
a valid case but I worry about how presenting that alone might reinforce mi=
sunderstandings that equate RTs with sessions. There are certainly times wh=
ere we want that (see mentions earlier of the online_access discussions) bu=
t there are also cases where the ability of a client to refresh ATs needs t=
o survive session boundaries (offline_access) and confusing the two are pro=
blematic. I don=E2=80=99t have a clear solution here, just pointing out a p=
otential point of confusion. Maybe there will be more opportunities to clar=
ify later in the spec.
=C2=A0
<=
pre>=C2=A77
P1
An important case to call out is the =
AS-RS colocation, where neither introspection nor token format agreements a=
re necessary. I suggest mentioning it openly.
=C2=
=A0
=C2=A77.2
=E2=80=9Cbearer tokens may be ex=
tended to include proof-of-possession=C2=A0 techniques by other specificati=
ons=E2=80=9D sounds like an oxymoron. Wouldn=E2=80=99t PoP make the token n=
o longer bearer by the very definition above?
It looks li=
ke we might need a term for simply =E2=80=9Ctoken=E2=80=9D.
=C2=A0
=C2=A77.2.1
Do we also want t=
o forbid two tokens in the same request, using different methods? Current l=
anguage only constraints the behavior of one token.
=C2=A0
=C2=A77.=
2.3
The =E2=80=9Cinsufficient_scope=E2=
=80=9D description here is problematic. The privileges the AT carries/point=
s to are not necessarily (or exclusively) represented by the included scope=
s (eg the RO might have granted document:read to the client, but RO might h=
ave no privileges for the particular document being requested in this parti=
cular call). It might be useful to specify that =E2=80=9Cinvalid_scope=E2=
=80=9D should be used for authorization errors that can be actually express=
ed in terms of delegated authorization, leaving to RS implementers the free=
dom to handle other authorization issues (eg user privileges, RBAC, etc) wi=
th a different error code. Or at least, we should be clear that authorizati=
on logic not expressed via scopes is out of scope (pun not intended) for th=
is specification.
Note, this isn=E2=80=99t an abstract pr=
oblem: there are SDKs out there that use =E2=80=9Cinvalid_scope=E2=80=9D fo=
r every permission issues. Very confusing.
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif">=C2=A0<=
u>
=C2=A77.3.1
We rewrite portions of 6750 in oau=
th2.1, but here we refer to it as its own spec=E2=80=A6 that could be confu=
sing as it=E2=80=99s unclear which parts of 6750 are overridden by oauth2.1=
 (eg no more querystring) and what parts remain normative. Perhaps we can c=
all those things out in the sections meant to replace the corresponding sec=
tions in 6750.
=C2=A0
=C2=A77.4.2
Pedantic: although the title of the section states it, wonderi=
ng whether every instance of =E2=80=9Ctoken=E2=80=9D here should be =E2=80=
=9Caccess token=E2=80=9D instead. Think of cases in which the spec is quote=
d in discussions and disputes, where snippets can be pasted and mentioned o=
utside of the context of this section.
P2
Referencing the JWT AT profile as an example of extension providing the =
info out of scope for the core might help the reader grok a concrete exampl=
e.
=C2=A0
=C2=A77.4.3.5
=E2=80=9Cone hour or less=E2=80=9D seems very arbitrary, and breaks step=
 in respect to what the spec does elsewhere (eg we don=E2=80=99t give any i=
ndication of how long an AS should wait to invalidate an RT for inactivity,=
 but we do say the AS should do so). I would actually not provide any refer=
ence value here.
=C2=A0
=C2=A77.4.3.6
Another opportunity of referencing the JWT AT profile for =
a concrete example of detailed audience restriction guidance in ATs.=

=C2=A0
=C2=A77.4.3.7
Beside=
s the indications given to clients here, should we also give guidance to an=
 RS to ignore tokens passed that way?
=C2=A0
=C2=A77.4.5
Along the same lines of the comments ab=
out delegated authorization earlier for =C2=A77.2.3. I think it would be us=
eful to acknowledge here that ATs might carry, and RSs might expect, author=
ization information that go beyond the delegated authorization for 3rd=
 party API case that is core to OAuth- and remind the reader that tho=
se mechanisms are out of scope for oauth hence they shouldn=E2=80=99t expec=
t those aspects to be addressed/handled/regulated by this specification. 
=C2=A0
=C2=A78
As ment=
ioned earlier, it seems a potentially confusing to reference the section of=
 a document being superseded. I do see an issue in redefining here somethin=
g already established and in use, hence I am not expecting this to change. =
Just wondering whether we need to provide a more explicit map of the sectio=
ns in 6749 that are being updated by oauth2.1.
=C2=
=A0
=C2=A79
Should we also say something about=
 the scenario being chiefly 3rd party clients? We know lots of p=
eople use OAuth2 for 1st party scenarios and some considerations=
 might differ. This might be an opportunity to finally make that clear.<=
/u>
=C2=A0
=C2=A79.1
P1
Well, the AS doesn=E2=80=99t really use client auth... the ac=
tive part here is the client itself. Perhaps the AS can require it, when po=
ssible.
P2
Unclear. Are we saying that =
if it is possible to safely distribute keys to client, the AS MUST use clie=
nt auth? That seems odd, there might be other reasons coming into play (cos=
t, security posture) making that choice not viable. Or is the intent to say=
 that the AS should not use client auth if the key distribution cannot be t=
rusted? That sounds far more realistic, but then the language should be twe=
aked or the reader might pick the former interpretation.
=
P3
The AS can=E2=80=99t really PREVENT creds forwarding a=
s the RO machine might still have funny business going on (eg DNS attacks).=
 Some softer language might be more accurate there. 
P4
That sounds very abstract. What does it mean? That the AS =
should consider to issuing RTs to public clients? If that=E2=80=99s the cas=
e, we should just say so=E2=80=A6 tho without more details, I don=E2=80=99t=
 know how actionable the guidance here will be. I can see BoFa requiring a =
user to reauth in their iPhone app after inactivity, but I don=E2=80=99t se=
e Uber doing so for their app.. unless they produce long lived ATs, which i=
sn=E2=80=99t what we want either.
P5 
T=
his could be clearer. The dynamic client registration case just flesh out t=
he confidence level an AS can have in its identity, but does not offer a co=
rresponding privilege level to it =E2=80=93 whereas the second case does me=
ntion assigned privileges explicitly. Also, pitting =E2=80=9Cdynamically re=
gistered client=E2=80=9D vs =E2=80=9Cweb application=E2=80=9D might suggest=
 the app type is a factor, whereas AFAIK 7591 can be used for registering w=
eb apps too (whether that s wise or not is immaterial here).<=
/span>
=C2=A79.2
Should we say something about whether nativ=
e clients should be allowed to be =E2=80=9Cupgraded=E2=80=9D as confidentia=
l clients in the future, or the other way round? I know of scenarios where =
people did that to preserve consent info, but that seem sketchy security wi=
se.
P3
The SHOULD here refers to a requ=
irement that in 10.3.1 is a MUST. I don=E2=80=99t think the MUST is warrant=
ed (more about that in the 10.3.1 comments) but if we do keep it, it looks =
like the level should be coherent here.
P4<=
/span>
That example is compatible with a SHOULD- works now, but would look odd=
 if we=E2=80=99d upgrade P3 with a MUST for coherence with 10.3.1.
P5
Inclusion where/how? We should be precise IM=
O. If it=E2=80=99s just registration material (eg not part of the redirect =
URI), we should mention how we expect it to be used in the context of OAuth=
- and if we don=E2=80=99t know, perhaps we should not mention it here. <=
/u>
=C2=A0
=C2=A79.3
P1
I know it becomes clearer later on, but I think it would help=
 here to explicitly call out confidential and credentialed client as the su=
bject of this sentence. Those are the only client types with credentials, h=
ence the current language is formally correct. This is just for clarity.=

P2
I thought we require redirect URI regi=
stration in all cases? This makes it sound it=E2=80=99s only for public cli=
ents.
P3
I have been in various discuss=
ions where people were attempting to interpret what =E2=80=9Cexplicit RO au=
thentication=E2=80=9D means in practice. Is it a full credential prompt reg=
ardless of whether one session already exists? A selection between existing=
 sessions, if present?
P4
=
This is uncle=
ar. As it currently reads it seems to prohibit things like getting a new au=
thz code silently via iframe (and prompt=3Dnone or equivalent UX suppressin=
g mechanism, please ignore the ITP complications for the sake of argument).=
 
=C2=A0
=C2=A79.3.1
=
P1
I don=E2=80=99t follow this sentence. The client ident=
ity cannot be proved for public clients (see also next P), and the native a=
pps are public clients unless otherwise specified (eg credentialed).=

P2
I find this misleading. Client side measur=
es such as claimed schemes, domains etc might work to prevent an app impers=
onating another app on the same device/OS, but they aren=E2=80=99t guarante=
ed to be honored on other operating systems. The AS has no way of knowing w=
hether those measures have been enforced on the client, hence it should not=
 accept them as proof.=C2=A0 
=C2=A0=

=
=C2=A79.4.1
This is another place where a reference to th=
e JWT AT profile would provide a concrete example of the conditions set for=
th here (eg RS guidance for audience validation).
Also, a=
s mentioned earlier, it might be useful to remind the reader that the AS mi=
ght include in the token authorization information that go beyond the deleg=
ated authz scenario OAuth2.x concerns itself with, and that those aspects a=
re beyond the scope of this specification.=C2=A0 That would truly go a long=
 way preventing people from abusing and overextending the spec on scenarios=
 it is not meant to address.
And even for the canonical s=
cenarios, it might be useful to remind the reader that the RS might have ex=
tra logic not described in this spec that determines whether the call will =
be authorized or otherwise- to dispel the notion that the AS is always the =
sole source of truth for authorization. 
=C2=A0=

=C2=A79.4.2
P2
Clarifying that=
 MTLS is one instance of the sender constraint methods just mentioned would=
 prevent some readers considering that an independent, additional constrain=
t.
=C2=A0
 =C2=A79.5
=
In =C2=A76.1 we give more details about protection, should we have a backwa=
rd reference to that section here?
P2
I=
s it worth to specify that it doesn=E2=80=99t matter how the AS tracks the =
binding? (eg server side or embedded in the RT bits themselves).<=
/u>
=C2=A0
=C2=A79.6
<=
span style=3D"font-size:11pt;font-family:Calibri,sans-serif">P1
This language makes the assumption that for client cred grants, the =
sub will take on the client_id value. That it certainly possible, but not a=
 given. As such, the language here should be explicit abouty the fact that =
it=E2=80=99s what we are expecting to happen in this particular scenario.
P2
Referring to the client as the actor =
here is confusing as soon as you move beyond client_id. When you talk about=
 rhe sub or any other value, it=E2=80=99s not as much the client as it is t=
he developer who owns the client. The difference is subtle but might be a s=
ource of confusion.
 
=C2=A79.7<=
u>
P3
I thought that we were going to make PKCE o=
r nonce the only two mandatory alternatives? Nothing against supporting sta=
te as an accepted way to achieve this, just surprised as I recall people be=
ing quite adamant about pushing PKCE.
P4
Looks like the iss response parameter might make the distinct redirect UR=
Is unnecessary?
=C2=A0
=C2=A79.7.1
The guidance in this section isn=E2=80=99t likely to be widel=
y followed, but I understand the rationale behind it.<=
/pre>
=
=C2=A0
=C2=A79.8
P2<=
/pre>
Tha=
t=E2=80=99s probably obvious, but I think we should specify that those mult=
iple attempts should come with the expected code verifier as well for the r=
evocation logic to be triggered- if it=E2=80=99s just the code without veri=
fier, it doesn=E2=80=99t look like the leak went far enough to warrant that=
 intervention.
P4
If this holds, then t=
he remark about the use of state for CSRF in =C2=A79.7 P3 seems unnecessary=
.
P9
The use of MUST here seems incompa=
tible with the concession of using nonce instead of PKCE. Either we allow i=
t or we don=E2=80=99t=E2=80=A6
 
=C2=
=A79.11
P1
Now that we no longer trade =
in RO passwords, should we mention them here? Sure, if the AS uses password=
s they do need protection, but so do lots of other things the AS might use =
as part of auth that we don=E2=80=99t mention here for Occam=E2=80=99s razo=
r. 
P3
What other means are we referrin=
g to? 
=C2=A0
=C2=A79.12=

=E2=80=9Cservice providers=E2=80=9D occurs for the first time in the d=
ocument here. Tying the guidance to entities already mentioned in the doc (=
clients, AS) might make things clearer/more actionable.
<=
u>=C2=A0
=C2=A79.13
I understand that some=
 of the comments in this area should be done on the BCP rather than here, b=
ut here we are. That said=E2=80=A6
Blanket comment: this =
section seems to assume native app =3D=3D mobile app, and that=E2=80=99s no=
t strictly the case. Desktop apps have different characteristics and deskto=
p OSes different capabilities. Would be clearer to make a distinction when =
relying on mobile OS capabilitesas we=C2=A0 appear to do here.
P2
Embedded user-agent !=3D fake external user agen=
t, but P2 uses that interchangeably. A desktop app might use an embedded br=
owser for UX reasons and making no attempt whatsoever to disguise that as a=
n external agent. And I would be pretty surprised to see a malware remover =
get rid of google drive for Mac, or Adobe products, or Office- all native a=
pps using embedded user-agents for authentication.
P3<=
/u>
It=E2=80=99s unclear how the AS would do that, given that us=
er agent strings can be faked. Google has its ML based secret sauce, but th=
at might not be accessible by everyone.
P4<=
/span>
This is mobile specific, doesn=E2=80=99t apply to desktop apps as readi=
ly. Also unclear how that would change for the end user, given that pixel p=
erfect replicas can easily include fake address bars. More details on how a=
 user would detect an actual browser (presence of an existing session, acce=
ss to bookmarks etc) might add enough color to help the reader truly unders=
tand the extent of the remedy power (or its true limits). 
=C2=A0
=C2=A79.14
There=E2=80=99s no =
action for the reader here. If that reflects the actual situation (none of =
the roles described in this spec can do anything to mitigate or contain the=
 damage, and solutions to prevent the situation lie outside its purview eg =
use MDM software on your corporate devices) we should explicitly say so.=

=C2=A0
=C2=A79.15
A bit=
 odd that we used CSRF throughout the document assuming the reader was fami=
liar with it, but here we attempt a definition. 
=

Still co=
nfused on how we admit state as a valid mechanism, as opposed to limiting t=
o nonce and PKCE. Also note the potential discrepancy called out earlier in=
 which at code redemption time we appear to require PKCE, in contrast to ad=
mitting nonce/state here.
=C2=A0
=C2=A7=
9.18.2
Wondering if here we should go as far as recommend=
ing the AS keeps dynamic client registration OFF when it=E2=80=99s not need=
ed. That might provide good secure by default guidance for AS SDKs and prod=
uct developers.
=C2=A0
=C2=A79.19
I assume we=E2=80=99d add the =E2=80=9Ciss=E2=80=9D response p=
arameter as alternative to the requirements here?
=
=C2=A0
=C2=A79.20
P1, P2, P3
The security properties described here do not apply as is to desktop apps =
using embedded browsers.
As mentioned earlier, on the des=
ktop the separation between apps isn=E2=80=99t as stark as on mobile- the k=
eystrokes message pump is potentially accessible at the user session level,=
 encompassing multiple applications. Although process separation mechanisms=
 are in place, the circumstances of the execution and the OS specific featu=
res in this respect determine the degree to which entering credentials in o=
ne process makes the data inaccessible by another. We should not claim adva=
ntages we cannot guarantee, and we should be explicit about what measures s=
pecific to dekstops should be considered to mitigate risks eg not executing=
 apps as admins, enable and use UAC at the right level on Windows or equiva=
lent on other OSes, use app sandboxing when the OS supports it, etc. Not su=
ggesting we call out specific technologies like UAC, but at least point at =
the category of security measures.
P4
A=
s mentioned above, the presence of the address bar can be easily faked by p=
ixel perfect replicas- relying on those is security theater.<=
/span>
P5
This is a valid concern, but if we want to frame i=
t in the context of the security considerations section we need to add more=
 color (eg minimizing the situations in which one needs to enter creds is g=
ood security practice).
=C2=A0
=

Another =
thing we might add as lowlight for embedded browsers: password managers mig=
ht not work, making the user=E2=80=99s life difficult and possibly promotin=
g insecure situations (eg placing a random pwd in the clipboard, where othe=
r apps might later steal it from).
=C2=A79.21
Do we need this here, given that we cover this in depth earlier?<=
/u>
=C2=A0
=C2=A710
=

I find t=
his subdivision confusing. We have native clients considerations scattered =
throughout the entire specification, but now we have a dedicated section th=
at somewhat repeats some of the points already made while interleaving new =
ones. Perhaps having a more specific section title, one that better charact=
erizes the content and intent of this section, would avoid giving the impre=
ssion that if the reader is interested in native clients, this is the only =
section they need to read.
P2
<=
pre>See discu=
ssion so far on native vs desktop.
Also: I have been in f=
erocious discussions where people thought the external user agent HAD to be=
 the browser, which we know isn=E2=80=99t the case (hero apps like the FB S=
DK or OS features like sign in w Apple work just as well). Some language he=
re giving a nod to those non-browser external user agents might help clarif=
y.
P4
See previous discussion on mobile=
!=3Ddesktop.
P5
I=E2=80=99d always qual=
ify the =E2=80=9Cbrowser=E2=80=9D with system, external, device etc given t=
hat some reader calls the embedded user-agent =E2=80=9Cembedded browser=E2=
=80=9D, hence just saying =E2=80=9Cbrowser=E2=80=9D without modifiers is am=
biguous.
User authentication state.. on the device. I thi=
nk specifying it will clarify what this really means.<=
/pre>
=
=C2=A0
=C2=A710.1
Unless you scope this st=
atement to MOBILE apps, I think the MUST here should be a SHOULD. 
The security posture of the desktop is different enough, and the =
quality of the user experience when using a system browser bad and disomoge=
neous enough, that a MUST isn=E2=80=99t justified here.
<=
u>=C2=A0
=C2=A710.2
Beware of the native-m=
obile false equivalence here.
P3
One or=
 two examples of non-browser external user agents might help.=

P4
Text pasted here is technically not a best practi=
ce but core.
I see there are examples here, so no need to=
 add them in P3.
It=E2=80=99s unclear why the external br=
owser is RECOMMENDED here- if it=E2=80=99s because we can=E2=80=99t go in d=
etails of the behavior of non browser apps, it seems like we should say tha=
t much rather than making a recommendation. In other words, RECOMMENDED exp=
resses a strong preference for it, but if I am on iOS and I want to sign in=
 with Facebook I am actually better off using their SDK both for security a=
nd user experience reasons than to use the system browser.
=C2=A0
=C2=A710.3
Requesting a MUST f=
or all 3 methods seems restrictive=E2=80=A6 why not requesting at least one=
?
=C2=A0
=C2=A710.3.1
P3
This seems unnecessarily restrictive. 3.8 in 7595 is =
mostly SHOULDs, and it refers to organizations rather than individuals. Not=
 every developer owns a domain, not every app goes on an app store and is m=
eant for general public consumption. An organization sideloading apps on ma=
naged devices should not be forced to follow those constraints if they cont=
rol the environment and aren=E2=80=99t worried about other apps competing f=
or the same schema, but placing a MUST here might compel SDK developers to =
embed validation checks that would make developers on those circumstances d=
eal with complexity without any security upside. In fact, apps should not e=
ven be required to have internet access in the general case but this requir=
ement does impose that. 
I think this is an important bes=
t practice that should be encouraged, RECOMMENDED or even SHOULDed , but it=
 shouldn=E2=80=99t be a MUST in the core specification.
<=
u>=C2=A0
=C2=A710.3.2
P4
Like everything happening on the client, the AS cannot really take that as=
 guarantee. What might be true for an app running on iOS might not apply if=
 the requests are all manufactured via cURL on a Linux box. The scope of th=
ose measures is really limited to one particular device or devices sharing =
an OS, outside of that cohort there are no guarantees.=

=C2=A0
=C2=A710.3.3
This section should c=
ome with glaring warnings, anything actively listening on the client extend=
s the attack surface- an app listening on the loopback might now get affect=
ed by exploits in the local HTTP driver/local network stack and taken over,=
 executing with the same privileges as the user (remember https://www.rapid7.com/db/vulnerabilities/WINDOWS-HOTFIX-MS15-034/=
). The fact that the loopback is only accessible locally only reduces the r=
isk but doesn=E2=80=99t eliminate it, a local process with lower privileges=
 might use that exploit for elevation of privileges for example. We should =
at least recommend that the app hosting the loopback adapter runs with low =
privileges, reiterate the =E2=80=9Clisten only when you must=E2=80=9D and g=
enerally warn about the extra attack surface.
As AS I mig=
ht not want to support this method at all, both for security reasons and fo=
r the extra logic the wildcard port entails at registration and request ser=
ving times, but right now the spec forces me to- more reasons for relaxing =
the MUST for all 3 methods as mentioned earlier..
=
=C2=A0
=C2=A712
I am not exactly sure where to=
 place the following- this section (or a subsection) might be the best fit.=

As mentioned during the interim meeting, the omission of=
 the implicit flow in OAuth2.1 has already caused a lot of people to interp=
ret this as an indirect deprecation of the use of implicit flow by OpenID C=
onnect for obtaining ID_tokens, either via traditional=C2=A0 response_modes=
 or via form_post.
We already debated and concluded that =
the reasons that led to the omission of the implicit grant in 2.1 do not ap=
ply to ID_tokens, hence there=E2=80=99s no reason for people to stop using =
OpenID Connect that way. 
Formally we are in the clear, a=
s OIDC is vased on 2.0 the omission of implicit here does not prevent it as=
 extension grant in OIDC anyway- but the formal stance doesn=E2=80=99t help=
 in preventing the confusion and assuaging the concerns of the developers w=
ho aren=E2=80=99t as well versed as the people on this list in all things s=
pecifications.
Because of this, I recommend we add some l=
anguage here that prevents that confusion. Something like 
=C2=A0
*=C2=A0=
 The Implicit grant ("response_type=3Dtoken") is omitted from thi=
s
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 specification as per Section 2.1.2 of[I-D.ietf-oauth-security-topics]
=

Please note: the omission of the implicit =
grant from this specification does not automatically imply that other exten=
sion grants obtaining credentials directly from the authorization endpoint =
should also be discarded. For example, the implicit flow defined in Section=
 3.2 of [OIDC] remains valid for all the resp=
onse_type values not including =E2=80=9Ctoken=E2=80=9D. 
=
=C2=A0
Although it might be a bit unusual to refer to det=
ails of specs from other entities, this spec already mentions OpenID 9 time=
s even excluding =C2=A714.2- and as soon as the browser apps section will b=
e included, that number is certain to rise. And the confusion on this point=
 is truly widespread- adding language along the lines of the above directly=
 in the core would go a long way to save a lot of grief.
=
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=

=C2=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0=

=C2=A0
=C2=A0
=C2=A0
=C2=A0
=
=C2=A0
=C2=A0
=C2=A0
=C2=
=A0
=C2=A0
=C2=A0
=C2=A0
=C2=A0
=
=C2=A0
=C2=A0
=C2=A0
=
=C2=A0
=C2=A0
=C2=A0
=C2=A0=

=C2=A0
=C2=A0
--00000000000009aa9805ba50f992-- From nobody Tue Feb 2 08:24:07 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 869D23A12AA; Tue, 2 Feb 2021 08:24:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161228304243.14351.11296656752366998904@ietfa.amsl.com> Date: Tue, 02 Feb 2021 08:24:02 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-par-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 16:24:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Pushed Authorization Requests Authors : Torsten Lodderstedt Brian Campbell Nat Sakimura Dave Tonge Filip Skokan Filename : draft-ietf-oauth-par-06.txt Pages : 22 Date : 2021-02-02 Abstract: This document defines the pushed authorization request endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-par-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 2 08:38:42 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475773A1E3A for ; Tue, 2 Feb 2021 08:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auIYM__OEgiD for ; Tue, 2 Feb 2021 08:38:37 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B823A1E32 for ; Tue, 2 Feb 2021 08:38:37 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id u25so28823115lfc.2 for ; Tue, 02 Feb 2021 08:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Kx1DVI2ipWWR1E1bOoCNTJgrgbopMXJvdIFKPuNt3wE=; b=VyOWnMIYFiS5lQZPI9c4nlrrLnVPUj3jbo94NHmIDFRjrj5bvcX5pBIA0a1NcAKS86 s6vGQVX+tIfOWGN286Q3eMle6kp6MW4O3kaxNwMNI6qlLizfNIHD5XLjsDZG27R5oBdn t8JCufZPyjWeJtnk+7h42ZDI0j0emdazxRbgGSN8Ibei18kKmIbWtYYh+o1/V35CkR4q 8prYsHkm6sXwnymZoydDgtivRaO3XWYniTrWZzNeiCvsk4eIIq6LZij+taFZGevgPiKZ h3r4YfrX1UAuak2Lnau+VOzdD0487kW3NV1TaTw7p/TfTU7zaq3aXgBZzF99W2etLp6e weNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Kx1DVI2ipWWR1E1bOoCNTJgrgbopMXJvdIFKPuNt3wE=; b=sRlDi0uzQ9gT66jLlcAjXA2Z1LIn+1vVcojaTJ0xsyuYpn/1bgPXB+0SjBjBYXtnF3 ZnAtfiW1K5HywbuzhjI85tCLH+X0OTv1k60aXgckCr+Et6NxqCKZBFGBk4WJtm/xySmo COh3xxGdMn03sSpp4YPsvN0Dty/6pn91q1TxevdcR9KnHTIdP1yludb5a/TY91aTWZoi wFMpPFuTHDRs/32nNcrULWCN74mFmvqyXmRRj80OmRn6r/SmfZf60RGgNj+hrN7XnxUY krhBNEMC7pG5kubL7Vc/FEgLkkD9dDurfVhY12/Igb3x/1KsI0LOCiXXybz8VfKr38I8 jumg== X-Gm-Message-State: AOAM531Z2U5LZ8uX5wMdWq8MOdiiNIEziXSnZQ7T0d8VRLUs7IabjmWf PPSpUnnBiFuFqfhsQ9Ara4gUsWr8aVWbQNrWdv5f109i+msGsmS1NfkNlc1gO93ZI66jGZa08UN p+a021WKfa5KZzye3VTQ= X-Google-Smtp-Source: ABdhPJzymE4zRDfZz/Z7h5IFh+Eb4lDYWjQQRFGPhgFNcJI51e37MwYRcJ0WfCYatLzioTnTY4tzkcVxIPbBcYnArt0= X-Received: by 2002:a05:6512:22c3:: with SMTP id g3mr10797935lfu.376.1612283915040; Tue, 02 Feb 2021 08:38:35 -0800 (PST) MIME-Version: 1.0 References: <161228304270.14351.8018650885407574191@ietfa.amsl.com> In-Reply-To: <161228304270.14351.8018650885407574191@ietfa.amsl.com> From: Brian Campbell Date: Tue, 2 Feb 2021 09:38:08 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000089b4b05ba5d1aa5" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 16:38:40 -0000 --000000000000089b4b05ba5d1aa5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This new revision only adds a brief note clarifying that the presence of "pushed_authorization_request_endpoint" in AS metadata is sufficient for a client to know that it can use the PAR flow. ---------- Forwarded message --------- From: Date: Tue, Feb 2, 2021 at 9:24 AM Subject: New Version Notification for draft-ietf-oauth-par-06.txt A new version of I-D, draft-ietf-oauth-par-06.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-par Revision: 06 Title: OAuth 2.0 Pushed Authorization Requests Document date: 2021-02-02 Group: oauth Pages: 22 URL: https://www.ietf.org/archive/id/draft-ietf-oauth-par-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ Html: https://www.ietf.org/archive/id/draft-ietf-oauth-par-06.htm= l Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-par-06 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-par-06 Abstract: This document defines the pushed authorization request endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000089b4b05ba5d1aa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This new revision only adds a brief note clarifying t= hat the presence of "pushed_authorization_request_endpoint" in AS= metadata is sufficient for a client to know that it can use the PAR flow.<= /div>


---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 2, 2021 at 9:24= AM
Subject: New Version Notification for draft-ietf-oauth-par-06.txt


A new version of I-D, draft-ietf-oauth-par-06.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-par
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A006
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Pushed Authorization Req= uests
Document date:=C2=A0 2021-02-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-ietf-oauth-par-06.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-oauth-par/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-ietf-oauth-par-06.html
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-oauth-par-06
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-par-06

Abstract:
=C2=A0 =C2=A0This document defines the pushed authorization request endpoin= t,
=C2=A0 =C2=A0which allows clients to push the payload of an OAuth 2.0
=C2=A0 =C2=A0authorization request to the authorization server via a direct=
=C2=A0 =C2=A0request and provides them with a request URI that is used as =C2=A0 =C2=A0reference to the data in a subsequent call to the authorizatio= n
=C2=A0 =C2=A0endpoint.




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

The IETF Secretariat



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000089b4b05ba5d1aa5-- From nobody Thu Feb 4 03:19:55 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9933A1290; Thu, 4 Feb 2021 03:19:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef , rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <161243759330.21901.3347578006693687311@ietfa.amsl.com> Date: Thu, 04 Feb 2021 03:19:53 -0800 Archived-At: Subject: [OAUTH-WG] Robert Wilton's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 11:19:53 -0000 Robert Wilton has entered the following ballot position for draft-ietf-oauth-jwt-introspection-response-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Thank you for this document. I have a couple of process related questions regarding the legal aspects considered in chapter 9 on privacy that I would like to discuss with the other ADs on the telechat (hence raising it as a Discuss). My two questions are: (1) Is it appropriate for an RFC to specifying requirements relating to legal issues and laws? Note, I think that the guidance that is provides is really helpful and should be included in the document, but I'm a bit concerned as to whether a standards track RFC should be stating formal requirements/constraints related to enforcing legal requirements rather that providing non-normative guidance. (2) Related to the first question, if the IESG believes believes that providing such requirements is okay, a further question is whether using RFC 2119 language is appropriate, or whether this should use regular English? An example from section 9: The AS MUST ensure a legal basis exists for the data transfer before any data is released to a particular RS. The way the legal basis is established might vary among jurisdictions and MUST consider the legal entities involved. Regards, Rob From nobody Thu Feb 4 06:41:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D5B3A1541; Thu, 4 Feb 2021 06:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSbUMx5o4YAU; Thu, 4 Feb 2021 06:41:05 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30CC13A1540; Thu, 4 Feb 2021 06:41:05 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 114Ef2xJ008005; Thu, 4 Feb 2021 09:41:02 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 114Ef2xJ008005 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1612449663; bh=LVEAYX+ABjVSwx2N+to/Xb+PYfuGitbYRPqT73yAykE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UALWHPPVez2h1kJVn2Gdzuh2LavVUOaI/s7YzAe/UILnQNKzDfgQZpv/cpZ6iACZy ce9x5oLIy0EzQKNEit+EyWaGpeFt5EpoXu4UfaUXf722ITo/jYP1HlPR+gqR9TZ0vB jC9W1xXNszQTETnjWfq0YB4RgbmYtN860nL3Gokk= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 114Ef16V033822; Thu, 4 Feb 2021 09:41:01 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Feb 2021 09:41:01 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Thu, 4 Feb 2021 09:41:01 -0500 From: Roman Danyliw To: Robert Wilton , The IESG CC: "oauth-chairs@ietf.org" , "draft-ietf-oauth-jwt-introspection-response@ietf.org" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Robert Wilton's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS) Thread-Index: AQHW+uewWTGq1ZNCUkuToVtarGgL4KpICIAw Date: Thu, 4 Feb 2021 14:40:59 +0000 Message-ID: <212be5c70c6542a5ac7efeea3a5b392e@cert.org> References: <161243759330.21901.3347578006693687311@ietfa.amsl.com> In-Reply-To: <161243759330.21901.3347578006693687311@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Robert Wilton's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 14:41:07 -0000 Hi! Rob! > -----Original Message----- > From: OAuth On Behalf Of Robert Wilton via > Datatracker > Sent: Thursday, February 4, 2021 6:20 AM > To: The IESG > Cc: oauth-chairs@ietf.org; draft-ietf-oauth-jwt-introspection- > response@ietf.org; oauth@ietf.org > Subject: [OAUTH-WG] Robert Wilton's Discuss on draft-ietf-oauth-jwt- > introspection-response-10: (with DISCUSS) >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respo= nse/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Hi, >=20 > Thank you for this document. >=20 > I have a couple of process related questions regarding the legal aspects > considered in chapter 9 on privacy that I would like to discuss with the = other > ADs on the telechat (hence raising it as a Discuss). >=20 > My two questions are: >=20 > (1) Is it appropriate for an RFC to specifying requirements relating to l= egal > issues and laws? Note, I think that the guidance that is provides is rea= lly > helpful and should be included in the document, but I'm a bit concerned a= s to > whether a standards track RFC should be stating formal > requirements/constraints related to enforcing legal requirements rather t= hat > providing non-normative guidance. > > (2) Related to the first question, if the IESG believes believes that pro= viding > such requirements is okay, a further question is whether using RFC 2119 > language is appropriate, or whether this should use regular English? >=20 > An example from section 9: >=20 > The AS MUST ensure a > legal basis exists for the data transfer before any data is released > to a particular RS. The way the legal basis is established might > vary among jurisdictions and MUST consider the legal entities > involved. I can see your point. I believe this language is here to make a very stron= g statement on the needed for operational policies that conform to the vari= ety of privacy laws which often governs some of this data. I'll let the authors/co-chairs comment. To start the discussion, let me pr= opose rough text that dilutes the legal mandate a bit but tries to keep the= spirit of the intent. =20 NEW The AS MUST conform to jurisdictional constraints for the data transfer bef= ore any data is released to a particular RS. These constraints will vary b= y jurisdictions; and their details and determining which apply to this rele= ase to RSs is outside the scope of this document. Regards, Roman >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Feb 4 12:06:57 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22B73A17A4 for ; Thu, 4 Feb 2021 12:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, MISSING_SUBJECT=1.799, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z44zLQ32nwEO for ; Thu, 4 Feb 2021 12:06:55 -0800 (PST) Received: from pv50p00im-ztdg10011201.me.com (pv50p00im-ztdg10011201.me.com [17.58.6.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B563A17A2 for ; Thu, 4 Feb 2021 12:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1612469213; bh=t3aGRB9qpWxhWanQ4Pm0+sYW6qJrm5hcmzBJ7JcqYWY=; h=Content-Type:From:Mime-Version:Date:Message-Id:To; b=undY5NPiB79w5iXRrOmRlhUYYHGNJri/0iDlMN0Aw9mnzXM/fmUgiEAeqWWvwuKVJ yAEFdWkCxmsb62A1gSrT+Roh0BQlQNn04DcpC/mcMYmCx4wZCd4JB+Ez2ZIdjRueyt 0SQFklJ0IxqMe0g8eyRcH5B8EXiOa+VFMqE2zu6w2RFuRcqpMPPUmyzIhZ4s002haR i30gILzwnx4jIGvlxSK4DWldjju2DrIKpbns/gj2spafwarkUfT+3ZaJnrUJBFioUY i5YGE63M/PhVeOMqlyHRR6waLtmgpTaiZ5ZVAipPtLFZN1f2B2axkQ3g3fzW2YuIcI ldbOGEb+h+iWQ== Received: from [192.168.100.8] (unknown [51.211.218.194]) by pv50p00im-ztdg10011201.me.com (Postfix) with ESMTPSA id D2BC12A0571; Thu, 4 Feb 2021 20:06:52 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-4D16AD00-5948-48F6-B1EB-42FBF5ABDD65 Content-Transfer-Encoding: 7bit From: =?utf-8?B?2KfZhNi02YrZgSDYp9mE2YbYrNin2LE=?= Mime-Version: 1.0 (1.0) Date: Thu, 4 Feb 2021 23:06:49 +0300 Message-Id: To: oauth@ietf.org X-Mailer: iPhone Mail (18D52) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-04_10:2021-02-04, 2021-02-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=346 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2102040123 Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 20:06:56 -0000 --Apple-Mail-4D16AD00-5948-48F6-B1EB-42FBF5ABDD65 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 2KfZhNiz2YTYp9mFINi52YTZitmD2YUgDQrZhdmD2YYg2YXYs9in2LnYr9iq2Yog2YHZiiDYp9ix 2KzYp9i5INit2LPYp9io2YogDQoNCuKAq9ij2Y/Ysdiz2YTYqiDZhdmGINin2YTZgCBpUGhvbmXi gKw= --Apple-Mail-4D16AD00-5948-48F6-B1EB-42FBF5ABDD65 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=D8=A7=D9=84= =D8=B3=D9=84=D8=A7=D9=85 =D8=B9=D9=84=D9=8A=D9=83=D9=85 
=D9=85=D9=83=D9=86 =D9=85=D8=B3=D8=A7=D8=B9=D8=AF=D8=AA= =D9=8A =D9=81=D9=8A =D8=A7=D8=B1=D8=AC=D8=A7=D8=B9 =D8=AD=D8=B3=D8=A7=D8=A8=D9= =8A 

=E2=80=AB=D8=A3=D9=8F=D8=B1=D8=B3=D9=84=D8= =AA =D9=85=D9=86 =D8=A7=D9=84=D9=80 iPhone=E2=80=AC
= --Apple-Mail-4D16AD00-5948-48F6-B1EB-42FBF5ABDD65-- From nobody Sat Feb 6 23:42:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA873AFA39; Sat, 6 Feb 2021 23:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsyY1qdtTJEm; Sat, 6 Feb 2021 23:42:10 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14643AFA37; Sat, 6 Feb 2021 23:42:09 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id w1so19681566ejf.11; Sat, 06 Feb 2021 23:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VDYVyxi/nYE39ZFyNGD+PNhq0+R18VMWYAmXdHuBdIY=; b=NCxIzHzxp/UL6dJ9ASQK/8i2EvksdvhQxNVCW9Ltp8l6f3ooLklLY57vrn+RDu6Haj gz7Osartmjo3s2We1KwM/eL5rIcRlBuZCPYGEUDxnSCO38pVWtEIgngUTk+KnwsN7me4 msE2kVnFCf2o0+tt1v5xp+Hd827EFfIdLiwT0m1YSyke9Jg7aUq3hfiT2ttfM5JiZXv/ jCr1sMSv+mFNHZm/iC2mEjH3m4IUL+qs2LOQLMQFZ5SjU6hVs2sNeaa4XzcQ5lQuMEVh pZiwkKx3vTe5WB+nGdQ01XOPGgCX050it61Tfzk6DvFFFASUTYeilDo/REVLNw+hr1Rp VuFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VDYVyxi/nYE39ZFyNGD+PNhq0+R18VMWYAmXdHuBdIY=; b=VuHDgFpow8BGuVOa+JnhdmSx0c51STWK3SiKAdfDSDrka3jDcac1wLR+2dq3Uf3Mhw zfKEPND0dZypPhAEjnUII9dsLNiAkSboB+E+k0NBK7hwDQm0ipTbLg1fICVskrsxt/I/ 6UHSU9E8Bvw5AWfIUjcacscai1clmT+EcJAXrFRcZkqEWGafNNQL55mD/HOhkysdCDHz 9g8ARdYIoNAtkhlbOZaI6WzrwdNiDbsV1re8fJRQJVOQj4fehbfbfpj5b8Bn5j8M5avH 1ZoWZ8wv824eYEMkCFMn+w+7RDEiOil18IGBFAR6Nhd+rp8BULwdHgq5tTQdSllPzPKH sB2g== X-Gm-Message-State: AOAM532xgYTNhStK6rFcJnEaTIwpee1FusVhzTMhQC1zRg/asEDmxJlW 6kKALJxAMAqK3ei1A0s75GvgvsJlfZH6uDmxyXFoBUp1mck= X-Google-Smtp-Source: ABdhPJwYByDOd0z25XUE8ggocZPzfdFoW77P66M2FRrQ8tDldf18waPicptNZSfvkUZqDx5epvYYPkj9FLF2lKLNULc= X-Received: by 2002:a17:906:a14e:: with SMTP id bu14mr11656352ejb.303.1612683727950; Sat, 06 Feb 2021 23:42:07 -0800 (PST) MIME-Version: 1.0 From: Andrii Deinega Date: Sat, 6 Feb 2021 23:41:57 -0800 Message-ID: To: oauth@ietf.org, draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="000000000000bd600705baba308b" Archived-At: Subject: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 07:42:11 -0000 --000000000000bd600705baba308b Content-Type: text/plain; charset="UTF-8" Hi WG, draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/token-introspection+jwt"? I expect there will be no differences, right? If so, I suggest to 1. replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response) 2. change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response) If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view. Regards, Andrii --000000000000bd600705baba308b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

draft-ietf-oauth-jwt-introspection-response-= 10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a me= thod for a protected resource to query an OAuth 2.0 authorization server to= determine the state of an access token and obtain data associated with the= access token." which is true. Although, according to RFC7662, the int= rospection endpoint allows to introspect a refresh token as well. Hence, th= e question I have is how will a token introspection response look like when= the caller provides a refresh token and sets the "Accept" HTTP h= eader to "application/token-introspection+jwt"?

I expect t= here will be no differences, right?

If so, I suggest to
  1. = replace "a resource server" by "the caller" in section = 4 (Requesting a JWT Response)
  2. change "If the access token = is invalid, expired, revoked" by "If a given token is invalid, ex= pired, revoked" in section 5 (JWT Response)
If not, my sugges= tion would be to clarify what the AS should do when it asked to introspect = the refresh token in general and additionally, what should=C2=A0happen in t= he same case based on the type of the caller from the AS's point of vie= w.

Regards,
Andrii

--000000000000bd600705baba308b-- From nobody Sun Feb 7 01:28:40 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C421C3AFB2E; Sun, 7 Feb 2021 01:28:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even via Datatracker To: Cc: draft-ietf-oauth-access-token-jwt.all@ietf.org, last-call@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161269010849.30071.8142300590273121238@ietfa.amsl.com> Reply-To: Roni Even Date: Sun, 07 Feb 2021 01:28:28 -0800 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-access-token-jwt-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 09:28:29 -0000 Reviewer: Roni Even Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-access-token-jwt-?? Reviewer: Roni Even Review Date: 2021-02-07 IETF LC End Date: 2021-02-09 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as a standard track RFC with nit Major issues: Minor issues: Nits/editorial comments: In section 3 the get example has client_id as s6BhdRkqt3 and the claims has s6BhdRkqt3_ From nobody Sun Feb 7 01:56:23 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97853AFB6B for ; Sun, 7 Feb 2021 01:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vjNFrRiBnTa for ; Sun, 7 Feb 2021 01:56:19 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F103AFB6A for ; Sun, 7 Feb 2021 01:56:19 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id s26so8892280edt.10 for ; Sun, 07 Feb 2021 01:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zWR+PqhyEXJpDA5JGqVZoushakk8X/Cjc2//a0wYpy8=; b=ElqTO+KR7tYm/gkmTfWH5paPuoGY1deVGBTc0dkwtM0KKy7HksLwEpC375HEue/zUv 3CbF5k5vssnREonqGXLQhBROYNfP1+7VHa/q1OQFjIfPLDJm++uLSqx+aVo/88uF1wiy xPy6/eojxHg9NtyeSL4WSnGtvICNqGpvGgPzO4ewsM8jxlBfCR6aI4VMqJDkAO0+eEi8 7IXQU6jaZt40NKMCCjUjhOpneFIt7tLdLuhf2m3YD19a+Gjgdw4eTV2DFmQuDcms93Je lPbzwQh28E3id0j0orJIRhdNAn6CIy5w1lWhv+vGY03mGPsuFI6ZNymXDnWtrsR49e7c PEGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zWR+PqhyEXJpDA5JGqVZoushakk8X/Cjc2//a0wYpy8=; b=c0J2TiKYTGDLnoqsg+Pqc5qTTc9DwW7s27XhLnajQ15p8FzWkOS4mSD7TP4T91XfKO 0BNev27T+fyGESCVcA5mZwDU/mhkV40FmwrMSzpwCgG2xjraMna2HiTZXbcPwuRSAHtP vfK0QNwziThF80t0KDynzDRmClQmN+sNPeQDKgl8KrYQ/r3o/HgTh+VNG5BYI8zExj1J omKFcuco6g/AoT5QOIfgAFfAxhuO/D+gB7R9m20pYhaEpgr72AmMc35rqNWxBHCXedYq VMphCtrnIWZCxyI1NWLCLiQkpNnu1VUCHsvo+rwjgyc9Db4aowEbMClTSMf//SJKM5cI FoVA== X-Gm-Message-State: AOAM533ke5xGchkKQ5HCYNfy6IncBSOjR3qfel9313Uuw7WAa3qGQO+7 lDQi6rTQRLDnCxq+vV4VP+JSQzo77H4A0nZ6GcYy2xV+o8A= X-Google-Smtp-Source: ABdhPJwIUjsJxGKKkVPbatYgBJyCTRlmvKVfX6d5InRs1fXI1doXmOUi/esBij06a2UrSdJcKupTwKadbyqlaFA/toI= X-Received: by 2002:a05:6402:1589:: with SMTP id c9mr12282660edv.282.1612691777149; Sun, 07 Feb 2021 01:56:17 -0800 (PST) MIME-Version: 1.0 From: Andrii Deinega Date: Sun, 7 Feb 2021 01:56:06 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000825c6d05babc103e" Archived-At: Subject: [OAUTH-WG] oauth-jwt-introspection-response and RFC 7797 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 09:56:21 -0000 --000000000000825c6d05babc103e Content-Type: text/plain; charset="UTF-8" Hi WG. draft-ietf-oauth-jwt-introspection-response-10 proposes to return signed JWTs as a response from the introspection endpoint... which is making me wonder if there are any particular reasons to not avail JSON Web Signature (JWS) Unencoded Payload Option (RFC 7797) and the X-JWS-SIGNATURE HTTP header in order to achieve the same goals? Pros would be 1. a token introspection response remains to be exactly the same as it was before with an exception for a JWT in the X-JWS-SIGNATURE HTTP header (where a detached payload is the actual token introspection response) 2. the AS can safely enable it for all responses from the introspection endpoint so clients who don't require or just aren't aware of this header will continue to work as before and accordingly, the clients who require some stronger assurance will require and check a JWT in X-JWS-SIGNATURE HTTP header 3. the same approach could also work for other endpoints such as the revocation and OIDC UserInfo endpoints What do you think? Regards, Andrii --000000000000825c6d05babc103e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG.

draft-ietf-oauth-jwt-intro= spection-response-10 proposes to return signed JWTs as a response from the = introspection endpoint... which is making me=C2=A0wonder if there are any p= articular reasons to not avail JSON Web Signature (JWS) Unencoded Payload O= ption (RFC 7797) and the X-JWS-SIGNATURE HTTP header in order to achieve th= e same goals?

Pros would be
  1. a token introspection respons= e remains to be exactly the same as it was before with an exception for a J= WT in the X-JWS-SIGNATURE HTTP header (where a detached payload is the actu= al token introspection response)
  2. the AS can safely enable it for al= l responses from the introspection endpoint so clients who don't requir= e or just aren't aware of this header will continue to work as before a= nd accordingly, the clients who require some stronger assurance will requir= e=C2=A0and check a JWT in=C2=A0X-JWS-SIGNATURE HTTP header
  3. the same= approach could also work for other endpoints such as the revocation and OI= DC UserInfo endpoints
What=C2=A0do you think?
<= br>
Regards,
Andrii

--000000000000825c6d05babc103e-- From nobody Sun Feb 7 04:14:13 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8B53A0BA0 for ; Sun, 7 Feb 2021 04:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chV0q6J4UBhk for ; Sun, 7 Feb 2021 04:14:09 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACFA3A0B16 for ; Sun, 7 Feb 2021 04:14:08 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id m13so13661571wro.12 for ; Sun, 07 Feb 2021 04:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qlYWycpIDICyQ+t9FQK9PuVBND9gjdZsQDu+4ItxEuo=; b=q1hH/P7XID/ovLZAGfzLyEQA7DyC0w2Xf+ANE4Iqdzj3n2fjyApEtKmXKTJ9RZW6sD 1bhYkXLct2Cec/jcombFP/+48ob7skT8nH6Bod4X9yiUTvhpw0S2qR9keP/zYwqNh3Lc Wb0gezFQ0n05EfekErDPo1MJ1sIsRww81xaUjurImG3jqUP6m9Ja8j4TnDmd7F1nx2A+ KBxmH7iaGSftQ7GlJy0y+pSvgEX7kfTgidQ4NjvFGsvSoIy2YOFy0d+VmQW9pDnhrTA1 UnDJ18ryKVnqjVkt4eF6wgcR1Isr/9Monj0CcomkYlbzb3hryCTBE2OacJ346HA99+uJ xXRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qlYWycpIDICyQ+t9FQK9PuVBND9gjdZsQDu+4ItxEuo=; b=CI5pBEYqzC9mwM494NYVPHkFWFztWJu1Lt0o6OMU04iTjKb1eOXR3ljWx4i9bGf1rm +AAP72dsiP6038zYpJlZcE4Hy/fcUQrfTx0NjV6Up9DqNsPqmH5uycbHEdvLgJUpvxEw LEsn4yX0aj+u+2BPQOeWsMdBHwVV1rt6MiG9LJMTxakY0nAOs7Pbc3qLhCOIsYJmVawK nMjFy/br3ub1thTkyYeAvVgffJ6xG7iHJ8Ml1UsgT5PZiADcQH85gFGypVesOMz6FAHx fMCrE2kXIyC4PddJ8p0p9YKiRV/s3u18lqPO6bN81SMOwenMAR0KLA1yS0CFaw0BThwL tPLQ== X-Gm-Message-State: AOAM5321NIYsU244koyLKXNDAH7F1B0chUHZ7jaKbVJI3lp0oMEWyAjr CjfgG6+KglFM1zDiG2AcQp+G7w== X-Google-Smtp-Source: ABdhPJwoKwFBrZpLbuZrwRDafiystcxZJ7DNg9gJJj/FTvxWERnMRfDw8QwzE/t7RLwq8ZVRVJrhPQ== X-Received: by 2002:a05:6000:1565:: with SMTP id 5mr15046531wrz.109.1612700047131; Sun, 07 Feb 2021 04:14:07 -0800 (PST) Received: from [192.168.71.123] (p5b0d9c0a.dip0.t-ipconnect.de. [91.13.156.10]) by smtp.gmail.com with ESMTPSA id g14sm22797706wru.45.2021.02.07.04.14.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Feb 2021 04:14:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Torsten Lodderstedt In-Reply-To: Date: Sun, 7 Feb 2021 13:14:05 +0100 Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andrii Deinega X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 12:14:12 -0000 Hi Andrii, thanks for your post.=20 The draft is intended to provide AS and RS with a solution to exchange = signed (and optionally encrypted) token introspection responses in order = to provide stronger assurance among those parties. This is important in = use cases where the RS acts upon the introspection response data and = wants the AS to take liability re the data quality.=20 I=E2=80=99m not sure whether there are similar use cases if a client = introspects a refresh token. What is your use case? best regards, Torsten. =20 > Am 07.02.2021 um 08:41 schrieb Andrii Deinega = : >=20 > Hi WG, >=20 > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 = Token Introspection [RFC7662] specifies a method for a protected = resource to query an OAuth 2.0 authorization server to determine the = state of an access token and obtain data associated with the access = token." which is true. Although, according to RFC7662, the introspection = endpoint allows to introspect a refresh token as well. Hence, the = question I have is how will a token introspection response look like = when the caller provides a refresh token and sets the "Accept" HTTP = header to "application/token-introspection+jwt"? >=20 > I expect there will be no differences, right? >=20 > If so, I suggest to > =E2=80=A2 replace "a resource server" by "the caller" in section = 4 (Requesting a JWT Response) > =E2=80=A2 change "If the access token is invalid, expired, = revoked" by "If a given token is invalid, expired, revoked" in section 5 = (JWT Response) > If not, my suggestion would be to clarify what the AS should do when = it asked to introspect the refresh token in general and additionally, = what should happen in the same case based on the type of the caller from = the AS's point of view. >=20 > Regards, > Andrii >=20 From nobody Sun Feb 7 04:42:33 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA3B3A045E; Sun, 7 Feb 2021 04:42:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <161270175060.8296.1897997883947486904@ietfa.amsl.com> Date: Sun, 07 Feb 2021 04:42:30 -0800 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 12:42:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-04.txt Pages : 36 Date : 2021-02-07 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 7 04:49:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D43A0D01 for ; Sun, 7 Feb 2021 04:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR_aC5sB-5HZ for ; Sun, 7 Feb 2021 04:49:51 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D043A0D00 for ; Sun, 7 Feb 2021 04:49:50 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id a1so13802178wrq.6 for ; Sun, 07 Feb 2021 04:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rlyejlgnYBjhaP5bdxd6676RIo9E87jrLb1OSjo73M8=; b=1OoDoE8aNXIPkqxEAh5XYhSVDACJ8Ljq45IIaac3W50r3H/M1SJGNKPlcSnwFiaW5T ZaWbzOOWaPdx6E6uvEV3kKF4XLXmy9Py5YKHVuI6esy6ExWXyR/Yqj34N8ZeLNH+m+/9 u/xFJxvKwx9IaNKaCcgKDokL9kGcKyryK0H1po7rmgYdkVtxg1oZ5bC5smXTT/KL5w+E dSu/kjcQGcvim3i7aFHcrR06ZZhi8uiRrrId8ds+VkOJXNRR9a+/7DBzQgffzfkCitsx iG8sO5Q1w+hqmkkHDMKljzBXmDh8x9uvyc8ZltUbaUPLjjXLDO5CtyOoIH6vbYCDH4ef +ZkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rlyejlgnYBjhaP5bdxd6676RIo9E87jrLb1OSjo73M8=; b=LYO5UYZ7eMM9LN0q5Wi4jR58a6e95SMrO4XKy9REIWv8hwYBEPd29+X5J/C5jkbQ/M rrmmQ9b0z2+mw7MPszVMq5eoouB0JHsBQDmikmV8ML2e0u39jzET9Aj4cFaCsHvo3BkF 2AZJA7KH1CfWaFUwmaFKumPAl8y7XvGt2MJRmn6aJuqyfO0qGCWdCDlvNATzGFMcEbHo roypZwYYqyaEgNmNh+ziWrfZ+Y/djpAd3NV5cLTVND7uYvn99vq1KZwxwdSQP08ZO7BL //+LSktwdbwx0ikcT4uSyhtNstpKFe5BK00psUP1XbmfVHwzMHtJdL0CdVlT76/QQlUf CIww== X-Gm-Message-State: AOAM533BcdmqKbLTmOHs/eWT18SnMksqYhg4vtmLwPhOrMqnncBVV84I 6oyWkD+Ljnsa3MwG1lyoJzMXiIN33e1rB5YE X-Google-Smtp-Source: ABdhPJzOX3iIdfjKEd9L81Tcqeyi9eaocn1sa8d2Vtao9VtJ30jK9FqkkEzUx0xUKJ2mhBlOmLllgA== X-Received: by 2002:a5d:68c1:: with SMTP id p1mr14928274wrw.325.1612702188918; Sun, 07 Feb 2021 04:49:48 -0800 (PST) Received: from [192.168.71.123] (p5b0d9c0a.dip0.t-ipconnect.de. [91.13.156.10]) by smtp.gmail.com with ESMTPSA id k11sm7373016wrv.51.2021.02.07.04.49.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Feb 2021 04:49:48 -0800 (PST) From: Torsten Lodderstedt Content-Type: multipart/alternative; boundary="Apple-Mail=_8737106E-CD4E-4341-811C-43A373AABA49" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Sun, 7 Feb 2021 13:49:47 +0100 References: <161270175060.8296.1897997883947486904@ietfa.amsl.com> To: oauth In-Reply-To: <161270175060.8296.1897997883947486904@ietfa.amsl.com> Message-Id: <06504BA6-6065-4ADD-BE45-5E13DF00DC1A@lodderstedt.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 12:49:53 -0000 --Apple-Mail=_8737106E-CD4E-4341-811C-43A373AABA49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, here is the list of changes in revision -04: restructured draft for better readability simplified normative text about use of the resource parameter with = authorization_details=20 added implementation considerations for deployments and products added type union language from GNAP =20 added recommendation to use PAR to cope with large requests and for = request protection Your feedback is highly appreciated. best regards, Torsten.=20 > Am 07.02.2021 um 13:42 schrieb internet-drafts@ietf.org: >=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 WG of the = IETF. >=20 > Title : OAuth 2.0 Rich Authorization Requests > Authors : Torsten Lodderstedt > Justin Richer > Brian Campbell > Filename : draft-ietf-oauth-rar-04.txt > Pages : 36 > Date : 2021-02-07 >=20 > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-ietf= -oauth-rar/&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw3-4SmuM= Fgxbz-cDK2Ir_a7 >=20 > There is also an HTML version available at: > = https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf-= oauth-rar-04.html&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw1= J52xGTvk1ZAuBC_fUAIjJ >=20 > A diff from the previous version is available at: > = https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-i= etf-oauth-rar-04&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw0T= YqmFwryvAYznR2Ho5Oj6 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw06g1z6o36BkkaqkiWc= 1Lw9 --Apple-Mail=_8737106E-CD4E-4341-811C-43A373AABA49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

here is the list of changes in revision = -04:

  • restructured draft for better = readability
  • simplified normative text about use of = the resource parameter with authorization_details 
  • added implementation considerations for deployments and = products
  • added type union language from GNAP =  
  • added recommendation to use PAR to cope with = large requests and for request protection

Your feedback is highly = appreciated.

best regards,
Torsten. 

Am = 07.02.2021 um 13:42 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 WG of the IETF.

       Title         =   : OAuth 2.0 Rich Authorization Requests
  =      Authors         : Torsten = Lodderstedt
            =              Justin Richer
                =          Brian Campbell
Filename =        : draft-ietf-oauth-rar-04.txt
= Pages           : 36
Date =            : 2021-02-07

Abstract:
  This document specifies a new = parameter "authorization_details" that
  is used to = carry fine grained authorization data in the OAuth
  = authorization request.


The = IETF datatracker status page for this draft is:
https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc= /draft-ietf-oauth-rar/&source=3Dgmail-imap&ust=3D1613306557000000&= amp;usg=3DAOvVaw3-4SmuMFgxbz-cDK2Ir_a7

There is also an HTML version available at:
https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/= draft-ietf-oauth-rar-04.html&source=3Dgmail-imap&ust=3D16133065570= 00000&usg=3DAOvVaw1J52xGTvk1ZAuBC_fUAIjJ

A diff from the previous version is available at:
https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url= 2%3Ddraft-ietf-oauth-rar-04&source=3Dgmail-imap&ust=3D161330655700= 0000&usg=3DAOvVaw0TYqmFwryvAYznR2Ho5Oj6


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

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DA= OvVaw06g1z6o36BkkaqkiWc1Lw9

= --Apple-Mail=_8737106E-CD4E-4341-811C-43A373AABA49-- From nobody Sun Feb 7 10:48:26 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6EE3A11D6; Sun, 7 Feb 2021 10:48:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: draft-ietf-oauth-access-token-jwt.all@ietf.org, last-call@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161272369978.20616.15063633580755015902@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sun, 07 Feb 2021 10:48:19 -0800 Archived-At: Subject: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 18:48:20 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document has issues. 1. (Editorial) What is the relationship between this document and RFC 7523. They are using JWT for different purposes, but I think it would be useful to clarify this in the introduction. 2. (Issue) The specification does not specify any mandatory to implement for the recommended asymmetric algorithms. This will not help interop. Perhaps specify one or both of "RS256" and "ES256". 3. (Question) Is it currently possible to use the JWT access token in a mode other than a bearer token? For example is there a way to bind the JWT to a verifiable key or identifier. If there is, there should be some discussion of this in the security considerations. If not, do the authors know if there is any work planned in this area? 4. Genart review pointed out a nit that should be fixed. From nobody Sun Feb 7 12:30:26 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7DE3A12C9; Sun, 7 Feb 2021 12:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyIg2PAG8fK1; Sun, 7 Feb 2021 12:30:23 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD603A12C8; Sun, 7 Feb 2021 12:30:23 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id a9so21472629ejr.2; Sun, 07 Feb 2021 12:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmopxuEjNCoTJ0KIiY+osSdbtXDTqLPRyiSQRTXQc78=; b=Lsjw4X8KrtL50Ci7VZ3MCMdSWhRjNF3JZCgLYPl2rgh4lfl1pjCXWhPsmEvBomwnId FFTVhyQ7BqodHOfVAWN9qt3ugS0L5K1c8wy94a81WMSlgMrtEbIfPZHY5sDYI519euYv V7EGQg7Zs5BLSAbpXRF5W54klhF5pvas0lGJlDkX/EpRQThLJeZMbLRd3dptZKoMJDIY rhE1EHOsBT2oncE+zxF16Ugs3VDI92g4FODzYJEqH0e9g6tZfonLwclats9JhHIv/Flz mCT+WZlVXL6AwmhlPGvqYY6oL+odIHytIuco2Ya5MBUFBH6mECPg474uKgrUGwFqlisz 5TKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TmopxuEjNCoTJ0KIiY+osSdbtXDTqLPRyiSQRTXQc78=; b=HStec2chSomHcrLHvF8ko9tFV6TeAlyrkbFX6ktDwqgdvsTicHIIZNwxvz9RffVlXu ls3pVZlZxbpTpzmFw7I9BOi4UT71jEqjYJeoXhgrnlzk6s/+N6ubtW8asptod2Jz2f0K U+jRjoEodeVKh/1rPxQM2ny8y/Wx1bBDflUtBKEoN+CZds1FHdnGFfylOMWgGkngzOy+ LDpQat9rY6r7mRGEqz0n9T8GOmGz8PSO6h17C8asJlHEINz7Z/WfPqfQP8l8C6U7tSTv UI5rBrCTtHjY+VJ/B5c759kVmAPPI2DCXJLv32yjXAI36keI8hbBB8Yyk/FKUitgRe1N E1nA== X-Gm-Message-State: AOAM532cYI+1ROOslcRzTh7THoe0CGGgy7ICABRde15BGDtoRe35xWRr ShAy+zMK9iyAxRtwfn5HL99smN853ck2k2Ri5Hk= X-Google-Smtp-Source: ABdhPJzZ03Zm1zwJ09DNgo8Sm7EWIr7m2PwSpIbOQHlVzUJ0KIvA3xmScte4Jk0p8WLcIYzmugiIfBt/Ikk/gdfH8S0= X-Received: by 2002:a17:906:af41:: with SMTP id ly1mr13526993ejb.525.1612729821405; Sun, 07 Feb 2021 12:30:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Deinega Date: Sun, 7 Feb 2021 12:30:10 -0800 Message-ID: To: Torsten Lodderstedt Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="0000000000001fa69c05bac4ec58" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 20:30:25 -0000 --0000000000001fa69c05bac4ec58 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, thank you for your response. My use case is pretty straight forward An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662). An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662). An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft). Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so. Regards, Andrii On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt wrote: > Hi Andrii, > > thanks for your post. > > The draft is intended to provide AS and RS with a solution to exchange > signed (and optionally encrypted) token introspection responses in order = to > provide stronger assurance among those parties. This is important in use > cases where the RS acts upon the introspection response data and wants th= e > AS to take liability re the data quality. > > I=E2=80=99m not sure whether there are similar use cases if a client intr= ospects a > refresh token. What is your use case? > > best regards, > Torsten. > > > Am 07.02.2021 um 08:41 schrieb Andrii Deinega >: > > > > Hi WG, > > > > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 > Token Introspection [RFC7662] specifies a method for a protected resource > to query an OAuth 2.0 authorization server to determine the state of an > access token and obtain data associated with the access token." which is > true. Although, according to RFC7662, the introspection endpoint allows t= o > introspect a refresh token as well. Hence, the question I have is how wil= l > a token introspection response look like when the caller provides a refre= sh > token and sets the "Accept" HTTP header to > "application/token-introspection+jwt"? > > > > I expect there will be no differences, right? > > > > If so, I suggest to > > =E2=80=A2 replace "a resource server" by "the caller" in section = 4 > (Requesting a JWT Response) > > =E2=80=A2 change "If the access token is invalid, expired, revoke= d" by "If > a given token is invalid, expired, revoked" in section 5 (JWT Response) > > If not, my suggestion would be to clarify what the AS should do when it > asked to introspect the refresh token in general and additionally, what > should happen in the same case based on the type of the caller from the > AS's point of view. > > > > Regards, > > Andrii > > > > --0000000000001fa69c05bac4ec58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Torsten,

thank you for your respons= e.

My use case is pretty straight=C2=A0forward

An OAuth client queries = the AS to determine the active state of an access token and gets the intros= pection response which indicates that this access token is active (using RF= C7662).

An OAuth client queries the AS to determine the active state of a refr= esh token and gets the introspection response which indicates that this ref= resh token is active (using RFC7662).

An OAuth client queries the AS to determ= ine the active state of an access token and gets the introspection response= (JWT) whi= ch indicates that this access token is active (using this draft).

No= w, an OAuth client queries the AS to determine the active state of a refresh token (u= sing this draft)... How will the introspection response look like assuming = that the client provides the valid refresh token and technically, nothing s= tops it from doing so.

Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <torsten@lodderstedt.net>= ; wrote:
Hi Andr= ii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange sign= ed (and optionally encrypted) token introspection responses in order to pro= vide stronger assurance among those parties. This is important in use cases= where the RS acts upon the introspection response data and wants the AS to= take liability re the data quality.

I=E2=80=99m not sure whether there are similar use cases if a client intros= pects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>:=
>
> Hi WG,
>
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth= 2.0 Token Introspection [RFC7662] specifies a method for a protected resou= rce to query an OAuth 2.0 authorization server to determine the state of an= access token and obtain data associated with the access token." which= is true. Although, according to RFC7662, the introspection endpoint allows= to introspect a refresh token as well. Hence, the question I have is how w= ill a token introspection response look like when the caller provides a ref= resh token and sets the "Accept" HTTP header to "application= /token-introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "a resource server&qu= ot; by "the caller" in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "If the access token i= s invalid, expired, revoked" by "If a given token is invalid, exp= ired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when i= t asked to introspect the refresh token in general and additionally, what s= hould happen in the same case based on the type of the caller from the AS&#= 39;s point of view.
>
> Regards,
> Andrii
>

--0000000000001fa69c05bac4ec58-- From nobody Sun Feb 7 13:58:28 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A083A1395 for ; Sun, 7 Feb 2021 13:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu-PX1BfBqPO for ; Sun, 7 Feb 2021 13:58:24 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06E33A1392 for ; Sun, 7 Feb 2021 13:58:23 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id u14so15034835wri.3 for ; Sun, 07 Feb 2021 13:58:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=mykHn/qZVVA22XA41UXf3ENNqNMSW5puxm+Nra+sLH0=; b=zx+iajtR1ueaTadllhRX/Nnln2dhUdMZ+Kh1n6XYVbxNrAzthWv4sMRhmA9w2u1wyI aZ2MkyaMRZ7K7UFIC4vzugZKKf+8xJdmQaRDvSlIqsYXsbBOjNGsktB69fezkWbH31J3 r0dg8wXy9WNfyLxhVevErVKctPD7azEtwpOodknZ6Eznkgiekb1zoX8zDYphjM0gxP/h tmLA71F5o3HNXOa9Fvz9FF/I1LfJ8SeP7+T6Q6j4sN9Y0nDHkRVC7/P7alQKrI4zzn9v fFB3CL6H4iB+JU3xp+k4rKC+uTUzHivih+6eYTmw4914z/PBlqmlxusMTfdkl0tT9EFe IpYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=mykHn/qZVVA22XA41UXf3ENNqNMSW5puxm+Nra+sLH0=; b=YtyDnVhy4fJRf0b80oCYSMTMtN6SNaTXJ0aUELZAEkgMi/8jK6P2UziCzstA1ovuW1 VQwUSYjHKL0tX5h1Mw4FVVkGFoGN3XHxcwo6hlo4Wj8VjjtmG4FO1QUuwcPX+BRnx5pQ KkpOaNof+ygMjK1T79e1CjHPjKDR9aeYr1cA6vff7+eNKiRKHWehdISM6hoNeT6GTVFo ODF5njCqSoxcUNXqGp/eMdDeRWx/0oXXQLF9YJJvFyEgQGC5H6CP6L3icP89vt5Gocum IfX6jf5gusuybYoO1v1spvDRFW69wWGm3cZFzzI+ZvUTNVVS9duujdb69JpZz6l9lfWg Tt1A== X-Gm-Message-State: AOAM531zXDNvjfwhtrt8h4u1l1znQ7QzTNNTovKeVQvanaxbb9PLU+Ob SLVwyUVqWhBITO9GLxo2GfXw3Q== X-Google-Smtp-Source: ABdhPJyyc2SVLrvJx8BYOlX6PK2BYEoNYsPx5nFzIDdDzG6bVy/9jpQ9GFX/iL9lXzDuzFMd7K/dkg== X-Received: by 2002:a5d:4bc2:: with SMTP id l2mr17020760wrt.204.1612735102244; Sun, 07 Feb 2021 13:58:22 -0800 (PST) Received: from [192.168.71.135] (p5b0d9c0a.dip0.t-ipconnect.de. [91.13.156.10]) by smtp.gmail.com with ESMTPSA id l2sm16979014wmq.17.2021.02.07.13.58.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Feb 2021 13:58:21 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-263011FB-C9DB-41E6-9A81-05A2E7727655; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 7 Feb 2021 22:58:19 +0100 Message-Id: <536313C1-95E8-4A05-97B1-F3CD8984B49F@lodderstedt.net> References: Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org In-Reply-To: To: Andrii Deinega X-Mailer: iPad Mail (18B92) Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 21:58:26 -0000 --Apple-Mail-263011FB-C9DB-41E6-9A81-05A2E7727655 Content-Type: multipart/alternative; boundary=Apple-Mail-705D37E2-EF6C-4447-9339-55DCCD5C0C8D Content-Transfer-Encoding: 7bit --Apple-Mail-705D37E2-EF6C-4447-9339-55DCCD5C0C8D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andrii, > Am 07.02.2021 um 21:30 schrieb Andrii Deinega : >=20 > =EF=BB=BF > Hi Torsten, >=20 > thank you for your response. >=20 > My use case is pretty straight forward >=20 > An OAuth client queries the AS to determine the active state of an access t= oken and gets the introspection response which indicates that this access to= ken is active (using RFC7662). >=20 > An OAuth client queries the AS to determine the active state of a refresh t= oken and gets the introspection response which indicates that this refresh t= oken is active (using RFC7662). >=20 > An OAuth client queries the AS to determine the active state of an access t= oken and gets the introspection response (JWT) which indicates that this acc= ess token is active (using this draft). >=20 > Now, an OAuth client queries the AS to determine the active state of a ref= resh token (using this draft)... How will the introspection response look li= ke assuming that the client provides the valid refresh token and technically= , nothing stops it from doing so. why should the state be provided as JWT?I think the plain JSON response is s= ufficient in that case. I also think using token introspection for checking= the state of a token from the client side has limited utility. The definiti= ve decision is always made when the client tries to access a resource.=20 I=E2=80=98m therefore leaning towards explicitly stating in our draft that i= t is not intended to be used with refresh tokens. best regards, Torsten. >=20 > Regards, > Andrii >=20 >=20 >> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt wrote: >> Hi Andrii, >>=20 >> thanks for your post.=20 >>=20 >> The draft is intended to provide AS and RS with a solution to exchange si= gned (and optionally encrypted) token introspection responses in order to pr= ovide stronger assurance among those parties. This is important in use cases= where the RS acts upon the introspection response data and wants the AS to t= ake liability re the data quality.=20 >>=20 >> I=E2=80=99m not sure whether there are similar use cases if a client intr= ospects a refresh token. What is your use case? >>=20 >> best regards, >> Torsten. =20 >>=20 >> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega : >> >=20 >> > Hi WG, >> >=20 >> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 T= oken Introspection [RFC7662] specifies a method for a protected resource to q= uery an OAuth 2.0 authorization server to determine the state of an access t= oken and obtain data associated with the access token." which is true. Altho= ugh, according to RFC7662, the introspection endpoint allows to introspect a= refresh token as well. Hence, the question I have is how will a token intro= spection response look like when the caller provides a refresh token and set= s the "Accept" HTTP header to "application/token-introspection+jwt"? >> >=20 >> > I expect there will be no differences, right? >> >=20 >> > If so, I suggest to >> > =E2=80=A2 replace "a resource server" by "the caller" in section 4= (Requesting a JWT Response) >> > =E2=80=A2 change "If the access token is invalid, expired, revoke= d" by "If a given token is invalid, expired, revoked" in section 5 (JWT Resp= onse) >> > If not, my suggestion would be to clarify what the AS should do when it= asked to introspect the refresh token in general and additionally, what sho= uld happen in the same case based on the type of the caller from the AS's po= int of view. >> >=20 >> > Regards, >> > Andrii >> >=20 >>=20 --Apple-Mail-705D37E2-EF6C-4447-9339-55DCCD5C0C8D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii De= inega <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi Torsten,
<= div>
thank you for your response.

My use case is pretty stra= ight forward

An OAuth client queries the AS to determine the active state o= f an access token and gets the introspection response which indicates that t= his access token is active (using RFC7662).

An OAuth client queries the AS to de= termine the active state of a refresh token and gets the introspection respo= nse which indicates that this refresh token is active (using RFC7662).
An OAuth c= lient queries the AS to determine the active state of an access token and ge= ts the introspection response (JWT) which indicates that this access token is active (u= sing this draft).

Now, an OAuth client queries the AS to determine the active st= ate of a refresh token (using this draft)... How will the introspection resp= onse look like assuming that the client provides the valid refresh token and= technically, nothing stops it from doing so.
<= br>
why should the state be provided as JWT?I think the plain JSON resp= onse is sufficient in that case.  I also think using token introsp= ection for checking the state of a token from the client side has limited ut= ility. The definitive decision is always made when the client tries to acces= s a resource. 

I=E2=80=98m therefore leaning towards= explicitly stating in our draft that it is not intended to be used with ref= resh tokens.

best regards,
Torsten.


Regards,
Andrii


On Sun, Feb 7, 2021 at 4:= 14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange signe= d (and optionally encrypted) token introspection responses in order to provi= de stronger assurance among those parties. This is important in use cases wh= ere the RS acts upon the introspection response data and wants the AS to tak= e liability re the data quality.

I=E2=80=99m not sure whether there are similar use cases if a client introsp= ects a refresh token. What is your use case?

best regards,
Torsten. 

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>: >
> Hi WG,
>
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 T= oken Introspection [RFC7662] specifies a method for a protected resource to q= uery an OAuth 2.0 authorization server to determine the state of an access t= oken and obtain data associated with the access token." which is true. Altho= ugh, according to RFC7662, the introspection endpoint allows to introspect a= refresh token as well. Hence, the question I have is how will a token intro= spection response look like when the caller provides a refresh token and set= s the "Accept" HTTP header to "application/token-introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>       =E2=80=A2 replace "a resource server" by "the= caller" in section 4 (Requesting a JWT Response)
>       =E2=80=A2 change "If the access token is inva= lid, expired, revoked" by "If a given token is invalid, expired, revoked" in= section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it= asked to introspect the refresh token in general and additionally, what sho= uld happen in the same case based on the type of the caller from the AS's po= int of view.
>
> Regards,
> Andrii
>

= --Apple-Mail-705D37E2-EF6C-4447-9339-55DCCD5C0C8D-- --Apple-Mail-263011FB-C9DB-41E6-9A81-05A2E7727655 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjA3MjE1ODE5WjAvBgkqhkiG9w0BCQQxIgQg sxGKcufjfJ221/PZ4P/FMcUUPjMfnlmIo/nx3AwxSl4wgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAXcNh8xRk9Xfg05Mb1sIAfzwmM9N38B0+vTMtkYaePyKK11dGtd3k Hkn7hTZrA2RaCcUSyyCYgr7AReC1+K0IM5OtGc0nkg7rWP4a7YA5lM0VOluvJFZE7bPASO4waNCl e9u7e+vCgKGTpk6LIB/enCXAMVIyrgC9JmDPLSitLlFtmlufG2cpGw7tMEoiIwdQyo8KU8XoHqm7 ZrO/lzEMF9eTsAM3akEELGzQtIDzMgNrQrQ5C5o/jXnOeQfY/mEaUo3GtX+MdWBBs1aCvKR/Z+z9 dpSAhJ4bDYwuk3DDJrusxZ8DOMG2pFG0iagmK9CCL1oare9WhCF1cUGBx1bl6wAAAAAAAA== --Apple-Mail-263011FB-C9DB-41E6-9A81-05A2E7727655-- From nobody Sun Feb 7 15:56:37 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9924E3A0C30 for ; Sun, 7 Feb 2021 15:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPmksY1IvUNs for ; Sun, 7 Feb 2021 15:56:31 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12593A0C28 for ; Sun, 7 Feb 2021 15:56:31 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id n201so13172342iod.12 for ; Sun, 07 Feb 2021 15:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zvZ3ygq6UFw3PKenL0MI2QZjDzjYCIKs1Yw7haUwyL8=; b=KcDtqOTVukPxx+9MMOByxyexPTGLsz4VujTckbWaq4uYOu0h+n8jT7wLmpoVLjJXoe K7epF3osCZ4oUq2MlYSLMNHzy9ZRtoMiQv+FNxxHuNBOTkxdTkP0DGXhwXCUYT6pvxvl qe+xffQotBS/ucE2srXjzO+y1cJcJXs0yxAhmqwZoMGW8OMdXQPj95CJpjn/sIG8nVF6 EbQ0wPVXAahx7sLR7ziYngz7quWacjVxgQSMeL92MwmyP6OhU7nVX5U5HRrjUD6wgjRb wzpaMjjaV2Xy21IEJ92yV0/KnmliVS3eH7zigl2rZvPLxnNLjN9FwGI1m3gA2MgBUsMU o/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zvZ3ygq6UFw3PKenL0MI2QZjDzjYCIKs1Yw7haUwyL8=; b=BP85JM+yNexmCWEG8or6rk6nQP5KUospAPdFaYEQcug7Hosr0UwXwIippO3PEhJt/2 diMF149nfx9mfSPF2M64hFgyA35/iXqskoCumlFnRWEmORy5SriJ1gV0lFq4NGOuz7bI KJ4q1j/vuD2QeSbVtvWD1q00T7KQ03ZgYJ07I+zHZXqZgKIxgrA+kV2h96Y1pb1AkGEi 2/lmP71SzYQtR0dd0T32SImN0cLNyaO5GViPUw+2YtHYZSKJZY74Ww//iFSi96gUq0iF pEb9hYCb3QtZ0HrYuQPeR3RNRJC1EvGtnfbX0VaY3kYdrlggoN9mO0Kr8GRaOn3tA3PP U7Hw== X-Gm-Message-State: AOAM532imR/T68x3p1ac/ED9CY1v0/s0iEO1vQkoceZbmNDUv1F4av88 cnAI82nThOJbNoDUXDWwhtKNdVV8Pr8NAS5sK7Ek X-Google-Smtp-Source: ABdhPJzLwj9JfbVcCCx5T2XcEIiVWgNeoW7o3URh6vOeVRKDaDReFGrDMUJFr0tOkb+Kddf79exbC15FqopCmDlwdoY= X-Received: by 2002:a02:5447:: with SMTP id t68mr11046283jaa.78.1612742190681; Sun, 07 Feb 2021 15:56:30 -0800 (PST) MIME-Version: 1.0 References: <536313C1-95E8-4A05-97B1-F3CD8984B49F@lodderstedt.net> In-Reply-To: <536313C1-95E8-4A05-97B1-F3CD8984B49F@lodderstedt.net> From: Warren Parad Date: Mon, 8 Feb 2021 00:56:20 +0100 Message-ID: To: Torsten Lodderstedt Cc: Andrii Deinega , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="0000000000006417b305bac7cd8b" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 23:56:36 -0000 --0000000000006417b305bac7cd8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I=E2=80=98m therefore leaning towards explicitly stating in our draft tha= t it is > not intended to be used with refresh tokens. I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt wrote: > Hi Andrii, > > Am 07.02.2021 um 21:30 schrieb Andrii Deinega : > > =EF=BB=BF > Hi Torsten, > > thank you for your response. > > My use case is pretty straight forward > > An OAuth client queries the AS to determine the active state of an access > token and gets the introspection response which indicates that this acces= s > token is active (using RFC7662). > > An OAuth client queries the AS to determine the active state of a refresh > token and gets the introspection response which indicates that this refre= sh > token is active (using RFC7662). > > An OAuth client queries the AS to determine the active state of an access > token and gets the introspection response (JWT) which indicates that this > access token is active (using this draft). > > Now, an OAuth client queries the AS to determine the active state of a > refresh token (using this draft)... How will the introspection response > look like assuming that the client provides the valid refresh token and > technically, nothing stops it from doing so. > > > why should the state be provided as JWT?I think the plain JSON response i= s > sufficient in that case. I also think using token introspection for > checking the state of a token from the client side has limited utility. T= he > definitive decision is always made when the client tries to access a > resource. > > I=E2=80=98m therefore leaning towards explicitly stating in our draft tha= t it is > not intended to be used with refresh tokens. > > best regards, > Torsten. > > > Regards, > Andrii > > > On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Andrii, >> >> thanks for your post. >> >> The draft is intended to provide AS and RS with a solution to exchange >> signed (and optionally encrypted) token introspection responses in order= to >> provide stronger assurance among those parties. This is important in use >> cases where the RS acts upon the introspection response data and wants t= he >> AS to take liability re the data quality. >> >> I=E2=80=99m not sure whether there are similar use cases if a client int= rospects >> a refresh token. What is your use case? >> >> best regards, >> Torsten. >> >> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega > >: >> > >> > Hi WG, >> > >> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 >> Token Introspection [RFC7662] specifies a method for a protected resourc= e >> to query an OAuth 2.0 authorization server to determine the state of an >> access token and obtain data associated with the access token." which is >> true. Although, according to RFC7662, the introspection endpoint allows = to >> introspect a refresh token as well. Hence, the question I have is how wi= ll >> a token introspection response look like when the caller provides a refr= esh >> token and sets the "Accept" HTTP header to >> "application/token-introspection+jwt"? >> > >> > I expect there will be no differences, right? >> > >> > If so, I suggest to >> > =E2=80=A2 replace "a resource server" by "the caller" in section= 4 >> (Requesting a JWT Response) >> > =E2=80=A2 change "If the access token is invalid, expired, revok= ed" by >> "If a given token is invalid, expired, revoked" in section 5 (JWT Respon= se) >> > If not, my suggestion would be to clarify what the AS should do when i= t >> asked to introspect the refresh token in general and additionally, what >> should happen in the same case based on the type of the caller from the >> AS's point of view. >> > >> > Regards, >> > Andrii >> > >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000006417b305bac7cd8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80= =98m therefore leaning towards explicitly stating in our draft that it is n= ot intended to be used with refresh tokens.
I'm not fo= llowing, why explicitly state that it isn't intended. If an AS wants to= provide a similar JSON response to a query with the refresh token, why not= encourage that?

<= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">

Warren Parad

Founder, CTO

Secure your user data and complete your autho= rization architecture. Implement=C2=A0Authress.


On Sun, Feb 7, 2021 = at 10:58 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
<= /div>
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.deinega@gmail.com>:
=EF=BB= =BF
Hi=C2=A0Torsten,

thank you for your response.
<= br>My use case is pretty straight=C2=A0forward

An OAuth client queries the AS to determi= ne the active state of an access token and gets the introspection response = which indicates that this access token is active (using RFC7662).

An= OAuth client querie= s the AS to determine the active state of a refresh token and gets the intr= ospection response which indicates that this refresh token is active (using= RFC7662).

An OAuth<= /span> client queries the AS to determine the active state of an access tok= en and gets the introspection response (JWT) which indicates that this access token is active (= using this draft).

Now, an OAuth client queries the AS to determine the active state of = a refresh token (using this draft)... How will the introspection response l= ook like assuming that the client provides the valid refresh token and tech= nically, nothing stops it from doing so.

<= /div>why should the state be provided as JWT?I think the plain JSON respons= e is sufficient in that case.=C2=A0=C2=A0I also think using token introspec= tion for checking the state of a token from the client side has limited uti= lity. The definitive decision is always made when the client tries to acces= s a resource.=C2=A0

I=E2=80=98m therefore leaning toward= s explicitly stating in our draft that it is not intended to be used with r= efresh tokens.

best regards,
Torsten= .


Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 = AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange sign= ed (and optionally encrypted) token introspection responses in order to pro= vide stronger assurance among those parties. This is important in use cases= where the RS acts upon the introspection response data and wants the AS to= take liability re the data quality.

I=E2=80=99m not sure whether there are similar use cases if a client intros= pects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>:=
>
> Hi WG,
>
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth= 2.0 Token Introspection [RFC7662] specifies a method for a protected resou= rce to query an OAuth 2.0 authorization server to determine the state of an= access token and obtain data associated with the access token." which= is true. Although, according to RFC7662, the introspection endpoint allows= to introspect a refresh token as well. Hence, the question I have is how w= ill a token introspection response look like when the caller provides a ref= resh token and sets the "Accept" HTTP header to "application= /token-introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "a resource server&qu= ot; by "the caller" in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "If the access token i= s invalid, expired, revoked" by "If a given token is invalid, exp= ired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when i= t asked to introspect the refresh token in general and additionally, what s= hould happen in the same case based on the type of the caller from the AS&#= 39;s point of view.
>
> Regards,
> Andrii
>

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000006417b305bac7cd8b-- From nobody Sun Feb 7 18:18:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6F3A0E3D for ; Sun, 7 Feb 2021 18:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXBopuhP7fyP for ; Sun, 7 Feb 2021 18:18:50 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C923A0E3A for ; Sun, 7 Feb 2021 18:18:49 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id a16so11340855wmm.0 for ; Sun, 07 Feb 2021 18:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=tCer/IFcTArqgPndcDvIqqI+DjC4Vd9OuLV9mR6LFjE=; b=f4u5nBrBlrqio7nSlRS21xmxvir8cVJzScSl05FPHYuUjk5BffFI1hmBd9GHXbvd5U 9yHZJ5ibCx9wXbCbp/0U1i5hj0uUSrlLQu4dP2bXwq7NeEBXjJBBDJobnaRWZOLHixzc BgsM1FgtlLPGNyKhL/Ii2n4ELEvg2k6FYh28aPnsdNORZO4ikQKgEBhUpTdbRVbuG8ZI N4k0vKa0PhwO0T+YXaBf5yqUT3zNveojeDDbN1auBp+YNTHe6Tl3hK1O1dJrBGbYXBQj swgOBhn5MqAV6cRde0PMf5JGDDDZyfun3F4RVRJFfaHwolGsKfDv4Lw9Sh9IEE9PEm8Z 92nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=tCer/IFcTArqgPndcDvIqqI+DjC4Vd9OuLV9mR6LFjE=; b=IgmCHc9pxRrr2iItmwHVmETrDz28yMjYB+RYm4Jl748/1kkgGUq/pbYKMVPeman5Ji 6FQaS7EBJyl5D4cMRelKfQBOJIN28Vu+5jLBwqkbEWTCKNDefL0gQwrsphIwAeeUHC8n PIUVILm+BiPGoq6HnKKDlg9ybZEmQ7LXg2bPmkwC7BxAjHFCC6WjS22IfwW01fy5YQJo 4wJdBUJpB6FbDNaQ2N3mjG/Ogn8TQVhnaylI9Ihc6Ze+GG2a/5fnrFetIKQoA7mbrRNa J4KroIcJiR+8g9SBKY0woXphXdZ1nPyxjUDxXofjIfjiGe1tRAWDAr3Lag5j+d90xamo ZXgw== X-Gm-Message-State: AOAM533C/w9Q3H5BdNmgkD55Q3+vDr6OOJRxcivVYIi4vALcG8Bmcvxg U4BTQGgGNU2SdilTjslZg8ezkA== X-Google-Smtp-Source: ABdhPJxCzI8ceKQHOQoj7qSWyWhhx0Vzv/pdsx6vMiwxJS1rkmP6KqNpnxbK+fSxsI5HJiE56Yd+cg== X-Received: by 2002:a05:600c:4f48:: with SMTP id m8mr12846876wmq.12.1612750727848; Sun, 07 Feb 2021 18:18:47 -0800 (PST) Received: from [192.168.71.135] (p5b0d9c0a.dip0.t-ipconnect.de. [91.13.156.10]) by smtp.gmail.com with ESMTPSA id y5sm6803333wmi.10.2021.02.07.18.18.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Feb 2021 18:18:46 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-F01FBA13-513D-475E-8FB7-EB1119030663; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Mon, 8 Feb 2021 03:18:45 +0100 Message-Id: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> References: Cc: Torsten Lodderstedt , Andrii Deinega , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org In-Reply-To: To: Warren Parad X-Mailer: iPad Mail (18B92) Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 02:18:53 -0000 --Apple-Mail-F01FBA13-513D-475E-8FB7-EB1119030663 Content-Type: multipart/alternative; boundary=Apple-Mail-3B4E0263-5919-4530-A3C7-571A18D23198 Content-Transfer-Encoding: 7bit --Apple-Mail-3B4E0263-5919-4530-A3C7-571A18D23198 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 08.02.2021 um 00:56 schrieb Warren Parad : >=20 > =EF=BB=BF >> I=E2=80=98m therefore leaning towards explicitly stating in our draft tha= t it is not intended to be used with refresh tokens. > I'm not following, why explicitly state that it isn't intended. If an AS w= ants to provide a similar JSON response to a query with the refresh token, w= hy not encourage that? Why should we encourage it?=20 >=20 > =09 > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. Implem= ent Authress. >=20 >=20 >> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt wrote: >> Hi Andrii, >>=20 >>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega : >>>>=20 >>> =EF=BB=BF >>> Hi Torsten, >>>=20 >>> thank you for your response. >>>=20 >>> My use case is pretty straight forward >>>=20 >>> An OAuth client queries the AS to determine the active state of an acces= s token and gets the introspection response which indicates that this access= token is active (using RFC7662). >>>=20 >>> An OAuth client queries the AS to determine the active state of a refres= h token and gets the introspection response which indicates that this refres= h token is active (using RFC7662). >>>=20 >>> An OAuth client queries the AS to determine the active state of an acces= s token and gets the introspection response (JWT) which indicates that this a= ccess token is active (using this draft). >>>=20 >>> Now, an OAuth client queries the AS to determine the active state of a r= efresh token (using this draft)... How will the introspection response look l= ike assuming that the client provides the valid refresh token and technicall= y, nothing stops it from doing so. >>=20 >> why should the state be provided as JWT?I think the plain JSON response i= s sufficient in that case. I also think using token introspection for check= ing the state of a token from the client side has limited utility. The defin= itive decision is always made when the client tries to access a resource.=20= >>=20 >> I=E2=80=98m therefore leaning towards explicitly stating in our draft tha= t it is not intended to be used with refresh tokens. >>=20 >> best regards, >> Torsten. >>=20 >>>=20 >>> Regards, >>> Andrii >>>=20 >>>=20 >>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt wrote: >>>> Hi Andrii, >>>>=20 >>>> thanks for your post.=20 >>>>=20 >>>> The draft is intended to provide AS and RS with a solution to exchange s= igned (and optionally encrypted) token introspection responses in order to p= rovide stronger assurance among those parties. This is important in use case= s where the RS acts upon the introspection response data and wants the AS to= take liability re the data quality.=20 >>>>=20 >>>> I=E2=80=99m not sure whether there are similar use cases if a client in= trospects a refresh token. What is your use case? >>>>=20 >>>> best regards, >>>> Torsten. =20 >>>>=20 >>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega : >>>> >=20 >>>> > Hi WG, >>>> >=20 >>>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0= Token Introspection [RFC7662] specifies a method for a protected resource t= o query an OAuth 2.0 authorization server to determine the state of an acces= s token and obtain data associated with the access token." which is true. Al= though, according to RFC7662, the introspection endpoint allows to introspec= t a refresh token as well. Hence, the question I have is how will a token in= trospection response look like when the caller provides a refresh token and s= ets the "Accept" HTTP header to "application/token-introspection+jwt"? >>>> >=20 >>>> > I expect there will be no differences, right? >>>> >=20 >>>> > If so, I suggest to >>>> > =E2=80=A2 replace "a resource server" by "the caller" in sectio= n 4 (Requesting a JWT Response) >>>> > =E2=80=A2 change "If the access token is invalid, expired, revo= ked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Re= sponse) >>>> > If not, my suggestion would be to clarify what the AS should do when i= t asked to introspect the refresh token in general and additionally, what sh= ould happen in the same case based on the type of the caller from the AS's p= oint of view. >>>> >=20 >>>> > Regards, >>>> > Andrii >>>> >=20 >>>>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3B4E0263-5919-4530-A3C7-571A18D23198 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Am 08.02.2021 um 00:56 schrieb Warren Parad &= lt;wparad@rhosys.ch>:

=EF=BB=BF
I=E2=80=98m therefore leaning towards explicitly stating in= our draft that it is not intended to be used with refresh tokens.
I'm not following, why explicitly state that it isn't intended. If a= n AS wants to provide a similar JSON response to a query with the refresh to= ken, why not encourage that?

Wh= y should we encourage it? 


Secure your user data and complete your a= uthorization architecture. Implement Authress.

On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt &= lt;torsten=3D40lodderste= dt.net@dmarc.ietf.org> wrote:
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andr= ii Deinega <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi Torsten,

tha= nk you for your response.

My use case is pretty straight forward=

An OAuth clie= nt queries the AS to determine the active state of an access token and gets t= he introspection response which indicates that this access token is active (= using RFC7662).

An OA= uth client queries the AS to determine the active state of a refresh t= oken and gets the introspection response which indicates that this refresh t= oken is active (using RFC7662).

An OAuth client queries the AS to determine the active sta= te of an access token and gets the introspection response (JWT) which indicates that this access t= oken is active (using this draft).

Now, an OAuth client queries the AS to determine the ac= tive state of a refresh token (using this draft)... How will the introspecti= on response look like assuming that the client provides the valid refresh to= ken and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JS= ON response is sufficient in that case.  I also think using token i= ntrospection for checking the state of a token from the client side has limi= ted utility. The definitive decision is always made when the client tries to= access a resource. 

I=E2=80=98m therefore leaning t= owards explicitly stating in our draft that it is not intended to be used wi= th refresh tokens.

best regards,
Tors= ten.


Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 A= M Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange signe= d (and optionally encrypted) token introspection responses in order to provi= de stronger assurance among those parties. This is important in use cases wh= ere the RS acts upon the introspection response data and wants the AS to tak= e liability re the data quality.

I=E2=80=99m not sure whether there are similar use cases if a client introsp= ects a refresh token. What is your use case?

best regards,
Torsten. 

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>: >
> Hi WG,
>
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 T= oken Introspection [RFC7662] specifies a method for a protected resource to q= uery an OAuth 2.0 authorization server to determine the state of an access t= oken and obtain data associated with the access token." which is true. Altho= ugh, according to RFC7662, the introspection endpoint allows to introspect a= refresh token as well. Hence, the question I have is how will a token intro= spection response look like when the caller provides a refresh token and set= s the "Accept" HTTP header to "application/token-introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>       =E2=80=A2 replace "a resource server" by "the= caller" in section 4 (Requesting a JWT Response)
>       =E2=80=A2 change "If the access token is inva= lid, expired, revoked" by "If a given token is invalid, expired, revoked" in= section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it= asked to introspect the refresh token in general and additionally, what sho= uld happen in the same case based on the type of the caller from the AS's po= int of view.
>
> Regards,
> Andrii
>

___________________________= ____________________
OAuth mailing list
OAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth
= --Apple-Mail-3B4E0263-5919-4530-A3C7-571A18D23198-- --Apple-Mail-F01FBA13-513D-475E-8FB7-EB1119030663 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjA4MDIxODQ1WjAvBgkqhkiG9w0BCQQxIgQg dyS8R0j0kzMBMm5tLg9Ie0eiI6e6mAvBfnrGr3DFuOwwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAamEH/k/m0g0ZcdcmOdJpYPP3Covqcq4Fpv6+bAVg5WbwMDHubUVv XDot9cHay1y3anHXDi+0CYsu4nmhqVi3NGJlBRzEhLSMQXadY8vwCaensntAUO9woNfPtXqbje39 eDEJPh2D/11sEiBT3nQ31syD7I7z/YdljMpu+Tu+KSldgWxEr7Sgc2sbpZWZ0mYOephc0Qu6vW5q qKunK+cD8ccK3H8uRaLoS1HJkjBQFGYtmk1FsPAhyVaoz9RkofOVqouCyRLzwWHcDD/HKdpwPQml KmTiz6/yzFRJEWdX2Xpdvy/mkZMYtbvpPIQyhSMdIU0F40kNMsh7nObHP/pMewAAAAAAAA== --Apple-Mail-F01FBA13-513D-475E-8FB7-EB1119030663-- From nobody Mon Feb 8 01:07:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CC93A14E9 for ; Mon, 8 Feb 2021 01:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuGThtu6eLKd for ; Mon, 8 Feb 2021 01:07:29 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4676E3A14E5 for ; Mon, 8 Feb 2021 01:07:29 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id n14so14214922iog.3 for ; Mon, 08 Feb 2021 01:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cgOXSqqMZpuNze4EifbCezvKpMaUiFsFTPz76DkKNz4=; b=fCcXwTanT+Pd+8pn0yJT5ZnE/yXxlyOuoYXQ1i0e48PZYiE70rUZ7Z/67le3Yl1Tev zNHHwtPp/wtODW4VjhRtWYSlQMt1X0YnU5hutLlR21rbnHvP0QiqcZveMXBi4QEQaBVv dKOIPPXE8CqZx61tD3tpiDR2SdRE368wl/8MEHV/0ophApmv9bv9G3NEcJ9zfchT3yLJ DGyJ4zP/sc1L4YCpW8bvW9g4SLpL/kPAYcdrkBd+M54ZU/S+ZYYWbHz2qjxX8A9+fr5O DWejp4VYj/sKADESF41NOvJ9uvx9h4bYVsk0mnVDxgYKEK6WIMpyKP4kkZe1aD01+0fg upqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cgOXSqqMZpuNze4EifbCezvKpMaUiFsFTPz76DkKNz4=; b=rP+1rX3ZhJ88023psJuBuJ2HG9tZ2VcL9BKuZ2UOC8Cf3I1V16+ywaIZbqRVyTcC5g RTivxUpJnyjy5le0leuwKI8FTvaisqAJATYel597mb6w4nw/vReaHcpNq+B+tKRTZyFX ZFiHjOiSQh/x7TZxWrgc3yCy6mROYXhs0JKCZWW0oWDxObPUV2X5E0+YW5ZDEDAakGMf f6AcVIlNMUR/4qKZ/76G0sqwYdE5IaCrBF2BLd1UBJuaWieCVV5w2+kQAviszqH9FeQG d0D2GzilXzh+moXT+1uiTyXppRtZS2iYmp5465iRnhJjiM5lPktpUQqSz9CH8JsyTpjh JIyA== X-Gm-Message-State: AOAM533WpYJrv9wQF+7WT5lS6MVLvj9x2RUUUE0rXKBf8e0Th57nQ7ni sSr9q6zcRlj3q/Kaa00Hw8HGA2Ym7KaT7xnfjS2y X-Google-Smtp-Source: ABdhPJxYV2I08y5DgHE7IRnyLIevzAeE/mjzgAAAxxNi7vH9lqnlVO1VOpitUFSJP0JXY0lPHTCDruw3cwb+ptmDa9g= X-Received: by 2002:a6b:da0f:: with SMTP id x15mr14137422iob.48.1612775248375; Mon, 08 Feb 2021 01:07:28 -0800 (PST) MIME-Version: 1.0 References: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> In-Reply-To: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> From: Warren Parad Date: Mon, 8 Feb 2021 10:07:19 +0100 Message-ID: To: torsten@lodderstedt.net Cc: Torsten Lodderstedt , Andrii Deinega , oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="000000000000c84a8305bacf7f12" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 09:07:32 -0000 --000000000000c84a8305bacf7f12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it. Otherwise I could just say why not? And I can go stronger, what's the purpose of nho introspection endpoint at all, and why encourage sending access tokens to the AS? Even if you can justify access tokens, there currently isn't evidence provided why we should explicity discourage. On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt wrote: > > > Am 08.02.2021 um 00:56 schrieb Warren Parad : > > =EF=BB=BF > >> I=E2=80=98m therefore leaning towards explicitly stating in our draft th= at it is >> not intended to be used with refresh tokens. > > I'm not following, why explicitly state that it isn't intended. If an AS > wants to provide a similar JSON response to a query with the refresh toke= n, > why not encourage that? > > > Why should we encourage it? > > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress > > . > > > On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >> Hi Andrii, >> >> Am 07.02.2021 um 21:30 schrieb Andrii Deinega = : >> >> =EF=BB=BF >> Hi Torsten, >> >> thank you for your response. >> >> My use case is pretty straight forward >> >> An OAuth client queries the AS to determine the active state of an >> access token and gets the introspection response which indicates that th= is >> access token is active (using RFC7662). >> >> An OAuth client queries the AS to determine the active state of a >> refresh token and gets the introspection response which indicates that t= his >> refresh token is active (using RFC7662). >> >> An OAuth client queries the AS to determine the active state of an >> access token and gets the introspection response (JWT) which indicates >> that this access token is active (using this draft). >> >> Now, an OAuth client queries the AS to determine the active state of a >> refresh token (using this draft)... How will the introspection response >> look like assuming that the client provides the valid refresh token and >> technically, nothing stops it from doing so. >> >> >> why should the state be provided as JWT?I think the plain JSON response >> is sufficient in that case. I also think using token introspection for >> checking the state of a token from the client side has limited utility. = The >> definitive decision is always made when the client tries to access a >> resource. >> >> I=E2=80=98m therefore leaning towards explicitly stating in our draft th= at it is >> not intended to be used with refresh tokens. >> >> best regards, >> Torsten. >> >> >> Regards, >> Andrii >> >> >> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi Andrii, >>> >>> thanks for your post. >>> >>> The draft is intended to provide AS and RS with a solution to exchange >>> signed (and optionally encrypted) token introspection responses in orde= r to >>> provide stronger assurance among those parties. This is important in us= e >>> cases where the RS acts upon the introspection response data and wants = the >>> AS to take liability re the data quality. >>> >>> I=E2=80=99m not sure whether there are similar use cases if a client in= trospects >>> a refresh token. What is your use case? >>> >>> best regards, >>> Torsten. >>> >>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega < >>> andrii.deinega@gmail.com>: >>> > >>> > Hi WG, >>> > >>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.0 >>> Token Introspection [RFC7662] specifies a method for a protected resour= ce >>> to query an OAuth 2.0 authorization server to determine the state of an >>> access token and obtain data associated with the access token." which i= s >>> true. Although, according to RFC7662, the introspection endpoint allows= to >>> introspect a refresh token as well. Hence, the question I have is how w= ill >>> a token introspection response look like when the caller provides a ref= resh >>> token and sets the "Accept" HTTP header to >>> "application/token-introspection+jwt"? >>> > >>> > I expect there will be no differences, right? >>> > >>> > If so, I suggest to >>> > =E2=80=A2 replace "a resource server" by "the caller" in sectio= n 4 >>> (Requesting a JWT Response) >>> > =E2=80=A2 change "If the access token is invalid, expired, revo= ked" by >>> "If a given token is invalid, expired, revoked" in section 5 (JWT Respo= nse) >>> > If not, my suggestion would be to clarify what the AS should do when >>> it asked to introspect the refresh token in general and additionally, w= hat >>> should happen in the same case based on the type of the caller from the >>> AS's point of view. >>> > >>> > Regards, >>> > Andrii >>> > >>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --000000000000c84a8305bacf7f12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It doesn't work that way. You suggested to add l= anguage to the draft, that means the burden of proof is on you to justify a= dding it.

Otherwise I could ju= st say why not?

And I ca= n go stronger, what's the purpose of nho introspection endpoint at all,= and why encourage sending access tokens to the AS?
=
Even if you can justify access tokens, there cu= rrently isn't evidence provided why we should explicity discourage.

= On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt <torsten@lodderstedt= .net> wrote:


Am 08.02.2021 um 00:56 schrieb Warren Parad <wparad@rhosys.ch= >:

=EF=BB=BF
I=E2=80=98m therefore leaning towards explicitly stating in our draft = that it is not intended to be used with refresh tokens.
I&= #39;m not following, why explicitly state that it isn't intended. If an= AS wants to provide a similar JSON response to a query with the refresh to= ken, why not encourage that?

W= hy should we encourage it?=C2=A0


Warren Parad

Founder, CTO

Warren Parad

Foun= der, CTO

Secure your user data and complete your authorization architectu= re. Implement=C2=A0Authress.


On Sun, Feb 7, 2021 at 10:58 PM Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.= ietf.org> wrote:
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii Deineg= a <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi=C2=A0Torsten,

thank yo= u for your response.

My use case is pretty straight=C2=A0forward
=
An OAuth client queries the AS to determine the = active state of an access token and gets the introspection response which i= ndicates that this access token is active (using RFC7662).

An OAuth client queries the AS to determine the active state = of a refresh token and gets the introspection response which indicates that= this refresh token is active (using RFC7662).

An OA= uth client queries the AS to determine the active state of an access= token and gets the introspection response (JWT) whi= ch indicates that this access token is active (using this draft).

No= w, an OAuth client queries the AS to determine the a= ctive state of a refresh token (using this draft)... How will the introspec= tion response look like assuming that the client provides the valid refresh= token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the pla= in JSON response is sufficient in that case.=C2=A0=C2=A0I also think using = token introspection for checking the state of a token from the client side = has limited utility. The definitive decision is always made when the client= tries to access a resource.=C2=A0

I=E2=80=98m therefore= leaning towards explicitly stating in our draft that it is not intended to= be used with refresh tokens.

best regards,
Torsten.

<= div dir=3D"ltr">

Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodder= stedt <torsten@lodderstedt.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange sign= ed (and optionally encrypted) token introspection responses in order to pro= vide stronger assurance among those parties. This is important in use cases= where the RS acts upon the introspection response data and wants the AS to= take liability re the data quality.

I=E2=80=99m not sure whether there are similar use cases if a client intros= pects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <and= rii.deinega@gmail.com>:
>
> Hi WG,
>
> draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth= 2.0 Token Introspection [RFC7662] specifies a method for a protected resou= rce to query an OAuth 2.0 authorization server to determine the state of an= access token and obtain data associated with the access token." which= is true. Although, according to RFC7662, the introspection endpoint allows= to introspect a refresh token as well. Hence, the question I have is how w= ill a token introspection response look like when the caller provides a ref= resh token and sets the "Accept" HTTP header to "application= /token-introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "a resource server&qu= ot; by "the caller" in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "If the access token i= s invalid, expired, revoked" by "If a given token is invalid, exp= ired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when i= t asked to introspect the refresh token in general and additionally, what s= hould happen in the same case based on the type of the caller from the AS&#= 39;s point of view.
>
> Regards,
> Andrii
>

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000c84a8305bacf7f12-- From nobody Mon Feb 8 07:13:39 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC43A0E32 for ; Mon, 8 Feb 2021 07:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYhDxIvP7AGe for ; Mon, 8 Feb 2021 07:13:34 -0800 (PST) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7473A0E30 for ; Mon, 8 Feb 2021 07:13:34 -0800 (PST) Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 98EFlmztU06jR98EGlp7vL; Mon, 08 Feb 2021 08:13:33 -0700 x-spam-cmae: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=6021551d p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=PzzBoh6yAAAA:8 a=pGLkceISAAAA:8 a=F18cNVTIXlhlJkRzNvQA:9 a=QEXdDO2ut3YA:10 a=1xOB4YiTHOsA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=W-gxJ9TLX_f0q5FysN4A:9 a=A58rr3yYCnV2Q1aA:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 a=L62bugPwxnpkHHKveAwe:22 x-spam-account: vladimir@connect2id.com x-spam-domain: connect2id.com X-CMAE-Analysis: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=6021551d p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8 a=PzzBoh6yAAAA:8 a=pGLkceISAAAA:8 a=F18cNVTIXlhlJkRzNvQA:9 a=QEXdDO2ut3YA:10 a=1xOB4YiTHOsA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=W-gxJ9TLX_f0q5FysN4A:9 a=A58rr3yYCnV2Q1aA:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=IdGyktwZ2tr74praB_5u:22 a=L62bugPwxnpkHHKveAwe:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: Warren Parad , torsten@lodderstedt.net Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, Torsten Lodderstedt , oauth References: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com> Date: Mon, 8 Feb 2021 17:13:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070309020105040506060909" X-CMAE-Envelope: MS4xfKdKA9CWRJktmSUyCCykJh8mhgzK9teGxW8g/Z5ndmmMmvLhMk3ZVVyXB11rAvXbdsAujgwhM0v6hOziHSKwd5ZpchQktrNfK0E/OaSlLpf2vr2GqD9S kK1jyIDvA+SZB85V8vW+x344vreiF39Atbzpgl5l7PcLlt0aFyNb6B4qJcVeX47oRLepJ/7Al1BGnEzINbPwO3nUjOZJtdybQBQrmInVhT/IKZHniSOkwVna XeYIjjBq6fYUJ4BVpVO3QA+PJ4Kz42b6XTBXgKeDJRzBUbgKmTyY4/KPA2UC+cBj7KvT8RUSgohrgT/G+zFyfBLawt4XPn/zl5TWCrQ7gcPziFbV+Xd9YO7R v6e7yKOmRVJgPobpK1bQzUyCdYVcSYhXZFxn5yweHj2Mg4P8ezQ= Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 15:13:37 -0000 This is a cryptographically signed message in MIME format. --------------ms070309020105040506060909 Content-Type: multipart/alternative; boundary="------------B9E0D63C747BB0E8075DB62F" Content-Language: en-US This is a multi-part message in MIME format. --------------B9E0D63C747BB0E8075DB62F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify. If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope" parameter: https://tools.ietf.org/html/rfc6749#section-5.1 RAR has a similar parameter: https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1 If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2= =2E2.2 If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes. https://tools.ietf.org/html/rfc7662#section-2.2 For instance "sub". OAuth 2.x in the relation between AS and client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this. Vladimir On 08/02/2021 11:07, Warren Parad wrote: > It doesn't work that way. You suggested to add language to the draft, > that means the burden of proof is on you to justify adding it. > > Otherwise I could just say why not? > > And I can go stronger, what's the purpose of nho introspection > endpoint at all, and why encourage sending access tokens to the AS? > > Even if you can justify access tokens, there currently isn't evidence > provided why we should explicity discourage. > > > On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt > > wrote: > > > >> Am 08.02.2021 um 00:56 schrieb Warren Parad > >: >> >> =EF=BB=BF >> >> I=E2=80=98m therefore leaning towards explicitly stating in ou= r draft >> that it is not intended to be used with refresh tokens. >> >> I'm not following, why explicitly state that it isn't intended. >> If an AS wants to provide a similar JSON response to a query with >> the refresh token, why not encourage that? > > Why should we encourage it?=C2=A0 > >> >> =09 >> >> Warren Parad >> >> Founder, CTO >> >> Secure your user data and complete your authorization >> architecture. Implement=C2=A0Authress >> . >> >> >> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt >> > > wrote: >> >> Hi Andrii, >> >>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >>> >:= >>> >>> =EF=BB=BF >>> Hi=C2=A0Torsten, >>> >>> thank you for your response. >>> >>> My use case is pretty straight=C2=A0forward >>> >>> An OAuth client queries the AS to determine the active state >>> of an access token and gets the introspection response which >>> indicates that this access token is active (using RFC7662). >>> >>> An OAuth client queries the AS to determine the active state >>> of a refresh token and gets the introspection response which >>> indicates that this refresh token is active (using RFC7662). >>> >>> An OAuth client queries the AS to determine the active state >>> of an access token and gets the introspection response (JWT) >>> which indicates that this access token is active (using this >>> draft). >>> >>> Now, an OAuth client queries the AS to determine the active >>> state of a refresh token (using this draft)... How will the >>> introspection response look like assuming that the client >>> provides the valid refresh token and technically, nothing >>> stops it from doing so. >> >> why should the state be provided as JWT?I think the plain >> JSON response is sufficient in that case.=C2=A0=C2=A0I also th= ink using >> token introspection for checking the state of a token from >> the client side has limited utility. The definitive decision >> is always made when the client tries to access a resource.=C2=A0= >> >> I=E2=80=98m therefore leaning towards explicitly stating in ou= r draft >> that it is not intended to be used with refresh tokens. >> >> best regards, >> Torsten. >> >>> >>> Regards, >>> Andrii >>> >>> >>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt >>> > >>> wrote: >>> >>> Hi Andrii, >>> >>> thanks for your post. >>> >>> The draft is intended to provide AS and RS with a >>> solution to exchange signed (and optionally encrypted) >>> token introspection responses in order to provide >>> stronger assurance among those parties. This is >>> important in use cases where the RS acts upon the >>> introspection response data and wants the AS to take >>> liability re the data quality. >>> >>> I=E2=80=99m not sure whether there are similar use cases = if a >>> client introspects a refresh token. What is your use case= ? >>> >>> best regards, >>> Torsten.=C2=A0 >>> >>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega >>> >> >: >>> > >>> > Hi WG, >>> > >>> > draft-ietf-oauth-jwt-introspection-response-10 states >>> that "OAuth 2.0 Token Introspection [RFC7662] specifies >>> a method for a protected resource to query an OAuth 2.0 >>> authorization server to determine the state of an access >>> token and obtain data associated with the access token." >>> which is true. Although, according to RFC7662, the >>> introspection endpoint allows to introspect a refresh >>> token as well. Hence, the question I have is how will a >>> token introspection response look like when the caller >>> provides a refresh token and sets the "Accept" HTTP >>> header to "application/token-introspection+jwt"? >>> > >>> > I expect there will be no differences, right? >>> > >>> > If so, I suggest to >>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "a resource= server" by "the caller" in >>> section 4 (Requesting a JWT Response) >>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "If the acce= ss token is invalid, >>> expired, revoked" by "If a given token is invalid, >>> expired, revoked" in section 5 (JWT Response) >>> > If not, my suggestion would be to clarify what the AS >>> should do when it asked to introspect the refresh token >>> in general and additionally, what should happen in the >>> same case based on the type of the caller from the AS's >>> point of view. >>> > >>> > Regards, >>> > Andrii >>> > >>> >> _______________________________________________ >> OAuth mailing 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 Vladimir Dzhuvinov --------------B9E0D63C747BB0E8075DB62F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify.

If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope" parameter:

https://tools.ietf.org/html/rfc6749#section-5.1=

RAR has a similar parameter:

https://tools.ietf.org/html/d= raft-ietf-oauth-rar-03#section-3.4.1

If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them.

https://tools.iet= f.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2

If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes.

https://tools.ietf.org/html/rfc7662#section-2.2=

For instance "sub". OAuth 2.x in the relation between AS and client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this.

Vladimir

On 08/02/2021 11:07, Warren Parad wrote:
It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it.

Otherwise I could just say why not?

And I can go stronger, what's the purpose of nho introspection endpoint at all, and why encourage sending access tokens to the AS?

Even if you can justify access tokens, there currently isn't evidence provided why we should explicity discourage.


On Mon, Feb 8, 2021, 03= :18 Torsten Lodderstedt <torsten@lodde= rstedt.net> wrote:


Am 08.02.2021 um 00:56 schrie= b Warren Parad <wparad@rhosys.ch>:<= br>
=EF=BB=BF
I=E2=80=98m th= erefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.
I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that?

Why should we encourage it?=C2=A0


<= span style=3D"border:none;display:inline-block;overflow:hidden;width:199p= x;height:34px">=

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Sun, Feb= 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dm= arc.ietf.org> wrote:
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi=C2=A0Torsten,

thank you for your response.

My use case is pretty straight=C2=A0for= ward

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).

Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.=C2=A0=C2=A0I also think using t= oken introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource.=C2=A0

I=E2=80=98m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.


Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <to= rsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality.

I=E2=80=99m not sure whether = there are similar use cases if a client introspects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <an= drii.deinega@gmail.com>:
>
> Hi WG,
>
> draft-ietf-oauth-jwt-introspe= ction-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/token-introspect= ion+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =E2=80=A2 replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response) >=C2=A0 =C2=A0 =C2=A0 =C2=A0= =E2=80=A2 change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
>
> Regards,
> Andrii
>

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

____________________________=
___________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
--------------B9E0D63C747BB0E8075DB62F-- --------------ms070309020105040506060909 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMDgxNTEzMzFaMC8G CSqGSIb3DQEJBDEiBCDCTJBZhugKUNjhal+0y/xH7bLC7I/idvo7lLeatFkWTDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAA7n232pwDP0pphzmPjtek6a9Guyq/ZV4D7uRn4cQjShQdKO yXwpqPpDJ/WlIQlOjetxwRJbZep5SpRwAsaqMkCX4r8Zbz+HUKoQyNY8nk5dhFIecJO332F+ 9ob7MfZbYnv30cfLMnuSCLKNz5I5W/DZDukGHIabCqbNB04VJ2KCbNRwFimA4FELdWPws++9 mXK7EKj6lwlUYO8n8DisgwjXPGsn1N+uTPCSAc52XCowPk55fvJ5Dgh2g4Iuk9ZKbspmKp9B WGN97rV5pXvgLQJZnKM+EXSyJ2leuUNJQYjtBfl3PNbkNW6EOlfRGV0UgUJnrXsEXAhAvgLB tocqOVkAAAAAAAA= --------------ms070309020105040506060909-- From nobody Mon Feb 8 08:00:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B927C3A10E6 for ; Mon, 8 Feb 2021 08:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhhCz0oNp_ar for ; Mon, 8 Feb 2021 07:59:59 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8B83A10E4 for ; Mon, 8 Feb 2021 07:59:59 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id f6so15486921ioz.5 for ; Mon, 08 Feb 2021 07:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+DWucPBhygW12HqQsn3czO2ypyEqRbrB9yLRVHOEFb4=; b=TcGeHnzYMa1u/XQ01G1tSuFqjoU/vyfW56k44VapKujzTh2Fhc0/mr0r7YB9iQ0CjA GBnqdK+aon2wnY8yhqs4EW+S30wa/xqvTMln2q+mQ4CeVzM1JaPKaKrDgKjL7aIF/Ln9 EOx9wQdubKoGkNsHyGxTeK7fpnKvtBUDwdcbIuqcL8lchlC03gKUMFex6wrkTFHyfyKF Ld9pT5+x6tfHYODs5N2ohrxlhEeQoKS1Hc+lhdEvRhwoLvb3XCh3xy7jCiumz4MWqMBb X38VTEbO/lUr363HpmiWZdUeYC3jXbdenR9SwVF1OjHxu61YH3dYl7edz3u797Curcj8 5qzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+DWucPBhygW12HqQsn3czO2ypyEqRbrB9yLRVHOEFb4=; b=dGwwbydC51Qs3F2TNaZEb4H3WzVQaBCdK1SVGurPGANT45ugQaRYIpraUz5p/aww/K gTJ0ng1U5gHYPEPT7mypRNcRGj3AKtposqpo5ga0LNqJF/9Ay7ce4gZg3oU2DoUSwwR2 v3R3g97OtL0qYzhfeFU0EnSd6cxjg3Ku6PvRwZGAGsLc1iFUOELspDs/Glx9QzfzhfPD r3BYd1/CinRx8EdRUQGjtV6bq53QA7lcFK42ES7RaNs0wxjL42GVcE618XW/qBZz8Xad 6GU44SsajyFjp6GapM3wR9i/Yf3tJMKgZP9xEr7wTw4oUMYr5r40MPaacZgxNl/RBwG4 Zmzw== X-Gm-Message-State: AOAM533mBlgT4qTsYS02LraDR+794T6G18+VRrH/fPwiykneNb7vWOuD j1rljw4b6kmNEZUvNFflmd1lEUbypBRVLiSYI0Bg X-Google-Smtp-Source: ABdhPJxFOwEuaG1RtZ9IH0uWD4CSg/SbFCgKUsD/rkyVzCuKUvYLGHtcC8/XOCVD1uYjz7h48DSVJEhsPk7R6ZJ4kuE= X-Received: by 2002:a05:6638:164c:: with SMTP id a12mr18318633jat.128.1612799998835; Mon, 08 Feb 2021 07:59:58 -0800 (PST) MIME-Version: 1.0 References: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com> In-Reply-To: <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com> From: Warren Parad Date: Mon, 8 Feb 2021 16:59:47 +0100 Message-ID: To: Vladimir Dzhuvinov Cc: Torsten Lodderstedt , draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000000658dd05bad543aa" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 16:00:03 -0000 --0000000000000658dd05bad543aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable None of that justified explicitly stating that refresh token introspection shouldn't be done. At best it suggests that we should explicitly add language in the draft to directly encourage it. But if an AS wants to support it, we shouldn't stop them, or suggest that they can't do it. Allowing refresh tokens to be introspected can also create a conflict with > the sec recommendation to rotate them Not following, can you explain this further? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov wrote: > At first it may appear that allowing refresh tokens at the introspection > endpoint may be a logical thing to do, but in practice there are issues > with that and from an OAuth 2.x perspective it's not easy to justify. > > If the point is to let clients check what authorization they have been > given OAuth 2.0 already provides a std way to do that - in the access tok= en > response - the "scope" parameter: > > https://tools.ietf.org/html/rfc6749#section-5.1 > > RAR has a similar parameter: > > https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1 > > If the point is to find if a refresh token is still valid - this can be > found out by simply using it. Allowing refresh tokens to be introspected > can also create a conflict with the sec recommendation to rotate them. So > thus it may be a better idea to not let clients assume too much about the= m. > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2= .2.2 > > If the AS is going to expose refresh token data to a client it will also > have to make a careful judgement what data it exposes. > > https://tools.ietf.org/html/rfc7662#section-2.2 > > For instance "sub". OAuth 2.x in the relation between AS and client > actually has no concept or definition of subject / end-user identifier. A= nd > this is done for a good reason, because it's not a user authentication > protocol. OIDC was designed for that. And to prevent tracking of users an= d > other privacy issues OIDC also specifies pairwise subject IDs. The plain > OAuth 2.x world doesn't have this. > > Vladimir > On 08/02/2021 11:07, Warren Parad wrote: > > It doesn't work that way. You suggested to add language to the draft, tha= t > means the burden of proof is on you to justify adding it. > > Otherwise I could just say why not? > > And I can go stronger, what's the purpose of nho introspection endpoint a= t > all, and why encourage sending access tokens to the AS? > > Even if you can justify access tokens, there currently isn't evidence > provided why we should explicity discourage. > > > On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt > wrote: > >> >> >> Am 08.02.2021 um 00:56 schrieb Warren Parad : >> >> =EF=BB=BF >> >>> I=E2=80=98m therefore leaning towards explicitly stating in our draft t= hat it is >>> not intended to be used with refresh tokens. >> >> I'm not following, why explicitly state that it isn't intended. If an AS >> wants to provide a similar JSON response to a query with the refresh tok= en, >> why not encourage that? >> >> >> Why should we encourage it? >> >> >> Warren Parad >> >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress >> >> . >> >> >> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt > 40lodderstedt.net@dmarc.ietf.org> wrote: >> >>> Hi Andrii, >>> >>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >> >: >>> >>> =EF=BB=BF >>> Hi Torsten, >>> >>> thank you for your response. >>> >>> My use case is pretty straight forward >>> >>> An OAuth client queries the AS to determine the active state of an >>> access token and gets the introspection response which indicates that t= his >>> access token is active (using RFC7662). >>> >>> An OAuth client queries the AS to determine the active state of a >>> refresh token and gets the introspection response which indicates that = this >>> refresh token is active (using RFC7662). >>> >>> An OAuth client queries the AS to determine the active state of an >>> access token and gets the introspection response (JWT) which indicates >>> that this access token is active (using this draft). >>> >>> Now, an OAuth client queries the AS to determine the active state of a >>> refresh token (using this draft)... How will the introspection response >>> look like assuming that the client provides the valid refresh token and >>> technically, nothing stops it from doing so. >>> >>> >>> why should the state be provided as JWT?I think the plain JSON response >>> is sufficient in that case. I also think using token introspection for >>> checking the state of a token from the client side has limited utility.= The >>> definitive decision is always made when the client tries to access a >>> resource. >>> >>> I=E2=80=98m therefore leaning towards explicitly stating in our draft t= hat it is >>> not intended to be used with refresh tokens. >>> >>> best regards, >>> Torsten. >>> >>> >>> Regards, >>> Andrii >>> >>> >>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> Hi Andrii, >>>> >>>> thanks for your post. >>>> >>>> The draft is intended to provide AS and RS with a solution to exchange >>>> signed (and optionally encrypted) token introspection responses in ord= er to >>>> provide stronger assurance among those parties. This is important in u= se >>>> cases where the RS acts upon the introspection response data and wants= the >>>> AS to take liability re the data quality. >>>> >>>> I=E2=80=99m not sure whether there are similar use cases if a client >>>> introspects a refresh token. What is your use case? >>>> >>>> best regards, >>>> Torsten. >>>> >>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega < >>>> andrii.deinega@gmail.com>: >>>> > >>>> > Hi WG, >>>> > >>>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth 2.= 0 >>>> Token Introspection [RFC7662] specifies a method for a protected resou= rce >>>> to query an OAuth 2.0 authorization server to determine the state of a= n >>>> access token and obtain data associated with the access token." which = is >>>> true. Although, according to RFC7662, the introspection endpoint allow= s to >>>> introspect a refresh token as well. Hence, the question I have is how = will >>>> a token introspection response look like when the caller provides a re= fresh >>>> token and sets the "Accept" HTTP header to >>>> "application/token-introspection+jwt"? >>>> > >>>> > I expect there will be no differences, right? >>>> > >>>> > If so, I suggest to >>>> > =E2=80=A2 replace "a resource server" by "the caller" in secti= on 4 >>>> (Requesting a JWT Response) >>>> > =E2=80=A2 change "If the access token is invalid, expired, rev= oked" by >>>> "If a given token is invalid, expired, revoked" in section 5 (JWT Resp= onse) >>>> > If not, my suggestion would be to clarify what the AS should do when >>>> it asked to introspect the refresh token in general and additionally, = what >>>> should happen in the same case based on the type of the caller from th= e >>>> AS's point of view. >>>> > >>>> > Regards, >>>> > Andrii >>>> > >>>> >>>> _______________________________________________ >>> 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 > > -- > Vladimir Dzhuvinov > > --0000000000000658dd05bad543aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
None of that justified explicitly stating that refresh tok= en introspection shouldn't be done. At best it suggests that we should = explicitly add language in the draft to directly encourage it. But if an AS= wants to support it, we shouldn't stop them, or suggest that they can&= #39;t do it.

Allowing refresh tokens to be introspected can also create a conflic= t with the sec recommendation to rotate them

Not following, can you explain this further?

=
Secure your user data and complete your = authorization architecture. Implement=C2=A0Authress.


On Mo= n, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify.

If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope" parameter:

https://tools.ietf.org/html/rfc6749#section-5.1

RAR has a similar parameter:

https://tools.ietf.org/html/draft-ietf-oauth-ra= r-03#section-3.4.1

If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them.

https://tools.ietf.org/html/draft-i= etf-oauth-security-topics-16#section-2.2.2

If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes.

https://tools.ietf.org/html/rfc7662#section-2.2

For instance "sub". OAuth 2.x in the relation between AS a= nd client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not = a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this.

Vladimir

On 08/02/2021 11:07, Warren Parad wrote:
=20
It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it.

Otherwise I could just say why not?

And I can go stronger, what's the purpose o= f nho introspection endpoint at all, and why encourage sending access tokens to the AS?

Even if you can justify access tokens, there currently isn't evidence provided why we should explicity discourage.


On Mon, Feb 8, 2021, 03:1= 8 Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


Am 08.02.2021 um 00:56 schrieb Warren Parad <wparad@rhosys.ch>:

=EF=BB=BF
I= =E2=80=98m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.
I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that?

Why should we encourage it?=C2=A0


Warren Parad

Founder, CTO

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0= Authress.


On Sun, Feb 7= , 2021 at 10:58 PM Torsten Lodderstedt <torsten=3D40lodderst= edt.net@dmarc.ietf.org> wrote:
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi=C2=A0Torsten,

thank you for your response.

My use case is pretty straight=C2=A0forwa= rd

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).

Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.=C2=A0=C2=A0I also think using tok= en introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource.=C2=A0

I=E2=80=98m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.


Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality.

I=E2=80=99m not sure whether th= ere are similar use cases if a client introspects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>:
>
> Hi WG,
>
> draft-ietf-oauth-jwt-introspect= ion-response-10 states that "OAuth 2.0 Tok= en Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which i= s true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTT= P header to "application/token-introsp= ection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =E2=80=A2 replace "a resource server" by "= the caller" in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =E2=80=A2 change "If the access token is invalid, expired, revoked" by "= ;If a given token is invalid, expired, revoked" in secti= on 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
>
> Regards,
> Andrii
>

_______________________________________________
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

--=20
Vladimir Dzhuvinov
--0000000000000658dd05bad543aa-- From nobody Mon Feb 8 08:03:14 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC23A10BA for ; Mon, 8 Feb 2021 08:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nwHGebFTZor for ; Mon, 8 Feb 2021 08:03:11 -0800 (PST) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12DC3A10E8 for ; Mon, 8 Feb 2021 08:03:11 -0800 (PST) Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 990HlxIGCw5Jf990HlRyik; Mon, 08 Feb 2021 09:03:10 -0700 X-CMAE-Analysis: v=2.4 cv=X62XlEfe c=1 sm=1 tr=0 ts=602160be a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=O7ycHR8boHRv27uBlEwA:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=nak9Ox0lsa0-jk66YjIA:9 a=216G3L1HtJXoGbrs:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: <40a89ab4-04ca-e494-638c-db149e046afd@connect2id.com> Date: Mon, 8 Feb 2021 18:03:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050304000102030505030502" X-CMAE-Envelope: MS4xfERgXj7uEwKyHNT/spE+n/A3TkqamwaPblbuUhfOiAiFgSXPsmdUcMFhLTw9ZeMYE2ITLWJkUosgXYQ1JWHHsEXOdNEpwxhWY7o8M0hw8G+yyfU1VYZd 8fCAZC2LFEPguiTHDfvaXhZI54bjkXbHaEgvJxrA+lk2rFwI2MHUDjmZKOaNaWsSiKeGhX3wZ+ugtw== Archived-At: Subject: Re: [OAUTH-WG] oauth-jwt-introspection-response and RFC 7797 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 16:03:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050304000102030505030502 Content-Type: multipart/alternative; boundary="------------2D9E00F12A2FDFA3586993AD" Content-Language: en-US This is a multi-part message in MIME format. --------------2D9E00F12A2FDFA3586993AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andrii, The unencoded payload JWS from RFC 7797 appears to be harder to get right. Web frameworks can for instance make serialization and parsing of JSON and text in general in HTTP unpredictable or difficult to control. A single \n introduced at the end of the body can for instance break the signature (been in one such situation). Incorrectly set charsets can also cause issues. To mitigate this there has been an effort to canonicalize JSON. Also note that the JSON payload of the signed introspection response is not a 1:1 copy of the RFC 7662 token introspection response. It includes claims outside the token_introspection container - iss, aud and iat. So where will they go and how is the signature going to include them as well= ? There's also the issue with encryption - we don't have a standard way of doing JWE over an RFC 7797 style signed text yet. Vladimir On 07/02/2021 11:56, Andrii Deinega wrote: > Hi WG. > > draft-ietf-oauth-jwt-introspection-response-10 proposes to return > signed JWTs as a response from the introspection endpoint... which is > making me=C2=A0wonder if there are any particular reasons to not avail = JSON > Web Signature (JWS) Unencoded Payload Option (RFC 7797) and the > X-JWS-SIGNATURE HTTP header in order to achieve the same goals? > > Pros would be > > 1. a token introspection response remains to be exactly the same as > it was before with an exception for a JWT in the X-JWS-SIGNATURE > HTTP header (where a detached payload is the actual token > introspection response) > 2. the AS can safely enable it for all responses from the > introspection endpoint so clients who don't require or just aren't > aware of this header will continue to work as before and > accordingly, the clients who require some stronger assurance will > require=C2=A0and check a JWT in=C2=A0X-JWS-SIGNATURE HTTP header > 3. the same approach could also work for other endpoints such as the > revocation and OIDC UserInfo endpoints > > What=C2=A0do you think? > > Regards, > Andrii > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------2D9E00F12A2FDFA3586993AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Andrii,

The unencoded payload JWS from RFC 7797 appears to be harder to get right. Web frameworks can for instance make serialization and parsing of JSON and text in general in HTTP unpredictable or difficult to control. A single \n introduced at the end of the body can for instance break the signature (been in one such situation). Incorrectly set charsets can also cause issues. To mitigate this there has been an effort to canonicalize JSON.

Also note that the JSON payload of the signed introspection response is not a 1:1 copy of the RFC 7662 token introspection response. It includes claims outside the token_introspection container - iss, aud and iat. So where will they go and how is the signature going to include them as well?

There's also the issue with encryption - we don't have a standard way of doing JWE over an RFC 7797 style signed text yet.

Vladimir

On 07/02/2021 11:56, Andrii Deinega wrote:
Hi WG.

draft-ietf-oauth-jwt-introspection-response-10 proposes to return signed JWTs as a response from the introspection endpoint... which is making me=C2=A0wonder if there are any particular reasons to not avail JSON Web Signature (JWS) Unencoded Payload Option (RFC 7797) and the X-JWS-SIGNATURE HTTP header in order to achieve the same goals?

Pros would be
  1. a token introspection response remains to be exactly the same as it was before with an exception for a JWT in the X-JWS-SIGNATURE HTTP header (where a detached payload is the actual token introspection response)
  2. the AS can safely enable it for all responses from the introspection endpoint so clients who don't require or just aren't aware of this header will continue to work as before and accordingly, the clients who require some stronger assurance will require=C2=A0and check a JWT in=C2=A0X-JWS-SIG= NATURE HTTP header
  3. the same approach could also work for other endpoints such as the revocation and OIDC UserInfo endpoints
What=C2=A0do you think?

Regards,
Andrii


____________________________=
___________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
--------------2D9E00F12A2FDFA3586993AD-- --------------ms050304000102030505030502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMDgxNjAzMDlaMC8G CSqGSIb3DQEJBDEiBCCyrkWK0LGWlBFKSmnsQF97nrYFXQV5+Bx3IPv7JrUGvzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBALMafcxS6cz2Dnby7d5qs4cX7BA9M8O5peLLtI57qnYMijNe EdnWQDCC4uQaZe6sAo1c1yD+kj59TU3E8mf9xjkmK399IF8y2OWFhc9OXOZVlNXpzeMrqpNp 4jJy7r54v18Y++2p/dk2n8glMRryDXf2SVA1M8Dgodoe7NL4TjF0yQNJXir2Q6/8pUcTic+Q oHMT3Nm8HlUXwbdByFLOB6Ak4XptITSYNKP8QdJii3AQvJqO/f/DxO+w52oi7FmTnt84FmD0 l3U4V+y4y11CSmZ88bRmyJyoxiwKmGvl1EEVAmk3m6Guqe2qq+s/GriZFea7GrXrSEFHNf5j R8yJ9EQAAAAAAAA= --------------ms050304000102030505030502-- From nobody Mon Feb 8 22:55:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65C93A1183; Mon, 8 Feb 2021 22:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCwqF_EVqlnp; Mon, 8 Feb 2021 22:55:40 -0800 (PST) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396FF3A1176; Mon, 8 Feb 2021 22:55:39 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id sa23so29679667ejb.0; Mon, 08 Feb 2021 22:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=C7R1xLeZmI8japrShi58F4YHG5Y/KuQTBAy3EPnVq7Q=; b=KfAN5wy21p8ftZL9JTLU9vqLkvBFXDIWVgMTVkdl6z+0xfPS1LjX95FuYkHTBHMj8l GzrqNorjlKa3OnURwkM4/+VDkTdmdCEfKxrcCJ4TlXLIMSPmVTuuGfUtn4RZxXdv/EWL vwJQ4npfRie7N+FGh6jWEC2tZ2L1kqPvR5ukWBuizPv+z5mlJ4vzCZU2UJ3X76+FAsfW KmeDsHxr3ml7uM83AqNyt4ZPUrz9PNVzTaMIOdcP5IJ4mvOp7k0KrEu5NurPk0JN9Af+ Y6/X8Ne06mCGFTpyhag0BZ1m6WnUUEZw2y8OX9Rbe7p1BhdN3jD+XOS+pyCLnKvWL4Qd l5FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C7R1xLeZmI8japrShi58F4YHG5Y/KuQTBAy3EPnVq7Q=; b=eV84m78kJt2lnP3hLuyEpc7QwejDmsHh+AoIZPLFMmnB9yL+BvBktQcFTB0Doxuuso 5smNGbtQsmJbw32hJUdW6EKPuUCSp7gsTAvpaHS8nsTtPJHSZ19cLRM7UkoIVafnHxfu cROk0bzBuk/5M2+Rrt9u3r0Hcgpb5WN4WpIYs3V75e8oIGTalR0v0p1Wr1RrE/ZHMWyH fdoLJyUWSJRAz81PH0Ww5z8xGdDHHHNK+51mE+h+n2N2y1a+wPXBWETRv//D38WrICFG ykuM0B8Svjye9HaUFlmch4/BFyY3qc8wMp8o0umIkSq+P8Jf0DfWhH38SayWze7EY24n xrJw== X-Gm-Message-State: AOAM532aoLPZ1LHDUZEzLU/AVEuy5FPLFKWC+9OkBqWhouc6P6ASjMR+ EJtFXMg76FH08CxCCEexyug4xUYj7tsEcV8rWlsbzTcxw6s= X-Google-Smtp-Source: ABdhPJwqHcFAlHnJaPBts3cu2sZKsG5pDu5vP2oNMnLMDjPMwqdhKZGJoSp8pwpTgKho64kYREhPAbfjir81KpZ6iF0= X-Received: by 2002:a17:906:259a:: with SMTP id m26mr21173627ejb.399.1612853738364; Mon, 08 Feb 2021 22:55:38 -0800 (PST) MIME-Version: 1.0 From: Andrii Deinega Date: Mon, 8 Feb 2021 22:55:27 -0800 Message-ID: To: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="0000000000002661c405bae1c60e" Archived-At: Subject: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 06:55:43 -0000 --0000000000002661c405bae1c60e Content-Type: text/plain; charset="UTF-8" Hi WG, I wonder if there are any particular reasons to not make nonce a mandatory parameter for the current JWT Response for OAuth Token Introspection draft. Or, at least, force an AS to include the nonce claim in a JWT response when nonce is presented in the introspection request similar to what happens with the similar scenario in the OpenID Connect ID Token? https://openid.net/specs/openid-connect-core-1_0.html#:~:text=If%20present%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Authentication%20Request. This will allow to mitigate replay attacks because clients can correlate the response with the initial request. Regards, Andrii --0000000000002661c405bae1c60e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

I wonder if there are any particular reasons= to not make nonce a mandatory parameter for the current JWT Response for O= Auth Token Introspection draft. Or, at least, force an AS to include the no= nce claim in a JWT response when nonce is presented in the introspection re= quest similar to what happens with the similar scenario in the OpenID Conne= ct ID Token?

https://openid.net/spec= s/openid-connect-core-1_0.html#:~:text=3DIf%20present%20in%20the%20Authenti= cation%20Request%2C,value%20sent%20in%20the%20Authentication%20Request.=

This will allow to mitigate replay attacks=C2=A0be= cause clients can correlate the response with the initial request.

Regards,
Andrii


--0000000000002661c405bae1c60e-- From nobody Tue Feb 9 00:44:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0C3A0D62 for ; Tue, 9 Feb 2021 00:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NXfwxyZQiqC for ; Tue, 9 Feb 2021 00:43:57 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E9C3A0D25 for ; Tue, 9 Feb 2021 00:43:57 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id a16so1238899wmm.0 for ; Tue, 09 Feb 2021 00:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=YvzG5Ua8DK3HSBf4ppxnWV7zVlbyyawHIq5jV0YIGsE=; b=aUoQPA663Kc22qhM4cJaeg4gk0UzXhAaZbQHSN23CnIsCWmgMZiHWYWqXU7l2jg8mX hRaQ+VwAjhMUtb9q2IrcxRRG3TP596LW4JIu2EBwLKUmAp/pBaNzMW6/Ohlv+poNZjPC 7cw7DK2RTFuK2CAVKHks9w+M/PALVlrzIFTyQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=YvzG5Ua8DK3HSBf4ppxnWV7zVlbyyawHIq5jV0YIGsE=; b=udqap/deEYIxMAUsFoCNT6U8nP7HQJ2hMfu1sG+i7c/MEN+jD4dHKXsGTKtpd2PtlT 5lk1mDpDYkdPRLd/BDeEr/QRtrM8oftqEbJK/VWAJN6Z0gPaUwOscKuODSvvKKA0uKJc cLIV6qnlfgiS+MpqZrHGDUAQpm4CgGaYIB499TCZw8G3/dwKgWesr6Fg4R4/ba2YYPxN C7hlqHdL2JZIxaDHEpjfl8LmuPcT1Pl4xXpsV9JMiAO+zR5in+ebn2jzcTKtiLIegMob 24F5G29eNkbDFZh1SUQCmSj7MmwcFODv3/taxO9EjM23wN8kzO7agvBv8Sj5mTTjcY6g VSsQ== X-Gm-Message-State: AOAM5321b9YKoVspbvMPJMiqbGoxWlMH2cvaTMdTB2BmHpMfKBKzdahb BXIDlVzP1XaS3/SM1sz7MIwjsaDjQBB+GGV0Ui0nzZDrxFcubm/nApTdCk7f8xKVASo6J5o0Fw= = X-Google-Smtp-Source: ABdhPJz8wzEH5wkHMatdLwjYkf2QZY1Y/s6v7nNYFZqTS6hTFpKguglRLZSGdQHXcqGFr2G1KqcssA== X-Received: by 2002:a05:600c:4ec7:: with SMTP id g7mr2323350wmq.56.1612860235347; Tue, 09 Feb 2021 00:43:55 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id g1sm33303815wrq.30.2021.02.09.00.43.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Feb 2021 00:43:55 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Tue, 9 Feb 2021 08:43:53 +0000 Message-Id: References: Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org In-Reply-To: To: Andrii Deinega X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-EA56D820-484D-4B52-AD83-4C3A0094E6EC Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 08:44:02 -0000 --Apple-Mail-EA56D820-484D-4B52-AD83-4C3A0094E6EC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 9 Feb 2021, at 06:55, Andrii Deinega wrote: >=20 > =EF=BB=BF > Hi WG, >=20 > I wonder if there are any particular reasons to not make nonce a mandator= y parameter for the current JWT Response for OAuth Token Introspection draf= t. Or, at least, force an AS to include the nonce claim in a JWT response w= hen nonce is presented in the introspection request similar to what happens= with the similar scenario in the OpenID Connect ID Token? >=20 > https://openid.net/specs/openid-connect-core-1_0.html#:~:text=3DIf%20pres= ent%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Auth= entication%20Request. >=20 > This will allow to mitigate replay attacks because clients can correlate = the response with the initial request ID tokens involve flows using an insecure channel (the browser). This is no= t the case for introspection requests which happen over a direct TLS connec= tion and so are already protected against replay attacks.=20 =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail-EA56D820-484D-4B52-AD83-4C3A0094E6EC Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 9 Feb 2021, at 06:5= 5, Andrii Deinega <andrii.deinega@gmail.com> wrote:

=EF=BB=BF
Hi WG,

I wonder if t= here are any particular reasons to not make nonce a mandatory parameter for= the current JWT Response for OAuth Token Introspection draft. Or, at least= , force an AS to include the nonce claim in a JWT response when nonce is pr= esented in the introspection request similar to what happens with the simil= ar scenario in the OpenID Connect ID Token?

https://openid.net/specs/openid-connect-core-1_0.html#:~:text=3DIf%= 20present%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%= 20Authentication%20Request.

This will allow to = mitigate replay attacks because clients can correlate the response wit= h the initial request

ID token= s involve flows using an insecure channel (the browser). This is not the ca= se for introspection requests which happen over a direct TLS connection and= so are already protected against replay attacks. 

=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail-EA56D820-484D-4B52-AD83-4C3A0094E6EC-- From nobody Tue Feb 9 01:57:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CF03A0D82 for ; Tue, 9 Feb 2021 01:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv7IF_vfZjzj for ; Tue, 9 Feb 2021 01:57:42 -0800 (PST) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176153A0D47 for ; Tue, 9 Feb 2021 01:57:42 -0800 (PST) Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 9Pm6lqohS06jR9Pm7lqDH3; Tue, 09 Feb 2021 02:57:40 -0700 X-CMAE-Analysis: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=60225c94 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=Wo1p0_sIAAAA:20 a=48vgC7mUAAAA:8 a=A1X0JdhQAAAA:8 a=JR3aLk_0Lp47AqYsvSAA:9 a=IeD2jsKuOu93BWtY:21 a=Rt5cFkbOw895cxyp:21 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 a=jGqiy6jZAAAA:8 a=PMt0SfQCIEJMTvNWhfMA:9 a=Aazfm-kxexYvZmxB:21 a=JiRLk17tKzU3IRD7:21 a=Adz7Y9YshWs3vJFl:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=jHrLhlbFqA1ZHZAWynec:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: Benjamin Kaduk , The IESG Cc: draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, Rifaat Shekh-Yusef References: <161172193850.26768.7940243594405897258@ietfa.amsl.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Tue, 9 Feb 2021 11:57:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <161172193850.26768.7940243594405897258@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030005030707000403080401" X-CMAE-Envelope: MS4xfN3PbmzdsW4k4DmOJKfM6sq87EXUmvvk4erRl93SaEvtRJdd9dOiSac3Ne0+QTTVn7YHA4NqKMKmhsAYJE86ci7mq6n8EMWKuAJTjh6CwgeUG1MZM5Zc 3jPvQizTiOJ5etZFUOSPSOvO6yqZo7Z8rKA+PetiiaJoIc2h871Ei0iJZtgo1I2GDjRBtiISzsI/uWskgOaQhjaUXbGL+bQd9ZOERQdQbLEw4NDWRFj4zQH9 dgfYg4q35dljASppP5Geqk8eq97OlDkFXx9t0zh9UBxkKNOdDZ82b6nvHkspIlzNNhuBLjgPlIYheRQTxlbc9XwWhZQRCieniYpMQaKHWMSQrR5kcas71ayA Jxdw8SiW4Y2eNOMu52Gdeiej3WWZlA== Archived-At: Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-introspection-response-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 09:57:45 -0000 This is a cryptographically signed message in MIME format. --------------ms030005030707000403080401 Content-Type: multipart/alternative; boundary="------------5CB0AB618AE7AEA098D67B1C" Content-Language: en-GB This is a multi-part message in MIME format. --------------5CB0AB618AE7AEA098D67B1C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Benjamin, Thanks a lot for your comments. We discussed them and applied several changes to the draft to address the= m. Those changes can be previewed here: https://github.com/oauthstuff/draft-ietf-oauth-jwt-introspection-response= /compare/address-comments-benjamin-kaduk-2021-01-26 Further comments inline: On 27/01/2021 06:32, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-oauth-jwt-introspection-response-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-res= ponse/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > We've made a lot of progress at unravelling the gnarly issues relating > to merging the introspection response and JWT claims namespaces, which > is good. That said, I'd still like to discuss a little bit more the > behavior described in Section 5, where the "token_introspection" claim > in the response can also contain JWT claims (''' In addition, claims > from the JSON Web Token Claims registry [IANA.JWT] established by > [RFC7519] MAY be included as members in the "token_introspection" > claim.''') That seems to be granting carte blanche to do the thing tha= t > was deemed problematic, i.e., mix the namespaces. As such, the current= > formulation in the document, in the general case of independent > uncoordinated implementations, seems to admit the prospect of an AS > adding something to an introspection response under the guise of the JW= T > claim exception that is interpreted by the recipient RS as a new > introspection response parameter (or, I think, vice versa). Yes, this > would require conflicting registrations to occur, but we still don't > have a procedure in place that would prevent such conflicting > registrations from occurring in the future. How can we add some > low-cost safety controls that mitigate the risk while still enabling th= e > desired functionality? > > I have a couple thoughts on this: there is already an exception for > implementation/service-specific (unregistered) claims in the > introspection response, which could apply to JWT claims under the same > requisite conditions of administrative control, if that's going to cove= r > the scenarios in question. One could also imagine a new registration > procedure for introspection response parameters whereby (for example) > any non-conflicting value already registered as a JWT claim can be > mechanically propagated into the introspection response registry > potentially just by IANA without even expert review. Then we would jus= t > require the contents to be registered introspection response parameters= , > and someone who wants to use JWT claims can trivially get them > registered before using them. To recap, the moving of the RFC 7662 response parameters into a token_introspection claim was to keep the JWT-specific claims - iss, iat, aud (RFC 7519) and the introspection parameters nicely separated and thus prevent potential conflicts / confusion between them. Speaking of the token introspection parameters, it was identified that certain applications need to obtain additional attributes related to the resource owner, besides the need to have the introspection response signed. For those attributes there happen to be suitable claims, such as email, name, etc., already registered in the JWT IANA registry, and it may make sense to reuse those names. Those are names from OpenID Connect intended to be used inside ID tokens and UserInfo JWTs. We updated the draft to state that when such claims get included, care must be taken. > selected claims from the JSON Web Token Claims registry established by > RFC7519 MAY be included as members in the token_introspection claim, > provided their names don't collide with OAuth Token Introspection > Response registry claims and care is taken to prevent other potential > conflicts and ambiguity.=20 In OpenID Connect there is a certain allowance for mixing claims from two "namespaces", for example in ID tokens which may include claims about the end-user besides those that are defined for the ID token itself. What helps here is having clear indication in the IANA JWT registry what the originating spec for a claim name is. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm not balloting this at a DISCUSS-level, because it may just be me > failing to understand the intended meaning (or being forgetful), but I'= m having a hard time > seeing how we're self-consistent about the requirement for an RS to > authenticate and authorize a given RS for a given introspection > transaction. In particular, in Section 3 we see that "the authorizatio= n > server MUST be able to identify, authenticate and authorize resource > servers" and that "[t]he authorization server MUST be able to determine= > whether an RS is the audience for a particular access token and what > data it is entitled to receive, otherwise the RS is not authorized to > obtain data for the access token". While I see that there is also some= > discussion about using the "scope" parameter of the token being > introspected as an indicator of the RS it is to be used for (and thus > the identity of the RS that would legitimately be making an > introspection request), and I also see discussion of using an encrypted= > introspection response as a way to ensure that the contents are only > viewable by the intended RS, I'm not sure how clearly either (or both) > mechanisms constitute "authentication" of the introspection request. > Since we already require a "strong two-way trust relationship", it's no= t > clear to me that it would be difficult to strongly authenticate the > actual introspection request itself or that there is much gained by > skipping such a check in favor of other mechanisms. Several of my > inline comments touch on this topic (on the assumption that there is a > strong MUST for strong authentication); I left them in place to benefit= > from the context of where they appear, rather than constructing a > laundry list of all of them. That said, it will suffice to explain how= > I'm wrong/confused just once; there's no need to repeat it at each plac= e > I bring up the topic. The draft was updated to make the MUST requirement for client authentication consistent. Originally, the intent was to allow for RFC 7662 style behaviour alongside the JWT response style, but as you pointed out there are issues with that, and it was dropped entirely. > > Section 3 > > To support encrypted token introspection response JWTs, the > authorization server MUST also be provided with the respective > resource server encryption keys and algorithms. > > That seems more of a descriptive than a normative "must", to me. The section was updated to > The authorization server MAY additionally encrypt the token > introspection response JWTs. If encryption is used the authorization > server is provisioned with encryption keys and algorithms for the RS. > > Section 4 > > A resource server requests a JWT introspection response by including= > an "Accept" HTTP header "application/token-introspection+jwt" in the= > introspection request. > > nit: "header field". and probably also something about "containing" or > "with body". Fixed. > > The AS SHOULD authenticate the caller at the token introspection > endpoint. Authentication can utilize client authentication methods > or a separate access token issued to the resource server. Whether a= > resource server is required to authenticate is determined by the > respective RS-specific policy at the AS. > > I don't think this can be only a SHOULD-level requirement and be > consistent with the MUST-level requirements in the previous section > (most notably, "[AS] MUST be able to determine whether an RS is the > audience for a particular access token". It is hard to believe that an= > unauthenticated RS could have such authorization. The draft was updated to make this consistent everywhere. We now have: > The AS MUST authenticate the caller at the token introspection > endpoint. Authentication can utilize client authentication methods or > a separate access token issued to the resource server and identifying > it as subject. > > The following is a non-normative example request with client > authentication: > > POST /introspect HTTP/1.1 > Host: as.example.com > Accept: application/token-introspection+jwt > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > (side note: "Authorization: Basic" makes me sad.) Updated the example for private_key_jwt authentication. > > Section 5 > > The introspection endpoint responds with a JWT, setting the "Content= - > Type" HTTP header to "application/token-introspection+jwt" and the > > nit: "header field" again. Fixed. > > If possible, the AS MUST narrow down the "scope" value to th= e > scopes relevant to the particular RS. > > What's the difference between "if possible, MUST" and " SHOULD"?= Edited to > The AS SHOULD narrow down the scope value to the scopes relevant to > the particular RS. > > The JWT MAY include other claims, including those from the "JSON Web= > Token Claims" registry established by [RFC7519]. The JWT SHOULD NOT= > include the "sub" and "exp" claims as an additional prevention > against misuse of the JWT as an access token (see Section 8.1). > > nit: I think a comma after "'exp' claims" would increase clarity. Thanks, fixed. > The JWT is cryptographically secured as specified in [RFC7662]. > > I think that this was intended to refer to 7519 (JWT), not 7662 > (introspection)? Thanks, the RFC ref was corrected. > > Depending on the specific resource server policy the JWT is either > signed, or signed and encrypted. If the JWT is signed and encrypted= > it MUST be a Nested JWT, as defined in JWT [RFC7519]. > > Note: If the resource server policy requires a signed and encrypted > > (nit?) Just to confirm: the "resource server policy" here is a policy > that's applied at the AS on a per-resource-server basis? If so, perhap= s > writing it "resource-server-specific policy" would clarify. Clarified as suggested. > > response and the authorization server receives an unauthenticated > request containing an "Accept" header with content type other than > "application/token-introspection+jwt", it MUST refuse to serve the > request and return an HTTP status code 400. This is done to prevent= > downgrading attacks to obtain token data intended for release to > legitimate recipients only (see Section 8.2). > > An unauthenticated request should be denied unconditionally, right? > Should this MUST apply to just requests containing the "Accept" header > (field) with other content-types? The section was rewritten to > Note: If the AS requires signed introspection responses for some or > all resource servers it MUST refuse to serve introspection requests > that don't authenticate the caller and return an HTTP status code 400. > This is done to prevent downgrading attacks to obtain token data > intended for release to legitimate recipients only (see > "token_data_leakage"). This greatly simplified things and allowed the security recommendations section to be shortened significantly. > > The example response JWT payload contains the following JSON > document: > [...] > "token_introspection": > { > [...] > "scope":"read write dolphin", > > Is there any chance the minimizer that was run on this payload as input= > to JWT generation also removed the spaces in the scope string? I seem > to be having some unexpected behavior from my local tooling, but it is > looking like the claims set from the example HTTP payload lists > "scope":"readwritedolphin". I'm not sure what the issue here is, but we'll keep an eye on the formatting of this example. > Section 8.2 > > To prevent introspection of leaked tokens and to present an > additional security layer against token guessing attacks the > authorization server MAY require all requests to the token > introspection endpoint to be authenticated. As an alternative or as= > an addition to the authentication, the intended recipients MAY be se= t > up for encrypted responses. > > Isn't this ("require all requests to be authenticated") also a MUST now= ? This section was removed entirely with the requirement to have all requests authenticated. The potential loophole of using a bearer access token for the introspection endpoint where the authorised subject is not identified (RFC 7662, section 2.2) is closed now. https://tools.ietf.org/html/rfc7662#section-2.2 Vladimir --=20 Vladimir Dzhuvinov --------------5CB0AB618AE7AEA098D67B1C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Benjamin,

Thanks a lot for your comments.

We discussed them and applied several changes to the draft to address them.

Those changes can be previewed here:

https://github.com/oauthstuff/draft-ietf-oa= uth-jwt-introspection-response/compare/address-comments-benjamin-kaduk-20= 21-01-26

Further comments inline:

On 27/01/2021 06:32, Benjamin Kaduk vi= a Datatracker wrote:
= 
Benjamin Kaduk has entered t=
he following ballot position for
draft-ietf-oauth-jwt-introspection-response-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/st=
atement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf=
=2Eorg/doc/draft-ietf-oauth-jwt-introspection-response/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

We've made a lot of progress at unravelling the gnarly issues relating
to merging the introspection response and JWT claims namespaces, which
is good.  That said, I'd still like to discuss a little bit more the
behavior described in Section 5, where the "token_introspection" claim
in the response can also contain JWT claims (''' In addition, claims
from the JSON Web Token Claims registry [IANA.JWT] established by
[RFC7519] MAY be included as members in the "token_introspection"
claim.''')  That seems to be granting carte blanche to do the thing that
was deemed problematic, i.e., mix the namespaces.  As such, the current
formulation in the document, in the general case of independent
uncoordinated implementations, seems to admit the prospect of an AS
adding something to an introspection response under the guise of the JWT
claim exception that is interpreted by the recipient RS as a new
introspection response parameter (or, I think, vice versa).  Yes, this
would require conflicting registrations to occur, but we still don't
have a procedure in place that would prevent such conflicting
registrations from occurring in the future.  How can we add some
low-cost safety controls that mitigate the risk while still enabling the
desired functionality?

I have a couple thoughts on this: there is already an exception for
implementation/service-specific (unregistered) claims in the
introspection response, which could apply to JWT claims under the same
requisite conditions of administrative control, if that's going to cover
the scenarios in question.  One could also imagine a new registration
procedure for introspection response parameters whereby (for example)
any non-conflicting value already registered as a JWT claim can be
mechanically propagated into the introspection response registry
potentially just by IANA without even expert review.  Then we would just
require the contents to be registered introspection response parameters,
and someone who wants to use JWT claims can trivially get them
registered before using them.

To recap, the moving of the RFC 7662 response parameters into a token_introspection claim was to keep the JWT-specific claims - iss, iat, aud (RFC 7519) and the introspection parameters nicely separated and thus prevent potential conflicts / confusion between them.

Speaking of the token introspection parameters, it was identified that certain applications need to obtain additional attributes related to the resource owner, besides the need to have the introspection response signed. For those attributes there happen to be suitable claims, such as email, name, etc., already registered in the JWT IANA registry, and it may make sense to reuse those names. Those are names from OpenID Connect intended to be used inside ID tokens and UserInfo JWTs.

We updated the draft to state that when such claims get included, care must be taken.

selected claims from the JSON Web Token Claims registry established by RFC7519 MAY be included as members in the token_introspection claim, provided their names don't collide with OAuth Token Introspection Response registry claims and care is taken to prevent other potential conflicts and ambiguity.

In OpenID Connect there is a certain allowance for mixing claims from two "namespaces", for example in ID tokens which may include claims about the end-user besides those that are defined for the ID token itself. What helps here is having clear indication in the IANA JWT registry what the originating spec for a claim name is.


= 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm not balloting this at a DISCUSS-level, because it may just be me
failing to understand the intended meaning (or being forgetful), but I'm =
having a hard time
seeing how we're self-consistent about the requirement for an RS to
authenticate and authorize a given RS for a given introspection
transaction.  In particular, in Section 3 we see that "the authorization
server MUST be able to identify, authenticate and authorize resource
servers" and that "[t]he authorization server MUST be able to determine
whether an RS is the audience for a particular access token and what
data it is entitled to receive, otherwise the RS is not authorized to
obtain data for the access token".  While I see that there is also some
discussion about using the "scope" parameter of the token being
introspected as an indicator of the RS it is to be used for (and thus
the identity of the RS that would legitimately be making an
introspection request), and I also see discussion of using an encrypted
introspection response as a way to ensure that the contents are only
viewable by the intended RS, I'm not sure how clearly either (or both)
mechanisms constitute "authentication" of the introspection request.
Since we already require a "strong two-way trust relationship", it's not
clear to me that it would be difficult to strongly authenticate the
actual introspection request itself or that there is much gained by
skipping such a check in favor of other mechanisms.  Several of my
inline comments touch on this topic (on the assumption that there is a
strong MUST for strong authentication); I left them in place to benefit
from the context of where they appear, rather than constructing a
laundry list of all of them.  That said, it will suffice to explain how
I'm wrong/confused just once; there's no need to repeat it at each place
I bring up the topic.

The draft was updated to make the MUST requirement for client authentication consistent.

Originally, the intent was to allow for RFC 7662 style behaviour alongside the JWT response style, but as you pointed out there are issues with that, and it was dropped entirely.


= 

Section 3

   To support encrypted token introspection response JWTs, the
   authorization server MUST also be provided with the respective
   resource server encryption keys and algorithms.

That seems more of a descriptive than a normative "must", to me.

The section was updated to

The authorization server MAY additionally= encrypt the token introspection response JWTs. If encryption is used the authorization server is provisioned with encryption keys and algorithms for the RS.


= 

Section 4

   A resource server requests a JWT introspection response by including
   an "Accept" HTTP header "application/token-introspection+jwt" in the
   introspection request.

nit: "header field". and probably also something about "containing" or
"with body".

Fixed.


= 

   The AS SHOULD authenticate the caller at the token introspection
   endpoint.  Authentication can utilize client authentication methods
   or a separate access token issued to the resource server.  Whether a
   resource server is required to authenticate is determined by the
   respective RS-specific policy at the AS.

I don't think this can be only a SHOULD-level requirement and be
consistent with the MUST-level requirements in the previous section
(most notably, "[AS] MUST be able to determine whether an RS is the
audience for a particular access token".  It is hard to believe that an
unauthenticated RS could have such authorization.

The draft was updated to make this consistent everywhere.

We now have:

The AS MUST authenticate the caller at th= e token introspection endpoint. Authentication can utilize client authentication methods or a separate access token issued to the resource server and identifying it as subject.



= 

   The following is a non-normative example request with client
   authentication:

   POST /introspect HTTP/1.1
   Host: as.example.com
   Accept: application/token-introspection+jwt
   Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

(side note: "Authorization: Basic" makes me sad.)

Updated the example for private_key_jwt authentication.


= 

Section 5

   The introspection endpoint responds with a JWT, setting the "Content-
   Type" HTTP header to "application/token-introspection+jwt" and the

nit: "header field" again.

Fixed.


= 

           If possible, the AS MUST narrow down the "scope" value to the
           scopes relevant to the particular RS.

What's the difference between "if possible, <X> MUST" and "<X>=
; SHOULD"?

Edited to

The AS SHOULD narrow down the scope value to the scopes relevant to the particular RS.<= /span>

= 

   The JWT MAY include other claims, including those from the "JSON Web
   Token Claims" registry established by [RFC7519].  The JWT SHOULD NOT
   include the "sub" and "exp" claims as an additional prevention
   against misuse of the JWT as an access token (see Section 8.1).

nit: I think a comma after "'exp' claims" would increase clarity.

Thanks, fixed.


= 
   The JWT is cryptographica=
lly secured as specified in [RFC7662].

I think that this was intended to refer to 7519 (JWT), not 7662
(introspection)?

Thanks, the RFC ref was corrected.


= 

   Depending on the specific resource server policy the JWT is either
   signed, or signed and encrypted.  If the JWT is signed and encrypted
   it MUST be a Nested JWT, as defined in JWT [RFC7519].

   Note: If the resource server policy requires a signed and encrypted

(nit?) Just to confirm: the "resource server policy" here is a policy
that's applied at the AS on a per-resource-server basis?  If so, perhaps
writing it "resource-server-specific policy" would clarify.

Clarified as suggested.


= 

   response and the authorization server receives an unauthenticated
   request containing an "Accept" header with content type other than
   "application/token-introspection+jwt", it MUST refuse to serve the
   request and return an HTTP status code 400.  This is done to prevent
   downgrading attacks to obtain token data intended for release to
   legitimate recipients only (see Section 8.2).

An unauthenticated request should be denied unconditionally, right?
Should this MUST apply to just requests containing the "Accept" header
(field) with other content-types?

The section was rewritten to

Note: If the AS requires signed introspection responses for some or all resource servers it MUST refuse to serve introspection requests that don't authenticate the caller and return an HTTP status code 400. This is done to prevent downgrading attacks to obtain token data intended for release to legitimate recipients only (see "token_data_leakage").

This greatly simplified things and allowed the security recommendations section to be shortened significantly.



= 

   The example response JWT payload contains the following JSON
   document:
   [...]
     "token_introspection":
        {
           [...]
           "scope":"read write dolphin",

Is there any chance the minimizer that was run on this payload as input
to JWT generation also removed the spaces in the scope string?  I seem
to be having some unexpected behavior from my local tooling, but it is
looking like the claims set from the example HTTP payload lists
"scope":"readwritedolphin".

I'm not sure what the issue here is, but we'll keep an eye on the formatting of this example.


= 
Section 8.2

   To prevent introspection of leaked tokens and to present an
   additional security layer against token guessing attacks the
   authorization server MAY require all requests to the token
   introspection endpoint to be authenticated.  As an alternative or as
   an addition to the authentication, the intended recipients MAY be set
   up for encrypted responses.

Isn't this ("require all requests to be authenticated") also a MUST now?

This section was removed entirely with the requirement to have all requests authenticated.

The potential loophole of using a bearer access token for the introspection endpoint where the authorised subject is not identified (RFC 7662, section 2.2) is closed now.

https://tools.ietf.org/html/rfc7662#section-2.2=


Vladimir

= 
--=20
Vladimir Dzhuvinov
--------------5CB0AB618AE7AEA098D67B1C-- --------------ms030005030707000403080401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMDkwOTU3MzhaMC8G CSqGSIb3DQEJBDEiBCDoS9pej0O+Di2+iXxMU8ZVO2+8fRHrGefSI8VDH355kTBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAJsjhqjOOhXN+YwFAPVhLm7VH/OoV4/q8TQg5VJEu9wXWSuK B9KXejBCinN9RDk9PUXF3wreTKt/zRJT7iVjg7CvCehyLXjSgzUTV1zrcsoFMO5VeNsGzIw1 fBacUJbC89mh1CV8mdkJ7k7XXJhhYcQsyKS3NaMI1+1x5LZWluXsWJ/ukj+beORC9fzYvy0Q IpJji9kmwrcWo3giro7HRE59R9CMS38+6xmhFcMOJkvQ3gCuiBpGse+64jU5x6OffPUn+HrI FHIUux37RskOI6saptgtqWu0lzeyCAHx8JmMzyC8JvMBmBAEI9HSWNacUEg53PqqdtDqVOcv 1r+E2BkAAAAAAAA= --------------ms030005030707000403080401-- From nobody Tue Feb 9 03:05:42 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68B3A0D39 for ; Tue, 9 Feb 2021 03:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHSgIz7OXtNx for ; Tue, 9 Feb 2021 03:05:36 -0800 (PST) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF48A3A0D2A for ; Tue, 9 Feb 2021 03:05:36 -0800 (PST) Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 9Qpqlr2II06jR9QpqlqGZx; Tue, 09 Feb 2021 04:05:35 -0700 x-spam-cmae: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=60226c80 p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=PzzBoh6yAAAA:8 a=__SxRlIrAAAA:8 a=1XWaLZrsAAAA:8 a=pGLkceISAAAA:8 a=6UTy7V93a0MtYHshHHQA:9 a=QEXdDO2ut3YA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=W1Cnb8L4jXWMME9jnaAA:9 a=drMbf5vwJYpDfcsa:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L62bugPwxnpkHHKveAwe:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=IdGyktwZ2tr74praB_5u:22 x-spam-account: vladimir@connect2id.com x-spam-domain: connect2id.com X-CMAE-Analysis: v=2.4 cv=GueHRm5C c=1 sm=1 tr=0 ts=60226c80 p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=PzzBoh6yAAAA:8 a=__SxRlIrAAAA:8 a=1XWaLZrsAAAA:8 a=pGLkceISAAAA:8 a=6UTy7V93a0MtYHshHHQA:9 a=QEXdDO2ut3YA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=W1Cnb8L4jXWMME9jnaAA:9 a=drMbf5vwJYpDfcsa:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L62bugPwxnpkHHKveAwe:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=IdGyktwZ2tr74praB_5u:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: Warren Parad Cc: oauth References: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Tue, 9 Feb 2021 13:05:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020109090309070208050805" X-CMAE-Envelope: MS4xfACSg0sRLMG8YET1eAZVTzqhEXbRcSJhAoQpAcW6gLSaVzs/rwzddZ4vPa+zOhSnOWTSuDR4SO4SJQUG3uCIY1zJI5xJY5COEAUugcAxKTyDUf6/sMlw kVAjVEfrTKfmGn+KDDIIYUeZSebICcmSqjQSx3hqg17Oy+suzSGiYQqQor2yvaNGUSEFosY4aGFcYg1O4lNyVunNg++z80uKVlQ= Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 11:05:40 -0000 This is a cryptographically signed message in MIME format. --------------ms020109090309070208050805 Content-Type: multipart/alternative; boundary="------------23416F35C62BB0A3DB974F0C" Content-Language: en-GB This is a multi-part message in MIME format. --------------23416F35C62BB0A3DB974F0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Warren, On 08/02/2021 17:59, Warren Parad wrote: > None of that justified explicitly stating that refresh token > introspection shouldn't be done. At best it suggests that we should > explicitly add language in the draft to directly encourage it. Did you mean discourage? > But if an AS wants to support it, we shouldn't stop them, or suggest > that they can't do it. The current draft doesn't mention refresh tokens at all. Its subject is the introspection of access tokens by authenticated resource servers and returning the response as a signed JWT. The use of refresh tokens at the introspection endpoint, per RFC 7662, is not forbidden by the draft. > > Allowing refresh tokens to be introspected can also create a > conflict with the sec recommendation to rotate them > > > Not following, can you explain this further? I just double checked the rotation spec. Use that triggers rotation is clearly specified as "access token response", so there should actually be no issues with confusing introspection as use. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4= =2E13.2 RFC 7662 also seems to imply that a public client with a refresh token should not normally be able to introspect it, because it can't authenticate to the AS. > https://tools.ietf.org/html/rfc7662#section-2.2 > To prevent token scanning attacks, the endpoint MUST also require > some form of authorization to access this endpoint, such as client > authentication as described in OAuth 2.0 [RFC6749 ] or a separate > OAuth 2.0 access token such as the bearer token described in OAuth > 2.0 Bearer Token Usage [RFC6750 ]. The methods of managing and > validating these authentication credentials are out of scope of this= > specification. Vladimir > > =09 > > Warren Parad > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement=C2=A0Authress . > > > On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov > > wrote: > > At first it may appear that allowing refresh tokens at the > introspection endpoint may be a logical thing to do, but in > practice there are issues with that and from an OAuth 2.x > perspective it's not easy to justify. > > If the point is to let clients check what authorization they have > been given OAuth 2.0 already provides a std way to do that - in > the access token response - the "scope" parameter: > > https://tools.ietf.org/html/rfc6749#section-5.1 > > RAR has a similar parameter: > > https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1 > > If the point is to find if a refresh token is still valid - this > can be found out by simply using it. Allowing refresh tokens to be > introspected can also create a conflict with the sec > recommendation to rotate them. So thus it may be a better idea to > not let clients assume too much about them. > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#sec= tion-2.2.2 > > If the AS is going to expose refresh token data to a client it > will also have to make a careful judgement what data it exposes. > > https://tools.ietf.org/html/rfc7662#section-2.2 > > For instance "sub". OAuth 2.x in the relation between AS and > client actually has no concept or definition of subject / end-user > identifier. And this is done for a good reason, because it's not a > user authentication protocol. OIDC was designed for that. And to > prevent tracking of users and other privacy issues OIDC also > specifies pairwise subject IDs. The plain OAuth 2.x world doesn't > have this. > > Vladimir > > On 08/02/2021 11:07, Warren Parad wrote: >> It doesn't work that way. You suggested to add language to the >> draft, that means the burden of proof is on you to justify adding >> it. >> >> Otherwise I could just say why not? >> >> And I can go stronger, what's the purpose of nho introspection >> endpoint at all, and why encourage sending access tokens to the AS= ? >> >> Even if you can justify access tokens, there currently isn't >> evidence provided why we should explicity discourage. >> >> >> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt >> > wrote: >> >> >> >>> Am 08.02.2021 um 00:56 schrieb Warren Parad >>> >: >>> >>> =EF=BB=BF >>> >>> I=E2=80=98m therefore leaning towards explicitly stating = in our >>> draft that it is not intended to be used with refresh >>> tokens. >>> >>> I'm not following, why explicitly state that it isn't >>> intended. If an AS wants to provide a similar JSON response >>> to a query with the refresh token, why not encourage that? >> >> Why should we encourage it?=C2=A0 >> >>> >>> =09 >>> >>> Warren Parad >>> >>> Founder, CTO >>> >>> Secure your user data and complete your authorization >>> architecture. Implement=C2=A0Authress >>> . >>> >>> >>> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt >>> >> > wrote: >>> >>> Hi Andrii, >>> >>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >>>> >>> >: >>>> >>>> =EF=BB=BF >>>> Hi=C2=A0Torsten, >>>> >>>> thank you for your response. >>>> >>>> My use case is pretty straight=C2=A0forward >>>> >>>> An OAuth client queries the AS to determine the active >>>> state of an access token and gets the introspection >>>> response which indicates that this access token is >>>> active (using RFC7662). >>>> >>>> An OAuth client queries the AS to determine the active >>>> state of a refresh token and gets the introspection >>>> response which indicates that this refresh token is >>>> active (using RFC7662). >>>> >>>> An OAuth client queries the AS to determine the active >>>> state of an access token and gets the introspection >>>> response (JWT) which indicates that this access token >>>> is active (using this draft). >>>> >>>> Now, an OAuth client queries the AS to determine the >>>> active state of a refresh token (using this draft)... >>>> How will the introspection response look like assuming >>>> that the client provides the valid refresh token and >>>> technically, nothing stops it from doing so. >>> >>> why should the state be provided as JWT?I think the >>> plain JSON response is sufficient in that case.=C2=A0=C2=A0= I also >>> think using token introspection for checking the state >>> of a token from the client side has limited utility. The >>> definitive decision is always made when the client tries >>> to access a resource.=C2=A0 >>> >>> I=E2=80=98m therefore leaning towards explicitly stating = in our >>> draft that it is not intended to be used with refresh >>> tokens. >>> >>> best regards, >>> Torsten. >>> >>>> >>>> Regards, >>>> Andrii >>>> >>>> >>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt >>>> >>> > wrote: >>>> >>>> Hi Andrii, >>>> >>>> thanks for your post. >>>> >>>> The draft is intended to provide AS and RS with a >>>> solution to exchange signed (and optionally >>>> encrypted) token introspection responses in order >>>> to provide stronger assurance among those parties. >>>> This is important in use cases where the RS acts >>>> upon the introspection response data and wants the >>>> AS to take liability re the data quality. >>>> >>>> I=E2=80=99m not sure whether there are similar use c= ases if >>>> a client introspects a refresh token. What is your >>>> use case? >>>> >>>> best regards, >>>> Torsten.=C2=A0 >>>> >>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega >>>> >>> >: >>>> > >>>> > Hi WG, >>>> > >>>> > draft-ietf-oauth-jwt-introspection-response-10 >>>> states that "OAuth 2.0 Token Introspection >>>> [RFC7662] specifies a method for a protected >>>> resource to query an OAuth 2.0 authorization server >>>> to determine the state of an access token and >>>> obtain data associated with the access token." >>>> which is true. Although, according to RFC7662, the >>>> introspection endpoint allows to introspect a >>>> refresh token as well. Hence, the question I have >>>> is how will a token introspection response look >>>> like when the caller provides a refresh token and >>>> sets the "Accept" HTTP header to >>>> "application/token-introspection+jwt"? >>>> > >>>> > I expect there will be no differences, right? >>>> > >>>> > If so, I suggest to >>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "a res= ource server" by "the >>>> caller" in section 4 (Requesting a JWT Response) >>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "If the= access token is invalid, >>>> expired, revoked" by "If a given token is invalid, >>>> expired, revoked" in section 5 (JWT Response) >>>> > If not, my suggestion would be to clarify what >>>> the AS should do when it asked to introspect the >>>> refresh token in general and additionally, what >>>> should happen in the same case based on the type of >>>> the caller from the AS's point of view. >>>> > >>>> > Regards, >>>> > Andrii >>>> > >>>> >>> _______________________________________________ >>> OAuth mailing 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 > Vladimir Dzhuvinov > --=20 Vladimir Dzhuvinov --------------23416F35C62BB0A3DB974F0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Warren,

On 08/02/2021 17:59, Warren Parad wrote:
None of that justified explicitly stating that refresh token introspection shouldn't be done. At best it suggests that we should explicitly add language in the draft to directly encourage it.

Did you mean discourage?

But if an AS wants to support it, we shouldn't sto= p them, or suggest that they can't do it.

The current draft doesn't mention refresh tokens at all. Its subject is the introspection of access tokens by authenticated resource servers and returning the response as a signed JWT. The use of refresh tokens at the introspection endpoint, per RFC 7662, is not forbidden by the draft.



Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them

Not following, can you explain this further?

I just double checked the rotation spec. Use that triggers rotation is clearly specified as "access token response", so there should actually be no issues with confusing introspection as use.

https://tools.ie= tf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2

RFC 7662 also seems to imply that a public client with a refresh token should not normally be able to introspect it, because it can't authenticate to the AS.

https://tools.ietf.org/= html/rfc7662#section-2.2
   To prevent token scanning attacks, the =
endpoint MUST also require
   some form of authorization to access this endpoint, such as client
   authentication as described in OAuth 2.0 [RFC6749] or a separate
   OAuth 2.0 access token such as the bearer token described in OAuth
   2.0 Bearer Token Usage [RFC6750].  The methods of managing and
   validating these authentication credentials are out of scope of this
   specification.

Vladimir

Warren Parad

Founder, CTO
Secure your user data= and complete your authorization architecture. Implement=C2=A0Authress.


On Mon, Feb 8, 2021 at 4:13= PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=

At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify.

If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope" parameter:

https://tools.= ietf.org/html/rfc6749#section-5.1

RAR has a similar parameter:

https://tools.= ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1

If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them.

https://tools.= ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2

If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes.

https://tools.= ietf.org/html/rfc7662#section-2.2

For instance "sub". OAuth 2.x in the relation between AS and client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this.

Vladimir

On 08/02/2021 11:07, Warren Parad wrote:
It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it.

Otherwise I could just say why not?

And I can go stronger, what's the purpose of nho introspection endpoint at all, and why encourage sending access tokens to the AS?

Even if you can justify access tokens= , there currently isn't evidence provided why we should explicity discourage.


On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
=EF=BB=BF
I=E2=80= =98m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.<= /blockquote>
I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that?

Why should we encourage it?=C2=A0

Warren Parad

Founder, CTO<= /p>

S= ecure your user data and complete your authorization architecture. Implement=C2=A0Authress= .


On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=3D40loddersted= t.net@dmarc.ietf.org> wrote:
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii= =2Edeinega@gmail.com>:

=EF=BB=BF
Hi=C2=A0Torsten,

thank you for your response.
My use case is pretty straight=C2=A0forward

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).

Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.=C2=A0=C2=A0= I also think using token introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource.=C2=A0

I=E2=80=98m therefore leaning to= wards explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.


Regards,
Andrii


= On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality.

I=E2=80=99m not sure = whether there are similar use cases if a client introspects a refresh token. What is your use case?
=
best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>:
>
> Hi WG,
>
> draft-ietf-oauth-jwt-= introspection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/token-in= trospection+jwt"?
>
> I expect there will be no differences, right? >
> If so, I suggest to
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0=E2=80=A2 replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0=E2=80=A2 change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
>
> Regards,
> Andrii
>

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

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


--=20
Vladimir Dzhuvinov
--=20
Vladimir Dzhuvinov
--------------23416F35C62BB0A3DB974F0C-- --------------ms020109090309070208050805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMDkxMTA1MzNaMC8G CSqGSIb3DQEJBDEiBCDQPsb3pAgOpN+thD0VcGALPh3cQKJrMGHQmEmADuIdLzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBACI7NYDtVZKqeizoO9bFnpljxqoi8L6nkaQMd1hlhtnCEd4P rX/Tgb0quMJIo7YDvkvR/hj0QB/ag/Mmv2URruPaNDcpDwsB3PDwtzPEfzrQIEWsWqguuwbx ouLPZsf6jPQtabQHERIJ1A30YxcttToE0+bftm/6hoz0d88K3h/0x4oa4b+R25G04V+g8GUA vWZLEWtg+3C8ifvrUHWXhVngRRlVmcMc2se+INc9EFtDf73VAUMsb62Cl0RayqMm3FKEuRdB tpQEkxlWirVngWWcbvWufl4rwtXdA+UgarrgBHNJlhzmYb0olQ7WLoM+Sszjepx2yFqn3oaG +pPxETQAAAAAAAA= --------------ms020109090309070208050805-- From nobody Tue Feb 9 04:53:01 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446183A1A60 for ; Tue, 9 Feb 2021 04:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pkYBR9Fnr8a for ; Tue, 9 Feb 2021 04:52:58 -0800 (PST) Received: from DEU01-FR2-obe.outbound.protection.outlook.com (mail-fr2deu01on2070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e24::70d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E493A1A61 for ; Tue, 9 Feb 2021 04:52:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KX4xXVvle4mU13JIkY7T3MIQOkX5qwyOS7f/i02oVbJGmXugWgCIyuWNrcv7esEBj6SphZwGB3NY/hiW25ATCrRxN5ahLJqp8zw+ga1oyNxmUCPVtQyCpks1onWvw2cgZB8iI8z8c8VzkgtKWZcxPPqWC1J9VjGG1I+FgCoRUNEFxTS/Bn3hc12o8Ba2CZiHUxnpOTMYnpLwUS66zUgX5+BhTs1vC2pQNndnfkMUiGJ7dDG4a6Kem7NIQsnyFVJGLzWOFxtFpkQo+WJmUXUzeXEK++iL3xGO0hRjs1a4XzKQ8nRuBsSkymzQG/xYN6bqlCiJb7ZpjBW5lXiOwxzPeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XQWY17zn+Y9aaFId93ZpnfPunOPwGHK++t+/pzVzAKA=; b=VkKKCinzZxPBv2exmWimveLQpuOXakNPMlup1ggU2+baQMO7COpRP6fQSoAy249nYxwg11Ah2bi2KwJUE8ec2sXENB6inN7e1AVOMfpkPctPKBEncacwDldVovh5K1tJOGpmi2vKz+uWIJlPkcSBeZ2uZ8Q0INiN78oBVarfukwqI59XraQ9/++gelIHQXGPMUXC5uxmqAG6okTJGyJAcnEP8XXY3AsDuCZ5DEHdw5ZPWONjqflNThmFH+uHIyB5OIylbVGq89oeDXjSrVcGGux93fE8mhOCdQzmSb5draPs03yavEt+pdiNbEDC9n98g6rVF4h331UeXpmqP9Z/Mg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=adorsys.de; dmarc=pass action=none header.from=adorsys.de; dkim=pass header.d=adorsys.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XQWY17zn+Y9aaFId93ZpnfPunOPwGHK++t+/pzVzAKA=; b=HOA5gX9JPOvHNL48DokYiXUCLqjcNK2Og7wLbUWvGgZ+epZwBwULhp4xpofcaFwZyd9le1tcV0zat19/aCMQ3hF1NxEG6IPfhmyOwHKOJyn+t9s8/VF/Toe11YCIWRTb22W0HCoEaQrCJY5tTr2QW6rLt6vfUijCQhcHiZtqa4PbLwieOL0HxasdAIGO5rjSYdbZ2kTYgZwt8f3Or52Dld+3J3eG0q1ZbRHPoHTsc6lHwlAYmrgVcTrfYZSw0mmFzDlXCv8SGqXvMJsebE5S3SCLfVppZB+qVOUTP5N9Lf3KRwBEYBWjVTqBo4AmkTpm7NBLAlCY/s45ubrjKUlEDQ== Received: from (2603:10a6:d10:11::11) by FRYP281MB0239.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.10; Tue, 9 Feb 2021 12:52:48 +0000 Received: from FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::858a:948b:efd1:953e]) by FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM ([fe80::858a:948b:efd1:953e%4]) with mapi id 15.20.3846.025; Tue, 9 Feb 2021 12:52:48 +0000 From: Francis Pouatcha To: Torsten Lodderstedt , oauth Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt Thread-Index: AQHW/U7BfQWTVVlnJ0OBUvPBsW2f+apMpNCAgAMizBk= Date: Tue, 9 Feb 2021 12:52:48 +0000 Message-ID: References: <161270175060.8296.1897997883947486904@ietfa.amsl.com>, <06504BA6-6065-4ADD-BE45-5E13DF00DC1A@lodderstedt.net> In-Reply-To: <06504BA6-6065-4ADD-BE45-5E13DF00DC1A@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=adorsys.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2603:9000:780a:f3b8:d84e:1caa:467b:271] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a3c1096-6530-443d-fce0-08d8ccf99aae x-ms-traffictypediagnostic: FRYP281MB0239: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v+V4X+ffmet9SjrF2NjvuX8feZfLgG8VR7xi/ThZeXBzyUDz0bryKvTt4U88qNEj67FrQSmhedQ8F+Z95L2Hdhcb/0H2BcXSnVzL6RFX7pYcigL5sSqI689ap4PvU+CHZOzEBYvrYzjCmqVB1LjIXbZo4cUie9HhwjADxeiYYTSUb3ZpjTXYcLpuhKZ1r+y566H8vLr+QahBe5h7OYiE/kX3PsGkQZz+Yde6V+nYZrS+wJs1p5/18Yeq8OYx4/4zq0uq40IqkFR4VIPiKCgJ0QtuLyGG+nOCoKE81tI3VhzJU/9q1CiuYDuNbi/sc7EWDhgFZ1CNUbTlrEQy0PEqM4TYS4TuAhgKNVH3CEvjz+MmciM/u9MuCRMLkQ/xw0+6Y0lNU+pc0SU1JNTA3ABYSKMGQna8mB9BmRY/rMiTJoAqPzd7TnYnGuEBz+irLvkK/33o0yvZHIdfThaR+h1jHDRQtQjeBInxetndCo+Fo1Egu9Fbq7nYwzGKNDTchFD2mUaFoPgzxC2JMYyxj698XEE3xdbxwLqVtvDGWF6OL9Jw/D0vKn4xD/nqJ7zeJ9+tjJyzfz8RHIdCVuLWnHxPoTm/i+aFi2xCparN31SlowD6XO14yER5TeSK0/m0wq8u8FngjoKx+9Y2krO23zkr/IUH7ydoy9m5lQDGdBmylxo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39830400003)(366004)(396003)(376002)(136003)(2906002)(478600001)(9686003)(66574015)(76116006)(66556008)(66946007)(91956017)(6506007)(64756008)(66446008)(66476007)(316002)(53546011)(71200400001)(19627405001)(8936002)(166002)(186003)(83380400001)(8676002)(55016002)(33656002)(86362001)(5660300002)(966005)(7696005)(110136005)(52536014)(133740200002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?cl3VZ1NRX78NDPVPU4v1/giQSZrluDxVBSY2l8MD/6OevE4PKo0Zf8qLkr?= =?iso-8859-1?Q?Vn7gxCtrAICfZNu44ALbPeUqqUKFSKb0iq/9Tf+8q8CzabHXOktKiBORxu?= =?iso-8859-1?Q?/VIpzBsmG+faeFyWAvKB2v+xjiGc6YfrDB7xUEldbl0XWWTIfRNPVYCOkK?= =?iso-8859-1?Q?YmbdCZTltPDokg58ipDz1eeSL0p0FGynOR59x2OqKV7toeVNYjgzhQUmRw?= =?iso-8859-1?Q?+5QUr+ouBGw0cg+PA43R0fS8ER4HNB4oJ3z/c8wSXhpI4f9zOSMb1Y1Isa?= =?iso-8859-1?Q?E5yfe+5+D17VSMnonToscKJupWJpqzkIqN8bC+YmZ+LkkPeOX8mULV3fWj?= =?iso-8859-1?Q?nYSjfcnj2FM4KdMd4027uHy75h2RZzCMulmYruJB22ntb1l6jak6GPbHV8?= =?iso-8859-1?Q?I+Kn2+4mavuih8y5N+YFhGrVEW7WAhQP8xLzNkRgP7W4eSfiAq9r9D2Ruk?= =?iso-8859-1?Q?v1o1jRyybAGc56FVwA3Cn4eZ5WElgRSvIrHLKH2qia8SwCQ49uLBm+FeiN?= =?iso-8859-1?Q?0/ntEaiyNOmI8T0/c6am7SnUEIjtxUTuAgdRkOEey5w8TIHm19nj1rQdqd?= =?iso-8859-1?Q?x56w9Od6PV8E+lRilAESmFboDfBsYXBZtnoSYuuzeng/XEA4wFAGYJTrvA?= =?iso-8859-1?Q?0sf7AyJldjOiDEMU7XEzrt60xSxkjMXyIAsonTNZ7G+pQIbI6pK4+nL3yw?= =?iso-8859-1?Q?y7p2YADQsrBIMARn+snChgs/qQyqvW15QxuE59SkM/MlvutdEIaggL6H4q?= =?iso-8859-1?Q?ofKrfJt6tnAsKzO3q3Y0E1wf8BNR1yoH15Jz53MzYY/cPZ2oiYxQAG9BDE?= =?iso-8859-1?Q?VdQ7irUOH3m09z7fbwBe9jChWsIF9aqAyebfwhzPjAYiXHJJ3hBrTznZp7?= =?iso-8859-1?Q?m70timkI2uZVC8zOi9idtIVcw4keArhaODMz+MUhZ2nnb+L85DKtw4ZCL9?= =?iso-8859-1?Q?GE1EAyE08rPLHTtDoPE2RmQKBJm7wVPu8Dm0ab5fA8dOh/PTEXPFGZ9PoS?= =?iso-8859-1?Q?vsSoQdIOtFMXEJxkMTDWhUHxq0auNRzIq2wyu47UkQjkdzBe0itkUDilGf?= =?iso-8859-1?Q?KQWY7RJrR85VjJmeg2chREzEXPSIcR8TyIF8BqwdRok8TwYVM5HkV86e5P?= =?iso-8859-1?Q?m5ace1iWDJon4+IK+ELM/yezLkMI8YIgxWf/b9GM5atp4zfhYfKSuawhzG?= =?iso-8859-1?Q?Dob0aR/yCe/QF/y4J0pRySoGtLWd7Rzo4RUvK6OSlFa6Q5kAYQFII9eea1?= =?iso-8859-1?Q?ZzhZ4GbwdTka8ltqHryPUyfqbIaIeJs9Bj3g4pRiY=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FR2P281MB01063CE7EE6ECFE8727E58878D8E9FR2P281MB0106DEUP_" MIME-Version: 1.0 X-OriginatorOrg: adorsys.de X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FR2P281MB0106.DEUP281.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5a3c1096-6530-443d-fce0-08d8ccf99aae X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2021 12:52:48.6639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5e2c5484-e522-479d-91ca-515d6e0ce228 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NoZOmUyuneBauXVH/uGk4INiSQLE6eL3akphmFppEthmUQ3EcLLTKye7+Af+/3g0p2XyTH1taCpUAMWztFEu55/c7FIPqi0Cfm0p6U7cBcg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRYP281MB0239 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 12:53:00 -0000 --_000_FR2P281MB01063CE7EE6ECFE8727E58878D8E9FR2P281MB0106DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Find bellow my review of the draft: 1. Redactional changes: 2.2. Authorization Data Types Interpretation of the value of the "type" parameter, and the object elements that the "type" parameter allows =3D> allowed 9. Metadata which is an JSON array. =3D> which is a JSON array 1. Application to existing APIs reason-1: Current open banking initiatives are built on the of existing Dat= a Standards like ISO20022 (PAIN, CAMT) which are XML's that do not provide = direct translation to JSON. Some authorization server's might even be able = to parse an ISO PAIN file to display the proper authorization request to th= e user. reason-2: In some situation, it might be more privacy preserving to have th= e authorization request content negotiated between the AS and the RS. In th= is case the "scope" parameter shall only carry some sort of "grant-id" (kno= wn in the Berlin Group spec as consent-id). This will allow the AS to negot= iate the data to be displayed directly with the RS. Any idea how to consider these two edge cases? Best regards. /Francis ________________________________ From: OAuth on behalf of Torsten Lodderstedt Sent: Sunday, February 7, 2021 12:49 PM To: oauth Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt Hi all, here is the list of changes in revision -04: * restructured draft for better readability * simplified normative text about use of the resource parameter with au= thorization_details * added implementation considerations for deployments and products * added type union language from GNAP * added recommendation to use PAR to cope with large requests and for r= equest protection Your feedback is highly appreciated. best regards, Torsten. Am 07.02.2021 um 13:42 schrieb internet-drafts@ietf.org: 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 WG of the IETF. Title : OAuth 2.0 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-04.txt Pages : 36 Date : 2021-02-07 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-ietf-= oauth-rar/&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw3-4SmuMFg= xbz-cDK2Ir_a7 There is also an HTML version available at: https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf-o= auth-rar-04.html&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw1J5= 2xGTvk1ZAuBC_fUAIjJ A diff from the previous version is available at: https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-ie= tf-oauth-rar-04&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw0TYq= mFwryvAYznR2Ho5Oj6 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth&= source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw06g1z6o36BkkaqkiWc1L= w9 --_000_FR2P281MB01063CE7EE6ECFE8727E58878D8E9FR2P281MB0106DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Find bellow my review of the draft:

  1. Redactional changes:

2.2.  Authorization Data Types


Interpretation of the value of the "type&qu= ot; parameter, and the object

 &nbs= p; elements that the "type" parameter allows =3D> allowed<= /span>


9.  Metadata

which is an

 &nbs= p; JSON array. =3D> which is a JSON array



  1. Application to existing APIs
reason-1: Current open banking initiatives are built on the of e= xisting Data Standards like ISO20022 (PAIN, CAMT) which are XML's that do n= ot provide direct translation to JSON. Some authorization server's might ev= en be able to parse an ISO PAIN file to display the proper authorization request to the user.

reason-2: In some situation, it might be more privacy preserving to ha= ve the authorization request content negotiated between the AS and the RS. = In this case the "scope" parameter shall only carry some sort of = "grant-id" (known in the Berlin Group spec as consent-id). This will allow the AS to negotiate the data to be display= ed directly with the RS.

Any idea how to consider these two edge cases?

Best regards.
/Francis


From: OAuth <oauth-bounc= es@ietf.org> on behalf of Torsten Lodderstedt <torsten=3D40loddersted= t.net@dmarc.ietf.org>
Sent: Sunday, February 7, 2021 12:49 PM
To: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt
 

here is the list of changes in revision -04:

  • restructured draft for better readability
  • simplified normative text about use of the resource parameter with authori= zation_details 
  • added implementation considerations= for deployments and products
  • added type union language = from GNAP  
  • added recommendation to use PAR to cope= with large requests and for request protection

Your feedback is highly appreciated.

best regards,
Torsten. 

Am 07.02.2021 um 13:42 schrieb internet-drafts@ietf.org:


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

       Title           : OAuth= 2.0 Rich Authorization Requests
       Authors         : Torsten Lo= dderstedt
                     = ;    Justin Richer
                     = ;    Brian Campbell
Filename =        : draft-ietf-oauth-rar-04.txt
Pages &nb= sp;         : 36
Date &nbs= p;          : 2021-02-07

Abstract:
  This document specifies a new parameter "authorization_details&= quot; that
  is used to carry fine grained authorization data in the OAuth
  authorization request.


The IETF datatracker status page for this draft is:
https://www.google.com/url= ?q=3Dhttps://datatracker.ietf.org/doc/draft-ietf-oauth-rar/&source=3Dgm= ail-imap&ust=3D1613306557000000&usg=3DAOvVaw3-4SmuMFgxbz-cDK2Ir_a7<= /a>

There is also an HTML version available at:
https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf-o= auth-rar-04.html&source=3Dgmail-imap&ust=3D1613306557000000&usg= =3DAOvVaw1J52xGTvk1ZAuBC_fUAIjJ

A diff from the previous version is available at:
https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-ie= tf-oauth-rar-04&source=3Dgmail-imap&ust=3D1613306557000000&usg= =3DAOvVaw0TYqmFwryvAYznR2Ho5Oj6


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

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth&= amp;source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw06g1z6o3= 6BkkaqkiWc1Lw9

--_000_FR2P281MB01063CE7EE6ECFE8727E58878D8E9FR2P281MB0106DEUP_-- From nobody Tue Feb 9 12:38:28 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77D63A09E3; Tue, 9 Feb 2021 12:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXK80lzUOAfg; Tue, 9 Feb 2021 12:38:25 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319483A09C7; Tue, 9 Feb 2021 12:38:25 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id bl23so34038660ejb.5; Tue, 09 Feb 2021 12:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WAfPLsWRF8lL1omjMzWM2nG5kUgKmHgPA9FmnLYMjvs=; b=eSRqvXrxiv2kk4PceMz/prnQsPMbJjxDrA7Oa6svkBmLny1XCZpknW1Rt8YFh12aVX QmZSM0xjNLU+CoFkk2sFlVZcSDYIYlIasRkOWYfoa+m29C9HFs5ieGMEsDx5tm3GNiOE xjHTt6FR0JlORLVnUV6Cg/TDj1juuKvt1hxjmQur3Rrdt+rf03ZNy6a4/j2qz4eM00lj 3Gqrre8E2Bh1MUyloYGVm1aWfJ+4CIFTWE2A6N1xUxDggqs0dRUob2O9rruUkvzVjE0x vDBwAtI0SKWo7Wo2xYWzvghrjBHFwq3DolhBNTsatWIC7coUcsHxuLMBzpm27b7Thapz atrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WAfPLsWRF8lL1omjMzWM2nG5kUgKmHgPA9FmnLYMjvs=; b=OSwhmaOfhCBcJi3ORl/SHtRup+m4FAxSrFGrZ6w1BcTV2rfKFeAQWSGjbOtHnwvszO KO1UsKrwfCPT7c5J9DNqL+K6bJYPrXvj43DO/XNLQY3tnnQDq3y2APEw1TmZq1gH4/Wn W1I5wS+x5TVo3z6gIFeZlVCykOOI8wyuOoLEeSUgvj1SjfCwAiyjbWfwnSkmdA+tTWGi cWGVzwW93qkB2IFrBE6OV8cHzBfA47pZYp6i/2Hkm/pAjvBkS1t9CDDVYnjFaPeyRp28 fEbD6aCreOfd5f++3gFFx7ScGb2d4e731jBuoMJ+S0v9zyzYHlgt3+o9Z10O6wwOKgLK 4XEA== X-Gm-Message-State: AOAM531/oRwZzFPw9HIIILr/ZZR6IgttedfGJhsspi2lZcF1QBmXNg1+ wxrgaBIBdWXEBbRUXTh35sS1z1rLYJy0EkSLmaA= X-Google-Smtp-Source: ABdhPJwnahUXwbdhBfRjGusioBZUIkakcAfQKW4JZcOOOqCNkjAvihtqr4GGwGDSL0mrbA32PJeA4WO8EFUUJQRQxIk= X-Received: by 2002:a17:906:547:: with SMTP id k7mr24315989eja.273.1612903103548; Tue, 09 Feb 2021 12:38:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Deinega Date: Tue, 9 Feb 2021 12:38:12 -0800 Message-ID: To: Neil Madden Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b4f1805baed4494" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 20:38:27 -0000 --0000000000008b4f1805baed4494 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How can you guarantee that there are always direct TLS connections between a client and an AS hosted say some cloud provider where you have a little control on their infrastructure? Even without all those cloud providers, how can you guarantee the same when there are a bunch of different (software and hardware) components that legitimately perform SSL offloading / DPI in front of an AS... or the client may just use the proxy server? Regards, Andrii On Tue, Feb 9, 2021 at 12:43 AM Neil Madden wrote: > On 9 Feb 2021, at 06:55, Andrii Deinega wrote: > > > =EF=BB=BF > Hi WG, > > I wonder if there are any particular reasons to not make nonce a mandator= y > parameter for the current JWT Response for OAuth Token Introspection draf= t. > Or, at least, force an AS to include the nonce claim in a JWT response wh= en > nonce is presented in the introspection request similar to what happens > with the similar scenario in the OpenID Connect ID Token? > > > https://openid.net/specs/openid-connect-core-1_0.html#:~:text=3DIf%20pres= ent%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Auth= entication%20Request. > > This will allow to mitigate replay attacks because clients can correlate > the response with the initial request > > > ID tokens involve flows using an insecure channel (the browser). This is > not the case for introspection requests which happen over a direct TLS > connection and so are already protected against replay attacks. > > =E2=80=94 Neil > > ForgeRock values your Privacy --0000000000008b4f1805baed4494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How can you guarantee that there are always direct TLS con= nections between a client and an AS hosted say some cloud provider where yo= u have a little control on their infrastructure?

Eve= n without all those cloud providers, how=C2=A0can you guarantee=C2=A0the sa= me when there are a bunch=C2=A0of different (software and hardware) compone= nts that legitimately perform SSL offloading / DPI in front of an AS...=C2= =A0 or the client may just use the proxy server?

<= div>Regards,
Andrii

On Tue, Feb 9, 2021 at 12:43 AM Ne= il Madden <neil.madden@forg= erock.com> wrote:
On 9 Feb 2021, at 06:55, Andr= ii Deinega <andrii.deinega@gmail.com> wrote:

=EF=BB=BF
Hi WG,

I wonder if there are any par= ticular reasons to not make nonce a mandatory parameter for the current JWT= Response for OAuth Token Introspection draft. Or, at least, force an AS to= include the nonce claim in a JWT response when nonce is presented in the i= ntrospection request similar to what happens with the similar scenario in t= he OpenID Connect ID Token?

https://openid.net/specs/openid-connect-core-1_0.html#:~:text= =3DIf%20present%20in%20the%20Authentication%20Request%2C,value%20sent%20in%= 20the%20Authentication%20Request.

This will all= ow to mitigate replay attacks=C2=A0because clients can correlate the respon= se with the initial request

ID= tokens involve flows using an insecure channel (the browser). This is not = the case for introspection requests which happen over a direct TLS connecti= on and so are already protected against replay attacks.=C2=A0
=E2=80=94 Neil

ForgeRock values your Privacy --0000000000008b4f1805baed4494-- From nobody Tue Feb 9 13:30:07 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA92F3A0D18 for ; Tue, 9 Feb 2021 13:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdAkH9ez1LfZ for ; Tue, 9 Feb 2021 13:30:04 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EFA3A0D13 for ; Tue, 9 Feb 2021 13:30:03 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id u14so23848741wri.3 for ; Tue, 09 Feb 2021 13:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=qd/qCMskCQDsV5hsHwOmr+4yqnmpC0RJIC9CCv/VQGg=; b=WsB0WJJ9LUEIangsFvLT+NW8BammbRiKe65JQHj6I/u8ZH42CxcYgftyq7jYBrxbhd B4TOBcrT3TGT0M5r1nYfHN5+dwnOJda6kwGv3Gn3vyqMn5LdEhm0tZoAgWOwTXBw7opZ LFIB/AkSVujNmXN3eBws0ku6OTRwsN6Go6o8k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=qd/qCMskCQDsV5hsHwOmr+4yqnmpC0RJIC9CCv/VQGg=; b=LvlMtuhzVYLJkl+XTGHze3T7knNZRdPkYVCcMsWMGl144YSgKcBEdMk33qo7EgFdXF mhX6fnDQu8uVcXpZV/T19+TFogXvpBVJMV9qCt8mKL2ANu8oSp5P2OkurwK4FsDVyg1/ HOpbvKUK46108Am0kKoaON9Vc8wj44hXwjAgRTn+npsKPEjGwELb07Q/sZjgearPQ78M kYMeddNDtfXRQLXbITUBVWQjvu6iOFtytD3R5BLe3wC9xaKd4yT8iSl9VqnM28SeAAkx iRUfg32rWN3STjQgdazX8VNoEclE7qknXJ+I58UHodrUqcKREK+iVFlJsxeDoB+JzIfs +Qgg== X-Gm-Message-State: AOAM532fKld/XKoJsfHqQ8gfd+7Hi6Cf6DZeHxwhqaIy4vO3oRLr264e Mfcvk6/OaFHJQMAdncOVPJ/rgDN4hdxvNrL1LAtswUBiVHl+MymdwXKyDpVmOljz6sZkyj1OUg= = X-Google-Smtp-Source: ABdhPJzMEtnKKpsZjMHSkuNdN8hqfUh4dEFNfkhbggzhWa8HDf/qMgE3YfuxyTF0aPB6GtTWQwtc5g== X-Received: by 2002:adf:9226:: with SMTP id 35mr94100wrj.408.1612906201668; Tue, 09 Feb 2021 13:30:01 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id v15sm13559314wra.61.2021.02.09.13.30.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Feb 2021 13:30:01 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Tue, 9 Feb 2021 21:29:59 +0000 Message-Id: References: Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org In-Reply-To: To: Andrii Deinega X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-F6FA7394-1F21-4DA1-A4AA-43859DCB803D Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 21:30:06 -0000 --Apple-Mail-F6FA7394-1F21-4DA1-A4AA-43859DCB803D Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Three points: 1. In many cases the JWT will be verified using a public key fetched over t= he same TLS channel.=20 2. Many proxies can now also produce and consume JWTs for downstream servic= es, so end-to-end JWT is no more guaranteed than end-to-end TLS. 3. The JWT response already contains an iat claim which is sufficient to ju= dge freshness.=20 It would be better to concentrate on ensuring end-to-end TLS rather than tr= ying to reinvent the same mechanisms in JWT form on top.=20 =E2=80=94 Neil > On 9 Feb 2021, at 20:38, Andrii Deinega wrote: >=20 > =EF=BB=BF > How can you guarantee that there are always direct TLS connections betwee= n a client and an AS hosted say some cloud provider where you have a little= control on their infrastructure? >=20 > Even without all those cloud providers, how can you guarantee the same wh= en there are a bunch of different (software and hardware) components that l= egitimately perform SSL offloading / DPI in front of an AS... or the clien= t may just use the proxy server? >=20 > Regards, > Andrii >=20 >> On Tue, Feb 9, 2021 at 12:43 AM Neil Madden = wrote: >>> On 9 Feb 2021, at 06:55, Andrii Deinega wrot= e: >>>=20 >>> =EF=BB=BF >>> Hi WG, >>>=20 >>> I wonder if there are any particular reasons to not make nonce a mandat= ory parameter for the current JWT Response for OAuth Token Introspection dr= aft. Or, at least, force an AS to include the nonce claim in a JWT response= when nonce is presented in the introspection request similar to what happe= ns with the similar scenario in the OpenID Connect ID Token? >>>=20 >>> https://openid.net/specs/openid-connect-core-1_0.html#:~:text=3DIf%20pr= esent%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Au= thentication%20Request. >>>=20 >>> This will allow to mitigate replay attacks because clients can correlat= e the response with the initial request >>=20 >> ID tokens involve flows using an insecure channel (the browser). This is= not the case for introspection requests which happen over a direct TLS con= nection and so are already protected against replay attacks.=20 >>=20 >> =E2=80=94 Neil >>=20 >> ForgeRock values your Privacy --=20 ForgeRock values your Privacy --Apple-Mail-F6FA7394-1F21-4DA1-A4AA-43859DCB803D Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Three points:

1. In many cases the JWT will be v= erified using a public key fetched over the same TLS channel. 

2. Many proxies can now also prod= uce and consume JWTs for downstream services, so end-to-end JWT is no more = guaranteed than end-to-end TLS.

3. The JWT response already contains an iat claim which is sufficient= to judge freshness. 

It would be better to concentrate on ensuring end-to-end TLS rather than t= rying to reinvent the same mechanisms in JWT form on top. 

=E2=80=94 Neil
=
On 9 Feb 2021, at 20:38, Andrii Deinega <a= ndrii.deinega@gmail.com> wrote:

=EF=BB=BF
How can you guarante= e that there are always direct TLS connections between a client and an AS h= osted say some cloud provider where you have a little control on their infr= astructure?

Even without all those cloud providers, = how can you guarantee the same when there are a bunch of dif= ferent (software and hardware) components that legitimately perform SSL off= loading / DPI in front of an AS...  or the client may just use the pro= xy server?

Regards,
Andrii

On Tue, Feb 9, 2021 at 12:43 AM Neil Madden <neil.madden@forgerock.com> wrote:
On 9 Feb 2021, at 06:55, Andrii Deinega <andrii.deinega@gmail.com> wrote= :

=EF=BB=BF
Hi WG,
I wonder if there are any particular reasons to not make nonce a mand= atory parameter for the current JWT Response for OAuth Token Introspection = draft. Or, at least, force an AS to include the nonce claim in a JWT respon= se when nonce is presented in the introspection request similar to what hap= pens with the similar scenario in the OpenID Connect ID Token?

https://openid.net/specs/openi= d-connect-core-1_0.html#:~:text=3DIf%20present%20in%20the%20Authentication%= 20Request%2C,value%20sent%20in%20the%20Authentication%20Request.

This will allow to mitigate replay attacks because c= lients can correlate the response with the initial request

ID tokens involve flows using an insecure chan= nel (the browser). This is not the case for introspection requests which ha= ppen over a direct TLS connection and so are already protected against repl= ay attacks. 

=E2=80=94 Neil

ForgeRock values your Privacy
ForgeRock values your Privacy --Apple-Mail-F6FA7394-1F21-4DA1-A4AA-43859DCB803D-- From nobody Tue Feb 9 14:04:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB18A3A0DAE; Tue, 9 Feb 2021 14:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcGntX4Zod_2; Tue, 9 Feb 2021 14:04:06 -0800 (PST) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244463A0DAC; Tue, 9 Feb 2021 14:04:05 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id i8so80465ejc.7; Tue, 09 Feb 2021 14:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jmi9DwYJwMrbWQ5xyrPCkTWBnQqVxoYKX23x4JrPX/4=; b=dG7DmCMaUL9mg3Xx20TZZEvdosv6zl1tmafiu4s8NuMRzB6uIJwX9GkxVPa0MgfeVV jBrmEAdyODnoZ5jQd/eAPZqSyA4naP+D4YvGbyBm7FIp+dOHYWipiRmk0L1aODDY+CSP AGzgcwE3/Puuf+/zkQM5hvhlfQCVahLyy6hERlPY6iQbJOQi++XBZ9zwwz7ya6eNIAgf BKYmMralh4aYaXC9//kGhkzrinaF4adIOBnAmfWz3tLD9Ie8F8bQ4Cj1mbWyP5wYKuVC ohnJAw+F8L5czDkaCS71/00SDu531hz5kRzbl+0wYhl5+myKQyZfwXSHsZ0KkW5iP63K tUiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jmi9DwYJwMrbWQ5xyrPCkTWBnQqVxoYKX23x4JrPX/4=; b=IGtpjRqtvlAHRrTU24ngwLGbfXNpYihx9OXZuDRa249BFxqYoVcI/5wXVyE7C4ytpM k+D3jjShV58GyGnhb1ZBIqCqswK+e+eJtihNTuvIcnZnxCo5MTm6l1VBq1qKGMwOnod9 hoLb3WSOYlX9zZ8gKIjSaX1wr0BC3X0YTRTQ/5o5bYNutSoSCXnXBebWwVdmv8akhqf3 nuNq+Wp7P5dimno6IyaWo8u10m8GW6n+9iasMTvlwZ0k5Pu4vRrkNl18lo+Pi3/MUtPZ vpLbkcd082X6kxfI+RHuoeo9Rkm9Kuf7zh1bSOhFNLEERivyYfVV7KRsb4ELtLIKaTak 6GFA== X-Gm-Message-State: AOAM533IF+LKK51RsyNC/5gxJaEFMqKEe/Xfz9RMnctJD72XEIt2n+ya ufuUl/2w8YNEAtnTE5PzOXLjVrwxcNl+pxxH1Kc= X-Google-Smtp-Source: ABdhPJwlzXuoNhCNxgRM9faM7A4Qnwv/5ikD+SkMxm2VgNCl4U2t8eQ6Ti2McKn5Hr4GvTIN93NzOVqwAVQOdeHSVE4= X-Received: by 2002:a17:906:259a:: with SMTP id m26mr24986531ejb.399.1612908244237; Tue, 09 Feb 2021 14:04:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrii Deinega Date: Tue, 9 Feb 2021 14:03:53 -0800 Message-ID: To: Neil Madden Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="000000000000f4002c05baee7606" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 22:04:11 -0000 --000000000000f4002c05baee7606 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I still don't see how your #1 and #3 points mitigate the replay attack when an attacker somehow eavesdrops a successful response from an AS (yes, it's signed by a public key) and then starts to replay it for other requests from the same client. The main problem here is that the client doesn't have a way to correlate the introspection response with the initial introspection request. Regarding #2, it's true that there are many proxies that do this and that. In practice, you don't always have control over the infrastructure where you may run your AS as I was saying before. Regards, Andrii On Tue, Feb 9, 2021 at 1:30 PM Neil Madden wrote: > Three points: > > 1. In many cases the JWT will be verified using a public key fetched over > the same TLS channel. > > 2. Many proxies can now also produce and consume JWTs for downstream > services, so end-to-end JWT is no more guaranteed than end-to-end TLS. > > 3. The JWT response already contains an iat claim which is sufficient to > judge freshness. > > It would be better to concentrate on ensuring end-to-end TLS rather than > trying to reinvent the same mechanisms in JWT form on top. > > =E2=80=94 Neil > > On 9 Feb 2021, at 20:38, Andrii Deinega wrote: > > =EF=BB=BF > How can you guarantee that there are always direct TLS connections betwee= n > a client and an AS hosted say some cloud provider where you have a little > control on their infrastructure? > > Even without all those cloud providers, how can you guarantee the same > when there are a bunch of different (software and hardware) components th= at > legitimately perform SSL offloading / DPI in front of an AS... or the > client may just use the proxy server? > > Regards, > Andrii > > On Tue, Feb 9, 2021 at 12:43 AM Neil Madden > wrote: > >> On 9 Feb 2021, at 06:55, Andrii Deinega wrote= : >> >> >> =EF=BB=BF >> Hi WG, >> >> I wonder if there are any particular reasons to not make nonce a >> mandatory parameter for the current JWT Response for OAuth Token >> Introspection draft. Or, at least, force an AS to include the nonce clai= m >> in a JWT response when nonce is presented in the introspection request >> similar to what happens with the similar scenario in the OpenID Connect = ID >> Token? >> >> >> https://openid.net/specs/openid-connect-core-1_0.html#:~:text=3DIf%20pre= sent%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Aut= hentication%20Request. >> >> This will allow to mitigate replay attacks because clients can correlate >> the response with the initial request >> >> >> ID tokens involve flows using an insecure channel (the browser). This is >> not the case for introspection requests which happen over a direct TLS >> connection and so are already protected against replay attacks. >> >> =E2=80=94 Neil >> >> ForgeRock values your Privacy > > > ForgeRock values your Privacy --000000000000f4002c05baee7606 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I still don't see how your #1 and #3 points mitigate t= he replay attack when an attacker somehow eavesdrops a successful response = from an AS (yes, it's signed by a public key) and then starts to replay= it for other requests from the same client.

The main problem here i= s that the client doesn't have a way to correlate the introspection res= ponse with the initial introspection request.

Regarding #2, it's= true that there are many proxies that do this and that. In practice, you d= on't always have control over the infrastructure where you may run your= AS as I was saying before.

Regards,
Andri= i


On Tue, Feb 9, 2021 at 1:30 PM Neil Madden <neil.madden@forgerock.com> wr= ote:
Three points:

1. In many cases the JWT will be verified using a public key fe= tched over the same TLS channel.=C2=A0

2. Many proxies can now also produce and consume JWTs for down= stream services, so end-to-end JWT is no more guaranteed than end-to-end TL= S.

3. The JWT response alr= eady contains an iat claim which is sufficient to judge freshness.=C2=A0

It would be better to concen= trate on ensuring end-to-end TLS rather than trying to reinvent the same me= chanisms in JWT form on top.=C2=A0

=E2=80=94 Neil

On 9 Feb 2021, at 20:38, Andrii Deinega <andrii.deinega@gmail.com> wrote:
=
=EF=BB=BF=
How can you guarantee that there are always direct TLS con= nections between a client and an AS hosted say some cloud provider where yo= u have a little control on their infrastructure?

Eve= n without all those cloud providers, how=C2=A0can you guarantee=C2=A0the sa= me when there are a bunch=C2=A0of different (software and hardware) compone= nts that legitimately perform SSL offloading / DPI in front of an AS...=C2= =A0 or the client may just use the proxy server?

<= div>Regards,
Andrii

On Tue, Feb 9, 2021 at 12:43 AM Ne= il Madden <neil.madden@forgerock.com> wrote:
On 9 Feb 2021= , at 06:55, Andrii Deinega <andrii.deinega@gmail.com> wrote:

=EF=BB=BF
Hi WG,

I wonder if t= here are any particular reasons to not make nonce a mandatory parameter for= the current JWT Response for OAuth Token Introspection draft. Or, at least= , force an AS to include the nonce claim in a JWT response when nonce is pr= esented in the introspection request similar to what happens with the simil= ar scenario in the OpenID Connect ID Token?

https://openid.net/specs/openid-connect-core-1_0.= html#:~:text=3DIf%20present%20in%20the%20Authentication%20Request%2C,value%= 20sent%20in%20the%20Authentication%20Request.

T= his will allow to mitigate replay attacks=C2=A0because clients can correlat= e the response with the initial request

ID tokens involve flows using an insecure channel (the browser). = This is not the case for introspection requests which happen over a direct = TLS connection and so are already protected against replay attacks.=C2=A0

=E2=80=94 Neil

ForgeRock values your Privacy

ForgeRock values your Privacy
--000000000000f4002c05baee7606-- From nobody Wed Feb 10 00:15:59 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3AB3A0E22 for ; Wed, 10 Feb 2021 00:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faqDY9-KS4C7 for ; Wed, 10 Feb 2021 00:15:54 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156C63A0E23 for ; Wed, 10 Feb 2021 00:15:53 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id 7so1464732wrz.0 for ; Wed, 10 Feb 2021 00:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=aQK6JyGn4Cz8QxtBhgVOIw1Dx56jmEWfcuPiqGIZWVI=; b=P6IzviEk+2krpUXyAV7GZ56fmFAdwfJBhd4oCneba6t4clhFvz2tChiW48zspMlo67 E7sT4f6736x1xEBptKCOr7KW168937VMjYKLD2BDkBaEaNwOI3G72MCeD6O/0r+3bEvb D36sGhbdEkki/ks2OoR4O1VUmxD2Ay0dMQVts= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=aQK6JyGn4Cz8QxtBhgVOIw1Dx56jmEWfcuPiqGIZWVI=; b=rThEdSyUFCrPmKjYpV2nqE4lKWwqmpnKRVImQxE7Uzh5jNrLovKAfsZJrZNDIKOUP4 idHXJDNO5l6Eha+oR8j6ae25Jzn6dek0vPZX48tHQXIXti7bj/vZ9D2YD/AlfoIfbDSV 6aq49WBbz4F0jYZdKdjvfhm97ZR3lYMig0dr/o+H24EnbyVab052Nx3D48FYUFEpMRxl A/tH0AYNZSD6I/mwojUj/tP82IfmHxaBTyCIqFyhhieFKv0AiJVj6Psz0+snywogqG3Y orUAF32ZwlqJr4M925T907HXWseGASWoLi7IBeeobL9rG3YPzBRF1zeu5FacvcmdYgFz qujg== X-Gm-Message-State: AOAM530fesOyg4nKW2Fb7xed212ntHnVRj64Qt7SUhPdBXegMDp+ZazH 2E82+OO8dy2Qb4yKiACBdHyKu4DKORfn11MiEJAqITnFjdDDWHnXSpZeCCS7660oeL/dErI/JA= = X-Google-Smtp-Source: ABdhPJwkOOhhfWlA0hrdoHicWLkwC6/9UIQ22p2H1tG83RYU5dTfytNleQM4qvn5CGdWsvefWjgGGA== X-Received: by 2002:a5d:654f:: with SMTP id z15mr2258925wrv.46.1612944952172; Wed, 10 Feb 2021 00:15:52 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y63sm1484847wmd.21.2021.02.10.00.15.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Feb 2021 00:15:51 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Wed, 10 Feb 2021 08:15:49 +0000 Message-Id: <54711021-47F1-4F69-8CCC-D96271A47474@forgerock.com> References: Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org In-Reply-To: To: Andrii Deinega X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-A7A93B8D-03F1-40FA-8D45-85AF193B89AC Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 08:15:57 -0000 --Apple-Mail-A7A93B8D-03F1-40FA-8D45-85AF193B89AC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > On 9 Feb 2021, at 22:04, Andrii Deinega wrote: >=20 > =EF=BB=BF > I still don't see how your #1 and #3 points mitigate the replay attack wh= en an attacker somehow eavesdrops a successful response from an AS (yes, it= 's signed by a public key) and then starts to replay it for other requests = from the same client. The point of #1 is that an attacker that has compromised the communication = channel between the AS and client can do much more than replay introspectio= n responses. In particular they can replace the AS=E2=80=99s public key wit= h their own and then sign their own introspection JWTs, with whatever nonce= in them that they like (they can easily see the nonce in the request).=20 They can also steal access tokens and almost certainly also steal user sess= ion cookies and manipulate authorization responses from users to change the= scopes that are approved for different requests.=20 It=E2=80=99s absolutely essential that ASs and clients ensure the TLS conne= ction between them is secure.=20 The stated purpose of JWT introspection responses is for non-repudiation. I= t=E2=80=99s not intended as a replacement for TLS. Within that context =E2= =80=9Ciat=E2=80=9D is sufficient proof of freshness.=20 >=20 > The main problem here is that the client doesn't have a way to correlate = the introspection response with the initial introspection request. In a properly secured environment this guaranteed by TLS (and even TCP).=20 >=20 > Regarding #2, it's true that there are many proxies that do this and that= . In practice, you don't always have control over the infrastructure where = you may run your AS as I was saying before. Right - so trying to solve this issue by replacing TLS with another technol= ogy that is just as susceptible to the problem is not a real solution.=20 =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail-A7A93B8D-03F1-40FA-8D45-85AF193B89AC Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 9 Feb 2021, at 22:04, Andrii Deinega <= andrii.deinega@gmail.com> wrote:

=EF=BB=BF
I still don't see h= ow your #1 and #3 points mitigate the replay attack when an attacker someho= w eavesdrops a successful response from an AS (yes, it's signed by a public= key) and then starts to replay it for other requests from the same client.=

The point of #1 is that an= attacker that has compromised the communication channel between the AS and= client can do much more than replay introspection responses. In particular= they can replace the AS=E2=80=99s public key with their own and then sign = their own introspection JWTs, with whatever nonce in them that they like (t= hey can easily see the nonce in the request). 

They can also steal access tokens and almost certainly also steal user se= ssion cookies and manipulate authorization responses from users to change t= he scopes that are approved for different requests. 

It=E2=80=99s absolutely essential that ASs and clients ensure the T= LS connection between them is secure. 

The st= ated purpose of JWT introspection responses is for non-repudiation. It=E2= =80=99s not intended as a replacement for TLS. Within that context =E2=80= =9Ciat=E2=80=9D is sufficient proof of freshness. 


The main problem here= is that the client doesn't have a way to correlate the introspection respo= nse with the initial introspection request.

In a properly secured environment this guaranteed by TLS (= and even TCP). 


Regarding #2, it's true that there are many proxies that= do this and that. In practice, you don't always have control over the infr= astructure where you may run your AS as I was saying before.

Right - so trying to solve this issue by = replacing TLS with another technology that is just as susceptible to the pr= oblem is not a real solution. 

=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail-A7A93B8D-03F1-40FA-8D45-85AF193B89AC-- From nobody Thu Feb 11 13:43:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760A23A0BF1; Thu, 11 Feb 2021 13:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoqPwt09N5mn; Thu, 11 Feb 2021 13:43:07 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C2F3A0962; Thu, 11 Feb 2021 13:43:07 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id lg21so12342758ejb.3; Thu, 11 Feb 2021 13:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jqtj2fh1k7yhUgW60aQhvywemx9eOv0vquDs4vmCtjo=; b=NDoS9MtumDdpvzr6HHALlJLXRV+0b9VDCULXwkR7H3Xnd5yYqePbFDwB4P4dJAhw5d TqURffHRjlotxv63rruylKiwGSRR9L8CcaoL70pHqX8yXENQBSUcK2qGxvRQWgNBzoUt OupAwTbO2BwDPp3HmxhK3x5iFUDrdDCtELlQ4Dcn3arCBizg8+zKLmA8osKq/kaAnIfy 2GrvSJFOU+ZoHHmDF+FJf450Zxy1gBGVIOLKdZ1VqQ99Kc50Yx1Nc8ARvtwcyrgw0IC+ q7HPp2Ep4loZyrrcK3SeRT7KZdUSMsecK3y4H+d5SC1jTUlBoHiXNu2Od3vm/mZ5tDX7 TaiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jqtj2fh1k7yhUgW60aQhvywemx9eOv0vquDs4vmCtjo=; b=cytmuPnBzGbOoU6p7fHRA7tPHvxn9HYRh2NMimZPBT655FJnFr5Y7IRoorvhY1eWs6 IEHn/O5SLmXP6MO7K0VSoXi+GB4kDKiHmeOqfc8RQtuPp6oJxH2/aEXsXjYzEXpYPL+9 LMika9KNTXKDZlcyHGJ9xNy5Igh4Q9eWa5ex6a7HnXsKexk18ijxRajseis+2fGSDeF/ QviPdnqCnP/zm1sG5XseD2ysfu35/IzZ1V0jDp9Wyqhmv6WR70oH82tyC12PHsPRFD/4 2ta/4+SWgOZbmW+h4XledrmJc/BXPZDOUdUnsnV+W7qBjLJie1jGjimS9fJOcWkd/ioC vg/w== X-Gm-Message-State: AOAM531/Vk60FgO7YSiRwWvE3fyxs4k+yr24AVduyUwR+3s6kl/uoHN1 dt9RKtk8It+yJ7Ti3iyUe1/O4QLFYxyTnKkrl/w= X-Google-Smtp-Source: ABdhPJyE9biglpthHgKmze4SG0v2a5xWDy+E4VBoEtncH8PwnXwyZjg/TVyOyKCfCuD7X96HPPQwesxuY0duDtZdElo= X-Received: by 2002:a17:906:ad98:: with SMTP id la24mr10574580ejb.315.1613079784319; Thu, 11 Feb 2021 13:43:04 -0800 (PST) MIME-Version: 1.0 References: <54711021-47F1-4F69-8CCC-D96271A47474@forgerock.com> In-Reply-To: <54711021-47F1-4F69-8CCC-D96271A47474@forgerock.com> From: Andrii Deinega Date: Thu, 11 Feb 2021 13:42:53 -0800 Message-ID: To: Neil Madden Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org Content-Type: multipart/alternative; boundary="00000000000089ec6805bb16676d" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:43:10 -0000 --00000000000089ec6805bb16676d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the response! Unfortunately, I'm still not convinced that there is no need for nonce. Based on the draft, I don't know how it's possible to achieve a =E2=80=9Cst= ronger assurance that the authorizationserver issued the token introspection response for an access token, includingcases where the authorization server assumes liability for the content of thetoken introspection response =E2=80=9D if we can't guarantee that a client will always get the response to its initial introspect request, or in other words, old communications can be never reused (the iat claim isn't going to be sufficient for that). Let's put aside those attackers for a moment and say we experience some awfully wrong caching issues that can happen anywhere between an AS and a client... where the client gets a cached response for its previous requests which isn't expected. How can it be prevented? Regards, Andrii On Wed, Feb 10, 2021 at 12:15 AM Neil Madden wrote: > > On 9 Feb 2021, at 22:04, Andrii Deinega wrote: > > =EF=BB=BF > I still don't see how your #1 and #3 points mitigate the replay attack > when an attacker somehow eavesdrops a successful response from an AS (yes= , > it's signed by a public key) and then starts to replay it for other > requests from the same client. > > > The point of #1 is that an attacker that has compromised the communicatio= n > channel between the AS and client can do much more than replay > introspection responses. In particular they can replace the AS=E2=80=99s = public key > with their own and then sign their own introspection JWTs, with whatever > nonce in them that they like (they can easily see the nonce in the > request). > > They can also steal access tokens and almost certainly also steal user > session cookies and manipulate authorization responses from users to chan= ge > the scopes that are approved for different requests. > > It=E2=80=99s absolutely essential that ASs and clients ensure the TLS con= nection > between them is secure. > > The stated purpose of JWT introspection responses is for non-repudiation. > It=E2=80=99s not intended as a replacement for TLS. Within that context = =E2=80=9Ciat=E2=80=9D is > sufficient proof of freshness. > > > The main problem here is that the client doesn't have a way to correlate > the introspection response with the initial introspection request. > > > In a properly secured environment this guaranteed by TLS (and even TCP). > > > Regarding #2, it's true that there are many proxies that do this and that= . > In practice, you don't always have control over the infrastructure where > you may run your AS as I was saying before. > > > Right - so trying to solve this issue by replacing TLS with another > technology that is just as susceptible to the problem is not a real > solution. > > =E2=80=94 Neil > > > ForgeRock values your Privacy --00000000000089ec6805bb16676d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thank you fo= r the response! Unfortunately, I'm still not convinced that there is no need for nonce.

=C2=A0

Based on the draft, I don'= ;t know how it's possible to achieve a =E2=80=9Cst= ronger assurance that the authorizationserver issued the token introspectio= n response for an access token, includingcases where the authorization serv= er assumes liability for the content of thetoken introspection response= =E2=80=9D if we can't guarantee that a client will always get the response to its initial introspect request, or in other words, old communications can be never reused (the iat claim isn't going to be suf= ficient for that).

=C2=A0

Let's put aside those attackers for a moment and say we experience some awfully wrong caching iss= ues that can happen anywhere between an AS and a client... where the client get= s a cached response for its previous requests which isn't expected. How can= it be prevented?

<= br>

Regards,=

Andrii



On Wed, Feb 10, 2021 at 12:15 AM Neil Madden <neil.madden@forgerock.com> wro= te:

On 9 Feb 2021, at 22:04, Andrii Deinega <andrii.deinega@gmail.com> wrote:
=
=EF=BB=BF=
I still don't see how your #1 and #3 points mitigate t= he replay attack when an attacker somehow eavesdrops a successful response = from an AS (yes, it's signed by a public key) and then starts to replay= it for other requests from the same client.

The point of #1 is that an attacker that has compromised = the communication channel between the AS and client can do much more than r= eplay introspection responses. In particular they can replace the AS=E2=80= =99s public key with their own and then sign their own introspection JWTs, = with whatever nonce in them that they like (they can easily see the nonce i= n the request).=C2=A0

They can also steal access t= okens and almost certainly also steal user session cookies and manipulate a= uthorization responses from users to change the scopes that are approved fo= r different requests.=C2=A0

It=E2=80=99s absolutel= y essential that ASs and clients ensure the TLS connection between them is = secure.=C2=A0

The stated purpose of JWT introspect= ion responses is for non-repudiation. It=E2=80=99s not intended as a replac= ement for TLS. Within that context =E2=80=9Ciat=E2=80=9D is sufficient proo= f of freshness.=C2=A0

<= div dir=3D"ltr">
The main problem here is that the client doesn't ha= ve a way to correlate the introspection response with the initial introspec= tion request.

In a properly= secured environment this guaranteed by TLS (and even TCP).=C2=A0

=

Regarding #= 2, it's true that there are many proxies that do this and that. In prac= tice, you don't always have control over the infrastructure where you m= ay run your AS as I was saying before.
Right - so trying to solve this issue by replacing TLS with ano= ther technology that is just as susceptible to the problem is not a real so= lution.=C2=A0

=E2=80= =94 Neil

ForgeRock values your Privacy --00000000000089ec6805bb16676d-- From nobody Thu Feb 11 13:47:52 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C643A0C28 for ; Thu, 11 Feb 2021 13:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-P9n6wkN_y0 for ; Thu, 11 Feb 2021 13:47:48 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C295A3A0C20 for ; Thu, 11 Feb 2021 13:47:47 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id i8so12325149ejc.7 for ; Thu, 11 Feb 2021 13:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VGPGGeV3K6i0mQXHzk/B+y5do/pSTFILzTUssOtOeTI=; b=lCos0jpkRBWwdEI9Sm4af8k3OqtNq+xNuhyOkZhY2HKWG+Eq2Z+WiaLvobsnVXg2Wm rAcvOZeEKZ/4N6bTo64dJ9FjRLSjQkJjeT2ph+3zGsE+kFjXzXuy8hXOug1SWQDiTgcU uWoBD81mXjfxmSFj0fKe7hj0ou3YSPPtLWziQ9T83a7BZfVk3RXFgz005ArW4ct7wmv7 PMm+8HtqXFNygkUfd/kjag1JrPmlYDJEBLUEfp5kxTncM0USCVzfy3vzcnu/0yyLgeHQ L9ZlvD+7olYHf+lfYXAQ6nr+4i5SijUy23NM/+mAfL59RlLIeJgWat0AKTW7SbnEZUK1 qatA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VGPGGeV3K6i0mQXHzk/B+y5do/pSTFILzTUssOtOeTI=; b=bWNQVNuiBspBckBLjM5rtISQx32lidc0cdPyi+UzkEYHJAzNh9HxCeM8gUC41WAoN4 PbxW7xPzXZqZzq8bFBSIcxsU4dNvtyro2/qnLn1wbmAtlIz23uNPBFXU4LNsDVJDpygU AnhdRDhV0O2r1x7ilS6Q6K56FTwlJ9cTlMr2JcpuNJQuBWhfnMcUNyBm+kFqCZXTPjPV IoHifBTGnUEHQND3TUpUAfU4sX0Zb9XWupXrYFo3nEPyBjdWqKMEorilq3fJIpqpUpx+ YBf3vB8mzJA2v4TlQWV03wmZ0ikB7oj//euPNtMOj2WRu7r1fnzDi21ayLnHS8fZNsED OXaA== X-Gm-Message-State: AOAM531uUUlR8x315S0rca9wmMvlsmv2kW3xCbgIgwxouh9aTI6nHXlD dcy5UshqfOkG6gQT+0DodHl82x/PHK2BCBJn9PfiB3PrUu7j5A== X-Google-Smtp-Source: ABdhPJyehPkzOdy833N651KvRj8A5g6jAIWex7TKRj88d9egx4YyGYM8wV8LpkdTT4ynU6dK+sAAAaPnXNwRVtQcdYg= X-Received: by 2002:a17:907:d25:: with SMTP id gn37mr10440863ejc.303.1613080065010; Thu, 11 Feb 2021 13:47:45 -0800 (PST) MIME-Version: 1.0 References: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com> In-Reply-To: From: Andrii Deinega Date: Thu, 11 Feb 2021 13:47:34 -0800 Message-ID: To: Vladimir Dzhuvinov Cc: Warren Parad , oauth Content-Type: multipart/alternative; boundary="00000000000044f01005bb1678cf" Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:47:51 -0000 --00000000000044f01005bb1678cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vladimir, What would be a value in the aud claim for refresh tokens? Regards, Andrii On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov wrote: > Hi Warren, > On 08/02/2021 17:59, Warren Parad wrote: > > None of that justified explicitly stating that refresh token introspectio= n > shouldn't be done. At best it suggests that we should explicitly add > language in the draft to directly encourage it. > > Did you mean discourage? > > But if an AS wants to support it, we shouldn't stop them, or suggest that > they can't do it. > > The current draft doesn't mention refresh tokens at all. Its subject is > the introspection of access tokens by authenticated resource servers and > returning the response as a signed JWT. The use of refresh tokens at the > introspection endpoint, per RFC 7662, is not forbidden by the draft. > > > > Allowing refresh tokens to be introspected can also create a conflict wit= h >> the sec recommendation to rotate them > > > Not following, can you explain this further? > > I just double checked the rotation spec. Use that triggers rotation is > clearly specified as "access token response", so there should actually be > no issues with confusing introspection as use. > > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4= .13.2 > > RFC 7662 also seems to imply that a public client with a refresh token > should not normally be able to introspect it, because it can't authentica= te > to the AS. > > https://tools.ietf.org/html/rfc7662#section-2.2 > > To prevent token scanning attacks, the endpoint MUST also require > some form of authorization to access this endpoint, such as client > authentication as described in OAuth 2.0 [RFC6749 ] or a separate > OAuth 2.0 access token such as the bearer token described in OAuth > 2.0 Bearer Token Usage [RFC6750 ]= . The methods of managing and > validating these authentication credentials are out of scope of this > specification. > > > Vladimir > > > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov > wrote: > >> At first it may appear that allowing refresh tokens at the introspection >> endpoint may be a logical thing to do, but in practice there are issues >> with that and from an OAuth 2.x perspective it's not easy to justify. >> >> If the point is to let clients check what authorization they have been >> given OAuth 2.0 already provides a std way to do that - in the access to= ken >> response - the "scope" parameter: >> >> https://tools.ietf.org/html/rfc6749#section-5.1 >> >> RAR has a similar parameter: >> >> https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1 >> >> If the point is to find if a refresh token is still valid - this can be >> found out by simply using it. Allowing refresh tokens to be introspected >> can also create a conflict with the sec recommendation to rotate them. S= o >> thus it may be a better idea to not let clients assume too much about th= em. >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-= 2.2.2 >> >> If the AS is going to expose refresh token data to a client it will also >> have to make a careful judgement what data it exposes. >> >> https://tools.ietf.org/html/rfc7662#section-2.2 >> >> For instance "sub". OAuth 2.x in the relation between AS and client >> actually has no concept or definition of subject / end-user identifier. = And >> this is done for a good reason, because it's not a user authentication >> protocol. OIDC was designed for that. And to prevent tracking of users a= nd >> other privacy issues OIDC also specifies pairwise subject IDs. The plain >> OAuth 2.x world doesn't have this. >> >> Vladimir >> On 08/02/2021 11:07, Warren Parad wrote: >> >> It doesn't work that way. You suggested to add language to the draft, >> that means the burden of proof is on you to justify adding it. >> >> Otherwise I could just say why not? >> >> And I can go stronger, what's the purpose of nho introspection endpoint >> at all, and why encourage sending access tokens to the AS? >> >> Even if you can justify access tokens, there currently isn't evidence >> provided why we should explicity discourage. >> >> >> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt >> wrote: >> >>> >>> >>> Am 08.02.2021 um 00:56 schrieb Warren Parad : >>> >>> =EF=BB=BF >>> >>>> I=E2=80=98m therefore leaning towards explicitly stating in our draft = that it >>>> is not intended to be used with refresh tokens. >>> >>> I'm not following, why explicitly state that it isn't intended. If an A= S >>> wants to provide a similar JSON response to a query with the refresh to= ken, >>> why not encourage that? >>> >>> >>> Why should we encourage it? >>> >>> >>> Warren Parad >>> >>> Founder, CTO >>> Secure your user data and complete your authorization architecture. >>> Implement Authress >>> >>> . >>> >>> >>> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt >> 40lodderstedt.net@dmarc.ietf.org> wrote: >>> >>>> Hi Andrii, >>>> >>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >>> >: >>>> >>>> =EF=BB=BF >>>> Hi Torsten, >>>> >>>> thank you for your response. >>>> >>>> My use case is pretty straight forward >>>> >>>> An OAuth client queries the AS to determine the active state of an >>>> access token and gets the introspection response which indicates that = this >>>> access token is active (using RFC7662). >>>> >>>> An OAuth client queries the AS to determine the active state of a >>>> refresh token and gets the introspection response which indicates that= this >>>> refresh token is active (using RFC7662). >>>> >>>> An OAuth client queries the AS to determine the active state of an >>>> access token and gets the introspection response (JWT) which indicates >>>> that this access token is active (using this draft). >>>> >>>> Now, an OAuth client queries the AS to determine the active state of a >>>> refresh token (using this draft)... How will the introspection respons= e >>>> look like assuming that the client provides the valid refresh token an= d >>>> technically, nothing stops it from doing so. >>>> >>>> >>>> why should the state be provided as JWT?I think the plain JSON respons= e >>>> is sufficient in that case. I also think using token introspection fo= r >>>> checking the state of a token from the client side has limited utility= . The >>>> definitive decision is always made when the client tries to access a >>>> resource. >>>> >>>> I=E2=80=98m therefore leaning towards explicitly stating in our draft = that it >>>> is not intended to be used with refresh tokens. >>>> >>>> best regards, >>>> Torsten. >>>> >>>> >>>> Regards, >>>> Andrii >>>> >>>> >>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt < >>>> torsten@lodderstedt.net> wrote: >>>> >>>>> Hi Andrii, >>>>> >>>>> thanks for your post. >>>>> >>>>> The draft is intended to provide AS and RS with a solution to exchang= e >>>>> signed (and optionally encrypted) token introspection responses in or= der to >>>>> provide stronger assurance among those parties. This is important in = use >>>>> cases where the RS acts upon the introspection response data and want= s the >>>>> AS to take liability re the data quality. >>>>> >>>>> I=E2=80=99m not sure whether there are similar use cases if a client >>>>> introspects a refresh token. What is your use case? >>>>> >>>>> best regards, >>>>> Torsten. >>>>> >>>>> > Am 07.02.2021 um 08:41 schrieb Andrii Deinega < >>>>> andrii.deinega@gmail.com>: >>>>> > >>>>> > Hi WG, >>>>> > >>>>> > draft-ietf-oauth-jwt-introspection-response-10 states that "OAuth >>>>> 2.0 Token Introspection [RFC7662] specifies a method for a protected >>>>> resource to query an OAuth 2.0 authorization server to determine the = state >>>>> of an access token and obtain data associated with the access token."= which >>>>> is true. Although, according to RFC7662, the introspection endpoint a= llows >>>>> to introspect a refresh token as well. Hence, the question I have is = how >>>>> will a token introspection response look like when the caller provide= s a >>>>> refresh token and sets the "Accept" HTTP header to >>>>> "application/token-introspection+jwt"? >>>>> > >>>>> > I expect there will be no differences, right? >>>>> > >>>>> > If so, I suggest to >>>>> > =E2=80=A2 replace "a resource server" by "the caller" in sect= ion 4 >>>>> (Requesting a JWT Response) >>>>> > =E2=80=A2 change "If the access token is invalid, expired, re= voked" by >>>>> "If a given token is invalid, expired, revoked" in section 5 (JWT Res= ponse) >>>>> > If not, my suggestion would be to clarify what the AS should do whe= n >>>>> it asked to introspect the refresh token in general and additionally,= what >>>>> should happen in the same case based on the type of the caller from t= he >>>>> AS's point of view. >>>>> > >>>>> > Regards, >>>>> > Andrii >>>>> > >>>>> >>>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> -- >> Vladimir Dzhuvinov >> >> -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000044f01005bb1678cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vladimir,

What would be a value in t= he aud claim for refresh tokens?

Regards,
Andrii


On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuv= inov <vladimir@connect2id.com= > wrote:
=20 =20 =20

Hi Warren,

On 08/02/2021 17:59, Warren Parad wrote:
=20
None of that justified explicitly stating that refresh token introspection shouldn't be done. At best it suggests that we should explicitly add language in the draft to directly encourage it.

Did you mean discourage?

But if an AS wants to support it, we shouldn't s= top them, or suggest that they can't do it.

The current draft doesn't mention refresh tokens at all. Its subject is the introspection of access tokens by authenticated resource servers and returning the response as a signed JWT. The use of refresh tokens at the introspection endpoint, per RFC 7662, is not forbidden by the draft.



Allowing refres= h tokens to be introspected can also create a conflict with the sec recommendation to rotate them

Not following, can you explain this further?

I just double checked the rotation spec. Use that triggers rotation is clearly specified as "access token response", s= o there should actually be no issues with confusing introspection as use.

https://tools.ietf.org/html/draft-= ietf-oauth-security-topics-16#section-4.13.2

RFC 7662 also seems to imply that a public client with a refresh token should not normally be able to introspect it, because it can't authenticate to the AS.

https://tools.ietf.org/html/rfc7662#= section-2.2
   To prevent token scanning attacks, the endpoint MUST also r=
equire
   some form of authorization to access this endpoint, such as client
   authentication as described in OAuth 2.0 [RFC6749] or a separate
   OAuth 2.0 access token such as the bearer token described in OAuth
   2.0 Bearer Token Usage [RFC6750].  The methods of managing and
   validating these authentication credentials are out of scope of this
   specification.

Vladimir

Warren Pa= rad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0Authress.


On Mon, Feb 8, 2021 at 4:13 P= M Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify.

If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope&q= uot; parameter:

https://tools.ietf.org/html/rfc6749#section-5.1

RAR has a similar parameter:

https://tools.ietf.org/html/draft-ietf-= oauth-rar-03#section-3.4.1

If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them.

https://tools.ietf.org/html= /draft-ietf-oauth-security-topics-16#section-2.2.2

If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes.

https://tools.ietf.org/html/rfc7662#section-2.2

For instance "sub". OAuth 2.x in the relation betw= een AS and client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this.

Vladimir

On 08/02/2021 11:07, Warren Parad wrote:
It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it.

Otherwise I could just say why not?

And I can go stronger, what's the purpose of nho introspection endpoint at all, and why encourage sending access tokens to the AS?

Even if you can justify access tokens, there currently isn't evidence provided why we should explicity discourage.


On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt <torsten@lodd= erstedt.net> wrote:


Am 08.02.2021 um 00:56 schrieb Warren Parad <wparad@rhosys= .ch>:

=EF=BB=BF
I=E2=80=98m therefore leaning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.
I'm not following, why explicitly state that it isn't intended. If an AS wants to provide a similar JSON response to a query with the refresh token, why not encourage that?

Why should we encourage it?=C2=A0

Warren Parad

Founder, CTO

Sec= ure your user data and complete your authorization architecture. Implement=C2=A0Authress<= /a>.


On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Andrii,

Am 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi=C2=A0Torsten,

thank you for your response.

My use case is pretty straight=C2=A0forward

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).

An OAuth client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).

Now, an OAuth client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.=C2=A0=C2=A0= I also think using token introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource.=C2=A0

I=E2=80=98m therefore leaning towa= rds explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.


Regards,
Andrii


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.

The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality.

I=E2=80=99m not sure wh= ether there are similar use cases if a client introspects a refresh token. What is your use case?

best regards,
Torsten.=C2=A0

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <andrii.deinega@gmail.com>:
>
> Hi WG,
>
> draft-ietf-oauth-jwt-in= trospection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." whi= ch is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP= header to "application/token= -introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0=E2=80=A2 replace "a resource server= " by "the caller&quo= t; in section 4 (Requesting a JWT Response)
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0=E2=80=A2 change "If the access tok= en is invalid, expired, revoked" by "= If a given token is invalid, expired, revoked" in sectio= n 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS'= s point of view.
>
> Regards,
> Andrii
>

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

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

--=20
Vladimir Dzhuvinov
--=20
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000044f01005bb1678cf-- From nobody Thu Feb 11 14:01:18 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD553A0CB5 for ; Thu, 11 Feb 2021 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJqtjPaCzw-7 for ; Thu, 11 Feb 2021 14:01:15 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1A63A0CA2 for ; Thu, 11 Feb 2021 14:01:14 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11BM1CN1004187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Feb 2021 17:01:13 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_DA47148D-23F5-492C-9C1F-1B1D55DEE341" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Thu, 11 Feb 2021 17:01:12 -0500 To: oauth X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [OAUTH-WG] Authorization Header Encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:01:17 -0000 --Apple-Mail=_DA47148D-23F5-492C-9C1F-1B1D55DEE341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The HTTP Working Group opened an issue for discussion in relation to the = updated HTTP semantics specification. The core of the issue is the = format of the =E2=80=9CAuthorization=E2=80=9D header, which of course = gets used by the =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750. https://github.com/httpwg/http-core/issues/733 = As it turns out, Bearer defines a more limited character set than is = allowed by core HTTP, and doesn=E2=80=99t follow the HTTP guidelines and = definitions for the Authorization header. There were a few observations = on the call: - The Bearer spec was limited because OAuth tokens were also allowed in = HTTP URLs and form parameters (and therefore had to have a more limited = character set) - In practice people don=E2=80=99t actually restrict the values they = put into this field; pretty much any implementation is just going to = concatenate whatever access token value they get to the magic word = =E2=80=9CBearer=E2=80=9D and send it - It=E2=80=99s not likely (or in my opinion proper) for the HTTP spec = to change to address the oddities of RFC6750 and decisions that were = made many years ago So the question is, what do we do about it? We could do a revision of = 6750 that reflects reality better, pretty much just changing the ABNF. Or, we could update the definition of the Bearer header in the upcoming = OAuth 2.1 specification. Are there other options? =E2=80=94 Justin --Apple-Mail=_DA47148D-23F5-492C-9C1F-1B1D55DEE341 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = HTTP Working Group opened an issue for discussion in relation to the = updated HTTP semantics specification. The core of the issue is the = format of the =E2=80=9CAuthorization=E2=80=9D header, which of course = gets used by the =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750.

https://github.com/httpwg/http-core/issues/733

As it turns out, Bearer = defines a more limited character set than is allowed by core HTTP, and = doesn=E2=80=99t follow the HTTP guidelines and definitions for the = Authorization header. There were a few observations on the = call:

 - = The Bearer spec was limited because OAuth tokens were also allowed in = HTTP URLs and form parameters (and therefore had to have a more limited = character set)
 - In practice people don=E2=80=99= t actually restrict the values they put into this field; pretty much any = implementation is just going to concatenate whatever access token value = they get to the magic word =E2=80=9CBearer=E2=80=9D and send = it
 - It=E2=80=99s not likely (or in my = opinion proper) for the HTTP spec to change to address the oddities of = RFC6750 and decisions that were made many years ago

So the question is, what = do we do about it? We could do a revision of 6750 that reflects reality = better, pretty much just changing the ABNF.

Or, we could update the definition of = the Bearer header in the upcoming OAuth 2.1 specification.

Are there other = options?

 =E2=80=94 Justin

= --Apple-Mail=_DA47148D-23F5-492C-9C1F-1B1D55DEE341-- From nobody Fri Feb 12 00:09:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961C23A1371 for ; Fri, 12 Feb 2021 00:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvcp3VbtRJrl for ; Fri, 12 Feb 2021 00:09:08 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729263A1370 for ; Fri, 12 Feb 2021 00:09:08 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id i8so14125189ejc.7 for ; Fri, 12 Feb 2021 00:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=bp+zqZEFLmkbNxGPr7w7yMvVM9Xv7RKJDtSWOckUdIQ=; b=OrKbeW3zA/cOMnh3j4JsSJL5Doz4VkAUksjvF2O9EvHFu3J1sCoBSJ06feH1rv9ruW WAkQXsyV1ee8zeZrS2GYM/nRmXeUFsVhBUIjlw8n8Ry9PEuJ6pr4dfXqhWqYLfsWAloX wfRQfY4I8V9wJ05rJH5doek+wd1PY+wEbQNQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=bp+zqZEFLmkbNxGPr7w7yMvVM9Xv7RKJDtSWOckUdIQ=; b=memlU1mU6n5t78Dlj9pfVGxak0RBAcX3Tz1/wm/vsJKfK0H3FnV7HGSsm6sroVKRoT vQ1yQDW2bq4YoGvGTeCnjewMisKCjcy0FalkqKGlabIsyURp5cn8Mm+V8MAZ8wv8yROK Sv+v6pV85a6vzPWMZpSrW9OUj5W5MqKxjCdV36RXrrB04Enh0J4umND3NU8LeIcY8McY ualfXi8EwHNkPEtK4XtIoqgTtONro5LdKsSHXalzsY7el1Ur6JpyEhSj8BMuc1CqQjrm j+Cnd6CKBWqGdKGXytm5qrQluQNBsC2QNSEeSEhKIPwoJP7HeyLgyv+W5gJXV+V2UmL+ VlTA== X-Gm-Message-State: AOAM533J2CY19OEzoqkriFfyvOr+rewzEmgmDch4BstGOVxh9R5P5QgK 2XQnoer4watxlFf/evvWDjHn9FvD3RkWStwqZUuKZBxr8CkQHDcNeY63G3XoTfiRal4XBv1EUg= = X-Google-Smtp-Source: ABdhPJwEWFS84mkcHIxSmTdoy+bZO66qn0wUl47BD5SjGtSQONY36H3g4tD1uZcZIagc+Y9PCd0L+w== X-Received: by 2002:a17:907:9702:: with SMTP id jg2mr1914321ejc.48.1613117346725; Fri, 12 Feb 2021 00:09:06 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id r23sm5825535ejd.56.2021.02.12.00.09.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Feb 2021 00:09:06 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Fri, 12 Feb 2021 08:09:05 +0000 Message-Id: <26C6C0BB-9C1B-464C-A393-2FEEC0981F41@forgerock.com> References: Cc: oauth , draft-ietf-oauth-jwt-introspection-response@ietf.org In-Reply-To: To: Andrii Deinega X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-F3F8DE8F-E853-42AC-9C07-08529D60499B Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 08:09:11 -0000 --Apple-Mail-F3F8DE8F-E853-42AC-9C07-08529D60499B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > On 11 Feb 2021, at 21:43, Andrii Deinega wrote= : >=20 > =EF=BB=BF > Thank you for the response! Unfortunately, I'm still not convinced that t= here is no need for nonce. > =20 > Based on the draft, I don't know how it's possible to achieve a =E2=80=9C= stronger assurance that the authorizationserver issued the token introspect= ion response for an access token, includingcases where the authorization se= rver assumes liability for the content of thetoken introspection response= =E2=80=9D if we can't guarantee that a client will always get the response = to its initial introspect request, or in other words, old communications ca= n be never reused (the iat claim isn't going to be sufficient for that). The whole point about liability is being able to establish it after the fac= t. A nonce is only meaningful within the initial interaction and so is no h= elp at all for establishing liability.=20 > =20 > Let's put aside those attackers for a moment and say we experience some a= wfully wrong caching issues that can happen anywhere between an AS and a cl= ient... where the client gets a cached response for its previous requests w= hich isn't expected. How can it be prevented? 1. TLS. 2. Cache-Control.=20 =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail-F3F8DE8F-E853-42AC-9C07-08529D60499B Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 11 Feb 2021, at 21:43, Andrii Deinega <= ;andrii.deinega@gmail.com> wrote:

=EF=BB=BF

Thank you for the response! Unfortunately, I'm still not convinced that there is no need for nonce.

 

Based on the draft, I don't know how it's possible to achieve a =E2=80=9Cstronger= assurance that the authorizationserver issued the token introspection resp= onse for an access token, includingcases where the authorization server ass= umes liability for the content of thetoken introspection response=E2=80= =9D if we can't guarantee that a client will always get the response to its initial introspect request, or in other words, old communications can be never reused (the iat claim isn't going to be suffici= ent for that).


The whole= point about liability is being able to establish it after the fact. A nonc= e is only meaningful within the initial interaction and so is no help at al= l for establishing liability. 

 

Let's put aside those attackers for a moment and say we experience some awfully wrong caching iss= ues that can happen anywhere between an AS and a client... where the client get= s a cached response for its previous requests which isn't expected. How can it = be prevented?


1. TLS= . 2. Cache-Control. 

=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail-F3F8DE8F-E853-42AC-9C07-08529D60499B-- From nobody Fri Feb 12 12:46:09 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15963A0E21 for ; Fri, 12 Feb 2021 12:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4-1b1UaZiOU for ; Fri, 12 Feb 2021 12:46:05 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC89F3A0E1B for ; Fri, 12 Feb 2021 12:46:05 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id t2so312549pjq.2 for ; Fri, 12 Feb 2021 12:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-transfer-encoding :mime-version; bh=BNP9onb1LQKmmN1hWZVfq+7j9EvbSHf1xVJle8yyGE4=; b=DoatqCaFuvmmodynCP6bTRkQoyDbplWRo41ita8gPU3zxea4wciHCGPjiS+8E6pFVd LbujWLhkOCgJZHdlCZRSj6IvzKXRFnqz9pqZihTLXjk9wacmySkSrjyr5rt9X5s5OQ+Z HIOrs5bz1owmjPHOqhosssqodvHFcgAhCXgfI6nZPYAUp/qWUP4vTguGG98xKosd0EEH uJ7ypoooo/Y3rA/8nfO8OVcMlcK1Be1aSq7mYg3GztpC1SZU/YkY4xW3eYQfAKK2bcT7 bGuetyV6gtOXhHx+SFwkRb0OiXV+/+PPkP4ufX/Z5Caw2pBjpGNUXdh8FI8Ky/tzHQhE KMIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language :content-transfer-encoding:mime-version; bh=BNP9onb1LQKmmN1hWZVfq+7j9EvbSHf1xVJle8yyGE4=; b=cPeZ8Ap+Hz29V426lDUJxJfhjfIyor0C1DLz3iXfjIkt0nfW2hqoD4K2N+kKeKACLc aCF3UyAsemzbPWgGCtXcDnGLsU/pSq2Ni7tLgclO5pE+fEVgX6g6n9L4cUaT68E0SjUN eSK4U4e+VCGzB3qIpXvnG5BpiMWK09hNFrFheEUwjw1LD2kicole6mh23/mHn2QbnoQY 6xfo9mX/cY+By9N6ctVshVhIGxXfc/CGmxe9WmCmCq6XoQcY6IdnwwGh8Ku9ShSPQ6GI uUe7O1XIWGtFu0NV+QIS3E/ilM2ID4EX+zn/N1DEbizDaAuQHV4JXUwsX3qFOTWs291y Cplw== X-Gm-Message-State: AOAM531Yu/D4+GFMebKjgEDdggLk5xc9WbaoX2V2ADBdmaJaUfXFhiWb GYWrQ5m35EZyu4rg+Rh+rm32F8KL6U/h6uTERmcMi56YxA3MoxAa5pgpvfeC+andohMM5mVS1Oc QgQsRdpP6nO4IZ+BpnUxcusOnmOyUV27bYy9Z6tNOlEPfwE6W85fG9Yomo4loPRE1fv/6 X-Google-Smtp-Source: ABdhPJzIECdf9BxyiwlmRnmSiH+fgT/eIFxr8ZzWZnYJMZ1DrSFiCD5jhR4eprck/UL5Al3x4vI3UQ== X-Received: by 2002:a17:90a:aa0d:: with SMTP id k13mr4503006pjq.210.1613162763214; Fri, 12 Feb 2021 12:46:03 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id z2sm9682492pfj.100.2021.02.12.12.46.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Feb 2021 12:46:02 -0800 (PST) From: Vittorio Bertocci To: "oauth@ietf.org" , Brian Campbell Thread-Topic: Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSAw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 12 Feb 2021 20:46:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 20:46:08 -0000 RGVhciBhbGwsDQpCcmlhbiBhbmQgeW91cnMgdHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVj aWZpY2F0aW9uIHRoYXQgc2hvd3MgaG93IHRoZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2Vi IGFwcCBjYW4gZGVsZWdhdGUgdG9rZW4gYWNxdWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0 cyBiYWNrZW5kLCBhbmQgcmVxdWVzdCBzdWNoIHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0 IGFjY2VzcyBvZiBwcm90ZWN0ZWQgcmVzb3VyY2VzIGZyb20gdGhlIGZyb250ZW5kIGNvZGUuDQoN ClRoZSBwYXR0ZXJuIGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2 YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFu dHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRl cm0gQkZGIChiYWNrZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQg aW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFjdGl2aXR5LCBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxl bWVudGF0aW9uIGRldGFpbHMgdG8gdGhlIHJlYWRlci4NCldlIGJlbGlldmUgdGhlIHBhdHRlcm4g aGFzIG1lcml0LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdyb3dpbmcgYWRvcHRpb24uIEJ5IGRl bGVnYXRpbmcgYWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIHRoZSBiYWNrZW5kLCB3ZSBhdm9p ZCBtYW55IG9mIHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBwYXJ0cyAoYW5kIGltcGxpZWQgYXR0 YWNrIHN1cmZhY2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNjZXNzIHRva2VucyBmcm9tIGEgdXNl ciBhZ2VudC4gVGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhl IG5lZWQgb2YgcGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3du IHNvcmUgcG9pbnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVs eWluZyBvbiBpdHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vu cy4NCg0KQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gaXMgdmVyeSBzaW1wbGUsIHByb3ZpZGlu ZyBleHBsaWNpdCBndWlkYW5jZSBvbiB0aGUgc2NlbmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50YWdl cy4gIA0KLSBJdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBjcmVhdGUgaW50ZXJvcGVyYWJsZSBTREtz LCB3aGVyZSBmcm9udGVuZCBkZXYgc3RhY2tzIChhbnkgSlMgZmxhdm9yKSBjYW4gYmUgbWl4ZWQg YW5kIG1hdGNoZWQgd2l0aCBjb21wbGlhbnQgYmFja2VuZCBzdGFja3MgKG1pZGRsZXdhcmVzIGlu IG5vZGUsIGphdmEsIEFTUC5ORVQsIFBIUCBldGMpDQotIEl0IGFsbG93cyB1cyB0byBwcm92aWRl IGd1aWRhbmNlIG9uIGhvdyB0byBwcm9wZXJseSB0YWNrbGUgdGhlIHNjZW5hcmlvIGFuZCB3YXJu IGltcGxlbWVudGVycyBhZ2FpbnN0IHNlY3VyaXR5IHJpc2tzIChzY29wZSBlc2NhbGF0aW9ucywg dXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBvZiBhY2Nlc3MgdG9rZW5zLCBldGMpDQotIEl0IGFsbG93 cyB1cyB0byBkaXNjdXNzIChhbmQgd2hlbiBhcHByb3ByaWF0ZSwgcHJvbW90ZSkgdGhpcyBwYXR0 ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dzZXIgYXBwcyBzZWN1cml0eSBndWlkYW5jZSwgYW5kIHBv c2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVyZSBmcm9udGVuZCBvbmx5IGNhbGxzIEFQSSBvbiBpdHMg b3duIGJhY2tlZCAoaGVuY2UgZG9lc27igJl0IG5lZWQgYWNjZXNzIHRva2Vucykgc2ltcGx5IGFz IGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMgbW9yZSBnZW5lcmFsIHBhdHRlcm4NCi0gVGhpcyBhcHBy b2FjaCBtYWtlcyBtb2NraW5nIGFuZCB0ZXN0aW5nIGFwcHMgdmVyeSBlYXN5LCBwb3NzaWJseSBw cmV2ZW50aW5nIGRldmVsb3BlcnMgZnJvbSB3ZWFrZW5pbmcgdGhlIHNlY3VyaXR5IG9mIHRoZWly IHN5c3RlbSAoZWcgdHVybmluZyBvbiBST1BHIG9wdGlvbnMpICBvciB0dXJuaW5nIHRvIHJpc2t5 IHByYWN0aWNlcyBsaWtlIHNjcmFwaW5nDQoNCk5lZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZp Y2F0aW9uIGRvZXNu4oCZdCBlbnRpcmVseSBlbGltaW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRv IGRpcmVjdCB1c2Ugb2YgYWNjZXNzIHRva2VucyBmcm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkg aXMgdGhhdCB0aGUgcGF0dGVybiBpcyBpbiB3aWRlc3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1z dGFuY2VzIGxlYWRpbmcgdG8gdGhhdCAoZWcgZGV2ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJv amVjdCBvbmx5IHdvcmsgd2l0aCBmcm9udGVuZCBzdGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZl cnNlIHByb3hpZXMgbWlnaHQgbm90IGFsd2F5cyBiZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29p bmcgYXdheSBhbnkgdGltZSBzb29uLiBCeSBwcm92aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRo aXMgcGF0dGVybiwgd2UgY2FuIHNpbXBsaWZ5IHRoZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3 aGlsZSBlbnNocmluaW5nIGJhc2ljIHNlY3VyaXR5IGh5Z2llbmUgaW4gc2NlbmFyaW9zIHRoYXQg d291bGQgaGF2ZSBvdGhlcndpc2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLg0KIA0KTG9v a2luZyBmb3J3YXJkIGZvciB5b3VyIGZlZWRiYWNrIQ0KDQpCJlYgIA0KDQrvu79PbiAyLzEyLzIx LCAxMjo0MSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4gd3JvdGU6DQoNCiAgICANCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVy dG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBWaXR0b3JpbyBCZXJ0b2NjaSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYg cmVwb3NpdG9yeS4NCiAgICANCiAgICBOYW1lOgkJZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1i ZmYNCiAgICBSZXZpc2lvbjoJMDANCiAgICBUaXRsZToJCVRva2VuIE1lZGlhdGluZyBhbmQgc2Vz c2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZA0KICAgIERvY3VtZW50IGRhdGU6 CTIwMjEtMDItMTINCiAgICBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2Vz OgkJMTYNCiAgICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9p ZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQNCiAgICBTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgy LXRtaS1iZmYvDQogICAgSHRtbDogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hp dmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRtbA0KICAgIEh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2ktb2F1dGgy LXRtaS1iZmYtMDANCiAgICANCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBob3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxlZ2F0ZSBhY2Nl c3MNCiAgICAgICB0b2tlbiBhY3F1aXNpdGlvbiB0byBhIGJhY2tlbmQgY29tcG9uZW50LiAgSW4g c28gZG9pbmcsIHRoZSBmcm9udGVuZA0KICAgICAgIGNhbiBhY2Nlc3MgcmVzb3VyY2Ugc2VydmVy cyBkaXJlY3RseSB3aXRob3V0IHRha2luZyBvbiB0aGUgYnVyZGVuIG9mDQogICAgICAgY29tbXVu aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0b2tlbnMs IGFuZA0KICAgICAgIHBlcmZvcm1pbmcgb3BlcmF0aW9ucyB0aGF0IGFyZSBmcmF1Z2h0IHdpdGgg c2VjdXJpdHkgY2hhbGxlbmdlcyB3aGVuDQogICAgICAgZXhlY3V0ZWQgaW4gYSB1c2VyIGFnZW50 LCBidXQgYXJlIHNhZmUgYW5kIHdlbGwgcHJvdmVuIHdoZW4gZXhlY3V0ZWQNCiAgICAgICBieSBh IGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQuDQogICAgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAg DQogICAgDQogICAgDQo= From nobody Fri Feb 12 15:38:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385F63A0DC6 for ; Fri, 12 Feb 2021 15:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5LJnRp4Dg-3 for ; Fri, 12 Feb 2021 15:38:39 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7755C3A0DAD for ; Fri, 12 Feb 2021 15:38:39 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id v24so1839458lfr.7 for ; Fri, 12 Feb 2021 15:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FtWOmzIjSilcbAw+clPOsIx6Nzp/xlg7SlJkxOLBgXA=; b=domBBB/av1XkNAqnBLdHILkQo8SjOdwXAmyFlOck9S2fi1PEbAcqGq2842uePmmgw0 l44NXia2/HFiSOXhOLop5sP72yghA3Wef/7Bbo96NZEYjqZHB5B30hSeey61gglQq3nI 7TXMnZO/TL60/DGccCK/UMxSQio32p9vANYzgXh4SY4xq0+ip/VE/NOjbbG9ehwOMVGk b2ZE1mrbLYMtTGIROExUAdknM81utn+oWUs0j59X0HKmAehZhK5PtusaslEbTCqq+68U uG8ELCTW8iat6xK0crdFgJXOfWislQYpjFZmxMEwS910LZxkWTdjzFc/v29166qQHTGp lP+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FtWOmzIjSilcbAw+clPOsIx6Nzp/xlg7SlJkxOLBgXA=; b=NzwnvaqjKHocuCl+AFT/BCx/LEzi6slH4aFqHW/TzSwyTuCo8TbosiK7WRqheocGW2 FaABjS0Ty+z1h+34nAnEitjEnstpYNdaSCSicU+qWW50r+Mvq833PE9t2FwfOBa5ZnsJ wFYS5IdBn24LYaFRnZXjSaR0y5XjBghDVM+lazf5ko9M+p3QeJULbzg1ieYGGFDtj6P7 sVOIs1k4rAmUHLXeT0GDAr5A8ZAHMjAYS9DXNAbjeJO2CPevYYNP9TfBkrAM9t1JD5sa AsASxrWQTFmJ+W7goABMDDBZmUP43KgaVGrQ0F3DiSi6BtdUWhmjdGPdMLqsxtb7fD36 bpFw== X-Gm-Message-State: AOAM532bohd/pSHmdro6babnEQ9nyBZBW/+Dqz5V58KobCMqZrR14mXv thWZnLv/x97PLo+h3esb6LD1KUTsCeOIYZKg/cQVyKiDZ762ckCM3fXgi9J1rr3zddoXGzVhirA O59V79hZPTVSaewBfHv7R9w== X-Google-Smtp-Source: ABdhPJz3LKyXdWpOREi3oh4Tzuko9cYJpqjiKDFNVUp+QNF8MeamMfELrxdrK0xnXZiaOehnUhyJW4qpBtpmsONqYl0= X-Received: by 2002:a05:6512:3196:: with SMTP id i22mr2609441lfe.574.1613173117310; Fri, 12 Feb 2021 15:38:37 -0800 (PST) MIME-Version: 1.0 References: <161270175060.8296.1897997883947486904@ietfa.amsl.com> <06504BA6-6065-4ADD-BE45-5E13DF00DC1A@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Fri, 12 Feb 2021 16:38:10 -0700 Message-ID: To: Francis Pouatcha Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="0000000000009e75c505bb2c22cc" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 23:38:42 -0000 --0000000000009e75c505bb2c22cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha wrote: > Find bellow my review of the draft: > > > 1. Redactional changes: > > 2.2. Authorization Data Types > > > Interpretation of the value of the "type" parameter, and the object > > elements that the "type" parameter allows =3D> allowed > > > The "allows" seems correct there. > 9. Metadata > > which is an > > JSON array. =3D> which is a JSON array > Fixed this in the document source. Thanks! > > 1. Application to existing APIs > > reason-1: Current open banking initiatives are built on the of existing > Data Standards like ISO20022 (PAIN, CAMT) which are XML's that do not > provide direct translation to JSON. Some authorization server's might eve= n > be able to parse an ISO PAIN file to display the proper authorization > request to the user. > That the APIs are XML doesn't necessarily mean that the details of the authorization can't be represented in JSON. And, if really need be, XML can be included as the value of some member in the authorization details and defined as such by the type. > reason-2: In some situation, it might be more privacy preserving to have > the authorization request content negotiated between the AS and the RS. I= n > this case the "scope" parameter shall only carry some sort of "grant-id" > (known in the Berlin Group spec as consent-id). This will allow the AS to > negotiate the data to be displayed directly with the RS. > RAR probably just isn't applicable in that kind of case. > > Any idea how to consider these two edge cases? > > Best regards. > /Francis > > > ------------------------------ > *From:* OAuth on behalf of Torsten Lodderstedt > > *Sent:* Sunday, February 7, 2021 12:49 PM > *To:* oauth > *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt > > Hi all, > > here is the list of changes in revision -04: > > > - restructured draft for better readability > - simplified normative text about use of the resource parameter with > authorization_details > - added implementation considerations for deployments and products > - added type union language from GNAP > - added recommendation to use PAR to cope with large requests and for > request protection > > > Your feedback is highly appreciated. > > best regards, > Torsten. > > Am 07.02.2021 um 13:42 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 WG of the IET= F. > > Title : OAuth 2.0 Rich Authorization Requests > Authors : Torsten Lodderstedt > Justin Richer > Brian Campbell > Filename : draft-ietf-oauth-rar-04.txt > Pages : 36 > Date : 2021-02-07 > > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. > > > The IETF datatracker status page for this draft is: > > https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-iet= f-oauth-rar/&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw3-4SmuM= Fgxbz-cDK2Ir_a7 > > There is also an HTML version available at: > > https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf= -oauth-rar-04.html&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw1= J52xGTvk1ZAuBC_fUAIjJ > > A diff from the previous version is available at: > > https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-= ietf-oauth-rar-04&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw0T= YqmFwryvAYznR2Ho5Oj6 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oaut= h&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw06g1z6o36BkkaqkiWc= 1Lw9 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000009e75c505bb2c22cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 9, 2021 at 5:53 AM Franci= s Pouatcha <fpo=3D40adors= ys.de@dmarc.ietf.org> wrote:
Find bellow my review of the draft:

  1. Redactional changes:

2.2.=C2=A0 Authorization Data Types


Interpretation of the value of the "type" parameter, and the obj= ect

=C2=A0=C2=A0 elements that the "type" parameter allows =3D> allowed<= /span>


=
The "allows" seems correct there.
<= br>
=C2=A0

9.=C2=A0 Metadata

which is an

=C2=A0=C2=A0 JSON array. =3D> which is a JSON array


Fixed this in the document source= . Thanks!
=C2=A0
  1. Application to existing APIs
reason-1: Current open banking initiatives are built on the of e= xisting Data Standards like ISO20022 (PAIN, CAMT) which are XML's that = do not provide direct translation to JSON. Some authorization server's = might even be able to parse an ISO PAIN file to display the proper authorization request to the user.

That the APIs are XML doesn= 9;t necessarily mean that the details of the authorization can't be rep= resented in JSON. And, if really need be, XML can be included as the value = of some member in the authorization details and defined as such by the type= .

=C2=A0
reason-2: In some situation, it might be more privacy preserving to ha= ve the authorization request content negotiated between the AS and the RS. = In this case the "scope" parameter shall only carry some sort of = "grant-id" (known in the Berlin Group spec as consent-id). This will allow the AS to negotiate the data to be display= ed directly with the RS.

= RAR probably just isn't applicable in that kind of case.

=C2=A0

Any idea how to consider these two edge cases?


=C2=A0
Best regards.
/Francis


Fro= m: OAuth <oauth-bounces@ietf.org> on behalf of Torsten Lodderstedt <torst= en=3D= 40lodderstedt.net@dmarc.ietf.org>
Sent: Sunday, February 7, 2021 12:49 PM
To: oauth <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt
=C2=A0
Hi all,

here is the list of changes in revision -04:

  • restructured draft for better readability
  • simplified normative = text about use of the resource parameter with authorization_details=C2=A0
  • added implementation considerations for deployments and products
  • added type union language from GNAP =C2=A0
  • added recommendatio= n to use PAR to cope with large requests and for request protection

Your feedback is highly appreciated.

best regards,
Torsten.=C2=A0

Am 07.02.2021 um 13:42 schrieb internet-drafts@ietf.org:


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : OAuth= 2.0 Rich Authorization Requests
=C2=A0 =C2=A0 =C2=A0 =C2=A0Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Torsten Lo= dderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Justin Richer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Brian Campbell
Filename =C2=A0 =C2=A0 =C2=A0 = =C2=A0: draft-ietf-oauth-rar-04.txt
Pages =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 36
Date =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: 2021-02-07

Abstract:
=C2=A0 This document specifies a new parameter "authorization_details&= quot; that
=C2=A0 is used to carry fine grained authorization data in the OAuth
=C2=A0 authorization request.


The IETF datatracker status page for this draft is:
https://www.google.= com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-ietf-oauth-rar/&sour= ce=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw3-4SmuMFgxbz-cDK= 2Ir_a7

There is also an HTML version available at:
https://www.g= oogle.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf-oauth-rar-04.h= tml&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw1J52= xGTvk1ZAuBC_fUAIjJ

A diff from the previous version is available at:
https://www.go= ogle.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-ietf-oauth-rar-0= 4&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw0TYqmF= wryvAYznR2Ho5Oj6


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

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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q= =3Dhttps://www.ietf.org/mailman/listinfo/oauth&source=3Dgmail-imap&= ust=3D1613306557000000&usg=3DAOvVaw06g1z6o36BkkaqkiWc1Lw9

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000009e75c505bb2c22cc-- From nobody Sat Feb 13 19:39:45 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7403A13B4 for ; Sat, 13 Feb 2021 19:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jywMJxWq7MKi for ; Sat, 13 Feb 2021 19:39:40 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B83C3A13B2 for ; Sat, 13 Feb 2021 19:39:40 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id lg21so5905465ejb.3 for ; Sat, 13 Feb 2021 19:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9icbxbQ7V6dDHeNxN5/VQ2p2gqhYMcAXJxLR5rb0Na4=; b=Mo7R00VI2FJ/uDC9BMJ7BGb2uzT5baFoVT0OA6u0KjIzX/13kmRDbcqRAt7qTghF2t Ow26NK/WOLEXDxJWMtMzzaIinLhzNLtNCFQYYH+HIuNzypiIYsVDyyyf4COBWpEkfCcE AbEtz0hCAQYJvSgrqKjXKzd0LfarzUv4PzeuZ+1S09vL8hDgdh/f1iJt2hframLDefud yL46jj2oC3kD671K3kW6g6pa/2196dMeRMEyIN5VgmwUyeWzlvFAwwUTrXbEfT6JWYhU SVIhHxU5Ez4CX6sm+1qNFPk2LdJ0ht3OIeg2iQ1250wwhpfVyWDwepu0SyAlZ4Ix/dlV 0RGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9icbxbQ7V6dDHeNxN5/VQ2p2gqhYMcAXJxLR5rb0Na4=; b=JaKYCVDMkl+oN4oJ2/tfvtG8ouQB6IHTKC6MVJwM2YsqhRU3fK1/zXKIHytuOD4ZkO +Xt1n2vn1UjfzxDpyNSWeJqWVuj5piWB6UoqvZC1S8+MYgpRI3wwtleoFK3Q5QhGGt83 0PD2hkUCFCiUJS/AToCBgSEzbjLZz6N7dAAhtH81Ym6MjzqxgNrFGUVP19nvyx3k2H+q RL/oYbhgRkeKCrj1Lzrs2HTgbBI6pkSlazXsRUIsdIOgoOxvy7TYdN+LHCmbBCl5kOwb QtX3tOIdKWwKnlcd5L2LC88jlmXK7NFSoqPAGNNZB1iT2vw4w6SSAWWUjwBGPwiXRjFn N4Gg== X-Gm-Message-State: AOAM531l2dai7QFvLn+7rWimporHpKcAUnnJJraXxXe5rdXNVxqn/K1U Qvih+TlKBXanQZ7pMpfYK31vE2my8eSiF7peCMZJOPeW3hI= X-Google-Smtp-Source: ABdhPJw7dunIfGKSDZ6FEwE6ayFzzFudMBmN4xwroP2JxCHSq2iV5eDDawBSKEy1KE3QvVVjoVUqfStmlHCrka2LQoo= X-Received: by 2002:a17:906:c0cd:: with SMTP id bn13mr9469530ejb.368.1613273978500; Sat, 13 Feb 2021 19:39:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stoycho Sleptsov Date: Sun, 14 Feb 2021 05:39:26 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000069fab105bb439ec0" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 03:39:43 -0000 --00000000000069fab105bb439ec0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mr. Bertocci, I am a novice yet at APIs and OAuth, but nevertheless am entrusted by the executives of our organisation to expose some of the capabilities of our system through APIs. For that I have set out to implement an OAuth server (based on the 2.1 draft), which is basically functional now, and the corresponding APIs (resource servers). Our team will also have to implement some initial frontend applications which will consume those exposed resources. I was exactly at the point of considering how to organise the correspondence of the access token from the auth server to the frontend and from the frontend to the resource servers, when I received as a very nice surprise the news about tmi-bff draft. It was such a relief, as the option to delegate access token acquisition to a backend component, while still accessing resource servers directly from the frontend, seemed most suitable and well balanced for our case. I have read the draft with great pleasure, but one thing concerns me in it. In the description of the protocol flow (1.2), in the step of token request from backend to AS (step B), it mentions that the AS should "issue the requested token without requiring user interaction". Same thing is reconfirmed in section 4, step 4: "the backend verifies whether it has the necessary artifacts to request it to the authorization server without requiring user interaction". But an initial interaction between the resource owner and the authorization server is required by the authorization code flow (section 1.3.1 of the draft-ietf-oauth-v2-1-01). So where does this interaction fit in the tmi-bff protocol flow? Or tmi-bff is not supposed to be used with authorization code flow? Thank you for your time, hoping to hear from you, Stoycho. =D0=9D=D0=B0 =D0=BF=D1=82, 12 =D1=84=D0=B5=D0=B2 2021 =D0=B3., 22:46 Vittor= io Bertocci =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: > Dear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to th= e > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend > For Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: > https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate > access > token acquisition to a backend component. In so doing, the fronte= nd > can access resource servers directly without taking on the burden = of > communicating with the authorization server, persisting tokens, an= d > performing operations that are fraught with security challenges wh= en > executed in a user agent, but are safe and well proven when execut= ed > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000069fab105bb439ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mr. Bertocci,

I am a novice yet at APIs and OAuth, but nevertheless am entruste= d by the executives of our organisation to expose some of the capabilities = of our system through APIs. For that I have set out to implement an OAuth s= erver (based on the 2.1 draft), which is basically functional now, and the = corresponding APIs (resource servers). Our team will also have to implement= some initial frontend applications which will
consu= me those exposed resources. I was exactly at the point of considering how t= o organise the correspondence of the access token from the auth server to t= he frontend and from the frontend to the
resource se= rvers, when I received as a very nice surprise the news about tmi-bff draft= . It was such a relief, as the option to delegate access token acquisition = to a backend component, while still accessing resource servers directly fro= m the frontend, seemed most suitable and
well balanc= ed for our case.

I have = read the draft with great pleasure, but one thing concerns me in it.
<= div dir=3D"auto">
In the description of the prot= ocol flow (1.2), in the step of token request from backend to AS (step B), = it mentions that the AS should "issue the requested token without requ= iring user interaction". Same
thing is reconfir= med in section 4, step 4: "the backend verifies whether it has the nec= essary artifacts to request it to the
authorization = server without requiring user interaction".
But an initial interaction between the resource ow= ner and the authorization server is required by the authorization code flow= (section 1.3.1 of the draft-ietf-oauth-v2-1-01).
So where does this interaction fit in the tmi-bff= protocol flow? Or tmi-bff is not supposed to be used with authorization co= de flow?

Thank you for y= our time,
hoping to hear from you,
Stoycho.

=D0=9D=D0=B0 =D0=BF=D1=82, 12 =D1=84=D0=B5=D0=B2 2021 = =D0=B3., 22:46 Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> =D0=BD=D0=B0= =D0=BF=D0=B8=D1=81=D0=B0:
Dear all= ,
Brian and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and persist= ence to its backend, and request such tokens when needed for direct access = of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern devel= opment stacks, such as Next.JS. Variants of the pattern, often discussed un= der the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=E2=80=99s activity, but always left all implementation = details to the reader.
We believe the pattern has merit, as corroborated by its growing adoption. = By delegating access token acquisition to the backend, we avoid many of the= often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend = from the need of persisting tokens in local storage, a well known sore poin= t of using OAuth directly in JavaScript, by relying on its backend storage = and session to preserve tokens.

Although the specification is very simple, providing explicit guidance on t= he scenario offers many advantages.=C2=A0
- It makes it possible to create interoperable SDKs, where frontend dev sta= cks (any JS flavor) can be mixed and matched with compliant backend stacks = (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario a= nd warn implementers against security risks (scope escalations, using IDtok= ens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as p= art of the browser apps security guidance, and position the scenario where = frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventi= ng developers from weakening the security of their system (eg turning on RO= PG options)=C2=A0 or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely eliminate the = risks inherent to direct use of access tokens from a browser. But reality i= s that the pattern is in widespread use, and the circumstances leading to t= hat (eg developers on a particular project only work with frontend stacks; = components like reverse proxies might not always be viable; etc) aren=E2=80= =99t going away any time soon. By providing simple guidance on this pattern= , we can simplify the life of many developers while enshrining basic securi= ty hygiene in scenarios that would have otherwise be left to their own devi= ce.

Looking forward for your feedback!

B&V=C2=A0

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" = <internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt =C2=A0 =C2=A0 has been successfully submitted by Vittorio Bertocci and post= ed to the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= raft-bertocci-oauth2-tmi-bff
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A000
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Token = Mediating and session Information Backend For Frontend
=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2021-02-12
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indivi= dual Submission
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draf= t-bertocci-oauth2-tmi-bff-00.txt
=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-bertocc= i-oauth2-tmi-bff/
=C2=A0 =C2=A0 Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/dra= ft-bertocci-oauth2-tmi-bff-00.html
=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-= bff-00


=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document describes how a JavaScript fronten= d can delegate access
=C2=A0 =C2=A0 =C2=A0 =C2=A0token acquisition to a backend component.=C2=A0 = In so doing, the frontend
=C2=A0 =C2=A0 =C2=A0 =C2=A0can access resource servers directly without tak= ing on the burden of
=C2=A0 =C2=A0 =C2=A0 =C2=A0communicating with the authorization server, per= sisting tokens, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0performing operations that are fraught with secu= rity challenges when
=C2=A0 =C2=A0 =C2=A0 =C2=A0executed in a user agent, but are safe and well = proven when executed
=C2=A0 =C2=A0 =C2=A0 =C2=A0by a confidential client running on a backend.



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

=C2=A0 =C2=A0 The IETF Secretariat



_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000069fab105bb439ec0-- From nobody Sun Feb 14 00:17:52 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31F3A17C6 for ; Sun, 14 Feb 2021 00:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAX82On9ETB7 for ; Sun, 14 Feb 2021 00:17:49 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562FA3A17C3 for ; Sun, 14 Feb 2021 00:17:49 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id jj19so6344393ejc.4 for ; Sun, 14 Feb 2021 00:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:cc:date:message-id:references :to:content-transfer-encoding; bh=UhDNtVKnX+VLVq5VqrbcrAPKctSbigeMEozOmcyxnzU=; b=QefJ6BOIXIo/e/hVFnWvaupIwczHhUoNUzWfdOUphPqs2iZUfN8Q7rN7WZp+ApKmIy wrISwBETWMj94Qc2IkHZFgisKT9pEN8wdGJonOBgNESmG6uzeUhxpBmScZPPNW7dh9zg F5g8bC0C6qlxgWO3MxfGgJt8PYID1EMIaoKfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:cc:date :message-id:references:to:content-transfer-encoding; bh=UhDNtVKnX+VLVq5VqrbcrAPKctSbigeMEozOmcyxnzU=; b=cZ1ILmAPy0XAd/Aii+8OpPE0R59RFRsn/gDvNNXN+Htl8zrtnTk88M45d8uSr5UZZW YbJUgK1I2EjqwJH4fh+29XQolK+Gg9DzY8G7ombZld9Rhg3Tegv3Av2W1OBOhZeh1Lll pKqVXhp5NjtwS+01xypOS3+K5zv5QcGZTVUTOI0KamWvtztnuInxO1wQ4Vg4zRLqW4Kl pBDlhd5jSLIVu4p8Wf5adqS4dSO7W0xMsj63ugA3HJHXaZ3EM6we97RPJVexkHi+INA/ Q0Lf9LtmFqct8v/1VTM8Xu9NmS9Mnn6Dc2rMgmVOeZ6qGMMGHkbyJh3/2cpQw2SEl2UF E0cA== X-Gm-Message-State: AOAM530ke+K1z2kzYooe6PKgC77arM1O2XgnrrhMg3D37wHyrC7Ytcbp TsLLgsJDvGUEnCmXHqiywCFP6m5UCOcyqyiUvBEEmnzl8QjWF0uTmQ1m0YpSEd8Q2GKKfcUbmg= = X-Google-Smtp-Source: ABdhPJyaVv0Y5zPi3u5P4kbWJMQCPMyt22mg390n4i0MjuTAn68COkhiTVEkXT0ZhhVrNpuMwjIFRg== X-Received: by 2002:a17:906:3456:: with SMTP id d22mr119243ejb.115.1613290667533; Sun, 14 Feb 2021 00:17:47 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y22sm365546ejq.122.2021.02.14.00.17.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 00:17:47 -0800 (PST) Mime-Version: 1.0 (1.0) From: Neil Madden In-Reply-To: Cc: oauth@ietf.org, Brian Campbell Date: Sun, 14 Feb 2021 08:17:46 +0000 Message-Id: References: To: Vittorio Bertocci X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-8EE3F0CC-5838-4789-993C-A9F5549EB49A Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 08:17:52 -0000 --Apple-Mail-8EE3F0CC-5838-4789-993C-A9F5549EB49A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have a lot of security concerns about this draft.=20 The draft alludes to security issues associated with handling access tokens= in the frontend but never really spells them out. From the Security Consid= erations it seems that the primary concern is with theft of access tokens f= rom local storage. To do this you=E2=80=99d need an XSS attack. But in that= case, wouldn=E2=80=99t the attacker simply use the XSS to make a call to t= he bff-token endpoint instead?=20 The combination of the bff-token endpoint recommending the use of GET reque= sts together with the hint to use cookie-based authentication is likely goi= ng to punch a hole in most CSRF defenses, which assume that GETs are safe. = The only thing preventing this being exploitable is Cross-Origin Read Block= ing (https://chromium.googlesource.com/chromium/src/+/master/services/netwo= rk/cross_origin_read_blocking_explainer.md) due to the JSON content-type. T= hat makes me really nervous. We should at least mandate X-Content-Type-Opti= ons: nosniff on that response. I=E2=80=99d feel more comfortable if this wa= s a POST request only.=20 As Stoycho Sleptsov mentioned in the other email, the lack of front-channel= communication between the AS and the RO seems odd. If the backend is alrea= dy implicitly trusted then couldn=E2=80=99t you skip OAuth and just get the= backend to issue short-lived JWTs to the frontend that it can use for API = access? If you want to allow auth code flow etc then perhaps the bff-token endpoint= can return a standard error code with an authorization endpoint URI that t= he SPA then navigates the user to. (Eg the backend can do a PAR request fir= st and return a URI that references that so that authorization details aren= =E2=80=99t passed through the frontend).=20 =E2=80=94 Neil > On 12 Feb 2021, at 20:46, Vittorio Bertocci wrote: > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how th= e user agent frontend of a web app can delegate token acquisition and persi= stence to its backend, and request such tokens when needed for direct acces= s of protected resources from the frontend code. >=20 > The pattern is already in use, in proprietary form, by various modern dev= elopment stacks, such as Next.JS. Variants of the pattern, often discussed = under the catch-all term BFF (backend for frontend), have been often mentio= ned in this workgroup=E2=80=99s activity, but always left all implementatio= n details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . By delegating access token acquisition to the backend, we avoid many of t= he often brittle moving parts (and implied attack surface) required to acqu= ire access tokens from a user agent. The topology also relieves the fronten= d from the need of persisting tokens in local storage, a well known sore po= int of using OAuth directly in JavaScript, by relying on its backend storag= e and session to preserve tokens. >=20 > Although the specification is very simple, providing explicit guidance on= the scenario offers many advantages. =20 > - It makes it possible to create interoperable SDKs, where frontend dev s= tacks (any JS flavor) can be mixed and matched with compliant backend stack= s (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario= and warn implementers against security risks (scope escalations, using IDt= okens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as= part of the browser apps security guidance, and position the scenario wher= e frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly preven= ting developers from weakening the security of their system (eg turning on = ROPG options) or turning to risky practices like scraping >=20 > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks inherent to direct use of access tokens from a browser. But reality= is that the pattern is in widespread use, and the circumstances leading to= that (eg developers on a particular project only work with frontend stacks= ; components like reverse proxies might not always be viable; etc) aren=E2= =80=99t going away any time soon. By providing simple guidance on this patt= ern, we can simplify the life of many developers while enshrining basic sec= urity hygiene in scenarios that would have otherwise be left to their own d= evice. >=20 > Looking forward for your feedback! >=20 > B&V =20 >=20 > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" wrote: >=20 >=20 > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. >=20 > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For Fron= tend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-= tmi-bff-00.txt > Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2= -tmi-bff/ > Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-= tmi-bff-00.html > Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-= bff-00 >=20 >=20 > Abstract: > This document describes how a JavaScript frontend can delegate acce= ss > token acquisition to a backend component. In so doing, the fronten= d > can access resource servers directly without taking on the burden o= f > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges whe= n > executed in a user agent, but are safe and well proven when execute= d > by a confidential client running on a backend. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of subm= ission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 ForgeRock values your Privacy --Apple-Mail-8EE3F0CC-5838-4789-993C-A9F5549EB49A Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a lot of security concerns about this draft.=  

The draft alludes t= o security issues associated with handling access tokens in the frontend bu= t never really spells them out. From the Security Considerations it seems t= hat the primary concern is with theft of access tokens from local storage. = To do this you=E2=80=99d need an XSS attack. But in that case, wouldn=E2=80= =99t the attacker simply use the XSS to make a call to the bff-token endpoi= nt instead? 

The comb= ination of the bff-token endpoint recommending the use of GET requests toge= ther with the hint to use cookie-based authentication is likely going to pu= nch a hole in most CSRF defenses, which assume that GETs are safe. The only= thing preventing this being exploitable is Cross-Origin Read Blocking (https://chromium.googlesourc= e.com/chromium/src/+/master/services/network/cross_origin_read_blocking_exp= lainer.md) due to the JSON content-type. That makes me really nervous. = We should at least mandate X-Content-Type-Options: nosniff on that response= . I=E2=80=99d feel more comfortable if this was a POST request only. <= /div>

As Stoycho Sleptsov mentio= ned in the other email, the lack of front-channel communication between the= AS and the RO seems odd. If the backend is already implicitly trusted then= couldn=E2=80=99t you skip OAuth and just get the backend to issue short-li= ved JWTs to the frontend that it can use for API access?

If you want to allow auth code flow etc then= perhaps the bff-token endpoint can return a standard error code with an au= thorization endpoint URI that the SPA then navigates the user to. (Eg the b= ackend can do a PAR request first and return a URI that references that so = that authorization details aren=E2=80=99t passed through the frontend).&nbs= p;

=E2=80=94 Neil


On 1= 2 Feb 2021, at 20:46, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com= @dmarc.ietf.org> wrote:

=EF=BB=BFDear all,
Brian and you= rs truly are proposing a new specification that shows how the user agent fr= ontend of a web app can delegate token acquisition and persistence to its b= ackend, and request such tokens when needed for direct access of protected = resources from the frontend code.

The patt= ern is already in use, in proprietary form, by various modern development s= tacks, such as Next.JS. Variants of the pattern, often discussed under the = catch-all term BFF (backend for frontend), have been often mentioned in thi= s workgroup=E2=80=99s activity, but always left all implementation details = to the reader.
We believe the pattern has merit, as corrobo= rated by its growing adoption. By delegating access token acquisition to th= e backend, we avoid many of the often brittle moving parts (and implied att= ack surface) required to acquire access tokens from a user agent. The topol= ogy also relieves the frontend from the need of persisting tokens in local = storage, a well known sore point of using OAuth directly in JavaScript, by = relying on its backend storage and session to preserve tokens.

Although the specification is very simple, providing e= xplicit guidance on the scenario offers many advantages.  
<= span>- It makes it possible to create interoperable SDKs, where frontend de= v stacks (any JS flavor) can be mixed and matched with compliant backend st= acks (middlewares in node, java, ASP.NET, PHP etc)
- It all= ows us to provide guidance on how to properly tackle the scenario and warn = implementers against security risks (scope escalations, using IDtokens inst= ead of access tokens, etc)
- It allows us to discuss (and w= hen appropriate, promote) this pattern as part of the browser apps security= guidance, and position the scenario where frontend only calls API on its o= wn backed (hence doesn=E2=80=99t need access tokens) simply as a special ca= se of this more general pattern
- This approach makes mocki= ng and testing apps very easy, possibly preventing developers from weakenin= g the security of their system (eg turning on ROPG options)  or turnin= g to risky practices like scraping

Needles= s to say, this specification doesn=E2=80=99t entirely eliminate the risks i= nherent to direct use of access tokens from a browser. But reality is that = the pattern is in widespread use, and the circumstances leading to that (eg= developers on a particular project only work with frontend stacks; compone= nts like reverse proxies might not always be viable; etc) aren=E2=80=99t go= ing away any time soon. By providing simple guidance on this pattern, we ca= n simplify the life of many developers while enshrining basic security hygi= ene in scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!
=
B&V  

=EF= =BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@iet= f.org> wrote:


 &= nbsp; A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
   has been successfully submitted by Vittorio B= ertocci and posted to the
   IETF repositor= y.

   Name:     =    draft-bertocci-oauth2-tmi-bff
  &nb= sp;Revision:    00
   Title: &nbs= p;      Token Mediating and session Information Backend For = Frontend
   Document date:    202= 1-02-12
   Group:       &nbs= p;Individual Submission
   Pages:   &n= bsp;    16
   URL:   &n= bsp;        https://www.ietf.org/ar= chive/id/draft-bertocci-oauth2-tmi-bff-00.txt
  =  Status:         https://datat= racker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
 &= nbsp; Html:          &nbs= p;https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html
   Htmlized:      &nb= sp;https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00
<= span>

   Abstract:<= br>       This document describes how a= JavaScript frontend can delegate access
   = ;   token acquisition to a backend component.  In so do= ing, the frontend
      can = access resource servers directly without taking on the burden of
=       communicating with the authoriza= tion server, persisting tokens, and
   &nbs= p;  performing operations that are fraught with security challeng= es when
      executed in a = user agent, but are safe and well proven when executed
&nb= sp;     by a confidential client running on a back= end.




   Please note that it may take a couple of m= inutes from the time of submission
   until= the htmlized version and diff are available at tools.ietf.org.
<= span>
   The IETF Secretariat



_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

ForgeRock values your Privacy --Apple-Mail-8EE3F0CC-5838-4789-993C-A9F5549EB49A-- From nobody Sun Feb 14 01:51:52 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0444D3A0925 for ; Sun, 14 Feb 2021 01:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA7UCRbwm49Y for ; Sun, 14 Feb 2021 01:51:47 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C5BB3A0922 for ; Sun, 14 Feb 2021 01:51:46 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id f20so3810651ioo.10 for ; Sun, 14 Feb 2021 01:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NIwMXf4mRkBhGLOEzUqgiwAEkS+rCZChsmA++eLw6yA=; b=STJlqdTLSxjisPI6zHTWUGrNYwv/wT79cwjuQS94hf5nJBmPSe47nWPLkz1QupSnfM 4khtqvRS7Ei6PnnNISLPKxGcrQjtbFDAKv4/y8ATWhOTE0HvWz+xZ2rvHpOM2LAYVgmH dUqWsrQtkL2HPhlB/ppeMP3u0PZZDgM2owPPGSAUrO9nPZm9bbiuwFHUMRSNPgm20S8Y M8U/F8vnBsBYUyGmD/MHGOed2IFcxFGCRpxq/P6UYrWm8B4oYpfsQL3us74SQ3ULEN2G ywAI3WOjzAtHOgeGky/v4wgODpSIF/39KZoQXkv6Nm34i5tncL3PFRASvbzynbve/Zcu gSWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NIwMXf4mRkBhGLOEzUqgiwAEkS+rCZChsmA++eLw6yA=; b=F7tqQ64cB8I0TK8bvXrcAXz4cXp8FjLpKvhtmZzLkUHu7EYvKg3NO8H+GmTGIc0d1A ST83pJPPp5prMJYGQOqzMcqtmNLAdXeQ1/ZY9XAaJ/FgOfp2YsEW4ZNVH7EgqKFlVXN/ 3yTXEAXnwjgaqYE9grfbanU5T/t46hmXO/kxqjV5bsVEqZyGpA3cKKc81RP2SqbmmrTE KkX5d/sUxuwq7HpBLAQ1cpdHGfcId7FFveIGbVoJRD1sIVPnWFvnWok0NHTwKQwpj6P0 xti1afHAn9zuQHE+kJjnzzPk23JCf1iarxbTAEFYEzxJeJLD5vSKph3ioDHBF5lfDwqm xq3g== X-Gm-Message-State: AOAM533AqZiB5XAizbbamb4sChod3BIC41hqaHc2C9CodtDxPzAqUk0u uvtnlLMw0kwQmW68SxfZkiyU7FvnQgLBBdw9A+NDHw7xBUHPUpCobA== X-Google-Smtp-Source: ABdhPJxu0cPD4Qm46dYNrvCrn167fORWlBMGYIfs/w2AZZCvCchiq3QFdVTYieX9iSoH8w4uWnJZFCJ5LcqyIBLH07s= X-Received: by 2002:a6b:da0f:: with SMTP id x15mr8550230iob.48.1613296305930; Sun, 14 Feb 2021 01:51:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 10:51:35 +0100 Message-ID: To: Neil Madden Cc: Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="0000000000003b98ed05bb48d18c" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 09:51:50 -0000 --0000000000003b98ed05bb48d18c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also flat out reject the premise of this draft. It introduces a pseudo AS-like proxy which now has all the requirements of an AS and more. While AS SDKs provide easy ways for client UIs to effectively deal with communication via the AS, there's no way for the AS to provide standard AS specific services prototypes to support BFF. That means that everyone is writing their own BFF AS-proxy. Additionally, I too am lacking the clarity on the *WHY*. The only thing mentioned in the draft is > That approach is not always viable, as in the absence of reverse proxy > deployments the creation and maintenance of a facade for multiple APIs ca= n > be expensive Which isn't ever justified, but even if we accept that as a true premise, what are these AS doing that even require a BFF? Hypothetically you could argue that the auth code flow requires a BFF and that's required for user login since implicit flow no longer exists, but that isn't true. You can use client side PKCE for validation of these via not requiring the client secret in the front end, and then the problem there is solved. And if you argue that this can't be done, then the solution is introducing a better way to handle this so that a BFF for AS flows don't have to exist. So what concrete problem is this solving? There was also the argument of *there are lots of people doing this*, which is always a terrible argument, but even if we do permit that in the discussion, we still need to answer the *why. *Why are developers creating BFF for their frontends to communicate with an AS. Is it because AS are terrible, is it because *front ends as a service* are terrible, etc... Until we know why this is happening concretely, I don't think we should encourage further use of a pattern rife with potential security risks by telling everyone how you can do it (because the guidance we are offering doesn't even slightly increase safety). Further, even if we were to accept this pattern and want to create a standard around it, we are effectively creating an AS proxy here, which means we should require it to act like an AS, and delegate the specification of resources, endpoints, terminology, and patterns to existing or future AS related RFCs. (We already have a problem with the current draft as it attempts to redefine and introduce new terms/patterns that have the same functionality as existing ones in the AS, yet fail to capture the full importance of the original RFCs. This is bad duplication). And therefore in conclusion we should focus only on the aspects that are absolutely required which aren't already present in some form in existing AS related RFCs, but what are those? The one counterpoint to all of this is the potential introduction of domain specific *cookie* language (which doesn't exist in the current draft). Concretely, *let's add a response_type=3Dcookie*, to AS to support domain first-party cookies and session management. When we built our AS we explicitly added this so that services can use the JWT found in the HttpOnly SameSite=3DStrict cookie as a security measure against XSS attacks that attempt to exfiltrate access tokens. That's a potential suggestion I would favor, although I still can't know if that solves the problem being presented in the draft. - Warren Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 9:18 AM Neil Madden wrote: > I have a lot of security concerns about this draft. > > The draft alludes to security issues associated with handling access > tokens in the frontend but never really spells them out. From the Securit= y > Considerations it seems that the primary concern is with theft of access > tokens from local storage. To do this you=E2=80=99d need an XSS attack. B= ut in that > case, wouldn=E2=80=99t the attacker simply use the XSS to make a call to = the > bff-token endpoint instead? > > The combination of the bff-token endpoint recommending the use of GET > requests together with the hint to use cookie-based authentication is > likely going to punch a hole in most CSRF defenses, which assume that GET= s > are safe. The only thing preventing this being exploitable is Cross-Origi= n > Read Blocking ( > https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md) > due to the JSON content-type. That makes me really nervous. We should at > least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel > more comfortable if this was a POST request only. > > As Stoycho Sleptsov mentioned in the other email, the lack of > front-channel communication between the AS and the RO seems odd. If the > backend is already implicitly trusted then couldn=E2=80=99t you skip OAut= h and just > get the backend to issue short-lived JWTs to the frontend that it can use > for API access? > > If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoint > URI that the SPA then navigates the user to. (Eg the backend can do a PAR > request first and return a URI that references that so that authorization > details aren=E2=80=99t passed through the frontend). > > =E2=80=94 Neil > > > On 12 Feb 2021, at 20:46, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For > Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: > https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate acce= ss > token acquisition to a backend component. In so doing, the fronten= d > can access resource servers directly without taking on the burden o= f > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges whe= n > executed in a user agent, but are safe and well proven when execute= d > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000003b98ed05bb48d18c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also flat out reject the premise of this draft. It intro= duces a pseudo AS-like proxy which now has all the requirements of an AS an= d more. While AS SDKs provide easy ways for client UIs to effectively deal = with communication via the AS, there's no way for the AS to provide sta= ndard AS specific services prototypes to support BFF. That means that every= one is writing their own BFF AS-proxy.

Additionally, I t= oo am lacking the clarity on the WHY. The only thing mentioned in th= e draft is
That= approach is not always viable, as in the absence of reverse proxy deployme= nts the creation and maintenance of a facade for multiple APIs can be expen= sive
Which isn't ever justified, but even if we accept= that as a true premise, what are these AS doing that even require a BFF?

Hypothetically you could argue that the auth code f= low requires a BFF and that's required for user login since implicit=C2= =A0flow no longer exists, but that isn't true. You can use client side = PKCE for validation of these via not requiring the client secret in the fro= nt end, and then the problem there is solved. And if you argue that this ca= n't be done, then the solution is introducing a better way to handle th= is so that a BFF for AS flows don't have to exist.

=
So what concrete problem is this solving?

The= re was also the argument of there are lots of people doing this, whi= ch is always a terrible argument, but even if we do permit that in the disc= ussion, we still need to answer the why. Why are developers creating= BFF for their frontends to communicate with an AS. Is it because AS are te= rrible, is it because front ends as a service=C2=A0are terrible, etc= ... Until we know why this is happening concretely, I don't think we sh= ould encourage further use of a pattern rife with potential security risks = by telling everyone how you can do it (because the guidance we are=C2=A0off= ering doesn't even slightly increase safety).

= Further, even if we were to accept this pattern and want to create a standa= rd around it, we are effectively creating an AS proxy here, which means we = should require it to act like an AS, and delegate the specification of reso= urces, endpoints, terminology, and patterns to existing or future AS relate= d RFCs. (We already have a problem with the current draft as it attempts to= redefine and introduce new terms/patterns that have the same functionality= as existing ones in the AS, yet fail to capture the full importance of the= original RFCs. This is bad duplication). And therefore in conclusion we sh= ould focus only on the aspects that are absolutely required which aren'= t already present in some form in existing AS related RFCs, but what are th= ose?

The one counterpoint=C2=A0to all of this is t= he potential introduction of domain specific cookie language (which = doesn't exist in the current draft). Concretely, let's add a res= ponse_type=3Dcookie, to AS to support domain first-party cookies and se= ssion management. When we built our AS we explicitly added this so that ser= vices can use the JWT found in the HttpOnly SameSite=3DStrict cookie as a s= ecurity measure against XSS attacks that attempt to exfiltrate=C2=A0access = tokens. That's a potential suggestion I would favor, although I still c= an't know if that solves the problem being presented in the draft.

- Warren

<= td style=3D"border-left:solid #cccccc 1pt;border-right:solid #ffffff 1pt;bo= rder-bottom:solid #ffffff 1pt;border-top:solid #ffffff 1pt;vertical-align:t= op;padding:5pt 5pt 5pt 5pt;overflow:hidden">

Warren Parad

Founder, CTO

Secure your user data an= d complete your authorization architecture. Implement=C2=A0Auth= ress.

On Sun, Feb 14, 2021 at 9:18 AM Neil Madden <neil.madden@forgerock.com> wrote:
=
<= div dir=3D"ltr">
I have a= lot of security concerns about this draft.=C2=A0
The draft alludes to security issues associated wit= h handling access tokens in the frontend but never really spells them out. = >From the Security Considerations it seems that the primary concern is with = theft of access tokens from local storage. To do this you=E2=80=99d need an= XSS attack. But in that case, wouldn=E2=80=99t the attacker simply use the= XSS to make a call to the bff-token endpoint instead?=C2=A0

The combination of the bff-token endpoi= nt recommending the use of GET requests together with the hint to use cooki= e-based authentication is likely going to punch a hole in most CSRF defense= s, which assume that GETs are safe. The only thing preventing this being ex= ploitable is Cross-Origin Read Blocking (https://chromium.googlesource.com/chromiu= m/src/+/master/services/network/cross_origin_read_blocking_explainer.md= ) due to the JSON content-type. That makes me really nervous. We should at = least mandate X-Content-Type-Options: nosniff on that response. I=E2=80=99d= feel more comfortable if this was a POST request only.=C2=A0

As Stoycho Sleptsov mentioned in the ot= her email, the lack of front-channel communication between the AS and the R= O seems odd. If the backend is already implicitly trusted then couldn=E2=80= =99t you skip OAuth and just get the backend to issue short-lived JWTs to t= he frontend that it can use for API access?

If you want to allow auth code flow etc then perhaps the = bff-token endpoint can return a standard error code with an authorization e= ndpoint URI that the SPA then navigates the user to. (Eg the backend can do= a PAR request first and return a URI that references that so that authoriz= ation details aren=E2=80=99t passed through the frontend).=C2=A0

=E2=80=94 Neil


On 12 Feb 2021, a= t 20:46, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

=EF=BB=BFDear all,
Brian and yours truly are proposi= ng a new specification that shows how the user agent frontend of a web app = can delegate token acquisition and persistence to its backend, and request = such tokens when needed for direct access of protected resources from the f= rontend code.

The pattern is already in us= e, in proprietary form, by various modern development stacks, such as Next.= JS. Variants of the pattern, often discussed under the catch-all term BFF (= backend for frontend), have been often mentioned in this workgroup=E2=80=99= s activity, but always left all implementation details to the reader.
We believe the pattern has merit, as corroborated by its growing= adoption. By delegating access token acquisition to the backend, we avoid = many of the often brittle moving parts (and implied attack surface) require= d to acquire access tokens from a user agent. The topology also relieves th= e frontend from the need of persisting tokens in local storage, a well know= n sore point of using OAuth directly in JavaScript, by relying on its backe= nd storage and session to preserve tokens.

Although the specification is very simple, providing explicit guidance on = the scenario offers many advantages. =C2=A0
- It makes it p= ossible to create interoperable SDKs, where frontend dev stacks (any JS fla= vor) can be mixed and matched with compliant backend stacks (middlewares in= node, java, ASP.NET, PHP = etc)
- It allows us to provide guidance on how to properly = tackle the scenario and warn implementers against security risks (scope esc= alations, using IDtokens instead of access tokens, etc)
- I= t allows us to discuss (and when appropriate, promote) this pattern as part= of the browser apps security guidance, and position the scenario where fro= ntend only calls API on its own backed (hence doesn=E2=80=99t need access t= okens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preven= ting developers from weakening the security of their system (eg turning on = ROPG options) =C2=A0or turning to risky practices like scraping
<= span>
Needless to say, this specification doesn=E2=80=99t e= ntirely eliminate the risks inherent to direct use of access tokens from a = browser. But reality is that the pattern is in widespread use, and the circ= umstances leading to that (eg developers on a particular project only work = with frontend stacks; components like reverse proxies might not always be v= iable; etc) aren=E2=80=99t going away any time soon. By providing simple gu= idance on this pattern, we can simplify the life of many developers while e= nshrining basic security hygiene in scenarios that would have otherwise be = left to their own device.

Looking forward = for your feedback!

B&V =C2=A0
=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org&= quot; <int= ernet-drafts@ietf.org> wrote:


=C2=A0=C2=A0=C2=A0A new version of I-D, draft-bertocci-oauth2-= tmi-bff-00.txt
=C2=A0=C2=A0=C2=A0has been successfully sub= mitted by Vittorio Bertocci and posted to the
=C2=A0=C2=A0= =C2=A0IETF repository.

=C2=A0=C2=A0=C2=A0= Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bertocci-oauth2-tmi-bff
=C2=A0=C2=A0=C2=A0Revision: =C2=A0 =C2=A000
=C2=A0=C2= =A0=C2=A0Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Token Mediating and session Info= rmation Backend For Frontend
=C2=A0=C2=A0=C2=A0Document da= te: =C2=A0 =C2=A02021-02-12
=C2=A0=C2=A0=C2=A0Group: =C2= =A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
=C2=A0=C2=A0= =C2=A0Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A016
=C2=A0=C2=A0=C2= =A0URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.= txt" target=3D"_blank">https://www.ietf.org/archive/id/draft-bertocci-oauth= 2-tmi-bff-00.txt
=C2=A0=C2=A0=C2=A0Status: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatrack= er.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
=C2=A0= =C2=A0=C2=A0Html: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0https://www.ietf.org/archive/id/draft-bertocci-= oauth2-tmi-bff-00.html
=C2=A0=C2=A0=C2=A0Htmlized: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/htm= l/draft-bertocci-oauth2-tmi-bff-00


=C2=A0=C2=A0=C2=A0Abstract:
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0This document describes how a JavaScript frontend can = delegate access
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0token = acquisition to a backend component.=C2=A0 In so doing, the frontend<= br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0can access resource servers d= irectly without taking on the burden of
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0communicating with the authorization server, persisting t= okens, and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0performing = operations that are fraught with security challenges when
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0executed in a user agent, but are safe = and well proven when executed
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0by a confidential client running on a backend.




=C2=A0=C2= =A0=C2=A0Please note that it may take a couple of minutes from the time of = submission
=C2=A0=C2=A0=C2=A0until the htmlized version an= d diff are available at tools.ietf.org.

=C2=A0=C2=A0=C2=A0Th= e IETF Secretariat



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

ForgeRock values your Privacy__= _____________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000003b98ed05bb48d18c-- From nobody Sun Feb 14 03:07:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059FD3A0BF7 for ; Sun, 14 Feb 2021 03:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YygIvC16Zch4 for ; Sun, 14 Feb 2021 03:07:28 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9538C3A0BF6 for ; Sun, 14 Feb 2021 03:07:28 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id r2so2141349plr.10 for ; Sun, 14 Feb 2021 03:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=Gcp+Dg0dos2CHqWDsQMUQsj+7wHg+LEpBlOCqITm8sM=; b=Ly3c33DFK8MWOqSIqe7QvQY0VCyaLyT9mMlbWGph8BMoxUOIkgd2hl2gD98pmCu3LD oXV84OCOQQmlBwkm4KWPv9npR6OVzAEgKxMJ2ac8Atr7ld3zwVOe5HjgcyhUdHrtOLrW UtC5VUFDn9Teu9WVOQj9JqAifF6kYrNxjL61JPpXRjq4Bu79PE/sgowAn+WKvzloJgw4 5aknw1uNrRUBI8tVQo3v3cLEbgaYeeP8f1DtLyRkEPKH9nyqSO+kA7u3EDxCR8/VYLO5 mOAgpxfuqtPe/j6uy1peONlo6MvzjqGmU5CpBFJrqR1BaEoQ8+96WzJa+O7LcOxSRrkc PvEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=Gcp+Dg0dos2CHqWDsQMUQsj+7wHg+LEpBlOCqITm8sM=; b=S4PjOjRgPNGTBwg/QYY5EA99dWP5NP3OZgDyDX7iIc2YM1LspQPLJ8kBRyM19sVvpy Jc6i11iIks+sAigBSrmPxM/4Ln34JG3H9X9bwwzGouw92TyhWbN26SDuCGhuwnzTQLQy 3yZrPi1fA8/71OnvpWF3UWE0s8NYOT7ZDQt4xnX8xaQHshjiMA0rMKBA/4h8i1pCyRht /Mj7t8M8AIh4xUVRZ0f7xnFOmvUEqYOnoSwgdzf5hKbhoFzI0NrrybXOVEIDqE+MK0OY E01eoYSJCfFCsV/o4jKsI78r9hV0l+FJ+aojDK5+uElFyAfJiqM76SWJupYioRZ6fBPu k5Fw== X-Gm-Message-State: AOAM532oSoqu90u5JaBcQ4Gus7DvPNndOdEMg4NokZytUvfzL0QebC2i N79gecEMqYTMwcFlua1SbgtOrA== X-Google-Smtp-Source: ABdhPJyEUk+qlAPp6Q6VjVVQeIEZNutv++iQvhULTOhWrqtReXbRXEVUj17VPe5YVtgvBE6WM1HbaQ== X-Received: by 2002:a17:902:e211:b029:e2:843c:426e with SMTP id u17-20020a170902e211b02900e2843c426emr10579633plb.16.1613300847719; Sun, 14 Feb 2021 03:07:27 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id k69sm14755849pfd.4.2021.02.14.03.07.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 03:07:27 -0800 (PST) From: Vittorio Bertocci To: Stoycho Sleptsov , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXAvsAgAB9K7Y= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 11:07:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB40526B1D2AAA259B11BF8C78AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 11:07:31 -0000 --_000_CO6PR18MB40526B1D2AAA259B11BF8C78AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFN0b3ljaG8gZm9yIHlvdXIgY29tbWVudCENClRoZSBUTUktQkZGIGFzc3VtZXMgdGhh dCB0aGUgaW50ZXJhY3RpdmUgcGFydCBvZiB0aGUgZmxvdyAoY29kZSBncmFudCBmb3IgZ2l2aW5n IGNvbnNlbnQgYW5kIGdldHRpbmcgYWNjZXNzK3JlZnJlc2ggdG9rZW5zLCBhbmQgYW55dGhpbmcg bmVjZXNzYXJ5IGZvciBlc3RhYmxpc2hpbmcgdGhlIHNlc3Npb24pIG9jY3VycyBiZWZvcmVoYW5k LiBJdCBpcyBub3QgZGVzY3JpYmVkIGluIHRoZSBzcGVjIGl0c2VsZiwgYnV0IGl0IGlzIGV4cGVj dGVkIHRoYXQgc3VjaCBmbG93IChvciBleHRlbnNpb24gZ3JhbnQgd2l0aCB0aGUgc2FtZSBjaGFy YWN0ZXJpc3RpY3MpIGhhcHBlbmVkLg0KSFRIIQ0KVi4NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBTdG95Y2hvIFNsZXB0c292IDxzdG95Y2hvLnNs ZXB0c292QGdtYWlsLmNvbT4NCkRhdGU6IFNhdHVyZGF5LCBGZWJydWFyeSAxMywgMjAyMSBhdCAx OTozOQ0KVG86ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tl bmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKQ0KDQpIZWxsbyBNci4gQmVydG9jY2ksDQoNCkkgYW0g YSBub3ZpY2UgeWV0IGF0IEFQSXMgYW5kIE9BdXRoLCBidXQgbmV2ZXJ0aGVsZXNzIGFtIGVudHJ1 c3RlZCBieSB0aGUgZXhlY3V0aXZlcyBvZiBvdXIgb3JnYW5pc2F0aW9uIHRvIGV4cG9zZSBzb21l IG9mIHRoZSBjYXBhYmlsaXRpZXMgb2Ygb3VyIHN5c3RlbSB0aHJvdWdoIEFQSXMuIEZvciB0aGF0 IEkgaGF2ZSBzZXQgb3V0IHRvIGltcGxlbWVudCBhbiBPQXV0aCBzZXJ2ZXIgKGJhc2VkIG9uIHRo ZSAyLjEgZHJhZnQpLCB3aGljaCBpcyBiYXNpY2FsbHkgZnVuY3Rpb25hbCBub3csIGFuZCB0aGUg Y29ycmVzcG9uZGluZyBBUElzIChyZXNvdXJjZSBzZXJ2ZXJzKS4gT3VyIHRlYW0gd2lsbCBhbHNv IGhhdmUgdG8gaW1wbGVtZW50IHNvbWUgaW5pdGlhbCBmcm9udGVuZCBhcHBsaWNhdGlvbnMgd2hp Y2ggd2lsbA0KY29uc3VtZSB0aG9zZSBleHBvc2VkIHJlc291cmNlcy4gSSB3YXMgZXhhY3RseSBh dCB0aGUgcG9pbnQgb2YgY29uc2lkZXJpbmcgaG93IHRvIG9yZ2FuaXNlIHRoZSBjb3JyZXNwb25k ZW5jZSBvZiB0aGUgYWNjZXNzIHRva2VuIGZyb20gdGhlIGF1dGggc2VydmVyIHRvIHRoZSBmcm9u dGVuZCBhbmQgZnJvbSB0aGUgZnJvbnRlbmQgdG8gdGhlDQpyZXNvdXJjZSBzZXJ2ZXJzLCB3aGVu IEkgcmVjZWl2ZWQgYXMgYSB2ZXJ5IG5pY2Ugc3VycHJpc2UgdGhlIG5ld3MgYWJvdXQgdG1pLWJm ZiBkcmFmdC4gSXQgd2FzIHN1Y2ggYSByZWxpZWYsIGFzIHRoZSBvcHRpb24gdG8gZGVsZWdhdGUg YWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2VuZCBjb21wb25lbnQsIHdoaWxlIHN0 aWxsIGFjY2Vzc2luZyByZXNvdXJjZSBzZXJ2ZXJzIGRpcmVjdGx5IGZyb20gdGhlIGZyb250ZW5k LCBzZWVtZWQgbW9zdCBzdWl0YWJsZSBhbmQNCndlbGwgYmFsYW5jZWQgZm9yIG91ciBjYXNlLg0K DQpJIGhhdmUgcmVhZCB0aGUgZHJhZnQgd2l0aCBncmVhdCBwbGVhc3VyZSwgYnV0IG9uZSB0aGlu ZyBjb25jZXJucyBtZSBpbiBpdC4NCg0KSW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm90b2Nv bCBmbG93ICgxLjIpLCBpbiB0aGUgc3RlcCBvZiB0b2tlbiByZXF1ZXN0IGZyb20gYmFja2VuZCB0 byBBUyAoc3RlcCBCKSwgaXQgbWVudGlvbnMgdGhhdCB0aGUgQVMgc2hvdWxkICJpc3N1ZSB0aGUg cmVxdWVzdGVkIHRva2VuIHdpdGhvdXQgcmVxdWlyaW5nIHVzZXIgaW50ZXJhY3Rpb24iLiBTYW1l DQp0aGluZyBpcyByZWNvbmZpcm1lZCBpbiBzZWN0aW9uIDQsIHN0ZXAgNDogInRoZSBiYWNrZW5k IHZlcmlmaWVzIHdoZXRoZXIgaXQgaGFzIHRoZSBuZWNlc3NhcnkgYXJ0aWZhY3RzIHRvIHJlcXVl c3QgaXQgdG8gdGhlDQphdXRob3JpemF0aW9uIHNlcnZlciB3aXRob3V0IHJlcXVpcmluZyB1c2Vy IGludGVyYWN0aW9uIi4NCg0KQnV0IGFuIGluaXRpYWwgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGUg cmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpcyByZXF1aXJlZCBi eSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZsb3cgKHNlY3Rpb24gMS4zLjEgb2YgdGhlIGRyYWZ0 LWlldGYtb2F1dGgtdjItMS0wMSkuDQoNClNvIHdoZXJlIGRvZXMgdGhpcyBpbnRlcmFjdGlvbiBm aXQgaW4gdGhlIHRtaS1iZmYgcHJvdG9jb2wgZmxvdz8gT3IgdG1pLWJmZiBpcyBub3Qgc3VwcG9z ZWQgdG8gYmUgdXNlZCB3aXRoIGF1dGhvcml6YXRpb24gY29kZSBmbG93Pw0KDQpUaGFuayB5b3Ug Zm9yIHlvdXIgdGltZSwNCmhvcGluZyB0byBoZWFyIGZyb20geW91LA0KU3RveWNoby4NCg0K0J3Q sCDQv9GCLCAxMiDRhNC10LIgMjAyMSDQsy4sIDIyOjQ2IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0 b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5j b21AZG1hcmMuaWV0Zi5vcmc+PiDQvdCw0L/QuNGB0LA6DQpEZWFyIGFsbCwNCkJyaWFuIGFuZCB5 b3VycyB0cnVseSBhcmUgcHJvcG9zaW5nIGEgbmV3IHNwZWNpZmljYXRpb24gdGhhdCBzaG93cyBo b3cgdGhlIHVzZXIgYWdlbnQgZnJvbnRlbmQgb2YgYSB3ZWIgYXBwIGNhbiBkZWxlZ2F0ZSB0b2tl biBhY3F1aXNpdGlvbiBhbmQgcGVyc2lzdGVuY2UgdG8gaXRzIGJhY2tlbmQsIGFuZCByZXF1ZXN0 IHN1Y2ggdG9rZW5zIHdoZW4gbmVlZGVkIGZvciBkaXJlY3QgYWNjZXNzIG9mIHByb3RlY3RlZCBy ZXNvdXJjZXMgZnJvbSB0aGUgZnJvbnRlbmQgY29kZS4NCg0KVGhlIHBhdHRlcm4gaXMgYWxyZWFk eSBpbiB1c2UsIGluIHByb3ByaWV0YXJ5IGZvcm0sIGJ5IHZhcmlvdXMgbW9kZXJuIGRldmVsb3Bt ZW50IHN0YWNrcywgc3VjaCBhcyBOZXh0LkpTLiBWYXJpYW50cyBvZiB0aGUgcGF0dGVybiwgb2Z0 ZW4gZGlzY3Vzc2VkIHVuZGVyIHRoZSBjYXRjaC1hbGwgdGVybSBCRkYgKGJhY2tlbmQgZm9yIGZy b250ZW5kKSwgaGF2ZSBiZWVuIG9mdGVuIG1lbnRpb25lZCBpbiB0aGlzIHdvcmtncm91cOKAmXMg YWN0aXZpdHksIGJ1dCBhbHdheXMgbGVmdCBhbGwgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byB0 aGUgcmVhZGVyLg0KV2UgYmVsaWV2ZSB0aGUgcGF0dGVybiBoYXMgbWVyaXQsIGFzIGNvcnJvYm9y YXRlZCBieSBpdHMgZ3Jvd2luZyBhZG9wdGlvbi4gQnkgZGVsZWdhdGluZyBhY2Nlc3MgdG9rZW4g YWNxdWlzaXRpb24gdG8gdGhlIGJhY2tlbmQsIHdlIGF2b2lkIG1hbnkgb2YgdGhlIG9mdGVuIGJy aXR0bGUgbW92aW5nIHBhcnRzIChhbmQgaW1wbGllZCBhdHRhY2sgc3VyZmFjZSkgcmVxdWlyZWQg dG8gYWNxdWlyZSBhY2Nlc3MgdG9rZW5zIGZyb20gYSB1c2VyIGFnZW50LiBUaGUgdG9wb2xvZ3kg YWxzbyByZWxpZXZlcyB0aGUgZnJvbnRlbmQgZnJvbSB0aGUgbmVlZCBvZiBwZXJzaXN0aW5nIHRv a2VucyBpbiBsb2NhbCBzdG9yYWdlLCBhIHdlbGwga25vd24gc29yZSBwb2ludCBvZiB1c2luZyBP QXV0aCBkaXJlY3RseSBpbiBKYXZhU2NyaXB0LCBieSByZWx5aW5nIG9uIGl0cyBiYWNrZW5kIHN0 b3JhZ2UgYW5kIHNlc3Npb24gdG8gcHJlc2VydmUgdG9rZW5zLg0KDQpBbHRob3VnaCB0aGUgc3Bl Y2lmaWNhdGlvbiBpcyB2ZXJ5IHNpbXBsZSwgcHJvdmlkaW5nIGV4cGxpY2l0IGd1aWRhbmNlIG9u IHRoZSBzY2VuYXJpbyBvZmZlcnMgbWFueSBhZHZhbnRhZ2VzLg0KLSBJdCBtYWtlcyBpdCBwb3Nz aWJsZSB0byBjcmVhdGUgaW50ZXJvcGVyYWJsZSBTREtzLCB3aGVyZSBmcm9udGVuZCBkZXYgc3Rh Y2tzIChhbnkgSlMgZmxhdm9yKSBjYW4gYmUgbWl4ZWQgYW5kIG1hdGNoZWQgd2l0aCBjb21wbGlh bnQgYmFja2VuZCBzdGFja3MgKG1pZGRsZXdhcmVzIGluIG5vZGUsIGphdmEsIEFTUC5ORVQ8aHR0 cDovL0FTUC5ORVQ+LCBQSFAgZXRjKQ0KLSBJdCBhbGxvd3MgdXMgdG8gcHJvdmlkZSBndWlkYW5j ZSBvbiBob3cgdG8gcHJvcGVybHkgdGFja2xlIHRoZSBzY2VuYXJpbyBhbmQgd2FybiBpbXBsZW1l bnRlcnMgYWdhaW5zdCBzZWN1cml0eSByaXNrcyAoc2NvcGUgZXNjYWxhdGlvbnMsIHVzaW5nIElE dG9rZW5zIGluc3RlYWQgb2YgYWNjZXNzIHRva2VucywgZXRjKQ0KLSBJdCBhbGxvd3MgdXMgdG8g ZGlzY3VzcyAoYW5kIHdoZW4gYXBwcm9wcmlhdGUsIHByb21vdGUpIHRoaXMgcGF0dGVybiBhcyBw YXJ0IG9mIHRoZSBicm93c2VyIGFwcHMgc2VjdXJpdHkgZ3VpZGFuY2UsIGFuZCBwb3NpdGlvbiB0 aGUgc2NlbmFyaW8gd2hlcmUgZnJvbnRlbmQgb25seSBjYWxscyBBUEkgb24gaXRzIG93biBiYWNr ZWQgKGhlbmNlIGRvZXNu4oCZdCBuZWVkIGFjY2VzcyB0b2tlbnMpIHNpbXBseSBhcyBhIHNwZWNp YWwgY2FzZSBvZiB0aGlzIG1vcmUgZ2VuZXJhbCBwYXR0ZXJuDQotIFRoaXMgYXBwcm9hY2ggbWFr ZXMgbW9ja2luZyBhbmQgdGVzdGluZyBhcHBzIHZlcnkgZWFzeSwgcG9zc2libHkgcHJldmVudGlu ZyBkZXZlbG9wZXJzIGZyb20gd2Vha2VuaW5nIHRoZSBzZWN1cml0eSBvZiB0aGVpciBzeXN0ZW0g KGVnIHR1cm5pbmcgb24gUk9QRyBvcHRpb25zKSAgb3IgdHVybmluZyB0byByaXNreSBwcmFjdGlj ZXMgbGlrZSBzY3JhcGluZw0KDQpOZWVkbGVzcyB0byBzYXksIHRoaXMgc3BlY2lmaWNhdGlvbiBk b2VzbuKAmXQgZW50aXJlbHkgZWxpbWluYXRlIHRoZSByaXNrcyBpbmhlcmVudCB0byBkaXJlY3Qg dXNlIG9mIGFjY2VzcyB0b2tlbnMgZnJvbSBhIGJyb3dzZXIuIEJ1dCByZWFsaXR5IGlzIHRoYXQg dGhlIHBhdHRlcm4gaXMgaW4gd2lkZXNwcmVhZCB1c2UsIGFuZCB0aGUgY2lyY3Vtc3RhbmNlcyBs ZWFkaW5nIHRvIHRoYXQgKGVnIGRldmVsb3BlcnMgb24gYSBwYXJ0aWN1bGFyIHByb2plY3Qgb25s eSB3b3JrIHdpdGggZnJvbnRlbmQgc3RhY2tzOyBjb21wb25lbnRzIGxpa2UgcmV2ZXJzZSBwcm94 aWVzIG1pZ2h0IG5vdCBhbHdheXMgYmUgdmlhYmxlOyBldGMpIGFyZW7igJl0IGdvaW5nIGF3YXkg YW55IHRpbWUgc29vbi4gQnkgcHJvdmlkaW5nIHNpbXBsZSBndWlkYW5jZSBvbiB0aGlzIHBhdHRl cm4sIHdlIGNhbiBzaW1wbGlmeSB0aGUgbGlmZSBvZiBtYW55IGRldmVsb3BlcnMgd2hpbGUgZW5z aHJpbmluZyBiYXNpYyBzZWN1cml0eSBoeWdpZW5lIGluIHNjZW5hcmlvcyB0aGF0IHdvdWxkIGhh dmUgb3RoZXJ3aXNlIGJlIGxlZnQgdG8gdGhlaXIgb3duIGRldmljZS4NCg0KTG9va2luZyBmb3J3 YXJkIGZvciB5b3VyIGZlZWRiYWNrIQ0KDQpCJlYNCg0K77u/T24gMi8xMi8yMSwgMTI6NDEsICJp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4i IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4+IHdyb3RlOg0KDQoNCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVydG9jY2kt b2F1dGgyLXRtaS1iZmYtMDAudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBWaXR0b3JpbyBCZXJ0b2NjaSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3Np dG9yeS4NCg0KICAgIE5hbWU6ICAgICAgICAgICAgICAgZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRt aS1iZmYNCiAgICBSZXZpc2lvbjogICAwMA0KICAgIFRpdGxlOiAgICAgICAgICAgICAgVG9rZW4g TWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kDQog ICAgRG9jdW1lbnQgZGF0ZTogICAgICAyMDIxLTAyLTEyDQogICAgR3JvdXA6ICAgICAgICAgICAg ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdlczogICAgICAgICAgICAgIDE2DQogICAg VVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVy dG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0DQogICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLw0K ICAgIEh0bWw6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0 LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLmh0bWwNCiAgICBIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAw DQoNCg0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBh IEphdmFTY3JpcHQgZnJvbnRlbmQgY2FuIGRlbGVnYXRlIGFjY2Vzcw0KICAgICAgIHRva2VuIGFj cXVpc2l0aW9uIHRvIGEgYmFja2VuZCBjb21wb25lbnQuICBJbiBzbyBkb2luZywgdGhlIGZyb250 ZW5kDQogICAgICAgY2FuIGFjY2VzcyByZXNvdXJjZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQg dGFraW5nIG9uIHRoZSBidXJkZW4gb2YNCiAgICAgICBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLCBwZXJzaXN0aW5nIHRva2VucywgYW5kDQogICAgICAgcGVyZm9y bWluZyBvcGVyYXRpb25zIHRoYXQgYXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2Vz IHdoZW4NCiAgICAgICBleGVjdXRlZCBpbiBhIHVzZXIgYWdlbnQsIGJ1dCBhcmUgc2FmZSBhbmQg d2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZA0KICAgICAgIGJ5IGEgY29uZmlkZW50aWFsIGNsaWVu dCBydW5uaW5nIG9uIGEgYmFja2VuZC4NCg0KDQoNCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24N CiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCiAgICBUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_CO6PR18MB40526B1D2AAA259B11BF8C78AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyBTdG95Y2hvIGZvciB5b3VyIGNvbW1lbnQhPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgVE1JLUJGRiBhc3N1bWVzIHRoYXQgdGhlIGludGVy YWN0aXZlIHBhcnQgb2YgdGhlIGZsb3cgKGNvZGUgZ3JhbnQgZm9yIGdpdmluZyBjb25zZW50IGFu ZCBnZXR0aW5nIGFjY2VzcytyZWZyZXNoIHRva2VucywgYW5kIGFueXRoaW5nIG5lY2Vzc2FyeSBm b3IgZXN0YWJsaXNoaW5nIHRoZSBzZXNzaW9uKSBvY2N1cnMgYmVmb3JlaGFuZC4gSXQgaXMgbm90 IGRlc2NyaWJlZCBpbiB0aGUgc3BlYyBpdHNlbGYsDQogYnV0IGl0IGlzIGV4cGVjdGVkIHRoYXQg c3VjaCBmbG93IChvciBleHRlbnNpb24gZ3JhbnQgd2l0aCB0aGUgc2FtZSBjaGFyYWN0ZXJpc3Rp Y3MpIGhhcHBlbmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SFRIITxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Vi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDtvYXV0aC1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgU3RveWNobyBTbGVwdHNvdiAmbHQ7c3RveWNoby5zbGVwdHNvdkBn bWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBGZWJydWFyeSAxMywgMjAy MSBhdCAxOTozOTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0 O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBU b2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRl bmQgKFRNSSBCRkYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBNci4gQmVydG9jY2ksPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGEgbm92aWNlIHlldCBhdCBBUElzIGFuZCBP QXV0aCwgYnV0IG5ldmVydGhlbGVzcyBhbSBlbnRydXN0ZWQgYnkgdGhlIGV4ZWN1dGl2ZXMgb2Yg b3VyIG9yZ2FuaXNhdGlvbiB0byBleHBvc2Ugc29tZSBvZiB0aGUgY2FwYWJpbGl0aWVzIG9mIG91 ciBzeXN0ZW0gdGhyb3VnaCBBUElzLiBGb3IgdGhhdCBJIGhhdmUgc2V0IG91dCB0byBpbXBsZW1l bnQgYW4gT0F1dGggc2VydmVyIChiYXNlZCBvbiB0aGUgMi4xDQogZHJhZnQpLCB3aGljaCBpcyBi YXNpY2FsbHkgZnVuY3Rpb25hbCBub3csIGFuZCB0aGUgY29ycmVzcG9uZGluZyBBUElzIChyZXNv dXJjZSBzZXJ2ZXJzKS4gT3VyIHRlYW0gd2lsbCBhbHNvIGhhdmUgdG8gaW1wbGVtZW50IHNvbWUg aW5pdGlhbCBmcm9udGVuZCBhcHBsaWNhdGlvbnMgd2hpY2ggd2lsbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29uc3VtZSB0aG9zZSBleHBvc2Vk IHJlc291cmNlcy4gSSB3YXMgZXhhY3RseSBhdCB0aGUgcG9pbnQgb2YgY29uc2lkZXJpbmcgaG93 IHRvIG9yZ2FuaXNlIHRoZSBjb3JyZXNwb25kZW5jZSBvZiB0aGUgYWNjZXNzIHRva2VuIGZyb20g dGhlIGF1dGggc2VydmVyIHRvIHRoZSBmcm9udGVuZCBhbmQgZnJvbSB0aGUgZnJvbnRlbmQgdG8g dGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5y ZXNvdXJjZSBzZXJ2ZXJzLCB3aGVuIEkgcmVjZWl2ZWQgYXMgYSB2ZXJ5IG5pY2Ugc3VycHJpc2Ug dGhlIG5ld3MgYWJvdXQgdG1pLWJmZiBkcmFmdC4gSXQgd2FzIHN1Y2ggYSByZWxpZWYsIGFzIHRo ZSBvcHRpb24gdG8gZGVsZWdhdGUgYWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2Vu ZCBjb21wb25lbnQsIHdoaWxlIHN0aWxsIGFjY2Vzc2luZyByZXNvdXJjZSBzZXJ2ZXJzIGRpcmVj dGx5IGZyb20NCiB0aGUgZnJvbnRlbmQsIHNlZW1lZCBtb3N0IHN1aXRhYmxlIGFuZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2VsbCBiYWxhbmNl ZCBmb3Igb3VyIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgaGF2ZSByZWFkIHRoZSBkcmFmdCB3aXRoIGdyZWF0IHBsZWFzdXJlLCBi dXQgb25lIHRoaW5nIGNvbmNlcm5zIG1lIGluIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHBy b3RvY29sIGZsb3cgKDEuMiksIGluIHRoZSBzdGVwIG9mIHRva2VuIHJlcXVlc3QgZnJvbSBiYWNr ZW5kIHRvIEFTIChzdGVwIEIpLCBpdCBtZW50aW9ucyB0aGF0IHRoZSBBUyBzaG91bGQgJnF1b3Q7 aXNzdWUgdGhlIHJlcXVlc3RlZCB0b2tlbiB3aXRob3V0IHJlcXVpcmluZyB1c2VyIGludGVyYWN0 aW9uJnF1b3Q7LiBTYW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50aGluZyBpcyByZWNvbmZpcm1lZCBpbiBzZWN0aW9uIDQsIHN0ZXAgNDogJnF1 b3Q7dGhlIGJhY2tlbmQgdmVyaWZpZXMgd2hldGhlciBpdCBoYXMgdGhlIG5lY2Vzc2FyeSBhcnRp ZmFjdHMgdG8gcmVxdWVzdCBpdCB0byB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmF1dGhvcml6YXRpb24gc2VydmVyIHdpdGhvdXQgcmVxdWly aW5nIHVzZXIgaW50ZXJhY3Rpb24mcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBhbiBpbml0aWFsIGludGVyYWN0aW9uIGJldHdl ZW4gdGhlIHJlc291cmNlIG93bmVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgcmVx dWlyZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gY29kZSBmbG93IChzZWN0aW9uIDEuMy4xIG9mIHRo ZSBkcmFmdC1pZXRmLW9hdXRoLXYyLTEtMDEpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3aGVyZSBkb2VzIHRoaXMgaW50ZXJhY3Rpb24g Zml0IGluIHRoZSB0bWktYmZmIHByb3RvY29sIGZsb3c/IE9yIHRtaS1iZmYgaXMgbm90IHN1cHBv c2VkIHRvIGJlIHVzZWQgd2l0aCBhdXRob3JpemF0aW9uIGNvZGUgZmxvdz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB5 b3VyIHRpbWUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ob3BpbmcgdG8gaGVhciBmcm9tIHlvdSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0b3ljaG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPtCd0LAg0L/RgiwgMTIg0YTQtdCyIDIwMjEg 0LMuLCAyMjo0NiBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9PGEgaHJl Zj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIj40MGF1dGgwLmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7INC90LDQv9C40YHQsDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgYWxsLDxicj4NCkJyaWFuIGFuZCB5 b3VycyB0cnVseSBhcmUgcHJvcG9zaW5nIGEgbmV3IHNwZWNpZmljYXRpb24gdGhhdCBzaG93cyBo b3cgdGhlIHVzZXIgYWdlbnQgZnJvbnRlbmQgb2YgYSB3ZWIgYXBwIGNhbiBkZWxlZ2F0ZSB0b2tl biBhY3F1aXNpdGlvbiBhbmQgcGVyc2lzdGVuY2UgdG8gaXRzIGJhY2tlbmQsIGFuZCByZXF1ZXN0 IHN1Y2ggdG9rZW5zIHdoZW4gbmVlZGVkIGZvciBkaXJlY3QgYWNjZXNzIG9mIHByb3RlY3RlZCBy ZXNvdXJjZXMgZnJvbSB0aGUNCiBmcm9udGVuZCBjb2RlLjxicj4NCjxicj4NClRoZSBwYXR0ZXJu IGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2YXJpb3VzIG1vZGVy biBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFudHMgb2YgdGhlIHBh dHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRlcm0gQkZGIChiYWNr ZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQgaW4gdGhpcyB3b3Jr Z3JvdXDigJlzIGFjdGl2aXR5LA0KIGJ1dCBhbHdheXMgbGVmdCBhbGwgaW1wbGVtZW50YXRpb24g ZGV0YWlscyB0byB0aGUgcmVhZGVyLjxicj4NCldlIGJlbGlldmUgdGhlIHBhdHRlcm4gaGFzIG1l cml0LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdyb3dpbmcgYWRvcHRpb24uIEJ5IGRlbGVnYXRp bmcgYWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIHRoZSBiYWNrZW5kLCB3ZSBhdm9pZCBtYW55 IG9mIHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBwYXJ0cyAoYW5kIGltcGxpZWQgYXR0YWNrIHN1 cmZhY2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNjZXNzIHRva2VucyBmcm9tIGEgdXNlciBhZ2Vu dC4NCiBUaGUgdG9wb2xvZ3kgYWxzbyByZWxpZXZlcyB0aGUgZnJvbnRlbmQgZnJvbSB0aGUgbmVl ZCBvZiBwZXJzaXN0aW5nIHRva2VucyBpbiBsb2NhbCBzdG9yYWdlLCBhIHdlbGwga25vd24gc29y ZSBwb2ludCBvZiB1c2luZyBPQXV0aCBkaXJlY3RseSBpbiBKYXZhU2NyaXB0LCBieSByZWx5aW5n IG9uIGl0cyBiYWNrZW5kIHN0b3JhZ2UgYW5kIHNlc3Npb24gdG8gcHJlc2VydmUgdG9rZW5zLjxi cj4NCjxicj4NCkFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHZlcnkgc2ltcGxlLCBwcm92 aWRpbmcgZXhwbGljaXQgZ3VpZGFuY2Ugb24gdGhlIHNjZW5hcmlvIG9mZmVycyBtYW55IGFkdmFu dGFnZXMuJm5ic3A7DQo8YnI+DQotIEl0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGNyZWF0ZSBpbnRl cm9wZXJhYmxlIFNES3MsIHdoZXJlIGZyb250ZW5kIGRldiBzdGFja3MgKGFueSBKUyBmbGF2b3Ip IGNhbiBiZSBtaXhlZCBhbmQgbWF0Y2hlZCB3aXRoIGNvbXBsaWFudCBiYWNrZW5kIHN0YWNrcyAo bWlkZGxld2FyZXMgaW4gbm9kZSwgamF2YSwNCjxhIGhyZWY9Imh0dHA6Ly9BU1AuTkVUIiB0YXJn ZXQ9Il9ibGFuayI+QVNQLk5FVDwvYT4sIFBIUCBldGMpPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8g cHJvdmlkZSBndWlkYW5jZSBvbiBob3cgdG8gcHJvcGVybHkgdGFja2xlIHRoZSBzY2VuYXJpbyBh bmQgd2FybiBpbXBsZW1lbnRlcnMgYWdhaW5zdCBzZWN1cml0eSByaXNrcyAoc2NvcGUgZXNjYWxh dGlvbnMsIHVzaW5nIElEdG9rZW5zIGluc3RlYWQgb2YgYWNjZXNzIHRva2VucywgZXRjKTxicj4N Ci0gSXQgYWxsb3dzIHVzIHRvIGRpc2N1c3MgKGFuZCB3aGVuIGFwcHJvcHJpYXRlLCBwcm9tb3Rl KSB0aGlzIHBhdHRlcm4gYXMgcGFydCBvZiB0aGUgYnJvd3NlciBhcHBzIHNlY3VyaXR5IGd1aWRh bmNlLCBhbmQgcG9zaXRpb24gdGhlIHNjZW5hcmlvIHdoZXJlIGZyb250ZW5kIG9ubHkgY2FsbHMg QVBJIG9uIGl0cyBvd24gYmFja2VkIChoZW5jZSBkb2VzbuKAmXQgbmVlZCBhY2Nlc3MgdG9rZW5z KSBzaW1wbHkgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhpcw0KIG1vcmUgZ2VuZXJhbCBwYXR0ZXJu PGJyPg0KLSBUaGlzIGFwcHJvYWNoIG1ha2VzIG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5 IGVhc3ksIHBvc3NpYmx5IHByZXZlbnRpbmcgZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUg c2VjdXJpdHkgb2YgdGhlaXIgc3lzdGVtIChlZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykmbmJz cDsgb3IgdHVybmluZyB0byByaXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZzxicj4NCjxicj4N Ck5lZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXNu4oCZdCBlbnRpcmVseSBl bGltaW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1c2Ugb2YgYWNjZXNzIHRva2Vu cyBmcm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0aGUgcGF0dGVybiBpcyBpbiB3 aWRlc3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxlYWRpbmcgdG8gdGhhdCAoZWcg ZGV2ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdA0KIG9ubHkgd29yayB3aXRoIGZyb250 ZW5kIHN0YWNrczsgY29tcG9uZW50cyBsaWtlIHJldmVyc2UgcHJveGllcyBtaWdodCBub3QgYWx3 YXlzIGJlIHZpYWJsZTsgZXRjKSBhcmVu4oCZdCBnb2luZyBhd2F5IGFueSB0aW1lIHNvb24uIEJ5 IHByb3ZpZGluZyBzaW1wbGUgZ3VpZGFuY2Ugb24gdGhpcyBwYXR0ZXJuLCB3ZSBjYW4gc2ltcGxp ZnkgdGhlIGxpZmUgb2YgbWFueSBkZXZlbG9wZXJzIHdoaWxlIGVuc2hyaW5pbmcgYmFzaWMgc2Vj dXJpdHkgaHlnaWVuZQ0KIGluIHNjZW5hcmlvcyB0aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJl IGxlZnQgdG8gdGhlaXIgb3duIGRldmljZS48YnI+DQo8YnI+DQpMb29raW5nIGZvcndhcmQgZm9y IHlvdXIgZmVlZGJhY2shPGJyPg0KPGJyPg0KQiZhbXA7ViZuYnNwOyA8YnI+DQo8YnI+DQrvu79P biAyLzEyLzIxLCAxMjo0MSwgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iZXJ0b2Nj aS1vYXV0aDItdG1pLWJmZi0wMC50eHQ8YnI+DQombmJzcDsgJm5ic3A7IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgVml0dG9yaW8gQmVydG9jY2kgYW5kIHBvc3RlZCB0byB0aGU8 YnI+DQombmJzcDsgJm5ic3A7IElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IE5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmPGJyPg0KJm5ic3A7ICZuYnNwOyBS ZXZpc2lvbjombmJzcDsgJm5ic3A7MDA8YnI+DQombmJzcDsgJm5ic3A7IFRpdGxlOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUb2tlbiBNZWRpYXRpbmcg YW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQ8YnI+DQombmJzcDsg Jm5ic3A7IERvY3VtZW50IGRhdGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMjAyMS0wMi0xMjxicj4N CiZuYnNwOyAmbmJzcDsgR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCiZuYnNwOyAmbmJzcDsgUGFn ZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDE2PGJy Pg0KJm5ic3A7ICZuYnNwOyBVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0 b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0 PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i ZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi88L2E+PGJyPg0K Jm5ic3A7ICZuYnNwOyBIdG1sOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2Nj aS1vYXV0aDItdG1pLWJmZi0wMC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC5odG1sPC9h Pjxicj4NCiZuYnNwOyAmbmJzcDsgSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRo Mi10bWktYmZmLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwPC9hPjxicj4NCjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhp cyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4gZGVsZWdh dGUgYWNjZXNzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dG9rZW4gYWNxdWlzaXRp b24gdG8gYSBiYWNrZW5kIGNvbXBvbmVudC4mbmJzcDsgSW4gc28gZG9pbmcsIHRoZSBmcm9udGVu ZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NhbiBhY2Nlc3MgcmVzb3VyY2Ugc2Vy dmVycyBkaXJlY3RseSB3aXRob3V0IHRha2luZyBvbiB0aGUgYnVyZGVuIG9mPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29tbXVuaWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciwgcGVyc2lzdGluZyB0b2tlbnMsIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3BlcmZvcm1pbmcgb3BlcmF0aW9ucyB0aGF0IGFyZSBmcmF1Z2h0IHdpdGggc2VjdXJp dHkgY2hhbGxlbmdlcyB3aGVuPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhlY3V0 ZWQgaW4gYSB1c2VyIGFnZW50LCBidXQgYXJlIHNhZmUgYW5kIHdlbGwgcHJvdmVuIHdoZW4gZXhl Y3V0ZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtieSBhIGNvbmZpZGVudGlhbCBj bGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJm5ic3A7ICZuYnNwOyB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8 L2E+Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CO6PR18MB40526B1D2AAA259B11BF8C78AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 03:29:00 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAB43A0C62 for ; Sun, 14 Feb 2021 03:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ65SKQi7Quy for ; Sun, 14 Feb 2021 03:28:55 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F643A0C61 for ; Sun, 14 Feb 2021 03:28:55 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id u11so2147347plg.13 for ; Sun, 14 Feb 2021 03:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=NAsHrceBBcuw0sQzA7qm8VEDmnCkMcij1pHyurHKi0A=; b=Y/sHeROHoVug/jwRGV1zLhSHrjPSAWxxM767jq0tfY1aIjJ+TMQgrEbQta1Ub4BCPb NRIzTZHTVzjYyGpOuEHKeT1hTP/J/NRe5Czxe6tQqZ7y5/6M6vTPtyjATiawQHHck2Yg Wgmvc9ClanB5vawo+98kcYG+EDRYnZLGx4LfsRfLHppJGqPqhrp5WwHSwTf2p1FBbif4 yxGCaenX6ay6HsM8+fuuxnsNcDOQULnFU38gFu/1t7nu4WiMyeSz1Elu8mVOm2cfUg7P uZg/d5dpi9jIFWPnQnb/7bk8aCd/P8CMwfGXglWpaSbzumw/N+tozswyPBdo+u6ycfPD PgPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=NAsHrceBBcuw0sQzA7qm8VEDmnCkMcij1pHyurHKi0A=; b=qb1D9lSWzrw1Xi32TdIyFCeCrpgZ2LqS+5vcvPXQBM9KJJMpXLIad2xy4TJoizwBmm 9KNvn93J15uxi3HD+zeMtpuspO7FVxGqIVWyLF8rQ9zB9dlKmjg7/6AwfNGFe8QO0LJp l2bElRPlQPoZ44TZ+/NXR48iJoNxlcDH6+ijc1T2/9bvKVguMbsjh7dwZ93VfngbT/We bNKufS5bAM4IYL6QA7vXVNRPeA+w7RWByOiXf97Uld56CldHvhmTGPzk7O1g5HfckQK+ k4OaO976pvwwfXBQ+pUEQanpH2C5ZAM8Jtx8fINygqP5hkFYDr0jLthd+HdtPw9aa0Mh MZQw== X-Gm-Message-State: AOAM533YAOKJqSh1M66+W8axAv439NYpCPiILomJgPfRB7srCJNcMN0r VM5sLcIHIKzVfC1jkRYwcx9AXRkXUOkJaw== X-Google-Smtp-Source: ABdhPJwG2HsYSMvEFj/xIAy/qitWXk53vBaHfn5R1jInYlZvhJZCcDfmw5fXvIMZr/81nYeGd3gNSw== X-Received: by 2002:a17:902:7006:b029:e3:2586:2d5 with SMTP id y6-20020a1709027006b02900e3258602d5mr9184799plk.36.1613302134891; Sun, 14 Feb 2021 03:28:54 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id e15sm16655820pgr.81.2021.02.14.03.28.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 03:28:54 -0800 (PST) From: Vittorio Bertocci To: Neil Madden CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAA1Za8= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 11:28:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052C7D49F34DDFCA1687D63AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 11:28:59 -0000 --_000_CO6PR18MB4052C7D49F34DDFCA1687D63AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmVpbCwNClRoYW5rcyBmb3IgdGhlIHByb21wdCBjb21tZW50cyENCg0KICAqICAgUmU6IEdF VCB2cyBQT1NULA0KcGVyc29uYWxseSBJ4oCZZCBiZSBmaW5lIHdpdGggcmVzdHJpY3RpbmcgdG8g UE9TVC4NCg0KDQogICogICBSZTogUk8tQVMsIGludGVyYWN0aW9uLQ0KcGVyaGFwcyBpdCBpcyBu b3QgdmVyeSBjbGVhciBmcm9tIHRoZSB0ZXh0IGF0IHRoZSBtb21lbnQgKGZpcnN0IGRyYWZ0KSwg YnV0IHRoYXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBSTyB3ZW50IHRocnUgd2hhdGV2ZXIgaW50ZXJh Y3RpdmUgc3RlcHMgYXJlIG5lY2Vzc2FyeSB0byBlc3RhYmxpc2ggYSBzZXNzaW9uIChlZyBzaWdu IGluLCBhc3N1bWluZyB0aGUgQVMgaXMgc2F5IGFuIE9JREMgcHJvdmlkZXIpIGFuZCBvYnRhaW4g YmVmb3JlaGFuZCB0aGUgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VucyB0aGF0IHdpbGwg YmUgbmVlZGVkIGR1cmluZyB0aGUgYXBwIGFjdGl2aXRpZXMgdGFraW5nIHBsYWNlIGFmdGVyICB0 aGF0LiBJbiBjb25jcmV0ZSB0ZXJtcywgaW1hZ2luZSB0aGF0IHRoZSBiYWNrZW5kIHBlcmZvcm1z IGFuIGF1dGhvcml6YXRpb24gY29kZSBncmFudCByZXF1ZXN0aW5nIGFuIElEdG9rZW4sIGFjY2Vz cyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBCRUZPUkUgdGhlIGFjdGl2aXRpZXMgZGVzY3JpYmVk IGluIFRNSS1CRkYgdGFrZSBwbGFjZS4NClRoZSBjdXJyZW50IGxhbmd1YWdlIHRyeWluZyB0byBl eHByZXNzIHRoYXQgaXMgaW4gMS4yOg0KQXMgYSBwcmVyZXF1aXNpdGUgZm9yIHRoZSBmbG93IGRl c2NyaWJlZCBiZWxvdywgdGhlIGJhY2tlbmQgTVVTVCBoYXZlIGVzdGFibGlzaGVkIGEgc2VjdXJl IHNlc3Npb24gd2l0aCB0aGUgdXNlciBhZ2VudCwgc28gdGhhdCBhbGwgcmVxdWVzdHMgZnJvbSB0 aGF0IHVzZXIgYWdlbnQgdG93YXJkIHRoZSBiYWNrZW5kIG9jY3VyIG92ZXIgSFRUUFMgYW5kIGNh cnJ5IGEgdmFsaWQgc2Vzc2lvbiBhcnRpZmFjdCAoc3VjaCBhcyBhIGNvb2tpZSkgdGhhdCB0aGUg YmFja2VuZCBjYW4gdmFsaWRhdGUuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFuZGF0ZSBhbnkg c3BlY2lmaWMgbWVjaGFuaXNtIHRvIGVzdGFibGlzaCBhbmQgbWFpbnRhaW4gdGhhdCBzZXNzaW9u Lg0KQW5kDQpjYWNoZWQsIGl0IHJlcXVlc3RzIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh IG5ldyBhY2Nlc3MgdG9rZW4gd2l0aCB0aGUgcmVxdWlyZWQgY2hhcmFjdGVyaXN0aWNzLCB1c2lu ZyBhbnkgYXJ0aWZhY3RzIHByZXZpb3VzeSBvYnRhaW5lZCAoZWcgcmVmcmVzaCB0b2tlbikgYW5k IGdyYW50cyB0aGF0IHdpbGwgYWxsb3cgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3Vl IHRoZSByZXF1ZXN0ZWQgdG9rZW4gd2l0aG91dCByZXF1aXJpbmcgdXNlciBpbnRlcmFjdGlvbi4N Cg0KDQogICogICAgSWYgdGhlIGJhY2tlbmQgaXMgYWxyZWFkeSBpbXBsaWNpdGx5IHRydXN0ZWQg dGhlbiBjb3VsZG7igJl0IHlvdSBza2lwIE9BdXRoIGFuZCBqdXN0IGdldCB0aGUgYmFja2VuZCB0 byBpc3N1ZSBzaG9ydC1saXZlZCBKV1RzIHRvIHRoZSBmcm9udGVuZCB0aGF0IGl0IGNhbiB1c2Ug Zm9yIEFQSSBhY2Nlc3M/DQpGb3IgdGhlIHRydXN0ZWQgcGFydCwgc2VlIGFib3ZlLiBGb3IgdGhl IHNob3J0IGxpdmVkIEpXVHMsIHRoYXTigJlzIG5vdCByZWFsbHkgYW4gb3B0aW9uLiBUaGUgbW9z dCBnZW5lcmljIHNjZW5hcmlvIGFkZHJlc3NlZCBoZXJlIGlzIGZvciBBUElzIHRoYXQgYWNjZXB0 IHRva2VucyBpc3N1ZWQgYnkgdGhlIEFTOyB0aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVtIGFz IGEgY2xpZW50LCBidXQgaXQgY2Fubm90IG1pbnQgdGhlbS4gSW1hZ2luZSB3ZeKAmXJlIHRhbGtp bmcgYWJvdXQgYSBTUEEgYXBwbGljYXRpb24gdGhhdCBzaWducyBpbiB1c2VycyB1c2luZyBBenVy ZSBBRCwgYW5kIG5lZWRzIHRvIGNhbGwgT2ZmaWNlIGFuZCBBenVyZSBBUElzLiBUaGUgU1BBIGJh Y2tlbmQgY2Fubm90IGlzc3VlIHRva2VucyBmb3IgdGhvc2UgQVBJcywgaXQgY2FuIG9ubHkgcmVx dWVzdCB0aGVtIHRvIHRoZSBBenVyZSBBRCBBUy4NCg0KDQogICogICBJZiB5b3Ugd2FudCB0byBh bGxvdyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYtdG9rZW4gZW5kcG9p bnQgY2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBhdXRob3JpemF0aW9u IGVuZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhlIHVzZXIgdG8uIChF ZyB0aGUgYmFja2VuZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJ IHRoYXQgcmVmZXJlbmNlcyB0aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7i gJl0IHBhc3NlZCB0aHJvdWdoIHRoZSBmcm9udGVuZCkuDQpXZSBkaWQgY29uc2lkZXIgYWRkaW5n IHNvbWV0aGluZyB0byB0aGF0IGVmZmVjdCwgYW4gZXJyb3IgbWVzc2FnZSB0aGF0IGNhbiBkaXJl Y3QgdGhlIGZyb250ZW5kIHRvIHBlcmZvcm0gdGhlIGludGVyYWN0aXZlIHBvcnRpb24gbmVjZXNz YXJ5IGZvciB0aGlzIHRvcG9sb2d5IHRvIHdvcmsuIEl0IHdvdWxkIGJlIHNvbWV0aGluZyBzaW1p bGFyIHRvIHRoZSBJRFAgaW5pdGlhdGVkIGxvZ2luIGluIE9JREMsIHdoZXJlIHRoZSBjbGllbnQg b2ZmZXJzIGFuIGVuZHBvaW50IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBpbml0aWF0ZSBhIHNpZ24g aW4gZmxvdyAoaGVuY2UgaW5qZWN0IGFsbCB0aGUgbmVjZXNzYXJ5IG5vbmNlcyBldGMpLiBXZSBk aWRu4oCZdCBhZGQgaXQgdXBmcm9udCBhbmQgbGVmdCBpdCBhcyBleGVyY2lzZSBmb3IgdGhlIHJl YWRlciBtb3N0bHkgYmVjYXVzZSBpdOKAmXMgbm90IGVhc3kgdG8gbW9kZWwgcHJvcGVybHkgYW5k IGJlZm9yZSBvcGVuaW5nIHRoYXQgd29yayBmcm9udCB3ZSB3YW50ZWQgdG8gc2VlIGhvdyB0aGUg aWRlYSB3YXMgcmVjZWl2ZWQuDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+DQpE YXRlOiBTdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAwOjE3DQpUbzogVml0dG9yaW8gQmVy dG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPg0KQ2M6 ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZy b250ZW5kIChUTUkgQkZGKQ0KDQpJIGhhdmUgYSBsb3Qgb2Ygc2VjdXJpdHkgY29uY2VybnMgYWJv dXQgdGhpcyBkcmFmdC4NCg0KVGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJpdHkgaXNzdWVzIGFz c29jaWF0ZWQgd2l0aCBoYW5kbGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBmcm9udGVuZCBidXQg bmV2ZXIgcmVhbGx5IHNwZWxscyB0aGVtIG91dC4gRnJvbSB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgaXQgc2VlbXMgdGhhdCB0aGUgcHJpbWFyeSBjb25jZXJuIGlzIHdpdGggdGhlZnQgb2Yg YWNjZXNzIHRva2VucyBmcm9tIGxvY2FsIHN0b3JhZ2UuIFRvIGRvIHRoaXMgeW914oCZZCBuZWVk IGFuIFhTUyBhdHRhY2suIEJ1dCBpbiB0aGF0IGNhc2UsIHdvdWxkbuKAmXQgdGhlIGF0dGFja2Vy IHNpbXBseSB1c2UgdGhlIFhTUyB0byBtYWtlIGEgY2FsbCB0byB0aGUgYmZmLXRva2VuIGVuZHBv aW50IGluc3RlYWQ/DQoNClRoZSBjb21iaW5hdGlvbiBvZiB0aGUgYmZmLXRva2VuIGVuZHBvaW50 IHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEdFVCByZXF1ZXN0cyB0b2dldGhlciB3aXRoIHRoZSBo aW50IHRvIHVzZSBjb29raWUtYmFzZWQgYXV0aGVudGljYXRpb24gaXMgbGlrZWx5IGdvaW5nIHRv IHB1bmNoIGEgaG9sZSBpbiBtb3N0IENTUkYgZGVmZW5zZXMsIHdoaWNoIGFzc3VtZSB0aGF0IEdF VHMgYXJlIHNhZmUuIFRoZSBvbmx5IHRoaW5nIHByZXZlbnRpbmcgdGhpcyBiZWluZyBleHBsb2l0 YWJsZSBpcyBDcm9zcy1PcmlnaW4gUmVhZCBCbG9ja2luZyAoaHR0cHM6Ly9jaHJvbWl1bS5nb29n bGVzb3VyY2UuY29tL2Nocm9taXVtL3NyYy8rL21hc3Rlci9zZXJ2aWNlcy9uZXR3b3JrL2Nyb3Nz X29yaWdpbl9yZWFkX2Jsb2NraW5nX2V4cGxhaW5lci5tZCkgZHVlIHRvIHRoZSBKU09OIGNvbnRl bnQtdHlwZS4gVGhhdCBtYWtlcyBtZSByZWFsbHkgbmVydm91cy4gV2Ugc2hvdWxkIGF0IGxlYXN0 IG1hbmRhdGUgWC1Db250ZW50LVR5cGUtT3B0aW9uczogbm9zbmlmZiBvbiB0aGF0IHJlc3BvbnNl LiBJ4oCZZCBmZWVsIG1vcmUgY29tZm9ydGFibGUgaWYgdGhpcyB3YXMgYSBQT1NUIHJlcXVlc3Qg b25seS4NCg0KQXMgU3RveWNobyBTbGVwdHNvdiBtZW50aW9uZWQgaW4gdGhlIG90aGVyIGVtYWls LCB0aGUgbGFjayBvZiBmcm9udC1jaGFubmVsIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgQVMg YW5kIHRoZSBSTyBzZWVtcyBvZGQuIElmIHRoZSBiYWNrZW5kIGlzIGFscmVhZHkgaW1wbGljaXRs eSB0cnVzdGVkIHRoZW4gY291bGRu4oCZdCB5b3Ugc2tpcCBPQXV0aCBhbmQganVzdCBnZXQgdGhl IGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgSldUcyB0byB0aGUgZnJvbnRlbmQgdGhhdCBp dCBjYW4gdXNlIGZvciBBUEkgYWNjZXNzPw0KDQpJZiB5b3Ugd2FudCB0byBhbGxvdyBhdXRoIGNv ZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgY2FuIHJldHVy biBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVS SSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhlIHVzZXIgdG8uIChFZyB0aGUgYmFja2Vu ZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJIHRoYXQgcmVmZXJl bmNlcyB0aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7igJl0IHBhc3NlZCB0 aHJvdWdoIHRoZSBmcm9udGVuZCkuDQoNCuKAlCBOZWlsDQoNCg0KDQpPbiAxMiBGZWIgMjAyMSwg YXQgMjA6NDYsIFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNv bUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQrvu79EZWFyIGFsbCwNCkJyaWFuIGFuZCB5b3VycyB0 cnVseSBhcmUgcHJvcG9zaW5nIGEgbmV3IHNwZWNpZmljYXRpb24gdGhhdCBzaG93cyBob3cgdGhl IHVzZXIgYWdlbnQgZnJvbnRlbmQgb2YgYSB3ZWIgYXBwIGNhbiBkZWxlZ2F0ZSB0b2tlbiBhY3F1 aXNpdGlvbiBhbmQgcGVyc2lzdGVuY2UgdG8gaXRzIGJhY2tlbmQsIGFuZCByZXF1ZXN0IHN1Y2gg dG9rZW5zIHdoZW4gbmVlZGVkIGZvciBkaXJlY3QgYWNjZXNzIG9mIHByb3RlY3RlZCByZXNvdXJj ZXMgZnJvbSB0aGUgZnJvbnRlbmQgY29kZS4NCg0KVGhlIHBhdHRlcm4gaXMgYWxyZWFkeSBpbiB1 c2UsIGluIHByb3ByaWV0YXJ5IGZvcm0sIGJ5IHZhcmlvdXMgbW9kZXJuIGRldmVsb3BtZW50IHN0 YWNrcywgc3VjaCBhcyBOZXh0LkpTLiBWYXJpYW50cyBvZiB0aGUgcGF0dGVybiwgb2Z0ZW4gZGlz Y3Vzc2VkIHVuZGVyIHRoZSBjYXRjaC1hbGwgdGVybSBCRkYgKGJhY2tlbmQgZm9yIGZyb250ZW5k KSwgaGF2ZSBiZWVuIG9mdGVuIG1lbnRpb25lZCBpbiB0aGlzIHdvcmtncm91cOKAmXMgYWN0aXZp dHksIGJ1dCBhbHdheXMgbGVmdCBhbGwgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byB0aGUgcmVh ZGVyLg0KV2UgYmVsaWV2ZSB0aGUgcGF0dGVybiBoYXMgbWVyaXQsIGFzIGNvcnJvYm9yYXRlZCBi eSBpdHMgZ3Jvd2luZyBhZG9wdGlvbi4gQnkgZGVsZWdhdGluZyBhY2Nlc3MgdG9rZW4gYWNxdWlz aXRpb24gdG8gdGhlIGJhY2tlbmQsIHdlIGF2b2lkIG1hbnkgb2YgdGhlIG9mdGVuIGJyaXR0bGUg bW92aW5nIHBhcnRzIChhbmQgaW1wbGllZCBhdHRhY2sgc3VyZmFjZSkgcmVxdWlyZWQgdG8gYWNx dWlyZSBhY2Nlc3MgdG9rZW5zIGZyb20gYSB1c2VyIGFnZW50LiBUaGUgdG9wb2xvZ3kgYWxzbyBy ZWxpZXZlcyB0aGUgZnJvbnRlbmQgZnJvbSB0aGUgbmVlZCBvZiBwZXJzaXN0aW5nIHRva2VucyBp biBsb2NhbCBzdG9yYWdlLCBhIHdlbGwga25vd24gc29yZSBwb2ludCBvZiB1c2luZyBPQXV0aCBk aXJlY3RseSBpbiBKYXZhU2NyaXB0LCBieSByZWx5aW5nIG9uIGl0cyBiYWNrZW5kIHN0b3JhZ2Ug YW5kIHNlc3Npb24gdG8gcHJlc2VydmUgdG9rZW5zLg0KDQpBbHRob3VnaCB0aGUgc3BlY2lmaWNh dGlvbiBpcyB2ZXJ5IHNpbXBsZSwgcHJvdmlkaW5nIGV4cGxpY2l0IGd1aWRhbmNlIG9uIHRoZSBz Y2VuYXJpbyBvZmZlcnMgbWFueSBhZHZhbnRhZ2VzLg0KLSBJdCBtYWtlcyBpdCBwb3NzaWJsZSB0 byBjcmVhdGUgaW50ZXJvcGVyYWJsZSBTREtzLCB3aGVyZSBmcm9udGVuZCBkZXYgc3RhY2tzIChh bnkgSlMgZmxhdm9yKSBjYW4gYmUgbWl4ZWQgYW5kIG1hdGNoZWQgd2l0aCBjb21wbGlhbnQgYmFj a2VuZCBzdGFja3MgKG1pZGRsZXdhcmVzIGluIG5vZGUsIGphdmEsIEFTUC5ORVQsIFBIUCBldGMp DQotIEl0IGFsbG93cyB1cyB0byBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9wZXJseSB0 YWNrbGUgdGhlIHNjZW5hcmlvIGFuZCB3YXJuIGltcGxlbWVudGVycyBhZ2FpbnN0IHNlY3VyaXR5 IHJpc2tzIChzY29wZSBlc2NhbGF0aW9ucywgdXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBvZiBhY2Nl c3MgdG9rZW5zLCBldGMpDQotIEl0IGFsbG93cyB1cyB0byBkaXNjdXNzIChhbmQgd2hlbiBhcHBy b3ByaWF0ZSwgcHJvbW90ZSkgdGhpcyBwYXR0ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dzZXIgYXBw cyBzZWN1cml0eSBndWlkYW5jZSwgYW5kIHBvc2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVyZSBmcm9u dGVuZCBvbmx5IGNhbGxzIEFQSSBvbiBpdHMgb3duIGJhY2tlZCAoaGVuY2UgZG9lc27igJl0IG5l ZWQgYWNjZXNzIHRva2Vucykgc2ltcGx5IGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMgbW9yZSBn ZW5lcmFsIHBhdHRlcm4NCi0gVGhpcyBhcHByb2FjaCBtYWtlcyBtb2NraW5nIGFuZCB0ZXN0aW5n IGFwcHMgdmVyeSBlYXN5LCBwb3NzaWJseSBwcmV2ZW50aW5nIGRldmVsb3BlcnMgZnJvbSB3ZWFr ZW5pbmcgdGhlIHNlY3VyaXR5IG9mIHRoZWlyIHN5c3RlbSAoZWcgdHVybmluZyBvbiBST1BHIG9w dGlvbnMpICBvciB0dXJuaW5nIHRvIHJpc2t5IHByYWN0aWNlcyBsaWtlIHNjcmFwaW5nDQoNCk5l ZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXNu4oCZdCBlbnRpcmVseSBlbGlt aW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1c2Ugb2YgYWNjZXNzIHRva2VucyBm cm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0aGUgcGF0dGVybiBpcyBpbiB3aWRl c3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxlYWRpbmcgdG8gdGhhdCAoZWcgZGV2 ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdCBvbmx5IHdvcmsgd2l0aCBmcm9udGVuZCBz dGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZlcnNlIHByb3hpZXMgbWlnaHQgbm90IGFsd2F5cyBi ZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29pbmcgYXdheSBhbnkgdGltZSBzb29uLiBCeSBwcm92 aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRoaXMgcGF0dGVybiwgd2UgY2FuIHNpbXBsaWZ5IHRo ZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3aGlsZSBlbnNocmluaW5nIGJhc2ljIHNlY3VyaXR5 IGh5Z2llbmUgaW4gc2NlbmFyaW9zIHRoYXQgd291bGQgaGF2ZSBvdGhlcndpc2UgYmUgbGVmdCB0 byB0aGVpciBvd24gZGV2aWNlLg0KDQpMb29raW5nIGZvcndhcmQgZm9yIHlvdXIgZmVlZGJhY2sh DQoNCkImVg0KDQrvu79PbiAyLzEyLzIxLCAxMjo0MSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KICAgQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dA0KICAgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWaXR0b3JpbyBCZXJ0b2NjaSBhbmQgcG9zdGVk IHRvIHRoZQ0KICAgSUVURiByZXBvc2l0b3J5Lg0KDQogICBOYW1lOiAgICAgICAgZHJhZnQtYmVy dG9jY2ktb2F1dGgyLXRtaS1iZmYNCiAgIFJldmlzaW9uOiAgICAwMA0KICAgVGl0bGU6ICAgICAg ICBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJv bnRlbmQNCiAgIERvY3VtZW50IGRhdGU6ICAgIDIwMjEtMDItMTINCiAgIEdyb3VwOiAgICAgICAg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICBQYWdlczogICAgICAgIDE2DQogICBVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0 aDItdG1pLWJmZi0wMC50eHQNCiAgIFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi8NCiAgIEh0bWw6ICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9h dXRoMi10bWktYmZmLTAwLmh0bWwNCiAgIEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDANCg0KDQogICBBYnN0 cmFjdDoNCiAgICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBhIEphdmFTY3JpcHQgZnJv bnRlbmQgY2FuIGRlbGVnYXRlIGFjY2Vzcw0KICAgICAgdG9rZW4gYWNxdWlzaXRpb24gdG8gYSBi YWNrZW5kIGNvbXBvbmVudC4gIEluIHNvIGRvaW5nLCB0aGUgZnJvbnRlbmQNCiAgICAgIGNhbiBh Y2Nlc3MgcmVzb3VyY2Ugc2VydmVycyBkaXJlY3RseSB3aXRob3V0IHRha2luZyBvbiB0aGUgYnVy ZGVuIG9mDQogICAgICBjb21tdW5pY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LCBwZXJzaXN0aW5nIHRva2VucywgYW5kDQogICAgICBwZXJmb3JtaW5nIG9wZXJhdGlvbnMgdGhh dCBhcmUgZnJhdWdodCB3aXRoIHNlY3VyaXR5IGNoYWxsZW5nZXMgd2hlbg0KICAgICAgZXhlY3V0 ZWQgaW4gYSB1c2VyIGFnZW50LCBidXQgYXJlIHNhZmUgYW5kIHdlbGwgcHJvdmVuIHdoZW4gZXhl Y3V0ZWQNCiAgICAgIGJ5IGEgY29uZmlkZW50aWFsIGNsaWVudCBydW5uaW5nIG9uIGEgYmFja2Vu ZC4NCg0KDQoNCg0KICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KICAg VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkZvcmdlUm9jayB2 YWx1ZXMgeW91ciBQcml2YWN5PGh0dHBzOi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1wcml2YWN5 Pg0K --_000_CO6PR18MB4052C7D49F34DDFCA1687D63AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJOb3RvIFNhbnMi Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgNSA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6LXdlYmtpdC1zdGFuZGFyZDsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5hcHBs ZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNl O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjM1NzA0NDU3NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MjgxMTY0MDIyIC03MzM4NDI3NDIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE5laWwsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBwcm9tcHQgY29tbWVudHMhPG86 cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+UmU6IEdFVCB2cyBQT1NULDxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj5wZXJzb25hbGx5 IEnigJlkIGJlIGZpbmUgd2l0aCByZXN0cmljdGluZyB0byBQT1NULjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj5SZTogUk8tQVMsIGludGVyYWN0aW9uLQ0KPG86cD48L286cD48L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wZXJoYXBzIGl0IGlzIG5vdCB2ZXJ5IGNsZWFy IGZyb20gdGhlIHRleHQgYXQgdGhlIG1vbWVudCAoZmlyc3QgZHJhZnQpLCBidXQgdGhhdCBpcyBh c3N1bWVkIHRoYXQgdGhlIFJPIHdlbnQgdGhydSB3aGF0ZXZlciBpbnRlcmFjdGl2ZSBzdGVwcyBh cmUgbmVjZXNzYXJ5IHRvIGVzdGFibGlzaCBhIHNlc3Npb24gKGVnIHNpZ24gaW4sIGFzc3VtaW5n IHRoZSBBUyBpcyBzYXkgYW4gT0lEQyBwcm92aWRlcikgYW5kDQogb2J0YWluIGJlZm9yZWhhbmQg dGhlIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbnMgdGhhdCB3aWxsIGJlIG5lZWRlZCBk dXJpbmcgdGhlIGFwcCBhY3Rpdml0aWVzIHRha2luZyBwbGFjZSBhZnRlciAmbmJzcDt0aGF0LiBJ biBjb25jcmV0ZSB0ZXJtcywgaW1hZ2luZSB0aGF0IHRoZSBiYWNrZW5kIHBlcmZvcm1zIGFuIGF1 dGhvcml6YXRpb24gY29kZSBncmFudCByZXF1ZXN0aW5nIGFuIElEdG9rZW4sIGFjY2VzcyB0b2tl biBhbmQgcmVmcmVzaCB0b2tlbg0KIEJFRk9SRSB0aGUgYWN0aXZpdGllcyBkZXNjcmliZWQgaW4g VE1JLUJGRiB0YWtlIHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGN1cnJlbnQgbGFuZ3VhZ2UgdHJ5aW5nIHRvIGV4cHJlc3MgdGhhdCBpcyBpbiAxLjI6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtOb3RvIFNhbnMmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPkFzIGEgcHJlcmVxdWlzaXRlIGZvciB0aGUgZmxv dyBkZXNjcmliZWQgYmVsb3csIHRoZSBiYWNrZW5kIE1VU1QgaGF2ZSBlc3RhYmxpc2hlZCBhIHNl Y3VyZSBzZXNzaW9uIHdpdGggdGhlIHVzZXIgYWdlbnQsIHNvIHRoYXQgYWxsIHJlcXVlc3RzDQog ZnJvbSB0aGF0IHVzZXIgYWdlbnQgdG93YXJkIHRoZSBiYWNrZW5kIG9jY3VyIG92ZXIgSFRUUFMg YW5kIGNhcnJ5IGEgdmFsaWQgc2Vzc2lvbiBhcnRpZmFjdCAoc3VjaCBhcyBhIGNvb2tpZSkgdGhh dCB0aGUgYmFja2VuZCBjYW4gdmFsaWRhdGUuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFuZGF0 ZSBhbnkgc3BlY2lmaWMgbWVjaGFuaXNtIHRvIGVzdGFibGlzaCBhbmQgbWFpbnRhaW4gdGhhdCBz ZXNzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Tm90byBTYW5zJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5jYWNoZWQsIGl0IHJlcXVlc3RzIHRvIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBhIG5ldyBhY2Nlc3MgdG9rZW4gd2l0aCB0aGUgcmVxdWlyZWQg Y2hhcmFjdGVyaXN0aWNzLCB1c2luZyBhbnkgYXJ0aWZhY3RzIHByZXZpb3VzeSBvYnRhaW5lZA0K IChlZyByZWZyZXNoIHRva2VuKSBhbmQgZ3JhbnRzIHRoYXQgd2lsbCBhbGxvdyB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgdG8gaXNzdWUgdGhlIHJlcXVlc3RlZCB0b2tlbiB3aXRob3V0IHJlcXVp cmluZyB1c2VyIGludGVyYWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3NwYW4+SWYgdGhlIGJhY2tlbmQgaXMgYWxyZWFkeSBpbXBsaWNpdGx5IHRydXN0ZWQg dGhlbg0KIGNvdWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNrZW5k IHRvIGlzc3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2FuIHVz ZSBmb3IgQVBJIGFjY2Vzcz88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZvciB0aGUgdHJ1c3RlZCBwYXJ0LCBzZWUgYWJvdmUuIEZvciB0aGUgc2hvcnQgbGl2ZWQg SldUcywgdGhhdOKAmXMgbm90IHJlYWxseSBhbiBvcHRpb24uIFRoZSBtb3N0IGdlbmVyaWMgc2Nl bmFyaW8gYWRkcmVzc2VkIGhlcmUgaXMgZm9yIEFQSXMgdGhhdCBhY2NlcHQgdG9rZW5zIGlzc3Vl ZCBieSB0aGUgQVM7IHRoZSBiYWNrZW5kIGNhbiByZXF1ZXN0IHRoZW0gYXMgYSBjbGllbnQsIGJ1 dCBpdCBjYW5ub3QgbWludA0KIHRoZW0uIEltYWdpbmUgd2XigJlyZSB0YWxraW5nIGFib3V0IGEg U1BBIGFwcGxpY2F0aW9uIHRoYXQgc2lnbnMgaW4gdXNlcnMgdXNpbmcgQXp1cmUgQUQsIGFuZCBu ZWVkcyB0byBjYWxsIE9mZmljZSBhbmQgQXp1cmUgQVBJcy4gVGhlIFNQQSBiYWNrZW5kIGNhbm5v dCBpc3N1ZSB0b2tlbnMgZm9yIHRob3NlIEFQSXMsIGl0IGNhbiBvbmx5IHJlcXVlc3QgdGhlbSB0 byB0aGUgQXp1cmUgQUQgQVMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JZiB5b3Ugd2FudCB0byBhbGxvdyBhdXRoIGNvZGUg ZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgY2FuIHJldHVybiBh IHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB0 aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhlIHVzZXINCiB0by4gKEVnIHRoZSBiYWNrZW5k IGNhbiBkbyBhIFBBUiByZXF1ZXN0IGZpcnN0IGFuZCByZXR1cm4gYSBVUkkgdGhhdCByZWZlcmVu Y2VzIHRoYXQgc28gdGhhdCBhdXRob3JpemF0aW9uIGRldGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRo cm91Z2ggdGhlIGZyb250ZW5kKS4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIGRpZCBjb25zaWRlciBhZGRpbmcgc29tZXRoaW5nIHRvIHRoYXQgZWZm ZWN0LCBhbiBlcnJvciBtZXNzYWdlIHRoYXQgY2FuIGRpcmVjdCB0aGUgZnJvbnRlbmQgdG8gcGVy Zm9ybSB0aGUgaW50ZXJhY3RpdmUgcG9ydGlvbiBuZWNlc3NhcnkgZm9yIHRoaXMgdG9wb2xvZ3kg dG8gd29yay4gSXQgd291bGQgYmUgc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIElEUCBpbml0aWF0 ZWQgbG9naW4gaW4gT0lEQywgd2hlcmUNCiB0aGUgY2xpZW50IG9mZmVycyBhbiBlbmRwb2ludCB0 aGF0IGlzIGd1YXJhbnRlZWQgdG8gaW5pdGlhdGUgYSBzaWduIGluIGZsb3cgKGhlbmNlIGluamVj dCBhbGwgdGhlIG5lY2Vzc2FyeSBub25jZXMgZXRjKS4gV2UgZGlkbuKAmXQgYWRkIGl0IHVwZnJv bnQgYW5kIGxlZnQgaXQgYXMgZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgbW9zdGx5IGJlY2F1c2Ug aXTigJlzIG5vdCBlYXN5IHRvIG1vZGVsIHByb3Blcmx5IGFuZCBiZWZvcmUgb3BlbmluZyB0aGF0 DQogd29yayBmcm9udCB3ZSB3YW50ZWQgdG8gc2VlIGhvdyB0aGUgaWRlYSB3YXMgcmVjZWl2ZWQu ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+T0F1dGgg Jmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBOZWlsIE1hZGRlbiAm bHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5 LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwMDoxNzxicj4NCjxiPlRvOiA8L2I+Vml0dG9yaW8gQmVy dG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnJmd0 Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBUb2tlbiBNZWRp YXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBC RkYpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgYSBsb3Qgb2Ygc2VjdXJpdHkgY29u Y2VybnMgYWJvdXQgdGhpcyBkcmFmdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJpdHkg aXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBoYW5kbGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBmcm9u dGVuZCBidXQgbmV2ZXIgcmVhbGx5IHNwZWxscyB0aGVtIG91dC4gRnJvbSB0aGUgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgaXQgc2VlbXMgdGhhdCB0aGUgcHJpbWFyeSBjb25jZXJuIGlzIHdpdGgg dGhlZnQgb2YgYWNjZXNzIHRva2VucyBmcm9tIGxvY2FsIHN0b3JhZ2UuDQogVG8gZG8gdGhpcyB5 b3XigJlkIG5lZWQgYW4gWFNTIGF0dGFjay4gQnV0IGluIHRoYXQgY2FzZSwgd291bGRu4oCZdCB0 aGUgYXR0YWNrZXIgc2ltcGx5IHVzZSB0aGUgWFNTIHRvIG1ha2UgYSBjYWxsIHRvIHRoZSBiZmYt dG9rZW4gZW5kcG9pbnQgaW5zdGVhZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBiZmYtdG9r ZW4gZW5kcG9pbnQgcmVjb21tZW5kaW5nIHRoZSB1c2Ugb2YgR0VUIHJlcXVlc3RzIHRvZ2V0aGVy IHdpdGggdGhlIGhpbnQgdG8gdXNlIGNvb2tpZS1iYXNlZCBhdXRoZW50aWNhdGlvbiBpcyBsaWtl bHkgZ29pbmcgdG8gcHVuY2ggYSBob2xlIGluIG1vc3QgQ1NSRiBkZWZlbnNlcywgd2hpY2ggYXNz dW1lIHRoYXQgR0VUcyBhcmUgc2FmZS4gVGhlIG9ubHkgdGhpbmcNCiBwcmV2ZW50aW5nIHRoaXMg YmVpbmcgZXhwbG9pdGFibGUgaXMgQ3Jvc3MtT3JpZ2luIFJlYWQgQmxvY2tpbmcgKDxhIGhyZWY9 Imh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXIv c2VydmljZXMvbmV0d29yay9jcm9zc19vcmlnaW5fcmVhZF9ibG9ja2luZ19leHBsYWluZXIubWQi Pmh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXIv c2VydmljZXMvbmV0d29yay9jcm9zc19vcmlnaW5fcmVhZF9ibG9ja2luZ19leHBsYWluZXIubWQ8 L2E+KQ0KIGR1ZSB0byB0aGUgSlNPTiBjb250ZW50LXR5cGUuIFRoYXQgbWFrZXMgbWUgcmVhbGx5 IG5lcnZvdXMuIFdlIHNob3VsZCBhdCBsZWFzdCBtYW5kYXRlIFgtQ29udGVudC1UeXBlLU9wdGlv bnM6IG5vc25pZmYgb24gdGhhdCByZXNwb25zZS4gSeKAmWQgZmVlbCBtb3JlIGNvbWZvcnRhYmxl IGlmIHRoaXMgd2FzIGEgUE9TVCByZXF1ZXN0IG9ubHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIFN0b3ljaG8gU2xlcHRzb3Yg bWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwgdGhlIGxhY2sgb2YgZnJvbnQtY2hhbm5lbCBj b21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0aGUgUk8gc2VlbXMgb2RkLiBJZiB0aGUg YmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVuIGNvdWxkbuKAmXQgeW91 IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlzc3VlIHNob3J0LWxpdmVk DQogSldUcyB0byB0aGUgZnJvbnRlbmQgdGhhdCBpdCBjYW4gdXNlIGZvciBBUEkgYWNjZXNzPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5 b3Ugd2FudCB0byBhbGxvdyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYt dG9rZW4gZW5kcG9pbnQgY2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBh dXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhl IHVzZXIgdG8uIChFZyB0aGUgYmFja2VuZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQg cmV0dXJuDQogYSBVUkkgdGhhdCByZWZlcmVuY2VzIHRoYXQgc28gdGhhdCBhdXRob3JpemF0aW9u IGRldGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5kKS4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCUIE5l aWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gMTIgRmViIDIwMjEsIGF0IDIwOjQ2LCBWaXR0b3Jp byBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7vu79EZWFyIGFsbCw8YnI+DQpCcmlhbiBhbmQgeW91 cnMgdHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVjaWZpY2F0aW9uIHRoYXQgc2hvd3MgaG93 IHRoZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2ViIGFwcCBjYW4gZGVsZWdhdGUgdG9rZW4g YWNxdWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0cyBiYWNrZW5kLCBhbmQgcmVxdWVzdCBz dWNoIHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0IGFjY2VzcyBvZiBwcm90ZWN0ZWQgcmVz b3VyY2VzIGZyb20gdGhlDQogZnJvbnRlbmQgY29kZS48YnI+DQo8YnI+DQpUaGUgcGF0dGVybiBp cyBhbHJlYWR5IGluIHVzZSwgaW4gcHJvcHJpZXRhcnkgZm9ybSwgYnkgdmFyaW91cyBtb2Rlcm4g ZGV2ZWxvcG1lbnQgc3RhY2tzLCBzdWNoIGFzIE5leHQuSlMuIFZhcmlhbnRzIG9mIHRoZSBwYXR0 ZXJuLCBvZnRlbiBkaXNjdXNzZWQgdW5kZXIgdGhlIGNhdGNoLWFsbCB0ZXJtIEJGRiAoYmFja2Vu ZCBmb3IgZnJvbnRlbmQpLCBoYXZlIGJlZW4gb2Z0ZW4gbWVudGlvbmVkIGluIHRoaXMgd29ya2dy b3Vw4oCZcyBhY3Rpdml0eSwNCiBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9uIGRl dGFpbHMgdG8gdGhlIHJlYWRlci48YnI+DQpXZSBiZWxpZXZlIHRoZSBwYXR0ZXJuIGhhcyBtZXJp dCwgYXMgY29ycm9ib3JhdGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9uLiBCeSBkZWxlZ2F0aW5n IGFjY2VzcyB0b2tlbiBhY3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwgd2UgYXZvaWQgbWFueSBv ZiB0aGUgb2Z0ZW4gYnJpdHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBsaWVkIGF0dGFjayBzdXJm YWNlKSByZXF1aXJlZCB0byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHVzZXIgYWdlbnQu DQogVGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhlIG5lZWQg b2YgcGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3duIHNvcmUg cG9pbnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVseWluZyBv biBpdHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vucy48YnI+ DQo8YnI+DQpBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBpcyB2ZXJ5IHNpbXBsZSwgcHJvdmlk aW5nIGV4cGxpY2l0IGd1aWRhbmNlIG9uIHRoZSBzY2VuYXJpbyBvZmZlcnMgbWFueSBhZHZhbnRh Z2VzLiAmbmJzcDs8YnI+DQotIEl0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGNyZWF0ZSBpbnRlcm9w ZXJhYmxlIFNES3MsIHdoZXJlIGZyb250ZW5kIGRldiBzdGFja3MgKGFueSBKUyBmbGF2b3IpIGNh biBiZSBtaXhlZCBhbmQgbWF0Y2hlZCB3aXRoIGNvbXBsaWFudCBiYWNrZW5kIHN0YWNrcyAobWlk ZGxld2FyZXMgaW4gbm9kZSwgamF2YSwgQVNQLk5FVCwgUEhQIGV0Yyk8YnI+DQotIEl0IGFsbG93 cyB1cyB0byBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9wZXJseSB0YWNrbGUgdGhlIHNj ZW5hcmlvIGFuZCB3YXJuIGltcGxlbWVudGVycyBhZ2FpbnN0IHNlY3VyaXR5IHJpc2tzIChzY29w ZSBlc2NhbGF0aW9ucywgdXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBvZiBhY2Nlc3MgdG9rZW5zLCBl dGMpPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8gZGlzY3VzcyAoYW5kIHdoZW4gYXBwcm9wcmlhdGUs IHByb21vdGUpIHRoaXMgcGF0dGVybiBhcyBwYXJ0IG9mIHRoZSBicm93c2VyIGFwcHMgc2VjdXJp dHkgZ3VpZGFuY2UsIGFuZCBwb3NpdGlvbiB0aGUgc2NlbmFyaW8gd2hlcmUgZnJvbnRlbmQgb25s eSBjYWxscyBBUEkgb24gaXRzIG93biBiYWNrZWQgKGhlbmNlIGRvZXNu4oCZdCBuZWVkIGFjY2Vz cyB0b2tlbnMpIHNpbXBseSBhcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGlzDQogbW9yZSBnZW5lcmFs IHBhdHRlcm48YnI+DQotIFRoaXMgYXBwcm9hY2ggbWFrZXMgbW9ja2luZyBhbmQgdGVzdGluZyBh cHBzIHZlcnkgZWFzeSwgcG9zc2libHkgcHJldmVudGluZyBkZXZlbG9wZXJzIGZyb20gd2Vha2Vu aW5nIHRoZSBzZWN1cml0eSBvZiB0aGVpciBzeXN0ZW0gKGVnIHR1cm5pbmcgb24gUk9QRyBvcHRp b25zKSAmbmJzcDtvciB0dXJuaW5nIHRvIHJpc2t5IHByYWN0aWNlcyBsaWtlIHNjcmFwaW5nPGJy Pg0KPGJyPg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlzIHNwZWNpZmljYXRpb24gZG9lc27igJl0IGVu dGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gZGlyZWN0IHVzZSBvZiBhY2Nl c3MgdG9rZW5zIGZyb20gYSBicm93c2VyLiBCdXQgcmVhbGl0eSBpcyB0aGF0IHRoZSBwYXR0ZXJu IGlzIGluIHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhlIGNpcmN1bXN0YW5jZXMgbGVhZGluZyB0byB0 aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEgcGFydGljdWxhciBwcm9qZWN0DQogb25seSB3b3JrIHdp dGggZnJvbnRlbmQgc3RhY2tzOyBjb21wb25lbnRzIGxpa2UgcmV2ZXJzZSBwcm94aWVzIG1pZ2h0 IG5vdCBhbHdheXMgYmUgdmlhYmxlOyBldGMpIGFyZW7igJl0IGdvaW5nIGF3YXkgYW55IHRpbWUg c29vbi4gQnkgcHJvdmlkaW5nIHNpbXBsZSBndWlkYW5jZSBvbiB0aGlzIHBhdHRlcm4sIHdlIGNh biBzaW1wbGlmeSB0aGUgbGlmZSBvZiBtYW55IGRldmVsb3BlcnMgd2hpbGUgZW5zaHJpbmluZyBi YXNpYyBzZWN1cml0eSBoeWdpZW5lDQogaW4gc2NlbmFyaW9zIHRoYXQgd291bGQgaGF2ZSBvdGhl cndpc2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLjxicj4NCjxicj4NCkxvb2tpbmcgZm9y d2FyZCBmb3IgeW91ciBmZWVkYmFjayE8YnI+DQo8YnI+DQpCJmFtcDtWICZuYnNwOzxicj4NCjxi cj4NCu+7v09uIDIvMTIvMjEsIDEyOjQxLCAmcXVvdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcm cXVvdDsgJmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZndDsgd3JvdGU6PGJyPg0KPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJlcnRv Y2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2hhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVml0dG9yaW8gQmVydG9jY2kgYW5kIHBvc3RlZCB0 byB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7TmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQt YmVydG9jY2ktb2F1dGgyLXRtaS1iZmY8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtSZXZpc2lvbjog Jm5ic3A7ICZuYnNwOzAwPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGU6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1Rva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBC YWNrZW5kIEZvciBGcm9udGVuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0RvY3VtZW50IGRhdGU6 ICZuYnNwOyAmbmJzcDsyMDIxLTAyLTEyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7R3JvdXA6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwO1BhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxNjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwO1VSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2 ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQ8YnI+DQombmJzcDsmbmJz cDsmbmJzcDtTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9h dXRoMi10bWktYmZmLzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0h0bWw6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3 LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRt bDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0h0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2kt b2F1dGgyLXRtaS1iZmYtMDA8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtBYnN0 cmFjdDo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBob3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxlZ2F0ZSBhY2Nl c3M8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0b2tlbiBhY3F1aXNp dGlvbiB0byBhIGJhY2tlbmQgY29tcG9uZW50LiAmbmJzcDtJbiBzbyBkb2luZywgdGhlIGZyb250 ZW5kPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2FuIGFjY2VzcyBy ZXNvdXJjZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBidXJkZW4gb2Y8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb21tdW5pY2F0aW5nIHdp dGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBwZXJzaXN0aW5nIHRva2VucywgYW5kPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGVyZm9ybWluZyBvcGVyYXRpb25z IHRoYXQgYXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW48YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleGVjdXRlZCBpbiBhIHVzZXIgYWdlbnQs IGJ1dCBhcmUgc2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2J5IGEgY29uZmlkZW50aWFsIGNsaWVudCBydW5u aW5nIG9uIGEgYmFja2VuZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDtQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGUgSUVURiBTZWNyZXRhcmlhdDxi cj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KT0F1dGhAaWV0Zi5vcmc8 YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29s b3I6IzE3MkI0RDtiYWNrZ3JvdW5kOndoaXRlIj5Gb3JnZVJvY2sgdmFsdWVzIHlvdXINCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1wcml2YWN5IiB0YXJnZXQ9Il9ibGFu ayI+UHJpdmFjeTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CO6PR18MB4052C7D49F34DDFCA1687D63AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 03:48:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF333A0CB5 for ; Sun, 14 Feb 2021 03:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nbInf91grRx for ; Sun, 14 Feb 2021 03:48:31 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD513A0CB2 for ; Sun, 14 Feb 2021 03:48:30 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id f6so4001647ioz.5 for ; Sun, 14 Feb 2021 03:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Sb6sv38xYb8rOfUDGzHksy1XpXHHp461gCf/5+KnHI=; b=dIHlcZBqh1J0xJ5GznoTr8WxREBiPpTBtbohx0/uNz+c1YoWgMhxAZTRrMXwx2lM3C Ij4WxbSzPAdyHfVQNZYw3qimDSpwI0kbdZO0IG8t7RiYH1oGfgVevNi7MlPMrPEVopul xsWC9NqZyKP+s5NIzaTiqmED2U2Xc8e9kzyxyAKcJTWj3cm1lnX2FnNN47MN50opPZH8 jpRO039WgzUHGX5hmNoIOhZAV9ArlcMBPVk/J+t9t15ghIgUpjfd3Hk8EbEvsaEkK2xu LZjvq071+X22URRTEmx0kd35NdGLlaIVEAcxrr2AJsmPy64NoYctZYvx8k3ssEv4vX+b PVXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Sb6sv38xYb8rOfUDGzHksy1XpXHHp461gCf/5+KnHI=; b=QeVnaF5uLp81jwaYIMI2PIV7JCTIGKIG3iZoux9PeqT7w2+9cex0bXpU1ufUjEGn1h sLvDiCGYTyda0J2pJl4D6V/NR5l/k+YkceI6dClJNj54FqmxP1ZrZdbmhL8lO5aUKZ8H hn/HUntRFUx7v92+97WVTC7yrF2B+3wX2tFxJ03tiTH4doCyfHOwGS4N/oqGR1Jh073a HM2gwfz3A8zzif2h8rsevuXq4FuqzziYWWOCyBdk59OLOzo7SrsoFkBZ8uHZCu+FIPso pN3Yz40UlZNPjulimvV9V2IuajTlHTKe/NH3pnrT8v0MKkEYAIYe9g/IRx798FV4GGMu sY3A== X-Gm-Message-State: AOAM532oN/XImHrC+rLbpv34xpBS6G4q0YT7UOeUtuvzQFIy9ags7WjZ iXZlEnebiVlN04RB1HqMS9tFfpYiaJQWzlBv8FnfzG+7NsYmcSQeSw== X-Google-Smtp-Source: ABdhPJxebMVIIxPblZYH14n1nqfo4KA1r6rcmDh5T4AfZoHwEsNmO1vwa2IjRE+JXToS5dwl1zxDxYHbnwSR/t6ViYw= X-Received: by 2002:a05:6638:164c:: with SMTP id a12mr10804621jat.128.1613303309926; Sun, 14 Feb 2021 03:48:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 12:48:19 +0100 Message-ID: To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b41bfc05bb4a7293" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 11:48:34 -0000 --000000000000b41bfc05bb4a7293 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. For UI related functionality, i.e. document selection, user profile display/changes, contact updates, etc... You should be able to execute the client side *silent authentication* using the provided session token from the Azure AD AS, without needing to make any RO api calls nor user redirects. For RO responsibilities, you can present the user with a button "Grant RO access to Azure resources" button and the user will go through a permission scope elevation flow, again no reason to need a BFF here. We did consider adding something to that effect, an error message that can > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. It may make sense for the app to have an error message, or even better might be a 302 *Location header* depending on what you are doing. There is nothing here that is OAuth specific however (nor common), and then we should challenge the need to directly provide an RFC recommendation for handling this. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci wrote: > Hi Neil, > > Thanks for the prompt comments! > > - Re: GET vs POST, > > personally I=E2=80=99d be fine with restricting to POST. > > > > - Re: RO-AS, interaction- > > perhaps it is not very clear from the text at the moment (first draft), > but that is assumed that the RO went thru whatever interactive steps are > necessary to establish a session (eg sign in, assuming the AS is say an > OIDC provider) and obtain beforehand the access token and refresh tokens > that will be needed during the app activities taking place after that. I= n > concrete terms, imagine that the backend performs an authorization code > grant requesting an IDtoken, access token and refresh token BEFORE the > activities described in TMI-BFF take place. > > The current language trying to express that is in 1.2: > > As a prerequisite for the flow described below, the backend MUST have > established a secure session with the user agent, so that all requests fr= om > that user agent toward the backend occur over HTTPS and carry a valid > session artifact (such as a cookie) that the backend can validate. This > document does not mandate any specific mechanism to establish and maintai= n > that session. > > And > > cached, it requests to the authorization server a new access token with > the required characteristics, using any artifacts previousy obtained (eg > refresh token) and grants that will allow the authorization server to iss= ue > the requested token without requiring user interaction. > > > > - If the backend is already implicitly trusted then couldn=E2=80=99t = you skip > OAuth and just get the backend to issue short-lived JWTs to the fronte= nd > that it can use for API access? > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > - If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoi= nt > URI that the SPA then navigates the user to. (Eg the backend can do a = PAR > request first and return a URI that references that so that authorizat= ion > details aren=E2=80=99t passed through the frontend). > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > > > *From: *OAuth on behalf of Neil Madden < > neil.madden@forgerock.com> > *Date: *Sunday, February 14, 2021 at 00:17 > *To: *Vittorio Bertocci > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > I have a lot of security concerns about this draft. > > > > The draft alludes to security issues associated with handling access > tokens in the frontend but never really spells them out. From the Securit= y > Considerations it seems that the primary concern is with theft of access > tokens from local storage. To do this you=E2=80=99d need an XSS attack. B= ut in that > case, wouldn=E2=80=99t the attacker simply use the XSS to make a call to = the > bff-token endpoint instead? > > > > The combination of the bff-token endpoint recommending the use of GET > requests together with the hint to use cookie-based authentication is > likely going to punch a hole in most CSRF defenses, which assume that GET= s > are safe. The only thing preventing this being exploitable is Cross-Origi= n > Read Blocking ( > https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md) > due to the JSON content-type. That makes me really nervous. We should at > least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel > more comfortable if this was a POST request only. > > > > As Stoycho Sleptsov mentioned in the other email, the lack of > front-channel communication between the AS and the RO seems odd. If the > backend is already implicitly trusted then couldn=E2=80=99t you skip OAut= h and just > get the backend to issue short-lived JWTs to the frontend that it can use > for API access? > > > > If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoint > URI that the SPA then navigates the user to. (Eg the backend can do a PAR > request first and return a URI that references that so that authorization > details aren=E2=80=99t passed through the frontend). > > > > =E2=80=94 Neil > > > > > > On 12 Feb 2021, at 20:46, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For > Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: > https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate acce= ss > token acquisition to a backend component. In so doing, the fronten= d > can access resource servers directly without taking on the burden o= f > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges whe= n > executed in a user agent, but are safe and well proven when execute= d > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000b41bfc05bb4a7293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For the = trusted part, see above. For the short lived JWTs, that=E2=80=99s not reall= y an option. The most generic scenario addressed here is for APIs that acce= pt tokens issued by the AS; the backend can request them as a client, but i= t cannot mint them. Imagine we=E2=80=99re talking about a SPA application t= hat signs in users using Azure AD, and needs to call Office and Azure APIs.= The SPA backend cannot issue tokens for those APIs, it can only request th= em to the Azure AD AS.

For UI related funct= ionality, i.e. document selection, user profile display/changes, contact up= dates, etc... You should be able to execute the client side silent authe= ntication=C2=A0using the provided session token from the Azure AD AS, w= ithout needing to make any RO api calls nor user redirects.=C2=A0For RO res= ponsibilities, you can present the user with a button "Grant RO access= to Azure resources" button and the user will go through=C2=A0a permis= sion scope elevation flow, again no reason to need a BFF here.
We did consider a= dding something to that effect, an error message that can direct the fronte= nd to perform the interactive portion necessary for this topology to work. = It would be something similar to the IDP initiated login in OIDC, where the= client offers an endpoint that is guaranteed to initiate a sign in flow (h= ence inject all the necessary nonces etc). We didn=E2=80=99t add it upfront= and left it as exercise for the reader mostly because it=E2=80=99s not eas= y to model properly and before opening that work front we wanted to see how= the idea was received.=C2=A0=C2=A0
It may make sense for = the app to have an error message, or even better might be a 302 Location= header=C2=A0depending on what you are doing. There is nothing here tha= t is OAuth specific however (nor common), and then we should challenge the = need to directly provide an RFC recommendation for handling this.

Warren Parad

Founder, CTO

Secure your user data and complete = your authorization architecture. Implement=C2=A0Authress.


On Sun, Feb = 14, 2021 at 12:29 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=

Hi Neil,

Thanks for the prompt comments!

  • Re: GET vs POST,

personally I=E2=80=99d = be fine with restricting to POST.

=C2=A0

  • Re: RO-AS, interaction-

perhaps it is not very clear from the text at the mo= ment (first draft), but that is assumed that the RO went thru whatever inte= ractive steps are necessary to establish a session (eg sign in, assuming th= e AS is say an OIDC provider) and obtain beforehand the access token and refresh tokens that will be needed = during the app activities taking place after =C2=A0that. In concrete terms,= imagine that the backend performs an authorization code grant requesting a= n IDtoken, access token and refresh token BEFORE the activities described in TMI-BFF take place.

The current language trying to express that is in 1.= 2:

As a prerequ= isite for the flow described below, the backend MUST have established a sec= ure session with the user agent, so that all requests from that user agent toward the backend occur over HTTPS and carry a valid= session artifact (such as a cookie) that the backend can validate. This do= cument does not mandate any specific mechanism to establish and maintain th= at session.

And

cached, it r= equests to the authorization server a new access token with the required ch= aracteristics, using any artifacts previousy obtained (eg refresh token) and grants that will allow the authorization server to = issue the requested token without requiring user interaction.=

=C2=A0

  • =C2=A0If the backend is already implicitly trusted then couldn=E2=80=99t you skip OAuth and just get the backend to issue short-li= ved JWTs to the frontend that it can use for API access?
    • =

For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can = request them as a client, but it cannot mint them. Imagine we=E2=80=99re talking about a SPA application that signs in = users using Azure AD, and needs to call Office and Azure APIs. The SPA back= end cannot issue tokens for those APIs, it can only request them to the Azu= re AD AS.

=C2=A0

  • If you want to allow auth code flow etc then perhaps the bff-toke= n endpoint can return a standard error code with an authorization endpoint = URI that the SPA then navigates the user to. (Eg the backend can do a PAR request first and return a URI that refer= ences that so that authorization details aren=E2=80=99t passed through the = frontend).=C2=A0

We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to th= e IDP initiated login in OIDC, where the client offers an endpoint that is guaranteed to initiate a sign in flo= w (hence inject all the necessary nonces etc). We didn=E2=80=99t add it upf= ront and left it as exercise for the reader mostly because it=E2=80=99s not= easy to model properly and before opening that work front we wanted to see how the idea was received. =C2=A0

=C2=A0

From: = OAuth <oauth-bounces@ietf.org= > on behalf of Neil Madden <neil.madden@forgerock.com>
Date: Sunday, February 14, 2021 at 00:17
To: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>= ;
Cc: "oauth@= ietf.org" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

I have a lot of security concerns about this draft.= =C2=A0

=C2=A0

The draft alludes to security issues associated with= handling access tokens in the frontend but never really spells them out. F= rom the Security Considerations it seems that the primary concern is with t= heft of access tokens from local storage. To do this you=E2=80=99d need an XSS attack. But in that case, wouldn=E2= =80=99t the attacker simply use the XSS to make a call to the bff-token end= point instead?=C2=A0

=C2=A0

The combination of the bff-token endpoint recommendi= ng the use of GET requests together with the hint to use cookie-based authe= ntication is likely going to punch a hole in most CSRF defenses, which assu= me that GETs are safe. The only thing preventing this being exploitable is Cross-Origin Read Blocking (https://chromi= um.googlesource.com/chromium/src/+/master/services/network/cross_origin_rea= d_blocking_explainer.md) due to the JSON content-type. That makes me really nervous. We should at l= east mandate X-Content-Type-Options: nosniff on that response. I=E2=80=99d = feel more comfortable if this was a POST request only.=C2=A0<= /p>

=C2=A0

As Stoycho Sleptsov mentioned in the other email, th= e lack of front-channel communication between the AS and the RO seems odd. = If the backend is already implicitly trusted then couldn=E2=80=99t you skip= OAuth and just get the backend to issue short-lived JWTs to the frontend that it can use for API access?

=C2=A0

If you want to allow auth code flow etc then perhaps= the bff-token endpoint can return a standard error code with an authorizat= ion endpoint URI that the SPA then navigates the user to. (Eg the backend c= an do a PAR request first and return a URI that references that so that authorization details aren=E2=80=99t pa= ssed through the frontend).=C2=A0

=C2=A0

=E2=80=94 Neil

=C2=A0



On 12 Feb 2021, at 20:4= 6, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=

=EF=BB=BFDear all,
Brian and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and persist= ence to its backend, and request such tokens when needed for direct access = of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern devel= opment stacks, such as Next.JS. Variants of the pattern, often discussed un= der the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=E2=80=99s activity, but always left all implementation details to the reader.
We believe the pattern has merit, as corroborated by its growing adoption. = By delegating access token acquisition to the backend, we avoid many of the= often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend from the need of persisting tokens= in local storage, a well known sore point of using OAuth directly in JavaS= cript, by relying on its backend storage and session to preserve tokens.
Although the specification is very simple, providing explicit guidance on t= he scenario offers many advantages. =C2=A0
- It makes it possible to create interoperable SDKs, where frontend dev sta= cks (any JS flavor) can be mixed and matched with compliant backend stacks = (middlewares in node, java, AS= P.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario a= nd warn implementers against security risks (scope escalations, using IDtok= ens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as p= art of the browser apps security guidance, and position the scenario where = frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventi= ng developers from weakening the security of their system (eg turning on RO= PG options) =C2=A0or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely eliminate the = risks inherent to direct use of access tokens from a browser. But reality i= s that the pattern is in widespread use, and the circumstances leading to t= hat (eg developers on a particular project only work with frontend stacks; components like reverse proxies might not = always be viable; etc) aren=E2=80=99t going away any time soon. By providin= g simple guidance on this pattern, we can simplify the life of many develop= ers while enshrining basic security hygiene in scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!

B&V =C2=A0

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org= > wrote:


=C2=A0=C2=A0=C2=A0A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.tx= t
=C2=A0=C2=A0=C2=A0has been successfully submitted by Vittorio Bertocci and = posted to the
=C2=A0=C2=A0=C2=A0IETF repository.

=C2=A0=C2=A0=C2=A0Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bertocci-oauth2-tm= i-bff
=C2=A0=C2=A0=C2=A0Revision: =C2=A0 =C2=A000
=C2=A0=C2=A0=C2=A0Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Token Mediating and ses= sion Information Backend For Frontend
=C2=A0=C2=A0=C2=A0Document date: =C2=A0 =C2=A02021-02-12
=C2=A0=C2=A0=C2=A0Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission =C2=A0=C2=A0=C2=A0Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A016
=C2=A0=C2=A0=C2=A0URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://www.ietf.org/archive/id/draf= t-bertocci-oauth2-tmi-bff-00.txt
=C2=A0=C2=A0=C2=A0Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/" = target=3D"_blank">https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tm= i-bff/
=C2=A0=C2=A0=C2=A0Html: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0https://www.ietf.org/archive/id/draft-ber= tocci-oauth2-tmi-bff-00.html
=C2=A0=C2=A0=C2=A0Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


=C2=A0=C2=A0=C2=A0Abstract:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This document describes how a JavaScrip= t frontend can delegate access
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0token acquisition to a backend componen= t.=C2=A0 In so doing, the frontend
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0can access resource servers directly wi= thout taking on the burden of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0communicating with the authorization se= rver, persisting tokens, and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0performing operations that are fraught = with security challenges when
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0executed in a user agent, but are safe = and well proven when executed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0by a confidential client running on a b= ackend.




=C2=A0=C2=A0=C2=A0Please note that it may take a couple of minutes from the= time of submission
=C2=A0=C2=A0=C2=A0until the htmlized version and diff are available at tools.ietf.org.

=C2=A0=C2=A0=C2=A0The IETF Secretariat



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


ForgeR= ock values your Privac= y

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000b41bfc05bb4a7293-- From nobody Sun Feb 14 04:06:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE41C3A0045 for ; Sun, 14 Feb 2021 04:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dDujv5Ta-Ec for ; Sun, 14 Feb 2021 04:06:06 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654F83A003E for ; Sun, 14 Feb 2021 04:06:06 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id a16so3290173ilq.5 for ; Sun, 14 Feb 2021 04:06:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=MuwX2FjMl1lt9bg6AgFNVtRQlou/P32QDssA1BdP8nw=; b=xWB87uJ4ncZMItq9lF018IzZ8cZZd4IpwrJE0GlpdnTIxOYrRo1hTxfBvqCVRPIqzM dyBk1RHzRFsYP0ujSPBVRQ7LzKPhGg/4Q7e0iI4DtuM1TaygVZqJyjUUaSG84T+MbLmM cOmrPxw7jDKMuYUmrTjaRw9wUk1d7pOWviGRC8+m2VBIXlLH9TbpoISPcaRVWJkfjtnW N7mHsvWvoTm8rZ5E8FGESvNU/+Uaj6aqEFOAI8Y66fcuvcPIGWr6+LJ5Yt20ffqBqeJw tmfUuVW1syQjOPrloDJQouY2rrmDxNtByTPhwN9/aO8wkx82lAodMpZfCSerCnIK3Nh6 Ordw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=MuwX2FjMl1lt9bg6AgFNVtRQlou/P32QDssA1BdP8nw=; b=MES5P85PG5yJmF8T0wxNX+FhgX4YexnXHjTOr8M/wF7VLPGWlCiZAq4ff8ttCEiFIu PawHhYu5qotY6X8vS1UEZP8Kr+TgXmJ6o2t537jCsTaV25OOycYqHp+Kc8n5NxkNt8Zi egXkIAwMHBP9bvQGdPYWWkjYuASGVOjHwYsGaQkO9XOzr1Josmc1sIba+zlJRea4HCAd iXTRNRWe0KswT+fdisgus09l1+HX6nkipVXbppS7DI3aCvLJ2BlOtcZznNQfKeBuItnv a9OlWLGy3r8g8bI7bG9jQ6R7osx/fHT2xtUK5sGiQKl0KWmCJxnB/TT2Q1sPMHUbFVPj NSEA== X-Gm-Message-State: AOAM530YajZCPmu40czLNfsWUGTatB86eYjbfiaw9qdnV4/lsVE9L0lz 0Gu9f8by3kDjvPQ9HS7du5rqk9MkSUwTgcUrcSeS X-Google-Smtp-Source: ABdhPJwBC1w+UwIAN9pEHz6jDvmCYOVURlKLTVhd510+uAYhTNxNt8kzzykAUAS7Y+HR7b+zOdoghrnNC7wx/nojiQg= X-Received: by 2002:a05:6e02:152c:: with SMTP id i12mr8729607ilu.46.1613304365295; Sun, 14 Feb 2021 04:06:05 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 14 Feb 2021 12:06:04 +0000 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Sun, 14 Feb 2021 12:06:04 +0000 Message-ID: To: Vittorio Bertocci , Brian Campbell , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009bc6e905bb4ab12c" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:06:10 -0000 --0000000000009bc6e905bb4ab12c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just making sure I understand - in your protocol flow diagram step D it looks like that the BFF is returning the access token to the front-end. Is that correct? My biggest concern with browser-based applications is that the JavaScript / browser has access to the access token (don=E2=80=99t care if it is in-memo= ry or local storage) - but this exactly seems to happen in D. Thanks =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 12. February 2021 at 21:46:20, Vittorio Bertocci ( vittorio.bertocci=3D40auth0.com@dmarc.ietf.org) wrote: Dear all, Brian and yours truly are proposing a new specification that shows how the user agent frontend of a web app can delegate token acquisition and persistence to its backend, and request such tokens when needed for direct access of protected resources from the frontend code. The pattern is already in use, in proprietary form, by various modern development stacks, such as Next.JS. Variants of the pattern, often discussed under the catch-all term BFF (backend for frontend), have been often mentioned in this workgroup=E2=80=99s activity, but always left all implementation details to the reader. We believe the pattern has merit, as corroborated by its growing adoption. By delegating access token acquisition to the backend, we avoid many of the often brittle moving parts (and implied attack surface) required to acquire access tokens from a user agent. The topology also relieves the frontend from the need of persisting tokens in local storage, a well known sore point of using OAuth directly in JavaScript, by relying on its backend storage and session to preserve tokens. Although the specification is very simple, providing explicit guidance on the scenario offers many advantages. - It makes it possible to create interoperable SDKs, where frontend dev stacks (any JS flavor) can be mixed and matched with compliant backend stacks (middlewares in node, java, ASP.NET, PHP etc) - It allows us to provide guidance on how to properly tackle the scenario and warn implementers against security risks (scope escalations, using IDtokens instead of access tokens, etc) - It allows us to discuss (and when appropriate, promote) this pattern as part of the browser apps security guidance, and position the scenario where frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern - This approach makes mocking and testing apps very easy, possibly preventing developers from weakening the security of their system (eg turning on ROPG options) or turning to risky practices like scraping Needless to say, this specification doesn=E2=80=99t entirely eliminate the = risks inherent to direct use of access tokens from a browser. But reality is that the pattern is in widespread use, and the circumstances leading to that (eg developers on a particular project only work with frontend stacks; components like reverse proxies might not always be viable; etc) aren=E2=80= =99t going away any time soon. By providing simple guidance on this pattern, we can simplify the life of many developers while enshrining basic security hygiene in scenarios that would have otherwise be left to their own device. Looking forward for your feedback! B&V =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" wrote: A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt has been successfully submitted by Vittorio Bertocci and posted to the IETF repository. Name: draft-bertocci-oauth2-tmi-bff Revision: 00 Title: Token Mediating and session Information Backend For Frontend Document date: 2021-02-12 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 Abstract: This document describes how a JavaScript frontend can delegate access token acquisition to a backend component. In so doing, the frontend can access resource servers directly without taking on the burden of communicating with the authorization server, persisting tokens, and performing operations that are fraught with security challenges when executed in a user agent, but are safe and well proven when executed by a confidential client running on a backend. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000009bc6e905bb4ab12c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi,= =C2=A0

<= /div>
Just making = sure I understand - in your protocol flow diagram step D it looks like that= the BFF is returning the access token to the front-end. Is that correct?

My biggest concern w= ith browser-based applications is that the JavaScript / browser has access = to the access token (don=E2=80=99t care if it is in-memory or local storage= ) - but this exactly seems to happen in D.

Thanks
=E2=80= =94=E2=80=94=E2=80=94
Dominick Baier

On 12. February 2021 at 21:46:20, Vittorio Bertocci (vittorio.bertocci=3D40aut= h0.com@dmarc.ietf.org) wrote:

Dear all,
Brian and yours truly are proposing a new specification that shows how = the user agent frontend of a web app can delegate token acquisition and per= sistence to its backend, and request such tokens when needed for direct acc= ess of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern d= evelopment stacks, such as Next.JS. Variants of the pattern, often discusse= d under the catch-all term BFF (backend for frontend), have been often ment= ioned in this workgroup=E2=80=99s activity, but always left all implementat= ion details to the reader.
We believe the pattern has merit, as corroborated by its growing adopti= on. By delegating access token acquisition to the backend, we avoid many of= the often brittle moving parts (and implied attack surface) required to ac= quire access tokens from a user agent. The topology also relieves the front= end from the need of persisting tokens in local storage, a well known sore = point of using OAuth directly in JavaScript, by relying on its backend stor= age and session to preserve tokens.

Although the specification is very simple, providing explicit guidance = on the scenario offers many advantages. =20
- It makes it possible to create interoperable SDKs, where frontend dev= stacks (any JS flavor) can be mixed and matched with compliant backend sta= cks (middlewares in node, java, ASP.NET, PHP= etc)
- It allows us to provide guidance on how to properly tackle the scenar= io and warn implementers against security risks (scope escalations, using I= Dtokens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern = as part of the browser apps security guidance, and position the scenario wh= ere frontend only calls API on its own backed (hence doesn=E2=80=99t need a= ccess tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly prev= enting developers from weakening the security of their system (eg turning o= n ROPG options) or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely eliminate = the risks inherent to direct use of access tokens from a browser. But reali= ty is that the pattern is in widespread use, and the circumstances leading = to that (eg developers on a particular project only work with frontend stac= ks; components like reverse proxies might not always be viable; etc) aren= =E2=80=99t going away any time soon. By providing simple guidance on this p= attern, we can simplify the life of many developers while enshrining basic = security hygiene in scenarios that would have otherwise be left to their ow= n device.
=20
Looking forward for your feedback!

B&V =20

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:

=20
A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
has been successfully submitted by Vittorio Bertocci and posted to = the
IETF repository.
=20
Name: draft-bertocci-oauth2-tmi-bff
Revision: 00
Title: Token Mediating and session Information Backend For Fronten= d
Document date: 2021-02-12
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-bertocc= i-oauth2-tmi-bff-00.txt
Status: https://datatracker.ietf.org/doc/draft-bertocci-oa= uth2-tmi-bff/
Html: https://www.ietf.org/archive/id/draft-bertoc= ci-oauth2-tmi-bff-00.html
Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi= -bff-00
=20
=20
Abstract:
This document describes how a JavaScript frontend can delegate a= ccess
token acquisition to a backend component. In so doing, the fron= tend
can access resource servers directly without taking on the burde= n of
communicating with the authorization server, persisting tokens, = and
performing operations that are fraught with security challenges = when
executed in a user agent, but are safe and well proven when exec= uted
by a confidential client running on a backend.
=20
= =20
=20
=20
Please note that it may take a couple of minutes from the time of s= ubmission
until the htmlized version and diff are available at tools.ietf.org.
=20
The IETF Secretariat
=20
=20
=20
_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth
--0000000000009bc6e905bb4ab12c-- From nobody Sun Feb 14 04:24:58 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8EB3A08ED for ; Sun, 14 Feb 2021 04:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adxzmt7jTxus for ; Sun, 14 Feb 2021 04:24:54 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFEC3A08E4 for ; Sun, 14 Feb 2021 04:24:54 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id o15so3294842ilt.6 for ; Sun, 14 Feb 2021 04:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OclN/02U9L18x4KEm+dcPJazdix8udoTSq/HuKj6z2M=; b=PS6OcHsbR1zvKDtqNchNgp0MTC+7lw/3gLvVnd31KDKtSBZrVtvZg2+/YCqOpArjec jKrzTZSDg0vrldT62KaibbzG4gpQJo5AQ8+1HybMerUItGykhnMW90OLwWS7RqjJXT8b P27i2tcDKxYISm75V8ZZFCuuV63QeMRHl6a4xghwvrYr/6tbCyFUtj0wxRyKugLXdWqS thzXX7LIwIek0qazzct2RwwQV4b4C8tqaaaZr3EgkldSveyIaLB1+Ztft0jrM8b6tMEr UBrcuy6Hcqhvpez9Yxn18a3fCmmvTzw+654XoSI6kimkhTz63LVLlM8PGEwp+g4SiGFe 7nzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OclN/02U9L18x4KEm+dcPJazdix8udoTSq/HuKj6z2M=; b=Gb5F42p2elEmMjtdntX+ycxo5OVJPNkDEgtAh/D4VuU5rfmBunIAmz5RgtqJioJv8m ySEj9OP8Jw/F8qir26l1nXlMW1OTuJyQ+jLsl0dWHeDEO2Jl+TgiAFiPl0BrXlc5qATD mVP/kJhTmvZ7dJBWP9EOf0ynUm6fHyKZdJRCegCxqHNSqJHzWORc/ChBLEjLZVj/3Bo8 8yF8yeGU+UMEwgsFX2jIFTm7ymOc4HdZyxjTeRbXfoSRdippuFnmnMt5M3BcVTZxrEjO wHeFj/2xryBpMFr41a1gjPinoccKRAdoDbKSuiqallqIDhrfqdTh7Jj19dHfHEhSknKy KjBQ== X-Gm-Message-State: AOAM532xNWh/FVejcAj++AylaDQCLgAO2iIuZbvX+DjOs5IBrydMdrjH nZLDaZhFmTA+BilZVsd1PqXS2/NZIcs7DieVDcIm X-Google-Smtp-Source: ABdhPJx1xcFa8Z7IbamUD5pK7vYBluqB7SA65WAYgb0xSMDOqFolN632WQ90wqT3VoL3S1euw1/oh0T0+EfJLXojoNs= X-Received: by 2002:a05:6e02:1d0e:: with SMTP id i14mr8632933ila.69.1613305493293; Sun, 14 Feb 2021 04:24:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 13:24:42 +0100 Message-ID: To: Dominick Baier Cc: Vittorio Bertocci , Brian Campbell , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d7ac8f05bb4af4fc" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:24:57 -0000 --000000000000d7ac8f05bb4af4fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > My biggest concern with browser-based applications is that the JavaScript > / browser has access to the access token (don=E2=80=99t care if it is in-= memory or > local storage) - but this exactly seems to happen in D. Unless the AS passes the token back in a HttpOnly cookie (which Oauth doesn't technically support) it will always be available to Javascript in browser, right? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 1:06 PM Dominick Baier wrote: > Hi, > > Just making sure I understand - in your protocol flow diagram step D it > looks like that the BFF is returning the access token to the front-end. I= s > that correct? > > My biggest concern with browser-based applications is that the JavaScript > / browser has access to the access token (don=E2=80=99t care if it is in-= memory or > local storage) - but this exactly seems to happen in D. > > Thanks > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 12. February 2021 at 21:46:20, Vittorio Bertocci ( > vittorio.bertocci=3D40auth0.com@dmarc.ietf.org) wrote: > > Dear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate access > token acquisition to a backend component. In so doing, the frontend > can access resource servers directly without taking on the burden of > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges when > executed in a user agent, but are safe and well proven when executed > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000d7ac8f05bb4af4fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My bigge= st concern with browser-based applications is that the JavaScript / browser= has access to the access token (don=E2=80=99t care if it is in-memory or l= ocal storage) - but this exactly seems to happen in D.
Unless the AS passes the = token back in a HttpOnly cookie (which Oauth doesn't technically suppor= t) it will always be available to Javascript in browser, right?

<= /tr>

Warren Parad

Founder, CTO

Secure your user data= and complete your authorization architecture. Implement=C2=A0Aut= hress.

On Sun, Feb 14, 2021 at 1:06 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
Hi,=C2=A0

Just making sure I understand - in your protocol= flow diagram step D it looks like that the BFF is returning the access tok= en to the front-end. Is that correct?

My biggest concern with browser-based applications is th= at the JavaScript / browser has access to the access token (don=E2=80=99t c= are if it is in-memory or local storage) - but this exactly seems to happen= in D.

<= /div>
Thanks
=
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On = 12. February 2021 at 21:46:20, Vittorio Bertocci (vittorio.bertocc= i=3D40auth0.com@dmarc.ietf.org) wrote:

Dear all,
Brian and yours truly are proposing a new specification that shows how = the user agent frontend of a web app can delegate token acquisition and per= sistence to its backend, and request such tokens when needed for direct acc= ess of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern d= evelopment stacks, such as Next.JS. Variants of the pattern, often discusse= d under the catch-all term BFF (backend for frontend), have been often ment= ioned in this workgroup=E2=80=99s activity, but always left all implementat= ion details to the reader.
We believe the pattern has merit, as corroborated by its growing adopti= on. By delegating access token acquisition to the backend, we avoid many of= the often brittle moving parts (and implied attack surface) required to ac= quire access tokens from a user agent. The topology also relieves the front= end from the need of persisting tokens in local storage, a well known sore = point of using OAuth directly in JavaScript, by relying on its backend stor= age and session to preserve tokens.

Although the specification is very simple, providing explicit guidance = on the scenario offers many advantages. =20
- It makes it possible to create interoperable SDKs, where frontend dev= stacks (any JS flavor) can be mixed and matched with compliant backend sta= cks (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenar= io and warn implementers against security risks (scope escalations, using I= Dtokens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern = as part of the browser apps security guidance, and position the scenario wh= ere frontend only calls API on its own backed (hence doesn=E2=80=99t need a= ccess tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly prev= enting developers from weakening the security of their system (eg turning o= n ROPG options) or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely eliminate = the risks inherent to direct use of access tokens from a browser. But reali= ty is that the pattern is in widespread use, and the circumstances leading = to that (eg developers on a particular project only work with frontend stac= ks; components like reverse proxies might not always be viable; etc) aren= =E2=80=99t going away any time soon. By providing simple guidance on this p= attern, we can simplify the life of many developers while enshrining basic = security hygiene in scenarios that would have otherwise be left to their ow= n device.
=20
Looking forward for your feedback!

B&V =20

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org= > wrote:

=20
A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
has been successfully submitted by Vittorio Bertocci and posted to = the
IETF repository.
=20
Name: draft-bertocci-oauth2-tmi-bff
Revision: 00
Title: Token Mediating and session Information Backend For Fronten= d
Document date: 2021-02-12
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archiv= e/id/draft-bertocci-oauth2-tmi-bff-00.txt
Status: https://datatracker.ietf.org/doc= /draft-bertocci-oauth2-tmi-bff/
Html: https://www.ietf.org/archi= ve/id/draft-bertocci-oauth2-tmi-bff-00.html
Htmlized: https://tools.ietf.org/html/draft-b= ertocci-oauth2-tmi-bff-00
=20
=20
Abstract:
This document describes how a JavaScript frontend can delegate a= ccess
token acquisition to a backend component. In so doing, the fron= tend
can access resource servers directly without taking on the burde= n of
communicating with the authorization server, persisting tokens, = and
performing operations that are fraught with security challenges = when
executed in a user agent, but are safe and well proven when exec= uted
by a confidential client running on a backend.
=20
= =20
=20
=20
Please note that it may take a couple of minutes from the time of s= ubmission
until the htmlized version and diff are available at tools.ietf.org.
=20
The IETF Secretariat
=20
=20
=20
_______________________________________________
OAuth mailing listOAuth@ietf.org= https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000d7ac8f05bb4af4fc-- From nobody Sun Feb 14 04:27:32 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E183A0912 for ; Sun, 14 Feb 2021 04:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5L253o5IUfA for ; Sun, 14 Feb 2021 04:27:26 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91573A08F4 for ; Sun, 14 Feb 2021 04:27:26 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id q72so2148099pjq.2 for ; Sun, 14 Feb 2021 04:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=EcKCqs6ozcRUFrmlTKrJbgAEUfMbgHJu+rZGZa7EQZk=; b=S5mNYfku/dCHVu0JaGwt5FHeJGku29fdnByHnAy4YmsnhthgwAQxndlzFlbb8Dl+gT oChDv6vTdlZKK12RivnEU121Yj/zjSOTp67aaL3zEPwz6CjlVLBBae5PP//sfywa/fkv gHBINKKtw8qxKYqPdtcXqQDsM/fTnZO+5jPq8rMfT7giJYuNahcIHAqSEY9aM5YAH0lw IdSvL5u+yVf2SMXhq8B3N6oQdr2UhV8LyvrMMUY7fKh+bgrsPxCytkPZ1T2Twke+khNi Xlu0lYGMtVDQxGyOLIovfzoJ3z0uuohG3jFIo0vaj5EMNtYJaEb6qFzu0LaC4fmwK0ry 2/Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=EcKCqs6ozcRUFrmlTKrJbgAEUfMbgHJu+rZGZa7EQZk=; b=a3C9NjMEXsmW6xBXemnj+6CPt6fFi0m9EnCzO9yueqPvO8RxGoFuGgx0CaLhi1L3+s dY67HWJ3VYJTTGF0TRsizyDT6SFI2r4wH2JUYnlgNOIL5Jd1RaZPflNgyY698nrWKmcc bIHSmIEDGhL7Yqo0nghiuTeVFQ2DfSiBZ2cMLsgN7UdV25woFHufTLGWt8zSumJd80xl Cuzm0hOJI75sXFPjB+ufj/JTgmZAMkPVDQhMCunSg4/KMefcT3vhqF0ab6YthCXEbu9p Zic9T/he7ydtJfUkdqqNx5V6OHYv0TFVQaaLqE50h614iwlTA/moipqBjUR7t6rT4MC0 6UHw== X-Gm-Message-State: AOAM5337SI+MtvDaDFn0aa2IGa8N2c9DuwxSQdpq3o7cW1oVdQVNUWg4 nR34LVQdPfMLCKWa1X3ILcz/Uh2sl9blCA== X-Google-Smtp-Source: ABdhPJzZ3QjGw9gKdYXTT9EUbLXPZS2RDXyp3SaiLl8hCdkeYqYE7FZyH2I7uBpkmFngSEhSIiqDIg== X-Received: by 2002:a17:90a:8c14:: with SMTP id a20mr5233925pjo.215.1613305645962; Sun, 14 Feb 2021 04:27:25 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id x8sm190868pjf.55.2021.02.14.04.27.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 04:27:25 -0800 (PST) From: Vittorio Bertocci To: Warren Parad , Neil Madden CC: oauth Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAAaNoCAACuILA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 12:27:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB405236B3F50E3A5C42B82C39AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:27:31 -0000 --_000_CO6PR18MB405236B3F50E3A5C42B82C39AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2FycmVuLCB0aGFua3MgZm9yIHRoZSB0aG91Z2h0ZnVsIGNvbW1lbnRzLg0KSW5saW5lLg0K DQoNCiAgKiAgIC4gSXQgaW50cm9kdWNlcyBhIHBzZXVkbyBBUy1saWtlIHByb3h5IHdoaWNoIG5v dyBoYXMgYWxsIHRoZSByZXF1aXJlbWVudHMgb2YgYW4gQVMgYW5kIG1vcmUuIFdoaWxlIEFTIFNE S3MgcHJvdmlkZSBlYXN5IHdheXMgZm9yIGNsaWVudCBVSXMgdG8gZWZmZWN0aXZlbHkgZGVhbCB3 aXRoIGNvbW11bmljYXRpb24gdmlhIHRoZSBBUywgdGhlcmUncyBubyB3YXkgZm9yIHRoZSBBUyB0 byBwcm92aWRlIHN0YW5kYXJkIEFTIHNwZWNpZmljIHNlcnZpY2VzIHByb3RvdHlwZXMgdG8gc3Vw cG9ydCBCRkYuIFRoYXQgbWVhbnMgdGhhdCBldmVyeW9uZSBpcyB3cml0aW5nIHRoZWlyIG93biBC RkYgQVMtcHJveHkuDQpUTUktQkZGIGRvZXMgcHJvdmlkZSBhIHNvcnQgb2YgcHJveHkgZm9yIHRo ZSBBUywgYnV0IGl0IGlzIHZlcnkgY29uc3RyYWluZWQgYm90aCBpbiBmdW5jdGlvbmFsaXR5IChv bmx5IG9uZSBzaW1wbGUgcmVxdWVzdCB0eXBlKSBhbmQgdG9wb2xvZ3kgKG9ubHkgb25lIHJlcXVl c3RvciB0eXBlLCB3aXRoIGFzc3VtcHRpb25zIGFib3V0IHNlc3Npb25zLCBvcmlnaW4gcHJvdmVu YW5jZSBldGMpIGhlbmNlIHRoZSByZXF1aXJlbWVudHMgYXJlIGEgdmVyeSBsaW1pdGVkIHN1YnNl dCBvZiBhIGZ1bGwgYmxvd24gQVMuDQpJbiB0ZXJtcyBvZiBldmVyeW9uZSBkb2luZyB0aGVpciBv d24gaW1wbGVtZW50YXRpb24sIHRoZSBpbnRlbnQgaGVyZSBpcyB0aGUgZXhhY3Qgb3Bwb3NpdGUu IEJ5IHByb3ZpZGluZyBndWlkYW5jZSBvbiBob3cgdG8gZm9ybWF0IHJlcXVlc3RzL3Jlc3BvbnNl cyBhbmQgd2hhdCBlbmRwb2ludHMgdG8gcmVmZXIgdG8sIHRoZSBpbXBsZW1lbnRhdGlvbiBkZXRh aWxzIGNhbiBiZSBmYWN0b3JlZCBvdXQgZnJvbSBpbmRpdmlkdWFsIGFwcHMgYW5kIHN0YWNrcywg ZmFjaWxpdGF0aW5nIGludGVyb3BlcmFiaWxpdHkuDQoNCg0KICAqICAgWy4uXSBXaGljaCBpc24n dCBldmVyIGp1c3RpZmllZCwgYnV0IGV2ZW4gaWYgd2UgYWNjZXB0IHRoYXQgYXMgYSB0cnVlIHBy ZW1pc2UsIHdoYXQgYXJlIHRoZXNlIEFTIGRvaW5nIHRoYXQgZXZlbiByZXF1aXJlIGEgQkZGPw0K SSBhbSBub3Qgc3VyZSBob3cgdG8gaW50ZXJwcmV0IHRoZSBzdGF0ZW1lbnQgYWJvdXQg4oCcZXZl ciBqdXN0aWZpZWTigJ0uIFRoaXMgaGFzIGxpdHRsZSB0byBkbyB3aXRoIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlci4gTm90IGV2ZXJ5IGFwcGxpY2F0aW9uIGNhbiBoYXZlIGEgYmFja2VuZCB0aGF0 IGV4cG9zZXMgYSBmYcOnYWRlIHJlcGxpY2F0aW5nIGFsbCB0aGUgQVBJcyB0aGUgZnJvbnRlbmQg bmVlZCB0byBpbnZva2UsIGZvciBhbGwgc29ydHMgb2YgcmVhc29uczogbWFpbnRlbmFuY2UsIHBl cmZvcm1hbmNlLCBza2lsbHMgb2YgdGhlIGRldmVsb3BlcnMgaW52b2x2ZWQsIGNhcGFiaWxpdGll cyBvZiB0aGUgc3RhY2tzIG9mIGNob2ljZSwgYW5kIHNvIG9uLiBUaGlzIGlzbuKAmXQgdGhlb3Jl dGljYWwsIEkgaGFkIHRoaXMgZGlzY3Vzc2lvbnMgbWFueSB0aW1lcyB3aXRoIHByb3NwZWN0cyBh bmQgZGV2ZWxvcGVycy4NCg0KDQogICogICBIeXBvdGhldGljYWxseSB5b3UgY291bGQgYXJndWUg dGhhdCB0aGUgYXV0aCBjb2RlIGZsb3cgcmVxdWlyZXMgYSBCRkYgYW5kIHRoYXQncyByZXF1aXJl ZCBmb3IgdXNlciBsb2dpbiBzaW5jZSBpbXBsaWNpdCBmbG93IG5vIGxvbmdlciBleGlzdHMsIGJ1 dCB0aGF0IGlzbid0IHRydWUuIFlvdSBjYW4gdXNlIGNsaWVudCBzaWRlIFBLQ0UgZm9yIHZhbGlk YXRpb24gb2YgdGhlc2UgdmlhIG5vdCByZXF1aXJpbmcgdGhlIGNsaWVudCBzZWNyZXQgaW4gdGhl IGZyb250IGVuZCwgYW5kIHRoZW4gdGhlIHByb2JsZW0gdGhlcmUgaXMgc29sdmVkLg0KSW4gY29u Y3JldGUgdGVybXMsIHRoaW5ncyBhcmUgYSBiaXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIOKAnGEg Z3JhbnQgZm9yIFNQQXMgYWxyZWFkeSBleGlzdOKAnS4gSSBhbSB3ZWxsIGF3YXJlIHRoYXQgY29k ZStQS0NFIGlzIGEgdmlhYmxlIHNvbHV0aW9uIGZvciBTUEFzIHRvIGdldCBhY2Nlc3MgdG9rZW5z LCBob3dldmVyIHRoYXQgaGFzIGl0cyBvd24gY2hhbGxlbmdlcy4gRm9yIGV4YW1wbGUsIGlmIHlv dSB3YW50IHRvIHVzZSByZWZyZXNoIHRva2VucyBpbiBpdCwgeW91IG5lZWQgdG8gc2VuZGVyIGNv bnN0cmFpbiB0aGVtIG9yIHN1cHBvcnQgcmVmcmVzaCB0b2tlbiByb3RhdGlvbi4gSWYgeW91IGNo ZWNrIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBhY3Jvc3MgdGhlIGluZHVzdHJ5LCB5b3XigJlsbCBz ZWUgdGhhdCB2ZXJ5IGZldyBTREtzIGFjdHVhbGx5IGRvIHN1cHBvcnQgcm90YXRpb24gb3Igc2Vu ZGVyIGNvbnN0cmFpbnQgdG9kYXktIGFyZ3VhYmx5IGludHJvZHVjaW5nIGEgbmV3IHNlY3VyaXR5 IGlzc3VlLiBBbmQgb2YgY291cnNlLCB0aGVyZeKAmXMgdGhlIGh1Z2UgZGViYWNsZSBhYm91dCBz YXZpbmcgdG9rZW5zIGluIGxvY2FsIHN0b3JhZ2UtIHNvbWV0aGluZyB0aGF0IG1hbnkgYXBwbGlj YXRpb25zIG5lZWQgdG8gZG8gaW4gb3JkZXIgdG8gb2ZmZXIgdGhlIGV4cGVyaWVuY2UgdGhlaXIg Y3VzdG9tZXJzIHJlcXVpcmUuDQpJZiBhIFNQQSBhcHAgZG9lcyBub3QgaGF2ZSBhIGJhY2tlbmQs IGNvZGUrUEtDRSBpcyB0aGUgb25seSBnYW1lIGluIHRvd24uIElmIGl0IGhhcyBhIGJhY2tlbmQg QU5EIGNhbiBsZWF2ZSBhbGwgYWN0dWFsIEFQSSBjYWxscyB0byBpdCwgdGhlcmXigJlzIG5vIG5l ZWQgdG8gZ2V0IHRva2VucyBpbiB0aGUgdXNlciBhZ2VudC4NCkJ1dCBpZiB5b3UgYXJlIGluIG9u ZSBzaXR1YXRpb24gd2hlcmUgeW91IGRvIGhhdmUgYSBiYWNrZW5kIGFuZCBjYW5ub3QgZGVsZWdh dGUgQVBJIGNhbGxzIChzZWUgbXkgcHJlY2VkaW5nIGNvbW1lbnQpLCB0aGVuIFRNSS1CRkYgY2Fu IGdldCB0b2tlbnMgdG8geW91ciBmcm9udGVuZCB3aXRob3V0IHJlcXVpcmluZyBjb21wbGV4IGph dmFzY3JpcHQgbG9naWMsIHdpdGhvdXQgaGF2aW5nIHRvIHBlcnNpc3QgYW55dGhpbmcgaW4gbG9j YWwgc3RvcmFnZSBhbmQgd2l0aG91dCByZXF1aXJpbmcgdGhlIEFTIHRvIHN1cHBvcnQgcm90YXRp b24gb3Igc2VuZGVyIGNvbnN0cmFpbnQuIEFzIGxvbmcgYXMgdGhlIHRyYWZmaWMgd2l0aCBiZmYt dG9rZW4gcHJveHkgaXMgaGFyZGVuZWQsIEkgd291bGQgYXJndWUgVE1JLUJGRiBtaWdodCBhY3R1 YWxseSBiZSBlYXNpZXIgdG8gaW1wbGVtZW50IHNlY3VyZWx5IHRoYXQgY29kZStQS0NFK3JvdGF0 aW9uL1NDLiBIYXZpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgZnJvbnRlbmQgcmVtYWlucyBub3Qg Z3JlYXQsIGJ1dCBpdCBzZWVtcyB0aGF0IGdpdmluZyBwZW9wbGUgd2hvIHdvdWxkIGRvIGl0IGFu eXdheSBzb21lIGd1aWRhbmNlIGlzIGJldHRlciB0aGFuIGxlYXZpbmcgdGhlbSBhdCB0aGVpciBv d24gZGV2aWNlLSB1bmxlc3Mgd2UgY29uY2x1ZGUgdGhhdCB0aGlzIGZsb3cgY2Fubm90IGJlIHNl Y3VyZWQsIGluIHdoaWNoIGNhc2UgSSBhZ3JlZSB3ZSBzaG91bGQgZXhwbGljaXRseSBpZG5jaWF0 ZSB0aGlzIGFzIGFudGkgcGF0dGVybi4gQnV0IHNvIGZhciwgaXQgc2VlbXMgc3RpbGwgdG8gYmUg ZGVtb3NudHJhdGVkLg0KDQoNCiAgKiAgIFRoZXJlIHdhcyBhbHNvIHRoZSBhcmd1bWVudCBvZiB0 aGVyZSBhcmUgbG90cyBvZiBwZW9wbGUgZG9pbmcgdGhpcywgd2hpY2ggaXMgYWx3YXlzIGEgdGVy cmlibGUgYXJndW1lbnQsIGJ1dCBldmVuIGlmIHdlIGRvIHBlcm1pdCB0aGF0IGluIHRoZSBkaXNj dXNzaW9uLCB3ZSBzdGlsbCBuZWVkIHRvIGFuc3dlciB0aGUgd2h5LiBXaHkgYXJlIGRldmVsb3Bl cnMgY3JlYXRpbmcgQkZGIGZvciB0aGVpciBmcm9udGVuZHMgdG8gY29tbXVuaWNhdGUgd2l0aCBh biBBUy4gSXMgaXQgYmVjYXVzZSBBUyBhcmUgdGVycmlibGUsIGlzIGl0IGJlY2F1c2UgZnJvbnQg ZW5kcyBhcyBhIHNlcnZpY2UgYXJlIHRlcnJpYmxlLCBldGMuLi4gVW50aWwgd2Uga25vdyB3aHkg dGhpcyBpcyBoYXBwZW5pbmcgY29uY3JldGVseSwgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgZW5j b3VyYWdlIGZ1cnRoZXIgdXNlIG9mIGEgcGF0dGVybiByaWZlIHdpdGggcG90ZW50aWFsIHNlY3Vy aXR5IHJpc2tzIGJ5IHRlbGxpbmcgZXZlcnlvbmUgaG93IHlvdSBjYW4gZG8gaXQgKGJlY2F1c2Ug dGhlIGd1aWRhbmNlIHdlIGFyZSBvZmZlcmluZyBkb2Vzbid0IGV2ZW4gc2xpZ2h0bHkgaW5jcmVh c2Ugc2FmZXR5KS4NClRoZSBwcmVjZWRpbmcgY29tbWVudHMgc2hvdWxkIGhhdmUgc2hlZCBtb3Jl IGxpZ2h0IGFib3V0IHRoZSB3aHksIGFuZCBvbiBzb21lIG9mIHRoZSBzZWN1cml0eSBjb25jZXJu cyAodGhlcmUgd2FzIG9uZSBjb25jZXJuIHJhaXNlZCBieSBOZWlsLCBhbmQgaXQgc2VlbXMgdGhl cmUgYXJlIHBvc3NpYmxlIG1pdGlnYXRpb25zIGluIHBsYWNlKSBwbHVzIGhvdyB0aGlzIG1pZ2h0 IGFjdHVhbGx5IGluY3JlYXNlIHNhZmV0eSBpbiBzb21lIGFzcGVjdHMuIEJ1dCB0byBhZGQgbW9y ZSBjb2xvciwgb25lIG9mIHRoZSBvdGhlciByZWFzb25zIGZvciB3aGljaCB0aGlzIGlzIGhhcHBl bmluZyBpcyBiZWNhdXNlIGl04oCZcyBzaW1wbGUuIEJhY2tlbmQgT0FVdGgvT0lEQyBTREtzIGxp a2UgbWlkZGxld2FyZXMgYW5kIHNpbWlsYXIgYXJlIHZlcnkgbWF0dXJlIGF0IHRoaXMgcG9pbnQs IGFuZCB0aGV5IGFyZW7igJl0IHNhZGRsZWQgYnkgYSBsb3Qgb2YgdGhlIGNvbXBsZXhpdHkgYW5k IHVuY2VydGFpbmx5IHRoYXQgYnJvd3NlciBiYXNlZCBTREtzIGNhcnJ5LiBUaGluZ3MgbGlrZSBJ RSB6b25lcywgSVRQLCBTYW1lU2l0ZSBhbmQgb3VyIG93biBjaGFuZ2luZyBndWlkYW5jZSAoZm9y IGdvb2QgcmVhc29ucykgcGx1cyBkaXNvbW9nZW5lb3VzIHN1cHBvcnQgZnJvbSBwcm92aWRlcnMg b2YgdGhlIGZlYXR1cmVzIHJlcXVpcmVkIGZvciB0aGUgbGF0ZXN0IGd1aWRhbmNlIGNyZWF0ZSB1 bmNlcnRhaW50eSBhbmQgY29tcGxleGl0eSB0aGF0IG1hbnkgbm9uLWluaXRpYXRlZCB3b27igJl0 IHB1dCB1cCB3aXRoLiBBZGQgdG8gdGhpcyB0aGF0IHRoZSBtb3JlIGFwcCBkZXZlbG9wbWVudCBt b3ZlcyB0byB0aGUgZnJvbnRlbmQsIHRoZSBtb3JlIHlvdSBkb27igJl0IGdldCBmdWxsIHN0YWNr IGRldmVsb3BlcnMgYW5kIGdldHRpbmcgYSBmcm9udGVuZCBkZXZlbG9wZXIgdG8gZGVhbCB3aXRo IGFsbCB0aG9zZSBxdWlya3MgaXMgaGFyZC4gR2V0dGluZyB0b2tlbnMgdGhydSB3ZWxsIHN1cHBv cnRlZCBtaWRkbGV3YXJlcyBhbmQgZm9yd2FyZCB0aGVtIHRvIHRoZSBmcm9udGVuZCBpcyBzaW1w bGUuDQpBbHNvLCB0byBiZSBjbGVhci4gVGhpcyBleGFjdCB0b3BvbG9neSBoYXMgYmVlbiBjb25z aWRlcmVkIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCBkdXJpbmcgSUVURiBtZWV0aW5ncywgaW4gTW9u dHJlYWwgd2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCBpbmNsdWRpbmcgaXQgaW4gc29tZSBCQ1Ag YW5kIHdoZXRoZXIgd2Ugc2hvdWxkIGhhdmUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8g c2lnbmFsIHRvIHRoZSBBUyB0aGF0IHRoZSB0b2tlbnMgd2lsbCBiZSB1c2VkIGJ5IGNvZGUgZXhl Y3V0aW5nIGluIGEgd2Vha2VyIHNlY3VyaXR5IGNvbnRleHQgKHVzZXIgYWdlbnQpIHRoYW4gdGhl IHJlcXVlc3RvcuKAmXMgKGNvbmZpZGVudGlhbCBjbGllbnQgb24gYmFja2VkKS4gSSBhbSBzdXJl IHdlIGNhbiBmaW5kIHRoZSBtaW51dGVzIG9mIHRoYXQuIFRoaXMgaXNu4oCZdCBzb21ldGhpbmcg Y29tcGxldGVseSBsZWZ0IGZpZWxkLg0KDQoNCiAgKiAgIEZ1cnRoZXIsIGV2ZW4gaWYgd2Ugd2Vy ZSB0byBhY2NlcHQgdGhpcyBwYXR0ZXJuIGFuZCB3YW50IHRvIGNyZWF0ZSBhIHN0YW5kYXJkIGFy b3VuZCBpdCwgd2UgYXJlIGVmZmVjdGl2ZWx5IGNyZWF0aW5nIGFuIEFTIHByb3h5IGhlcmUsIHdo aWNoIG1lYW5zIHdlIHNob3VsZCByZXF1aXJlIGl0IHRvIGFjdCBsaWtlIGFuIEFTLCBhbmQgZGVs ZWdhdGUgdGhlIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2VzLCBlbmRwb2ludHMsIHRlcm1pbm9s b2d5LCBhbmQgcGF0dGVybnMgdG8gZXhpc3Rpbmcgb3IgZnV0dXJlIEFTIHJlbGF0ZWQgUkZDcy4N CkkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NhbCB3YXJyYW50 cyBkb2luZyBhbCB0aGF0LiBDb3VsZCB5b3UgcG9pbnQgYXQgdGhlIGFyZWEgaW4gdGhlIHNwZWMg dGhhdCBzdWdnZXN0IHdl4oCZZCBuZWVkIHRvIGFkZCBhbnl0aGluZyBiZXlvbmQgd2hhdOKAmXMg c3VnZ2VzdGVkIGF0IHRoZSBtb21lbnQgdG8gYWNoaWV2ZSB0aGUgc3RhdGVkIGdvYWxzPw0KDQoN CiAgKiAgIEFuZCB0aGVyZWZvcmUgaW4gY29uY2x1c2lvbiB3ZSBzaG91bGQgZm9jdXMgb25seSBv biB0aGUgYXNwZWN0cyB0aGF0IGFyZSBhYnNvbHV0ZWx5IHJlcXVpcmVkIHdoaWNoIGFyZW4ndCBh bHJlYWR5IHByZXNlbnQgaW4gc29tZSBmb3JtIGluIGV4aXN0aW5nIEFTIHJlbGF0ZWQgUkZDcywg YnV0IHdoYXQgYXJlIHRob3NlPw0KSSBhbSBzdGlsbCBtaXNzaW5nIGhvdyB0aGlzIGhhcyB0byBk byB3aXRoIG1pc3NpbmcgQVMgZnVuY3Rpb25hbGl0eS4gT25lIG9mIHRoZSB0aGluZ3Mgd2UgdHJp ZWQgdG8gZG8gd2FzIG5vdCB0byByZXF1aXJlIGFueSBjaGFuZ2UgdG8gdGhlIEFTLiBUaGUgcHJv YmxlbSBiZWluZyBzb2x2ZWQgaGVyZSBpcyBob3cgdG8gYWxsb3cgamF2YXNjcmlwdCBkZXZlbG9w ZXJzIHRvIGNhbGwgQVBJIGRpcmVjdGx5IGZyb20gdGhlaXIgZnJvbnRlbmQgd2hlbiB0aGV5IGhh dmUgYSBiYWNrZW5kIHdpdGggYmFzaWMgb2F1dGggY2FwYWJpbGl0aWVzIGF0IHRoZWlyIGRpc3Bv c2FsLCBpbiB0aGUgc2ltcGxlc3QgcG9zc2libGUgd2F5LiBDaGFuZ2VzIGluIHRoZSBBUyBkb2Vu 4oCZdCBhcHBlYXIgdG8gYmUgbmVjZXNzYXJ5IHRoZXJlDQoNCg0KICAqICAgVGhlIG9uZSBjb3Vu dGVycG9pbnQgdG8gYWxsIG9mIHRoaXMgaXMgdGhlIHBvdGVudGlhbCBpbnRyb2R1Y3Rpb24gb2Yg ZG9tYWluIHNwZWNpZmljIGNvb2tpZSBsYW5ndWFnZSAod2hpY2ggZG9lc24ndCBleGlzdCBpbiB0 aGUgY3VycmVudCBkcmFmdCkuIENvbmNyZXRlbHksIGxldCdzIGFkZCBhIHJlc3BvbnNlX3R5cGU9 Y29va2llLCB0byBBUyB0byBzdXBwb3J0IGRvbWFpbiBmaXJzdC1wYXJ0eSBjb29raWVzIGFuZCBz ZXNzaW9uIG1hbmFnZW1lbnQuDQpDb3VsZCB5b3UgZXhwYW5kIG9uIGhvdyB5b3UgZW52aXNpb24g dGhpcyB3b3VsZCB3b3JrL3NvbHZlIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQgYWJvdmU/DQoNCg0K RnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWQ9NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc+DQpE YXRlOiBTdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAxOjUxDQpUbzogTmVpbCBNYWRkZW4g PG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+DQpDYzogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRv cmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBC YWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KSSBhbHNvIGZsYXQgb3V0IHJlamVjdCB0 aGUgcHJlbWlzZSBvZiB0aGlzIGRyYWZ0LiBJdCBpbnRyb2R1Y2VzIGEgcHNldWRvIEFTLWxpa2Ug cHJveHkgd2hpY2ggbm93IGhhcyBhbGwgdGhlIHJlcXVpcmVtZW50cyBvZiBhbiBBUyBhbmQgbW9y ZS4gV2hpbGUgQVMgU0RLcyBwcm92aWRlIGVhc3kgd2F5cyBmb3IgY2xpZW50IFVJcyB0byBlZmZl Y3RpdmVseSBkZWFsIHdpdGggY29tbXVuaWNhdGlvbiB2aWEgdGhlIEFTLCB0aGVyZSdzIG5vIHdh eSBmb3IgdGhlIEFTIHRvIHByb3ZpZGUgc3RhbmRhcmQgQVMgc3BlY2lmaWMgc2VydmljZXMgcHJv dG90eXBlcyB0byBzdXBwb3J0IEJGRi4gVGhhdCBtZWFucyB0aGF0IGV2ZXJ5b25lIGlzIHdyaXRp bmcgdGhlaXIgb3duIEJGRiBBUy1wcm94eS4NCg0KQWRkaXRpb25hbGx5LCBJIHRvbyBhbSBsYWNr aW5nIHRoZSBjbGFyaXR5IG9uIHRoZSBXSFkuIFRoZSBvbmx5IHRoaW5nIG1lbnRpb25lZCBpbiB0 aGUgZHJhZnQgaXMNClRoYXQgYXBwcm9hY2ggaXMgbm90IGFsd2F5cyB2aWFibGUsIGFzIGluIHRo ZSBhYnNlbmNlIG9mIHJldmVyc2UgcHJveHkgZGVwbG95bWVudHMgdGhlIGNyZWF0aW9uIGFuZCBt YWludGVuYW5jZSBvZiBhIGZhY2FkZSBmb3IgbXVsdGlwbGUgQVBJcyBjYW4gYmUgZXhwZW5zaXZl DQpXaGljaCBpc24ndCBldmVyIGp1c3RpZmllZCwgYnV0IGV2ZW4gaWYgd2UgYWNjZXB0IHRoYXQg YXMgYSB0cnVlIHByZW1pc2UsIHdoYXQgYXJlIHRoZXNlIEFTIGRvaW5nIHRoYXQgZXZlbiByZXF1 aXJlIGEgQkZGPw0KDQpIeXBvdGhldGljYWxseSB5b3UgY291bGQgYXJndWUgdGhhdCB0aGUgYXV0 aCBjb2RlIGZsb3cgcmVxdWlyZXMgYSBCRkYgYW5kIHRoYXQncyByZXF1aXJlZCBmb3IgdXNlciBs b2dpbiBzaW5jZSBpbXBsaWNpdCBmbG93IG5vIGxvbmdlciBleGlzdHMsIGJ1dCB0aGF0IGlzbid0 IHRydWUuIFlvdSBjYW4gdXNlIGNsaWVudCBzaWRlIFBLQ0UgZm9yIHZhbGlkYXRpb24gb2YgdGhl c2UgdmlhIG5vdCByZXF1aXJpbmcgdGhlIGNsaWVudCBzZWNyZXQgaW4gdGhlIGZyb250IGVuZCwg YW5kIHRoZW4gdGhlIHByb2JsZW0gdGhlcmUgaXMgc29sdmVkLiBBbmQgaWYgeW91IGFyZ3VlIHRo YXQgdGhpcyBjYW4ndCBiZSBkb25lLCB0aGVuIHRoZSBzb2x1dGlvbiBpcyBpbnRyb2R1Y2luZyBh IGJldHRlciB3YXkgdG8gaGFuZGxlIHRoaXMgc28gdGhhdCBhIEJGRiBmb3IgQVMgZmxvd3MgZG9u J3QgaGF2ZSB0byBleGlzdC4NCg0KU28gd2hhdCBjb25jcmV0ZSBwcm9ibGVtIGlzIHRoaXMgc29s dmluZz8NCg0KVGhlcmUgd2FzIGFsc28gdGhlIGFyZ3VtZW50IG9mIHRoZXJlIGFyZSBsb3RzIG9m IHBlb3BsZSBkb2luZyB0aGlzLCB3aGljaCBpcyBhbHdheXMgYSB0ZXJyaWJsZSBhcmd1bWVudCwg YnV0IGV2ZW4gaWYgd2UgZG8gcGVybWl0IHRoYXQgaW4gdGhlIGRpc2N1c3Npb24sIHdlIHN0aWxs IG5lZWQgdG8gYW5zd2VyIHRoZSB3aHkuIFdoeSBhcmUgZGV2ZWxvcGVycyBjcmVhdGluZyBCRkYg Zm9yIHRoZWlyIGZyb250ZW5kcyB0byBjb21tdW5pY2F0ZSB3aXRoIGFuIEFTLiBJcyBpdCBiZWNh dXNlIEFTIGFyZSB0ZXJyaWJsZSwgaXMgaXQgYmVjYXVzZSBmcm9udCBlbmRzIGFzIGEgc2Vydmlj ZSBhcmUgdGVycmlibGUsIGV0Yy4uLiBVbnRpbCB3ZSBrbm93IHdoeSB0aGlzIGlzIGhhcHBlbmlu ZyBjb25jcmV0ZWx5LCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBlbmNvdXJhZ2UgZnVydGhlciB1 c2Ugb2YgYSBwYXR0ZXJuIHJpZmUgd2l0aCBwb3RlbnRpYWwgc2VjdXJpdHkgcmlza3MgYnkgdGVs bGluZyBldmVyeW9uZSBob3cgeW91IGNhbiBkbyBpdCAoYmVjYXVzZSB0aGUgZ3VpZGFuY2Ugd2Ug YXJlIG9mZmVyaW5nIGRvZXNuJ3QgZXZlbiBzbGlnaHRseSBpbmNyZWFzZSBzYWZldHkpLg0KDQpG dXJ0aGVyLCBldmVuIGlmIHdlIHdlcmUgdG8gYWNjZXB0IHRoaXMgcGF0dGVybiBhbmQgd2FudCB0 byBjcmVhdGUgYSBzdGFuZGFyZCBhcm91bmQgaXQsIHdlIGFyZSBlZmZlY3RpdmVseSBjcmVhdGlu ZyBhbiBBUyBwcm94eSBoZXJlLCB3aGljaCBtZWFucyB3ZSBzaG91bGQgcmVxdWlyZSBpdCB0byBh Y3QgbGlrZSBhbiBBUywgYW5kIGRlbGVnYXRlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHJlc291cmNl cywgZW5kcG9pbnRzLCB0ZXJtaW5vbG9neSwgYW5kIHBhdHRlcm5zIHRvIGV4aXN0aW5nIG9yIGZ1 dHVyZSBBUyByZWxhdGVkIFJGQ3MuIChXZSBhbHJlYWR5IGhhdmUgYSBwcm9ibGVtIHdpdGggdGhl IGN1cnJlbnQgZHJhZnQgYXMgaXQgYXR0ZW1wdHMgdG8gcmVkZWZpbmUgYW5kIGludHJvZHVjZSBu ZXcgdGVybXMvcGF0dGVybnMgdGhhdCBoYXZlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgYXMgZXhp c3Rpbmcgb25lcyBpbiB0aGUgQVMsIHlldCBmYWlsIHRvIGNhcHR1cmUgdGhlIGZ1bGwgaW1wb3J0 YW5jZSBvZiB0aGUgb3JpZ2luYWwgUkZDcy4gVGhpcyBpcyBiYWQgZHVwbGljYXRpb24pLiBBbmQg dGhlcmVmb3JlIGluIGNvbmNsdXNpb24gd2Ugc2hvdWxkIGZvY3VzIG9ubHkgb24gdGhlIGFzcGVj dHMgdGhhdCBhcmUgYWJzb2x1dGVseSByZXF1aXJlZCB3aGljaCBhcmVuJ3QgYWxyZWFkeSBwcmVz ZW50IGluIHNvbWUgZm9ybSBpbiBleGlzdGluZyBBUyByZWxhdGVkIFJGQ3MsIGJ1dCB3aGF0IGFy ZSB0aG9zZT8NCg0KVGhlIG9uZSBjb3VudGVycG9pbnQgdG8gYWxsIG9mIHRoaXMgaXMgdGhlIHBv dGVudGlhbCBpbnRyb2R1Y3Rpb24gb2YgZG9tYWluIHNwZWNpZmljIGNvb2tpZSBsYW5ndWFnZSAo d2hpY2ggZG9lc24ndCBleGlzdCBpbiB0aGUgY3VycmVudCBkcmFmdCkuIENvbmNyZXRlbHksIGxl dCdzIGFkZCBhIHJlc3BvbnNlX3R5cGU9Y29va2llLCB0byBBUyB0byBzdXBwb3J0IGRvbWFpbiBm aXJzdC1wYXJ0eSBjb29raWVzIGFuZCBzZXNzaW9uIG1hbmFnZW1lbnQuIFdoZW4gd2UgYnVpbHQg b3VyIEFTIHdlIGV4cGxpY2l0bHkgYWRkZWQgdGhpcyBzbyB0aGF0IHNlcnZpY2VzIGNhbiB1c2Ug dGhlIEpXVCBmb3VuZCBpbiB0aGUgSHR0cE9ubHkgU2FtZVNpdGU9U3RyaWN0IGNvb2tpZSBhcyBh IHNlY3VyaXR5IG1lYXN1cmUgYWdhaW5zdCBYU1MgYXR0YWNrcyB0aGF0IGF0dGVtcHQgdG8gZXhm aWx0cmF0ZSBhY2Nlc3MgdG9rZW5zLiBUaGF0J3MgYSBwb3RlbnRpYWwgc3VnZ2VzdGlvbiBJIHdv dWxkIGZhdm9yLCBhbHRob3VnaCBJIHN0aWxsIGNhbid0IGtub3cgaWYgdGhhdCBzb2x2ZXMgdGhl IHByb2JsZW0gYmVpbmcgcHJlc2VudGVkIGluIHRoZSBkcmFmdC4NCg0KLSBXYXJyZW4NCg0KDQpb SW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuXQ0KDQpXYXJyZW4gUGFyYWQNCg0KRm91bmRlciwgQ1RP DQpTZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBh cmNoaXRlY3R1cmUuIEltcGxlbWVudCBBdXRocmVzczxodHRwczovL2F1dGhyZXNzLmlvPi4NCg0K DQpPbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCA5OjE4IEFNIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRl bkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4gd3JvdGU6 DQpJIGhhdmUgYSBsb3Qgb2Ygc2VjdXJpdHkgY29uY2VybnMgYWJvdXQgdGhpcyBkcmFmdC4NCg0K VGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJpdHkgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBoYW5k bGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBmcm9udGVuZCBidXQgbmV2ZXIgcmVhbGx5IHNwZWxs cyB0aGVtIG91dC4gPkZyb20gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGl0IHNlZW1zIHRo YXQgdGhlIHByaW1hcnkgY29uY2VybiBpcyB3aXRoIHRoZWZ0IG9mIGFjY2VzcyB0b2tlbnMgZnJv bSBsb2NhbCBzdG9yYWdlLiBUbyBkbyB0aGlzIHlvdeKAmWQgbmVlZCBhbiBYU1MgYXR0YWNrLiBC dXQgaW4gdGhhdCBjYXNlLCB3b3VsZG7igJl0IHRoZSBhdHRhY2tlciBzaW1wbHkgdXNlIHRoZSBY U1MgdG8gbWFrZSBhIGNhbGwgdG8gdGhlIGJmZi10b2tlbiBlbmRwb2ludCBpbnN0ZWFkPw0KDQpU aGUgY29tYmluYXRpb24gb2YgdGhlIGJmZi10b2tlbiBlbmRwb2ludCByZWNvbW1lbmRpbmcgdGhl IHVzZSBvZiBHRVQgcmVxdWVzdHMgdG9nZXRoZXIgd2l0aCB0aGUgaGludCB0byB1c2UgY29va2ll LWJhc2VkIGF1dGhlbnRpY2F0aW9uIGlzIGxpa2VseSBnb2luZyB0byBwdW5jaCBhIGhvbGUgaW4g bW9zdCBDU1JGIGRlZmVuc2VzLCB3aGljaCBhc3N1bWUgdGhhdCBHRVRzIGFyZSBzYWZlLiBUaGUg b25seSB0aGluZyBwcmV2ZW50aW5nIHRoaXMgYmVpbmcgZXhwbG9pdGFibGUgaXMgQ3Jvc3MtT3Jp Z2luIFJlYWQgQmxvY2tpbmcgKGh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291cmNlLmNvbS9jaHJv bWl1bS9zcmMvKy9tYXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19vcmlnaW5fcmVhZF9ibG9j a2luZ19leHBsYWluZXIubWQpIGR1ZSB0byB0aGUgSlNPTiBjb250ZW50LXR5cGUuIFRoYXQgbWFr ZXMgbWUgcmVhbGx5IG5lcnZvdXMuIFdlIHNob3VsZCBhdCBsZWFzdCBtYW5kYXRlIFgtQ29udGVu dC1UeXBlLU9wdGlvbnM6IG5vc25pZmYgb24gdGhhdCByZXNwb25zZS4gSeKAmWQgZmVlbCBtb3Jl IGNvbWZvcnRhYmxlIGlmIHRoaXMgd2FzIGEgUE9TVCByZXF1ZXN0IG9ubHkuDQoNCkFzIFN0b3lj aG8gU2xlcHRzb3YgbWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwgdGhlIGxhY2sgb2YgZnJv bnQtY2hhbm5lbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0aGUgUk8gc2VlbXMg b2RkLiBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVuIGNv dWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlzc3Vl IHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3IgQVBJ IGFjY2Vzcz8NCg0KSWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cgZXRjIHRoZW4g cGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFuZGFyZCBlcnJv ciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0aGUgU1BBIHRo ZW4gbmF2aWdhdGVzIHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRvIGEgUEFSIHJl cXVlc3QgZmlyc3QgYW5kIHJldHVybiBhIFVSSSB0aGF0IHJlZmVyZW5jZXMgdGhhdCBzbyB0aGF0 IGF1dGhvcml6YXRpb24gZGV0YWlscyBhcmVu4oCZdCBwYXNzZWQgdGhyb3VnaCB0aGUgZnJvbnRl bmQpLg0KDQrigJQgTmVpbA0KDQoNCg0KT24gMTIgRmViIDIwMjEsIGF0IDIwOjQ2LCBWaXR0b3Jp byBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQrvu79EZWFyIGFsbCwN CkJyaWFuIGFuZCB5b3VycyB0cnVseSBhcmUgcHJvcG9zaW5nIGEgbmV3IHNwZWNpZmljYXRpb24g dGhhdCBzaG93cyBob3cgdGhlIHVzZXIgYWdlbnQgZnJvbnRlbmQgb2YgYSB3ZWIgYXBwIGNhbiBk ZWxlZ2F0ZSB0b2tlbiBhY3F1aXNpdGlvbiBhbmQgcGVyc2lzdGVuY2UgdG8gaXRzIGJhY2tlbmQs IGFuZCByZXF1ZXN0IHN1Y2ggdG9rZW5zIHdoZW4gbmVlZGVkIGZvciBkaXJlY3QgYWNjZXNzIG9m IHByb3RlY3RlZCByZXNvdXJjZXMgZnJvbSB0aGUgZnJvbnRlbmQgY29kZS4NCg0KVGhlIHBhdHRl cm4gaXMgYWxyZWFkeSBpbiB1c2UsIGluIHByb3ByaWV0YXJ5IGZvcm0sIGJ5IHZhcmlvdXMgbW9k ZXJuIGRldmVsb3BtZW50IHN0YWNrcywgc3VjaCBhcyBOZXh0LkpTLiBWYXJpYW50cyBvZiB0aGUg cGF0dGVybiwgb2Z0ZW4gZGlzY3Vzc2VkIHVuZGVyIHRoZSBjYXRjaC1hbGwgdGVybSBCRkYgKGJh Y2tlbmQgZm9yIGZyb250ZW5kKSwgaGF2ZSBiZWVuIG9mdGVuIG1lbnRpb25lZCBpbiB0aGlzIHdv cmtncm91cOKAmXMgYWN0aXZpdHksIGJ1dCBhbHdheXMgbGVmdCBhbGwgaW1wbGVtZW50YXRpb24g ZGV0YWlscyB0byB0aGUgcmVhZGVyLg0KV2UgYmVsaWV2ZSB0aGUgcGF0dGVybiBoYXMgbWVyaXQs IGFzIGNvcnJvYm9yYXRlZCBieSBpdHMgZ3Jvd2luZyBhZG9wdGlvbi4gQnkgZGVsZWdhdGluZyBh Y2Nlc3MgdG9rZW4gYWNxdWlzaXRpb24gdG8gdGhlIGJhY2tlbmQsIHdlIGF2b2lkIG1hbnkgb2Yg dGhlIG9mdGVuIGJyaXR0bGUgbW92aW5nIHBhcnRzIChhbmQgaW1wbGllZCBhdHRhY2sgc3VyZmFj ZSkgcmVxdWlyZWQgdG8gYWNxdWlyZSBhY2Nlc3MgdG9rZW5zIGZyb20gYSB1c2VyIGFnZW50LiBU aGUgdG9wb2xvZ3kgYWxzbyByZWxpZXZlcyB0aGUgZnJvbnRlbmQgZnJvbSB0aGUgbmVlZCBvZiBw ZXJzaXN0aW5nIHRva2VucyBpbiBsb2NhbCBzdG9yYWdlLCBhIHdlbGwga25vd24gc29yZSBwb2lu dCBvZiB1c2luZyBPQXV0aCBkaXJlY3RseSBpbiBKYXZhU2NyaXB0LCBieSByZWx5aW5nIG9uIGl0 cyBiYWNrZW5kIHN0b3JhZ2UgYW5kIHNlc3Npb24gdG8gcHJlc2VydmUgdG9rZW5zLg0KDQpBbHRo b3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBpcyB2ZXJ5IHNpbXBsZSwgcHJvdmlkaW5nIGV4cGxpY2l0 IGd1aWRhbmNlIG9uIHRoZSBzY2VuYXJpbyBvZmZlcnMgbWFueSBhZHZhbnRhZ2VzLg0KLSBJdCBt YWtlcyBpdCBwb3NzaWJsZSB0byBjcmVhdGUgaW50ZXJvcGVyYWJsZSBTREtzLCB3aGVyZSBmcm9u dGVuZCBkZXYgc3RhY2tzIChhbnkgSlMgZmxhdm9yKSBjYW4gYmUgbWl4ZWQgYW5kIG1hdGNoZWQg d2l0aCBjb21wbGlhbnQgYmFja2VuZCBzdGFja3MgKG1pZGRsZXdhcmVzIGluIG5vZGUsIGphdmEs IEFTUC5ORVQ8aHR0cDovL0FTUC5ORVQ+LCBQSFAgZXRjKQ0KLSBJdCBhbGxvd3MgdXMgdG8gcHJv dmlkZSBndWlkYW5jZSBvbiBob3cgdG8gcHJvcGVybHkgdGFja2xlIHRoZSBzY2VuYXJpbyBhbmQg d2FybiBpbXBsZW1lbnRlcnMgYWdhaW5zdCBzZWN1cml0eSByaXNrcyAoc2NvcGUgZXNjYWxhdGlv bnMsIHVzaW5nIElEdG9rZW5zIGluc3RlYWQgb2YgYWNjZXNzIHRva2VucywgZXRjKQ0KLSBJdCBh bGxvd3MgdXMgdG8gZGlzY3VzcyAoYW5kIHdoZW4gYXBwcm9wcmlhdGUsIHByb21vdGUpIHRoaXMg cGF0dGVybiBhcyBwYXJ0IG9mIHRoZSBicm93c2VyIGFwcHMgc2VjdXJpdHkgZ3VpZGFuY2UsIGFu ZCBwb3NpdGlvbiB0aGUgc2NlbmFyaW8gd2hlcmUgZnJvbnRlbmQgb25seSBjYWxscyBBUEkgb24g aXRzIG93biBiYWNrZWQgKGhlbmNlIGRvZXNu4oCZdCBuZWVkIGFjY2VzcyB0b2tlbnMpIHNpbXBs eSBhcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGlzIG1vcmUgZ2VuZXJhbCBwYXR0ZXJuDQotIFRoaXMg YXBwcm9hY2ggbWFrZXMgbW9ja2luZyBhbmQgdGVzdGluZyBhcHBzIHZlcnkgZWFzeSwgcG9zc2li bHkgcHJldmVudGluZyBkZXZlbG9wZXJzIGZyb20gd2Vha2VuaW5nIHRoZSBzZWN1cml0eSBvZiB0 aGVpciBzeXN0ZW0gKGVnIHR1cm5pbmcgb24gUk9QRyBvcHRpb25zKSAgb3IgdHVybmluZyB0byBy aXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZw0KDQpOZWVkbGVzcyB0byBzYXksIHRoaXMgc3Bl Y2lmaWNhdGlvbiBkb2VzbuKAmXQgZW50aXJlbHkgZWxpbWluYXRlIHRoZSByaXNrcyBpbmhlcmVu dCB0byBkaXJlY3QgdXNlIG9mIGFjY2VzcyB0b2tlbnMgZnJvbSBhIGJyb3dzZXIuIEJ1dCByZWFs aXR5IGlzIHRoYXQgdGhlIHBhdHRlcm4gaXMgaW4gd2lkZXNwcmVhZCB1c2UsIGFuZCB0aGUgY2ly Y3Vtc3RhbmNlcyBsZWFkaW5nIHRvIHRoYXQgKGVnIGRldmVsb3BlcnMgb24gYSBwYXJ0aWN1bGFy IHByb2plY3Qgb25seSB3b3JrIHdpdGggZnJvbnRlbmQgc3RhY2tzOyBjb21wb25lbnRzIGxpa2Ug cmV2ZXJzZSBwcm94aWVzIG1pZ2h0IG5vdCBhbHdheXMgYmUgdmlhYmxlOyBldGMpIGFyZW7igJl0 IGdvaW5nIGF3YXkgYW55IHRpbWUgc29vbi4gQnkgcHJvdmlkaW5nIHNpbXBsZSBndWlkYW5jZSBv biB0aGlzIHBhdHRlcm4sIHdlIGNhbiBzaW1wbGlmeSB0aGUgbGlmZSBvZiBtYW55IGRldmVsb3Bl cnMgd2hpbGUgZW5zaHJpbmluZyBiYXNpYyBzZWN1cml0eSBoeWdpZW5lIGluIHNjZW5hcmlvcyB0 aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJlIGxlZnQgdG8gdGhlaXIgb3duIGRldmljZS4NCg0K TG9va2luZyBmb3J3YXJkIGZvciB5b3VyIGZlZWRiYWNrIQ0KDQpCJlYNCg0K77u/T24gMi8xMi8y MSwgMTI6NDEsICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZz4iIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQoNCiAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQNCiAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgVml0dG9yaW8gQmVydG9jY2kgYW5kIHBvc3RlZCB0byB0aGUNCiAgIElF VEYgcmVwb3NpdG9yeS4NCg0KICAgTmFtZTogICAgICAgIGRyYWZ0LWJlcnRvY2NpLW9hdXRoMi10 bWktYmZmDQogICBSZXZpc2lvbjogICAgMDANCiAgIFRpdGxlOiAgICAgICAgVG9rZW4gTWVkaWF0 aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kDQogICBEb2N1 bWVudCBkYXRlOiAgICAyMDIxLTAyLTEyDQogICBHcm91cDogICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KICAgUGFnZXM6ICAgICAgICAxNg0KICAgVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAu dHh0DQogICBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYvDQogICBIdG1sOiAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0w MC5odG1sDQogICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwDQoNCg0KICAgQWJzdHJhY3Q6DQogICAgICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxl Z2F0ZSBhY2Nlc3MNCiAgICAgIHRva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2VuZCBjb21wb25l bnQuICBJbiBzbyBkb2luZywgdGhlIGZyb250ZW5kDQogICAgICBjYW4gYWNjZXNzIHJlc291cmNl IHNlcnZlcnMgZGlyZWN0bHkgd2l0aG91dCB0YWtpbmcgb24gdGhlIGJ1cmRlbiBvZg0KICAgICAg Y29tbXVuaWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0 b2tlbnMsIGFuZA0KICAgICAgcGVyZm9ybWluZyBvcGVyYXRpb25zIHRoYXQgYXJlIGZyYXVnaHQg d2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW4NCiAgICAgIGV4ZWN1dGVkIGluIGEgdXNlciBh Z2VudCwgYnV0IGFyZSBzYWZlIGFuZCB3ZWxsIHByb3ZlbiB3aGVuIGV4ZWN1dGVkDQogICAgICBi eSBhIGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQuDQoNCg0KDQoNCiAg IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3Jn Pi4NCg0KICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KRm9yZ2VSb2NrIHZhbHVlcyB5b3VyIFByaXZhY3k8aHR0cHM6 Ly93d3cuZm9yZ2Vyb2NrLmNvbS95b3VyLXByaXZhY3k+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0K --_000_CO6PR18MB405236B3F50E3A5C42B82C39AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyODY4MDk3NDM7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTA4NjA3NDIyIC0xMDg0OTc1MjY2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 NTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFdhcnJl biwgdGhhbmtzIGZvciB0aGUgdGhvdWdodGZ1bCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklubGluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPi4gSXQgaW50cm9kdWNlcyBhIHBzZXVk byBBUy1saWtlIHByb3h5IHdoaWNoIG5vdyBoYXMgYWxsIHRoZSByZXF1aXJlbWVudHMgb2YgYW4g QVMgYW5kIG1vcmUuIFdoaWxlIEFTIFNES3MgcHJvdmlkZSBlYXN5IHdheXMgZm9yIGNsaWVudCBV SXMgdG8gZWZmZWN0aXZlbHkgZGVhbCB3aXRoIGNvbW11bmljYXRpb24gdmlhDQogdGhlIEFTLCB0 aGVyZSdzIG5vIHdheSBmb3IgdGhlIEFTIHRvIHByb3ZpZGUgc3RhbmRhcmQgQVMgc3BlY2lmaWMg c2VydmljZXMgcHJvdG90eXBlcyB0byBzdXBwb3J0IEJGRi4gVGhhdCBtZWFucyB0aGF0IGV2ZXJ5 b25lIGlzIHdyaXRpbmcgdGhlaXIgb3duIEJGRiBBUy1wcm94eS48bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRNSS1CRkYgZG9lcyBwcm92aWRlIGEgc29ydCBvZiBw cm94eSBmb3IgdGhlIEFTLCBidXQgaXQgaXMgdmVyeSBjb25zdHJhaW5lZCBib3RoIGluIGZ1bmN0 aW9uYWxpdHkgKG9ubHkgb25lIHNpbXBsZSByZXF1ZXN0IHR5cGUpIGFuZCB0b3BvbG9neSAob25s eSBvbmUgcmVxdWVzdG9yIHR5cGUsIHdpdGggYXNzdW1wdGlvbnMgYWJvdXQgc2Vzc2lvbnMsIG9y aWdpbiBwcm92ZW5hbmNlIGV0YykgaGVuY2UgdGhlIHJlcXVpcmVtZW50cw0KIGFyZSBhIHZlcnkg bGltaXRlZCBzdWJzZXQgb2YgYSBmdWxsIGJsb3duIEFTLjxicj4NCkluIHRlcm1zIG9mIGV2ZXJ5 b25lIGRvaW5nIHRoZWlyIG93biBpbXBsZW1lbnRhdGlvbiwgdGhlIGludGVudCBoZXJlIGlzIHRo ZSBleGFjdCBvcHBvc2l0ZS4gQnkgcHJvdmlkaW5nIGd1aWRhbmNlIG9uIGhvdyB0byBmb3JtYXQg cmVxdWVzdHMvcmVzcG9uc2VzIGFuZCB3aGF0IGVuZHBvaW50cyB0byByZWZlciB0bywgdGhlIGlt cGxlbWVudGF0aW9uIGRldGFpbHMgY2FuIGJlIGZhY3RvcmVkIG91dCBmcm9tIGluZGl2aWR1YWwg YXBwcyBhbmQgc3RhY2tzLA0KIGZhY2lsaXRhdGluZyBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ Wy4uXSBXaGljaCBpc24ndCBldmVyIGp1c3RpZmllZCwgYnV0IGV2ZW4gaWYgd2UgYWNjZXB0IHRo YXQgYXMgYSB0cnVlIHByZW1pc2UsIHdoYXQgYXJlIHRoZXNlIEFTIGRvaW5nIHRoYXQgZXZlbiBy ZXF1aXJlIGEgQkZGPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBhbSBub3Qgc3VyZSBob3cgdG8gaW50ZXJwcmV0IHRoZSBzdGF0ZW1lbnQgYWJvdXQg4oCcZXZl ciBqdXN0aWZpZWTigJ0uIFRoaXMgaGFzIGxpdHRsZSB0byBkbyB3aXRoIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlci4gTm90IGV2ZXJ5IGFwcGxpY2F0aW9uIGNhbiBoYXZlIGEgYmFja2VuZCB0aGF0 IGV4cG9zZXMgYSBmYcOnYWRlIHJlcGxpY2F0aW5nIGFsbCB0aGUgQVBJcyB0aGUgZnJvbnRlbmQg bmVlZCB0byBpbnZva2UsDQogZm9yIGFsbCBzb3J0cyBvZiByZWFzb25zOiBtYWludGVuYW5jZSwg cGVyZm9ybWFuY2UsIHNraWxscyBvZiB0aGUgZGV2ZWxvcGVycyBpbnZvbHZlZCwgY2FwYWJpbGl0 aWVzIG9mIHRoZSBzdGFja3Mgb2YgY2hvaWNlLCBhbmQgc28gb24uIFRoaXMgaXNu4oCZdCB0aGVv cmV0aWNhbCwgSSBoYWQgdGhpcyBkaXNjdXNzaW9ucyBtYW55IHRpbWVzIHdpdGggcHJvc3BlY3Rz IGFuZCBkZXZlbG9wZXJzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkh5cG90aGV0aWNhbGx5IHlvdSBjb3VsZCBh cmd1ZSB0aGF0IHRoZSBhdXRoIGNvZGUgZmxvdyByZXF1aXJlcyBhIEJGRiBhbmQgdGhhdCdzIHJl cXVpcmVkIGZvciB1c2VyIGxvZ2luIHNpbmNlIGltcGxpY2l0Jm5ic3A7ZmxvdyBubyBsb25nZXIg ZXhpc3RzLCBidXQgdGhhdCBpc24ndCB0cnVlLiBZb3UgY2FuIHVzZSBjbGllbnQNCiBzaWRlIFBL Q0UgZm9yIHZhbGlkYXRpb24gb2YgdGhlc2UgdmlhIG5vdCByZXF1aXJpbmcgdGhlIGNsaWVudCBz ZWNyZXQgaW4gdGhlIGZyb250IGVuZCwgYW5kIHRoZW4gdGhlIHByb2JsZW0gdGhlcmUgaXMgc29s dmVkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gY29uY3Jl dGUgdGVybXMsIHRoaW5ncyBhcmUgYSBiaXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIOKAnGEgZ3Jh bnQgZm9yIFNQQXMgYWxyZWFkeSBleGlzdOKAnS4gSSBhbSB3ZWxsIGF3YXJlIHRoYXQgY29kZStQ S0NFIGlzIGEgdmlhYmxlIHNvbHV0aW9uIGZvciBTUEFzIHRvIGdldCBhY2Nlc3MgdG9rZW5zLCBo b3dldmVyIHRoYXQgaGFzIGl0cyBvd24gY2hhbGxlbmdlcy4gRm9yIGV4YW1wbGUsIGlmIHlvdSB3 YW50DQogdG8gdXNlIHJlZnJlc2ggdG9rZW5zIGluIGl0LCB5b3UgbmVlZCB0byBzZW5kZXIgY29u c3RyYWluIHRoZW0gb3Igc3VwcG9ydCByZWZyZXNoIHRva2VuIHJvdGF0aW9uLiBJZiB5b3UgY2hl Y2sgdGhlIGN1cnJlbnQgc2l0dWF0aW9uIGFjcm9zcyB0aGUgaW5kdXN0cnksIHlvdeKAmWxsIHNl ZSB0aGF0IHZlcnkgZmV3IFNES3MgYWN0dWFsbHkgZG8gc3VwcG9ydCByb3RhdGlvbiBvciBzZW5k ZXIgY29uc3RyYWludCB0b2RheS0gYXJndWFibHkgaW50cm9kdWNpbmcNCiBhIG5ldyBzZWN1cml0 eSBpc3N1ZS4gQW5kIG9mIGNvdXJzZSwgdGhlcmXigJlzIHRoZSBodWdlIGRlYmFjbGUgYWJvdXQg c2F2aW5nIHRva2VucyBpbiBsb2NhbCBzdG9yYWdlLSBzb21ldGhpbmcgdGhhdCBtYW55IGFwcGxp Y2F0aW9ucyBuZWVkIHRvIGRvIGluIG9yZGVyIHRvIG9mZmVyIHRoZSBleHBlcmllbmNlIHRoZWly IGN1c3RvbWVycyByZXF1aXJlLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklmIGEgU1BBIGFwcCBkb2VzIG5vdCBoYXZlIGEgYmFja2VuZCwgY29kZStQS0NFIGlz IHRoZSBvbmx5IGdhbWUgaW4gdG93bi4gSWYgaXQgaGFzIGEgYmFja2VuZCBBTkQgY2FuIGxlYXZl IGFsbCBhY3R1YWwgQVBJIGNhbGxzIHRvIGl0LCB0aGVyZeKAmXMgbm8gbmVlZCB0byBnZXQgdG9r ZW5zIGluIHRoZSB1c2VyIGFnZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnV0IGlmIHlvdSBhcmUgaW4gb25lIHNpdHVhdGlvbiB3aGVyZSB5b3UgZG8gaGF2ZSBhIGJh Y2tlbmQgYW5kIGNhbm5vdCBkZWxlZ2F0ZSBBUEkgY2FsbHMgKHNlZSBteSBwcmVjZWRpbmcgY29t bWVudCksIHRoZW4gVE1JLUJGRiBjYW4gZ2V0IHRva2VucyB0byB5b3VyIGZyb250ZW5kIHdpdGhv dXQgcmVxdWlyaW5nIGNvbXBsZXggamF2YXNjcmlwdCBsb2dpYywgd2l0aG91dCBoYXZpbmcgdG8g cGVyc2lzdCBhbnl0aGluZw0KIGluIGxvY2FsIHN0b3JhZ2UgYW5kIHdpdGhvdXQgcmVxdWlyaW5n IHRoZSBBUyB0byBzdXBwb3J0IHJvdGF0aW9uIG9yIHNlbmRlciBjb25zdHJhaW50LiBBcyBsb25n IGFzIHRoZSB0cmFmZmljIHdpdGggYmZmLXRva2VuIHByb3h5IGlzIGhhcmRlbmVkLCBJIHdvdWxk IGFyZ3VlIFRNSS1CRkYgbWlnaHQgYWN0dWFsbHkgYmUgZWFzaWVyIHRvIGltcGxlbWVudCBzZWN1 cmVseSB0aGF0IGNvZGUrUEtDRStyb3RhdGlvbi9TQy4gSGF2aW5nIGFjY2Vzcw0KIHRva2VucyBp biB0aGUgZnJvbnRlbmQgcmVtYWlucyBub3QgZ3JlYXQsIGJ1dCBpdCBzZWVtcyB0aGF0IGdpdmlu ZyBwZW9wbGUgd2hvIHdvdWxkIGRvIGl0IGFueXdheSBzb21lIGd1aWRhbmNlIGlzIGJldHRlciB0 aGFuIGxlYXZpbmcgdGhlbSBhdCB0aGVpciBvd24gZGV2aWNlLSB1bmxlc3Mgd2UgY29uY2x1ZGUg dGhhdCB0aGlzIGZsb3cgY2Fubm90IGJlIHNlY3VyZWQsIGluIHdoaWNoIGNhc2UgSSBhZ3JlZSB3 ZSBzaG91bGQgZXhwbGljaXRseQ0KIGlkbmNpYXRlIHRoaXMgYXMgYW50aSBwYXR0ZXJuLiBCdXQg c28gZmFyLCBpdCBzZWVtcyBzdGlsbCB0byBiZSBkZW1vc250cmF0ZWQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5UaGVyZSB3 YXMgYWxzbyB0aGUgYXJndW1lbnQgb2YNCjxiPnRoZXJlIGFyZSBsb3RzIG9mIHBlb3BsZSBkb2lu ZyB0aGlzPC9iPiwgd2hpY2ggaXMgYWx3YXlzIGEgdGVycmlibGUgYXJndW1lbnQsIGJ1dCBldmVu IGlmIHdlIGRvIHBlcm1pdCB0aGF0IGluIHRoZSBkaXNjdXNzaW9uLCB3ZSBzdGlsbCBuZWVkIHRv IGFuc3dlciB0aGUNCjxiPndoeS4gPC9iPldoeSBhcmUgZGV2ZWxvcGVycyBjcmVhdGluZyBCRkYg Zm9yIHRoZWlyIGZyb250ZW5kcyB0byBjb21tdW5pY2F0ZSB3aXRoIGFuIEFTLiBJcyBpdCBiZWNh dXNlIEFTIGFyZSB0ZXJyaWJsZSwgaXMgaXQgYmVjYXVzZQ0KPGI+ZnJvbnQgZW5kcyBhcyBhIHNl cnZpY2U8L2I+Jm5ic3A7YXJlIHRlcnJpYmxlLCBldGMuLi4gVW50aWwgd2Uga25vdyB3aHkgdGhp cyBpcyBoYXBwZW5pbmcgY29uY3JldGVseSwgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgZW5jb3Vy YWdlIGZ1cnRoZXIgdXNlIG9mIGEgcGF0dGVybiByaWZlIHdpdGggcG90ZW50aWFsIHNlY3VyaXR5 IHJpc2tzIGJ5IHRlbGxpbmcgZXZlcnlvbmUgaG93IHlvdSBjYW4gZG8gaXQgKGJlY2F1c2UgdGhl IGd1aWRhbmNlIHdlDQogYXJlJm5ic3A7b2ZmZXJpbmcgZG9lc24ndCBldmVuIHNsaWdodGx5IGlu Y3JlYXNlIHNhZmV0eSkuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgcHJlY2VkaW5nIGNvbW1lbnRzIHNob3VsZCBoYXZlIHNoZWQgbW9yZSBsaWdodCBhYm91 dCB0aGUgd2h5LCBhbmQgb24gc29tZSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgKHRoZXJlIHdh cyBvbmUgY29uY2VybiByYWlzZWQgYnkgTmVpbCwgYW5kIGl0IHNlZW1zIHRoZXJlIGFyZSBwb3Nz aWJsZSBtaXRpZ2F0aW9ucyBpbiBwbGFjZSkgcGx1cyBob3cgdGhpcyBtaWdodCBhY3R1YWxseSBp bmNyZWFzZSBzYWZldHkNCiBpbiBzb21lIGFzcGVjdHMuIEJ1dCB0byBhZGQgbW9yZSBjb2xvciwg b25lIG9mIHRoZSBvdGhlciByZWFzb25zIGZvciB3aGljaCB0aGlzIGlzIGhhcHBlbmluZyBpcyBi ZWNhdXNlIGl04oCZcyBzaW1wbGUuIEJhY2tlbmQgT0FVdGgvT0lEQyBTREtzIGxpa2UgbWlkZGxl d2FyZXMgYW5kIHNpbWlsYXIgYXJlIHZlcnkgbWF0dXJlIGF0IHRoaXMgcG9pbnQsIGFuZCB0aGV5 IGFyZW7igJl0IHNhZGRsZWQgYnkgYSBsb3Qgb2YgdGhlIGNvbXBsZXhpdHkgYW5kDQogdW5jZXJ0 YWlubHkgdGhhdCBicm93c2VyIGJhc2VkIFNES3MgY2FycnkuIFRoaW5ncyBsaWtlIElFIHpvbmVz LCBJVFAsIFNhbWVTaXRlIGFuZCBvdXIgb3duIGNoYW5naW5nIGd1aWRhbmNlIChmb3IgZ29vZCBy ZWFzb25zKSBwbHVzIGRpc29tb2dlbmVvdXMgc3VwcG9ydCBmcm9tIHByb3ZpZGVycyBvZiB0aGUg ZmVhdHVyZXMgcmVxdWlyZWQgZm9yIHRoZSBsYXRlc3QgZ3VpZGFuY2UgY3JlYXRlIHVuY2VydGFp bnR5IGFuZCBjb21wbGV4aXR5IHRoYXQNCiBtYW55IG5vbi1pbml0aWF0ZWQgd29u4oCZdCBwdXQg dXAgd2l0aC4gQWRkIHRvIHRoaXMgdGhhdCB0aGUgbW9yZSBhcHAgZGV2ZWxvcG1lbnQgbW92ZXMg dG8gdGhlIGZyb250ZW5kLCB0aGUgbW9yZSB5b3UgZG9u4oCZdCBnZXQgZnVsbCBzdGFjayBkZXZl bG9wZXJzIGFuZCBnZXR0aW5nIGEgZnJvbnRlbmQgZGV2ZWxvcGVyIHRvIGRlYWwgd2l0aCBhbGwg dGhvc2UgcXVpcmtzIGlzIGhhcmQuIEdldHRpbmcgdG9rZW5zIHRocnUgd2VsbCBzdXBwb3J0ZWQg bWlkZGxld2FyZXMNCiBhbmQgZm9yd2FyZCB0aGVtIHRvIHRoZSBmcm9udGVuZCBpcyBzaW1wbGUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB0byBiZSBjbGVhci4g VGhpcyBleGFjdCB0b3BvbG9neSBoYXMgYmVlbiBjb25zaWRlcmVkIGRpc2N1c3NlZCBpbiB0aGUg cGFzdCBkdXJpbmcgSUVURiBtZWV0aW5ncywgaW4gTW9udHJlYWwgd2UgaGFkIGEgZGlzY3Vzc2lv biBhYm91dCBpbmNsdWRpbmcgaXQgaW4gc29tZSBCQ1AgYW5kIHdoZXRoZXIgd2Ugc2hvdWxkIGhh dmUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8gc2lnbmFsIHRvIHRoZQ0KIEFTIHRoYXQg dGhlIHRva2VucyB3aWxsIGJlIHVzZWQgYnkgY29kZSBleGVjdXRpbmcgaW4gYSB3ZWFrZXIgc2Vj dXJpdHkgY29udGV4dCAodXNlciBhZ2VudCkgdGhhbiB0aGUgcmVxdWVzdG9y4oCZcyAoY29uZmlk ZW50aWFsIGNsaWVudCBvbiBiYWNrZWQpLiBJIGFtIHN1cmUgd2UgY2FuIGZpbmQgdGhlIG1pbnV0 ZXMgb2YgdGhhdC4gVGhpcyBpc27igJl0IHNvbWV0aGluZyBjb21wbGV0ZWx5IGxlZnQgZmllbGQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj5GdXJ0aGVyLCBldmVuIGlmIHdlIHdlcmUgdG8gYWNjZXB0IHRoaXMgcGF0dGVybiBh bmQgd2FudCB0byBjcmVhdGUgYSBzdGFuZGFyZCBhcm91bmQgaXQsIHdlIGFyZSBlZmZlY3RpdmVs eSBjcmVhdGluZyBhbiBBUyBwcm94eSBoZXJlLCB3aGljaCBtZWFucyB3ZSBzaG91bGQgcmVxdWly ZSBpdCB0byBhY3QgbGlrZQ0KIGFuIEFTLCBhbmQgZGVsZWdhdGUgdGhlIHNwZWNpZmljYXRpb24g b2YgcmVzb3VyY2VzLCBlbmRwb2ludHMsIHRlcm1pbm9sb2d5LCBhbmQgcGF0dGVybnMgdG8gZXhp c3Rpbmcgb3IgZnV0dXJlIEFTIHJlbGF0ZWQgUkZDcy4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IGJlbGlldmUgdGhhdCB0aGUgc2NvcGUgb2Yg dGhlIHByb3Bvc2FsIHdhcnJhbnRzIGRvaW5nIGFsIHRoYXQuIENvdWxkIHlvdSBwb2ludCBhdCB0 aGUgYXJlYSBpbiB0aGUgc3BlYyB0aGF0IHN1Z2dlc3Qgd2XigJlkIG5lZWQgdG8gYWRkIGFueXRo aW5nIGJleW9uZCB3aGF04oCZcyBzdWdnZXN0ZWQgYXQgdGhlIG1vbWVudCB0byBhY2hpZXZlIHRo ZSBzdGF0ZWQgZ29hbHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj5BbmQgdGhlcmVmb3JlIGluIGNvbmNsdXNpb24gd2Ugc2hv dWxkIGZvY3VzIG9ubHkgb24gdGhlIGFzcGVjdHMgdGhhdCBhcmUgYWJzb2x1dGVseSByZXF1aXJl ZCB3aGljaCBhcmVuJ3QgYWxyZWFkeSBwcmVzZW50IGluIHNvbWUgZm9ybSBpbiBleGlzdGluZyBB UyByZWxhdGVkIFJGQ3MsIGJ1dCB3aGF0IGFyZSB0aG9zZT88bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gc3RpbGwgbWlzc2luZyBob3cgdGhpcyBoYXMgdG8g ZG8gd2l0aCBtaXNzaW5nIEFTIGZ1bmN0aW9uYWxpdHkuIE9uZSBvZiB0aGUgdGhpbmdzIHdlIHRy aWVkIHRvIGRvIHdhcyBub3QgdG8gcmVxdWlyZSBhbnkgY2hhbmdlIHRvIHRoZSBBUy4gVGhlIHBy b2JsZW0gYmVpbmcgc29sdmVkIGhlcmUgaXMgaG93IHRvIGFsbG93IGphdmFzY3JpcHQgZGV2ZWxv cGVycyB0byBjYWxsIEFQSSBkaXJlY3RseSBmcm9tDQogdGhlaXIgZnJvbnRlbmQgd2hlbiB0aGV5 IGhhdmUgYSBiYWNrZW5kIHdpdGggYmFzaWMgb2F1dGggY2FwYWJpbGl0aWVzIGF0IHRoZWlyIGRp c3Bvc2FsLCBpbiB0aGUgc2ltcGxlc3QgcG9zc2libGUgd2F5LiBDaGFuZ2VzIGluIHRoZSBBUyBk b2Vu4oCZdCBhcHBlYXIgdG8gYmUgbmVjZXNzYXJ5IHRoZXJlICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+VGhlIG9uZSBjb3VudGVycG9pbnQmbmJzcDt0byBhbGwgb2YgdGhpcyBpcyB0 aGUgcG90ZW50aWFsIGludHJvZHVjdGlvbiBvZiBkb21haW4gc3BlY2lmaWMNCjxiPmNvb2tpZTwv Yj4gbGFuZ3VhZ2UgKHdoaWNoIGRvZXNuJ3QgZXhpc3QgaW4gdGhlIGN1cnJlbnQgZHJhZnQpLiBD b25jcmV0ZWx5LCA8Yj4NCmxldCdzIGFkZCBhIHJlc3BvbnNlX3R5cGU9Y29va2llPC9iPiwgdG8g QVMgdG8gc3VwcG9ydCBkb21haW4gZmlyc3QtcGFydHkgY29va2llcyBhbmQgc2Vzc2lvbiBtYW5h Z2VtZW50LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q291bGQg eW91IGV4cGFuZCBvbiBob3cgeW91IGVudmlzaW9uIHRoaXMgd291bGQgd29yay9zb2x2ZSB0aGUg cHJvYmxlbXMgZGVzY3JpYmVkIGFib3ZlPw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PldhcnJlbiBQYXJhZCAmbHQ7d3BhcmFkPTQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAxOjUxPGJyPg0K PGI+VG86IDwvYj5OZWlsIE1hZGRlbiAmbHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPlZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaUBh dXRoMC5jb20mZ3Q7LCBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1h dGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBmbGF0IG91dCBy ZWplY3QgdGhlIHByZW1pc2Ugb2YgdGhpcyBkcmFmdC4gSXQgaW50cm9kdWNlcyBhIHBzZXVkbyBB Uy1saWtlIHByb3h5IHdoaWNoIG5vdyBoYXMgYWxsIHRoZSByZXF1aXJlbWVudHMgb2YgYW4gQVMg YW5kIG1vcmUuIFdoaWxlIEFTIFNES3MgcHJvdmlkZSBlYXN5IHdheXMgZm9yIGNsaWVudCBVSXMg dG8gZWZmZWN0aXZlbHkgZGVhbCB3aXRoIGNvbW11bmljYXRpb24gdmlhIHRoZSBBUywNCiB0aGVy ZSdzIG5vIHdheSBmb3IgdGhlIEFTIHRvIHByb3ZpZGUgc3RhbmRhcmQgQVMgc3BlY2lmaWMgc2Vy dmljZXMgcHJvdG90eXBlcyB0byBzdXBwb3J0IEJGRi4gVGhhdCBtZWFucyB0aGF0IGV2ZXJ5b25l IGlzIHdyaXRpbmcgdGhlaXIgb3duIEJGRiBBUy1wcm94eS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGl0aW9uYWxseSwgSSB0b28gYW0gbGFja2luZyB0 aGUgY2xhcml0eSBvbiB0aGUgPGI+V0hZPC9iPi4gVGhlIG9ubHkgdGhpbmcgbWVudGlvbmVkIGlu IHRoZSBkcmFmdCBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgYXBwcm9hY2ggaXMgbm90IGFsd2F5cyB2aWFibGUs IGFzIGluIHRoZSBhYnNlbmNlIG9mIHJldmVyc2UgcHJveHkgZGVwbG95bWVudHMgdGhlIGNyZWF0 aW9uIGFuZCBtYWludGVuYW5jZSBvZiBhIGZhY2FkZSBmb3IgbXVsdGlwbGUgQVBJcyBjYW4gYmUg ZXhwZW5zaXZlPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2hpY2ggaXNuJ3QgZXZlciBqdXN0aWZpZWQsIGJ1dCBldmVuIGlmIHdlIGFj Y2VwdCB0aGF0IGFzIGEgdHJ1ZSBwcmVtaXNlLCB3aGF0IGFyZSB0aGVzZSBBUyBkb2luZyB0aGF0 IGV2ZW4gcmVxdWlyZSBhIEJGRj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SHlwb3RoZXRpY2FsbHkgeW91IGNvdWxkIGFyZ3VlIHRoYXQgdGhl IGF1dGggY29kZSBmbG93IHJlcXVpcmVzIGEgQkZGIGFuZCB0aGF0J3MgcmVxdWlyZWQgZm9yIHVz ZXIgbG9naW4gc2luY2UgaW1wbGljaXQmbmJzcDtmbG93IG5vIGxvbmdlciBleGlzdHMsIGJ1dCB0 aGF0IGlzbid0IHRydWUuIFlvdSBjYW4gdXNlIGNsaWVudCBzaWRlIFBLQ0UgZm9yIHZhbGlkYXRp b24gb2YgdGhlc2UgdmlhIG5vdCByZXF1aXJpbmcgdGhlDQogY2xpZW50IHNlY3JldCBpbiB0aGUg ZnJvbnQgZW5kLCBhbmQgdGhlbiB0aGUgcHJvYmxlbSB0aGVyZSBpcyBzb2x2ZWQuIEFuZCBpZiB5 b3UgYXJndWUgdGhhdCB0aGlzIGNhbid0IGJlIGRvbmUsIHRoZW4gdGhlIHNvbHV0aW9uIGlzIGlu dHJvZHVjaW5nIGEgYmV0dGVyIHdheSB0byBoYW5kbGUgdGhpcyBzbyB0aGF0IGEgQkZGIGZvciBB UyBmbG93cyBkb24ndCBoYXZlIHRvIGV4aXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3aGF0IGNvbmNyZXRlIHByb2JsZW0gaXMgdGhp cyBzb2x2aW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGVyZSB3YXMgYWxzbyB0aGUgYXJndW1lbnQgb2YgPGI+dGhlcmUgYXJlIGxvdHMg b2YgcGVvcGxlIGRvaW5nIHRoaXM8L2I+LCB3aGljaCBpcyBhbHdheXMgYSB0ZXJyaWJsZSBhcmd1 bWVudCwgYnV0IGV2ZW4gaWYgd2UgZG8gcGVybWl0IHRoYXQgaW4gdGhlIGRpc2N1c3Npb24sIHdl IHN0aWxsIG5lZWQgdG8gYW5zd2VyIHRoZQ0KPGI+d2h5LiA8L2I+V2h5IGFyZSBkZXZlbG9wZXJz IGNyZWF0aW5nIEJGRiBmb3IgdGhlaXIgZnJvbnRlbmRzIHRvIGNvbW11bmljYXRlIHdpdGggYW4g QVMuIElzIGl0IGJlY2F1c2UgQVMgYXJlIHRlcnJpYmxlLCBpcyBpdCBiZWNhdXNlDQo8Yj5mcm9u dCBlbmRzIGFzIGEgc2VydmljZTwvYj4mbmJzcDthcmUgdGVycmlibGUsIGV0Yy4uLiBVbnRpbCB3 ZSBrbm93IHdoeSB0aGlzIGlzIGhhcHBlbmluZyBjb25jcmV0ZWx5LCBJIGRvbid0IHRoaW5rIHdl IHNob3VsZCBlbmNvdXJhZ2UgZnVydGhlciB1c2Ugb2YgYSBwYXR0ZXJuIHJpZmUgd2l0aCBwb3Rl bnRpYWwgc2VjdXJpdHkgcmlza3MgYnkgdGVsbGluZyBldmVyeW9uZSBob3cgeW91IGNhbiBkbyBp dCAoYmVjYXVzZSB0aGUgZ3VpZGFuY2Ugd2UNCiBhcmUmbmJzcDtvZmZlcmluZyBkb2Vzbid0IGV2 ZW4gc2xpZ2h0bHkgaW5jcmVhc2Ugc2FmZXR5KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnVydGhlciwgZXZlbiBpZiB3ZSB3ZXJlIHRvIGFj Y2VwdCB0aGlzIHBhdHRlcm4gYW5kIHdhbnQgdG8gY3JlYXRlIGEgc3RhbmRhcmQgYXJvdW5kIGl0 LCB3ZSBhcmUgZWZmZWN0aXZlbHkgY3JlYXRpbmcgYW4gQVMgcHJveHkgaGVyZSwgd2hpY2ggbWVh bnMgd2Ugc2hvdWxkIHJlcXVpcmUgaXQgdG8gYWN0IGxpa2UgYW4gQVMsIGFuZCBkZWxlZ2F0ZSB0 aGUgc3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZXMsIGVuZHBvaW50cywNCiB0ZXJtaW5vbG9neSwg YW5kIHBhdHRlcm5zIHRvIGV4aXN0aW5nIG9yIGZ1dHVyZSBBUyByZWxhdGVkIFJGQ3MuIChXZSBh bHJlYWR5IGhhdmUgYSBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgZHJhZnQgYXMgaXQgYXR0ZW1w dHMgdG8gcmVkZWZpbmUgYW5kIGludHJvZHVjZSBuZXcgdGVybXMvcGF0dGVybnMgdGhhdCBoYXZl IHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgYXMgZXhpc3Rpbmcgb25lcyBpbiB0aGUgQVMsIHlldCBm YWlsIHRvIGNhcHR1cmUNCiB0aGUgZnVsbCBpbXBvcnRhbmNlIG9mIHRoZSBvcmlnaW5hbCBSRkNz LiBUaGlzIGlzIGJhZCBkdXBsaWNhdGlvbikuIEFuZCB0aGVyZWZvcmUgaW4gY29uY2x1c2lvbiB3 ZSBzaG91bGQgZm9jdXMgb25seSBvbiB0aGUgYXNwZWN0cyB0aGF0IGFyZSBhYnNvbHV0ZWx5IHJl cXVpcmVkIHdoaWNoIGFyZW4ndCBhbHJlYWR5IHByZXNlbnQgaW4gc29tZSBmb3JtIGluIGV4aXN0 aW5nIEFTIHJlbGF0ZWQgUkZDcywgYnV0IHdoYXQgYXJlIHRob3NlPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25lIGNvdW50ZXJwb2lu dCZuYnNwO3RvIGFsbCBvZiB0aGlzIGlzIHRoZSBwb3RlbnRpYWwgaW50cm9kdWN0aW9uIG9mIGRv bWFpbiBzcGVjaWZpYw0KPGI+Y29va2llPC9iPiBsYW5ndWFnZSAod2hpY2ggZG9lc24ndCBleGlz dCBpbiB0aGUgY3VycmVudCBkcmFmdCkuIENvbmNyZXRlbHksIDxiPg0KbGV0J3MgYWRkIGEgcmVz cG9uc2VfdHlwZT1jb29raWU8L2I+LCB0byBBUyB0byBzdXBwb3J0IGRvbWFpbiBmaXJzdC1wYXJ0 eSBjb29raWVzIGFuZCBzZXNzaW9uIG1hbmFnZW1lbnQuIFdoZW4gd2UgYnVpbHQgb3VyIEFTIHdl IGV4cGxpY2l0bHkgYWRkZWQgdGhpcyBzbyB0aGF0IHNlcnZpY2VzIGNhbiB1c2UgdGhlIEpXVCBm b3VuZCBpbiB0aGUgSHR0cE9ubHkgU2FtZVNpdGU9U3RyaWN0IGNvb2tpZSBhcyBhIHNlY3VyaXR5 IG1lYXN1cmUgYWdhaW5zdA0KIFhTUyBhdHRhY2tzIHRoYXQgYXR0ZW1wdCB0byBleGZpbHRyYXRl Jm5ic3A7YWNjZXNzIHRva2Vucy4gVGhhdCdzIGEgcG90ZW50aWFsIHN1Z2dlc3Rpb24gSSB3b3Vs ZCBmYXZvciwgYWx0aG91Z2ggSSBzdGlsbCBjYW4ndCBrbm93IGlmIHRoYXQgc29sdmVzIHRoZSBw cm9ibGVtIGJlaW5nIHByZXNlbnRlZCBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gV2FycmVuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHls ZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93Omhp ZGRlbiI+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNv bGlkIHdoaXRlIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+PGltZyB3aWR0 aD0iMTk5IiBoZWlnaHQ9IjM0IiBzdHlsZT0id2lkdGg6Mi4wNzI5aW47aGVpZ2h0Oi4zNTQxaW4i IGlkPSJfeDAwMDBfaTEwMjUiIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIiBkYXRhLW91 dGxvb2stdHJhY2U9IkY6MHxUOjEiIHNyYz0iY2lkOn5XUkQwMDAuanBnIj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6 c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUu MHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJh LWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1ib3R0b206bm9uZTtw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XYXJyZW4gUGFyYWQ8L3NwYW4+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJh LWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRk aW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZvdW5kZXIs IENUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOndoaXRlIj5TZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlv dXIgYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCZuYnNwOzwvc3Bhbj48YSBo cmVmPSJodHRwczovL2F1dGhyZXNzLmlvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPkF1dGhyZXNzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgRmViIDE0LCAyMDIxIGF0 IDk6MTggQU0gTmVpbCBNYWRkZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3Jn ZXJvY2suY29tIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGxvdCBvZiBzZWN1cml0eSBj b25jZXJucyBhYm91dCB0aGlzIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgYWxsdWRlcyB0byBzZWN1cml0 eSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGhhbmRsaW5nIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGZy b250ZW5kIGJ1dCBuZXZlciByZWFsbHkgc3BlbGxzIHRoZW0gb3V0LiAmZ3Q7RnJvbSB0aGUgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgaXQgc2VlbXMgdGhhdCB0aGUgcHJpbWFyeSBjb25jZXJuIGlz IHdpdGggdGhlZnQgb2YgYWNjZXNzIHRva2VucyBmcm9tIGxvY2FsDQogc3RvcmFnZS4gVG8gZG8g dGhpcyB5b3XigJlkIG5lZWQgYW4gWFNTIGF0dGFjay4gQnV0IGluIHRoYXQgY2FzZSwgd291bGRu 4oCZdCB0aGUgYXR0YWNrZXIgc2ltcGx5IHVzZSB0aGUgWFNTIHRvIG1ha2UgYSBjYWxsIHRvIHRo ZSBiZmYtdG9rZW4gZW5kcG9pbnQgaW5zdGVhZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBi ZmYtdG9rZW4gZW5kcG9pbnQgcmVjb21tZW5kaW5nIHRoZSB1c2Ugb2YgR0VUIHJlcXVlc3RzIHRv Z2V0aGVyIHdpdGggdGhlIGhpbnQgdG8gdXNlIGNvb2tpZS1iYXNlZCBhdXRoZW50aWNhdGlvbiBp cyBsaWtlbHkgZ29pbmcgdG8gcHVuY2ggYSBob2xlIGluIG1vc3QgQ1NSRiBkZWZlbnNlcywgd2hp Y2ggYXNzdW1lIHRoYXQgR0VUcyBhcmUgc2FmZS4gVGhlIG9ubHkgdGhpbmcNCiBwcmV2ZW50aW5n IHRoaXMgYmVpbmcgZXhwbG9pdGFibGUgaXMgQ3Jvc3MtT3JpZ2luIFJlYWQgQmxvY2tpbmcgKDxh IGhyZWY9Imh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9t YXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19vcmlnaW5fcmVhZF9ibG9ja2luZ19leHBsYWlu ZXIubWQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Nocm9taXVtLmdvb2dsZXNvdXJjZS5jb20v Y2hyb21pdW0vc3JjLysvbWFzdGVyL3NlcnZpY2VzL25ldHdvcmsvY3Jvc3Nfb3JpZ2luX3JlYWRf YmxvY2tpbmdfZXhwbGFpbmVyLm1kPC9hPikNCiBkdWUgdG8gdGhlIEpTT04gY29udGVudC10eXBl LiBUaGF0IG1ha2VzIG1lIHJlYWxseSBuZXJ2b3VzLiBXZSBzaG91bGQgYXQgbGVhc3QgbWFuZGF0 ZSBYLUNvbnRlbnQtVHlwZS1PcHRpb25zOiBub3NuaWZmIG9uIHRoYXQgcmVzcG9uc2UuIEnigJlk IGZlZWwgbW9yZSBjb21mb3J0YWJsZSBpZiB0aGlzIHdhcyBhIFBPU1QgcmVxdWVzdCBvbmx5LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BcyBTdG95Y2hvIFNsZXB0c292IG1lbnRpb25lZCBpbiB0aGUgb3RoZXIgZW1haWwsIHRoZSBs YWNrIG9mIGZyb250LWNoYW5uZWwgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhl IFJPIHNlZW1zIG9kZC4gSWYgdGhlIGJhY2tlbmQgaXMgYWxyZWFkeSBpbXBsaWNpdGx5IHRydXN0 ZWQgdGhlbiBjb3VsZG7igJl0IHlvdSBza2lwIE9BdXRoIGFuZCBqdXN0IGdldCB0aGUgYmFja2Vu ZCB0byBpc3N1ZSBzaG9ydC1saXZlZA0KIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2Fu IHVzZSBmb3IgQVBJIGFjY2Vzcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cgZXRj IHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFuZGFy ZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0aGUg U1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRvIGEg UEFSIHJlcXVlc3QgZmlyc3QgYW5kIHJldHVybg0KIGEgVVJJIHRoYXQgcmVmZXJlbmNlcyB0aGF0 IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7igJl0IHBhc3NlZCB0aHJvdWdoIHRo ZSBmcm9udGVuZCkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPuKAlCBOZWlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDEyIEZlYiAy MDIxLCBhdCAyMDo0NiwgVml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTxh IGhyZWY9Im1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPu+7 v0RlYXIgYWxsLDxicj4NCkJyaWFuIGFuZCB5b3VycyB0cnVseSBhcmUgcHJvcG9zaW5nIGEgbmV3 IHNwZWNpZmljYXRpb24gdGhhdCBzaG93cyBob3cgdGhlIHVzZXIgYWdlbnQgZnJvbnRlbmQgb2Yg YSB3ZWIgYXBwIGNhbiBkZWxlZ2F0ZSB0b2tlbiBhY3F1aXNpdGlvbiBhbmQgcGVyc2lzdGVuY2Ug dG8gaXRzIGJhY2tlbmQsIGFuZCByZXF1ZXN0IHN1Y2ggdG9rZW5zIHdoZW4gbmVlZGVkIGZvciBk aXJlY3QgYWNjZXNzIG9mIHByb3RlY3RlZCByZXNvdXJjZXMgZnJvbSB0aGUNCiBmcm9udGVuZCBj b2RlLjxicj4NCjxicj4NClRoZSBwYXR0ZXJuIGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmll dGFyeSBmb3JtLCBieSB2YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMg TmV4dC5KUy4gVmFyaWFudHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0 aGUgY2F0Y2gtYWxsIHRlcm0gQkZGIChiYWNrZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBv ZnRlbiBtZW50aW9uZWQgaW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFjdGl2aXR5LA0KIGJ1dCBhbHdh eXMgbGVmdCBhbGwgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byB0aGUgcmVhZGVyLjxicj4NCldl IGJlbGlldmUgdGhlIHBhdHRlcm4gaGFzIG1lcml0LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdy b3dpbmcgYWRvcHRpb24uIEJ5IGRlbGVnYXRpbmcgYWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRv IHRoZSBiYWNrZW5kLCB3ZSBhdm9pZCBtYW55IG9mIHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBw YXJ0cyAoYW5kIGltcGxpZWQgYXR0YWNrIHN1cmZhY2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNj ZXNzIHRva2VucyBmcm9tIGEgdXNlciBhZ2VudC4NCiBUaGUgdG9wb2xvZ3kgYWxzbyByZWxpZXZl cyB0aGUgZnJvbnRlbmQgZnJvbSB0aGUgbmVlZCBvZiBwZXJzaXN0aW5nIHRva2VucyBpbiBsb2Nh bCBzdG9yYWdlLCBhIHdlbGwga25vd24gc29yZSBwb2ludCBvZiB1c2luZyBPQXV0aCBkaXJlY3Rs eSBpbiBKYXZhU2NyaXB0LCBieSByZWx5aW5nIG9uIGl0cyBiYWNrZW5kIHN0b3JhZ2UgYW5kIHNl c3Npb24gdG8gcHJlc2VydmUgdG9rZW5zLjxicj4NCjxicj4NCkFsdGhvdWdoIHRoZSBzcGVjaWZp Y2F0aW9uIGlzIHZlcnkgc2ltcGxlLCBwcm92aWRpbmcgZXhwbGljaXQgZ3VpZGFuY2Ugb24gdGhl IHNjZW5hcmlvIG9mZmVycyBtYW55IGFkdmFudGFnZXMuICZuYnNwOzxicj4NCi0gSXQgbWFrZXMg aXQgcG9zc2libGUgdG8gY3JlYXRlIGludGVyb3BlcmFibGUgU0RLcywgd2hlcmUgZnJvbnRlbmQg ZGV2IHN0YWNrcyAoYW55IEpTIGZsYXZvcikgY2FuIGJlIG1peGVkIGFuZCBtYXRjaGVkIHdpdGgg Y29tcGxpYW50IGJhY2tlbmQgc3RhY2tzIChtaWRkbGV3YXJlcyBpbiBub2RlLCBqYXZhLA0KPGEg aHJlZj0iaHR0cDovL0FTUC5ORVQiIHRhcmdldD0iX2JsYW5rIj5BU1AuTkVUPC9hPiwgUEhQIGV0 Yyk8YnI+DQotIEl0IGFsbG93cyB1cyB0byBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9w ZXJseSB0YWNrbGUgdGhlIHNjZW5hcmlvIGFuZCB3YXJuIGltcGxlbWVudGVycyBhZ2FpbnN0IHNl Y3VyaXR5IHJpc2tzIChzY29wZSBlc2NhbGF0aW9ucywgdXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBv ZiBhY2Nlc3MgdG9rZW5zLCBldGMpPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8gZGlzY3VzcyAoYW5k IHdoZW4gYXBwcm9wcmlhdGUsIHByb21vdGUpIHRoaXMgcGF0dGVybiBhcyBwYXJ0IG9mIHRoZSBi cm93c2VyIGFwcHMgc2VjdXJpdHkgZ3VpZGFuY2UsIGFuZCBwb3NpdGlvbiB0aGUgc2NlbmFyaW8g d2hlcmUgZnJvbnRlbmQgb25seSBjYWxscyBBUEkgb24gaXRzIG93biBiYWNrZWQgKGhlbmNlIGRv ZXNu4oCZdCBuZWVkIGFjY2VzcyB0b2tlbnMpIHNpbXBseSBhcyBhIHNwZWNpYWwgY2FzZSBvZiB0 aGlzDQogbW9yZSBnZW5lcmFsIHBhdHRlcm48YnI+DQotIFRoaXMgYXBwcm9hY2ggbWFrZXMgbW9j a2luZyBhbmQgdGVzdGluZyBhcHBzIHZlcnkgZWFzeSwgcG9zc2libHkgcHJldmVudGluZyBkZXZl bG9wZXJzIGZyb20gd2Vha2VuaW5nIHRoZSBzZWN1cml0eSBvZiB0aGVpciBzeXN0ZW0gKGVnIHR1 cm5pbmcgb24gUk9QRyBvcHRpb25zKSAmbmJzcDtvciB0dXJuaW5nIHRvIHJpc2t5IHByYWN0aWNl cyBsaWtlIHNjcmFwaW5nPGJyPg0KPGJyPg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlzIHNwZWNpZmlj YXRpb24gZG9lc27igJl0IGVudGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlza3MgaW5oZXJlbnQgdG8g ZGlyZWN0IHVzZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gYSBicm93c2VyLiBCdXQgcmVhbGl0eSBp cyB0aGF0IHRoZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhlIGNpcmN1bXN0 YW5jZXMgbGVhZGluZyB0byB0aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEgcGFydGljdWxhciBwcm9q ZWN0DQogb25seSB3b3JrIHdpdGggZnJvbnRlbmQgc3RhY2tzOyBjb21wb25lbnRzIGxpa2UgcmV2 ZXJzZSBwcm94aWVzIG1pZ2h0IG5vdCBhbHdheXMgYmUgdmlhYmxlOyBldGMpIGFyZW7igJl0IGdv aW5nIGF3YXkgYW55IHRpbWUgc29vbi4gQnkgcHJvdmlkaW5nIHNpbXBsZSBndWlkYW5jZSBvbiB0 aGlzIHBhdHRlcm4sIHdlIGNhbiBzaW1wbGlmeSB0aGUgbGlmZSBvZiBtYW55IGRldmVsb3BlcnMg d2hpbGUgZW5zaHJpbmluZyBiYXNpYyBzZWN1cml0eSBoeWdpZW5lDQogaW4gc2NlbmFyaW9zIHRo YXQgd291bGQgaGF2ZSBvdGhlcndpc2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLjxicj4N Cjxicj4NCkxvb2tpbmcgZm9yd2FyZCBmb3IgeW91ciBmZWVkYmFjayE8YnI+DQo8YnI+DQpCJmFt cDtWICZuYnNwOzxicj4NCjxicj4NCu+7v09uIDIvMTIvMjEsIDEyOjQxLCAmcXVvdDs8YSBocmVm PSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0EgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQ8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDtoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZp dHRvcmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 SUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO05hbWU6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7UmV2aXNpb246ICZuYnNwOyAmbmJzcDswMDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwO1RpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUb2tlbiBNZWRpYXRp bmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQ8YnI+DQombmJz cDsmbmJzcDsmbmJzcDtEb2N1bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7MjAyMS0wMi0xMjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwO0dyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQombmJzcDsmbmJzcDsmbmJzcDtQYWdlczogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7MTY8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtVUkw6ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2kt b2F1dGgyLXRtaS1iZmYtMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQ8L2E+PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi8iIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJm Zi88L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SHRtbDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC5o dG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC5odG1sPC9hPjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwO0h0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1i ZmYtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7QWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4g ZGVsZWdhdGUgYWNjZXNzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 dG9rZW4gYWNxdWlzaXRpb24gdG8gYSBiYWNrZW5kIGNvbXBvbmVudC4mbmJzcDsgSW4gc28gZG9p bmcsIHRoZSBmcm9udGVuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2NhbiBhY2Nlc3MgcmVzb3VyY2Ugc2VydmVycyBkaXJlY3RseSB3aXRob3V0IHRha2luZyBvbiB0 aGUgYnVyZGVuIG9mPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29t bXVuaWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0b2tl bnMsIGFuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BlcmZvcm1p bmcgb3BlcmF0aW9ucyB0aGF0IGFyZSBmcmF1Z2h0IHdpdGggc2VjdXJpdHkgY2hhbGxlbmdlcyB3 aGVuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXhlY3V0ZWQgaW4g YSB1c2VyIGFnZW50LCBidXQgYXJlIHNhZmUgYW5kIHdlbGwgcHJvdmVuIHdoZW4gZXhlY3V0ZWQ8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtieSBhIGNvbmZpZGVudGlh bCBjbGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwO3VudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29s cy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIElFVEYgU2Vj cmV0YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6IzE3MkI0RDtiYWNrZ3JvdW5kOndoaXRl Ij5Gb3JnZVJvY2sgdmFsdWVzIHlvdXINCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmZvcmdlcm9jay5j b20veW91ci1wcml2YWN5IiB0YXJnZXQ9Il9ibGFuayI+UHJpdmFjeTwvYT48L3NwYW4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO6PR18MB405236B3F50E3A5C42B82C39AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 04:33:05 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F493A091F for ; Sun, 14 Feb 2021 04:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cepz_BpHND7u for ; Sun, 14 Feb 2021 04:33:00 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3833A0922 for ; Sun, 14 Feb 2021 04:33:00 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id d26so2539380pfn.5 for ; Sun, 14 Feb 2021 04:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=5DoWs6dp/64wqla0A0b1nga2ZgzOV0zGqCFlnhme5+0=; b=OKl3Kng2g2gXX558mx1XL8GDykTODWF/LRqBkAb0lEk8p/jlmTiP/iHxWa1Rc8H0jR JDVx68/3dpHFS7QUVNvkKfdjp5RTblhIrKN9sCunKUPPxZR5sPFpTvDKWt4yI5+9jwht Ev6RsBkE7+CVKyRIBrSRjuPB5BQnK/yJrzBYc0kuV0VwO4VN/WLbAMHBBc11ftgqA7Ue ze5lSjcn0h1RCipcHad1zn5bxRcBGKwHL8Nn+tJrmsLxwNM8aihz6IRrJvyp7bQOwrua 8gaphwk2x+6hfyTT5lXqpIa0I8kR8iYlWjfoscjWo1cpZ4OojzWznZLEWZ9g37fzx3Ez JIWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=5DoWs6dp/64wqla0A0b1nga2ZgzOV0zGqCFlnhme5+0=; b=VHMDdGsHz10hcxlV29zfbSTSk1i2FEcIatp25mATcM76V8HO/msX/OwFIWOCnyL6UH vfMKM6dsQ3UApcrwprqkiohsnyzVtnzjkAnUg/pLjff2T3n3Dv3hqqSpRVaiej4YV1Bl i3sVYCAsUtkmtgCVV9mpsfYqbciaHW8SxGPUHlDAyCN5XI+4fug9sQaHNyZV5XBLMDp3 os0hR+1WL+9qE0GJUZ5IV3BbXzNlmWsUnfRAlCCfRXIJ/wjvaelBY0AqVETIrZ90+/Wm 3ihscDHcK2ewZnSeUn09DPWAnZskWuYcVtMU72mhtP9mVE+w4EnucMo71AY8BBxPpX1t Xaog== X-Gm-Message-State: AOAM533f9LSFpUVznRNHbDYI+fSZSa/38Nd1g97GF7CWUACnSmITM+Mj 904BfQ5rFihrsPoSGsoAhlaq/g== X-Google-Smtp-Source: ABdhPJxB+k2f7oLKGb4sZ0aknTI3VccY/q/ZFx1o2aGwRGy9PsXmjpKpHBQ91607Pz2xw39XpOwe7g== X-Received: by 2002:a62:191:0:b029:1dd:3b65:c91d with SMTP id 139-20020a6201910000b02901dd3b65c91dmr11305797pfb.14.1613305979824; Sun, 14 Feb 2021 04:32:59 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id s18sm13291481pjr.14.2021.02.14.04.32.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 04:32:59 -0800 (PST) From: Vittorio Bertocci To: Warren Parad CC: Neil Madden , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAA1Za+AAAVvgIAADHnk X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 12:32:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB405252DBE4E8235AAD829067AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:33:04 -0000 --_000_CO6PR18MB405252DBE4E8235AAD829067AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgRm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBkb2N1bWVudCBzZWxlY3Rp b24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNvbnRhY3QgdXBkYXRlcywgZXRjLi4u IFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBjbGllbnQgc2lkZSBzaWxlbnQgYXV0 aGVudGljYXRpb24gdXNpbmcgdGhlIHByb3ZpZGVkIHNlc3Npb24gdG9rZW4gZnJvbSB0aGUgQXp1 cmUgQUQgQVMsIHdpdGhvdXQgbmVlZGluZyB0byBtYWtlIGFueSBSTyBhcGkgY2FsbHMgbm9yIHVz ZXIgcmVkaXJlY3RzLg0KQ2FuIHlvdSBleHBhbmQgb24gd2hhdCBzaWxlbnQgYXV0aGVudGljYXRp b24gYW5kIHNlc3Npb24gdG9rZW4gc3RhbmRzIGZvciBoZXJlPyBJZiB5b3UgYXJlIHJlZmVycmlu ZyB0byB0aGUgaWZyYW1lIHNjZW5hcmlvLCB0aGUgbmV3IGJyb3dzZXIgbWVhc3VyZXMgbWFrZSBp dCBwcm9ibGVtYXRpYy4gSW4gY29kZStQS0NFIHlvdSBjYW4gdXNlIGEgcmVmcmVzaCB0b2tlbiwg YnV0IHNlZSB0aGUgb3RoZXIgcmVwbHkgZm9yIGhvdyB0aGlzIHByb3Bvc2FsIGlzIGFuIGFsdGVy bmF0aXZlIHRvIHRoYXQgaW4gc29tZSBzaXR1YXRpb25zLiBUaGlzIGFuc3dlciB3YXMgc3BlY2lm aWNhbGx5IG9uIHdoeSBoYXZpbmcgYmFja2VuZC1pc3N1ZWQgdG9rZW5zIGRpZG7igJl0IGFwcGx5 IHRvIHRoaXMgc2NlbmFyaW8uDQoNCg0KRnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWQ9NDByaG9z eXMuY2hAZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBTdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0 IDAzOjQ4DQpUbzogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNv bT4NCkNjOiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4sICJvYXV0aEBp ZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVG9rZW4g TWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChU TUkgQkZGKQ0KDQpGb3IgdGhlIHRydXN0ZWQgcGFydCwgc2VlIGFib3ZlLiBGb3IgdGhlIHNob3J0 IGxpdmVkIEpXVHMsIHRoYXTigJlzIG5vdCByZWFsbHkgYW4gb3B0aW9uLiBUaGUgbW9zdCBnZW5l cmljIHNjZW5hcmlvIGFkZHJlc3NlZCBoZXJlIGlzIGZvciBBUElzIHRoYXQgYWNjZXB0IHRva2Vu cyBpc3N1ZWQgYnkgdGhlIEFTOyB0aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVtIGFzIGEgY2xp ZW50LCBidXQgaXQgY2Fubm90IG1pbnQgdGhlbS4gSW1hZ2luZSB3ZeKAmXJlIHRhbGtpbmcgYWJv dXQgYSBTUEEgYXBwbGljYXRpb24gdGhhdCBzaWducyBpbiB1c2VycyB1c2luZyBBenVyZSBBRCwg YW5kIG5lZWRzIHRvIGNhbGwgT2ZmaWNlIGFuZCBBenVyZSBBUElzLiBUaGUgU1BBIGJhY2tlbmQg Y2Fubm90IGlzc3VlIHRva2VucyBmb3IgdGhvc2UgQVBJcywgaXQgY2FuIG9ubHkgcmVxdWVzdCB0 aGVtIHRvIHRoZSBBenVyZSBBRCBBUy4NCg0KRm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwg aS5lLiBkb2N1bWVudCBzZWxlY3Rpb24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNv bnRhY3QgdXBkYXRlcywgZXRjLi4uIFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBj bGllbnQgc2lkZSBzaWxlbnQgYXV0aGVudGljYXRpb24gdXNpbmcgdGhlIHByb3ZpZGVkIHNlc3Np b24gdG9rZW4gZnJvbSB0aGUgQXp1cmUgQUQgQVMsIHdpdGhvdXQgbmVlZGluZyB0byBtYWtlIGFu eSBSTyBhcGkgY2FsbHMgbm9yIHVzZXIgcmVkaXJlY3RzLiBGb3IgUk8gcmVzcG9uc2liaWxpdGll cywgeW91IGNhbiBwcmVzZW50IHRoZSB1c2VyIHdpdGggYSBidXR0b24gIkdyYW50IFJPIGFjY2Vz cyB0byBBenVyZSByZXNvdXJjZXMiIGJ1dHRvbiBhbmQgdGhlIHVzZXIgd2lsbCBnbyB0aHJvdWdo IGEgcGVybWlzc2lvbiBzY29wZSBlbGV2YXRpb24gZmxvdywgYWdhaW4gbm8gcmVhc29uIHRvIG5l ZWQgYSBCRkYgaGVyZS4NCg0KV2UgZGlkIGNvbnNpZGVyIGFkZGluZyBzb21ldGhpbmcgdG8gdGhh dCBlZmZlY3QsIGFuIGVycm9yIG1lc3NhZ2UgdGhhdCBjYW4gZGlyZWN0IHRoZSBmcm9udGVuZCB0 byBwZXJmb3JtIHRoZSBpbnRlcmFjdGl2ZSBwb3J0aW9uIG5lY2Vzc2FyeSBmb3IgdGhpcyB0b3Bv bG9neSB0byB3b3JrLiBJdCB3b3VsZCBiZSBzb21ldGhpbmcgc2ltaWxhciB0byB0aGUgSURQIGlu aXRpYXRlZCBsb2dpbiBpbiBPSURDLCB3aGVyZSB0aGUgY2xpZW50IG9mZmVycyBhbiBlbmRwb2lu dCB0aGF0IGlzIGd1YXJhbnRlZWQgdG8gaW5pdGlhdGUgYSBzaWduIGluIGZsb3cgKGhlbmNlIGlu amVjdCBhbGwgdGhlIG5lY2Vzc2FyeSBub25jZXMgZXRjKS4gV2UgZGlkbuKAmXQgYWRkIGl0IHVw ZnJvbnQgYW5kIGxlZnQgaXQgYXMgZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgbW9zdGx5IGJlY2F1 c2UgaXTigJlzIG5vdCBlYXN5IHRvIG1vZGVsIHByb3Blcmx5IGFuZCBiZWZvcmUgb3BlbmluZyB0 aGF0IHdvcmsgZnJvbnQgd2Ugd2FudGVkIHRvIHNlZSBob3cgdGhlIGlkZWEgd2FzIHJlY2VpdmVk Lg0KSXQgbWF5IG1ha2Ugc2Vuc2UgZm9yIHRoZSBhcHAgdG8gaGF2ZSBhbiBlcnJvciBtZXNzYWdl LCBvciBldmVuIGJldHRlciBtaWdodCBiZSBhIDMwMiBMb2NhdGlvbiBoZWFkZXIgZGVwZW5kaW5n IG9uIHdoYXQgeW91IGFyZSBkb2luZy4gVGhlcmUgaXMgbm90aGluZyBoZXJlIHRoYXQgaXMgT0F1 dGggc3BlY2lmaWMgaG93ZXZlciAobm9yIGNvbW1vbiksIGFuZCB0aGVuIHdlIHNob3VsZCBjaGFs bGVuZ2UgdGhlIG5lZWQgdG8gZGlyZWN0bHkgcHJvdmlkZSBhbiBSRkMgcmVjb21tZW5kYXRpb24g Zm9yIGhhbmRsaW5nIHRoaXMuDQoNCg0KW0ltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLl0NCg0KV2Fy cmVuIFBhcmFkDQoNCkZvdW5kZXIsIENUTw0KU2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21w bGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0ZWN0dXJlLiBJbXBsZW1lbnQgQXV0aHJlc3M8 aHR0cHM6Ly9hdXRocmVzcy5pbz4uDQoNCg0KT24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgMTI6Mjkg UE0gVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSGkg TmVpbCwNClRoYW5rcyBmb3IgdGhlIHByb21wdCBjb21tZW50cyENCg0KICAqICAgUmU6IEdFVCB2 cyBQT1NULA0KcGVyc29uYWxseSBJ4oCZZCBiZSBmaW5lIHdpdGggcmVzdHJpY3RpbmcgdG8gUE9T VC4NCg0KDQogICogICBSZTogUk8tQVMsIGludGVyYWN0aW9uLQ0KcGVyaGFwcyBpdCBpcyBub3Qg dmVyeSBjbGVhciBmcm9tIHRoZSB0ZXh0IGF0IHRoZSBtb21lbnQgKGZpcnN0IGRyYWZ0KSwgYnV0 IHRoYXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBSTyB3ZW50IHRocnUgd2hhdGV2ZXIgaW50ZXJhY3Rp dmUgc3RlcHMgYXJlIG5lY2Vzc2FyeSB0byBlc3RhYmxpc2ggYSBzZXNzaW9uIChlZyBzaWduIGlu LCBhc3N1bWluZyB0aGUgQVMgaXMgc2F5IGFuIE9JREMgcHJvdmlkZXIpIGFuZCBvYnRhaW4gYmVm b3JlaGFuZCB0aGUgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VucyB0aGF0IHdpbGwgYmUg bmVlZGVkIGR1cmluZyB0aGUgYXBwIGFjdGl2aXRpZXMgdGFraW5nIHBsYWNlIGFmdGVyICB0aGF0 LiBJbiBjb25jcmV0ZSB0ZXJtcywgaW1hZ2luZSB0aGF0IHRoZSBiYWNrZW5kIHBlcmZvcm1zIGFu IGF1dGhvcml6YXRpb24gY29kZSBncmFudCByZXF1ZXN0aW5nIGFuIElEdG9rZW4sIGFjY2VzcyB0 b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBCRUZPUkUgdGhlIGFjdGl2aXRpZXMgZGVzY3JpYmVkIGlu IFRNSS1CRkYgdGFrZSBwbGFjZS4NClRoZSBjdXJyZW50IGxhbmd1YWdlIHRyeWluZyB0byBleHBy ZXNzIHRoYXQgaXMgaW4gMS4yOg0KQXMgYSBwcmVyZXF1aXNpdGUgZm9yIHRoZSBmbG93IGRlc2Ny aWJlZCBiZWxvdywgdGhlIGJhY2tlbmQgTVVTVCBoYXZlIGVzdGFibGlzaGVkIGEgc2VjdXJlIHNl c3Npb24gd2l0aCB0aGUgdXNlciBhZ2VudCwgc28gdGhhdCBhbGwgcmVxdWVzdHMgZnJvbSB0aGF0 IHVzZXIgYWdlbnQgdG93YXJkIHRoZSBiYWNrZW5kIG9jY3VyIG92ZXIgSFRUUFMgYW5kIGNhcnJ5 IGEgdmFsaWQgc2Vzc2lvbiBhcnRpZmFjdCAoc3VjaCBhcyBhIGNvb2tpZSkgdGhhdCB0aGUgYmFj a2VuZCBjYW4gdmFsaWRhdGUuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFuZGF0ZSBhbnkgc3Bl Y2lmaWMgbWVjaGFuaXNtIHRvIGVzdGFibGlzaCBhbmQgbWFpbnRhaW4gdGhhdCBzZXNzaW9uLg0K QW5kDQpjYWNoZWQsIGl0IHJlcXVlc3RzIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhIG5l dyBhY2Nlc3MgdG9rZW4gd2l0aCB0aGUgcmVxdWlyZWQgY2hhcmFjdGVyaXN0aWNzLCB1c2luZyBh bnkgYXJ0aWZhY3RzIHByZXZpb3VzeSBvYnRhaW5lZCAoZWcgcmVmcmVzaCB0b2tlbikgYW5kIGdy YW50cyB0aGF0IHdpbGwgYWxsb3cgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGlzc3VlIHRo ZSByZXF1ZXN0ZWQgdG9rZW4gd2l0aG91dCByZXF1aXJpbmcgdXNlciBpbnRlcmFjdGlvbi4NCg0K DQogICogICAgSWYgdGhlIGJhY2tlbmQgaXMgYWxyZWFkeSBpbXBsaWNpdGx5IHRydXN0ZWQgdGhl biBjb3VsZG7igJl0IHlvdSBza2lwIE9BdXRoIGFuZCBqdXN0IGdldCB0aGUgYmFja2VuZCB0byBp c3N1ZSBzaG9ydC1saXZlZCBKV1RzIHRvIHRoZSBmcm9udGVuZCB0aGF0IGl0IGNhbiB1c2UgZm9y IEFQSSBhY2Nlc3M/DQpGb3IgdGhlIHRydXN0ZWQgcGFydCwgc2VlIGFib3ZlLiBGb3IgdGhlIHNo b3J0IGxpdmVkIEpXVHMsIHRoYXTigJlzIG5vdCByZWFsbHkgYW4gb3B0aW9uLiBUaGUgbW9zdCBn ZW5lcmljIHNjZW5hcmlvIGFkZHJlc3NlZCBoZXJlIGlzIGZvciBBUElzIHRoYXQgYWNjZXB0IHRv a2VucyBpc3N1ZWQgYnkgdGhlIEFTOyB0aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVtIGFzIGEg Y2xpZW50LCBidXQgaXQgY2Fubm90IG1pbnQgdGhlbS4gSW1hZ2luZSB3ZeKAmXJlIHRhbGtpbmcg YWJvdXQgYSBTUEEgYXBwbGljYXRpb24gdGhhdCBzaWducyBpbiB1c2VycyB1c2luZyBBenVyZSBB RCwgYW5kIG5lZWRzIHRvIGNhbGwgT2ZmaWNlIGFuZCBBenVyZSBBUElzLiBUaGUgU1BBIGJhY2tl bmQgY2Fubm90IGlzc3VlIHRva2VucyBmb3IgdGhvc2UgQVBJcywgaXQgY2FuIG9ubHkgcmVxdWVz dCB0aGVtIHRvIHRoZSBBenVyZSBBRCBBUy4NCg0KDQogICogICBJZiB5b3Ugd2FudCB0byBhbGxv dyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQg Y2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBhdXRob3JpemF0aW9uIGVu ZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhlIHVzZXIgdG8uIChFZyB0 aGUgYmFja2VuZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJIHRo YXQgcmVmZXJlbmNlcyB0aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7igJl0 IHBhc3NlZCB0aHJvdWdoIHRoZSBmcm9udGVuZCkuDQpXZSBkaWQgY29uc2lkZXIgYWRkaW5nIHNv bWV0aGluZyB0byB0aGF0IGVmZmVjdCwgYW4gZXJyb3IgbWVzc2FnZSB0aGF0IGNhbiBkaXJlY3Qg dGhlIGZyb250ZW5kIHRvIHBlcmZvcm0gdGhlIGludGVyYWN0aXZlIHBvcnRpb24gbmVjZXNzYXJ5 IGZvciB0aGlzIHRvcG9sb2d5IHRvIHdvcmsuIEl0IHdvdWxkIGJlIHNvbWV0aGluZyBzaW1pbGFy IHRvIHRoZSBJRFAgaW5pdGlhdGVkIGxvZ2luIGluIE9JREMsIHdoZXJlIHRoZSBjbGllbnQgb2Zm ZXJzIGFuIGVuZHBvaW50IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBpbml0aWF0ZSBhIHNpZ24gaW4g ZmxvdyAoaGVuY2UgaW5qZWN0IGFsbCB0aGUgbmVjZXNzYXJ5IG5vbmNlcyBldGMpLiBXZSBkaWRu 4oCZdCBhZGQgaXQgdXBmcm9udCBhbmQgbGVmdCBpdCBhcyBleGVyY2lzZSBmb3IgdGhlIHJlYWRl ciBtb3N0bHkgYmVjYXVzZSBpdOKAmXMgbm90IGVhc3kgdG8gbW9kZWwgcHJvcGVybHkgYW5kIGJl Zm9yZSBvcGVuaW5nIHRoYXQgd29yayBmcm9udCB3ZSB3YW50ZWQgdG8gc2VlIGhvdyB0aGUgaWRl YSB3YXMgcmVjZWl2ZWQuDQoNCkZyb206IE9BdXRoIDxvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE5laWwgTWFkZGVuIDxu ZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t Pj4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMDA6MTcNClRvOiBWaXR0b3Jp byBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj4NCkNjOiAib2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Np b24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpDQoNCkkgaGF2ZSBh IGxvdCBvZiBzZWN1cml0eSBjb25jZXJucyBhYm91dCB0aGlzIGRyYWZ0Lg0KDQpUaGUgZHJhZnQg YWxsdWRlcyB0byBzZWN1cml0eSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGhhbmRsaW5nIGFjY2Vz cyB0b2tlbnMgaW4gdGhlIGZyb250ZW5kIGJ1dCBuZXZlciByZWFsbHkgc3BlbGxzIHRoZW0gb3V0 LiBGcm9tIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpdCBzZWVtcyB0aGF0IHRoZSBwcmlt YXJ5IGNvbmNlcm4gaXMgd2l0aCB0aGVmdCBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gbG9jYWwgc3Rv cmFnZS4gVG8gZG8gdGhpcyB5b3XigJlkIG5lZWQgYW4gWFNTIGF0dGFjay4gQnV0IGluIHRoYXQg Y2FzZSwgd291bGRu4oCZdCB0aGUgYXR0YWNrZXIgc2ltcGx5IHVzZSB0aGUgWFNTIHRvIG1ha2Ug YSBjYWxsIHRvIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgaW5zdGVhZD8NCg0KVGhlIGNvbWJpbmF0 aW9uIG9mIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgcmVjb21tZW5kaW5nIHRoZSB1c2Ugb2YgR0VU IHJlcXVlc3RzIHRvZ2V0aGVyIHdpdGggdGhlIGhpbnQgdG8gdXNlIGNvb2tpZS1iYXNlZCBhdXRo ZW50aWNhdGlvbiBpcyBsaWtlbHkgZ29pbmcgdG8gcHVuY2ggYSBob2xlIGluIG1vc3QgQ1NSRiBk ZWZlbnNlcywgd2hpY2ggYXNzdW1lIHRoYXQgR0VUcyBhcmUgc2FmZS4gVGhlIG9ubHkgdGhpbmcg cHJldmVudGluZyB0aGlzIGJlaW5nIGV4cGxvaXRhYmxlIGlzIENyb3NzLU9yaWdpbiBSZWFkIEJs b2NraW5nIChodHRwczovL2Nocm9taXVtLmdvb2dsZXNvdXJjZS5jb20vY2hyb21pdW0vc3JjLysv bWFzdGVyL3NlcnZpY2VzL25ldHdvcmsvY3Jvc3Nfb3JpZ2luX3JlYWRfYmxvY2tpbmdfZXhwbGFp bmVyLm1kKSBkdWUgdG8gdGhlIEpTT04gY29udGVudC10eXBlLiBUaGF0IG1ha2VzIG1lIHJlYWxs eSBuZXJ2b3VzLiBXZSBzaG91bGQgYXQgbGVhc3QgbWFuZGF0ZSBYLUNvbnRlbnQtVHlwZS1PcHRp b25zOiBub3NuaWZmIG9uIHRoYXQgcmVzcG9uc2UuIEnigJlkIGZlZWwgbW9yZSBjb21mb3J0YWJs ZSBpZiB0aGlzIHdhcyBhIFBPU1QgcmVxdWVzdCBvbmx5Lg0KDQpBcyBTdG95Y2hvIFNsZXB0c292 IG1lbnRpb25lZCBpbiB0aGUgb3RoZXIgZW1haWwsIHRoZSBsYWNrIG9mIGZyb250LWNoYW5uZWwg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJPIHNlZW1zIG9kZC4gSWYgdGhl IGJhY2tlbmQgaXMgYWxyZWFkeSBpbXBsaWNpdGx5IHRydXN0ZWQgdGhlbiBjb3VsZG7igJl0IHlv dSBza2lwIE9BdXRoIGFuZCBqdXN0IGdldCB0aGUgYmFja2VuZCB0byBpc3N1ZSBzaG9ydC1saXZl ZCBKV1RzIHRvIHRoZSBmcm9udGVuZCB0aGF0IGl0IGNhbiB1c2UgZm9yIEFQSSBhY2Nlc3M/DQoN CklmIHlvdSB3YW50IHRvIGFsbG93IGF1dGggY29kZSBmbG93IGV0YyB0aGVuIHBlcmhhcHMgdGhl IGJmZi10b2tlbiBlbmRwb2ludCBjYW4gcmV0dXJuIGEgc3RhbmRhcmQgZXJyb3IgY29kZSB3aXRo IGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgVVJJIHRoYXQgdGhlIFNQQSB0aGVuIG5hdmlnYXRl cyB0aGUgdXNlciB0by4gKEVnIHRoZSBiYWNrZW5kIGNhbiBkbyBhIFBBUiByZXF1ZXN0IGZpcnN0 IGFuZCByZXR1cm4gYSBVUkkgdGhhdCByZWZlcmVuY2VzIHRoYXQgc28gdGhhdCBhdXRob3JpemF0 aW9uIGRldGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5kKS4NCg0K4oCU IE5laWwNCg0KDQpPbiAxMiBGZWIgMjAyMSwgYXQgMjA6NDYsIFZpdHRvcmlvIEJlcnRvY2NpIDx2 aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRo MC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCu+7v0RlYXIgYWxsLA0KQnJpYW4gYW5kIHlv dXJzIHRydWx5IGFyZSBwcm9wb3NpbmcgYSBuZXcgc3BlY2lmaWNhdGlvbiB0aGF0IHNob3dzIGhv dyB0aGUgdXNlciBhZ2VudCBmcm9udGVuZCBvZiBhIHdlYiBhcHAgY2FuIGRlbGVnYXRlIHRva2Vu IGFjcXVpc2l0aW9uIGFuZCBwZXJzaXN0ZW5jZSB0byBpdHMgYmFja2VuZCwgYW5kIHJlcXVlc3Qg c3VjaCB0b2tlbnMgd2hlbiBuZWVkZWQgZm9yIGRpcmVjdCBhY2Nlc3Mgb2YgcHJvdGVjdGVkIHJl c291cmNlcyBmcm9tIHRoZSBmcm9udGVuZCBjb2RlLg0KDQpUaGUgcGF0dGVybiBpcyBhbHJlYWR5 IGluIHVzZSwgaW4gcHJvcHJpZXRhcnkgZm9ybSwgYnkgdmFyaW91cyBtb2Rlcm4gZGV2ZWxvcG1l bnQgc3RhY2tzLCBzdWNoIGFzIE5leHQuSlMuIFZhcmlhbnRzIG9mIHRoZSBwYXR0ZXJuLCBvZnRl biBkaXNjdXNzZWQgdW5kZXIgdGhlIGNhdGNoLWFsbCB0ZXJtIEJGRiAoYmFja2VuZCBmb3IgZnJv bnRlbmQpLCBoYXZlIGJlZW4gb2Z0ZW4gbWVudGlvbmVkIGluIHRoaXMgd29ya2dyb3Vw4oCZcyBh Y3Rpdml0eSwgYnV0IGFsd2F5cyBsZWZ0IGFsbCBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIHRo ZSByZWFkZXIuDQpXZSBiZWxpZXZlIHRoZSBwYXR0ZXJuIGhhcyBtZXJpdCwgYXMgY29ycm9ib3Jh dGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9uLiBCeSBkZWxlZ2F0aW5nIGFjY2VzcyB0b2tlbiBh Y3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwgd2UgYXZvaWQgbWFueSBvZiB0aGUgb2Z0ZW4gYnJp dHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBsaWVkIGF0dGFjayBzdXJmYWNlKSByZXF1aXJlZCB0 byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHVzZXIgYWdlbnQuIFRoZSB0b3BvbG9neSBh bHNvIHJlbGlldmVzIHRoZSBmcm9udGVuZCBmcm9tIHRoZSBuZWVkIG9mIHBlcnNpc3RpbmcgdG9r ZW5zIGluIGxvY2FsIHN0b3JhZ2UsIGEgd2VsbCBrbm93biBzb3JlIHBvaW50IG9mIHVzaW5nIE9B dXRoIGRpcmVjdGx5IGluIEphdmFTY3JpcHQsIGJ5IHJlbHlpbmcgb24gaXRzIGJhY2tlbmQgc3Rv cmFnZSBhbmQgc2Vzc2lvbiB0byBwcmVzZXJ2ZSB0b2tlbnMuDQoNCkFsdGhvdWdoIHRoZSBzcGVj aWZpY2F0aW9uIGlzIHZlcnkgc2ltcGxlLCBwcm92aWRpbmcgZXhwbGljaXQgZ3VpZGFuY2Ugb24g dGhlIHNjZW5hcmlvIG9mZmVycyBtYW55IGFkdmFudGFnZXMuDQotIEl0IG1ha2VzIGl0IHBvc3Np YmxlIHRvIGNyZWF0ZSBpbnRlcm9wZXJhYmxlIFNES3MsIHdoZXJlIGZyb250ZW5kIGRldiBzdGFj a3MgKGFueSBKUyBmbGF2b3IpIGNhbiBiZSBtaXhlZCBhbmQgbWF0Y2hlZCB3aXRoIGNvbXBsaWFu dCBiYWNrZW5kIHN0YWNrcyAobWlkZGxld2FyZXMgaW4gbm9kZSwgamF2YSwgQVNQLk5FVDxodHRw Oi8vQVNQLk5FVD4sIFBIUCBldGMpDQotIEl0IGFsbG93cyB1cyB0byBwcm92aWRlIGd1aWRhbmNl IG9uIGhvdyB0byBwcm9wZXJseSB0YWNrbGUgdGhlIHNjZW5hcmlvIGFuZCB3YXJuIGltcGxlbWVu dGVycyBhZ2FpbnN0IHNlY3VyaXR5IHJpc2tzIChzY29wZSBlc2NhbGF0aW9ucywgdXNpbmcgSUR0 b2tlbnMgaW5zdGVhZCBvZiBhY2Nlc3MgdG9rZW5zLCBldGMpDQotIEl0IGFsbG93cyB1cyB0byBk aXNjdXNzIChhbmQgd2hlbiBhcHByb3ByaWF0ZSwgcHJvbW90ZSkgdGhpcyBwYXR0ZXJuIGFzIHBh cnQgb2YgdGhlIGJyb3dzZXIgYXBwcyBzZWN1cml0eSBndWlkYW5jZSwgYW5kIHBvc2l0aW9uIHRo ZSBzY2VuYXJpbyB3aGVyZSBmcm9udGVuZCBvbmx5IGNhbGxzIEFQSSBvbiBpdHMgb3duIGJhY2tl ZCAoaGVuY2UgZG9lc27igJl0IG5lZWQgYWNjZXNzIHRva2Vucykgc2ltcGx5IGFzIGEgc3BlY2lh bCBjYXNlIG9mIHRoaXMgbW9yZSBnZW5lcmFsIHBhdHRlcm4NCi0gVGhpcyBhcHByb2FjaCBtYWtl cyBtb2NraW5nIGFuZCB0ZXN0aW5nIGFwcHMgdmVyeSBlYXN5LCBwb3NzaWJseSBwcmV2ZW50aW5n IGRldmVsb3BlcnMgZnJvbSB3ZWFrZW5pbmcgdGhlIHNlY3VyaXR5IG9mIHRoZWlyIHN5c3RlbSAo ZWcgdHVybmluZyBvbiBST1BHIG9wdGlvbnMpICBvciB0dXJuaW5nIHRvIHJpc2t5IHByYWN0aWNl cyBsaWtlIHNjcmFwaW5nDQoNCk5lZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRv ZXNu4oCZdCBlbnRpcmVseSBlbGltaW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1 c2Ugb2YgYWNjZXNzIHRva2VucyBmcm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0 aGUgcGF0dGVybiBpcyBpbiB3aWRlc3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxl YWRpbmcgdG8gdGhhdCAoZWcgZGV2ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdCBvbmx5 IHdvcmsgd2l0aCBmcm9udGVuZCBzdGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZlcnNlIHByb3hp ZXMgbWlnaHQgbm90IGFsd2F5cyBiZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29pbmcgYXdheSBh bnkgdGltZSBzb29uLiBCeSBwcm92aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRoaXMgcGF0dGVy biwgd2UgY2FuIHNpbXBsaWZ5IHRoZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3aGlsZSBlbnNo cmluaW5nIGJhc2ljIHNlY3VyaXR5IGh5Z2llbmUgaW4gc2NlbmFyaW9zIHRoYXQgd291bGQgaGF2 ZSBvdGhlcndpc2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLg0KDQpMb29raW5nIGZvcndh cmQgZm9yIHlvdXIgZmVlZGJhY2shDQoNCkImVg0KDQrvu79PbiAyLzEyLzIxLCAxMjo0MSwgImlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiIg PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Pj4gd3JvdGU6DQoNCg0KICAgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJlcnRvY2NpLW9h dXRoMi10bWktYmZmLTAwLnR4dA0KICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBWaXR0b3JpbyBCZXJ0b2NjaSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgSUVURiByZXBvc2l0b3J5 Lg0KDQogICBOYW1lOiAgICAgICAgZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYNCiAgIFJl dmlzaW9uOiAgICAwMA0KICAgVGl0bGU6ICAgICAgICBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Np b24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQNCiAgIERvY3VtZW50IGRhdGU6ICAg IDIwMjEtMDItMTINCiAgIEdyb3VwOiAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICBQ YWdlczogICAgICAgIDE2DQogICBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv YXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQNCiAgIFN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2Nj aS1vYXV0aDItdG1pLWJmZi8NCiAgIEh0bWw6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLmh0bWwNCiAgIEh0 bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2kt b2F1dGgyLXRtaS1iZmYtMDANCg0KDQogICBBYnN0cmFjdDoNCiAgICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGhvdyBhIEphdmFTY3JpcHQgZnJvbnRlbmQgY2FuIGRlbGVnYXRlIGFjY2Vzcw0K ICAgICAgdG9rZW4gYWNxdWlzaXRpb24gdG8gYSBiYWNrZW5kIGNvbXBvbmVudC4gIEluIHNvIGRv aW5nLCB0aGUgZnJvbnRlbmQNCiAgICAgIGNhbiBhY2Nlc3MgcmVzb3VyY2Ugc2VydmVycyBkaXJl Y3RseSB3aXRob3V0IHRha2luZyBvbiB0aGUgYnVyZGVuIG9mDQogICAgICBjb21tdW5pY2F0aW5n IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBwZXJzaXN0aW5nIHRva2VucywgYW5kDQog ICAgICBwZXJmb3JtaW5nIG9wZXJhdGlvbnMgdGhhdCBhcmUgZnJhdWdodCB3aXRoIHNlY3VyaXR5 IGNoYWxsZW5nZXMgd2hlbg0KICAgICAgZXhlY3V0ZWQgaW4gYSB1c2VyIGFnZW50LCBidXQgYXJl IHNhZmUgYW5kIHdlbGwgcHJvdmVuIHdoZW4gZXhlY3V0ZWQNCiAgICAgIGJ5IGEgY29uZmlkZW50 aWFsIGNsaWVudCBydW5uaW5nIG9uIGEgYmFja2VuZC4NCg0KDQoNCg0KICAgUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQogICBUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KDQpGb3JnZVJvY2sgdmFsdWVzIHlvdXIgUHJpdmFjeTxodHRwczovL3d3dy5mb3JnZXJv Y2suY29tL3lvdXItcHJpdmFjeT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg== --_000_CO6PR18MB405252DBE4E8235AAD829067AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTm90byBTYW5zIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDUgNCAyIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS01 MTYzNTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbS01MTYzNTM2OTIx NDQzOTk3OTQ5bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0 OW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tNTE2MzUzNjkyMTQ0 Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLmdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OWFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy01MTYzNTM2OTIxNDQzOTk3OTQ5YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6ODU0NzMwODUxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0 NzIxMjY2MTg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjM0MzE4MTkxOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAzNzYzNDkx NiA0Nzc2NjQxNDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDo1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMzUxODM1ODIyOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMjA5NDk5NjA5MDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0 LWlkOjE1OTc5MDE2ODc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc4ODE0NDUwO30NCkBsaXN0 IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MjA5MjkyMTI0NzsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MjAyMTE0MjU4Njt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZv NSI+Rm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBkb2N1bWVudCBzZWxlY3Rpb24s IHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNvbnRhY3QgdXBkYXRlcywgZXRjLi4uIFlv dSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBjbGllbnQgc2lkZQ0KPGI+c2lsZW50IGF1 dGhlbnRpY2F0aW9uPC9iPiZuYnNwO3VzaW5nIHRoZSBwcm92aWRlZCBzZXNzaW9uIHRva2VuIGZy b20gdGhlIEF6dXJlIEFEIEFTLCB3aXRob3V0IG5lZWRpbmcgdG8gbWFrZSBhbnkgUk8gYXBpIGNh bGxzIG5vciB1c2VyIHJlZGlyZWN0cy4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgZXhwYW5kIG9uIHdoYXQgc2lsZW50IGF1dGhlbnRpY2F0 aW9uIGFuZCBzZXNzaW9uIHRva2VuIHN0YW5kcyBmb3IgaGVyZT8gSWYgeW91IGFyZSByZWZlcnJp bmcgdG8gdGhlIGlmcmFtZSBzY2VuYXJpbywgdGhlIG5ldyBicm93c2VyIG1lYXN1cmVzIG1ha2Ug aXQgcHJvYmxlbWF0aWMuIEluIGNvZGUrUEtDRSB5b3UgY2FuIHVzZSBhIHJlZnJlc2ggdG9rZW4s IGJ1dCBzZWUgdGhlIG90aGVyIHJlcGx5DQogZm9yIGhvdyB0aGlzIHByb3Bvc2FsIGlzIGFuIGFs dGVybmF0aXZlIHRvIHRoYXQgaW4gc29tZSBzaXR1YXRpb25zLiBUaGlzIGFuc3dlciB3YXMgc3Bl Y2lmaWNhbGx5IG9uIHdoeSBoYXZpbmcgYmFja2VuZC1pc3N1ZWQgdG9rZW5zIGRpZG7igJl0IGFw cGx5IHRvIHRoaXMgc2NlbmFyaW8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPldhcnJl biBQYXJhZCAmbHQ7d3BhcmFkPTQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCjxi PkRhdGU6IDwvYj5TdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAzOjQ4PGJyPg0KPGI+VG86 IDwvYj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tJmd0 Ozxicj4NCjxiPkNjOiA8L2I+TmVpbCBNYWRkZW4gJmx0O25laWwubWFkZGVuQGZvcmdlcm9jay5j b20mZ3Q7LCAmcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQg c2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Gb3IgdGhlIHRydXN0ZWQgcGFydCwgc2VlIGFib3ZlLiBGb3IgdGhlIHNob3J0 IGxpdmVkIEpXVHMsIHRoYXTigJlzIG5vdCByZWFsbHkgYW4gb3B0aW9uLiBUaGUgbW9zdCBnZW5l cmljIHNjZW5hcmlvIGFkZHJlc3NlZCBoZXJlIGlzIGZvciBBUElzIHRoYXQgYWNjZXB0IHRva2Vu cyBpc3N1ZWQgYnkgdGhlIEFTOyB0aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVtIGFzIGEgY2xp ZW50LCBidXQgaXQgY2Fubm90IG1pbnQNCiB0aGVtLiBJbWFnaW5lIHdl4oCZcmUgdGFsa2luZyBh Ym91dCBhIFNQQSBhcHBsaWNhdGlvbiB0aGF0IHNpZ25zIGluIHVzZXJzIHVzaW5nIEF6dXJlIEFE LCBhbmQgbmVlZHMgdG8gY2FsbCBPZmZpY2UgYW5kIEF6dXJlIEFQSXMuIFRoZSBTUEEgYmFja2Vu ZCBjYW5ub3QgaXNzdWUgdG9rZW5zIGZvciB0aG9zZSBBUElzLCBpdCBjYW4gb25seSByZXF1ZXN0 IHRoZW0gdG8gdGhlIEF6dXJlIEFEIEFTLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0 eSwgaS5lLiBkb2N1bWVudCBzZWxlY3Rpb24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMs IGNvbnRhY3QgdXBkYXRlcywgZXRjLi4uIFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRo ZSBjbGllbnQgc2lkZQ0KPGI+c2lsZW50IGF1dGhlbnRpY2F0aW9uPC9iPiZuYnNwO3VzaW5nIHRo ZSBwcm92aWRlZCBzZXNzaW9uIHRva2VuIGZyb20gdGhlIEF6dXJlIEFEIEFTLCB3aXRob3V0IG5l ZWRpbmcgdG8gbWFrZSBhbnkgUk8gYXBpIGNhbGxzIG5vciB1c2VyIHJlZGlyZWN0cy4mbmJzcDtG b3IgUk8gcmVzcG9uc2liaWxpdGllcywgeW91IGNhbiBwcmVzZW50IHRoZSB1c2VyIHdpdGggYSBi dXR0b24gJnF1b3Q7R3JhbnQgUk8gYWNjZXNzIHRvIEF6dXJlIHJlc291cmNlcyZxdW90OyBidXR0 b24gYW5kDQogdGhlIHVzZXIgd2lsbCBnbyB0aHJvdWdoJm5ic3A7YSBwZXJtaXNzaW9uIHNjb3Bl IGVsZXZhdGlvbiBmbG93LCBhZ2FpbiBubyByZWFzb24gdG8gbmVlZCBhIEJGRiBoZXJlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSBkaWQgY29uc2lkZXIgYWRkaW5nIHNvbWV0aGluZyB0byB0aGF0IGVmZmVjdCwgYW4gZXJyb3Ig bWVzc2FnZSB0aGF0IGNhbiBkaXJlY3QgdGhlIGZyb250ZW5kIHRvIHBlcmZvcm0gdGhlIGludGVy YWN0aXZlIHBvcnRpb24gbmVjZXNzYXJ5IGZvciB0aGlzIHRvcG9sb2d5IHRvIHdvcmsuIEl0IHdv dWxkIGJlIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoZSBJRFAgaW5pdGlhdGVkIGxvZ2luIGluIE9J REMsIHdoZXJlDQogdGhlIGNsaWVudCBvZmZlcnMgYW4gZW5kcG9pbnQgdGhhdCBpcyBndWFyYW50 ZWVkIHRvIGluaXRpYXRlIGEgc2lnbiBpbiBmbG93IChoZW5jZSBpbmplY3QgYWxsIHRoZSBuZWNl c3Nhcnkgbm9uY2VzIGV0YykuIFdlIGRpZG7igJl0IGFkZCBpdCB1cGZyb250IGFuZCBsZWZ0IGl0 IGFzIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIG1vc3RseSBiZWNhdXNlIGl04oCZcyBub3QgZWFz eSB0byBtb2RlbCBwcm9wZXJseSBhbmQgYmVmb3JlIG9wZW5pbmcgdGhhdA0KIHdvcmsgZnJvbnQg d2Ugd2FudGVkIHRvIHNlZSBob3cgdGhlIGlkZWEgd2FzIHJlY2VpdmVkLiZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkl0IG1heSBtYWtlIHNlbnNlIGZvciB0aGUgYXBwIHRvIGhhdmUgYW4gZXJyb3IgbWVzc2FnZSwg b3IgZXZlbiBiZXR0ZXIgbWlnaHQgYmUgYSAzMDINCjxiPkxvY2F0aW9uIGhlYWRlcjwvYj4mbmJz cDtkZXBlbmRpbmcgb24gd2hhdCB5b3UgYXJlIGRvaW5nLiBUaGVyZSBpcyBub3RoaW5nIGhlcmUg dGhhdCBpcyBPQXV0aCBzcGVjaWZpYyBob3dldmVyIChub3IgY29tbW9uKSwgYW5kIHRoZW4gd2Ug c2hvdWxkIGNoYWxsZW5nZSB0aGUgbmVlZCB0byBkaXJlY3RseSBwcm92aWRlIGFuIFJGQyByZWNv bW1lbmRhdGlvbiBmb3IgaGFuZGxpbmcgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3Jk ZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHls ZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgd2lkdGg9IjE5OSIgaGVpZ2h0PSIz NCIgc3R5bGU9IndpZHRoOjIuMDcyOWluO2hlaWdodDouMzU0MWluIiBpZD0iX3gwMDAwX2kxMDI1 IiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiIgZGF0YS1vdXRsb29rLXRyYWNlPSJGOjB8 VDoxIiBzcmM9ImNpZDp+V1JEMDAwLmpwZyI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0 O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxv dzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItYm90dG9tOm5vbmU7cGFkZGluZzowaW4gMGluIDBp biAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRl cjpub25lO3BhZGRpbmc6MGluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+V2FycmVuIFBhcmFkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAw aW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aGl0 ZSI+U2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24g YXJjaGl0ZWN0dXJlLiBJbXBsZW1lbnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9hdXRo cmVzcy5pbyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5B dXRocmVzczwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDEyOjI5IFBNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2 aXR0b3Jpby5iZXJ0b2NjaT08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5v cmciPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SGkgTmVpbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhh bmtzIGZvciB0aGUgcHJvbXB0IGNvbW1lbnRzITxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPg0KUmU6IEdFVCB2cyBQT1NULDxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4y NWluIj4NCnBlcnNvbmFsbHkgSeKAmWQgYmUgZmluZSB3aXRoIHJlc3RyaWN0aW5nIHRvIFBPU1Qu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjI1aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Imdt YWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlz dDpsNCBsZXZlbDEgbGZvMiI+DQpSZTogUk8tQVMsIGludGVyYWN0aW9uLSA8bzpwPjwvbzpwPjwv bGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cGVyaGFwcyBpdCBpcyBub3QgdmVyeSBj bGVhciBmcm9tIHRoZSB0ZXh0IGF0IHRoZSBtb21lbnQgKGZpcnN0IGRyYWZ0KSwgYnV0IHRoYXQg aXMgYXNzdW1lZCB0aGF0IHRoZSBSTyB3ZW50IHRocnUgd2hhdGV2ZXIgaW50ZXJhY3RpdmUgc3Rl cHMgYXJlIG5lY2Vzc2FyeSB0byBlc3RhYmxpc2ggYSBzZXNzaW9uDQogKGVnIHNpZ24gaW4sIGFz c3VtaW5nIHRoZSBBUyBpcyBzYXkgYW4gT0lEQyBwcm92aWRlcikgYW5kIG9idGFpbiBiZWZvcmVo YW5kIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW5zIHRoYXQgd2lsbCBiZSBuZWVk ZWQgZHVyaW5nIHRoZSBhcHAgYWN0aXZpdGllcyB0YWtpbmcgcGxhY2UgYWZ0ZXIgJm5ic3A7dGhh dC4gSW4gY29uY3JldGUgdGVybXMsIGltYWdpbmUgdGhhdCB0aGUgYmFja2VuZCBwZXJmb3JtcyBh biBhdXRob3JpemF0aW9uIGNvZGUNCiBncmFudCByZXF1ZXN0aW5nIGFuIElEdG9rZW4sIGFjY2Vz cyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBCRUZPUkUgdGhlIGFjdGl2aXRpZXMgZGVzY3JpYmVk IGluIFRNSS1CRkYgdGFrZSBwbGFjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIGN1cnJlbnQgbGFuZ3VhZ2UgdHJ5aW5nIHRvIGV4cHJlc3MgdGhhdCBpcyBpbiAx LjI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O05vdG8gU2FucyZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+QXMgYSBwcmVyZXF1aXNpdGUgZm9y IHRoZSBmbG93IGRlc2NyaWJlZCBiZWxvdywgdGhlIGJhY2tlbmQgTVVTVCBoYXZlIGVzdGFibGlz aGVkDQogYSBzZWN1cmUgc2Vzc2lvbiB3aXRoIHRoZSB1c2VyIGFnZW50LCBzbyB0aGF0IGFsbCBy ZXF1ZXN0cyBmcm9tIHRoYXQgdXNlciBhZ2VudCB0b3dhcmQgdGhlIGJhY2tlbmQgb2NjdXIgb3Zl ciBIVFRQUyBhbmQgY2FycnkgYSB2YWxpZCBzZXNzaW9uIGFydGlmYWN0IChzdWNoIGFzIGEgY29v a2llKSB0aGF0IHRoZSBiYWNrZW5kIGNhbiB2YWxpZGF0ZS4gVGhpcyBkb2N1bWVudCBkb2VzIG5v dCBtYW5kYXRlIGFueSBzcGVjaWZpYyBtZWNoYW5pc20gdG8NCiBlc3RhYmxpc2ggYW5kIG1haW50 YWluIHRoYXQgc2Vzc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtOb3RvIFNhbnMmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPmNhY2hlZCwgaXQgcmVx dWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGEgbmV3IGFjY2VzcyB0b2tlbiB3aXRo IHRoZSByZXF1aXJlZA0KIGNoYXJhY3RlcmlzdGljcywgdXNpbmcgYW55IGFydGlmYWN0cyBwcmV2 aW91c3kgb2J0YWluZWQgKGVnIHJlZnJlc2ggdG9rZW4pIGFuZCBncmFudHMgdGhhdCB3aWxsIGFs bG93IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1ZSB0aGUgcmVxdWVzdGVkIHRva2Vu IHdpdGhvdXQgcmVxdWlyaW5nIHVzZXIgaW50ZXJhY3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS01MTYzNTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCjxzcGFuIGNsYXNzPSJn bWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDlhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPklm IHRoZSBiYWNrZW5kIGlzIGFscmVhZHkgaW1wbGljaXRseSB0cnVzdGVkIHRoZW4gY291bGRu4oCZ dCB5b3Ugc2tpcCBPQXV0aCBhbmQganVzdCBnZXQgdGhlIGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQt bGl2ZWQgSldUcyB0byB0aGUgZnJvbnRlbmQNCiB0aGF0IGl0IGNhbiB1c2UgZm9yIEFQSSBhY2Nl c3M/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciB0aGUg dHJ1c3RlZCBwYXJ0LCBzZWUgYWJvdmUuIEZvciB0aGUgc2hvcnQgbGl2ZWQgSldUcywgdGhhdOKA mXMgbm90IHJlYWxseSBhbiBvcHRpb24uIFRoZSBtb3N0IGdlbmVyaWMgc2NlbmFyaW8gYWRkcmVz c2VkIGhlcmUgaXMgZm9yIEFQSXMgdGhhdCBhY2NlcHQgdG9rZW5zIGlzc3VlZCBieSB0aGUgQVM7 DQogdGhlIGJhY2tlbmQgY2FuIHJlcXVlc3QgdGhlbSBhcyBhIGNsaWVudCwgYnV0IGl0IGNhbm5v dCBtaW50IHRoZW0uIEltYWdpbmUgd2XigJlyZSB0YWxraW5nIGFib3V0IGEgU1BBIGFwcGxpY2F0 aW9uIHRoYXQgc2lnbnMgaW4gdXNlcnMgdXNpbmcgQXp1cmUgQUQsIGFuZCBuZWVkcyB0byBjYWxs IE9mZmljZSBhbmQgQXp1cmUgQVBJcy4gVGhlIFNQQSBiYWNrZW5kIGNhbm5vdCBpc3N1ZSB0b2tl bnMgZm9yIHRob3NlIEFQSXMsIGl0IGNhbiBvbmx5IHJlcXVlc3QNCiB0aGVtIHRvIHRoZSBBenVy ZSBBRCBBUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9ImdtYWlsLW0tNTE2MzUz NjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEg bGZvNCI+DQpJZiB5b3Ugd2FudCB0byBhbGxvdyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJo YXBzIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgY2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNv ZGUgd2l0aCBhbiBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBu YXZpZ2F0ZXMgdGhlIHVzZXIgdG8uIChFZyB0aGUgYmFja2VuZCBjYW4gZG8gYSBQQVIgcmVxdWVz dCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJIHRoYXQgcmVmZXJlbmNlcw0KIHRoYXQgc28gdGhhdCBh dXRob3JpemF0aW9uIGRldGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5k KS4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2Ug ZGlkIGNvbnNpZGVyIGFkZGluZyBzb21ldGhpbmcgdG8gdGhhdCBlZmZlY3QsIGFuIGVycm9yIG1l c3NhZ2UgdGhhdCBjYW4gZGlyZWN0IHRoZSBmcm9udGVuZCB0byBwZXJmb3JtIHRoZSBpbnRlcmFj dGl2ZSBwb3J0aW9uIG5lY2Vzc2FyeSBmb3IgdGhpcyB0b3BvbG9neSB0byB3b3JrLiBJdCB3b3Vs ZCBiZQ0KIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoZSBJRFAgaW5pdGlhdGVkIGxvZ2luIGluIE9J REMsIHdoZXJlIHRoZSBjbGllbnQgb2ZmZXJzIGFuIGVuZHBvaW50IHRoYXQgaXMgZ3VhcmFudGVl ZCB0byBpbml0aWF0ZSBhIHNpZ24gaW4gZmxvdyAoaGVuY2UgaW5qZWN0IGFsbCB0aGUgbmVjZXNz YXJ5IG5vbmNlcyBldGMpLiBXZSBkaWRu4oCZdCBhZGQgaXQgdXBmcm9udCBhbmQgbGVmdCBpdCBh cyBleGVyY2lzZSBmb3IgdGhlIHJlYWRlciBtb3N0bHkgYmVjYXVzZQ0KIGl04oCZcyBub3QgZWFz eSB0byBtb2RlbCBwcm9wZXJseSBhbmQgYmVmb3JlIG9wZW5pbmcgdGhhdCB3b3JrIGZyb250IHdl IHdhbnRlZCB0byBzZWUgaG93IHRoZSBpZGVhIHdhcyByZWNlaXZlZC4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDs8YSBocmVm PSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTmVpbCBNYWRkZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIiB0YXJnZXQ9Il9ibGFuayI+bmVp bC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwg RmVicnVhcnkgMTQsIDIwMjEgYXQgMDA6MTc8YnI+DQo8Yj5UbzogPC9iPlZpdHRvcmlvIEJlcnRv Y2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaT08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5n IGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBhIGxvdCBvZiBzZWN1cml0eSBjb25j ZXJucyBhYm91dCB0aGlzIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJp dHkgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBoYW5kbGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBm cm9udGVuZCBidXQgbmV2ZXIgcmVhbGx5IHNwZWxscyB0aGVtIG91dC4gRnJvbSB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgaXQgc2VlbXMgdGhhdCB0aGUNCiBwcmltYXJ5IGNvbmNlcm4gaXMg d2l0aCB0aGVmdCBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gbG9jYWwgc3RvcmFnZS4gVG8gZG8gdGhp cyB5b3XigJlkIG5lZWQgYW4gWFNTIGF0dGFjay4gQnV0IGluIHRoYXQgY2FzZSwgd291bGRu4oCZ dCB0aGUgYXR0YWNrZXIgc2ltcGx5IHVzZSB0aGUgWFNTIHRvIG1ha2UgYSBjYWxsIHRvIHRoZSBi ZmYtdG9rZW4gZW5kcG9pbnQgaW5zdGVhZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjb21iaW5hdGlvbiBvZiB0aGUg YmZmLXRva2VuIGVuZHBvaW50IHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEdFVCByZXF1ZXN0cyB0 b2dldGhlciB3aXRoIHRoZSBoaW50IHRvIHVzZSBjb29raWUtYmFzZWQgYXV0aGVudGljYXRpb24g aXMgbGlrZWx5IGdvaW5nIHRvIHB1bmNoIGEgaG9sZSBpbiBtb3N0DQogQ1NSRiBkZWZlbnNlcywg d2hpY2ggYXNzdW1lIHRoYXQgR0VUcyBhcmUgc2FmZS4gVGhlIG9ubHkgdGhpbmcgcHJldmVudGlu ZyB0aGlzIGJlaW5nIGV4cGxvaXRhYmxlIGlzIENyb3NzLU9yaWdpbiBSZWFkIEJsb2NraW5nICg8 YSBocmVmPSJodHRwczovL2Nocm9taXVtLmdvb2dsZXNvdXJjZS5jb20vY2hyb21pdW0vc3JjLysv bWFzdGVyL3NlcnZpY2VzL25ldHdvcmsvY3Jvc3Nfb3JpZ2luX3JlYWRfYmxvY2tpbmdfZXhwbGFp bmVyLm1kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jaHJvbWl1bS5nb29nbGVzb3VyY2UuY29t L2Nocm9taXVtL3NyYy8rL21hc3Rlci9zZXJ2aWNlcy9uZXR3b3JrL2Nyb3NzX29yaWdpbl9yZWFk X2Jsb2NraW5nX2V4cGxhaW5lci5tZDwvYT4pDQogZHVlIHRvIHRoZSBKU09OIGNvbnRlbnQtdHlw ZS4gVGhhdCBtYWtlcyBtZSByZWFsbHkgbmVydm91cy4gV2Ugc2hvdWxkIGF0IGxlYXN0IG1hbmRh dGUgWC1Db250ZW50LVR5cGUtT3B0aW9uczogbm9zbmlmZiBvbiB0aGF0IHJlc3BvbnNlLiBJ4oCZ ZCBmZWVsIG1vcmUgY29tZm9ydGFibGUgaWYgdGhpcyB3YXMgYSBQT1NUIHJlcXVlc3Qgb25seS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFzIFN0b3ljaG8gU2xlcHRzb3YgbWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwg dGhlIGxhY2sgb2YgZnJvbnQtY2hhbm5lbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFu ZCB0aGUgUk8gc2VlbXMgb2RkLiBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkg dHJ1c3RlZCB0aGVuDQogY291bGRu4oCZdCB5b3Ugc2tpcCBPQXV0aCBhbmQganVzdCBnZXQgdGhl IGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgSldUcyB0byB0aGUgZnJvbnRlbmQgdGhhdCBp dCBjYW4gdXNlIGZvciBBUEkgYWNjZXNzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2Rl IGZsb3cgZXRjIHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4g YSBzdGFuZGFyZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkg dGhhdCB0aGUgU1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyDQogdG8uIChFZyB0aGUgYmFja2Vu ZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJIHRoYXQgcmVmZXJl bmNlcyB0aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7igJl0IHBhc3NlZCB0 aHJvdWdoIHRoZSBmcm9udGVuZCkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJQgTmVpbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+T24gMTIgRmViIDIwMjEsIGF0IDIwOjQ2LCBWaXR0b3JpbyBCZXJ0 b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7vu79EZWFyIGFsbCw8YnI+DQpCcmlhbiBhbmQg eW91cnMgdHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVjaWZpY2F0aW9uIHRoYXQgc2hvd3Mg aG93IHRoZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2ViIGFwcCBjYW4gZGVsZWdhdGUgdG9r ZW4gYWNxdWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0cyBiYWNrZW5kLCBhbmQgcmVxdWVz dCBzdWNoIHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0IGFjY2VzcyBvZiBwcm90ZWN0ZWQg cmVzb3VyY2VzIGZyb20gdGhlDQogZnJvbnRlbmQgY29kZS48YnI+DQo8YnI+DQpUaGUgcGF0dGVy biBpcyBhbHJlYWR5IGluIHVzZSwgaW4gcHJvcHJpZXRhcnkgZm9ybSwgYnkgdmFyaW91cyBtb2Rl cm4gZGV2ZWxvcG1lbnQgc3RhY2tzLCBzdWNoIGFzIE5leHQuSlMuIFZhcmlhbnRzIG9mIHRoZSBw YXR0ZXJuLCBvZnRlbiBkaXNjdXNzZWQgdW5kZXIgdGhlIGNhdGNoLWFsbCB0ZXJtIEJGRiAoYmFj a2VuZCBmb3IgZnJvbnRlbmQpLCBoYXZlIGJlZW4gb2Z0ZW4gbWVudGlvbmVkIGluIHRoaXMgd29y a2dyb3Vw4oCZcyBhY3Rpdml0eSwNCiBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9u IGRldGFpbHMgdG8gdGhlIHJlYWRlci48YnI+DQpXZSBiZWxpZXZlIHRoZSBwYXR0ZXJuIGhhcyBt ZXJpdCwgYXMgY29ycm9ib3JhdGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9uLiBCeSBkZWxlZ2F0 aW5nIGFjY2VzcyB0b2tlbiBhY3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwgd2UgYXZvaWQgbWFu eSBvZiB0aGUgb2Z0ZW4gYnJpdHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBsaWVkIGF0dGFjayBz dXJmYWNlKSByZXF1aXJlZCB0byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHVzZXIgYWdl bnQuDQogVGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhlIG5l ZWQgb2YgcGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3duIHNv cmUgcG9pbnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVseWlu ZyBvbiBpdHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vucy48 YnI+DQo8YnI+DQpBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBpcyB2ZXJ5IHNpbXBsZSwgcHJv dmlkaW5nIGV4cGxpY2l0IGd1aWRhbmNlIG9uIHRoZSBzY2VuYXJpbyBvZmZlcnMgbWFueSBhZHZh bnRhZ2VzLiAmbmJzcDs8YnI+DQotIEl0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGNyZWF0ZSBpbnRl cm9wZXJhYmxlIFNES3MsIHdoZXJlIGZyb250ZW5kIGRldiBzdGFja3MgKGFueSBKUyBmbGF2b3Ip IGNhbiBiZSBtaXhlZCBhbmQgbWF0Y2hlZCB3aXRoIGNvbXBsaWFudCBiYWNrZW5kIHN0YWNrcyAo bWlkZGxld2FyZXMgaW4gbm9kZSwgamF2YSwNCjxhIGhyZWY9Imh0dHA6Ly9BU1AuTkVUIiB0YXJn ZXQ9Il9ibGFuayI+QVNQLk5FVDwvYT4sIFBIUCBldGMpPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8g cHJvdmlkZSBndWlkYW5jZSBvbiBob3cgdG8gcHJvcGVybHkgdGFja2xlIHRoZSBzY2VuYXJpbyBh bmQgd2FybiBpbXBsZW1lbnRlcnMgYWdhaW5zdCBzZWN1cml0eSByaXNrcyAoc2NvcGUgZXNjYWxh dGlvbnMsIHVzaW5nIElEdG9rZW5zIGluc3RlYWQgb2YgYWNjZXNzIHRva2VucywgZXRjKTxicj4N Ci0gSXQgYWxsb3dzIHVzIHRvIGRpc2N1c3MgKGFuZCB3aGVuIGFwcHJvcHJpYXRlLCBwcm9tb3Rl KSB0aGlzIHBhdHRlcm4gYXMgcGFydCBvZiB0aGUgYnJvd3NlciBhcHBzIHNlY3VyaXR5IGd1aWRh bmNlLCBhbmQgcG9zaXRpb24gdGhlIHNjZW5hcmlvIHdoZXJlIGZyb250ZW5kIG9ubHkgY2FsbHMg QVBJIG9uIGl0cyBvd24gYmFja2VkIChoZW5jZSBkb2VzbuKAmXQgbmVlZCBhY2Nlc3MgdG9rZW5z KSBzaW1wbHkgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhpcw0KIG1vcmUgZ2VuZXJhbCBwYXR0ZXJu PGJyPg0KLSBUaGlzIGFwcHJvYWNoIG1ha2VzIG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5 IGVhc3ksIHBvc3NpYmx5IHByZXZlbnRpbmcgZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUg c2VjdXJpdHkgb2YgdGhlaXIgc3lzdGVtIChlZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykgJm5i c3A7b3IgdHVybmluZyB0byByaXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZzxicj4NCjxicj4N Ck5lZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXNu4oCZdCBlbnRpcmVseSBl bGltaW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1c2Ugb2YgYWNjZXNzIHRva2Vu cyBmcm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0aGUgcGF0dGVybiBpcyBpbiB3 aWRlc3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxlYWRpbmcgdG8gdGhhdCAoZWcg ZGV2ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdA0KIG9ubHkgd29yayB3aXRoIGZyb250 ZW5kIHN0YWNrczsgY29tcG9uZW50cyBsaWtlIHJldmVyc2UgcHJveGllcyBtaWdodCBub3QgYWx3 YXlzIGJlIHZpYWJsZTsgZXRjKSBhcmVu4oCZdCBnb2luZyBhd2F5IGFueSB0aW1lIHNvb24uIEJ5 IHByb3ZpZGluZyBzaW1wbGUgZ3VpZGFuY2Ugb24gdGhpcyBwYXR0ZXJuLCB3ZSBjYW4gc2ltcGxp ZnkgdGhlIGxpZmUgb2YgbWFueSBkZXZlbG9wZXJzIHdoaWxlIGVuc2hyaW5pbmcgYmFzaWMgc2Vj dXJpdHkgaHlnaWVuZQ0KIGluIHNjZW5hcmlvcyB0aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJl IGxlZnQgdG8gdGhlaXIgb3duIGRldmljZS48YnI+DQo8YnI+DQpMb29raW5nIGZvcndhcmQgZm9y IHlvdXIgZmVlZGJhY2shPGJyPg0KPGJyPg0KQiZhbXA7ViAmbmJzcDs8YnI+DQo8YnI+DQrvu79P biAyLzEyLzIxLCAxMjo0MSwgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVy dG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7aGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWaXR0b3JpbyBCZXJ0b2NjaSBhbmQgcG9zdGVk IHRvIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0lFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDtOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFm dC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1JldmlzaW9u OiAmbmJzcDsgJm5ic3A7MDA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaXRsZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7VG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9u IEJhY2tlbmQgRm9yIEZyb250ZW5kPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7RG9jdW1lbnQgZGF0 ZTogJm5ic3A7ICZuYnNwOzIwMjEtMDItMTI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtHcm91cDog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7UGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzE2PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9j Y2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0PC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1N0YXR1 czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgy LXRtaS1iZmYvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYvPC9hPjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwO0h0bWw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJh ZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYt MDAuaHRtbDwvYT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDtIdG1saXplZDogJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAw PC9hPjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0Fic3RyYWN0Ojxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGhvdyBhIEphdmFTY3JpcHQgZnJvbnRlbmQgY2FuIGRlbGVnYXRlIGFjY2Vzczxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Rva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFj a2VuZCBjb21wb25lbnQuJm5ic3A7IEluIHNvIGRvaW5nLCB0aGUgZnJvbnRlbmQ8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjYW4gYWNjZXNzIHJlc291cmNlIHNlcnZl cnMgZGlyZWN0bHkgd2l0aG91dCB0YWtpbmcgb24gdGhlIGJ1cmRlbiBvZjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbW11bmljYXRpbmcgd2l0aCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIsIHBlcnNpc3RpbmcgdG9rZW5zLCBhbmQ8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwZXJmb3JtaW5nIG9wZXJhdGlvbnMgdGhhdCBhcmUgZnJh dWdodCB3aXRoIHNlY3VyaXR5IGNoYWxsZW5nZXMgd2hlbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2V4ZWN1dGVkIGluIGEgdXNlciBhZ2VudCwgYnV0IGFyZSBzYWZl IGFuZCB3ZWxsIHByb3ZlbiB3aGVuIGV4ZWN1dGVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7YnkgYSBjb25maWRlbnRpYWwgY2xpZW50IHJ1bm5pbmcgb24gYSBiYWNr ZW5kLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1BsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb248YnI+DQombmJzcDsmbmJzcDsmbmJzcDt1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4N CiZuYnNwOyZuYnNwOyZuYnNwO1RoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9y OiMxNzJCNEQ7YmFja2dyb3VuZDp3aGl0ZSI+Rm9yZ2VSb2NrIHZhbHVlcyB5b3VyDQo8YSBocmVm PSJodHRwczovL3d3dy5mb3JnZXJvY2suY29tL3lvdXItcHJpdmFjeSIgdGFyZ2V0PSJfYmxhbmsi PlByaXZhY3k8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CO6PR18MB405252DBE4E8235AAD829067AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 04:35:23 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DB93A0957 for ; Sun, 14 Feb 2021 04:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9an3KFpOCmG for ; Sun, 14 Feb 2021 04:35:20 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1F43A094E for ; Sun, 14 Feb 2021 04:35:20 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id t26so2688922pgv.3 for ; Sun, 14 Feb 2021 04:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=MGfH469y7PRTdQP9swXh+GG6qakvXEQ/HwKXsw/vykc=; b=itmFf6qfF/zkZJ9Tqn4OBIJXZekyFJRT/aEiIlG8nK7mYA0FUdlwpFGvlswzvBdbN0 zNhKkXv6hK02J1WJXNPmUwgLHnGE461U3fKOl+qlfVsdEOPT3axNVGlVfP484Nftwk66 dXF9AUmUK8DttgpijKghEbS/DADpDmnH8O5h208ZwTmvdWm/DTU2LmPTr0zwLKhLu/1M 3XOtmh3DOpbJHOGaPUjTc4agTyH1DvriGcyKvQJF85et3vahk8GPv+b9xUCxLKv0uC/v PEf3O/ICwo3xzs8U9wGl6SXe2YXPYe361yBGuNTExvh6sNWSiq3WZKe4e26pjgMtytGO XlKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :mime-version; bh=MGfH469y7PRTdQP9swXh+GG6qakvXEQ/HwKXsw/vykc=; b=p1eLYJ4U0/sPbVJAXq0mhZEtHTTWIoA2MxE0RFtic/u5sF2deCPxukS9V1lLDn0riO mxeFEh6cKojjm48yOe02ixUytkncR5t+mLaFkFchXJ1P6j/Ka8Gd47CeBg4R6lhVxCgy asy6nJ6u5PNXhc7Lf0aQpvSlPoEd9xFqgRFwWuXYIFMXxBynPTCsayatoMEcip/2i8QX u+ziEaCRnBbdUndwkvANHuUxYlIInc1XdEC2hJ7tkPRz+YlL6T4hDc1LsVDUf9dFfSN0 9tXqg6ORt/c4NpamI5JSdN/PzfKneCGl2akoWDpo1CrYl/zxfDjdXn5FSN3WKO+lCLKk mTJw== X-Gm-Message-State: AOAM5319/+zxJ4M1fd6uaHSiqIQtnsyjzI2Mlg5WhYgKM5BO0D1c6V6+ LmSMcShBKFXLRhUIVt2Ty6a7Eg== X-Google-Smtp-Source: ABdhPJz+zzccRaDOLYhZbR6Q4tvHhzt9fWZlnsAubzUNleylicJo2XNF9ElmlOwGWQ/EKirvDgfslw== X-Received: by 2002:a65:4088:: with SMTP id t8mr11270643pgp.296.1613306119946; Sun, 14 Feb 2021 04:35:19 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id dw23sm13369251pjb.3.2021.02.14.04.35.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 04:35:19 -0800 (PST) From: Vittorio Bertocci To: Dominick Baier , Brian Campbell , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXkIgAgAAIK/U= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 12:35:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052F1E9375F3CB62A10DFB9AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:35:23 -0000 --_000_CO6PR18MB4052F1E9375F3CB62A10DFB9AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdCwgdGhlIGFjY2VzcyB0b2tlbiBlbmRzIHVwIGluIHRoZSBKYXZhU2NyaXB0IOKAkyB0 aGUgb3V0Y29tZSBpcyB0aGUgc2FtZSBhcyBjb2RlK1BLQ0UsIHRoZSBhY2Nlc3MgdG9rZW4gZW5k IHVwIGluIHRoZSB1c2VyIGFnZW50LiBUaGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoYXQgc29tZSBv ZiB0aGUgZnVuY3Rpb25hbGl0eSBpcyBub3cgb3V0c291cmNlZCB0byB0aGUgYmFja2VuZCBidXQg dGhlIGNhbGxzIHRvIHRoZSBSUyBzdGlsbCB0YWtlIHBsYWNlIGZyb20gdGhlIHVzZXIgYWdlbnQu DQoNCkZyb206IERvbWluaWNrIEJhaWVyIDxkYmFpZXJAbGVhc3Rwcml2aWxlZ2UuY29tPg0KRGF0 ZTogU3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwNDowNg0KVG86IFZpdHRvcmlvIEJlcnRv Y2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+LCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20+LCAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZv cm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KSGksDQoNCkp1c3QgbWFr aW5nIHN1cmUgSSB1bmRlcnN0YW5kIC0gaW4geW91ciBwcm90b2NvbCBmbG93IGRpYWdyYW0gc3Rl cCBEIGl0IGxvb2tzIGxpa2UgdGhhdCB0aGUgQkZGIGlzIHJldHVybmluZyB0aGUgYWNjZXNzIHRv a2VuIHRvIHRoZSBmcm9udC1lbmQuIElzIHRoYXQgY29ycmVjdD8NCg0KTXkgYmlnZ2VzdCBjb25j ZXJuIHdpdGggYnJvd3Nlci1iYXNlZCBhcHBsaWNhdGlvbnMgaXMgdGhhdCB0aGUgSmF2YVNjcmlw dCAvIGJyb3dzZXIgaGFzIGFjY2VzcyB0byB0aGUgYWNjZXNzIHRva2VuIChkb27igJl0IGNhcmUg aWYgaXQgaXMgaW4tbWVtb3J5IG9yIGxvY2FsIHN0b3JhZ2UpIC0gYnV0IHRoaXMgZXhhY3RseSBz ZWVtcyB0byBoYXBwZW4gaW4gRC4NCg0KVGhhbmtzDQrigJTigJTigJQNCkRvbWluaWNrIEJhaWVy DQoNCg0KT24gMTIuIEZlYnJ1YXJ5IDIwMjEgYXQgMjE6NDY6MjAsIFZpdHRvcmlvIEJlcnRvY2Np ICh2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86dml0 dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+KSB3cm90ZToNCkRlYXIg YWxsLA0KQnJpYW4gYW5kIHlvdXJzIHRydWx5IGFyZSBwcm9wb3NpbmcgYSBuZXcgc3BlY2lmaWNh dGlvbiB0aGF0IHNob3dzIGhvdyB0aGUgdXNlciBhZ2VudCBmcm9udGVuZCBvZiBhIHdlYiBhcHAg Y2FuIGRlbGVnYXRlIHRva2VuIGFjcXVpc2l0aW9uIGFuZCBwZXJzaXN0ZW5jZSB0byBpdHMgYmFj a2VuZCwgYW5kIHJlcXVlc3Qgc3VjaCB0b2tlbnMgd2hlbiBuZWVkZWQgZm9yIGRpcmVjdCBhY2Nl c3Mgb2YgcHJvdGVjdGVkIHJlc291cmNlcyBmcm9tIHRoZSBmcm9udGVuZCBjb2RlLg0KDQpUaGUg cGF0dGVybiBpcyBhbHJlYWR5IGluIHVzZSwgaW4gcHJvcHJpZXRhcnkgZm9ybSwgYnkgdmFyaW91 cyBtb2Rlcm4gZGV2ZWxvcG1lbnQgc3RhY2tzLCBzdWNoIGFzIE5leHQuSlMuIFZhcmlhbnRzIG9m IHRoZSBwYXR0ZXJuLCBvZnRlbiBkaXNjdXNzZWQgdW5kZXIgdGhlIGNhdGNoLWFsbCB0ZXJtIEJG RiAoYmFja2VuZCBmb3IgZnJvbnRlbmQpLCBoYXZlIGJlZW4gb2Z0ZW4gbWVudGlvbmVkIGluIHRo aXMgd29ya2dyb3Vw4oCZcyBhY3Rpdml0eSwgYnV0IGFsd2F5cyBsZWZ0IGFsbCBpbXBsZW1lbnRh dGlvbiBkZXRhaWxzIHRvIHRoZSByZWFkZXIuDQpXZSBiZWxpZXZlIHRoZSBwYXR0ZXJuIGhhcyBt ZXJpdCwgYXMgY29ycm9ib3JhdGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9uLiBCeSBkZWxlZ2F0 aW5nIGFjY2VzcyB0b2tlbiBhY3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwgd2UgYXZvaWQgbWFu eSBvZiB0aGUgb2Z0ZW4gYnJpdHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBsaWVkIGF0dGFjayBz dXJmYWNlKSByZXF1aXJlZCB0byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHVzZXIgYWdl bnQuIFRoZSB0b3BvbG9neSBhbHNvIHJlbGlldmVzIHRoZSBmcm9udGVuZCBmcm9tIHRoZSBuZWVk IG9mIHBlcnNpc3RpbmcgdG9rZW5zIGluIGxvY2FsIHN0b3JhZ2UsIGEgd2VsbCBrbm93biBzb3Jl IHBvaW50IG9mIHVzaW5nIE9BdXRoIGRpcmVjdGx5IGluIEphdmFTY3JpcHQsIGJ5IHJlbHlpbmcg b24gaXRzIGJhY2tlbmQgc3RvcmFnZSBhbmQgc2Vzc2lvbiB0byBwcmVzZXJ2ZSB0b2tlbnMuDQoN CkFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHZlcnkgc2ltcGxlLCBwcm92aWRpbmcgZXhw bGljaXQgZ3VpZGFuY2Ugb24gdGhlIHNjZW5hcmlvIG9mZmVycyBtYW55IGFkdmFudGFnZXMuDQot IEl0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGNyZWF0ZSBpbnRlcm9wZXJhYmxlIFNES3MsIHdoZXJl IGZyb250ZW5kIGRldiBzdGFja3MgKGFueSBKUyBmbGF2b3IpIGNhbiBiZSBtaXhlZCBhbmQgbWF0 Y2hlZCB3aXRoIGNvbXBsaWFudCBiYWNrZW5kIHN0YWNrcyAobWlkZGxld2FyZXMgaW4gbm9kZSwg amF2YSwgQVNQLk5FVDxodHRwOi8vQVNQLk5FVD4sIFBIUCBldGMpDQotIEl0IGFsbG93cyB1cyB0 byBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9wZXJseSB0YWNrbGUgdGhlIHNjZW5hcmlv IGFuZCB3YXJuIGltcGxlbWVudGVycyBhZ2FpbnN0IHNlY3VyaXR5IHJpc2tzIChzY29wZSBlc2Nh bGF0aW9ucywgdXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBvZiBhY2Nlc3MgdG9rZW5zLCBldGMpDQot IEl0IGFsbG93cyB1cyB0byBkaXNjdXNzIChhbmQgd2hlbiBhcHByb3ByaWF0ZSwgcHJvbW90ZSkg dGhpcyBwYXR0ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dzZXIgYXBwcyBzZWN1cml0eSBndWlkYW5j ZSwgYW5kIHBvc2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVyZSBmcm9udGVuZCBvbmx5IGNhbGxzIEFQ SSBvbiBpdHMgb3duIGJhY2tlZCAoaGVuY2UgZG9lc27igJl0IG5lZWQgYWNjZXNzIHRva2Vucykg c2ltcGx5IGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMgbW9yZSBnZW5lcmFsIHBhdHRlcm4NCi0g VGhpcyBhcHByb2FjaCBtYWtlcyBtb2NraW5nIGFuZCB0ZXN0aW5nIGFwcHMgdmVyeSBlYXN5LCBw b3NzaWJseSBwcmV2ZW50aW5nIGRldmVsb3BlcnMgZnJvbSB3ZWFrZW5pbmcgdGhlIHNlY3VyaXR5 IG9mIHRoZWlyIHN5c3RlbSAoZWcgdHVybmluZyBvbiBST1BHIG9wdGlvbnMpIG9yIHR1cm5pbmcg dG8gcmlza3kgcHJhY3RpY2VzIGxpa2Ugc2NyYXBpbmcNCg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlz IHNwZWNpZmljYXRpb24gZG9lc27igJl0IGVudGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlza3MgaW5o ZXJlbnQgdG8gZGlyZWN0IHVzZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gYSBicm93c2VyLiBCdXQg cmVhbGl0eSBpcyB0aGF0IHRoZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhl IGNpcmN1bXN0YW5jZXMgbGVhZGluZyB0byB0aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEgcGFydGlj dWxhciBwcm9qZWN0IG9ubHkgd29yayB3aXRoIGZyb250ZW5kIHN0YWNrczsgY29tcG9uZW50cyBs aWtlIHJldmVyc2UgcHJveGllcyBtaWdodCBub3QgYWx3YXlzIGJlIHZpYWJsZTsgZXRjKSBhcmVu 4oCZdCBnb2luZyBhd2F5IGFueSB0aW1lIHNvb24uIEJ5IHByb3ZpZGluZyBzaW1wbGUgZ3VpZGFu Y2Ugb24gdGhpcyBwYXR0ZXJuLCB3ZSBjYW4gc2ltcGxpZnkgdGhlIGxpZmUgb2YgbWFueSBkZXZl bG9wZXJzIHdoaWxlIGVuc2hyaW5pbmcgYmFzaWMgc2VjdXJpdHkgaHlnaWVuZSBpbiBzY2VuYXJp b3MgdGhhdCB3b3VsZCBoYXZlIG90aGVyd2lzZSBiZSBsZWZ0IHRvIHRoZWlyIG93biBkZXZpY2Uu DQoNCkxvb2tpbmcgZm9yd2FyZCBmb3IgeW91ciBmZWVkYmFjayENCg0KQiZWDQoNCu+7v09uIDIv MTIvMjEsIDEyOjQxLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFZpdHRvcmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmDQpSZXZpc2lv bjogMDANClRpdGxlOiBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFj a2VuZCBGb3IgRnJvbnRlbmQNCkRvY3VtZW50IGRhdGU6IDIwMjEtMDItMTINCkdyb3VwOiBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAxNg0KVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dA0KU3RhdHVzOiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1p LWJmZi8NCkh0bWw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9j Y2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRtbA0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMA0KDQoNCkFic3RyYWN0Og0K VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4gZGVs ZWdhdGUgYWNjZXNzDQp0b2tlbiBhY3F1aXNpdGlvbiB0byBhIGJhY2tlbmQgY29tcG9uZW50LiBJ biBzbyBkb2luZywgdGhlIGZyb250ZW5kDQpjYW4gYWNjZXNzIHJlc291cmNlIHNlcnZlcnMgZGly ZWN0bHkgd2l0aG91dCB0YWtpbmcgb24gdGhlIGJ1cmRlbiBvZg0KY29tbXVuaWNhdGluZyB3aXRo IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0b2tlbnMsIGFuZA0KcGVyZm9y bWluZyBvcGVyYXRpb25zIHRoYXQgYXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2Vz IHdoZW4NCmV4ZWN1dGVkIGluIGEgdXNlciBhZ2VudCwgYnV0IGFyZSBzYWZlIGFuZCB3ZWxsIHBy b3ZlbiB3aGVuIGV4ZWN1dGVkDQpieSBhIGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBh IGJhY2tlbmQuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDov L3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_CO6PR18MB4052F1E9375F3CB62A10DFB9AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1z dHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29ycmVjdCwgdGhlIGFjY2VzcyB0b2tlbiBlbmRzIHVwIGlu IHRoZSBKYXZhU2NyaXB0IOKAkyB0aGUgb3V0Y29tZSBpcyB0aGUgc2FtZSBhcyBjb2RlK1BLQ0Us IHRoZSBhY2Nlc3MgdG9rZW4gZW5kIHVwIGluIHRoZSB1c2VyIGFnZW50LiBUaGUgbWFpbiBkaWZm ZXJlbmNlIGlzIHRoYXQgc29tZSBvZiB0aGUgZnVuY3Rpb25hbGl0eSBpcyBub3cgb3V0c291cmNl ZCB0byB0aGUgYmFja2VuZCBidXQgdGhlIGNhbGxzDQogdG8gdGhlIFJTIHN0aWxsIHRha2UgcGxh Y2UgZnJvbSB0aGUgdXNlciBhZ2VudC4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Eb21pbmljayBCYWllciAmbHQ7ZGJhaWVyQGxlYXN0cHJpdmlsZWdlLmNvbSZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwNDowNjxi cj4NCjxiPlRvOiA8L2I+Vml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1 dGgwLmNvbSZndDssIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSZndDssICZxdW90O29hdXRoQGlldGYub3JnJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBz ZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5IaSwmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+SnVzdCBtYWtpbmcgc3VyZSBJIHVuZGVyc3RhbmQgLSBpbiB5b3VyIHByb3RvY29sIGZs b3cgZGlhZ3JhbSBzdGVwIEQgaXQgbG9va3MgbGlrZSB0aGF0IHRoZSBCRkYgaXMgcmV0dXJuaW5n IHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGZyb250LWVuZC4gSXMgdGhhdCBjb3JyZWN0PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5N eSBiaWdnZXN0IGNvbmNlcm4gd2l0aCBicm93c2VyLWJhc2VkIGFwcGxpY2F0aW9ucyBpcyB0aGF0 IHRoZSBKYXZhU2NyaXB0IC8gYnJvd3NlciBoYXMgYWNjZXNzIHRvIHRoZSBhY2Nlc3MgdG9rZW4g KGRvbuKAmXQgY2FyZSBpZiBpdCBpcyBpbi1tZW1vcnkgb3IgbG9jYWwgc3RvcmFnZSkgLSBidXQg dGhpcyBleGFjdGx5DQogc2VlbXMgdG8gaGFwcGVuIGluIEQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoYW5rczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlOKAlOKA lDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbWluaWNrIEJh aWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj5PbiAxMi4gRmVicnVh cnkgMjAyMSBhdCAyMTo0NjoyMCwgVml0dG9yaW8gQmVydG9jY2kgKDxhIGhyZWY9Im1haWx0bzp2 aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyI+dml0dG9yaW8uYmVy dG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCwgPGJyPg0K QnJpYW4gYW5kIHlvdXJzIHRydWx5IGFyZSBwcm9wb3NpbmcgYSBuZXcgc3BlY2lmaWNhdGlvbiB0 aGF0IHNob3dzIGhvdyB0aGUgdXNlciBhZ2VudCBmcm9udGVuZCBvZiBhIHdlYiBhcHAgY2FuIGRl bGVnYXRlIHRva2VuIGFjcXVpc2l0aW9uIGFuZCBwZXJzaXN0ZW5jZSB0byBpdHMgYmFja2VuZCwg YW5kIHJlcXVlc3Qgc3VjaCB0b2tlbnMgd2hlbiBuZWVkZWQgZm9yIGRpcmVjdCBhY2Nlc3Mgb2Yg cHJvdGVjdGVkIHJlc291cmNlcyBmcm9tIHRoZQ0KIGZyb250ZW5kIGNvZGUuIDxicj4NCjxicj4N ClRoZSBwYXR0ZXJuIGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2 YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFu dHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRl cm0gQkZGIChiYWNrZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQg aW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFjdGl2aXR5LA0KIGJ1dCBhbHdheXMgbGVmdCBhbGwgaW1w bGVtZW50YXRpb24gZGV0YWlscyB0byB0aGUgcmVhZGVyLiA8YnI+DQpXZSBiZWxpZXZlIHRoZSBw YXR0ZXJuIGhhcyBtZXJpdCwgYXMgY29ycm9ib3JhdGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9u LiBCeSBkZWxlZ2F0aW5nIGFjY2VzcyB0b2tlbiBhY3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwg d2UgYXZvaWQgbWFueSBvZiB0aGUgb2Z0ZW4gYnJpdHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBs aWVkIGF0dGFjayBzdXJmYWNlKSByZXF1aXJlZCB0byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJv bSBhIHVzZXIgYWdlbnQuDQogVGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5k IGZyb20gdGhlIG5lZWQgb2YgcGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3 ZWxsIGtub3duIHNvcmUgcG9pbnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlw dCwgYnkgcmVseWluZyBvbiBpdHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNl cnZlIHRva2Vucy4NCjxicj4NCjxicj4NCkFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHZl cnkgc2ltcGxlLCBwcm92aWRpbmcgZXhwbGljaXQgZ3VpZGFuY2Ugb24gdGhlIHNjZW5hcmlvIG9m ZmVycyBtYW55IGFkdmFudGFnZXMuDQo8YnI+DQotIEl0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGNy ZWF0ZSBpbnRlcm9wZXJhYmxlIFNES3MsIHdoZXJlIGZyb250ZW5kIGRldiBzdGFja3MgKGFueSBK UyBmbGF2b3IpIGNhbiBiZSBtaXhlZCBhbmQgbWF0Y2hlZCB3aXRoIGNvbXBsaWFudCBiYWNrZW5k IHN0YWNrcyAobWlkZGxld2FyZXMgaW4gbm9kZSwgamF2YSwNCjxhIGhyZWY9Imh0dHA6Ly9BU1Au TkVUIj5BU1AuTkVUPC9hPiwgUEhQIGV0YykgPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8gcHJvdmlk ZSBndWlkYW5jZSBvbiBob3cgdG8gcHJvcGVybHkgdGFja2xlIHRoZSBzY2VuYXJpbyBhbmQgd2Fy biBpbXBsZW1lbnRlcnMgYWdhaW5zdCBzZWN1cml0eSByaXNrcyAoc2NvcGUgZXNjYWxhdGlvbnMs IHVzaW5nIElEdG9rZW5zIGluc3RlYWQgb2YgYWNjZXNzIHRva2VucywgZXRjKQ0KPGJyPg0KLSBJ dCBhbGxvd3MgdXMgdG8gZGlzY3VzcyAoYW5kIHdoZW4gYXBwcm9wcmlhdGUsIHByb21vdGUpIHRo aXMgcGF0dGVybiBhcyBwYXJ0IG9mIHRoZSBicm93c2VyIGFwcHMgc2VjdXJpdHkgZ3VpZGFuY2Us IGFuZCBwb3NpdGlvbiB0aGUgc2NlbmFyaW8gd2hlcmUgZnJvbnRlbmQgb25seSBjYWxscyBBUEkg b24gaXRzIG93biBiYWNrZWQgKGhlbmNlIGRvZXNu4oCZdCBuZWVkIGFjY2VzcyB0b2tlbnMpIHNp bXBseSBhcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGlzDQogbW9yZSBnZW5lcmFsIHBhdHRlcm4gPGJy Pg0KLSBUaGlzIGFwcHJvYWNoIG1ha2VzIG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5IGVh c3ksIHBvc3NpYmx5IHByZXZlbnRpbmcgZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUgc2Vj dXJpdHkgb2YgdGhlaXIgc3lzdGVtIChlZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykgb3IgdHVy bmluZyB0byByaXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZw0KPGJyPg0KPGJyPg0KTmVlZGxl c3MgdG8gc2F5LCB0aGlzIHNwZWNpZmljYXRpb24gZG9lc27igJl0IGVudGlyZWx5IGVsaW1pbmF0 ZSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gZGlyZWN0IHVzZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20g YSBicm93c2VyLiBCdXQgcmVhbGl0eSBpcyB0aGF0IHRoZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJl YWQgdXNlLCBhbmQgdGhlIGNpcmN1bXN0YW5jZXMgbGVhZGluZyB0byB0aGF0IChlZyBkZXZlbG9w ZXJzIG9uIGEgcGFydGljdWxhciBwcm9qZWN0DQogb25seSB3b3JrIHdpdGggZnJvbnRlbmQgc3Rh Y2tzOyBjb21wb25lbnRzIGxpa2UgcmV2ZXJzZSBwcm94aWVzIG1pZ2h0IG5vdCBhbHdheXMgYmUg dmlhYmxlOyBldGMpIGFyZW7igJl0IGdvaW5nIGF3YXkgYW55IHRpbWUgc29vbi4gQnkgcHJvdmlk aW5nIHNpbXBsZSBndWlkYW5jZSBvbiB0aGlzIHBhdHRlcm4sIHdlIGNhbiBzaW1wbGlmeSB0aGUg bGlmZSBvZiBtYW55IGRldmVsb3BlcnMgd2hpbGUgZW5zaHJpbmluZyBiYXNpYyBzZWN1cml0eSBo eWdpZW5lDQogaW4gc2NlbmFyaW9zIHRoYXQgd291bGQgaGF2ZSBvdGhlcndpc2UgYmUgbGVmdCB0 byB0aGVpciBvd24gZGV2aWNlLiA8YnI+DQo8YnI+DQpMb29raW5nIGZvcndhcmQgZm9yIHlvdXIg ZmVlZGJhY2shIDxicj4NCjxicj4NCkImYW1wO1YgPGJyPg0KPGJyPg0K77u/T24gMi8xMi8yMSwg MTI6NDEsICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOg0KPGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJlcnRv Y2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dCA8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFZpdHRvcmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlIDxicj4NCklFVEYg cmVwb3NpdG9yeS4gPGJyPg0KPGJyPg0KTmFtZTogZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1i ZmYgPGJyPg0KUmV2aXNpb246IDAwIDxicj4NClRpdGxlOiBUb2tlbiBNZWRpYXRpbmcgYW5kIHNl c3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgPGJyPg0KRG9jdW1lbnQgZGF0 ZTogMjAyMS0wMi0xMiA8YnI+DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uIDxicj4NClBh Z2VzOiAxNiA8YnI+DQpVUkw6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUv aWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0Ij4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0PC9h PiA8YnI+DQpTdGF0dXM6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi88L2E+IDxicj4NCkh0bWw6 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2kt b2F1dGgyLXRtaS1iZmYtMDAuaHRtbCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lk L2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLmh0bWw8L2E+IDxicj4NCkh0bWxpemVk OiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2ktb2F1 dGgyLXRtaS1iZmYtMDAiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcnRv Y2NpLW9hdXRoMi10bWktYmZmLTAwPC9hPiA8YnI+DQo8YnI+DQo8YnI+DQpBYnN0cmFjdDogPGJy Pg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4g ZGVsZWdhdGUgYWNjZXNzIDxicj4NCnRva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2VuZCBjb21w b25lbnQuIEluIHNvIGRvaW5nLCB0aGUgZnJvbnRlbmQgPGJyPg0KY2FuIGFjY2VzcyByZXNvdXJj ZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBidXJkZW4gb2YgPGJyPg0K Y29tbXVuaWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0 b2tlbnMsIGFuZCA8YnI+DQpwZXJmb3JtaW5nIG9wZXJhdGlvbnMgdGhhdCBhcmUgZnJhdWdodCB3 aXRoIHNlY3VyaXR5IGNoYWxsZW5nZXMgd2hlbiA8YnI+DQpleGVjdXRlZCBpbiBhIHVzZXIgYWdl bnQsIGJ1dCBhcmUgc2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZCA8YnI+DQpieSBh IGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQuIDxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gPGJyPg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmciPg0KdG9vbHMuaWV0Zi5vcmc8L2E+LiA8YnI+DQo8YnI+DQpUaGUgSUVURiBT ZWNyZXRhcmlhdCA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CO6PR18MB4052F1E9375F3CB62A10DFB9AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 04:54:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E263A0A02 for ; Sun, 14 Feb 2021 04:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjiyeil-0jdo for ; Sun, 14 Feb 2021 04:53:58 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60BD43A09B9 for ; Sun, 14 Feb 2021 04:53:58 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id a4so1104137pgc.11 for ; Sun, 14 Feb 2021 04:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=b673eCyCECRLnVEg9M8oYQzhwdSZDvj1sce5ugMndoI=; b=dVAlnvmKVXk+edrUjzoegkCh7lIMyA9toXOz/fak15Rnq3GJ9rbriK3e2tv9E43KLE Rn0dIJlyZZllZ6njrP5cQyKmftcN96bxX5HpqAL3wh2CnlbKGReIGhYS0G9tKGSglsse gnu1O5nV7t2aGCf8slR220/lq35F2A/y2+UrEmXkeh+px5fldywtiB3qIQS9eAKA89OY +GnkXoGow8w5h8HzZTmB5bWzConJNQzGBcS27eo5xmQTXFFKV9iS1Khy0nuxgla4GMg+ OmSQx7B6mYGCtugH19UoWh7g8MUiheIUK2o+lp4GdlW5ps6CYI0YWFQ/GnB8OYRGPXsX BQ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=b673eCyCECRLnVEg9M8oYQzhwdSZDvj1sce5ugMndoI=; b=kZaT51CO9gTsUOv3A/wFsUntxM3UpRAoVbcOYFx55wGrO4QCNddqltTFAnCt8SLd8k 3DNy8dZVUG9aROUvX5VQeXT/L3uoEf3jGakuybGenID4ydzrwGDV8ocoCeUsTpQEBQZf 7MPs0NlvbX1mjwWoFvWpxmCE6vzQA+OrQAT4U32P6UQwd8xtr6sJ87hqMIhozsqI/nxQ UnYsrxd1UM9dyDMniQkfJ7gu8r//AX3TEtdGJQbbTcHEqD6vEU2WBjDUm9zEOkeMP1Nc LVcaFFabsmi+xwKX/jriV7ayJbiqBN1Fy8nBVc8+MvG7RHolSrg8q7nBLHuyL+qQhzJK i5pQ== X-Gm-Message-State: AOAM531HMvPrJNQulFEGJw8xg2bXXpIZ+O5HvADC6hgYCEGFhOiAK/Kc qUJM9pJcpkdpFvmqVCG8cP2ezQ== X-Google-Smtp-Source: ABdhPJz90W99XA76QXGdmfzVCNy7N44NvFGIzIHMO3RxPPpAJe2Fzdoasq6GtBY+nLMJL24284sWsg== X-Received: by 2002:a05:6a00:2296:b029:1b6:6972:2f2a with SMTP id f22-20020a056a002296b02901b669722f2amr10988363pfe.69.1613307237563; Sun, 14 Feb 2021 04:53:57 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id nl12sm15424017pjb.2.2021.02.14.04.53.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 04:53:56 -0800 (PST) From: Vittorio Bertocci To: Warren Parad , Neil Madden CC: oauth Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAAaNoCAACuILIAAB2qx X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 12:53:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052FF780E71AE2FF62B173EAE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:54:02 -0000 --_000_CO6PR18MB4052FF780E71AE2FF62B173EAE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHRoaW5nIEkgc2hvdWxkIGFkZCBoZXJlLCBhbmQgdGhlbiBJ4oCZbGwgaGVhZCB0byBiZWQg Z2l2ZW4gdGhhdCBpdOKAmXMgYWxtb3N0IDVhbSBoZXJlIPCfmIotDQpJIGFtIGZ1bGx5IGJlaGlu ZCBjb2RlK1BLQ0UuIEF1dGgwIGhhcyBiZWVuIHN1cHBvcnRpbmcgY29kZStQS0NFIGluIGl0cyBK UyBTUEEgU0RLcywgaW5jbHVkaW5nIHJlZnJlc2ggdG9rZW4gcm90YXRpb24gc3VwcG9ydCwgc2lu Y2UgZWFybHkgbGFzdCB5ZWFyLg0KSSBzdHJlc3MgdGhpcyBzbyB0aGF0IG5vIG9uZSB0aGlua3Mg dGhpcyBhbiBhdHRlbXB0IHRvIGdldCBvdXQgb2Ygc3VwcG9ydGluZyBjb2RlK1BLQ0UsIGl04oCZ cyBub3QuIEZvciB0cnVlIFNQQXMgKG5vIGJhY2tlbmQpIHRoYXQgcmVtYWlucyB0aGUgbWFpbiB3 YXkgZm9yIGVuYWJsaW5nIGZyb250ZW50cyB0byBjYWxsIEFQSS4gVGhpcyBpcyAgbW9yZSBhYm91 dCB0cnlpbmcgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIHByZXNlbmNlIG9mIHRoZSBiYWNrZW5k IHRvIG1ha2UgdGhpbmdzIHNpbXBsZXIgd2hlbiB2aWFibGUsIGFuZCB0byBicmluZyBzb21lIGd1 aWRhbmNlIHRvIGVtZXJnaW5nIHByYWN0aWNlcyB0aGF0IHJpc2sgZHJpZnRpbmcgaW50byBpbnNl Y3VyZSB3YXRlcnMgd2l0aG91dCBpdC4NCg0KRnJvbTogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRv cmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEg YXQgMDQ6MjcNClRvOiBXYXJyZW4gUGFyYWQgPHdwYXJhZD00MHJob3N5cy5jaEBkbWFyYy5pZXRm Lm9yZz4sIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPg0KQ2M6IG9hdXRo IDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGlu ZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikN Cg0KSGkgV2FycmVuLCB0aGFua3MgZm9yIHRoZSB0aG91Z2h0ZnVsIGNvbW1lbnRzLg0KSW5saW5l Lg0KDQoNCiAgKiAgIC4gSXQgaW50cm9kdWNlcyBhIHBzZXVkbyBBUy1saWtlIHByb3h5IHdoaWNo IG5vdyBoYXMgYWxsIHRoZSByZXF1aXJlbWVudHMgb2YgYW4gQVMgYW5kIG1vcmUuIFdoaWxlIEFT IFNES3MgcHJvdmlkZSBlYXN5IHdheXMgZm9yIGNsaWVudCBVSXMgdG8gZWZmZWN0aXZlbHkgZGVh bCB3aXRoIGNvbW11bmljYXRpb24gdmlhIHRoZSBBUywgdGhlcmUncyBubyB3YXkgZm9yIHRoZSBB UyB0byBwcm92aWRlIHN0YW5kYXJkIEFTIHNwZWNpZmljIHNlcnZpY2VzIHByb3RvdHlwZXMgdG8g c3VwcG9ydCBCRkYuIFRoYXQgbWVhbnMgdGhhdCBldmVyeW9uZSBpcyB3cml0aW5nIHRoZWlyIG93 biBCRkYgQVMtcHJveHkuDQpUTUktQkZGIGRvZXMgcHJvdmlkZSBhIHNvcnQgb2YgcHJveHkgZm9y IHRoZSBBUywgYnV0IGl0IGlzIHZlcnkgY29uc3RyYWluZWQgYm90aCBpbiBmdW5jdGlvbmFsaXR5 IChvbmx5IG9uZSBzaW1wbGUgcmVxdWVzdCB0eXBlKSBhbmQgdG9wb2xvZ3kgKG9ubHkgb25lIHJl cXVlc3RvciB0eXBlLCB3aXRoIGFzc3VtcHRpb25zIGFib3V0IHNlc3Npb25zLCBvcmlnaW4gcHJv dmVuYW5jZSBldGMpIGhlbmNlIHRoZSByZXF1aXJlbWVudHMgYXJlIGEgdmVyeSBsaW1pdGVkIHN1 YnNldCBvZiBhIGZ1bGwgYmxvd24gQVMuDQpJbiB0ZXJtcyBvZiBldmVyeW9uZSBkb2luZyB0aGVp ciBvd24gaW1wbGVtZW50YXRpb24sIHRoZSBpbnRlbnQgaGVyZSBpcyB0aGUgZXhhY3Qgb3Bwb3Np dGUuIEJ5IHByb3ZpZGluZyBndWlkYW5jZSBvbiBob3cgdG8gZm9ybWF0IHJlcXVlc3RzL3Jlc3Bv bnNlcyBhbmQgd2hhdCBlbmRwb2ludHMgdG8gcmVmZXIgdG8sIHRoZSBpbXBsZW1lbnRhdGlvbiBk ZXRhaWxzIGNhbiBiZSBmYWN0b3JlZCBvdXQgZnJvbSBpbmRpdmlkdWFsIGFwcHMgYW5kIHN0YWNr cywgZmFjaWxpdGF0aW5nIGludGVyb3BlcmFiaWxpdHkuDQoNCg0KICAqICAgWy4uXSBXaGljaCBp c24ndCBldmVyIGp1c3RpZmllZCwgYnV0IGV2ZW4gaWYgd2UgYWNjZXB0IHRoYXQgYXMgYSB0cnVl IHByZW1pc2UsIHdoYXQgYXJlIHRoZXNlIEFTIGRvaW5nIHRoYXQgZXZlbiByZXF1aXJlIGEgQkZG Pw0KSSBhbSBub3Qgc3VyZSBob3cgdG8gaW50ZXJwcmV0IHRoZSBzdGF0ZW1lbnQgYWJvdXQg4oCc ZXZlciBqdXN0aWZpZWTigJ0uIFRoaXMgaGFzIGxpdHRsZSB0byBkbyB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlci4gTm90IGV2ZXJ5IGFwcGxpY2F0aW9uIGNhbiBoYXZlIGEgYmFja2VuZCB0 aGF0IGV4cG9zZXMgYSBmYcOnYWRlIHJlcGxpY2F0aW5nIGFsbCB0aGUgQVBJcyB0aGUgZnJvbnRl bmQgbmVlZCB0byBpbnZva2UsIGZvciBhbGwgc29ydHMgb2YgcmVhc29uczogbWFpbnRlbmFuY2Us IHBlcmZvcm1hbmNlLCBza2lsbHMgb2YgdGhlIGRldmVsb3BlcnMgaW52b2x2ZWQsIGNhcGFiaWxp dGllcyBvZiB0aGUgc3RhY2tzIG9mIGNob2ljZSwgYW5kIHNvIG9uLiBUaGlzIGlzbuKAmXQgdGhl b3JldGljYWwsIEkgaGFkIHRoaXMgZGlzY3Vzc2lvbnMgbWFueSB0aW1lcyB3aXRoIHByb3NwZWN0 cyBhbmQgZGV2ZWxvcGVycy4NCg0KDQogICogICBIeXBvdGhldGljYWxseSB5b3UgY291bGQgYXJn dWUgdGhhdCB0aGUgYXV0aCBjb2RlIGZsb3cgcmVxdWlyZXMgYSBCRkYgYW5kIHRoYXQncyByZXF1 aXJlZCBmb3IgdXNlciBsb2dpbiBzaW5jZSBpbXBsaWNpdCBmbG93IG5vIGxvbmdlciBleGlzdHMs IGJ1dCB0aGF0IGlzbid0IHRydWUuIFlvdSBjYW4gdXNlIGNsaWVudCBzaWRlIFBLQ0UgZm9yIHZh bGlkYXRpb24gb2YgdGhlc2UgdmlhIG5vdCByZXF1aXJpbmcgdGhlIGNsaWVudCBzZWNyZXQgaW4g dGhlIGZyb250IGVuZCwgYW5kIHRoZW4gdGhlIHByb2JsZW0gdGhlcmUgaXMgc29sdmVkLg0KSW4g Y29uY3JldGUgdGVybXMsIHRoaW5ncyBhcmUgYSBiaXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIOKA nGEgZ3JhbnQgZm9yIFNQQXMgYWxyZWFkeSBleGlzdOKAnS4gSSBhbSB3ZWxsIGF3YXJlIHRoYXQg Y29kZStQS0NFIGlzIGEgdmlhYmxlIHNvbHV0aW9uIGZvciBTUEFzIHRvIGdldCBhY2Nlc3MgdG9r ZW5zLCBob3dldmVyIHRoYXQgaGFzIGl0cyBvd24gY2hhbGxlbmdlcy4gRm9yIGV4YW1wbGUsIGlm IHlvdSB3YW50IHRvIHVzZSByZWZyZXNoIHRva2VucyBpbiBpdCwgeW91IG5lZWQgdG8gc2VuZGVy IGNvbnN0cmFpbiB0aGVtIG9yIHN1cHBvcnQgcmVmcmVzaCB0b2tlbiByb3RhdGlvbi4gSWYgeW91 IGNoZWNrIHRoZSBjdXJyZW50IHNpdHVhdGlvbiBhY3Jvc3MgdGhlIGluZHVzdHJ5LCB5b3XigJls bCBzZWUgdGhhdCB2ZXJ5IGZldyBTREtzIGFjdHVhbGx5IGRvIHN1cHBvcnQgcm90YXRpb24gb3Ig c2VuZGVyIGNvbnN0cmFpbnQgdG9kYXktIGFyZ3VhYmx5IGludHJvZHVjaW5nIGEgbmV3IHNlY3Vy aXR5IGlzc3VlLiBBbmQgb2YgY291cnNlLCB0aGVyZeKAmXMgdGhlIGh1Z2UgZGViYWNsZSBhYm91 dCBzYXZpbmcgdG9rZW5zIGluIGxvY2FsIHN0b3JhZ2UtIHNvbWV0aGluZyB0aGF0IG1hbnkgYXBw bGljYXRpb25zIG5lZWQgdG8gZG8gaW4gb3JkZXIgdG8gb2ZmZXIgdGhlIGV4cGVyaWVuY2UgdGhl aXIgY3VzdG9tZXJzIHJlcXVpcmUuDQpJZiBhIFNQQSBhcHAgZG9lcyBub3QgaGF2ZSBhIGJhY2tl bmQsIGNvZGUrUEtDRSBpcyB0aGUgb25seSBnYW1lIGluIHRvd24uIElmIGl0IGhhcyBhIGJhY2tl bmQgQU5EIGNhbiBsZWF2ZSBhbGwgYWN0dWFsIEFQSSBjYWxscyB0byBpdCwgdGhlcmXigJlzIG5v IG5lZWQgdG8gZ2V0IHRva2VucyBpbiB0aGUgdXNlciBhZ2VudC4NCkJ1dCBpZiB5b3UgYXJlIGlu IG9uZSBzaXR1YXRpb24gd2hlcmUgeW91IGRvIGhhdmUgYSBiYWNrZW5kIGFuZCBjYW5ub3QgZGVs ZWdhdGUgQVBJIGNhbGxzIChzZWUgbXkgcHJlY2VkaW5nIGNvbW1lbnQpLCB0aGVuIFRNSS1CRkYg Y2FuIGdldCB0b2tlbnMgdG8geW91ciBmcm9udGVuZCB3aXRob3V0IHJlcXVpcmluZyBjb21wbGV4 IGphdmFzY3JpcHQgbG9naWMsIHdpdGhvdXQgaGF2aW5nIHRvIHBlcnNpc3QgYW55dGhpbmcgaW4g bG9jYWwgc3RvcmFnZSBhbmQgd2l0aG91dCByZXF1aXJpbmcgdGhlIEFTIHRvIHN1cHBvcnQgcm90 YXRpb24gb3Igc2VuZGVyIGNvbnN0cmFpbnQuIEFzIGxvbmcgYXMgdGhlIHRyYWZmaWMgd2l0aCBi ZmYtdG9rZW4gcHJveHkgaXMgaGFyZGVuZWQsIEkgd291bGQgYXJndWUgVE1JLUJGRiBtaWdodCBh Y3R1YWxseSBiZSBlYXNpZXIgdG8gaW1wbGVtZW50IHNlY3VyZWx5IHRoYXQgY29kZStQS0NFK3Jv dGF0aW9uL1NDLiBIYXZpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgZnJvbnRlbmQgcmVtYWlucyBu b3QgZ3JlYXQsIGJ1dCBpdCBzZWVtcyB0aGF0IGdpdmluZyBwZW9wbGUgd2hvIHdvdWxkIGRvIGl0 IGFueXdheSBzb21lIGd1aWRhbmNlIGlzIGJldHRlciB0aGFuIGxlYXZpbmcgdGhlbSBhdCB0aGVp ciBvd24gZGV2aWNlLSB1bmxlc3Mgd2UgY29uY2x1ZGUgdGhhdCB0aGlzIGZsb3cgY2Fubm90IGJl IHNlY3VyZWQsIGluIHdoaWNoIGNhc2UgSSBhZ3JlZSB3ZSBzaG91bGQgZXhwbGljaXRseSBpZG5j aWF0ZSB0aGlzIGFzIGFudGkgcGF0dGVybi4gQnV0IHNvIGZhciwgaXQgc2VlbXMgc3RpbGwgdG8g YmUgZGVtb3NudHJhdGVkLg0KDQoNCiAgKiAgIFRoZXJlIHdhcyBhbHNvIHRoZSBhcmd1bWVudCBv ZiB0aGVyZSBhcmUgbG90cyBvZiBwZW9wbGUgZG9pbmcgdGhpcywgd2hpY2ggaXMgYWx3YXlzIGEg dGVycmlibGUgYXJndW1lbnQsIGJ1dCBldmVuIGlmIHdlIGRvIHBlcm1pdCB0aGF0IGluIHRoZSBk aXNjdXNzaW9uLCB3ZSBzdGlsbCBuZWVkIHRvIGFuc3dlciB0aGUgd2h5LiBXaHkgYXJlIGRldmVs b3BlcnMgY3JlYXRpbmcgQkZGIGZvciB0aGVpciBmcm9udGVuZHMgdG8gY29tbXVuaWNhdGUgd2l0 aCBhbiBBUy4gSXMgaXQgYmVjYXVzZSBBUyBhcmUgdGVycmlibGUsIGlzIGl0IGJlY2F1c2UgZnJv bnQgZW5kcyBhcyBhIHNlcnZpY2UgYXJlIHRlcnJpYmxlLCBldGMuLi4gVW50aWwgd2Uga25vdyB3 aHkgdGhpcyBpcyBoYXBwZW5pbmcgY29uY3JldGVseSwgSSBkb24ndCB0aGluayB3ZSBzaG91bGQg ZW5jb3VyYWdlIGZ1cnRoZXIgdXNlIG9mIGEgcGF0dGVybiByaWZlIHdpdGggcG90ZW50aWFsIHNl Y3VyaXR5IHJpc2tzIGJ5IHRlbGxpbmcgZXZlcnlvbmUgaG93IHlvdSBjYW4gZG8gaXQgKGJlY2F1 c2UgdGhlIGd1aWRhbmNlIHdlIGFyZSBvZmZlcmluZyBkb2Vzbid0IGV2ZW4gc2xpZ2h0bHkgaW5j cmVhc2Ugc2FmZXR5KS4NClRoZSBwcmVjZWRpbmcgY29tbWVudHMgc2hvdWxkIGhhdmUgc2hlZCBt b3JlIGxpZ2h0IGFib3V0IHRoZSB3aHksIGFuZCBvbiBzb21lIG9mIHRoZSBzZWN1cml0eSBjb25j ZXJucyAodGhlcmUgd2FzIG9uZSBjb25jZXJuIHJhaXNlZCBieSBOZWlsLCBhbmQgaXQgc2VlbXMg dGhlcmUgYXJlIHBvc3NpYmxlIG1pdGlnYXRpb25zIGluIHBsYWNlKSBwbHVzIGhvdyB0aGlzIG1p Z2h0IGFjdHVhbGx5IGluY3JlYXNlIHNhZmV0eSBpbiBzb21lIGFzcGVjdHMuIEJ1dCB0byBhZGQg bW9yZSBjb2xvciwgb25lIG9mIHRoZSBvdGhlciByZWFzb25zIGZvciB3aGljaCB0aGlzIGlzIGhh cHBlbmluZyBpcyBiZWNhdXNlIGl04oCZcyBzaW1wbGUuIEJhY2tlbmQgT0FVdGgvT0lEQyBTREtz IGxpa2UgbWlkZGxld2FyZXMgYW5kIHNpbWlsYXIgYXJlIHZlcnkgbWF0dXJlIGF0IHRoaXMgcG9p bnQsIGFuZCB0aGV5IGFyZW7igJl0IHNhZGRsZWQgYnkgYSBsb3Qgb2YgdGhlIGNvbXBsZXhpdHkg YW5kIHVuY2VydGFpbmx5IHRoYXQgYnJvd3NlciBiYXNlZCBTREtzIGNhcnJ5LiBUaGluZ3MgbGlr ZSBJRSB6b25lcywgSVRQLCBTYW1lU2l0ZSBhbmQgb3VyIG93biBjaGFuZ2luZyBndWlkYW5jZSAo Zm9yIGdvb2QgcmVhc29ucykgcGx1cyBkaXNvbW9nZW5lb3VzIHN1cHBvcnQgZnJvbSBwcm92aWRl cnMgb2YgdGhlIGZlYXR1cmVzIHJlcXVpcmVkIGZvciB0aGUgbGF0ZXN0IGd1aWRhbmNlIGNyZWF0 ZSB1bmNlcnRhaW50eSBhbmQgY29tcGxleGl0eSB0aGF0IG1hbnkgbm9uLWluaXRpYXRlZCB3b27i gJl0IHB1dCB1cCB3aXRoLiBBZGQgdG8gdGhpcyB0aGF0IHRoZSBtb3JlIGFwcCBkZXZlbG9wbWVu dCBtb3ZlcyB0byB0aGUgZnJvbnRlbmQsIHRoZSBtb3JlIHlvdSBkb27igJl0IGdldCBmdWxsIHN0 YWNrIGRldmVsb3BlcnMgYW5kIGdldHRpbmcgYSBmcm9udGVuZCBkZXZlbG9wZXIgdG8gZGVhbCB3 aXRoIGFsbCB0aG9zZSBxdWlya3MgaXMgaGFyZC4gR2V0dGluZyB0b2tlbnMgdGhydSB3ZWxsIHN1 cHBvcnRlZCBtaWRkbGV3YXJlcyBhbmQgZm9yd2FyZCB0aGVtIHRvIHRoZSBmcm9udGVuZCBpcyBz aW1wbGUuDQpBbHNvLCB0byBiZSBjbGVhci4gVGhpcyBleGFjdCB0b3BvbG9neSBoYXMgYmVlbiBj b25zaWRlcmVkIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCBkdXJpbmcgSUVURiBtZWV0aW5ncywgaW4g TW9udHJlYWwgd2UgaGFkIGEgZGlzY3Vzc2lvbiBhYm91dCBpbmNsdWRpbmcgaXQgaW4gc29tZSBC Q1AgYW5kIHdoZXRoZXIgd2Ugc2hvdWxkIGhhdmUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQg dG8gc2lnbmFsIHRvIHRoZSBBUyB0aGF0IHRoZSB0b2tlbnMgd2lsbCBiZSB1c2VkIGJ5IGNvZGUg ZXhlY3V0aW5nIGluIGEgd2Vha2VyIHNlY3VyaXR5IGNvbnRleHQgKHVzZXIgYWdlbnQpIHRoYW4g dGhlIHJlcXVlc3RvcuKAmXMgKGNvbmZpZGVudGlhbCBjbGllbnQgb24gYmFja2VkKS4gSSBhbSBz dXJlIHdlIGNhbiBmaW5kIHRoZSBtaW51dGVzIG9mIHRoYXQuIFRoaXMgaXNu4oCZdCBzb21ldGhp bmcgY29tcGxldGVseSBsZWZ0IGZpZWxkLg0KDQoNCiAgKiAgIEZ1cnRoZXIsIGV2ZW4gaWYgd2Ug d2VyZSB0byBhY2NlcHQgdGhpcyBwYXR0ZXJuIGFuZCB3YW50IHRvIGNyZWF0ZSBhIHN0YW5kYXJk IGFyb3VuZCBpdCwgd2UgYXJlIGVmZmVjdGl2ZWx5IGNyZWF0aW5nIGFuIEFTIHByb3h5IGhlcmUs IHdoaWNoIG1lYW5zIHdlIHNob3VsZCByZXF1aXJlIGl0IHRvIGFjdCBsaWtlIGFuIEFTLCBhbmQg ZGVsZWdhdGUgdGhlIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2VzLCBlbmRwb2ludHMsIHRlcm1p bm9sb2d5LCBhbmQgcGF0dGVybnMgdG8gZXhpc3Rpbmcgb3IgZnV0dXJlIEFTIHJlbGF0ZWQgUkZD cy4NCkkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NhbCB3YXJy YW50cyBkb2luZyBhbCB0aGF0LiBDb3VsZCB5b3UgcG9pbnQgYXQgdGhlIGFyZWEgaW4gdGhlIHNw ZWMgdGhhdCBzdWdnZXN0IHdl4oCZZCBuZWVkIHRvIGFkZCBhbnl0aGluZyBiZXlvbmQgd2hhdOKA mXMgc3VnZ2VzdGVkIGF0IHRoZSBtb21lbnQgdG8gYWNoaWV2ZSB0aGUgc3RhdGVkIGdvYWxzPw0K DQoNCiAgKiAgIEFuZCB0aGVyZWZvcmUgaW4gY29uY2x1c2lvbiB3ZSBzaG91bGQgZm9jdXMgb25s eSBvbiB0aGUgYXNwZWN0cyB0aGF0IGFyZSBhYnNvbHV0ZWx5IHJlcXVpcmVkIHdoaWNoIGFyZW4n dCBhbHJlYWR5IHByZXNlbnQgaW4gc29tZSBmb3JtIGluIGV4aXN0aW5nIEFTIHJlbGF0ZWQgUkZD cywgYnV0IHdoYXQgYXJlIHRob3NlPw0KSSBhbSBzdGlsbCBtaXNzaW5nIGhvdyB0aGlzIGhhcyB0 byBkbyB3aXRoIG1pc3NpbmcgQVMgZnVuY3Rpb25hbGl0eS4gT25lIG9mIHRoZSB0aGluZ3Mgd2Ug dHJpZWQgdG8gZG8gd2FzIG5vdCB0byByZXF1aXJlIGFueSBjaGFuZ2UgdG8gdGhlIEFTLiBUaGUg cHJvYmxlbSBiZWluZyBzb2x2ZWQgaGVyZSBpcyBob3cgdG8gYWxsb3cgamF2YXNjcmlwdCBkZXZl bG9wZXJzIHRvIGNhbGwgQVBJIGRpcmVjdGx5IGZyb20gdGhlaXIgZnJvbnRlbmQgd2hlbiB0aGV5 IGhhdmUgYSBiYWNrZW5kIHdpdGggYmFzaWMgb2F1dGggY2FwYWJpbGl0aWVzIGF0IHRoZWlyIGRp c3Bvc2FsLCBpbiB0aGUgc2ltcGxlc3QgcG9zc2libGUgd2F5LiBDaGFuZ2VzIGluIHRoZSBBUyBk b2Vu4oCZdCBhcHBlYXIgdG8gYmUgbmVjZXNzYXJ5IHRoZXJlDQoNCg0KICAqICAgVGhlIG9uZSBj b3VudGVycG9pbnQgdG8gYWxsIG9mIHRoaXMgaXMgdGhlIHBvdGVudGlhbCBpbnRyb2R1Y3Rpb24g b2YgZG9tYWluIHNwZWNpZmljIGNvb2tpZSBsYW5ndWFnZSAod2hpY2ggZG9lc24ndCBleGlzdCBp biB0aGUgY3VycmVudCBkcmFmdCkuIENvbmNyZXRlbHksIGxldCdzIGFkZCBhIHJlc3BvbnNlX3R5 cGU9Y29va2llLCB0byBBUyB0byBzdXBwb3J0IGRvbWFpbiBmaXJzdC1wYXJ0eSBjb29raWVzIGFu ZCBzZXNzaW9uIG1hbmFnZW1lbnQuDQpDb3VsZCB5b3UgZXhwYW5kIG9uIGhvdyB5b3UgZW52aXNp b24gdGhpcyB3b3VsZCB3b3JrL3NvbHZlIHRoZSBwcm9ibGVtcyBkZXNjcmliZWQgYWJvdmU/DQoN Cg0KRnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWQ9NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc+ DQpEYXRlOiBTdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAxOjUxDQpUbzogTmVpbCBNYWRk ZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+DQpDYzogVml0dG9yaW8gQmVydG9jY2kgPHZp dHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4sIG9hdXRoIDxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlv biBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KSSBhbHNvIGZsYXQgb3V0IHJlamVj dCB0aGUgcHJlbWlzZSBvZiB0aGlzIGRyYWZ0LiBJdCBpbnRyb2R1Y2VzIGEgcHNldWRvIEFTLWxp a2UgcHJveHkgd2hpY2ggbm93IGhhcyBhbGwgdGhlIHJlcXVpcmVtZW50cyBvZiBhbiBBUyBhbmQg bW9yZS4gV2hpbGUgQVMgU0RLcyBwcm92aWRlIGVhc3kgd2F5cyBmb3IgY2xpZW50IFVJcyB0byBl ZmZlY3RpdmVseSBkZWFsIHdpdGggY29tbXVuaWNhdGlvbiB2aWEgdGhlIEFTLCB0aGVyZSdzIG5v IHdheSBmb3IgdGhlIEFTIHRvIHByb3ZpZGUgc3RhbmRhcmQgQVMgc3BlY2lmaWMgc2VydmljZXMg cHJvdG90eXBlcyB0byBzdXBwb3J0IEJGRi4gVGhhdCBtZWFucyB0aGF0IGV2ZXJ5b25lIGlzIHdy aXRpbmcgdGhlaXIgb3duIEJGRiBBUy1wcm94eS4NCg0KQWRkaXRpb25hbGx5LCBJIHRvbyBhbSBs YWNraW5nIHRoZSBjbGFyaXR5IG9uIHRoZSBXSFkuIFRoZSBvbmx5IHRoaW5nIG1lbnRpb25lZCBp biB0aGUgZHJhZnQgaXMNClRoYXQgYXBwcm9hY2ggaXMgbm90IGFsd2F5cyB2aWFibGUsIGFzIGlu IHRoZSBhYnNlbmNlIG9mIHJldmVyc2UgcHJveHkgZGVwbG95bWVudHMgdGhlIGNyZWF0aW9uIGFu ZCBtYWludGVuYW5jZSBvZiBhIGZhY2FkZSBmb3IgbXVsdGlwbGUgQVBJcyBjYW4gYmUgZXhwZW5z aXZlDQpXaGljaCBpc24ndCBldmVyIGp1c3RpZmllZCwgYnV0IGV2ZW4gaWYgd2UgYWNjZXB0IHRo YXQgYXMgYSB0cnVlIHByZW1pc2UsIHdoYXQgYXJlIHRoZXNlIEFTIGRvaW5nIHRoYXQgZXZlbiBy ZXF1aXJlIGEgQkZGPw0KDQpIeXBvdGhldGljYWxseSB5b3UgY291bGQgYXJndWUgdGhhdCB0aGUg YXV0aCBjb2RlIGZsb3cgcmVxdWlyZXMgYSBCRkYgYW5kIHRoYXQncyByZXF1aXJlZCBmb3IgdXNl ciBsb2dpbiBzaW5jZSBpbXBsaWNpdCBmbG93IG5vIGxvbmdlciBleGlzdHMsIGJ1dCB0aGF0IGlz bid0IHRydWUuIFlvdSBjYW4gdXNlIGNsaWVudCBzaWRlIFBLQ0UgZm9yIHZhbGlkYXRpb24gb2Yg dGhlc2UgdmlhIG5vdCByZXF1aXJpbmcgdGhlIGNsaWVudCBzZWNyZXQgaW4gdGhlIGZyb250IGVu ZCwgYW5kIHRoZW4gdGhlIHByb2JsZW0gdGhlcmUgaXMgc29sdmVkLiBBbmQgaWYgeW91IGFyZ3Vl IHRoYXQgdGhpcyBjYW4ndCBiZSBkb25lLCB0aGVuIHRoZSBzb2x1dGlvbiBpcyBpbnRyb2R1Y2lu ZyBhIGJldHRlciB3YXkgdG8gaGFuZGxlIHRoaXMgc28gdGhhdCBhIEJGRiBmb3IgQVMgZmxvd3Mg ZG9uJ3QgaGF2ZSB0byBleGlzdC4NCg0KU28gd2hhdCBjb25jcmV0ZSBwcm9ibGVtIGlzIHRoaXMg c29sdmluZz8NCg0KVGhlcmUgd2FzIGFsc28gdGhlIGFyZ3VtZW50IG9mIHRoZXJlIGFyZSBsb3Rz IG9mIHBlb3BsZSBkb2luZyB0aGlzLCB3aGljaCBpcyBhbHdheXMgYSB0ZXJyaWJsZSBhcmd1bWVu dCwgYnV0IGV2ZW4gaWYgd2UgZG8gcGVybWl0IHRoYXQgaW4gdGhlIGRpc2N1c3Npb24sIHdlIHN0 aWxsIG5lZWQgdG8gYW5zd2VyIHRoZSB3aHkuIFdoeSBhcmUgZGV2ZWxvcGVycyBjcmVhdGluZyBC RkYgZm9yIHRoZWlyIGZyb250ZW5kcyB0byBjb21tdW5pY2F0ZSB3aXRoIGFuIEFTLiBJcyBpdCBi ZWNhdXNlIEFTIGFyZSB0ZXJyaWJsZSwgaXMgaXQgYmVjYXVzZSBmcm9udCBlbmRzIGFzIGEgc2Vy dmljZSBhcmUgdGVycmlibGUsIGV0Yy4uLiBVbnRpbCB3ZSBrbm93IHdoeSB0aGlzIGlzIGhhcHBl bmluZyBjb25jcmV0ZWx5LCBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBlbmNvdXJhZ2UgZnVydGhl ciB1c2Ugb2YgYSBwYXR0ZXJuIHJpZmUgd2l0aCBwb3RlbnRpYWwgc2VjdXJpdHkgcmlza3MgYnkg dGVsbGluZyBldmVyeW9uZSBob3cgeW91IGNhbiBkbyBpdCAoYmVjYXVzZSB0aGUgZ3VpZGFuY2Ug d2UgYXJlIG9mZmVyaW5nIGRvZXNuJ3QgZXZlbiBzbGlnaHRseSBpbmNyZWFzZSBzYWZldHkpLg0K DQpGdXJ0aGVyLCBldmVuIGlmIHdlIHdlcmUgdG8gYWNjZXB0IHRoaXMgcGF0dGVybiBhbmQgd2Fu dCB0byBjcmVhdGUgYSBzdGFuZGFyZCBhcm91bmQgaXQsIHdlIGFyZSBlZmZlY3RpdmVseSBjcmVh dGluZyBhbiBBUyBwcm94eSBoZXJlLCB3aGljaCBtZWFucyB3ZSBzaG91bGQgcmVxdWlyZSBpdCB0 byBhY3QgbGlrZSBhbiBBUywgYW5kIGRlbGVnYXRlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHJlc291 cmNlcywgZW5kcG9pbnRzLCB0ZXJtaW5vbG9neSwgYW5kIHBhdHRlcm5zIHRvIGV4aXN0aW5nIG9y IGZ1dHVyZSBBUyByZWxhdGVkIFJGQ3MuIChXZSBhbHJlYWR5IGhhdmUgYSBwcm9ibGVtIHdpdGgg dGhlIGN1cnJlbnQgZHJhZnQgYXMgaXQgYXR0ZW1wdHMgdG8gcmVkZWZpbmUgYW5kIGludHJvZHVj ZSBuZXcgdGVybXMvcGF0dGVybnMgdGhhdCBoYXZlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgYXMg ZXhpc3Rpbmcgb25lcyBpbiB0aGUgQVMsIHlldCBmYWlsIHRvIGNhcHR1cmUgdGhlIGZ1bGwgaW1w b3J0YW5jZSBvZiB0aGUgb3JpZ2luYWwgUkZDcy4gVGhpcyBpcyBiYWQgZHVwbGljYXRpb24pLiBB bmQgdGhlcmVmb3JlIGluIGNvbmNsdXNpb24gd2Ugc2hvdWxkIGZvY3VzIG9ubHkgb24gdGhlIGFz cGVjdHMgdGhhdCBhcmUgYWJzb2x1dGVseSByZXF1aXJlZCB3aGljaCBhcmVuJ3QgYWxyZWFkeSBw cmVzZW50IGluIHNvbWUgZm9ybSBpbiBleGlzdGluZyBBUyByZWxhdGVkIFJGQ3MsIGJ1dCB3aGF0 IGFyZSB0aG9zZT8NCg0KVGhlIG9uZSBjb3VudGVycG9pbnQgdG8gYWxsIG9mIHRoaXMgaXMgdGhl IHBvdGVudGlhbCBpbnRyb2R1Y3Rpb24gb2YgZG9tYWluIHNwZWNpZmljIGNvb2tpZSBsYW5ndWFn ZSAod2hpY2ggZG9lc24ndCBleGlzdCBpbiB0aGUgY3VycmVudCBkcmFmdCkuIENvbmNyZXRlbHks IGxldCdzIGFkZCBhIHJlc3BvbnNlX3R5cGU9Y29va2llLCB0byBBUyB0byBzdXBwb3J0IGRvbWFp biBmaXJzdC1wYXJ0eSBjb29raWVzIGFuZCBzZXNzaW9uIG1hbmFnZW1lbnQuIFdoZW4gd2UgYnVp bHQgb3VyIEFTIHdlIGV4cGxpY2l0bHkgYWRkZWQgdGhpcyBzbyB0aGF0IHNlcnZpY2VzIGNhbiB1 c2UgdGhlIEpXVCBmb3VuZCBpbiB0aGUgSHR0cE9ubHkgU2FtZVNpdGU9U3RyaWN0IGNvb2tpZSBh cyBhIHNlY3VyaXR5IG1lYXN1cmUgYWdhaW5zdCBYU1MgYXR0YWNrcyB0aGF0IGF0dGVtcHQgdG8g ZXhmaWx0cmF0ZSBhY2Nlc3MgdG9rZW5zLiBUaGF0J3MgYSBwb3RlbnRpYWwgc3VnZ2VzdGlvbiBJ IHdvdWxkIGZhdm9yLCBhbHRob3VnaCBJIHN0aWxsIGNhbid0IGtub3cgaWYgdGhhdCBzb2x2ZXMg dGhlIHByb2JsZW0gYmVpbmcgcHJlc2VudGVkIGluIHRoZSBkcmFmdC4NCg0KLSBXYXJyZW4NCg0K DQpbSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuXQ0KDQpXYXJyZW4gUGFyYWQNCg0KRm91bmRlciwg Q1RPDQpTZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlv biBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCBBdXRocmVzczxodHRwczovL2F1dGhyZXNzLmlvPi4N Cg0KDQpPbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCA5OjE4IEFNIE5laWwgTWFkZGVuIDxuZWlsLm1h ZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4gd3Jv dGU6DQpJIGhhdmUgYSBsb3Qgb2Ygc2VjdXJpdHkgY29uY2VybnMgYWJvdXQgdGhpcyBkcmFmdC4N Cg0KVGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJpdHkgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBo YW5kbGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBmcm9udGVuZCBidXQgbmV2ZXIgcmVhbGx5IHNw ZWxscyB0aGVtIG91dC4gPkZyb20gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGl0IHNlZW1z IHRoYXQgdGhlIHByaW1hcnkgY29uY2VybiBpcyB3aXRoIHRoZWZ0IG9mIGFjY2VzcyB0b2tlbnMg ZnJvbSBsb2NhbCBzdG9yYWdlLiBUbyBkbyB0aGlzIHlvdeKAmWQgbmVlZCBhbiBYU1MgYXR0YWNr LiBCdXQgaW4gdGhhdCBjYXNlLCB3b3VsZG7igJl0IHRoZSBhdHRhY2tlciBzaW1wbHkgdXNlIHRo ZSBYU1MgdG8gbWFrZSBhIGNhbGwgdG8gdGhlIGJmZi10b2tlbiBlbmRwb2ludCBpbnN0ZWFkPw0K DQpUaGUgY29tYmluYXRpb24gb2YgdGhlIGJmZi10b2tlbiBlbmRwb2ludCByZWNvbW1lbmRpbmcg dGhlIHVzZSBvZiBHRVQgcmVxdWVzdHMgdG9nZXRoZXIgd2l0aCB0aGUgaGludCB0byB1c2UgY29v a2llLWJhc2VkIGF1dGhlbnRpY2F0aW9uIGlzIGxpa2VseSBnb2luZyB0byBwdW5jaCBhIGhvbGUg aW4gbW9zdCBDU1JGIGRlZmVuc2VzLCB3aGljaCBhc3N1bWUgdGhhdCBHRVRzIGFyZSBzYWZlLiBU aGUgb25seSB0aGluZyBwcmV2ZW50aW5nIHRoaXMgYmVpbmcgZXhwbG9pdGFibGUgaXMgQ3Jvc3Mt T3JpZ2luIFJlYWQgQmxvY2tpbmcgKGh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291cmNlLmNvbS9j aHJvbWl1bS9zcmMvKy9tYXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19vcmlnaW5fcmVhZF9i bG9ja2luZ19leHBsYWluZXIubWQpIGR1ZSB0byB0aGUgSlNPTiBjb250ZW50LXR5cGUuIFRoYXQg bWFrZXMgbWUgcmVhbGx5IG5lcnZvdXMuIFdlIHNob3VsZCBhdCBsZWFzdCBtYW5kYXRlIFgtQ29u dGVudC1UeXBlLU9wdGlvbnM6IG5vc25pZmYgb24gdGhhdCByZXNwb25zZS4gSeKAmWQgZmVlbCBt b3JlIGNvbWZvcnRhYmxlIGlmIHRoaXMgd2FzIGEgUE9TVCByZXF1ZXN0IG9ubHkuDQoNCkFzIFN0 b3ljaG8gU2xlcHRzb3YgbWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwgdGhlIGxhY2sgb2Yg ZnJvbnQtY2hhbm5lbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0aGUgUk8gc2Vl bXMgb2RkLiBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVu IGNvdWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlz c3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3Ig QVBJIGFjY2Vzcz8NCg0KSWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cgZXRjIHRo ZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFuZGFyZCBl cnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0aGUgU1BB IHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRvIGEgUEFS IHJlcXVlc3QgZmlyc3QgYW5kIHJldHVybiBhIFVSSSB0aGF0IHJlZmVyZW5jZXMgdGhhdCBzbyB0 aGF0IGF1dGhvcml6YXRpb24gZGV0YWlscyBhcmVu4oCZdCBwYXNzZWQgdGhyb3VnaCB0aGUgZnJv bnRlbmQpLg0KDQrigJQgTmVpbA0KDQoNCk9uIDEyIEZlYiAyMDIxLCBhdCAyMDo0NiwgVml0dG9y aW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K77u/RGVhciBhbGws DQpCcmlhbiBhbmQgeW91cnMgdHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVjaWZpY2F0aW9u IHRoYXQgc2hvd3MgaG93IHRoZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2ViIGFwcCBjYW4g ZGVsZWdhdGUgdG9rZW4gYWNxdWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0cyBiYWNrZW5k LCBhbmQgcmVxdWVzdCBzdWNoIHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0IGFjY2VzcyBv ZiBwcm90ZWN0ZWQgcmVzb3VyY2VzIGZyb20gdGhlIGZyb250ZW5kIGNvZGUuDQoNClRoZSBwYXR0 ZXJuIGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2YXJpb3VzIG1v ZGVybiBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFudHMgb2YgdGhl IHBhdHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRlcm0gQkZGIChi YWNrZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQgaW4gdGhpcyB3 b3JrZ3JvdXDigJlzIGFjdGl2aXR5LCBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9u IGRldGFpbHMgdG8gdGhlIHJlYWRlci4NCldlIGJlbGlldmUgdGhlIHBhdHRlcm4gaGFzIG1lcml0 LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdyb3dpbmcgYWRvcHRpb24uIEJ5IGRlbGVnYXRpbmcg YWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIHRoZSBiYWNrZW5kLCB3ZSBhdm9pZCBtYW55IG9m IHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBwYXJ0cyAoYW5kIGltcGxpZWQgYXR0YWNrIHN1cmZh Y2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNjZXNzIHRva2VucyBmcm9tIGEgdXNlciBhZ2VudC4g VGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhlIG5lZWQgb2Yg cGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3duIHNvcmUgcG9p bnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVseWluZyBvbiBp dHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vucy4NCg0KQWx0 aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gaXMgdmVyeSBzaW1wbGUsIHByb3ZpZGluZyBleHBsaWNp dCBndWlkYW5jZSBvbiB0aGUgc2NlbmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50YWdlcy4NCi0gSXQg bWFrZXMgaXQgcG9zc2libGUgdG8gY3JlYXRlIGludGVyb3BlcmFibGUgU0RLcywgd2hlcmUgZnJv bnRlbmQgZGV2IHN0YWNrcyAoYW55IEpTIGZsYXZvcikgY2FuIGJlIG1peGVkIGFuZCBtYXRjaGVk IHdpdGggY29tcGxpYW50IGJhY2tlbmQgc3RhY2tzIChtaWRkbGV3YXJlcyBpbiBub2RlLCBqYXZh LCBBU1AuTkVUPGh0dHA6Ly9BU1AuTkVUPiwgUEhQIGV0YykNCi0gSXQgYWxsb3dzIHVzIHRvIHBy b3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIHByb3Blcmx5IHRhY2tsZSB0aGUgc2NlbmFyaW8gYW5k IHdhcm4gaW1wbGVtZW50ZXJzIGFnYWluc3Qgc2VjdXJpdHkgcmlza3MgKHNjb3BlIGVzY2FsYXRp b25zLCB1c2luZyBJRHRva2VucyBpbnN0ZWFkIG9mIGFjY2VzcyB0b2tlbnMsIGV0YykNCi0gSXQg YWxsb3dzIHVzIHRvIGRpc2N1c3MgKGFuZCB3aGVuIGFwcHJvcHJpYXRlLCBwcm9tb3RlKSB0aGlz IHBhdHRlcm4gYXMgcGFydCBvZiB0aGUgYnJvd3NlciBhcHBzIHNlY3VyaXR5IGd1aWRhbmNlLCBh bmQgcG9zaXRpb24gdGhlIHNjZW5hcmlvIHdoZXJlIGZyb250ZW5kIG9ubHkgY2FsbHMgQVBJIG9u IGl0cyBvd24gYmFja2VkIChoZW5jZSBkb2VzbuKAmXQgbmVlZCBhY2Nlc3MgdG9rZW5zKSBzaW1w bHkgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhpcyBtb3JlIGdlbmVyYWwgcGF0dGVybg0KLSBUaGlz IGFwcHJvYWNoIG1ha2VzIG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5IGVhc3ksIHBvc3Np Ymx5IHByZXZlbnRpbmcgZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUgc2VjdXJpdHkgb2Yg dGhlaXIgc3lzdGVtIChlZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykgIG9yIHR1cm5pbmcgdG8g cmlza3kgcHJhY3RpY2VzIGxpa2Ugc2NyYXBpbmcNCg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlzIHNw ZWNpZmljYXRpb24gZG9lc27igJl0IGVudGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlza3MgaW5oZXJl bnQgdG8gZGlyZWN0IHVzZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gYSBicm93c2VyLiBCdXQgcmVh bGl0eSBpcyB0aGF0IHRoZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhlIGNp cmN1bXN0YW5jZXMgbGVhZGluZyB0byB0aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEgcGFydGljdWxh ciBwcm9qZWN0IG9ubHkgd29yayB3aXRoIGZyb250ZW5kIHN0YWNrczsgY29tcG9uZW50cyBsaWtl IHJldmVyc2UgcHJveGllcyBtaWdodCBub3QgYWx3YXlzIGJlIHZpYWJsZTsgZXRjKSBhcmVu4oCZ dCBnb2luZyBhd2F5IGFueSB0aW1lIHNvb24uIEJ5IHByb3ZpZGluZyBzaW1wbGUgZ3VpZGFuY2Ug b24gdGhpcyBwYXR0ZXJuLCB3ZSBjYW4gc2ltcGxpZnkgdGhlIGxpZmUgb2YgbWFueSBkZXZlbG9w ZXJzIHdoaWxlIGVuc2hyaW5pbmcgYmFzaWMgc2VjdXJpdHkgaHlnaWVuZSBpbiBzY2VuYXJpb3Mg dGhhdCB3b3VsZCBoYXZlIG90aGVyd2lzZSBiZSBsZWZ0IHRvIHRoZWlyIG93biBkZXZpY2UuDQoN Ckxvb2tpbmcgZm9yd2FyZCBmb3IgeW91ciBmZWVkYmFjayENCg0KQiZWDQoNCu+7v09uIDIvMTIv MjEsIDEyOjQxLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQogICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0DQogICBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFZpdHRvcmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlDQogICBJ RVRGIHJlcG9zaXRvcnkuDQoNCiAgIE5hbWU6ICAgICAgICBkcmFmdC1iZXJ0b2NjaS1vYXV0aDIt dG1pLWJmZg0KICAgUmV2aXNpb246ICAgIDAwDQogICBUaXRsZTogICAgICAgIFRva2VuIE1lZGlh dGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZA0KICAgRG9j dW1lbnQgZGF0ZTogICAgMjAyMS0wMi0xMg0KICAgR3JvdXA6ICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCiAgIFBhZ2VzOiAgICAgICAgMTYNCiAgIFVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAw LnR4dA0KICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLw0KICAgSHRtbDogICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYt MDAuaHRtbA0KICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMA0KDQoNCiAgIEFic3RyYWN0Og0KICAgICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4gZGVs ZWdhdGUgYWNjZXNzDQogICAgICB0b2tlbiBhY3F1aXNpdGlvbiB0byBhIGJhY2tlbmQgY29tcG9u ZW50LiAgSW4gc28gZG9pbmcsIHRoZSBmcm9udGVuZA0KICAgICAgY2FuIGFjY2VzcyByZXNvdXJj ZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBidXJkZW4gb2YNCiAgICAg IGNvbW11bmljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHBlcnNpc3Rpbmcg dG9rZW5zLCBhbmQNCiAgICAgIHBlcmZvcm1pbmcgb3BlcmF0aW9ucyB0aGF0IGFyZSBmcmF1Z2h0 IHdpdGggc2VjdXJpdHkgY2hhbGxlbmdlcyB3aGVuDQogICAgICBleGVjdXRlZCBpbiBhIHVzZXIg YWdlbnQsIGJ1dCBhcmUgc2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZA0KICAgICAg YnkgYSBjb25maWRlbnRpYWwgY2xpZW50IHJ1bm5pbmcgb24gYSBiYWNrZW5kLg0KDQoNCg0KDQog ICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9y Zz4uDQoNCiAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBp ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoDQoNCkZvcmdlUm9jayB2YWx1ZXMgeW91ciBQcml2YWN5PGh0dHBz Oi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1wcml2YWN5Pl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg== --_000_CO6PR18MB4052FF780E71AE2FF62B173EAE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwMCwgbGkubXNvbm9ybWFsMDAsIGRpdi5tc29ub3Jt YWwwMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWwwOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29jaHBkZWZhdWx0LCBsaS5tc29jaHBkZWZhdWx0LCBkaXYu bXNvY2hwZGVmYXVsdA0KCXttc28tc3R5bGUtbmFtZTptc29jaHBkZWZhdWx0Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5lbWFpbHN0eWxlMTkNCgl7bXNvLXN0 eWxlLW5hbWU6ZW1haWxzdHlsZTE5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4MjgwMzg3OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTEwODYwNDI4OTI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3Mjg1MDM0 NzA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM0MDU4NTg2Mjt9DQpAbGlzdCBsMTpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjkzNjEzNTcyOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQwOTM0 NzI0ODt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjEyMzUwOTM0NjE7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjEwODM1Nzc0NzQ7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28t bGlzdC1pZDoxMzIyNDcwMjM5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc2MzY2NjgxMDt9 DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjE1ODU4MDExMzE7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi05NzQxMjQ2NDA7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1p ZDoxNjQ1MTYzMzU3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDE5MzQ0MTM4O30NCkBsaXN0 IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDY6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDY6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSB0 aGluZyBJIHNob3VsZCBhZGQgaGVyZSwgYW5kIHRoZW4gSeKAmWxsIGhlYWQgdG8gYmVkIGdpdmVu IHRoYXQgaXTigJlzIGFsbW9zdCA1YW0gaGVyZQ0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FwcGxlIENvbG9yIEVtb2ppJnF1b3Q7Ij4mIzEyODUyMjs8L3NwYW4+LTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+SSBhbSBmdWxseSBiZWhpbmQgY29kZStQS0NF PC9iPi4gQXV0aDAgaGFzIGJlZW4gc3VwcG9ydGluZyBjb2RlK1BLQ0UgaW4gaXRzIEpTIFNQQSBT REtzLCBpbmNsdWRpbmcgcmVmcmVzaCB0b2tlbiByb3RhdGlvbiBzdXBwb3J0LCBzaW5jZSBlYXJs eSBsYXN0IHllYXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0cmVz cyB0aGlzIHNvIHRoYXQgbm8gb25lIHRoaW5rcyB0aGlzIGFuIGF0dGVtcHQgdG8gZ2V0IG91dCBv ZiBzdXBwb3J0aW5nIGNvZGUrUEtDRSwgaXTigJlzIG5vdC4gRm9yIHRydWUgU1BBcyAobm8gYmFj a2VuZCkgdGhhdCByZW1haW5zIHRoZSBtYWluIHdheSBmb3IgZW5hYmxpbmcgZnJvbnRlbnRzIHRv IGNhbGwgQVBJLiBUaGlzIGlzICZuYnNwO21vcmUgYWJvdXQgdHJ5aW5nIHRvIHRha2UgYWR2YW50 YWdlIG9mIHRoZQ0KIHByZXNlbmNlIG9mIHRoZSBiYWNrZW5kIHRvIG1ha2UgdGhpbmdzIHNpbXBs ZXIgd2hlbiB2aWFibGUsIGFuZCB0byBicmluZyBzb21lIGd1aWRhbmNlIHRvIGVtZXJnaW5nIHBy YWN0aWNlcyB0aGF0IHJpc2sgZHJpZnRpbmcgaW50byBpbnNlY3VyZSB3YXRlcnMgd2l0aG91dCBp dC4gJm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29t Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDA0OjI3 PGJyPg0KPGI+VG86IDwvYj5XYXJyZW4gUGFyYWQgJmx0O3dwYXJhZD00MHJob3N5cy5jaEBkbWFy Yy5pZXRmLm9yZyZndDssIE5laWwgTWFkZGVuICZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t Jmd0Ozxicj4NCjxiPkNjOiA8L2I+b2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24g SW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBXYXJyZW4s IHRoYW5rcyBmb3IgdGhlIHRob3VnaHRmdWwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbmxpbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0Omw1IGxldmVsMSBsZm8xIj4uIEl0IGludHJvZHVjZXMgYSBwc2V1ZG8g QVMtbGlrZSBwcm94eSB3aGljaCBub3cgaGFzIGFsbCB0aGUgcmVxdWlyZW1lbnRzIG9mIGFuIEFT IGFuZCBtb3JlLiBXaGlsZSBBUyBTREtzIHByb3ZpZGUgZWFzeSB3YXlzIGZvciBjbGllbnQgVUlz IHRvIGVmZmVjdGl2ZWx5IGRlYWwgd2l0aCBjb21tdW5pY2F0aW9uIHZpYQ0KIHRoZSBBUywgdGhl cmUncyBubyB3YXkgZm9yIHRoZSBBUyB0byBwcm92aWRlIHN0YW5kYXJkIEFTIHNwZWNpZmljIHNl cnZpY2VzIHByb3RvdHlwZXMgdG8gc3VwcG9ydCBCRkYuIFRoYXQgbWVhbnMgdGhhdCBldmVyeW9u ZSBpcyB3cml0aW5nIHRoZWlyIG93biBCRkYgQVMtcHJveHkuPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UTUktQkZGIGRvZXMgcHJvdmlkZSBhIHNvcnQgb2YgcHJv eHkgZm9yIHRoZSBBUywgYnV0IGl0IGlzIHZlcnkgY29uc3RyYWluZWQgYm90aCBpbiBmdW5jdGlv bmFsaXR5IChvbmx5IG9uZSBzaW1wbGUgcmVxdWVzdCB0eXBlKSBhbmQgdG9wb2xvZ3kgKG9ubHkg b25lIHJlcXVlc3RvciB0eXBlLCB3aXRoIGFzc3VtcHRpb25zIGFib3V0IHNlc3Npb25zLCBvcmln aW4gcHJvdmVuYW5jZSBldGMpIGhlbmNlIHRoZSByZXF1aXJlbWVudHMNCiBhcmUgYSB2ZXJ5IGxp bWl0ZWQgc3Vic2V0IG9mIGEgZnVsbCBibG93biBBUy48YnI+DQpJbiB0ZXJtcyBvZiBldmVyeW9u ZSBkb2luZyB0aGVpciBvd24gaW1wbGVtZW50YXRpb24sIHRoZSBpbnRlbnQgaGVyZSBpcyB0aGUg ZXhhY3Qgb3Bwb3NpdGUuIEJ5IHByb3ZpZGluZyBndWlkYW5jZSBvbiBob3cgdG8gZm9ybWF0IHJl cXVlc3RzL3Jlc3BvbnNlcyBhbmQgd2hhdCBlbmRwb2ludHMgdG8gcmVmZXIgdG8sIHRoZSBpbXBs ZW1lbnRhdGlvbiBkZXRhaWxzIGNhbiBiZSBmYWN0b3JlZCBvdXQgZnJvbSBpbmRpdmlkdWFsIGFw cHMgYW5kIHN0YWNrcywNCiBmYWNpbGl0YXRpbmcgaW50ZXJvcGVyYWJpbGl0eS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzIiPlsu Ll0gV2hpY2ggaXNuJ3QgZXZlciBqdXN0aWZpZWQsIGJ1dCBldmVuIGlmIHdlIGFjY2VwdCB0aGF0 IGFzIGEgdHJ1ZSBwcmVtaXNlLCB3aGF0IGFyZSB0aGVzZSBBUyBkb2luZyB0aGF0IGV2ZW4gcmVx dWlyZSBhIEJGRj88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YW0gbm90IHN1cmUgaG93IHRvIGludGVycHJldCB0aGUgc3RhdGVtZW50IGFib3V0IOKAnGV2ZXIg anVzdGlmaWVk4oCdLiBUaGlzIGhhcyBsaXR0bGUgdG8gZG8gd2l0aCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIuIE5vdCBldmVyeSBhcHBsaWNhdGlvbiBjYW4gaGF2ZSBhIGJhY2tlbmQgdGhhdCBl eHBvc2VzIGEgZmHDp2FkZSByZXBsaWNhdGluZyBhbGwgdGhlIEFQSXMgdGhlIGZyb250ZW5kIG5l ZWQgdG8gaW52b2tlLA0KIGZvciBhbGwgc29ydHMgb2YgcmVhc29uczogbWFpbnRlbmFuY2UsIHBl cmZvcm1hbmNlLCBza2lsbHMgb2YgdGhlIGRldmVsb3BlcnMgaW52b2x2ZWQsIGNhcGFiaWxpdGll cyBvZiB0aGUgc3RhY2tzIG9mIGNob2ljZSwgYW5kIHNvIG9uLiBUaGlzIGlzbuKAmXQgdGhlb3Jl dGljYWwsIEkgaGFkIHRoaXMgZGlzY3Vzc2lvbnMgbWFueSB0aW1lcyB3aXRoIHByb3NwZWN0cyBh bmQgZGV2ZWxvcGVycy4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj5IeXBvdGhldGljYWxseSB5b3UgY291bGQgYXJn dWUgdGhhdCB0aGUgYXV0aCBjb2RlIGZsb3cgcmVxdWlyZXMgYSBCRkYgYW5kIHRoYXQncyByZXF1 aXJlZCBmb3IgdXNlciBsb2dpbiBzaW5jZSBpbXBsaWNpdCZuYnNwO2Zsb3cgbm8gbG9uZ2VyIGV4 aXN0cywgYnV0IHRoYXQgaXNuJ3QgdHJ1ZS4gWW91IGNhbiB1c2UgY2xpZW50DQogc2lkZSBQS0NF IGZvciB2YWxpZGF0aW9uIG9mIHRoZXNlIHZpYSBub3QgcmVxdWlyaW5nIHRoZSBjbGllbnQgc2Vj cmV0IGluIHRoZSBmcm9udCBlbmQsIGFuZCB0aGVuIHRoZSBwcm9ibGVtIHRoZXJlIGlzIHNvbHZl ZC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNvbmNyZXRl IHRlcm1zLCB0aGluZ3MgYXJlIGEgYml0IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiDigJxhIGdyYW50 IGZvciBTUEFzIGFscmVhZHkgZXhpc3TigJ0uIEkgYW0gd2VsbCBhd2FyZSB0aGF0IGNvZGUrUEtD RSBpcyBhIHZpYWJsZSBzb2x1dGlvbiBmb3IgU1BBcyB0byBnZXQgYWNjZXNzIHRva2VucywgaG93 ZXZlciB0aGF0IGhhcyBpdHMgb3duIGNoYWxsZW5nZXMuIEZvciBleGFtcGxlLCBpZiB5b3Ugd2Fu dA0KIHRvIHVzZSByZWZyZXNoIHRva2VucyBpbiBpdCwgeW91IG5lZWQgdG8gc2VuZGVyIGNvbnN0 cmFpbiB0aGVtIG9yIHN1cHBvcnQgcmVmcmVzaCB0b2tlbiByb3RhdGlvbi4gSWYgeW91IGNoZWNr IHRoZSBjdXJyZW50IHNpdHVhdGlvbiBhY3Jvc3MgdGhlIGluZHVzdHJ5LCB5b3XigJlsbCBzZWUg dGhhdCB2ZXJ5IGZldyBTREtzIGFjdHVhbGx5IGRvIHN1cHBvcnQgcm90YXRpb24gb3Igc2VuZGVy IGNvbnN0cmFpbnQgdG9kYXktIGFyZ3VhYmx5IGludHJvZHVjaW5nDQogYSBuZXcgc2VjdXJpdHkg aXNzdWUuIEFuZCBvZiBjb3Vyc2UsIHRoZXJl4oCZcyB0aGUgaHVnZSBkZWJhY2xlIGFib3V0IHNh dmluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZS0gc29tZXRoaW5nIHRoYXQgbWFueSBhcHBsaWNh dGlvbnMgbmVlZCB0byBkbyBpbiBvcmRlciB0byBvZmZlciB0aGUgZXhwZXJpZW5jZSB0aGVpciBj dXN0b21lcnMgcmVxdWlyZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiBhIFNQQSBhcHAgZG9lcyBub3QgaGF2ZSBhIGJhY2tlbmQsIGNvZGUrUEtDRSBpcyB0 aGUgb25seSBnYW1lIGluIHRvd24uIElmIGl0IGhhcyBhIGJhY2tlbmQgQU5EIGNhbiBsZWF2ZSBh bGwgYWN0dWFsIEFQSSBjYWxscyB0byBpdCwgdGhlcmXigJlzIG5vIG5lZWQgdG8gZ2V0IHRva2Vu cyBpbiB0aGUgdXNlciBhZ2VudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJ1dCBpZiB5b3UgYXJlIGluIG9uZSBzaXR1YXRpb24gd2hlcmUgeW91IGRvIGhhdmUgYSBiYWNr ZW5kIGFuZCBjYW5ub3QgZGVsZWdhdGUgQVBJIGNhbGxzIChzZWUgbXkgcHJlY2VkaW5nIGNvbW1l bnQpLCB0aGVuIFRNSS1CRkYgY2FuIGdldCB0b2tlbnMgdG8geW91ciBmcm9udGVuZCB3aXRob3V0 IHJlcXVpcmluZyBjb21wbGV4IGphdmFzY3JpcHQgbG9naWMsIHdpdGhvdXQgaGF2aW5nIHRvIHBl cnNpc3QgYW55dGhpbmcNCiBpbiBsb2NhbCBzdG9yYWdlIGFuZCB3aXRob3V0IHJlcXVpcmluZyB0 aGUgQVMgdG8gc3VwcG9ydCByb3RhdGlvbiBvciBzZW5kZXIgY29uc3RyYWludC4gQXMgbG9uZyBh cyB0aGUgdHJhZmZpYyB3aXRoIGJmZi10b2tlbiBwcm94eSBpcyBoYXJkZW5lZCwgSSB3b3VsZCBh cmd1ZSBUTUktQkZGIG1pZ2h0IGFjdHVhbGx5IGJlIGVhc2llciB0byBpbXBsZW1lbnQgc2VjdXJl bHkgdGhhdCBjb2RlK1BLQ0Urcm90YXRpb24vU0MuIEhhdmluZyBhY2Nlc3MNCiB0b2tlbnMgaW4g dGhlIGZyb250ZW5kIHJlbWFpbnMgbm90IGdyZWF0LCBidXQgaXQgc2VlbXMgdGhhdCBnaXZpbmcg cGVvcGxlIHdobyB3b3VsZCBkbyBpdCBhbnl3YXkgc29tZSBndWlkYW5jZSBpcyBiZXR0ZXIgdGhh biBsZWF2aW5nIHRoZW0gYXQgdGhlaXIgb3duIGRldmljZS0gdW5sZXNzIHdlIGNvbmNsdWRlIHRo YXQgdGhpcyBmbG93IGNhbm5vdCBiZSBzZWN1cmVkLCBpbiB3aGljaCBjYXNlIEkgYWdyZWUgd2Ug c2hvdWxkIGV4cGxpY2l0bHkNCiBpZG5jaWF0ZSB0aGlzIGFzIGFudGkgcGF0dGVybi4gQnV0IHNv IGZhciwgaXQgc2VlbXMgc3RpbGwgdG8gYmUgZGVtb3NudHJhdGVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+VGhlcmUgd2Fz IGFsc28gdGhlIGFyZ3VtZW50IG9mDQo8Yj50aGVyZSBhcmUgbG90cyBvZiBwZW9wbGUgZG9pbmcg dGhpczwvYj4sIHdoaWNoIGlzIGFsd2F5cyBhIHRlcnJpYmxlIGFyZ3VtZW50LCBidXQgZXZlbiBp ZiB3ZSBkbyBwZXJtaXQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiwgd2Ugc3RpbGwgbmVlZCB0byBh bnN3ZXIgdGhlDQo8Yj53aHkuIDwvYj5XaHkgYXJlIGRldmVsb3BlcnMgY3JlYXRpbmcgQkZGIGZv ciB0aGVpciBmcm9udGVuZHMgdG8gY29tbXVuaWNhdGUgd2l0aCBhbiBBUy4gSXMgaXQgYmVjYXVz ZSBBUyBhcmUgdGVycmlibGUsIGlzIGl0IGJlY2F1c2UNCjxiPmZyb250IGVuZHMgYXMgYSBzZXJ2 aWNlPC9iPiZuYnNwO2FyZSB0ZXJyaWJsZSwgZXRjLi4uIFVudGlsIHdlIGtub3cgd2h5IHRoaXMg aXMgaGFwcGVuaW5nIGNvbmNyZXRlbHksIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGVuY291cmFn ZSBmdXJ0aGVyIHVzZSBvZiBhIHBhdHRlcm4gcmlmZSB3aXRoIHBvdGVudGlhbCBzZWN1cml0eSBy aXNrcyBieSB0ZWxsaW5nIGV2ZXJ5b25lIGhvdyB5b3UgY2FuIGRvIGl0IChiZWNhdXNlIHRoZSBn dWlkYW5jZSB3ZQ0KIGFyZSZuYnNwO29mZmVyaW5nIGRvZXNuJ3QgZXZlbiBzbGlnaHRseSBpbmNy ZWFzZSBzYWZldHkpLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHByZWNlZGluZyBjb21tZW50cyBzaG91bGQgaGF2ZSBzaGVkIG1vcmUgbGlnaHQgYWJvdXQg dGhlIHdoeSwgYW5kIG9uIHNvbWUgb2YgdGhlIHNlY3VyaXR5IGNvbmNlcm5zICh0aGVyZSB3YXMg b25lIGNvbmNlcm4gcmFpc2VkIGJ5IE5laWwsIGFuZCBpdCBzZWVtcyB0aGVyZSBhcmUgcG9zc2li bGUgbWl0aWdhdGlvbnMgaW4gcGxhY2UpIHBsdXMgaG93IHRoaXMgbWlnaHQgYWN0dWFsbHkgaW5j cmVhc2Ugc2FmZXR5DQogaW4gc29tZSBhc3BlY3RzLiBCdXQgdG8gYWRkIG1vcmUgY29sb3IsIG9u ZSBvZiB0aGUgb3RoZXIgcmVhc29ucyBmb3Igd2hpY2ggdGhpcyBpcyBoYXBwZW5pbmcgaXMgYmVj YXVzZSBpdOKAmXMgc2ltcGxlLiBCYWNrZW5kIE9BVXRoL09JREMgU0RLcyBsaWtlIG1pZGRsZXdh cmVzIGFuZCBzaW1pbGFyIGFyZSB2ZXJ5IG1hdHVyZSBhdCB0aGlzIHBvaW50LCBhbmQgdGhleSBh cmVu4oCZdCBzYWRkbGVkIGJ5IGEgbG90IG9mIHRoZSBjb21wbGV4aXR5IGFuZA0KIHVuY2VydGFp bmx5IHRoYXQgYnJvd3NlciBiYXNlZCBTREtzIGNhcnJ5LiBUaGluZ3MgbGlrZSBJRSB6b25lcywg SVRQLCBTYW1lU2l0ZSBhbmQgb3VyIG93biBjaGFuZ2luZyBndWlkYW5jZSAoZm9yIGdvb2QgcmVh c29ucykgcGx1cyBkaXNvbW9nZW5lb3VzIHN1cHBvcnQgZnJvbSBwcm92aWRlcnMgb2YgdGhlIGZl YXR1cmVzIHJlcXVpcmVkIGZvciB0aGUgbGF0ZXN0IGd1aWRhbmNlIGNyZWF0ZSB1bmNlcnRhaW50 eSBhbmQgY29tcGxleGl0eSB0aGF0DQogbWFueSBub24taW5pdGlhdGVkIHdvbuKAmXQgcHV0IHVw IHdpdGguIEFkZCB0byB0aGlzIHRoYXQgdGhlIG1vcmUgYXBwIGRldmVsb3BtZW50IG1vdmVzIHRv IHRoZSBmcm9udGVuZCwgdGhlIG1vcmUgeW91IGRvbuKAmXQgZ2V0IGZ1bGwgc3RhY2sgZGV2ZWxv cGVycyBhbmQgZ2V0dGluZyBhIGZyb250ZW5kIGRldmVsb3BlciB0byBkZWFsIHdpdGggYWxsIHRo b3NlIHF1aXJrcyBpcyBoYXJkLiBHZXR0aW5nIHRva2VucyB0aHJ1IHdlbGwgc3VwcG9ydGVkIG1p ZGRsZXdhcmVzDQogYW5kIGZvcndhcmQgdGhlbSB0byB0aGUgZnJvbnRlbmQgaXMgc2ltcGxlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgdG8gYmUgY2xlYXIuIFRo aXMgZXhhY3QgdG9wb2xvZ3kgaGFzIGJlZW4gY29uc2lkZXJlZCBkaXNjdXNzZWQgaW4gdGhlIHBh c3QgZHVyaW5nIElFVEYgbWVldGluZ3MsIGluIE1vbnRyZWFsIHdlIGhhZCBhIGRpc2N1c3Npb24g YWJvdXQgaW5jbHVkaW5nIGl0IGluIHNvbWUgQkNQIGFuZCB3aGV0aGVyIHdlIHNob3VsZCBoYXZl IGEgbWVjaGFuaXNtIGZvciB0aGUgY2xpZW50IHRvIHNpZ25hbCB0byB0aGUNCiBBUyB0aGF0IHRo ZSB0b2tlbnMgd2lsbCBiZSB1c2VkIGJ5IGNvZGUgZXhlY3V0aW5nIGluIGEgd2Vha2VyIHNlY3Vy aXR5IGNvbnRleHQgKHVzZXIgYWdlbnQpIHRoYW4gdGhlIHJlcXVlc3RvcuKAmXMgKGNvbmZpZGVu dGlhbCBjbGllbnQgb24gYmFja2VkKS4gSSBhbSBzdXJlIHdlIGNhbiBmaW5kIHRoZSBtaW51dGVz IG9mIHRoYXQuIFRoaXMgaXNu4oCZdCBzb21ldGhpbmcgY29tcGxldGVseSBsZWZ0IGZpZWxkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvNSI+RnVydGhlciwgZXZlbiBpZiB3ZSB3ZXJlIHRvIGFjY2VwdCB0aGlzIHBhdHRlcm4gYW5k IHdhbnQgdG8gY3JlYXRlIGEgc3RhbmRhcmQgYXJvdW5kIGl0LCB3ZSBhcmUgZWZmZWN0aXZlbHkg Y3JlYXRpbmcgYW4gQVMgcHJveHkgaGVyZSwgd2hpY2ggbWVhbnMgd2Ugc2hvdWxkIHJlcXVpcmUg aXQgdG8gYWN0IGxpa2UNCiBhbiBBUywgYW5kIGRlbGVnYXRlIHRoZSBzcGVjaWZpY2F0aW9uIG9m IHJlc291cmNlcywgZW5kcG9pbnRzLCB0ZXJtaW5vbG9neSwgYW5kIHBhdHRlcm5zIHRvIGV4aXN0 aW5nIG9yIGZ1dHVyZSBBUyByZWxhdGVkIFJGQ3MuDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhlIHNjb3BlIG9mIHRo ZSBwcm9wb3NhbCB3YXJyYW50cyBkb2luZyBhbCB0aGF0LiBDb3VsZCB5b3UgcG9pbnQgYXQgdGhl IGFyZWEgaW4gdGhlIHNwZWMgdGhhdCBzdWdnZXN0IHdl4oCZZCBuZWVkIHRvIGFkZCBhbnl0aGlu ZyBiZXlvbmQgd2hhdOKAmXMgc3VnZ2VzdGVkIGF0IHRoZSBtb21lbnQgdG8gYWNoaWV2ZSB0aGUg c3RhdGVkIGdvYWxzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsNiBsZXZlbDEgbGZvNiI+QW5kIHRoZXJlZm9yZSBpbiBjb25jbHVzaW9uIHdlIHNob3Vs ZCBmb2N1cyBvbmx5IG9uIHRoZSBhc3BlY3RzIHRoYXQgYXJlIGFic29sdXRlbHkgcmVxdWlyZWQg d2hpY2ggYXJlbid0IGFscmVhZHkgcHJlc2VudCBpbiBzb21lIGZvcm0gaW4gZXhpc3RpbmcgQVMg cmVsYXRlZCBSRkNzLCBidXQgd2hhdCBhcmUgdGhvc2U/PG86cD48L286cD48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHN0aWxsIG1pc3NpbmcgaG93IHRoaXMgaGFzIHRvIGRv IHdpdGggbWlzc2luZyBBUyBmdW5jdGlvbmFsaXR5LiBPbmUgb2YgdGhlIHRoaW5ncyB3ZSB0cmll ZCB0byBkbyB3YXMgbm90IHRvIHJlcXVpcmUgYW55IGNoYW5nZSB0byB0aGUgQVMuIFRoZSBwcm9i bGVtIGJlaW5nIHNvbHZlZCBoZXJlIGlzIGhvdyB0byBhbGxvdyBqYXZhc2NyaXB0IGRldmVsb3Bl cnMgdG8gY2FsbCBBUEkgZGlyZWN0bHkgZnJvbQ0KIHRoZWlyIGZyb250ZW5kIHdoZW4gdGhleSBo YXZlIGEgYmFja2VuZCB3aXRoIGJhc2ljIG9hdXRoIGNhcGFiaWxpdGllcyBhdCB0aGVpciBkaXNw b3NhbCwgaW4gdGhlIHNpbXBsZXN0IHBvc3NpYmxlIHdheS4gQ2hhbmdlcyBpbiB0aGUgQVMgZG9l buKAmXQgYXBwZWFyIHRvIGJlIG5lY2Vzc2FyeSB0aGVyZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2 ZWwxIGxmbzciPlRoZSBvbmUgY291bnRlcnBvaW50Jm5ic3A7dG8gYWxsIG9mIHRoaXMgaXMgdGhl IHBvdGVudGlhbCBpbnRyb2R1Y3Rpb24gb2YgZG9tYWluIHNwZWNpZmljDQo8Yj5jb29raWU8L2I+ IGxhbmd1YWdlICh3aGljaCBkb2Vzbid0IGV4aXN0IGluIHRoZSBjdXJyZW50IGRyYWZ0KS4gQ29u Y3JldGVseSwgPGI+DQpsZXQncyBhZGQgYSByZXNwb25zZV90eXBlPWNvb2tpZTwvYj4sIHRvIEFT IHRvIHN1cHBvcnQgZG9tYWluIGZpcnN0LXBhcnR5IGNvb2tpZXMgYW5kIHNlc3Npb24gbWFuYWdl bWVudC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvdWxkIHlv dSBleHBhbmQgb24gaG93IHlvdSBlbnZpc2lvbiB0aGlzIHdvdWxkIHdvcmsvc29sdmUgdGhlIHBy b2JsZW1zIGRlc2NyaWJlZCBhYm92ZT8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9t OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5X YXJyZW4gUGFyYWQgJmx0O3dwYXJhZD00MHJob3N5cy5jaEBkbWFyYy5pZXRmLm9yZyZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwMTo1MTxicj4NCjxi PlRvOiA8L2I+TmVpbCBNYWRkZW4gJmx0O25laWwubWFkZGVuQGZvcmdlcm9jay5jb20mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2lAYXV0 aDAuY29tJmd0Oywgb2F1dGggJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRp b24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gZmxhdCBvdXQgcmVq ZWN0IHRoZSBwcmVtaXNlIG9mIHRoaXMgZHJhZnQuIEl0IGludHJvZHVjZXMgYSBwc2V1ZG8gQVMt bGlrZSBwcm94eSB3aGljaCBub3cgaGFzIGFsbCB0aGUgcmVxdWlyZW1lbnRzIG9mIGFuIEFTIGFu ZCBtb3JlLiBXaGlsZSBBUyBTREtzIHByb3ZpZGUgZWFzeSB3YXlzIGZvciBjbGllbnQgVUlzIHRv IGVmZmVjdGl2ZWx5IGRlYWwgd2l0aCBjb21tdW5pY2F0aW9uIHZpYSB0aGUgQVMsDQogdGhlcmUn cyBubyB3YXkgZm9yIHRoZSBBUyB0byBwcm92aWRlIHN0YW5kYXJkIEFTIHNwZWNpZmljIHNlcnZp Y2VzIHByb3RvdHlwZXMgdG8gc3VwcG9ydCBCRkYuIFRoYXQgbWVhbnMgdGhhdCBldmVyeW9uZSBp cyB3cml0aW5nIHRoZWlyIG93biBCRkYgQVMtcHJveHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGRpdGlvbmFsbHksIEkgdG9vIGFtIGxhY2tpbmcgdGhl IGNsYXJpdHkgb24gdGhlIDxiPldIWTwvYj4uIFRoZSBvbmx5IHRoaW5nIG1lbnRpb25lZCBpbiB0 aGUgZHJhZnQgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhdCBhcHByb2FjaCBpcyBub3QgYWx3YXlzIHZpYWJsZSwgYXMgaW4gdGhlIGFic2VuY2Ugb2Yg cmV2ZXJzZSBwcm94eSBkZXBsb3ltZW50cyB0aGUgY3JlYXRpb24gYW5kIG1haW50ZW5hbmNlIG9m IGEgZmFjYWRlIGZvciBtdWx0aXBsZSBBUElzIGNhbiBiZSBleHBlbnNpdmU8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGljaCBpc24n dCBldmVyIGp1c3RpZmllZCwgYnV0IGV2ZW4gaWYgd2UgYWNjZXB0IHRoYXQgYXMgYSB0cnVlIHBy ZW1pc2UsIHdoYXQgYXJlIHRoZXNlIEFTIGRvaW5nIHRoYXQgZXZlbiByZXF1aXJlIGEgQkZGPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IeXBv dGhldGljYWxseSB5b3UgY291bGQgYXJndWUgdGhhdCB0aGUgYXV0aCBjb2RlIGZsb3cgcmVxdWly ZXMgYSBCRkYgYW5kIHRoYXQncyByZXF1aXJlZCBmb3IgdXNlciBsb2dpbiBzaW5jZSBpbXBsaWNp dCZuYnNwO2Zsb3cgbm8gbG9uZ2VyIGV4aXN0cywgYnV0IHRoYXQgaXNuJ3QgdHJ1ZS4gWW91IGNh biB1c2UgY2xpZW50IHNpZGUgUEtDRSBmb3IgdmFsaWRhdGlvbiBvZiB0aGVzZSB2aWEgbm90IHJl cXVpcmluZyB0aGUNCiBjbGllbnQgc2VjcmV0IGluIHRoZSBmcm9udCBlbmQsIGFuZCB0aGVuIHRo ZSBwcm9ibGVtIHRoZXJlIGlzIHNvbHZlZC4gQW5kIGlmIHlvdSBhcmd1ZSB0aGF0IHRoaXMgY2Fu J3QgYmUgZG9uZSwgdGhlbiB0aGUgc29sdXRpb24gaXMgaW50cm9kdWNpbmcgYSBiZXR0ZXIgd2F5 IHRvIGhhbmRsZSB0aGlzIHNvIHRoYXQgYSBCRkYgZm9yIEFTIGZsb3dzIGRvbid0IGhhdmUgdG8g ZXhpc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvIHdoYXQgY29uY3JldGUgcHJvYmxlbSBpcyB0aGlzIHNvbHZpbmc/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIHdhcyBhbHNv IHRoZSBhcmd1bWVudCBvZiA8Yj50aGVyZSBhcmUgbG90cyBvZiBwZW9wbGUgZG9pbmcgdGhpczwv Yj4sIHdoaWNoIGlzIGFsd2F5cyBhIHRlcnJpYmxlIGFyZ3VtZW50LCBidXQgZXZlbiBpZiB3ZSBk byBwZXJtaXQgdGhhdCBpbiB0aGUgZGlzY3Vzc2lvbiwgd2Ugc3RpbGwgbmVlZCB0byBhbnN3ZXIg dGhlDQo8Yj53aHkuIDwvYj5XaHkgYXJlIGRldmVsb3BlcnMgY3JlYXRpbmcgQkZGIGZvciB0aGVp ciBmcm9udGVuZHMgdG8gY29tbXVuaWNhdGUgd2l0aCBhbiBBUy4gSXMgaXQgYmVjYXVzZSBBUyBh cmUgdGVycmlibGUsIGlzIGl0IGJlY2F1c2UNCjxiPmZyb250IGVuZHMgYXMgYSBzZXJ2aWNlPC9i PiZuYnNwO2FyZSB0ZXJyaWJsZSwgZXRjLi4uIFVudGlsIHdlIGtub3cgd2h5IHRoaXMgaXMgaGFw cGVuaW5nIGNvbmNyZXRlbHksIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGVuY291cmFnZSBmdXJ0 aGVyIHVzZSBvZiBhIHBhdHRlcm4gcmlmZSB3aXRoIHBvdGVudGlhbCBzZWN1cml0eSByaXNrcyBi eSB0ZWxsaW5nIGV2ZXJ5b25lIGhvdyB5b3UgY2FuIGRvIGl0IChiZWNhdXNlIHRoZSBndWlkYW5j ZSB3ZQ0KIGFyZSZuYnNwO29mZmVyaW5nIGRvZXNuJ3QgZXZlbiBzbGlnaHRseSBpbmNyZWFzZSBz YWZldHkpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5GdXJ0aGVyLCBldmVuIGlmIHdlIHdlcmUgdG8gYWNjZXB0IHRoaXMgcGF0dGVybiBhbmQg d2FudCB0byBjcmVhdGUgYSBzdGFuZGFyZCBhcm91bmQgaXQsIHdlIGFyZSBlZmZlY3RpdmVseSBj cmVhdGluZyBhbiBBUyBwcm94eSBoZXJlLCB3aGljaCBtZWFucyB3ZSBzaG91bGQgcmVxdWlyZSBp dCB0byBhY3QgbGlrZSBhbiBBUywgYW5kIGRlbGVnYXRlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHJl c291cmNlcywgZW5kcG9pbnRzLA0KIHRlcm1pbm9sb2d5LCBhbmQgcGF0dGVybnMgdG8gZXhpc3Rp bmcgb3IgZnV0dXJlIEFTIHJlbGF0ZWQgUkZDcy4gKFdlIGFscmVhZHkgaGF2ZSBhIHByb2JsZW0g d2l0aCB0aGUgY3VycmVudCBkcmFmdCBhcyBpdCBhdHRlbXB0cyB0byByZWRlZmluZSBhbmQgaW50 cm9kdWNlIG5ldyB0ZXJtcy9wYXR0ZXJucyB0aGF0IGhhdmUgdGhlIHNhbWUgZnVuY3Rpb25hbGl0 eSBhcyBleGlzdGluZyBvbmVzIGluIHRoZSBBUywgeWV0IGZhaWwgdG8gY2FwdHVyZQ0KIHRoZSBm dWxsIGltcG9ydGFuY2Ugb2YgdGhlIG9yaWdpbmFsIFJGQ3MuIFRoaXMgaXMgYmFkIGR1cGxpY2F0 aW9uKS4gQW5kIHRoZXJlZm9yZSBpbiBjb25jbHVzaW9uIHdlIHNob3VsZCBmb2N1cyBvbmx5IG9u IHRoZSBhc3BlY3RzIHRoYXQgYXJlIGFic29sdXRlbHkgcmVxdWlyZWQgd2hpY2ggYXJlbid0IGFs cmVhZHkgcHJlc2VudCBpbiBzb21lIGZvcm0gaW4gZXhpc3RpbmcgQVMgcmVsYXRlZCBSRkNzLCBi dXQgd2hhdCBhcmUgdGhvc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBvbmUgY291bnRlcnBvaW50Jm5ic3A7dG8gYWxsIG9mIHRoaXMg aXMgdGhlIHBvdGVudGlhbCBpbnRyb2R1Y3Rpb24gb2YgZG9tYWluIHNwZWNpZmljDQo8Yj5jb29r aWU8L2I+IGxhbmd1YWdlICh3aGljaCBkb2Vzbid0IGV4aXN0IGluIHRoZSBjdXJyZW50IGRyYWZ0 KS4gQ29uY3JldGVseSwgPGI+DQpsZXQncyBhZGQgYSByZXNwb25zZV90eXBlPWNvb2tpZTwvYj4s IHRvIEFTIHRvIHN1cHBvcnQgZG9tYWluIGZpcnN0LXBhcnR5IGNvb2tpZXMgYW5kIHNlc3Npb24g bWFuYWdlbWVudC4gV2hlbiB3ZSBidWlsdCBvdXIgQVMgd2UgZXhwbGljaXRseSBhZGRlZCB0aGlz IHNvIHRoYXQgc2VydmljZXMgY2FuIHVzZSB0aGUgSldUIGZvdW5kIGluIHRoZSBIdHRwT25seSBT YW1lU2l0ZT1TdHJpY3QgY29va2llIGFzIGEgc2VjdXJpdHkgbWVhc3VyZSBhZ2FpbnN0DQogWFNT IGF0dGFja3MgdGhhdCBhdHRlbXB0IHRvIGV4ZmlsdHJhdGUmbmJzcDthY2Nlc3MgdG9rZW5zLiBU aGF0J3MgYSBwb3RlbnRpYWwgc3VnZ2VzdGlvbiBJIHdvdWxkIGZhdm9yLCBhbHRob3VnaCBJIHN0 aWxsIGNhbid0IGtub3cgaWYgdGhhdCBzb2x2ZXMgdGhlIHByb2JsZW0gYmVpbmcgcHJlc2VudGVk IGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSBXYXJyZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29s bGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNv bGlkIHdoaXRlIDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgd2lkdGg9IjE5OSIgaGVpZ2h0PSIz NCIgc3R5bGU9IndpZHRoOjIuMDcyOWluO2hlaWdodDouMzU0MWluIiBpZD0iX3gwMDAwX2kxMDI1 IiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiIgZGF0YS1vdXRsb29rLXRyYWNlPSJGOjB8 VDoxIiBzcmM9ImNpZDp+V1JEMDAwLmpwZyI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0 O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxv dzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1i b3R0b206bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XYXJyZW4gUGFyYWQ8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9y ZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Rm91bmRlciwgQ1RPPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3Rh YmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6d2hpdGUiPlNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQgY29tcGxldGUgeW91ciBhdXRo b3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vYXV0aHJlc3MuaW8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+QXV0aHJlc3M8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgOToxOCBB TSBOZWlsIE1hZGRlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5j b20iPm5laWwubWFkZGVuQGZvcmdlcm9jay5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgaGF2ZSBhIGxvdCBvZiBzZWN1cml0eSBjb25jZXJucyBhYm91dCB0aGlzIGRyYWZ0LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgZHJhZnQgYWxsdWRlcyB0byBzZWN1cml0eSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGhh bmRsaW5nIGFjY2VzcyB0b2tlbnMgaW4gdGhlIGZyb250ZW5kIGJ1dCBuZXZlciByZWFsbHkgc3Bl bGxzIHRoZW0gb3V0LiAmZ3Q7RnJvbSB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaXQgc2Vl bXMgdGhhdCB0aGUgcHJpbWFyeSBjb25jZXJuIGlzIHdpdGggdGhlZnQgb2YgYWNjZXNzIHRva2Vu cyBmcm9tIGxvY2FsDQogc3RvcmFnZS4gVG8gZG8gdGhpcyB5b3XigJlkIG5lZWQgYW4gWFNTIGF0 dGFjay4gQnV0IGluIHRoYXQgY2FzZSwgd291bGRu4oCZdCB0aGUgYXR0YWNrZXIgc2ltcGx5IHVz ZSB0aGUgWFNTIHRvIG1ha2UgYSBjYWxsIHRvIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgaW5zdGVh ZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgcmVjb21tZW5k aW5nIHRoZSB1c2Ugb2YgR0VUIHJlcXVlc3RzIHRvZ2V0aGVyIHdpdGggdGhlIGhpbnQgdG8gdXNl IGNvb2tpZS1iYXNlZCBhdXRoZW50aWNhdGlvbiBpcyBsaWtlbHkgZ29pbmcgdG8gcHVuY2ggYSBo b2xlIGluIG1vc3QgQ1NSRiBkZWZlbnNlcywgd2hpY2ggYXNzdW1lIHRoYXQgR0VUcyBhcmUgc2Fm ZS4gVGhlIG9ubHkgdGhpbmcNCiBwcmV2ZW50aW5nIHRoaXMgYmVpbmcgZXhwbG9pdGFibGUgaXMg Q3Jvc3MtT3JpZ2luIFJlYWQgQmxvY2tpbmcgKDxhIGhyZWY9Imh0dHBzOi8vY2hyb21pdW0uZ29v Z2xlc291cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9z c19vcmlnaW5fcmVhZF9ibG9ja2luZ19leHBsYWluZXIubWQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2Nocm9taXVtLmdvb2dsZXNvdXJjZS5jb20vY2hyb21pdW0vc3JjLysvbWFzdGVyL3NlcnZp Y2VzL25ldHdvcmsvY3Jvc3Nfb3JpZ2luX3JlYWRfYmxvY2tpbmdfZXhwbGFpbmVyLm1kPC9hPikN CiBkdWUgdG8gdGhlIEpTT04gY29udGVudC10eXBlLiBUaGF0IG1ha2VzIG1lIHJlYWxseSBuZXJ2 b3VzLiBXZSBzaG91bGQgYXQgbGVhc3QgbWFuZGF0ZSBYLUNvbnRlbnQtVHlwZS1PcHRpb25zOiBu b3NuaWZmIG9uIHRoYXQgcmVzcG9uc2UuIEnigJlkIGZlZWwgbW9yZSBjb21mb3J0YWJsZSBpZiB0 aGlzIHdhcyBhIFBPU1QgcmVxdWVzdCBvbmx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBTdG95Y2hvIFNsZXB0c292IG1lbnRp b25lZCBpbiB0aGUgb3RoZXIgZW1haWwsIHRoZSBsYWNrIG9mIGZyb250LWNoYW5uZWwgY29tbXVu aWNhdGlvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJPIHNlZW1zIG9kZC4gSWYgdGhlIGJhY2tl bmQgaXMgYWxyZWFkeSBpbXBsaWNpdGx5IHRydXN0ZWQgdGhlbiBjb3VsZG7igJl0IHlvdSBza2lw IE9BdXRoIGFuZCBqdXN0IGdldCB0aGUgYmFja2VuZCB0byBpc3N1ZSBzaG9ydC1saXZlZA0KIEpX VHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3IgQVBJIGFjY2Vzcz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IHdh bnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cgZXRjIHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2Vu IGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFuZGFyZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9y aXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0aGUgU1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2Vy IHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRvIGEgUEFSIHJlcXVlc3QgZmlyc3QgYW5kIHJldHVy bg0KIGEgVVJJIHRoYXQgcmVmZXJlbmNlcyB0aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRh aWxzIGFyZW7igJl0IHBhc3NlZCB0aHJvdWdoIHRoZSBmcm9udGVuZCkuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAlCBOZWlsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gMTIgRmViIDIwMjEs IGF0IDIwOjQ2LCBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9PGEgaHJl Zj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBh dXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+77u/RGVh ciBhbGwsPGJyPg0KQnJpYW4gYW5kIHlvdXJzIHRydWx5IGFyZSBwcm9wb3NpbmcgYSBuZXcgc3Bl Y2lmaWNhdGlvbiB0aGF0IHNob3dzIGhvdyB0aGUgdXNlciBhZ2VudCBmcm9udGVuZCBvZiBhIHdl YiBhcHAgY2FuIGRlbGVnYXRlIHRva2VuIGFjcXVpc2l0aW9uIGFuZCBwZXJzaXN0ZW5jZSB0byBp dHMgYmFja2VuZCwgYW5kIHJlcXVlc3Qgc3VjaCB0b2tlbnMgd2hlbiBuZWVkZWQgZm9yIGRpcmVj dCBhY2Nlc3Mgb2YgcHJvdGVjdGVkIHJlc291cmNlcyBmcm9tIHRoZQ0KIGZyb250ZW5kIGNvZGUu PGJyPg0KPGJyPg0KVGhlIHBhdHRlcm4gaXMgYWxyZWFkeSBpbiB1c2UsIGluIHByb3ByaWV0YXJ5 IGZvcm0sIGJ5IHZhcmlvdXMgbW9kZXJuIGRldmVsb3BtZW50IHN0YWNrcywgc3VjaCBhcyBOZXh0 LkpTLiBWYXJpYW50cyBvZiB0aGUgcGF0dGVybiwgb2Z0ZW4gZGlzY3Vzc2VkIHVuZGVyIHRoZSBj YXRjaC1hbGwgdGVybSBCRkYgKGJhY2tlbmQgZm9yIGZyb250ZW5kKSwgaGF2ZSBiZWVuIG9mdGVu IG1lbnRpb25lZCBpbiB0aGlzIHdvcmtncm91cOKAmXMgYWN0aXZpdHksDQogYnV0IGFsd2F5cyBs ZWZ0IGFsbCBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIHRoZSByZWFkZXIuPGJyPg0KV2UgYmVs aWV2ZSB0aGUgcGF0dGVybiBoYXMgbWVyaXQsIGFzIGNvcnJvYm9yYXRlZCBieSBpdHMgZ3Jvd2lu ZyBhZG9wdGlvbi4gQnkgZGVsZWdhdGluZyBhY2Nlc3MgdG9rZW4gYWNxdWlzaXRpb24gdG8gdGhl IGJhY2tlbmQsIHdlIGF2b2lkIG1hbnkgb2YgdGhlIG9mdGVuIGJyaXR0bGUgbW92aW5nIHBhcnRz IChhbmQgaW1wbGllZCBhdHRhY2sgc3VyZmFjZSkgcmVxdWlyZWQgdG8gYWNxdWlyZSBhY2Nlc3Mg dG9rZW5zIGZyb20gYSB1c2VyIGFnZW50Lg0KIFRoZSB0b3BvbG9neSBhbHNvIHJlbGlldmVzIHRo ZSBmcm9udGVuZCBmcm9tIHRoZSBuZWVkIG9mIHBlcnNpc3RpbmcgdG9rZW5zIGluIGxvY2FsIHN0 b3JhZ2UsIGEgd2VsbCBrbm93biBzb3JlIHBvaW50IG9mIHVzaW5nIE9BdXRoIGRpcmVjdGx5IGlu IEphdmFTY3JpcHQsIGJ5IHJlbHlpbmcgb24gaXRzIGJhY2tlbmQgc3RvcmFnZSBhbmQgc2Vzc2lv biB0byBwcmVzZXJ2ZSB0b2tlbnMuPGJyPg0KPGJyPg0KQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRp b24gaXMgdmVyeSBzaW1wbGUsIHByb3ZpZGluZyBleHBsaWNpdCBndWlkYW5jZSBvbiB0aGUgc2Nl bmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50YWdlcy4gJm5ic3A7PGJyPg0KLSBJdCBtYWtlcyBpdCBw b3NzaWJsZSB0byBjcmVhdGUgaW50ZXJvcGVyYWJsZSBTREtzLCB3aGVyZSBmcm9udGVuZCBkZXYg c3RhY2tzIChhbnkgSlMgZmxhdm9yKSBjYW4gYmUgbWl4ZWQgYW5kIG1hdGNoZWQgd2l0aCBjb21w bGlhbnQgYmFja2VuZCBzdGFja3MgKG1pZGRsZXdhcmVzIGluIG5vZGUsIGphdmEsDQo8YSBocmVm PSJodHRwOi8vQVNQLk5FVCIgdGFyZ2V0PSJfYmxhbmsiPkFTUC5ORVQ8L2E+LCBQSFAgZXRjKTxi cj4NCi0gSXQgYWxsb3dzIHVzIHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIHByb3Blcmx5 IHRhY2tsZSB0aGUgc2NlbmFyaW8gYW5kIHdhcm4gaW1wbGVtZW50ZXJzIGFnYWluc3Qgc2VjdXJp dHkgcmlza3MgKHNjb3BlIGVzY2FsYXRpb25zLCB1c2luZyBJRHRva2VucyBpbnN0ZWFkIG9mIGFj Y2VzcyB0b2tlbnMsIGV0Yyk8YnI+DQotIEl0IGFsbG93cyB1cyB0byBkaXNjdXNzIChhbmQgd2hl biBhcHByb3ByaWF0ZSwgcHJvbW90ZSkgdGhpcyBwYXR0ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dz ZXIgYXBwcyBzZWN1cml0eSBndWlkYW5jZSwgYW5kIHBvc2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVy ZSBmcm9udGVuZCBvbmx5IGNhbGxzIEFQSSBvbiBpdHMgb3duIGJhY2tlZCAoaGVuY2UgZG9lc27i gJl0IG5lZWQgYWNjZXNzIHRva2Vucykgc2ltcGx5IGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMN CiBtb3JlIGdlbmVyYWwgcGF0dGVybjxicj4NCi0gVGhpcyBhcHByb2FjaCBtYWtlcyBtb2NraW5n IGFuZCB0ZXN0aW5nIGFwcHMgdmVyeSBlYXN5LCBwb3NzaWJseSBwcmV2ZW50aW5nIGRldmVsb3Bl cnMgZnJvbSB3ZWFrZW5pbmcgdGhlIHNlY3VyaXR5IG9mIHRoZWlyIHN5c3RlbSAoZWcgdHVybmlu ZyBvbiBST1BHIG9wdGlvbnMpICZuYnNwO29yIHR1cm5pbmcgdG8gcmlza3kgcHJhY3RpY2VzIGxp a2Ugc2NyYXBpbmc8YnI+DQo8YnI+DQpOZWVkbGVzcyB0byBzYXksIHRoaXMgc3BlY2lmaWNhdGlv biBkb2VzbuKAmXQgZW50aXJlbHkgZWxpbWluYXRlIHRoZSByaXNrcyBpbmhlcmVudCB0byBkaXJl Y3QgdXNlIG9mIGFjY2VzcyB0b2tlbnMgZnJvbSBhIGJyb3dzZXIuIEJ1dCByZWFsaXR5IGlzIHRo YXQgdGhlIHBhdHRlcm4gaXMgaW4gd2lkZXNwcmVhZCB1c2UsIGFuZCB0aGUgY2lyY3Vtc3RhbmNl cyBsZWFkaW5nIHRvIHRoYXQgKGVnIGRldmVsb3BlcnMgb24gYSBwYXJ0aWN1bGFyIHByb2plY3QN CiBvbmx5IHdvcmsgd2l0aCBmcm9udGVuZCBzdGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZlcnNl IHByb3hpZXMgbWlnaHQgbm90IGFsd2F5cyBiZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29pbmcg YXdheSBhbnkgdGltZSBzb29uLiBCeSBwcm92aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRoaXMg cGF0dGVybiwgd2UgY2FuIHNpbXBsaWZ5IHRoZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3aGls ZSBlbnNocmluaW5nIGJhc2ljIHNlY3VyaXR5IGh5Z2llbmUNCiBpbiBzY2VuYXJpb3MgdGhhdCB3 b3VsZCBoYXZlIG90aGVyd2lzZSBiZSBsZWZ0IHRvIHRoZWlyIG93biBkZXZpY2UuPGJyPg0KPGJy Pg0KTG9va2luZyBmb3J3YXJkIGZvciB5b3VyIGZlZWRiYWNrITxicj4NCjxicj4NCkImYW1wO1Yg Jm5ic3A7PGJyPg0KPGJyPg0K77u/T24gMi8xMi8yMSwgMTI6NDEsICZxdW90OzxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7QSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwO2hhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVml0dG9y aW8gQmVydG9jY2kgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtJRVRG IHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7TmFtZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmY8YnI+DQombmJz cDsmbmJzcDsmbmJzcDtSZXZpc2lvbjogJm5ic3A7ICZuYnNwOzAwPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7VGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Rva2VuIE1lZGlhdGluZyBh bmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwO0RvY3VtZW50IGRhdGU6ICZuYnNwOyAmbmJzcDsyMDIxLTAyLTEyPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1 YWwgU3VibWlzc2lvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1BhZ2VzOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsxNjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1VSTDogJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0 aDItdG1pLWJmZi0wMC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dDwvYT48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDtTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLzwv YT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDtIdG1sOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLmh0bWwi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJl cnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLmh0bWw8L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 SHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0w MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0 b2NjaS1vYXV0aDItdG1pLWJmZi0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDtBYnN0cmFjdDo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxl Z2F0ZSBhY2Nlc3M8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0b2tl biBhY3F1aXNpdGlvbiB0byBhIGJhY2tlbmQgY29tcG9uZW50LiZuYnNwOyBJbiBzbyBkb2luZywg dGhlIGZyb250ZW5kPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2Fu IGFjY2VzcyByZXNvdXJjZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBi dXJkZW4gb2Y8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb21tdW5p Y2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBwZXJzaXN0aW5nIHRva2Vucywg YW5kPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGVyZm9ybWluZyBv cGVyYXRpb25zIHRoYXQgYXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW48 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleGVjdXRlZCBpbiBhIHVz ZXIgYWdlbnQsIGJ1dCBhcmUgc2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2J5IGEgY29uZmlkZW50aWFsIGNs aWVudCBydW5uaW5nIG9uIGEgYmFja2VuZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDtQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmll dGYub3JnPC9hPi48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGUgSUVURiBTZWNyZXRh cmlhdDxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjojMTcyQjREO2JhY2tncm91bmQ6d2hpdGUiPkZv cmdlUm9jayB2YWx1ZXMgeW91cg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuZm9yZ2Vyb2NrLmNvbS95 b3VyLXByaXZhY3kiIHRhcmdldD0iX2JsYW5rIj5Qcml2YWN5PC9hPjwvc3Bhbj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CO6PR18MB4052FF780E71AE2FF62B173EAE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 04:54:28 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A783E3A0A0B for ; Sun, 14 Feb 2021 04:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyyC6uLiUhmn for ; Sun, 14 Feb 2021 04:54:19 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900D93A0B16 for ; Sun, 14 Feb 2021 04:54:18 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id y15so3294608ilj.11 for ; Sun, 14 Feb 2021 04:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mQE23SDfRCoGpEAr2Nxyd2QsBuPRxWQvnLbOj4rV5xE=; b=EaXVANxZH9u7U0QUBorVPhW+qHz/EPOg9PlWj6SaEGfB4UFqQT+e6kRrsMGxFaRobx JTZvCnKObwefsYq0ej50+sJaZ6WXNfLoqerlzGtbgizTazaZ6Mn4GLb7DBkAYiNoOK65 fMlTUbGpXU2TaAl4d8BHF/PshCWQeZQvDLanfUMwDoFgH9g3+JPjjEDq9Oxnd4UcONc3 KkaImswYAR4mB6WYCewR/THn4OXIINTLVxADWbvFfy8Fh2woSot8APUIDTZo8xOLdoeI 6yg8emvAJK7fk5DBC+dByZjmeq9w6i1gwE+E5+/UNCI0MxX1/yiaNdrrePjv+eLPaKHD gc2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mQE23SDfRCoGpEAr2Nxyd2QsBuPRxWQvnLbOj4rV5xE=; b=jvhL/vobhkUDvN8ABeGCeOJF+7gZo8/8MvXuzwIovdsTCiZyKrnwd+XS6+cLFai2zv KP6/GKgBXqODCbnXUV34a1NVkWZptUwUHDgylw80IistZrqTnjFs1OClPusdczRCp61y tVU5rbGid+njC4Z4OiAjVXCX7+PS7lyj70lYt843ZG1ZprILxrIh1qFR2mE+MM2Fk9Ry 97jlN0ywTgjlwc2soOJg39UjGnqSwgqfkavXCPtLBpaJbisUT3y/jqHW2Khgvnk4VCWU 7C+x8OSCQi18nNNp4RvU0u1XFlVK6z80nFmDEERhaakWHeDgHf2M6tvSlwfNPmZsRq3U DGfw== X-Gm-Message-State: AOAM532gRLev2OPd8VsCk9CzptiYXOLADCDUZE3KcsbCJgDdq4O5j9KH c0pU18FHqrQ2tbh1ocHpxDJvDrmqzvQzJNR01utC X-Google-Smtp-Source: ABdhPJygDab8px1lZ19UiEO1/GxDHMOHQCqS/IoF61fnfkpLwOkqja2oM1i7ENrGYVAxiNAE5ol1KO4JRwaKDY44jyU= X-Received: by 2002:a05:6e02:1a29:: with SMTP id g9mr8985508ile.54.1613307257680; Sun, 14 Feb 2021 04:54:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 13:54:06 +0100 Message-ID: To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000002200b05bb4b5ee1" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 12:54:27 -0000 --00000000000002200b05bb4b5ee1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measur= es > make it problematic. Which new browser measures? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci wrote: > > - For UI related functionality, i.e. document selection, user profile > display/changes, contact updates, etc... You should be able to execute= the > client side *silent authentication* using the provided session token > from the Azure AD AS, without needing to make any RO api calls nor use= r > redirects. > > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measur= es > make it problematic. In code+PKCE you can use a refresh token, but see th= e > other reply for how this proposal is an alternative to that in some > situations. This answer was specifically on why having backend-issued > tokens didn=E2=80=99t apply to this scenario. > > > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 03:48 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > For UI related functionality, i.e. document selection, user profile > display/changes, contact updates, etc... You should be able to execute th= e > client side *silent authentication* using the provided session token from > the Azure AD AS, without needing to make any RO api calls nor user > redirects. For RO responsibilities, you can present the user with a butto= n > "Grant RO access to Azure resources" button and the user will go through = a > permission scope elevation flow, again no reason to need a BFF here. > > > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > It may make sense for the app to have an error message, or even better > might be a 302 *Location header* depending on what you are doing. There > is nothing here that is OAuth specific however (nor common), and then we > should challenge the need to directly provide an RFC recommendation for > handling this. > > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > Hi Neil, > > Thanks for the prompt comments! > > - Re: GET vs POST, > > personally I=E2=80=99d be fine with restricting to POST. > > > > - Re: RO-AS, interaction- > > perhaps it is not very clear from the text at the moment (first draft), > but that is assumed that the RO went thru whatever interactive steps are > necessary to establish a session (eg sign in, assuming the AS is say an > OIDC provider) and obtain beforehand the access token and refresh tokens > that will be needed during the app activities taking place after that. I= n > concrete terms, imagine that the backend performs an authorization code > grant requesting an IDtoken, access token and refresh token BEFORE the > activities described in TMI-BFF take place. > > The current language trying to express that is in 1.2: > > As a prerequisite for the flow described below, the backend MUST have > established a secure session with the user agent, so that all requests fr= om > that user agent toward the backend occur over HTTPS and carry a valid > session artifact (such as a cookie) that the backend can validate. This > document does not mandate any specific mechanism to establish and maintai= n > that session. > > And > > cached, it requests to the authorization server a new access token with > the required characteristics, using any artifacts previousy obtained (eg > refresh token) and grants that will allow the authorization server to iss= ue > the requested token without requiring user interaction. > > > > - If the backend is already implicitly trusted then couldn=E2=80=99t = you skip > OAuth and just get the backend to issue short-lived JWTs to the fronte= nd > that it can use for API access? > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > - If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoi= nt > URI that the SPA then navigates the user to. (Eg the backend can do a = PAR > request first and return a URI that references that so that authorizat= ion > details aren=E2=80=99t passed through the frontend). > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > > > *From: *OAuth on behalf of Neil Madden < > neil.madden@forgerock.com> > *Date: *Sunday, February 14, 2021 at 00:17 > *To: *Vittorio Bertocci > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > I have a lot of security concerns about this draft. > > > > The draft alludes to security issues associated with handling access > tokens in the frontend but never really spells them out. From the Securit= y > Considerations it seems that the primary concern is with theft of access > tokens from local storage. To do this you=E2=80=99d need an XSS attack. B= ut in that > case, wouldn=E2=80=99t the attacker simply use the XSS to make a call to = the > bff-token endpoint instead? > > > > The combination of the bff-token endpoint recommending the use of GET > requests together with the hint to use cookie-based authentication is > likely going to punch a hole in most CSRF defenses, which assume that GET= s > are safe. The only thing preventing this being exploitable is Cross-Origi= n > Read Blocking ( > https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md) > due to the JSON content-type. That makes me really nervous. We should at > least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel > more comfortable if this was a POST request only. > > > > As Stoycho Sleptsov mentioned in the other email, the lack of > front-channel communication between the AS and the RO seems odd. If the > backend is already implicitly trusted then couldn=E2=80=99t you skip OAut= h and just > get the backend to issue short-lived JWTs to the frontend that it can use > for API access? > > > > If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoint > URI that the SPA then navigates the user to. (Eg the backend can do a PAR > request first and return a URI that references that so that authorization > details aren=E2=80=99t passed through the frontend). > > > > =E2=80=94 Neil > > > > > > On 12 Feb 2021, at 20:46, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For > Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: > https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate acce= ss > token acquisition to a backend component. In so doing, the fronten= d > can access resource servers directly without taking on the burden o= f > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges whe= n > executed in a user agent, but are safe and well proven when execute= d > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --00000000000002200b05bb4b5ee1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you = expand on what silent authentication and session token stands for here? If = you are referring to the iframe scenario, the new browser measures make it = problematic.
Which new browser measures?

=

Warren Parad

= Founder, CTO

Secure your user data and complete your authorization archit= ecture. Implement=C2=A0Authress.


=
On Sun, Feb 14, 2021 at 1:33 PM Vitto= rio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
  • For UI related functionality, i.e. document selection, user profi= le display/changes, contact updates, etc... You should be able to execute t= he client side silent authentication=C2=A0using the provided session token from the= Azure AD AS, without needing to make any RO api calls nor user redirects.= =C2=A0

Can you expand on what silent authentication and ses= sion token stands for here? If you are referring to the iframe scenario, th= e new browser measures make it problematic. In code+PKCE you can use a refr= esh token, but see the other reply for how this proposal is an alternative to that in some situations. This a= nswer was specifically on why having backend-issued tokens didn=E2=80=99t a= pply to this scenario.

=C2=A0

=C2=A0

From: = Warren Parad <wpar= ad=3D40rhos= ys.ch@dmarc.ietf.org>
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can = request them as a client, but it cannot mint them. Imagine we=E2=80=99re talking about a SPA application that signs in = users using Azure AD, and needs to call Office and Azure APIs. The SPA back= end cannot issue tokens for those APIs, it can only request them to the Azu= re AD AS.

=C2=A0

For UI related functionality, i.e. document selectio= n, user profile display/changes, contact updates, etc... You should be able= to execute the client side silent authentication=C2=A0using the provided session token from the= Azure AD AS, without needing to make any RO api calls nor user redirects.= =C2=A0For RO responsibilities, you can present the user with a button "= ;Grant RO access to Azure resources" button and the user will go through=C2=A0a permission scope elevation flow, again no = reason to need a BFF here.

=C2=A0

We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to th= e IDP initiated login in OIDC, where the client offers an endpoint that is guaranteed to initiate a sign in flo= w (hence inject all the necessary nonces etc). We didn=E2=80=99t add it upf= ront and left it as exercise for the reader mostly because it=E2=80=99s not= easy to model properly and before opening that work front we wanted to see how the idea was received.=C2=A0=C2=A0<= u>

It may make sense for the app to have an error messa= ge, or even better might be a 302 Location header=C2=A0depending on what you are doing. There is nothi= ng here that is OAuth specific however (nor common), and then we should cha= llenge the need to directly provide an RFC recommendation for handling this= .

=C2=A0

3D"Image

Warren Parad

Founder, CTO=

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci &= lt;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Hi Neil,

Thanks for the prompt comments!

  • Re: GET vs POST,

personally I=E2=80=99d be fine with restricting to POST.

=C2=A0

  • Re: RO-AS, interaction-

perhaps it is not very clear from the text at the mo= ment (first draft), but that is assumed that the RO went thru whatever inte= ractive steps are necessary to establish a session (eg sign in, assuming the AS is say an OIDC provider) and obtain beforehan= d the access token and refresh tokens that will be needed during the app ac= tivities taking place after =C2=A0that. In concrete terms, imagine that the= backend performs an authorization code grant requesting an IDtoken, access token and refresh token BEFORE the act= ivities described in TMI-BFF take place.

The current language trying to express that is in 1.= 2:

As a prerequ= isite for the flow described below, the backend MUST have established a secure session with the user agent, so that all requests from that user = agent toward the backend occur over HTTPS and carry a valid session artifac= t (such as a cookie) that the backend can validate. This document does not = mandate any specific mechanism to establish and maintain that session.

And

cached, it r= equests to the authorization server a new access token with the required characteristics, using any artifacts previousy obtained (eg refresh token)= and grants that will allow the authorization server to issue the requested= token without requiring user interaction.

=C2=A0

  • =C2=A0If the backend is already implicitly trusted then couldn=E2=80=99t = you skip OAuth and just get the backend to issue short-lived JWTs to the fr= ontend that it can use for API access?

For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine= we=E2=80=99re talking about a SPA application that signs in users using Az= ure AD, and needs to call Office and Azure APIs. The SPA backend cannot iss= ue tokens for those APIs, it can only request them to the Azure AD AS.

=C2=A0

  • If you want to allow auth code flow etc then perhaps the bff-token endpoint= can return a standard error code with an authorization endpoint URI that t= he SPA then navigates the user to. (Eg the backend can do a PAR request fir= st and return a URI that references that so that authorization details aren=E2=80=99t passed through the front= end).=C2=A0

We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client off= ers an endpoint that is guaranteed to initiate a sign in flow (hence inject= all the necessary nonces etc). We didn=E2=80=99t add it upfront and left i= t as exercise for the reader mostly because it=E2=80=99s not easy to model properly and before opening that work front= we wanted to see how the idea was received. =C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Neil Madden <neil.madden@forgerock.com>
Date: Sunday, February 14, 2021 at 00:17
To: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>= ;
Cc: "oauth@= ietf.org" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

I have a lot of security concerns about this draft.= =C2=A0

=C2=A0

The draft alludes to security issues associated with= handling access tokens in the frontend but never really spells them out. F= rom the Security Considerations it seems that the primary concern is with theft of access tokens from local storage. To do t= his you=E2=80=99d need an XSS attack. But in that case, wouldn=E2=80=99t th= e attacker simply use the XSS to make a call to the bff-token endpoint inst= ead?=C2=A0

=C2=A0

The combination of the bff-token endpoint recommendi= ng the use of GET requests together with the hint to use cookie-based authe= ntication is likely going to punch a hole in most CSRF defenses, which assume that GETs are safe. The only thing preventing = this being exploitable is Cross-Origin Read Blocking (https://chromium.googlesourc= e.com/chromium/src/+/master/services/network/cross_origin_read_blocking_exp= lainer.md) due to the JSON content-type. That makes me really nervous. We should at l= east mandate X-Content-Type-Options: nosniff on that response. I=E2=80=99d = feel more comfortable if this was a POST request only.=C2=A0<= /p>

=C2=A0

As Stoycho Sleptsov mentioned in the other email, th= e lack of front-channel communication between the AS and the RO seems odd. = If the backend is already implicitly trusted then couldn=E2=80=99t you skip OAuth and just get the backend to issue short-li= ved JWTs to the frontend that it can use for API access?

=C2=A0

If you want to allow auth code flow etc then perhaps= the bff-token endpoint can return a standard error code with an authorizat= ion endpoint URI that the SPA then navigates the user to. (Eg the backend can do a PAR request first and return a URI that refer= ences that so that authorization details aren=E2=80=99t passed through the = frontend).=C2=A0

=C2=A0

=E2=80=94 Neil

=C2=A0

=C2=A0

On 12 Feb 2021, at 20:4= 6, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=

=EF=BB=BFDear all,
Brian and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and persist= ence to its backend, and request such tokens when needed for direct access = of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern devel= opment stacks, such as Next.JS. Variants of the pattern, often discussed un= der the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=E2=80=99s activity, but always left all implementation details to the reader.
We believe the pattern has merit, as corroborated by its growing adoption. = By delegating access token acquisition to the backend, we avoid many of the= often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend from the need of persisting tokens= in local storage, a well known sore point of using OAuth directly in JavaS= cript, by relying on its backend storage and session to preserve tokens.
Although the specification is very simple, providing explicit guidance on t= he scenario offers many advantages. =C2=A0
- It makes it possible to create interoperable SDKs, where frontend dev sta= cks (any JS flavor) can be mixed and matched with compliant backend stacks = (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario a= nd warn implementers against security risks (scope escalations, using IDtok= ens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as p= art of the browser apps security guidance, and position the scenario where = frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventi= ng developers from weakening the security of their system (eg turning on RO= PG options) =C2=A0or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely eliminate the = risks inherent to direct use of access tokens from a browser. But reality i= s that the pattern is in widespread use, and the circumstances leading to t= hat (eg developers on a particular project only work with frontend stacks; components like reverse proxies might not = always be viable; etc) aren=E2=80=99t going away any time soon. By providin= g simple guidance on this pattern, we can simplify the life of many develop= ers while enshrining basic security hygiene in scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!

B&V =C2=A0

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org= > wrote:


=C2=A0=C2=A0=C2=A0A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.tx= t
=C2=A0=C2=A0=C2=A0has been successfully submitted by Vittorio Bertocci and = posted to the
=C2=A0=C2=A0=C2=A0IETF repository.

=C2=A0=C2=A0=C2=A0Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bertocci-oauth2-tm= i-bff
=C2=A0=C2=A0=C2=A0Revision: =C2=A0 =C2=A000
=C2=A0=C2=A0=C2=A0Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Token Mediating and ses= sion Information Backend For Frontend
=C2=A0=C2=A0=C2=A0Document date: =C2=A0 =C2=A02021-02-12
=C2=A0=C2=A0=C2=A0Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission =C2=A0=C2=A0=C2=A0Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A016
=C2=A0=C2=A0=C2=A0URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://www.ietf.org/archive/id/draf= t-bertocci-oauth2-tmi-bff-00.txt
=C2=A0=C2=A0=C2=A0Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/" = target=3D"_blank">https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tm= i-bff/
=C2=A0=C2=A0=C2=A0Html: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0https://www.ietf.org/archive/id/draft-ber= tocci-oauth2-tmi-bff-00.html
=C2=A0=C2=A0=C2=A0Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


=C2=A0=C2=A0=C2=A0Abstract:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This document describes how a JavaScrip= t frontend can delegate access
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0token acquisition to a backend componen= t.=C2=A0 In so doing, the frontend
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0can access resource servers directly wi= thout taking on the burden of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0communicating with the authorization se= rver, persisting tokens, and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0performing operations that are fraught = with security challenges when
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0executed in a user agent, but are safe = and well proven when executed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0by a confidential client running on a b= ackend.




=C2=A0=C2=A0=C2=A0Please note that it may take a couple of minutes from the= time of submission
=C2=A0=C2=A0=C2=A0until the htmlized version and diff are available at tools.ietf.org.

=C2=A0=C2=A0=C2=A0The IETF Secretariat



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


ForgeR= ock values your Privac= y

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

--00000000000002200b05bb4b5ee1-- From nobody Sun Feb 14 05:48:21 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F13A0C18 for ; Sun, 14 Feb 2021 05:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yoe7qYx1dv3 for ; Sun, 14 Feb 2021 05:48:17 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B03E3A0C11 for ; Sun, 14 Feb 2021 05:48:17 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id u18so4924053ejf.6 for ; Sun, 14 Feb 2021 05:48:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tFZdd9hNoCLK0UlUmGMV1IftCzRuJ+kx+/lK58TKoBs=; b=ZQWkOE7lVBSKcMF6P8DVyB7s1CpTzTPIERCNi1LCCWKenIaSXHIx9zF9aE//bDFQ+w zh8iIQSQO5WcpA6qdd9Mw2iUA4vFvfg2jLkSBQHVX7FdtJXCjrItBtl+O9HkTB4FzFuQ R6VhRsCqU3339eNC1ts4LR5RlJCD1sMkX7JPRnMWs1MMFYwWI/oIWelPdMAuI9nPR03c oXRcxVEz/cbFfngqCOpB9aAbpe3zLt50FA23XxsOvqAWCHYn/e84urfX4SAaRWngewFm nSEq3BoFYAvBaGNkn3YG/OKxTu6A6PARHyL9Xm/MVz8W9sVYB3Y9sUtQWULef4e71w7a /ccw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFZdd9hNoCLK0UlUmGMV1IftCzRuJ+kx+/lK58TKoBs=; b=gMcvaiI5IIckFtOQrInhaGiAOH4W8jcJcasR35dQjWs4Om+sO5uZznuoRCZJLdpj5j bcm9FOf1uxvv+B0cqfov0s0g5mPeW7348tMbePXt+pwxQVYqsIjbpLyKBwYLYRGFEx3z 14CkWlKThGl2zpvmEz9KIU7433jkK+PhFDjrCWwWOR4WZ+AcGJchyRYsrJpNcq3V1XN+ F7MKKqx/nk06Pnb+GUI24ruMbP6/lWtNAIj2du+uBPqtVdyZJ7TO+QnZPyrl3/dkzbnr haRucqrlqw9OxpALmQf+SiFZVs7x7nc4dpT226nRq4MTSihA11airFGUzGq3osuVrUhc cxRg== X-Gm-Message-State: AOAM533416DQ6OgFT272On9tUeSIhjUb8ee3/LUn9KVy0D79Q6rfR/Qa jSkoGHr+3EeEQzo1r7oqlbGfXbTNoOXSeo3AadI= X-Google-Smtp-Source: ABdhPJwwENg2PvGSoVqu8nWmTgXQZGnKH3eNkpsfHMbTkVo+UmdQZ+sE4dLxf0Iv7AACMPhmfnVgoN+xe7kjvOtj/K8= X-Received: by 2002:a17:906:33c5:: with SMTP id w5mr11621329eja.319.1613310495581; Sun, 14 Feb 2021 05:48:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stoycho Sleptsov Date: Sun, 14 Feb 2021 15:48:04 +0200 Message-ID: To: Vittorio Bertocci Cc: Warren Parad , oauth Content-Type: multipart/alternative; boundary="00000000000000695905bb4c1f15" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 13:48:19 -0000 --00000000000000695905bb4c1f15 Content-Type: text/plain; charset="UTF-8" I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS", with the objective to verify if they are valid. I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example). If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication. Or is it considered a bad practice to do that? Regards, Stoycho. --00000000000000695905bb4c1f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to add my reasons about the "Why ar= e developers creating BFF for their frontends to communicate with an AS&quo= t;,
with the objective to verify if they are valid.

I need the client app. to be authenticated at the AS (to de= termine if it is a first-party app., for example).
If we decide t= o implement our client as a frontend SPA , then we have no other option exc= ept through a BFF, as PKCE does not help for authentication.

=
Or is it considered a bad practice to do that?

Regards,
Stoycho.
--00000000000000695905bb4c1f15-- From nobody Sun Feb 14 05:53:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ECB3A0C30 for ; Sun, 14 Feb 2021 05:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfZu_XkYpMWu for ; Sun, 14 Feb 2021 05:53:33 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23B43A0C2F for ; Sun, 14 Feb 2021 05:53:33 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id f6so4190175ioz.5 for ; Sun, 14 Feb 2021 05:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uVCGfFQDl7ZluxXnMe1EsedBVuL03fHnlX5/CjzneIc=; b=KruT/SQwzmK5NXbkX0sNJOlVsG+LEqmvPp3lXgxE+2Z4sRAb+eBX3rt3luSj/IeQWI Ob7tWoxW6kZ8DpoZ/haTSp8gYHEjeu9fcwRLiATF6Dqr1s8JHPhasmdMxo3Tmh7nZWwY kPhe4cEFMyLwnXvDx0GhtXbp3EdKhW8kpNpqgFVSUfDc0IKu2UMurCqqjls7JoVeEigQ O/vnvIqDmW7mXgc5+NkGl6+j5sLBMgQnOr0RY+3jr8Pv6M1kyYxmlb9zWAPzpIAdGx3R pmUEJrMpWQ14SiE5/w1kLMfmenQE5JFt59OcL7GYbIgarXvvIabqzLigPbrwtOHnhKrs QxQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uVCGfFQDl7ZluxXnMe1EsedBVuL03fHnlX5/CjzneIc=; b=MwHzGYlzbm4bxGbZgoHbDoTM+xrxy38kvYWX+vgyANEEnn//UPhVKwKa/cjUkxWAyx KIYNBTHuKVI0pSbrIg+BklyZYxuhBc3FbWq4gIUrk5yUbm1kGZIjfyGOeQfrwRx51tbX LCBo7cGCWNLImYTUMW/b6PkGArJIPP7gqik8/k6YF/dVyvohXmjOOTjKZRcufwkvsfHg 8YCdMnVZFwVuE62QV6jQI/2DGTTLKT/CPuE9qj1Hao1w82jxXgZ0vR3OeZKtTBhCPUQ+ XVPgei4A87Y0N6lWDnZC/99fUUB9Uf677DA9BguoZ5dTzFxeddVOJNC4Z154ZPrU2/dR 8/kw== X-Gm-Message-State: AOAM531J8AHNFtB6GMtrvPxI0EpZOCZqILVCryus9r+wnlm7x/iAGTYn +u8Oh/MbV8odWMs6VdMuNdgXsNuTmy0WULiIZr70 X-Google-Smtp-Source: ABdhPJxHOzQDBeSYznbutNLWu7wp0+T9Ca3vkLmPssKlAbH/tk7+h9/HJL2psMVob0HnvnWxTJqPb0TDddCKd6Vo3YU= X-Received: by 2002:a02:661c:: with SMTP id k28mr10941870jac.78.1613310812692; Sun, 14 Feb 2021 05:53:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 14:53:21 +0100 Message-ID: To: Stoycho Sleptsov Cc: Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="000000000000e73ca905bb4c3131" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 13:53:35 -0000 --000000000000e73ca905bb4c3131 Content-Type: text/plain; charset="UTF-8" Why doesn't PKCE help for authentication? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 2:48 PM Stoycho Sleptsov wrote: > I would like to add my reasons about the "Why are developers creating BFF > for their frontends to communicate with an AS", > with the objective to verify if they are valid. > > I need the client app. to be authenticated at the AS (to determine if it > is a first-party app., for example). > If we decide to implement our client as a frontend SPA , then we have no > other option except through a BFF, as PKCE does not help for authentication. > > Or is it considered a bad practice to do that? > > Regards, > Stoycho. > --000000000000e73ca905bb4c3131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why doesn't PKCE help for authentication?

=

Warren Parad

Founder, CTO<= /span>

Secure your user data and complete your authorization architecture. Imple= ment=C2=A0Authress.<= br>


On Sun, Feb 14, 2021 at 2:48 PM Stoycho Slep= tsov <stoycho.sleptsov@gma= il.com> wrote:
I would like to add my reasons about the "= Why are developers creating BFF for their frontends to communicate with an = AS",
with the objective to verify if they are valid.

I need the client app. to be authenticated at the AS = (to determine if it is a first-party app., for example).
If we de= cide to implement our client as a frontend SPA , then we have no other opti= on except through a BFF, as PKCE does not help for authentication.

Or is it considered a bad practice to do that?
<= br>
Regards,
Stoycho.
--000000000000e73ca905bb4c3131-- From nobody Sun Feb 14 06:10:57 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C433A0C77 for ; Sun, 14 Feb 2021 06:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8ubDoJRpbG9 for ; Sun, 14 Feb 2021 06:10:54 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCA23A0C70 for ; Sun, 14 Feb 2021 06:10:54 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id v9so785630edw.8 for ; Sun, 14 Feb 2021 06:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AqJZa7m8JOHUtW80S/pDlnVpvYqHao3ejIjiXwC41qE=; b=QvR6OEHSRISFvpIcTFNTsZ+NzpnstZwFAY/lPpm67mD0IG9HFhx1LjYkLtQVkMFrmP A4rjR/08lgX8Azp7Q7+OGojDpejsWoHNKS36Nou4qla4MPXcA4MIPoulhzCKi2NXjwcg J5CG/u4OPgKmzvugVW691LXAz/mFE71/mIkJknkRLEldn+HVxyc19Tts+aoRjLerGN/Z Xe2GXdKhbB1pvIEXI3X2jwBlGZwPMYr9LK6shGNOwHb/cgNIjaj6eAu77Tuwti81DRok wx8UKuE5DJoa4AAff0zkxChs2eH2TxzYLAUqWCMAP9BrTJLYuu0juZiMJXMSxZf+IBHT SoTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AqJZa7m8JOHUtW80S/pDlnVpvYqHao3ejIjiXwC41qE=; b=Ve7ME0a5q4xEVkUaHTD67VE9DRSCSOgb5RCreWqeZC3vVjJMB0y4CtID3mVaaL0kUb eW4TY59kY4P+GsRgrhhTQp037LFBiOo0JGPGRsKnrwbVX4bQemaUsJY9v0h6zLJzHFXr 05nEx4R+A+22l3tsIFCPGRb+98ScDWrTu1HPbSq4wAvpZNTRlE+f44Q1AXFVF2ZwJggI VFLOpIgt71QN7H4bFuaOrgxj7GwjRh6ULbAPMf3GmeAJAIpyP98ltXDpL1b8LfQDelFJ c0wGTOSRqtAqoVC20c72tsPQSsSv7n/YfpRYvKOzmnjZZpxJCij5la31bESncMWy9ZF1 +A5w== X-Gm-Message-State: AOAM531UZNG6OsBnknlwcsw5EVSF6O25XrMzCkieTkuie6yBh/mLSpga nBkcFGxRuPv+KPw3zWOI/4XrYSJdyCgbClrVtds= X-Google-Smtp-Source: ABdhPJyg0WjRaeNgWe7WFk6y7gJtYpq8JPWql4JfDwXGWsyFWmR+vWAj/CcpbxWtaAIpveW9+OOt+PJFeoE49nVxx64= X-Received: by 2002:a05:6402:5250:: with SMTP id t16mr11555680edd.302.1613311852995; Sun, 14 Feb 2021 06:10:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stoycho Sleptsov Date: Sun, 14 Feb 2021 16:10:42 +0200 Message-ID: To: Warren Parad Cc: Vittorio Bertocci , oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 14:10:56 -0000 If I understood correctly, PKCE try to guarantee that the app which requests the access token in exchange for authorization code is the same as the application which initiated the authorization request, but it cannot help to guarantee which app exactly that is (as per section 2.3 of the draft-ietf-oauth-v2-1-01, through mTLS, Basic authentication with client secret, "private_key_jwt", or other means). On Sun, 14 Feb 2021 at 15:53, Warren Parad wrote: > > Why doesn't PKCE help for authentication? > > Warren Parad > > Founder, CTO > > Secure your user data and complete your authorization architecture. Implement Authress. > > > On Sun, Feb 14, 2021 at 2:48 PM Stoycho Sleptsov wrote: >> >> I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS", >> with the objective to verify if they are valid. >> >> I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example). >> If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication. >> >> Or is it considered a bad practice to do that? >> >> Regards, >> Stoycho. From nobody Sun Feb 14 06:11:56 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E423A0C7A for ; Sun, 14 Feb 2021 06:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PG80EJBb55y for ; Sun, 14 Feb 2021 06:11:53 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611543A0C70 for ; Sun, 14 Feb 2021 06:11:53 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id g6so5396674wrs.11 for ; Sun, 14 Feb 2021 06:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Uvn4PvhC2I3cEmvpv2sDXfJbPIcIdRlU1r9X+ABpl+Y=; b=wBI3PFz51O6i79F5ysuzFMSyeJsm3p03wp/pV4WZ2M+v3CxGgwjmM78FzOVAtLdkRG S4AeMbNkIMbtZL5NHi74G1tqHYM/f5HDRzyGtsW03BtUF3UFhhYY58w8wyZnxSYtQdZh k2QaxKvTLGHGHHj9wfmVMjhCWwItXr9JsgOLViPHycQeSe1AvS7jmG92kNA2iejciq5j DRbSV0Q30y3qYhS59HgCHzX1cV6fxl0ok/zZBfvoS84X3WJMqhPgv62yAMQRpBzIgoxM vDGA4pDLFReiJ8ApckmN8UBZcZGcK0swngA0ICKa/ottNBx7hd9ksRa/UG0KaD5pR9iE tamQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Uvn4PvhC2I3cEmvpv2sDXfJbPIcIdRlU1r9X+ABpl+Y=; b=t3fdyhRzUtkt9qmo8wf99wHuvKfYNNuNuRav33YFoNu6NKrCtOovZBprBQWv6432LW etNTYY/tEjdWF72EdAE6B2fKO8X7EzjthF7FaxzQ0YnjU+Cte71NOHiJ7QMOp1nASguz 3Iejpe+1OZI9gI38oHJ9MJPuNP1NqziBDfSFgOCMbYG32ZWlIXHnut5iyisewnzAv+yD tsoFnHWAGcnG3Dq/V56Yem28sDT+ItceA8JMFLbR1Wt26YiMAp7Vop13m3ZQ1eO0QyJ4 48gR7ax14EF0zjnBbDx2KXBuhr/X3w86toZw13P4Ut/vGGw/mCLWPXosIRZJZnRl1EN7 kyDw== X-Gm-Message-State: AOAM532RvcCHdxhkMEThIA7ochC/dKl7mRclJw2K7L6Ay1o9yH3xI1Jf isyKTqL/AdEE2QO2+jDgOdp2jU/ufgWJSQ9H X-Google-Smtp-Source: ABdhPJyOMh3gUcba55TU8GpP0knwX6kzkhulhwLu0rEWySEVCkpog85xPvOzeeB7dA6VzqJ3YTRNaA== X-Received: by 2002:a5d:6951:: with SMTP id r17mr2863054wrw.279.1613311911704; Sun, 14 Feb 2021 06:11:51 -0800 (PST) Received: from p200300eb8f061195608d66025bbab74b.dip0.t-ipconnect.de (p200300eb8f061195608d66025bbab74b.dip0.t-ipconnect.de. [2003:eb:8f06:1195:608d:6602:5bba:b74b]) by smtp.gmail.com with ESMTPSA id s14sm1116666wmj.23.2021.02.14.06.11.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 06:11:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Torsten Lodderstedt In-Reply-To: Date: Sun, 14 Feb 2021 15:11:48 +0100 Cc: "oauth@ietf.org" , Brian Campbell Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vittorio Bertocci X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 14:11:55 -0000 Hi, I=E2=80=99m trying to understand your proposal.=20 Section 1.2, bullet (B) states (B) If the backend does not already have a suitable access token obtained in previous flows and cached, it requests to the authorization server a new access token with the required characteristics, using any artifacts previousy obtained (eg refresh token) and grants that will allow the authorization server to issue the requested token without requiring user interaction. Can you please explain how the authorization process works towards the = AS, especially in case of the authorisation code grant type. I would = have expected to frontend to pass an authorisation code to the bff-token = request.=20 But section 4.1. only defines the parameters =E2=80=9Eresource" and = =E2=80=9Escope" for the bff-token endpoint.=20 thanks, Torsten.=20 > Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci = : >=20 > Dear all, > Brian and yours truly are proposing a new specification that shows how = the user agent frontend of a web app can delegate token acquisition and = persistence to its backend, and request such tokens when needed for = direct access of protected resources from the frontend code. >=20 > The pattern is already in use, in proprietary form, by various modern = development stacks, such as Next.JS. Variants of the pattern, often = discussed under the catch-all term BFF (backend for frontend), have been = often mentioned in this workgroup=E2=80=99s activity, but always left = all implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing = adoption. By delegating access token acquisition to the backend, we = avoid many of the often brittle moving parts (and implied attack = surface) required to acquire access tokens from a user agent. The = topology also relieves the frontend from the need of persisting tokens = in local storage, a well known sore point of using OAuth directly in = JavaScript, by relying on its backend storage and session to preserve = tokens. >=20 > Although the specification is very simple, providing explicit guidance = on the scenario offers many advantages. =20 > - It makes it possible to create interoperable SDKs, where frontend = dev stacks (any JS flavor) can be mixed and matched with compliant = backend stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the = scenario and warn implementers against security risks (scope = escalations, using IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern = as part of the browser apps security guidance, and position the scenario = where frontend only calls API on its own backed (hence doesn=E2=80=99t = need access tokens) simply as a special case of this more general = pattern > - This approach makes mocking and testing apps very easy, possibly = preventing developers from weakening the security of their system (eg = turning on ROPG options) or turning to risky practices like scraping >=20 > Needless to say, this specification doesn=E2=80=99t entirely eliminate = the risks inherent to direct use of access tokens from a browser. But = reality is that the pattern is in widespread use, and the circumstances = leading to that (eg developers on a particular project only work with = frontend stacks; components like reverse proxies might not always be = viable; etc) aren=E2=80=99t going away any time soon. By providing = simple guidance on this pattern, we can simplify the life of many = developers while enshrining basic security hygiene in scenarios that = would have otherwise be left to their own device. >=20 > Looking forward for your feedback! >=20 > B&V =20 >=20 > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" = wrote: >=20 >=20 > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to = the > IETF repository. >=20 > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend = For Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: = https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-berto= cci-oauth2-tmi-bff-00.txt&source=3Dgmail-imap&ust=3D1613767591000000&usg=3D= AOvVaw3Rb-S0l6cEv0ytjDxtYLAP > Status: = https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-bert= occi-oauth2-tmi-bff/&source=3Dgmail-imap&ust=3D1613767591000000&usg=3DAOvV= aw3-qg5MDtY7kD1HpR5jR2QY > Html: = https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-berto= cci-oauth2-tmi-bff-00.html&source=3Dgmail-imap&ust=3D1613767591000000&usg=3D= AOvVaw05WK4GSEKcWjZzNhvb1p5d > Htmlized: = https://www.google.com/url?q=3Dhttps://tools.ietf.org/html/draft-bertocci-= oauth2-tmi-bff-00&source=3Dgmail-imap&ust=3D1613767591000000&usg=3DAOvVaw0= qm45MWGbZf0zbBjZj3ggz >=20 >=20 > Abstract: > This document describes how a JavaScript frontend can delegate = access > token acquisition to a backend component. In so doing, the = frontend > can access resource servers directly without taking on the = burden of > communicating with the authorization server, persisting tokens, = and > performing operations that are fraught with security challenges = when > executed in a user agent, but are safe and well proven when = executed > by a confidential client running on a backend. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1613767591000000&usg=3DAOvVaw1Bfu9fJ2Fj_BZJ3H9y= w7od From nobody Sun Feb 14 06:28:16 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B918F3A0D25 for ; Sun, 14 Feb 2021 06:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geebRL3yN1O3 for ; Sun, 14 Feb 2021 06:28:14 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA343A0D24 for ; Sun, 14 Feb 2021 06:28:13 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id g6so5444634wrs.11 for ; Sun, 14 Feb 2021 06:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=Q2oBxOOV3kitY4hQEK7hHBhAhti7yHE3kvY4zF/Yp10=; b=W4ewy/Qw6twhrBYQMhpDKIrOvfc8obIQBYZVPfBnKNd1GMuVxaN8USG5eqZm/4fc/q ozwFFlmExBkiX/S4rOjXl3av90SOXk60f/vTjWyAwMbwLNUTBPnROrePCQifAubp4KMN 4adZ+cqWfzS/5HRKWMh7mQay7AG9ZimeSUa9o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=Q2oBxOOV3kitY4hQEK7hHBhAhti7yHE3kvY4zF/Yp10=; b=lLYWY1vd91sZAYu40sOzvJkyasIgtVfWmuR968z11cowbu8jFXTsh/VqF9Uz55mtXJ IJmWUgHk4yEvGBDOLepaSs/WgRnz89pJxmEOUJPugjrNFb5F1P29TCCgoa3IOFnyNYOg pQ3gpwm6XzWo6lstrBv0cjqrItA4JsdgugAAqMObvoKUriQxIpSISFY37ylQRuq+zeJB UWPrXm/+MwRsIUkK7ctQ6SMUmI4RzbPdbaHAiYuG1YxpUZsU+DKvnlxgZd+qq54LMC3a aVumo2E/AGgmydBIQfBGnkSIs+VyI4N8owjakRmt+ovmzPPN/UB643Mcyc83cZ10o9Y6 dnBw== X-Gm-Message-State: AOAM5324oJoW0RwIz0zALfESJazC24Z515WPn372INBw/Mgx+V97rHIE 79LRTs5CzJs4n6joknPv1GONmMB2J55sF6TYoNTmidKBHXO+JGY0ULj7QsUUAo2veIAcnO5z8jI fwt4mm/RzGiOW8PTB0BRB1ODdgD2+ylBByamEmXkkBoc1zuMaYMwybpbhcOBjmxKGkA== X-Google-Smtp-Source: ABdhPJyZ0Vm77iyxFirKiHNNMxKFQ/UKM9Wrq6LuejY9rgtLInXL3mm1/4rjfGh2Rx298idZ0bFg/A== X-Received: by 2002:a5d:4cc9:: with SMTP id c9mr13631420wrt.43.1613312892123; Sun, 14 Feb 2021 06:28:12 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y16sm15696415wrw.46.2021.02.14.06.28.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 06:28:11 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sun, 14 Feb 2021 14:28:08 +0000 Message-Id: References: Cc: Vittorio Bertocci , oauth , Warren Parad In-Reply-To: To: Stoycho Sleptsov X-Mailer: iPhone Mail (18C66) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 14:28:16 -0000 Public clients are implicitly authenticated by their ownership of the regis= tered redirect_uri. This why it=E2=80=99s important to use a redirect_uri f= or which ownership can be reasonably established, such as HTTPS endpoints w= ith exact URI matching.=20 There are more things that can go wrong with that (see the security BCP), b= ut it can be made reasonably secure.=20 =E2=80=94 Neil > On 14 Feb 2021, at 13:48, Stoycho Sleptsov w= rote: >=20 > =EF=BB=BF > I would like to add my reasons about the "Why are developers creating BFF= for their frontends to communicate with an AS", > with the objective to verify if they are valid. >=20 > I need the client app. to be authenticated at the AS (to determine if it = is a first-party app., for example). > If we decide to implement our client as a frontend SPA , then we have no = other option except through a BFF, as PKCE does not help for authentication= . >=20 > Or is it considered a bad practice to do that? >=20 > Regards, > Stoycho. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 ForgeRock values your Privacy From nobody Sun Feb 14 06:51:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43B23A0D75 for ; Sun, 14 Feb 2021 06:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ace-4C-fpk4p for ; Sun, 14 Feb 2021 06:51:29 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9817F3A0D73 for ; Sun, 14 Feb 2021 06:51:29 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id y10so384253edt.12 for ; Sun, 14 Feb 2021 06:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PpGatPFMJsosjVEk970LSDPEDsXiW7PiJQGLqEZauSc=; b=Jg7U4pgLLLYKdBCekJ4aCLVh6RxnR4IO1frFq2L+HttgKA6lJFNELTcocSYysFKYPe Y/sAOhSZP/ulJTlQjEkMGMsk4u5NzCHmaAS4eH723UNKY7/aaP0GII2at2yl3pfOY3KE f/Y6iXRBH9o3WEsrqehg19BD1uGV6qc1MzFtJOJHvxFSMB/wdvZ/4A4oijJmNnvqrWMn O2nGO9m8/IC9aaSPVkiuccydd7h2XzkQK1DpYGbt0532WxSmYDNqXZzblxgdFsADfxCp h68DE2ozkdYnIHixT63AeqVC6b5bVyk4NUv3yGm0U41BHj5J3kn54jdOCwZdpR9L0pWw HnhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PpGatPFMJsosjVEk970LSDPEDsXiW7PiJQGLqEZauSc=; b=iJnczi46JOfesuiTRCKgMNda5W7+TBS9aivltv6DM3o2Ji8MD7eyM2CewL1QmcEVNZ AywPOEjty8XndTo/zDsJzD9Jlj7IGmWV4AKS8vNB4A+d/K1zmw5+Oseh5U+7KIo6EJEQ bqLF9MCjfM8Xf2U3XRyOY90yQgIC1dgYYsHQ4kjoYgTA05j4/rw4RHwba2y7gb7L+zyb EgysExtiqGkCvv3N+0rx7S21Rxw4gVKbirpEBrLbYyBsnrQYsS50NshFOfGUIMlzDpEI 8EY9zmX1zX7VwjJEpw4zttKSTm9ZNlC6Nsst/y+AxqoqIHpe9g0DxS8htU1DpJddRi+y AnQw== X-Gm-Message-State: AOAM531rKOh2vMLW+IUwGoaS6zY/13wsq8tGdgocZmj+RHsbrtkSxQnJ 3WBBqQ+J0ZfasgoRZfk5PPvFOS8poZ8stNn0LH0= X-Google-Smtp-Source: ABdhPJwLQTuS8xJQTjbElqsIocetzly0+n7dwlHnW3lKf0bYHm2y5t6AY4K0I65gFMouHRWfJgPgspGS6PT46VPb+TI= X-Received: by 2002:a05:6402:1484:: with SMTP id e4mr12043306edv.104.1613314288087; Sun, 14 Feb 2021 06:51:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stoycho Sleptsov Date: Sun, 14 Feb 2021 16:51:17 +0200 Message-ID: To: Neil Madden Cc: Vittorio Bertocci , oauth , Warren Parad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 14:51:32 -0000 Thanks a lot for your answer Neil, as I am no expert (yet :-)) in security I was afraid to rely on redirect_uri for authentication of the client, but I will consider that option as more trustworthy now. (it is also not very clear for me which part of the app can be regarded as the redirect_uri owner, the BFF or the loaded frontend SPA, but maybe it is not so important) If you had the two options for authentication of the frontend SPA client - the redirect_uri on the one hand, and the Basic authentication with client secret through the BFF on the other, which one would you recommend? On Sun, 14 Feb 2021 at 16:28, Neil Madden wrote= : > > Public clients are implicitly authenticated by their ownership of the reg= istered redirect_uri. This why it=E2=80=99s important to use a redirect_uri= for which ownership can be reasonably established, such as HTTPS endpoints= with exact URI matching. > > There are more things that can go wrong with that (see the security BCP),= but it can be made reasonably secure. > > =E2=80=94 Neil > > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov = wrote: > > > > =EF=BB=BF > > I would like to add my reasons about the "Why are developers creating B= FF for their frontends to communicate with an AS", > > with the objective to verify if they are valid. > > > > I need the client app. to be authenticated at the AS (to determine if i= t is a first-party app., for example). > > If we decide to implement our client as a frontend SPA , then we have n= o other option except through a BFF, as PKCE does not help for authenticati= on. > > > > Or is it considered a bad practice to do that? > > > > Regards, > > Stoycho. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- > ForgeRock values your Privacy From nobody Sun Feb 14 07:35:37 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702103A0E0E for ; Sun, 14 Feb 2021 07:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hrcXbHrOWhe for ; Sun, 14 Feb 2021 07:35:33 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21B53A0E0D for ; Sun, 14 Feb 2021 07:35:33 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id i8so55670iog.7 for ; Sun, 14 Feb 2021 07:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tavwzFq54ZA9aEZWYn/DTAWqnBWg/yDj2p7pxaf+blU=; b=cwK939l8sXWjwTeIJUHSB0cezLrF9j58tq/yX0Dj/o4RHjWHVQq3ZGwwk53k0F99gW lwnKm0kCBz9zRsIQV6cGvFoLF9IK2uM1TBTHS2Z7Oeeu0+InSYuFbdsMXTYJYPq8Mnue shseJFRvywzpyfAMt+93Hbbxe0um6fzvbRuumJ0Yzs8vFrazL68GrhwHa9LgrFjy6iOO m/fZ2Kh8Lngy4V/v5vNi/Xgd1hV7STukcAmOQ9onqN0zGAnpXROb3+UDHC2UEsAzpd/P n9KwB4iga7UNz70qF5Cd3FS3jDjsIIIy+T3hWxqL+qLJU5olGnPqXSRGDSf2OF/486ib bEdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tavwzFq54ZA9aEZWYn/DTAWqnBWg/yDj2p7pxaf+blU=; b=ZXE5IF5FjVPtnoKSKSK3T+q8+U+BlqzS+vXpeY13L3jY9TpR0Bo8F3V59rOeZCgTcn YrX4UESHUfEpCRb/mnfKfYPSMok9t3oVFzYmliz3DkRB3QHhPzun6yuludyn3ep+o2s6 H8Pyg1w9XIwCHZsid6JY0ytjCJ9RreYpsh3nsUXIfQfBOlC3DL7Hxs7DGBO3B4oGMHCd p4mg8UqxQUo5NEfoA+7SD0VmgMtKCixAkhKzyosLt2ympZpR33LA46+/ka4R/nfoQOXK +TB82Kxnp/MNoCPhCzsfRFZZqwfx0f5GfYiwRA2HuEN9+atAB8QyeN4wK137IO2BS+fq 4uvw== X-Gm-Message-State: AOAM532cWiCMVK6Oa27YfHsmN6RZZeuPuFGvU0tvAI4CZKXZLdVDKTdG mb9lJC/84GAE/tOhYK8lSGE7kewMWkWP7lpP4Get X-Google-Smtp-Source: ABdhPJyl6BCninotvnBfwp1gxzqFEwtWxKATyI8KS+tQ2WKUYLR3en3htAtKM9WnBksy2wMt554gTxlK3DRBbeRaQ6Q= X-Received: by 2002:a02:3541:: with SMTP id y1mr11485921jae.66.1613316931646; Sun, 14 Feb 2021 07:35:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 16:35:20 +0100 Message-ID: To: Stoycho Sleptsov Cc: Neil Madden , Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="0000000000009f112d05bb4d9e6b" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 15:35:35 -0000 --0000000000009f112d05bb4d9e6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable redirect_uri and use PKCE via the code verifier. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov wrote: > Thanks a lot for your answer Neil, > > as I am no expert (yet :-)) in security I was afraid to rely on > redirect_uri for authentication of the client, > but I will consider that option as more trustworthy now. > > (it is also not very clear for me which part of the app can be > regarded as the redirect_uri owner, the BFF or the loaded frontend > SPA, but maybe it is not so important) > > If you had the two options for authentication of the frontend SPA > client - the redirect_uri on the one hand, and the Basic > authentication with client secret through the BFF on the other, which > one would you recommend? > > On Sun, 14 Feb 2021 at 16:28, Neil Madden > wrote: > > > > Public clients are implicitly authenticated by their ownership of the > registered redirect_uri. This why it=E2=80=99s important to use a redirec= t_uri for > which ownership can be reasonably established, such as HTTPS endpoints wi= th > exact URI matching. > > > > There are more things that can go wrong with that (see the security > BCP), but it can be made reasonably secure. > > > > =E2=80=94 Neil > > > > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov > wrote: > > > > > > =EF=BB=BF > > > I would like to add my reasons about the "Why are developers creating > BFF for their frontends to communicate with an AS", > > > with the objective to verify if they are valid. > > > > > > I need the client app. to be authenticated at the AS (to determine if > it is a first-party app., for example). > > > If we decide to implement our client as a frontend SPA , then we have > no other option except through a BFF, as PKCE does not help for > authentication. > > > > > > Or is it considered a bad practice to do that? > > > > > > Regards, > > > Stoycho. > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > ForgeRock values your Privacy > --0000000000009f112d05bb4d9e6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
redirect_uri and use PKCE via the code verifier.

Warren Parad

Founder, C= TO

Secure your user data and complete your authorization architecture. Im= plement=C2=A0Authress.


On Sun, Feb 14, 2021 at 3:51 PM Stoycho S= leptsov <stoycho.sleptsov@= gmail.com> wrote:
Thanks a lot for your answer Neil,

as I am no expert (yet :-)) in security I was afraid to rely on
redirect_uri for authentication of the client,
but I will consider that option as more trustworthy now.

(it is also not very clear for me which part of the app can be
regarded as the redirect_uri owner, the BFF or the loaded frontend
SPA, but maybe it is not so important)

If you had the two options for authentication of the frontend SPA
client - the redirect_uri on the one hand, and the Basic
authentication with client secret through the BFF on the other, which
one would you recommend?

On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com> wrote:<= br> >
> Public clients are implicitly authenticated by their ownership of the = registered redirect_uri. This why it=E2=80=99s important to use a redirect_= uri for which ownership can be reasonably established, such as HTTPS endpoi= nts with exact URI matching.
>
> There are more things that can go wrong with that (see the security BC= P), but it can be made reasonably secure.
>
> =E2=80=94 Neil
>
> > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
> >
> > =EF=BB=BF
> > I would like to add my reasons about the "Why are developers= creating BFF for their frontends to communicate with an AS",
> > with the objective to verify if they are valid.
> >
> > I need the client app. to be authenticated at the AS (to determin= e if it is a first-party app., for example).
> > If we decide to implement our client as a frontend SPA , then we = have no other option except through a BFF, as PKCE does not help for authen= tication.
> >
> > Or is it considered a bad practice to do that?
> >
> > Regards,
> > Stoycho.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> --
> ForgeRock values your Privacy <https://www.forgerock.c= om/your-privacy>
--0000000000009f112d05bb4d9e6b-- From nobody Sun Feb 14 09:27:32 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4EA3A1024 for ; Sun, 14 Feb 2021 09:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUuJrrzpqY5z for ; Sun, 14 Feb 2021 09:27:28 -0800 (PST) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151C93A101C for ; Sun, 14 Feb 2021 09:27:27 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id w1so7512247ejf.11 for ; Sun, 14 Feb 2021 09:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjYUn0tYsMwZolnmD+fCxvCIZI3iaSOxz33trOLWVv8=; b=vIN0V9utVEgQ3oDBM78x2j2VlIAsiPvus1ZPOQErD1l6PmWFlo7XgWoeTxJ5q8hkzT VZLVJy10g2/LWonmW7Pp5R1RtTtSjid+6i2OnXLuEDRBUvEoFfHnssmwGn1WA5YXSwX1 pcd9y8c7rd9F4gUC7kk0AOyF4Hz+iiyJqDQzVMwUrJk7icC9tGSWzDEceLu7lPl7WxPX 5SS7bbi2I/ROxpCyR/JkzDLowFSPUcrevoFLeSWubbshcS4nxTaf7u3FHxhsNBUgVLSP OlO5MUjyAZxwQm+jrWAjWDp8GHpsN5f4kVwf2E87OeHe2nLDGE2qFxje3kDj6sl/pvjI HcWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KjYUn0tYsMwZolnmD+fCxvCIZI3iaSOxz33trOLWVv8=; b=U0Qh217i8/xjNIb1jXyu+sbvecwQE2xzK7sbToc/lxGYfKpKVkJ33pKD2UQBJBMCYp rpE0fyT6hdTFbTqpI3LazfNxoR+nVkukAv1hZSzgYqKJgRX6dkt1FXJN9hUX2Hp/DnLe VZxnkR0IPAZP9EwA1QkLLcDfXCfg/To3EUfLNMouMsjmuNPUx/TDB7JWLj/04hSC4Jch SO8LatcCcyThoY3wLschCgG/stkQ3v8m7efrCMj7YSfbcd2vg+dhNBIBavEFCvokYYiM p1pIJU/vRnnI55txV6K4Zk4UsovHp71B4IPxC0bmtjQyeNe0+I4MtxZnZvGxQfSnCrc0 5RwA== X-Gm-Message-State: AOAM532IxvAOmSxRqa0EjgJXQms3F6W72LM+l9/SQko9IdX45xRaaVDv XQd58gHu0AOpDHcKqyvKj6TXF4smky6yHjaG3Nk= X-Google-Smtp-Source: ABdhPJyiKVZBQAPDytsejP2XFuXzimpk9tx7TbdJdb/f3zAtTV5H3fr+/reO/WN7ivLzXzSR3nLG1lvKSXkuQzpkL5g= X-Received: by 2002:a17:907:11c1:: with SMTP id va1mr3121208ejb.352.1613323646405; Sun, 14 Feb 2021 09:27:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stoycho Sleptsov Date: Sun, 14 Feb 2021 19:27:15 +0200 Message-ID: To: Warren Parad Cc: Neil Madden , Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="000000000000da0e4f05bb4f2e31" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 17:27:30 -0000 --000000000000da0e4f05bb4f2e31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Warren, as I see you and Neil have the same idea, but as of this moment I think this method is not a valid option for authenticating a client according to the draft-ietf-oauth-v2-1. On the other hand, authenticating the client through the BFF seems conforming to the spec., but in the case when the access token is use= d in the browser in fact, I am afraid that it can be regarded as some kind of "deception" of the AS. It seems the frontend SPA is not the easiest way to go with oauth... Stoycho. On Sun, 14 Feb 2021 at 17:35, Warren Parad wrote: > redirect_uri and use PKCE via the code verifier. > > Warren Parad > > Founder, CTO > Secure your user data and complete your authorization architecture. > Implement Authress . > > > On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov < > stoycho.sleptsov@gmail.com> wrote: > >> Thanks a lot for your answer Neil, >> >> as I am no expert (yet :-)) in security I was afraid to rely on >> redirect_uri for authentication of the client, >> but I will consider that option as more trustworthy now. >> >> (it is also not very clear for me which part of the app can be >> regarded as the redirect_uri owner, the BFF or the loaded frontend >> SPA, but maybe it is not so important) >> >> If you had the two options for authentication of the frontend SPA >> client - the redirect_uri on the one hand, and the Basic >> authentication with client secret through the BFF on the other, which >> one would you recommend? >> >> On Sun, 14 Feb 2021 at 16:28, Neil Madden >> wrote: >> > >> > Public clients are implicitly authenticated by their ownership of the >> registered redirect_uri. This why it=E2=80=99s important to use a redire= ct_uri for >> which ownership can be reasonably established, such as HTTPS endpoints w= ith >> exact URI matching. >> > >> > There are more things that can go wrong with that (see the security >> BCP), but it can be made reasonably secure. >> > >> > =E2=80=94 Neil >> > >> > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov < >> stoycho.sleptsov@gmail.com> wrote: >> > > >> > > =EF=BB=BF >> > > I would like to add my reasons about the "Why are developers creatin= g >> BFF for their frontends to communicate with an AS", >> > > with the objective to verify if they are valid. >> > > >> > > I need the client app. to be authenticated at the AS (to determine i= f >> it is a first-party app., for example). >> > > If we decide to implement our client as a frontend SPA , then we hav= e >> no other option except through a BFF, as PKCE does not help for >> authentication. >> > > >> > > Or is it considered a bad practice to do that? >> > > >> > > Regards, >> > > Stoycho. >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > -- >> > ForgeRock values your Privacy >> > --000000000000da0e4f05bb4f2e31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Warren,

as I see you and Neil ha= ve the same idea,
but as of this moment I think this method is no= t a valid option for authenticating
a client according to the=C2= =A0draft-ietf-oauth-v2-1.

On the other hand, authe= nticating the client through the BFF
seems conforming to the spec= ., but=C2=A0in the=C2=A0case when=C2=A0the access token is used
i= n the browser in fact, I am afraid that it can be regarded as
som= e kind of "deception" of the AS.

It seem= s the frontend SPA is not the easiest way to go with oauth...
Stoycho.

On Sun, 14 Feb 2021 at 17:35, Warren Parad <wparad@rhosys.ch> wrote:
=
redirect= _uri and use PKCE via the code verifier.

Secure your user data and complete you= r authorization architecture. Implement=C2=A0Authress.

On Sun, F= eb 14, 2021 at 3:51 PM Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:<= br>
Thanks a lot for= your answer Neil,

as I am no expert (yet :-)) in security I was afraid to rely on
redirect_uri for authentication of the client,
but I will consider that option as more trustworthy now.

(it is also not very clear for me which part of the app can be
regarded as the redirect_uri owner, the BFF or the loaded frontend
SPA, but maybe it is not so important)

If you had the two options for authentication of the frontend SPA
client - the redirect_uri on the one hand, and the Basic
authentication with client secret through the BFF on the other, which
one would you recommend?

On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com> wrote:<= br> >
> Public clients are implicitly authenticated by their ownership of the = registered redirect_uri. This why it=E2=80=99s important to use a redirect_= uri for which ownership can be reasonably established, such as HTTPS endpoi= nts with exact URI matching.
>
> There are more things that can go wrong with that (see the security BC= P), but it can be made reasonably secure.
>
> =E2=80=94 Neil
>
> > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
> >
> > =EF=BB=BF
> > I would like to add my reasons about the "Why are developers= creating BFF for their frontends to communicate with an AS",
> > with the objective to verify if they are valid.
> >
> > I need the client app. to be authenticated at the AS (to determin= e if it is a first-party app., for example).
> > If we decide to implement our client as a frontend SPA , then we = have no other option except through a BFF, as PKCE does not help for authen= tication.
> >
> > Or is it considered a bad practice to do that?
> >
> > Regards,
> > Stoycho.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> --
> ForgeRock values your Privacy <https://www.forgerock.c= om/your-privacy>
--000000000000da0e4f05bb4f2e31-- From nobody Sun Feb 14 09:45:10 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482C13A1040 for ; Sun, 14 Feb 2021 09:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caaXRbAhwiD4 for ; Sun, 14 Feb 2021 09:45:07 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ABD3A103F for ; Sun, 14 Feb 2021 09:45:07 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id y5so824881ioc.2 for ; Sun, 14 Feb 2021 09:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jOEGcHdykuBIM3qs1cUd8yU0XXrr46ZwWPe8abjR7Cw=; b=ZSXsyMqdFEqPdFlDTW5ivLIJ0lGEfS2blHhB7WVReVCgaxl7B3eu1KJny51oUFicc/ //Mi7ifLn8JhiMwf0Jvj2RvTmcK3EJDeqePgtR+BtvlA1/g8lnT5SJog2GJBXErZWitK wp4oY2tCnsNToFZGMxop/aElbGTiOcOVHHVECIFAABULEHtV5rSuS5zvIRg2Inms7NB7 hcOD08u/HAtl1SScMIx6n6WjUCDbejl5Ho9kbG/l58MvLvrDDFtm73D+tWit+mN3eItX wRPZo1CbF8oUvrbHP1TPMo/vAaXLg0elsvMD3+EKoB2nPnDFW+O0lrxSvlWYtb6py4Uv zAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jOEGcHdykuBIM3qs1cUd8yU0XXrr46ZwWPe8abjR7Cw=; b=htmdKQMNCc+XqPlQJvkomvML5vrxGN1iVA183TIBsrzzzlCNgGp8+tnecpt0qlz4vS VOUunHxhFcdug1ooj3XpIHOk00CdB+mpw+AzIx7NzB1Ad+EaUOkygOTSNvEO1lembqRh glNG0d+qyFPdrdqNbnRvHKySEsB/r1N/eYUPhbVJzGaA21BCw0v7od7dyzt9TIO/M79F 9FuJqqCh2CYxTLw39NPlTRZzcdlWI56zZ/0nRWttU3a6Z4IHJNIpYCsyczGK8tqcaBnV fuUWeVWEohr7gUwSxsnDxge79uTNGRAuV1vH0SBPxdB9AL2UpVzLH8q8Ru6kdoq28Jg2 Rb4A== X-Gm-Message-State: AOAM531RVVoI1LYSWGI//hlAuzJyeOAtdthUb2aZp6Pt82zZWT/sqgyl +R1P+ig4ZDrN9dma8gve/UbQfr0gXXJQCydWmCY6 X-Google-Smtp-Source: ABdhPJzAFIED2Lj+M5hImAOSIero7fAY4rLZbLpeNAKwbdlhHFVqkHJLN6nAJoXDoGoFS17NBEBfF6I9eyzIb7+Brig= X-Received: by 2002:a6b:da0f:: with SMTP id x15mr9837416iob.48.1613324706214; Sun, 14 Feb 2021 09:45:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 18:44:55 +0100 Message-ID: To: Stoycho Sleptsov Cc: Neil Madden , Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="000000000000058b5d05bb4f6ecd" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 17:45:09 -0000 --000000000000058b5d05bb4f6ecd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct it would never need to be used to authenticate a client, as a client is always offline and can directly use the backchannel. You would never need the front channel to authenticate a client, however you might need the front channel to authorize a client to access user resources offline. Is that what you are talking about, i.e. the offline refresh_token authorization code flow? If yes, then the standard would be to use the authorization code flow requesting as you've mentioned. Although that flow already exists and well established, and without any issues, having a standard specifying how to communicate with the client doesn't seem to be useful, as you only need to pass an *auth code* and the *issuer* to the client. But since these endpoints are never exposed nor need to have interoperability between different owners (i.e. the owner of the front-channel is different from the owner of the back-channel), what's the benefit of specifying the explicit endpoints necessary for the BFF to have? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sleptsov wrote: > Thanks Warren, > > as I see you and Neil have the same idea, > but as of this moment I think this method is not a valid option for > authenticating > a client according to the draft-ietf-oauth-v2-1. > > On the other hand, authenticating the client through the BFF > seems conforming to the spec., but in the case when the access token is > used > in the browser in fact, I am afraid that it can be regarded as > some kind of "deception" of the AS. > > It seems the frontend SPA is not the easiest way to go with oauth... > > Stoycho. > > On Sun, 14 Feb 2021 at 17:35, Warren Parad wrote: > >> redirect_uri and use PKCE via the code verifier. >> >> Warren Parad >> >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov < >> stoycho.sleptsov@gmail.com> wrote: >> >>> Thanks a lot for your answer Neil, >>> >>> as I am no expert (yet :-)) in security I was afraid to rely on >>> redirect_uri for authentication of the client, >>> but I will consider that option as more trustworthy now. >>> >>> (it is also not very clear for me which part of the app can be >>> regarded as the redirect_uri owner, the BFF or the loaded frontend >>> SPA, but maybe it is not so important) >>> >>> If you had the two options for authentication of the frontend SPA >>> client - the redirect_uri on the one hand, and the Basic >>> authentication with client secret through the BFF on the other, which >>> one would you recommend? >>> >>> On Sun, 14 Feb 2021 at 16:28, Neil Madden >>> wrote: >>> > >>> > Public clients are implicitly authenticated by their ownership of the >>> registered redirect_uri. This why it=E2=80=99s important to use a redir= ect_uri for >>> which ownership can be reasonably established, such as HTTPS endpoints = with >>> exact URI matching. >>> > >>> > There are more things that can go wrong with that (see the security >>> BCP), but it can be made reasonably secure. >>> > >>> > =E2=80=94 Neil >>> > >>> > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov < >>> stoycho.sleptsov@gmail.com> wrote: >>> > > >>> > > =EF=BB=BF >>> > > I would like to add my reasons about the "Why are developers >>> creating BFF for their frontends to communicate with an AS", >>> > > with the objective to verify if they are valid. >>> > > >>> > > I need the client app. to be authenticated at the AS (to determine >>> if it is a first-party app., for example). >>> > > If we decide to implement our client as a frontend SPA , then we >>> have no other option except through a BFF, as PKCE does not help for >>> authentication. >>> > > >>> > > Or is it considered a bad practice to do that? >>> > > >>> > > Regards, >>> > > Stoycho. >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > -- >>> > ForgeRock values your Privacy >>> >> --000000000000058b5d05bb4f6ecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct it would never need to be used to authenticate a c= lient, as a client is always offline and can directly use the backchannel. = You would never need the front channel to authenticate a client, however yo= u might need the front channel to authorize a client to access user resourc= es offline. Is that what you are talking about, i.e. the offline refresh_to= ken authorization code flow?

If yes, then the stand= ard would be to use the authorization code flow requesting as you've me= ntioned. Although that flow already exists and well established, and withou= t any issues, having a standard specifying how to communicate with the clie= nt doesn't seem to be useful, as you only need to pass an auth code<= /b>=C2=A0and the issuer=C2=A0to the client. But since these endpoint= s are never exposed nor need to have interoperability between different own= ers (i.e. the owner of the front-channel is different from the owner of the= back-channel), what's the benefit of specifying the explicit endpoints= necessary for the BFF to have?

=

Warren Parad

Founder, CTO

<= /p>

Warren Parad

Founder, CTO

Secure your user data and complete your authorizatio= n architecture. Implement=C2=A0Authress.


On Sun, Feb 14, 2= 021 at 6:27 PM Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
Thanks Warren,

as I see you and Neil have the same idea,
but as of this= moment I think this method is not a valid option for authenticating
<= div>a client according to the=C2=A0draft-ietf-oauth-v2-1.

On the other hand, authenticating the client through the BFF
<= div>seems conforming to the spec., but=C2=A0in the=C2=A0case when=C2=A0the = access token is used
in the browser in fact, I am afraid that it = can be regarded as
some kind of "deception" of the AS.<= /div>

It seems the frontend SPA is not the easiest way t= o go with oauth...

Stoycho.

On Sun, 14 Feb 20= 21 at 17:35, Warren Parad <wparad@rhosys.ch> wrote:
redirect_uri and use PKCE via the= code verifier.

Warren Pa= rad

Fou= nder, CTO

Secure your user data and complete your authorization architect= ure. Implement=C2=A0Authress.


On Sun, Feb 14, 2021 at 3:51 PM St= oycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
Thanks a lot for your answer Neil,

as I am no expert (yet :-)) in security I was afraid to rely on
redirect_uri for authentication of the client,
but I will consider that option as more trustworthy now.

(it is also not very clear for me which part of the app can be
regarded as the redirect_uri owner, the BFF or the loaded frontend
SPA, but maybe it is not so important)

If you had the two options for authentication of the frontend SPA
client - the redirect_uri on the one hand, and the Basic
authentication with client secret through the BFF on the other, which
one would you recommend?

On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com> wrote:<= br> >
> Public clients are implicitly authenticated by their ownership of the = registered redirect_uri. This why it=E2=80=99s important to use a redirect_= uri for which ownership can be reasonably established, such as HTTPS endpoi= nts with exact URI matching.
>
> There are more things that can go wrong with that (see the security BC= P), but it can be made reasonably secure.
>
> =E2=80=94 Neil
>
> > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
> >
> > =EF=BB=BF
> > I would like to add my reasons about the "Why are developers= creating BFF for their frontends to communicate with an AS",
> > with the objective to verify if they are valid.
> >
> > I need the client app. to be authenticated at the AS (to determin= e if it is a first-party app., for example).
> > If we decide to implement our client as a frontend SPA , then we = have no other option except through a BFF, as PKCE does not help for authen= tication.
> >
> > Or is it considered a bad practice to do that?
> >
> > Regards,
> > Stoycho.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> --
> ForgeRock values your Privacy <https://www.forgerock.c= om/your-privacy>
--000000000000058b5d05bb4f6ecd-- From nobody Sun Feb 14 10:30:58 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0655E3A10C7 for ; Sun, 14 Feb 2021 10:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrM3xEPzOpva for ; Sun, 14 Feb 2021 10:30:53 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CA63A10C5 for ; Sun, 14 Feb 2021 10:30:53 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id m1so5876108wml.2 for ; Sun, 14 Feb 2021 10:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:cc:date:message-id:references :to:content-transfer-encoding; bh=ZbLYx5xbrwhvkJzyjJGG8ik1PDJpoL55HdJSfkx65pE=; b=BvvC65QXM3Gj+2LF7k6I/LGTaFpkbXXL1yqYV55eCcOwSwPvw3Jga7jYTFLZnVPi/Q K1lDeKuTT64n9ltoG55Cz5Zz1GD3ugofUGsNZ2tn4RU5iXJMQssrmcQlDTe2R7up75CL 5jRIiXYKGXvAPISdVz0+5T3rQevAfN9LkmR4A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:cc:date :message-id:references:to:content-transfer-encoding; bh=ZbLYx5xbrwhvkJzyjJGG8ik1PDJpoL55HdJSfkx65pE=; b=Ry6puUNt2/wGOxFJbknEE1BBrn1uLn21Y9SWNY9YWIxqNgvt9akMGfE75RulHBzNWy wP4+drBQdxuPNPuR0yTxMOrHrytzjGRn6Qhi044Rv6z1xwsHbaUPDX3kH5nMWZASQCUu 4bF4ikAyVlAHmrrhKNI5mwJjY7TfCSxF/U0cIqf3iu826XIzcU1nuVCFl+GoSBGXqpLa qQF9iosX/XaxkbA0Yw3+giDzesZ4Vu+KOITYzoENHUlZOxU/EBqv1I6e/ObHriL6InEx xemHsiW2Yq8B7FeTe+zXYqJ2MbeHsjf7OLur57f5vsnBTR18RfmCiDzktdUO8nZXMeyd N8Iw== X-Gm-Message-State: AOAM5332tOaC7u+Mig48lvBaCjj7trzS0OZWYNC2crrBpwzzSgSBtDf+ X5vtqOjlVQggJOa7Mo5t7wH6WcTWfvwn6dtMoJsMRx7XsKsK9ULcFZHME0Sx26GfteCKgRUiKA= = X-Google-Smtp-Source: ABdhPJzzeFHkxIMyiU20GUgIUzX3cv4MOCZ4CM2JpmhVKOz6iT3314zwvRNQSkkkSRdOCiuaeTcsFw== X-Received: by 2002:a1c:8096:: with SMTP id b144mr11443862wmd.169.1613327451612; Sun, 14 Feb 2021 10:30:51 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id 11sm20293569wmo.46.2021.02.14.10.30.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 10:30:51 -0800 (PST) Mime-Version: 1.0 (1.0) From: Neil Madden In-Reply-To: Cc: Warren Parad , Vittorio Bertocci , oauth Date: Sun, 14 Feb 2021 18:30:47 +0000 Message-Id: <1A964B70-7C73-4CAE-B3B9-FF3BACF0E698@forgerock.com> References: To: Stoycho Sleptsov X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-6B1DD390-D2ED-4DAF-9B64-D8D7BF0E098E Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 18:30:56 -0000 --Apple-Mail-6B1DD390-D2ED-4DAF-9B64-D8D7BF0E098E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Within the spec =E2=80=9Cclient authentication=E2=80=9D refers to explicit = authentication of the client using credentials. But you said initially that= you wanted this to =E2=80=9Cdetermine if it is a first-party app, for exam= ple=E2=80=9D. You can determine this based on the redirect_uri and the fact= that only the legitimate client can receive an authorization code at that = redirect_uri (if its HTTPS, exact matching of URIs, etc). This is what I re= fer to as implicit authentication - the AS knows at the point of auth code = exchange that only the legitimate client could have obtained that code.=20 (This is not true for mobile clients using private-use URI schemes). Note that for both public and confidential clients, the confirmation of the= client identity happens after the user has gone through the authorization = flow. PAR fixes this for confidential clients, but not public ones. So that= is one reason to prefer a BFF pattern and a confidential client.=20 Confidential clients also have an extra layer of defence in depth: they nee= d a redirect_uri *and* client credentials. So that is another reason to use= a confidential client and BFF.=20 A backend server may also have a more reliable connection to the AS. So tha= t may also be a good reason to use a BFF - eg to avoid having to reauthoriz= e with the user because an auth code or refresh request timed out due to a = flaky network connection.=20 So there may be many good reasons to use a BFF pattern. But if you just wan= t a reasonable assurance of client identity at the point of issuing tokens,= then IMO a public client + PKCE is fine for many cases.=20 =E2=80=94 Neil > On 14 Feb 2021, at 17:27, Stoycho Sleptsov w= rote: > =EF=BB=BF > Thanks Warren, >=20 > as I see you and Neil have the same idea, > but as of this moment I think this method is not a valid option for authe= nticating > a client according to the draft-ietf-oauth-v2-1. >=20 > On the other hand, authenticating the client through the BFF > seems conforming to the spec., but in the case when the access token is u= sed > in the browser in fact, I am afraid that it can be regarded as > some kind of "deception" of the AS. >=20 > It seems the frontend SPA is not the easiest way to go with oauth... >=20 > Stoycho. >=20 > On Sun, 14 Feb 2021 at 17:35, Warren Parad wrote: >> redirect_uri and use PKCE via the code verifier. >>=20 >>=20 >> Warren Parad >> Founder, CTO >> Secure your user data and complete your authorization architecture. Impl= ement Authress. >>=20 >>=20 >> On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov wrote: >>> Thanks a lot for your answer Neil, >>>=20 >>> as I am no expert (yet :-)) in security I was afraid to rely on >>> redirect_uri for authentication of the client, >>> but I will consider that option as more trustworthy now. >>>=20 >>> (it is also not very clear for me which part of the app can be >>> regarded as the redirect_uri owner, the BFF or the loaded frontend >>> SPA, but maybe it is not so important) >>>=20 >>> If you had the two options for authentication of the frontend SPA >>> client - the redirect_uri on the one hand, and the Basic >>> authentication with client secret through the BFF on the other, which >>> one would you recommend? >>>=20 >>> On Sun, 14 Feb 2021 at 16:28, Neil Madden w= rote: >>> > >>> > Public clients are implicitly authenticated by their ownership of the= registered redirect_uri. This why it=E2=80=99s important to use a redirect= _uri for which ownership can be reasonably established, such as HTTPS endpo= ints with exact URI matching. >>> > >>> > There are more things that can go wrong with that (see the security B= CP), but it can be made reasonably secure. >>> > >>> > =E2=80=94 Neil >>> > >>> > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov wrote: >>> > > >>> > > =EF=BB=BF >>> > > I would like to add my reasons about the "Why are developers creati= ng BFF for their frontends to communicate with an AS", >>> > > with the objective to verify if they are valid. >>> > > >>> > > I need the client app. to be authenticated at the AS (to determine = if it is a first-party app., for example). >>> > > If we decide to implement our client as a frontend SPA , then we ha= ve no other option except through a BFF, as PKCE does not help for authenti= cation. >>> > > >>> > > Or is it considered a bad practice to do that? >>> > > >>> > > Regards, >>> > > Stoycho. >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > -- >>> > ForgeRock values your Privacy --=20 ForgeRock values your Privacy --Apple-Mail-6B1DD390-D2ED-4DAF-9B64-D8D7BF0E098E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Within = the spec =E2=80=9Cclient authentication=E2=80=9D refers to explicit authent= ication of the client using credentials. But you said initially that you wa= nted this to =E2=80=9Cdetermine if it is a first-party app, for example=E2= =80=9D. You can determine this based on the redirect_uri and the fact that = only the legitimate client can receive an authorization code at that redire= ct_uri (if its HTTPS, exact matching of URIs, etc). This is what I refer to= as implicit authentication - the AS knows at the point of auth code exchan= ge that only the legitimate client could have obtained that code. 

(This is not true for mobile = clients using private-use URI schemes).

Note that for both public and confidential clients, the confi= rmation of the client identity happens after the user has gone through the = authorization flow. PAR fixes this for confidential clients, but not public= ones. So that is one reason to prefer a BFF pattern and a confidential cli= ent. 

Confidential cl= ients also have an extra layer of defence in depth: they need a redirect_ur= i *and* client credentials. So that is another reason to use a confidential= client and BFF. 

A b= ackend server may also have a more reliable connection to the AS. So that m= ay also be a good reason to use a BFF - eg to avoid having to reauthorize w= ith the user because an auth code or refresh request timed out due to a fla= ky network connection. 

So there may be many good reasons to use a BFF pattern. But if you just = want a reasonable assurance of client identity at the point of issuing toke= ns, then IMO a public client + PKCE is fine for many cases. 

=E2=80=94 Neil

On 14 Feb 2021, at 1= 7:27, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:

=EF=BB=BF
Thanks Warren,

as I see you and Neil have the = same idea,
but as of this moment I think this method is not a val= id option for authenticating
a client according to the draft= -ietf-oauth-v2-1.

On the other hand, authenticatin= g the client through the BFF
seems conforming to the spec., but&n= bsp;in the case when the access token is used
in the br= owser in fact, I am afraid that it can be regarded as
some kind o= f "deception" of the AS.

It seems the frontend SPA= is not the easiest way to go with oauth...

Stoych= o.

On Sun, 14 Feb 2021 at 17:35, Warren Parad <wparad@rhosys.ch> wrote:
redirect_uri and use PKCE= via the code verifier.

<= col width=3D"214">

Warren Parad

Founder, CTO

Secure your user data and c= omplete your authorization architecture. Implement Authress<= /a>.


On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov <stoycho.sleptsov@gmail.com&= gt; wrote:
Thank= s a lot for your answer Neil,

as I am no expert (yet :-)) in security I was afraid to rely on
redirect_uri for authentication of the client,
but I will consider that option as more trustworthy now.

(it is also not very clear for me which part of the app can be
regarded as the redirect_uri owner, the BFF or the loaded frontend
SPA, but maybe it is not so important)

If you had the two options for authentication of the frontend SPA
client - the redirect_uri on the one hand, and the Basic
authentication with client secret through the BFF on the other, which
one would you recommend?

On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com> wrote:<= br> >
> Public clients are implicitly authenticated by their ownership of the = registered redirect_uri. This why it=E2=80=99s important to use a redirect_= uri for which ownership can be reasonably established, such as HTTPS endpoi= nts with exact URI matching.
>
> There are more things that can go wrong with that (see the security BC= P), but it can be made reasonably secure.
>
> =E2=80=94 Neil
>
> > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
> >
> > =EF=BB=BF
> > I would like to add my reasons about the "Why are developers crea= ting BFF for their frontends to communicate with an AS",
> > with the objective to verify if they are valid.
> >
> > I need the client app. to be authenticated at the AS (to determin= e if it is a first-party app., for example).
> > If we decide to implement our client as a frontend SPA , then we = have no other option except through a BFF, as PKCE does not help for authen= tication.
> >
> > Or is it considered a bad practice to do that?
> >
> > Regards,
> > Stoycho.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> --
> ForgeRock values your Privacy <https://www.forgerock.c= om/your-privacy>

ForgeRock values your Privacy --Apple-Mail-6B1DD390-D2ED-4DAF-9B64-D8D7BF0E098E-- From nobody Sun Feb 14 10:57:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91323A112A for ; Sun, 14 Feb 2021 10:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joyJPuuT0iz6 for ; Sun, 14 Feb 2021 10:57:30 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13EED3A1128 for ; Sun, 14 Feb 2021 10:57:30 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id n10so2993004pgl.10 for ; Sun, 14 Feb 2021 10:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=LPyR78kHVXc96QHXgUdv31eoKbzp2c+NgAamGrv+YVI=; b=WmdhP3SRufsywisr08fRN9M0V2wVAIQGb/d2epYZd76JNWMY+vMPyE6WA8LPH4FWp7 dNQYdmXmDOyRib8LuYFFFN99QRmzG/cQp+Z35MwkG1XpzLdmbh5OJYiadlc87mDuRTce Px8deTREnDZXMeXHU6bStKUO/uYm5DHr+82/CI6BNAz8cx+6NcKRJtv2buf0cCTJts5+ /vUvK+647lWqFlltI8Au0cx1MVCzHOsKBDBCE/njnEbc/eEgGVd03PRftnU3MF20ngPV dCZn5I4Mm7L/0/hinQ4zO22jQMXEm1vuPMAsecBIU9B8J+ufmB/3IDrF58a0c7P6bfgE xOLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=LPyR78kHVXc96QHXgUdv31eoKbzp2c+NgAamGrv+YVI=; b=jsItj7rj8qulqLwHyCO+JtlFBi4fCSPcPmproD7yJWrVZZriYbYEKf7MGw6lczJYAV fPIJcNqbsaMOQEUonDG2Pw80qKaspjamAs0doFwXBJujz44iA2uhKMy4FmhSFtxtWmDF tFRyNFvB/3WpNkkuZ+kvAwDeEbTAe6tSRb1KRXM55HBD7kMsiFuJTcApoivbElOVTksc yWrOZ6zQVmvGZerfMqM8DVVEIygRxlN6hnNMmjwlKIQHVIIbDd/WBKLxbu0mX3zSB+pV DbQWAgx0KL23M3ereqR3cb8JwZQGXmoyglUbozT1CUie5hoBEjzVzUaRKJFbJ6+8kn8a u8yg== X-Gm-Message-State: AOAM53208iSElZOVuFf7sGYi4pnT4R6ybMxbg/eka4z0V4TJnIyH7XAw WfckiVoafbnfiyyBIPfFEUYEgQ== X-Google-Smtp-Source: ABdhPJzF7cHkwAVdtxUyitXc4+eS5xeZW48B/nbGHGHi2P9tbMPHC9iAudmGPV80bsksCjRS8mX18A== X-Received: by 2002:a63:1343:: with SMTP id 3mr336784pgt.166.1613329047173; Sun, 14 Feb 2021 10:57:27 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id n1sm15609622pfd.212.2021.02.14.10.57.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 10:57:26 -0800 (PST) From: Vittorio Bertocci To: Warren Parad CC: Neil Madden , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAA1Za+AAAVvgIAADHnkgAAF6ACAAGWCiw== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 18:57:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052378AF13E3AAA9743DA0AAE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 18:57:33 -0000 --_000_CO6PR18MB4052378AF13E3AAA9743DA0AAE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SVRQLCBmb3IgZXhhbXBsZQ0KDQpGcm9tOiBXYXJyZW4gUGFyYWQgPHdwYXJhZD00MHJob3N5cy5j aEBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMDQ6 NTQNClRvOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPg0K Q2M6IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPiwgIm9hdXRoQGlldGYu b3JnIiA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBUb2tlbiBNZWRp YXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBC RkYpDQoNCkNhbiB5b3UgZXhwYW5kIG9uIHdoYXQgc2lsZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBz ZXNzaW9uIHRva2VuIHN0YW5kcyBmb3IgaGVyZT8gSWYgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhl IGlmcmFtZSBzY2VuYXJpbywgdGhlIG5ldyBicm93c2VyIG1lYXN1cmVzIG1ha2UgaXQgcHJvYmxl bWF0aWMuDQpXaGljaCBuZXcgYnJvd3NlciBtZWFzdXJlcz8NCg0KDQpbSW1hZ2UgcmVtb3ZlZCBi eSBzZW5kZXIuXQ0KDQpXYXJyZW4gUGFyYWQNCg0KRm91bmRlciwgQ1RPDQpTZWN1cmUgeW91ciB1 c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1cmUuIElt cGxlbWVudCBBdXRocmVzczxodHRwczovL2F1dGhyZXNzLmlvPi4NCg0KDQpPbiBTdW4sIEZlYiAx NCwgMjAyMSBhdCAxOjMzIFBNIFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00 MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCg0KICAqICAgRm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBk b2N1bWVudCBzZWxlY3Rpb24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNvbnRhY3Qg dXBkYXRlcywgZXRjLi4uIFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBjbGllbnQg c2lkZSBzaWxlbnQgYXV0aGVudGljYXRpb24gdXNpbmcgdGhlIHByb3ZpZGVkIHNlc3Npb24gdG9r ZW4gZnJvbSB0aGUgQXp1cmUgQUQgQVMsIHdpdGhvdXQgbmVlZGluZyB0byBtYWtlIGFueSBSTyBh cGkgY2FsbHMgbm9yIHVzZXIgcmVkaXJlY3RzLg0KQ2FuIHlvdSBleHBhbmQgb24gd2hhdCBzaWxl bnQgYXV0aGVudGljYXRpb24gYW5kIHNlc3Npb24gdG9rZW4gc3RhbmRzIGZvciBoZXJlPyBJZiB5 b3UgYXJlIHJlZmVycmluZyB0byB0aGUgaWZyYW1lIHNjZW5hcmlvLCB0aGUgbmV3IGJyb3dzZXIg bWVhc3VyZXMgbWFrZSBpdCBwcm9ibGVtYXRpYy4gSW4gY29kZStQS0NFIHlvdSBjYW4gdXNlIGEg cmVmcmVzaCB0b2tlbiwgYnV0IHNlZSB0aGUgb3RoZXIgcmVwbHkgZm9yIGhvdyB0aGlzIHByb3Bv c2FsIGlzIGFuIGFsdGVybmF0aXZlIHRvIHRoYXQgaW4gc29tZSBzaXR1YXRpb25zLiBUaGlzIGFu c3dlciB3YXMgc3BlY2lmaWNhbGx5IG9uIHdoeSBoYXZpbmcgYmFja2VuZC1pc3N1ZWQgdG9rZW5z IGRpZG7igJl0IGFwcGx5IHRvIHRoaXMgc2NlbmFyaW8uDQoNCg0KRnJvbTogV2FycmVuIFBhcmFk IDx3cGFyYWQ9NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwcmhvc3lzLmNoQGRt YXJjLmlldGYub3JnPj4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMDM6NDgN ClRvOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPG1haWx0 bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+Pg0KQ2M6IE5laWwgTWFkZGVuIDxuZWlsLm1h ZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4sICJv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlh dGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJG RikNCg0KRm9yIHRoZSB0cnVzdGVkIHBhcnQsIHNlZSBhYm92ZS4gRm9yIHRoZSBzaG9ydCBsaXZl ZCBKV1RzLCB0aGF04oCZcyBub3QgcmVhbGx5IGFuIG9wdGlvbi4gVGhlIG1vc3QgZ2VuZXJpYyBz Y2VuYXJpbyBhZGRyZXNzZWQgaGVyZSBpcyBmb3IgQVBJcyB0aGF0IGFjY2VwdCB0b2tlbnMgaXNz dWVkIGJ5IHRoZSBBUzsgdGhlIGJhY2tlbmQgY2FuIHJlcXVlc3QgdGhlbSBhcyBhIGNsaWVudCwg YnV0IGl0IGNhbm5vdCBtaW50IHRoZW0uIEltYWdpbmUgd2XigJlyZSB0YWxraW5nIGFib3V0IGEg U1BBIGFwcGxpY2F0aW9uIHRoYXQgc2lnbnMgaW4gdXNlcnMgdXNpbmcgQXp1cmUgQUQsIGFuZCBu ZWVkcyB0byBjYWxsIE9mZmljZSBhbmQgQXp1cmUgQVBJcy4gVGhlIFNQQSBiYWNrZW5kIGNhbm5v dCBpc3N1ZSB0b2tlbnMgZm9yIHRob3NlIEFQSXMsIGl0IGNhbiBvbmx5IHJlcXVlc3QgdGhlbSB0 byB0aGUgQXp1cmUgQUQgQVMuDQoNCkZvciBVSSByZWxhdGVkIGZ1bmN0aW9uYWxpdHksIGkuZS4g ZG9jdW1lbnQgc2VsZWN0aW9uLCB1c2VyIHByb2ZpbGUgZGlzcGxheS9jaGFuZ2VzLCBjb250YWN0 IHVwZGF0ZXMsIGV0Yy4uLiBZb3Ugc2hvdWxkIGJlIGFibGUgdG8gZXhlY3V0ZSB0aGUgY2xpZW50 IHNpZGUgc2lsZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5nIHRoZSBwcm92aWRlZCBzZXNzaW9uIHRv a2VuIGZyb20gdGhlIEF6dXJlIEFEIEFTLCB3aXRob3V0IG5lZWRpbmcgdG8gbWFrZSBhbnkgUk8g YXBpIGNhbGxzIG5vciB1c2VyIHJlZGlyZWN0cy4gRm9yIFJPIHJlc3BvbnNpYmlsaXRpZXMsIHlv dSBjYW4gcHJlc2VudCB0aGUgdXNlciB3aXRoIGEgYnV0dG9uICJHcmFudCBSTyBhY2Nlc3MgdG8g QXp1cmUgcmVzb3VyY2VzIiBidXR0b24gYW5kIHRoZSB1c2VyIHdpbGwgZ28gdGhyb3VnaCBhIHBl cm1pc3Npb24gc2NvcGUgZWxldmF0aW9uIGZsb3csIGFnYWluIG5vIHJlYXNvbiB0byBuZWVkIGEg QkZGIGhlcmUuDQoNCldlIGRpZCBjb25zaWRlciBhZGRpbmcgc29tZXRoaW5nIHRvIHRoYXQgZWZm ZWN0LCBhbiBlcnJvciBtZXNzYWdlIHRoYXQgY2FuIGRpcmVjdCB0aGUgZnJvbnRlbmQgdG8gcGVy Zm9ybSB0aGUgaW50ZXJhY3RpdmUgcG9ydGlvbiBuZWNlc3NhcnkgZm9yIHRoaXMgdG9wb2xvZ3kg dG8gd29yay4gSXQgd291bGQgYmUgc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIElEUCBpbml0aWF0 ZWQgbG9naW4gaW4gT0lEQywgd2hlcmUgdGhlIGNsaWVudCBvZmZlcnMgYW4gZW5kcG9pbnQgdGhh dCBpcyBndWFyYW50ZWVkIHRvIGluaXRpYXRlIGEgc2lnbiBpbiBmbG93IChoZW5jZSBpbmplY3Qg YWxsIHRoZSBuZWNlc3Nhcnkgbm9uY2VzIGV0YykuIFdlIGRpZG7igJl0IGFkZCBpdCB1cGZyb250 IGFuZCBsZWZ0IGl0IGFzIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIG1vc3RseSBiZWNhdXNlIGl0 4oCZcyBub3QgZWFzeSB0byBtb2RlbCBwcm9wZXJseSBhbmQgYmVmb3JlIG9wZW5pbmcgdGhhdCB3 b3JrIGZyb250IHdlIHdhbnRlZCB0byBzZWUgaG93IHRoZSBpZGVhIHdhcyByZWNlaXZlZC4NCkl0 IG1heSBtYWtlIHNlbnNlIGZvciB0aGUgYXBwIHRvIGhhdmUgYW4gZXJyb3IgbWVzc2FnZSwgb3Ig ZXZlbiBiZXR0ZXIgbWlnaHQgYmUgYSAzMDIgTG9jYXRpb24gaGVhZGVyIGRlcGVuZGluZyBvbiB3 aGF0IHlvdSBhcmUgZG9pbmcuIFRoZXJlIGlzIG5vdGhpbmcgaGVyZSB0aGF0IGlzIE9BdXRoIHNw ZWNpZmljIGhvd2V2ZXIgKG5vciBjb21tb24pLCBhbmQgdGhlbiB3ZSBzaG91bGQgY2hhbGxlbmdl IHRoZSBuZWVkIHRvIGRpcmVjdGx5IHByb3ZpZGUgYW4gUkZDIHJlY29tbWVuZGF0aW9uIGZvciBo YW5kbGluZyB0aGlzLg0KDQoNCkVycm9yISBGaWxlbmFtZSBub3Qgc3BlY2lmaWVkLg0KDQpXYXJy ZW4gUGFyYWQNCg0KRm91bmRlciwgQ1RPDQpTZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBs ZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCBBdXRocmVzczxo dHRwczovL2F1dGhyZXNzLmlvPi4NCg0KDQpPbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCAxMjoyOSBQ TSBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpIaSBO ZWlsLA0KVGhhbmtzIGZvciB0aGUgcHJvbXB0IGNvbW1lbnRzIQ0KDQogICogICBSZTogR0VUIHZz IFBPU1QsDQpwZXJzb25hbGx5IEnigJlkIGJlIGZpbmUgd2l0aCByZXN0cmljdGluZyB0byBQT1NU Lg0KDQoNCiAgKiAgIFJlOiBSTy1BUywgaW50ZXJhY3Rpb24tDQpwZXJoYXBzIGl0IGlzIG5vdCB2 ZXJ5IGNsZWFyIGZyb20gdGhlIHRleHQgYXQgdGhlIG1vbWVudCAoZmlyc3QgZHJhZnQpLCBidXQg dGhhdCBpcyBhc3N1bWVkIHRoYXQgdGhlIFJPIHdlbnQgdGhydSB3aGF0ZXZlciBpbnRlcmFjdGl2 ZSBzdGVwcyBhcmUgbmVjZXNzYXJ5IHRvIGVzdGFibGlzaCBhIHNlc3Npb24gKGVnIHNpZ24gaW4s IGFzc3VtaW5nIHRoZSBBUyBpcyBzYXkgYW4gT0lEQyBwcm92aWRlcikgYW5kIG9idGFpbiBiZWZv cmVoYW5kIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW5zIHRoYXQgd2lsbCBiZSBu ZWVkZWQgZHVyaW5nIHRoZSBhcHAgYWN0aXZpdGllcyB0YWtpbmcgcGxhY2UgYWZ0ZXIgIHRoYXQu IEluIGNvbmNyZXRlIHRlcm1zLCBpbWFnaW5lIHRoYXQgdGhlIGJhY2tlbmQgcGVyZm9ybXMgYW4g YXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHJlcXVlc3RpbmcgYW4gSUR0b2tlbiwgYWNjZXNzIHRv a2VuIGFuZCByZWZyZXNoIHRva2VuIEJFRk9SRSB0aGUgYWN0aXZpdGllcyBkZXNjcmliZWQgaW4g VE1JLUJGRiB0YWtlIHBsYWNlLg0KVGhlIGN1cnJlbnQgbGFuZ3VhZ2UgdHJ5aW5nIHRvIGV4cHJl c3MgdGhhdCBpcyBpbiAxLjI6DQpBcyBhIHByZXJlcXVpc2l0ZSBmb3IgdGhlIGZsb3cgZGVzY3Jp YmVkIGJlbG93LCB0aGUgYmFja2VuZCBNVVNUIGhhdmUgZXN0YWJsaXNoZWQgYSBzZWN1cmUgc2Vz c2lvbiB3aXRoIHRoZSB1c2VyIGFnZW50LCBzbyB0aGF0IGFsbCByZXF1ZXN0cyBmcm9tIHRoYXQg dXNlciBhZ2VudCB0b3dhcmQgdGhlIGJhY2tlbmQgb2NjdXIgb3ZlciBIVFRQUyBhbmQgY2Fycnkg YSB2YWxpZCBzZXNzaW9uIGFydGlmYWN0IChzdWNoIGFzIGEgY29va2llKSB0aGF0IHRoZSBiYWNr ZW5kIGNhbiB2YWxpZGF0ZS4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBtYW5kYXRlIGFueSBzcGVj aWZpYyBtZWNoYW5pc20gdG8gZXN0YWJsaXNoIGFuZCBtYWludGFpbiB0aGF0IHNlc3Npb24uDQpB bmQNCmNhY2hlZCwgaXQgcmVxdWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGEgbmV3 IGFjY2VzcyB0b2tlbiB3aXRoIHRoZSByZXF1aXJlZCBjaGFyYWN0ZXJpc3RpY3MsIHVzaW5nIGFu eSBhcnRpZmFjdHMgcHJldmlvdXN5IG9idGFpbmVkIChlZyByZWZyZXNoIHRva2VuKSBhbmQgZ3Jh bnRzIHRoYXQgd2lsbCBhbGxvdyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gaXNzdWUgdGhl IHJlcXVlc3RlZCB0b2tlbiB3aXRob3V0IHJlcXVpcmluZyB1c2VyIGludGVyYWN0aW9uLg0KDQoN CiAgKiAgICBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVu IGNvdWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlz c3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3Ig QVBJIGFjY2Vzcz8NCkZvciB0aGUgdHJ1c3RlZCBwYXJ0LCBzZWUgYWJvdmUuIEZvciB0aGUgc2hv cnQgbGl2ZWQgSldUcywgdGhhdOKAmXMgbm90IHJlYWxseSBhbiBvcHRpb24uIFRoZSBtb3N0IGdl bmVyaWMgc2NlbmFyaW8gYWRkcmVzc2VkIGhlcmUgaXMgZm9yIEFQSXMgdGhhdCBhY2NlcHQgdG9r ZW5zIGlzc3VlZCBieSB0aGUgQVM7IHRoZSBiYWNrZW5kIGNhbiByZXF1ZXN0IHRoZW0gYXMgYSBj bGllbnQsIGJ1dCBpdCBjYW5ub3QgbWludCB0aGVtLiBJbWFnaW5lIHdl4oCZcmUgdGFsa2luZyBh Ym91dCBhIFNQQSBhcHBsaWNhdGlvbiB0aGF0IHNpZ25zIGluIHVzZXJzIHVzaW5nIEF6dXJlIEFE LCBhbmQgbmVlZHMgdG8gY2FsbCBPZmZpY2UgYW5kIEF6dXJlIEFQSXMuIFRoZSBTUEEgYmFja2Vu ZCBjYW5ub3QgaXNzdWUgdG9rZW5zIGZvciB0aG9zZSBBUElzLCBpdCBjYW4gb25seSByZXF1ZXN0 IHRoZW0gdG8gdGhlIEF6dXJlIEFEIEFTLg0KDQoNCiAgKiAgIElmIHlvdSB3YW50IHRvIGFsbG93 IGF1dGggY29kZSBmbG93IGV0YyB0aGVuIHBlcmhhcHMgdGhlIGJmZi10b2tlbiBlbmRwb2ludCBj YW4gcmV0dXJuIGEgc3RhbmRhcmQgZXJyb3IgY29kZSB3aXRoIGFuIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgVVJJIHRoYXQgdGhlIFNQQSB0aGVuIG5hdmlnYXRlcyB0aGUgdXNlciB0by4gKEVnIHRo ZSBiYWNrZW5kIGNhbiBkbyBhIFBBUiByZXF1ZXN0IGZpcnN0IGFuZCByZXR1cm4gYSBVUkkgdGhh dCByZWZlcmVuY2VzIHRoYXQgc28gdGhhdCBhdXRob3JpemF0aW9uIGRldGFpbHMgYXJlbuKAmXQg cGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5kKS4NCldlIGRpZCBjb25zaWRlciBhZGRpbmcgc29t ZXRoaW5nIHRvIHRoYXQgZWZmZWN0LCBhbiBlcnJvciBtZXNzYWdlIHRoYXQgY2FuIGRpcmVjdCB0 aGUgZnJvbnRlbmQgdG8gcGVyZm9ybSB0aGUgaW50ZXJhY3RpdmUgcG9ydGlvbiBuZWNlc3Nhcnkg Zm9yIHRoaXMgdG9wb2xvZ3kgdG8gd29yay4gSXQgd291bGQgYmUgc29tZXRoaW5nIHNpbWlsYXIg dG8gdGhlIElEUCBpbml0aWF0ZWQgbG9naW4gaW4gT0lEQywgd2hlcmUgdGhlIGNsaWVudCBvZmZl cnMgYW4gZW5kcG9pbnQgdGhhdCBpcyBndWFyYW50ZWVkIHRvIGluaXRpYXRlIGEgc2lnbiBpbiBm bG93IChoZW5jZSBpbmplY3QgYWxsIHRoZSBuZWNlc3Nhcnkgbm9uY2VzIGV0YykuIFdlIGRpZG7i gJl0IGFkZCBpdCB1cGZyb250IGFuZCBsZWZ0IGl0IGFzIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVy IG1vc3RseSBiZWNhdXNlIGl04oCZcyBub3QgZWFzeSB0byBtb2RlbCBwcm9wZXJseSBhbmQgYmVm b3JlIG9wZW5pbmcgdGhhdCB3b3JrIGZyb250IHdlIHdhbnRlZCB0byBzZWUgaG93IHRoZSBpZGVh IHdhcyByZWNlaXZlZC4NCg0KRnJvbTogT0F1dGggPG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTmVpbCBNYWRkZW4gPG5l aWwubWFkZGVuQGZvcmdlcm9jay5jb208bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+ Pg0KRGF0ZTogU3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwMDoxNw0KVG86IFZpdHRvcmlv IEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lv biBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KSSBoYXZlIGEg bG90IG9mIHNlY3VyaXR5IGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQuDQoNClRoZSBkcmFmdCBh bGx1ZGVzIHRvIHNlY3VyaXR5IGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggaGFuZGxpbmcgYWNjZXNz IHRva2VucyBpbiB0aGUgZnJvbnRlbmQgYnV0IG5ldmVyIHJlYWxseSBzcGVsbHMgdGhlbSBvdXQu IEZyb20gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGl0IHNlZW1zIHRoYXQgdGhlIHByaW1h cnkgY29uY2VybiBpcyB3aXRoIHRoZWZ0IG9mIGFjY2VzcyB0b2tlbnMgZnJvbSBsb2NhbCBzdG9y YWdlLiBUbyBkbyB0aGlzIHlvdeKAmWQgbmVlZCBhbiBYU1MgYXR0YWNrLiBCdXQgaW4gdGhhdCBj YXNlLCB3b3VsZG7igJl0IHRoZSBhdHRhY2tlciBzaW1wbHkgdXNlIHRoZSBYU1MgdG8gbWFrZSBh IGNhbGwgdG8gdGhlIGJmZi10b2tlbiBlbmRwb2ludCBpbnN0ZWFkPw0KDQpUaGUgY29tYmluYXRp b24gb2YgdGhlIGJmZi10b2tlbiBlbmRwb2ludCByZWNvbW1lbmRpbmcgdGhlIHVzZSBvZiBHRVQg cmVxdWVzdHMgdG9nZXRoZXIgd2l0aCB0aGUgaGludCB0byB1c2UgY29va2llLWJhc2VkIGF1dGhl bnRpY2F0aW9uIGlzIGxpa2VseSBnb2luZyB0byBwdW5jaCBhIGhvbGUgaW4gbW9zdCBDU1JGIGRl ZmVuc2VzLCB3aGljaCBhc3N1bWUgdGhhdCBHRVRzIGFyZSBzYWZlLiBUaGUgb25seSB0aGluZyBw cmV2ZW50aW5nIHRoaXMgYmVpbmcgZXhwbG9pdGFibGUgaXMgQ3Jvc3MtT3JpZ2luIFJlYWQgQmxv Y2tpbmcgKGh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9t YXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19vcmlnaW5fcmVhZF9ibG9ja2luZ19leHBsYWlu ZXIubWQpIGR1ZSB0byB0aGUgSlNPTiBjb250ZW50LXR5cGUuIFRoYXQgbWFrZXMgbWUgcmVhbGx5 IG5lcnZvdXMuIFdlIHNob3VsZCBhdCBsZWFzdCBtYW5kYXRlIFgtQ29udGVudC1UeXBlLU9wdGlv bnM6IG5vc25pZmYgb24gdGhhdCByZXNwb25zZS4gSeKAmWQgZmVlbCBtb3JlIGNvbWZvcnRhYmxl IGlmIHRoaXMgd2FzIGEgUE9TVCByZXF1ZXN0IG9ubHkuDQoNCkFzIFN0b3ljaG8gU2xlcHRzb3Yg bWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwgdGhlIGxhY2sgb2YgZnJvbnQtY2hhbm5lbCBj b21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0aGUgUk8gc2VlbXMgb2RkLiBJZiB0aGUg YmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVuIGNvdWxkbuKAmXQgeW91 IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlzc3VlIHNob3J0LWxpdmVk IEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3IgQVBJIGFjY2Vzcz8NCg0K SWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cgZXRjIHRoZW4gcGVyaGFwcyB0aGUg YmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFuZGFyZCBlcnJvciBjb2RlIHdpdGgg YW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0aGUgU1BBIHRoZW4gbmF2aWdhdGVz IHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRvIGEgUEFSIHJlcXVlc3QgZmlyc3Qg YW5kIHJldHVybiBhIFVSSSB0aGF0IHJlZmVyZW5jZXMgdGhhdCBzbyB0aGF0IGF1dGhvcml6YXRp b24gZGV0YWlscyBhcmVu4oCZdCBwYXNzZWQgdGhyb3VnaCB0aGUgZnJvbnRlbmQpLg0KDQrigJQg TmVpbA0KDQoNCk9uIDEyIEZlYiAyMDIxLCBhdCAyMDo0NiwgVml0dG9yaW8gQmVydG9jY2kgPHZp dHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGF1dGgw LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K77u/RGVhciBhbGwsDQpCcmlhbiBhbmQgeW91 cnMgdHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVjaWZpY2F0aW9uIHRoYXQgc2hvd3MgaG93 IHRoZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2ViIGFwcCBjYW4gZGVsZWdhdGUgdG9rZW4g YWNxdWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0cyBiYWNrZW5kLCBhbmQgcmVxdWVzdCBz dWNoIHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0IGFjY2VzcyBvZiBwcm90ZWN0ZWQgcmVz b3VyY2VzIGZyb20gdGhlIGZyb250ZW5kIGNvZGUuDQoNClRoZSBwYXR0ZXJuIGlzIGFscmVhZHkg aW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVu dCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFudHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVu IGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRlcm0gQkZGIChiYWNrZW5kIGZvciBmcm9u dGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQgaW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFj dGl2aXR5LCBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gdGhl IHJlYWRlci4NCldlIGJlbGlldmUgdGhlIHBhdHRlcm4gaGFzIG1lcml0LCBhcyBjb3Jyb2JvcmF0 ZWQgYnkgaXRzIGdyb3dpbmcgYWRvcHRpb24uIEJ5IGRlbGVnYXRpbmcgYWNjZXNzIHRva2VuIGFj cXVpc2l0aW9uIHRvIHRoZSBiYWNrZW5kLCB3ZSBhdm9pZCBtYW55IG9mIHRoZSBvZnRlbiBicml0 dGxlIG1vdmluZyBwYXJ0cyAoYW5kIGltcGxpZWQgYXR0YWNrIHN1cmZhY2UpIHJlcXVpcmVkIHRv IGFjcXVpcmUgYWNjZXNzIHRva2VucyBmcm9tIGEgdXNlciBhZ2VudC4gVGhlIHRvcG9sb2d5IGFs c28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhlIG5lZWQgb2YgcGVyc2lzdGluZyB0b2tl bnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3duIHNvcmUgcG9pbnQgb2YgdXNpbmcgT0F1 dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVseWluZyBvbiBpdHMgYmFja2VuZCBzdG9y YWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vucy4NCg0KQWx0aG91Z2ggdGhlIHNwZWNp ZmljYXRpb24gaXMgdmVyeSBzaW1wbGUsIHByb3ZpZGluZyBleHBsaWNpdCBndWlkYW5jZSBvbiB0 aGUgc2NlbmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50YWdlcy4NCi0gSXQgbWFrZXMgaXQgcG9zc2li bGUgdG8gY3JlYXRlIGludGVyb3BlcmFibGUgU0RLcywgd2hlcmUgZnJvbnRlbmQgZGV2IHN0YWNr cyAoYW55IEpTIGZsYXZvcikgY2FuIGJlIG1peGVkIGFuZCBtYXRjaGVkIHdpdGggY29tcGxpYW50 IGJhY2tlbmQgc3RhY2tzIChtaWRkbGV3YXJlcyBpbiBub2RlLCBqYXZhLCBBU1AuTkVUPGh0dHA6 Ly9BU1AuTkVUPiwgUEhQIGV0YykNCi0gSXQgYWxsb3dzIHVzIHRvIHByb3ZpZGUgZ3VpZGFuY2Ug b24gaG93IHRvIHByb3Blcmx5IHRhY2tsZSB0aGUgc2NlbmFyaW8gYW5kIHdhcm4gaW1wbGVtZW50 ZXJzIGFnYWluc3Qgc2VjdXJpdHkgcmlza3MgKHNjb3BlIGVzY2FsYXRpb25zLCB1c2luZyBJRHRv a2VucyBpbnN0ZWFkIG9mIGFjY2VzcyB0b2tlbnMsIGV0YykNCi0gSXQgYWxsb3dzIHVzIHRvIGRp c2N1c3MgKGFuZCB3aGVuIGFwcHJvcHJpYXRlLCBwcm9tb3RlKSB0aGlzIHBhdHRlcm4gYXMgcGFy dCBvZiB0aGUgYnJvd3NlciBhcHBzIHNlY3VyaXR5IGd1aWRhbmNlLCBhbmQgcG9zaXRpb24gdGhl IHNjZW5hcmlvIHdoZXJlIGZyb250ZW5kIG9ubHkgY2FsbHMgQVBJIG9uIGl0cyBvd24gYmFja2Vk IChoZW5jZSBkb2VzbuKAmXQgbmVlZCBhY2Nlc3MgdG9rZW5zKSBzaW1wbHkgYXMgYSBzcGVjaWFs IGNhc2Ugb2YgdGhpcyBtb3JlIGdlbmVyYWwgcGF0dGVybg0KLSBUaGlzIGFwcHJvYWNoIG1ha2Vz IG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5IGVhc3ksIHBvc3NpYmx5IHByZXZlbnRpbmcg ZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUgc2VjdXJpdHkgb2YgdGhlaXIgc3lzdGVtIChl ZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykgIG9yIHR1cm5pbmcgdG8gcmlza3kgcHJhY3RpY2Vz IGxpa2Ugc2NyYXBpbmcNCg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlzIHNwZWNpZmljYXRpb24gZG9l c27igJl0IGVudGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gZGlyZWN0IHVz ZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gYSBicm93c2VyLiBCdXQgcmVhbGl0eSBpcyB0aGF0IHRo ZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhlIGNpcmN1bXN0YW5jZXMgbGVh ZGluZyB0byB0aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEgcGFydGljdWxhciBwcm9qZWN0IG9ubHkg d29yayB3aXRoIGZyb250ZW5kIHN0YWNrczsgY29tcG9uZW50cyBsaWtlIHJldmVyc2UgcHJveGll cyBtaWdodCBub3QgYWx3YXlzIGJlIHZpYWJsZTsgZXRjKSBhcmVu4oCZdCBnb2luZyBhd2F5IGFu eSB0aW1lIHNvb24uIEJ5IHByb3ZpZGluZyBzaW1wbGUgZ3VpZGFuY2Ugb24gdGhpcyBwYXR0ZXJu LCB3ZSBjYW4gc2ltcGxpZnkgdGhlIGxpZmUgb2YgbWFueSBkZXZlbG9wZXJzIHdoaWxlIGVuc2hy aW5pbmcgYmFzaWMgc2VjdXJpdHkgaHlnaWVuZSBpbiBzY2VuYXJpb3MgdGhhdCB3b3VsZCBoYXZl IG90aGVyd2lzZSBiZSBsZWZ0IHRvIHRoZWlyIG93biBkZXZpY2UuDQoNCkxvb2tpbmcgZm9yd2Fy ZCBmb3IgeW91ciBmZWVkYmFjayENCg0KQiZWDQoNCu+7v09uIDIvMTIvMjEsIDEyOjQxLCAiaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IiA8 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ PiB3cm90ZToNCg0KDQogICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVydG9jY2ktb2F1 dGgyLXRtaS1iZmYtMDAudHh0DQogICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFZpdHRvcmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlDQogICBJRVRGIHJlcG9zaXRvcnku DQoNCiAgIE5hbWU6ICAgICAgICBkcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZg0KICAgUmV2 aXNpb246ICAgIDAwDQogICBUaXRsZTogICAgICAgIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lv biBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZA0KICAgRG9jdW1lbnQgZGF0ZTogICAg MjAyMS0wMi0xMg0KICAgR3JvdXA6ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgIFBh Z2VzOiAgICAgICAgMTYNCiAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dA0KICAgU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2Np LW9hdXRoMi10bWktYmZmLw0KICAgSHRtbDogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRtbA0KICAgSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1v YXV0aDItdG1pLWJmZi0wMA0KDQoNCiAgIEFic3RyYWN0Og0KICAgICAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4gZGVsZWdhdGUgYWNjZXNzDQog ICAgICB0b2tlbiBhY3F1aXNpdGlvbiB0byBhIGJhY2tlbmQgY29tcG9uZW50LiAgSW4gc28gZG9p bmcsIHRoZSBmcm9udGVuZA0KICAgICAgY2FuIGFjY2VzcyByZXNvdXJjZSBzZXJ2ZXJzIGRpcmVj dGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBidXJkZW4gb2YNCiAgICAgIGNvbW11bmljYXRpbmcg d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHBlcnNpc3RpbmcgdG9rZW5zLCBhbmQNCiAg ICAgIHBlcmZvcm1pbmcgb3BlcmF0aW9ucyB0aGF0IGFyZSBmcmF1Z2h0IHdpdGggc2VjdXJpdHkg Y2hhbGxlbmdlcyB3aGVuDQogICAgICBleGVjdXRlZCBpbiBhIHVzZXIgYWdlbnQsIGJ1dCBhcmUg c2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZA0KICAgICAgYnkgYSBjb25maWRlbnRp YWwgY2xpZW50IHJ1bm5pbmcgb24gYSBiYWNrZW5kLg0KDQoNCg0KDQogICBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQogICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCiAgIFRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCkZvcmdlUm9jayB2YWx1ZXMgeW91ciBQcml2YWN5PGh0dHBzOi8vd3d3LmZvcmdlcm9j ay5jb20veW91ci1wcml2YWN5Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0K --_000_CO6PR18MB4052378AF13E3AAA9743DA0AAE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik5vdG8gU2Fu cyI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCA1IDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnAuZ21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1bXNvbGlzdHBhcmFncmFwaCwg bGkuZ21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWls LW0tODk2ODcwNTYzNDk4NjQ4MzA2NW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtbV8tODk2ODcwNTYzNDk4NjQ4MzA2NW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmdtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2 NWdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0t ODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJh Z3JhcGgsIGRpdi5nbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0 NDM5OTc5NDltc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTg5Njg3 MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdyYXBo Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5nbWFpbC1tLTg5 Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDlhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tODk2ODcwNTYzNDk4NjQ4MzA2NWdt YWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OWFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVt YWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc3NDk4 MzM2MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1OTU1MzU3Nzg7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoxNjc5NTAwMTg0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MjA4MDUwMzYwMDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE4NzE5MjAxNDg7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjcwNTE2ODAzMDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJ e21zby1saXN0LWlkOjE4Nzk3NzQzNzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODI2ODE2 ODEyO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MjAwMjAwMjMwMzsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTE3Nzg4NDc2MTQ7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SVRQLCBmb3IgZXhhbXBsZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+V2FycmVuIFBhcmFkICZsdDt3cGFy YWQ9NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRh eSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMDQ6NTQ8YnI+DQo8Yj5UbzogPC9iPlZpdHRvcmlvIEJl cnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj5OZWlsIE1hZGRlbiAmbHQ7bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSZndDssICZxdW90O29h dXRoQGlldGYub3JnJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0 aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5 b3UgZXhwYW5kIG9uIHdoYXQgc2lsZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBzZXNzaW9uIHRva2Vu IHN0YW5kcyBmb3IgaGVyZT8gSWYgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIGlmcmFtZSBzY2Vu YXJpbywgdGhlIG5ldyBicm93c2VyIG1lYXN1cmVzIG1ha2UgaXQgcHJvYmxlbWF0aWMuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hp Y2ggbmV3IGJyb3dzZXIgbWVhc3VyZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNl OmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxl PSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUg d2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+PGltZyB3aWR0aD0iMTk5IiBoZWlnaHQ9IjM0 IiBzdHlsZT0id2lkdGg6Mi4wNzI5aW47aGVpZ2h0Oi4zNTQxaW4iIGlkPSJfeDAwMDBfaTEwMjUi IGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIiBkYXRhLW91dGxvb2stdHJhY2U9IkY6MHxU OjEiIHNyYz0iY2lkOn5XUkQwMDAuanBnIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7 Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93 OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVy OnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1ib3R0b206bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Ym9yZGVy Om5vbmU7cGFkZGluZzowaW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5XYXJyZW4gUGFyYWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVy OnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Ym9yZGVyOm5v bmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZvdW5kZXIsIENUTzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndoaXRl Ij5TZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBh cmNoaXRlY3R1cmUuIEltcGxlbWVudCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2F1dGhy ZXNzLmlvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkF1 dGhyZXNzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgMTozMyBQTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0 dG9yaW8uYmVydG9jY2k9PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3Jn Ij40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9ImdtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NW1zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpGb3IgVUkgcmVsYXRlZCBmdW5jdGlvbmFs aXR5LCBpLmUuIGRvY3VtZW50IHNlbGVjdGlvbiwgdXNlciBwcm9maWxlIGRpc3BsYXkvY2hhbmdl cywgY29udGFjdCB1cGRhdGVzLCBldGMuLi4gWW91IHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUg dGhlIGNsaWVudCBzaWRlDQo8Yj5zaWxlbnQgYXV0aGVudGljYXRpb248L2I+Jm5ic3A7dXNpbmcg dGhlIHByb3ZpZGVkIHNlc3Npb24gdG9rZW4gZnJvbSB0aGUgQXp1cmUgQUQgQVMsIHdpdGhvdXQg bmVlZGluZyB0byBtYWtlIGFueSBSTyBhcGkgY2FsbHMgbm9yIHVzZXIgcmVkaXJlY3RzLiZuYnNw OzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DYW4geW91IGV4 cGFuZCBvbiB3aGF0IHNpbGVudCBhdXRoZW50aWNhdGlvbiBhbmQgc2Vzc2lvbiB0b2tlbiBzdGFu ZHMgZm9yIGhlcmU/IElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBpZnJhbWUgc2NlbmFyaW8s IHRoZSBuZXcgYnJvd3NlciBtZWFzdXJlcyBtYWtlIGl0IHByb2JsZW1hdGljLiBJbiBjb2RlK1BL Q0UNCiB5b3UgY2FuIHVzZSBhIHJlZnJlc2ggdG9rZW4sIGJ1dCBzZWUgdGhlIG90aGVyIHJlcGx5 IGZvciBob3cgdGhpcyBwcm9wb3NhbCBpcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGF0IGluIHNvbWUg c2l0dWF0aW9ucy4gVGhpcyBhbnN3ZXIgd2FzIHNwZWNpZmljYWxseSBvbiB3aHkgaGF2aW5nIGJh Y2tlbmQtaXNzdWVkIHRva2VucyBkaWRu4oCZdCBhcHBseSB0byB0aGlzIHNjZW5hcmlvLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+V2FycmVuIFBhcmFkICZsdDt3cGFyYWQ9 PGEgaHJlZj0ibWFpbHRvOjQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5T dW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAzOjQ4PGJyPg0KPGI+VG86IDwvYj5WaXR0b3Jp byBCZXJ0b2NjaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6IDwvYj5OZWlsIE1hZGRlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVu QGZvcmdlcm9jay5jb20iIHRhcmdldD0iX2JsYW5rIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24g SW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgdGhlIHRydXN0 ZWQgcGFydCwgc2VlIGFib3ZlLiBGb3IgdGhlIHNob3J0IGxpdmVkIEpXVHMsIHRoYXTigJlzIG5v dCByZWFsbHkgYW4gb3B0aW9uLiBUaGUgbW9zdCBnZW5lcmljIHNjZW5hcmlvIGFkZHJlc3NlZCBo ZXJlIGlzIGZvciBBUElzIHRoYXQgYWNjZXB0IHRva2VucyBpc3N1ZWQgYnkgdGhlIEFTOw0KIHRo ZSBiYWNrZW5kIGNhbiByZXF1ZXN0IHRoZW0gYXMgYSBjbGllbnQsIGJ1dCBpdCBjYW5ub3QgbWlu dCB0aGVtLiBJbWFnaW5lIHdl4oCZcmUgdGFsa2luZyBhYm91dCBhIFNQQSBhcHBsaWNhdGlvbiB0 aGF0IHNpZ25zIGluIHVzZXJzIHVzaW5nIEF6dXJlIEFELCBhbmQgbmVlZHMgdG8gY2FsbCBPZmZp Y2UgYW5kIEF6dXJlIEFQSXMuIFRoZSBTUEEgYmFja2VuZCBjYW5ub3QgaXNzdWUgdG9rZW5zIGZv ciB0aG9zZSBBUElzLCBpdCBjYW4gb25seSByZXF1ZXN0DQogdGhlbSB0byB0aGUgQXp1cmUgQUQg QVMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Rm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBkb2N1bWVudCBz ZWxlY3Rpb24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNvbnRhY3QgdXBkYXRlcywg ZXRjLi4uIFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBjbGllbnQgc2lkZQ0KPGI+ c2lsZW50IGF1dGhlbnRpY2F0aW9uPC9iPiZuYnNwO3VzaW5nIHRoZSBwcm92aWRlZCBzZXNzaW9u IHRva2VuIGZyb20gdGhlIEF6dXJlIEFEIEFTLCB3aXRob3V0IG5lZWRpbmcgdG8gbWFrZSBhbnkg Uk8gYXBpIGNhbGxzIG5vciB1c2VyIHJlZGlyZWN0cy4mbmJzcDtGb3IgUk8gcmVzcG9uc2liaWxp dGllcywgeW91IGNhbiBwcmVzZW50IHRoZSB1c2VyIHdpdGggYSBidXR0b24gJnF1b3Q7R3JhbnQg Uk8gYWNjZXNzIHRvIEF6dXJlIHJlc291cmNlcyZxdW90OyBidXR0b24gYW5kDQogdGhlIHVzZXIg d2lsbCBnbyB0aHJvdWdoJm5ic3A7YSBwZXJtaXNzaW9uIHNjb3BlIGVsZXZhdGlvbiBmbG93LCBh Z2FpbiBubyByZWFzb24gdG8gbmVlZCBhIEJGRiBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPldlIGRpZCBjb25zaWRlciBhZGRpbmcgc29tZXRoaW5nIHRv IHRoYXQgZWZmZWN0LCBhbiBlcnJvciBtZXNzYWdlIHRoYXQgY2FuIGRpcmVjdCB0aGUgZnJvbnRl bmQgdG8gcGVyZm9ybSB0aGUgaW50ZXJhY3RpdmUgcG9ydGlvbiBuZWNlc3NhcnkgZm9yIHRoaXMg dG9wb2xvZ3kgdG8gd29yay4gSXQgd291bGQgYmUNCiBzb21ldGhpbmcgc2ltaWxhciB0byB0aGUg SURQIGluaXRpYXRlZCBsb2dpbiBpbiBPSURDLCB3aGVyZSB0aGUgY2xpZW50IG9mZmVycyBhbiBl bmRwb2ludCB0aGF0IGlzIGd1YXJhbnRlZWQgdG8gaW5pdGlhdGUgYSBzaWduIGluIGZsb3cgKGhl bmNlIGluamVjdCBhbGwgdGhlIG5lY2Vzc2FyeSBub25jZXMgZXRjKS4gV2UgZGlkbuKAmXQgYWRk IGl0IHVwZnJvbnQgYW5kIGxlZnQgaXQgYXMgZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgbW9zdGx5 IGJlY2F1c2UNCiBpdOKAmXMgbm90IGVhc3kgdG8gbW9kZWwgcHJvcGVybHkgYW5kIGJlZm9yZSBv cGVuaW5nIHRoYXQgd29yayBmcm9udCB3ZSB3YW50ZWQgdG8gc2VlIGhvdyB0aGUgaWRlYSB3YXMg cmVjZWl2ZWQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBtYXkgbWFrZSBzZW5zZSBmb3IgdGhlIGFwcCB0 byBoYXZlIGFuIGVycm9yIG1lc3NhZ2UsIG9yIGV2ZW4gYmV0dGVyIG1pZ2h0IGJlIGEgMzAyDQo8 Yj5Mb2NhdGlvbiBoZWFkZXI8L2I+Jm5ic3A7ZGVwZW5kaW5nIG9uIHdoYXQgeW91IGFyZSBkb2lu Zy4gVGhlcmUgaXMgbm90aGluZyBoZXJlIHRoYXQgaXMgT0F1dGggc3BlY2lmaWMgaG93ZXZlciAo bm9yIGNvbW1vbiksIGFuZCB0aGVuIHdlIHNob3VsZCBjaGFsbGVuZ2UgdGhlIG5lZWQgdG8gZGly ZWN0bHkgcHJvdmlkZSBhbiBSRkMgcmVjb21tZW5kYXRpb24gZm9yIGhhbmRsaW5nIHRoaXMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu Zz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXJp Z2h0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtv dmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBpbiI+PGI+RXJyb3IhIEZpbGVuYW1lIG5vdCBzcGVjaWZpZWQuPC9iPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpz b2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItbGVmdDpub25lO3BhZGRpbmc6NS4wcHQgNS4wcHQgNS4w cHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0 ZSAxLjBwdDtib3JkZXItYm90dG9tOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAg c3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+V2FycmVuIFBhcmFkPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlk IHdoaXRlIDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PkZvdW5kZXIsIENUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2hpdGUiPlNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQg Y29tcGxldGUgeW91ciBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vYXV0aHJlc3MuaW8iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QXV0aHJlc3M8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEZlYiAxNCwgMjAyMSBh dCAxMjoyOSBQTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9PGEgaHJl Zj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBh dXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgTmVpbCw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB0aGUgcHJvbXB0IGNvbW1lbnRz ITxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTg5 Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdy YXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KUmU6IEdFVCB2cyBQT1NULDxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4y NWluIj4NCnBlcnNvbmFsbHkgSeKAmWQgYmUgZmluZSB3aXRoIHJlc3RyaWN0aW5nIHRvIFBPU1Qu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjI1aW4i Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Imdt YWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xp c3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQpSZTogUk8tQVMs IGludGVyYWN0aW9uLSA8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+cGVyaGFwcyBpdCBpcyBub3QgdmVyeSBjbGVhciBmcm9tIHRoZSB0ZXh0IGF0IHRoZSBtb21l bnQgKGZpcnN0IGRyYWZ0KSwgYnV0IHRoYXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBSTyB3ZW50IHRo cnUgd2hhdGV2ZXIgaW50ZXJhY3RpdmUgc3RlcHMgYXJlIG5lY2Vzc2FyeSB0byBlc3RhYmxpc2gg YSBzZXNzaW9uDQogKGVnIHNpZ24gaW4sIGFzc3VtaW5nIHRoZSBBUyBpcyBzYXkgYW4gT0lEQyBw cm92aWRlcikgYW5kIG9idGFpbiBiZWZvcmVoYW5kIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJl c2ggdG9rZW5zIHRoYXQgd2lsbCBiZSBuZWVkZWQgZHVyaW5nIHRoZSBhcHAgYWN0aXZpdGllcyB0 YWtpbmcgcGxhY2UgYWZ0ZXIgJm5ic3A7dGhhdC4gSW4gY29uY3JldGUgdGVybXMsIGltYWdpbmUg dGhhdCB0aGUgYmFja2VuZCBwZXJmb3JtcyBhbiBhdXRob3JpemF0aW9uIGNvZGUNCiBncmFudCBy ZXF1ZXN0aW5nIGFuIElEdG9rZW4sIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBCRUZP UkUgdGhlIGFjdGl2aXRpZXMgZGVzY3JpYmVkIGluIFRNSS1CRkYgdGFrZSBwbGFjZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGN1cnJlbnQgbGFuZ3VhZ2UgdHJ5 aW5nIHRvIGV4cHJlc3MgdGhhdCBpcyBpbiAxLjI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O05vdG8gU2FucyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3 aGl0ZSI+QXMgYSBwcmVyZXF1aXNpdGUgZm9yIHRoZSBmbG93IGRlc2NyaWJlZCBiZWxvdywgdGhl IGJhY2tlbmQgTVVTVCBoYXZlIGVzdGFibGlzaGVkDQogYSBzZWN1cmUgc2Vzc2lvbiB3aXRoIHRo ZSB1c2VyIGFnZW50LCBzbyB0aGF0IGFsbCByZXF1ZXN0cyBmcm9tIHRoYXQgdXNlciBhZ2VudCB0 b3dhcmQgdGhlIGJhY2tlbmQgb2NjdXIgb3ZlciBIVFRQUyBhbmQgY2FycnkgYSB2YWxpZCBzZXNz aW9uIGFydGlmYWN0IChzdWNoIGFzIGEgY29va2llKSB0aGF0IHRoZSBiYWNrZW5kIGNhbiB2YWxp ZGF0ZS4gVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBtYW5kYXRlIGFueSBzcGVjaWZpYyBtZWNoYW5p c20gdG8NCiBlc3RhYmxpc2ggYW5kIG1haW50YWluIHRoYXQgc2Vzc2lvbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtOb3RvIFNhbnMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tn cm91bmQ6d2hpdGUiPmNhY2hlZCwgaXQgcmVxdWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGEgbmV3IGFjY2VzcyB0b2tlbiB3aXRoIHRoZSByZXF1aXJlZA0KIGNoYXJhY3RlcmlzdGlj cywgdXNpbmcgYW55IGFydGlmYWN0cyBwcmV2aW91c3kgb2J0YWluZWQgKGVnIHJlZnJlc2ggdG9r ZW4pIGFuZCBncmFudHMgdGhhdCB3aWxsIGFsbG93IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0 byBpc3N1ZSB0aGUgcmVxdWVzdGVkIHRva2VuIHdpdGhvdXQgcmVxdWlyaW5nIHVzZXIgaW50ZXJh Y3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS04 OTY4NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYzNTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBsZm80Ij4NCjxzcGFuIGNsYXNzPSJnbWFp bC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDlhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPklmIHRoZSBiYWNrZW5kIGlzIGFscmVhZHkgaW1wbGljaXRs eSB0cnVzdGVkIHRoZW4gY291bGRu4oCZdCB5b3Ugc2tpcCBPQXV0aCBhbmQganVzdCBnZXQgdGhl IGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQNCiBKV1RzIHRvIHRoZSBmcm9udGVuZCB0aGF0 IGl0IGNhbiB1c2UgZm9yIEFQSSBhY2Nlc3M/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkZvciB0aGUgdHJ1c3RlZCBwYXJ0LCBzZWUgYWJvdmUuIEZvciB0aGUg c2hvcnQgbGl2ZWQgSldUcywgdGhhdOKAmXMgbm90IHJlYWxseSBhbiBvcHRpb24uIFRoZSBtb3N0 IGdlbmVyaWMgc2NlbmFyaW8gYWRkcmVzc2VkIGhlcmUgaXMgZm9yIEFQSXMgdGhhdCBhY2NlcHQg dG9rZW5zIGlzc3VlZCBieSB0aGUgQVM7DQogdGhlIGJhY2tlbmQgY2FuIHJlcXVlc3QgdGhlbSBh cyBhIGNsaWVudCwgYnV0IGl0IGNhbm5vdCBtaW50IHRoZW0uIEltYWdpbmUgd2XigJlyZSB0YWxr aW5nIGFib3V0IGEgU1BBIGFwcGxpY2F0aW9uIHRoYXQgc2lnbnMgaW4gdXNlcnMgdXNpbmcgQXp1 cmUgQUQsIGFuZCBuZWVkcyB0byBjYWxsIE9mZmljZSBhbmQgQXp1cmUgQVBJcy4gVGhlIFNQQSBi YWNrZW5kIGNhbm5vdCBpc3N1ZSB0b2tlbnMgZm9yIHRob3NlIEFQSXMsIGl0IGNhbiBvbmx5IHJl cXVlc3QNCiB0aGVtIHRvIHRoZSBBenVyZSBBRCBBUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9ImdtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2MzUzNjkyMTQ0 Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvNSI+ DQpJZiB5b3Ugd2FudCB0byBhbGxvdyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRo ZSBiZmYtdG9rZW4gZW5kcG9pbnQgY2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0 aCBhbiBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0 ZXMgdGhlIHVzZXIgdG8uIChFZyB0aGUgYmFja2VuZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJz dCBhbmQgcmV0dXJuIGEgVVJJIHRoYXQgcmVmZXJlbmNlcw0KIHRoYXQgc28gdGhhdCBhdXRob3Jp emF0aW9uIGRldGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5kKS4mbmJz cDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgZGlkIGNv bnNpZGVyIGFkZGluZyBzb21ldGhpbmcgdG8gdGhhdCBlZmZlY3QsIGFuIGVycm9yIG1lc3NhZ2Ug dGhhdCBjYW4gZGlyZWN0IHRoZSBmcm9udGVuZCB0byBwZXJmb3JtIHRoZSBpbnRlcmFjdGl2ZSBw b3J0aW9uIG5lY2Vzc2FyeSBmb3IgdGhpcyB0b3BvbG9neSB0byB3b3JrLiBJdCB3b3VsZCBiZQ0K IHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoZSBJRFAgaW5pdGlhdGVkIGxvZ2luIGluIE9JREMsIHdo ZXJlIHRoZSBjbGllbnQgb2ZmZXJzIGFuIGVuZHBvaW50IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBp bml0aWF0ZSBhIHNpZ24gaW4gZmxvdyAoaGVuY2UgaW5qZWN0IGFsbCB0aGUgbmVjZXNzYXJ5IG5v bmNlcyBldGMpLiBXZSBkaWRu4oCZdCBhZGQgaXQgdXBmcm9udCBhbmQgbGVmdCBpdCBhcyBleGVy Y2lzZSBmb3IgdGhlIHJlYWRlciBtb3N0bHkgYmVjYXVzZQ0KIGl04oCZcyBub3QgZWFzeSB0byBt b2RlbCBwcm9wZXJseSBhbmQgYmVmb3JlIG9wZW5pbmcgdGhhdCB3b3JrIGZyb250IHdlIHdhbnRl ZCB0byBzZWUgaG93IHRoZSBpZGVhIHdhcyByZWNlaXZlZC4gJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk9BdXRoICZsdDs8YSBocmVmPSJtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTmVpbCBNYWRkZW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIiB0YXJnZXQ9Il9ibGFuayI+bmVpbC5tYWRk ZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgRmVicnVh cnkgMTQsIDIwMjEgYXQgMDA6MTc8YnI+DQo8Yj5UbzogPC9iPlZpdHRvcmlvIEJlcnRvY2NpICZs dDt2aXR0b3Jpby5iZXJ0b2NjaT08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBz ZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBhIGxvdCBvZiBzZWN1cml0eSBjb25jZXJucyBh Ym91dCB0aGlzIGRyYWZ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJpdHkgaXNz dWVzIGFzc29jaWF0ZWQgd2l0aCBoYW5kbGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBmcm9udGVu ZCBidXQgbmV2ZXIgcmVhbGx5IHNwZWxscyB0aGVtIG91dC4gRnJvbSB0aGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgaXQgc2VlbXMgdGhhdCB0aGUNCiBwcmltYXJ5IGNvbmNlcm4gaXMgd2l0aCB0 aGVmdCBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gbG9jYWwgc3RvcmFnZS4gVG8gZG8gdGhpcyB5b3Xi gJlkIG5lZWQgYW4gWFNTIGF0dGFjay4gQnV0IGluIHRoYXQgY2FzZSwgd291bGRu4oCZdCB0aGUg YXR0YWNrZXIgc2ltcGx5IHVzZSB0aGUgWFNTIHRvIG1ha2UgYSBjYWxsIHRvIHRoZSBiZmYtdG9r ZW4gZW5kcG9pbnQgaW5zdGVhZD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjb21iaW5hdGlvbiBvZiB0aGUgYmZmLXRv a2VuIGVuZHBvaW50IHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEdFVCByZXF1ZXN0cyB0b2dldGhl ciB3aXRoIHRoZSBoaW50IHRvIHVzZSBjb29raWUtYmFzZWQgYXV0aGVudGljYXRpb24gaXMgbGlr ZWx5IGdvaW5nIHRvIHB1bmNoIGEgaG9sZSBpbiBtb3N0DQogQ1NSRiBkZWZlbnNlcywgd2hpY2gg YXNzdW1lIHRoYXQgR0VUcyBhcmUgc2FmZS4gVGhlIG9ubHkgdGhpbmcgcHJldmVudGluZyB0aGlz IGJlaW5nIGV4cGxvaXRhYmxlIGlzIENyb3NzLU9yaWdpbiBSZWFkIEJsb2NraW5nICg8YSBocmVm PSJodHRwczovL2Nocm9taXVtLmdvb2dsZXNvdXJjZS5jb20vY2hyb21pdW0vc3JjLysvbWFzdGVy L3NlcnZpY2VzL25ldHdvcmsvY3Jvc3Nfb3JpZ2luX3JlYWRfYmxvY2tpbmdfZXhwbGFpbmVyLm1k IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9jaHJvbWl1bS5nb29nbGVzb3VyY2UuY29tL2Nocm9t aXVtL3NyYy8rL21hc3Rlci9zZXJ2aWNlcy9uZXR3b3JrL2Nyb3NzX29yaWdpbl9yZWFkX2Jsb2Nr aW5nX2V4cGxhaW5lci5tZDwvYT4pDQogZHVlIHRvIHRoZSBKU09OIGNvbnRlbnQtdHlwZS4gVGhh dCBtYWtlcyBtZSByZWFsbHkgbmVydm91cy4gV2Ugc2hvdWxkIGF0IGxlYXN0IG1hbmRhdGUgWC1D b250ZW50LVR5cGUtT3B0aW9uczogbm9zbmlmZiBvbiB0aGF0IHJlc3BvbnNlLiBJ4oCZZCBmZWVs IG1vcmUgY29tZm9ydGFibGUgaWYgdGhpcyB3YXMgYSBQT1NUIHJlcXVlc3Qgb25seS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFzIFN0b3ljaG8gU2xlcHRzb3YgbWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwgdGhlIGxh Y2sgb2YgZnJvbnQtY2hhbm5lbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0aGUg Uk8gc2VlbXMgb2RkLiBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3Rl ZCB0aGVuDQogY291bGRu4oCZdCB5b3Ugc2tpcCBPQXV0aCBhbmQganVzdCBnZXQgdGhlIGJhY2tl bmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgSldUcyB0byB0aGUgZnJvbnRlbmQgdGhhdCBpdCBjYW4g dXNlIGZvciBBUEkgYWNjZXNzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cg ZXRjIHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFu ZGFyZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0 aGUgU1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyDQogdG8uIChFZyB0aGUgYmFja2VuZCBjYW4g ZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJIHRoYXQgcmVmZXJlbmNlcyB0 aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7igJl0IHBhc3NlZCB0aHJvdWdo IHRoZSBmcm9udGVuZCkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJQgTmVpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+T24gMTIgRmViIDIwMjEsIGF0IDIwOjQ2LCBWaXR0b3JpbyBCZXJ0b2NjaSAm bHQ7dml0dG9yaW8uYmVydG9jY2k9PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj7vu79EZWFyIGFsbCw8YnI+DQpCcmlhbiBhbmQgeW91cnMg dHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVjaWZpY2F0aW9uIHRoYXQgc2hvd3MgaG93IHRo ZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2ViIGFwcCBjYW4gZGVsZWdhdGUgdG9rZW4gYWNx dWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0cyBiYWNrZW5kLCBhbmQgcmVxdWVzdCBzdWNo IHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0IGFjY2VzcyBvZiBwcm90ZWN0ZWQgcmVzb3Vy Y2VzIGZyb20gdGhlDQogZnJvbnRlbmQgY29kZS48YnI+DQo8YnI+DQpUaGUgcGF0dGVybiBpcyBh bHJlYWR5IGluIHVzZSwgaW4gcHJvcHJpZXRhcnkgZm9ybSwgYnkgdmFyaW91cyBtb2Rlcm4gZGV2 ZWxvcG1lbnQgc3RhY2tzLCBzdWNoIGFzIE5leHQuSlMuIFZhcmlhbnRzIG9mIHRoZSBwYXR0ZXJu LCBvZnRlbiBkaXNjdXNzZWQgdW5kZXIgdGhlIGNhdGNoLWFsbCB0ZXJtIEJGRiAoYmFja2VuZCBm b3IgZnJvbnRlbmQpLCBoYXZlIGJlZW4gb2Z0ZW4gbWVudGlvbmVkIGluIHRoaXMgd29ya2dyb3Vw 4oCZcyBhY3Rpdml0eSwNCiBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9uIGRldGFp bHMgdG8gdGhlIHJlYWRlci48YnI+DQpXZSBiZWxpZXZlIHRoZSBwYXR0ZXJuIGhhcyBtZXJpdCwg YXMgY29ycm9ib3JhdGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9uLiBCeSBkZWxlZ2F0aW5nIGFj Y2VzcyB0b2tlbiBhY3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwgd2UgYXZvaWQgbWFueSBvZiB0 aGUgb2Z0ZW4gYnJpdHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBsaWVkIGF0dGFjayBzdXJmYWNl KSByZXF1aXJlZCB0byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHVzZXIgYWdlbnQuDQog VGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhlIG5lZWQgb2Yg cGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3duIHNvcmUgcG9p bnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVseWluZyBvbiBp dHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vucy48YnI+DQo8 YnI+DQpBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBpcyB2ZXJ5IHNpbXBsZSwgcHJvdmlkaW5n IGV4cGxpY2l0IGd1aWRhbmNlIG9uIHRoZSBzY2VuYXJpbyBvZmZlcnMgbWFueSBhZHZhbnRhZ2Vz LiAmbmJzcDs8YnI+DQotIEl0IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGNyZWF0ZSBpbnRlcm9wZXJh YmxlIFNES3MsIHdoZXJlIGZyb250ZW5kIGRldiBzdGFja3MgKGFueSBKUyBmbGF2b3IpIGNhbiBi ZSBtaXhlZCBhbmQgbWF0Y2hlZCB3aXRoIGNvbXBsaWFudCBiYWNrZW5kIHN0YWNrcyAobWlkZGxl d2FyZXMgaW4gbm9kZSwgamF2YSwNCjxhIGhyZWY9Imh0dHA6Ly9BU1AuTkVUIiB0YXJnZXQ9Il9i bGFuayI+QVNQLk5FVDwvYT4sIFBIUCBldGMpPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8gcHJvdmlk ZSBndWlkYW5jZSBvbiBob3cgdG8gcHJvcGVybHkgdGFja2xlIHRoZSBzY2VuYXJpbyBhbmQgd2Fy biBpbXBsZW1lbnRlcnMgYWdhaW5zdCBzZWN1cml0eSByaXNrcyAoc2NvcGUgZXNjYWxhdGlvbnMs IHVzaW5nIElEdG9rZW5zIGluc3RlYWQgb2YgYWNjZXNzIHRva2VucywgZXRjKTxicj4NCi0gSXQg YWxsb3dzIHVzIHRvIGRpc2N1c3MgKGFuZCB3aGVuIGFwcHJvcHJpYXRlLCBwcm9tb3RlKSB0aGlz IHBhdHRlcm4gYXMgcGFydCBvZiB0aGUgYnJvd3NlciBhcHBzIHNlY3VyaXR5IGd1aWRhbmNlLCBh bmQgcG9zaXRpb24gdGhlIHNjZW5hcmlvIHdoZXJlIGZyb250ZW5kIG9ubHkgY2FsbHMgQVBJIG9u IGl0cyBvd24gYmFja2VkIChoZW5jZSBkb2VzbuKAmXQgbmVlZCBhY2Nlc3MgdG9rZW5zKSBzaW1w bHkgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhpcw0KIG1vcmUgZ2VuZXJhbCBwYXR0ZXJuPGJyPg0K LSBUaGlzIGFwcHJvYWNoIG1ha2VzIG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5IGVhc3ks IHBvc3NpYmx5IHByZXZlbnRpbmcgZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUgc2VjdXJp dHkgb2YgdGhlaXIgc3lzdGVtIChlZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykgJm5ic3A7b3Ig dHVybmluZyB0byByaXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZzxicj4NCjxicj4NCk5lZWRs ZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXNu4oCZdCBlbnRpcmVseSBlbGltaW5h dGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1c2Ugb2YgYWNjZXNzIHRva2VucyBmcm9t IGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0aGUgcGF0dGVybiBpcyBpbiB3aWRlc3By ZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxlYWRpbmcgdG8gdGhhdCAoZWcgZGV2ZWxv cGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdA0KIG9ubHkgd29yayB3aXRoIGZyb250ZW5kIHN0 YWNrczsgY29tcG9uZW50cyBsaWtlIHJldmVyc2UgcHJveGllcyBtaWdodCBub3QgYWx3YXlzIGJl IHZpYWJsZTsgZXRjKSBhcmVu4oCZdCBnb2luZyBhd2F5IGFueSB0aW1lIHNvb24uIEJ5IHByb3Zp ZGluZyBzaW1wbGUgZ3VpZGFuY2Ugb24gdGhpcyBwYXR0ZXJuLCB3ZSBjYW4gc2ltcGxpZnkgdGhl IGxpZmUgb2YgbWFueSBkZXZlbG9wZXJzIHdoaWxlIGVuc2hyaW5pbmcgYmFzaWMgc2VjdXJpdHkg aHlnaWVuZQ0KIGluIHNjZW5hcmlvcyB0aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJlIGxlZnQg dG8gdGhlaXIgb3duIGRldmljZS48YnI+DQo8YnI+DQpMb29raW5nIGZvcndhcmQgZm9yIHlvdXIg ZmVlZGJhY2shPGJyPg0KPGJyPg0KQiZhbXA7ViAmbmJzcDs8YnI+DQo8YnI+DQrvu79PbiAyLzEy LzIxLCAxMjo0MSwgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDtBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVydG9jY2kt b2F1dGgyLXRtaS1iZmYtMDAudHh0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7aGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWaXR0b3JpbyBCZXJ0b2NjaSBhbmQgcG9zdGVkIHRvIHRo ZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0lFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDtOYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1iZXJ0 b2NjaS1vYXV0aDItdG1pLWJmZjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1JldmlzaW9uOiAmbmJz cDsgJm5ic3A7MDA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaXRsZTogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7VG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tl bmQgRm9yIEZyb250ZW5kPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7RG9jdW1lbnQgZGF0ZTogJm5i c3A7ICZuYnNwOzIwMjEtMDItMTI8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtHcm91cDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7UGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzE2PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7VVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9h cmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1 dGgyLXRtaS1iZmYtMDAudHh0PC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1N0YXR1czogJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1i ZmYvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYvPC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0h0 bWw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVy dG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRt bDwvYT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDtIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwPC9hPjxi cj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0Fic3RyYWN0Ojxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBh IEphdmFTY3JpcHQgZnJvbnRlbmQgY2FuIGRlbGVnYXRlIGFjY2Vzczxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Rva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2VuZCBj b21wb25lbnQuJm5ic3A7IEluIHNvIGRvaW5nLCB0aGUgZnJvbnRlbmQ8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjYW4gYWNjZXNzIHJlc291cmNlIHNlcnZlcnMgZGly ZWN0bHkgd2l0aG91dCB0YWtpbmcgb24gdGhlIGJ1cmRlbiBvZjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbW11bmljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIsIHBlcnNpc3RpbmcgdG9rZW5zLCBhbmQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtwZXJmb3JtaW5nIG9wZXJhdGlvbnMgdGhhdCBhcmUgZnJhdWdodCB3 aXRoIHNlY3VyaXR5IGNoYWxsZW5nZXMgd2hlbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2V4ZWN1dGVkIGluIGEgdXNlciBhZ2VudCwgYnV0IGFyZSBzYWZlIGFuZCB3 ZWxsIHByb3ZlbiB3aGVuIGV4ZWN1dGVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7YnkgYSBjb25maWRlbnRpYWwgY2xpZW50IHJ1bm5pbmcgb24gYSBiYWNrZW5kLjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1BsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb248YnI+DQombmJzcDsmbmJzcDsmbmJzcDt1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwO1RoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOiMxNzJC NEQ7YmFja2dyb3VuZDp3aGl0ZSI+Rm9yZ2VSb2NrIHZhbHVlcyB5b3VyDQo8YSBocmVmPSJodHRw czovL3d3dy5mb3JnZXJvY2suY29tL3lvdXItcHJpdmFjeSIgdGFyZ2V0PSJfYmxhbmsiPlByaXZh Y3k8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO6PR18MB4052378AF13E3AAA9743DA0AAE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 11:19:24 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9A33A1164 for ; Sun, 14 Feb 2021 11:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9s9ZO5et-MK for ; Sun, 14 Feb 2021 11:19:20 -0800 (PST) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6623A1162 for ; Sun, 14 Feb 2021 11:19:20 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id fa16so2474215pjb.1 for ; Sun, 14 Feb 2021 11:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=AAmF8mL0o8Ddnet5qmI/TZHVxhuNPZaIWcl/XFibos8=; b=LcDKvGlFZCSsJfALu78dnOCg7qIJUmS5VuPsVMr6PAmL4PcSPd2DtugahQoOLkizM9 ka2ggsa0Mpu1uNOFZJr2doQycP/aQIcN07ZxTxrmW9mIK3tIR4RUFktDUG8fsOJyrTlc pyox8jkAo5b6rbcNMBeWBxqlkGplRdqfIEvabGfwbODt4dBnm42Rb3W8X0woDHZzipdD fFpy5BQZprLqBA+V3YKVaFfVSiD/T9cr95AYQTelRVbvnCNQMx4qbIZePoMByx5zN5Zp wC4YC+/sk79A9Kh5XYWUqPwaTrDQr7dDuNo82f/DYU2cQ9aeZImlnASBCqEprSxwBDxn cIvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=AAmF8mL0o8Ddnet5qmI/TZHVxhuNPZaIWcl/XFibos8=; b=t9fATKROx6oB1cxxsLyuw+2omWaLQfxvJMBcBDudYk/T1SGemS/cM8k1QlQ+QpawaO BXPP0e3OOXfFOwtecvo0AZCMET0wikbPojfYqbJBsOav7qk6D8dQgVbRBCteNoIbXUKi uLFjeNbxHLbgWcvSFcALq9p5nKJxuOxfXy+/1f3RTWfFkVC6rF/2N9iqyDLbzWSqazJs bMeXsr4RmWsnMP2qBmrl7G/vFDumFTgpTe4aM62GfN4P02wdXioemPJiZVUuXCn2s4uP 4WZoMvt2MsoEp0BQgg2fmFqzmdvPqqBUIAwK10nefxt/CkVUlP8b8uUfroal/rZebSrC JHmA== X-Gm-Message-State: AOAM530f0qNtAyabwjZIWx01bAhwE2uDEWKwA0aSsqF9D8R0gD1SIVvN Ez0hMNzdHNUypvb+EMqR745WpQ== X-Google-Smtp-Source: ABdhPJw8umKQiKa/FJZW3uNGYLE5cNASY3+A7PQ5JpVF+b1mMmo/G7ZaSXceLwRZnT6mCh4J9tKdZA== X-Received: by 2002:a17:90a:5d89:: with SMTP id t9mr12490797pji.21.1613330359708; Sun, 14 Feb 2021 11:19:19 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id z16sm15836340pgj.51.2021.02.14.11.19.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 11:19:19 -0800 (PST) From: Vittorio Bertocci To: Torsten Lodderstedt CC: "oauth@ietf.org" , Brian Campbell Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXs6oAgABV6O8= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 19:19:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 19:19:23 -0000 SGkgVG9yc3RlbiwgdGhhbmtzIGZvciBsb29raW5nIGludG8gdGhpcyENClRoZSBpZGVhIGlzIHRo YXQgdGhlIGFwcGxpY2F0aW9uIGJhY2tlbmQgcGVyZm9ybWVkIGFsbCB0aGUgaW50ZXJhY3RpdmUg dG9rZW4gYWNxdWlzaXRpb24gc3RlcHMgYmVmb3JlIFRNSS1CRkYgY29tZSBpbnRvIHBsYXkuDQpJ bWFnaW5lIHRoYXQgYSByZWd1bGFyIHdlYiBhcHAgcGVyZm9ybXMgYW4gYXV0aG9yaXphdGlvbiBj b2RlIGdyYW50LCByZXF1ZXN0aW5nIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiBpbiB0 aGUgcHJvY2VzcyAoYW5kIG9mdGVuIGFsc28gc2V0dGluZyBpdHMgb3duIHNlc3Npb24gd2l0aCB0 aGUgdXNlciBhZ2VudCBpbiB0aGUgcHJvY2VzcywgaWYgdGhlIEFTIGlzIGFsc28gdGhlaXIgSWRQ IHZpYSBPSURDIG9yIHNpbWlsYXIsIGJ1dCB0aGF0J3Mgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSku IE5vdyB0aGUgYXBwIGJhY2tlbmQgaGFzIGFuIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tl biBwZXJzaXN0ZWQgb24gdGhlIHNlcnZlciBzaWRlLg0KQWxsIFRNSS1CRkYgZG9lcyBpcyB0byBk ZXNjcmliZSBob3cgdGhlIGJhY2tlbmQgY2FuIHNoYXJlIHRob3NlIHRva2VucyB3aXRoIGl0cyBm cm9udGVkLCBlaXRoZXIgZGlyZWN0bHkgKGlmIHRoZSBwZXJzaXN0ZWQgQVQgaXMgc3RpbGwgdmFs aWQpIG9yIGluZGlyZWN0bHkgKGlmIGl0IGhhcyB0byB1c2UgYW4gUlQgdG8gb2J0YWluIGEgbmV3 IEFUIGJlZm9yZSBzZW5kaW5nIGl0IGJhY2spLg0KVGhlIGZyb250ZW5kIHByb3ZpZGVzIHJlc291 cmNlIGFuZCBzY29wZSB0byBzZWxlY3Qgd2hhdCB0b2tlbiBpdCBuZWVkcywgYnV0IHRoZSBjdXJy ZW50IGlkZWEgaXMgdGhhdCB0aGUgYmFja2VuZCBhbHJlYWR5IG9idGFpbmVkIGJvdGggY29uc2Vu dCBhbmQgYXJ0aWZhY3RzIHRvIG9idGFpbiB0aG9zZSB0b2tlbnMgZnJvbSB0aGUgQVMuIEFuZCBp ZiBpdCBkb2Vzbid0LCBhdCB0aGUgbW9tZW50IHdlIHNpbXBseSBmYWlsIGFuZCBleHBlY3QgdGhl IGFwcCBkZXZlbG9wZXIgdG8gdGFrZSB0aGUgc3RlcHMgcmVxdWlyZWQgdG8gcHJvbXB0IHRoZSB1 c2VyIHdpdGggd2hhdGV2ZXIgaXMgbmVjZXNzYXJ5IGZvciB1cGRhdGluZyB0aGUgYmFja2VuZCB3 aXRoIHRoZSByaWdodCBwZXJtaXNzaW9ucywgZWcgY3JlYXRpbmcgYSBuZXcgYXV0aG9yaXphdGlv biByZXF1ZXN0IGFza2luZyBmb3IgYSBzY29wZSB0aGUgZnJvbnRlbmQgbmVlZHMgYW5kIHRoYXQg dGhlIHVzZXIgd2Fzbid0IHByb21wdGVkIHRvIGNvbnNlbnQgeWV0LiBBdCB0aGUgbW9tZW50IFRN SS1CRkYgZG9lcyBub3QgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgdGhhdCBwcm9tcHQgdG8gb2Nj dXIsIGl0IGp1c3QgZXJyb3JzIG91dCBzYXlpbmcgInlvdSd2ZSBnb3QgdG8gIHVwZGF0ZSB5b3Vy IGF1dGhvcml6YXRpb24gYXJ0aWZhY3RzIGJlZm9yZSB0aGUgZnJvbnRlbmQgY2FuIGdldCB0aGUg dG9rZW4gdyB0aGUgc2NvcGVzIGl0IG5lZWRzIi4NCkFub3RoZXIgd2F5IHRvIHRoaW5rIGFib3V0 IHRoaXM6IGluIFRNSS1CRkYgdGhlIGZyb250ZW5kIHRyZWF0cyB0aGUgYmFja2VuZCBpcyBhIHRv a2VucyBkYXRhYmFzZS4gSW5kaWNhdGluZyB0aGUgcmVzb3VyY2UgYW5kIHNjb3BlcyBpcyBhIHF1 ZXJ5LiBJZiB0aGUgYmFja2VuZCBjYW4gc2VydmUgdGhhdCBxdWVyeSAod2l0aCB0aGUgQVRzIGl0 IHNhdmVkLCBvciBieSB1c2luZyB0aGUgUlRzIGl0IHNhdmVkIEFORCB0aGUgZ3JhbnRzIHRoZSB1 c2VyIGFscmVhZHkgZ2F2ZSkgaXQgcmV0dXJucyBhIHRva2VuLiBJZiBpdCBkb2Vzbid0LCBpdCBm YWlscyB0aGUgcXVlcnkuIFRoZSBmcm9udGVuZCBkb2VzIG5vdCBwbGF5IGEgZGlyZWN0IHJvbGUg aW50byBpbnNlcnRpbmcgaW4gdGhlIERCIG1vcmUgdG9rZW5zLiBUaGF0IGlzIGxlZnQgdG8gdGhl IGJhY2tlbmQsIHRoYXQgY2FuIGRvIHNvIGJ5IGluaXRpYXRpbmcgYSBuZXcgYXV0aG9yaXphdGlv biBncmFudCwgbm90IGRlc2NyaWJlZCBpbiBUTUktQkZGLCB0aGF0IG11c3QgY29uY2x1ZGUgc3Vj Y2Vzc2Z1bGx5IGZvciB0aGUgZnJvbnRlbmQgdG8gYmUgYWJsZSB0byByZXBlYXQgaXRzIHF1ZXJ5 IGFuZCB0aGlzIHRpbWUgZ2V0IHRoZSB0b2tlbiB0aGV5IHdhbnQgb3V0LiBOb3RlIHRoYXQgdGhl IGJhY2tlbmQgbWlnaHQgZGVjaWRlIHRoYXQgaXQgd29u4oCZdCB0cnkgdG8gZ2V0IHRoZSB0b2tl biByZXF1ZXN0ZWQsIG9yIGl0IG1pZ2h0IHVuYWJsZSB0byBkbyBzbyAoZWcgdGhlIHVzZXIvYXBw IGNhbm5vdCBtZWV0IHNvbWUgcmVxdWlyZW1lbnRzIGFzIHRoZSBBUyBpcyBjb25jZXJuZWQpLCBo ZW5jZSB0aGUgcmVxdWVzdCBvZiBpdCBtaWdodCBhdCB0aW1lcyBiZSBwZXJtYW5lbnRseSBkZW5p ZWQuIFRoaXMgbGFzdCBwYXJ0IGlzIHRvIHNheSB0aGF0IHByb3ZpZGluZyBpbiB0aGUgZXJyb3Ig bWVzc2FnZSBkZXRhaWxzIGFib3V0IHRoZSByZW1lZGlhdGlvbiBtaWdodCB0YWtlIG1vcmUgd29y ayB0aGFuIG9uZSByZWFsaXplcyBhdCBmaXJzdCwgYW5kIHVsdGltYXRlbHkgYWN0aW5nIG9uIHRo ZSBlcnJvciBzaXR1YXRpb24gdG8gcmV0cmlldmUgYSBuZXcgdG9rZW4gaXMgc3RpbGwgdXAgdG8g dGhlIGJhY2tlbmQgYW55d2F5LCBoZW5jZSBwcm92aWRpbmcgZWxhYm9yYXRlIG1hY2hpbmVyeSB0 byBpbmZvcm0gdGhlIGZyb250ZW5kIGJleW9uZCB0aGUgZXJyb3Igc2l0dWF0aW9uIG1pZ2h0IG5v dCBiZSBhcyBlZmZlY3RpdmUgYXMgaXQgbWlnaHQgbG9vayBhdCBmaXJzdCBnbGFuY2UuIEkgYW0g dG90YWxseSBvcGVuIHRvIGl0LCBqdXN0IG1ha2luZyBzdXJlIHdlIHVuZGVyc3RhbmQgd2hhdCBp dCBjYW4gYnV5IHVzLiAgDQoNCu+7v09uIDIvMTQvMjEsIDA2OjExLCAiVG9yc3RlbiBMb2RkZXJz dGVkdCIgPHRvcnN0ZW49NDBsb2RkZXJzdGVkdC5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0K DQogICAgSGksDQogICAgDQogICAgSeKAmW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgeW91ciBwcm9w b3NhbC4gDQogICAgDQogICAgU2VjdGlvbiAxLjIsIGJ1bGxldCAoQikgc3RhdGVzDQogICAgDQog ICAgKEIpIElmIHRoZSBiYWNrZW5kIGRvZXMgbm90IGFscmVhZHkgaGF2ZSBhIHN1aXRhYmxlIGFj Y2VzcyB0b2tlbg0KICAgICAgICAgIG9idGFpbmVkIGluIHByZXZpb3VzIGZsb3dzIGFuZCBjYWNo ZWQsIGl0IHJlcXVlc3RzIHRvIHRoZQ0KICAgICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyIGEg bmV3IGFjY2VzcyB0b2tlbiB3aXRoIHRoZSByZXF1aXJlZA0KICAgICAgICAgIGNoYXJhY3Rlcmlz dGljcywgdXNpbmcgYW55IGFydGlmYWN0cyBwcmV2aW91c3kgb2J0YWluZWQgKGVnDQogICAgICAg ICAgcmVmcmVzaCB0b2tlbikgYW5kIGdyYW50cyB0aGF0IHdpbGwgYWxsb3cgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyDQogICAgICAgICAgdG8gaXNzdWUgdGhlIHJlcXVlc3RlZCB0b2tlbiB3aXRo b3V0IHJlcXVpcmluZyB1c2VyIGludGVyYWN0aW9uLg0KICAgIA0KICAgIENhbiB5b3UgcGxlYXNl IGV4cGxhaW4gaG93IHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3Mgd29ya3MgdG93YXJkcyB0aGUg QVMsIGVzcGVjaWFsbHkgaW4gY2FzZSBvZiB0aGUgYXV0aG9yaXNhdGlvbiBjb2RlIGdyYW50IHR5 cGUuIEkgd291bGQgaGF2ZSBleHBlY3RlZCB0byBmcm9udGVuZCB0byBwYXNzIGFuIGF1dGhvcmlz YXRpb24gY29kZSB0byB0aGUgYmZmLXRva2VuIHJlcXVlc3QuIA0KICAgIA0KICAgIEJ1dCBzZWN0 aW9uIDQuMS4gb25seSBkZWZpbmVzIHRoZSBwYXJhbWV0ZXJzIOKAnnJlc291cmNlIiBhbmQg4oCe c2NvcGUiIGZvciB0aGUgYmZmLXRva2VuIGVuZHBvaW50LiANCiAgICANCiAgICB0aGFua3MsDQog ICAgVG9yc3Rlbi4gDQogICAgDQogICAgPiBBbSAxMi4wMi4yMDIxIHVtIDIxOjQ2IHNjaHJpZWIg Vml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmll dGYub3JnPjoNCiAgICA+IA0KICAgID4gRGVhciBhbGwsDQogICAgPiBCcmlhbiBhbmQgeW91cnMg dHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVjaWZpY2F0aW9uIHRoYXQgc2hvd3MgaG93IHRo ZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2ViIGFwcCBjYW4gZGVsZWdhdGUgdG9rZW4gYWNx dWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0cyBiYWNrZW5kLCBhbmQgcmVxdWVzdCBzdWNo IHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0IGFjY2VzcyBvZiBwcm90ZWN0ZWQgcmVzb3Vy Y2VzIGZyb20gdGhlIGZyb250ZW5kIGNvZGUuDQogICAgPiANCiAgICA+IFRoZSBwYXR0ZXJuIGlz IGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2YXJpb3VzIG1vZGVybiBk ZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFudHMgb2YgdGhlIHBhdHRl cm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRlcm0gQkZGIChiYWNrZW5k IGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQgaW4gdGhpcyB3b3JrZ3Jv dXDigJlzIGFjdGl2aXR5LCBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9uIGRldGFp bHMgdG8gdGhlIHJlYWRlci4NCiAgICA+IFdlIGJlbGlldmUgdGhlIHBhdHRlcm4gaGFzIG1lcml0 LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdyb3dpbmcgYWRvcHRpb24uIEJ5IGRlbGVnYXRpbmcg YWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIHRoZSBiYWNrZW5kLCB3ZSBhdm9pZCBtYW55IG9m IHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBwYXJ0cyAoYW5kIGltcGxpZWQgYXR0YWNrIHN1cmZh Y2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNjZXNzIHRva2VucyBmcm9tIGEgdXNlciBhZ2VudC4g VGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhlIG5lZWQgb2Yg cGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3duIHNvcmUgcG9p bnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVseWluZyBvbiBp dHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vucy4NCiAgICA+ IA0KICAgID4gQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gaXMgdmVyeSBzaW1wbGUsIHByb3Zp ZGluZyBleHBsaWNpdCBndWlkYW5jZSBvbiB0aGUgc2NlbmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50 YWdlcy4gIA0KICAgID4gLSBJdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBjcmVhdGUgaW50ZXJvcGVy YWJsZSBTREtzLCB3aGVyZSBmcm9udGVuZCBkZXYgc3RhY2tzIChhbnkgSlMgZmxhdm9yKSBjYW4g YmUgbWl4ZWQgYW5kIG1hdGNoZWQgd2l0aCBjb21wbGlhbnQgYmFja2VuZCBzdGFja3MgKG1pZGRs ZXdhcmVzIGluIG5vZGUsIGphdmEsIEFTUC5ORVQsIFBIUCBldGMpDQogICAgPiAtIEl0IGFsbG93 cyB1cyB0byBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9wZXJseSB0YWNrbGUgdGhlIHNj ZW5hcmlvIGFuZCB3YXJuIGltcGxlbWVudGVycyBhZ2FpbnN0IHNlY3VyaXR5IHJpc2tzIChzY29w ZSBlc2NhbGF0aW9ucywgdXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBvZiBhY2Nlc3MgdG9rZW5zLCBl dGMpDQogICAgPiAtIEl0IGFsbG93cyB1cyB0byBkaXNjdXNzIChhbmQgd2hlbiBhcHByb3ByaWF0 ZSwgcHJvbW90ZSkgdGhpcyBwYXR0ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dzZXIgYXBwcyBzZWN1 cml0eSBndWlkYW5jZSwgYW5kIHBvc2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVyZSBmcm9udGVuZCBv bmx5IGNhbGxzIEFQSSBvbiBpdHMgb3duIGJhY2tlZCAoaGVuY2UgZG9lc27igJl0IG5lZWQgYWNj ZXNzIHRva2Vucykgc2ltcGx5IGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMgbW9yZSBnZW5lcmFs IHBhdHRlcm4NCiAgICA+IC0gVGhpcyBhcHByb2FjaCBtYWtlcyBtb2NraW5nIGFuZCB0ZXN0aW5n IGFwcHMgdmVyeSBlYXN5LCBwb3NzaWJseSBwcmV2ZW50aW5nIGRldmVsb3BlcnMgZnJvbSB3ZWFr ZW5pbmcgdGhlIHNlY3VyaXR5IG9mIHRoZWlyIHN5c3RlbSAoZWcgdHVybmluZyBvbiBST1BHIG9w dGlvbnMpICBvciB0dXJuaW5nIHRvIHJpc2t5IHByYWN0aWNlcyBsaWtlIHNjcmFwaW5nDQogICAg PiANCiAgICA+IE5lZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXNu4oCZdCBl bnRpcmVseSBlbGltaW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1c2Ugb2YgYWNj ZXNzIHRva2VucyBmcm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0aGUgcGF0dGVy biBpcyBpbiB3aWRlc3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxlYWRpbmcgdG8g dGhhdCAoZWcgZGV2ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdCBvbmx5IHdvcmsgd2l0 aCBmcm9udGVuZCBzdGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZlcnNlIHByb3hpZXMgbWlnaHQg bm90IGFsd2F5cyBiZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29pbmcgYXdheSBhbnkgdGltZSBz b29uLiBCeSBwcm92aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRoaXMgcGF0dGVybiwgd2UgY2Fu IHNpbXBsaWZ5IHRoZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3aGlsZSBlbnNocmluaW5nIGJh c2ljIHNlY3VyaXR5IGh5Z2llbmUgaW4gc2NlbmFyaW9zIHRoYXQgd291bGQgaGF2ZSBvdGhlcndp c2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLg0KICAgID4gDQogICAgPiBMb29raW5nIGZv cndhcmQgZm9yIHlvdXIgZmVlZGJhY2shDQogICAgPiANCiAgICA+IEImViAgDQogICAgPiANCiAg ICA+IO+7v09uIDIvMTIvMjEsIDEyOjQxLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCiAgICA+IA0KICAgID4gDQogICAgPiAgICBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0 DQogICAgPiAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZpdHRvcmlvIEJl cnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgPiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAg PiANCiAgICA+ICAgIE5hbWU6CQlkcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZg0KICAgID4g ICAgUmV2aXNpb246CTAwDQogICAgPiAgICBUaXRsZToJCVRva2VuIE1lZGlhdGluZyBhbmQgc2Vz c2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZA0KICAgID4gICAgRG9jdW1lbnQg ZGF0ZToJMjAyMS0wMi0xMg0KICAgID4gICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N CiAgICA+ICAgIFBhZ2VzOgkJMTYNCiAgICA+ICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3 dy5nb29nbGUuY29tL3VybD9xPWh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt YmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0JnNvdXJjZT1nbWFpbC1pbWFwJnVzdD0xNjEz NzY3NTkxMDAwMDAwJnVzZz1BT3ZWYXczUmItUzBsNmNFdjB5dGpEeHRZTEFQDQogICAgPiAgICBT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cT1odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi8mc291cmNl PWdtYWlsLWltYXAmdXN0PTE2MTM3Njc1OTEwMDAwMDAmdXNnPUFPdlZhdzMtcWc1TUR0WTdrRDFI cFI1alIyUVkNCiAgICA+ICAgIEh0bWw6ICAgICAgICAgICBodHRwczovL3d3dy5nb29nbGUuY29t L3VybD9xPWh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1 dGgyLXRtaS1iZmYtMDAuaHRtbCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxMzc2NzU5MTAwMDAw MCZ1c2c9QU92VmF3MDVXSzRHU0VLY1dqWnpOaHZiMXA1ZA0KICAgID4gICAgSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwJnNvdXJjZT1nbWFpbC1pbWFwJnVz dD0xNjEzNzY3NTkxMDAwMDAwJnVzZz1BT3ZWYXcwcW00NU1XR2JaZjB6YkJqWmozZ2d6DQogICAg PiANCiAgICA+IA0KICAgID4gICAgQWJzdHJhY3Q6DQogICAgPiAgICAgICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBob3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxlZ2F0ZSBhY2Nlc3MN CiAgICA+ICAgICAgIHRva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2VuZCBjb21wb25lbnQuICBJ biBzbyBkb2luZywgdGhlIGZyb250ZW5kDQogICAgPiAgICAgICBjYW4gYWNjZXNzIHJlc291cmNl IHNlcnZlcnMgZGlyZWN0bHkgd2l0aG91dCB0YWtpbmcgb24gdGhlIGJ1cmRlbiBvZg0KICAgID4g ICAgICAgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lz dGluZyB0b2tlbnMsIGFuZA0KICAgID4gICAgICAgcGVyZm9ybWluZyBvcGVyYXRpb25zIHRoYXQg YXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW4NCiAgICA+ICAgICAgIGV4 ZWN1dGVkIGluIGEgdXNlciBhZ2VudCwgYnV0IGFyZSBzYWZlIGFuZCB3ZWxsIHByb3ZlbiB3aGVu IGV4ZWN1dGVkDQogICAgPiAgICAgICBieSBhIGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBv biBhIGJhY2tlbmQuDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+ICAgIFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCiAgICA+ICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgPiANCiAgICA+ICAg IFRoZSBJRVRGIFNlY3JldGFyaWF0DQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gT0F1dGgg bWFpbGluZyBsaXN0DQogICAgPiBPQXV0aEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuZ29v Z2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo JnNvdXJjZT1nbWFpbC1pbWFwJnVzdD0xNjEzNzY3NTkxMDAwMDAwJnVzZz1BT3ZWYXcxQmZ1OWZK MkZqX0JaSjNIOXl3N29kDQogICAgDQogICAgDQo= From nobody Sun Feb 14 11:39:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99F73A07DA for ; Sun, 14 Feb 2021 11:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pfyu6psnItJ for ; Sun, 14 Feb 2021 11:38:59 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AC63A0650 for ; Sun, 14 Feb 2021 11:38:59 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id t2so2625960pjq.2 for ; Sun, 14 Feb 2021 11:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=3d7M4w+cg96ioi2OTOkHyyv5vlOT6RALXpy1+FcW1jg=; b=cC1kqZ8KvNGlpzRELI+sjoW1nCBEuaYetAyfIKP6ZCnAcMVV9TYu1UBXT5f+poQ7gF ua6Q3O4efAAuRH1VRhR2N0hWXHQcPzLDjQ30vU91iLVcKxPftmzWsRRnPS8prVKfqJXw DS3aq11CQwt2vnJMiLge/zmpWs5U5KB8+yFy77QKd5/BXu6NHIuyK+F1rMM73LcFLLbI qxhNFj8W6aiCqe7XNxf6FeH67oKzi+Z+9C1lebCE/4RYAi/RVruoFMSJfYNYQegB3Mf9 6PNNcgnbKCYAsGXjr9H17HZgsXKqDAQVshDz6iypbsOLs0VAppouXLL89k3h6kcEnHKq 9bSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=3d7M4w+cg96ioi2OTOkHyyv5vlOT6RALXpy1+FcW1jg=; b=bzVzj8rwXjIqeSxGrPWPF276OskADV3Lp1ck6Ziz8l2WizwwFSKuENO9ZgIjXYSkAL cF+d/cvQTfUCDBpaOL6r7OOYGsKx3FfnKwNZgOCq0Fyv43pZAHjRa0rTHlrlMwRLBQ3d tvVV+TkrproGRUUPUeseL1IhbjhL/JaHNHmLX7qzbziuPiBGfqKTsEfFW7cytnCKN+rm G3bYbEnh4kJGWIWjuES0+xLtYrnMjhgBNYZvyfdWpI9RYob7QTlJKoOcqoUaWNXyl520 K6t9+nuFL2Ak1/TV+J54djoy0Y6OWZqwUwj5xYDshlDbt7/feVxFKXjHLfpzrAEDwn7d brQw== X-Gm-Message-State: AOAM532IwmwhwQgdtmCclkGSkTLG+on0DFn7xozefe+b0WL+WMZ3mCCy nDvYYN6YQmijvPavxkdU2nt9Fg== X-Google-Smtp-Source: ABdhPJwSa5m1KAiO7P1NCVEbMnndIfCJ8nVKPSy/vDF3f5TPcD4Z2TbZts3kWYZzBYp0OwLFN9Rujw== X-Received: by 2002:a17:90a:f497:: with SMTP id bx23mr12525584pjb.170.1613331539056; Sun, 14 Feb 2021 11:38:59 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id h8sm14278687pfv.154.2021.02.14.11.38.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 11:38:58 -0800 (PST) From: Vittorio Bertocci To: Warren Parad , Stoycho Sleptsov CC: Neil Madden , oauth Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAAaNoCAACuILIAAFosAgAALMgCAAAZ4gIAADE4AgAAfRYCAAATwgIAAH9sv X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 19:38:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB40520FF440BAD7B312B29904AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 19:39:02 -0000 --_000_CO6PR18MB40520FF440BAD7B312B29904AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIFRNSS1CRkYgdG9wb2xvZ3ksIHRoZSBiYWNrZW5kIGFuZCBmcm9udGVuZCBkZXZlbG9w ZXIgYXJlIHRoZSBzYW1lIHBlcnNvbi4gVGhlIG9wZXJhdGlvbnMgVE1JLUJGRiBkZXNjcmliZXMg YXJlIHRoZSBmdW5jdGlvbmFsIGVxdWl2YWxlbnQgb2Ygd2hhdCB0aGUgSlMgY29kZSBvZiBvbmUg U1BBIGFwcCB1c2luZyBhIGNvZGUrUEtDRSBTREsgd291bGQgZG8gd2hlbiByZXRyaWV2aW5nIHBy ZXZpb3VzbHkgb2J0YWluaW5nIHRva2VucyBmcm9tIHRoZSBzdG9yZSBpbiBvcmRlciB0byBwZXJm b3JtIGFuIEFQSSBjYWxsLiBXaGVyZWFzIHN1Y2ggYW4gYXBwIHdvdWxkIG1ha2UgdGhhdCBjYWxs IGluIG1lbW9yeSAoYW5kIHJlc3VsdCBpbiB0aGUgc2FtZSBvcGVyYXRpb25zIGRlc2NyaWJlZCBo ZXJlLCBlaXRoZXIgdXNlIGEgcHJldmlvdXNseSBzYXZlZCBhY2Nlc3MgdG9rZW4gbWF0Y2hpbmcg dGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgQVBJIGNhbGwsIG9yIHVzZSBhcnRpZmFjdHMgbGlrZSBS VHMgdG8gcmVxdWVzdCBhIG5ldyBhY2Nlc3MgdG9rZW4gbWF0Y2hpbmcgdGhlIHJlcXVlc3QpIGlu IFRNSS1CRkYgYWwgdGhlIGxvZ2ljIGFuZCBwZXJzaXN0ZW5jZSBsYXllciBhcmUgaW4gdGhlIGJh Y2tlbmQsIGhlbmNlIHRoYXQgcXVlcnkgYmVjb21lcyBhIHJlcXVlc3QgdG8gdGhlIGJhY2tlbmQg aW5zdGVhZCBvZiBhIGxvY2FsIGZ1bmN0aW9uIGNhbGwuDQpUaGUgYWR2YW50YWdlcyBoYXZlIGJl ZW4gZGVzY3JpYmVkIGluIG90aGVyIGJyYW5jaGVzIG9mIHRoaXMgdGhyZWFkLCBidXQgVEw7RFIt IGEgbG90IG9mIHRoZSB0b2tlbiByZXF1ZXN0aW5nIHdvcmsgY2FuIGJlIHBlcmZvcm1lZCBtb3Jl IHJlbGlhYmx5IChlZyBsZXNzIHRoaW5ncyBjYW4gZ28gd3JvbmcpIGZyb20gYSBjb25maWRlbnRp YWwgY2xpZW50IGFuZCBpdOKAmXMgZWFzaWVyIGZvciBTREsgZGV2ZWxvcGVycyB0byBwYWNrYWdl IGl0IChzZWUgZXhpc3RpbmcgbWlkZGxld2FyZXMgdnMgSlMgU0RLcykuIE5vdGUgdGhhdCBmb3Ig dGhlIGFwcCBkZXZlbG9wZXIgdGhpcyBtaWdodCBzdGlsbCBsb29rIGxpa2UgdGhlIHNhbWUgZmxv dywgYXNraW5nIGEgSlMgU0RLIHRvIGdldCB0aGUgdG9rZW4gdGhlIGFwcCBuZWVkcyB0byBjYWxs IGFuIEFQSSwgYnV0IHRoZSBKUyBTREsgd291bGQgYmUgZHJhbWF0aWNhbGx5IHNpbXBsZXIgdGhh biB0aGUgb25lIHBlcmZvcm1pbmcgY29kZStQS0NFIGluIHRoZSB1c2VyIGFnZW50IGFuZCBlbnRh aWwgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGZyb250ZW5kIGEgYmFja2VuZCwgaGVuY2UgdGhlIG5l ZWQgdG8gZGVmaW5lIGhvdyB0aGF0IGNvbW11bmljYXRpb24gaGFwcGVucyBpZiB3ZSB3YW50IGRl dmVsb3BlcnMgdG8gYmUgYWJsZSB0byBtaXggYW5kIG1hdGNoIGZyb250ZW5kIGFuZCBiYWNrZW5k IGRldiBzdGFja3MuDQpBZ2FpbiwgdGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBhZGQgc2VjdXJp dHkgdG8gdGhlIGNvZGUrUEtDRSBpbiB0aGUgdXNlciBhZ2VudCBtb2RlbCAod2hpY2ggcmVtYWlu cyB0aGUgb25seSBnYW1lIGluIHRvd24gZm9yIGJhY2tlbmRsZXNzIFNQQXMpLCBidXQgaXQgZG9l cyBtYWtlIHRoaW5ncyBzaW1wbGVyIGZvciB0aGUgZnJvbnRlbmQgZGV2ZWxvcGVyIGFuZCByZXF1 aXJlcyBsZXNzIGFkdmFuY2VkIGNhcGFiaWxpdGllcyBpbiB0aGUgQVMuDQoNCkZyb206IFdhcnJl biBQYXJhZCA8d3BhcmFkQHJob3N5cy5jaD4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIw MjEgYXQgMDk6NDUNClRvOiBTdG95Y2hvIFNsZXB0c292IDxzdG95Y2hvLnNsZXB0c292QGdtYWls LmNvbT4NCkNjOiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4sIFZpdHRv cmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+LCBvYXV0aCA8b2F1dGhA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNl c3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpDQoNCkNvcnJl Y3QgaXQgd291bGQgbmV2ZXIgbmVlZCB0byBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBhIGNsaWVu dCwgYXMgYSBjbGllbnQgaXMgYWx3YXlzIG9mZmxpbmUgYW5kIGNhbiBkaXJlY3RseSB1c2UgdGhl IGJhY2tjaGFubmVsLiBZb3Ugd291bGQgbmV2ZXIgbmVlZCB0aGUgZnJvbnQgY2hhbm5lbCB0byBh dXRoZW50aWNhdGUgYSBjbGllbnQsIGhvd2V2ZXIgeW91IG1pZ2h0IG5lZWQgdGhlIGZyb250IGNo YW5uZWwgdG8gYXV0aG9yaXplIGEgY2xpZW50IHRvIGFjY2VzcyB1c2VyIHJlc291cmNlcyBvZmZs aW5lLiBJcyB0aGF0IHdoYXQgeW91IGFyZSB0YWxraW5nIGFib3V0LCBpLmUuIHRoZSBvZmZsaW5l IHJlZnJlc2hfdG9rZW4gYXV0aG9yaXphdGlvbiBjb2RlIGZsb3c/DQoNCklmIHllcywgdGhlbiB0 aGUgc3RhbmRhcmQgd291bGQgYmUgdG8gdXNlIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBy ZXF1ZXN0aW5nIGFzIHlvdSd2ZSBtZW50aW9uZWQuIEFsdGhvdWdoIHRoYXQgZmxvdyBhbHJlYWR5 IGV4aXN0cyBhbmQgd2VsbCBlc3RhYmxpc2hlZCwgYW5kIHdpdGhvdXQgYW55IGlzc3VlcywgaGF2 aW5nIGEgc3RhbmRhcmQgc3BlY2lmeWluZyBob3cgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgY2xp ZW50IGRvZXNuJ3Qgc2VlbSB0byBiZSB1c2VmdWwsIGFzIHlvdSBvbmx5IG5lZWQgdG8gcGFzcyBh biBhdXRoIGNvZGUgYW5kIHRoZSBpc3N1ZXIgdG8gdGhlIGNsaWVudC4gQnV0IHNpbmNlIHRoZXNl IGVuZHBvaW50cyBhcmUgbmV2ZXIgZXhwb3NlZCBub3IgbmVlZCB0byBoYXZlIGludGVyb3BlcmFi aWxpdHkgYmV0d2VlbiBkaWZmZXJlbnQgb3duZXJzIChpLmUuIHRoZSBvd25lciBvZiB0aGUgZnJv bnQtY2hhbm5lbCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb3duZXIgb2YgdGhlIGJhY2stY2hhbm5l bCksIHdoYXQncyB0aGUgYmVuZWZpdCBvZiBzcGVjaWZ5aW5nIHRoZSBleHBsaWNpdCBlbmRwb2lu dHMgbmVjZXNzYXJ5IGZvciB0aGUgQkZGIHRvIGhhdmU/DQoNCg0KW0ltYWdlIHJlbW92ZWQgYnkg c2VuZGVyLl0NCg0KV2FycmVuIFBhcmFkDQoNCkZvdW5kZXIsIENUTw0KU2VjdXJlIHlvdXIgdXNl ciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0ZWN0dXJlLiBJbXBs ZW1lbnQgQXV0aHJlc3M8aHR0cHM6Ly9hdXRocmVzcy5pbz4uDQoNCg0KT24gU3VuLCBGZWIgMTQs IDIwMjEgYXQgNjoyNyBQTSBTdG95Y2hvIFNsZXB0c292IDxzdG95Y2hvLnNsZXB0c292QGdtYWls LmNvbTxtYWlsdG86c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb20+PiB3cm90ZToNClRoYW5rcyBX YXJyZW4sDQoNCmFzIEkgc2VlIHlvdSBhbmQgTmVpbCBoYXZlIHRoZSBzYW1lIGlkZWEsDQpidXQg YXMgb2YgdGhpcyBtb21lbnQgSSB0aGluayB0aGlzIG1ldGhvZCBpcyBub3QgYSB2YWxpZCBvcHRp b24gZm9yIGF1dGhlbnRpY2F0aW5nDQphIGNsaWVudCBhY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LWll dGYtb2F1dGgtdjItMS4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGF1dGhlbnRpY2F0aW5nIHRoZSBj bGllbnQgdGhyb3VnaCB0aGUgQkZGDQpzZWVtcyBjb25mb3JtaW5nIHRvIHRoZSBzcGVjLiwgYnV0 IGluIHRoZSBjYXNlIHdoZW4gdGhlIGFjY2VzcyB0b2tlbiBpcyB1c2VkDQppbiB0aGUgYnJvd3Nl ciBpbiBmYWN0LCBJIGFtIGFmcmFpZCB0aGF0IGl0IGNhbiBiZSByZWdhcmRlZCBhcw0Kc29tZSBr aW5kIG9mICJkZWNlcHRpb24iIG9mIHRoZSBBUy4NCg0KSXQgc2VlbXMgdGhlIGZyb250ZW5kIFNQ QSBpcyBub3QgdGhlIGVhc2llc3Qgd2F5IHRvIGdvIHdpdGggb2F1dGguLi4NCg0KU3RveWNoby4N Cg0KT24gU3VuLCAxNCBGZWIgMjAyMSBhdCAxNzozNSwgV2FycmVuIFBhcmFkIDx3cGFyYWRAcmhv c3lzLmNoPG1haWx0bzp3cGFyYWRAcmhvc3lzLmNoPj4gd3JvdGU6DQpyZWRpcmVjdF91cmkgYW5k IHVzZSBQS0NFIHZpYSB0aGUgY29kZSB2ZXJpZmllci4NCg0KDQpbSW1hZ2UgcmVtb3ZlZCBieSBz ZW5kZXIuXQ0KDQpXYXJyZW4gUGFyYWQNCg0KRm91bmRlciwgQ1RPDQpTZWN1cmUgeW91ciB1c2Vy IGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1cmUuIEltcGxl bWVudCBBdXRocmVzczxodHRwczovL2F1dGhyZXNzLmlvPi4NCg0KDQpPbiBTdW4sIEZlYiAxNCwg MjAyMSBhdCAzOjUxIFBNIFN0b3ljaG8gU2xlcHRzb3YgPHN0b3ljaG8uc2xlcHRzb3ZAZ21haWwu Y29tPG1haWx0bzpzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGEg bG90IGZvciB5b3VyIGFuc3dlciBOZWlsLA0KDQphcyBJIGFtIG5vIGV4cGVydCAoeWV0IDotKSkg aW4gc2VjdXJpdHkgSSB3YXMgYWZyYWlkIHRvIHJlbHkgb24NCnJlZGlyZWN0X3VyaSBmb3IgYXV0 aGVudGljYXRpb24gb2YgdGhlIGNsaWVudCwNCmJ1dCBJIHdpbGwgY29uc2lkZXIgdGhhdCBvcHRp b24gYXMgbW9yZSB0cnVzdHdvcnRoeSBub3cuDQoNCihpdCBpcyBhbHNvIG5vdCB2ZXJ5IGNsZWFy IGZvciBtZSB3aGljaCBwYXJ0IG9mIHRoZSBhcHAgY2FuIGJlDQpyZWdhcmRlZCBhcyB0aGUgcmVk aXJlY3RfdXJpIG93bmVyLCB0aGUgQkZGIG9yIHRoZSBsb2FkZWQgZnJvbnRlbmQNClNQQSwgYnV0 IG1heWJlIGl0IGlzIG5vdCBzbyBpbXBvcnRhbnQpDQoNCklmIHlvdSBoYWQgdGhlIHR3byBvcHRp b25zIGZvciBhdXRoZW50aWNhdGlvbiBvZiB0aGUgZnJvbnRlbmQgU1BBDQpjbGllbnQgLSB0aGUg cmVkaXJlY3RfdXJpIG9uIHRoZSBvbmUgaGFuZCwgYW5kIHRoZSBCYXNpYw0KYXV0aGVudGljYXRp b24gd2l0aCBjbGllbnQgc2VjcmV0IHRocm91Z2ggdGhlIEJGRiBvbiB0aGUgb3RoZXIsIHdoaWNo DQpvbmUgd291bGQgeW91IHJlY29tbWVuZD8NCg0KT24gU3VuLCAxNCBGZWIgMjAyMSBhdCAxNjoy OCwgTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208bWFpbHRvOm5laWwubWFk ZGVuQGZvcmdlcm9jay5jb20+PiB3cm90ZToNCj4NCj4gUHVibGljIGNsaWVudHMgYXJlIGltcGxp Y2l0bHkgYXV0aGVudGljYXRlZCBieSB0aGVpciBvd25lcnNoaXAgb2YgdGhlIHJlZ2lzdGVyZWQg cmVkaXJlY3RfdXJpLiBUaGlzIHdoeSBpdOKAmXMgaW1wb3J0YW50IHRvIHVzZSBhIHJlZGlyZWN0 X3VyaSBmb3Igd2hpY2ggb3duZXJzaGlwIGNhbiBiZSByZWFzb25hYmx5IGVzdGFibGlzaGVkLCBz dWNoIGFzIEhUVFBTIGVuZHBvaW50cyB3aXRoIGV4YWN0IFVSSSBtYXRjaGluZy4NCj4NCj4gVGhl cmUgYXJlIG1vcmUgdGhpbmdzIHRoYXQgY2FuIGdvIHdyb25nIHdpdGggdGhhdCAoc2VlIHRoZSBz ZWN1cml0eSBCQ1ApLCBidXQgaXQgY2FuIGJlIG1hZGUgcmVhc29uYWJseSBzZWN1cmUuDQo+DQo+ IOKAlCBOZWlsDQo+DQo+ID4gT24gMTQgRmViIDIwMjEsIGF0IDEzOjQ4LCBTdG95Y2hvIFNsZXB0 c292IDxzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNvbTxtYWlsdG86c3RveWNoby5zbGVwdHNvdkBn bWFpbC5jb20+PiB3cm90ZToNCj4gPg0KPiA+IO+7vw0KPiA+IEkgd291bGQgbGlrZSB0byBhZGQg bXkgcmVhc29ucyBhYm91dCB0aGUgIldoeSBhcmUgZGV2ZWxvcGVycyBjcmVhdGluZyBCRkYgZm9y IHRoZWlyIGZyb250ZW5kcyB0byBjb21tdW5pY2F0ZSB3aXRoIGFuIEFTIiwNCj4gPiB3aXRoIHRo ZSBvYmplY3RpdmUgdG8gdmVyaWZ5IGlmIHRoZXkgYXJlIHZhbGlkLg0KPiA+DQo+ID4gSSBuZWVk IHRoZSBjbGllbnQgYXBwLiB0byBiZSBhdXRoZW50aWNhdGVkIGF0IHRoZSBBUyAodG8gZGV0ZXJt aW5lIGlmIGl0IGlzIGEgZmlyc3QtcGFydHkgYXBwLiwgZm9yIGV4YW1wbGUpLg0KPiA+IElmIHdl IGRlY2lkZSB0byBpbXBsZW1lbnQgb3VyIGNsaWVudCBhcyBhIGZyb250ZW5kIFNQQSAsIHRoZW4g d2UgaGF2ZSBubyBvdGhlciBvcHRpb24gZXhjZXB0IHRocm91Z2ggYSBCRkYsIGFzIFBLQ0UgZG9l cyBub3QgaGVscCBmb3IgYXV0aGVudGljYXRpb24uDQo+ID4NCj4gPiBPciBpcyBpdCBjb25zaWRl cmVkIGEgYmFkIHByYWN0aWNlIHRvIGRvIHRoYXQ/DQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFN0 b3ljaG8uDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KPg0KPiAtLQ0KPiBGb3JnZVJvY2sgdmFsdWVzIHlvdXIgUHJpdmFjeSA8aHR0cHM6Ly93 d3cuZm9yZ2Vyb2NrLmNvbS95b3VyLXByaXZhY3k+DQo= --_000_CO6PR18MB40520FF440BAD7B312B29904AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biB0aGUgVE1JLUJGRiB0b3BvbG9neSwgdGhlIGJhY2tlbmQgYW5kIGZyb250ZW5kIGRldmVsb3Bl ciBhcmUgdGhlIHNhbWUgcGVyc29uLiBUaGUgb3BlcmF0aW9ucyBUTUktQkZGIGRlc2NyaWJlcyBh cmUgdGhlIGZ1bmN0aW9uYWwgZXF1aXZhbGVudCBvZiB3aGF0IHRoZSBKUyBjb2RlIG9mIG9uZSBT UEEgYXBwIHVzaW5nIGEgY29kZStQS0NFIFNESyB3b3VsZCBkbyB3aGVuIHJldHJpZXZpbmcgcHJl dmlvdXNseQ0KIG9idGFpbmluZyB0b2tlbnMgZnJvbSB0aGUgc3RvcmUgaW4gb3JkZXIgdG8gcGVy Zm9ybSBhbiBBUEkgY2FsbC4gV2hlcmVhcyBzdWNoIGFuIGFwcCB3b3VsZCBtYWtlIHRoYXQgY2Fs bCBpbiBtZW1vcnkgKGFuZCByZXN1bHQgaW4gdGhlIHNhbWUgb3BlcmF0aW9ucyBkZXNjcmliZWQg aGVyZSwgZWl0aGVyIHVzZSBhIHByZXZpb3VzbHkgc2F2ZWQgYWNjZXNzIHRva2VuIG1hdGNoaW5n IHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIEFQSSBjYWxsLCBvcg0KIHVzZSBhcnRpZmFjdHMgbGlr ZSBSVHMgdG8gcmVxdWVzdCBhIG5ldyBhY2Nlc3MgdG9rZW4gbWF0Y2hpbmcgdGhlIHJlcXVlc3Qp IGluIFRNSS1CRkYgYWwgdGhlIGxvZ2ljIGFuZCBwZXJzaXN0ZW5jZSBsYXllciBhcmUgaW4gdGhl IGJhY2tlbmQsIGhlbmNlIHRoYXQgcXVlcnkgYmVjb21lcyBhIHJlcXVlc3QgdG8gdGhlIGJhY2tl bmQgaW5zdGVhZCBvZiBhIGxvY2FsIGZ1bmN0aW9uIGNhbGwuDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhZHZhbnRhZ2VzIGhhdmUgYmVlbiBkZXNjcmliZWQgaW4g b3RoZXIgYnJhbmNoZXMgb2YgdGhpcyB0aHJlYWQsIGJ1dCBUTDtEUi0gYSBsb3Qgb2YgdGhlIHRv a2VuIHJlcXVlc3Rpbmcgd29yayBjYW4gYmUgcGVyZm9ybWVkIG1vcmUgcmVsaWFibHkgKGVnIGxl c3MgdGhpbmdzIGNhbiBnbyB3cm9uZykgZnJvbSBhIGNvbmZpZGVudGlhbCBjbGllbnQgYW5kIGl0 4oCZcyBlYXNpZXIgZm9yIFNESyBkZXZlbG9wZXJzDQogdG8gcGFja2FnZSBpdCAoc2VlIGV4aXN0 aW5nIG1pZGRsZXdhcmVzIHZzIEpTIFNES3MpLiBOb3RlIHRoYXQgZm9yIHRoZSBhcHAgZGV2ZWxv cGVyIHRoaXMgbWlnaHQgc3RpbGwgbG9vayBsaWtlIHRoZSBzYW1lIGZsb3csIGFza2luZyBhIEpT IFNESyB0byBnZXQgdGhlIHRva2VuIHRoZSBhcHAgbmVlZHMgdG8gY2FsbCBhbiBBUEksIGJ1dCB0 aGUgSlMgU0RLIHdvdWxkIGJlIGRyYW1hdGljYWxseSBzaW1wbGVyIHRoYW4gdGhlIG9uZSBwZXJm b3JtaW5nDQogY29kZStQS0NFIGluIHRoZSB1c2VyIGFnZW50IGFuZCBlbnRhaWwgY29tbXVuaWNh dGlvbiBiZXR3ZWVuIGZyb250ZW5kIGEgYmFja2VuZCwgaGVuY2UgdGhlIG5lZWQgdG8gZGVmaW5l IGhvdyB0aGF0IGNvbW11bmljYXRpb24gaGFwcGVucyBpZiB3ZSB3YW50IGRldmVsb3BlcnMgdG8g YmUgYWJsZSB0byBtaXggYW5kIG1hdGNoIGZyb250ZW5kIGFuZCBiYWNrZW5kIGRldiBzdGFja3Mu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWluLCB0aGlzIGRvZXMg bm90IG5lY2Vzc2FyaWx5IGFkZCBzZWN1cml0eSB0byB0aGUgY29kZStQS0NFIGluIHRoZSB1c2Vy IGFnZW50IG1vZGVsICh3aGljaCByZW1haW5zIHRoZSBvbmx5IGdhbWUgaW4gdG93biBmb3IgYmFj a2VuZGxlc3MgU1BBcyksIGJ1dCBpdCBkb2VzIG1ha2UgdGhpbmdzIHNpbXBsZXIgZm9yIHRoZSBm cm9udGVuZCBkZXZlbG9wZXIgYW5kIHJlcXVpcmVzIGxlc3MgYWR2YW5jZWQgY2FwYWJpbGl0aWVz DQogaW4gdGhlIEFTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ V2FycmVuIFBhcmFkICZsdDt3cGFyYWRAcmhvc3lzLmNoJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5T dW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDA5OjQ1PGJyPg0KPGI+VG86IDwvYj5TdG95Y2hv IFNsZXB0c292ICZsdDtzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPk5laWwgTWFkZGVuICZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tJmd0OywgVml0dG9y aW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSZndDssIG9hdXRoICZs dDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10g VG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250 ZW5kIChUTUkgQkZGKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q29ycmVjdCBpdCB3b3VsZCBuZXZlciBuZWVkIHRvIGJlIHVzZWQg dG8gYXV0aGVudGljYXRlIGEgY2xpZW50LCBhcyBhIGNsaWVudCBpcyBhbHdheXMgb2ZmbGluZSBh bmQgY2FuIGRpcmVjdGx5IHVzZSB0aGUgYmFja2NoYW5uZWwuIFlvdSB3b3VsZCBuZXZlciBuZWVk IHRoZSBmcm9udCBjaGFubmVsIHRvIGF1dGhlbnRpY2F0ZSBhIGNsaWVudCwgaG93ZXZlciB5b3Ug bWlnaHQgbmVlZCB0aGUgZnJvbnQgY2hhbm5lbA0KIHRvIGF1dGhvcml6ZSBhIGNsaWVudCB0byBh Y2Nlc3MgdXNlciByZXNvdXJjZXMgb2ZmbGluZS4gSXMgdGhhdCB3aGF0IHlvdSBhcmUgdGFsa2lu ZyBhYm91dCwgaS5lLiB0aGUgb2ZmbGluZSByZWZyZXNoX3Rva2VuIGF1dGhvcml6YXRpb24gY29k ZSBmbG93PzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHllcywgdGhlbiB0aGUgc3RhbmRhcmQgd291bGQgYmUgdG8gdXNlIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUgZmxvdyByZXF1ZXN0aW5nIGFzIHlvdSd2ZSBtZW50aW9uZWQuIEFsdGhvdWdo IHRoYXQgZmxvdyBhbHJlYWR5IGV4aXN0cyBhbmQgd2VsbCBlc3RhYmxpc2hlZCwgYW5kIHdpdGhv dXQgYW55IGlzc3VlcywgaGF2aW5nIGEgc3RhbmRhcmQgc3BlY2lmeWluZyBob3cgdG8gY29tbXVu aWNhdGUgd2l0aCB0aGUNCiBjbGllbnQgZG9lc24ndCBzZWVtIHRvIGJlIHVzZWZ1bCwgYXMgeW91 IG9ubHkgbmVlZCB0byBwYXNzIGFuIDxiPmF1dGggY29kZTwvYj4mbmJzcDthbmQgdGhlDQo8Yj5p c3N1ZXI8L2I+Jm5ic3A7dG8gdGhlIGNsaWVudC4gQnV0IHNpbmNlIHRoZXNlIGVuZHBvaW50cyBh cmUgbmV2ZXIgZXhwb3NlZCBub3IgbmVlZCB0byBoYXZlIGludGVyb3BlcmFiaWxpdHkgYmV0d2Vl biBkaWZmZXJlbnQgb3duZXJzIChpLmUuIHRoZSBvd25lciBvZiB0aGUgZnJvbnQtY2hhbm5lbCBp cyBkaWZmZXJlbnQgZnJvbSB0aGUgb3duZXIgb2YgdGhlIGJhY2stY2hhbm5lbCksIHdoYXQncyB0 aGUgYmVuZWZpdCBvZiBzcGVjaWZ5aW5nIHRoZSBleHBsaWNpdA0KIGVuZHBvaW50cyBuZWNlc3Nh cnkgZm9yIHRoZSBCRkYgdG8gaGF2ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIw IiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6 Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVy OnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9 Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3 aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48aW1nIHdpZHRoPSIxOTkiIGhlaWdodD0iMzQi IHN0eWxlPSJ3aWR0aDoyLjA3MjlpbjtoZWlnaHQ6LjM1NDFpbiIgaWQ9Il94MDAwMF9pMTAyNiIg YWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iIGRhdGEtb3V0bG9vay10cmFjZT0iRjowfFQ6 MSIgc3JjPSJjaWQ6fldSRDAxMy5qcGciPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDti b3JkZXItbGVmdDpub25lO3BhZGRpbmc6NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7b3ZlcmZsb3c6 aGlkZGVuIj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6 c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWJvdHRvbTpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4g MGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtib3JkZXI6 bm9uZTtwYWRkaW5nOjBpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPldhcnJlbiBQYXJhZDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6 c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDtib3JkZXI6bm9u ZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Rm91bmRlciwgQ1RPPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2hpdGUi PlNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQgY29tcGxldGUgeW91ciBhdXRob3JpemF0aW9uIGFy Y2hpdGVjdHVyZS4gSW1wbGVtZW50Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vYXV0aHJl c3MuaW8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QXV0 aHJlc3M8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgNjoyNyBQTSBTdG95Y2hvIFNs ZXB0c292ICZsdDs8YSBocmVmPSJtYWlsdG86c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb20iPnN0 b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFdh cnJlbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFzIEkg c2VlIHlvdSBhbmQgTmVpbCBoYXZlIHRoZSBzYW1lIGlkZWEsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgYXMgb2YgdGhpcyBtb21lbnQgSSB0 aGluayB0aGlzIG1ldGhvZCBpcyBub3QgYSB2YWxpZCBvcHRpb24gZm9yIGF1dGhlbnRpY2F0aW5n PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIGNs aWVudCBhY2NvcmRpbmcgdG8gdGhlJm5ic3A7ZHJhZnQtaWV0Zi1vYXV0aC12Mi0xLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgb3Ro ZXIgaGFuZCwgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCB0aHJvdWdoIHRoZSBCRkY8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNlZW1zIGNvbmZv cm1pbmcgdG8gdGhlIHNwZWMuLCBidXQmbmJzcDtpbiB0aGUmbmJzcDtjYXNlIHdoZW4mbmJzcDt0 aGUgYWNjZXNzIHRva2VuIGlzIHVzZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmluIHRoZSBicm93c2VyIGluIGZhY3QsIEkgYW0gYWZyYWlkIHRo YXQgaXQgY2FuIGJlIHJlZ2FyZGVkIGFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5zb21lIGtpbmQgb2YgJnF1b3Q7ZGVjZXB0aW9uJnF1b3Q7IG9m IHRoZSBBUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgc2VlbXMgdGhlIGZyb250ZW5kIFNQQSBpcyBub3QgdGhlIGVhc2llc3Qgd2F5IHRv IGdvIHdpdGggb2F1dGguLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U3RveWNoby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCAxNCBGZWIgMjAyMSBhdCAxNzozNSwgV2FycmVu IFBhcmFkICZsdDs8YSBocmVmPSJtYWlsdG86d3BhcmFkQHJob3N5cy5jaCIgdGFyZ2V0PSJfYmxh bmsiPndwYXJhZEByaG9zeXMuY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yZWRpcmVjdF91cmkg YW5kIHVzZSBQS0NFIHZpYSB0aGUgY29kZSB2ZXJpZmllci48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxh cHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJv cmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0 eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5v bmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIx OTkiIGhlaWdodD0iMzQiIHN0eWxlPSJ3aWR0aDoyLjA3MjlpbjtoZWlnaHQ6LjM1NDFpbiIgaWQ9 Il94MDAwMF9pMTAyNSIgYWx0PSJJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci4iIGRhdGEtb3V0bG9v ay10cmFjZT0iRjowfFQ6MSIgc3JjPSJjaWQ6fldSRDAxMy5qcGciPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xp ZCB3aGl0ZSAxLjBwdDtib3JkZXItbGVmdDpub25lO3BhZGRpbmc6NS4wcHQgNS4wcHQgNS4wcHQg NS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9y ZGVyLWRpdjtib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWJvdHRvbTpub25lO3BhZGRp bmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldhcnJlbiBQYXJhZDwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9y ZGVyLWRpdjtib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6 MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Rm91bmRlciwgQ1RP PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6d2hpdGUiPlNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQgY29tcGxldGUgeW91ciBh dXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vYXV0aHJlc3MuaW8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+QXV0aHJlc3M8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDM6NTEgUE0gU3Rv eWNobyBTbGVwdHNvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0b3ljaG8uc2xlcHRzb3ZAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciBhbnN3ZXIgTmVpbCw8YnI+DQo8YnI+DQphcyBJ IGFtIG5vIGV4cGVydCAoeWV0IDotKSkgaW4gc2VjdXJpdHkgSSB3YXMgYWZyYWlkIHRvIHJlbHkg b248YnI+DQpyZWRpcmVjdF91cmkgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQsPGJy Pg0KYnV0IEkgd2lsbCBjb25zaWRlciB0aGF0IG9wdGlvbiBhcyBtb3JlIHRydXN0d29ydGh5IG5v dy48YnI+DQo8YnI+DQooaXQgaXMgYWxzbyBub3QgdmVyeSBjbGVhciBmb3IgbWUgd2hpY2ggcGFy dCBvZiB0aGUgYXBwIGNhbiBiZTxicj4NCnJlZ2FyZGVkIGFzIHRoZSByZWRpcmVjdF91cmkgb3du ZXIsIHRoZSBCRkYgb3IgdGhlIGxvYWRlZCBmcm9udGVuZDxicj4NClNQQSwgYnV0IG1heWJlIGl0 IGlzIG5vdCBzbyBpbXBvcnRhbnQpPGJyPg0KPGJyPg0KSWYgeW91IGhhZCB0aGUgdHdvIG9wdGlv bnMgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBmcm9udGVuZCBTUEE8YnI+DQpjbGllbnQgLSB0 aGUgcmVkaXJlY3RfdXJpIG9uIHRoZSBvbmUgaGFuZCwgYW5kIHRoZSBCYXNpYzxicj4NCmF1dGhl bnRpY2F0aW9uIHdpdGggY2xpZW50IHNlY3JldCB0aHJvdWdoIHRoZSBCRkYgb24gdGhlIG90aGVy LCB3aGljaDxicj4NCm9uZSB3b3VsZCB5b3UgcmVjb21tZW5kPzxicj4NCjxicj4NCk9uIFN1biwg MTQgRmViIDIwMjEgYXQgMTY6MjgsIE5laWwgTWFkZGVuICZsdDs8YSBocmVmPSJtYWlsdG86bmVp bC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5laWwubWFkZGVuQGZvcmdl cm9jay5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQdWJsaWMgY2xpZW50 cyBhcmUgaW1wbGljaXRseSBhdXRoZW50aWNhdGVkIGJ5IHRoZWlyIG93bmVyc2hpcCBvZiB0aGUg cmVnaXN0ZXJlZCByZWRpcmVjdF91cmkuIFRoaXMgd2h5IGl04oCZcyBpbXBvcnRhbnQgdG8gdXNl IGEgcmVkaXJlY3RfdXJpIGZvciB3aGljaCBvd25lcnNoaXAgY2FuIGJlIHJlYXNvbmFibHkgZXN0 YWJsaXNoZWQsIHN1Y2ggYXMgSFRUUFMgZW5kcG9pbnRzIHdpdGggZXhhY3QgVVJJIG1hdGNoaW5n Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBtb3JlIHRoaW5ncyB0aGF0IGNhbiBnbyB3 cm9uZyB3aXRoIHRoYXQgKHNlZSB0aGUgc2VjdXJpdHkgQkNQKSwgYnV0IGl0IGNhbiBiZSBtYWRl IHJlYXNvbmFibHkgc2VjdXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IOKAlCBOZWlsPGJyPg0KJmd0 Ozxicj4NCiZndDsgJmd0OyBPbiAxNCBGZWIgMjAyMSwgYXQgMTM6NDgsIFN0b3ljaG8gU2xlcHRz b3YgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnN0b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IO+7vzxicj4NCiZndDsgJmd0OyBJIHdvdWxkIGxpa2Ug dG8gYWRkIG15IHJlYXNvbnMgYWJvdXQgdGhlICZxdW90O1doeSBhcmUgZGV2ZWxvcGVycyBjcmVh dGluZyBCRkYgZm9yIHRoZWlyIGZyb250ZW5kcyB0byBjb21tdW5pY2F0ZSB3aXRoIGFuIEFTJnF1 b3Q7LDxicj4NCiZndDsgJmd0OyB3aXRoIHRoZSBvYmplY3RpdmUgdG8gdmVyaWZ5IGlmIHRoZXkg YXJlIHZhbGlkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIG5lZWQgdGhlIGNsaWVu dCBhcHAuIHRvIGJlIGF1dGhlbnRpY2F0ZWQgYXQgdGhlIEFTICh0byBkZXRlcm1pbmUgaWYgaXQg aXMgYSBmaXJzdC1wYXJ0eSBhcHAuLCBmb3IgZXhhbXBsZSkuPGJyPg0KJmd0OyAmZ3Q7IElmIHdl IGRlY2lkZSB0byBpbXBsZW1lbnQgb3VyIGNsaWVudCBhcyBhIGZyb250ZW5kIFNQQSAsIHRoZW4g d2UgaGF2ZSBubyBvdGhlciBvcHRpb24gZXhjZXB0IHRocm91Z2ggYSBCRkYsIGFzIFBLQ0UgZG9l cyBub3QgaGVscCBmb3IgYXV0aGVudGljYXRpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IE9yIGlzIGl0IGNvbnNpZGVyZWQgYSBiYWQgcHJhY3RpY2UgdG8gZG8gdGhhdD88YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgU3RveWNoby48 YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxh IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZn dDsgRm9yZ2VSb2NrIHZhbHVlcyB5b3VyIFByaXZhY3kgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3 LmZvcmdlcm9jay5jb20veW91ci1wcml2YWN5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu Zm9yZ2Vyb2NrLmNvbS95b3VyLXByaXZhY3k8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO6PR18MB40520FF440BAD7B312B29904AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 11:40:52 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572363A07F7 for ; Sun, 14 Feb 2021 11:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rcgT3x5Oq-N for ; Sun, 14 Feb 2021 11:40:48 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D283A08C0 for ; Sun, 14 Feb 2021 11:40:19 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id n14so4786463iog.3 for ; Sun, 14 Feb 2021 11:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QH+nSfeLayWHRgnXzulxU4yKNg3oZWgXAyZMyRPXqdo=; b=Q9DQYafIJ8+Rg8BHgWxwdEHgAUMntI1hkgEelEhLcOcY27F8WFNgAbH/yLLLfpEd1L 37ASrJtxgSSBe7tf6DDswHShWjRowudw4QX4SpcRs/ufk8JVjIXDjByCK6g6oQIMRZtH eCHurym7tgMK+3O6p9EE2SrFLoYiSWaqsWT1Bqg8j3RZEWufZFR5BpPtv0x7b17o42N6 vQ/s+N3sA4Vd/oQ5SvzQhL5RWzd/XG68+tgDMuhx4qLPUhbG8SMzGIgLTJeUHa0gH+Ey Si5nJGprKEODYL+Aaac75D/JuDgfxFA9PXH/LyvozS/XvHfMTyk/im9XfNOoabwupQqu S1cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QH+nSfeLayWHRgnXzulxU4yKNg3oZWgXAyZMyRPXqdo=; b=Nno99YoqxzpLNbz28BbtsbYEwAfbXqOtOqZOxlc497jMJMAtPN9wNSto0+dRVNNWiw BXheI70cbeKRD4o+2rWK8NSvVXF/EMwEa541CtmbfrgkJnLo7j1BzXViDAZ/4KOrVp6u u6KDWhHiRRNAEmyQ+khc9SqSp3IBB23TzzetYPuTOLp7HxPvU8iYFtDjSd5AOJ6O+grI 3aCtIcEh8j9VFhN6C8mF90lYCQAfNGzi1hRKumN3AmGlaArdHq0VIzR70okxA3yzSkI1 S0xobof93EhjR9H4vPH4aHcuuvffPW3Q/BDEcDjKF4qCs7HuoeLkmLf5DnDUmHZBMrYB ig7g== X-Gm-Message-State: AOAM5339PEkrrwS8o8m2LAdWgs31EK6NTCPUEWVgY8hqGUl79S1zGoCe B0iaVASi9V6Y2iqFJ1XI1EYr+ICws39qYBLZU/3+ X-Google-Smtp-Source: ABdhPJysnAOyOgQDurWL+brEi7k6uTbp7Cd9+MW/pXQntJo7zfUtW9ysHTd2mmbmmw5q8cTBTc0MknZWEelnyE40XKw= X-Received: by 2002:a05:6638:218d:: with SMTP id s13mr12435828jaj.47.1613331618930; Sun, 14 Feb 2021 11:40:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 20:40:07 +0100 Message-ID: To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000d3cd705bb510ac6" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 19:40:51 -0000 --0000000000000d3cd705bb510ac6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That only applies to third party cookies, it shouldn't affect third-party iframes as far as I'm aware. So unless we expect those to break, we probably shouldn't include that as a driving use case. Is there another measure that would be relevant here? Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci wrote: > ITP, for example > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 04:54 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measur= es > make it problematic. > > Which new browser measures? > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > > - For UI related functionality, i.e. document selection, user profile > display/changes, contact updates, etc... You should be able to execute= the > client side *silent authentication* using the provided session token > from the Azure AD AS, without needing to make any RO api calls nor use= r > redirects. > > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measur= es > make it problematic. In code+PKCE you can use a refresh token, but see th= e > other reply for how this proposal is an alternative to that in some > situations. This answer was specifically on why having backend-issued > tokens didn=E2=80=99t apply to this scenario. > > > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 03:48 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > For UI related functionality, i.e. document selection, user profile > display/changes, contact updates, etc... You should be able to execute th= e > client side *silent authentication* using the provided session token from > the Azure AD AS, without needing to make any RO api calls nor user > redirects. For RO responsibilities, you can present the user with a butto= n > "Grant RO access to Azure resources" button and the user will go through = a > permission scope elevation flow, again no reason to need a BFF here. > > > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > It may make sense for the app to have an error message, or even better > might be a 302 *Location header* depending on what you are doing. There > is nothing here that is OAuth specific however (nor common), and then we > should challenge the need to directly provide an RFC recommendation for > handling this. > > > > *Error! Filename not specified.* > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > Hi Neil, > > Thanks for the prompt comments! > > - Re: GET vs POST, > > personally I=E2=80=99d be fine with restricting to POST. > > > > - Re: RO-AS, interaction- > > perhaps it is not very clear from the text at the moment (first draft), > but that is assumed that the RO went thru whatever interactive steps are > necessary to establish a session (eg sign in, assuming the AS is say an > OIDC provider) and obtain beforehand the access token and refresh tokens > that will be needed during the app activities taking place after that. I= n > concrete terms, imagine that the backend performs an authorization code > grant requesting an IDtoken, access token and refresh token BEFORE the > activities described in TMI-BFF take place. > > The current language trying to express that is in 1.2: > > As a prerequisite for the flow described below, the backend MUST have > established a secure session with the user agent, so that all requests fr= om > that user agent toward the backend occur over HTTPS and carry a valid > session artifact (such as a cookie) that the backend can validate. This > document does not mandate any specific mechanism to establish and maintai= n > that session. > > And > > cached, it requests to the authorization server a new access token with > the required characteristics, using any artifacts previousy obtained (eg > refresh token) and grants that will allow the authorization server to iss= ue > the requested token without requiring user interaction. > > > > - If the backend is already implicitly trusted then couldn=E2=80=99t = you skip > OAuth and just get the backend to issue short-lived JWTs to the fronte= nd > that it can use for API access? > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > - If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoi= nt > URI that the SPA then navigates the user to. (Eg the backend can do a = PAR > request first and return a URI that references that so that authorizat= ion > details aren=E2=80=99t passed through the frontend). > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > > > *From: *OAuth on behalf of Neil Madden < > neil.madden@forgerock.com> > *Date: *Sunday, February 14, 2021 at 00:17 > *To: *Vittorio Bertocci > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > I have a lot of security concerns about this draft. > > > > The draft alludes to security issues associated with handling access > tokens in the frontend but never really spells them out. From the Securit= y > Considerations it seems that the primary concern is with theft of access > tokens from local storage. To do this you=E2=80=99d need an XSS attack. B= ut in that > case, wouldn=E2=80=99t the attacker simply use the XSS to make a call to = the > bff-token endpoint instead? > > > > The combination of the bff-token endpoint recommending the use of GET > requests together with the hint to use cookie-based authentication is > likely going to punch a hole in most CSRF defenses, which assume that GET= s > are safe. The only thing preventing this being exploitable is Cross-Origi= n > Read Blocking ( > https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md) > due to the JSON content-type. That makes me really nervous. We should at > least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel > more comfortable if this was a POST request only. > > > > As Stoycho Sleptsov mentioned in the other email, the lack of > front-channel communication between the AS and the RO seems odd. If the > backend is already implicitly trusted then couldn=E2=80=99t you skip OAut= h and just > get the backend to issue short-lived JWTs to the frontend that it can use > for API access? > > > > If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoint > URI that the SPA then navigates the user to. (Eg the backend can do a PAR > request first and return a URI that references that so that authorization > details aren=E2=80=99t passed through the frontend). > > > > =E2=80=94 Neil > > > > > > On 12 Feb 2021, at 20:46, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For > Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: > https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate acce= ss > token acquisition to a backend component. In so doing, the fronten= d > can access resource servers directly without taking on the burden o= f > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges whe= n > executed in a user agent, but are safe and well proven when execute= d > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0000000000000d3cd705bb510ac6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That only applies to third party cookies, it shouldn't= affect third-party iframes as far as I'm aware. So unless we expect th= ose to break, we probably shouldn't include that=C2=A0as a driving use = case. Is there another measure that would be relevant here?

<= p dir=3D"ltr" style=3D"line-height:1.2;border-left:solid #ffffff 1pt;border= -right:solid #ffffff 1pt;border-top:solid #ffffff 1pt;border-bottom:solid #= ffffff 1pt;margin-top:0pt;margin-bottom:0pt">

Warren Parad

Founder, CTO

Secure your user data and complete your authorization architecture. Implem= ent=C2=A0Authress.


On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bert= occi <vittorio.bertocci=3D= 40auth0.com@dmarc.ietf.org> wrote:

ITP, for example

=C2=A0

From: = Warren Parad <wpar= ad=3D40rhos= ys.ch@dmarc.ietf.org>
Date: Sunday, February 14, 2021 at 04:54
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Can you expand on what silent authentication and ses= sion token stands for here? If you are referring to the iframe scenario, th= e new browser measures make it problematic.

Which new browser measures?


3D"Image

Warren Parad

Founder, CTO=

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci &l= t;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

  • For UI related functionality, i.e. document selection, user profile display= /changes, contact updates, etc... You should be able to execute the client = side silent authentication=C2=A0using the provided session token from the= Azure AD AS, without needing to make any RO api calls nor user redirects.= =C2=A0

Can you expand on what silent authentication and ses= sion token stands for here? If you are referring to the iframe scenario, th= e new browser measures make it problematic. In code+PKCE you can use a refresh token, but see the other reply for how this proposal= is an alternative to that in some situations. This answer was specifically= on why having backend-issued tokens didn=E2=80=99t apply to this scenario.=

=C2=A0

=C2=A0

From: Warren Parad <wpar= ad=3D40rhos= ys.ch@dmarc.ietf.org>
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine= we=E2=80=99re talking about a SPA application that signs in users using Az= ure AD, and needs to call Office and Azure APIs. The SPA backend cannot iss= ue tokens for those APIs, it can only request them to the Azure AD AS.

=C2=A0

For UI related functionality, i.e. document selectio= n, user profile display/changes, contact updates, etc... You should be able= to execute the client side silent authentication=C2=A0using the provided session token from the= Azure AD AS, without needing to make any RO api calls nor user redirects.= =C2=A0For RO responsibilities, you can present the user with a button "= ;Grant RO access to Azure resources" button and the user will go through=C2=A0a permission scope elevation flow, again no = reason to need a BFF here.

=C2=A0

We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client off= ers an endpoint that is guaranteed to initiate a sign in flow (hence inject= all the necessary nonces etc). We didn=E2=80=99t add it upfront and left i= t as exercise for the reader mostly because it=E2=80=99s not easy to model properly and before opening that work front= we wanted to see how the idea was received.=C2=A0=C2=A0

It may make sense for the app to have an error messa= ge, or even better might be a 302 Location header=C2=A0depending on what you are doing. There is nothi= ng here that is OAuth specific however (nor common), and then we should cha= llenge the need to directly provide an RFC recommendation for handling this= .

=C2=A0

Error! Filenam= e not specified.

Warren Parad

Founder, CTO

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci &= lt;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Hi Neil,

Thanks for the prompt comments!

  • Re: GET vs POST,

personally I=E2=80=99d be fine with restricting to POST.

=C2=A0

  • Re: RO-AS, interaction-

perhaps it is not very clear from the text at the mo= ment (first draft), but that is assumed that the RO went thru whatever inte= ractive steps are necessary to establish a session (eg sign in, assuming the AS is say an OIDC provider) and obtain beforehan= d the access token and refresh tokens that will be needed during the app ac= tivities taking place after =C2=A0that. In concrete terms, imagine that the= backend performs an authorization code grant requesting an IDtoken, access token and refresh token BEFORE the act= ivities described in TMI-BFF take place.

The current language trying to express that is in 1.= 2:

As a prerequ= isite for the flow described below, the backend MUST have established a secure session with the user agent, so that all requests from that user = agent toward the backend occur over HTTPS and carry a valid session artifac= t (such as a cookie) that the backend can validate. This document does not = mandate any specific mechanism to establish and maintain that session.

And

cached, it r= equests to the authorization server a new access token with the required characteristics, using any artifacts previousy obtained (eg refresh token)= and grants that will allow the authorization server to issue the requested= token without requiring user interaction.

=C2=A0

  • =C2=A0If the backend is already implicitly tru= sted then couldn=E2=80=99t you skip OAuth and just get the backend to issue= short-lived JWTs to the frontend that it can use for API access?

    • For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine= we=E2=80=99re talking about a SPA application that signs in users using Az= ure AD, and needs to call Office and Azure APIs. The SPA backend cannot iss= ue tokens for those APIs, it can only request them to the Azure AD AS.

    =C2=A0

    • If you want to allow auth code flow etc then perhaps the bff-token endpoint= can return a standard error code with an authorization endpoint URI that t= he SPA then navigates the user to. (Eg the backend can do a PAR request fir= st and return a URI that references that so that authorization details aren=E2=80=99t passed through the front= end).=C2=A0

    We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client off= ers an endpoint that is guaranteed to initiate a sign in flow (hence inject= all the necessary nonces etc). We didn=E2=80=99t add it upfront and left i= t as exercise for the reader mostly because it=E2=80=99s not easy to model properly and before opening that work front= we wanted to see how the idea was received. =C2=A0

    =C2=A0

    From: OAuth <oauth-bounces@ietf.org= > on behalf of Neil Madden <neil.madden@forgerock.com>
    Date: Sunday, February 14, 2021 at 00:17
    To: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>= ;
    Cc: "oauth@= ietf.org" <= oauth@ietf.org>
    Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

    =C2=A0

    I have a lot of security concerns about this draft.= =C2=A0

    =C2=A0

    The draft alludes to security issues associated with= handling access tokens in the frontend but never really spells them out. F= rom the Security Considerations it seems that the primary concern is with theft of access tokens from local storage. To do t= his you=E2=80=99d need an XSS attack. But in that case, wouldn=E2=80=99t th= e attacker simply use the XSS to make a call to the bff-token endpoint inst= ead?=C2=A0

    =C2=A0

    The combination of the bff-token endpoint recommendi= ng the use of GET requests together with the hint to use cookie-based authe= ntication is likely going to punch a hole in most CSRF defenses, which assume that GETs are safe. The only thing preventing = this being exploitable is Cross-Origin Read Blocking (https://chromium.googlesourc= e.com/chromium/src/+/master/services/network/cross_origin_read_blocking_exp= lainer.md) due to the JSON content-type. That makes me really nervous. We should at l= east mandate X-Content-Type-Options: nosniff on that response. I=E2=80=99d = feel more comfortable if this was a POST request only.=C2=A0<= /p>

    =C2=A0

    As Stoycho Sleptsov mentioned in the other email, th= e lack of front-channel communication between the AS and the RO seems odd. = If the backend is already implicitly trusted then couldn=E2=80=99t you skip OAuth and just get the backend to issue short-li= ved JWTs to the frontend that it can use for API access?

    =C2=A0

    If you want to allow auth code flow etc then perhaps= the bff-token endpoint can return a standard error code with an authorizat= ion endpoint URI that the SPA then navigates the user to. (Eg the backend can do a PAR request first and return a URI that refer= ences that so that authorization details aren=E2=80=99t passed through the = frontend).=C2=A0

    =C2=A0

    =E2=80=94 Neil

    =C2=A0

    =C2=A0

    On 12 Feb 2021, at 20:4= 6, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=

    =EF=BB=BFDear all,
    Brian and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and persist= ence to its backend, and request such tokens when needed for direct access = of protected resources from the frontend code.

    The pattern is already in use, in proprietary form, by various modern devel= opment stacks, such as Next.JS. Variants of the pattern, often discussed un= der the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=E2=80=99s activity, but always left all implementation details to the reader.
    We believe the pattern has merit, as corroborated by its growing adoption. = By delegating access token acquisition to the backend, we avoid many of the= often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend from the need of persisting tokens= in local storage, a well known sore point of using OAuth directly in JavaS= cript, by relying on its backend storage and session to preserve tokens.
    Although the specification is very simple, providing explicit guidance on t= he scenario offers many advantages. =C2=A0
    - It makes it possible to create interoperable SDKs, where frontend dev sta= cks (any JS flavor) can be mixed and matched with compliant backend stacks = (middlewares in node, java, ASP.NET, PHP etc)
    - It allows us to provide guidance on how to properly tackle the scenario a= nd warn implementers against security risks (scope escalations, using IDtok= ens instead of access tokens, etc)
    - It allows us to discuss (and when appropriate, promote) this pattern as p= art of the browser apps security guidance, and position the scenario where = frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern
    - This approach makes mocking and testing apps very easy, possibly preventi= ng developers from weakening the security of their system (eg turning on RO= PG options) =C2=A0or turning to risky practices like scraping

    Needless to say, this specification doesn=E2=80=99t entirely eliminate the = risks inherent to direct use of access tokens from a browser. But reality i= s that the pattern is in widespread use, and the circumstances leading to t= hat (eg developers on a particular project only work with frontend stacks; components like reverse proxies might not = always be viable; etc) aren=E2=80=99t going away any time soon. By providin= g simple guidance on this pattern, we can simplify the life of many develop= ers while enshrining basic security hygiene in scenarios that would have otherwise be left to their own device.

    Looking forward for your feedback!

    B&V =C2=A0

    =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org= > wrote:


    =C2=A0=C2=A0=C2=A0A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.tx= t
    =C2=A0=C2=A0=C2=A0has been successfully submitted by Vittorio Bertocci and = posted to the
    =C2=A0=C2=A0=C2=A0IETF repository.

    =C2=A0=C2=A0=C2=A0Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bertocci-oauth2-tm= i-bff
    =C2=A0=C2=A0=C2=A0Revision: =C2=A0 =C2=A000
    =C2=A0=C2=A0=C2=A0Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Token Mediating and ses= sion Information Backend For Frontend
    =C2=A0=C2=A0=C2=A0Document date: =C2=A0 =C2=A02021-02-12
    =C2=A0=C2=A0=C2=A0Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission =C2=A0=C2=A0=C2=A0Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A016
    =C2=A0=C2=A0=C2=A0URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://www.ietf.org/archive/id/draf= t-bertocci-oauth2-tmi-bff-00.txt
    =C2=A0=C2=A0=C2=A0Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/" = target=3D"_blank">https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tm= i-bff/
    =C2=A0=C2=A0=C2=A0Html: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0https://www.ietf.org/archive/id/draft-ber= tocci-oauth2-tmi-bff-00.html
    =C2=A0=C2=A0=C2=A0Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


    =C2=A0=C2=A0=C2=A0Abstract:
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This document describes how a JavaScrip= t frontend can delegate access
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0token acquisition to a backend componen= t.=C2=A0 In so doing, the frontend
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0can access resource servers directly wi= thout taking on the burden of
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0communicating with the authorization se= rver, persisting tokens, and
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0performing operations that are fraught = with security challenges when
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0executed in a user agent, but are safe = and well proven when executed
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0by a confidential client running on a b= ackend.




    =C2=A0=C2=A0=C2=A0Please note that it may take a couple of minutes from the= time of submission
    =C2=A0=C2=A0=C2=A0until the htmlized version and diff are available at tools.ietf.org.

    =C2=A0=C2=A0=C2=A0The IETF Secretariat



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


    ForgeR= ock values your Privac= y

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

--0000000000000d3cd705bb510ac6-- From nobody Sun Feb 14 11:45:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5783A0812 for ; Sun, 14 Feb 2021 11:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI7F5JmGxS9j for ; Sun, 14 Feb 2021 11:45:33 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2EF3A0813 for ; Sun, 14 Feb 2021 11:45:32 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id z63so735574wmg.4 for ; Sun, 14 Feb 2021 11:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=LuHdtQ3NYyPfFHsixqXGZ5578XJMCds7J1Gdsoorn3k=; b=m50iSyO9HYj5uYk6ihB1sru1ee5uZI9EMJSw4YVKMIe7vCKo3YUBwh4iPmMP1idTtF 7o1JAtYLi7TiaDTIcRf7ccZI/2BZhw2Pkp1MVBDwSZqEu1Kb9F3/xWfEcklGQ+0RhW5F fZsg1LcTPQdN27yqjURVYX/FkzFdATmNEYdXB3tgk3g2oYGG5PwY7Xc2LtQ1Ondp8sAA CrWVg3/mHqdvJXKxScgY22RPGzdTcxwG7ky0RZ6SYLu85twoPM9ntQn4LwYHqNoDFM7J qdvvJWZGs2XDkBsWsZxt8SWMaowH1KcUrMatAOuhqv5gPKQFG76SLurW9/XjuqfLqzta +3QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=LuHdtQ3NYyPfFHsixqXGZ5578XJMCds7J1Gdsoorn3k=; b=XfcPXfGNS1e9gda6kp+tcXzQKpx1s5HHq3bhdQ7fvm1LYrc4FxK6jDH+14+UwnWk+m af4UIm13WCyfywbZF+rUs7Ec2jre+d/6jaLUA+yrW6X6GHa01EeVG0XDKnWOxvczIi4p wiIvpTaoPHvjYwcDE4yIzNrlBnWxXqXd7b0cNGgvkxMi6icfC1Hstc3wBqbbsdSggiPq xJtdBmiIpvH2fqCUdX0OeJdDr7c4isNhz1r5X93SkmCZnIO7wScTy5u0PX5uebbKg+wv tXbisOO1VgdqCMMvLxaUEf98olQ4DykRlHyXUFbpDBryC/LpsD2dC3cZykpeMxn6Zma0 TyWg== X-Gm-Message-State: AOAM5335vqOvUs0y7IJ1vPtXPhbinL74O2rSPlF0DN0KCgS2KhSpYP8Z 4RqyAdByJcWFCHcQTQh6fA4pQg== X-Google-Smtp-Source: ABdhPJzbtDRiJWOSx1TiJRBG4r09UMguhqYiTPcreD3Uax/P3SNVZsWzJ9vmNecXj2gnd9mbic2ZkA== X-Received: by 2002:a1c:2d47:: with SMTP id t68mr11548611wmt.189.1613331930714; Sun, 14 Feb 2021 11:45:30 -0800 (PST) Received: from ?IPv6:2003:eb:8f06:1195:d91d:452f:bcb6:713b? (p200300eb8f061195d91d452fbcb6713b.dip0.t-ipconnect.de. [2003:eb:8f06:1195:d91d:452f:bcb6:713b]) by smtp.gmail.com with ESMTPSA id f7sm20440224wre.78.2021.02.14.11.45.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Feb 2021 11:45:30 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-8E1CAFC6-27B4-4EF6-8501-AA1DFB03DCFA; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 14 Feb 2021 20:45:28 +0100 Message-Id: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> References: Cc: oauth@ietf.org, Brian Campbell In-Reply-To: To: Vittorio Bertocci X-Mailer: iPad Mail (18D52) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 19:45:36 -0000 --Apple-Mail-8E1CAFC6-27B4-4EF6-8501-AA1DFB03DCFA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Vittorio, thanks for the explanation. Do you assume the frontend passes the code or in= itial refresh token to the backend using an application specific mechanism? W= hy isn=E2=80=99t this part of the bff-token request? best regards, Torsten. > Am 14.02.2021 um 20:19 schrieb Vittorio Bertocci : >=20 > =EF=BB=BFHi Torsten, thanks for looking into this! > The idea is that the application backend performed all the interactive tok= en acquisition steps before TMI-BFF come into play. > Imagine that a regular web app performs an authorization code grant, reque= sting access token and refresh token in the process (and often also setting i= ts own session with the user agent in the process, if the AS is also their I= dP via OIDC or similar, but that's not strictly necessary). Now the app back= end has an access token and refresh token persisted on the server side. > All TMI-BFF does is to describe how the backend can share those tokens wit= h its fronted, either directly (if the persisted AT is still valid) or indir= ectly (if it has to use an RT to obtain a new AT before sending it back). > The frontend provides resource and scope to select what token it needs, bu= t the current idea is that the backend already obtained both consent and art= ifacts to obtain those tokens from the AS. And if it doesn't, at the moment w= e simply fail and expect the app developer to take the steps required to pro= mpt the user with whatever is necessary for updating the backend with the ri= ght permissions, eg creating a new authorization request asking for a scope t= he frontend needs and that the user wasn't prompted to consent yet. At the m= oment TMI-BFF does not provide a mechanism for that prompt to occur, it just= errors out saying "you've got to update your authorization artifacts befor= e the frontend can get the token w the scopes it needs". > Another way to think about this: in TMI-BFF the frontend treats the backen= d is a tokens database. Indicating the resource and scopes is a query. If th= e backend can serve that query (with the ATs it saved, or by using the RTs i= t saved AND the grants the user already gave) it returns a token. If it does= n't, it fails the query. The frontend does not play a direct role into inser= ting in the DB more tokens. That is left to the backend, that can do so by i= nitiating a new authorization grant, not described in TMI-BFF, that must con= clude successfully for the frontend to be able to repeat its query and this t= ime get the token they want out. Note that the backend might decide that it w= on=E2=80=99t try to get the token requested, or it might unable to do so (eg= the user/app cannot meet some requirements as the AS is concerned), hence t= he request of it might at times be permanently denied. This last part is to s= ay that providing in the error message details about the remediation might t= ake more work than one realizes at first, and ultimately acting on the error= situation to retrieve a new token is still up to the backend anyway, hence p= roviding elaborate machinery to inform the frontend beyond the error situati= on might not be as effective as it might look at first glance. I am totally o= pen to it, just making sure we understand what it can buy us. =20 >=20 > =EF=BB=BFOn 2/14/21, 06:11, "Torsten Lodderstedt" wrote: >=20 > Hi, >=20 > I=E2=80=99m trying to understand your proposal.=20 >=20 > Section 1.2, bullet (B) states >=20 > (B) If the backend does not already have a suitable access token > obtained in previous flows and cached, it requests to the > authorization server a new access token with the required > characteristics, using any artifacts previousy obtained (eg > refresh token) and grants that will allow the authorization serve= r > to issue the requested token without requiring user interaction. >=20 > Can you please explain how the authorization process works towards the A= S, especially in case of the authorisation code grant type. I would have exp= ected to frontend to pass an authorisation code to the bff-token request.=20= >=20 > But section 4.1. only defines the parameters =E2=80=9Eresource" and =E2= =80=9Escope" for the bff-token endpoint.=20 >=20 > thanks, > Torsten.=20 >=20 >> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci : >>=20 >> Dear all, >> Brian and yours truly are proposing a new specification that shows how th= e user agent frontend of a web app can delegate token acquisition and persis= tence to its backend, and request such tokens when needed for direct access o= f protected resources from the frontend code. >>=20 >> The pattern is already in use, in proprietary form, by various modern dev= elopment stacks, such as Next.JS. Variants of the pattern, often discussed u= nder the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=E2=80=99s activity, but always left all implementation d= etails to the reader. >> We believe the pattern has merit, as corroborated by its growing adoption= . By delegating access token acquisition to the backend, we avoid many of th= e often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend f= rom the need of persisting tokens in local storage, a well known sore point o= f using OAuth directly in JavaScript, by relying on its backend storage and s= ession to preserve tokens. >>=20 >> Although the specification is very simple, providing explicit guidance on= the scenario offers many advantages. =20 >> - It makes it possible to create interoperable SDKs, where frontend dev s= tacks (any JS flavor) can be mixed and matched with compliant backend stacks= (middlewares in node, java, ASP.NET, PHP etc) >> - It allows us to provide guidance on how to properly tackle the scenario= and warn implementers against security risks (scope escalations, using IDto= kens instead of access tokens, etc) >> - It allows us to discuss (and when appropriate, promote) this pattern as= part of the browser apps security guidance, and position the scenario where= frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern >> - This approach makes mocking and testing apps very easy, possibly preven= ting developers from weakening the security of their system (eg turning on R= OPG options) or turning to risky practices like scraping >>=20 >> Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks inherent to direct use of access tokens from a browser. But reality i= s that the pattern is in widespread use, and the circumstances leading to th= at (eg developers on a particular project only work with frontend stacks; co= mponents like reverse proxies might not always be viable; etc) aren=E2=80=99= t going away any time soon. By providing simple guidance on this pattern, we= can simplify the life of many developers while enshrining basic security hy= giene in scenarios that would have otherwise be left to their own device. >>=20 >> Looking forward for your feedback! >>=20 >> B&V =20 >>=20 >> =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" wrote: >>=20 >>=20 >> A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt >> has been successfully submitted by Vittorio Bertocci and posted to the >> IETF repository. >>=20 >> Name: draft-bertocci-oauth2-tmi-bff >> Revision: 00 >> Title: Token Mediating and session Information Backend For Front= end >> Document date: 2021-02-12 >> Group: Individual Submission >> Pages: 16 >> URL: https://www.google.com/url?q=3Dhttps://www.google.com/u= rl?q%3Dhttps://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt%= 26source%3Dgmail-imap%26ust%3D1613767591000000%26usg%3DAOvVaw3Rb-S0l6cEv0ytj= DxtYLAP&source=3Dgmail-imap&ust=3D1613935165000000&usg=3DAOvVaw3p5263a_rEePN= bnX7jWFjq >> Status: https://www.google.com/url?q=3Dhttps://www.google.com/u= rl?q%3Dhttps://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/%26sou= rce%3Dgmail-imap%26ust%3D1613767591000000%26usg%3DAOvVaw3-qg5MDtY7kD1HpR5jR2= QY&source=3Dgmail-imap&ust=3D1613935165000000&usg=3DAOvVaw1YZmVHpENHa-bqqtbe= zRpa >> Html: https://www.google.com/url?q=3Dhttps://www.google.com/u= rl?q%3Dhttps://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html= %26source%3Dgmail-imap%26ust%3D1613767591000000%26usg%3DAOvVaw05WK4GSEKcWjZz= Nhvb1p5d&source=3Dgmail-imap&ust=3D1613935165000000&usg=3DAOvVaw2HibfQtTYv3t= alGT379MOu >> Htmlized: https://www.google.com/url?q=3Dhttps://www.google.com/u= rl?q%3Dhttps://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00%26source= %3Dgmail-imap%26ust%3D1613767591000000%26usg%3DAOvVaw0qm45MWGbZf0zbBjZj3ggz&= source=3Dgmail-imap&ust=3D1613935165000000&usg=3DAOvVaw0gZZ0ZU8QVx7OBjxDcG8d= - >>=20 >>=20 >> Abstract: >> This document describes how a JavaScript frontend can delegate acces= s >> token acquisition to a backend component. In so doing, the frontend= >> can access resource servers directly without taking on the burden of= >> communicating with the authorization server, persisting tokens, and >> performing operations that are fraught with security challenges when= >> executed in a user agent, but are safe and well proven when executed= >> by a confidential client running on a backend. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submi= ssion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.google.com/url?q=3Dhttps://www.google.com/url?q%3Dhttps://www= .ietf.org/mailman/listinfo/oauth%26source%3Dgmail-imap%26ust%3D1613767591000= 000%26usg%3DAOvVaw1Bfu9fJ2Fj_BZJ3H9yw7od&source=3Dgmail-imap&ust=3D161393516= 5000000&usg=3DAOvVaw3a73buBtPOBoDQ3SMH_XJW >=20 >=20 --Apple-Mail-8E1CAFC6-27B4-4EF6-8501-AA1DFB03DCFA Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjE0MTk0NTI4WjAvBgkqhkiG9w0BCQQxIgQg Q+/5k88mVyLOCRliXUX9Ie8xjsSkc2K3k10/AZKn/ZUwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAX8pgBu2KwkWg9zEPM7dgDDraF/iodN2v0rkADMKmk79f3TN4bGAV WxkRYKALSHqd5/ICOAyXvppzSNr1k9WnpqBpvAhU4HzbwZAl4Y2jfuGc0nAtFqWmgFSLLCmm3b4/ olM+sOP3CBJgp7J1tG+rH9vmprFzWYhFcup7n3h7eUIgonOLhMBvkLSwoZ9/1mZYDDUKe6PGiYfd NtqGGQvrqzoZSjOzDmqQB78hB/3dAugMsLGcYnP8SpVE4ks/5N3iSMYY5Eq+J8/yCKtBARkpJYEE IB0SZRgL1qf95t263pdKZytSaFdpbJ0nuq2cEpY6GRCuokenS8ehCDQs5GOBBgAAAAAAAA== --Apple-Mail-8E1CAFC6-27B4-4EF6-8501-AA1DFB03DCFA-- From nobody Sun Feb 14 11:57:23 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104FD3A08E4 for ; Sun, 14 Feb 2021 11:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI8QfA30cSaf for ; Sun, 14 Feb 2021 11:57:19 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375123A08BE for ; Sun, 14 Feb 2021 11:57:18 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id i8so478563iog.7 for ; Sun, 14 Feb 2021 11:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5XtbkUdg6z2XAr3UyKasHNWvq5cIlmjnotyYkMoXpO0=; b=Fi0nAYPoWalocQxHGuHcAQikzQyxlzH10/WGxX9Tk35Yb4cc+zVjwSywemQXECnu4Q dypqZUYUzXjGh9wIzgT6drUf0XcEPNMVLxXG30+cpm9cHPCQb8FDrjRScEDAPpOCSuFS ttED85XZyU8M7dgoG9rfTMpPxiO9WiDvM3jmB8WrNdH58PCHKp8z1QJETrwjsC96sJA0 DCR3pKjwwWebpesSDn+AtUmytrxCubmply5edTOUr1Y7wQn0tU3oOJ5oZvdKufx2Nyrx QTHIuCdgfdw9rG4l5v/NWlhYEhhrkcYtxPODa2+SpqHSqaP4B2TvekJENbhXVdTXDlXK rkaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5XtbkUdg6z2XAr3UyKasHNWvq5cIlmjnotyYkMoXpO0=; b=AcDDN2z6oX61EeOghbhQp8ZRhzcY3QC43ls2veJxhL8XkTT87GBElbfoZLOpZvBNmk 0BjqEYeWt3y0J/z00dW/n91iwOaDhvlTPnDxUsg1HjSH/YotHb8ZeENOYdf1JXo/osop Asw3V3uHa6jrWCdfzHY70toKelMjMl9916Hteo8u7LjTgrumUIcsJWT8v7sxFWTMYsGq i6b/DYIrHPx5Xq5y5WifO9OgX3NsIWKv8gQtjT9ZQy0fytMOZcUQ2FJvMwoGwZaAqgZ5 3CmMWlMRgS9FHctAWznu2yl501MCp8cW0Fy/+cMjupN6L0+kIrpxgjVJkmUH9HDvbVbQ NNgg== X-Gm-Message-State: AOAM532eRbOlapvjjtKnpoQYRV9F2mvQSTe5No/8s/ceSndm9WQaHA9g lDLHL252ro1Dq2LJU2w4TMKtKnlezvM7QFSQjPs3 X-Google-Smtp-Source: ABdhPJxzuCD1T5UWoKo/9hM4GKBjWjfdTZ0C6hrQ77LrYHico9Ac5R2uPIlk8NnYu7F9dXqKifABz/fvzKC+npcYAPY= X-Received: by 2002:a5d:93d4:: with SMTP id j20mr9647491ioo.41.1613332638188; Sun, 14 Feb 2021 11:57:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 20:57:07 +0100 Message-ID: To: Vittorio Bertocci Cc: Stoycho Sleptsov , Neil Madden , oauth Content-Type: multipart/alternative; boundary="000000000000cdd9de05bb5146d5" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 19:57:22 -0000 --000000000000cdd9de05bb5146d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > but it does make things simpler for the frontend developer and requires > less advanced capabilities in the AS. I guess I'm still getting lost on this point, which seems not yet justified for me. What is the frontend developer doing any different in the new hypothetical world than they would be, right now they are including an SDK and writing one line of code on login redirect/silent auth and one line of code for PKCE+code validation. If a service client needs to be authorized there would be a third line of code to call the backend. These three lines still need to be present irrespective of whether you use an AS-proxy TMI-BFF or the AS directly. Except now we are encouraging every app to write a BFF and integrate their front channel with it. Additionally, we aren't requiring less capabilities from the spec, we are just also requiring additional ones for a BFF. If there are capabilities this lets us drop from OAuth could you explain which ones those are, because since an AS can't know whether "customers" are going to want to use a BFF or not, it will still have to implement all the necessary AS features that already exist (and the new ones that don't). I don't see how this affords an AS any additional freedom. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress . On Sun, Feb 14, 2021 at 8:39 PM Vittorio Bertocci < vittorio.bertocci@auth0.com> wrote: > In the TMI-BFF topology, the backend and frontend developer are the same > person. The operations TMI-BFF describes are the functional equivalent of > what the JS code of one SPA app using a code+PKCE SDK would do when > retrieving previously obtaining tokens from the store in order to perform > an API call. Whereas such an app would make that call in memory (and resu= lt > in the same operations described here, either use a previously saved acce= ss > token matching the requirements of the API call, or use artifacts like RT= s > to request a new access token matching the request) in TMI-BFF al the log= ic > and persistence layer are in the backend, hence that query becomes a > request to the backend instead of a local function call. > > The advantages have been described in other branches of this thread, but > TL;DR- a lot of the token requesting work can be performed more reliably > (eg less things can go wrong) from a confidential client and it=E2=80=99s= easier > for SDK developers to package it (see existing middlewares vs JS SDKs). > Note that for the app developer this might still look like the same flow, > asking a JS SDK to get the token the app needs to call an API, but the JS > SDK would be dramatically simpler than the one performing code+PKCE in th= e > user agent and entail communication between frontend a backend, hence the > need to define how that communication happens if we want developers to be > able to mix and match frontend and backend dev stacks. > > Again, this does not necessarily add security to the code+PKCE in the use= r > agent model (which remains the only game in town for backendless SPAs), b= ut > it does make things simpler for the frontend developer and requires less > advanced capabilities in the AS. > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 09:45 > *To: *Stoycho Sleptsov > *Cc: *Neil Madden , Vittorio Bertocci < > vittorio.bertocci@auth0.com>, oauth > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > Correct it would never need to be used to authenticate a client, as a > client is always offline and can directly use the backchannel. You would > never need the front channel to authenticate a client, however you might > need the front channel to authorize a client to access user resources > offline. Is that what you are talking about, i.e. the offline refresh_tok= en > authorization code flow? > > > > If yes, then the standard would be to use the authorization code flow > requesting as you've mentioned. Although that flow already exists and wel= l > established, and without any issues, having a standard specifying how to > communicate with the client doesn't seem to be useful, as you only need t= o > pass an *auth code* and the *issuer* to the client. But since these > endpoints are never exposed nor need to have interoperability between > different owners (i.e. the owner of the front-channel is different from t= he > owner of the back-channel), what's the benefit of specifying the explicit > endpoints necessary for the BFF to have? > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sleptsov < > stoycho.sleptsov@gmail.com> wrote: > > Thanks Warren, > > > > as I see you and Neil have the same idea, > > but as of this moment I think this method is not a valid option for > authenticating > > a client according to the draft-ietf-oauth-v2-1. > > > > On the other hand, authenticating the client through the BFF > > seems conforming to the spec., but in the case when the access token is > used > > in the browser in fact, I am afraid that it can be regarded as > > some kind of "deception" of the AS. > > > > It seems the frontend SPA is not the easiest way to go with oauth... > > > > Stoycho. > > > > On Sun, 14 Feb 2021 at 17:35, Warren Parad wrote: > > redirect_uri and use PKCE via the code verifier. > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov < > stoycho.sleptsov@gmail.com> wrote: > > Thanks a lot for your answer Neil, > > as I am no expert (yet :-)) in security I was afraid to rely on > redirect_uri for authentication of the client, > but I will consider that option as more trustworthy now. > > (it is also not very clear for me which part of the app can be > regarded as the redirect_uri owner, the BFF or the loaded frontend > SPA, but maybe it is not so important) > > If you had the two options for authentication of the frontend SPA > client - the redirect_uri on the one hand, and the Basic > authentication with client secret through the BFF on the other, which > one would you recommend? > > On Sun, 14 Feb 2021 at 16:28, Neil Madden > wrote: > > > > Public clients are implicitly authenticated by their ownership of the > registered redirect_uri. This why it=E2=80=99s important to use a redirec= t_uri for > which ownership can be reasonably established, such as HTTPS endpoints wi= th > exact URI matching. > > > > There are more things that can go wrong with that (see the security > BCP), but it can be made reasonably secure. > > > > =E2=80=94 Neil > > > > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov > wrote: > > > > > > =EF=BB=BF > > > I would like to add my reasons about the "Why are developers creating > BFF for their frontends to communicate with an AS", > > > with the objective to verify if they are valid. > > > > > > I need the client app. to be authenticated at the AS (to determine if > it is a first-party app., for example). > > > If we decide to implement our client as a frontend SPA , then we have > no other option except through a BFF, as PKCE does not help for > authentication. > > > > > > Or is it considered a bad practice to do that? > > > > > > Regards, > > > Stoycho. > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > ForgeRock values your Privacy > > --000000000000cdd9de05bb5146d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
but it d= oes make things simpler for the frontend developer and requires less advanc= ed capabilities in the AS.
I guess I'm still getting lost o= n this point, which seems not yet justified for me. What is the frontend de= veloper doing any different in the new hypothetical world than they would b= e, right now they are including an SDK and writing one line of code on logi= n redirect/silent auth and one line of code for PKCE+code validation. If a = service client needs to be authorized there would be a third line of code t= o call the backend. These three lines still need to be present irrespective= of whether you use an AS-proxy TMI-BFF or the AS directly. Except now we a= re encouraging every app to write a BFF and integrate their front channel w= ith it.

Additionally, we aren't requiring less capab= ilities from the spec, we are just also requiring additional ones for a BFF= . If there are capabilities this lets us drop from OAuth could you explain = which ones those are, because since an AS=C2=A0can't know whether "= ;customers" are going to want to use a BFF or not, it will still have = to implement all the necessary AS features that already exist (and the new = ones that don't). I don't see how this affords an AS any additional= freedom.

Secure your user data and complete your= authorization architecture. Implement=C2=A0Authress.


On S= un, Feb 14, 2021 at 8:39 PM Vittorio Bertocci <vittorio.bertocci@auth0.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

In the TMI-BFF topology, the backend and frontend de= veloper are the same person. The operations TMI-BFF describes are the funct= ional equivalent of what the JS code of one SPA app using a code+PKCE SDK w= ould do when retrieving previously obtaining tokens from the store in order to perform an API call. Whereas s= uch an app would make that call in memory (and result in the same operation= s described here, either use a previously saved access token matching the r= equirements of the API call, or use artifacts like RTs to request a new access token matching the request)= in TMI-BFF al the logic and persistence layer are in the backend, hence th= at query becomes a request to the backend instead of a local function call.

The advantages have been described in other branches= of this thread, but TL;DR- a lot of the token requesting work can be perfo= rmed more reliably (eg less things can go wrong) from a confidential client= and it=E2=80=99s easier for SDK developers to package it (see existing middlewares vs JS SDKs). Note that for the app= developer this might still look like the same flow, asking a JS SDK to get= the token the app needs to call an API, but the JS SDK would be dramatical= ly simpler than the one performing code+PKCE in the user agent and entail communication between frontend a ba= ckend, hence the need to define how that communication happens if we want d= evelopers to be able to mix and match frontend and backend dev stacks.

Again, this does not necessarily add security to the= code+PKCE in the user agent model (which remains the only game in town for= backendless SPAs), but it does make things simpler for the frontend develo= per and requires less advanced capabilities in the AS.

=C2=A0

From: = Warren Parad <wparad@rhosys.ch><= br> Date: Sunday, February 14, 2021 at 09:45
To: Stoycho Sleptsov <stoycho.sleptsov@gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, Vittorio Bertocci <vittorio.bert= occi@auth0.com>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Correct it would never need to be used to authentica= te a client, as a client is always offline and can directly use the backcha= nnel. You would never need the front channel to authenticate a client, howe= ver you might need the front channel to authorize a client to access user resources offline. Is that what you a= re talking about, i.e. the offline refresh_token authorization code flow?

=C2=A0

If yes, then the standard would be to use the author= ization code flow requesting as you've mentioned. Although that flow al= ready exists and well established, and without any issues, having a standar= d specifying how to communicate with the client doesn't seem to be useful, as you only need to pass an auth = code=C2=A0and the issuer=C2=A0to the client. But since these endpoints are never expos= ed nor need to have interoperability between different owners (i.e. the own= er of the front-channel is different from the owner of the back-channel), w= hat's the benefit of specifying the explicit endpoints necessary for the BFF to have?


Warren Parad

Founder, CTO

3D"Image

Warren Parad

Founder, CTO=

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 6:27 PM Stoycho Sleptsov <= ;stoycho.sl= eptsov@gmail.com> wrote:

Thanks Warren,

=C2=A0

as I see you and Neil have the same idea,<= /u>

but as of this moment I think this method is not a v= alid option for authenticating

a client according to the=C2=A0draft-ietf-oauth-v2-1= .

=C2=A0

On the other hand, authenticating the client through= the BFF

seems conforming to the spec., but=C2=A0in the=C2=A0= case when=C2=A0the access token is used

in the browser in fact, I am afraid that it can be r= egarded as

some kind of "deception" of the AS.=

=C2=A0

It seems the frontend SPA is not the easiest way to = go with oauth...

=C2=A0

Stoycho.

=C2=A0

On Sun, 14 Feb 2021 at 17:35, Warren Parad <wparad@rhosys.ch> w= rote:

redirect_uri and use PKCE via the code verifier.<= /u>


=3D"Image

Warren Parad

Founder, CTO=

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov <= ;stoycho.sl= eptsov@gmail.com> wrote:

Thanks a lot for your answer Neil,

as I am no expert (yet :-)) in security I was afraid to rely on
redirect_uri for authentication of the client,
but I will consider that option as more trustworthy now.

(it is also not very clear for me which part of the app can be
regarded as the redirect_uri owner, the BFF or the loaded frontend
SPA, but maybe it is not so important)

If you had the two options for authentication of the frontend SPA
client - the redirect_uri on the one hand, and the Basic
authentication with client secret through the BFF on the other, which
one would you recommend?

On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com> wrote:<= br> >
> Public clients are implicitly authenticated by their ownership of the = registered redirect_uri. This why it=E2=80=99s important to use a redirect_= uri for which ownership can be reasonably established, such as HTTPS endpoi= nts with exact URI matching.
>
> There are more things that can go wrong with that (see the security BC= P), but it can be made reasonably secure.
>
> =E2=80=94 Neil
>
> > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
> >
> > =EF=BB=BF
> > I would like to add my reasons about the "Why are developers= creating BFF for their frontends to communicate with an AS",
> > with the objective to verify if they are valid.
> >
> > I need the client app. to be authenticated at the AS (to determin= e if it is a first-party app., for example).
> > If we decide to implement our client as a frontend SPA , then we = have no other option except through a BFF, as PKCE does not help for authen= tication.
> >
> > Or is it considered a bad practice to do that?
> >
> > Regards,
> > Stoycho.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth
>
> --
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy= >

--000000000000cdd9de05bb5146d5-- From nobody Sun Feb 14 12:20:51 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6920D3A09CF for ; Sun, 14 Feb 2021 12:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-ggA1FTO2cN for ; Sun, 14 Feb 2021 12:20:45 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E883A09C9 for ; Sun, 14 Feb 2021 12:20:45 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id z21so3084297pgj.4 for ; Sun, 14 Feb 2021 12:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=RoA4waixC3YL6BUqzoH+ws9WYe3cYTxME/3YAWP8cug=; b=DadDpldGa1+eQO1bZcvOJQDqIoIpskO3ozY7WfRH0axFFkEUCtBusQ4noeGi66og+1 BRflmX78yd6YyrjYxTs5kPmw9UGbUzp2bp1OPySrX1Kuei5XU5ALS7SypuHH+JeX9MTZ GyQdiGmmcsDjT0OcqP7/aXkIXaJaB8S+uKMAx5K+3rL/6TxemvltSqAND2hwryFEBniG +TTyGHjt1dXbYfXw/sseixvN2Prfa4s2fCJb/yB0Erdb8Auc2LdcBHXlpthBj6bJ7nBw /sPfToykM0S+BxuuO1GgumXH9icHCeMUJzllTr/T5TgIOz+Ws2SkY84/FyxMYvZ5P5Ra uyXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=RoA4waixC3YL6BUqzoH+ws9WYe3cYTxME/3YAWP8cug=; b=FqDmeC7iLVD8ZPs9xZjrFwRTt72AiwOIZzZ5djfcr2nQJeTbr9b/acFNRIsFx/K6uA DcJ6DqLr3Kj+3lsLw0JbIpyYF1pRNDslB45H+UcLFcCx5S/IG2yTOEKI96gr4hLLKqpC BsNSZGTkn+wky7XStipRE4MuIQy5iAbvcyRUSLcmKxJnbhkQjpX9Q0Z1geXNx1lfyxbX 3ZKT3BH73yjsdYFnUtIetJU3UzFECSWMMKpJpSCBRAx8irKMGfSuosRlJQHrnhC9cxp9 SZeXxzpHycorMP9OFT3USlw9NH+oaJvOydB3qrp3wLtyNYMIw/x26HZwY2lBDyN3bZ9C GkHg== X-Gm-Message-State: AOAM531HFoPNI+AR1RFtfFVyyVOyjxhdw/YQXWfHkEykAgXxSyT4dqvW nIMPBosK/QYCGbxizHZAdwY8qg== X-Google-Smtp-Source: ABdhPJymEDHJBsFGUONbgfig3S3nPTM3dnVB2gLj1vpEMyvq7De0fO046IGCLVpBZVP1AeB1V+GwGg== X-Received: by 2002:a63:1e4b:: with SMTP id p11mr12720940pgm.301.1613334044445; Sun, 14 Feb 2021 12:20:44 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id ob6sm13897293pjb.30.2021.02.14.12.20.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 12:20:43 -0800 (PST) From: Vittorio Bertocci To: Warren Parad CC: Neil Madden , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAA1Za+AAAVvgIAADHnkgAAF6ACAAGWCi4AAC++AgAALVsE= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 20:20:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052B7B005A1CA1F3AACF417AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 20:20:49 -0000 --_000_CO6PR18MB4052B7B005A1CA1F3AACF417AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIHJld2luZCBhIGJpdCBoZXJlLiBUaGlzIHdhcyBuZXZlciBwcmVzZW50ZWQgYXMgZHJp dmluZyB1c2UgY2FzZS4NCg0KDQogICogICBOZWlsIHN1Z2dlc3RlZCB0aGF0IHRoZSBiYWNrZW5k IGNvdWxkIHNpbXBseSBnaXZlIHNob3J0IGxpdmVkIEpUV3MgZm9yIHRoZSBmcm9udGVudCB0byBj YWxsIEFQSS4NCiAgKiAgIEkgY2xhcmlmaWVkIHRoYXQgdGhpcyB3b3VsZCBub3QgYmUgdmlhYmxl IGluIHRoZSBnZW5lcmFsIGNhc2UgYW5kIHByb3ZpZGVkIGFuIGV4YW1wbGUgc2NlbmFyaW8gd2hl cmUgYmFja2VuZCBpc3N1ZWQgc2hvcnQgbGl2ZWQgdG9rZW5zIHdvdWxkIG5vdCBoYXZlIHdvcmtl ZA0KICAqICAgWW91IGNvbW1lbnRlZCB0aGF0IHRoZSBmcm9udGVuZCBjYW4gb2J0YWluIEFTIHRv a2VucyBmcm9tIEpTIGFuZCBtZW50aW9uZWQgc2lsZW50IGF1dGhlbnRpY2F0aW9uLiBJIGNsYXJp ZmllZCAob3IgdHJpZWQgdG8pIHRoYXQgdGhpcyBvZmZzaG9vdCBvZiB0aGUgZGlzY3Vzc2lvbiB3 YXNu4oCZdCB0byBzYXkgdGhhdCB0aGVyZSBpcyBubyB2aWFibGUgd2F5IG9mIGRvaW5nIHRoZSBz Y2VuYXJpbyBhbHJlYWR5LCBhbmQgYnkgdGhlIHdheSB1c2luZyBhbiBpRnJhbWUgdG8gZG8gc2ls ZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdyBwcm9ibGVtYXRpYy4gQXQgdGhpcyBwb2ludCB3ZSBh cmUgbm8gbG9uZ2VyIGRpc2N1c3NpbmcgVE1JLUJGRiwgYnV0IGN1cnJlbnQgYWZmYWlycyBpbiB0 aGUgYXV0aGVudGljYXRpb24gd29ybGQuIFRoZSBmYWN0IHRoYXQgd2UgYXJlIHByb3Bvc2luZyBU TUktQkZGIGFuZCB0aGUgZmFjdCB0aGF0IHNpbGVudCBhdXRoZW50aWNhdGlvbiBpcyBsZXNzIGFu ZCBsZXNzIHZpYWJsZSBhcmUgaW5kZXBlbmRlbnQgZmFjdHMsIHRoZSBmb3JtZXIgaXNu4oCZdCBt ZWFudCB0byBiZSBhIHNvbHV0aW9uIGZvciB0aGUgbGF0dGVyIChpdOKAmXMgYWxyZWFkeSBhZGRy ZXNzZWQgYnkgdXNpbmcgUlRzIGluIGNva2UrUEtDRSkNCg0KVGhhdCBjbGFyaWZpZWQuIE5vdCBv bmx5IHdlIGV4cGVjdCBJVFAgdG8gYWZmZWN0IHNpbGVudCBhdXRoZW50aWNhdGlvbiwgaXQgaGFz IGJlZW4gYWZmZWN0ZWQgZm9yIHRoZSBwYXN0IHllYXIgYW5kIHRoYXQgaGFzIGJlZW4gb25lIG9m IHRoZSBwcmltYXJ5IGJ1c2luZXNzIGRyaXZlcnMgZm9yIHRoZSByYXBpZCBhZG9wdGlvbiBvZiBj b2RlK1BLQ0UrUlRzIGluIHRoZSB1c2VyIGFnZW50LCBhcyBjdXN0b21lcnMgd2l0aCBwdXJlIFNQ QXMgZm91bmQgdGhlbXNlbHZlcyB1bmFibGUgdG8gcmVuZXcgdG9rZW5zIHdpdGhvdXQgcHJvbXB0 aW5nIGFzIHRoZWlyIGFjY2VzcyB0byBjb29raWVzIGluIGZsb3dzIGRyaXZlbiBieSBpZnJhbWVz IGJlY2FtZSBsZXNzIGFuZCBsZXNzIHJlbGlhYmxlLg0KV2hlbiBJVFAgd2FzIGludHJvZHVjZWQg d2UgcHV0IG1hbnkgY29tcGFuaWVzIHRvZ2V0aGVyIHRvIHRyeSB0byBnZXQgQXBwbGUgdG8gY2hh bmdlIGl0ICh5b3UgY2FuIGZpbmQgdGhlIGRvYyBpbiBodHRwczovL2RvY3MuZ29vZ2xlLmNvbS9k b2N1bWVudC9kLzFScy0tREZ6WmpfU2ZRanR6OG9IOURsTElJMHJhM3ZpTUVIcks3c0tzYWlVL2Vk aXQjaGVhZGluZz1oLnAzbnZwNnhteHZ6ZikgYnV0IHRoZXkgZGlkbuKAmXQgYnVsZ2UgYW5kIHVs dGltYXRlbHkgdGhlIGludHJvZHVjdGlvbiBvZiBSVHMgaW4gdXNlciBhZ2VudCBjb2RlIChhbGJl aXQgd2l0aCBleHRyYSByZXN0cmljdGlvbnMsIHRoZSBvbmUgSSBtZW50aW9uZWQgbm90IGV2ZXJ5 b25lIGlzIGZvbGxvd2luZykgbWFkZSB0aGUgcHJvYmxlbSBtYW5hZ2VhYmxlLiBXZSBoYXZlIGFu IGluaXRpYXRpdmUgY3Jvc3Mgd29ya2luZyBncm91cHMgKElFVEYsIE9JREMgZXRjKWZvciB3b3Jr aW5nIHdpdGggYnJvd3NlciB2ZW5kb3JzIHRvIHRyeSBjb250YWluaW5nIHNpbWlsYXIgcmVncmVz c2lvbnMgaW4gdGhlIGZ1dHVyZS4gRm9yIGEgc3VtbWFyeSBvZiBzaW1pbGFyIHByb2JsZW1zIHNl ZSBodHRwczovL2lkZW50aXZlcnNlLmdhbGxlcnkudmlkZW8vZGV0YWlsL3ZpZGVvLzYxODQ0NDMw MzcwMDEvYnJvd3Nlci1mZWF0dXJlcy12cy1pZGVudGl0eS1wcm90b2NvbHMuDQoNClRvIHJlc3Rh dGUsIHRoZSBUTUktQkZGIHByb3Bvc2FsIGlzIG5vdCB0cnlpbmcgdG8gZml4IGFueSBvZiB0aGF0 LCBub3IgcGVyIHRoZSBhYm92ZSBzb21lIG9mIGl0IG5lZWQgZml4aW5nLiBUaGUgb25seSBpbmRp cmVjdCBjb25uZWN0aW9uIG1pZ2h0IGJlIHRoYXQgbGVzcyBzdHVmZiBoYXBwZW5pbmcgaW4gdGhl IHVzZXIgYWdlbnQgbWVhbnMgbGVzcyBvcHBvcnR1bml0aWVzIGZvciBzaW1pbGFyIGNoYW5nZXMg dG8gaW1wYWN0IHRoZSBmbG93cywgYnV0IGl04oCZcyBkZWZpbml0ZWx5IG5vdCBhIHRvcCBsZXZl bCBkcml2ZXIuDQoNCkZyb206IFdhcnJlbiBQYXJhZCA8d3BhcmFkPTQwcmhvc3lzLmNoQGRtYXJj LmlldGYub3JnPg0KRGF0ZTogU3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAxMTo0MQ0KVG86 IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+DQpDYzogTmVp bCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+LCAib2F1dGhAaWV0Zi5vcmciIDxv YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBh bmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0K VGhhdCBvbmx5IGFwcGxpZXMgdG8gdGhpcmQgcGFydHkgY29va2llcywgaXQgc2hvdWxkbid0IGFm ZmVjdCB0aGlyZC1wYXJ0eSBpZnJhbWVzIGFzIGZhciBhcyBJJ20gYXdhcmUuIFNvIHVubGVzcyB3 ZSBleHBlY3QgdGhvc2UgdG8gYnJlYWssIHdlIHByb2JhYmx5IHNob3VsZG4ndCBpbmNsdWRlIHRo YXQgYXMgYSBkcml2aW5nIHVzZSBjYXNlLiBJcyB0aGVyZSBhbm90aGVyIG1lYXN1cmUgdGhhdCB3 b3VsZCBiZSByZWxldmFudCBoZXJlPw0KDQoNCltJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci5dDQoN CldhcnJlbiBQYXJhZA0KDQpGb3VuZGVyLCBDVE8NClNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQg Y29tcGxldGUgeW91ciBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50IEF1dGhy ZXNzPGh0dHBzOi8vYXV0aHJlc3MuaW8+Lg0KDQoNCk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDc6 NTcgUE0gVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K SVRQLCBmb3IgZXhhbXBsZQ0KDQpGcm9tOiBXYXJyZW4gUGFyYWQgPHdwYXJhZD00MHJob3N5cy5j aEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0 ZTogU3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwNDo1NA0KVG86IFZpdHRvcmlvIEJlcnRv Y2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvY2Np QGF1dGgwLmNvbT4+DQpDYzogTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208 bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiwgIm9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIElu Zm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKQ0KDQpDYW4geW91IGV4cGFu ZCBvbiB3aGF0IHNpbGVudCBhdXRoZW50aWNhdGlvbiBhbmQgc2Vzc2lvbiB0b2tlbiBzdGFuZHMg Zm9yIGhlcmU/IElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBpZnJhbWUgc2NlbmFyaW8sIHRo ZSBuZXcgYnJvd3NlciBtZWFzdXJlcyBtYWtlIGl0IHByb2JsZW1hdGljLg0KV2hpY2ggbmV3IGJy b3dzZXIgbWVhc3VyZXM/DQoNCg0KRXJyb3IhIEZpbGVuYW1lIG5vdCBzcGVjaWZpZWQuDQoNCldh cnJlbiBQYXJhZA0KDQpGb3VuZGVyLCBDVE8NClNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQgY29t cGxldGUgeW91ciBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50IEF1dGhyZXNz PGh0dHBzOi8vYXV0aHJlc3MuaW8+Lg0KDQoNCk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDE6MzMg UE0gVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQog ICogICBGb3IgVUkgcmVsYXRlZCBmdW5jdGlvbmFsaXR5LCBpLmUuIGRvY3VtZW50IHNlbGVjdGlv biwgdXNlciBwcm9maWxlIGRpc3BsYXkvY2hhbmdlcywgY29udGFjdCB1cGRhdGVzLCBldGMuLi4g WW91IHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUgdGhlIGNsaWVudCBzaWRlIHNpbGVudCBhdXRo ZW50aWNhdGlvbiB1c2luZyB0aGUgcHJvdmlkZWQgc2Vzc2lvbiB0b2tlbiBmcm9tIHRoZSBBenVy ZSBBRCBBUywgd2l0aG91dCBuZWVkaW5nIHRvIG1ha2UgYW55IFJPIGFwaSBjYWxscyBub3IgdXNl ciByZWRpcmVjdHMuDQpDYW4geW91IGV4cGFuZCBvbiB3aGF0IHNpbGVudCBhdXRoZW50aWNhdGlv biBhbmQgc2Vzc2lvbiB0b2tlbiBzdGFuZHMgZm9yIGhlcmU/IElmIHlvdSBhcmUgcmVmZXJyaW5n IHRvIHRoZSBpZnJhbWUgc2NlbmFyaW8sIHRoZSBuZXcgYnJvd3NlciBtZWFzdXJlcyBtYWtlIGl0 IHByb2JsZW1hdGljLiBJbiBjb2RlK1BLQ0UgeW91IGNhbiB1c2UgYSByZWZyZXNoIHRva2VuLCBi dXQgc2VlIHRoZSBvdGhlciByZXBseSBmb3IgaG93IHRoaXMgcHJvcG9zYWwgaXMgYW4gYWx0ZXJu YXRpdmUgdG8gdGhhdCBpbiBzb21lIHNpdHVhdGlvbnMuIFRoaXMgYW5zd2VyIHdhcyBzcGVjaWZp Y2FsbHkgb24gd2h5IGhhdmluZyBiYWNrZW5kLWlzc3VlZCB0b2tlbnMgZGlkbuKAmXQgYXBwbHkg dG8gdGhpcyBzY2VuYXJpby4NCg0KDQpGcm9tOiBXYXJyZW4gUGFyYWQgPHdwYXJhZD00MHJob3N5 cy5jaEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc+Pg0K RGF0ZTogU3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwMzo0OA0KVG86IFZpdHRvcmlvIEJl cnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRv Y2NpQGF1dGgwLmNvbT4+DQpDYzogTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5j b208bWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20+PiwgIm9hdXRoQGlldGYub3JnPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9u IEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKQ0KDQpGb3IgdGhlIHRy dXN0ZWQgcGFydCwgc2VlIGFib3ZlLiBGb3IgdGhlIHNob3J0IGxpdmVkIEpXVHMsIHRoYXTigJlz IG5vdCByZWFsbHkgYW4gb3B0aW9uLiBUaGUgbW9zdCBnZW5lcmljIHNjZW5hcmlvIGFkZHJlc3Nl ZCBoZXJlIGlzIGZvciBBUElzIHRoYXQgYWNjZXB0IHRva2VucyBpc3N1ZWQgYnkgdGhlIEFTOyB0 aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVtIGFzIGEgY2xpZW50LCBidXQgaXQgY2Fubm90IG1p bnQgdGhlbS4gSW1hZ2luZSB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQgYSBTUEEgYXBwbGljYXRpb24g dGhhdCBzaWducyBpbiB1c2VycyB1c2luZyBBenVyZSBBRCwgYW5kIG5lZWRzIHRvIGNhbGwgT2Zm aWNlIGFuZCBBenVyZSBBUElzLiBUaGUgU1BBIGJhY2tlbmQgY2Fubm90IGlzc3VlIHRva2VucyBm b3IgdGhvc2UgQVBJcywgaXQgY2FuIG9ubHkgcmVxdWVzdCB0aGVtIHRvIHRoZSBBenVyZSBBRCBB Uy4NCg0KRm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBkb2N1bWVudCBzZWxlY3Rp b24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNvbnRhY3QgdXBkYXRlcywgZXRjLi4u IFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBjbGllbnQgc2lkZSBzaWxlbnQgYXV0 aGVudGljYXRpb24gdXNpbmcgdGhlIHByb3ZpZGVkIHNlc3Npb24gdG9rZW4gZnJvbSB0aGUgQXp1 cmUgQUQgQVMsIHdpdGhvdXQgbmVlZGluZyB0byBtYWtlIGFueSBSTyBhcGkgY2FsbHMgbm9yIHVz ZXIgcmVkaXJlY3RzLiBGb3IgUk8gcmVzcG9uc2liaWxpdGllcywgeW91IGNhbiBwcmVzZW50IHRo ZSB1c2VyIHdpdGggYSBidXR0b24gIkdyYW50IFJPIGFjY2VzcyB0byBBenVyZSByZXNvdXJjZXMi IGJ1dHRvbiBhbmQgdGhlIHVzZXIgd2lsbCBnbyB0aHJvdWdoIGEgcGVybWlzc2lvbiBzY29wZSBl bGV2YXRpb24gZmxvdywgYWdhaW4gbm8gcmVhc29uIHRvIG5lZWQgYSBCRkYgaGVyZS4NCg0KV2Ug ZGlkIGNvbnNpZGVyIGFkZGluZyBzb21ldGhpbmcgdG8gdGhhdCBlZmZlY3QsIGFuIGVycm9yIG1l c3NhZ2UgdGhhdCBjYW4gZGlyZWN0IHRoZSBmcm9udGVuZCB0byBwZXJmb3JtIHRoZSBpbnRlcmFj dGl2ZSBwb3J0aW9uIG5lY2Vzc2FyeSBmb3IgdGhpcyB0b3BvbG9neSB0byB3b3JrLiBJdCB3b3Vs ZCBiZSBzb21ldGhpbmcgc2ltaWxhciB0byB0aGUgSURQIGluaXRpYXRlZCBsb2dpbiBpbiBPSURD LCB3aGVyZSB0aGUgY2xpZW50IG9mZmVycyBhbiBlbmRwb2ludCB0aGF0IGlzIGd1YXJhbnRlZWQg dG8gaW5pdGlhdGUgYSBzaWduIGluIGZsb3cgKGhlbmNlIGluamVjdCBhbGwgdGhlIG5lY2Vzc2Fy eSBub25jZXMgZXRjKS4gV2UgZGlkbuKAmXQgYWRkIGl0IHVwZnJvbnQgYW5kIGxlZnQgaXQgYXMg ZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgbW9zdGx5IGJlY2F1c2UgaXTigJlzIG5vdCBlYXN5IHRv IG1vZGVsIHByb3Blcmx5IGFuZCBiZWZvcmUgb3BlbmluZyB0aGF0IHdvcmsgZnJvbnQgd2Ugd2Fu dGVkIHRvIHNlZSBob3cgdGhlIGlkZWEgd2FzIHJlY2VpdmVkLg0KSXQgbWF5IG1ha2Ugc2Vuc2Ug Zm9yIHRoZSBhcHAgdG8gaGF2ZSBhbiBlcnJvciBtZXNzYWdlLCBvciBldmVuIGJldHRlciBtaWdo dCBiZSBhIDMwMiBMb2NhdGlvbiBoZWFkZXIgZGVwZW5kaW5nIG9uIHdoYXQgeW91IGFyZSBkb2lu Zy4gVGhlcmUgaXMgbm90aGluZyBoZXJlIHRoYXQgaXMgT0F1dGggc3BlY2lmaWMgaG93ZXZlciAo bm9yIGNvbW1vbiksIGFuZCB0aGVuIHdlIHNob3VsZCBjaGFsbGVuZ2UgdGhlIG5lZWQgdG8gZGly ZWN0bHkgcHJvdmlkZSBhbiBSRkMgcmVjb21tZW5kYXRpb24gZm9yIGhhbmRsaW5nIHRoaXMuDQoN Cg0KRXJyb3IhIEZpbGVuYW1lIG5vdCBzcGVjaWZpZWQuDQoNCldhcnJlbiBQYXJhZA0KDQpGb3Vu ZGVyLCBDVE8NClNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQgY29tcGxldGUgeW91ciBhdXRob3Jp emF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50IEF1dGhyZXNzPGh0dHBzOi8vYXV0aHJlc3Mu aW8+Lg0KDQoNCk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDEyOjI5IFBNIFZpdHRvcmlvIEJlcnRv Y2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIE5laWwsDQpUaGFua3MgZm9y IHRoZSBwcm9tcHQgY29tbWVudHMhDQoNCiAgKiAgIFJlOiBHRVQgdnMgUE9TVCwNCnBlcnNvbmFs bHkgSeKAmWQgYmUgZmluZSB3aXRoIHJlc3RyaWN0aW5nIHRvIFBPU1QuDQoNCg0KICAqICAgUmU6 IFJPLUFTLCBpbnRlcmFjdGlvbi0NCnBlcmhhcHMgaXQgaXMgbm90IHZlcnkgY2xlYXIgZnJvbSB0 aGUgdGV4dCBhdCB0aGUgbW9tZW50IChmaXJzdCBkcmFmdCksIGJ1dCB0aGF0IGlzIGFzc3VtZWQg dGhhdCB0aGUgUk8gd2VudCB0aHJ1IHdoYXRldmVyIGludGVyYWN0aXZlIHN0ZXBzIGFyZSBuZWNl c3NhcnkgdG8gZXN0YWJsaXNoIGEgc2Vzc2lvbiAoZWcgc2lnbiBpbiwgYXNzdW1pbmcgdGhlIEFT IGlzIHNheSBhbiBPSURDIHByb3ZpZGVyKSBhbmQgb2J0YWluIGJlZm9yZWhhbmQgdGhlIGFjY2Vz cyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbnMgdGhhdCB3aWxsIGJlIG5lZWRlZCBkdXJpbmcgdGhl IGFwcCBhY3Rpdml0aWVzIHRha2luZyBwbGFjZSBhZnRlciAgdGhhdC4gSW4gY29uY3JldGUgdGVy bXMsIGltYWdpbmUgdGhhdCB0aGUgYmFja2VuZCBwZXJmb3JtcyBhbiBhdXRob3JpemF0aW9uIGNv ZGUgZ3JhbnQgcmVxdWVzdGluZyBhbiBJRHRva2VuLCBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2gg dG9rZW4gQkVGT1JFIHRoZSBhY3Rpdml0aWVzIGRlc2NyaWJlZCBpbiBUTUktQkZGIHRha2UgcGxh Y2UuDQpUaGUgY3VycmVudCBsYW5ndWFnZSB0cnlpbmcgdG8gZXhwcmVzcyB0aGF0IGlzIGluIDEu MjoNCkFzIGEgcHJlcmVxdWlzaXRlIGZvciB0aGUgZmxvdyBkZXNjcmliZWQgYmVsb3csIHRoZSBi YWNrZW5kIE1VU1QgaGF2ZSBlc3RhYmxpc2hlZCBhIHNlY3VyZSBzZXNzaW9uIHdpdGggdGhlIHVz ZXIgYWdlbnQsIHNvIHRoYXQgYWxsIHJlcXVlc3RzIGZyb20gdGhhdCB1c2VyIGFnZW50IHRvd2Fy ZCB0aGUgYmFja2VuZCBvY2N1ciBvdmVyIEhUVFBTIGFuZCBjYXJyeSBhIHZhbGlkIHNlc3Npb24g YXJ0aWZhY3QgKHN1Y2ggYXMgYSBjb29raWUpIHRoYXQgdGhlIGJhY2tlbmQgY2FuIHZhbGlkYXRl LiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1hbmRhdGUgYW55IHNwZWNpZmljIG1lY2hhbmlzbSB0 byBlc3RhYmxpc2ggYW5kIG1haW50YWluIHRoYXQgc2Vzc2lvbi4NCkFuZA0KY2FjaGVkLCBpdCBy ZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYSBuZXcgYWNjZXNzIHRva2VuIHdp dGggdGhlIHJlcXVpcmVkIGNoYXJhY3RlcmlzdGljcywgdXNpbmcgYW55IGFydGlmYWN0cyBwcmV2 aW91c3kgb2J0YWluZWQgKGVnIHJlZnJlc2ggdG9rZW4pIGFuZCBncmFudHMgdGhhdCB3aWxsIGFs bG93IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBpc3N1ZSB0aGUgcmVxdWVzdGVkIHRva2Vu IHdpdGhvdXQgcmVxdWlyaW5nIHVzZXIgaW50ZXJhY3Rpb24uDQoNCg0KICAqICAgIElmIHRoZSBi YWNrZW5kIGlzIGFscmVhZHkgaW1wbGljaXRseSB0cnVzdGVkIHRoZW4gY291bGRu4oCZdCB5b3Ug c2tpcCBPQXV0aCBhbmQganVzdCBnZXQgdGhlIGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQg SldUcyB0byB0aGUgZnJvbnRlbmQgdGhhdCBpdCBjYW4gdXNlIGZvciBBUEkgYWNjZXNzPw0KRm9y IHRoZSB0cnVzdGVkIHBhcnQsIHNlZSBhYm92ZS4gRm9yIHRoZSBzaG9ydCBsaXZlZCBKV1RzLCB0 aGF04oCZcyBub3QgcmVhbGx5IGFuIG9wdGlvbi4gVGhlIG1vc3QgZ2VuZXJpYyBzY2VuYXJpbyBh ZGRyZXNzZWQgaGVyZSBpcyBmb3IgQVBJcyB0aGF0IGFjY2VwdCB0b2tlbnMgaXNzdWVkIGJ5IHRo ZSBBUzsgdGhlIGJhY2tlbmQgY2FuIHJlcXVlc3QgdGhlbSBhcyBhIGNsaWVudCwgYnV0IGl0IGNh bm5vdCBtaW50IHRoZW0uIEltYWdpbmUgd2XigJlyZSB0YWxraW5nIGFib3V0IGEgU1BBIGFwcGxp Y2F0aW9uIHRoYXQgc2lnbnMgaW4gdXNlcnMgdXNpbmcgQXp1cmUgQUQsIGFuZCBuZWVkcyB0byBj YWxsIE9mZmljZSBhbmQgQXp1cmUgQVBJcy4gVGhlIFNQQSBiYWNrZW5kIGNhbm5vdCBpc3N1ZSB0 b2tlbnMgZm9yIHRob3NlIEFQSXMsIGl0IGNhbiBvbmx5IHJlcXVlc3QgdGhlbSB0byB0aGUgQXp1 cmUgQUQgQVMuDQoNCg0KICAqICAgSWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cg ZXRjIHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFu ZGFyZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0 aGUgU1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRv IGEgUEFSIHJlcXVlc3QgZmlyc3QgYW5kIHJldHVybiBhIFVSSSB0aGF0IHJlZmVyZW5jZXMgdGhh dCBzbyB0aGF0IGF1dGhvcml6YXRpb24gZGV0YWlscyBhcmVu4oCZdCBwYXNzZWQgdGhyb3VnaCB0 aGUgZnJvbnRlbmQpLg0KV2UgZGlkIGNvbnNpZGVyIGFkZGluZyBzb21ldGhpbmcgdG8gdGhhdCBl ZmZlY3QsIGFuIGVycm9yIG1lc3NhZ2UgdGhhdCBjYW4gZGlyZWN0IHRoZSBmcm9udGVuZCB0byBw ZXJmb3JtIHRoZSBpbnRlcmFjdGl2ZSBwb3J0aW9uIG5lY2Vzc2FyeSBmb3IgdGhpcyB0b3BvbG9n eSB0byB3b3JrLiBJdCB3b3VsZCBiZSBzb21ldGhpbmcgc2ltaWxhciB0byB0aGUgSURQIGluaXRp YXRlZCBsb2dpbiBpbiBPSURDLCB3aGVyZSB0aGUgY2xpZW50IG9mZmVycyBhbiBlbmRwb2ludCB0 aGF0IGlzIGd1YXJhbnRlZWQgdG8gaW5pdGlhdGUgYSBzaWduIGluIGZsb3cgKGhlbmNlIGluamVj dCBhbGwgdGhlIG5lY2Vzc2FyeSBub25jZXMgZXRjKS4gV2UgZGlkbuKAmXQgYWRkIGl0IHVwZnJv bnQgYW5kIGxlZnQgaXQgYXMgZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgbW9zdGx5IGJlY2F1c2Ug aXTigJlzIG5vdCBlYXN5IHRvIG1vZGVsIHByb3Blcmx5IGFuZCBiZWZvcmUgb3BlbmluZyB0aGF0 IHdvcmsgZnJvbnQgd2Ugd2FudGVkIHRvIHNlZSBob3cgdGhlIGlkZWEgd2FzIHJlY2VpdmVkLg0K DQpGcm9tOiBPQXV0aCA8b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl c0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBOZWlsIE1hZGRlbiA8bmVpbC5tYWRkZW5AZm9yZ2Vy b2NrLmNvbTxtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbT4+DQpEYXRlOiBTdW5kYXks IEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAwOjE3DQpUbzogVml0dG9yaW8gQmVydG9jY2kgPHZpdHRv cmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNv bUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJh Y2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKQ0KDQpJIGhhdmUgYSBsb3Qgb2Ygc2VjdXJpdHkg Y29uY2VybnMgYWJvdXQgdGhpcyBkcmFmdC4NCg0KVGhlIGRyYWZ0IGFsbHVkZXMgdG8gc2VjdXJp dHkgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBoYW5kbGluZyBhY2Nlc3MgdG9rZW5zIGluIHRoZSBm cm9udGVuZCBidXQgbmV2ZXIgcmVhbGx5IHNwZWxscyB0aGVtIG91dC4gRnJvbSB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgaXQgc2VlbXMgdGhhdCB0aGUgcHJpbWFyeSBjb25jZXJuIGlzIHdp dGggdGhlZnQgb2YgYWNjZXNzIHRva2VucyBmcm9tIGxvY2FsIHN0b3JhZ2UuIFRvIGRvIHRoaXMg eW914oCZZCBuZWVkIGFuIFhTUyBhdHRhY2suIEJ1dCBpbiB0aGF0IGNhc2UsIHdvdWxkbuKAmXQg dGhlIGF0dGFja2VyIHNpbXBseSB1c2UgdGhlIFhTUyB0byBtYWtlIGEgY2FsbCB0byB0aGUgYmZm LXRva2VuIGVuZHBvaW50IGluc3RlYWQ/DQoNClRoZSBjb21iaW5hdGlvbiBvZiB0aGUgYmZmLXRv a2VuIGVuZHBvaW50IHJlY29tbWVuZGluZyB0aGUgdXNlIG9mIEdFVCByZXF1ZXN0cyB0b2dldGhl ciB3aXRoIHRoZSBoaW50IHRvIHVzZSBjb29raWUtYmFzZWQgYXV0aGVudGljYXRpb24gaXMgbGlr ZWx5IGdvaW5nIHRvIHB1bmNoIGEgaG9sZSBpbiBtb3N0IENTUkYgZGVmZW5zZXMsIHdoaWNoIGFz c3VtZSB0aGF0IEdFVHMgYXJlIHNhZmUuIFRoZSBvbmx5IHRoaW5nIHByZXZlbnRpbmcgdGhpcyBi ZWluZyBleHBsb2l0YWJsZSBpcyBDcm9zcy1PcmlnaW4gUmVhZCBCbG9ja2luZyAoaHR0cHM6Ly9j aHJvbWl1bS5nb29nbGVzb3VyY2UuY29tL2Nocm9taXVtL3NyYy8rL21hc3Rlci9zZXJ2aWNlcy9u ZXR3b3JrL2Nyb3NzX29yaWdpbl9yZWFkX2Jsb2NraW5nX2V4cGxhaW5lci5tZCkgZHVlIHRvIHRo ZSBKU09OIGNvbnRlbnQtdHlwZS4gVGhhdCBtYWtlcyBtZSByZWFsbHkgbmVydm91cy4gV2Ugc2hv dWxkIGF0IGxlYXN0IG1hbmRhdGUgWC1Db250ZW50LVR5cGUtT3B0aW9uczogbm9zbmlmZiBvbiB0 aGF0IHJlc3BvbnNlLiBJ4oCZZCBmZWVsIG1vcmUgY29tZm9ydGFibGUgaWYgdGhpcyB3YXMgYSBQ T1NUIHJlcXVlc3Qgb25seS4NCg0KQXMgU3RveWNobyBTbGVwdHNvdiBtZW50aW9uZWQgaW4gdGhl IG90aGVyIGVtYWlsLCB0aGUgbGFjayBvZiBmcm9udC1jaGFubmVsIGNvbW11bmljYXRpb24gYmV0 d2VlbiB0aGUgQVMgYW5kIHRoZSBSTyBzZWVtcyBvZGQuIElmIHRoZSBiYWNrZW5kIGlzIGFscmVh ZHkgaW1wbGljaXRseSB0cnVzdGVkIHRoZW4gY291bGRu4oCZdCB5b3Ugc2tpcCBPQXV0aCBhbmQg anVzdCBnZXQgdGhlIGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgSldUcyB0byB0aGUgZnJv bnRlbmQgdGhhdCBpdCBjYW4gdXNlIGZvciBBUEkgYWNjZXNzPw0KDQpJZiB5b3Ugd2FudCB0byBh bGxvdyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYtdG9rZW4gZW5kcG9p bnQgY2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBhdXRob3JpemF0aW9u IGVuZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhlIHVzZXIgdG8uIChF ZyB0aGUgYmFja2VuZCBjYW4gZG8gYSBQQVIgcmVxdWVzdCBmaXJzdCBhbmQgcmV0dXJuIGEgVVJJ IHRoYXQgcmVmZXJlbmNlcyB0aGF0IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7i gJl0IHBhc3NlZCB0aHJvdWdoIHRoZSBmcm9udGVuZCkuDQoNCuKAlCBOZWlsDQoNCg0KT24gMTIg RmViIDIwMjEsIGF0IDIwOjQ2LCBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9 NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYu b3JnPj4gd3JvdGU6DQrvu79EZWFyIGFsbCwNCkJyaWFuIGFuZCB5b3VycyB0cnVseSBhcmUgcHJv cG9zaW5nIGEgbmV3IHNwZWNpZmljYXRpb24gdGhhdCBzaG93cyBob3cgdGhlIHVzZXIgYWdlbnQg ZnJvbnRlbmQgb2YgYSB3ZWIgYXBwIGNhbiBkZWxlZ2F0ZSB0b2tlbiBhY3F1aXNpdGlvbiBhbmQg cGVyc2lzdGVuY2UgdG8gaXRzIGJhY2tlbmQsIGFuZCByZXF1ZXN0IHN1Y2ggdG9rZW5zIHdoZW4g bmVlZGVkIGZvciBkaXJlY3QgYWNjZXNzIG9mIHByb3RlY3RlZCByZXNvdXJjZXMgZnJvbSB0aGUg ZnJvbnRlbmQgY29kZS4NCg0KVGhlIHBhdHRlcm4gaXMgYWxyZWFkeSBpbiB1c2UsIGluIHByb3By aWV0YXJ5IGZvcm0sIGJ5IHZhcmlvdXMgbW9kZXJuIGRldmVsb3BtZW50IHN0YWNrcywgc3VjaCBh cyBOZXh0LkpTLiBWYXJpYW50cyBvZiB0aGUgcGF0dGVybiwgb2Z0ZW4gZGlzY3Vzc2VkIHVuZGVy IHRoZSBjYXRjaC1hbGwgdGVybSBCRkYgKGJhY2tlbmQgZm9yIGZyb250ZW5kKSwgaGF2ZSBiZWVu IG9mdGVuIG1lbnRpb25lZCBpbiB0aGlzIHdvcmtncm91cOKAmXMgYWN0aXZpdHksIGJ1dCBhbHdh eXMgbGVmdCBhbGwgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byB0aGUgcmVhZGVyLg0KV2UgYmVs aWV2ZSB0aGUgcGF0dGVybiBoYXMgbWVyaXQsIGFzIGNvcnJvYm9yYXRlZCBieSBpdHMgZ3Jvd2lu ZyBhZG9wdGlvbi4gQnkgZGVsZWdhdGluZyBhY2Nlc3MgdG9rZW4gYWNxdWlzaXRpb24gdG8gdGhl IGJhY2tlbmQsIHdlIGF2b2lkIG1hbnkgb2YgdGhlIG9mdGVuIGJyaXR0bGUgbW92aW5nIHBhcnRz IChhbmQgaW1wbGllZCBhdHRhY2sgc3VyZmFjZSkgcmVxdWlyZWQgdG8gYWNxdWlyZSBhY2Nlc3Mg dG9rZW5zIGZyb20gYSB1c2VyIGFnZW50LiBUaGUgdG9wb2xvZ3kgYWxzbyByZWxpZXZlcyB0aGUg ZnJvbnRlbmQgZnJvbSB0aGUgbmVlZCBvZiBwZXJzaXN0aW5nIHRva2VucyBpbiBsb2NhbCBzdG9y YWdlLCBhIHdlbGwga25vd24gc29yZSBwb2ludCBvZiB1c2luZyBPQXV0aCBkaXJlY3RseSBpbiBK YXZhU2NyaXB0LCBieSByZWx5aW5nIG9uIGl0cyBiYWNrZW5kIHN0b3JhZ2UgYW5kIHNlc3Npb24g dG8gcHJlc2VydmUgdG9rZW5zLg0KDQpBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBpcyB2ZXJ5 IHNpbXBsZSwgcHJvdmlkaW5nIGV4cGxpY2l0IGd1aWRhbmNlIG9uIHRoZSBzY2VuYXJpbyBvZmZl cnMgbWFueSBhZHZhbnRhZ2VzLg0KLSBJdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBjcmVhdGUgaW50 ZXJvcGVyYWJsZSBTREtzLCB3aGVyZSBmcm9udGVuZCBkZXYgc3RhY2tzIChhbnkgSlMgZmxhdm9y KSBjYW4gYmUgbWl4ZWQgYW5kIG1hdGNoZWQgd2l0aCBjb21wbGlhbnQgYmFja2VuZCBzdGFja3Mg KG1pZGRsZXdhcmVzIGluIG5vZGUsIGphdmEsIEFTUC5ORVQ8aHR0cDovL0FTUC5ORVQ+LCBQSFAg ZXRjKQ0KLSBJdCBhbGxvd3MgdXMgdG8gcHJvdmlkZSBndWlkYW5jZSBvbiBob3cgdG8gcHJvcGVy bHkgdGFja2xlIHRoZSBzY2VuYXJpbyBhbmQgd2FybiBpbXBsZW1lbnRlcnMgYWdhaW5zdCBzZWN1 cml0eSByaXNrcyAoc2NvcGUgZXNjYWxhdGlvbnMsIHVzaW5nIElEdG9rZW5zIGluc3RlYWQgb2Yg YWNjZXNzIHRva2VucywgZXRjKQ0KLSBJdCBhbGxvd3MgdXMgdG8gZGlzY3VzcyAoYW5kIHdoZW4g YXBwcm9wcmlhdGUsIHByb21vdGUpIHRoaXMgcGF0dGVybiBhcyBwYXJ0IG9mIHRoZSBicm93c2Vy IGFwcHMgc2VjdXJpdHkgZ3VpZGFuY2UsIGFuZCBwb3NpdGlvbiB0aGUgc2NlbmFyaW8gd2hlcmUg ZnJvbnRlbmQgb25seSBjYWxscyBBUEkgb24gaXRzIG93biBiYWNrZWQgKGhlbmNlIGRvZXNu4oCZ dCBuZWVkIGFjY2VzcyB0b2tlbnMpIHNpbXBseSBhcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGlzIG1v cmUgZ2VuZXJhbCBwYXR0ZXJuDQotIFRoaXMgYXBwcm9hY2ggbWFrZXMgbW9ja2luZyBhbmQgdGVz dGluZyBhcHBzIHZlcnkgZWFzeSwgcG9zc2libHkgcHJldmVudGluZyBkZXZlbG9wZXJzIGZyb20g d2Vha2VuaW5nIHRoZSBzZWN1cml0eSBvZiB0aGVpciBzeXN0ZW0gKGVnIHR1cm5pbmcgb24gUk9Q RyBvcHRpb25zKSAgb3IgdHVybmluZyB0byByaXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZw0K DQpOZWVkbGVzcyB0byBzYXksIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzbuKAmXQgZW50aXJlbHkg ZWxpbWluYXRlIHRoZSByaXNrcyBpbmhlcmVudCB0byBkaXJlY3QgdXNlIG9mIGFjY2VzcyB0b2tl bnMgZnJvbSBhIGJyb3dzZXIuIEJ1dCByZWFsaXR5IGlzIHRoYXQgdGhlIHBhdHRlcm4gaXMgaW4g d2lkZXNwcmVhZCB1c2UsIGFuZCB0aGUgY2lyY3Vtc3RhbmNlcyBsZWFkaW5nIHRvIHRoYXQgKGVn IGRldmVsb3BlcnMgb24gYSBwYXJ0aWN1bGFyIHByb2plY3Qgb25seSB3b3JrIHdpdGggZnJvbnRl bmQgc3RhY2tzOyBjb21wb25lbnRzIGxpa2UgcmV2ZXJzZSBwcm94aWVzIG1pZ2h0IG5vdCBhbHdh eXMgYmUgdmlhYmxlOyBldGMpIGFyZW7igJl0IGdvaW5nIGF3YXkgYW55IHRpbWUgc29vbi4gQnkg cHJvdmlkaW5nIHNpbXBsZSBndWlkYW5jZSBvbiB0aGlzIHBhdHRlcm4sIHdlIGNhbiBzaW1wbGlm eSB0aGUgbGlmZSBvZiBtYW55IGRldmVsb3BlcnMgd2hpbGUgZW5zaHJpbmluZyBiYXNpYyBzZWN1 cml0eSBoeWdpZW5lIGluIHNjZW5hcmlvcyB0aGF0IHdvdWxkIGhhdmUgb3RoZXJ3aXNlIGJlIGxl ZnQgdG8gdGhlaXIgb3duIGRldmljZS4NCg0KTG9va2luZyBmb3J3YXJkIGZvciB5b3VyIGZlZWRi YWNrIQ0KDQpCJlYNCg0K77u/T24gMi8xMi8yMSwgMTI6NDEsICJpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4iIDxpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQoNCiAg IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50 eHQNCiAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVml0dG9yaW8gQmVydG9j Y2kgYW5kIHBvc3RlZCB0byB0aGUNCiAgIElFVEYgcmVwb3NpdG9yeS4NCg0KICAgTmFtZTogICAg ICAgIGRyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmDQogICBSZXZpc2lvbjogICAgMDANCiAg IFRpdGxlOiAgICAgICAgVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJh Y2tlbmQgRm9yIEZyb250ZW5kDQogICBEb2N1bWVudCBkYXRlOiAgICAyMDIxLTAyLTEyDQogICBH cm91cDogICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgUGFnZXM6ICAgICAgICAxNg0K ICAgVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt YmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0DQogICBTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYv DQogICBIdG1sOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm dC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC5odG1sDQogICBIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAw DQoNCg0KICAgQWJzdHJhY3Q6DQogICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgYSBK YXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxlZ2F0ZSBhY2Nlc3MNCiAgICAgIHRva2VuIGFjcXVp c2l0aW9uIHRvIGEgYmFja2VuZCBjb21wb25lbnQuICBJbiBzbyBkb2luZywgdGhlIGZyb250ZW5k DQogICAgICBjYW4gYWNjZXNzIHJlc291cmNlIHNlcnZlcnMgZGlyZWN0bHkgd2l0aG91dCB0YWtp bmcgb24gdGhlIGJ1cmRlbiBvZg0KICAgICAgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0b2tlbnMsIGFuZA0KICAgICAgcGVyZm9ybWluZyBv cGVyYXRpb25zIHRoYXQgYXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW4N CiAgICAgIGV4ZWN1dGVkIGluIGEgdXNlciBhZ2VudCwgYnV0IGFyZSBzYWZlIGFuZCB3ZWxsIHBy b3ZlbiB3aGVuIGV4ZWN1dGVkDQogICAgICBieSBhIGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmlu ZyBvbiBhIGJhY2tlbmQuDQoNCg0KDQoNCiAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KICAgVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KRm9yZ2VSb2Nr IHZhbHVlcyB5b3VyIFByaXZhY3k8aHR0cHM6Ly93d3cuZm9yZ2Vyb2NrLmNvbS95b3VyLXByaXZh Y3k+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1 dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_CO6PR18MB4052B7B005A1CA1F3AACF417AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTm90byBTYW5zIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDUgNCAyIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS02 NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1bXNvbGlzdHBhcmFn cmFwaCwgbGkuZ21haWwtbS02NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2 NDgzMDY1bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tNjQ3NTI2NjExNjA1Nzk2Njg0N2dt YWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NW1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5h bWU6Z21haWwtbV8tNjQ3NTI2NjExNjA1Nzk2Njg0N2dtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2 NW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLmdtYWlsLW0tNjQ3NTI2NjExNjA1Nzk2Njg0N2dtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2 NWdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0t NjQ3NTI2NjExNjA1Nzk2Njg0N2dtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2 MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tLTY0NzUyNjYxMTYw NTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5 OTc5NDltc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTY0NzUyNjYx MTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0 NDM5OTc5NDltc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5nbWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2 MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDlhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tNjQ3NTI2NjExNjA1Nzk2Njg0N2dtYWlsLW0t ODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OWFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjU4NzIyMjYyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDAzMDk0 NDIwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTcwNDMwMjAwOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotNjc1OTI5ODE4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6MTI0MjA2MDA5MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA2NzIyNjQwNDt9DQpA bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE1NjAyODgzODg7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjEzOTk2MzA1NzY7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDox OTU5MzM2MTk2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotOTQxMzQ4MTQwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGw0OmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjE5 NjcxNTU2NTc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ0OTIxMjA2Mjt9DQpAbGlzdCBsNTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgbWUgcmV3 aW5kIGEgYml0IGhlcmUuIFRoaXMgd2FzIG5ldmVyIHByZXNlbnRlZCBhcyBkcml2aW5nIHVzZSBj YXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBs ZXZlbDEgbGZvNiI+TmVpbCBzdWdnZXN0ZWQgdGhhdCB0aGUgYmFja2VuZCBjb3VsZCBzaW1wbHkg Z2l2ZSBzaG9ydCBsaXZlZCBKVFdzIGZvciB0aGUgZnJvbnRlbnQgdG8gY2FsbCBBUEkuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNiI+SSBjbGFyaWZpZWQgdGhhdCB0aGlzIHdvdWxk IG5vdCBiZSB2aWFibGUgaW4gdGhlIGdlbmVyYWwgY2FzZSBhbmQgcHJvdmlkZWQgYW4gZXhhbXBs ZSBzY2VuYXJpbyB3aGVyZSBiYWNrZW5kIGlzc3VlZCBzaG9ydCBsaXZlZCB0b2tlbnMgd291bGQg bm90IGhhdmUgd29ya2VkPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvNiI+WW91IGNv bW1lbnRlZCB0aGF0IHRoZSBmcm9udGVuZCBjYW4gb2J0YWluIEFTIHRva2VucyBmcm9tIEpTIGFu ZCBtZW50aW9uZWQgc2lsZW50IGF1dGhlbnRpY2F0aW9uLiBJIGNsYXJpZmllZCAob3IgdHJpZWQg dG8pIHRoYXQgdGhpcyBvZmZzaG9vdCBvZiB0aGUgZGlzY3Vzc2lvbiB3YXNu4oCZdCB0byBzYXkg dGhhdA0KIHRoZXJlIGlzIG5vIHZpYWJsZSB3YXkgb2YgZG9pbmcgdGhlIHNjZW5hcmlvIGFscmVh ZHksIGFuZCBieSB0aGUgd2F5IHVzaW5nIGFuIGlGcmFtZSB0byBkbyBzaWxlbnQgYXV0aGVudGlj YXRpb24gaXMgbm93IHByb2JsZW1hdGljLiBBdCB0aGlzIHBvaW50IHdlIGFyZSBubyBsb25nZXIg ZGlzY3Vzc2luZyBUTUktQkZGLCBidXQgY3VycmVudCBhZmZhaXJzIGluIHRoZSBhdXRoZW50aWNh dGlvbiB3b3JsZC4gVGhlIGZhY3QgdGhhdCB3ZSBhcmUgcHJvcG9zaW5nDQogVE1JLUJGRiBhbmQg dGhlIGZhY3QgdGhhdCBzaWxlbnQgYXV0aGVudGljYXRpb24gaXMgbGVzcyBhbmQgbGVzcyB2aWFi bGUgYXJlIGluZGVwZW5kZW50IGZhY3RzLCB0aGUgZm9ybWVyIGlzbuKAmXQgbWVhbnQgdG8gYmUg YSBzb2x1dGlvbiBmb3IgdGhlIGxhdHRlciAoaXTigJlzIGFscmVhZHkgYWRkcmVzc2VkIGJ5IHVz aW5nIFJUcyBpbiBjb2tlK1BLQ0UpPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQg Y2xhcmlmaWVkLiBOb3Qgb25seSB3ZSBleHBlY3QgSVRQIHRvIGFmZmVjdCBzaWxlbnQgYXV0aGVu dGljYXRpb24sIGl0IGhhcyBiZWVuIGFmZmVjdGVkIGZvciB0aGUgcGFzdCB5ZWFyIGFuZCB0aGF0 IGhhcyBiZWVuIG9uZSBvZiB0aGUgcHJpbWFyeSBidXNpbmVzcyBkcml2ZXJzIGZvciB0aGUgcmFw aWQgYWRvcHRpb24gb2YgY29kZStQS0NFK1JUcyBpbiB0aGUgdXNlciBhZ2VudCwgYXMgY3VzdG9t ZXJzDQogd2l0aCBwdXJlIFNQQXMgZm91bmQgdGhlbXNlbHZlcyB1bmFibGUgdG8gcmVuZXcgdG9r ZW5zIHdpdGhvdXQgcHJvbXB0aW5nIGFzIHRoZWlyIGFjY2VzcyB0byBjb29raWVzIGluIGZsb3dz IGRyaXZlbiBieSBpZnJhbWVzIGJlY2FtZSBsZXNzIGFuZCBsZXNzIHJlbGlhYmxlLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIElUUCB3YXMgaW50cm9kdWNlZCB3 ZSBwdXQgbWFueSBjb21wYW5pZXMgdG9nZXRoZXIgdG8gdHJ5IHRvIGdldCBBcHBsZSB0byBjaGFu Z2UgaXQgKHlvdSBjYW4gZmluZCB0aGUgZG9jIGluDQo8YSBocmVmPSJodHRwczovL2RvY3MuZ29v Z2xlLmNvbS9kb2N1bWVudC9kLzFScy0tREZ6WmpfU2ZRanR6OG9IOURsTElJMHJhM3ZpTUVIcks3 c0tzYWlVL2VkaXQjaGVhZGluZz1oLnAzbnZwNnhteHZ6ZiI+DQpodHRwczovL2RvY3MuZ29vZ2xl LmNvbS9kb2N1bWVudC9kLzFScy0tREZ6WmpfU2ZRanR6OG9IOURsTElJMHJhM3ZpTUVIcks3c0tz YWlVL2VkaXQjaGVhZGluZz1oLnAzbnZwNnhteHZ6ZjwvYT4pIGJ1dCB0aGV5IGRpZG7igJl0IGJ1 bGdlIGFuZCB1bHRpbWF0ZWx5IHRoZSBpbnRyb2R1Y3Rpb24gb2YgUlRzIGluIHVzZXIgYWdlbnQg Y29kZSAoYWxiZWl0IHdpdGggZXh0cmEgcmVzdHJpY3Rpb25zLCB0aGUgb25lIEkgbWVudGlvbmVk IG5vdCBldmVyeW9uZQ0KIGlzIGZvbGxvd2luZykgbWFkZSB0aGUgcHJvYmxlbSBtYW5hZ2VhYmxl LiBXZSBoYXZlIGFuIGluaXRpYXRpdmUgY3Jvc3Mgd29ya2luZyBncm91cHMgKElFVEYsIE9JREMg ZXRjKWZvciB3b3JraW5nIHdpdGggYnJvd3NlciB2ZW5kb3JzIHRvIHRyeSBjb250YWluaW5nIHNp bWlsYXIgcmVncmVzc2lvbnMgaW4gdGhlIGZ1dHVyZS4gRm9yIGEgc3VtbWFyeSBvZiBzaW1pbGFy IHByb2JsZW1zIHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9pZGVudGl2ZXJzZS5nYWxsZXJ5LnZpZGVv L2RldGFpbC92aWRlby82MTg0NDQzMDM3MDAxL2Jyb3dzZXItZmVhdHVyZXMtdnMtaWRlbnRpdHkt cHJvdG9jb2xzIj4NCmh0dHBzOi8vaWRlbnRpdmVyc2UuZ2FsbGVyeS52aWRlby9kZXRhaWwvdmlk ZW8vNjE4NDQ0MzAzNzAwMS9icm93c2VyLWZlYXR1cmVzLXZzLWlkZW50aXR5LXByb3RvY29sczwv YT4uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyByZXN0YXRlLCB0aGUgVE1JLUJG RiBwcm9wb3NhbCBpcyBub3QgdHJ5aW5nIHRvIGZpeCBhbnkgb2YgdGhhdCwgbm9yIHBlciB0aGUg YWJvdmUgc29tZSBvZiBpdCBuZWVkIGZpeGluZy4gVGhlIG9ubHkgaW5kaXJlY3QgY29ubmVjdGlv biBtaWdodCBiZSB0aGF0IGxlc3Mgc3R1ZmYgaGFwcGVuaW5nIGluIHRoZSB1c2VyIGFnZW50IG1l YW5zIGxlc3Mgb3Bwb3J0dW5pdGllcyBmb3Igc2ltaWxhciBjaGFuZ2VzDQogdG8gaW1wYWN0IHRo ZSBmbG93cywgYnV0IGl04oCZcyBkZWZpbml0ZWx5IG5vdCBhIHRvcCBsZXZlbCBkcml2ZXIuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5XYXJyZW4gUGFyYWQgJmx0 O3dwYXJhZD00MHJob3N5cy5jaEBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAxMTo0MTxicj4NCjxiPlRvOiA8L2I+Vml0dG9y aW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSZndDs8YnI+DQo8Yj5D YzogPC9iPk5laWwgTWFkZGVuICZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tJmd0OywgJnF1 b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5m b3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IG9ubHkgYXBw bGllcyB0byB0aGlyZCBwYXJ0eSBjb29raWVzLCBpdCBzaG91bGRuJ3QgYWZmZWN0IHRoaXJkLXBh cnR5IGlmcmFtZXMgYXMgZmFyIGFzIEknbSBhd2FyZS4gU28gdW5sZXNzIHdlIGV4cGVjdCB0aG9z ZSB0byBicmVhaywgd2UgcHJvYmFibHkgc2hvdWxkbid0IGluY2x1ZGUgdGhhdCZuYnNwO2FzIGEg ZHJpdmluZyB1c2UgY2FzZS4gSXMgdGhlcmUgYW5vdGhlciBtZWFzdXJlIHRoYXQgd291bGQgYmUN CiByZWxldmFudCBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0i MCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEu MHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6NS4wcHQgNS4wcHQg NS4wcHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBh cmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRl cjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE5OSIgaGVpZ2h0PSIzNCIgc3R5 bGU9IndpZHRoOjIuMDcyOWluO2hlaWdodDouMzU0MWluIiBpZD0iX3gwMDAwX2kxMDI1IiBhbHQ9 IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiIgZGF0YS1vdXRsb29rLXRyYWNlPSJGOjB8VDoxIiBz cmM9ImNpZDp+V1JEMTU3LmpwZyI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3Rk Pg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRl ci1sZWZ0Om5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRk ZW4iPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xp ZCB3aGl0ZSAxLjBwdDtib3JkZXItYm90dG9tOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4i Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRlcjpub25l O3BhZGRpbmc6MGluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+V2FycmVuIFBhcmFkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xp ZCB3aGl0ZSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRlcjpub25lO3Bh ZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aGl0ZSI+U2Vj dXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0 ZWN0dXJlLiBJbXBsZW1lbnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9hdXRocmVzcy5p byIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BdXRocmVz czwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgNzo1NyBQTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7 dml0dG9yaW8uYmVydG9jY2k9PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYu b3JnIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPklUUCwgZm9yIGV4YW1wbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+V2FycmVuIFBhcmFkICZsdDt3cGFyYWQ9PGEgaHJlZj0ibWFpbHRvOjQw cmhvc3lzLmNoQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDByaG9zeXMuY2hAZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIEZlYnJ1YXJ5IDE0 LCAyMDIxIGF0IDA0OjU0PGJyPg0KPGI+VG86IDwvYj5WaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5OZWls IE1hZGRlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5jb20iIHRh cmdldD0iX2JsYW5rIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2Vu ZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DYW4geW91IGV4cGFuZCBvbiB3aGF0IHNpbGVudCBh dXRoZW50aWNhdGlvbiBhbmQgc2Vzc2lvbiB0b2tlbiBzdGFuZHMgZm9yIGhlcmU/IElmIHlvdSBh cmUgcmVmZXJyaW5nIHRvIHRoZSBpZnJhbWUgc2NlbmFyaW8sIHRoZSBuZXcgYnJvd3NlciBtZWFz dXJlcyBtYWtlIGl0IHByb2JsZW1hdGljLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpY2ggbmV3IGJyb3dzZXIgbWVhc3VyZXM/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi ciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2Jv cmRlci1yaWdodDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6NS4wcHQgNS4wcHQgNS4wcHQg NS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4iPjxiPkVycm9yISBGaWxlbmFtZSBub3Qgc3BlY2lmaWVkLjwvYj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJi b3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUu MHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29s aWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWJvdHRvbTpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldhcnJlbiBQ YXJhZDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAw aW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndoaXRlIj5TZWN1cmUgeW91ciB1c2VyIGRh dGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1cmUuIEltcGxlbWVu dCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2F1dGhyZXNzLmlvIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkF1dGhyZXNzPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBGZWIgMTQs IDIwMjEgYXQgMTozMyBQTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9 PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS02 NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1bXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1zby1saXN0OmwzIGxldmVsMSBsZm8xIj4NCkZvciBVSSByZWxhdGVkIGZ1 bmN0aW9uYWxpdHksIGkuZS4gZG9jdW1lbnQgc2VsZWN0aW9uLCB1c2VyIHByb2ZpbGUgZGlzcGxh eS9jaGFuZ2VzLCBjb250YWN0IHVwZGF0ZXMsIGV0Yy4uLiBZb3Ugc2hvdWxkIGJlIGFibGUgdG8g ZXhlY3V0ZSB0aGUgY2xpZW50IHNpZGUNCjxiPnNpbGVudCBhdXRoZW50aWNhdGlvbjwvYj4mbmJz cDt1c2luZyB0aGUgcHJvdmlkZWQgc2Vzc2lvbiB0b2tlbiBmcm9tIHRoZSBBenVyZSBBRCBBUywg d2l0aG91dCBuZWVkaW5nIHRvIG1ha2UgYW55IFJPIGFwaSBjYWxscyBub3IgdXNlciByZWRpcmVj dHMuJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNh biB5b3UgZXhwYW5kIG9uIHdoYXQgc2lsZW50IGF1dGhlbnRpY2F0aW9uIGFuZCBzZXNzaW9uIHRv a2VuIHN0YW5kcyBmb3IgaGVyZT8gSWYgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIGlmcmFtZSBz Y2VuYXJpbywgdGhlIG5ldyBicm93c2VyIG1lYXN1cmVzIG1ha2UgaXQgcHJvYmxlbWF0aWMuIElu IGNvZGUrUEtDRQ0KIHlvdSBjYW4gdXNlIGEgcmVmcmVzaCB0b2tlbiwgYnV0IHNlZSB0aGUgb3Ro ZXIgcmVwbHkgZm9yIGhvdyB0aGlzIHByb3Bvc2FsIGlzIGFuIGFsdGVybmF0aXZlIHRvIHRoYXQg aW4gc29tZSBzaXR1YXRpb25zLiBUaGlzIGFuc3dlciB3YXMgc3BlY2lmaWNhbGx5IG9uIHdoeSBo YXZpbmcgYmFja2VuZC1pc3N1ZWQgdG9rZW5zIGRpZG7igJl0IGFwcGx5IHRvIHRoaXMgc2NlbmFy aW8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5XYXJyZW4gUGFyYWQgJmx0 O3dwYXJhZD08YSBocmVmPSJtYWlsdG86NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj40MHJob3N5cy5jaEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMDM6NDg8YnI+DQo8Yj5UbzogPC9i PlZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lA YXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPC9h PiZndDs8YnI+DQo8Yj5DYzogPC9iPk5laWwgTWFkZGVuICZsdDs8YSBocmVmPSJtYWlsdG86bmVp bC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5laWwubWFkZGVuQGZvcmdl cm9jay5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQg c2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRik8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciB0 aGUgdHJ1c3RlZCBwYXJ0LCBzZWUgYWJvdmUuIEZvciB0aGUgc2hvcnQgbGl2ZWQgSldUcywgdGhh dOKAmXMgbm90IHJlYWxseSBhbiBvcHRpb24uIFRoZSBtb3N0IGdlbmVyaWMgc2NlbmFyaW8gYWRk cmVzc2VkIGhlcmUgaXMgZm9yIEFQSXMgdGhhdCBhY2NlcHQgdG9rZW5zIGlzc3VlZCBieSB0aGUg QVM7DQogdGhlIGJhY2tlbmQgY2FuIHJlcXVlc3QgdGhlbSBhcyBhIGNsaWVudCwgYnV0IGl0IGNh bm5vdCBtaW50IHRoZW0uIEltYWdpbmUgd2XigJlyZSB0YWxraW5nIGFib3V0IGEgU1BBIGFwcGxp Y2F0aW9uIHRoYXQgc2lnbnMgaW4gdXNlcnMgdXNpbmcgQXp1cmUgQUQsIGFuZCBuZWVkcyB0byBj YWxsIE9mZmljZSBhbmQgQXp1cmUgQVBJcy4gVGhlIFNQQSBiYWNrZW5kIGNhbm5vdCBpc3N1ZSB0 b2tlbnMgZm9yIHRob3NlIEFQSXMsIGl0IGNhbiBvbmx5IHJlcXVlc3QNCiB0aGVtIHRvIHRoZSBB enVyZSBBRCBBUy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgVUkgcmVsYXRlZCBmdW5jdGlvbmFsaXR5LCBpLmUuIGRv Y3VtZW50IHNlbGVjdGlvbiwgdXNlciBwcm9maWxlIGRpc3BsYXkvY2hhbmdlcywgY29udGFjdCB1 cGRhdGVzLCBldGMuLi4gWW91IHNob3VsZCBiZSBhYmxlIHRvIGV4ZWN1dGUgdGhlIGNsaWVudCBz aWRlDQo8Yj5zaWxlbnQgYXV0aGVudGljYXRpb248L2I+Jm5ic3A7dXNpbmcgdGhlIHByb3ZpZGVk IHNlc3Npb24gdG9rZW4gZnJvbSB0aGUgQXp1cmUgQUQgQVMsIHdpdGhvdXQgbmVlZGluZyB0byBt YWtlIGFueSBSTyBhcGkgY2FsbHMgbm9yIHVzZXIgcmVkaXJlY3RzLiZuYnNwO0ZvciBSTyByZXNw b25zaWJpbGl0aWVzLCB5b3UgY2FuIHByZXNlbnQgdGhlIHVzZXIgd2l0aCBhIGJ1dHRvbiAmcXVv dDtHcmFudCBSTyBhY2Nlc3MgdG8gQXp1cmUgcmVzb3VyY2VzJnF1b3Q7IGJ1dHRvbiBhbmQNCiB0 aGUgdXNlciB3aWxsIGdvIHRocm91Z2gmbmJzcDthIHBlcm1pc3Npb24gc2NvcGUgZWxldmF0aW9u IGZsb3csIGFnYWluIG5vIHJlYXNvbiB0byBuZWVkIGEgQkZGIGhlcmUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2UgZGlkIGNvbnNpZGVyIGFkZGluZyBzb21l dGhpbmcgdG8gdGhhdCBlZmZlY3QsIGFuIGVycm9yIG1lc3NhZ2UgdGhhdCBjYW4gZGlyZWN0IHRo ZSBmcm9udGVuZCB0byBwZXJmb3JtIHRoZSBpbnRlcmFjdGl2ZSBwb3J0aW9uIG5lY2Vzc2FyeSBm b3IgdGhpcyB0b3BvbG9neSB0byB3b3JrLiBJdCB3b3VsZCBiZQ0KIHNvbWV0aGluZyBzaW1pbGFy IHRvIHRoZSBJRFAgaW5pdGlhdGVkIGxvZ2luIGluIE9JREMsIHdoZXJlIHRoZSBjbGllbnQgb2Zm ZXJzIGFuIGVuZHBvaW50IHRoYXQgaXMgZ3VhcmFudGVlZCB0byBpbml0aWF0ZSBhIHNpZ24gaW4g ZmxvdyAoaGVuY2UgaW5qZWN0IGFsbCB0aGUgbmVjZXNzYXJ5IG5vbmNlcyBldGMpLiBXZSBkaWRu 4oCZdCBhZGQgaXQgdXBmcm9udCBhbmQgbGVmdCBpdCBhcyBleGVyY2lzZSBmb3IgdGhlIHJlYWRl ciBtb3N0bHkgYmVjYXVzZQ0KIGl04oCZcyBub3QgZWFzeSB0byBtb2RlbCBwcm9wZXJseSBhbmQg YmVmb3JlIG9wZW5pbmcgdGhhdCB3b3JrIGZyb250IHdlIHdhbnRlZCB0byBzZWUgaG93IHRoZSBp ZGVhIHdhcyByZWNlaXZlZC4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IG1heSBtYWtlIHNlbnNlIGZvciB0 aGUgYXBwIHRvIGhhdmUgYW4gZXJyb3IgbWVzc2FnZSwgb3IgZXZlbiBiZXR0ZXIgbWlnaHQgYmUg YSAzMDINCjxiPkxvY2F0aW9uIGhlYWRlcjwvYj4mbmJzcDtkZXBlbmRpbmcgb24gd2hhdCB5b3Ug YXJlIGRvaW5nLiBUaGVyZSBpcyBub3RoaW5nIGhlcmUgdGhhdCBpcyBPQXV0aCBzcGVjaWZpYyBo b3dldmVyIChub3IgY29tbW9uKSwgYW5kIHRoZW4gd2Ugc2hvdWxkIGNoYWxsZW5nZSB0aGUgbmVl ZCB0byBkaXJlY3RseSBwcm92aWRlIGFuIFJGQyByZWNvbW1lbmRhdGlvbiBmb3IgaGFuZGxpbmcg dGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDti b3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0 IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MGluIj5FcnJvciEgRmlsZW5hbWUgbm90IHNwZWNpZmllZC48L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzo1LjBwdCA1 LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv bGlkIHdoaXRlIDEuMHB0O2JvcmRlci1ib3R0b206bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XYXJyZW4g UGFyYWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4g MGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+Rm91bmRlciwgQ1RPPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aGl0ZSI+U2VjdXJlIHlvdXIgdXNlciBk YXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0ZWN0dXJlLiBJbXBsZW1l bnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9hdXRocmVzcy5pbyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BdXRocmVzczwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFN1biwgRmViIDE0 LCAyMDIxIGF0IDEyOjI5IFBNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2Nj aT08YSBocmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj40MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBOZWlsLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIHRoZSBwcm9tcHQg Y29tbWVudHMhPG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Imdt YWlsLW0tNjQ3NTI2NjExNjA1Nzk2Njg0N2dtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWls LW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDps NSBsZXZlbDEgbGZvMiI+DQpSZTogR0VUIHZzIFBPU1QsPG86cD48L286cD48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjI1aW4iPg0KcGVyc29uYWxseSBJ4oCZ ZCBiZSBmaW5lIHdpdGggcmVzdHJpY3RpbmcgdG8gUE9TVC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS02NDc1MjY2MTE2MDU3OTY2 ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYzNTM2OTIxNDQzOTk3OTQ5 bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClJlOiBS Ty1BUywgaW50ZXJhY3Rpb24tIDxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5wZXJoYXBzIGl0IGlzIG5vdCB2ZXJ5IGNsZWFyIGZyb20gdGhlIHRleHQgYXQgdGhl IG1vbWVudCAoZmlyc3QgZHJhZnQpLCBidXQgdGhhdCBpcyBhc3N1bWVkIHRoYXQgdGhlIFJPIHdl bnQgdGhydSB3aGF0ZXZlciBpbnRlcmFjdGl2ZSBzdGVwcyBhcmUgbmVjZXNzYXJ5IHRvIGVzdGFi bGlzaCBhIHNlc3Npb24NCiAoZWcgc2lnbiBpbiwgYXNzdW1pbmcgdGhlIEFTIGlzIHNheSBhbiBP SURDIHByb3ZpZGVyKSBhbmQgb2J0YWluIGJlZm9yZWhhbmQgdGhlIGFjY2VzcyB0b2tlbiBhbmQg cmVmcmVzaCB0b2tlbnMgdGhhdCB3aWxsIGJlIG5lZWRlZCBkdXJpbmcgdGhlIGFwcCBhY3Rpdml0 aWVzIHRha2luZyBwbGFjZSBhZnRlciAmbmJzcDt0aGF0LiBJbiBjb25jcmV0ZSB0ZXJtcywgaW1h Z2luZSB0aGF0IHRoZSBiYWNrZW5kIHBlcmZvcm1zIGFuIGF1dGhvcml6YXRpb24gY29kZQ0KIGdy YW50IHJlcXVlc3RpbmcgYW4gSUR0b2tlbiwgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2Vu IEJFRk9SRSB0aGUgYWN0aXZpdGllcyBkZXNjcmliZWQgaW4gVE1JLUJGRiB0YWtlIHBsYWNlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY3VycmVudCBsYW5ndWFn ZSB0cnlpbmcgdG8gZXhwcmVzcyB0aGF0IGlzIGluIDEuMjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Tm90byBTYW5zJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3Jv dW5kOndoaXRlIj5BcyBhIHByZXJlcXVpc2l0ZSBmb3IgdGhlIGZsb3cgZGVzY3JpYmVkIGJlbG93 LCB0aGUgYmFja2VuZCBNVVNUIGhhdmUgZXN0YWJsaXNoZWQNCiBhIHNlY3VyZSBzZXNzaW9uIHdp dGggdGhlIHVzZXIgYWdlbnQsIHNvIHRoYXQgYWxsIHJlcXVlc3RzIGZyb20gdGhhdCB1c2VyIGFn ZW50IHRvd2FyZCB0aGUgYmFja2VuZCBvY2N1ciBvdmVyIEhUVFBTIGFuZCBjYXJyeSBhIHZhbGlk IHNlc3Npb24gYXJ0aWZhY3QgKHN1Y2ggYXMgYSBjb29raWUpIHRoYXQgdGhlIGJhY2tlbmQgY2Fu IHZhbGlkYXRlLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1hbmRhdGUgYW55IHNwZWNpZmljIG1l Y2hhbmlzbSB0bw0KIGVzdGFibGlzaCBhbmQgbWFpbnRhaW4gdGhhdCBzZXNzaW9uLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O05vdG8gU2FucyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7 YmFja2dyb3VuZDp3aGl0ZSI+Y2FjaGVkLCBpdCByZXF1ZXN0cyB0byB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYSBuZXcgYWNjZXNzIHRva2VuIHdpdGggdGhlIHJlcXVpcmVkDQogY2hhcmFjdGVy aXN0aWNzLCB1c2luZyBhbnkgYXJ0aWZhY3RzIHByZXZpb3VzeSBvYnRhaW5lZCAoZWcgcmVmcmVz aCB0b2tlbikgYW5kIGdyYW50cyB0aGF0IHdpbGwgYWxsb3cgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHRvIGlzc3VlIHRoZSByZXF1ZXN0ZWQgdG9rZW4gd2l0aG91dCByZXF1aXJpbmcgdXNlciBp bnRlcmFjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFp bC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1t LTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzQiPg0KPHNwYW4gY2xhc3M9ImdtYWlsLW0tNjQ3NTI2NjExNjA1Nzk2Njg0N2dt YWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2MzUzNjkyMTQ0Mzk5Nzk0OWFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+SWYgdGhlIGJhY2tlbmQgaXMgYWxyZWFkeSBpbXBsaWNp dGx5IHRydXN0ZWQgdGhlbiBjb3VsZG7igJl0IHlvdSBza2lwIE9BdXRoIGFuZCBqdXN0DQogZ2V0 IHRoZSBiYWNrZW5kIHRvIGlzc3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRo YXQgaXQgY2FuIHVzZSBmb3IgQVBJIGFjY2Vzcz88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHRoZSB0cnVzdGVkIHBhcnQsIHNlZSBhYm92ZS4gRm9yIHRo ZSBzaG9ydCBsaXZlZCBKV1RzLCB0aGF04oCZcyBub3QgcmVhbGx5IGFuIG9wdGlvbi4gVGhlIG1v c3QgZ2VuZXJpYyBzY2VuYXJpbyBhZGRyZXNzZWQgaGVyZSBpcyBmb3IgQVBJcyB0aGF0IGFjY2Vw dCB0b2tlbnMgaXNzdWVkIGJ5IHRoZSBBUzsNCiB0aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVt IGFzIGEgY2xpZW50LCBidXQgaXQgY2Fubm90IG1pbnQgdGhlbS4gSW1hZ2luZSB3ZeKAmXJlIHRh bGtpbmcgYWJvdXQgYSBTUEEgYXBwbGljYXRpb24gdGhhdCBzaWducyBpbiB1c2VycyB1c2luZyBB enVyZSBBRCwgYW5kIG5lZWRzIHRvIGNhbGwgT2ZmaWNlIGFuZCBBenVyZSBBUElzLiBUaGUgU1BB IGJhY2tlbmQgY2Fubm90IGlzc3VlIHRva2VucyBmb3IgdGhvc2UgQVBJcywgaXQgY2FuIG9ubHkg cmVxdWVzdA0KIHRoZW0gdG8gdGhlIEF6dXJlIEFEIEFTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iZ21haWwtbS02NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0 OTg2NDgzMDY1Z21haWwtbS01MTYzNTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBhcmFncmFwaCIgc3R5 bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm81Ij4NCklmIHlvdSB3YW50IHRvIGFsbG93IGF1dGgg Y29kZSBmbG93IGV0YyB0aGVuIHBlcmhhcHMgdGhlIGJmZi10b2tlbiBlbmRwb2ludCBjYW4gcmV0 dXJuIGEgc3RhbmRhcmQgZXJyb3IgY29kZSB3aXRoIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQg VVJJIHRoYXQgdGhlIFNQQSB0aGVuIG5hdmlnYXRlcyB0aGUgdXNlciB0by4gKEVnIHRoZSBiYWNr ZW5kIGNhbiBkbyBhIFBBUiByZXF1ZXN0IGZpcnN0IGFuZCByZXR1cm4gYSBVUkkgdGhhdCByZWZl cmVuY2VzDQogdGhhdCBzbyB0aGF0IGF1dGhvcml6YXRpb24gZGV0YWlscyBhcmVu4oCZdCBwYXNz ZWQgdGhyb3VnaCB0aGUgZnJvbnRlbmQpLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5XZSBkaWQgY29uc2lkZXIgYWRkaW5nIHNvbWV0aGluZyB0byB0 aGF0IGVmZmVjdCwgYW4gZXJyb3IgbWVzc2FnZSB0aGF0IGNhbiBkaXJlY3QgdGhlIGZyb250ZW5k IHRvIHBlcmZvcm0gdGhlIGludGVyYWN0aXZlIHBvcnRpb24gbmVjZXNzYXJ5IGZvciB0aGlzIHRv cG9sb2d5IHRvIHdvcmsuIEl0IHdvdWxkIGJlDQogc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIElE UCBpbml0aWF0ZWQgbG9naW4gaW4gT0lEQywgd2hlcmUgdGhlIGNsaWVudCBvZmZlcnMgYW4gZW5k cG9pbnQgdGhhdCBpcyBndWFyYW50ZWVkIHRvIGluaXRpYXRlIGEgc2lnbiBpbiBmbG93IChoZW5j ZSBpbmplY3QgYWxsIHRoZSBuZWNlc3Nhcnkgbm9uY2VzIGV0YykuIFdlIGRpZG7igJl0IGFkZCBp dCB1cGZyb250IGFuZCBsZWZ0IGl0IGFzIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIG1vc3RseSBi ZWNhdXNlDQogaXTigJlzIG5vdCBlYXN5IHRvIG1vZGVsIHByb3Blcmx5IGFuZCBiZWZvcmUgb3Bl bmluZyB0aGF0IHdvcmsgZnJvbnQgd2Ugd2FudGVkIHRvIHNlZSBob3cgdGhlIGlkZWEgd2FzIHJl Y2VpdmVkLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+T0F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBv ZiBOZWlsIE1hZGRlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5j b20iIHRhcmdldD0iX2JsYW5rIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAwMDoxNzxicj4NCjxi PlRvOiA8L2I+Vml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTxhIGhyZWY9 Im1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0 aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhy ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3Jn PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09B VVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBG b3IgRnJvbnRlbmQgKFRNSSBCRkYpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZl IGEgbG90IG9mIHNlY3VyaXR5IGNvbmNlcm5zIGFib3V0IHRoaXMgZHJhZnQuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg ZHJhZnQgYWxsdWRlcyB0byBzZWN1cml0eSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGhhbmRsaW5n IGFjY2VzcyB0b2tlbnMgaW4gdGhlIGZyb250ZW5kIGJ1dCBuZXZlciByZWFsbHkgc3BlbGxzIHRo ZW0gb3V0LiBGcm9tIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBpdCBzZWVtcyB0aGF0IHRo ZQ0KIHByaW1hcnkgY29uY2VybiBpcyB3aXRoIHRoZWZ0IG9mIGFjY2VzcyB0b2tlbnMgZnJvbSBs b2NhbCBzdG9yYWdlLiBUbyBkbyB0aGlzIHlvdeKAmWQgbmVlZCBhbiBYU1MgYXR0YWNrLiBCdXQg aW4gdGhhdCBjYXNlLCB3b3VsZG7igJl0IHRoZSBhdHRhY2tlciBzaW1wbHkgdXNlIHRoZSBYU1Mg dG8gbWFrZSBhIGNhbGwgdG8gdGhlIGJmZi10b2tlbiBlbmRwb2ludCBpbnN0ZWFkPyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBiZmYtdG9rZW4gZW5kcG9pbnQgcmVjb21tZW5kaW5nIHRo ZSB1c2Ugb2YgR0VUIHJlcXVlc3RzIHRvZ2V0aGVyIHdpdGggdGhlIGhpbnQgdG8gdXNlIGNvb2tp ZS1iYXNlZCBhdXRoZW50aWNhdGlvbiBpcyBsaWtlbHkgZ29pbmcgdG8gcHVuY2ggYSBob2xlIGlu IG1vc3QNCiBDU1JGIGRlZmVuc2VzLCB3aGljaCBhc3N1bWUgdGhhdCBHRVRzIGFyZSBzYWZlLiBU aGUgb25seSB0aGluZyBwcmV2ZW50aW5nIHRoaXMgYmVpbmcgZXhwbG9pdGFibGUgaXMgQ3Jvc3Mt T3JpZ2luIFJlYWQgQmxvY2tpbmcgKDxhIGhyZWY9Imh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291 cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19vcmln aW5fcmVhZF9ibG9ja2luZ19leHBsYWluZXIubWQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2No cm9taXVtLmdvb2dsZXNvdXJjZS5jb20vY2hyb21pdW0vc3JjLysvbWFzdGVyL3NlcnZpY2VzL25l dHdvcmsvY3Jvc3Nfb3JpZ2luX3JlYWRfYmxvY2tpbmdfZXhwbGFpbmVyLm1kPC9hPikNCiBkdWUg dG8gdGhlIEpTT04gY29udGVudC10eXBlLiBUaGF0IG1ha2VzIG1lIHJlYWxseSBuZXJ2b3VzLiBX ZSBzaG91bGQgYXQgbGVhc3QgbWFuZGF0ZSBYLUNvbnRlbnQtVHlwZS1PcHRpb25zOiBub3NuaWZm IG9uIHRoYXQgcmVzcG9uc2UuIEnigJlkIGZlZWwgbW9yZSBjb21mb3J0YWJsZSBpZiB0aGlzIHdh cyBhIFBPU1QgcmVxdWVzdCBvbmx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgU3RveWNobyBTbGVwdHNvdiBtZW50aW9u ZWQgaW4gdGhlIG90aGVyIGVtYWlsLCB0aGUgbGFjayBvZiBmcm9udC1jaGFubmVsIGNvbW11bmlj YXRpb24gYmV0d2VlbiB0aGUgQVMgYW5kIHRoZSBSTyBzZWVtcyBvZGQuIElmIHRoZSBiYWNrZW5k IGlzIGFscmVhZHkgaW1wbGljaXRseSB0cnVzdGVkIHRoZW4NCiBjb3VsZG7igJl0IHlvdSBza2lw IE9BdXRoIGFuZCBqdXN0IGdldCB0aGUgYmFja2VuZCB0byBpc3N1ZSBzaG9ydC1saXZlZCBKV1Rz IHRvIHRoZSBmcm9udGVuZCB0aGF0IGl0IGNhbiB1c2UgZm9yIEFQSSBhY2Nlc3M/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB5b3Ug d2FudCB0byBhbGxvdyBhdXRoIGNvZGUgZmxvdyBldGMgdGhlbiBwZXJoYXBzIHRoZSBiZmYtdG9r ZW4gZW5kcG9pbnQgY2FuIHJldHVybiBhIHN0YW5kYXJkIGVycm9yIGNvZGUgd2l0aCBhbiBhdXRo b3JpemF0aW9uIGVuZHBvaW50IFVSSSB0aGF0IHRoZSBTUEEgdGhlbiBuYXZpZ2F0ZXMgdGhlIHVz ZXINCiB0by4gKEVnIHRoZSBiYWNrZW5kIGNhbiBkbyBhIFBBUiByZXF1ZXN0IGZpcnN0IGFuZCBy ZXR1cm4gYSBVUkkgdGhhdCByZWZlcmVuY2VzIHRoYXQgc28gdGhhdCBhdXRob3JpemF0aW9uIGRl dGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5kKS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPuKAlCBO ZWlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAxMiBGZWIgMjAyMSwg YXQgMjA6NDYsIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaT08YSBocmVm PSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPu+7v0Rl YXIgYWxsLDxicj4NCkJyaWFuIGFuZCB5b3VycyB0cnVseSBhcmUgcHJvcG9zaW5nIGEgbmV3IHNw ZWNpZmljYXRpb24gdGhhdCBzaG93cyBob3cgdGhlIHVzZXIgYWdlbnQgZnJvbnRlbmQgb2YgYSB3 ZWIgYXBwIGNhbiBkZWxlZ2F0ZSB0b2tlbiBhY3F1aXNpdGlvbiBhbmQgcGVyc2lzdGVuY2UgdG8g aXRzIGJhY2tlbmQsIGFuZCByZXF1ZXN0IHN1Y2ggdG9rZW5zIHdoZW4gbmVlZGVkIGZvciBkaXJl Y3QgYWNjZXNzIG9mIHByb3RlY3RlZCByZXNvdXJjZXMgZnJvbSB0aGUNCiBmcm9udGVuZCBjb2Rl Ljxicj4NCjxicj4NClRoZSBwYXR0ZXJuIGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFy eSBmb3JtLCBieSB2YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4 dC5KUy4gVmFyaWFudHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUg Y2F0Y2gtYWxsIHRlcm0gQkZGIChiYWNrZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRl biBtZW50aW9uZWQgaW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFjdGl2aXR5LA0KIGJ1dCBhbHdheXMg bGVmdCBhbGwgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byB0aGUgcmVhZGVyLjxicj4NCldlIGJl bGlldmUgdGhlIHBhdHRlcm4gaGFzIG1lcml0LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdyb3dp bmcgYWRvcHRpb24uIEJ5IGRlbGVnYXRpbmcgYWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIHRo ZSBiYWNrZW5kLCB3ZSBhdm9pZCBtYW55IG9mIHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBwYXJ0 cyAoYW5kIGltcGxpZWQgYXR0YWNrIHN1cmZhY2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNjZXNz IHRva2VucyBmcm9tIGEgdXNlciBhZ2VudC4NCiBUaGUgdG9wb2xvZ3kgYWxzbyByZWxpZXZlcyB0 aGUgZnJvbnRlbmQgZnJvbSB0aGUgbmVlZCBvZiBwZXJzaXN0aW5nIHRva2VucyBpbiBsb2NhbCBz dG9yYWdlLCBhIHdlbGwga25vd24gc29yZSBwb2ludCBvZiB1c2luZyBPQXV0aCBkaXJlY3RseSBp biBKYXZhU2NyaXB0LCBieSByZWx5aW5nIG9uIGl0cyBiYWNrZW5kIHN0b3JhZ2UgYW5kIHNlc3Np b24gdG8gcHJlc2VydmUgdG9rZW5zLjxicj4NCjxicj4NCkFsdGhvdWdoIHRoZSBzcGVjaWZpY2F0 aW9uIGlzIHZlcnkgc2ltcGxlLCBwcm92aWRpbmcgZXhwbGljaXQgZ3VpZGFuY2Ugb24gdGhlIHNj ZW5hcmlvIG9mZmVycyBtYW55IGFkdmFudGFnZXMuICZuYnNwOzxicj4NCi0gSXQgbWFrZXMgaXQg cG9zc2libGUgdG8gY3JlYXRlIGludGVyb3BlcmFibGUgU0RLcywgd2hlcmUgZnJvbnRlbmQgZGV2 IHN0YWNrcyAoYW55IEpTIGZsYXZvcikgY2FuIGJlIG1peGVkIGFuZCBtYXRjaGVkIHdpdGggY29t cGxpYW50IGJhY2tlbmQgc3RhY2tzIChtaWRkbGV3YXJlcyBpbiBub2RlLCBqYXZhLA0KPGEgaHJl Zj0iaHR0cDovL0FTUC5ORVQiIHRhcmdldD0iX2JsYW5rIj5BU1AuTkVUPC9hPiwgUEhQIGV0Yyk8 YnI+DQotIEl0IGFsbG93cyB1cyB0byBwcm92aWRlIGd1aWRhbmNlIG9uIGhvdyB0byBwcm9wZXJs eSB0YWNrbGUgdGhlIHNjZW5hcmlvIGFuZCB3YXJuIGltcGxlbWVudGVycyBhZ2FpbnN0IHNlY3Vy aXR5IHJpc2tzIChzY29wZSBlc2NhbGF0aW9ucywgdXNpbmcgSUR0b2tlbnMgaW5zdGVhZCBvZiBh Y2Nlc3MgdG9rZW5zLCBldGMpPGJyPg0KLSBJdCBhbGxvd3MgdXMgdG8gZGlzY3VzcyAoYW5kIHdo ZW4gYXBwcm9wcmlhdGUsIHByb21vdGUpIHRoaXMgcGF0dGVybiBhcyBwYXJ0IG9mIHRoZSBicm93 c2VyIGFwcHMgc2VjdXJpdHkgZ3VpZGFuY2UsIGFuZCBwb3NpdGlvbiB0aGUgc2NlbmFyaW8gd2hl cmUgZnJvbnRlbmQgb25seSBjYWxscyBBUEkgb24gaXRzIG93biBiYWNrZWQgKGhlbmNlIGRvZXNu 4oCZdCBuZWVkIGFjY2VzcyB0b2tlbnMpIHNpbXBseSBhcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGlz DQogbW9yZSBnZW5lcmFsIHBhdHRlcm48YnI+DQotIFRoaXMgYXBwcm9hY2ggbWFrZXMgbW9ja2lu ZyBhbmQgdGVzdGluZyBhcHBzIHZlcnkgZWFzeSwgcG9zc2libHkgcHJldmVudGluZyBkZXZlbG9w ZXJzIGZyb20gd2Vha2VuaW5nIHRoZSBzZWN1cml0eSBvZiB0aGVpciBzeXN0ZW0gKGVnIHR1cm5p bmcgb24gUk9QRyBvcHRpb25zKSAmbmJzcDtvciB0dXJuaW5nIHRvIHJpc2t5IHByYWN0aWNlcyBs aWtlIHNjcmFwaW5nPGJyPg0KPGJyPg0KTmVlZGxlc3MgdG8gc2F5LCB0aGlzIHNwZWNpZmljYXRp b24gZG9lc27igJl0IGVudGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gZGly ZWN0IHVzZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gYSBicm93c2VyLiBCdXQgcmVhbGl0eSBpcyB0 aGF0IHRoZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJlYWQgdXNlLCBhbmQgdGhlIGNpcmN1bXN0YW5j ZXMgbGVhZGluZyB0byB0aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEgcGFydGljdWxhciBwcm9qZWN0 DQogb25seSB3b3JrIHdpdGggZnJvbnRlbmQgc3RhY2tzOyBjb21wb25lbnRzIGxpa2UgcmV2ZXJz ZSBwcm94aWVzIG1pZ2h0IG5vdCBhbHdheXMgYmUgdmlhYmxlOyBldGMpIGFyZW7igJl0IGdvaW5n IGF3YXkgYW55IHRpbWUgc29vbi4gQnkgcHJvdmlkaW5nIHNpbXBsZSBndWlkYW5jZSBvbiB0aGlz IHBhdHRlcm4sIHdlIGNhbiBzaW1wbGlmeSB0aGUgbGlmZSBvZiBtYW55IGRldmVsb3BlcnMgd2hp bGUgZW5zaHJpbmluZyBiYXNpYyBzZWN1cml0eSBoeWdpZW5lDQogaW4gc2NlbmFyaW9zIHRoYXQg d291bGQgaGF2ZSBvdGhlcndpc2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLjxicj4NCjxi cj4NCkxvb2tpbmcgZm9yd2FyZCBmb3IgeW91ciBmZWVkYmFjayE8YnI+DQo8YnI+DQpCJmFtcDtW ICZuYnNwOzxicj4NCjxicj4NCu+7v09uIDIvMTIvMjEsIDEyOjQxLCAmcXVvdDs8YSBocmVmPSJt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0EgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQ8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDtoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZpdHRv cmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SUVU RiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO05hbWU6ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7UmV2aXNpb246ICZuYnNwOyAmbmJzcDswMDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwO1RpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUb2tlbiBNZWRpYXRpbmcg YW5kIHNlc3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQ8YnI+DQombmJzcDsm bmJzcDsmbmJzcDtEb2N1bWVudCBkYXRlOiAmbmJzcDsgJm5ic3A7MjAyMS0wMi0xMjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwO0dyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlk dWFsIFN1Ym1pc3Npb248YnI+DQombmJzcDsmbmJzcDsmbmJzcDtQYWdlczogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MTY8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtVUkw6ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1 dGgyLXRtaS1iZmYtMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv YXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC50eHQ8L2E+PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi88 L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SHRtbDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC5odG1s IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1i ZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMC5odG1sPC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw O0h0bWxpemVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYt MDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVy dG9jY2ktb2F1dGgyLXRtaS1iZmYtMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7QWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVuZCBjYW4gZGVs ZWdhdGUgYWNjZXNzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dG9r ZW4gYWNxdWlzaXRpb24gdG8gYSBiYWNrZW5kIGNvbXBvbmVudC4mbmJzcDsgSW4gc28gZG9pbmcs IHRoZSBmcm9udGVuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Nh biBhY2Nlc3MgcmVzb3VyY2Ugc2VydmVycyBkaXJlY3RseSB3aXRob3V0IHRha2luZyBvbiB0aGUg YnVyZGVuIG9mPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29tbXVu aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0b2tlbnMs IGFuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3BlcmZvcm1pbmcg b3BlcmF0aW9ucyB0aGF0IGFyZSBmcmF1Z2h0IHdpdGggc2VjdXJpdHkgY2hhbGxlbmdlcyB3aGVu PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXhlY3V0ZWQgaW4gYSB1 c2VyIGFnZW50LCBidXQgYXJlIHNhZmUgYW5kIHdlbGwgcHJvdmVuIHdoZW4gZXhlY3V0ZWQ8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtieSBhIGNvbmZpZGVudGlhbCBj bGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwO3VudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5p ZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIElFVEYgU2VjcmV0 YXJpYXQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny41cHQ7Y29sb3I6IzE3MkI0RDtiYWNrZ3JvdW5kOndoaXRlIj5Gb3JnZVJv Y2sgdmFsdWVzIHlvdXINCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1w cml2YWN5IiB0YXJnZXQ9Il9ibGFuayI+UHJpdmFjeTwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CO6PR18MB4052B7B005A1CA1F3AACF417AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 12:35:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3E3A0A41 for ; Sun, 14 Feb 2021 12:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dELABWyrAtGQ for ; Sun, 14 Feb 2021 12:35:51 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77253A0A3E for ; Sun, 14 Feb 2021 12:35:51 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id t2so2679088pjq.2 for ; Sun, 14 Feb 2021 12:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=KiAyuLeN5jdQ8SXDP31wX+fXM5g+g0iRgawEreTdXNA=; b=cWm6MVDE01c0CmHqTtSoqhgUzV2LrJKZbo1b4VNGQJVu4yKtYC35OBtQWtqTf7DjoT GhFpP1mSbuAF8QaKjd3kbBFAQ/SKCLW2dX96aQ5d+pxr5g0C49xKgZOs0Iaer2ipyJIF t5c+RBqOqN7C7iU5yTTbij3Zdlul/rvrFSncw4ptMw0RcJ7+Ss/je0WnR9kBTW4crUBX GYwr3/uXY/1phSrSLhWh15gcKXReeUBOTRyfdjnlCiATV0K0iPCPxQiyz/KAZn4M/9Aw z+qmovP0ANcZKKmXudj1twvcJvCH6Pdq47wJhW5HtjNnWdEUwgrihtzDwk+NhBEQ4tnH 5+jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=KiAyuLeN5jdQ8SXDP31wX+fXM5g+g0iRgawEreTdXNA=; b=GnsWZWMqOq9pvrLNCZFbDa7hRWp4NHM+3cyFAkB+w4ITkY0yRuGnlEoSRS1R6KfXDc BBeVE11I/zkHSCs3TVaFH/gng+Vma3Wi7DWM+4hE2JuI1+Fm0O7einSkK2Bx6p+z+P1X +1Hu9zHdir7LOAbfvI3/Y0+8UHC6CO+w9u2cEE7Jr/+Nn+rpcdmp7RgCnGYUmsFe+wR5 5j7jmcClTNiAz34CC9WDyTpGI6c2Gxb9KuLS2KQqGD96tjfRWz3FE0Et3uOTdUJ6z1Ne ZKtE5Eq96rmggYa2NRzcd86YeDRAG3GdB8yo1Hm/Mw518gXDyWcY2CibaFArCnajUo2M +e9g== X-Gm-Message-State: AOAM532iVx5b3flalxJkEQ7ihj9uinXaw5dDMahlsbSGQgZewZTjUURE K/CdSHslw7Jp+SIcdeDyvx8jyrjsQIcTtQ== X-Google-Smtp-Source: ABdhPJxuqYuBqxd/OzC9j89C8zrtUpr+l+VsrMC0xutd4aC0E+n6AZBYiV2fZNmKM4uFYQYctTpFJg== X-Received: by 2002:a17:90a:7343:: with SMTP id j3mr12752756pjs.169.1613334950864; Sun, 14 Feb 2021 12:35:50 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id nl12sm16590822pjb.2.2021.02.14.12.35.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 12:35:50 -0800 (PST) From: Vittorio Bertocci To: Torsten Lodderstedt CC: "oauth@ietf.org" , Brian Campbell Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXs6oAgABV6O+AAAdRAIAADhHd X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 20:35:48 +0000 Message-ID: References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> In-Reply-To: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 20:35:54 -0000 VGhhbmtzIQ0KSSBleHBlY3QgdGhlIGZyb250ZW5kIChhcyBpbiBKUyBjb2RlKSBub3QgdG8ga2lj ayBpbiB1bnRpbCB0aGUgaW5pdGlhbCBhdXRob3JpemF0aW9uIGhhcyBiZWVuIHBlcmZvbWVkLiBC cmVha2luZyBpdCBkb3duIGFzIGEgY2xhc3NpYyBwb3NzaWJsZSBmbG93Og0KDQotIFVzZXIgbmF2 aWdhdGVzIHRvIHRoZSBhcHAgcGFnZSwgY2xpY2tzICJzaWduIGluIg0KLSBUaGUgYmFja2VuZCBy ZWRpcmVjdHMgdGhlIHVzZXIgdG8gdGhlIEFTIHRvIHBlcmZvcm0gYSBjb2RlIGdyYW50IChmb3Ig dGhlIHNha2Ugb2YgYXJndW1lbnQgbGV0J3MgYWxzbyBzYXkgdGhleSBhc2sgZm9yIGFuIElEdG9r ZW4gYXMgd2VsbCB0aG8gaXQgaXNu4oCZdCBzdHJpY3RseSBuZWNlc3NhcnkpLCB3aXRoIHRoZSBw dXJwb3NlIG9mIGdhdGhlcmluZyBjb25zZW50IGZvciB0aGUgc2NvcGVzIHJlcXVpcmVkLiBObyBm cm9udGVuZCBjb2RlIGludm9sdmVkLiANCi0gVGhlIGNvZGUgZ3JhbnQgY29uY2x1ZGVzIHN1Y2Nl c3NmdWxseSwgdGhlIGJhY2tlbmQgbm93IGhhcyBhIHNlc3Npb24gd2l0aCB0aGUgdXNlciBhZ2Vu dCBhbmQgYW4gQVQsIFJUIHN0b3JlZCBvbiB0aGUgc2VydmVyIHNpZGUNCi0gLS0+IGhlcmUgVE1J LUJGRiBiZWdpbnMuIFdoZW5ldmVyIHRoZSBmcm9udGVuZCBuZWVkcyBhIHRva2VuIHRvIGNhbGwg YW4gQVBJLCB0aGV5IHVzZSBUTUktQkZGIHRvIGFzayBmb3IgdGhhdCB0b2tlbiB0byB0aGUgYmFj a2VuZA0KLSBpZiB0aGUgYmFja2VuZCBjYW4gcmV0dXJuIHRoZSByZXF1ZXN0ZWQgdG9rZW4sIHZp YSBzdG9yZWQgQVQgb3IgYnkgdXNpbmcgdGhlIFJULCBpdCBkb2VzIGl0DQotIGlmIHRoZSBiYWNr ZW5kIGNhbm5vdCBnZXQgdGhlIHJlcXVlc3RlZCB0b2tlbiB3aXRoIHdoYXQgaXQgYWxyZWFkeSBo YXMgd2l0aG91dCBzdWVyIGludGVyYWN0aW9uLCBpdCBmYWlscw0KLS0+IGhlcmUgdGhlcmUncyB3 aGVyZSBUTUktQkZGIGVuZHMtIGl0J3MgdXAgdG8gdGhlIGJhY2tlbmQgdG8gZGVjaWRlIGhvdyB0 byBtZWV0IHRoZSBuZXcgcmVxdWlyZW1lbnRzLCBlZyBieSB0cmlnZ2VyaW5nIGFub3RoZXIgYXV0 aG9yaXphdGlvbiBjb2RlIGdyYW50IGZvciBuZXcgc2NvcGVzLiBUaGUgZnJvbnRlbmQgaXMgbm90 IGludm9sdmVkIGFwYXJ0IGZyb20gcGVyaGFwcyBvZmZlcmluZyBhZmZvcmRhbmNlcyB0byB0aGUg ZW5kIHVwcGVyIHRvIHN0YXJ0IHN1Y2ggcHJvY2Vzcw0KDQpUTUktQkZGIGRvZXMgbm90IGluY2x1 ZGUgdGhlIGFjdHVhbCBhdXRob3JpemF0aW9uIHJlcXVlc3RzIG1vc3RseSBmb3Igc2ltcGxpY2l0 eS4gV2UgZG9u4oCZdCByZWFsbHkga25vdyBob3cgdGhlIGFwcCBpcyBzdHJ1Y3R1cmVkIG5vciB0 aGUgcmVhc29ucyBmb3Igd2hpY2ggYSBiYWNrZW5kIG1pZ2h0IGJlIHVuYWJsZSB0byBnZXQgdGhl IHJlcXVlc3RlZCB0b2tlbi4gVGhlIFJUIG1pZ2h0IGJlIGV4cGlyZWQ7IG9yIHRoZSBjdXJyZW50 IHNjb3BlcyBtaWdodCBiZSBpbnN1ZmZpY2llbnQ7IG9yIHRoZSBBUyBtaWdodCBkZWNpZGUgdGhh dCBub3cgaXNzdWluZyBhbiBBVCB3aXRoIHRoYXQgc2NvcGUgbWlnaHQgcmVxdWlyZSBhIGRpZmZl cmVudCBhdXRoZW50aWNhdGlvbiBtZXRob2Q7IGFuZCBtYW55IG90aGVyIHJlYXNvbnMgSSBjYW7i gJl0IHRoaW5rIG9mLiBJZiB3ZSB3ZXJlIHRvIHByb3ZpZGUgYSBtZWNoYW5pc20gdGhhdCBpbmNs dWRlcyBpbiB0aGUgZXJyb3IgbWVzc2FnZSBpbmRpY2F0aW9ucyBvbiB3aGF0IHRoZSBmcm9udGVu dCBzaG91bGQgZG8gdG8gcmVtZWRpYXRlIHRoZSBlcnJvciwgd2UgbWlnaHQgbmVlZCB0byBlaXRo ZXIgc2NvcGUgZG93biB0aGUgc2NlbmFyaW9zIG9yIGNyZWF0ZSBhIHZlcnkgZmxleGlibGUgbWVj aGFuaXNtLiBJIGFtIG5vdCBvcHBvc2VkLCBidXQgYmVmb3JlIHZlbnR1cmluZyBpbnRvIHRoYXQg d2Ugd2FudGVkIHRvIHNlZSB3aGF0IHRoZSByZWFjdGlvbiB3b3VsZCBiZS4gIA0KDQrvu79PbiAy LzE0LzIxLCAxMTo0NSwgIlRvcnN0ZW4gTG9kZGVyc3RlZHQiIDx0b3JzdGVuPTQwbG9kZGVyc3Rl ZHQubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0KICAgIEhpIFZpdHRvcmlvLA0KICAgIA0K ICAgIHRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLiBEbyB5b3UgYXNzdW1lIHRoZSBmcm9udGVu ZCBwYXNzZXMgdGhlIGNvZGUgb3IgaW5pdGlhbCByZWZyZXNoIHRva2VuIHRvIHRoZSBiYWNrZW5k IHVzaW5nIGFuIGFwcGxpY2F0aW9uIHNwZWNpZmljIG1lY2hhbmlzbT8gV2h5IGlzbuKAmXQgdGhp cyBwYXJ0IG9mIHRoZSBiZmYtdG9rZW4gcmVxdWVzdD8NCiAgICANCiAgICBiZXN0IHJlZ2FyZHMs DQogICAgVG9yc3Rlbi4NCiAgICANCiAgICA+IEFtIDE0LjAyLjIwMjEgdW0gMjA6MTkgc2Nocmll YiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc+Og0KICAgID4gDQogICAgPiDvu79IaSBUb3JzdGVuLCB0aGFua3MgZm9yIGxvb2tp bmcgaW50byB0aGlzIQ0KICAgID4gVGhlIGlkZWEgaXMgdGhhdCB0aGUgYXBwbGljYXRpb24gYmFj a2VuZCBwZXJmb3JtZWQgYWxsIHRoZSBpbnRlcmFjdGl2ZSB0b2tlbiBhY3F1aXNpdGlvbiBzdGVw cyBiZWZvcmUgVE1JLUJGRiBjb21lIGludG8gcGxheS4NCiAgICA+IEltYWdpbmUgdGhhdCBhIHJl Z3VsYXIgd2ViIGFwcCBwZXJmb3JtcyBhbiBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQsIHJlcXVl c3RpbmcgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VuIGluIHRoZSBwcm9jZXNzIChhbmQg b2Z0ZW4gYWxzbyBzZXR0aW5nIGl0cyBvd24gc2Vzc2lvbiB3aXRoIHRoZSB1c2VyIGFnZW50IGlu IHRoZSBwcm9jZXNzLCBpZiB0aGUgQVMgaXMgYWxzbyB0aGVpciBJZFAgdmlhIE9JREMgb3Igc2lt aWxhciwgYnV0IHRoYXQncyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5KS4gTm93IHRoZSBhcHAgYmFj a2VuZCBoYXMgYW4gYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VuIHBlcnNpc3RlZCBvbiB0 aGUgc2VydmVyIHNpZGUuDQogICAgPiBBbGwgVE1JLUJGRiBkb2VzIGlzIHRvIGRlc2NyaWJlIGhv dyB0aGUgYmFja2VuZCBjYW4gc2hhcmUgdGhvc2UgdG9rZW5zIHdpdGggaXRzIGZyb250ZWQsIGVp dGhlciBkaXJlY3RseSAoaWYgdGhlIHBlcnNpc3RlZCBBVCBpcyBzdGlsbCB2YWxpZCkgb3IgaW5k aXJlY3RseSAoaWYgaXQgaGFzIHRvIHVzZSBhbiBSVCB0byBvYnRhaW4gYSBuZXcgQVQgYmVmb3Jl IHNlbmRpbmcgaXQgYmFjaykuDQogICAgPiBUaGUgZnJvbnRlbmQgcHJvdmlkZXMgcmVzb3VyY2Ug YW5kIHNjb3BlIHRvIHNlbGVjdCB3aGF0IHRva2VuIGl0IG5lZWRzLCBidXQgdGhlIGN1cnJlbnQg aWRlYSBpcyB0aGF0IHRoZSBiYWNrZW5kIGFscmVhZHkgb2J0YWluZWQgYm90aCBjb25zZW50IGFu ZCBhcnRpZmFjdHMgdG8gb2J0YWluIHRob3NlIHRva2VucyBmcm9tIHRoZSBBUy4gQW5kIGlmIGl0 IGRvZXNuJ3QsIGF0IHRoZSBtb21lbnQgd2Ugc2ltcGx5IGZhaWwgYW5kIGV4cGVjdCB0aGUgYXBw IGRldmVsb3BlciB0byB0YWtlIHRoZSBzdGVwcyByZXF1aXJlZCB0byBwcm9tcHQgdGhlIHVzZXIg d2l0aCB3aGF0ZXZlciBpcyBuZWNlc3NhcnkgZm9yIHVwZGF0aW5nIHRoZSBiYWNrZW5kIHdpdGgg dGhlIHJpZ2h0IHBlcm1pc3Npb25zLCBlZyBjcmVhdGluZyBhIG5ldyBhdXRob3JpemF0aW9uIHJl cXVlc3QgYXNraW5nIGZvciBhIHNjb3BlIHRoZSBmcm9udGVuZCBuZWVkcyBhbmQgdGhhdCB0aGUg dXNlciB3YXNuJ3QgcHJvbXB0ZWQgdG8gY29uc2VudCB5ZXQuIEF0IHRoZSBtb21lbnQgVE1JLUJG RiBkb2VzIG5vdCBwcm92aWRlIGEgbWVjaGFuaXNtIGZvciB0aGF0IHByb21wdCB0byBvY2N1ciwg aXQganVzdCBlcnJvcnMgb3V0IHNheWluZyAieW91J3ZlIGdvdCB0byAgdXBkYXRlIHlvdXIgYXV0 aG9yaXphdGlvbiBhcnRpZmFjdHMgYmVmb3JlIHRoZSBmcm9udGVuZCBjYW4gZ2V0IHRoZSB0b2tl biB3IHRoZSBzY29wZXMgaXQgbmVlZHMiLg0KICAgID4gQW5vdGhlciB3YXkgdG8gdGhpbmsgYWJv dXQgdGhpczogaW4gVE1JLUJGRiB0aGUgZnJvbnRlbmQgdHJlYXRzIHRoZSBiYWNrZW5kIGlzIGEg dG9rZW5zIGRhdGFiYXNlLiBJbmRpY2F0aW5nIHRoZSByZXNvdXJjZSBhbmQgc2NvcGVzIGlzIGEg cXVlcnkuIElmIHRoZSBiYWNrZW5kIGNhbiBzZXJ2ZSB0aGF0IHF1ZXJ5ICh3aXRoIHRoZSBBVHMg aXQgc2F2ZWQsIG9yIGJ5IHVzaW5nIHRoZSBSVHMgaXQgc2F2ZWQgQU5EIHRoZSBncmFudHMgdGhl IHVzZXIgYWxyZWFkeSBnYXZlKSBpdCByZXR1cm5zIGEgdG9rZW4uIElmIGl0IGRvZXNuJ3QsIGl0 IGZhaWxzIHRoZSBxdWVyeS4gVGhlIGZyb250ZW5kIGRvZXMgbm90IHBsYXkgYSBkaXJlY3Qgcm9s ZSBpbnRvIGluc2VydGluZyBpbiB0aGUgREIgbW9yZSB0b2tlbnMuIFRoYXQgaXMgbGVmdCB0byB0 aGUgYmFja2VuZCwgdGhhdCBjYW4gZG8gc28gYnkgaW5pdGlhdGluZyBhIG5ldyBhdXRob3JpemF0 aW9uIGdyYW50LCBub3QgZGVzY3JpYmVkIGluIFRNSS1CRkYsIHRoYXQgbXVzdCBjb25jbHVkZSBz dWNjZXNzZnVsbHkgZm9yIHRoZSBmcm9udGVuZCB0byBiZSBhYmxlIHRvIHJlcGVhdCBpdHMgcXVl cnkgYW5kIHRoaXMgdGltZSBnZXQgdGhlIHRva2VuIHRoZXkgd2FudCBvdXQuIE5vdGUgdGhhdCB0 aGUgYmFja2VuZCBtaWdodCBkZWNpZGUgdGhhdCBpdCB3b27igJl0IHRyeSB0byBnZXQgdGhlIHRv a2VuIHJlcXVlc3RlZCwgb3IgaXQgbWlnaHQgdW5hYmxlIHRvIGRvIHNvIChlZyB0aGUgdXNlci9h cHAgY2Fubm90IG1lZXQgc29tZSByZXF1aXJlbWVudHMgYXMgdGhlIEFTIGlzIGNvbmNlcm5lZCks IGhlbmNlIHRoZSByZXF1ZXN0IG9mIGl0IG1pZ2h0IGF0IHRpbWVzIGJlIHBlcm1hbmVudGx5IGRl bmllZC4gVGhpcyBsYXN0IHBhcnQgaXMgdG8gc2F5IHRoYXQgcHJvdmlkaW5nIGluIHRoZSBlcnJv ciBtZXNzYWdlIGRldGFpbHMgYWJvdXQgdGhlIHJlbWVkaWF0aW9uIG1pZ2h0IHRha2UgbW9yZSB3 b3JrIHRoYW4gb25lIHJlYWxpemVzIGF0IGZpcnN0LCBhbmQgdWx0aW1hdGVseSBhY3Rpbmcgb24g dGhlIGVycm9yIHNpdHVhdGlvbiB0byByZXRyaWV2ZSBhIG5ldyB0b2tlbiBpcyBzdGlsbCB1cCB0 byB0aGUgYmFja2VuZCBhbnl3YXksIGhlbmNlIHByb3ZpZGluZyBlbGFib3JhdGUgbWFjaGluZXJ5 IHRvIGluZm9ybSB0aGUgZnJvbnRlbmQgYmV5b25kIHRoZSBlcnJvciBzaXR1YXRpb24gbWlnaHQg bm90IGJlIGFzIGVmZmVjdGl2ZSBhcyBpdCBtaWdodCBsb29rIGF0IGZpcnN0IGdsYW5jZS4gSSBh bSB0b3RhbGx5IG9wZW4gdG8gaXQsIGp1c3QgbWFraW5nIHN1cmUgd2UgdW5kZXJzdGFuZCB3aGF0 IGl0IGNhbiBidXkgdXMuICANCiAgICA+IA0KICAgID4g77u/T24gMi8xNC8yMSwgMDY6MTEsICJU b3JzdGVuIExvZGRlcnN0ZWR0IiA8dG9yc3Rlbj00MGxvZGRlcnN0ZWR0Lm5ldEBkbWFyYy5pZXRm Lm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgIEhpLA0KICAgID4gDQogICAgPiAgICBJ4oCZ bSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB5b3VyIHByb3Bvc2FsLiANCiAgICA+IA0KICAgID4gICAg U2VjdGlvbiAxLjIsIGJ1bGxldCAoQikgc3RhdGVzDQogICAgPiANCiAgICA+ICAgIChCKSBJZiB0 aGUgYmFja2VuZCBkb2VzIG5vdCBhbHJlYWR5IGhhdmUgYSBzdWl0YWJsZSBhY2Nlc3MgdG9rZW4N CiAgICA+ICAgICAgICAgIG9idGFpbmVkIGluIHByZXZpb3VzIGZsb3dzIGFuZCBjYWNoZWQsIGl0 IHJlcXVlc3RzIHRvIHRoZQ0KICAgID4gICAgICAgICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYSBu ZXcgYWNjZXNzIHRva2VuIHdpdGggdGhlIHJlcXVpcmVkDQogICAgPiAgICAgICAgICBjaGFyYWN0 ZXJpc3RpY3MsIHVzaW5nIGFueSBhcnRpZmFjdHMgcHJldmlvdXN5IG9idGFpbmVkIChlZw0KICAg ID4gICAgICAgICAgcmVmcmVzaCB0b2tlbikgYW5kIGdyYW50cyB0aGF0IHdpbGwgYWxsb3cgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyDQogICAgPiAgICAgICAgICB0byBpc3N1ZSB0aGUgcmVxdWVz dGVkIHRva2VuIHdpdGhvdXQgcmVxdWlyaW5nIHVzZXIgaW50ZXJhY3Rpb24uDQogICAgPiANCiAg ICA+ICAgIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4gaG93IHRoZSBhdXRob3JpemF0aW9uIHByb2Nl c3Mgd29ya3MgdG93YXJkcyB0aGUgQVMsIGVzcGVjaWFsbHkgaW4gY2FzZSBvZiB0aGUgYXV0aG9y aXNhdGlvbiBjb2RlIGdyYW50IHR5cGUuIEkgd291bGQgaGF2ZSBleHBlY3RlZCB0byBmcm9udGVu ZCB0byBwYXNzIGFuIGF1dGhvcmlzYXRpb24gY29kZSB0byB0aGUgYmZmLXRva2VuIHJlcXVlc3Qu IA0KICAgID4gDQogICAgPiAgICBCdXQgc2VjdGlvbiA0LjEuIG9ubHkgZGVmaW5lcyB0aGUgcGFy YW1ldGVycyDigJ5yZXNvdXJjZSIgYW5kIOKAnnNjb3BlIiBmb3IgdGhlIGJmZi10b2tlbiBlbmRw b2ludC4gDQogICAgPiANCiAgICA+ICAgIHRoYW5rcywNCiAgICA+ICAgIFRvcnN0ZW4uIA0KICAg ID4gDQogICAgPj4gQW0gMTIuMDIuMjAyMSB1bSAyMTo0NiBzY2hyaWViIFZpdHRvcmlvIEJlcnRv Y2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz46DQogICAg Pj4gDQogICAgPj4gRGVhciBhbGwsDQogICAgPj4gQnJpYW4gYW5kIHlvdXJzIHRydWx5IGFyZSBw cm9wb3NpbmcgYSBuZXcgc3BlY2lmaWNhdGlvbiB0aGF0IHNob3dzIGhvdyB0aGUgdXNlciBhZ2Vu dCBmcm9udGVuZCBvZiBhIHdlYiBhcHAgY2FuIGRlbGVnYXRlIHRva2VuIGFjcXVpc2l0aW9uIGFu ZCBwZXJzaXN0ZW5jZSB0byBpdHMgYmFja2VuZCwgYW5kIHJlcXVlc3Qgc3VjaCB0b2tlbnMgd2hl biBuZWVkZWQgZm9yIGRpcmVjdCBhY2Nlc3Mgb2YgcHJvdGVjdGVkIHJlc291cmNlcyBmcm9tIHRo ZSBmcm9udGVuZCBjb2RlLg0KICAgID4+IA0KICAgID4+IFRoZSBwYXR0ZXJuIGlzIGFscmVhZHkg aW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVu dCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFudHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVu IGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRlcm0gQkZGIChiYWNrZW5kIGZvciBmcm9u dGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQgaW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFj dGl2aXR5LCBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gdGhl IHJlYWRlci4NCiAgICA+PiBXZSBiZWxpZXZlIHRoZSBwYXR0ZXJuIGhhcyBtZXJpdCwgYXMgY29y cm9ib3JhdGVkIGJ5IGl0cyBncm93aW5nIGFkb3B0aW9uLiBCeSBkZWxlZ2F0aW5nIGFjY2VzcyB0 b2tlbiBhY3F1aXNpdGlvbiB0byB0aGUgYmFja2VuZCwgd2UgYXZvaWQgbWFueSBvZiB0aGUgb2Z0 ZW4gYnJpdHRsZSBtb3ZpbmcgcGFydHMgKGFuZCBpbXBsaWVkIGF0dGFjayBzdXJmYWNlKSByZXF1 aXJlZCB0byBhY3F1aXJlIGFjY2VzcyB0b2tlbnMgZnJvbSBhIHVzZXIgYWdlbnQuIFRoZSB0b3Bv bG9neSBhbHNvIHJlbGlldmVzIHRoZSBmcm9udGVuZCBmcm9tIHRoZSBuZWVkIG9mIHBlcnNpc3Rp bmcgdG9rZW5zIGluIGxvY2FsIHN0b3JhZ2UsIGEgd2VsbCBrbm93biBzb3JlIHBvaW50IG9mIHVz aW5nIE9BdXRoIGRpcmVjdGx5IGluIEphdmFTY3JpcHQsIGJ5IHJlbHlpbmcgb24gaXRzIGJhY2tl bmQgc3RvcmFnZSBhbmQgc2Vzc2lvbiB0byBwcmVzZXJ2ZSB0b2tlbnMuDQogICAgPj4gDQogICAg Pj4gQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gaXMgdmVyeSBzaW1wbGUsIHByb3ZpZGluZyBl eHBsaWNpdCBndWlkYW5jZSBvbiB0aGUgc2NlbmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50YWdlcy4g IA0KICAgID4+IC0gSXQgbWFrZXMgaXQgcG9zc2libGUgdG8gY3JlYXRlIGludGVyb3BlcmFibGUg U0RLcywgd2hlcmUgZnJvbnRlbmQgZGV2IHN0YWNrcyAoYW55IEpTIGZsYXZvcikgY2FuIGJlIG1p eGVkIGFuZCBtYXRjaGVkIHdpdGggY29tcGxpYW50IGJhY2tlbmQgc3RhY2tzIChtaWRkbGV3YXJl cyBpbiBub2RlLCBqYXZhLCBBU1AuTkVULCBQSFAgZXRjKQ0KICAgID4+IC0gSXQgYWxsb3dzIHVz IHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIHByb3Blcmx5IHRhY2tsZSB0aGUgc2NlbmFy aW8gYW5kIHdhcm4gaW1wbGVtZW50ZXJzIGFnYWluc3Qgc2VjdXJpdHkgcmlza3MgKHNjb3BlIGVz Y2FsYXRpb25zLCB1c2luZyBJRHRva2VucyBpbnN0ZWFkIG9mIGFjY2VzcyB0b2tlbnMsIGV0YykN CiAgICA+PiAtIEl0IGFsbG93cyB1cyB0byBkaXNjdXNzIChhbmQgd2hlbiBhcHByb3ByaWF0ZSwg cHJvbW90ZSkgdGhpcyBwYXR0ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dzZXIgYXBwcyBzZWN1cml0 eSBndWlkYW5jZSwgYW5kIHBvc2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVyZSBmcm9udGVuZCBvbmx5 IGNhbGxzIEFQSSBvbiBpdHMgb3duIGJhY2tlZCAoaGVuY2UgZG9lc27igJl0IG5lZWQgYWNjZXNz IHRva2Vucykgc2ltcGx5IGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMgbW9yZSBnZW5lcmFsIHBh dHRlcm4NCiAgICA+PiAtIFRoaXMgYXBwcm9hY2ggbWFrZXMgbW9ja2luZyBhbmQgdGVzdGluZyBh cHBzIHZlcnkgZWFzeSwgcG9zc2libHkgcHJldmVudGluZyBkZXZlbG9wZXJzIGZyb20gd2Vha2Vu aW5nIHRoZSBzZWN1cml0eSBvZiB0aGVpciBzeXN0ZW0gKGVnIHR1cm5pbmcgb24gUk9QRyBvcHRp b25zKSAgb3IgdHVybmluZyB0byByaXNreSBwcmFjdGljZXMgbGlrZSBzY3JhcGluZw0KICAgID4+ IA0KICAgID4+IE5lZWRsZXNzIHRvIHNheSwgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXNu4oCZdCBl bnRpcmVseSBlbGltaW5hdGUgdGhlIHJpc2tzIGluaGVyZW50IHRvIGRpcmVjdCB1c2Ugb2YgYWNj ZXNzIHRva2VucyBmcm9tIGEgYnJvd3Nlci4gQnV0IHJlYWxpdHkgaXMgdGhhdCB0aGUgcGF0dGVy biBpcyBpbiB3aWRlc3ByZWFkIHVzZSwgYW5kIHRoZSBjaXJjdW1zdGFuY2VzIGxlYWRpbmcgdG8g dGhhdCAoZWcgZGV2ZWxvcGVycyBvbiBhIHBhcnRpY3VsYXIgcHJvamVjdCBvbmx5IHdvcmsgd2l0 aCBmcm9udGVuZCBzdGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZlcnNlIHByb3hpZXMgbWlnaHQg bm90IGFsd2F5cyBiZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29pbmcgYXdheSBhbnkgdGltZSBz b29uLiBCeSBwcm92aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRoaXMgcGF0dGVybiwgd2UgY2Fu IHNpbXBsaWZ5IHRoZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3aGlsZSBlbnNocmluaW5nIGJh c2ljIHNlY3VyaXR5IGh5Z2llbmUgaW4gc2NlbmFyaW9zIHRoYXQgd291bGQgaGF2ZSBvdGhlcndp c2UgYmUgbGVmdCB0byB0aGVpciBvd24gZGV2aWNlLg0KICAgID4+IA0KICAgID4+IExvb2tpbmcg Zm9yd2FyZCBmb3IgeW91ciBmZWVkYmFjayENCiAgICA+PiANCiAgICA+PiBCJlYgIA0KICAgID4+ IA0KICAgID4+IO+7v09uIDIvMTIvMjEsIDEyOjQxLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCiAgICA+PiANCiAgICA+PiANCiAg ICA+PiAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJm Zi0wMC50eHQNCiAgICA+PiAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVml0 dG9yaW8gQmVydG9jY2kgYW5kIHBvc3RlZCB0byB0aGUNCiAgICA+PiAgIElFVEYgcmVwb3NpdG9y eS4NCiAgICA+PiANCiAgICA+PiAgIE5hbWU6ICAgICAgICBkcmFmdC1iZXJ0b2NjaS1vYXV0aDIt dG1pLWJmZg0KICAgID4+ICAgUmV2aXNpb246ICAgIDAwDQogICAgPj4gICBUaXRsZTogICAgICAg IFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9u dGVuZA0KICAgID4+ICAgRG9jdW1lbnQgZGF0ZTogICAgMjAyMS0wMi0xMg0KICAgID4+ICAgR3Jv dXA6ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICA+PiAgIFBhZ2VzOiAgICAgICAg MTYNCiAgICA+PiAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5nb29nbGUuY29tL3VybD9x PWh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3ElM0RodHRwczovL3d3dy5pZXRmLm9yZy9hcmNo aXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dCUyNnNvdXJjZSUzRGdt YWlsLWltYXAlMjZ1c3QlM0QxNjEzNzY3NTkxMDAwMDAwJTI2dXNnJTNEQU92VmF3M1JiLVMwbDZj RXYweXRqRHh0WUxBUCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxMzkzNTE2NTAwMDAwMCZ1c2c9 QU92VmF3M3A1MjYzYV9yRWVQTmJuWDdqV0ZqcQ0KICAgID4+ICAgU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cSUz RGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10 bWktYmZmLyUyNnNvdXJjZSUzRGdtYWlsLWltYXAlMjZ1c3QlM0QxNjEzNzY3NTkxMDAwMDAwJTI2 dXNnJTNEQU92VmF3My1xZzVNRHRZN2tEMUhwUjVqUjJRWSZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9 MTYxMzkzNTE2NTAwMDAwMCZ1c2c9QU92VmF3MVlabVZIcEVOSGEtYnFxdGJlelJwYQ0KICAgID4+ ICAgSHRtbDogICAgICAgICAgIGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly93 d3cuZ29vZ2xlLmNvbS91cmw/cSUzRGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJh ZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAuaHRtbCUyNnNvdXJjZSUzRGdtYWlsLWltYXAl MjZ1c3QlM0QxNjEzNzY3NTkxMDAwMDAwJTI2dXNnJTNEQU92VmF3MDVXSzRHU0VLY1dqWnpOaHZi MXA1ZCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxMzkzNTE2NTAwMDAwMCZ1c2c9QU92VmF3Mkhp YmZRdFRZdjN0YWxHVDM3OU1PdQ0KICAgID4+ICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vd3d3 Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS91cmw/cSUzRGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMCUyNnNv dXJjZSUzRGdtYWlsLWltYXAlMjZ1c3QlM0QxNjEzNzY3NTkxMDAwMDAwJTI2dXNnJTNEQU92VmF3 MHFtNDVNV0diWmYwemJCalpqM2dneiZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxMzkzNTE2NTAw MDAwMCZ1c2c9QU92VmF3MGdaWjBaVThRVng3T0JqeERjRzhkLQ0KICAgID4+IA0KICAgID4+IA0K ICAgID4+ICAgQWJzdHJhY3Q6DQogICAgPj4gICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBo b3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxlZ2F0ZSBhY2Nlc3MNCiAgICA+PiAgICAg IHRva2VuIGFjcXVpc2l0aW9uIHRvIGEgYmFja2VuZCBjb21wb25lbnQuICBJbiBzbyBkb2luZywg dGhlIGZyb250ZW5kDQogICAgPj4gICAgICBjYW4gYWNjZXNzIHJlc291cmNlIHNlcnZlcnMgZGly ZWN0bHkgd2l0aG91dCB0YWtpbmcgb24gdGhlIGJ1cmRlbiBvZg0KICAgID4+ICAgICAgY29tbXVu aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgcGVyc2lzdGluZyB0b2tlbnMs IGFuZA0KICAgID4+ICAgICAgcGVyZm9ybWluZyBvcGVyYXRpb25zIHRoYXQgYXJlIGZyYXVnaHQg d2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW4NCiAgICA+PiAgICAgIGV4ZWN1dGVkIGluIGEg dXNlciBhZ2VudCwgYnV0IGFyZSBzYWZlIGFuZCB3ZWxsIHByb3ZlbiB3aGVuIGV4ZWN1dGVkDQog ICAgPj4gICAgICBieSBhIGNvbmZpZGVudGlhbCBjbGllbnQgcnVubmluZyBvbiBhIGJhY2tlbmQu DQogICAgPj4gDQogICAgPj4gDQogICAgPj4gDQogICAgPj4gDQogICAgPj4gICBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uDQogICAgPj4gICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgID4+IA0KICAgID4+ICAgVGhlIElF VEYgU2VjcmV0YXJpYXQNCiAgICA+PiANCiAgICA+PiANCiAgICA+PiANCiAgICA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+IE9BdXRoIG1h aWxpbmcgbGlzdA0KICAgID4+IE9BdXRoQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93d3cuZ29v Z2xlLmNvbS91cmw/cT1odHRwczovL3d3dy5nb29nbGUuY29tL3VybD9xJTNEaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCUyNnNvdXJjZSUzRGdtYWlsLWltYXAlMjZ1 c3QlM0QxNjEzNzY3NTkxMDAwMDAwJTI2dXNnJTNEQU92VmF3MUJmdTlmSjJGal9CWkozSDl5dzdv ZCZzb3VyY2U9Z21haWwtaW1hcCZ1c3Q9MTYxMzkzNTE2NTAwMDAwMCZ1c2c9QU92VmF3M2E3M2J1 QnRQT0JvRFEzU01IX1hKVw0KICAgID4gDQogICAgPiANCiAgICANCg== From nobody Sun Feb 14 12:59:45 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06F3A0AF3 for ; Sun, 14 Feb 2021 12:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8F3m3ZOLX8l for ; Sun, 14 Feb 2021 12:59:39 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DD53A0AE5 for ; Sun, 14 Feb 2021 12:59:39 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id e7so3937279ile.7 for ; Sun, 14 Feb 2021 12:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0m5h+OPqhRDOxLUXUQ/kEZevNnpKGTEbd0l0Yqwqbrs=; b=AnL2hIDAfoIiQuW4GeWO7QMdmvVnuvvYYRpr++hVO7F3lXQbsG98Kjz3g+eDcJqJlH EBV/x0s0J1cF3UPFxhLpkKNukgBJD0tlEZwdstGHsTwjlxhYEgTpR/OGoM425rNJewUq qVH/73yMsRaJWR7HDnb6N4phXSlLBv7MhvX7J9DU9sU6jjB9pVvzjBc+/V6mS6eDxvSi NiXInn/M6ZDBM+xsVoSptGO/8FfvSieDGFLuh8EBi1NjrgcNJbXjT4e0FCn3P7fnxpVf se8oHfD4EJzBFjcatzwy4xRpn95HDzmiQFq/edCqWKsnk8UHnOqk7DzlmsIKGt+H7kfB E3FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0m5h+OPqhRDOxLUXUQ/kEZevNnpKGTEbd0l0Yqwqbrs=; b=S+zo7a4OvSW8xPN8gjzxvjq81OhCc4yEoABpO15PntwviXORiDdDYIkrJMxQxMCFYK gxTCO+aun3V++AcanVpjV/3cDP8O2UpnM/7lTujUcQnnSpuoiCUH7SEd057iBWmaU7HD 1qzin/Sjtp4+lCbfCEK5i+e2rnwI5pLvxh/pZv8ww0CPkKxMdBki7dcS2CRecmfhtgih 6l8F2va26JVsRCD77FaFpMrte2k68/70kaKmn1LnjWQ3eNHEA7Qs8BNvqJHMv+B2EKE4 eW6llUBk34zmX2gtOlzaCYgynUjG9v0swYcAdz2HjpRQwPIjriZi5dP7L9Y7yP13j1HN 5jvQ== X-Gm-Message-State: AOAM533PGNNIMgte1zhC0VQPzr9swvw7/qp95G/OVZgK31nM/2AlXiDP weA+R8uudedHZLGRvz6XF5lm0zTGI/wjfG4C4sg3BvmM7Asqx5nUiw== X-Google-Smtp-Source: ABdhPJzio1HTHbBsENx7iDGuy2KJnq/tnvzpcuVPqAjLley8clX4Eq2O8QQqaOIC4K2Y/Bqd+X4JAgxXRCtesf0ZoU0= X-Received: by 2002:a05:6e02:1d0e:: with SMTP id i14mr9771371ila.69.1613336378113; Sun, 14 Feb 2021 12:59:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 14 Feb 2021 21:59:27 +0100 Message-ID: To: Vittorio Bertocci Cc: Neil Madden , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b8991c05bb522592" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 20:59:43 -0000 --000000000000b8991c05bb522592 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > To restate, the TMI-BFF proposal is not trying to fix any of that... it= =E2=80=99s > definitely not a top level driver. Great, then we are back to: what is the top level driver. Because, while I appreciate the circumstances around ITP2.1~ as I fully understand how identity providers like Auth0 are using iframes and thirdparty cookies, this problem vanishes with the use of first-party domains. So let's skip the digression and assume we aren't solving ITP future related issues. The real problem I have with the draft is that it essentially suggests that every app needs to run a BFF to do user token generation because an AS is no longer afforded the capability for some reason. If we pull in expecting to solve ITP related issues then I think that justification is in play and we can work together to come up with a solution, rather than starting with the current deleterious prevalent pattern on the internet (which honestly is the most ridiculous paradigm I have seen). If we don't assume ITP is an issue, then I fail to see the core problem that existing AS have (as you pointed out code+PKCE already works) without the front channel or back channel needing really to make any additional changes. I assume there is a flaw in my reasoning somewhere, so please help me find it. - Warren Warren Parad Founder, CTO On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci wrote: > Let me rewind a bit here. This was never presented as driving use case. > > > > - Neil suggested that the backend could simply give short lived JTWs > for the frontent to call API. > - I clarified that this would not be viable in the general case and > provided an example scenario where backend issued short lived tokens w= ould > not have worked > - You commented that the frontend can obtain AS tokens from JS and > mentioned silent authentication. I clarified (or tried to) that this > offshoot of the discussion wasn=E2=80=99t to say that there is no viab= le way of > doing the scenario already, and by the way using an iFrame to do silen= t > authentication is now problematic. At this point we are no longer > discussing TMI-BFF, but current affairs in the authentication world. T= he > fact that we are proposing TMI-BFF and the fact that silent authentica= tion > is less and less viable are independent facts, the former isn=E2=80=99= t meant to be > a solution for the latter (it=E2=80=99s already addressed by using RTs= in coke+PKCE) > > > > That clarified. Not only we expect ITP to affect silent authentication, i= t > has been affected for the past year and that has been one of the primary > business drivers for the rapid adoption of code+PKCE+RTs in the user agen= t, > as customers with pure SPAs found themselves unable to renew tokens witho= ut > prompting as their access to cookies in flows driven by iframes became le= ss > and less reliable. > > When ITP was introduced we put many companies together to try to get Appl= e > to change it (you can find the doc in > https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7= sKsaiU/edit#heading=3Dh.p3nvp6xmxvzf) > but they didn=E2=80=99t bulge and ultimately the introduction of RTs in u= ser agent > code (albeit with extra restrictions, the one I mentioned not everyone is > following) made the problem manageable. We have an initiative cross worki= ng > groups (IETF, OIDC etc)for working with browser vendors to try containing > similar regressions in the future. For a summary of similar problems see > https://identiverse.gallery.video/detail/video/6184443037001/browser-feat= ures-vs-identity-protocols. > > > > > To restate, the TMI-BFF proposal is not trying to fix any of that, nor pe= r > the above some of it need fixing. The only indirect connection might be > that less stuff happening in the user agent means less opportunities for > similar changes to impact the flows, but it=E2=80=99s definitely not a to= p level > driver. > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 11:41 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > That only applies to third party cookies, it shouldn't affect third-party > iframes as far as I'm aware. So unless we expect those to break, we > probably shouldn't include that as a driving use case. Is there another > measure that would be relevant here? > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > ITP, for example > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 04:54 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measur= es > make it problematic. > > Which new browser measures? > > > *Error! Filename not specified.* > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > > - For UI related functionality, i.e. document selection, user profile > display/changes, contact updates, etc... You should be able to execute= the > client side *silent authentication* using the provided session token > from the Azure AD AS, without needing to make any RO api calls nor use= r > redirects. > > Can you expand on what silent authentication and session token stands for > here? If you are referring to the iframe scenario, the new browser measur= es > make it problematic. In code+PKCE you can use a refresh token, but see th= e > other reply for how this proposal is an alternative to that in some > situations. This answer was specifically on why having backend-issued > tokens didn=E2=80=99t apply to this scenario. > > > > > > *From: *Warren Parad > *Date: *Sunday, February 14, 2021 at 03:48 > *To: *Vittorio Bertocci > *Cc: *Neil Madden , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > For UI related functionality, i.e. document selection, user profile > display/changes, contact updates, etc... You should be able to execute th= e > client side *silent authentication* using the provided session token from > the Azure AD AS, without needing to make any RO api calls nor user > redirects. For RO responsibilities, you can present the user with a butto= n > "Grant RO access to Azure resources" button and the user will go through = a > permission scope elevation flow, again no reason to need a BFF here. > > > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > It may make sense for the app to have an error message, or even better > might be a 302 *Location header* depending on what you are doing. There > is nothing here that is OAuth specific however (nor common), and then we > should challenge the need to directly provide an RFC recommendation for > handling this. > > > > *Error! Filename not specified.* > > *Warren Parad* > > Founder, CTO > > Secure your user data and complete your authorization architecture. > Implement Authress . > > > > > > On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > Hi Neil, > > Thanks for the prompt comments! > > - Re: GET vs POST, > > personally I=E2=80=99d be fine with restricting to POST. > > > > - Re: RO-AS, interaction- > > perhaps it is not very clear from the text at the moment (first draft), > but that is assumed that the RO went thru whatever interactive steps are > necessary to establish a session (eg sign in, assuming the AS is say an > OIDC provider) and obtain beforehand the access token and refresh tokens > that will be needed during the app activities taking place after that. I= n > concrete terms, imagine that the backend performs an authorization code > grant requesting an IDtoken, access token and refresh token BEFORE the > activities described in TMI-BFF take place. > > The current language trying to express that is in 1.2: > > As a prerequisite for the flow described below, the backend MUST have > established a secure session with the user agent, so that all requests fr= om > that user agent toward the backend occur over HTTPS and carry a valid > session artifact (such as a cookie) that the backend can validate. This > document does not mandate any specific mechanism to establish and maintai= n > that session. > > And > > cached, it requests to the authorization server a new access token with > the required characteristics, using any artifacts previousy obtained (eg > refresh token) and grants that will allow the authorization server to iss= ue > the requested token without requiring user interaction. > > > > - If the backend is already implicitly trusted then couldn=E2=80=99t = you skip > OAuth and just get the backend to issue short-lived JWTs to the fronte= nd > that it can use for API access? > > For the trusted part, see above. For the short lived JWTs, that=E2=80=99s= not > really an option. The most generic scenario addressed here is for APIs th= at > accept tokens issued by the AS; the backend can request them as a client, > but it cannot mint them. Imagine we=E2=80=99re talking about a SPA applic= ation that > signs in users using Azure AD, and needs to call Office and Azure APIs. T= he > SPA backend cannot issue tokens for those APIs, it can only request them = to > the Azure AD AS. > > > > - If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoi= nt > URI that the SPA then navigates the user to. (Eg the backend can do a = PAR > request first and return a URI that references that so that authorizat= ion > details aren=E2=80=99t passed through the frontend). > > We did consider adding something to that effect, an error message that ca= n > direct the frontend to perform the interactive portion necessary for this > topology to work. It would be something similar to the IDP initiated logi= n > in OIDC, where the client offers an endpoint that is guaranteed to initia= te > a sign in flow (hence inject all the necessary nonces etc). We didn=E2=80= =99t add > it upfront and left it as exercise for the reader mostly because it=E2=80= =99s not > easy to model properly and before opening that work front we wanted to se= e > how the idea was received. > > > > *From: *OAuth on behalf of Neil Madden < > neil.madden@forgerock.com> > *Date: *Sunday, February 14, 2021 at 00:17 > *To: *Vittorio Bertocci > *Cc: *"oauth@ietf.org" > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > I have a lot of security concerns about this draft. > > > > The draft alludes to security issues associated with handling access > tokens in the frontend but never really spells them out. From the Securit= y > Considerations it seems that the primary concern is with theft of access > tokens from local storage. To do this you=E2=80=99d need an XSS attack. B= ut in that > case, wouldn=E2=80=99t the attacker simply use the XSS to make a call to = the > bff-token endpoint instead? > > > > The combination of the bff-token endpoint recommending the use of GET > requests together with the hint to use cookie-based authentication is > likely going to punch a hole in most CSRF defenses, which assume that GET= s > are safe. The only thing preventing this being exploitable is Cross-Origi= n > Read Blocking ( > https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md) > due to the JSON content-type. That makes me really nervous. We should at > least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel > more comfortable if this was a POST request only. > > > > As Stoycho Sleptsov mentioned in the other email, the lack of > front-channel communication between the AS and the RO seems odd. If the > backend is already implicitly trusted then couldn=E2=80=99t you skip OAut= h and just > get the backend to issue short-lived JWTs to the frontend that it can use > for API access? > > > > If you want to allow auth code flow etc then perhaps the bff-token > endpoint can return a standard error code with an authorization endpoint > URI that the SPA then navigates the user to. (Eg the backend can do a PAR > request first and return a URI that references that so that authorization > details aren=E2=80=99t passed through the frontend). > > > > =E2=80=94 Neil > > > > > > On 12 Feb 2021, at 20:46, Vittorio Bertocci 40auth0.com@dmarc.ietf.org> wrote: > > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how th= e > user agent frontend of a web app can delegate token acquisition and > persistence to its backend, and request such tokens when needed for direc= t > access of protected resources from the frontend code. > > The pattern is already in use, in proprietary form, by various modern > development stacks, such as Next.JS. Variants of the pattern, often > discussed under the catch-all term BFF (backend for frontend), have been > often mentioned in this workgroup=E2=80=99s activity, but always left all > implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing adoption= . > By delegating access token acquisition to the backend, we avoid many of t= he > often brittle moving parts (and implied attack surface) required to acqui= re > access tokens from a user agent. The topology also relieves the frontend > from the need of persisting tokens in local storage, a well known sore > point of using OAuth directly in JavaScript, by relying on its backend > storage and session to preserve tokens. > > Although the specification is very simple, providing explicit guidance on > the scenario offers many advantages. > - It makes it possible to create interoperable SDKs, where frontend dev > stacks (any JS flavor) can be mixed and matched with compliant backend > stacks (middlewares in node, java, ASP.NET, PHP etc) > - It allows us to provide guidance on how to properly tackle the scenario > and warn implementers against security risks (scope escalations, using > IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern as > part of the browser apps security guidance, and position the scenario whe= re > frontend only calls API on its own backed (hence doesn=E2=80=99t need acc= ess > tokens) simply as a special case of this more general pattern > - This approach makes mocking and testing apps very easy, possibly > preventing developers from weakening the security of their system (eg > turning on ROPG options) or turning to risky practices like scraping > > Needless to say, this specification doesn=E2=80=99t entirely eliminate th= e risks > inherent to direct use of access tokens from a browser. But reality is th= at > the pattern is in widespread use, and the circumstances leading to that (= eg > developers on a particular project only work with frontend stacks; > components like reverse proxies might not always be viable; etc) aren=E2= =80=99t > going away any time soon. By providing simple guidance on this pattern, w= e > can simplify the life of many developers while enshrining basic security > hygiene in scenarios that would have otherwise be left to their own devic= e. > > Looking forward for your feedback! > > B&V > > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: > > > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to the > IETF repository. > > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For > Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt > Status: > https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ > Html: > https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html > Htmlized: > https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 > > > Abstract: > This document describes how a JavaScript frontend can delegate acce= ss > token acquisition to a backend component. In so doing, the fronten= d > can access resource servers directly without taking on the burden o= f > communicating with the authorization server, persisting tokens, and > performing operations that are fraught with security challenges whe= n > executed in a user agent, but are safe and well proven when execute= d > by a confidential client running on a backend. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ForgeRock values your Privacy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000000000000b8991c05bb522592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To = restate, the TMI-BFF proposal is not trying to fix any of that... it=E2=80= =99s definitely not a top level driver.
Great, then we are= back to: what is the top level driver. Because, while I appreciate the cir= cumstances around ITP2.1~ as I fully understand how identity providers like= Auth0 are using iframes and thirdparty=C2=A0cookies, this problem vanishes= with the use of first-party domains. So let's skip the digression and = assume we aren't solving ITP future related issues.

The real problem I have with the draft is that it essentially suggest= s that every app needs to run a BFF to do user token generation because an = AS is no longer afforded the capability for some reason. If we pull in expe= cting to solve ITP related issues then I think=C2=A0that justification is i= n play and we can work together to come up with a solution, rather than sta= rting with the current deleterious=C2=A0prevalent=C2=A0pattern on the inter= net (which honestly is the most ridiculous paradigm I have seen). If we don= 't assume ITP is an issue, then I fail to see the core problem that exi= sting AS have (as you pointed out code+PKCE already works) without the fron= t channel or back channel needing really to make any additional changes.

I assume there is a flaw in my reasoning somewhere, = so please help me find it.

- Warren

Warren Parad

Founder, C= TO


<= br>
On Sun,= Feb 14, 2021 at 9:20 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> w= rote:

Let me rewind a bit here. This was never presented a= s driving use case.

=C2=A0

  • Neil suggested that the backend could simply give short lived JTW= s for the frontent to call API.
  • I clarified tha= t this would not be viable in the general case and provided an example scen= ario where backend issued short lived tokens would not have worked
  • You commented that the frontend can obtain AS tokens f= rom JS and mentioned silent authentication. I clarified (or tried to) that = this offshoot of the discussion wasn=E2=80=99t to say that there is no viable way of doing the scenario already, and by the way using= an iFrame to do silent authentication is now problematic. At this point we= are no longer discussing TMI-BFF, but current affairs in the authenticatio= n world. The fact that we are proposing TMI-BFF and the fact that silent authentication is less and less viable ar= e independent facts, the former isn=E2=80=99t meant to be a solution for th= e latter (it=E2=80=99s already addressed by using RTs in coke+PKCE)<= u>

=C2=A0

That clarified. Not only we expect ITP to affect sil= ent authentication, it has been affected for the past year and that has bee= n one of the primary business drivers for the rapid adoption of code+PKCE+R= Ts in the user agent, as customers with pure SPAs found themselves unable to renew tokens without prompting a= s their access to cookies in flows driven by iframes became less and less r= eliable.

When ITP was introduced we put many companies togeth= er to try to get Apple to change it (you can find the doc in https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7sK= saiU/edit#heading=3Dh.p3nvp6xmxvzf) but they didn=E2=80=99t bulge and u= ltimately the introduction of RTs in user agent code (albeit with extra res= trictions, the one I mentioned not everyone is following) made the problem manageable. We have an initiative cross wor= king groups (IETF, OIDC etc)for working with browser vendors to try contain= ing similar regressions in the future. For a summary of similar problems se= e https://identiverse.gallery.video/detail/video/6184443037001/browser-featur= es-vs-identity-protocols. =C2=A0

=C2=A0

To restate, the TMI-BFF proposal is not trying to fi= x any of that, nor per the above some of it need fixing. The only indirect = connection might be that less stuff happening in the user agent means less = opportunities for similar changes to impact the flows, but it=E2=80=99s definitely not a top level driver.

=C2=A0

From: = Warren Parad <wpar= ad=3D40rhos= ys.ch@dmarc.ietf.org>
Date: Sunday, February 14, 2021 at 11:41
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

That only applies to third party cookies, it shouldn= 't affect third-party iframes as far as I'm aware. So unless we exp= ect those to break, we probably shouldn't include that=C2=A0as a drivin= g use case. Is there another measure that would be relevant here?


=3D"Image

Warren Parad

Founder, CTO=

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci &l= t;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

ITP, for example

=C2=A0

From: Warren Parad <wpar= ad=3D40rhos= ys.ch@dmarc.ietf.org>
Date: Sunday, February 14, 2021 at 04:54
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Can you expand on what silent authentication and ses= sion token stands for here? If you are referring to the iframe scenario, th= e new browser measures make it problematic.

Which new browser measures?


Error! Filenam= e not specified.

Warren Parad

Founder, CTO

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci &l= t;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

  • For UI related functionality, i.e. document selection, user profile display= /changes, contact updates, etc... You should be able to execute the client = side silent authentication=C2=A0using the provided session token from the= Azure AD AS, without needing to make any RO api calls nor user redirects.= =C2=A0

Can you expand on what silent authentication and ses= sion token stands for here? If you are referring to the iframe scenario, th= e new browser measures make it problematic. In code+PKCE you can use a refresh token, but see the other reply for how this proposal= is an alternative to that in some situations. This answer was specifically= on why having backend-issued tokens didn=E2=80=99t apply to this scenario.=

=C2=A0

=C2=A0

From: Warren Parad <wpar= ad=3D40rhos= ys.ch@dmarc.ietf.org>
Date: Sunday, February 14, 2021 at 03:48
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine= we=E2=80=99re talking about a SPA application that signs in users using Az= ure AD, and needs to call Office and Azure APIs. The SPA backend cannot iss= ue tokens for those APIs, it can only request them to the Azure AD AS.

=C2=A0

For UI related functionality, i.e. document selectio= n, user profile display/changes, contact updates, etc... You should be able= to execute the client side silent authentication=C2=A0using the provided session token from the= Azure AD AS, without needing to make any RO api calls nor user redirects.= =C2=A0For RO responsibilities, you can present the user with a button "= ;Grant RO access to Azure resources" button and the user will go through=C2=A0a permission scope elevation flow, again no = reason to need a BFF here.

=C2=A0

We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client off= ers an endpoint that is guaranteed to initiate a sign in flow (hence inject= all the necessary nonces etc). We didn=E2=80=99t add it upfront and left i= t as exercise for the reader mostly because it=E2=80=99s not easy to model properly and before opening that work front= we wanted to see how the idea was received.=C2=A0=C2=A0

It may make sense for the app to have an error messa= ge, or even better might be a 302 Location header=C2=A0depending on what you are doing. There is nothi= ng here that is OAuth specific however (nor common), and then we should cha= llenge the need to directly provide an RFC recommendation for handling this= .

=C2=A0

Error! Filenam= e not specified.

Warren Parad

Founder, CTO

Secure yo= ur user data and complete your authorization architecture. Implement=C2=A0<= /span>Authress.

=C2=A0

=C2=A0

On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci &= lt;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

Hi Neil,

Thanks for the prompt comments!

  • Re: GET vs POST,

personally I=E2=80=99d be fine with restricting to POST.

=C2=A0

  • Re: RO-AS, interaction-

perhaps it is not very clear from the text at the mo= ment (first draft), but that is assumed that the RO went thru whatever inte= ractive steps are necessary to establish a session (eg sign in, assuming the AS is say an OIDC provider) and obtain beforehan= d the access token and refresh tokens that will be needed during the app ac= tivities taking place after =C2=A0that. In concrete terms, imagine that the= backend performs an authorization code grant requesting an IDtoken, access token and refresh token BEFORE the act= ivities described in TMI-BFF take place.

The current language trying to express that is in 1.= 2:

As a prerequ= isite for the flow described below, the backend MUST have established a secure session with the user agent, so that all requests from that user = agent toward the backend occur over HTTPS and carry a valid session artifac= t (such as a cookie) that the backend can validate. This document does not = mandate any specific mechanism to establish and maintain that session.

And

cached, it r= equests to the authorization server a new access token with the required characteristics, using any artifacts previousy obtained (eg refresh token)= and grants that will allow the authorization server to issue the requested= token without requiring user interaction.

=C2=A0

  • =C2=A0If the backen= d is already implicitly trusted then couldn=E2=80=99t you skip OAuth and ju= st get the backend to issue short-lived JWTs to the frontend that it can use = for API access?

For the trusted part, see above. For the short lived= JWTs, that=E2=80=99s not really an option. The most generic scenario addre= ssed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine= we=E2=80=99re talking about a SPA application that signs in users using Az= ure AD, and needs to call Office and Azure APIs. The SPA backend cannot iss= ue tokens for those APIs, it can only request them to the Azure AD AS.

=C2=A0

  • If you want to allow auth code flow etc then perhaps the bff-token endpoint= can return a standard error code with an authorization endpoint URI that t= he SPA then navigates the user to. (Eg the backend can do a PAR request fir= st and return a URI that references that so that authorization details aren=E2=80=99t passed through the front= end).=C2=A0

We did consider adding something to that effect, an = error message that can direct the frontend to perform the interactive porti= on necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client off= ers an endpoint that is guaranteed to initiate a sign in flow (hence inject= all the necessary nonces etc). We didn=E2=80=99t add it upfront and left i= t as exercise for the reader mostly because it=E2=80=99s not easy to model properly and before opening that work front= we wanted to see how the idea was received. =C2=A0

=C2=A0

From: OAuth <oauth-bounces@ietf.org= > on behalf of Neil Madden <neil.madden@forgerock.com>
Date: Sunday, February 14, 2021 at 00:17
To: Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>= ;
Cc: "oauth@= ietf.org" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

I have a lot of security concerns about this draft.= =C2=A0

=C2=A0

The draft alludes to security issues associated with= handling access tokens in the frontend but never really spells them out. F= rom the Security Considerations it seems that the primary concern is with theft of access tokens from local storage. To do t= his you=E2=80=99d need an XSS attack. But in that case, wouldn=E2=80=99t th= e attacker simply use the XSS to make a call to the bff-token endpoint inst= ead?=C2=A0

=C2=A0

The combination of the bff-token endpoint recommendi= ng the use of GET requests together with the hint to use cookie-based authe= ntication is likely going to punch a hole in most CSRF defenses, which assume that GETs are safe. The only thing preventing = this being exploitable is Cross-Origin Read Blocking (https://chromium.googlesourc= e.com/chromium/src/+/master/services/network/cross_origin_read_blocking_exp= lainer.md) due to the JSON content-type. That makes me really nervous. We should at l= east mandate X-Content-Type-Options: nosniff on that response. I=E2=80=99d = feel more comfortable if this was a POST request only.=C2=A0<= /p>

=C2=A0

As Stoycho Sleptsov mentioned in the other email, th= e lack of front-channel communication between the AS and the RO seems odd. = If the backend is already implicitly trusted then couldn=E2=80=99t you skip OAuth and just get the backend to issue short-li= ved JWTs to the frontend that it can use for API access?

=C2=A0

If you want to allow auth code flow etc then perhaps= the bff-token endpoint can return a standard error code with an authorizat= ion endpoint URI that the SPA then navigates the user to. (Eg the backend can do a PAR request first and return a URI that refer= ences that so that authorization details aren=E2=80=99t passed through the = frontend).=C2=A0

=C2=A0

=E2=80=94 Neil

=C2=A0

=C2=A0

On 12 Feb 2021, at 20:4= 6, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=

=EF=BB=BFDear all,
Brian and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and persist= ence to its backend, and request such tokens when needed for direct access = of protected resources from the frontend code.

The pattern is already in use, in proprietary form, by various modern devel= opment stacks, such as Next.JS. Variants of the pattern, often discussed un= der the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=E2=80=99s activity, but always left all implementation details to the reader.
We believe the pattern has merit, as corroborated by its growing adoption. = By delegating access token acquisition to the backend, we avoid many of the= often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend from the need of persisting tokens= in local storage, a well known sore point of using OAuth directly in JavaS= cript, by relying on its backend storage and session to preserve tokens.
Although the specification is very simple, providing explicit guidance on t= he scenario offers many advantages. =C2=A0
- It makes it possible to create interoperable SDKs, where frontend dev sta= cks (any JS flavor) can be mixed and matched with compliant backend stacks = (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide guidance on how to properly tackle the scenario a= nd warn implementers against security risks (scope escalations, using IDtok= ens instead of access tokens, etc)
- It allows us to discuss (and when appropriate, promote) this pattern as p= art of the browser apps security guidance, and position the scenario where = frontend only calls API on its own backed (hence doesn=E2=80=99t need acces= s tokens) simply as a special case of this more general pattern
- This approach makes mocking and testing apps very easy, possibly preventi= ng developers from weakening the security of their system (eg turning on RO= PG options) =C2=A0or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely eliminate the = risks inherent to direct use of access tokens from a browser. But reality i= s that the pattern is in widespread use, and the circumstances leading to t= hat (eg developers on a particular project only work with frontend stacks; components like reverse proxies might not = always be viable; etc) aren=E2=80=99t going away any time soon. By providin= g simple guidance on this pattern, we can simplify the life of many develop= ers while enshrining basic security hygiene in scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!

B&V =C2=A0

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org= > wrote:


=C2=A0=C2=A0=C2=A0A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.tx= t
=C2=A0=C2=A0=C2=A0has been successfully submitted by Vittorio Bertocci and = posted to the
=C2=A0=C2=A0=C2=A0IETF repository.

=C2=A0=C2=A0=C2=A0Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bertocci-oauth2-tm= i-bff
=C2=A0=C2=A0=C2=A0Revision: =C2=A0 =C2=A000
=C2=A0=C2=A0=C2=A0Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Token Mediating and ses= sion Information Backend For Frontend
=C2=A0=C2=A0=C2=A0Document date: =C2=A0 =C2=A02021-02-12
=C2=A0=C2=A0=C2=A0Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission =C2=A0=C2=A0=C2=A0Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A016
=C2=A0=C2=A0=C2=A0URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://www.ietf.org/archive/id/draf= t-bertocci-oauth2-tmi-bff-00.txt
=C2=A0=C2=A0=C2=A0Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/" = target=3D"_blank">https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tm= i-bff/
=C2=A0=C2=A0=C2=A0Html: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0https://www.ietf.org/archive/id/draft-ber= tocci-oauth2-tmi-bff-00.html
=C2=A0=C2=A0=C2=A0Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


=C2=A0=C2=A0=C2=A0Abstract:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0This document describes how a JavaScrip= t frontend can delegate access
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0token acquisition to a backend componen= t.=C2=A0 In so doing, the frontend
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0can access resource servers directly wi= thout taking on the burden of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0communicating with the authorization se= rver, persisting tokens, and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0performing operations that are fraught = with security challenges when
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0executed in a user agent, but are safe = and well proven when executed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0by a confidential client running on a b= ackend.




=C2=A0=C2=A0=C2=A0Please note that it may take a couple of minutes from the= time of submission
=C2=A0=C2=A0=C2=A0until the htmlized version and diff are available at tools.ietf.org.

=C2=A0=C2=A0=C2=A0The IETF Secretariat



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


ForgeR= ock values your Privac= y

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

--000000000000b8991c05bb522592-- From nobody Sun Feb 14 13:02:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702F13A0AFB for ; Sun, 14 Feb 2021 13:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aisB-XYbKLjW for ; Sun, 14 Feb 2021 13:02:45 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45DB3A0AE6 for ; Sun, 14 Feb 2021 13:02:01 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id w18so2987729pfu.9 for ; Sun, 14 Feb 2021 13:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=ReDxUV1ILKr/VpW5/HP9YGmFu7S/VfyRHBsrzjqnkBY=; b=FwWp3nvbMtEMUT/8K8p4Iu0UVi22rm0c2oo7ZCwAHOIfpp5XL8BlTCbPGMp+vjTAfZ Wp7pmOEVMcfo+SwStbgsZE/nwmpIFGOZrSk37qJLk6Jd7kQr6nidsRwgYbWA/CsbFUCr ZvAaQhH43cMcNOlH38mYM5kQJxun5y0DCsJmlO6/zLKia2tyLY0oDUE/w9LBoW1IXuj4 SZloV9mF26M6rU1ncIZMhFL01iN9NgClrpDo8lbShS/xMVYzbNX9HLBLPYMMes1/kH1l VP9SlK5fgKBabeRBRpL751KA6PU/E2ItuBkD+BOgO/7sN9SLekXuqSwdgSeiL1pK78jr IB2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=ReDxUV1ILKr/VpW5/HP9YGmFu7S/VfyRHBsrzjqnkBY=; b=U2KFysL+J1X0LBrWqMqG7VM9rPPj61PX6ZoBzvUFQ/1i3M2tNDrwmbEDMCEm4SI/4u YV9EBejp370i1v6kRFVeMUokgOiNMY1AX+6efFNHI1iwXlpkauX6it7bWNbxMQGloKbm WLgtXGZBKFkdWJ5KAu8QR5Xe64i0gxubdpq4V7znyEW7K1oVrLilpWsSVl61V0CFLaen BCHcxt9mQ3Bi6snTCn1HkoqdQt7YNC/8wdU/MK59vlPQKO1KzIc7q6p436Z14Gf5Rujy BDGpC8ekveiiXMsI/+oiQqkJyiIJYAlRlD79NEube8o1fFF7c52443zRuHXqcaiDgIAg bfWA== X-Gm-Message-State: AOAM530yfDomf2Tk3z85JeRRsyS9vrbeUkurq3KCn2nPFpSjzTov2k/E TzAh360tJAWpZbwHkgrEnogdiGzaqC0ykA== X-Google-Smtp-Source: ABdhPJxK0v+cP83pht0xsczRvHB0KnjDAEHmBYTcDMnvOhtDXOt6HIIyfJdE5IlZefWBAzj7vM1gSA== X-Received: by 2002:a63:d58:: with SMTP id 24mr1517563pgn.91.1613336521175; Sun, 14 Feb 2021 13:02:01 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id x20sm15989379pfn.14.2021.02.14.13.02.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 13:02:00 -0800 (PST) From: Vittorio Bertocci To: Warren Parad CC: Stoycho Sleptsov , Neil Madden , oauth Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAAaNoCAACuILIAAFosAgAALMgCAAAZ4gIAADE4AgAAfRYCAAATwgIAAH9svgAAFFYCAABIfOA== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 21:01:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB405282E82D5E7C0C68BFD51BAE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 21:02:48 -0000 --_000_CO6PR18MB405282E82D5E7C0C68BFD51BAE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgIFdoYXQgaXMgdGhlIGZyb250ZW5kIGRldmVsb3BlciBkb2luZyBhbnkgZGlmZmVyZW50 IGluIHRoZSBuZXcgaHlwb3RoZXRpY2FsIHdvcmxkIHRoYW4gdGhleSB3b3VsZCBiZSwgcmlnaHQg bm93IHRoZXkgYXJlIGluY2x1ZGluZyBhbiBTREsgYW5kIHdyaXRpbmcgb25lIGxpbmUgb2YgY29k ZSBvbiBsb2dpbiByZWRpcmVjdC9zaWxlbnQgYXV0aCBhbmQgb25lIGxpbmUgb2YgY29kZSBmb3Ig UEtDRStjb2RlIHZhbGlkYXRpb24uIElmIGEgc2VydmljZSBjbGllbnQgbmVlZHMgdG8gYmUgYXV0 aG9yaXplZCB0aGVyZSB3b3VsZCBiZSBhIHRoaXJkIGxpbmUgb2YgY29kZSB0byBjYWxsIHRoZSBi YWNrZW5kLg0KDQpBcyBtZW50aW9uZWQsIHRoZSBjbGllbnQgY29kZSBtaWdodCBub3QgbG9vayB2 ZXJ5IGRpZmZlcmVudC0gYWx0aG91Z2ggaW4gdGhlIFRNSS1CRkYgbW9kZWwgdGhlIEpTIGNvZGUg bWlnaHQgYmUgZXZlbiBtb3JlIHN1Y2NpbmN0IChnaXZlbiB0aGF0IHRoZSBzaWduIGluIHBhcnRz IGFyZSBoYW5kbGVkIGJ5IHRoZSBiYWNrZW5kLCB0aGV5IG1pZ2h0IHNpbXBseSBiZSBkZWNvcmF0 ZWQgcm91dGVzIG9uIHRoZSBtaWRkbGV3YXJlLSBubyBuZWVkIGZvciB0aGUgSlMgdG8gbWFrZSB0 aG9zZSBjYWxscyBkaXJlY3RseSwganVzdCB0byBoaXQgdGhlIHJvdXRlcykgYW5kIHRoZSBTREsg ZmFyIG1vcmUgbGlnaHR3ZWlnaHQuIFRoZSBkaWZmZXJlbmNlIG1pZ2h0IGJlIHRoYXQgaWYgeW91 ciBhdXRob3JpemF0aW9uIHNlcnZlciBkb2VzIG5vdCBzdXBwb3J0IHJlZnJlc2ggdG9rZW4gcm90 YXRpb24gb3Igc2VuZGVyIGNvbnN0cmFpbmluZyBSVHMsIHdpdGggY29kZStQS0NFIHlvdSBtaWdo dCBub3QgYmUgYWJsZSB0byBvYnRhaW4gdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBhcyBUTUktQkZG IGdpdmVuIHRoYXQgeW91IG1pZ2h0IG5vdCBoYXZlIGEgd2F5IG9mIHJlbmV3aW5nIHNob3J0IGxp dmVkIHRva2VucyB3aXRob3V0IGZ1bGwgcmVkaXJlY3RzIChzZWUgZGlzY3Vzc2lvbiBvbiBJVFAp LiBUaGF0IGlzIGEgdGVtcG9yYXJ5IHNpdHVhdGlvbiwgaG9wZWZ1bGx5IGV2ZW50dWFsbHkgYWxs IEFTIHZlbmRvcnMgd2lsbCBzdXBwb3J0IHJvdGF0aW9uIGFuZC9vciBzZW5kZXIgY29uc3RyYWlu dCwgYnV0IGl0IGlzIGFuIGV4YW1wbGUgb2YgaG93IHRoZSBwcm9wb3NhbCBkb2VzIGhhdmUgYWR2 YW50YWdlcy4NCg0KDQogICogICBUaGVzZSB0aHJlZSBsaW5lcyBzdGlsbCBuZWVkIHRvIGJlIHBy ZXNlbnQgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgeW91IHVzZSBhbiBBUy1wcm94eSBUTUktQkZG IG9yIHRoZSBBUyBkaXJlY3RseS4NClNlZSBhYm92ZS4gVGhhdOKAmXMgbm90IG5lY2Vzc2FyaWx5 IHRoZSBjYXNlLCBhbmQgd2hhdCB0aGUgY2xpZW50IGNvZGUgbG9va3MgbGlrZSBpc27igJl0IHdo YXQgVE1JLUJGRiBpcyB0cnlpbmcgdG8gYWRkcmVzcyBhbnl3YXkuDQoNCg0KICAqICAgRXhjZXB0 IG5vdyB3ZSBhcmUgZW5jb3VyYWdpbmcgZXZlcnkgYXBwIHRvIHdyaXRlIGEgQkZGIGFuZCBpbnRl Z3JhdGUgdGhlaXIgZnJvbnQgY2hhbm5lbCB3aXRoIGl0Lg0KVGhhdCBpcyBub3QgdGhlIGNhc2Uu IFRoZSBzY29wZSBvZiB0aGlzIHByb3Bvc2FsIHJlbWFpbnMgbGltaXRlZCB0byBhcHBzIHRoYXQg YWxyZWFkeSBoYXZlIGEgYmFja2VuZC4NCg0KDQogICogICBBZGRpdGlvbmFsbHksIHdlIGFyZW4n dCByZXF1aXJpbmcgbGVzcyBjYXBhYmlsaXRpZXMgZnJvbSB0aGUgc3BlYywgd2UgYXJlIGp1c3Qg YWxzbyByZXF1aXJpbmcgYWRkaXRpb25hbCBvbmVzIGZvciBhIEJGRi4gSWYgdGhlcmUgYXJlIGNh cGFiaWxpdGllcyB0aGlzIGxldHMgdXMgZHJvcCBmcm9tIE9BdXRoIGNvdWxkIHlvdSBleHBsYWlu IHdoaWNoIG9uZXMgdGhvc2UgYXJlLCBiZWNhdXNlIHNpbmNlIGFuIEFTIGNhbid0IGtub3cgd2hl dGhlciAiY3VzdG9tZXJzIiBhcmUgZ29pbmcgdG8gd2FudCB0byB1c2UgYSBCRkYgb3Igbm90LCBp dCB3aWxsIHN0aWxsIGhhdmUgdG8gaW1wbGVtZW50IGFsbCB0aGUgbmVjZXNzYXJ5IEFTIGZlYXR1 cmVzIHRoYXQgYWxyZWFkeSBleGlzdCAoYW5kIHRoZSBuZXcgb25lcyB0aGF0IGRvbid0KS4gSSBk b24ndCBzZWUgaG93IHRoaXMgYWZmb3JkcyBhbiBBUyBhbnkgYWRkaXRpb25hbCBmcmVlZG9tLg0K T25jZSBhZ2FpbiwgdGhpcyBwcm9wb3NhbCBpcyBub3QgbWVhbnQgdG8gbGlnaHRlbiB0aGUgQVMg YnVyZGVuLCBidXQgdG8gbWFrZSB0aGUgbGlmZSBvZiBkZXZlbG9wZXJzIGVhc2llci4gSSBhbHJl YWR5IG1lbnRpb25lZCB0aGUgcm90YXRpb24vc2VuZGVyIGNvbnN0cmFpbnQgY2FwYWJpbGl0aWVz IHRoYXQgY29kZStQS0NFIHJlcXVpcmUgZm9yIFJUcyB0byBiZSB1c2VkIGluIGEgdXNlciBhZ2Vu dCwgYW5kIHRoZSBmYWN0IHRoYXQgdmFyaW91cyBpbXBvcnRhbnQgQVMgb24gdGhlIG1hcmtldCB0 b2RheSBkbyBub3Qgb2ZmZXIgdGhhdCBjYXBhYmlsaXR5LiBUaGVyZSBtaWdodCBiZSBvdGhlcnM6 IGZvciBleGFtcGxlLCB1bnRpbCByZWNlbnRseSB2YXJpb3VzIGltcG9ydGFudCBBUyBkaWQgbm90 IHN1cHBvcnQgQ09SUyBvbiB0aGVpciBtZXRhZGF0YSBhbmQgdG9rZW4gZW5kcG9pbnRzLCBtYWtp bmcgdGhlIGNvZGUrUEtDRSBpbiB0aGUgdXNlciBhZ2VudCBpbXBvc3NpYmxlLiBNeSBob3BlIGFu ZCBhc3N1bXB0aW9uIGlzIHRoYXQgdGhvc2UgYXJlIGFsbCB0ZW1wb3Jhcnkgc2l0dWF0aW9ucywg YW5kIFRNSS1CRkYgZ29hbCBpcyBOT1QgdG8gZGlzcGVuc2UgQVMgZGV2ZWxvcGVycyBmcm9tIGlt cGxlbWVudGluZyB0aG9zZSBmZWF0dXJlcy4gIEJ1dCB0aG9zZSBhcmUgY29uY3JldGUgZXhhbXBs ZXMgb2YgY2FzZXMgaW4gd2hpY2ggVE9EQVkgYW4gYXBwIGRldmVsb3BlciAod2hvc2UgYXBwIGhh cyBhIGJhY2tlbmQpIHRvb2sgYSBkZXBlbmRlbmN5IG9uIG9uZSBBUyB3aXRob3V0IHRob3NlIGZl YXR1cmVzIG1pZ2h0IGJlIGFibGUgdG8gZG8gbW9yZSB0aGluZ3MgaW4gdGhlaXIgYXBwIHdoZW4g dXNpbmcgVE1JLUJGRiB0aGFuIHdpdGggSlMgY29kZSB0aGF0IHJlbGllcyBvbiB0aG9zZSBBUyBj YXBhYmlsaXRpZXMgdG8gZnVuY3Rpb24uDQoNCkZyb206IFdhcnJlbiBQYXJhZCA8d3BhcmFkQHJo b3N5cy5jaD4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMTE6NTcNClRvOiBW aXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPg0KQ2M6IFN0b3lj aG8gU2xlcHRzb3YgPHN0b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29tPiwgTmVpbCBNYWRkZW4gPG5l aWwubWFkZGVuQGZvcmdlcm9jay5jb20+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNlc3Npb24gSW5mb3JtYXRpb24g QmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpDQoNCmJ1dCBpdCBkb2VzIG1ha2UgdGhpbmdz IHNpbXBsZXIgZm9yIHRoZSBmcm9udGVuZCBkZXZlbG9wZXIgYW5kIHJlcXVpcmVzIGxlc3MgYWR2 YW5jZWQgY2FwYWJpbGl0aWVzIGluIHRoZSBBUy4NCkkgZ3Vlc3MgSSdtIHN0aWxsIGdldHRpbmcg bG9zdCBvbiB0aGlzIHBvaW50LCB3aGljaCBzZWVtcyBub3QgeWV0IGp1c3RpZmllZCBmb3IgbWUu IFdoYXQgaXMgdGhlIGZyb250ZW5kIGRldmVsb3BlciBkb2luZyBhbnkgZGlmZmVyZW50IGluIHRo ZSBuZXcgaHlwb3RoZXRpY2FsIHdvcmxkIHRoYW4gdGhleSB3b3VsZCBiZSwgcmlnaHQgbm93IHRo ZXkgYXJlIGluY2x1ZGluZyBhbiBTREsgYW5kIHdyaXRpbmcgb25lIGxpbmUgb2YgY29kZSBvbiBs b2dpbiByZWRpcmVjdC9zaWxlbnQgYXV0aCBhbmQgb25lIGxpbmUgb2YgY29kZSBmb3IgUEtDRStj b2RlIHZhbGlkYXRpb24uIElmIGEgc2VydmljZSBjbGllbnQgbmVlZHMgdG8gYmUgYXV0aG9yaXpl ZCB0aGVyZSB3b3VsZCBiZSBhIHRoaXJkIGxpbmUgb2YgY29kZSB0byBjYWxsIHRoZSBiYWNrZW5k LiBUaGVzZSB0aHJlZSBsaW5lcyBzdGlsbCBuZWVkIHRvIGJlIHByZXNlbnQgaXJyZXNwZWN0aXZl IG9mIHdoZXRoZXIgeW91IHVzZSBhbiBBUy1wcm94eSBUTUktQkZGIG9yIHRoZSBBUyBkaXJlY3Rs eS4gRXhjZXB0IG5vdyB3ZSBhcmUgZW5jb3VyYWdpbmcgZXZlcnkgYXBwIHRvIHdyaXRlIGEgQkZG IGFuZCBpbnRlZ3JhdGUgdGhlaXIgZnJvbnQgY2hhbm5lbCB3aXRoIGl0Lg0KDQpBZGRpdGlvbmFs bHksIHdlIGFyZW4ndCByZXF1aXJpbmcgbGVzcyBjYXBhYmlsaXRpZXMgZnJvbSB0aGUgc3BlYywg d2UgYXJlIGp1c3QgYWxzbyByZXF1aXJpbmcgYWRkaXRpb25hbCBvbmVzIGZvciBhIEJGRi4gSWYg dGhlcmUgYXJlIGNhcGFiaWxpdGllcyB0aGlzIGxldHMgdXMgZHJvcCBmcm9tIE9BdXRoIGNvdWxk IHlvdSBleHBsYWluIHdoaWNoIG9uZXMgdGhvc2UgYXJlLCBiZWNhdXNlIHNpbmNlIGFuIEFTIGNh bid0IGtub3cgd2hldGhlciAiY3VzdG9tZXJzIiBhcmUgZ29pbmcgdG8gd2FudCB0byB1c2UgYSBC RkYgb3Igbm90LCBpdCB3aWxsIHN0aWxsIGhhdmUgdG8gaW1wbGVtZW50IGFsbCB0aGUgbmVjZXNz YXJ5IEFTIGZlYXR1cmVzIHRoYXQgYWxyZWFkeSBleGlzdCAoYW5kIHRoZSBuZXcgb25lcyB0aGF0 IGRvbid0KS4gSSBkb24ndCBzZWUgaG93IHRoaXMgYWZmb3JkcyBhbiBBUyBhbnkgYWRkaXRpb25h bCBmcmVlZG9tLg0KDQoNCltJbWFnZSByZW1vdmVkIGJ5IHNlbmRlci5dDQoNCldhcnJlbiBQYXJh ZA0KDQpGb3VuZGVyLCBDVE8NClNlY3VyZSB5b3VyIHVzZXIgZGF0YSBhbmQgY29tcGxldGUgeW91 ciBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50IEF1dGhyZXNzPGh0dHBzOi8v YXV0aHJlc3MuaW8+Lg0KDQoNCk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDg6MzkgUE0gVml0dG9y aW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbTxtYWlsdG86dml0dG9yaW8u YmVydG9jY2lAYXV0aDAuY29tPj4gd3JvdGU6DQpJbiB0aGUgVE1JLUJGRiB0b3BvbG9neSwgdGhl IGJhY2tlbmQgYW5kIGZyb250ZW5kIGRldmVsb3BlciBhcmUgdGhlIHNhbWUgcGVyc29uLiBUaGUg b3BlcmF0aW9ucyBUTUktQkZGIGRlc2NyaWJlcyBhcmUgdGhlIGZ1bmN0aW9uYWwgZXF1aXZhbGVu dCBvZiB3aGF0IHRoZSBKUyBjb2RlIG9mIG9uZSBTUEEgYXBwIHVzaW5nIGEgY29kZStQS0NFIFNE SyB3b3VsZCBkbyB3aGVuIHJldHJpZXZpbmcgcHJldmlvdXNseSBvYnRhaW5pbmcgdG9rZW5zIGZy b20gdGhlIHN0b3JlIGluIG9yZGVyIHRvIHBlcmZvcm0gYW4gQVBJIGNhbGwuIFdoZXJlYXMgc3Vj aCBhbiBhcHAgd291bGQgbWFrZSB0aGF0IGNhbGwgaW4gbWVtb3J5IChhbmQgcmVzdWx0IGluIHRo ZSBzYW1lIG9wZXJhdGlvbnMgZGVzY3JpYmVkIGhlcmUsIGVpdGhlciB1c2UgYSBwcmV2aW91c2x5 IHNhdmVkIGFjY2VzcyB0b2tlbiBtYXRjaGluZyB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBBUEkg Y2FsbCwgb3IgdXNlIGFydGlmYWN0cyBsaWtlIFJUcyB0byByZXF1ZXN0IGEgbmV3IGFjY2VzcyB0 b2tlbiBtYXRjaGluZyB0aGUgcmVxdWVzdCkgaW4gVE1JLUJGRiBhbCB0aGUgbG9naWMgYW5kIHBl cnNpc3RlbmNlIGxheWVyIGFyZSBpbiB0aGUgYmFja2VuZCwgaGVuY2UgdGhhdCBxdWVyeSBiZWNv bWVzIGEgcmVxdWVzdCB0byB0aGUgYmFja2VuZCBpbnN0ZWFkIG9mIGEgbG9jYWwgZnVuY3Rpb24g Y2FsbC4NClRoZSBhZHZhbnRhZ2VzIGhhdmUgYmVlbiBkZXNjcmliZWQgaW4gb3RoZXIgYnJhbmNo ZXMgb2YgdGhpcyB0aHJlYWQsIGJ1dCBUTDtEUi0gYSBsb3Qgb2YgdGhlIHRva2VuIHJlcXVlc3Rp bmcgd29yayBjYW4gYmUgcGVyZm9ybWVkIG1vcmUgcmVsaWFibHkgKGVnIGxlc3MgdGhpbmdzIGNh biBnbyB3cm9uZykgZnJvbSBhIGNvbmZpZGVudGlhbCBjbGllbnQgYW5kIGl04oCZcyBlYXNpZXIg Zm9yIFNESyBkZXZlbG9wZXJzIHRvIHBhY2thZ2UgaXQgKHNlZSBleGlzdGluZyBtaWRkbGV3YXJl cyB2cyBKUyBTREtzKS4gTm90ZSB0aGF0IGZvciB0aGUgYXBwIGRldmVsb3BlciB0aGlzIG1pZ2h0 IHN0aWxsIGxvb2sgbGlrZSB0aGUgc2FtZSBmbG93LCBhc2tpbmcgYSBKUyBTREsgdG8gZ2V0IHRo ZSB0b2tlbiB0aGUgYXBwIG5lZWRzIHRvIGNhbGwgYW4gQVBJLCBidXQgdGhlIEpTIFNESyB3b3Vs ZCBiZSBkcmFtYXRpY2FsbHkgc2ltcGxlciB0aGFuIHRoZSBvbmUgcGVyZm9ybWluZyBjb2RlK1BL Q0UgaW4gdGhlIHVzZXIgYWdlbnQgYW5kIGVudGFpbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gZnJv bnRlbmQgYSBiYWNrZW5kLCBoZW5jZSB0aGUgbmVlZCB0byBkZWZpbmUgaG93IHRoYXQgY29tbXVu aWNhdGlvbiBoYXBwZW5zIGlmIHdlIHdhbnQgZGV2ZWxvcGVycyB0byBiZSBhYmxlIHRvIG1peCBh bmQgbWF0Y2ggZnJvbnRlbmQgYW5kIGJhY2tlbmQgZGV2IHN0YWNrcy4NCkFnYWluLCB0aGlzIGRv ZXMgbm90IG5lY2Vzc2FyaWx5IGFkZCBzZWN1cml0eSB0byB0aGUgY29kZStQS0NFIGluIHRoZSB1 c2VyIGFnZW50IG1vZGVsICh3aGljaCByZW1haW5zIHRoZSBvbmx5IGdhbWUgaW4gdG93biBmb3Ig YmFja2VuZGxlc3MgU1BBcyksIGJ1dCBpdCBkb2VzIG1ha2UgdGhpbmdzIHNpbXBsZXIgZm9yIHRo ZSBmcm9udGVuZCBkZXZlbG9wZXIgYW5kIHJlcXVpcmVzIGxlc3MgYWR2YW5jZWQgY2FwYWJpbGl0 aWVzIGluIHRoZSBBUy4NCg0KRnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWRAcmhvc3lzLmNoPG1h aWx0bzp3cGFyYWRAcmhvc3lzLmNoPj4NCkRhdGU6IFN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEg YXQgMDk6NDUNClRvOiBTdG95Y2hvIFNsZXB0c292IDxzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNv bTxtYWlsdG86c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb20+Pg0KQ2M6IE5laWwgTWFkZGVuIDxu ZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t Pj4sIFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208bWFpbHRv OnZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbT4+LCBvYXV0aCA8b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlh dGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJG RikNCg0KQ29ycmVjdCBpdCB3b3VsZCBuZXZlciBuZWVkIHRvIGJlIHVzZWQgdG8gYXV0aGVudGlj YXRlIGEgY2xpZW50LCBhcyBhIGNsaWVudCBpcyBhbHdheXMgb2ZmbGluZSBhbmQgY2FuIGRpcmVj dGx5IHVzZSB0aGUgYmFja2NoYW5uZWwuIFlvdSB3b3VsZCBuZXZlciBuZWVkIHRoZSBmcm9udCBj aGFubmVsIHRvIGF1dGhlbnRpY2F0ZSBhIGNsaWVudCwgaG93ZXZlciB5b3UgbWlnaHQgbmVlZCB0 aGUgZnJvbnQgY2hhbm5lbCB0byBhdXRob3JpemUgYSBjbGllbnQgdG8gYWNjZXNzIHVzZXIgcmVz b3VyY2VzIG9mZmxpbmUuIElzIHRoYXQgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQsIGkuZS4g dGhlIG9mZmxpbmUgcmVmcmVzaF90b2tlbiBhdXRob3JpemF0aW9uIGNvZGUgZmxvdz8NCg0KSWYg eWVzLCB0aGVuIHRoZSBzdGFuZGFyZCB3b3VsZCBiZSB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24g Y29kZSBmbG93IHJlcXVlc3RpbmcgYXMgeW91J3ZlIG1lbnRpb25lZC4gQWx0aG91Z2ggdGhhdCBm bG93IGFscmVhZHkgZXhpc3RzIGFuZCB3ZWxsIGVzdGFibGlzaGVkLCBhbmQgd2l0aG91dCBhbnkg aXNzdWVzLCBoYXZpbmcgYSBzdGFuZGFyZCBzcGVjaWZ5aW5nIGhvdyB0byBjb21tdW5pY2F0ZSB3 aXRoIHRoZSBjbGllbnQgZG9lc24ndCBzZWVtIHRvIGJlIHVzZWZ1bCwgYXMgeW91IG9ubHkgbmVl ZCB0byBwYXNzIGFuIGF1dGggY29kZSBhbmQgdGhlIGlzc3VlciB0byB0aGUgY2xpZW50LiBCdXQg c2luY2UgdGhlc2UgZW5kcG9pbnRzIGFyZSBuZXZlciBleHBvc2VkIG5vciBuZWVkIHRvIGhhdmUg aW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBvd25lcnMgKGkuZS4gdGhlIG93bmVy IG9mIHRoZSBmcm9udC1jaGFubmVsIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvd25lciBvZiB0aGUg YmFjay1jaGFubmVsKSwgd2hhdCdzIHRoZSBiZW5lZml0IG9mIHNwZWNpZnlpbmcgdGhlIGV4cGxp Y2l0IGVuZHBvaW50cyBuZWNlc3NhcnkgZm9yIHRoZSBCRkYgdG8gaGF2ZT8NCg0KDQpFcnJvciEg RmlsZW5hbWUgbm90IHNwZWNpZmllZC4NCg0KV2FycmVuIFBhcmFkDQoNCkZvdW5kZXIsIENUTw0K U2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJj aGl0ZWN0dXJlLiBJbXBsZW1lbnQgQXV0aHJlc3M8aHR0cHM6Ly9hdXRocmVzcy5pbz4uDQoNCg0K T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgNjoyNyBQTSBTdG95Y2hvIFNsZXB0c292IDxzdG95Y2hv LnNsZXB0c292QGdtYWlsLmNvbTxtYWlsdG86c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb20+PiB3 cm90ZToNClRoYW5rcyBXYXJyZW4sDQoNCmFzIEkgc2VlIHlvdSBhbmQgTmVpbCBoYXZlIHRoZSBz YW1lIGlkZWEsDQpidXQgYXMgb2YgdGhpcyBtb21lbnQgSSB0aGluayB0aGlzIG1ldGhvZCBpcyBu b3QgYSB2YWxpZCBvcHRpb24gZm9yIGF1dGhlbnRpY2F0aW5nDQphIGNsaWVudCBhY2NvcmRpbmcg dG8gdGhlIGRyYWZ0LWlldGYtb2F1dGgtdjItMS4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGF1dGhl bnRpY2F0aW5nIHRoZSBjbGllbnQgdGhyb3VnaCB0aGUgQkZGDQpzZWVtcyBjb25mb3JtaW5nIHRv IHRoZSBzcGVjLiwgYnV0IGluIHRoZSBjYXNlIHdoZW4gdGhlIGFjY2VzcyB0b2tlbiBpcyB1c2Vk DQppbiB0aGUgYnJvd3NlciBpbiBmYWN0LCBJIGFtIGFmcmFpZCB0aGF0IGl0IGNhbiBiZSByZWdh cmRlZCBhcw0Kc29tZSBraW5kIG9mICJkZWNlcHRpb24iIG9mIHRoZSBBUy4NCg0KSXQgc2VlbXMg dGhlIGZyb250ZW5kIFNQQSBpcyBub3QgdGhlIGVhc2llc3Qgd2F5IHRvIGdvIHdpdGggb2F1dGgu Li4NCg0KU3RveWNoby4NCg0KT24gU3VuLCAxNCBGZWIgMjAyMSBhdCAxNzozNSwgV2FycmVuIFBh cmFkIDx3cGFyYWRAcmhvc3lzLmNoPG1haWx0bzp3cGFyYWRAcmhvc3lzLmNoPj4gd3JvdGU6DQpy ZWRpcmVjdF91cmkgYW5kIHVzZSBQS0NFIHZpYSB0aGUgY29kZSB2ZXJpZmllci4NCg0KDQpFcnJv ciEgRmlsZW5hbWUgbm90IHNwZWNpZmllZC4NCg0KV2FycmVuIFBhcmFkDQoNCkZvdW5kZXIsIENU Tw0KU2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24g YXJjaGl0ZWN0dXJlLiBJbXBsZW1lbnQgQXV0aHJlc3M8aHR0cHM6Ly9hdXRocmVzcy5pbz4uDQoN Cg0KT24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgMzo1MSBQTSBTdG95Y2hvIFNsZXB0c292IDxzdG95 Y2hvLnNsZXB0c292QGdtYWlsLmNvbTxtYWlsdG86c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb20+ PiB3cm90ZToNClRoYW5rcyBhIGxvdCBmb3IgeW91ciBhbnN3ZXIgTmVpbCwNCg0KYXMgSSBhbSBu byBleHBlcnQgKHlldCA6LSkpIGluIHNlY3VyaXR5IEkgd2FzIGFmcmFpZCB0byByZWx5IG9uDQpy ZWRpcmVjdF91cmkgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQsDQpidXQgSSB3aWxs IGNvbnNpZGVyIHRoYXQgb3B0aW9uIGFzIG1vcmUgdHJ1c3R3b3J0aHkgbm93Lg0KDQooaXQgaXMg YWxzbyBub3QgdmVyeSBjbGVhciBmb3IgbWUgd2hpY2ggcGFydCBvZiB0aGUgYXBwIGNhbiBiZQ0K cmVnYXJkZWQgYXMgdGhlIHJlZGlyZWN0X3VyaSBvd25lciwgdGhlIEJGRiBvciB0aGUgbG9hZGVk IGZyb250ZW5kDQpTUEEsIGJ1dCBtYXliZSBpdCBpcyBub3Qgc28gaW1wb3J0YW50KQ0KDQpJZiB5 b3UgaGFkIHRoZSB0d28gb3B0aW9ucyBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGZyb250ZW5k IFNQQQ0KY2xpZW50IC0gdGhlIHJlZGlyZWN0X3VyaSBvbiB0aGUgb25lIGhhbmQsIGFuZCB0aGUg QmFzaWMNCmF1dGhlbnRpY2F0aW9uIHdpdGggY2xpZW50IHNlY3JldCB0aHJvdWdoIHRoZSBCRkYg b24gdGhlIG90aGVyLCB3aGljaA0Kb25lIHdvdWxkIHlvdSByZWNvbW1lbmQ/DQoNCk9uIFN1biwg MTQgRmViIDIwMjEgYXQgMTY6MjgsIE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2su Y29tPG1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4gd3JvdGU6DQo+DQo+IFB1Ymxp YyBjbGllbnRzIGFyZSBpbXBsaWNpdGx5IGF1dGhlbnRpY2F0ZWQgYnkgdGhlaXIgb3duZXJzaGlw IG9mIHRoZSByZWdpc3RlcmVkIHJlZGlyZWN0X3VyaS4gVGhpcyB3aHkgaXTigJlzIGltcG9ydGFu dCB0byB1c2UgYSByZWRpcmVjdF91cmkgZm9yIHdoaWNoIG93bmVyc2hpcCBjYW4gYmUgcmVhc29u YWJseSBlc3RhYmxpc2hlZCwgc3VjaCBhcyBIVFRQUyBlbmRwb2ludHMgd2l0aCBleGFjdCBVUkkg bWF0Y2hpbmcuDQo+DQo+IFRoZXJlIGFyZSBtb3JlIHRoaW5ncyB0aGF0IGNhbiBnbyB3cm9uZyB3 aXRoIHRoYXQgKHNlZSB0aGUgc2VjdXJpdHkgQkNQKSwgYnV0IGl0IGNhbiBiZSBtYWRlIHJlYXNv bmFibHkgc2VjdXJlLg0KPg0KPiDigJQgTmVpbA0KPg0KPiA+IE9uIDE0IEZlYiAyMDIxLCBhdCAx Mzo0OCwgU3RveWNobyBTbGVwdHNvdiA8c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb208bWFpbHRv OnN0b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29tPj4gd3JvdGU6DQo+ID4NCj4gPiDvu78NCj4gPiBJ IHdvdWxkIGxpa2UgdG8gYWRkIG15IHJlYXNvbnMgYWJvdXQgdGhlICJXaHkgYXJlIGRldmVsb3Bl cnMgY3JlYXRpbmcgQkZGIGZvciB0aGVpciBmcm9udGVuZHMgdG8gY29tbXVuaWNhdGUgd2l0aCBh biBBUyIsDQo+ID4gd2l0aCB0aGUgb2JqZWN0aXZlIHRvIHZlcmlmeSBpZiB0aGV5IGFyZSB2YWxp ZC4NCj4gPg0KPiA+IEkgbmVlZCB0aGUgY2xpZW50IGFwcC4gdG8gYmUgYXV0aGVudGljYXRlZCBh dCB0aGUgQVMgKHRvIGRldGVybWluZSBpZiBpdCBpcyBhIGZpcnN0LXBhcnR5IGFwcC4sIGZvciBl eGFtcGxlKS4NCj4gPiBJZiB3ZSBkZWNpZGUgdG8gaW1wbGVtZW50IG91ciBjbGllbnQgYXMgYSBm cm9udGVuZCBTUEEgLCB0aGVuIHdlIGhhdmUgbm8gb3RoZXIgb3B0aW9uIGV4Y2VwdCB0aHJvdWdo IGEgQkZGLCBhcyBQS0NFIGRvZXMgbm90IGhlbHAgZm9yIGF1dGhlbnRpY2F0aW9uLg0KPiA+DQo+ ID4gT3IgaXMgaXQgY29uc2lkZXJlZCBhIGJhZCBwcmFjdGljZSB0byBkbyB0aGF0Pw0KPiA+DQo+ ID4gUmVnYXJkcywNCj4gPiBTdG95Y2hvLg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4gLS0NCj4gRm9yZ2VSb2NrIHZhbHVlcyB5b3Vy IFByaXZhY3kgPGh0dHBzOi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1wcml2YWN5Pg0K --_000_CO6PR18MB405282E82D5E7C0C68BFD51BAE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21z by1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NTk2MTczMzY7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM0NjI5MDI2IC0y MjQ4OTA4ODggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDo1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPiZuYnNwO1doYXQgaXMgdGhl IGZyb250ZW5kIGRldmVsb3BlciBkb2luZyBhbnkgZGlmZmVyZW50IGluIHRoZSBuZXcgaHlwb3Ro ZXRpY2FsIHdvcmxkIHRoYW4gdGhleSB3b3VsZCBiZSwgcmlnaHQgbm93IHRoZXkgYXJlIGluY2x1 ZGluZyBhbiBTREsgYW5kIHdyaXRpbmcgb25lIGxpbmUgb2YgY29kZSBvbiBsb2dpbiByZWRpcmVj dC9zaWxlbnQNCiBhdXRoIGFuZCBvbmUgbGluZSBvZiBjb2RlIGZvciBQS0NFK2NvZGUgdmFsaWRh dGlvbi4gSWYgYSBzZXJ2aWNlIGNsaWVudCBuZWVkcyB0byBiZSBhdXRob3JpemVkIHRoZXJlIHdv dWxkIGJlIGEgdGhpcmQgbGluZSBvZiBjb2RlIHRvIGNhbGwgdGhlIGJhY2tlbmQuPG86cD48L286 cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIG1lbnRpb25lZCwgdGhlIGNsaWVudCBjb2RlIG1pZ2h0 IG5vdCBsb29rIHZlcnkgZGlmZmVyZW50LSBhbHRob3VnaCBpbiB0aGUgVE1JLUJGRiBtb2RlbCB0 aGUgSlMgY29kZSBtaWdodCBiZSBldmVuIG1vcmUgc3VjY2luY3QgKGdpdmVuIHRoYXQgdGhlIHNp Z24gaW4gcGFydHMgYXJlIGhhbmRsZWQgYnkgdGhlIGJhY2tlbmQsIHRoZXkgbWlnaHQgc2ltcGx5 IGJlIGRlY29yYXRlZCByb3V0ZXMgb24gdGhlIG1pZGRsZXdhcmUtDQogbm8gbmVlZCBmb3IgdGhl IEpTIHRvIG1ha2UgdGhvc2UgY2FsbHMgZGlyZWN0bHksIGp1c3QgdG8gaGl0IHRoZSByb3V0ZXMp IGFuZCB0aGUgU0RLIGZhciBtb3JlIGxpZ2h0d2VpZ2h0LiBUaGUgZGlmZmVyZW5jZSBtaWdodCBi ZSB0aGF0IGlmIHlvdXIgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBub3Qgc3VwcG9ydCByZWZy ZXNoIHRva2VuIHJvdGF0aW9uIG9yIHNlbmRlciBjb25zdHJhaW5pbmcgUlRzLCB3aXRoIGNvZGUr UEtDRSB5b3UgbWlnaHQNCiBub3QgYmUgYWJsZSB0byBvYnRhaW4gdGhlIHNhbWUgZnVuY3Rpb25h bGl0eSBhcyBUTUktQkZGIGdpdmVuIHRoYXQgeW91IG1pZ2h0IG5vdCBoYXZlIGEgd2F5IG9mIHJl bmV3aW5nIHNob3J0IGxpdmVkIHRva2VucyB3aXRob3V0IGZ1bGwgcmVkaXJlY3RzIChzZWUgZGlz Y3Vzc2lvbiBvbiBJVFApLiBUaGF0IGlzIGEgdGVtcG9yYXJ5IHNpdHVhdGlvbiwgaG9wZWZ1bGx5 IGV2ZW50dWFsbHkgYWxsIEFTIHZlbmRvcnMgd2lsbCBzdXBwb3J0IHJvdGF0aW9uDQogYW5kL29y IHNlbmRlciBjb25zdHJhaW50LCBidXQgaXQgaXMgYW4gZXhhbXBsZSBvZiBob3cgdGhlIHByb3Bv c2FsIGRvZXMgaGF2ZSBhZHZhbnRhZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VGhlc2UgdGhyZWUgbGluZXMgc3RpbGwg bmVlZCB0byBiZSBwcmVzZW50IGlycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIHlvdSB1c2UgYW4gQVMt cHJveHkgVE1JLUJGRiBvciB0aGUgQVMgZGlyZWN0bHkuPG86cD48L286cD48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgYWJvdmUuIFRoYXTigJlzIG5vdCBuZWNlc3NhcmlseSB0 aGUgY2FzZSwgYW5kIHdoYXQgdGhlIGNsaWVudCBjb2RlIGxvb2tzIGxpa2UgaXNu4oCZdCB3aGF0 IFRNSS1CRkYgaXMgdHJ5aW5nIHRvIGFkZHJlc3MgYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+RXhjZXB0IG5vdyB3 ZSBhcmUgZW5jb3VyYWdpbmcgZXZlcnkgYXBwIHRvIHdyaXRlIGEgQkZGIGFuZCBpbnRlZ3JhdGUg dGhlaXIgZnJvbnQgY2hhbm5lbCB3aXRoIGl0LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBub3QgdGhlIGNhc2UuIFRoZSBzY29wZSBvZiB0aGlzIHBy b3Bvc2FsIHJlbWFpbnMgbGltaXRlZCB0byBhcHBzIHRoYXQgYWxyZWFkeSBoYXZlIGEgYmFja2Vu ZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPkFkZGl0aW9uYWxseSwgd2UgYXJlbid0IHJlcXVpcmluZyBsZXNzIGNhcGFiaWxp dGllcyBmcm9tIHRoZSBzcGVjLCB3ZSBhcmUganVzdCBhbHNvIHJlcXVpcmluZyBhZGRpdGlvbmFs IG9uZXMgZm9yIGEgQkZGLiBJZiB0aGVyZSBhcmUgY2FwYWJpbGl0aWVzIHRoaXMgbGV0cyB1cyBk cm9wIGZyb20gT0F1dGggY291bGQNCiB5b3UgZXhwbGFpbiB3aGljaCBvbmVzIHRob3NlIGFyZSwg YmVjYXVzZSBzaW5jZSBhbiBBUyZuYnNwO2Nhbid0IGtub3cgd2hldGhlciAmcXVvdDtjdXN0b21l cnMmcXVvdDsgYXJlIGdvaW5nIHRvIHdhbnQgdG8gdXNlIGEgQkZGIG9yIG5vdCwgaXQgd2lsbCBz dGlsbCBoYXZlIHRvIGltcGxlbWVudCBhbGwgdGhlIG5lY2Vzc2FyeSBBUyBmZWF0dXJlcyB0aGF0 IGFscmVhZHkgZXhpc3QgKGFuZCB0aGUgbmV3IG9uZXMgdGhhdCBkb24ndCkuIEkgZG9uJ3Qgc2Vl IGhvdyB0aGlzDQogYWZmb3JkcyBhbiBBUyBhbnkgYWRkaXRpb25hbCBmcmVlZG9tLjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25jZSBhZ2FpbiwgPGI+dGhpcyBw cm9wb3NhbCBpcyBub3QgbWVhbnQgdG8gbGlnaHRlbiB0aGUgQVMgYnVyZGVuLCBidXQgdG8gbWFr ZSB0aGUgbGlmZSBvZiBkZXZlbG9wZXJzIGVhc2llcjwvYj4uIEkgYWxyZWFkeSBtZW50aW9uZWQg dGhlIHJvdGF0aW9uL3NlbmRlciBjb25zdHJhaW50IGNhcGFiaWxpdGllcyB0aGF0IGNvZGUrUEtD RSByZXF1aXJlIGZvciBSVHMgdG8gYmUgdXNlZCBpbiBhIHVzZXIgYWdlbnQsDQogYW5kIHRoZSBm YWN0IHRoYXQgdmFyaW91cyBpbXBvcnRhbnQgQVMgb24gdGhlIG1hcmtldCB0b2RheSBkbyBub3Qg b2ZmZXIgdGhhdCBjYXBhYmlsaXR5LiBUaGVyZSBtaWdodCBiZSBvdGhlcnM6IGZvciBleGFtcGxl LCB1bnRpbCByZWNlbnRseSB2YXJpb3VzIGltcG9ydGFudCBBUyBkaWQgbm90IHN1cHBvcnQgQ09S UyBvbiB0aGVpciBtZXRhZGF0YSBhbmQgdG9rZW4gZW5kcG9pbnRzLCBtYWtpbmcgdGhlIGNvZGUr UEtDRSBpbiB0aGUgdXNlciBhZ2VudA0KIGltcG9zc2libGUuIE15IGhvcGUgYW5kIGFzc3VtcHRp b24gaXMgdGhhdCB0aG9zZSBhcmUgYWxsIHRlbXBvcmFyeSBzaXR1YXRpb25zLCBhbmQgVE1JLUJG RiBnb2FsIGlzIE5PVCB0byBkaXNwZW5zZSBBUyBkZXZlbG9wZXJzIGZyb20gaW1wbGVtZW50aW5n IHRob3NlIGZlYXR1cmVzLiAmbmJzcDtCdXQgdGhvc2UgYXJlIGNvbmNyZXRlIGV4YW1wbGVzIG9m IGNhc2VzIGluIHdoaWNoIFRPREFZIGFuIGFwcCBkZXZlbG9wZXIgKHdob3NlIGFwcCBoYXMgYSBi YWNrZW5kKQ0KIHRvb2sgYSBkZXBlbmRlbmN5IG9uIG9uZSBBUyB3aXRob3V0IHRob3NlIGZlYXR1 cmVzIG1pZ2h0IGJlIGFibGUgdG8gZG8gbW9yZSB0aGluZ3MgaW4gdGhlaXIgYXBwIHdoZW4gdXNp bmcgVE1JLUJGRiB0aGFuIHdpdGggSlMgY29kZSB0aGF0IHJlbGllcyBvbiB0aG9zZSBBUyBjYXBh YmlsaXRpZXMgdG8gZnVuY3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPldhcnJlbiBQYXJhZCAmbHQ7d3BhcmFkQHJob3N5cy5jaCZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAxMTo1Nzxicj4NCjxiPlRvOiA8 L2I+Vml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPlN0b3ljaG8gU2xlcHRzb3YgJmx0O3N0b3ljaG8uc2xlcHRzb3ZAZ21h aWwuY29tJmd0OywgTmVpbCBNYWRkZW4gJmx0O25laWwubWFkZGVuQGZvcmdlcm9jay5jb20mZ3Q7 LCBvYXV0aCAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb T0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5k IEZvciBGcm9udGVuZCAoVE1JIEJGRik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5idXQgaXQgZG9lcyBtYWtl IHRoaW5ncyBzaW1wbGVyIGZvciB0aGUgZnJvbnRlbmQgZGV2ZWxvcGVyIGFuZCByZXF1aXJlcyBs ZXNzIGFkdmFuY2VkIGNhcGFiaWxpdGllcyBpbiB0aGUgQVMuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIEknbSBzdGlsbCBnZXR0aW5n IGxvc3Qgb24gdGhpcyBwb2ludCwgd2hpY2ggc2VlbXMgbm90IHlldCBqdXN0aWZpZWQgZm9yIG1l LiBXaGF0IGlzIHRoZSBmcm9udGVuZCBkZXZlbG9wZXIgZG9pbmcgYW55IGRpZmZlcmVudCBpbiB0 aGUgbmV3IGh5cG90aGV0aWNhbCB3b3JsZCB0aGFuIHRoZXkgd291bGQgYmUsIHJpZ2h0IG5vdyB0 aGV5IGFyZSBpbmNsdWRpbmcgYW4gU0RLIGFuZCB3cml0aW5nIG9uZQ0KIGxpbmUgb2YgY29kZSBv biBsb2dpbiByZWRpcmVjdC9zaWxlbnQgYXV0aCBhbmQgb25lIGxpbmUgb2YgY29kZSBmb3IgUEtD RStjb2RlIHZhbGlkYXRpb24uIElmIGEgc2VydmljZSBjbGllbnQgbmVlZHMgdG8gYmUgYXV0aG9y aXplZCB0aGVyZSB3b3VsZCBiZSBhIHRoaXJkIGxpbmUgb2YgY29kZSB0byBjYWxsIHRoZSBiYWNr ZW5kLiBUaGVzZSB0aHJlZSBsaW5lcyBzdGlsbCBuZWVkIHRvIGJlIHByZXNlbnQgaXJyZXNwZWN0 aXZlIG9mIHdoZXRoZXINCiB5b3UgdXNlIGFuIEFTLXByb3h5IFRNSS1CRkYgb3IgdGhlIEFTIGRp cmVjdGx5LiBFeGNlcHQgbm93IHdlIGFyZSBlbmNvdXJhZ2luZyBldmVyeSBhcHAgdG8gd3JpdGUg YSBCRkYgYW5kIGludGVncmF0ZSB0aGVpciBmcm9udCBjaGFubmVsIHdpdGggaXQuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGRpdGlvbmFsbHksIHdlIGFy ZW4ndCByZXF1aXJpbmcgbGVzcyBjYXBhYmlsaXRpZXMgZnJvbSB0aGUgc3BlYywgd2UgYXJlIGp1 c3QgYWxzbyByZXF1aXJpbmcgYWRkaXRpb25hbCBvbmVzIGZvciBhIEJGRi4gSWYgdGhlcmUgYXJl IGNhcGFiaWxpdGllcyB0aGlzIGxldHMgdXMgZHJvcCBmcm9tIE9BdXRoIGNvdWxkIHlvdSBleHBs YWluIHdoaWNoIG9uZXMgdGhvc2UgYXJlLCBiZWNhdXNlIHNpbmNlIGFuIEFTJm5ic3A7Y2FuJ3QN CiBrbm93IHdoZXRoZXIgJnF1b3Q7Y3VzdG9tZXJzJnF1b3Q7IGFyZSBnb2luZyB0byB3YW50IHRv IHVzZSBhIEJGRiBvciBub3QsIGl0IHdpbGwgc3RpbGwgaGF2ZSB0byBpbXBsZW1lbnQgYWxsIHRo ZSBuZWNlc3NhcnkgQVMgZmVhdHVyZXMgdGhhdCBhbHJlYWR5IGV4aXN0IChhbmQgdGhlIG5ldyBv bmVzIHRoYXQgZG9uJ3QpLiBJIGRvbid0IHNlZSBob3cgdGhpcyBhZmZvcmRzIGFuIEFTIGFueSBh ZGRpdGlvbmFsIGZyZWVkb20uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBz ZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3Jk ZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHls ZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25l IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgd2lkdGg9IjE5OSIgaGVpZ2h0PSIz NCIgc3R5bGU9IndpZHRoOjIuMDcyOWluO2hlaWdodDouMzU0MWluIiBpZD0iX3gwMDAwX2kxMDI1 IiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiIgZGF0YS1vdXRsb29rLXRyYWNlPSJGOjB8 VDoxIiBzcmM9ImNpZDp+V1JENDAxLmpwZyI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0 O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxv dzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItYm90dG9tOm5vbmU7cGFkZGluZzowaW4gMGluIDBp biAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRl cjpub25lO3BhZGRpbmc6MGluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+V2FycmVuIFBhcmFkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAw aW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRlcjpu b25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aGl0 ZSI+U2VjdXJlIHlvdXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24g YXJjaGl0ZWN0dXJlLiBJbXBsZW1lbnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9hdXRo cmVzcy5pbyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5B dXRocmVzczwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCA4OjM5IFBNIFZpdHRvcmlv IEJlcnRvY2NpICZsdDs8YSBocmVmPSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29t Ij52aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JbiB0aGUgVE1JLUJGRiB0b3BvbG9neSwgdGhlIGJhY2tlbmQgYW5kIGZyb250ZW5kIGRl dmVsb3BlciBhcmUgdGhlIHNhbWUgcGVyc29uLiBUaGUgb3BlcmF0aW9ucyBUTUktQkZGIGRlc2Ny aWJlcyBhcmUgdGhlIGZ1bmN0aW9uYWwgZXF1aXZhbGVudCBvZiB3aGF0IHRoZSBKUyBjb2RlIG9m IG9uZSBTUEEgYXBwDQogdXNpbmcgYSBjb2RlK1BLQ0UgU0RLIHdvdWxkIGRvIHdoZW4gcmV0cmll dmluZyBwcmV2aW91c2x5IG9idGFpbmluZyB0b2tlbnMgZnJvbSB0aGUgc3RvcmUgaW4gb3JkZXIg dG8gcGVyZm9ybSBhbiBBUEkgY2FsbC4gV2hlcmVhcyBzdWNoIGFuIGFwcCB3b3VsZCBtYWtlIHRo YXQgY2FsbCBpbiBtZW1vcnkgKGFuZCByZXN1bHQgaW4gdGhlIHNhbWUgb3BlcmF0aW9ucyBkZXNj cmliZWQgaGVyZSwgZWl0aGVyIHVzZSBhIHByZXZpb3VzbHkgc2F2ZWQgYWNjZXNzDQogdG9rZW4g bWF0Y2hpbmcgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgQVBJIGNhbGwsIG9yIHVzZSBhcnRpZmFj dHMgbGlrZSBSVHMgdG8gcmVxdWVzdCBhIG5ldyBhY2Nlc3MgdG9rZW4gbWF0Y2hpbmcgdGhlIHJl cXVlc3QpIGluIFRNSS1CRkYgYWwgdGhlIGxvZ2ljIGFuZCBwZXJzaXN0ZW5jZSBsYXllciBhcmUg aW4gdGhlIGJhY2tlbmQsIGhlbmNlIHRoYXQgcXVlcnkgYmVjb21lcyBhIHJlcXVlc3QgdG8gdGhl IGJhY2tlbmQgaW5zdGVhZCBvZiBhDQogbG9jYWwgZnVuY3Rpb24gY2FsbC4gPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBhZHZhbnRhZ2VzIGhhdmUgYmVlbiBkZXNj cmliZWQgaW4gb3RoZXIgYnJhbmNoZXMgb2YgdGhpcyB0aHJlYWQsIGJ1dCBUTDtEUi0gYSBsb3Qg b2YgdGhlIHRva2VuIHJlcXVlc3Rpbmcgd29yayBjYW4gYmUgcGVyZm9ybWVkIG1vcmUgcmVsaWFi bHkgKGVnIGxlc3MgdGhpbmdzIGNhbiBnbyB3cm9uZykgZnJvbQ0KIGEgY29uZmlkZW50aWFsIGNs aWVudCBhbmQgaXTigJlzIGVhc2llciBmb3IgU0RLIGRldmVsb3BlcnMgdG8gcGFja2FnZSBpdCAo c2VlIGV4aXN0aW5nIG1pZGRsZXdhcmVzIHZzIEpTIFNES3MpLiBOb3RlIHRoYXQgZm9yIHRoZSBh cHAgZGV2ZWxvcGVyIHRoaXMgbWlnaHQgc3RpbGwgbG9vayBsaWtlIHRoZSBzYW1lIGZsb3csIGFz a2luZyBhIEpTIFNESyB0byBnZXQgdGhlIHRva2VuIHRoZSBhcHAgbmVlZHMgdG8gY2FsbCBhbiBB UEksIGJ1dCB0aGUgSlMNCiBTREsgd291bGQgYmUgZHJhbWF0aWNhbGx5IHNpbXBsZXIgdGhhbiB0 aGUgb25lIHBlcmZvcm1pbmcgY29kZStQS0NFIGluIHRoZSB1c2VyIGFnZW50IGFuZCBlbnRhaWwg Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIGZyb250ZW5kIGEgYmFja2VuZCwgaGVuY2UgdGhlIG5lZWQg dG8gZGVmaW5lIGhvdyB0aGF0IGNvbW11bmljYXRpb24gaGFwcGVucyBpZiB3ZSB3YW50IGRldmVs b3BlcnMgdG8gYmUgYWJsZSB0byBtaXggYW5kIG1hdGNoIGZyb250ZW5kIGFuZA0KIGJhY2tlbmQg ZGV2IHN0YWNrcy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFnYWlu LCB0aGlzIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGFkZCBzZWN1cml0eSB0byB0aGUgY29kZStQS0NF IGluIHRoZSB1c2VyIGFnZW50IG1vZGVsICh3aGljaCByZW1haW5zIHRoZSBvbmx5IGdhbWUgaW4g dG93biBmb3IgYmFja2VuZGxlc3MgU1BBcyksIGJ1dCBpdCBkb2VzIG1ha2UgdGhpbmdzIHNpbXBs ZXINCiBmb3IgdGhlIGZyb250ZW5kIGRldmVsb3BlciBhbmQgcmVxdWlyZXMgbGVzcyBhZHZhbmNl ZCBjYXBhYmlsaXRpZXMgaW4gdGhlIEFTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5XYXJyZW4gUGFyYWQgJmx0OzxhIGhyZWY9Im1haWx0bzp3cGFyYWRA cmhvc3lzLmNoIiB0YXJnZXQ9Il9ibGFuayI+d3BhcmFkQHJob3N5cy5jaDwvYT4mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPlN1bmRheSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMDk6NDU8YnI+DQo8Yj5U bzogPC9iPlN0b3ljaG8gU2xlcHRzb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG95Y2hvLnNsZXB0 c292QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPk5laWwgTWFkZGVuICZsdDs8YSBocmVmPSJtYWlsdG86 bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5laWwubWFkZGVuQGZv cmdlcm9jay5jb208L2E+Jmd0OywgVml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0 bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20iIHRhcmdldD0iX2JsYW5rIj52aXR0b3Jpby5i ZXJ0b2NjaUBhdXRoMC5jb208L2E+Jmd0Oywgb2F1dGggJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9u IEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvcnJl Y3QgaXQgd291bGQgbmV2ZXIgbmVlZCB0byBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBhIGNsaWVu dCwgYXMgYSBjbGllbnQgaXMgYWx3YXlzIG9mZmxpbmUgYW5kIGNhbiBkaXJlY3RseSB1c2UgdGhl IGJhY2tjaGFubmVsLiBZb3Ugd291bGQgbmV2ZXIgbmVlZCB0aGUgZnJvbnQgY2hhbm5lbCB0byBh dXRoZW50aWNhdGUNCiBhIGNsaWVudCwgaG93ZXZlciB5b3UgbWlnaHQgbmVlZCB0aGUgZnJvbnQg Y2hhbm5lbCB0byBhdXRob3JpemUgYSBjbGllbnQgdG8gYWNjZXNzIHVzZXIgcmVzb3VyY2VzIG9m ZmxpbmUuIElzIHRoYXQgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQsIGkuZS4gdGhlIG9mZmxp bmUgcmVmcmVzaF90b2tlbiBhdXRob3JpemF0aW9uIGNvZGUgZmxvdz88bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgeWVzLCB0aGVuIHRo ZSBzdGFuZGFyZCB3b3VsZCBiZSB0byB1c2UgdGhlIGF1dGhvcml6YXRpb24gY29kZSBmbG93IHJl cXVlc3RpbmcgYXMgeW91J3ZlIG1lbnRpb25lZC4gQWx0aG91Z2ggdGhhdCBmbG93IGFscmVhZHkg ZXhpc3RzIGFuZCB3ZWxsIGVzdGFibGlzaGVkLCBhbmQgd2l0aG91dCBhbnkgaXNzdWVzLA0KIGhh dmluZyBhIHN0YW5kYXJkIHNwZWNpZnlpbmcgaG93IHRvIGNvbW11bmljYXRlIHdpdGggdGhlIGNs aWVudCBkb2Vzbid0IHNlZW0gdG8gYmUgdXNlZnVsLCBhcyB5b3Ugb25seSBuZWVkIHRvIHBhc3Mg YW4NCjxiPmF1dGggY29kZTwvYj4mbmJzcDthbmQgdGhlIDxiPmlzc3VlcjwvYj4mbmJzcDt0byB0 aGUgY2xpZW50LiBCdXQgc2luY2UgdGhlc2UgZW5kcG9pbnRzIGFyZSBuZXZlciBleHBvc2VkIG5v ciBuZWVkIHRvIGhhdmUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBvd25lcnMg KGkuZS4gdGhlIG93bmVyIG9mIHRoZSBmcm9udC1jaGFubmVsIGlzIGRpZmZlcmVudCBmcm9tIHRo ZSBvd25lciBvZiB0aGUgYmFjay1jaGFubmVsKSwgd2hhdCdzIHRoZSBiZW5lZml0DQogb2Ygc3Bl Y2lmeWluZyB0aGUgZXhwbGljaXQgZW5kcG9pbnRzIG5lY2Vzc2FyeSBmb3IgdGhlIEJGRiB0byBo YXZlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAi IGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9k eT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBw dDtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUuMHB0IDUu MHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hp dGUgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEu MHB0O3BhZGRpbmc6MGluIj48Yj5FcnJvciEgRmlsZW5hbWUgbm90IHNwZWNpZmllZC48L2I+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzo1LjBw dCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0iYm9yZGVy OnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1ib3R0b206bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XYXJy ZW4gUGFyYWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGluIDBpbiAw aW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+Rm91bmRlciwgQ1RPPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aGl0ZSI+U2VjdXJlIHlvdXIgdXNl ciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0ZWN0dXJlLiBJbXBs ZW1lbnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9hdXRocmVzcy5pbyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BdXRocmVzczwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCA2OjI3IFBNIFN0b3ljaG8gU2xlcHRzb3YgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnN0b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIFdhcnJlbiw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hcyBJIHNlZSB5b3Ug YW5kIE5laWwgaGF2ZSB0aGUgc2FtZSBpZGVhLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5idXQgYXMgb2YgdGhpcyBtb21lbnQgSSB0aGluayB0 aGlzIG1ldGhvZCBpcyBub3QgYSB2YWxpZCBvcHRpb24gZm9yIGF1dGhlbnRpY2F0aW5nPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmEgY2xpZW50 IGFjY29yZGluZyB0byB0aGUmbmJzcDtkcmFmdC1pZXRmLW9hdXRoLXYyLTEuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiB0aGUgb3Ro ZXIgaGFuZCwgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCB0aHJvdWdoIHRoZSBCRkY8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c2VlbXMgY29u Zm9ybWluZyB0byB0aGUgc3BlYy4sIGJ1dCZuYnNwO2luIHRoZSZuYnNwO2Nhc2Ugd2hlbiZuYnNw O3RoZSBhY2Nlc3MgdG9rZW4gaXMgdXNlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbiB0aGUgYnJvd3NlciBpbiBmYWN0LCBJIGFtIGFmcmFp ZCB0aGF0IGl0IGNhbiBiZSByZWdhcmRlZCBhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zb21lIGtpbmQgb2YgJnF1b3Q7ZGVjZXB0aW9uJnF1 b3Q7IG9mIHRoZSBBUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkl0IHNlZW1zIHRoZSBmcm9udGVuZCBTUEEgaXMgbm90IHRoZSBlYXNp ZXN0IHdheSB0byBnbyB3aXRoIG9hdXRoLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdG95Y2hvLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCAxNCBGZWIgMjAy MSBhdCAxNzozNSwgV2FycmVuIFBhcmFkICZsdDs8YSBocmVmPSJtYWlsdG86d3BhcmFkQHJob3N5 cy5jaCIgdGFyZ2V0PSJfYmxhbmsiPndwYXJhZEByaG9zeXMuY2g8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZWRpcmVjdF91cmkg YW5kIHVzZSBQS0NFIHZpYSB0aGUgY29kZSB2ZXJpZmllci48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29s bGFwc2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0i Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2Jv cmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxiPkVycm9yISBGaWxlbmFt ZSBub3Qgc3BlY2lmaWVkLjwvYj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVy LWxlZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRl biI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWJvdHRvbTpu b25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPldhcnJlbiBQYXJhZDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItdG9w Om5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OndoaXRlIj5TZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXph dGlvbiBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczov L2F1dGhyZXNzLmlvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPkF1dGhyZXNzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCAzOjUxIFBNIFN0b3lj aG8gU2xlcHRzb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpzdG95Y2hvLnNsZXB0c292QGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnN0b3ljaG8uc2xlcHRzb3ZAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgYSBsb3Qg Zm9yIHlvdXIgYW5zd2VyIE5laWwsPGJyPg0KPGJyPg0KYXMgSSBhbSBubyBleHBlcnQgKHlldCA6 LSkpIGluIHNlY3VyaXR5IEkgd2FzIGFmcmFpZCB0byByZWx5IG9uPGJyPg0KcmVkaXJlY3RfdXJp IGZvciBhdXRoZW50aWNhdGlvbiBvZiB0aGUgY2xpZW50LDxicj4NCmJ1dCBJIHdpbGwgY29uc2lk ZXIgdGhhdCBvcHRpb24gYXMgbW9yZSB0cnVzdHdvcnRoeSBub3cuPGJyPg0KPGJyPg0KKGl0IGlz IGFsc28gbm90IHZlcnkgY2xlYXIgZm9yIG1lIHdoaWNoIHBhcnQgb2YgdGhlIGFwcCBjYW4gYmU8 YnI+DQpyZWdhcmRlZCBhcyB0aGUgcmVkaXJlY3RfdXJpIG93bmVyLCB0aGUgQkZGIG9yIHRoZSBs b2FkZWQgZnJvbnRlbmQ8YnI+DQpTUEEsIGJ1dCBtYXliZSBpdCBpcyBub3Qgc28gaW1wb3J0YW50 KTxicj4NCjxicj4NCklmIHlvdSBoYWQgdGhlIHR3byBvcHRpb25zIGZvciBhdXRoZW50aWNhdGlv biBvZiB0aGUgZnJvbnRlbmQgU1BBPGJyPg0KY2xpZW50IC0gdGhlIHJlZGlyZWN0X3VyaSBvbiB0 aGUgb25lIGhhbmQsIGFuZCB0aGUgQmFzaWM8YnI+DQphdXRoZW50aWNhdGlvbiB3aXRoIGNsaWVu dCBzZWNyZXQgdGhyb3VnaCB0aGUgQkZGIG9uIHRoZSBvdGhlciwgd2hpY2g8YnI+DQpvbmUgd291 bGQgeW91IHJlY29tbWVuZD88YnI+DQo8YnI+DQpPbiBTdW4sIDE0IEZlYiAyMDIxIGF0IDE2OjI4 LCBOZWlsIE1hZGRlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5laWwubWFkZGVuQGZvcmdlcm9jay5j b20iIHRhcmdldD0iX2JsYW5rIj5uZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgUHVibGljIGNsaWVudHMgYXJlIGltcGxpY2l0bHkgYXV0 aGVudGljYXRlZCBieSB0aGVpciBvd25lcnNoaXAgb2YgdGhlIHJlZ2lzdGVyZWQgcmVkaXJlY3Rf dXJpLiBUaGlzIHdoeSBpdOKAmXMgaW1wb3J0YW50IHRvIHVzZSBhIHJlZGlyZWN0X3VyaSBmb3Ig d2hpY2ggb3duZXJzaGlwIGNhbiBiZSByZWFzb25hYmx5IGVzdGFibGlzaGVkLCBzdWNoIGFzIEhU VFBTIGVuZHBvaW50cyB3aXRoIGV4YWN0IFVSSSBtYXRjaGluZy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaGVyZSBhcmUgbW9yZSB0aGluZ3MgdGhhdCBjYW4gZ28gd3Jvbmcgd2l0aCB0aGF0IChzZWUg dGhlIHNlY3VyaXR5IEJDUCksIGJ1dCBpdCBjYW4gYmUgbWFkZSByZWFzb25hYmx5IHNlY3VyZS48 YnI+DQomZ3Q7PGJyPg0KJmd0OyDigJQgTmVpbDxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgT24g MTQgRmViIDIwMjEsIGF0IDEzOjQ4LCBTdG95Y2hvIFNsZXB0c292ICZsdDs8YSBocmVmPSJtYWls dG86c3RveWNoby5zbGVwdHNvdkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zdG95Y2hvLnNs ZXB0c292QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyDvu788YnI+DQomZ3Q7ICZndDsgSSB3b3VsZCBsaWtlIHRvIGFkZCBteSByZWFzb25zIGFi b3V0IHRoZSAmcXVvdDtXaHkgYXJlIGRldmVsb3BlcnMgY3JlYXRpbmcgQkZGIGZvciB0aGVpciBm cm9udGVuZHMgdG8gY29tbXVuaWNhdGUgd2l0aCBhbiBBUyZxdW90Oyw8YnI+DQomZ3Q7ICZndDsg d2l0aCB0aGUgb2JqZWN0aXZlIHRvIHZlcmlmeSBpZiB0aGV5IGFyZSB2YWxpZC48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBuZWVkIHRoZSBjbGllbnQgYXBwLiB0byBiZSBhdXRoZW50 aWNhdGVkIGF0IHRoZSBBUyAodG8gZGV0ZXJtaW5lIGlmIGl0IGlzIGEgZmlyc3QtcGFydHkgYXBw LiwgZm9yIGV4YW1wbGUpLjxicj4NCiZndDsgJmd0OyBJZiB3ZSBkZWNpZGUgdG8gaW1wbGVtZW50 IG91ciBjbGllbnQgYXMgYSBmcm9udGVuZCBTUEEgLCB0aGVuIHdlIGhhdmUgbm8gb3RoZXIgb3B0 aW9uIGV4Y2VwdCB0aHJvdWdoIGEgQkZGLCBhcyBQS0NFIGRvZXMgbm90IGhlbHAgZm9yIGF1dGhl bnRpY2F0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPciBpcyBpdCBjb25zaWRl cmVkIGEgYmFkIHByYWN0aWNlIHRvIGRvIHRoYXQ/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IFN0b3ljaG8uPGJyPg0KJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZn dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IEZvcmdlUm9jayB2YWx1ZXMg eW91ciBQcml2YWN5ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5mb3JnZXJvY2suY29tL3lvdXIt cHJpdmFjeSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1w cml2YWN5PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CO6PR18MB405282E82D5E7C0C68BFD51BAE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 13:31:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCC73A0BC7 for ; Sun, 14 Feb 2021 13:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk-cW-LtGivF for ; Sun, 14 Feb 2021 13:31:16 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5BF3A0BC2 for ; Sun, 14 Feb 2021 13:31:16 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id a24so2616361plm.11 for ; Sun, 14 Feb 2021 13:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=gqZmVHAp6ASdqxvAjcianva+zShoRzMMu1/1jWh1YhE=; b=XFEDUq47NRUOBnrmFm6apzbhmQ+0ai/86a79hCJxKYWltMA95cGpDolwYBtDV/Ffg9 Yvu9kBkcvvZ4QrJYWYGFf/yCJSRHbhmfxuhXgYxCoqLn2JAdpUVj+nIk+pi2EcSzO813 bf/AoIA4rG2oAq5UH9JKFlgsTIZhUk15QcnWqyAfPSMENxV5hRzENI80ykgFaJdYHMiW uBFzf6cMZNYfxD8xyDu+Tpu3EvITrwb6Ppn1QGyRJfudFzJmDx38gfG83DC+NGnn9a7m BHLFpnd5nnDtnDC4j9Wos90h1znjIOrYHk8WlAP04ZvaD866V/uqBdKCIPuk5EoNw7rz 6FfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=gqZmVHAp6ASdqxvAjcianva+zShoRzMMu1/1jWh1YhE=; b=X3wN2BVjnPkFDGePxcRxvG0xPznss9uT8gM22gDhlFYOpM/pR37+dWMlTMDSKoDKBY 45x3pYx+PtiznoIFOl/TUC60z40nk41LhlwhKFnMrr7w2+QVIxdSb/BIRaQaFWxu5r2Y Gjsfxbs/vfLYFw4p1FpubCuyXS4wCOzs5EZahjzJcdWX0VRi3pH21EVINMLFhaXVowFX I76ItWYyoZBDNbdtd/NiTl7kEgVm7Bm68TUWhdt7BGeqpogcXBB8PhsNza514tPuqPgG 9D6oGlnjPB91pRQ+aZVHKMvG8zz+HhS/Wkm+NFnE6L1skn7u+vNes5izbSQRMEIEOMd5 PGQA== X-Gm-Message-State: AOAM531GpTMGN1NcsKYMQib4XHHTO/payWfyDVnlpTugsZ9rd/NssOmX FMeapYQopG8YelMJF7vSJaB1jZ17sU8fow== X-Google-Smtp-Source: ABdhPJz1aLXM7VzoHHs2UyN+MZPueY8tTP0FPNaK3sIw/4dM3Bbyfw91PH2YZTgXJol1wtobbDHsyw== X-Received: by 2002:a17:902:c114:b029:e1:5c6f:4a26 with SMTP id 20-20020a170902c114b02900e15c6f4a26mr12601179pli.85.1613338275046; Sun, 14 Feb 2021 13:31:15 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id y24sm15610612pfr.152.2021.02.14.13.31.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 13:31:14 -0800 (PST) From: Vittorio Bertocci To: Warren Parad CC: Neil Madden , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAA1Za+AAAVvgIAADHnkgAAF6ACAAGWCi4AAC++AgAALVsGAAArUgIAACN82 X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 14 Feb 2021 21:31:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052D4D091965B34B1DACD35AE899CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 21:31:19 -0000 --_000_CO6PR18MB4052D4D091965B34B1DACD35AE899CO6PR18MB4052namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgRHJhZnQgWy4uXSBlc3NlbnRpYWxseSBzdWdnZXN0cyB0aGF0IGV2ZXJ5IGFwcCBuZWVk cyB0byBydW4gYSBCRkYgdG8gZG8gdXNlciB0b2tlbiBnZW5lcmF0aW9uIGJlY2F1c2UgYW4gQVMg aXMgbm8gbG9uZ2VyIGFmZm9yZGVkIHRoZSBjYXBhYmlsaXR5IGZvciBzb21lIHJlYXNvbg0KSSBi ZWxpZXZlIHRoaXMgbWlnaHQgYmUgdGhlIGNydXggb2YgdGhlIHByb2JsZW0sIG15IGltcHJlc3Np b24gaXMgdGhhdCB5b3UgYXJlIGF0dHJpYnV0aW5nIHRvIHRoZSBkcmFmdCBhIHdheSBsYXJnZXIg c2NvcGUgdGhhbiBpdCBpcyBpbnRlbmRlZCB0byBoYXZlLiBUaGUgZHJhZnQgbWFrZXMgbm8gc3Vj aCBzdWdnZXN0aW9uLiBUaGUgZHJhZnQgc2F5cyBub3RoaW5nIGFib3V0IEFTIGxvc2luZyBjYXBh YmlsaXRpZXMuIFRoZSBkcmFmdCBpcyBub3QgdHJ5aW5nIHRvIHNvbHZlIGFuIEFTIHByb2JsZW0u IEFuZCBhYm92ZSBhbGwsIHRoZSBkcmFmdCBkb2VzIG5vdCB0YXJnZXQgZXZlcnkgYXBwLg0KDQpU aGUgZHJhZnQgaXMgYW4gb3B0aW1pemF0aW9uIGFpbWVkIGF0IGEgdmVyeSBzcGVjaWZpYywgYWxi ZWl0IHZlcnkgY29tbW9uLCBhcHBsaWNhdGlvbiB0b3BvbG9neSB3aGVyZSB0aGVyZSBpcyBhIGZy b250ZW5kIGFuZCBhIGJhY2tlbmQsIGFuZCB0aGUgZGV2ZWxvcGVyIHdhbnRzIHRvIHBlcmZvcm0g QVBJIGNhbGxzIGZyb20gdGhlIGZyb250ZW5kIGRpcmVjdGx5IHRvIHRoZSBSUy4gVGhpcyBpcyBv bmx5IGEgc3BlY2lmaWMgdG9wb2xvZ3ksIGFuZCB0aGUgcHJvcG9zYWwgaXMgc2NvcGVkIGRvd24g dG8gdGhhdC4gQWxsIG90aGVyIHRvcG9sb2dpZXMgYXJlIHVuYWZmZWN0ZWQuIEFsc28sIHRoZSBk cmFmdCBpc27igJl0IHB1c2hpbmcgdGhpcyB0b3BvbG9neSBhcyB0aGUgcHJlZmVycmVkIG9uZS4g SXTigJlzIGJlc3QgdG8ga2VlcCB0b2tlbnMgb3V0IG9mIHRoZSBmcm9udGVuZCBhbHRvZ2V0aGVy LiBCdXQgaWYgdGhlIGRldmVsb3BlciBpcyBhZGFtYW50IGluIHBlcmZvcm1pbmcgQVBJIGNhbGxz IGRpcmVjdCBmcm9tIHRoZWlyIEpTLCBhbmQgaWYgdGhleSBhbHJlYWR5IGhhdmUgYSBiYWNrZW5k LCBhbmQgb25seSBpbiB0aGF0IGNhc2UsIHRoZSBjdXJyZW50IHByb3Bvc2FsIGhhcyBsZXNzIG1v dmluZyBwYXJ0cyBhbmQgbGVzcyByZXF1aXJlbWVudHMgdGhhbiBjb2RlK1BLQ0UgLg0KDQpDb2Rl K1BLQ0UgYWxyZWFkeSBoYXMgdGhlIGV4cHJlc3NpdmUgcG93ZXIgdG8gaGFuZGxlIHRoZSBzY2Vu YXJpbyBkZXNjcmliZWQgaGVyZSwgYW5kIGlzIGFwcGxpY2FibGUgdG8gYSB3aWRlciByYW5nZSBv ZiBzY2VuYXJpb3MuIFRoZSBtYWluIHBvaW50IHRoZSBkcmFmdCBicmluZ3MgdG8gdGhlIHRhYmxl IGlzIHRoZSBhYmlsaXR5IGZvciBhIGZyb250ZW5kIHRvIGRlbGVnYXRlIHRvIGEgYmFja2VuZCBh IGxvdCBvZiBsb2dpYyB0aGF0IGluIHRoZSBjb2RlK1BLQ0UgY2FzZSBleGVjdXRlcyBpbiBhbiBl bnZpcm9ubWVudCB0aGF0IGlzIG5hdHVyYWxseSBtb3JlIGNvbnN0cmFpbmVkIGFuZCBwcm9uZSB0 byBhdHRhY2tzIHRoYW4gYSBiYWNrZW5kLiBUaGF0IGRvZXNu4oCZdCBtZWFuIGRldmVsb3BlcnMg d2hvc2UgYXBwIGhhcyBhIGJhY2tlbmQgc2hvdWxkIGF1dG9tYXRpY2FsbHkgY2hvb3NlIHRoZSBu ZXcgbW9kZWwgb3ZlciBjb2RlK1BLQ0UsIG1vcmUgdGhhdCB0aGUgbW9kZWwgZGlzY3Vzc2VkIGhl cmUgbWlnaHQgYmUgdmlhYmxlIGFuZCByZXF1aXJlIGxlc3MgY2FwYWJpbGl0aWVzL21vdmluZyBw YXJ0cyB0byBhY2hpZXZlIHRoZSBzYW1lIGV4cHJlc3NpdmUgcG93ZXIsIGVzcGVjaWFsbHkgaWYg dGhlIFNES3MgdXNlZCBpbiB0aGUgc29sdXRpb24gaGF2ZSBhIHN0YW5kYXJkIHdheSB0byBoYW5k bGUgaXQuIFRoYXQgaXMgZmFyIGZyb20gZXZlcnkgYXBwLCBidXQgaXQgaXMgYSBzaXR1YXRpb24g SSBlbmNvdW50ZXJlZCBpbiB0aGUgd2lsZCBvZnRlbiBlbm91Z2ggdG8gcHJvbXB0IHRoZSBkaXNj dXNzaW9uIHdpdGggQnJpYW4gYW5kIHRoZSBkcmFmdC4NCg0KQXMgYSBzaWRlIG5vdGUsIHRoZSBp bml0aWFsIHJlYWN0aW9ucyBvZiBwcmFjdGl0aW9uZXJzIGhhdmUgYmVlbiB2ZXJ5IHBvc2l0aXZl LiBJIGFtIHJlYWxseSBob3BpbmcgdGhlIGRpc2N1c3Npb24gd2lsbCBsZWFkIHRvIGlkZW50aWZ5 aW5nIGFuZCB3ZWVkaW5nIG91dCBzZWN1cml0eSBpc3N1ZXMsIG9yIGxhbmQgb24gc2VjdXJpdHkg Zmxhd3MgaW4gdGhlIG1vZGVsIHNvIGdyYXZlIHRoYXQgdGhleSBjYW4gYmUgcHJvcGVybHkgdXNl ZCB0byBkaXNjb3VyYWdlIGl0cyB1c2UuIE5vIG1hdHRlciB3aGF0IHdheSBpdCB3aWxsIGdvLCBJ IGFtIHZlcnkgZ2xhZCB0aGUgZGlzY3Vzc2lvbiBpcyB0YWtpbmcgcGxhY2UuDQoNCkZyb206IFdh cnJlbiBQYXJhZCA8d3BhcmFkPTQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogU3Vu ZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAxMjo1OQ0KVG86IFZpdHRvcmlvIEJlcnRvY2NpIDx2 aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+DQpDYzogTmVpbCBNYWRkZW4gPG5laWwubWFkZGVu QGZvcmdlcm9jay5jb20+LCAib2F1dGhAaWV0Zi5vcmciIDxvYXV0aEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlv biBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KVG8gcmVzdGF0ZSwgdGhlIFRNSS1C RkYgcHJvcG9zYWwgaXMgbm90IHRyeWluZyB0byBmaXggYW55IG9mIHRoYXQuLi4gaXTigJlzIGRl ZmluaXRlbHkgbm90IGEgdG9wIGxldmVsIGRyaXZlci4NCkdyZWF0LCB0aGVuIHdlIGFyZSBiYWNr IHRvOiB3aGF0IGlzIHRoZSB0b3AgbGV2ZWwgZHJpdmVyLiBCZWNhdXNlLCB3aGlsZSBJIGFwcHJl Y2lhdGUgdGhlIGNpcmN1bXN0YW5jZXMgYXJvdW5kIElUUDIuMX4gYXMgSSBmdWxseSB1bmRlcnN0 YW5kIGhvdyBpZGVudGl0eSBwcm92aWRlcnMgbGlrZSBBdXRoMCBhcmUgdXNpbmcgaWZyYW1lcyBh bmQgdGhpcmRwYXJ0eSBjb29raWVzLCB0aGlzIHByb2JsZW0gdmFuaXNoZXMgd2l0aCB0aGUgdXNl IG9mIGZpcnN0LXBhcnR5IGRvbWFpbnMuIFNvIGxldCdzIHNraXAgdGhlIGRpZ3Jlc3Npb24gYW5k IGFzc3VtZSB3ZSBhcmVuJ3Qgc29sdmluZyBJVFAgZnV0dXJlIHJlbGF0ZWQgaXNzdWVzLg0KDQpU aGUgcmVhbCBwcm9ibGVtIEkgaGF2ZSB3aXRoIHRoZSBkcmFmdCBpcyB0aGF0IGl0IGVzc2VudGlh bGx5IHN1Z2dlc3RzIHRoYXQgZXZlcnkgYXBwIG5lZWRzIHRvIHJ1biBhIEJGRiB0byBkbyB1c2Vy IHRva2VuIGdlbmVyYXRpb24gYmVjYXVzZSBhbiBBUyBpcyBubyBsb25nZXIgYWZmb3JkZWQgdGhl IGNhcGFiaWxpdHkgZm9yIHNvbWUgcmVhc29uLiBJZiB3ZSBwdWxsIGluIGV4cGVjdGluZyB0byBz b2x2ZSBJVFAgcmVsYXRlZCBpc3N1ZXMgdGhlbiBJIHRoaW5rIHRoYXQganVzdGlmaWNhdGlvbiBp cyBpbiBwbGF5IGFuZCB3ZSBjYW4gd29yayB0b2dldGhlciB0byBjb21lIHVwIHdpdGggYSBzb2x1 dGlvbiwgcmF0aGVyIHRoYW4gc3RhcnRpbmcgd2l0aCB0aGUgY3VycmVudCBkZWxldGVyaW91cyBw cmV2YWxlbnQgcGF0dGVybiBvbiB0aGUgaW50ZXJuZXQgKHdoaWNoIGhvbmVzdGx5IGlzIHRoZSBt b3N0IHJpZGljdWxvdXMgcGFyYWRpZ20gSSBoYXZlIHNlZW4pLiBJZiB3ZSBkb24ndCBhc3N1bWUg SVRQIGlzIGFuIGlzc3VlLCB0aGVuIEkgZmFpbCB0byBzZWUgdGhlIGNvcmUgcHJvYmxlbSB0aGF0 IGV4aXN0aW5nIEFTIGhhdmUgKGFzIHlvdSBwb2ludGVkIG91dCBjb2RlK1BLQ0UgYWxyZWFkeSB3 b3Jrcykgd2l0aG91dCB0aGUgZnJvbnQgY2hhbm5lbCBvciBiYWNrIGNoYW5uZWwgbmVlZGluZyBy ZWFsbHkgdG8gbWFrZSBhbnkgYWRkaXRpb25hbCBjaGFuZ2VzLg0KDQpJIGFzc3VtZSB0aGVyZSBp cyBhIGZsYXcgaW4gbXkgcmVhc29uaW5nIHNvbWV3aGVyZSwgc28gcGxlYXNlIGhlbHAgbWUgZmlu ZCBpdC4NCg0KLSBXYXJyZW4NCg0KDQpbSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuXQ0KDQpXYXJy ZW4gUGFyYWQNCg0KRm91bmRlciwgQ1RPDQoNCg0KT24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgOToy MCBQTSBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVydG9jY2k9NDBhdXRoMC5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpM ZXQgbWUgcmV3aW5kIGEgYml0IGhlcmUuIFRoaXMgd2FzIG5ldmVyIHByZXNlbnRlZCBhcyBkcml2 aW5nIHVzZSBjYXNlLg0KDQoNCiAgKiAgIE5laWwgc3VnZ2VzdGVkIHRoYXQgdGhlIGJhY2tlbmQg Y291bGQgc2ltcGx5IGdpdmUgc2hvcnQgbGl2ZWQgSlRXcyBmb3IgdGhlIGZyb250ZW50IHRvIGNh bGwgQVBJLg0KICAqICAgSSBjbGFyaWZpZWQgdGhhdCB0aGlzIHdvdWxkIG5vdCBiZSB2aWFibGUg aW4gdGhlIGdlbmVyYWwgY2FzZSBhbmQgcHJvdmlkZWQgYW4gZXhhbXBsZSBzY2VuYXJpbyB3aGVy ZSBiYWNrZW5kIGlzc3VlZCBzaG9ydCBsaXZlZCB0b2tlbnMgd291bGQgbm90IGhhdmUgd29ya2Vk DQogICogICBZb3UgY29tbWVudGVkIHRoYXQgdGhlIGZyb250ZW5kIGNhbiBvYnRhaW4gQVMgdG9r ZW5zIGZyb20gSlMgYW5kIG1lbnRpb25lZCBzaWxlbnQgYXV0aGVudGljYXRpb24uIEkgY2xhcmlm aWVkIChvciB0cmllZCB0bykgdGhhdCB0aGlzIG9mZnNob290IG9mIHRoZSBkaXNjdXNzaW9uIHdh c27igJl0IHRvIHNheSB0aGF0IHRoZXJlIGlzIG5vIHZpYWJsZSB3YXkgb2YgZG9pbmcgdGhlIHNj ZW5hcmlvIGFscmVhZHksIGFuZCBieSB0aGUgd2F5IHVzaW5nIGFuIGlGcmFtZSB0byBkbyBzaWxl bnQgYXV0aGVudGljYXRpb24gaXMgbm93IHByb2JsZW1hdGljLiBBdCB0aGlzIHBvaW50IHdlIGFy ZSBubyBsb25nZXIgZGlzY3Vzc2luZyBUTUktQkZGLCBidXQgY3VycmVudCBhZmZhaXJzIGluIHRo ZSBhdXRoZW50aWNhdGlvbiB3b3JsZC4gVGhlIGZhY3QgdGhhdCB3ZSBhcmUgcHJvcG9zaW5nIFRN SS1CRkYgYW5kIHRoZSBmYWN0IHRoYXQgc2lsZW50IGF1dGhlbnRpY2F0aW9uIGlzIGxlc3MgYW5k IGxlc3MgdmlhYmxlIGFyZSBpbmRlcGVuZGVudCBmYWN0cywgdGhlIGZvcm1lciBpc27igJl0IG1l YW50IHRvIGJlIGEgc29sdXRpb24gZm9yIHRoZSBsYXR0ZXIgKGl04oCZcyBhbHJlYWR5IGFkZHJl c3NlZCBieSB1c2luZyBSVHMgaW4gY29rZStQS0NFKQ0KDQpUaGF0IGNsYXJpZmllZC4gTm90IG9u bHkgd2UgZXhwZWN0IElUUCB0byBhZmZlY3Qgc2lsZW50IGF1dGhlbnRpY2F0aW9uLCBpdCBoYXMg YmVlbiBhZmZlY3RlZCBmb3IgdGhlIHBhc3QgeWVhciBhbmQgdGhhdCBoYXMgYmVlbiBvbmUgb2Yg dGhlIHByaW1hcnkgYnVzaW5lc3MgZHJpdmVycyBmb3IgdGhlIHJhcGlkIGFkb3B0aW9uIG9mIGNv ZGUrUEtDRStSVHMgaW4gdGhlIHVzZXIgYWdlbnQsIGFzIGN1c3RvbWVycyB3aXRoIHB1cmUgU1BB cyBmb3VuZCB0aGVtc2VsdmVzIHVuYWJsZSB0byByZW5ldyB0b2tlbnMgd2l0aG91dCBwcm9tcHRp bmcgYXMgdGhlaXIgYWNjZXNzIHRvIGNvb2tpZXMgaW4gZmxvd3MgZHJpdmVuIGJ5IGlmcmFtZXMg YmVjYW1lIGxlc3MgYW5kIGxlc3MgcmVsaWFibGUuDQpXaGVuIElUUCB3YXMgaW50cm9kdWNlZCB3 ZSBwdXQgbWFueSBjb21wYW5pZXMgdG9nZXRoZXIgdG8gdHJ5IHRvIGdldCBBcHBsZSB0byBjaGFu Z2UgaXQgKHlvdSBjYW4gZmluZCB0aGUgZG9jIGluIGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2Rv Y3VtZW50L2QvMVJzLS1ERnpaal9TZlFqdHo4b0g5RGxMSUkwcmEzdmlNRUhySzdzS3NhaVUvZWRp dCNoZWFkaW5nPWgucDNudnA2eG14dnpmKSBidXQgdGhleSBkaWRu4oCZdCBidWxnZSBhbmQgdWx0 aW1hdGVseSB0aGUgaW50cm9kdWN0aW9uIG9mIFJUcyBpbiB1c2VyIGFnZW50IGNvZGUgKGFsYmVp dCB3aXRoIGV4dHJhIHJlc3RyaWN0aW9ucywgdGhlIG9uZSBJIG1lbnRpb25lZCBub3QgZXZlcnlv bmUgaXMgZm9sbG93aW5nKSBtYWRlIHRoZSBwcm9ibGVtIG1hbmFnZWFibGUuIFdlIGhhdmUgYW4g aW5pdGlhdGl2ZSBjcm9zcyB3b3JraW5nIGdyb3VwcyAoSUVURiwgT0lEQyBldGMpZm9yIHdvcmtp bmcgd2l0aCBicm93c2VyIHZlbmRvcnMgdG8gdHJ5IGNvbnRhaW5pbmcgc2ltaWxhciByZWdyZXNz aW9ucyBpbiB0aGUgZnV0dXJlLiBGb3IgYSBzdW1tYXJ5IG9mIHNpbWlsYXIgcHJvYmxlbXMgc2Vl IGh0dHBzOi8vaWRlbnRpdmVyc2UuZ2FsbGVyeS52aWRlby9kZXRhaWwvdmlkZW8vNjE4NDQ0MzAz NzAwMS9icm93c2VyLWZlYXR1cmVzLXZzLWlkZW50aXR5LXByb3RvY29scy4NCg0KVG8gcmVzdGF0 ZSwgdGhlIFRNSS1CRkYgcHJvcG9zYWwgaXMgbm90IHRyeWluZyB0byBmaXggYW55IG9mIHRoYXQs IG5vciBwZXIgdGhlIGFib3ZlIHNvbWUgb2YgaXQgbmVlZCBmaXhpbmcuIFRoZSBvbmx5IGluZGly ZWN0IGNvbm5lY3Rpb24gbWlnaHQgYmUgdGhhdCBsZXNzIHN0dWZmIGhhcHBlbmluZyBpbiB0aGUg dXNlciBhZ2VudCBtZWFucyBsZXNzIG9wcG9ydHVuaXRpZXMgZm9yIHNpbWlsYXIgY2hhbmdlcyB0 byBpbXBhY3QgdGhlIGZsb3dzLCBidXQgaXTigJlzIGRlZmluaXRlbHkgbm90IGEgdG9wIGxldmVs IGRyaXZlci4NCg0KRnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWQ9NDByaG9zeXMuY2hAZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOjQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IFN1bmRh eSwgRmVicnVhcnkgMTQsIDIwMjEgYXQgMTE6NDENClRvOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0 dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5j b20+Pg0KQ2M6IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpu ZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPj4sICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlv biBCYWNrZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KVGhhdCBvbmx5IGFwcGxpZXMgdG8g dGhpcmQgcGFydHkgY29va2llcywgaXQgc2hvdWxkbid0IGFmZmVjdCB0aGlyZC1wYXJ0eSBpZnJh bWVzIGFzIGZhciBhcyBJJ20gYXdhcmUuIFNvIHVubGVzcyB3ZSBleHBlY3QgdGhvc2UgdG8gYnJl YWssIHdlIHByb2JhYmx5IHNob3VsZG4ndCBpbmNsdWRlIHRoYXQgYXMgYSBkcml2aW5nIHVzZSBj YXNlLiBJcyB0aGVyZSBhbm90aGVyIG1lYXN1cmUgdGhhdCB3b3VsZCBiZSByZWxldmFudCBoZXJl Pw0KDQoNCkVycm9yISBGaWxlbmFtZSBub3Qgc3BlY2lmaWVkLg0KDQpXYXJyZW4gUGFyYWQNCg0K Rm91bmRlciwgQ1RPDQpTZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0 aG9yaXphdGlvbiBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCBBdXRocmVzczxodHRwczovL2F1dGhy ZXNzLmlvPi4NCg0KDQpPbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCA3OjU3IFBNIFZpdHRvcmlvIEJl cnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCklUUCwgZm9yIGV4YW1wbGUN Cg0KRnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWQ9NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IFN1bmRheSwgRmVicnVh cnkgMTQsIDIwMjEgYXQgMDQ6NTQNClRvOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVy dG9jY2lAYXV0aDAuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+Pg0KQ2M6 IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1hZGRl bkBmb3JnZXJvY2suY29tPj4sICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5k IEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KQ2FuIHlvdSBleHBhbmQgb24gd2hhdCBzaWxlbnQg YXV0aGVudGljYXRpb24gYW5kIHNlc3Npb24gdG9rZW4gc3RhbmRzIGZvciBoZXJlPyBJZiB5b3Ug YXJlIHJlZmVycmluZyB0byB0aGUgaWZyYW1lIHNjZW5hcmlvLCB0aGUgbmV3IGJyb3dzZXIgbWVh c3VyZXMgbWFrZSBpdCBwcm9ibGVtYXRpYy4NCldoaWNoIG5ldyBicm93c2VyIG1lYXN1cmVzPw0K DQoNCkVycm9yISBGaWxlbmFtZSBub3Qgc3BlY2lmaWVkLg0KDQpXYXJyZW4gUGFyYWQNCg0KRm91 bmRlciwgQ1RPDQpTZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9y aXphdGlvbiBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCBBdXRocmVzczxodHRwczovL2F1dGhyZXNz LmlvPi4NCg0KDQpPbiBTdW4sIEZlYiAxNCwgMjAyMSBhdCAxOjMzIFBNIFZpdHRvcmlvIEJlcnRv Y2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KICAqICAgRm9yIFVJIHJlbGF0 ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBkb2N1bWVudCBzZWxlY3Rpb24sIHVzZXIgcHJvZmlsZSBk aXNwbGF5L2NoYW5nZXMsIGNvbnRhY3QgdXBkYXRlcywgZXRjLi4uIFlvdSBzaG91bGQgYmUgYWJs ZSB0byBleGVjdXRlIHRoZSBjbGllbnQgc2lkZSBzaWxlbnQgYXV0aGVudGljYXRpb24gdXNpbmcg dGhlIHByb3ZpZGVkIHNlc3Npb24gdG9rZW4gZnJvbSB0aGUgQXp1cmUgQUQgQVMsIHdpdGhvdXQg bmVlZGluZyB0byBtYWtlIGFueSBSTyBhcGkgY2FsbHMgbm9yIHVzZXIgcmVkaXJlY3RzLg0KQ2Fu IHlvdSBleHBhbmQgb24gd2hhdCBzaWxlbnQgYXV0aGVudGljYXRpb24gYW5kIHNlc3Npb24gdG9r ZW4gc3RhbmRzIGZvciBoZXJlPyBJZiB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgaWZyYW1lIHNj ZW5hcmlvLCB0aGUgbmV3IGJyb3dzZXIgbWVhc3VyZXMgbWFrZSBpdCBwcm9ibGVtYXRpYy4gSW4g Y29kZStQS0NFIHlvdSBjYW4gdXNlIGEgcmVmcmVzaCB0b2tlbiwgYnV0IHNlZSB0aGUgb3RoZXIg cmVwbHkgZm9yIGhvdyB0aGlzIHByb3Bvc2FsIGlzIGFuIGFsdGVybmF0aXZlIHRvIHRoYXQgaW4g c29tZSBzaXR1YXRpb25zLiBUaGlzIGFuc3dlciB3YXMgc3BlY2lmaWNhbGx5IG9uIHdoeSBoYXZp bmcgYmFja2VuZC1pc3N1ZWQgdG9rZW5zIGRpZG7igJl0IGFwcGx5IHRvIHRoaXMgc2NlbmFyaW8u DQoNCg0KRnJvbTogV2FycmVuIFBhcmFkIDx3cGFyYWQ9NDByaG9zeXMuY2hAZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwcmhvc3lzLmNoQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IFN1bmRheSwgRmVi cnVhcnkgMTQsIDIwMjEgYXQgMDM6NDgNClRvOiBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8u YmVydG9jY2lAYXV0aDAuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+Pg0K Q2M6IE5laWwgTWFkZGVuIDxuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tPG1haWx0bzpuZWlsLm1h ZGRlbkBmb3JnZXJvY2suY29tPj4sICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNr ZW5kIEZvciBGcm9udGVuZCAoVE1JIEJGRikNCg0KRm9yIHRoZSB0cnVzdGVkIHBhcnQsIHNlZSBh Ym92ZS4gRm9yIHRoZSBzaG9ydCBsaXZlZCBKV1RzLCB0aGF04oCZcyBub3QgcmVhbGx5IGFuIG9w dGlvbi4gVGhlIG1vc3QgZ2VuZXJpYyBzY2VuYXJpbyBhZGRyZXNzZWQgaGVyZSBpcyBmb3IgQVBJ cyB0aGF0IGFjY2VwdCB0b2tlbnMgaXNzdWVkIGJ5IHRoZSBBUzsgdGhlIGJhY2tlbmQgY2FuIHJl cXVlc3QgdGhlbSBhcyBhIGNsaWVudCwgYnV0IGl0IGNhbm5vdCBtaW50IHRoZW0uIEltYWdpbmUg d2XigJlyZSB0YWxraW5nIGFib3V0IGEgU1BBIGFwcGxpY2F0aW9uIHRoYXQgc2lnbnMgaW4gdXNl cnMgdXNpbmcgQXp1cmUgQUQsIGFuZCBuZWVkcyB0byBjYWxsIE9mZmljZSBhbmQgQXp1cmUgQVBJ cy4gVGhlIFNQQSBiYWNrZW5kIGNhbm5vdCBpc3N1ZSB0b2tlbnMgZm9yIHRob3NlIEFQSXMsIGl0 IGNhbiBvbmx5IHJlcXVlc3QgdGhlbSB0byB0aGUgQXp1cmUgQUQgQVMuDQoNCkZvciBVSSByZWxh dGVkIGZ1bmN0aW9uYWxpdHksIGkuZS4gZG9jdW1lbnQgc2VsZWN0aW9uLCB1c2VyIHByb2ZpbGUg ZGlzcGxheS9jaGFuZ2VzLCBjb250YWN0IHVwZGF0ZXMsIGV0Yy4uLiBZb3Ugc2hvdWxkIGJlIGFi bGUgdG8gZXhlY3V0ZSB0aGUgY2xpZW50IHNpZGUgc2lsZW50IGF1dGhlbnRpY2F0aW9uIHVzaW5n IHRoZSBwcm92aWRlZCBzZXNzaW9uIHRva2VuIGZyb20gdGhlIEF6dXJlIEFEIEFTLCB3aXRob3V0 IG5lZWRpbmcgdG8gbWFrZSBhbnkgUk8gYXBpIGNhbGxzIG5vciB1c2VyIHJlZGlyZWN0cy4gRm9y IFJPIHJlc3BvbnNpYmlsaXRpZXMsIHlvdSBjYW4gcHJlc2VudCB0aGUgdXNlciB3aXRoIGEgYnV0 dG9uICJHcmFudCBSTyBhY2Nlc3MgdG8gQXp1cmUgcmVzb3VyY2VzIiBidXR0b24gYW5kIHRoZSB1 c2VyIHdpbGwgZ28gdGhyb3VnaCBhIHBlcm1pc3Npb24gc2NvcGUgZWxldmF0aW9uIGZsb3csIGFn YWluIG5vIHJlYXNvbiB0byBuZWVkIGEgQkZGIGhlcmUuDQoNCldlIGRpZCBjb25zaWRlciBhZGRp bmcgc29tZXRoaW5nIHRvIHRoYXQgZWZmZWN0LCBhbiBlcnJvciBtZXNzYWdlIHRoYXQgY2FuIGRp cmVjdCB0aGUgZnJvbnRlbmQgdG8gcGVyZm9ybSB0aGUgaW50ZXJhY3RpdmUgcG9ydGlvbiBuZWNl c3NhcnkgZm9yIHRoaXMgdG9wb2xvZ3kgdG8gd29yay4gSXQgd291bGQgYmUgc29tZXRoaW5nIHNp bWlsYXIgdG8gdGhlIElEUCBpbml0aWF0ZWQgbG9naW4gaW4gT0lEQywgd2hlcmUgdGhlIGNsaWVu dCBvZmZlcnMgYW4gZW5kcG9pbnQgdGhhdCBpcyBndWFyYW50ZWVkIHRvIGluaXRpYXRlIGEgc2ln biBpbiBmbG93IChoZW5jZSBpbmplY3QgYWxsIHRoZSBuZWNlc3Nhcnkgbm9uY2VzIGV0YykuIFdl IGRpZG7igJl0IGFkZCBpdCB1cGZyb250IGFuZCBsZWZ0IGl0IGFzIGV4ZXJjaXNlIGZvciB0aGUg cmVhZGVyIG1vc3RseSBiZWNhdXNlIGl04oCZcyBub3QgZWFzeSB0byBtb2RlbCBwcm9wZXJseSBh bmQgYmVmb3JlIG9wZW5pbmcgdGhhdCB3b3JrIGZyb250IHdlIHdhbnRlZCB0byBzZWUgaG93IHRo ZSBpZGVhIHdhcyByZWNlaXZlZC4NCkl0IG1heSBtYWtlIHNlbnNlIGZvciB0aGUgYXBwIHRvIGhh dmUgYW4gZXJyb3IgbWVzc2FnZSwgb3IgZXZlbiBiZXR0ZXIgbWlnaHQgYmUgYSAzMDIgTG9jYXRp b24gaGVhZGVyIGRlcGVuZGluZyBvbiB3aGF0IHlvdSBhcmUgZG9pbmcuIFRoZXJlIGlzIG5vdGhp bmcgaGVyZSB0aGF0IGlzIE9BdXRoIHNwZWNpZmljIGhvd2V2ZXIgKG5vciBjb21tb24pLCBhbmQg dGhlbiB3ZSBzaG91bGQgY2hhbGxlbmdlIHRoZSBuZWVkIHRvIGRpcmVjdGx5IHByb3ZpZGUgYW4g UkZDIHJlY29tbWVuZGF0aW9uIGZvciBoYW5kbGluZyB0aGlzLg0KDQoNCkVycm9yISBGaWxlbmFt ZSBub3Qgc3BlY2lmaWVkLg0KDQpXYXJyZW4gUGFyYWQNCg0KRm91bmRlciwgQ1RPDQpTZWN1cmUg eW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlvbiBhcmNoaXRlY3R1 cmUuIEltcGxlbWVudCBBdXRocmVzczxodHRwczovL2F1dGhyZXNzLmlvPi4NCg0KDQpPbiBTdW4s IEZlYiAxNCwgMjAyMSBhdCAxMjoyOSBQTSBWaXR0b3JpbyBCZXJ0b2NjaSA8dml0dG9yaW8uYmVy dG9jY2k9NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwYXV0aDAuY29tQGRtYXJj LmlldGYub3JnPj4gd3JvdGU6DQpIaSBOZWlsLA0KVGhhbmtzIGZvciB0aGUgcHJvbXB0IGNvbW1l bnRzIQ0KDQogICogICBSZTogR0VUIHZzIFBPU1QsDQpwZXJzb25hbGx5IEnigJlkIGJlIGZpbmUg d2l0aCByZXN0cmljdGluZyB0byBQT1NULg0KDQoNCiAgKiAgIFJlOiBSTy1BUywgaW50ZXJhY3Rp b24tDQpwZXJoYXBzIGl0IGlzIG5vdCB2ZXJ5IGNsZWFyIGZyb20gdGhlIHRleHQgYXQgdGhlIG1v bWVudCAoZmlyc3QgZHJhZnQpLCBidXQgdGhhdCBpcyBhc3N1bWVkIHRoYXQgdGhlIFJPIHdlbnQg dGhydSB3aGF0ZXZlciBpbnRlcmFjdGl2ZSBzdGVwcyBhcmUgbmVjZXNzYXJ5IHRvIGVzdGFibGlz aCBhIHNlc3Npb24gKGVnIHNpZ24gaW4sIGFzc3VtaW5nIHRoZSBBUyBpcyBzYXkgYW4gT0lEQyBw cm92aWRlcikgYW5kIG9idGFpbiBiZWZvcmVoYW5kIHRoZSBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJl c2ggdG9rZW5zIHRoYXQgd2lsbCBiZSBuZWVkZWQgZHVyaW5nIHRoZSBhcHAgYWN0aXZpdGllcyB0 YWtpbmcgcGxhY2UgYWZ0ZXIgIHRoYXQuIEluIGNvbmNyZXRlIHRlcm1zLCBpbWFnaW5lIHRoYXQg dGhlIGJhY2tlbmQgcGVyZm9ybXMgYW4gYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50IHJlcXVlc3Rp bmcgYW4gSUR0b2tlbiwgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VuIEJFRk9SRSB0aGUg YWN0aXZpdGllcyBkZXNjcmliZWQgaW4gVE1JLUJGRiB0YWtlIHBsYWNlLg0KVGhlIGN1cnJlbnQg bGFuZ3VhZ2UgdHJ5aW5nIHRvIGV4cHJlc3MgdGhhdCBpcyBpbiAxLjI6DQpBcyBhIHByZXJlcXVp c2l0ZSBmb3IgdGhlIGZsb3cgZGVzY3JpYmVkIGJlbG93LCB0aGUgYmFja2VuZCBNVVNUIGhhdmUg ZXN0YWJsaXNoZWQgYSBzZWN1cmUgc2Vzc2lvbiB3aXRoIHRoZSB1c2VyIGFnZW50LCBzbyB0aGF0 IGFsbCByZXF1ZXN0cyBmcm9tIHRoYXQgdXNlciBhZ2VudCB0b3dhcmQgdGhlIGJhY2tlbmQgb2Nj dXIgb3ZlciBIVFRQUyBhbmQgY2FycnkgYSB2YWxpZCBzZXNzaW9uIGFydGlmYWN0IChzdWNoIGFz IGEgY29va2llKSB0aGF0IHRoZSBiYWNrZW5kIGNhbiB2YWxpZGF0ZS4gVGhpcyBkb2N1bWVudCBk b2VzIG5vdCBtYW5kYXRlIGFueSBzcGVjaWZpYyBtZWNoYW5pc20gdG8gZXN0YWJsaXNoIGFuZCBt YWludGFpbiB0aGF0IHNlc3Npb24uDQpBbmQNCmNhY2hlZCwgaXQgcmVxdWVzdHMgdG8gdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGEgbmV3IGFjY2VzcyB0b2tlbiB3aXRoIHRoZSByZXF1aXJlZCBj aGFyYWN0ZXJpc3RpY3MsIHVzaW5nIGFueSBhcnRpZmFjdHMgcHJldmlvdXN5IG9idGFpbmVkIChl ZyByZWZyZXNoIHRva2VuKSBhbmQgZ3JhbnRzIHRoYXQgd2lsbCBhbGxvdyB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdG8gaXNzdWUgdGhlIHJlcXVlc3RlZCB0b2tlbiB3aXRob3V0IHJlcXVpcmlu ZyB1c2VyIGludGVyYWN0aW9uLg0KDQoNCiAgKiAgICBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5 IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVuIGNvdWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1 c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlzc3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250 ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3IgQVBJIGFjY2Vzcz8NCkZvciB0aGUgdHJ1c3RlZCBwYXJ0 LCBzZWUgYWJvdmUuIEZvciB0aGUgc2hvcnQgbGl2ZWQgSldUcywgdGhhdOKAmXMgbm90IHJlYWxs eSBhbiBvcHRpb24uIFRoZSBtb3N0IGdlbmVyaWMgc2NlbmFyaW8gYWRkcmVzc2VkIGhlcmUgaXMg Zm9yIEFQSXMgdGhhdCBhY2NlcHQgdG9rZW5zIGlzc3VlZCBieSB0aGUgQVM7IHRoZSBiYWNrZW5k IGNhbiByZXF1ZXN0IHRoZW0gYXMgYSBjbGllbnQsIGJ1dCBpdCBjYW5ub3QgbWludCB0aGVtLiBJ bWFnaW5lIHdl4oCZcmUgdGFsa2luZyBhYm91dCBhIFNQQSBhcHBsaWNhdGlvbiB0aGF0IHNpZ25z IGluIHVzZXJzIHVzaW5nIEF6dXJlIEFELCBhbmQgbmVlZHMgdG8gY2FsbCBPZmZpY2UgYW5kIEF6 dXJlIEFQSXMuIFRoZSBTUEEgYmFja2VuZCBjYW5ub3QgaXNzdWUgdG9rZW5zIGZvciB0aG9zZSBB UElzLCBpdCBjYW4gb25seSByZXF1ZXN0IHRoZW0gdG8gdGhlIEF6dXJlIEFEIEFTLg0KDQoNCiAg KiAgIElmIHlvdSB3YW50IHRvIGFsbG93IGF1dGggY29kZSBmbG93IGV0YyB0aGVuIHBlcmhhcHMg dGhlIGJmZi10b2tlbiBlbmRwb2ludCBjYW4gcmV0dXJuIGEgc3RhbmRhcmQgZXJyb3IgY29kZSB3 aXRoIGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgVVJJIHRoYXQgdGhlIFNQQSB0aGVuIG5hdmln YXRlcyB0aGUgdXNlciB0by4gKEVnIHRoZSBiYWNrZW5kIGNhbiBkbyBhIFBBUiByZXF1ZXN0IGZp cnN0IGFuZCByZXR1cm4gYSBVUkkgdGhhdCByZWZlcmVuY2VzIHRoYXQgc28gdGhhdCBhdXRob3Jp emF0aW9uIGRldGFpbHMgYXJlbuKAmXQgcGFzc2VkIHRocm91Z2ggdGhlIGZyb250ZW5kKS4NCldl IGRpZCBjb25zaWRlciBhZGRpbmcgc29tZXRoaW5nIHRvIHRoYXQgZWZmZWN0LCBhbiBlcnJvciBt ZXNzYWdlIHRoYXQgY2FuIGRpcmVjdCB0aGUgZnJvbnRlbmQgdG8gcGVyZm9ybSB0aGUgaW50ZXJh Y3RpdmUgcG9ydGlvbiBuZWNlc3NhcnkgZm9yIHRoaXMgdG9wb2xvZ3kgdG8gd29yay4gSXQgd291 bGQgYmUgc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIElEUCBpbml0aWF0ZWQgbG9naW4gaW4gT0lE Qywgd2hlcmUgdGhlIGNsaWVudCBvZmZlcnMgYW4gZW5kcG9pbnQgdGhhdCBpcyBndWFyYW50ZWVk IHRvIGluaXRpYXRlIGEgc2lnbiBpbiBmbG93IChoZW5jZSBpbmplY3QgYWxsIHRoZSBuZWNlc3Nh cnkgbm9uY2VzIGV0YykuIFdlIGRpZG7igJl0IGFkZCBpdCB1cGZyb250IGFuZCBsZWZ0IGl0IGFz IGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIG1vc3RseSBiZWNhdXNlIGl04oCZcyBub3QgZWFzeSB0 byBtb2RlbCBwcm9wZXJseSBhbmQgYmVmb3JlIG9wZW5pbmcgdGhhdCB3b3JrIGZyb250IHdlIHdh bnRlZCB0byBzZWUgaG93IHRoZSBpZGVhIHdhcyByZWNlaXZlZC4NCg0KRnJvbTogT0F1dGggPG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgTmVpbCBNYWRkZW4gPG5laWwubWFkZGVuQGZvcmdlcm9jay5jb208bWFpbHRvOm5l aWwubWFkZGVuQGZvcmdlcm9jay5jb20+Pg0KRGF0ZTogU3VuZGF5LCBGZWJydWFyeSAxNCwgMjAy MSBhdCAwMDoxNw0KVG86IFZpdHRvcmlvIEJlcnRvY2NpIDx2aXR0b3Jpby5iZXJ0b2NjaT00MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc+ Pg0KQ2M6ICJvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFRv a2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVu ZCAoVE1JIEJGRikNCg0KSSBoYXZlIGEgbG90IG9mIHNlY3VyaXR5IGNvbmNlcm5zIGFib3V0IHRo aXMgZHJhZnQuDQoNClRoZSBkcmFmdCBhbGx1ZGVzIHRvIHNlY3VyaXR5IGlzc3VlcyBhc3NvY2lh dGVkIHdpdGggaGFuZGxpbmcgYWNjZXNzIHRva2VucyBpbiB0aGUgZnJvbnRlbmQgYnV0IG5ldmVy IHJlYWxseSBzcGVsbHMgdGhlbSBvdXQuIEZyb20gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IGl0IHNlZW1zIHRoYXQgdGhlIHByaW1hcnkgY29uY2VybiBpcyB3aXRoIHRoZWZ0IG9mIGFjY2Vz cyB0b2tlbnMgZnJvbSBsb2NhbCBzdG9yYWdlLiBUbyBkbyB0aGlzIHlvdeKAmWQgbmVlZCBhbiBY U1MgYXR0YWNrLiBCdXQgaW4gdGhhdCBjYXNlLCB3b3VsZG7igJl0IHRoZSBhdHRhY2tlciBzaW1w bHkgdXNlIHRoZSBYU1MgdG8gbWFrZSBhIGNhbGwgdG8gdGhlIGJmZi10b2tlbiBlbmRwb2ludCBp bnN0ZWFkPw0KDQpUaGUgY29tYmluYXRpb24gb2YgdGhlIGJmZi10b2tlbiBlbmRwb2ludCByZWNv bW1lbmRpbmcgdGhlIHVzZSBvZiBHRVQgcmVxdWVzdHMgdG9nZXRoZXIgd2l0aCB0aGUgaGludCB0 byB1c2UgY29va2llLWJhc2VkIGF1dGhlbnRpY2F0aW9uIGlzIGxpa2VseSBnb2luZyB0byBwdW5j aCBhIGhvbGUgaW4gbW9zdCBDU1JGIGRlZmVuc2VzLCB3aGljaCBhc3N1bWUgdGhhdCBHRVRzIGFy ZSBzYWZlLiBUaGUgb25seSB0aGluZyBwcmV2ZW50aW5nIHRoaXMgYmVpbmcgZXhwbG9pdGFibGUg aXMgQ3Jvc3MtT3JpZ2luIFJlYWQgQmxvY2tpbmcgKGh0dHBzOi8vY2hyb21pdW0uZ29vZ2xlc291 cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19vcmln aW5fcmVhZF9ibG9ja2luZ19leHBsYWluZXIubWQpIGR1ZSB0byB0aGUgSlNPTiBjb250ZW50LXR5 cGUuIFRoYXQgbWFrZXMgbWUgcmVhbGx5IG5lcnZvdXMuIFdlIHNob3VsZCBhdCBsZWFzdCBtYW5k YXRlIFgtQ29udGVudC1UeXBlLU9wdGlvbnM6IG5vc25pZmYgb24gdGhhdCByZXNwb25zZS4gSeKA mWQgZmVlbCBtb3JlIGNvbWZvcnRhYmxlIGlmIHRoaXMgd2FzIGEgUE9TVCByZXF1ZXN0IG9ubHku DQoNCkFzIFN0b3ljaG8gU2xlcHRzb3YgbWVudGlvbmVkIGluIHRoZSBvdGhlciBlbWFpbCwgdGhl IGxhY2sgb2YgZnJvbnQtY2hhbm5lbCBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0 aGUgUk8gc2VlbXMgb2RkLiBJZiB0aGUgYmFja2VuZCBpcyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1 c3RlZCB0aGVuIGNvdWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1c3QgZ2V0IHRoZSBiYWNr ZW5kIHRvIGlzc3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250ZW5kIHRoYXQgaXQgY2Fu IHVzZSBmb3IgQVBJIGFjY2Vzcz8NCg0KSWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZs b3cgZXRjIHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBz dGFuZGFyZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhh dCB0aGUgU1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2Fu IGRvIGEgUEFSIHJlcXVlc3QgZmlyc3QgYW5kIHJldHVybiBhIFVSSSB0aGF0IHJlZmVyZW5jZXMg dGhhdCBzbyB0aGF0IGF1dGhvcml6YXRpb24gZGV0YWlscyBhcmVu4oCZdCBwYXNzZWQgdGhyb3Vn aCB0aGUgZnJvbnRlbmQpLg0KDQrigJQgTmVpbA0KDQoNCk9uIDEyIEZlYiAyMDIxLCBhdCAyMDo0 NiwgVml0dG9yaW8gQmVydG9jY2kgPHZpdHRvcmlvLmJlcnRvY2NpPTQwYXV0aDAuY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K77u/ RGVhciBhbGwsDQpCcmlhbiBhbmQgeW91cnMgdHJ1bHkgYXJlIHByb3Bvc2luZyBhIG5ldyBzcGVj aWZpY2F0aW9uIHRoYXQgc2hvd3MgaG93IHRoZSB1c2VyIGFnZW50IGZyb250ZW5kIG9mIGEgd2Vi IGFwcCBjYW4gZGVsZWdhdGUgdG9rZW4gYWNxdWlzaXRpb24gYW5kIHBlcnNpc3RlbmNlIHRvIGl0 cyBiYWNrZW5kLCBhbmQgcmVxdWVzdCBzdWNoIHRva2VucyB3aGVuIG5lZWRlZCBmb3IgZGlyZWN0 IGFjY2VzcyBvZiBwcm90ZWN0ZWQgcmVzb3VyY2VzIGZyb20gdGhlIGZyb250ZW5kIGNvZGUuDQoN ClRoZSBwYXR0ZXJuIGlzIGFscmVhZHkgaW4gdXNlLCBpbiBwcm9wcmlldGFyeSBmb3JtLCBieSB2 YXJpb3VzIG1vZGVybiBkZXZlbG9wbWVudCBzdGFja3MsIHN1Y2ggYXMgTmV4dC5KUy4gVmFyaWFu dHMgb2YgdGhlIHBhdHRlcm4sIG9mdGVuIGRpc2N1c3NlZCB1bmRlciB0aGUgY2F0Y2gtYWxsIHRl cm0gQkZGIChiYWNrZW5kIGZvciBmcm9udGVuZCksIGhhdmUgYmVlbiBvZnRlbiBtZW50aW9uZWQg aW4gdGhpcyB3b3JrZ3JvdXDigJlzIGFjdGl2aXR5LCBidXQgYWx3YXlzIGxlZnQgYWxsIGltcGxl bWVudGF0aW9uIGRldGFpbHMgdG8gdGhlIHJlYWRlci4NCldlIGJlbGlldmUgdGhlIHBhdHRlcm4g aGFzIG1lcml0LCBhcyBjb3Jyb2JvcmF0ZWQgYnkgaXRzIGdyb3dpbmcgYWRvcHRpb24uIEJ5IGRl bGVnYXRpbmcgYWNjZXNzIHRva2VuIGFjcXVpc2l0aW9uIHRvIHRoZSBiYWNrZW5kLCB3ZSBhdm9p ZCBtYW55IG9mIHRoZSBvZnRlbiBicml0dGxlIG1vdmluZyBwYXJ0cyAoYW5kIGltcGxpZWQgYXR0 YWNrIHN1cmZhY2UpIHJlcXVpcmVkIHRvIGFjcXVpcmUgYWNjZXNzIHRva2VucyBmcm9tIGEgdXNl ciBhZ2VudC4gVGhlIHRvcG9sb2d5IGFsc28gcmVsaWV2ZXMgdGhlIGZyb250ZW5kIGZyb20gdGhl IG5lZWQgb2YgcGVyc2lzdGluZyB0b2tlbnMgaW4gbG9jYWwgc3RvcmFnZSwgYSB3ZWxsIGtub3du IHNvcmUgcG9pbnQgb2YgdXNpbmcgT0F1dGggZGlyZWN0bHkgaW4gSmF2YVNjcmlwdCwgYnkgcmVs eWluZyBvbiBpdHMgYmFja2VuZCBzdG9yYWdlIGFuZCBzZXNzaW9uIHRvIHByZXNlcnZlIHRva2Vu cy4NCg0KQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gaXMgdmVyeSBzaW1wbGUsIHByb3ZpZGlu ZyBleHBsaWNpdCBndWlkYW5jZSBvbiB0aGUgc2NlbmFyaW8gb2ZmZXJzIG1hbnkgYWR2YW50YWdl cy4NCi0gSXQgbWFrZXMgaXQgcG9zc2libGUgdG8gY3JlYXRlIGludGVyb3BlcmFibGUgU0RLcywg d2hlcmUgZnJvbnRlbmQgZGV2IHN0YWNrcyAoYW55IEpTIGZsYXZvcikgY2FuIGJlIG1peGVkIGFu ZCBtYXRjaGVkIHdpdGggY29tcGxpYW50IGJhY2tlbmQgc3RhY2tzIChtaWRkbGV3YXJlcyBpbiBu b2RlLCBqYXZhLCBBU1AuTkVUPGh0dHA6Ly9BU1AuTkVUPiwgUEhQIGV0YykNCi0gSXQgYWxsb3dz IHVzIHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIHByb3Blcmx5IHRhY2tsZSB0aGUgc2Nl bmFyaW8gYW5kIHdhcm4gaW1wbGVtZW50ZXJzIGFnYWluc3Qgc2VjdXJpdHkgcmlza3MgKHNjb3Bl IGVzY2FsYXRpb25zLCB1c2luZyBJRHRva2VucyBpbnN0ZWFkIG9mIGFjY2VzcyB0b2tlbnMsIGV0 YykNCi0gSXQgYWxsb3dzIHVzIHRvIGRpc2N1c3MgKGFuZCB3aGVuIGFwcHJvcHJpYXRlLCBwcm9t b3RlKSB0aGlzIHBhdHRlcm4gYXMgcGFydCBvZiB0aGUgYnJvd3NlciBhcHBzIHNlY3VyaXR5IGd1 aWRhbmNlLCBhbmQgcG9zaXRpb24gdGhlIHNjZW5hcmlvIHdoZXJlIGZyb250ZW5kIG9ubHkgY2Fs bHMgQVBJIG9uIGl0cyBvd24gYmFja2VkIChoZW5jZSBkb2VzbuKAmXQgbmVlZCBhY2Nlc3MgdG9r ZW5zKSBzaW1wbHkgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhpcyBtb3JlIGdlbmVyYWwgcGF0dGVy bg0KLSBUaGlzIGFwcHJvYWNoIG1ha2VzIG1vY2tpbmcgYW5kIHRlc3RpbmcgYXBwcyB2ZXJ5IGVh c3ksIHBvc3NpYmx5IHByZXZlbnRpbmcgZGV2ZWxvcGVycyBmcm9tIHdlYWtlbmluZyB0aGUgc2Vj dXJpdHkgb2YgdGhlaXIgc3lzdGVtIChlZyB0dXJuaW5nIG9uIFJPUEcgb3B0aW9ucykgIG9yIHR1 cm5pbmcgdG8gcmlza3kgcHJhY3RpY2VzIGxpa2Ugc2NyYXBpbmcNCg0KTmVlZGxlc3MgdG8gc2F5 LCB0aGlzIHNwZWNpZmljYXRpb24gZG9lc27igJl0IGVudGlyZWx5IGVsaW1pbmF0ZSB0aGUgcmlz a3MgaW5oZXJlbnQgdG8gZGlyZWN0IHVzZSBvZiBhY2Nlc3MgdG9rZW5zIGZyb20gYSBicm93c2Vy LiBCdXQgcmVhbGl0eSBpcyB0aGF0IHRoZSBwYXR0ZXJuIGlzIGluIHdpZGVzcHJlYWQgdXNlLCBh bmQgdGhlIGNpcmN1bXN0YW5jZXMgbGVhZGluZyB0byB0aGF0IChlZyBkZXZlbG9wZXJzIG9uIGEg cGFydGljdWxhciBwcm9qZWN0IG9ubHkgd29yayB3aXRoIGZyb250ZW5kIHN0YWNrczsgY29tcG9u ZW50cyBsaWtlIHJldmVyc2UgcHJveGllcyBtaWdodCBub3QgYWx3YXlzIGJlIHZpYWJsZTsgZXRj KSBhcmVu4oCZdCBnb2luZyBhd2F5IGFueSB0aW1lIHNvb24uIEJ5IHByb3ZpZGluZyBzaW1wbGUg Z3VpZGFuY2Ugb24gdGhpcyBwYXR0ZXJuLCB3ZSBjYW4gc2ltcGxpZnkgdGhlIGxpZmUgb2YgbWFu eSBkZXZlbG9wZXJzIHdoaWxlIGVuc2hyaW5pbmcgYmFzaWMgc2VjdXJpdHkgaHlnaWVuZSBpbiBz Y2VuYXJpb3MgdGhhdCB3b3VsZCBoYXZlIG90aGVyd2lzZSBiZSBsZWZ0IHRvIHRoZWlyIG93biBk ZXZpY2UuDQoNCkxvb2tpbmcgZm9yd2FyZCBmb3IgeW91ciBmZWVkYmFjayENCg0KQiZWDQoNCu+7 v09uIDIvMTIvMjEsIDEyOjQxLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+IiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQogICBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmYtMDAudHh0DQogICBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZpdHRvcmlvIEJlcnRvY2NpIGFuZCBwb3N0ZWQgdG8g dGhlDQogICBJRVRGIHJlcG9zaXRvcnkuDQoNCiAgIE5hbWU6ICAgICAgICBkcmFmdC1iZXJ0b2Nj aS1vYXV0aDItdG1pLWJmZg0KICAgUmV2aXNpb246ICAgIDAwDQogICBUaXRsZTogICAgICAgIFRv a2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVu ZA0KICAgRG9jdW1lbnQgZGF0ZTogICAgMjAyMS0wMi0xMg0KICAgR3JvdXA6ICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCiAgIFBhZ2VzOiAgICAgICAgMTYNCiAgIFVSTDogICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10 bWktYmZmLTAwLnR4dA0KICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLw0KICAgSHRtbDogICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYmVydG9jY2ktb2F1dGgy LXRtaS1iZmYtMDAuaHRtbA0KICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMA0KDQoNCiAgIEFic3RyYWN0 Og0KICAgICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IGEgSmF2YVNjcmlwdCBmcm9udGVu ZCBjYW4gZGVsZWdhdGUgYWNjZXNzDQogICAgICB0b2tlbiBhY3F1aXNpdGlvbiB0byBhIGJhY2tl bmQgY29tcG9uZW50LiAgSW4gc28gZG9pbmcsIHRoZSBmcm9udGVuZA0KICAgICAgY2FuIGFjY2Vz cyByZXNvdXJjZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBidXJkZW4g b2YNCiAgICAgIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHBl cnNpc3RpbmcgdG9rZW5zLCBhbmQNCiAgICAgIHBlcmZvcm1pbmcgb3BlcmF0aW9ucyB0aGF0IGFy ZSBmcmF1Z2h0IHdpdGggc2VjdXJpdHkgY2hhbGxlbmdlcyB3aGVuDQogICAgICBleGVjdXRlZCBp biBhIHVzZXIgYWdlbnQsIGJ1dCBhcmUgc2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRl ZA0KICAgICAgYnkgYSBjb25maWRlbnRpYWwgY2xpZW50IHJ1bm5pbmcgb24gYSBiYWNrZW5kLg0K DQoNCg0KDQogICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29s cy5pZXRmLm9yZz4uDQoNCiAgIFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCkZvcmdlUm9jayB2YWx1ZXMgeW91ciBQcml2 YWN5PGh0dHBzOi8vd3d3LmZvcmdlcm9jay5jb20veW91ci1wcml2YWN5Pg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_CO6PR18MB4052D4D091965B34B1DACD35AE899CO6PR18MB4052namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTm90byBTYW5zIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDUgNCAyIDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1h bDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuZ21haWwtbS0z MzA4NTY0NjA2MTc1MDYxMzA3bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbS0zMzA4NTY0NjA2 MTc1MDYxMzA3bXNvbGlzdHBhcmFncmFwaCwgZGl2LmdtYWlsLW0tMzMwODU2NDYwNjE3NTA2MTMw N21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tMzMwODU2NDYwNjE3 NTA2MTMwN21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLmdtYWlsLW0tMzMwODU2NDYwNjE3NTA2MTMwN2dtYWlsLW0tNjQ3NTI2NjExNjA1 Nzk2Njg0N2dtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdt YWlsLW0tMzMwODU2NDYwNjE3NTA2MTMwN2dtYWlsLW0tNjQ3NTI2NjExNjA1Nzk2Njg0N2dtYWls LW0tODk2ODcwNTYzNDk4NjQ4MzA2NW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tLTMzMDg1 NjQ2MDYxNzUwNjEzMDdnbWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2 MzQ5ODY0ODMwNjVtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTMz MDg1NjQ2MDYxNzUwNjEzMDdnbWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3 MDU2MzQ5ODY0ODMwNjVtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tLTMzMDg1NjQ2MDYxNzUwNjEzMDdnbWFpbC1tLTY0NzUy NjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5 MjE0NDM5OTc5NDltc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tLTMzMDg1NjQ2MDYxNzUwNjEz MDdnbWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVn bWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbS0z MzA4NTY0NjA2MTc1MDYxMzA3Z21haWwtbS02NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4 NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYzNTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBhcmFncmFw aA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy0zMzA4NTY0NjA2MTc1MDYxMzA3Z21haWwtbS02 NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYz NTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtbS0zMzA4NTY0NjA2MTc1MDYxMzA3Z21haWwtbS02 NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYz NTM2OTIxNDQzOTk3OTQ5YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmdt YWlsLW1fLTMzMDg1NjQ2MDYxNzUwNjEzMDdnbWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFp bC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1tLTUxNjM1MzY5MjE0NDM5OTc5NDlhcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoxNjM2NjQyNjU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjYxOTE5MzM2MCAtODE1NDc4MDQ0IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NTsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6MjczNTY0MjY1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODE1OTUzMzQ7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo1OTYyMDcwMDc7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xOTMzMDMxOTc0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6 OTU3MDk5OTY3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzMyMjg4MTkyO30NCkBsaXN0IGwz OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTgwNDkyOTM2NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MjgyNzczMTg0O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTg4MTgyMzc1 MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NTI0MTgwNzA7fQ0KQGxpc3QgbDU6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs Ng0KCXttc28tbGlzdC1pZDoyMDA1NjIyODcwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0MjMz OTczOTI7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzciPkRyYWZ0IFsu Ll0gZXNzZW50aWFsbHkgc3VnZ2VzdHMgdGhhdCBldmVyeSBhcHAgbmVlZHMgdG8gcnVuIGEgQkZG IHRvIGRvIHVzZXIgdG9rZW4gZ2VuZXJhdGlvbiBiZWNhdXNlIGFuIEFTIGlzIG5vIGxvbmdlciBh ZmZvcmRlZCB0aGUgY2FwYWJpbGl0eSBmb3Igc29tZSByZWFzb248bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2ZSB0aGlzIG1pZ2h0IGJlIHRoZSBjcnV4 IG9mIHRoZSBwcm9ibGVtLCBteSBpbXByZXNzaW9uIGlzIHRoYXQgeW91IGFyZSBhdHRyaWJ1dGlu ZyB0byB0aGUgZHJhZnQgYSB3YXkgbGFyZ2VyIHNjb3BlIHRoYW4gaXQgaXMgaW50ZW5kZWQgdG8g aGF2ZS4gVGhlIGRyYWZ0IG1ha2VzIG5vIHN1Y2ggc3VnZ2VzdGlvbi4gVGhlIGRyYWZ0IHNheXMg bm90aGluZyBhYm91dCBBUyBsb3NpbmcgY2FwYWJpbGl0aWVzLg0KIFRoZSBkcmFmdCBpcyBub3Qg dHJ5aW5nIHRvIHNvbHZlIGFuIEFTIHByb2JsZW0uIEFuZCBhYm92ZSBhbGwsIHRoZSBkcmFmdCBk b2VzIG5vdCB0YXJnZXQNCjxiPmV2ZXJ5IGFwcDwvYj4uIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgZHJhZnQgaXMgYW4gb3B0aW1pemF0aW9uIGFpbWVkIGF0IDxiPmEgdmVyeSBzcGVjaWZp YzwvYj4sIGFsYmVpdCB2ZXJ5IGNvbW1vbiwgYXBwbGljYXRpb24gdG9wb2xvZ3kgd2hlcmUgdGhl cmUgaXMgYSBmcm9udGVuZCBhbmQgYSBiYWNrZW5kLCBhbmQgdGhlIGRldmVsb3BlciB3YW50cyB0 byBwZXJmb3JtIEFQSSBjYWxscyBmcm9tIHRoZSBmcm9udGVuZCBkaXJlY3RseSB0byB0aGUgUlMu IFRoaXMgaXMgb25seQ0KIGEgc3BlY2lmaWMgdG9wb2xvZ3ksIGFuZCB0aGUgcHJvcG9zYWwgaXMg c2NvcGVkIGRvd24gdG8gdGhhdC4gQWxsIG90aGVyIHRvcG9sb2dpZXMgYXJlIHVuYWZmZWN0ZWQu IEFsc28sIHRoZSBkcmFmdCBpc27igJl0IHB1c2hpbmcgdGhpcyB0b3BvbG9neSBhcyB0aGUgcHJl ZmVycmVkIG9uZS4gSXTigJlzIGJlc3QgdG8ga2VlcCB0b2tlbnMgb3V0IG9mIHRoZSBmcm9udGVu ZCBhbHRvZ2V0aGVyLiBCdXQgaWYgdGhlIGRldmVsb3BlciBpcyBhZGFtYW50IGluDQogcGVyZm9y bWluZyBBUEkgY2FsbHMgZGlyZWN0IGZyb20gdGhlaXIgSlMsIGFuZCBpZiB0aGV5IGFscmVhZHkg aGF2ZSBhIGJhY2tlbmQsIDxiPg0KYW5kIG9ubHkgaW4gdGhhdCBjYXNlPC9iPiwgdGhlIGN1cnJl bnQgcHJvcG9zYWwgaGFzIGxlc3MgbW92aW5nIHBhcnRzIGFuZCBsZXNzIHJlcXVpcmVtZW50cyB0 aGFuIGNvZGUrUEtDRSAuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29kZStQS0NFIGFscmVh ZHkgaGFzIHRoZSBleHByZXNzaXZlIHBvd2VyIHRvIGhhbmRsZSB0aGUgc2NlbmFyaW8gZGVzY3Jp YmVkIGhlcmUsIGFuZCBpcyBhcHBsaWNhYmxlIHRvIGEgd2lkZXIgcmFuZ2Ugb2Ygc2NlbmFyaW9z LiBUaGUgbWFpbiBwb2ludCB0aGUgZHJhZnQgYnJpbmdzIHRvIHRoZSB0YWJsZSBpcyB0aGUgYWJp bGl0eSBmb3IgYSBmcm9udGVuZCB0byBkZWxlZ2F0ZSB0byBhIGJhY2tlbmQgYSBsb3QNCiBvZiBs b2dpYyB0aGF0IGluIHRoZSBjb2RlK1BLQ0UgY2FzZSBleGVjdXRlcyBpbiBhbiBlbnZpcm9ubWVu dCB0aGF0IGlzIG5hdHVyYWxseSBtb3JlIGNvbnN0cmFpbmVkIGFuZCBwcm9uZSB0byBhdHRhY2tz IHRoYW4gYSBiYWNrZW5kLiBUaGF0IGRvZXNu4oCZdCBtZWFuIGRldmVsb3BlcnMgd2hvc2UgYXBw IGhhcyBhIGJhY2tlbmQgc2hvdWxkIGF1dG9tYXRpY2FsbHkgY2hvb3NlIHRoZSBuZXcgbW9kZWwg b3ZlciBjb2RlK1BLQ0UsIG1vcmUgdGhhdA0KIHRoZSBtb2RlbCBkaXNjdXNzZWQgaGVyZSBtaWdo dCBiZSB2aWFibGUgYW5kIHJlcXVpcmUgbGVzcyBjYXBhYmlsaXRpZXMvbW92aW5nIHBhcnRzIHRv IGFjaGlldmUgdGhlIHNhbWUgZXhwcmVzc2l2ZSBwb3dlciwgZXNwZWNpYWxseSBpZiB0aGUgU0RL cyB1c2VkIGluIHRoZSBzb2x1dGlvbiBoYXZlIGEgc3RhbmRhcmQgd2F5IHRvIGhhbmRsZSBpdC4g VGhhdCBpcyBmYXIgZnJvbSBldmVyeSBhcHAsIGJ1dCBpdCBpcyBhIHNpdHVhdGlvbiBJIGVuY291 bnRlcmVkDQogaW4gdGhlIHdpbGQgb2Z0ZW4gZW5vdWdoIHRvIHByb21wdCB0aGUgZGlzY3Vzc2lv biB3aXRoIEJyaWFuIGFuZCB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGEg c2lkZSBub3RlLCB0aGUgaW5pdGlhbCByZWFjdGlvbnMgb2YgcHJhY3RpdGlvbmVycyBoYXZlIGJl ZW4gdmVyeSBwb3NpdGl2ZS4gSSBhbSByZWFsbHkgaG9waW5nIHRoZSBkaXNjdXNzaW9uIHdpbGwg bGVhZCB0byBpZGVudGlmeWluZyBhbmQgd2VlZGluZyBvdXQgc2VjdXJpdHkgaXNzdWVzLCBvciBs YW5kIG9uIHNlY3VyaXR5IGZsYXdzIGluIHRoZSBtb2RlbCBzbyBncmF2ZSB0aGF0IHRoZXkgY2Fu IGJlDQogcHJvcGVybHkgdXNlZCB0byBkaXNjb3VyYWdlIGl0cyB1c2UuIE5vIG1hdHRlciB3aGF0 IHdheSBpdCB3aWxsIGdvLCBJIGFtIHZlcnkgZ2xhZCB0aGUgZGlzY3Vzc2lvbiBpcyB0YWtpbmcg cGxhY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5XYXJyZW4g UGFyYWQgJmx0O3dwYXJhZD00MHJob3N5cy5jaEBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAxMjo1OTxicj4NCjxiPlRvOiA8 L2I+Vml0dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPk5laWwgTWFkZGVuICZsdDtuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29t Jmd0OywgJnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBUb2tlbiBNZWRpYXRpbmcgYW5kIHNl c3Npb24gSW5mb3JtYXRpb24gQmFja2VuZCBGb3IgRnJvbnRlbmQgKFRNSSBCRkYpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRvIHJlc3RhdGUsIHRoZSBUTUktQkZGIHByb3Bvc2FsIGlzIG5vdCB0 cnlpbmcgdG8gZml4IGFueSBvZiB0aGF0Li4uIGl04oCZcyBkZWZpbml0ZWx5IG5vdCBhIHRvcCBs ZXZlbCBkcml2ZXIuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+R3JlYXQsIHRoZW4gd2UgYXJlIGJhY2sgdG86IHdoYXQgaXMgdGhlIHRv cCBsZXZlbCBkcml2ZXIuIEJlY2F1c2UsIHdoaWxlIEkgYXBwcmVjaWF0ZSB0aGUgY2lyY3Vtc3Rh bmNlcyBhcm91bmQgSVRQMi4xfiBhcyBJIGZ1bGx5IHVuZGVyc3RhbmQgaG93IGlkZW50aXR5IHBy b3ZpZGVycyBsaWtlIEF1dGgwIGFyZSB1c2luZyBpZnJhbWVzIGFuZCB0aGlyZHBhcnR5Jm5ic3A7 Y29va2llcywgdGhpcyBwcm9ibGVtIHZhbmlzaGVzDQogd2l0aCB0aGUgdXNlIG9mIGZpcnN0LXBh cnR5IGRvbWFpbnMuIFNvIGxldCdzIHNraXAgdGhlIGRpZ3Jlc3Npb24gYW5kIGFzc3VtZSB3ZSBh cmVuJ3Qgc29sdmluZyBJVFAgZnV0dXJlIHJlbGF0ZWQgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVhbCBwcm9ibGVtIEkg aGF2ZSB3aXRoIHRoZSBkcmFmdCBpcyB0aGF0IGl0IGVzc2VudGlhbGx5IHN1Z2dlc3RzIHRoYXQg ZXZlcnkgYXBwIG5lZWRzIHRvIHJ1biBhIEJGRiB0byBkbyB1c2VyIHRva2VuIGdlbmVyYXRpb24g YmVjYXVzZSBhbiBBUyBpcyBubyBsb25nZXIgYWZmb3JkZWQgdGhlIGNhcGFiaWxpdHkgZm9yIHNv bWUgcmVhc29uLiBJZiB3ZSBwdWxsIGluIGV4cGVjdGluZyB0byBzb2x2ZSBJVFANCiByZWxhdGVk IGlzc3VlcyB0aGVuIEkgdGhpbmsmbmJzcDt0aGF0IGp1c3RpZmljYXRpb24gaXMgaW4gcGxheSBh bmQgd2UgY2FuIHdvcmsgdG9nZXRoZXIgdG8gY29tZSB1cCB3aXRoIGEgc29sdXRpb24sIHJhdGhl ciB0aGFuIHN0YXJ0aW5nIHdpdGggdGhlIGN1cnJlbnQgZGVsZXRlcmlvdXMmbmJzcDtwcmV2YWxl bnQmbmJzcDtwYXR0ZXJuIG9uIHRoZSBpbnRlcm5ldCAod2hpY2ggaG9uZXN0bHkgaXMgdGhlIG1v c3QgcmlkaWN1bG91cyBwYXJhZGlnbSBJIGhhdmUgc2VlbikuDQogSWYgd2UgZG9uJ3QgYXNzdW1l IElUUCBpcyBhbiBpc3N1ZSwgdGhlbiBJIGZhaWwgdG8gc2VlIHRoZSBjb3JlIHByb2JsZW0gdGhh dCBleGlzdGluZyBBUyBoYXZlIChhcyB5b3UgcG9pbnRlZCBvdXQgY29kZStQS0NFIGFscmVhZHkg d29ya3MpIHdpdGhvdXQgdGhlIGZyb250IGNoYW5uZWwgb3IgYmFjayBjaGFubmVsIG5lZWRpbmcg cmVhbGx5IHRvIG1ha2UgYW55IGFkZGl0aW9uYWwgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhc3N1bWUgdGhlcmUgaXMgYSBm bGF3IGluIG15IHJlYXNvbmluZyBzb21ld2hlcmUsIHNvIHBsZWFzZSBoZWxwIG1lIGZpbmQgaXQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBXYXJyZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5n PSIwIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8 dGJvZHk+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUg MS4wcHQ7Ym9yZGVyLXJpZ2h0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo1LjBwdCA1LjBw dCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6 cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7Ym9y ZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzowaW4iPjxpbWcgd2lkdGg9IjE5OSIgaGVpZ2h0PSIzNCIgc3R5bGU9IndpZHRo OjIuMDcyOWluO2hlaWdodDouMzU0MWluIiBpZD0iX3gwMDAwX2kxMDI1IiBhbHQ9IkltYWdlIHJl bW92ZWQgYnkgc2VuZGVyLiIgZGF0YS1vdXRsb29rLXRyYWNlPSJGOjB8VDoxIiBzcmM9ImNpZDp+ V1JEMjEyLmpwZyI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1sZWZ0Om5v bmU7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRp diBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCB3aGl0ZSAx LjBwdDtib3JkZXItYm90dG9tOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRlcjpub25lO3BhZGRpbmc6 MGluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+V2FycmVuIFBhcmFkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCB3aGl0ZSAx LjBwdDtib3JkZXItdG9wOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2JvcmRlcjpub25lO3BhZGRpbmc6MGlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgRmViIDE0LCAyMDIxIGF0IDk6MjAgUE0gVml0 dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTxhIGhyZWY9Im1haWx0bzo0MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5MZXQgbWUgcmV3aW5kIGEgYml0IGhlcmUuIFRoaXMg d2FzIG5ldmVyIHByZXNlbnRlZCBhcyBkcml2aW5nIHVzZSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS0zMzA4NTY0NjA2MTc1MDYxMzA3bXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1zby1saXN0OmwzIGxldmVsMSBsZm8xIj4NCk5laWwgc3VnZ2VzdGVkIHRo YXQgdGhlIGJhY2tlbmQgY291bGQgc2ltcGx5IGdpdmUgc2hvcnQgbGl2ZWQgSlRXcyBmb3IgdGhl IGZyb250ZW50IHRvIGNhbGwgQVBJLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9ImdtYWlsLW0t MzMwODU2NDYwNjE3NTA2MTMwN21zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMyBs ZXZlbDEgbGZvMSI+DQpJIGNsYXJpZmllZCB0aGF0IHRoaXMgd291bGQgbm90IGJlIHZpYWJsZSBp biB0aGUgZ2VuZXJhbCBjYXNlIGFuZCBwcm92aWRlZCBhbiBleGFtcGxlIHNjZW5hcmlvIHdoZXJl IGJhY2tlbmQgaXNzdWVkIHNob3J0IGxpdmVkIHRva2VucyB3b3VsZCBub3QgaGF2ZSB3b3JrZWQ8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tLTMzMDg1NjQ2MDYxNzUwNjEzMDdtc29s aXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzEiPg0KWW91IGNvbW1l bnRlZCB0aGF0IHRoZSBmcm9udGVuZCBjYW4gb2J0YWluIEFTIHRva2VucyBmcm9tIEpTIGFuZCBt ZW50aW9uZWQgc2lsZW50IGF1dGhlbnRpY2F0aW9uLiBJIGNsYXJpZmllZCAob3IgdHJpZWQgdG8p IHRoYXQgdGhpcyBvZmZzaG9vdCBvZiB0aGUgZGlzY3Vzc2lvbiB3YXNu4oCZdCB0byBzYXkgdGhh dCB0aGVyZSBpcyBubyB2aWFibGUgd2F5IG9mIGRvaW5nIHRoZSBzY2VuYXJpbyBhbHJlYWR5LCBh bmQgYnkgdGhlIHdheSB1c2luZyBhbg0KIGlGcmFtZSB0byBkbyBzaWxlbnQgYXV0aGVudGljYXRp b24gaXMgbm93IHByb2JsZW1hdGljLiBBdCB0aGlzIHBvaW50IHdlIGFyZSBubyBsb25nZXIgZGlz Y3Vzc2luZyBUTUktQkZGLCBidXQgY3VycmVudCBhZmZhaXJzIGluIHRoZSBhdXRoZW50aWNhdGlv biB3b3JsZC4gVGhlIGZhY3QgdGhhdCB3ZSBhcmUgcHJvcG9zaW5nIFRNSS1CRkYgYW5kIHRoZSBm YWN0IHRoYXQgc2lsZW50IGF1dGhlbnRpY2F0aW9uIGlzIGxlc3MgYW5kIGxlc3MgdmlhYmxlDQog YXJlIGluZGVwZW5kZW50IGZhY3RzLCB0aGUgZm9ybWVyIGlzbuKAmXQgbWVhbnQgdG8gYmUgYSBz b2x1dGlvbiBmb3IgdGhlIGxhdHRlciAoaXTigJlzIGFscmVhZHkgYWRkcmVzc2VkIGJ5IHVzaW5n IFJUcyBpbiBjb2tlK1BLQ0UpPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0 IGNsYXJpZmllZC4gTm90IG9ubHkgd2UgZXhwZWN0IElUUCB0byBhZmZlY3Qgc2lsZW50IGF1dGhl bnRpY2F0aW9uLCBpdCBoYXMgYmVlbiBhZmZlY3RlZCBmb3IgdGhlIHBhc3QgeWVhciBhbmQgdGhh dCBoYXMgYmVlbiBvbmUgb2YgdGhlIHByaW1hcnkgYnVzaW5lc3MgZHJpdmVycyBmb3IgdGhlIHJh cGlkDQogYWRvcHRpb24gb2YgY29kZStQS0NFK1JUcyBpbiB0aGUgdXNlciBhZ2VudCwgYXMgY3Vz dG9tZXJzIHdpdGggcHVyZSBTUEFzIGZvdW5kIHRoZW1zZWx2ZXMgdW5hYmxlIHRvIHJlbmV3IHRv a2VucyB3aXRob3V0IHByb21wdGluZyBhcyB0aGVpciBhY2Nlc3MgdG8gY29va2llcyBpbiBmbG93 cyBkcml2ZW4gYnkgaWZyYW1lcyBiZWNhbWUgbGVzcyBhbmQgbGVzcyByZWxpYWJsZS4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGVuIElUUCB3YXMgaW50cm9kdWNl ZCB3ZSBwdXQgbWFueSBjb21wYW5pZXMgdG9nZXRoZXIgdG8gdHJ5IHRvIGdldCBBcHBsZSB0byBj aGFuZ2UgaXQgKHlvdSBjYW4gZmluZCB0aGUgZG9jIGluDQo8YSBocmVmPSJodHRwczovL2RvY3Mu Z29vZ2xlLmNvbS9kb2N1bWVudC9kLzFScy0tREZ6WmpfU2ZRanR6OG9IOURsTElJMHJhM3ZpTUVI cks3c0tzYWlVL2VkaXQjaGVhZGluZz1oLnAzbnZwNnhteHZ6ZiIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20vZG9jdW1lbnQvZC8xUnMtLURGelpqX1NmUWp0ejhvSDlE bExJSTByYTN2aU1FSHJLN3NLc2FpVS9lZGl0I2hlYWRpbmc9aC5wM252cDZ4bXh2emY8L2E+KSBi dXQgdGhleSBkaWRu4oCZdCBidWxnZSBhbmQgdWx0aW1hdGVseSB0aGUgaW50cm9kdWN0aW9uIG9m IFJUcyBpbiB1c2VyIGFnZW50IGNvZGUgKGFsYmVpdCB3aXRoIGV4dHJhIHJlc3RyaWN0aW9ucywg dGhlIG9uZSBJIG1lbnRpb25lZCBub3QgZXZlcnlvbmUNCiBpcyBmb2xsb3dpbmcpIG1hZGUgdGhl IHByb2JsZW0gbWFuYWdlYWJsZS4gV2UgaGF2ZSBhbiBpbml0aWF0aXZlIGNyb3NzIHdvcmtpbmcg Z3JvdXBzIChJRVRGLCBPSURDIGV0Yylmb3Igd29ya2luZyB3aXRoIGJyb3dzZXIgdmVuZG9ycyB0 byB0cnkgY29udGFpbmluZyBzaW1pbGFyIHJlZ3Jlc3Npb25zIGluIHRoZSBmdXR1cmUuIEZvciBh IHN1bW1hcnkgb2Ygc2ltaWxhciBwcm9ibGVtcyBzZWUNCjxhIGhyZWY9Imh0dHBzOi8vaWRlbnRp dmVyc2UuZ2FsbGVyeS52aWRlby9kZXRhaWwvdmlkZW8vNjE4NDQ0MzAzNzAwMS9icm93c2VyLWZl YXR1cmVzLXZzLWlkZW50aXR5LXByb3RvY29scyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9p ZGVudGl2ZXJzZS5nYWxsZXJ5LnZpZGVvL2RldGFpbC92aWRlby82MTg0NDQzMDM3MDAxL2Jyb3dz ZXItZmVhdHVyZXMtdnMtaWRlbnRpdHktcHJvdG9jb2xzPC9hPi4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UbyByZXN0YXRlLCB0aGUgVE1JLUJGRiBwcm9wb3NhbCBpcyBub3Qg dHJ5aW5nIHRvIGZpeCBhbnkgb2YgdGhhdCwgbm9yIHBlciB0aGUgYWJvdmUgc29tZSBvZiBpdCBu ZWVkIGZpeGluZy4gVGhlIG9ubHkgaW5kaXJlY3QgY29ubmVjdGlvbiBtaWdodCBiZSB0aGF0IGxl c3Mgc3R1ZmYgaGFwcGVuaW5nIGluIHRoZQ0KIHVzZXIgYWdlbnQgbWVhbnMgbGVzcyBvcHBvcnR1 bml0aWVzIGZvciBzaW1pbGFyIGNoYW5nZXMgdG8gaW1wYWN0IHRoZSBmbG93cywgYnV0IGl04oCZ cyBkZWZpbml0ZWx5IG5vdCBhIHRvcCBsZXZlbCBkcml2ZXIuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPldhcnJlbiBQYXJhZCAmbHQ7d3BhcmFkPTxhIGhy ZWY9Im1haWx0bzo0MHJob3N5cy5jaEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQw cmhvc3lzLmNoQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5 LCBGZWJydWFyeSAxNCwgMjAyMSBhdCAxMTo0MTxicj4NCjxiPlRvOiA8L2I+Vml0dG9yaW8gQmVy dG9jY2kgJmx0OzxhIGhyZWY9Im1haWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20iIHRh cmdldD0iX2JsYW5rIj52aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOiA8L2I+TmVpbCBNYWRkZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3Jn ZXJvY2suY29tIiB0YXJnZXQ9Il9ibGFuayI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5vYXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9y bWF0aW9uIEJhY2tlbmQgRm9yIEZyb250ZW5kIChUTUkgQkZGKTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYXQgb25seSBh cHBsaWVzIHRvIHRoaXJkIHBhcnR5IGNvb2tpZXMsIGl0IHNob3VsZG4ndCBhZmZlY3QgdGhpcmQt cGFydHkgaWZyYW1lcyBhcyBmYXIgYXMgSSdtIGF3YXJlLiBTbyB1bmxlc3Mgd2UgZXhwZWN0IHRo b3NlIHRvIGJyZWFrLCB3ZSBwcm9iYWJseSBzaG91bGRuJ3QgaW5jbHVkZSB0aGF0Jm5ic3A7YXMN CiBhIGRyaXZpbmcgdXNlIGNhc2UuIElzIHRoZXJlIGFub3RoZXIgbWVhc3VyZSB0aGF0IHdvdWxk IGJlIHJlbGV2YW50IGhlcmU/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNp bmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4N Cjx0Ym9keT4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0 ZSAxLjBwdDtib3JkZXItcmlnaHQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjUuMHB0IDUu MHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29s aWQgd2hpdGUgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48Yj5FcnJvciEgRmlsZW5hbWUgbm90IHNwZWNpZmllZC48 L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9w IiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGlu Zzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBwdDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1ib3R0b206bm9uZTtwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5XYXJyZW4gUGFyYWQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6MGlu IDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+Rm91bmRlciwgQ1RPPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjp3aGl0ZSI+U2VjdXJlIHlv dXIgdXNlciBkYXRhIGFuZCBjb21wbGV0ZSB5b3VyIGF1dGhvcml6YXRpb24gYXJjaGl0ZWN0dXJl LiBJbXBsZW1lbnQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9hdXRocmVzcy5pbyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5BdXRocmVzczwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgNzo1NyBQTSBWaXR0b3JpbyBCZXJ0b2NjaSAmbHQ7 dml0dG9yaW8uYmVydG9jY2k9PGEgaHJlZj0ibWFpbHRvOjQwYXV0aDAuY29tQGRtYXJjLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SVRQLCBmb3IgZXhhbXBsZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5XYXJyZW4gUGFyYWQgJmx0O3dwYXJhZD08YSBocmVmPSJtYWlsdG86NDByaG9z eXMuY2hAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MHJob3N5cy5jaEBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgRmVicnVhcnkgMTQsIDIw MjEgYXQgMDQ6NTQ8YnI+DQo8Yj5UbzogPC9iPlZpdHRvcmlvIEJlcnRvY2NpICZsdDs8YSBocmVm PSJtYWlsdG86dml0dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tIiB0YXJnZXQ9Il9ibGFuayI+dml0 dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPk5laWwgTWFk ZGVuICZsdDs8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm5laWwubWFkZGVuQGZvcmdlcm9jay5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FV VEgtV0ddIFRva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZv ciBGcm9udGVuZCAoVE1JIEJGRik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkNhbiB5b3UgZXhwYW5kIG9uIHdoYXQgc2lsZW50IGF1dGhl bnRpY2F0aW9uIGFuZCBzZXNzaW9uIHRva2VuIHN0YW5kcyBmb3IgaGVyZT8gSWYgeW91IGFyZSBy ZWZlcnJpbmcgdG8gdGhlIGlmcmFtZSBzY2VuYXJpbywgdGhlIG5ldyBicm93c2VyIG1lYXN1cmVz IG1ha2UgaXQgcHJvYmxlbWF0aWMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGljaCBuZXcgYnJvd3NlciBtZWFzdXJlcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFk ZGluZz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHI+ DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVy LXJpZ2h0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo1LjBwdCA1LjBwdCA1LjBwdCA1LjBw dDtvdmVyZmxvdzpoaWRkZW4iPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdoaXRlIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjBpbiI+RXJyb3IhIEZpbGVuYW1lIG5vdCBzcGVjaWZpZWQuPC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRl cjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItbGVmdDpub25lO3BhZGRpbmc6NS4wcHQgNS4wcHQg NS4wcHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3 aGl0ZSAxLjBwdDtib3JkZXItYm90dG9tOm5vbmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K PHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+V2FycmVuIFBhcmFk PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNv bGlkIHdoaXRlIDEuMHB0O2JvcmRlci10b3A6bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPkZvdW5kZXIsIENUTzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6d2hpdGUiPlNlY3VyZSB5b3VyIHVzZXIgZGF0YSBh bmQgY29tcGxldGUgeW91ciBhdXRob3JpemF0aW9uIGFyY2hpdGVjdHVyZS4gSW1wbGVtZW50Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vYXV0aHJlc3MuaW8iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+QXV0aHJlc3M8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEZlYiAxNCwgMjAy MSBhdCAxOjMzIFBNIFZpdHRvcmlvIEJlcnRvY2NpICZsdDt2aXR0b3Jpby5iZXJ0b2NjaT08YSBo cmVmPSJtYWlsdG86NDBhdXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40 MGF1dGgwLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTMzMDg1 NjQ2MDYxNzUwNjEzMDdnbWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2 MzQ5ODY0ODMwNjVtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDYgbGV2ZWwxIGxm bzIiPg0KRm9yIFVJIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgaS5lLiBkb2N1bWVudCBzZWxlY3Rp b24sIHVzZXIgcHJvZmlsZSBkaXNwbGF5L2NoYW5nZXMsIGNvbnRhY3QgdXBkYXRlcywgZXRjLi4u IFlvdSBzaG91bGQgYmUgYWJsZSB0byBleGVjdXRlIHRoZSBjbGllbnQgc2lkZQ0KPGI+c2lsZW50 IGF1dGhlbnRpY2F0aW9uPC9iPiZuYnNwO3VzaW5nIHRoZSBwcm92aWRlZCBzZXNzaW9uIHRva2Vu IGZyb20gdGhlIEF6dXJlIEFEIEFTLCB3aXRob3V0IG5lZWRpbmcgdG8gbWFrZSBhbnkgUk8gYXBp IGNhbGxzIG5vciB1c2VyIHJlZGlyZWN0cy4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Q2FuIHlvdSBleHBhbmQgb24gd2hhdCBzaWxlbnQgYXV0aGVu dGljYXRpb24gYW5kIHNlc3Npb24gdG9rZW4gc3RhbmRzIGZvciBoZXJlPyBJZiB5b3UgYXJlIHJl ZmVycmluZyB0byB0aGUgaWZyYW1lIHNjZW5hcmlvLCB0aGUgbmV3IGJyb3dzZXIgbWVhc3VyZXMg bWFrZSBpdCBwcm9ibGVtYXRpYy4gSW4gY29kZStQS0NFDQogeW91IGNhbiB1c2UgYSByZWZyZXNo IHRva2VuLCBidXQgc2VlIHRoZSBvdGhlciByZXBseSBmb3IgaG93IHRoaXMgcHJvcG9zYWwgaXMg YW4gYWx0ZXJuYXRpdmUgdG8gdGhhdCBpbiBzb21lIHNpdHVhdGlvbnMuIFRoaXMgYW5zd2VyIHdh cyBzcGVjaWZpY2FsbHkgb24gd2h5IGhhdmluZyBiYWNrZW5kLWlzc3VlZCB0b2tlbnMgZGlkbuKA mXQgYXBwbHkgdG8gdGhpcyBzY2VuYXJpby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPldhcnJlbiBQYXJhZCAmbHQ7d3BhcmFkPTxhIGhyZWY9Im1haWx0bzo0MHJob3N5cy5j aEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwcmhvc3lzLmNoQGRtYXJjLmlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSAxNCwgMjAyMSBh dCAwMzo0ODxicj4NCjxiPlRvOiA8L2I+Vml0dG9yaW8gQmVydG9jY2kgJmx0OzxhIGhyZWY9Im1h aWx0bzp2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20iIHRhcmdldD0iX2JsYW5rIj52aXR0b3Jp by5iZXJ0b2NjaUBhdXRoMC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+TmVpbCBNYWRkZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpuZWlsLm1hZGRlbkBmb3JnZXJvY2suY29tIiB0YXJnZXQ9Il9i bGFuayI+bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1X R10gVG9rZW4gTWVkaWF0aW5nIGFuZCBzZXNzaW9uIEluZm9ybWF0aW9uIEJhY2tlbmQgRm9yIEZy b250ZW5kIChUTUkgQkZGKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHRoZSB0cnVzdGVkIHBhcnQsIHNlZSBhYm92ZS4gRm9yIHRo ZSBzaG9ydCBsaXZlZCBKV1RzLCB0aGF04oCZcyBub3QgcmVhbGx5IGFuIG9wdGlvbi4gVGhlIG1v c3QgZ2VuZXJpYyBzY2VuYXJpbyBhZGRyZXNzZWQgaGVyZSBpcyBmb3IgQVBJcyB0aGF0IGFjY2Vw dCB0b2tlbnMgaXNzdWVkIGJ5IHRoZSBBUzsNCiB0aGUgYmFja2VuZCBjYW4gcmVxdWVzdCB0aGVt IGFzIGEgY2xpZW50LCBidXQgaXQgY2Fubm90IG1pbnQgdGhlbS4gSW1hZ2luZSB3ZeKAmXJlIHRh bGtpbmcgYWJvdXQgYSBTUEEgYXBwbGljYXRpb24gdGhhdCBzaWducyBpbiB1c2VycyB1c2luZyBB enVyZSBBRCwgYW5kIG5lZWRzIHRvIGNhbGwgT2ZmaWNlIGFuZCBBenVyZSBBUElzLiBUaGUgU1BB IGJhY2tlbmQgY2Fubm90IGlzc3VlIHRva2VucyBmb3IgdGhvc2UgQVBJcywgaXQgY2FuIG9ubHkg cmVxdWVzdA0KIHRoZW0gdG8gdGhlIEF6dXJlIEFEIEFTLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBVSSByZWxhdGVk IGZ1bmN0aW9uYWxpdHksIGkuZS4gZG9jdW1lbnQgc2VsZWN0aW9uLCB1c2VyIHByb2ZpbGUgZGlz cGxheS9jaGFuZ2VzLCBjb250YWN0IHVwZGF0ZXMsIGV0Yy4uLiBZb3Ugc2hvdWxkIGJlIGFibGUg dG8gZXhlY3V0ZSB0aGUgY2xpZW50IHNpZGUNCjxiPnNpbGVudCBhdXRoZW50aWNhdGlvbjwvYj4m bmJzcDt1c2luZyB0aGUgcHJvdmlkZWQgc2Vzc2lvbiB0b2tlbiBmcm9tIHRoZSBBenVyZSBBRCBB Uywgd2l0aG91dCBuZWVkaW5nIHRvIG1ha2UgYW55IFJPIGFwaSBjYWxscyBub3IgdXNlciByZWRp cmVjdHMuJm5ic3A7Rm9yIFJPIHJlc3BvbnNpYmlsaXRpZXMsIHlvdSBjYW4gcHJlc2VudCB0aGUg dXNlciB3aXRoIGEgYnV0dG9uICZxdW90O0dyYW50IFJPIGFjY2VzcyB0byBBenVyZSByZXNvdXJj ZXMmcXVvdDsgYnV0dG9uIGFuZA0KIHRoZSB1c2VyIHdpbGwgZ28gdGhyb3VnaCZuYnNwO2EgcGVy bWlzc2lvbiBzY29wZSBlbGV2YXRpb24gZmxvdywgYWdhaW4gbm8gcmVhc29uIHRvIG5lZWQgYSBC RkYgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSBk aWQgY29uc2lkZXIgYWRkaW5nIHNvbWV0aGluZyB0byB0aGF0IGVmZmVjdCwgYW4gZXJyb3IgbWVz c2FnZSB0aGF0IGNhbiBkaXJlY3QgdGhlIGZyb250ZW5kIHRvIHBlcmZvcm0gdGhlIGludGVyYWN0 aXZlIHBvcnRpb24gbmVjZXNzYXJ5IGZvciB0aGlzIHRvcG9sb2d5IHRvIHdvcmsuIEl0IHdvdWxk IGJlDQogc29tZXRoaW5nIHNpbWlsYXIgdG8gdGhlIElEUCBpbml0aWF0ZWQgbG9naW4gaW4gT0lE Qywgd2hlcmUgdGhlIGNsaWVudCBvZmZlcnMgYW4gZW5kcG9pbnQgdGhhdCBpcyBndWFyYW50ZWVk IHRvIGluaXRpYXRlIGEgc2lnbiBpbiBmbG93IChoZW5jZSBpbmplY3QgYWxsIHRoZSBuZWNlc3Nh cnkgbm9uY2VzIGV0YykuIFdlIGRpZG7igJl0IGFkZCBpdCB1cGZyb250IGFuZCBsZWZ0IGl0IGFz IGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyIG1vc3RseSBiZWNhdXNlDQogaXTigJlzIG5vdCBlYXN5 IHRvIG1vZGVsIHByb3Blcmx5IGFuZCBiZWZvcmUgb3BlbmluZyB0aGF0IHdvcmsgZnJvbnQgd2Ug d2FudGVkIHRvIHNlZSBob3cgdGhlIGlkZWEgd2FzIHJlY2VpdmVkLiZuYnNwOyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SXQgbWF5IG1ha2Ugc2Vuc2UgZm9yIHRoZSBhcHAgdG8gaGF2ZSBhbiBlcnJvciBtZXNzYWdlLCBv ciBldmVuIGJldHRlciBtaWdodCBiZSBhIDMwMg0KPGI+TG9jYXRpb24gaGVhZGVyPC9iPiZuYnNw O2RlcGVuZGluZyBvbiB3aGF0IHlvdSBhcmUgZG9pbmcuIFRoZXJlIGlzIG5vdGhpbmcgaGVyZSB0 aGF0IGlzIE9BdXRoIHNwZWNpZmljIGhvd2V2ZXIgKG5vciBjb21tb24pLCBhbmQgdGhlbiB3ZSBz aG91bGQgY2hhbGxlbmdlIHRoZSBuZWVkIHRvIGRpcmVjdGx5IHByb3ZpZGUgYW4gUkZDIHJlY29t bWVuZGF0aW9uIGZvciBoYW5kbGluZyB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxlPSJib3JkZXItY29sbGFw c2U6Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9y ZGVyOnNvbGlkIHdoaXRlIDEuMHB0O2JvcmRlci1yaWdodDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6NS4wcHQgNS4wcHQgNS4wcHQgNS4wcHQ7b3ZlcmZsb3c6aGlkZGVuIj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2Jv cmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkVycm9yISBGaWxlbmFtZSBu b3Qgc3BlY2lmaWVkLjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8 dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWxl ZnQ6bm9uZTtwYWRkaW5nOjUuMHB0IDUuMHB0IDUuMHB0IDUuMHB0O292ZXJmbG93OmhpZGRlbiI+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgd2hpdGUgMS4wcHQ7Ym9yZGVyLWJvdHRvbTpub25l O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPldhcnJlbiBQYXJhZDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCB3aGl0ZSAxLjBwdDtib3JkZXItdG9wOm5v bmU7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Gb3VuZGVyLCBDVE88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOndo aXRlIj5TZWN1cmUgeW91ciB1c2VyIGRhdGEgYW5kIGNvbXBsZXRlIHlvdXIgYXV0aG9yaXphdGlv biBhcmNoaXRlY3R1cmUuIEltcGxlbWVudCZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2F1 dGhyZXNzLmlvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PkF1dGhyZXNzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gU3VuLCBGZWIgMTQsIDIwMjEgYXQgMTI6MjkgUE0gVml0dG9yaW8gQmVydG9j Y2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTxhIGhyZWY9Im1haWx0bzo0MGF1dGgwLmNvbUBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkhpIE5laWwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoYW5rcyBmb3IgdGhlIHByb21wdCBjb21tZW50cyE8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iZ21haWwtbS0zMzA4NTY0NjA2MTc1MDYxMzA3Z21haWwtbS02 NDc1MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYz NTM2OTIxNDQzOTk3OTQ5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVs MSBsZm8zIj4NClJlOiBHRVQgdnMgUE9TVCw8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQpwZXJzb25hbGx5IEnigJlkIGJlIGZp bmUgd2l0aCByZXN0cmljdGluZyB0byBQT1NULjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVs IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTMzMDg1NjQ2MDYxNzUwNjEzMDdnbWFp bC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFpbC1t LTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzQiPg0KUmU6IFJPLUFTLCBpbnRlcmFjdGlvbi0gPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnBlcmhhcHMgaXQgaXMgbm90IHZlcnkgY2xlYXIg ZnJvbSB0aGUgdGV4dCBhdCB0aGUgbW9tZW50IChmaXJzdCBkcmFmdCksIGJ1dCB0aGF0IGlzIGFz c3VtZWQgdGhhdCB0aGUgUk8gd2VudCB0aHJ1IHdoYXRldmVyIGludGVyYWN0aXZlIHN0ZXBzIGFy ZSBuZWNlc3NhcnkgdG8gZXN0YWJsaXNoIGEgc2Vzc2lvbg0KIChlZyBzaWduIGluLCBhc3N1bWlu ZyB0aGUgQVMgaXMgc2F5IGFuIE9JREMgcHJvdmlkZXIpIGFuZCBvYnRhaW4gYmVmb3JlaGFuZCB0 aGUgYWNjZXNzIHRva2VuIGFuZCByZWZyZXNoIHRva2VucyB0aGF0IHdpbGwgYmUgbmVlZGVkIGR1 cmluZyB0aGUgYXBwIGFjdGl2aXRpZXMgdGFraW5nIHBsYWNlIGFmdGVyICZuYnNwO3RoYXQuIElu IGNvbmNyZXRlIHRlcm1zLCBpbWFnaW5lIHRoYXQgdGhlIGJhY2tlbmQgcGVyZm9ybXMgYW4gYXV0 aG9yaXphdGlvbiBjb2RlDQogZ3JhbnQgcmVxdWVzdGluZyBhbiBJRHRva2VuLCBhY2Nlc3MgdG9r ZW4gYW5kIHJlZnJlc2ggdG9rZW4gQkVGT1JFIHRoZSBhY3Rpdml0aWVzIGRlc2NyaWJlZCBpbiBU TUktQkZGIHRha2UgcGxhY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBjdXJyZW50IGxhbmd1YWdlIHRyeWluZyB0byBleHByZXNzIHRoYXQgaXMgaW4gMS4yOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtOb3RvIFNhbnMmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPkFzIGEgcHJlcmVxdWlzaXRlIGZvciB0aGUg ZmxvdyBkZXNjcmliZWQgYmVsb3csIHRoZSBiYWNrZW5kIE1VU1QgaGF2ZSBlc3RhYmxpc2hlZA0K IGEgc2VjdXJlIHNlc3Npb24gd2l0aCB0aGUgdXNlciBhZ2VudCwgc28gdGhhdCBhbGwgcmVxdWVz dHMgZnJvbSB0aGF0IHVzZXIgYWdlbnQgdG93YXJkIHRoZSBiYWNrZW5kIG9jY3VyIG92ZXIgSFRU UFMgYW5kIGNhcnJ5IGEgdmFsaWQgc2Vzc2lvbiBhcnRpZmFjdCAoc3VjaCBhcyBhIGNvb2tpZSkg dGhhdCB0aGUgYmFja2VuZCBjYW4gdmFsaWRhdGUuIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFu ZGF0ZSBhbnkgc3BlY2lmaWMgbWVjaGFuaXNtIHRvDQogZXN0YWJsaXNoIGFuZCBtYWludGFpbiB0 aGF0IHNlc3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Tm90byBTYW5zJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5jYWNoZWQsIGl0IHJlcXVlc3Rz IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhIG5ldyBhY2Nlc3MgdG9rZW4gd2l0aCB0aGUg cmVxdWlyZWQNCiBjaGFyYWN0ZXJpc3RpY3MsIHVzaW5nIGFueSBhcnRpZmFjdHMgcHJldmlvdXN5 IG9idGFpbmVkIChlZyByZWZyZXNoIHRva2VuKSBhbmQgZ3JhbnRzIHRoYXQgd2lsbCBhbGxvdyB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gaXNzdWUgdGhlIHJlcXVlc3RlZCB0b2tlbiB3aXRo b3V0IHJlcXVpcmluZyB1c2VyIGludGVyYWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9ImdtYWlsLW0tMzMwODU2NDYwNjE3NTA2MTMwN2dtYWlsLW0tNjQ3NTI2 NjExNjA1Nzk2Njg0N2dtYWlsLW0tODk2ODcwNTYzNDk4NjQ4MzA2NWdtYWlsLW0tNTE2MzUzNjky MTQ0Mzk5Nzk0OW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZv NSI+DQo8c3BhbiBjbGFzcz0iZ21haWwtbS0zMzA4NTY0NjA2MTc1MDYxMzA3Z21haWwtbS02NDc1 MjY2MTE2MDU3OTY2ODQ3Z21haWwtbS04OTY4NzA1NjM0OTg2NDgzMDY1Z21haWwtbS01MTYzNTM2 OTIxNDQzOTk3OTQ5YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5JZiB0aGUgYmFja2VuZCBp cyBhbHJlYWR5IGltcGxpY2l0bHkgdHJ1c3RlZCB0aGVuIGNvdWxkbuKAmXQNCiB5b3Ugc2tpcCBP QXV0aCBhbmQganVzdCBnZXQgdGhlIGJhY2tlbmQgdG8gaXNzdWUgc2hvcnQtbGl2ZWQgSldUcyB0 byB0aGUgZnJvbnRlbmQgdGhhdCBpdCBjYW4gdXNlIGZvciBBUEkgYWNjZXNzPzxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgdGhlIHRydXN0ZWQgcGFydCwg c2VlIGFib3ZlLiBGb3IgdGhlIHNob3J0IGxpdmVkIEpXVHMsIHRoYXTigJlzIG5vdCByZWFsbHkg YW4gb3B0aW9uLiBUaGUgbW9zdCBnZW5lcmljIHNjZW5hcmlvIGFkZHJlc3NlZCBoZXJlIGlzIGZv ciBBUElzIHRoYXQgYWNjZXB0IHRva2VucyBpc3N1ZWQgYnkgdGhlIEFTOw0KIHRoZSBiYWNrZW5k IGNhbiByZXF1ZXN0IHRoZW0gYXMgYSBjbGllbnQsIGJ1dCBpdCBjYW5ub3QgbWludCB0aGVtLiBJ bWFnaW5lIHdl4oCZcmUgdGFsa2luZyBhYm91dCBhIFNQQSBhcHBsaWNhdGlvbiB0aGF0IHNpZ25z IGluIHVzZXJzIHVzaW5nIEF6dXJlIEFELCBhbmQgbmVlZHMgdG8gY2FsbCBPZmZpY2UgYW5kIEF6 dXJlIEFQSXMuIFRoZSBTUEEgYmFja2VuZCBjYW5ub3QgaXNzdWUgdG9rZW5zIGZvciB0aG9zZSBB UElzLCBpdCBjYW4gb25seSByZXF1ZXN0DQogdGhlbSB0byB0aGUgQXp1cmUgQUQgQVMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTMzMDg1NjQ2MDYxNzUwNjEzMDdn bWFpbC1tLTY0NzUyNjYxMTYwNTc5NjY4NDdnbWFpbC1tLTg5Njg3MDU2MzQ5ODY0ODMwNjVnbWFp bC1tLTUxNjM1MzY5MjE0NDM5OTc5NDltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6 bDUgbGV2ZWwxIGxmbzYiPg0KSWYgeW91IHdhbnQgdG8gYWxsb3cgYXV0aCBjb2RlIGZsb3cgZXRj IHRoZW4gcGVyaGFwcyB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGNhbiByZXR1cm4gYSBzdGFuZGFy ZCBlcnJvciBjb2RlIHdpdGggYW4gYXV0aG9yaXphdGlvbiBlbmRwb2ludCBVUkkgdGhhdCB0aGUg U1BBIHRoZW4gbmF2aWdhdGVzIHRoZSB1c2VyIHRvLiAoRWcgdGhlIGJhY2tlbmQgY2FuIGRvIGEg UEFSIHJlcXVlc3QgZmlyc3QgYW5kIHJldHVybiBhIFVSSSB0aGF0IHJlZmVyZW5jZXMNCiB0aGF0 IHNvIHRoYXQgYXV0aG9yaXphdGlvbiBkZXRhaWxzIGFyZW7igJl0IHBhc3NlZCB0aHJvdWdoIHRo ZSBmcm9udGVuZCkuJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPldlIGRpZCBjb25zaWRlciBhZGRpbmcgc29tZXRoaW5nIHRvIHRoYXQgZWZmZWN0LCBh biBlcnJvciBtZXNzYWdlIHRoYXQgY2FuIGRpcmVjdCB0aGUgZnJvbnRlbmQgdG8gcGVyZm9ybSB0 aGUgaW50ZXJhY3RpdmUgcG9ydGlvbiBuZWNlc3NhcnkgZm9yIHRoaXMgdG9wb2xvZ3kgdG8gd29y ay4gSXQgd291bGQgYmUNCiBzb21ldGhpbmcgc2ltaWxhciB0byB0aGUgSURQIGluaXRpYXRlZCBs b2dpbiBpbiBPSURDLCB3aGVyZSB0aGUgY2xpZW50IG9mZmVycyBhbiBlbmRwb2ludCB0aGF0IGlz IGd1YXJhbnRlZWQgdG8gaW5pdGlhdGUgYSBzaWduIGluIGZsb3cgKGhlbmNlIGluamVjdCBhbGwg dGhlIG5lY2Vzc2FyeSBub25jZXMgZXRjKS4gV2UgZGlkbuKAmXQgYWRkIGl0IHVwZnJvbnQgYW5k IGxlZnQgaXQgYXMgZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIgbW9zdGx5IGJlY2F1c2UNCiBpdOKA mXMgbm90IGVhc3kgdG8gbW9kZWwgcHJvcGVybHkgYW5kIGJlZm9yZSBvcGVuaW5nIHRoYXQgd29y ayBmcm9udCB3ZSB3YW50ZWQgdG8gc2VlIGhvdyB0aGUgaWRlYSB3YXMgcmVjZWl2ZWQuICZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5PQXV0aCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIE5laWwgTWFkZGVu ICZsdDs8YSBocmVmPSJtYWlsdG86bmVpbC5tYWRkZW5AZm9yZ2Vyb2NrLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm5laWwubWFkZGVuQGZvcmdlcm9jay5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5TdW5kYXksIEZlYnJ1YXJ5IDE0LCAyMDIxIGF0IDAwOjE3PGJyPg0KPGI+VG86IDwvYj5WaXR0 b3JpbyBCZXJ0b2NjaSAmbHQ7dml0dG9yaW8uYmVydG9jY2k9PGEgaHJlZj0ibWFpbHRvOjQwYXV0 aDAuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBhdXRoMC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFRva2Vu IE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJbmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZCAo VE1JIEJGRik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgYSBsb3Qgb2Ygc2Vj dXJpdHkgY29uY2VybnMgYWJvdXQgdGhpcyBkcmFmdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBkcmFmdCBhbGx1ZGVz IHRvIHNlY3VyaXR5IGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggaGFuZGxpbmcgYWNjZXNzIHRva2Vu cyBpbiB0aGUgZnJvbnRlbmQgYnV0IG5ldmVyIHJlYWxseSBzcGVsbHMgdGhlbSBvdXQuIEZyb20g dGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGl0IHNlZW1zIHRoYXQgdGhlDQogcHJpbWFyeSBj b25jZXJuIGlzIHdpdGggdGhlZnQgb2YgYWNjZXNzIHRva2VucyBmcm9tIGxvY2FsIHN0b3JhZ2Uu IFRvIGRvIHRoaXMgeW914oCZZCBuZWVkIGFuIFhTUyBhdHRhY2suIEJ1dCBpbiB0aGF0IGNhc2Us IHdvdWxkbuKAmXQgdGhlIGF0dGFja2VyIHNpbXBseSB1c2UgdGhlIFhTUyB0byBtYWtlIGEgY2Fs bCB0byB0aGUgYmZmLXRva2VuIGVuZHBvaW50IGluc3RlYWQ/Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgY29tYmluYXRp b24gb2YgdGhlIGJmZi10b2tlbiBlbmRwb2ludCByZWNvbW1lbmRpbmcgdGhlIHVzZSBvZiBHRVQg cmVxdWVzdHMgdG9nZXRoZXIgd2l0aCB0aGUgaGludCB0byB1c2UgY29va2llLWJhc2VkIGF1dGhl bnRpY2F0aW9uIGlzIGxpa2VseSBnb2luZyB0byBwdW5jaCBhIGhvbGUgaW4gbW9zdA0KIENTUkYg ZGVmZW5zZXMsIHdoaWNoIGFzc3VtZSB0aGF0IEdFVHMgYXJlIHNhZmUuIFRoZSBvbmx5IHRoaW5n IHByZXZlbnRpbmcgdGhpcyBiZWluZyBleHBsb2l0YWJsZSBpcyBDcm9zcy1PcmlnaW4gUmVhZCBC bG9ja2luZyAoPGEgaHJlZj0iaHR0cHM6Ly9jaHJvbWl1bS5nb29nbGVzb3VyY2UuY29tL2Nocm9t aXVtL3NyYy8rL21hc3Rlci9zZXJ2aWNlcy9uZXR3b3JrL2Nyb3NzX29yaWdpbl9yZWFkX2Jsb2Nr aW5nX2V4cGxhaW5lci5tZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vY2hyb21pdW0uZ29vZ2xl c291cmNlLmNvbS9jaHJvbWl1bS9zcmMvKy9tYXN0ZXIvc2VydmljZXMvbmV0d29yay9jcm9zc19v cmlnaW5fcmVhZF9ibG9ja2luZ19leHBsYWluZXIubWQ8L2E+KQ0KIGR1ZSB0byB0aGUgSlNPTiBj b250ZW50LXR5cGUuIFRoYXQgbWFrZXMgbWUgcmVhbGx5IG5lcnZvdXMuIFdlIHNob3VsZCBhdCBs ZWFzdCBtYW5kYXRlIFgtQ29udGVudC1UeXBlLU9wdGlvbnM6IG5vc25pZmYgb24gdGhhdCByZXNw b25zZS4gSeKAmWQgZmVlbCBtb3JlIGNvbWZvcnRhYmxlIGlmIHRoaXMgd2FzIGEgUE9TVCByZXF1 ZXN0IG9ubHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5BcyBTdG95Y2hvIFNsZXB0c292IG1lbnRpb25lZCBpbiB0aGUgb3Ro ZXIgZW1haWwsIHRoZSBsYWNrIG9mIGZyb250LWNoYW5uZWwgY29tbXVuaWNhdGlvbiBiZXR3ZWVu IHRoZSBBUyBhbmQgdGhlIFJPIHNlZW1zIG9kZC4gSWYgdGhlIGJhY2tlbmQgaXMgYWxyZWFkeSBp bXBsaWNpdGx5IHRydXN0ZWQgdGhlbg0KIGNvdWxkbuKAmXQgeW91IHNraXAgT0F1dGggYW5kIGp1 c3QgZ2V0IHRoZSBiYWNrZW5kIHRvIGlzc3VlIHNob3J0LWxpdmVkIEpXVHMgdG8gdGhlIGZyb250 ZW5kIHRoYXQgaXQgY2FuIHVzZSBmb3IgQVBJIGFjY2Vzcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHlvdSB3YW50IHRvIGFsbG93 IGF1dGggY29kZSBmbG93IGV0YyB0aGVuIHBlcmhhcHMgdGhlIGJmZi10b2tlbiBlbmRwb2ludCBj YW4gcmV0dXJuIGEgc3RhbmRhcmQgZXJyb3IgY29kZSB3aXRoIGFuIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgVVJJIHRoYXQgdGhlIFNQQSB0aGVuIG5hdmlnYXRlcyB0aGUgdXNlcg0KIHRvLiAoRWcg dGhlIGJhY2tlbmQgY2FuIGRvIGEgUEFSIHJlcXVlc3QgZmlyc3QgYW5kIHJldHVybiBhIFVSSSB0 aGF0IHJlZmVyZW5jZXMgdGhhdCBzbyB0aGF0IGF1dGhvcml6YXRpb24gZGV0YWlscyBhcmVu4oCZ dCBwYXNzZWQgdGhyb3VnaCB0aGUgZnJvbnRlbmQpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+4oCUIE5laWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDEyIEZlYiAyMDIxLCBhdCAyMDo0NiwgVml0 dG9yaW8gQmVydG9jY2kgJmx0O3ZpdHRvcmlvLmJlcnRvY2NpPTxhIGhyZWY9Im1haWx0bzo0MGF1 dGgwLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwYXV0aDAuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+77u/RGVhciBhbGwsPGJyPg0K QnJpYW4gYW5kIHlvdXJzIHRydWx5IGFyZSBwcm9wb3NpbmcgYSBuZXcgc3BlY2lmaWNhdGlvbiB0 aGF0IHNob3dzIGhvdyB0aGUgdXNlciBhZ2VudCBmcm9udGVuZCBvZiBhIHdlYiBhcHAgY2FuIGRl bGVnYXRlIHRva2VuIGFjcXVpc2l0aW9uIGFuZCBwZXJzaXN0ZW5jZSB0byBpdHMgYmFja2VuZCwg YW5kIHJlcXVlc3Qgc3VjaCB0b2tlbnMgd2hlbiBuZWVkZWQgZm9yIGRpcmVjdCBhY2Nlc3Mgb2Yg cHJvdGVjdGVkIHJlc291cmNlcyBmcm9tIHRoZQ0KIGZyb250ZW5kIGNvZGUuPGJyPg0KPGJyPg0K VGhlIHBhdHRlcm4gaXMgYWxyZWFkeSBpbiB1c2UsIGluIHByb3ByaWV0YXJ5IGZvcm0sIGJ5IHZh cmlvdXMgbW9kZXJuIGRldmVsb3BtZW50IHN0YWNrcywgc3VjaCBhcyBOZXh0LkpTLiBWYXJpYW50 cyBvZiB0aGUgcGF0dGVybiwgb2Z0ZW4gZGlzY3Vzc2VkIHVuZGVyIHRoZSBjYXRjaC1hbGwgdGVy bSBCRkYgKGJhY2tlbmQgZm9yIGZyb250ZW5kKSwgaGF2ZSBiZWVuIG9mdGVuIG1lbnRpb25lZCBp biB0aGlzIHdvcmtncm91cOKAmXMgYWN0aXZpdHksDQogYnV0IGFsd2F5cyBsZWZ0IGFsbCBpbXBs ZW1lbnRhdGlvbiBkZXRhaWxzIHRvIHRoZSByZWFkZXIuPGJyPg0KV2UgYmVsaWV2ZSB0aGUgcGF0 dGVybiBoYXMgbWVyaXQsIGFzIGNvcnJvYm9yYXRlZCBieSBpdHMgZ3Jvd2luZyBhZG9wdGlvbi4g QnkgZGVsZWdhdGluZyBhY2Nlc3MgdG9rZW4gYWNxdWlzaXRpb24gdG8gdGhlIGJhY2tlbmQsIHdl IGF2b2lkIG1hbnkgb2YgdGhlIG9mdGVuIGJyaXR0bGUgbW92aW5nIHBhcnRzIChhbmQgaW1wbGll ZCBhdHRhY2sgc3VyZmFjZSkgcmVxdWlyZWQgdG8gYWNxdWlyZSBhY2Nlc3MgdG9rZW5zIGZyb20g YSB1c2VyIGFnZW50Lg0KIFRoZSB0b3BvbG9neSBhbHNvIHJlbGlldmVzIHRoZSBmcm9udGVuZCBm cm9tIHRoZSBuZWVkIG9mIHBlcnNpc3RpbmcgdG9rZW5zIGluIGxvY2FsIHN0b3JhZ2UsIGEgd2Vs bCBrbm93biBzb3JlIHBvaW50IG9mIHVzaW5nIE9BdXRoIGRpcmVjdGx5IGluIEphdmFTY3JpcHQs IGJ5IHJlbHlpbmcgb24gaXRzIGJhY2tlbmQgc3RvcmFnZSBhbmQgc2Vzc2lvbiB0byBwcmVzZXJ2 ZSB0b2tlbnMuPGJyPg0KPGJyPg0KQWx0aG91Z2ggdGhlIHNwZWNpZmljYXRpb24gaXMgdmVyeSBz aW1wbGUsIHByb3ZpZGluZyBleHBsaWNpdCBndWlkYW5jZSBvbiB0aGUgc2NlbmFyaW8gb2ZmZXJz IG1hbnkgYWR2YW50YWdlcy4gJm5ic3A7PGJyPg0KLSBJdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBj cmVhdGUgaW50ZXJvcGVyYWJsZSBTREtzLCB3aGVyZSBmcm9udGVuZCBkZXYgc3RhY2tzIChhbnkg SlMgZmxhdm9yKSBjYW4gYmUgbWl4ZWQgYW5kIG1hdGNoZWQgd2l0aCBjb21wbGlhbnQgYmFja2Vu ZCBzdGFja3MgKG1pZGRsZXdhcmVzIGluIG5vZGUsIGphdmEsDQo8YSBocmVmPSJodHRwOi8vQVNQ Lk5FVCIgdGFyZ2V0PSJfYmxhbmsiPkFTUC5ORVQ8L2E+LCBQSFAgZXRjKTxicj4NCi0gSXQgYWxs b3dzIHVzIHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24gaG93IHRvIHByb3Blcmx5IHRhY2tsZSB0aGUg c2NlbmFyaW8gYW5kIHdhcm4gaW1wbGVtZW50ZXJzIGFnYWluc3Qgc2VjdXJpdHkgcmlza3MgKHNj b3BlIGVzY2FsYXRpb25zLCB1c2luZyBJRHRva2VucyBpbnN0ZWFkIG9mIGFjY2VzcyB0b2tlbnMs IGV0Yyk8YnI+DQotIEl0IGFsbG93cyB1cyB0byBkaXNjdXNzIChhbmQgd2hlbiBhcHByb3ByaWF0 ZSwgcHJvbW90ZSkgdGhpcyBwYXR0ZXJuIGFzIHBhcnQgb2YgdGhlIGJyb3dzZXIgYXBwcyBzZWN1 cml0eSBndWlkYW5jZSwgYW5kIHBvc2l0aW9uIHRoZSBzY2VuYXJpbyB3aGVyZSBmcm9udGVuZCBv bmx5IGNhbGxzIEFQSSBvbiBpdHMgb3duIGJhY2tlZCAoaGVuY2UgZG9lc27igJl0IG5lZWQgYWNj ZXNzIHRva2Vucykgc2ltcGx5IGFzIGEgc3BlY2lhbCBjYXNlIG9mIHRoaXMNCiBtb3JlIGdlbmVy YWwgcGF0dGVybjxicj4NCi0gVGhpcyBhcHByb2FjaCBtYWtlcyBtb2NraW5nIGFuZCB0ZXN0aW5n IGFwcHMgdmVyeSBlYXN5LCBwb3NzaWJseSBwcmV2ZW50aW5nIGRldmVsb3BlcnMgZnJvbSB3ZWFr ZW5pbmcgdGhlIHNlY3VyaXR5IG9mIHRoZWlyIHN5c3RlbSAoZWcgdHVybmluZyBvbiBST1BHIG9w dGlvbnMpICZuYnNwO29yIHR1cm5pbmcgdG8gcmlza3kgcHJhY3RpY2VzIGxpa2Ugc2NyYXBpbmc8 YnI+DQo8YnI+DQpOZWVkbGVzcyB0byBzYXksIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzbuKAmXQg ZW50aXJlbHkgZWxpbWluYXRlIHRoZSByaXNrcyBpbmhlcmVudCB0byBkaXJlY3QgdXNlIG9mIGFj Y2VzcyB0b2tlbnMgZnJvbSBhIGJyb3dzZXIuIEJ1dCByZWFsaXR5IGlzIHRoYXQgdGhlIHBhdHRl cm4gaXMgaW4gd2lkZXNwcmVhZCB1c2UsIGFuZCB0aGUgY2lyY3Vtc3RhbmNlcyBsZWFkaW5nIHRv IHRoYXQgKGVnIGRldmVsb3BlcnMgb24gYSBwYXJ0aWN1bGFyIHByb2plY3QNCiBvbmx5IHdvcmsg d2l0aCBmcm9udGVuZCBzdGFja3M7IGNvbXBvbmVudHMgbGlrZSByZXZlcnNlIHByb3hpZXMgbWln aHQgbm90IGFsd2F5cyBiZSB2aWFibGU7IGV0YykgYXJlbuKAmXQgZ29pbmcgYXdheSBhbnkgdGlt ZSBzb29uLiBCeSBwcm92aWRpbmcgc2ltcGxlIGd1aWRhbmNlIG9uIHRoaXMgcGF0dGVybiwgd2Ug Y2FuIHNpbXBsaWZ5IHRoZSBsaWZlIG9mIG1hbnkgZGV2ZWxvcGVycyB3aGlsZSBlbnNocmluaW5n IGJhc2ljIHNlY3VyaXR5IGh5Z2llbmUNCiBpbiBzY2VuYXJpb3MgdGhhdCB3b3VsZCBoYXZlIG90 aGVyd2lzZSBiZSBsZWZ0IHRvIHRoZWlyIG93biBkZXZpY2UuPGJyPg0KPGJyPg0KTG9va2luZyBm b3J3YXJkIGZvciB5b3VyIGZlZWRiYWNrITxicj4NCjxicj4NCkImYW1wO1YgJm5ic3A7PGJyPg0K PGJyPg0K77u/T24gMi8xMi8yMSwgMTI6NDEsICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsgd3JvdGU6 PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7QSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dDxicj4NCiZuYnNwOyZuYnNwOyZu YnNwO2hhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVml0dG9yaW8gQmVydG9jY2kg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtJRVRGIHJlcG9zaXRvcnku PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7TmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtYmVydG9jY2ktb2F1dGgyLXRtaS1iZmY8YnI+DQombmJzcDsmbmJzcDsmbmJz cDtSZXZpc2lvbjogJm5ic3A7ICZuYnNwOzAwPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGl0bGU6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1Rva2VuIE1lZGlhdGluZyBhbmQgc2Vzc2lvbiBJ bmZvcm1hdGlvbiBCYWNrZW5kIEZvciBGcm9udGVuZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0Rv Y3VtZW50IGRhdGU6ICZuYnNwOyAmbmJzcDsyMDIxLTAyLTEyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlzc2lv bjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1BhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsxNjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1VSTDogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0w MC50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2Ry YWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLnR4dDwvYT48YnI+DQombmJzcDsmbmJzcDsm bmJzcDtTdGF0dXM6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRv Y2NpLW9hdXRoMi10bWktYmZmLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLzwvYT48YnI+DQombmJz cDsmbmJzcDsmbmJzcDtIdG1sOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9hcmNo aXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRoMi10bWktYmZmLTAwLmh0bWwiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWJlcnRvY2NpLW9hdXRo Mi10bWktYmZmLTAwLmh0bWw8L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SHRtbGl6ZWQ6ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDItdG1pLWJmZi0wMCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZXJ0b2NjaS1vYXV0aDIt dG1pLWJmZi0wMDwvYT48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtBYnN0cmFj dDo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyBob3cgYSBKYXZhU2NyaXB0IGZyb250ZW5kIGNhbiBkZWxlZ2F0ZSBhY2Nlc3M8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0b2tlbiBhY3F1aXNpdGlv biB0byBhIGJhY2tlbmQgY29tcG9uZW50LiZuYnNwOyBJbiBzbyBkb2luZywgdGhlIGZyb250ZW5k PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2FuIGFjY2VzcyByZXNv dXJjZSBzZXJ2ZXJzIGRpcmVjdGx5IHdpdGhvdXQgdGFraW5nIG9uIHRoZSBidXJkZW4gb2Y8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb21tdW5pY2F0aW5nIHdpdGgg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBwZXJzaXN0aW5nIHRva2VucywgYW5kPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGVyZm9ybWluZyBvcGVyYXRpb25zIHRo YXQgYXJlIGZyYXVnaHQgd2l0aCBzZWN1cml0eSBjaGFsbGVuZ2VzIHdoZW48YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleGVjdXRlZCBpbiBhIHVzZXIgYWdlbnQsIGJ1 dCBhcmUgc2FmZSBhbmQgd2VsbCBwcm92ZW4gd2hlbiBleGVjdXRlZDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2J5IGEgY29uZmlkZW50aWFsIGNsaWVudCBydW5uaW5n IG9uIGEgYmFja2VuZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDtQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48 YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxi cj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjVwdDtjb2xvcjojMTcyQjREO2JhY2tncm91bmQ6d2hpdGUiPkZvcmdlUm9jayB2YWx1ZXMgeW91 cg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuZm9yZ2Vyb2NrLmNvbS95b3VyLXByaXZhY3kiIHRhcmdl dD0iX2JsYW5rIj5Qcml2YWN5PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO6PR18MB4052D4D091965B34B1DACD35AE899CO6PR18MB4052namp_-- From nobody Sun Feb 14 22:45:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EAC3A0C6D for ; Sun, 14 Feb 2021 22:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=ZEb1yQKS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ChuFrK5R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3irYjMNIXXgd for ; Sun, 14 Feb 2021 22:45:36 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C573A0C67 for ; Sun, 14 Feb 2021 22:45:36 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A3A54C62; Mon, 15 Feb 2021 01:45:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 15 Feb 2021 01:45:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=LiHjQDguMpYxwof9fmesjAyPn2udxQSAr/yMzCrehkY=; b=ZEb1yQKSeKMn kIZF4Qk9uMhQruWKwhcjy4SwOP3+02W/Qy+UTdFo72Xvbyk5KJErMIDiWTzco21t EROj95di6RLdvjNe/ib94Swy3/menrv2R1logq+5y+Lp/sdFm7mHIVYs6zknR4nc YuFF6th/G9XXk1V3I+dSu9BxasYfzzuPg51Txt94psQiaSvqk72L6/666XN5ygd3 QXuqqIQqPxSEVeaib1hBL0+8Tn4ryPviXCci79dDeOLpWFy6PfWxG1M2QVmpG74r +v+dUesHtnLV5YTHr5uWQCq+UN5OTCDUgI8G/oXktlk09+yvGO957vOpY5P0yjd5 jIdyv39Z+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=LiHjQD guMpYxwof9fmesjAyPn2udxQSAr/yMzCrehkY=; b=ChuFrK5Rkdl+RkGgo7oyrS t0TIdquUV+NuS7s4yCKGqvVMNkbos35BE9jehMREyo2qt7GeigYU5qCgZU8CWVrL pY28TApuFq1jzwU+/aTAnV9NkTgEPgWZexAZCr6/dBCnN6YuSy9eu2iQRTD66WJ2 UhGYFU7QtEy3ZNEheh4tekgJj51NBLJhVmkV8m9SgL4HBdqTfg/jhKVr7vy7UmFl HZC9pKGjLD1uBT503CwXec7p/4BS28c05iDgeXircDHY7HRHbgQqYGvorc16qKeU qZb9kD+kWe/TvdEtU6Hx4v/wBOtyUCT0TEiDNhuDC8lHqI111UO8i3fB61YpSdJA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieejgdeiiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhlihhp phgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvg gtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhephfdtjeeuffetvdegjeehieeh leettdeiudeitefggfevgeeuteefteelhfeljeevnecuffhomhgrihhnpehprhgrghhmrg htihgtfigvsghsvggtuhhrihhthidrtghomhdpghhoohhglhgvrdgtohhmpdhgrghllhgv rhihrdhvihguvghopdgruhhthhhrvghsshdrihhopdhgohhoghhlvghsohhurhgtvgdrtg homhdprghsphdrnhgvthdpihgvthhfrdhorhhgpdhfohhrghgvrhhotghkrdgtohhmnecu kfhppeekuddrudeigedruddvledrleehnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepphhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghs vggtuhhrihhthidrtghomh X-ME-Proxy: Received: from [192.168.1.47] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B1E4240057; Mon, 15 Feb 2021 01:45:32 -0500 (EST) From: Philippe De Ryck Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B3D022D0-29AD-4EF3-B3BD-199FDE788587" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 15 Feb 2021 07:45:29 +0100 In-Reply-To: Cc: Warren Parad , "oauth@ietf.org" To: Vittorio Bertocci References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 06:45:43 -0000 --Apple-Mail=_B3D022D0-29AD-4EF3-B3BD-199FDE788587 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A couple of notes from my end: Developers building an application that consists of a frontend, a = backend, and APIs indeed often struggle with identifying the correct = client, especially with the combination of OAuth 2.0 and OIDC. Having a = standardized way of handling such cases is definitely useful.=20 That said, the current spec is a bit all over the place. Vittorio stated = here that the main goal is to make it easier for developers, but the = spec makes quite a bit of (vague) security statements. It also aims to = avoid the need for a reverse proxy-based BFF, but comes up short = compared to such a BFF.=20 A few detailed security notes: 1) Section 6.1 states not to use localStorage (I assume because of = malicious JS code), which makes no sense. If malicious code is running = in the frontend, it can simply call the bff-token endpoint and grab the = token from there. Other attacks typically also allow to steal tokens = from memory (e.g., prototype pollution attacks as I discuss here: = https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html = ).=20 2) The use of confidential clients is a big plus, but since the access = token is used in the frontend, you lose the ability to use sender = constrained tokens, which a proxy BFF would be able to do. A proxy-based = BFF can also limit the API endpoints it exposes to a specific frontend = and can apply traffic analysis to detect malicious behavior from a = compromised frontend. 3) Keeping refresh tokens on the backend is good, but not necessarily = better than keeping them in a web worker, as Auth0=E2=80=99s JS SDK (and = presumably others, haven=E2=80=99t checked) does by default.=20 Overall, my recommendation is to focus on the specific use case of = handling tokens in a =E2=80=9Cfrontend with backend=E2=80=9D application = type, and forget about trying to also solve security issues in frontends = caused by malicious JS. Philippe =E2=80=94 Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com/ > On 14 Feb 2021, at 22:31, Vittorio Bertocci = wrote: >=20 > Draft [..] essentially suggests that every app needs to run a BFF to = do user token generation because an AS is no longer afforded the = capability for some reason > I believe this might be the crux of the problem, my impression is that = you are attributing to the draft a way larger scope than it is intended = to have. The draft makes no such suggestion. The draft says nothing = about AS losing capabilities. The draft is not trying to solve an AS = problem. And above all, the draft does not target every app.=20 > =20 > The draft is an optimization aimed at a very specific, albeit very = common, application topology where there is a frontend and a backend, = and the developer wants to perform API calls from the frontend directly = to the RS. This is only a specific topology, and the proposal is scoped = down to that. All other topologies are unaffected. Also, the draft = isn=E2=80=99t pushing this topology as the preferred one. It=E2=80=99s = best to keep tokens out of the frontend altogether. But if the developer = is adamant in performing API calls direct from their JS, and if they = already have a backend, and only in that case, the current proposal has = less moving parts and less requirements than code+PKCE . > =20 > Code+PKCE already has the expressive power to handle the scenario = described here, and is applicable to a wider range of scenarios. The = main point the draft brings to the table is the ability for a frontend = to delegate to a backend a lot of logic that in the code+PKCE case = executes in an environment that is naturally more constrained and prone = to attacks than a backend. That doesn=E2=80=99t mean developers whose = app has a backend should automatically choose the new model over = code+PKCE, more that the model discussed here might be viable and = require less capabilities/moving parts to achieve the same expressive = power, especially if the SDKs used in the solution have a standard way = to handle it. That is far from every app, but it is a situation I = encountered in the wild often enough to prompt the discussion with Brian = and the draft. > =20 > As a side note, the initial reactions of practitioners have been very = positive. I am really hoping the discussion will lead to identifying and = weeding out security issues, or land on security flaws in the model so = grave that they can be properly used to discourage its use. No matter = what way it will go, I am very glad the discussion is taking place. > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 12:59 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > To restate, the TMI-BFF proposal is not trying to fix any of that... = it=E2=80=99s definitely not a top level driver. > Great, then we are back to: what is the top level driver. Because, = while I appreciate the circumstances around ITP2.1~ as I fully = understand how identity providers like Auth0 are using iframes and = thirdparty cookies, this problem vanishes with the use of first-party = domains. So let's skip the digression and assume we aren't solving ITP = future related issues. > =20 > The real problem I have with the draft is that it essentially suggests = that every app needs to run a BFF to do user token generation because an = AS is no longer afforded the capability for some reason. If we pull in = expecting to solve ITP related issues then I think that justification is = in play and we can work together to come up with a solution, rather than = starting with the current deleterious prevalent pattern on the internet = (which honestly is the most ridiculous paradigm I have seen). If we = don't assume ITP is an issue, then I fail to see the core problem that = existing AS have (as you pointed out code+PKCE already works) without = the front channel or back channel needing really to make any additional = changes. > =20 > I assume there is a flaw in my reasoning somewhere, so please help me = find it. > =20 > - Warren > =20 >=20 > Warren Parad > Founder, CTO > =20 > =20 > On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci = > wrote: > Let me rewind a bit here. This was never presented as driving use = case. > =20 > Neil suggested that the backend could simply give short lived JTWs for = the frontent to call API. > I clarified that this would not be viable in the general case and = provided an example scenario where backend issued short lived tokens = would not have worked > You commented that the frontend can obtain AS tokens from JS and = mentioned silent authentication. I clarified (or tried to) that this = offshoot of the discussion wasn=E2=80=99t to say that there is no viable = way of doing the scenario already, and by the way using an iFrame to do = silent authentication is now problematic. At this point we are no longer = discussing TMI-BFF, but current affairs in the authentication world. The = fact that we are proposing TMI-BFF and the fact that silent = authentication is less and less viable are independent facts, the former = isn=E2=80=99t meant to be a solution for the latter (it=E2=80=99s = already addressed by using RTs in coke+PKCE) > =20 > That clarified. Not only we expect ITP to affect silent = authentication, it has been affected for the past year and that has been = one of the primary business drivers for the rapid adoption of = code+PKCE+RTs in the user agent, as customers with pure SPAs found = themselves unable to renew tokens without prompting as their access to = cookies in flows driven by iframes became less and less reliable. > When ITP was introduced we put many companies together to try to get = Apple to change it (you can find the doc in = https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7s= KsaiU/edit#heading=3Dh.p3nvp6xmxvzf = ) but they didn=E2=80=99t bulge and = ultimately the introduction of RTs in user agent code (albeit with extra = restrictions, the one I mentioned not everyone is following) made the = problem manageable. We have an initiative cross working groups (IETF, = OIDC etc)for working with browser vendors to try containing similar = regressions in the future. For a summary of similar problems see = https://identiverse.gallery.video/detail/video/6184443037001/browser-featu= res-vs-identity-protocols = . =20 > =20 > To restate, the TMI-BFF proposal is not trying to fix any of that, nor = per the above some of it need fixing. The only indirect connection might = be that less stuff happening in the user agent means less opportunities = for similar changes to impact the flows, but it=E2=80=99s definitely not = a top level driver. > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 11:41 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > That only applies to third party cookies, it shouldn't affect = third-party iframes as far as I'm aware. So unless we expect those to = break, we probably shouldn't include that as a driving use case. Is = there another measure that would be relevant here? >=20 > Error! Filename not specified. > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . > =20 > =20 > On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci = > wrote: > ITP, for example > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 04:54 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > Can you expand on what silent authentication and session token stands = for here? If you are referring to the iframe scenario, the new browser = measures make it problematic. > Which new browser measures? >=20 > Error! Filename not specified. > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . > =20 > =20 > On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci = > wrote: > For UI related functionality, i.e. document selection, user profile = display/changes, contact updates, etc... You should be able to execute = the client side silent authentication using the provided session token = from the Azure AD AS, without needing to make any RO api calls nor user = redirects.=20 > Can you expand on what silent authentication and session token stands = for here? If you are referring to the iframe scenario, the new browser = measures make it problematic. In code+PKCE you can use a refresh token, = but see the other reply for how this proposal is an alternative to that = in some situations. This answer was specifically on why having = backend-issued tokens didn=E2=80=99t apply to this scenario. > =20 > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 03:48 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > For the trusted part, see above. For the short lived JWTs, that=E2=80=99= s not really an option. The most generic scenario addressed here is for = APIs that accept tokens issued by the AS; the backend can request them = as a client, but it cannot mint them. Imagine we=E2=80=99re talking = about a SPA application that signs in users using Azure AD, and needs to = call Office and Azure APIs. The SPA backend cannot issue tokens for = those APIs, it can only request them to the Azure AD AS. > =20 > For UI related functionality, i.e. document selection, user profile = display/changes, contact updates, etc... You should be able to execute = the client side silent authentication using the provided session token = from the Azure AD AS, without needing to make any RO api calls nor user = redirects. For RO responsibilities, you can present the user with a = button "Grant RO access to Azure resources" button and the user will go = through a permission scope elevation flow, again no reason to need a BFF = here. > =20 > We did consider adding something to that effect, an error message that = can direct the frontend to perform the interactive portion necessary for = this topology to work. It would be something similar to the IDP = initiated login in OIDC, where the client offers an endpoint that is = guaranteed to initiate a sign in flow (hence inject all the necessary = nonces etc). We didn=E2=80=99t add it upfront and left it as exercise = for the reader mostly because it=E2=80=99s not easy to model properly = and before opening that work front we wanted to see how the idea was = received. =20 > It may make sense for the app to have an error message, or even better = might be a 302 Location header depending on what you are doing. There is = nothing here that is OAuth specific however (nor common), and then we = should challenge the need to directly provide an RFC recommendation for = handling this. > =20 > Error! Filename not specified. > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . > =20 > =20 > On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci = > wrote: > Hi Neil, > Thanks for the prompt comments! > Re: GET vs POST, > personally I=E2=80=99d be fine with restricting to POST. > =20 > Re: RO-AS, interaction-=20 > perhaps it is not very clear from the text at the moment (first = draft), but that is assumed that the RO went thru whatever interactive = steps are necessary to establish a session (eg sign in, assuming the AS = is say an OIDC provider) and obtain beforehand the access token and = refresh tokens that will be needed during the app activities taking = place after that. In concrete terms, imagine that the backend performs = an authorization code grant requesting an IDtoken, access token and = refresh token BEFORE the activities described in TMI-BFF take place. > The current language trying to express that is in 1.2: > As a prerequisite for the flow described below, the backend MUST have = established a secure session with the user agent, so that all requests = from that user agent toward the backend occur over HTTPS and carry a = valid session artifact (such as a cookie) that the backend can validate. = This document does not mandate any specific mechanism to establish and = maintain that session. > And > cached, it requests to the authorization server a new access token = with the required characteristics, using any artifacts previousy = obtained (eg refresh token) and grants that will allow the authorization = server to issue the requested token without requiring user interaction. > =20 > If the backend is already implicitly trusted then couldn=E2=80=99t = you skip OAuth and just get the backend to issue short-lived JWTs to the = frontend that it can use for API access? > For the trusted part, see above. For the short lived JWTs, that=E2=80=99= s not really an option. The most generic scenario addressed here is for = APIs that accept tokens issued by the AS; the backend can request them = as a client, but it cannot mint them. Imagine we=E2=80=99re talking = about a SPA application that signs in users using Azure AD, and needs to = call Office and Azure APIs. The SPA backend cannot issue tokens for = those APIs, it can only request them to the Azure AD AS. > =20 > If you want to allow auth code flow etc then perhaps the bff-token = endpoint can return a standard error code with an authorization endpoint = URI that the SPA then navigates the user to. (Eg the backend can do a = PAR request first and return a URI that references that so that = authorization details aren=E2=80=99t passed through the frontend).=20 > We did consider adding something to that effect, an error message that = can direct the frontend to perform the interactive portion necessary for = this topology to work. It would be something similar to the IDP = initiated login in OIDC, where the client offers an endpoint that is = guaranteed to initiate a sign in flow (hence inject all the necessary = nonces etc). We didn=E2=80=99t add it upfront and left it as exercise = for the reader mostly because it=E2=80=99s not easy to model properly = and before opening that work front we wanted to see how the idea was = received. =20 > =20 > From: OAuth > = on behalf of Neil Madden > > Date: Sunday, February 14, 2021 at 00:17 > To: Vittorio Bertocci > > Cc: "oauth@ietf.org " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > I have a lot of security concerns about this draft.=20 > =20 > The draft alludes to security issues associated with handling access = tokens in the frontend but never really spells them out. =46rom the = Security Considerations it seems that the primary concern is with theft = of access tokens from local storage. To do this you=E2=80=99d need an = XSS attack. But in that case, wouldn=E2=80=99t the attacker simply use = the XSS to make a call to the bff-token endpoint instead?=20 > =20 > The combination of the bff-token endpoint recommending the use of GET = requests together with the hint to use cookie-based authentication is = likely going to punch a hole in most CSRF defenses, which assume that = GETs are safe. The only thing preventing this being exploitable is = Cross-Origin Read Blocking = (https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md = ) due to the JSON content-type. = That makes me really nervous. We should at least mandate = X-Content-Type-Options: nosniff on that response. I=E2=80=99d feel more = comfortable if this was a POST request only.=20 > =20 > As Stoycho Sleptsov mentioned in the other email, the lack of = front-channel communication between the AS and the RO seems odd. If the = backend is already implicitly trusted then couldn=E2=80=99t you skip = OAuth and just get the backend to issue short-lived JWTs to the frontend = that it can use for API access? > =20 > If you want to allow auth code flow etc then perhaps the bff-token = endpoint can return a standard error code with an authorization endpoint = URI that the SPA then navigates the user to. (Eg the backend can do a = PAR request first and return a URI that references that so that = authorization details aren=E2=80=99t passed through the frontend).=20 > =20 > =E2=80=94 Neil > =20 > =20 >=20 > On 12 Feb 2021, at 20:46, Vittorio Bertocci = > wrote: >=20 > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how = the user agent frontend of a web app can delegate token acquisition and = persistence to its backend, and request such tokens when needed for = direct access of protected resources from the frontend code. >=20 > The pattern is already in use, in proprietary form, by various modern = development stacks, such as Next.JS. Variants of the pattern, often = discussed under the catch-all term BFF (backend for frontend), have been = often mentioned in this workgroup=E2=80=99s activity, but always left = all implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing = adoption. By delegating access token acquisition to the backend, we = avoid many of the often brittle moving parts (and implied attack = surface) required to acquire access tokens from a user agent. The = topology also relieves the frontend from the need of persisting tokens = in local storage, a well known sore point of using OAuth directly in = JavaScript, by relying on its backend storage and session to preserve = tokens. >=20 > Although the specification is very simple, providing explicit guidance = on the scenario offers many advantages. =20 > - It makes it possible to create interoperable SDKs, where frontend = dev stacks (any JS flavor) can be mixed and matched with compliant = backend stacks (middlewares in node, java, ASP.NET , = PHP etc) > - It allows us to provide guidance on how to properly tackle the = scenario and warn implementers against security risks (scope = escalations, using IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern = as part of the browser apps security guidance, and position the scenario = where frontend only calls API on its own backed (hence doesn=E2=80=99t = need access tokens) simply as a special case of this more general = pattern > - This approach makes mocking and testing apps very easy, possibly = preventing developers from weakening the security of their system (eg = turning on ROPG options) or turning to risky practices like scraping >=20 > Needless to say, this specification doesn=E2=80=99t entirely eliminate = the risks inherent to direct use of access tokens from a browser. But = reality is that the pattern is in widespread use, and the circumstances = leading to that (eg developers on a particular project only work with = frontend stacks; components like reverse proxies might not always be = viable; etc) aren=E2=80=99t going away any time soon. By providing = simple guidance on this pattern, we can simplify the life of many = developers while enshrining basic security hygiene in scenarios that = would have otherwise be left to their own device. >=20 > Looking forward for your feedback! >=20 > B&V =20 >=20 > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org = " > wrote: >=20 >=20 > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to = the > IETF repository. >=20 > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For = Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: = https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ = > Html: = https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html = > Htmlized: = https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 = >=20 >=20 > Abstract: > This document describes how a JavaScript frontend can delegate = access > token acquisition to a backend component. In so doing, the = frontend > can access resource servers directly without taking on the = burden of > communicating with the authorization server, persisting tokens, = and > performing operations that are fraught with security challenges = when > executed in a user agent, but are safe and well proven when = executed > by a confidential client running on a backend. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > ForgeRock values your Privacy > _______________________________________________ > OAuth mailing 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=_B3D022D0-29AD-4EF3-B3BD-199FDE788587 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = couple of notes from my end:

Developers building an application that consists of a = frontend, a backend, and APIs indeed often struggle with identifying the = correct client, especially with the combination of OAuth 2.0 and OIDC. = Having a standardized way of handling such cases is definitely = useful. 

That said, the current spec is a bit all over the place. = Vittorio stated here that the main goal is to make it easier for = developers, but the spec makes quite a bit of (vague) security = statements. It also aims to avoid the need for a reverse proxy-based = BFF, but comes up short compared to such a BFF. 

A few detailed security = notes:

1) = Section 6.1 states not to use localStorage (I assume because of = malicious JS code), which makes no sense. If malicious code is running = in the frontend, it can simply call the bff-token endpoint and grab the = token from there. Other attacks typically also allow to steal tokens = from memory (e.g., prototype pollution attacks as I discuss = here: https://pragmaticwebsecurity.com/articles/oauthoidc/localstorag= e-xss.html). 

2) The use of confidential clients is a big plus, but since = the access token is used in the frontend, you lose the ability to use = sender constrained tokens, which a proxy BFF would be able to do. A = proxy-based BFF can also limit the API endpoints it exposes to a = specific frontend and can apply traffic analysis to detect malicious = behavior from a compromised frontend.

3) Keeping refresh tokens on the = backend is good, but not necessarily better than keeping them in a web = worker, as Auth0=E2=80=99s JS SDK (and presumably others, haven=E2=80=99t = checked) does by default. 

Overall, my recommendation is to focus = on the specific use case of handling tokens in a =E2=80=9Cfrontend with = backend=E2=80=9D application type, and forget about trying to also solve = security issues in frontends caused by malicious JS.

Philippe


=E2=80=94
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/


On 14 Feb 2021, at 22:31, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:

  • Draft [..] essentially suggests that every app = needs to run a BFF to do user token generation because an AS is no = longer afforded the capability for some reason
I believe = this might be the crux of the problem, my impression is that you are = attributing to the draft a way larger scope than it is intended to have. = The draft makes no such suggestion. The draft says nothing about AS = losing capabilities. The draft is not trying to solve an AS problem. And = above all, the draft does not target every = app. 
 
The draft = is an optimization aimed at a very = specific, albeit very common, application topology where there is a = frontend and a backend, and the developer wants to perform API calls = from the frontend directly to the RS. This is only a specific topology, = and the proposal is scoped down to that. All other topologies are = unaffected. Also, the draft isn=E2=80=99t pushing this topology as the = preferred one. It=E2=80=99s best to keep tokens out of the frontend = altogether. But if the developer is adamant in performing API calls = direct from their JS, and if they already have a backend, and only in = that case, the current proposal has less moving parts and less = requirements than code+PKCE .
 
Code+PKCE already has the expressive = power to handle the scenario described here, and is applicable to a = wider range of scenarios. The main point the draft brings to the table = is the ability for a frontend to delegate to a backend a lot of logic = that in the code+PKCE case executes in an environment that is naturally = more constrained and prone to attacks than a backend. That doesn=E2=80=99t= mean developers whose app has a backend should automatically choose the = new model over code+PKCE, more that the model discussed here might be = viable and require less capabilities/moving parts to achieve the same = expressive power, especially if the SDKs used in the solution have a = standard way to handle it. That is far from every app, but it is a = situation I encountered in the wild often enough to prompt the = discussion with Brian and the draft.
 
As a side note, the initial reactions = of practitioners have been very positive. I am really hoping the = discussion will lead to identifying and weeding out security issues, or = land on security flaws in the model so grave that they can be properly = used to discourage its use. No matter what way it will go, I am very = glad the discussion is taking place.
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 12:59
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI BFF)
 
To restate, the TMI-BFF proposal is not = trying to fix any of that... it=E2=80=99s definitely not a top level = driver.
Great, then we are back to: what is the = top level driver. Because, while I appreciate the circumstances around = ITP2.1~ as I fully understand how identity providers like Auth0 are = using iframes and thirdparty cookies, this problem vanishes with = the use of first-party domains. So let's skip the digression and assume = we aren't solving ITP future related issues.
 
The real problem I have with the draft = is that it essentially suggests that every app needs to run a BFF to do = user token generation because an AS is no longer afforded the capability = for some reason. If we pull in expecting to solve ITP related issues = then I think that justification is in play and we can work together = to come up with a solution, rather than starting with the current = deleterious prevalent pattern on the internet (which honestly = is the most ridiculous paradigm I have seen). If we don't assume ITP is = an issue, then I fail to see the core problem that existing AS have (as = you pointed out code+PKCE already works) without the front channel or = back channel needing really to make any additional changes.
 
I assume there is a flaw in my = reasoning somewhere, so please help me find it.
 
- Warren
 
3D"Image
Warren = Parad
Founder, CTO
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: = Calibri, sans-serif;" class=3D""> 
 
On Sun, Feb 14, 2021 at = 9:20 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>= wrote:
Let me rewind a bit here. = This was never presented as driving use case.
 
  • Neil suggested that the backend could = simply give short lived JTWs for the frontent to call API.
  • I clarified that this would not be = viable in the general case and provided an example scenario where = backend issued short lived tokens would not have worked
  • You commented that the frontend can = obtain AS tokens from JS and mentioned silent authentication. I = clarified (or tried to) that this offshoot of the discussion wasn=E2=80=99= t to say that there is no viable way of doing the scenario already, and = by the way using an iFrame to do silent authentication is now = problematic. At this point we are no longer discussing TMI-BFF, but = current affairs in the authentication world. The fact that we are = proposing TMI-BFF and the fact that silent authentication is less and = less viable are independent facts, the former isn=E2=80=99t meant to be = a solution for the latter (it=E2=80=99s already addressed by using RTs = in coke+PKCE)
 
That clarified. Not only we expect ITP to affect silent = authentication, it has been affected for the past year and that has been = one of the primary business drivers for the rapid adoption of = code+PKCE+RTs in the user agent, as customers with pure SPAs found = themselves unable to renew tokens without prompting as their access to = cookies in flows driven by iframes became less and less reliable.
When ITP = was introduced we put many companies together to try to get Apple to = change it (you can find the doc in https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0r= a3viMEHrK7sKsaiU/edit#heading=3Dh.p3nvp6xmxvzf) but they didn=E2=80=99= t bulge and ultimately the introduction of RTs in user agent code = (albeit with extra restrictions, the one I mentioned not everyone is = following) made the problem manageable. We have an initiative cross = working groups (IETF, OIDC etc)for working with browser vendors to try = containing similar regressions in the future. For a summary of similar = problems see https://identiverse.gallery.video/detail/video/6184443037001/br= owser-features-vs-identity-protocols.  
 
To = restate, the TMI-BFF proposal is not trying to fix any of that, nor per = the above some of it need fixing. The only indirect connection might be = that less stuff happening in the user agent means less opportunities for = similar changes to impact the flows, but it=E2=80=99s definitely not a = top level driver.
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 11:41
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
That only applies to third party cookies, it shouldn't affect = third-party iframes as far as I'm aware. So unless we expect those to = break, we probably shouldn't include that as a driving use case. Is = there another measure that would be relevant here?

Error! Filename = not specified.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization = architecture. Implement Authress.
 
 
On Sun, Feb 14, 2021 at = 7:57 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
ITP, for example
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 04:54
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
Can you = expand on what silent authentication and session token stands for here? = If you are referring to the iframe scenario, the new browser measures = make it problematic.
Which new browser = measures?

Error! = Filename not specified.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization = architecture. Implement Authress.
 
 
On Sun, Feb 14, 2021 at 1:33 PM = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
  • For UI related functionality, i.e. document selection, user = profile display/changes, contact updates, etc... You should be able to = execute the client side silent = authentication using the provided session token from the Azure = AD AS, without needing to make any RO api calls nor user = redirects. 
Can you expand on what silent authentication and session = token stands for here? If you are referring to the iframe scenario, the = new browser measures make it problematic. In code+PKCE you can use a = refresh token, but see the other reply for how this proposal is an = alternative to that in some situations. This answer was specifically on = why having backend-issued tokens didn=E2=80=99t apply to this = scenario.
 
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 03:48
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
For the = trusted part, see above. For the short lived JWTs, that=E2=80=99s not = really an option. The most generic scenario addressed here is for APIs = that accept tokens issued by the AS; the backend can request them as a = client, but it cannot mint them. Imagine we=E2=80=99re talking about a = SPA application that signs in users using Azure AD, and needs to call = Office and Azure APIs. The SPA backend cannot issue tokens for those = APIs, it can only request them to the Azure AD AS.
 
For UI related functionality, i.e. = document selection, user profile display/changes, contact updates, = etc... You should be able to execute the client side silent = authentication using the provided session token from the Azure = AD AS, without needing to make any RO api calls nor user = redirects. For RO responsibilities, you can present the user with a = button "Grant RO access to Azure resources" button and the user will go = through a permission scope elevation flow, again no reason to need = a BFF here.
 
We did consider adding = something to that effect, an error message that can direct the frontend = to perform the interactive portion necessary for this topology to work. = It would be something similar to the IDP initiated login in OIDC, where = the client offers an endpoint that is guaranteed to initiate a sign in = flow (hence inject all the necessary nonces etc). We didn=E2=80=99t add = it upfront and left it as exercise for the reader mostly because it=E2=80=99= s not easy to model properly and before opening that work front we = wanted to see how the idea was received.  
It may make sense for the app to have an error message, or = even better might be a 302 Location = header depending on what you are doing. There is nothing here = that is OAuth specific however (nor common), and then we should = challenge the need to directly provide an RFC recommendation for = handling this.
 
Error! = Filename not specified.
Warren Parad
Founder, CTO
Secure your user data and complete your authorization = architecture. Implement Authress.
 
 
On Sun, Feb 14, 2021 at 12:29 PM = Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
Hi Neil,
Thanks for the prompt comments!
  • Re: GET vs POST,
personally I=E2=80=99d be fine with restricting to POST.
 
  • Re: RO-AS, interaction- 
perhaps = it is not very clear from the text at the moment (first draft), but that = is assumed that the RO went thru whatever interactive steps are = necessary to establish a session (eg sign in, assuming the AS is say an = OIDC provider) and obtain beforehand the access token and refresh tokens = that will be needed during the app activities taking place after =  that. In concrete terms, imagine that the backend performs an = authorization code grant requesting an IDtoken, access token and refresh = token BEFORE the activities described in TMI-BFF take place.
The = current language trying to express that is in 1.2:
As a prerequisite for the flow described below, the = backend MUST have established a secure session with the user agent, so = that all requests from that user agent toward the backend occur over = HTTPS and carry a valid session artifact (such as a cookie) that the = backend can validate. This document does not mandate any specific = mechanism to establish and maintain that session.
And
cached, it requests to the authorization server a = new access token with the required characteristics, using any artifacts = previousy obtained (eg refresh token) and grants that will allow the = authorization server to issue the requested token without requiring user = interaction.
 
  •  If the = backend is already implicitly trusted then couldn=E2=80=99t you skip = OAuth and just get the backend to issue short-lived JWTs to the frontend = that it can use for API access?
For the trusted part, see above. For = the short lived JWTs, that=E2=80=99s not really an option. The most = generic scenario addressed here is for APIs that accept tokens issued by = the AS; the backend can request them as a client, but it cannot mint = them. Imagine we=E2=80=99re talking about a SPA application that signs = in users using Azure AD, and needs to call Office and Azure APIs. The = SPA backend cannot issue tokens for those APIs, it can only request them = to the Azure AD AS.
 
  • If you want to allow auth code flow = etc then perhaps the bff-token endpoint can return a standard error code = with an authorization endpoint URI that the SPA then navigates the user = to. (Eg the backend can do a PAR request first and return a URI that = references that so that authorization details aren=E2=80=99t passed = through the frontend). 
We did consider adding something to = that effect, an error message that can direct the frontend to perform = the interactive portion necessary for this topology to work. It would be = something similar to the IDP initiated login in OIDC, where the client = offers an endpoint that is guaranteed to initiate a sign in flow (hence = inject all the necessary nonces etc). We didn=E2=80=99t add it upfront = and left it as exercise for the reader mostly because it=E2=80=99s not = easy to model properly and before opening that work front we wanted to = see how the idea was received.  
 
From: OAuth <oauth-bounces@ietf.org> on behalf of Neil Madden = <neil.madden@forgerock.com>
Date: Sunday, February 14, = 2021 at 00:17
To: Vittorio Bertocci = <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
I have a = lot of security concerns about this draft. 
 
The draft alludes to security issues = associated with handling access tokens in the frontend but never really = spells them out. =46rom the Security Considerations it seems that the = primary concern is with theft of access tokens from local storage. To do = this you=E2=80=99d need an XSS attack. But in that case, wouldn=E2=80=99t = the attacker simply use the XSS to make a call to the bff-token endpoint = instead? 
 
The combination of the bff-token endpoint recommending the = use of GET requests together with the hint to use cookie-based = authentication is likely going to punch a hole in most CSRF defenses, = which assume that GETs are safe. The only thing preventing this being = exploitable is Cross-Origin Read Blocking (https://chromium.googlesource.com/chromium/src/+/master/service= s/network/cross_origin_read_blocking_explainer.md) due to the JSON = content-type. That makes me really nervous. We should at least mandate = X-Content-Type-Options: nosniff on that response. I=E2=80=99d feel more = comfortable if this was a POST request only. 
 
As Stoycho Sleptsov mentioned in the = other email, the lack of front-channel communication between the AS and = the RO seems odd. If the backend is already implicitly trusted then = couldn=E2=80=99t you skip OAuth and just get the backend to issue = short-lived JWTs to the frontend that it can use for API access?
 
If you want to allow auth code flow etc = then perhaps the bff-token endpoint can return a standard error code = with an authorization endpoint URI that the SPA then navigates the user = to. (Eg the backend can do a PAR request first and return a URI that = references that so that authorization details aren=E2=80=99t passed = through the frontend). 
 
=E2=80=94 Neil
 

 

On 12 Feb 2021, at 20:46, Vittorio = Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

=EF=BB=BFDear all,
Brian and yours truly are = proposing a new specification that shows how the user agent frontend of = a web app can delegate token acquisition and persistence to its backend, = and request such tokens when needed for direct access of protected = resources from the frontend code.

The = pattern is already in use, in proprietary form, by various modern = development stacks, such as Next.JS. Variants of the pattern, often = discussed under the catch-all term BFF (backend for frontend), have been = often mentioned in this workgroup=E2=80=99s activity, but always left = all implementation details to the reader.
We believe the = pattern has merit, as corroborated by its growing adoption. By = delegating access token acquisition to the backend, we avoid many of the = often brittle moving parts (and implied attack surface) required to = acquire access tokens from a user agent. The topology also relieves the = frontend from the need of persisting tokens in local storage, a well = known sore point of using OAuth directly in JavaScript, by relying on = its backend storage and session to preserve tokens.

Although the specification is very simple, providing explicit = guidance on the scenario offers many advantages.  
- = It makes it possible to create interoperable SDKs, where frontend dev = stacks (any JS flavor) can be mixed and matched with compliant backend = stacks (middlewares in node, java, ASP.NET, PHP etc)
- It allows us to provide = guidance on how to properly tackle the scenario and warn implementers = against security risks (scope escalations, using IDtokens instead of = access tokens, etc)
- It allows us to discuss (and when = appropriate, promote) this pattern as part of the browser apps security = guidance, and position the scenario where frontend only calls API on its = own backed (hence doesn=E2=80=99t need access tokens) simply as a = special case of this more general pattern
- This approach = makes mocking and testing apps very easy, possibly preventing developers = from weakening the security of their system (eg turning on ROPG options) =  or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99t entirely = eliminate the risks inherent to direct use of access tokens from a = browser. But reality is that the pattern is in widespread use, and the = circumstances leading to that (eg developers on a particular project = only work with frontend stacks; components like reverse proxies might = not always be viable; etc) aren=E2=80=99t going away any time soon. By = providing simple guidance on this pattern, we can simplify the life of = many developers while enshrining basic security hygiene in scenarios = that would have otherwise be left to their own device.

Looking forward for your feedback!

B&V  

=EF=BB=BFOn = 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:


   A new version of I-D, = draft-bertocci-oauth2-tmi-bff-00.txt
   has = been successfully submitted by Vittorio Bertocci and posted to the
   IETF repository.

   Name:       =  draft-bertocci-oauth2-tmi-bff
   Revision:    00
   Title:        Token = Mediating and session Information Backend For Frontend
   Document date:    2021-02-12
   Group:       =  Individual Submission
   Pages: =        16
   URL: =            https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-0= 0.txt
   Status: =         https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/=
   Html: =           https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-0= 0.html
   Htmlized: =       https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


   Abstract:
      This document describes = how a JavaScript frontend can delegate access
      token acquisition to a = backend component.  In so doing, the frontend
      can access resource = servers directly without taking on the burden of
      communicating with the = authorization server, persisting tokens, and
      performing operations = that are fraught with security challenges when
      executed in a user agent, = but are safe and well proven when executed
      by a confidential client = running on a backend.




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

   The IETF Secretariat



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

ForgeRock values your Privacy
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;" = class=3D"">_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_B3D022D0-29AD-4EF3-B3BD-199FDE788587-- From nobody Sun Feb 14 23:50:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BF63A0D7D for ; Sun, 14 Feb 2021 23:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URZtEoLFI9v3 for ; Sun, 14 Feb 2021 23:50:30 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1A83A0D7C for ; Sun, 14 Feb 2021 23:50:30 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id c11so3676915pfp.10 for ; Sun, 14 Feb 2021 23:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=+hqfuPO6AFy+56cfEi9VtBahrsC8z/I8b0Mn/NOIwMM=; b=VMz5/TWwN19ID75vQoN/8Cq1ma7D/3UfZmC7bLhZT4ZgQK3/41RhJH0Pp4G6LRvBlH tmXCujftAeLWOwfBFrxZSoVDSrDpBHYv4DIWndfrcDnFfbbVZRWH3oF3+AnlAspPnJ9W XZiPvrE5D4khvmx2WHC4GSz7vxKDqh2wMgnOHCpH8bYMbiS9X+pbqu1u82IjiPVwcZWQ WPwj3kGmPTVBERC8I69Ky/EsYuZRb1AFiHbbY10F1f9w0W28biF9JY0VGyoYaqYsxCH+ IV6ZcJ+qs88m8EZz+oQITUsu4XaC+fe2/8+mwNEWepNZoK/7MCAIdGTemWzKENXaMKp+ YDag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=+hqfuPO6AFy+56cfEi9VtBahrsC8z/I8b0Mn/NOIwMM=; b=JpIGQy4m5uHsJTjCiss8WVr9O7Pe/ca6CqI9KToZ5DkFn2str6ZezJXmZpZ8bQtBDP PqArVD9unZkNuZoofU4vjNSTv2+WQUEi2iULSTPUzo1XFLsUocxJAJgYbOH2Hrb0xTL0 ifzMwKH8SrKj5wfbWUETM1l/TKuSF8nCnhvReGLCJjzQkdE3e2tTAM8LGyC66WBWXGpv Dbe9De1/7TwnPbmTPjV7Xo71oEWquCGjlVFTy1rPRCOeUuVynNp+yweUU1+RbBvguuk5 p8II8vP422ap01iKukXIsA05oMrR9wiOjVvEV057aWuSKyKwx0NegPgWokZ2WEV9tw9z 0CpA== X-Gm-Message-State: AOAM530Uap+xpCF6fKUtgSti/X72vNqN4GNdxnbzNlMrb07pmmy+jQ2j tzuiPW985EJx1Hay70pnBGheLJGb9yWy8g== X-Google-Smtp-Source: ABdhPJwH+VJM2+5f2ulDod/oc9Q36LatC4Ph5Gd57A1qjw3hQw+sos24z1/zT/6bz0ZmjUqNphO+jw== X-Received: by 2002:a63:205f:: with SMTP id r31mr13828894pgm.328.1613375429231; Sun, 14 Feb 2021 23:50:29 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id g17sm18416817pfq.135.2021.02.14.23.50.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Feb 2021 23:50:28 -0800 (PST) From: Vittorio Bertocci To: Philippe De Ryck CC: Warren Parad , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXUL8AgAA1Za+AAAVvgIAADHnkgAAF6ACAAGWCi4AAC++AgAALVsGAAArUgIAACN82gACa3YCAABInfQ== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 15 Feb 2021 07:50:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052599253874EE042B4DECDAE889CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 07:50:35 -0000 --_000_CO6PR18MB4052599253874EE042B4DECDAE889CO6PR18MB4052namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Philippe for your comments! Some considerations: * It also aims to avoid the need for a reverse proxy-based BFF, but com= es up short compared to such a BFF. That isn=92t a goal. If the developer can use a reverse proxy, they should = definitely go for it. Not getting tokens in the user agent at all is the sa= fest option. TMI-BFF is for the cases where it is not a viable option- thru= the threads I mentioned some of those cases. * Section 6.1 states not to use localStorage (I assume because of malic= ious JS code),=85 We might have been na=EFve there- a common discussion point even when consi= dering code+PKCE is that local storage is somehow vulnerable to more exploi= ts than memory. If there are attacks that only work with storage but not with memory, this = would be an incremental improvement. If every attack that can access the st= orage can also access memory, then I agree it=92s a moot point- but then th= e current public discourse needs a severe reset given that the two options = are presented as having very different security properties. * you lose the ability to use sender constrained tokens, which a proxy = BFF would be able to do Absolutely. If the reverse proxy is an option, the security improves for su= re. TMI-BFF is meant to help when it is not an option. * Keeping refresh tokens on the backend is good, but not necessarily be= tter than keeping them in a web worker, as Auth0=92s JS SDK A web worker is definitely good practice, but it=92s still on the local mac= hine. One might argue it=92s enough security for the scenario, but not the = same as not having the tokens available at all in the local box. But as you= say, the thrust behind TMI-BFF is more about dev experience- I=92d be happ= y with equivalent security with code+PKCE+RTs From: Philippe De Ryck Date: Sunday, February 14, 2021 at 22:45 To: Vittorio Bertocci Cc: Warren Parad , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) A couple of notes from my end: Developers building an application that consists of a frontend, a backend, = and APIs indeed often struggle with identifying the correct client, especia= lly with the combination of OAuth 2.0 and OIDC. Having a standardized way o= f handling such cases is definitely useful. That said, the current spec is a bit all over the place. Vittorio stated he= re that the main goal is to make it easier for developers, but the spec mak= es quite a bit of (vague) security statements. It also aims to avoid the ne= ed for a reverse proxy-based BFF, but comes up short compared to such a BFF= . A few detailed security notes: 1) Section 6.1 states not to use localStorage (I assume because of maliciou= s JS code), which makes no sense. If malicious code is running in the front= end, it can simply call the bff-token endpoint and grab the token from ther= e. Other attacks typically also allow to steal tokens from memory (e.g., pr= ototype pollution attacks as I discuss here: https://pragmaticwebsecurity.c= om/articles/oauthoidc/localstorage-xss.html). 2) The use of confidential clients is a big plus, but since the access toke= n is used in the frontend, you lose the ability to use sender constrained t= okens, which a proxy BFF would be able to do. A proxy-based BFF can also li= mit the API endpoints it exposes to a specific frontend and can apply traff= ic analysis to detect malicious behavior from a compromised frontend. 3) Keeping refresh tokens on the backend is good, but not necessarily bette= r than keeping them in a web worker, as Auth0=92s JS SDK (and presumably ot= hers, haven=92t checked) does by default. Overall, my recommendation is to focus on the specific use case of handling= tokens in a =93frontend with backend=94 application type, and forget about= trying to also solve security issues in frontends caused by malicious JS. Philippe =97 Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com/ On 14 Feb 2021, at 22:31, Vittorio Bertocci > wr= ote: * Draft [..] essentially suggests that every app needs to run a BFF to = do user token generation because an AS is no longer afforded the capability= for some reason I believe this might be the crux of the problem, my impression is that you = are attributing to the draft a way larger scope than it is intended to have= . The draft makes no such suggestion. The draft says nothing about AS losin= g capabilities. The draft is not trying to solve an AS problem. And above a= ll, the draft does not target every app. The draft is an optimization aimed at a very specific, albeit very common, = application topology where there is a frontend and a backend, and the devel= oper wants to perform API calls from the frontend directly to the RS. This = is only a specific topology, and the proposal is scoped down to that. All o= ther topologies are unaffected. Also, the draft isn=92t pushing this topolo= gy as the preferred one. It=92s best to keep tokens out of the frontend alt= ogether. But if the developer is adamant in performing API calls direct fro= m their JS, and if they already have a backend, and only in that case, the = current proposal has less moving parts and less requirements than code+PKCE= . Code+PKCE already has the expressive power to handle the scenario described= here, and is applicable to a wider range of scenarios. The main point the = draft brings to the table is the ability for a frontend to delegate to a ba= ckend a lot of logic that in the code+PKCE case executes in an environment = that is naturally more constrained and prone to attacks than a backend. Tha= t doesn=92t mean developers whose app has a backend should automatically ch= oose the new model over code+PKCE, more that the model discussed here might= be viable and require less capabilities/moving parts to achieve the same e= xpressive power, especially if the SDKs used in the solution have a standar= d way to handle it. That is far from every app, but it is a situation I enc= ountered in the wild often enough to prompt the discussion with Brian and t= he draft. As a side note, the initial reactions of practitioners have been very posit= ive. I am really hoping the discussion will lead to identifying and weeding= out security issues, or land on security flaws in the model so grave that = they can be properly used to discourage its use. No matter what way it will= go, I am very glad the discussion is taking place. From: Warren Parad > Date: Sunday, February 14, 2021 at 12:59 To: Vittorio Bertocci > Cc: Neil Madden >, "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) To restate, the TMI-BFF proposal is not trying to fix any of that... it=92s= definitely not a top level driver. Great, then we are back to: what is the top level driver. Because, while I = appreciate the circumstances around ITP2.1~ as I fully understand how ident= ity providers like Auth0 are using iframes and thirdparty cookies, this pro= blem vanishes with the use of first-party domains. So let's skip the digres= sion and assume we aren't solving ITP future related issues. The real problem I have with the draft is that it essentially suggests that= every app needs to run a BFF to do user token generation because an AS is = no longer afforded the capability for some reason. If we pull in expecting = to solve ITP related issues then I think that justification is in play and = we can work together to come up with a solution, rather than starting with = the current deleterious prevalent pattern on the internet (which honestly i= s the most ridiculous paradigm I have seen). If we don't assume ITP is an i= ssue, then I fail to see the core problem that existing AS have (as you poi= nted out code+PKCE already works) without the front channel or back channel= needing really to make any additional changes. I assume there is a flaw in my reasoning somewhere, so please help me find = it. - Warren [Image removed by sender.] Warren Parad Founder, CTO On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci > wrote: Let me rewind a bit here. This was never presented as driving use case. * Neil suggested that the backend could simply give short lived JTWs fo= r the frontent to call API. * I clarified that this would not be viable in the general case and pro= vided an example scenario where backend issued short lived tokens would not= have worked * You commented that the frontend can obtain AS tokens from JS and ment= ioned silent authentication. I clarified (or tried to) that this offshoot o= f the discussion wasn=92t to say that there is no viable way of doing the s= cenario already, and by the way using an iFrame to do silent authentication= is now problematic. At this point we are no longer discussing TMI-BFF, but= current affairs in the authentication world. The fact that we are proposin= g TMI-BFF and the fact that silent authentication is less and less viable a= re independent facts, the former isn=92t meant to be a solution for the lat= ter (it=92s already addressed by using RTs in coke+PKCE) That clarified. Not only we expect ITP to affect silent authentication, it = has been affected for the past year and that has been one of the primary bu= siness drivers for the rapid adoption of code+PKCE+RTs in the user agent, a= s customers with pure SPAs found themselves unable to renew tokens without = prompting as their access to cookies in flows driven by iframes became less= and less reliable. When ITP was introduced we put many companies together to try to get Apple = to change it (you can find the doc in https://docs.google.com/document/d/1R= s--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7sKsaiU/edit#heading=3Dh.p3nvp6xmxvzf) b= ut they didn=92t bulge and ultimately the introduction of RTs in user agent= code (albeit with extra restrictions, the one I mentioned not everyone is = following) made the problem manageable. We have an initiative cross working= groups (IETF, OIDC etc)for working with browser vendors to try containing = similar regressions in the future. For a summary of similar problems see ht= tps://identiverse.gallery.video/detail/video/6184443037001/browser-features= -vs-identity-protocols. To restate, the TMI-BFF proposal is not trying to fix any of that, nor per = the above some of it need fixing. The only indirect connection might be tha= t less stuff happening in the user agent means less opportunities for simil= ar changes to impact the flows, but it=92s definitely not a top level drive= r. From: Warren Parad > Date: Sunday, February 14, 2021 at 11:41 To: Vittorio Bertocci > Cc: Neil Madden >, "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) That only applies to third party cookies, it shouldn't affect third-party i= frames as far as I'm aware. So unless we expect those to break, we probably= shouldn't include that as a driving use case. Is there another measure tha= t would be relevant here? Error! Filename not specified. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Impleme= nt Authress. On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci > wrote: ITP, for example From: Warren Parad > Date: Sunday, February 14, 2021 at 04:54 To: Vittorio Bertocci > Cc: Neil Madden >, "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) Can you expand on what silent authentication and session token stands for h= ere? If you are referring to the iframe scenario, the new browser measures = make it problematic. Which new browser measures? Error! Filename not specified. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Impleme= nt Authress. On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci > wrote: * For UI related functionality, i.e. document selection, user profile d= isplay/changes, contact updates, etc... You should be able to execute the c= lient side silent authentication using the provided session token from the = Azure AD AS, without needing to make any RO api calls nor user redirects. Can you expand on what silent authentication and session token stands for h= ere? If you are referring to the iframe scenario, the new browser measures = make it problematic. In code+PKCE you can use a refresh token, but see the = other reply for how this proposal is an alternative to that in some situati= ons. This answer was specifically on why having backend-issued tokens didn= =92t apply to this scenario. From: Warren Parad > Date: Sunday, February 14, 2021 at 03:48 To: Vittorio Bertocci > Cc: Neil Madden >, "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) For the trusted part, see above. For the short lived JWTs, that=92s not rea= lly an option. The most generic scenario addressed here is for APIs that ac= cept tokens issued by the AS; the backend can request them as a client, but= it cannot mint them. Imagine we=92re talking about a SPA application that = signs in users using Azure AD, and needs to call Office and Azure APIs. The= SPA backend cannot issue tokens for those APIs, it can only request them t= o the Azure AD AS. For UI related functionality, i.e. document selection, user profile display= /changes, contact updates, etc... You should be able to execute the client = side silent authentication using the provided session token from the Azure = AD AS, without needing to make any RO api calls nor user redirects. For RO = responsibilities, you can present the user with a button "Grant RO access t= o Azure resources" button and the user will go through a permission scope e= levation flow, again no reason to need a BFF here. We did consider adding something to that effect, an error message that can = direct the frontend to perform the interactive portion necessary for this t= opology to work. It would be something similar to the IDP initiated login i= n OIDC, where the client offers an endpoint that is guaranteed to initiate = a sign in flow (hence inject all the necessary nonces etc). We didn=92t add= it upfront and left it as exercise for the reader mostly because it=92s no= t easy to model properly and before opening that work front we wanted to se= e how the idea was received. It may make sense for the app to have an error message, or even better migh= t be a 302 Location header depending on what you are doing. There is nothin= g here that is OAuth specific however (nor common), and then we should chal= lenge the need to directly provide an RFC recommendation for handling this. Error! Filename not specified. Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Impleme= nt Authress. On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci > wrote: Hi Neil, Thanks for the prompt comments! * Re: GET vs POST, personally I=92d be fine with restricting to POST. * Re: RO-AS, interaction- perhaps it is not very clear from the text at the moment (first draft), but= that is assumed that the RO went thru whatever interactive steps are neces= sary to establish a session (eg sign in, assuming the AS is say an OIDC pro= vider) and obtain beforehand the access token and refresh tokens that will = be needed during the app activities taking place after that. In concrete t= erms, imagine that the backend performs an authorization code grant request= ing an IDtoken, access token and refresh token BEFORE the activities descri= bed in TMI-BFF take place. The current language trying to express that is in 1.2: As a prerequisite for the flow described below, the backend MUST have estab= lished a secure session with the user agent, so that all requests from that= user agent toward the backend occur over HTTPS and carry a valid session a= rtifact (such as a cookie) that the backend can validate. This document doe= s not mandate any specific mechanism to establish and maintain that session= . And cached, it requests to the authorization server a new access token with the= required characteristics, using any artifacts previousy obtained (eg refre= sh token) and grants that will allow the authorization server to issue the = requested token without requiring user interaction. * If the backend is already implicitly trusted then couldn=92t you ski= p OAuth and just get the backend to issue short-lived JWTs to the frontend = that it can use for API access? For the trusted part, see above. For the short lived JWTs, that=92s not rea= lly an option. The most generic scenario addressed here is for APIs that ac= cept tokens issued by the AS; the backend can request them as a client, but= it cannot mint them. Imagine we=92re talking about a SPA application that = signs in users using Azure AD, and needs to call Office and Azure APIs. The= SPA backend cannot issue tokens for those APIs, it can only request them t= o the Azure AD AS. * If you want to allow auth code flow etc then perhaps the bff-token en= dpoint can return a standard error code with an authorization endpoint URI = that the SPA then navigates the user to. (Eg the backend can do a PAR reque= st first and return a URI that references that so that authorization detail= s aren=92t passed through the frontend). We did consider adding something to that effect, an error message that can = direct the frontend to perform the interactive portion necessary for this t= opology to work. It would be something similar to the IDP initiated login i= n OIDC, where the client offers an endpoint that is guaranteed to initiate = a sign in flow (hence inject all the necessary nonces etc). We didn=92t add= it upfront and left it as exercise for the reader mostly because it=92s no= t easy to model properly and before opening that work front we wanted to se= e how the idea was received. From: OAuth > on beha= lf of Neil Madden > Date: Sunday, February 14, 2021 at 00:17 To: Vittorio Bertocci > Cc: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) I have a lot of security concerns about this draft. The draft alludes to security issues associated with handling access tokens= in the frontend but never really spells them out. From the Security Consid= erations it seems that the primary concern is with theft of access tokens f= rom local storage. To do this you=92d need an XSS attack. But in that case,= wouldn=92t the attacker simply use the XSS to make a call to the bff-token= endpoint instead? The combination of the bff-token endpoint recommending the use of GET reque= sts together with the hint to use cookie-based authentication is likely goi= ng to punch a hole in most CSRF defenses, which assume that GETs are safe. = The only thing preventing this being exploitable is Cross-Origin Read Block= ing (https://chromium.googlesource.com/chromium/src/+/master/services/netwo= rk/cross_origin_read_blocking_explainer.md) due to the JSON content-type. T= hat makes me really nervous. We should at least mandate X-Content-Type-Opti= ons: nosniff on that response. I=92d feel more comfortable if this was a PO= ST request only. As Stoycho Sleptsov mentioned in the other email, the lack of front-channel= communication between the AS and the RO seems odd. If the backend is alrea= dy implicitly trusted then couldn=92t you skip OAuth and just get the backe= nd to issue short-lived JWTs to the frontend that it can use for API access= ? If you want to allow auth code flow etc then perhaps the bff-token endpoint= can return a standard error code with an authorization endpoint URI that t= he SPA then navigates the user to. (Eg the backend can do a PAR request fir= st and return a URI that references that so that authorization details aren= =92t passed through the frontend). =97 Neil On 12 Feb 2021, at 20:46, Vittorio Bertocci > wrote: ?Dear all, Brian and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and persist= ence to its backend, and request such tokens when needed for direct access = of protected resources from the frontend code. The pattern is already in use, in proprietary form, by various modern devel= opment stacks, such as Next.JS. Variants of the pattern, often discussed un= der the catch-all term BFF (backend for frontend), have been often mentione= d in this workgroup=92s activity, but always left all implementation detail= s to the reader. We believe the pattern has merit, as corroborated by its growing adoption. = By delegating access token acquisition to the backend, we avoid many of the= often brittle moving parts (and implied attack surface) required to acquir= e access tokens from a user agent. The topology also relieves the frontend = from the need of persisting tokens in local storage, a well known sore poin= t of using OAuth directly in JavaScript, by relying on its backend storage = and session to preserve tokens. Although the specification is very simple, providing explicit guidance on t= he scenario offers many advantages. - It makes it possible to create interoperable SDKs, where frontend dev sta= cks (any JS flavor) can be mixed and matched with compliant backend stacks = (middlewares in node, java, ASP.NET, PHP etc) - It allows us to provide guidance on how to properly tackle the scenario a= nd warn implementers against security risks (scope escalations, using IDtok= ens instead of access tokens, etc) - It allows us to discuss (and when appropriate, promote) this pattern as p= art of the browser apps security guidance, and position the scenario where = frontend only calls API on its own backed (hence doesn=92t need access toke= ns) simply as a special case of this more general pattern - This approach makes mocking and testing apps very easy, possibly preventi= ng developers from weakening the security of their system (eg turning on RO= PG options) or turning to risky practices like scraping Needless to say, this specification doesn=92t entirely eliminate the risks = inherent to direct use of access tokens from a browser. But reality is that= the pattern is in widespread use, and the circumstances leading to that (e= g developers on a particular project only work with frontend stacks; compon= ents like reverse proxies might not always be viable; etc) aren=92t going a= way any time soon. By providing simple guidance on this pattern, we can sim= plify the life of many developers while enshrining basic security hygiene i= n scenarios that would have otherwise be left to their own device. Looking forward for your feedback! B&V ?On 2/12/21, 12:41, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt has been successfully submitted by Vittorio Bertocci and posted to the IETF repository. Name: draft-bertocci-oauth2-tmi-bff Revision: 00 Title: Token Mediating and session Information Backend For Fronte= nd Document date: 2021-02-12 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tm= i-bff-00.txt Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-t= mi-bff/ Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tm= i-bff-00.html Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bf= f-00 Abstract: This document describes how a JavaScript frontend can delegate access token acquisition to a backend component. In so doing, the frontend can access resource servers directly without taking on the burden of communicating with the authorization server, persisting tokens, and performing operations that are fraught with security challenges when executed in a user agent, but are safe and well proven when executed by a confidential client running on a backend. Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ForgeRock values your Privacy _______________________________________________ OAuth mailing 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_CO6PR18MB4052599253874EE042B4DECDAE889CO6PR18MB4052namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank you Philippe for your comments! Some considera= tions:

  • It also ai= ms to avoid the need for a reverse proxy-based BFF, but comes up short comp= ared to such a BFF.

That isn=92t a goal. If the developer can use= a reverse proxy, they should definitely go for it. Not getting tokens in t= he user agent at all is the safest option. TMI-BFF is for the cases where i= t is not a viable option- thru the threads I mentioned some of those cases.

 

  • Section 6.= 1 states not to use localStorage (I assume because of malicious JS code),= =85

We might have been na=EFve there- a common discussio= n point even when considering code+PKCE is that local storage is somehow vu= lnerable to more exploits than memory.

If there are attacks that only work with storage but= not with memory, this would be an incremental improvement. If every attack= that can access the storage can also access memory, then I agree it=92s a = moot point- but then the current public discourse needs a severe reset given that the two options are presented as= having very different security properties.

 

 

  • you lose t= he ability to use sender constrained tokens, which a proxy BFF would be abl= e to do

Absolutely. If the reverse proxy is an option, the s= ecurity improves for sure. TMI-BFF is meant to help when it is not an optio= n.

 

 

  • Keeping re= fresh tokens on the backend is good, but not necessarily better than keepin= g them in a web worker, as Auth0=92s JS SDK

A web worker is definitely good practice, but it=92s= still on the local machine. One might argue it=92s enough security for the scenario, but not the same as not having the= tokens available at all in the local box. But as you say, the thrust behin= d TMI-BFF is more about dev experience- I=92d be happy with equivalent secu= rity with code+PKCE+RTs

 

From= : Philippe De Ryck = <philippe@pragmaticwebsecurity.com>
Date: Sunday, February 14, 2021 at 22:45
To: Vittorio Bertocci <vittorio.bertocci@auth0.com>
Cc: Warren Parad <wparad@rhosys.ch>, "oauth@ietf.org"= ; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

 

A couple of notes from my end:

 

Developers building an application that consists of = a frontend, a backend, and APIs indeed often struggle with identifying the = correct client, especially with the combination of OAuth 2.0 and OIDC. Havi= ng a standardized way of handling such cases is definitely useful. 

 

That said, the current spec is a bit all over the pl= ace. Vittorio stated here that the main goal is to make it easier for devel= opers, but the spec makes quite a bit of (vague) security statements. It al= so aims to avoid the need for a reverse proxy-based BFF, but comes up short compared to such a BFF. 

 

A few detailed security notes:

 

1) Section 6.1 states not to use localStorage (I ass= ume because of malicious JS code), which makes no sense. If malicious code = is running in the frontend, it can simply call the bff-token endpoint and g= rab the token from there. Other attacks typically also allow to steal tokens from memory (e.g., prototype pollutio= n attacks as I discuss here: https://pragmaticwebsecurity.c= om/articles/oauthoidc/localstorage-xss.html). 

 

2) The use of confidential clients is a big plus, bu= t since the access token is used in the frontend, you lose the ability to u= se sender constrained tokens, which a proxy BFF would be able to do. A prox= y-based BFF can also limit the API endpoints it exposes to a specific frontend and can apply traffic analysis= to detect malicious behavior from a compromised frontend.

 

3) Keeping refresh tokens on the backend is good, bu= t not necessarily better than keeping them in a web worker, as Auth0=92s JS= SDK (and presumably others, haven=92t checked) does by default. =

 

Overall, my recommendation is to focus on the specif= ic use case of handling tokens in a =93frontend with backend=94 application= type, and forget about trying to also solve security issues in frontends c= aused by malicious JS.

 

Philippe

 

 

=97

Pragmatic Web Security Security for developers
https://pragmaticwebsecurity.= com/



On 14 Feb 2021, at 22:31, Vittorio Bertocci <vittorio.bert= occi=3D40auth0.com@dmarc.ietf.org> wrote:

 

  • Draft [..] essentially suggests that every app needs to run a BFF to do use= r token generation because an AS is no longer afforded the capability for s= ome reason

I believe this might be the crux of the problem, my = impression is that you are attributing to the draft a way larger scope than= it is intended to have. The draft makes no such suggestion. The draft says= nothing about AS losing capabilities. The draft is not trying to solve an AS problem. And above all, the draft d= oes not target every a= pp. 

 

The draft is an optimization aimed at a very specific, albeit very com= mon, application topology where there is a frontend and a backend, and the = developer wants to perform API calls from the frontend directly to the RS. This is only a specific topology, and the= proposal is scoped down to that. All other topologies are unaffected. Also= , the draft isn=92t pushing this topology as the preferred one. It=92s best= to keep tokens out of the frontend altogether. But if the developer is adamant in performing API calls direct= from their JS, and if they already have a backend, and only in that case, the current propos= al has less moving parts and less requirements than code+PKCE .

 

Code+PKCE already has the expressive power to handle= the scenario described here, and is applicable to a wider range of scenari= os. The main point the draft brings to the table is the ability for a front= end to delegate to a backend a lot of logic that in the code+PKCE case executes in an environment that is nat= urally more constrained and prone to attacks than a backend. That doesn=92t= mean developers whose app has a backend should automatically choose the ne= w model over code+PKCE, more that the model discussed here might be viable and require less capabilities/mov= ing parts to achieve the same expressive power, especially if the SDKs used= in the solution have a standard way to handle it. That is far from every a= pp, but it is a situation I encountered in the wild often enough to prompt the discussion with Brian and the draft= .

 

As a side note, the initial reactions of practitione= rs have been very positive. I am really hoping the discussion will lead to = identifying and weeding out security issues, or land on security flaws in t= he model so grave that they can be properly used to discourage its use. No matter what way it will go, I am v= ery glad the discussion is taking place.

 

From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, Febr= uary 14, 2021 at 12:59
To: Vittorio Berto= cci <vittorio.bertocci@auth0.com>
Cc: Neil Madden &l= t;neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@i= etf.org>
Subject: Re: [OAUT= H-WG] Token Mediating and session Information Backend For Frontend (TMI BFF= )

 

To restate, the TMI-BFF proposal is not trying to fi= x any of that... it=92s definitely not a top level driver.

Great, then we are back to: what is the top level dr= iver. Because, while I appreciate the circumstances around ITP2.1~ as I ful= ly understand how identity providers like Auth0 are using iframes and third= party cookies, this problem vanishes with the use of first-party domains. So let's skip the digression and assu= me we aren't solving ITP future related issues.

 

The real problem I have with the draft is that it es= sentially suggests that every app needs to run a BFF to do user token gener= ation because an AS is no longer afforded the capability for some reason. I= f we pull in expecting to solve ITP related issues then I think that justification is in play and we can = work together to come up with a solution, rather than starting with the cur= rent deleterious prevalent pattern on the internet (which honestl= y is the most ridiculous paradigm I have seen). If we don't assume ITP is an issue, then I fail to see the core problem th= at existing AS have (as you pointed out code+PKCE already works) without th= e front channel or back channel needing really to make any additional chang= es.

 

I assume there is a flaw in my reasoning somewhere, = so please help me find it.

 

- Warren

 

3D"Image

Warren Parad

Founder, CTO

 =

 

On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci &l= t;vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=

Let me rewind a bit here. This was never presented a= s driving use case.

 

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

 

--_000_CO6PR18MB4052599253874EE042B4DECDAE889CO6PR18MB4052namp_-- From nobody Mon Feb 15 00:32:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C1D3A0E63 for ; Mon, 15 Feb 2021 00:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=Yf7jwnWL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VA8hxWkV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw2DrvQbTY8J for ; Mon, 15 Feb 2021 00:32:40 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473803A0E61 for ; Mon, 15 Feb 2021 00:32:40 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 621CBAAE; Mon, 15 Feb 2021 03:32:39 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 15 Feb 2021 03:32:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=5Mx5BiTqYkVdI371TkHH0z10rte1ZhWBRuHxUlNub/k=; b=Yf7jwnWLjXZ9 tmYGAuzOuh2fAohZXcKP27RcnXz2c8ma4QTW3rjA0wTBiLBltWkGXbaAE8pHEk72 Y04Qdm2xzRP+uxBdH4x6htNGOO7G5/yf89gKb0kve1o78QWMj6I5MD2ZcxeFRkhb edXoPD14A6LmphjC0pNLQo1jsatO5beSMJIiVY1oa/qejI3umuKKF+NfW++xVFqN 45/Xh9QvbT6rqHXyYfM+LahaBS2+dgmk66vXw4lZ0M0y18ORlmYdIODRt9w+ACn6 gD50biTN+10hZeoB9RwdEcN+kaEvXI6W47k7gWnSTjuCbcZVlY9ckn6RnZVFwEyn 4691EFn9Iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5Mx5Bi TqYkVdI371TkHH0z10rte1ZhWBRuHxUlNub/k=; b=VA8hxWkVPEXbbhO61EJMGk Th+4cyfDbYD9IMi5ROw8TKMb0o8r3WhzXFgGnvltlBz8XCIr8hNhA+nxSmzQyP5v AOBVqafn2//319t/1A6++hPGx9P/qYf3Xk4Li4MaCDYgJ9RWZAtMWfN1uruR2p82 1tKp08Ieg5zHmLOoquSdvDEZJfXaCn0xvXO4fSOGs2WmMO/xqCSllWB5/V+K2+JM rNBt2sgIkG8YIdowqEf8VZJcrDPX/2V8dJqyI9b2cS3r7Tnwnyyg/BJccLs7kByd xa722jduybVJX80Y15ThrcX8jq6kufkmKVm/UI/LSgrdFHHNMTutNtTPp9GIb7Ww == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieejgdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenog fuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefhkfgtggfuffgjvfhfofes rgdtmherhhdtjeenucfhrhhomheprfhhihhlihhpphgvucffvgcutfihtghkuceophhhih hlihhpphgvsehprhgrghhmrghtihgtfigvsghsvggtuhhrihhthidrtghomheqnecuggft rfgrthhtvghrnhephfdtjeeuffetvdegjeehieehleettdeiudeitefggfevgeeuteefte elhfeljeevnecuffhomhgrihhnpehprhgrghhmrghtihgtfigvsghsvggtuhhrihhthidr tghomhdpghhoohhglhgvrdgtohhmpdhgrghllhgvrhihrdhvihguvghopdgruhhthhhrvg hsshdrihhopdhgohhoghhlvghsohhurhgtvgdrtghomhdprghsphdrnhgvthdpihgvthhf rdhorhhgpdhfohhrghgvrhhotghkrdgtohhmnecukfhppeekuddrudeigedruddvledrle ehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhh ihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvggtuhhrihhthidrtghomh X-ME-Proxy: Received: from [192.168.1.10] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 5438E1080057; Mon, 15 Feb 2021 03:32:37 -0500 (EST) From: Philippe De Ryck Message-Id: <43B559AA-D888-4E8D-8F82-4226676AC536@pragmaticwebsecurity.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B5C10186-89EF-4408-9901-B808F87E2D24" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 15 Feb 2021 09:32:35 +0100 In-Reply-To: Cc: Warren Parad , "oauth@ietf.org" To: Vittorio Bertocci References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 08:32:46 -0000 --Apple-Mail=_B5C10186-89EF-4408-9901-B808F87E2D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Feb 2021, at 08:50, Vittorio Bertocci = wrote: >=20 > Thank you Philippe for your comments! Some considerations: > It also aims to avoid the need for a reverse proxy-based BFF, but = comes up short compared to such a BFF. > That isn=E2=80=99t a goal. If the developer can use a reverse proxy, = they should definitely go for it. Not getting tokens in the user agent = at all is the safest option. TMI-BFF is for the cases where it is not a = viable option- thru the threads I mentioned some of those cases. OK, seems that I got thrown off by the introduction. Adding a section to = describe these architectural patterns and their trade-offs could = definitely help to scope this spec. > Section 6.1 states not to use localStorage (I assume because of = malicious JS code),=E2=80=A6 > We might have been na=C3=AFve there- a common discussion point even = when considering code+PKCE is that local storage is somehow vulnerable = to more exploits than memory. > If there are attacks that only work with storage but not with memory, = this would be an incremental improvement. If every attack that can = access the storage can also access memory, then I agree it=E2=80=99s a = moot point- but then the current public discourse needs a severe reset = given that the two options are presented as having very different = security properties. Welcome to my life :) Let me try to give an analogy to frame this problem a bit. You're = worried about burglars breaking into your home, so instead of leaving = jewellery on the kitchen table, you lock it away in a safe. Rookie = burglars will break in, and not find anything on the kitchen table, and = be stumped on how to proceed. However, a veteran burglar probably knows = where to find your safe. If they can't unlock the safe, they can just = hide behind the door until you open your safe, hit you on the head with = a bat, and take your jewellery. In essence, removing valuables from the = kitchen table only addresses a consequence, but not the underlying = problem. The same applies to malicious JS and localStorage. Going after data in = localStorage is an easy and simple attack. It's what a script kiddie = would do when they have no idea what they are really doing. However, a = targeted attack will not be hampered by that. They can apply the = following techniques: Override any JS function used by the legitimate application for handling = the token (e.g., setRequestHeader) Send a request to the backend to obtain an access token (this would be = indistinguishable from a legitimate request) Without the use of a TMI-BFF, the attacker would also be able to run a = silent flow to obtain a new set of tokens from the AS. Moving to a = confidential client, as the spec proposes, addresses this major = vulnerability. Note that "in memory" here means "in memory of the application's = execution context". A web worker runs in a separate context and is = isolated by design. > you lose the ability to use sender constrained tokens, which a proxy = BFF would be able to do > Absolutely. If the reverse proxy is an option, the security improves = for sure. TMI-BFF is meant to help when it is not an option. See the note above about a separate section on the trade-offs.=20 > Keeping refresh tokens on the backend is good, but not necessarily = better than keeping them in a web worker, as Auth0=E2=80=99s JS SDK > A web worker is definitely good practice, but it=E2=80=99s still on = the local machine. One might argue it=E2=80=99s enough security for the = scenario, but not the same as not having the tokens available at all in = the local box. But as you say, the thrust behind TMI-BFF is more about = dev experience- I=E2=80=99d be happy with equivalent security with = code+PKCE+RTs I get the impression that this spec lacks a concrete threat model. A = worker is an isolated environment in the browser. If the local machine = is considered untrusted, then what about the user's credentials that are = entered on that machine, or the U2F/WebAuthN authentication used for = MFA? The local machine is part of the TCB here, and that includes the = browser and its extensions. So I'd say that RTs in such an environment = are properly secured. Also, since workers live in memory only, RTs for a = frontend web should have a similar lifetime as a traditional session = (e.g., 12 hours). Compared to using a worker for handling RTs, I believe the TMI-BFF only = adds a single security benefit: an attacker is no longer able to run a = silent flow to obtain a fresh set of tokens (since the client is now a = confidential client).=20 Hope this helps Philippe > =20 > From: Philippe De Ryck > Date: Sunday, February 14, 2021 at 22:45 > To: Vittorio Bertocci > Cc: Warren Parad , "oauth@ietf.org" > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > A couple of notes from my end: > =20 > Developers building an application that consists of a frontend, a = backend, and APIs indeed often struggle with identifying the correct = client, especially with the combination of OAuth 2.0 and OIDC. Having a = standardized way of handling such cases is definitely useful.=20 > =20 > That said, the current spec is a bit all over the place. Vittorio = stated here that the main goal is to make it easier for developers, but = the spec makes quite a bit of (vague) security statements. It also aims = to avoid the need for a reverse proxy-based BFF, but comes up short = compared to such a BFF.=20 > =20 > A few detailed security notes: > =20 > 1) Section 6.1 states not to use localStorage (I assume because of = malicious JS code), which makes no sense. If malicious code is running = in the frontend, it can simply call the bff-token endpoint and grab the = token from there. Other attacks typically also allow to steal tokens = from memory (e.g., prototype pollution attacks as I discuss here: = https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html = ).=20 > =20 > 2) The use of confidential clients is a big plus, but since the access = token is used in the frontend, you lose the ability to use sender = constrained tokens, which a proxy BFF would be able to do. A proxy-based = BFF can also limit the API endpoints it exposes to a specific frontend = and can apply traffic analysis to detect malicious behavior from a = compromised frontend. > =20 > 3) Keeping refresh tokens on the backend is good, but not necessarily = better than keeping them in a web worker, as Auth0=E2=80=99s JS SDK (and = presumably others, haven=E2=80=99t checked) does by default.=20 > =20 > Overall, my recommendation is to focus on the specific use case of = handling tokens in a =E2=80=9Cfrontend with backend=E2=80=9D application = type, and forget about trying to also solve security issues in frontends = caused by malicious JS. > =20 > Philippe > =20 > =20 > =E2=80=94 > Pragmatic Web Security > Security for developers > https://pragmaticwebsecurity.com/ >=20 >=20 > On 14 Feb 2021, at 22:31, Vittorio Bertocci = > wrote: > =20 > Draft [..] essentially suggests that every app needs to run a BFF to = do user token generation because an AS is no longer afforded the = capability for some reason > I believe this might be the crux of the problem, my impression is that = you are attributing to the draft a way larger scope than it is intended = to have. The draft makes no such suggestion. The draft says nothing = about AS losing capabilities. The draft is not trying to solve an AS = problem. And above all, the draft does not target every app.=20 > =20 > The draft is an optimization aimed at a very specific, albeit very = common, application topology where there is a frontend and a backend, = and the developer wants to perform API calls from the frontend directly = to the RS. This is only a specific topology, and the proposal is scoped = down to that. All other topologies are unaffected. Also, the draft = isn=E2=80=99t pushing this topology as the preferred one. It=E2=80=99s = best to keep tokens out of the frontend altogether. But if the developer = is adamant in performing API calls direct from their JS, and if they = already have a backend, and only in that case, the current proposal has = less moving parts and less requirements than code+PKCE . > =20 > Code+PKCE already has the expressive power to handle the scenario = described here, and is applicable to a wider range of scenarios. The = main point the draft brings to the table is the ability for a frontend = to delegate to a backend a lot of logic that in the code+PKCE case = executes in an environment that is naturally more constrained and prone = to attacks than a backend. That doesn=E2=80=99t mean developers whose = app has a backend should automatically choose the new model over = code+PKCE, more that the model discussed here might be viable and = require less capabilities/moving parts to achieve the same expressive = power, especially if the SDKs used in the solution have a standard way = to handle it. That is far from every app, but it is a situation I = encountered in the wild often enough to prompt the discussion with Brian = and the draft. > =20 > As a side note, the initial reactions of practitioners have been very = positive. I am really hoping the discussion will lead to identifying and = weeding out security issues, or land on security flaws in the model so = grave that they can be properly used to discourage its use. No matter = what way it will go, I am very glad the discussion is taking place. > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 12:59 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > To restate, the TMI-BFF proposal is not trying to fix any of that... = it=E2=80=99s definitely not a top level driver. > Great, then we are back to: what is the top level driver. Because, = while I appreciate the circumstances around ITP2.1~ as I fully = understand how identity providers like Auth0 are using iframes and = thirdparty cookies, this problem vanishes with the use of first-party = domains. So let's skip the digression and assume we aren't solving ITP = future related issues. > =20 > The real problem I have with the draft is that it essentially suggests = that every app needs to run a BFF to do user token generation because an = AS is no longer afforded the capability for some reason. If we pull in = expecting to solve ITP related issues then I think that justification is = in play and we can work together to come up with a solution, rather than = starting with the current deleterious prevalent pattern on the internet = (which honestly is the most ridiculous paradigm I have seen). If we = don't assume ITP is an issue, then I fail to see the core problem that = existing AS have (as you pointed out code+PKCE already works) without = the front channel or back channel needing really to make any additional = changes. > =20 > I assume there is a flaw in my reasoning somewhere, so please help me = find it. > =20 > - Warren > =20 >=20 > Warren Parad > Founder, CTO > =20 > =20 > On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci = > wrote: > Let me rewind a bit here. This was never presented as driving use = case. > =20 > Neil suggested that the backend could simply give short lived JTWs for = the frontent to call API. > I clarified that this would not be viable in the general case and = provided an example scenario where backend issued short lived tokens = would not have worked > You commented that the frontend can obtain AS tokens from JS and = mentioned silent authentication. I clarified (or tried to) that this = offshoot of the discussion wasn=E2=80=99t to say that there is no viable = way of doing the scenario already, and by the way using an iFrame to do = silent authentication is now problematic. At this point we are no longer = discussing TMI-BFF, but current affairs in the authentication world. The = fact that we are proposing TMI-BFF and the fact that silent = authentication is less and less viable are independent facts, the former = isn=E2=80=99t meant to be a solution for the latter (it=E2=80=99s = already addressed by using RTs in coke+PKCE) > =20 > That clarified. Not only we expect ITP to affect silent = authentication, it has been affected for the past year and that has been = one of the primary business drivers for the rapid adoption of = code+PKCE+RTs in the user agent, as customers with pure SPAs found = themselves unable to renew tokens without prompting as their access to = cookies in flows driven by iframes became less and less reliable. > When ITP was introduced we put many companies together to try to get = Apple to change it (you can find the doc in = https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7s= KsaiU/edit#heading=3Dh.p3nvp6xmxvzf = ) but they didn=E2=80=99t bulge and = ultimately the introduction of RTs in user agent code (albeit with extra = restrictions, the one I mentioned not everyone is following) made the = problem manageable. We have an initiative cross working groups (IETF, = OIDC etc)for working with browser vendors to try containing similar = regressions in the future. For a summary of similar problems see = https://identiverse.gallery.video/detail/video/6184443037001/browser-featu= res-vs-identity-protocols = . =20 > =20 > To restate, the TMI-BFF proposal is not trying to fix any of that, nor = per the above some of it need fixing. The only indirect connection might = be that less stuff happening in the user agent means less opportunities = for similar changes to impact the flows, but it=E2=80=99s definitely not = a top level driver. > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 11:41 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > That only applies to third party cookies, it shouldn't affect = third-party iframes as far as I'm aware. So unless we expect those to = break, we probably shouldn't include that as a driving use case. Is = there another measure that would be relevant here? >=20 > Error! Filename not specified. > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . > =20 > =20 > On Sun, Feb 14, 2021 at 7:57 PM Vittorio Bertocci = > wrote: > ITP, for example > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 04:54 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > Can you expand on what silent authentication and session token stands = for here? If you are referring to the iframe scenario, the new browser = measures make it problematic. > Which new browser measures? >=20 > Error! Filename not specified. > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . > =20 > =20 > On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci = > wrote: > For UI related functionality, i.e. document selection, user profile = display/changes, contact updates, etc... You should be able to execute = the client side silent authentication using the provided session token = from the Azure AD AS, without needing to make any RO api calls nor user = redirects.=20 > Can you expand on what silent authentication and session token stands = for here? If you are referring to the iframe scenario, the new browser = measures make it problematic. In code+PKCE you can use a refresh token, = but see the other reply for how this proposal is an alternative to that = in some situations. This answer was specifically on why having = backend-issued tokens didn=E2=80=99t apply to this scenario. > =20 > =20 > From: Warren Parad > > Date: Sunday, February 14, 2021 at 03:48 > To: Vittorio Bertocci > > Cc: Neil Madden >, "oauth@ietf.org = " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > For the trusted part, see above. For the short lived JWTs, that=E2=80=99= s not really an option. The most generic scenario addressed here is for = APIs that accept tokens issued by the AS; the backend can request them = as a client, but it cannot mint them. Imagine we=E2=80=99re talking = about a SPA application that signs in users using Azure AD, and needs to = call Office and Azure APIs. The SPA backend cannot issue tokens for = those APIs, it can only request them to the Azure AD AS. > =20 > For UI related functionality, i.e. document selection, user profile = display/changes, contact updates, etc... You should be able to execute = the client side silent authentication using the provided session token = from the Azure AD AS, without needing to make any RO api calls nor user = redirects. For RO responsibilities, you can present the user with a = button "Grant RO access to Azure resources" button and the user will go = through a permission scope elevation flow, again no reason to need a BFF = here. > =20 > We did consider adding something to that effect, an error message that = can direct the frontend to perform the interactive portion necessary for = this topology to work. It would be something similar to the IDP = initiated login in OIDC, where the client offers an endpoint that is = guaranteed to initiate a sign in flow (hence inject all the necessary = nonces etc). We didn=E2=80=99t add it upfront and left it as exercise = for the reader mostly because it=E2=80=99s not easy to model properly = and before opening that work front we wanted to see how the idea was = received. =20 > It may make sense for the app to have an error message, or even better = might be a 302 Location header depending on what you are doing. There is = nothing here that is OAuth specific however (nor common), and then we = should challenge the need to directly provide an RFC recommendation for = handling this. > =20 > Error! Filename not specified. > Warren Parad > Founder, CTO > Secure your user data and complete your authorization architecture. = Implement Authress . > =20 > =20 > On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci = > wrote: > Hi Neil, > Thanks for the prompt comments! > Re: GET vs POST, > personally I=E2=80=99d be fine with restricting to POST. > =20 > Re: RO-AS, interaction-=20 > perhaps it is not very clear from the text at the moment (first = draft), but that is assumed that the RO went thru whatever interactive = steps are necessary to establish a session (eg sign in, assuming the AS = is say an OIDC provider) and obtain beforehand the access token and = refresh tokens that will be needed during the app activities taking = place after that. In concrete terms, imagine that the backend performs = an authorization code grant requesting an IDtoken, access token and = refresh token BEFORE the activities described in TMI-BFF take place. > The current language trying to express that is in 1.2: > As a prerequisite for the flow described below, the backend MUST have = established a secure session with the user agent, so that all requests = from that user agent toward the backend occur over HTTPS and carry a = valid session artifact (such as a cookie) that the backend can validate. = This document does not mandate any specific mechanism to establish and = maintain that session. > And > cached, it requests to the authorization server a new access token = with the required characteristics, using any artifacts previousy = obtained (eg refresh token) and grants that will allow the authorization = server to issue the requested token without requiring user interaction. > =20 > If the backend is already implicitly trusted then couldn=E2=80=99t = you skip OAuth and just get the backend to issue short-lived JWTs to the = frontend that it can use for API access? > For the trusted part, see above. For the short lived JWTs, that=E2=80=99= s not really an option. The most generic scenario addressed here is for = APIs that accept tokens issued by the AS; the backend can request them = as a client, but it cannot mint them. Imagine we=E2=80=99re talking = about a SPA application that signs in users using Azure AD, and needs to = call Office and Azure APIs. The SPA backend cannot issue tokens for = those APIs, it can only request them to the Azure AD AS. > =20 > If you want to allow auth code flow etc then perhaps the bff-token = endpoint can return a standard error code with an authorization endpoint = URI that the SPA then navigates the user to. (Eg the backend can do a = PAR request first and return a URI that references that so that = authorization details aren=E2=80=99t passed through the frontend).=20 > We did consider adding something to that effect, an error message that = can direct the frontend to perform the interactive portion necessary for = this topology to work. It would be something similar to the IDP = initiated login in OIDC, where the client offers an endpoint that is = guaranteed to initiate a sign in flow (hence inject all the necessary = nonces etc). We didn=E2=80=99t add it upfront and left it as exercise = for the reader mostly because it=E2=80=99s not easy to model properly = and before opening that work front we wanted to see how the idea was = received. =20 > =20 > From: OAuth > = on behalf of Neil Madden > > Date: Sunday, February 14, 2021 at 00:17 > To: Vittorio Bertocci > > Cc: "oauth@ietf.org " > > Subject: Re: [OAUTH-WG] Token Mediating and session Information = Backend For Frontend (TMI BFF) > =20 > I have a lot of security concerns about this draft.=20 > =20 > The draft alludes to security issues associated with handling access = tokens in the frontend but never really spells them out. =46rom the = Security Considerations it seems that the primary concern is with theft = of access tokens from local storage. To do this you=E2=80=99d need an = XSS attack. But in that case, wouldn=E2=80=99t the attacker simply use = the XSS to make a call to the bff-token endpoint instead?=20 > =20 > The combination of the bff-token endpoint recommending the use of GET = requests together with the hint to use cookie-based authentication is = likely going to punch a hole in most CSRF defenses, which assume that = GETs are safe. The only thing preventing this being exploitable is = Cross-Origin Read Blocking = (https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md = ) due to the JSON content-type. = That makes me really nervous. We should at least mandate = X-Content-Type-Options: nosniff on that response. I=E2=80=99d feel more = comfortable if this was a POST request only.=20 > =20 > As Stoycho Sleptsov mentioned in the other email, the lack of = front-channel communication between the AS and the RO seems odd. If the = backend is already implicitly trusted then couldn=E2=80=99t you skip = OAuth and just get the backend to issue short-lived JWTs to the frontend = that it can use for API access? > =20 > If you want to allow auth code flow etc then perhaps the bff-token = endpoint can return a standard error code with an authorization endpoint = URI that the SPA then navigates the user to. (Eg the backend can do a = PAR request first and return a URI that references that so that = authorization details aren=E2=80=99t passed through the frontend).=20 > =20 > =E2=80=94 Neil > =20 > =20 >=20 > On 12 Feb 2021, at 20:46, Vittorio Bertocci = > wrote: >=20 > =EF=BB=BFDear all, > Brian and yours truly are proposing a new specification that shows how = the user agent frontend of a web app can delegate token acquisition and = persistence to its backend, and request such tokens when needed for = direct access of protected resources from the frontend code. >=20 > The pattern is already in use, in proprietary form, by various modern = development stacks, such as Next.JS. Variants of the pattern, often = discussed under the catch-all term BFF (backend for frontend), have been = often mentioned in this workgroup=E2=80=99s activity, but always left = all implementation details to the reader. > We believe the pattern has merit, as corroborated by its growing = adoption. By delegating access token acquisition to the backend, we = avoid many of the often brittle moving parts (and implied attack = surface) required to acquire access tokens from a user agent. The = topology also relieves the frontend from the need of persisting tokens = in local storage, a well known sore point of using OAuth directly in = JavaScript, by relying on its backend storage and session to preserve = tokens. >=20 > Although the specification is very simple, providing explicit guidance = on the scenario offers many advantages. =20 > - It makes it possible to create interoperable SDKs, where frontend = dev stacks (any JS flavor) can be mixed and matched with compliant = backend stacks (middlewares in node, java, ASP.NET , = PHP etc) > - It allows us to provide guidance on how to properly tackle the = scenario and warn implementers against security risks (scope = escalations, using IDtokens instead of access tokens, etc) > - It allows us to discuss (and when appropriate, promote) this pattern = as part of the browser apps security guidance, and position the scenario = where frontend only calls API on its own backed (hence doesn=E2=80=99t = need access tokens) simply as a special case of this more general = pattern > - This approach makes mocking and testing apps very easy, possibly = preventing developers from weakening the security of their system (eg = turning on ROPG options) or turning to risky practices like scraping >=20 > Needless to say, this specification doesn=E2=80=99t entirely eliminate = the risks inherent to direct use of access tokens from a browser. But = reality is that the pattern is in widespread use, and the circumstances = leading to that (eg developers on a particular project only work with = frontend stacks; components like reverse proxies might not always be = viable; etc) aren=E2=80=99t going away any time soon. By providing = simple guidance on this pattern, we can simplify the life of many = developers while enshrining basic security hygiene in scenarios that = would have otherwise be left to their own device. >=20 > Looking forward for your feedback! >=20 > B&V =20 >=20 > =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org = " > wrote: >=20 >=20 > A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt > has been successfully submitted by Vittorio Bertocci and posted to = the > IETF repository. >=20 > Name: draft-bertocci-oauth2-tmi-bff > Revision: 00 > Title: Token Mediating and session Information Backend For = Frontend > Document date: 2021-02-12 > Group: Individual Submission > Pages: 16 > URL: = https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ = > Html: = https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html = > Htmlized: = https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 = >=20 >=20 > Abstract: > This document describes how a JavaScript frontend can delegate = access > token acquisition to a backend component. In so doing, the = frontend > can access resource servers directly without taking on the = burden of > communicating with the authorization server, persisting tokens, = and > performing operations that are fraught with security challenges = when > executed in a user agent, but are safe and well proven when = executed > by a confidential client running on a backend. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > ForgeRock values your Privacy > _______________________________________________ > OAuth mailing 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=_B5C10186-89EF-4408-9901-B808F87E2D24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 15 Feb 2021, at 08:50, Vittorio Bertocci <vittorio.bertocci@auth0.com> wrote:

Thank you = Philippe for your comments! Some considerations:
  • It = also aims to avoid the need for a reverse proxy-based BFF, but comes up = short compared to such a BFF.
That isn=E2=80=99t a goal. If the = developer can use = a reverse proxy, they should definitely go for it. Not getting tokens in = the user agent at all is the safest option. TMI-BFF is for the cases = where it is not a viable option- thru the threads I mentioned some of = those cases.

OK, seems that I got thrown off by the = introduction. Adding a section to describe these architectural patterns = and their trade-offs could definitely help to scope this = spec.


  • Section 6.1 states not to use localStorage (I assume = because of malicious JS code),=E2=80=A6
We might = have been na=C3=AFve there- a common discussion point even when = considering code+PKCE is that local storage is somehow vulnerable to = more exploits than memory.
If there are attacks that only work = with storage but not with memory, this would be an incremental = improvement. If every attack that can access the storage can also access = memory, then I agree it=E2=80=99s a moot point- but then the current = public discourse needs a severe reset given that the two options are = presented as having very different security = properties.

Welcome to = my life :)

Let me try to give an = analogy to frame this problem a bit. You're worried about burglars = breaking into your home, so instead of leaving jewellery on the kitchen = table, you lock it away in a safe. Rookie burglars will break in, and = not find anything on the kitchen table, and be stumped on how to = proceed. However, a veteran burglar probably knows where to find your = safe. If they can't unlock the safe, they can just hide behind the door = until you open your safe, hit you on the head with a bat, and take your = jewellery. In essence, removing valuables from the kitchen table only = addresses a consequence, but not the underlying problem.

The same applies to malicious JS and localStorage. = Going after data in localStorage is an easy and simple attack. It's what = a script kiddie would do when they have no idea what they are really = doing. However, a targeted attack will not be hampered by that. They can = apply the following techniques:
  • Override any JS function used by the legitimate application = for handling the token (e.g., setRequestHeader)
  • Send = a request to the backend to obtain an access token (this would be = indistinguishable from a legitimate request)

Without the use of a TMI-BFF, the = attacker would also be able to run a silent flow to obtain a new set of = tokens from the AS. Moving to a confidential client, as the spec = proposes, addresses this major vulnerability.

Note that "in memory" = here means "in memory of the application's execution context". A web = worker runs in a separate context and is isolated by = design.

  • you lose the ability = to use sender constrained tokens, which a proxy BFF would be able to = do
Absolutely. If the reverse proxy is an option, the security = improves for sure. TMI-BFF is meant to help when it is not an = option.

See the = note above about a separate section on the = trade-offs. 


  • Keeping refresh tokens on the backend is good, but not = necessarily better than keeping them in a web worker, as Auth0=E2=80=99s = JS SDK
A= web worker is definitely good practice, but it=E2=80=99s still on the = local machine. One might argue it=E2=80=99s enough security for the scenario, = but not the same as not having the tokens available at all in the local = box. But as you say, the thrust behind TMI-BFF is more about dev = experience- I=E2=80=99d be happy with equivalent security with = code+PKCE+RTs

I = get the impression that this spec lacks a concrete threat model. A = worker is an isolated environment in the browser. If the local machine = is considered untrusted, then what about the user's credentials that are = entered on that machine, or the U2F/WebAuthN authentication used for = MFA? The local machine is part of the TCB here, and that includes the = browser and its extensions. So I'd say that RTs in such an environment = are properly secured. Also, since workers live in memory only, RTs for a = frontend web should have a similar lifetime as a traditional session = (e.g., 12 hours).

Compared to using a worker for handling RTs, I believe the = TMI-BFF only adds a single security benefit: an attacker is no longer = able to run a silent flow to obtain a fresh set of tokens (since the = client is now a confidential client). 

Hope this helps

Philippe


 
From: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Date: Sunday, February 14, = 2021 at 22:45
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Warren Parad <wparad@rhosys.ch>, = "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI BFF)
 
A couple of notes from my end:
 
Developers building an application that consists of a = frontend, a backend, and APIs indeed often struggle with identifying the = correct client, especially with the combination of OAuth 2.0 and OIDC. = Having a standardized way of handling such cases is definitely = useful. 
 
That said, the current spec is a bit all over the place. = Vittorio stated here that the main goal is to make it easier for = developers, but the spec makes quite a bit of (vague) security = statements. It also aims to avoid the need for a reverse proxy-based = BFF, but comes up short compared to such a BFF. 
 
A few detailed security notes:
 
1) Section 6.1 states not to use = localStorage (I assume because of malicious JS code), which makes no = sense. If malicious code is running in the frontend, it can simply call = the bff-token endpoint and grab the token from there. Other attacks = typically also allow to steal tokens from memory (e.g., prototype = pollution attacks as I discuss here: https://pragmaticwebsecurity.com/articles/oauthoidc/localstorag= e-xss.html). 
 
2) The use of confidential clients is a big plus, but since = the access token is used in the frontend, you lose the ability to use = sender constrained tokens, which a proxy BFF would be able to do. A = proxy-based BFF can also limit the API endpoints it exposes to a = specific frontend and can apply traffic analysis to detect malicious = behavior from a compromised frontend.
 
3) Keeping refresh tokens on the = backend is good, but not necessarily better than keeping them in a web = worker, as Auth0=E2=80=99s JS SDK (and presumably others, haven=E2=80=99t = checked) does by default. 
 
Overall, my recommendation is to focus on the specific use = case of handling tokens in a =E2=80=9Cfrontend with backend=E2=80=9D = application type, and forget about trying to also solve security issues = in frontends caused by malicious JS.
 
Philippe
 
 
=E2=80=94

Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/



On 14 Feb 2021, at 22:31, Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> = wrote:
 
  • Draft [..] = essentially suggests that every app needs to run a BFF to do user token = generation because an AS is no longer afforded the capability for some = reason
I believe this might be the crux of the = problem, my impression is that you are attributing to the draft a way = larger scope than it is intended to have. The draft makes no such = suggestion. The draft says nothing about AS losing capabilities. The = draft is not trying to solve an AS problem. And above all, the draft = does not target every app. 
 
The draft is an optimization aimed = at a = very specific, albeit very common, application topology where there = is a frontend and a backend, and the developer wants to perform API = calls from the frontend directly to the RS. This is only a specific = topology, and the proposal is scoped down to that. All other topologies = are unaffected. Also, the draft isn=E2=80=99t pushing this topology as = the preferred one. It=E2=80=99s best to keep tokens out of the frontend = altogether. But if the developer is adamant in performing API calls = direct from their JS, and if they already have a backend, and only in = that case, the current proposal has less moving parts and less = requirements than code+PKCE .
 
Code+PKCE already has the expressive power to handle the = scenario described here, and is applicable to a wider range of = scenarios. The main point the draft brings to the table is the ability = for a frontend to delegate to a backend a lot of logic that in the = code+PKCE case executes in an environment that is naturally more = constrained and prone to attacks than a backend. That doesn=E2=80=99t = mean developers whose app has a backend should automatically choose the = new model over code+PKCE, more that the model discussed here might be = viable and require less capabilities/moving parts to achieve the same = expressive power, especially if the SDKs used in the solution have a = standard way to handle it. That is far from every app, but it is a = situation I encountered in the wild often enough to prompt the = discussion with Brian and the draft.
 
As a side note, the initial reactions of practitioners have = been very positive. I am really hoping the discussion will lead to = identifying and weeding out security issues, or land on security flaws = in the model so grave that they can be properly used to discourage its = use. No matter what way it will go, I am very glad the discussion is = taking place.
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 12:59
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
To restate, the TMI-BFF = proposal is not trying to fix any of that... it=E2=80=99s definitely not = a top level driver.
Great, = then we are back to: what is the top level driver. Because, while I = appreciate the circumstances around ITP2.1~ as I fully understand how = identity providers like Auth0 are using iframes and = thirdparty cookies, this problem vanishes with the use of = first-party domains. So let's skip the digression and assume we aren't = solving ITP future related issues.
 
The real problem I have with the draft = is that it essentially suggests that every app needs to run a BFF to do = user token generation because an AS is no longer afforded the capability = for some reason. If we pull in expecting to solve ITP related issues = then I think that justification is in play and we can work together = to come up with a solution, rather than starting with the current = deleterious prevalent pattern on the internet (which honestly = is the most ridiculous paradigm I have seen). If we don't assume ITP is = an issue, then I fail to see the core problem that existing AS have (as = you pointed out code+PKCE already works) without the front channel or = back channel needing really to make any additional changes.
 
I assume there is a flaw in my = reasoning somewhere, so please help me find it.
 
- Warren
 
3D"Image
Warren Parad
Founder, CTO
<= /div>
 
 
On Sun, = Feb 14, 2021 at 9:20 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
Let me rewind a bit here. This was = never presented as driving use case.
 
  • Neil suggested that the backend could = simply give short lived JTWs for the frontent to call API.
  • I clarified that this would not be = viable in the general case and provided an example scenario where = backend issued short lived tokens would not have worked
  • You commented that the frontend can = obtain AS tokens from JS and mentioned silent authentication. I = clarified (or tried to) that this offshoot of the discussion wasn=E2=80=99= t to say that there is no viable way of doing the scenario already, and = by the way using an iFrame to do silent authentication is now = problematic. At this point we are no longer discussing TMI-BFF, but = current affairs in the authentication world. The fact that we are = proposing TMI-BFF and the fact that silent authentication is less and = less viable are independent facts, the former isn=E2=80=99t meant to be = a solution for the latter (it=E2=80=99s already addressed by using RTs = in coke+PKCE)
 
That clarified. Not only we expect ITP to affect silent = authentication, it has been affected for the past year and that has been = one of the primary business drivers for the rapid adoption of = code+PKCE+RTs in the user agent, as customers with pure SPAs found = themselves unable to renew tokens without prompting as their access to = cookies in flows driven by iframes became less and less reliable.
When ITP was introduced we put many companies together to try = to get Apple to change it (you can find the doc in https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0r= a3viMEHrK7sKsaiU/edit#heading=3Dh.p3nvp6xmxvzf) but they = didn=E2=80=99t bulge and ultimately the introduction of RTs in user = agent code (albeit with extra restrictions, the one I mentioned not = everyone is following) made the problem manageable. We have an = initiative cross working groups (IETF, OIDC etc)for working with browser = vendors to try containing similar regressions in the future. For a = summary of similar problems see https://identiverse.gallery.video/detail/video/6184443037001/br= owser-features-vs-identity-protocols.  
 
To restate, the TMI-BFF proposal is not = trying to fix any of that, nor per the above some of it need fixing. The = only indirect connection might be that less stuff happening in the user = agent means less opportunities for similar changes to impact the flows, = but it=E2=80=99s definitely not a top level driver.
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 11:41
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
That only applies to third party = cookies, it shouldn't affect third-party iframes as far as I'm aware. So = unless we expect those to break, we probably shouldn't include = that as a driving use case. Is there another measure that would be = relevant here?

Error! Filename not = specified.
Warren Parad
Founder, CTO
Secure your user data and complete your = authorization architecture. Implement Authress.
 
 
On Sun, Feb 14, 2021 at = 7:57 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
ITP, for example
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 04:54
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
Can you expand on what silent authentication and session = token stands for here? If you are referring to the iframe scenario, the = new browser measures make it problematic.
Which new browser = measures?

Error! Filename not = specified.
Warren Parad
Founder, CTO
Secure your user data and complete your = authorization architecture. Implement Authress.
 
 
On Sun, = Feb 14, 2021 at 1:33 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
  • For UI related functionality, i.e. document selection, user = profile display/changes, contact updates, etc... You should be able to = execute the client side silent = authentication using the provided session token from the Azure = AD AS, without needing to make any RO api calls nor user = redirects. 
Can you expand on what silent = authentication and session token stands for here? If you are referring = to the iframe scenario, the new browser measures make it problematic. In = code+PKCE you can use a refresh token, but see the other reply for how = this proposal is an alternative to that in some situations. This answer = was specifically on why having backend-issued tokens didn=E2=80=99t = apply to this scenario.
 
 
From: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Date: Sunday, February 14, = 2021 at 03:48
To: Vittorio Bertocci = <vittorio.bertocci@auth0.com>
Cc: Neil = Madden <neil.madden@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
For the trusted part, see above. For the short lived JWTs, = that=E2=80=99s not really an option. The most generic scenario addressed = here is for APIs that accept tokens issued by the AS; the backend can = request them as a client, but it cannot mint them. Imagine we=E2=80=99re = talking about a SPA application that signs in users using Azure AD, and = needs to call Office and Azure APIs. The SPA backend cannot issue tokens = for those APIs, it can only request them to the Azure AD AS.
 
For UI related functionality, i.e. = document selection, user profile display/changes, contact updates, = etc... You should be able to execute the client side silent = authentication using the provided session token from the Azure = AD AS, without needing to make any RO api calls nor user = redirects. For RO responsibilities, you can present the user with a = button "Grant RO access to Azure resources" button and the user will go = through a permission scope elevation flow, again no reason to need = a BFF here.
 
We did consider adding something to that effect, an error = message that can direct the frontend to perform the interactive portion = necessary for this topology to work. It would be something similar to = the IDP initiated login in OIDC, where the client offers an endpoint = that is guaranteed to initiate a sign in flow (hence inject all the = necessary nonces etc). We didn=E2=80=99t add it upfront and left it as = exercise for the reader mostly because it=E2=80=99s not easy to model = properly and before opening that work front we wanted to see how the = idea was received.  
It may make sense for the = app to have an error message, or even better might be a 302 Location = header depending on what you are doing. There is nothing here = that is OAuth specific however (nor common), and then we should = challenge the need to directly provide an RFC recommendation for = handling this.
 
Error! Filename not specified.
Warren Parad
Founder, CTO
Secure your user data and complete your = authorization architecture. Implement Authress.
 
 
On Sun, = Feb 14, 2021 at 12:29 PM Vittorio Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:
Hi Neil,
Thanks for the prompt comments!
  • Re: GET vs POST,
personally I=E2=80=99d be = fine with restricting to POST.
 
  • Re: RO-AS, interaction- 
perhaps it is not very clear from the text at the moment = (first draft), but that is assumed that the RO went thru whatever = interactive steps are necessary to establish a session (eg sign in, = assuming the AS is say an OIDC provider) and obtain beforehand the = access token and refresh tokens that will be needed during the app = activities taking place after  that. In concrete terms, imagine = that the backend performs an authorization code grant requesting an = IDtoken, access token and refresh token BEFORE the activities described = in TMI-BFF take place.
The current language = trying to express that is in 1.2:
As a prerequisite for = the flow described below, the backend MUST have established a secure = session with the user agent, so that all requests from that user agent = toward the backend occur over HTTPS and carry a valid session artifact = (such as a cookie) that the backend can validate. This document does not = mandate any specific mechanism to establish and maintain that = session.
And
cached, it requests to = the authorization server a new access token with the required = characteristics, using any artifacts previousy obtained (eg refresh = token) and grants that will allow the authorization server to issue the = requested token without requiring user interaction.
 
  •  If the = backend is already implicitly trusted then couldn=E2=80=99t you skip = OAuth and just get the backend to issue short-lived JWTs to the frontend = that it can use for API access?
For the trusted part, see = above. For the short lived JWTs, that=E2=80=99s not really an option. = The most generic scenario addressed here is for APIs that accept tokens = issued by the AS; the backend can request them as a client, but it = cannot mint them. Imagine we=E2=80=99re talking about a SPA application = that signs in users using Azure AD, and needs to call Office and Azure = APIs. The SPA backend cannot issue tokens for those APIs, it can only = request them to the Azure AD AS.
 
  • If you want to allow auth code flow = etc then perhaps the bff-token endpoint can return a standard error code = with an authorization endpoint URI that the SPA then navigates the user = to. (Eg the backend can do a PAR request first and return a URI that = references that so that authorization details aren=E2=80=99t passed = through the frontend). 
We did consider adding = something to that effect, an error message that can direct the frontend = to perform the interactive portion necessary for this topology to work. = It would be something similar to the IDP initiated login in OIDC, where = the client offers an endpoint that is guaranteed to initiate a sign in = flow (hence inject all the necessary nonces etc). We didn=E2=80=99t add = it upfront and left it as exercise for the reader mostly because it=E2=80=99= s not easy to model properly and before opening that work front we = wanted to see how the idea was received.  
 
From: OAuth <oauth-bounces@ietf.org> on behalf of = Neil Madden <neil.madden@forgerock.com>
Date: Sunday, February 14, = 2021 at 00:17
To: Vittorio Bertocci = <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token = Mediating and session Information Backend For Frontend (TMI = BFF)
 
I= have a lot of security concerns about this draft. 
 
The draft alludes to security issues = associated with handling access tokens in the frontend but never really = spells them out. =46rom the Security Considerations it seems that the = primary concern is with theft of access tokens from local storage. To do = this you=E2=80=99d need an XSS attack. But in that case, wouldn=E2=80=99t = the attacker simply use the XSS to make a call to the bff-token endpoint = instead? 
 
The combination of the bff-token = endpoint recommending the use of GET requests together with the hint to = use cookie-based authentication is likely going to punch a hole in most = CSRF defenses, which assume that GETs are safe. The only thing = preventing this being exploitable is Cross-Origin Read Blocking (https://chromium.googlesource.com/chromium/src/+/master/service= s/network/cross_origin_read_blocking_explainer.md) due to the = JSON content-type. That makes me really nervous. We should at least = mandate X-Content-Type-Options: nosniff on that response. I=E2=80=99d = feel more comfortable if this was a POST request only. 
 
As Stoycho Sleptsov mentioned in the = other email, the lack of front-channel communication between the AS and = the RO seems odd. If the backend is already implicitly trusted then = couldn=E2=80=99t you skip OAuth and just get the backend to issue = short-lived JWTs to the frontend that it can use for API access?
 
If you want to allow auth code flow etc = then perhaps the bff-token endpoint can return a standard error code = with an authorization endpoint URI that the SPA then navigates the user = to. (Eg the backend can do a PAR request first and return a URI that = references that so that authorization details aren=E2=80=99t passed = through the frontend). 
 
=E2=80=94 Neil
 

 

On 12 Feb 2021, at 20:46, Vittorio = Bertocci <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:

=EF=BB=BFDear all,
Brian = and yours truly are proposing a new specification that shows how the = user agent frontend of a web app can delegate token acquisition and = persistence to its backend, and request such tokens when needed for = direct access of protected resources from the frontend code.

The pattern is already in use, in proprietary = form, by various modern development stacks, such as Next.JS. Variants of = the pattern, often discussed under the catch-all term BFF (backend for = frontend), have been often mentioned in this workgroup=E2=80=99s = activity, but always left all implementation details to the reader.
We believe the pattern has merit, as corroborated by its = growing adoption. By delegating access token acquisition to the backend, = we avoid many of the often brittle moving parts (and implied attack = surface) required to acquire access tokens from a user agent. The = topology also relieves the frontend from the need of persisting tokens = in local storage, a well known sore point of using OAuth directly in = JavaScript, by relying on its backend storage and session to preserve = tokens.

Although the specification is very = simple, providing explicit guidance on the scenario offers many = advantages.  
- It makes it possible to create = interoperable SDKs, where frontend dev stacks (any JS flavor) can be = mixed and matched with compliant backend stacks (middlewares in node, = java, ASP.NET, PHP etc)
- It allows us to = provide guidance on how to properly tackle the scenario and warn = implementers against security risks (scope escalations, using IDtokens = instead of access tokens, etc)
- It allows us to discuss = (and when appropriate, promote) this pattern as part of the browser apps = security guidance, and position the scenario where frontend only calls = API on its own backed (hence doesn=E2=80=99t need access tokens) simply = as a special case of this more general pattern
- This = approach makes mocking and testing apps very easy, possibly preventing = developers from weakening the security of their system (eg turning on = ROPG options)  or turning to risky practices like scraping

Needless to say, this specification doesn=E2=80=99= t entirely eliminate the risks inherent to direct use of access tokens = from a browser. But reality is that the pattern is in widespread use, = and the circumstances leading to that (eg developers on a particular = project only work with frontend stacks; components like reverse proxies = might not always be viable; etc) aren=E2=80=99t going away any time = soon. By providing simple guidance on this pattern, we can simplify the = life of many developers while enshrining basic security hygiene in = scenarios that would have otherwise be left to their own device.

Looking forward for your feedback!

B&V  

=EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote:


   A new version = of I-D, draft-bertocci-oauth2-tmi-bff-00.txt
   has been successfully submitted by Vittorio = Bertocci and posted to the
   IETF = repository.

   Name:   =      draft-bertocci-oauth2-tmi-bff
   Revision:    00
   Title:        Token = Mediating and session Information Backend For Frontend
   Document date:    2021-02-12
   Group:       =  Individual Submission
   Pages: =        16
   URL: =            https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-0= 0.txt
   Status: =         https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/=
   Html: =           https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-0= 0.html
   Htmlized: =       https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00


   Abstract:
      This document describes = how a JavaScript frontend can delegate access
      token acquisition to a = backend component.  In so doing, the frontend
      can access resource = servers directly without taking on the burden of
      communicating with the = authorization server, persisting tokens, and
      performing operations = that are fraught with security challenges when
      executed in a user agent, = but are safe and well proven when executed
      by a confidential client = running on a backend.




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

   The IETF Secretariat



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

ForgeRock values your Privacy
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
<= /div>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_B5C10186-89EF-4408-9901-B808F87E2D24-- From nobody Mon Feb 15 02:14:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1BE3A0EF0 for ; Mon, 15 Feb 2021 02:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkbJdofjmfGL for ; Mon, 15 Feb 2021 02:14:52 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451013A0DC4 for ; Mon, 15 Feb 2021 02:14:52 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id r5so2459851wmp.1 for ; Mon, 15 Feb 2021 02:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=mZaRg1uWVMsP5sTOQyoGv6hReuRI7orsXvscT480asQ=; b=jpqbfB0IcKTTrRYvsKHO+R7nZlanwwQwO7NNZGjYCbHjcyWhOIMEHskkiVP81JItpQ LfTss2gQ3fy9175pw3bkcCNwZkUFhVPpfaoy5gsQC+ejOz2RCIekL0125lSHIYont4jQ LMHP97yBHLwmp6S7E2xNVdrwmfi6OyNwN1l0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=mZaRg1uWVMsP5sTOQyoGv6hReuRI7orsXvscT480asQ=; b=dkr6m/pYmayiZw/0iWitY6sqviaNSr+U+fPpKmJkeC5xqO+/af5XNZktJ36vaTGRYL oi+oHRsXFNmpCjgn2bsjN0iSYzn5bIuwYZosz/JjocFuZJ0D8y1V1uJKG2LL+ncMUkvc JSLzLmGH3CjMGH1RZUlj0cfD08+Lsrihgo2Sp36KKyh2tsKgHVrF8ccJFx8rQtiilF+8 UpIweZ+7gCMq7qeY5V9de77Q+I0uVRZE7rNU70pBz857Z2HRNfinPgsPp1wnjHu1D9zF yQLho45FGkM9lcWlPivZJ5+cRrpMyecSc8ZLdtW2aPsdQLtBPJH98c3YrzL4CeNVJ+Mt LiTg== X-Gm-Message-State: AOAM530R79oBLv0lo505LJIAwqxN1PZUePpGZoyCthdoavMuIB/Zy1hc xhwU7kQMl2iURReRvw8XueMPxvyIA83cax2AHA9S4uDu7WJtdIsYCyd1yo3RzBl3/u6+gA8TQw= = X-Google-Smtp-Source: ABdhPJx8yAQXXTw5IcauMfy3PSVWO+Ql7/X9QFt+Ny92+LqNzjHVixaPlTxyVVuemkZY2laqFmEzSQ== X-Received: by 2002:a7b:c214:: with SMTP id x20mr10100161wmi.185.1613384090526; Mon, 15 Feb 2021 02:14:50 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id t74sm17848526wmt.45.2021.02.15.02.14.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Feb 2021 02:14:49 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Mon, 15 Feb 2021 10:14:47 +0000 Message-Id: References: <43B559AA-D888-4E8D-8F82-4226676AC536@pragmaticwebsecurity.com> Cc: Vittorio Bertocci , oauth@ietf.org In-Reply-To: <43B559AA-D888-4E8D-8F82-4226676AC536@pragmaticwebsecurity.com> To: Philippe De Ryck X-Mailer: iPhone Mail (18C66) Content-Type: multipart/alternative; boundary=Apple-Mail-5C230414-B64C-40D7-A7D8-806CC0015B08 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 10:14:54 -0000 --Apple-Mail-5C230414-B64C-40D7-A7D8-806CC0015B08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > On 15 Feb 2021, at 08:32, Philippe De Ryck wrote: >=20 > [...] >=20 > Compared to using a worker for handling RTs, I believe the TMI-BFF only a= dds a single security benefit: an attacker is no longer able to run a silen= t flow to obtain a fresh set of tokens (since the client is now a confident= ial client).=20 But they can just call the bff-token endpoint to do the same. If there is a= security advantage, IMO it is as a defence in depth against open redirects= , unicode normalisation attacks (ie not validating the redirect_uri correct= ly at the AS), etc.=20 =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail-5C230414-B64C-40D7-A7D8-806CC0015B08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 


ForgeRock values your Privacy --Apple-Mail-1812512E-1133-4B1D-9DB6-3694DF6716E5-- From nobody Mon Feb 15 03:34:16 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855643A11A4 for ; Mon, 15 Feb 2021 03:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTgz0hcvew1q for ; Mon, 15 Feb 2021 03:34:12 -0800 (PST) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D665A3A11A3 for ; Mon, 15 Feb 2021 03:34:12 -0800 (PST) Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id Bc8plhrzI4A0UBc8pl9K3r; Mon, 15 Feb 2021 04:34:12 -0700 X-CMAE-Analysis: v=2.4 cv=OKDiYQWB c=1 sm=1 tr=0 ts=602a5c34 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=d2bkhBcXAAAA:20 a=48vgC7mUAAAA:8 a=hR4K_BDzmdF4DJ9DuxEA:9 a=QEXdDO2ut3YA:10 a=KNQ3XAJQr-rKUG28BdsA:9 a=8oK9xwvSmwmeeHbD:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2id.com> Date: Mon, 15 Feb 2021 13:34:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060203050609010008070503" X-CMAE-Envelope: MS4xfNDTMcnBUarwSeLytyysw/DAdDhjAtlwe26ltlZGDicMWJgYGT7gVZMYIWjasJPrVg4qPMSFbDlXyG352lO/Cro0gbF+aNOTmbPxUsm3CfJJgGyKqTVl XNzfFfv0Yea4oTwmWZZwQpuGoIYgXAe1Wqcq/OYoeA5ixqWdnghbfFKwCj99u3egqApov3+Qb0pQvw== Archived-At: Subject: Re: [OAUTH-WG] Authorization Header Encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 11:34:15 -0000 This is a cryptographically signed message in MIME format. --------------ms060203050609010008070503 Content-Type: multipart/alternative; boundary="------------61BCEBEE6FEF745DAC7AEA59" Content-Language: en-US This is a multi-part message in MIME format. --------------61BCEBEE6FEF745DAC7AEA59 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, Thanks for alerting us on this development. +1 for keeping the updated HTTP semantics unencumbered by the Authorization header formatting in RFC 6750. IMO revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAuth 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers who maintain their software to pick up the 2.1 spec, sooner or later. Vladimir On 12/02/2021 00:01, Justin Richer wrote: > The HTTP Working Group opened an issue for discussion in relation to > the updated HTTP semantics specification. The core of the issue is the > format of the =E2=80=9CAuthorization=E2=80=9D header, which of course g= ets used by the > =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750. > > https://github.com/httpwg/http-core/issues/733 > > As it turns out, Bearer defines a more limited character set than is > allowed by core HTTP, and doesn=E2=80=99t follow the HTTP guidelines an= d > definitions for the Authorization header. There were a few > observations on the call: > > =C2=A0- The Bearer spec was limited because OAuth tokens were also allo= wed > in HTTP URLs and form parameters (and therefore had to have a more > limited character set) > =C2=A0- In practice people don=E2=80=99t actually restrict the values t= hey put into > this field; pretty much any implementation is just going to > concatenate whatever access token value they get to the magic word > =E2=80=9CBearer=E2=80=9D and send it > =C2=A0- It=E2=80=99s not likely (or in my opinion proper) for the HTTP = spec to > change to address the oddities of RFC6750 and decisions that were made > many years ago > > So the question is, what do we do about it? We could do a revision of > 6750 that reflects reality better, pretty much just changing the ABNF. > > Or, we could update the definition of the Bearer header in the > upcoming OAuth 2.1 specification. > > Are there other options? > > =C2=A0=E2=80=94 Justin > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------61BCEBEE6FEF745DAC7AEA59 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Justin,

Thanks for alerting us on this development.

+1 for keeping the updated HTTP semantics unencumbered by the Authorization header formatting in RFC 6750.

IMO revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAuth 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers who maintain their software to pick up the 2.1 spec, sooner or later.

Vladimir


On 12/02/2021 00:01, Justin Richer wrote:
The HTTP Working Group opened an issue for discussion in relation to the updated HTTP semantics specification. The core of the issue is the format of the =E2=80=9CAuthorization=E2=80=9D header, which = of course gets used by the =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750.

https://github.com/httpwg/http-core/is= sues/733

As it turns out, Bearer defines a more limited character set than is allowed by core HTTP, and doesn=E2=80=99t f= ollow the HTTP guidelines and definitions for the Authorization header. There were a few observations on the call:

=C2=A0- The Bearer spec was limited because OAuth t= okens were also allowed in HTTP URLs and form parameters (and therefore had to have a more limited character set)
=C2=A0- In practice people don=E2=80=99t actually r= estrict the values they put into this field; pretty much any implementation is just going to concatenate whatever access token value they get to the magic word =E2=80=9CBearer=E2=80=9D and send it
=C2=A0- It=E2=80=99s not likely (or in my opinion p= roper) for the HTTP spec to change to address the oddities of RFC6750 and decisions that were made many years ago

So the question is, what do we do about it? We coul= d do a revision of 6750 that reflects reality better, pretty much just changing the ABNF.

Or, we could update the definition of the Bearer header in the upcoming OAuth 2.1 specification.

Are there other options?

=C2=A0=E2=80=94 Justin


____________________________=
___________________
OAuth mailing list
OAut=
h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov
--------------61BCEBEE6FEF745DAC7AEA59-- --------------ms060203050609010008070503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMTUxMTM0MTBaMC8G CSqGSIb3DQEJBDEiBCBJwALQiyiuE6NnnHcFLFrHs+sjS3u5Mb/sQkFsJaiSkDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAInUMwJh821FqLpR2MAG0xu1XFrCDsWxCI+Ua1ixmVOlK6O9 OzWn0Nh2N9qaqv4QnTikOxnP21cf4uDvYgYRopaQEXReyN5lHnniToBCq0VigsNEhCBWPYiP E2WV32XB23Be9ex1TV+uMR3kg3yPUm856GYIk9SsQmFIBfbYbS/YhyKpRehyTLVZt08FYMh3 lbGLfzikpbLEEIjkpopCNG2lfVCipFceQ7ERPpUPDRBMwYg+MzK8Qso4QaOIIdYoAJ3Hl578 b7NLJCjvhIBcwDzQt+A5ZXDExfvg0X/7jF1creNatvA7xCWKbV/clJSpjrzBOdQWToOnvikq jrQR+XgAAAAAAAA= --------------ms060203050609010008070503-- From nobody Mon Feb 15 03:47:00 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F023A11B2 for ; Mon, 15 Feb 2021 03:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKEnDved8huU for ; Mon, 15 Feb 2021 03:46:55 -0800 (PST) Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429983A11AF for ; Mon, 15 Feb 2021 03:46:55 -0800 (PST) Received: from [192.168.88.211] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id BcL6l0fAamLOfBcL7lbXKQ; Mon, 15 Feb 2021 04:46:54 -0700 x-spam-cmae: v=2.4 cv=L9fY/8f8 c=1 sm=1 tr=0 ts=602a5f2e p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=PzzBoh6yAAAA:8 a=1XWaLZrsAAAA:8 a=pGLkceISAAAA:8 a=qP_WgVGEIEcTGspHoc8A:9 a=QEXdDO2ut3YA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=ENpFjlsUdC_nJagxT18A:9 a=lxLXS0ixPy8Fkpkr:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22 a=L62bugPwxnpkHHKveAwe:22 a=IdGyktwZ2tr74praB_5u:22 x-spam-account: vladimir@connect2id.com x-spam-domain: connect2id.com X-CMAE-Analysis: v=2.4 cv=L9fY/8f8 c=1 sm=1 tr=0 ts=602a5f2e p=_Y5QVBCcAAAA:8 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=PzzBoh6yAAAA:8 a=1XWaLZrsAAAA:8 a=pGLkceISAAAA:8 a=qP_WgVGEIEcTGspHoc8A:9 a=QEXdDO2ut3YA:10 a=lvNDOE9i95YA:10 a=k5j4i2vlAAAA:20 a=ENpFjlsUdC_nJagxT18A:9 a=lxLXS0ixPy8Fkpkr:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22 a=L62bugPwxnpkHHKveAwe:22 a=IdGyktwZ2tr74praB_5u:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: Andrii Deinega Cc: Warren Parad , oauth References: <579E1C30-107C-43E6-A521-01A674DAB0F3@lodderstedt.net> <78c83541-0b77-1c16-a302-3e88b2842947@connect2id.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd Organization: Connect2id Ltd. Message-ID: Date: Mon, 15 Feb 2021 13:46:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060204020405050605080107" X-CMAE-Envelope: MS4xfPBnTJA+kXoG3z15HvALstGUSRXKCp0JM3LxgGAhIdBOtmRzgjvLBwjn+mFJmKHATeSKR95nKm+o0THb89QiAZJgOecwGJBSZUsrCHaEFG75lxmFGGhJ T7MKVv6KLNHTQUFbOnH68TCTWSqRptyq0f9+bOUxSt0fp/bxkRKqVWEwQfG3guZj+uUhtBxs0PP5C4obfFuR0FLebjDhrj0a3Z2p++j7Cy0VTLG9MkV4pscX I6jOL9Hf79ykVN+rLCEZcQ== Archived-At: Subject: Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 11:46:58 -0000 This is a cryptographically signed message in MIME format. --------------ms060204020405050605080107 Content-Type: multipart/alternative; boundary="------------6477B69384B818E245BCCF7E" Content-Language: en-US This is a multi-part message in MIME format. --------------6477B69384B818E245BCCF7E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud" value or setting it to the AS, the ultimate consumer, appears valid here.= Vladimir On 11/02/2021 23:47, Andrii Deinega wrote: > Hi Vladimir, > > What would be a value in the aud claim for refresh tokens? > > Regards, > Andrii > > > On Tue, Feb 9, 2021 at 3:06 AM Vladimir Dzhuvinov > > wrote: > > Hi Warren, > > On 08/02/2021 17:59, Warren Parad wrote: >> None of that justified explicitly stating that refresh token >> introspection shouldn't be done. At best it suggests that we >> should explicitly add language in the draft to directly encourage >> it. > > Did you mean discourage? > >> But if an AS wants to support it, we shouldn't stop them, or >> suggest that they can't do it. > > The current draft doesn't mention refresh tokens at all. Its > subject is the introspection of access tokens by authenticated > resource servers and returning the response as a signed JWT. The > use of refresh tokens at the introspection endpoint, per RFC 7662, > is not forbidden by the draft. > > >> >> Allowing refresh tokens to be introspected can also create a >> conflict with the sec recommendation to rotate them >> >> >> Not following, can you explain this further? > > I just double checked the rotation spec. Use that triggers > rotation is clearly specified as "access token response", so there > should actually be no issues with confusing introspection as use. > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#sec= tion-4.13.2 > > RFC 7662 also seems to imply that a public client with a refresh > token should not normally be able to introspect it, because it > can't authenticate to the AS. > >> https://tools.ietf.org/html/rfc7662#section-2.2 >> To prevent token scanning attacks, the endpoint MUST also requi= re >> some form of authorization to access this endpoint, such as cli= ent >> authentication as described in OAuth 2.0 [RFC6749 ] or a separate >> OAuth 2.0 access token such as the bearer token described in OA= uth >> 2.0 Bearer Token Usage [RFC6750 ]. The methods of managing and >> validating these authentication credentials are out of scope of= this >> specification. > > Vladimir > > >> >> =09 >> >> Warren Parad >> >> Founder, CTO >> >> Secure your user data and complete your authorization >> architecture. Implement=C2=A0Authress . >> >> >> On Mon, Feb 8, 2021 at 4:13 PM Vladimir Dzhuvinov >> > wrote: >> >> At first it may appear that allowing refresh tokens at the >> introspection endpoint may be a logical thing to do, but in >> practice there are issues with that and from an OAuth 2.x >> perspective it's not easy to justify. >> >> If the point is to let clients check what authorization they >> have been given OAuth 2.0 already provides a std way to do >> that - in the access token response - the "scope" parameter: >> >> https://tools.ietf.org/html/rfc6749#section-5.1 >> >> RAR has a similar parameter: >> >> https://tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.= 4.1 >> >> If the point is to find if a refresh token is still valid - >> this can be found out by simply using it. Allowing refresh >> tokens to be introspected can also create a conflict with the >> sec recommendation to rotate them. So thus it may be a better >> idea to not let clients assume too much about them. >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-1= 6#section-2.2.2 >> >> If the AS is going to expose refresh token data to a client >> it will also have to make a careful judgement what data it >> exposes. >> >> https://tools.ietf.org/html/rfc7662#section-2.2 >> >> For instance "sub". OAuth 2.x in the relation between AS and >> client actually has no concept or definition of subject / >> end-user identifier. And this is done for a good reason, >> because it's not a user authentication protocol. OIDC was >> designed for that. And to prevent tracking of users and other >> privacy issues OIDC also specifies pairwise subject IDs. The >> plain OAuth 2.x world doesn't have this. >> >> Vladimir >> >> On 08/02/2021 11:07, Warren Parad wrote: >>> It doesn't work that way. You suggested to add language to >>> the draft, that means the burden of proof is on you to >>> justify adding it. >>> >>> Otherwise I could just say why not? >>> >>> And I can go stronger, what's the purpose of nho >>> introspection endpoint at all, and why encourage sending >>> access tokens to the AS? >>> >>> Even if you can justify access tokens, there currently isn't >>> evidence provided why we should explicity discourage. >>> >>> >>> On Mon, Feb 8, 2021, 03:18 Torsten Lodderstedt >>> > >>> wrote: >>> >>> >>> >>>> Am 08.02.2021 um 00:56 schrieb Warren Parad >>>> >: >>>> >>>> =EF=BB=BF >>>> >>>> I=E2=80=98m therefore leaning towards explicitly sta= ting in >>>> our draft that it is not intended to be used with >>>> refresh tokens. >>>> >>>> I'm not following, why explicitly state that it isn't >>>> intended. If an AS wants to provide a similar JSON >>>> response to a query with the refresh token, why not >>>> encourage that? >>> >>> Why should we encourage it?=C2=A0 >>> >>>> >>>> =09 >>>> >>>> Warren Parad >>>> >>>> Founder, CTO >>>> >>>> Secure your user data and complete your authorization >>>> architecture. Implement=C2=A0Authress >>>> . >>>> >>>> >>>> On Sun, Feb 7, 2021 at 10:58 PM Torsten Lodderstedt >>>> >>> > wrote: >>>> >>>> Hi Andrii, >>>> >>>>> Am 07.02.2021 um 21:30 schrieb Andrii Deinega >>>>> >>>> >: >>>>> >>>>> =EF=BB=BF >>>>> Hi=C2=A0Torsten, >>>>> >>>>> thank you for your response. >>>>> >>>>> My use case is pretty straight=C2=A0forward >>>>> >>>>> An OAuth client queries the AS to determine the >>>>> active state of an access token and gets the >>>>> introspection response which indicates that this >>>>> access token is active (using RFC7662). >>>>> >>>>> An OAuth client queries the AS to determine the >>>>> active state of a refresh token and gets the >>>>> introspection response which indicates that this >>>>> refresh token is active (using RFC7662). >>>>> >>>>> An OAuth client queries the AS to determine the >>>>> active state of an access token and gets the >>>>> introspection response (JWT) which indicates that >>>>> this access token is active (using this draft). >>>>> >>>>> Now, an OAuth client queries the AS to determine >>>>> the active state of a refresh token (using this >>>>> draft)... How will the introspection response look >>>>> like assuming that the client provides the valid >>>>> refresh token and technically, nothing stops it >>>>> from doing so. >>>> >>>> why should the state be provided as JWT?I think the >>>> plain JSON response is sufficient in that case.=C2=A0= =C2=A0I >>>> also think using token introspection for checking >>>> the state of a token from the client side has >>>> limited utility. The definitive decision is always >>>> made when the client tries to access a resource.=C2=A0= >>>> >>>> I=E2=80=98m therefore leaning towards explicitly sta= ting in >>>> our draft that it is not intended to be used with >>>> refresh tokens. >>>> >>>> best regards, >>>> Torsten. >>>> >>>>> >>>>> Regards, >>>>> Andrii >>>>> >>>>> >>>>> On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt >>>>> >>>> > wrote: >>>>> >>>>> Hi Andrii, >>>>> >>>>> thanks for your post. >>>>> >>>>> The draft is intended to provide AS and RS >>>>> with a solution to exchange signed (and >>>>> optionally encrypted) token introspection >>>>> responses in order to provide stronger >>>>> assurance among those parties. This is >>>>> important in use cases where the RS acts upon >>>>> the introspection response data and wants the >>>>> AS to take liability re the data quality. >>>>> >>>>> I=E2=80=99m not sure whether there are similar = use >>>>> cases if a client introspects a refresh token. >>>>> What is your use case? >>>>> >>>>> best regards, >>>>> Torsten.=C2=A0 >>>>> >>>>> > Am 07.02.2021 um 08:41 schrieb Andrii >>>>> Deinega >>>> >: >>>>> > >>>>> > Hi WG, >>>>> > >>>>> > >>>>> draft-ietf-oauth-jwt-introspection-response-10 >>>>> states that "OAuth 2.0 Token Introspection >>>>> [RFC7662] specifies a method for a protected >>>>> resource to query an OAuth 2.0 authorization >>>>> server to determine the state of an access >>>>> token and obtain data associated with the >>>>> access token." which is true. Although, >>>>> according to RFC7662, the introspection >>>>> endpoint allows to introspect a refresh token >>>>> as well. Hence, the question I have is how >>>>> will a token introspection response look like >>>>> when the caller provides a refresh token and >>>>> sets the "Accept" HTTP header to >>>>> "application/token-introspection+jwt"? >>>>> > >>>>> > I expect there will be no differences, right?= >>>>> > >>>>> > If so, I suggest to >>>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 replace "= a resource server" by "the >>>>> caller" in section 4 (Requesting a JWT Response= ) >>>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 change "I= f the access token is >>>>> invalid, expired, revoked" by "If a given >>>>> token is invalid, expired, revoked" in section >>>>> 5 (JWT Response) >>>>> > If not, my suggestion would be to clarify >>>>> what the AS should do when it asked to >>>>> introspect the refresh token in general and >>>>> additionally, what should happen in the same >>>>> case based on the type of the caller from the >>>>> AS's point of view. >>>>> > >>>>> > Regards, >>>>> > Andrii >>>>> > >>>>> >>>> _______________________________________________ >>>> OAuth mailing 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 >> Vladimir Dzhuvinov >> > --=20 > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Vladimir Dzhuvinov --------------6477B69384B818E245BCCF7E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud" value or setting it to the AS, the ultimate consumer, appears valid here.

Vladimir

On 11/02/2021 23:47, Andrii Deinega wrote:
Hi Vladimir,

What would be a value in the aud claim for refresh tokens?

Regards,
Andrii


On Tue, Feb 9, 2021 at 3:06= AM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=

Hi Warren,

On 08/02/2021 17:59, Warren Parad wrote:
None of that justified explicitly stating that refresh token introspection shouldn't be done. At best it suggests that we should explicitly add language in the draft to directly encourage it.

Did you mean discourage?

But if an AS wants to support it, we shouldn't stop them, or suggest that they can't do it.

The current draft doesn't mention refresh tokens at all. Its subject is the introspection of access tokens by authenticated resource servers and returning the response as a signed JWT. The use of refresh tokens at the introspection endpoint, per RFC 7662, is not forbidden by the draft.



Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them

Not following, can you explain this further?
=

I just double checked the rotation spec. Use that triggers rotation is clearly specified as "access token response", so there should actually be no issues with confusing introspection as use.

https://tools.= ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.13.2

RFC 7662 also seems to imply that a public client with a refresh token should not normally be able to introspect it, because it can't authenticate to the AS.

https://tools.= ietf.org/html/rfc7662#section-2.2
   To prevent token scanning attacks, the endpoint MUS=
T also require
   some form of authorization to access this endpoint, such as client
   authentication as described in OAuth 2.0 [RFC6749] or a separ=
ate
   OAuth 2.0 access token such as the bearer token described in OAuth
   2.0 Bearer Token Usage [RFC6750].  The me=
thods of managing and
   validating these authentication credentials are out of scope of this
   specification.

Vladimir

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture. Implement=C2=A0Authress.


On Mon, Feb 8, 2021= at 4:13 PM Vladimir Dzhuvinov <vladimir@c= onnect2id.com> wrote:

At first it may appear that allowing refresh tokens at the introspection endpoint may be a logical thing to do, but in practice there are issues with that and from an OAuth 2.x perspective it's not easy to justify.

If the point is to let clients check what authorization they have been given OAuth 2.0 already provides a std way to do that - in the access token response - the "scope" parameter:

https:= //tools.ietf.org/html/rfc6749#section-5.1

RAR has a similar parameter:

https:= //tools.ietf.org/html/draft-ietf-oauth-rar-03#section-3.4.1

If the point is to find if a refresh token is still valid - this can be found out by simply using it. Allowing refresh tokens to be introspected can also create a conflict with the sec recommendation to rotate them. So thus it may be a better idea to not let clients assume too much about them.

https:= //tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-2.2.2

If the AS is going to expose refresh token data to a client it will also have to make a careful judgement what data it exposes.

https:= //tools.ietf.org/html/rfc7662#section-2.2

For instance "sub". OAuth 2.x in the relation between AS and client actually has no concept or definition of subject / end-user identifier. And this is done for a good reason, because it's not a user authentication protocol. OIDC was designed for that. And to prevent tracking of users and other privacy issues OIDC also specifies pairwise subject IDs. The plain OAuth 2.x world doesn't have this.

Vladimir

On 08/02/2021 11:07, Warren Parad wrote:
It doesn't work that way. You suggested to add language to the draft, that means the burden of proof is on you to justify adding it.

Otherwise I could just say wh= y not?

And I can go stronger, what's= the purpose of nho introspection endpoint at all, and why encourage sending access tokens to the AS?

Even if you can justify acces= s tokens, there currently isn't evidence provided why we should explicity discourage.<= /div>

On Mon,= Feb 8, 2021, 03:18 Torsten Lodderstedt <torsten@lodderst= edt.net> wrote:


Am 08.02.2021= um 00:56 schrieb Warren Parad <wparad@rho= sys.ch>:

=EF=BB=BF

Warren Parad

Founder, CTO=

Secure your user data and complete your authorization architecture. Implement=C2= =A0= Authress.


On Sun, Fe= b 7, 2021 at 10:58 PM Torsten Lodderstedt <torsten=3D40lo= dderstedt.net@dmarc.ietf.org> wrote:
Hi Andrii,

A= m 07.02.2021 um 21:30 schrieb Andrii Deinega <andrii.deinega@gmail.com>:

=EF=BB=BF
Hi=C2=A0Torste= n,

thank you for your response.

My use case is pretty straight=C2=A0forward
An OAuth<= /span> client queries the AS to determine the active state of an access token and gets the introspection response which indicates that this access token is active (using RFC7662).

An OAuth<= /span> client queries the AS to determine the active state of a refresh token and gets the introspection response which indicates that this refresh token is active (using RFC7662).

An OAuth<= /span> client queries the AS to determine the active state of an access token and gets the introspection response (JWT) which indicates that this access token is active (using this draft).

Now, an OAuth<= /span> client queries the AS to determine the active state of a refresh token (using this draft)... How will the introspection response look like assuming that the client provides the valid refresh token and technically, nothing stops it from doing so.

why should the state be provided as JWT?I think the plain JSON response is sufficient in that case.=C2=A0= =C2=A0I also think using token introspection for checking the state of a token from the client side has limited utility. The definitive decision is always made when the client tries to access a resource.=C2=A0

I=E2=80=98m therefore le= aning towards explicitly stating in our draft that it is not intended to be used with refresh tokens.

best regards,
Torsten.

=

Regards,
Andrii=


On Sun, Feb 7, 2021 at 4:14 AM Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:
Hi Andrii,

thanks for your post.
=
The draft is intended to provide AS and RS with a solution to exchange signed (and optionally encrypted) token introspection responses in order to provide stronger assurance among those parties. This is important in use cases where the RS acts upon the introspection response data and wants the AS to take liability re the data quality.

I=E2=80=99m not= sure whether there are similar use cases if a client introspects a refresh token. What is your use case?

best regards, Torsten.=C2=A0 =

> Am 07.02.2021 um 08:41 schrieb Andrii Deinega <= andrii.deinega@gmail.com>:
>
> Hi WG,
= >
> draft-ietf-oaut= h-jwt-introspection-response-10 states that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a protected resource to query an OAuth 2.0 authorization server to determine the state of an access token and obtain data associated with the access token." which is true. Although, according to RFC7662, the introspection endpoint allows to introspect a refresh token as well. Hence, the question I have is how will a token introspection response look like when the caller provides a refresh token and sets the "Accept" HTTP header to "application/to= ken-introspection+jwt"?
>
> I expect there will be no differences, right?
>
> If so, I suggest to
>=C2=A0 =C2=A0= =C2=A0 =C2=A0=E2=80=A2 replace "a resource server" by "the caller" in section 4 (Requesting a JWT Response) >=C2=A0 =C2=A0= =C2=A0 =C2=A0=E2=80=A2 change "If the access token is invalid, expired, revoked" by "If a given token is invalid, expired, revoked" in section 5 (JWT Response)
> If not, my suggestion would be to clarify what the AS should do when it asked to introspect the refresh token in general and additionally, what should happen in the same case based on the type of the caller from the AS's point of view.
>
> Regards, > Andrii
= >

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

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


--=20
Vladimir Dzhuvinov
--=20
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--=20
Vladimir Dzhuvinov
--------------6477B69384B818E245BCCF7E-- --------------ms060204020405050605080107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTAyMTUxMTQ2NTJaMC8G CSqGSIb3DQEJBDEiBCDJI+LNP3Wb5RUM9RzSVvBe8IlByCGFNgeCgwmtS9dugzBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBADCy7gZSvLor8JBA12TE7fT61upv6t0/f+ne8g+SsRdqJvvy rUzlOgaltGECu/IrSQutIC6YdL8xVfazKl39Q8BacPgFn1VudOREx9brRm8n+eY/Ij/vAb6v zTzp/5GJTRbBQ47Jzn/ecgs57Jp0sMDBqKSg8gYBsF76x4Yc9oMq/5FPnnSmkDHL/AkCQjuA BKJTwLbAJ/2CJy6d8iWIM1k7pKQYsGY5e7AvqgyohudoW+muxALAyKpsIVV+HozBsl3NV0p5 kegB6QvE3UqPZUBa6VL9OYpY5vB33ia7b5t+19KNTBFkJKMIyODKbFY2gZFQdmaVSrNw6v3H jSuTCCEAAAAAAAA= --------------ms060204020405050605080107-- From nobody Mon Feb 15 05:35:15 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D363A09B5 for ; Mon, 15 Feb 2021 05:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rabw9Sg6pQBB for ; Mon, 15 Feb 2021 05:35:12 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C663A3A084A for ; Mon, 15 Feb 2021 05:35:11 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id o3so5895816edv.4 for ; Mon, 15 Feb 2021 05:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lnxYdKF1FYiDAwI6oBLSGMZXj6ZeEA8AxgrpUwkjCf8=; b=tBWz8B+swt3z5FPWRbkgXRUsUEVZQwVhU2MjnRXnFkjATRqa7yfX/sghFtjhu8HQJ4 hHHuwxpZ1c56Ih5LSKtsZseEnauYS57yptDkwLWOFu6gHer7/sVJyDvNQQpCIbF4f2WN xARjcBto+X1Emzl/eX8vAb6rLHFaNvEg0IQhW7j+0JIUt448UM8g7TBghp2d6DOt3hjj nbrHCJu0M8Jf+xlbHEcLZ7SLtcriw/bHg0B5YCikN/N9jJH1kJMcnZTm9epmfF0H6BqG fmm6KH1u0f81a/fAQtM7h9/pDPDZ5VO1DF8AVJlvZmgMati7SiWT2OO1/YWDd2Pe8hAY xq8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lnxYdKF1FYiDAwI6oBLSGMZXj6ZeEA8AxgrpUwkjCf8=; b=PHK0vbS2QqHA6tiVuknlbiMwoJtGol1joyPDA8emGgqG5jkX9eV/jr7DNQFcoywDSC qd2aWxt1qMjHCZj7b2UxUKSz7lCMvsIeRe9EahOT0nbtoCCOqmK2FhZLbWtdrwpNlVsx 9L7tWkEBzleis3Trrn6GODfiUSONPcdh7OflFitBqGaalCvNzqQ+CcPw0YmBBQEWmgjL Ts3gLM/4G+nHhmFMsw9moHIS5tq3mucMLn+la2vh/uvCZkA7dqm1LftEFrlqwQV8478D ZXhIhdf+YbmkwqI9KWMpK30bt6go43OVTqduRMBd79MuWIx77EIWDGPOz8EqB49WVPKC 7zVw== X-Gm-Message-State: AOAM530UefaSwWDO6yo2UwPsENFph+tNXUd3lJGebi2WdHIofdAPMsHK jamoXktJ99C5zVV7THtY8N+vHPG8T2Rq2x36CRc= X-Google-Smtp-Source: ABdhPJzLUud9jN8hlTRQL2UW9JFSAT6xOGdykEuXpMe1/py9fUxnhilAnt6f9qSL35AH8FxhjWng7qXAs5viYodsO88= X-Received: by 2002:aa7:c155:: with SMTP id r21mr221610edp.382.1613396109991; Mon, 15 Feb 2021 05:35:09 -0800 (PST) MIME-Version: 1.0 References: <1A964B70-7C73-4CAE-B3B9-FF3BACF0E698@forgerock.com> In-Reply-To: <1A964B70-7C73-4CAE-B3B9-FF3BACF0E698@forgerock.com> From: Stoycho Sleptsov Date: Mon, 15 Feb 2021 15:34:58 +0200 Message-ID: To: Neil Madden Cc: Warren Parad , Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="00000000000004a48d05bb600ee5" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 13:35:14 -0000 --00000000000004a48d05bb600ee5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the comprehensive answer, Neil. Initially I said that "I need the client app. to be authenticated at the AS", and I meant authenticated as by the spec (explicit authentication). It seems that the reason which I gave as an example to explain why would I need that (to determine if it is a first-party app.), taken alone, is weak to justify the decision for such a constraint as an explicit authentication= . And I thank you for that clarification. But the question why would I (or somebody else) need the client to be explicitly authenticated as a confidential client at the AS is a different matter. It is an important question, of course, and it would be very interesting for me to understand what is the difference between the set of architectural properties induced by an explicit authentication (credentials by the spec), and the properties induced by an implicit (redirect_uri) authentication, but I am afraid to not abduct the conversation away from the original intent of the TMI-BFF. The main point for me was to verify that for a proper (explicit) client authentication we need to go through the backend, because PKCE doesn't help for that. Which means that a document like TMI-BFF could be very helpful while trying to consider all the BFF options. Regards, Stoycho. On Sun, 14 Feb 2021 at 20:30, Neil Madden wrote= : > Within the spec =E2=80=9Cclient authentication=E2=80=9D refers to explici= t authentication > of the client using credentials. But you said initially that you wanted > this to =E2=80=9Cdetermine if it is a first-party app, for example=E2=80= =9D. You can > determine this based on the redirect_uri and the fact that only the > legitimate client can receive an authorization code at that redirect_uri > (if its HTTPS, exact matching of URIs, etc). This is what I refer to as > implicit authentication - the AS knows at the point of auth code exchange > that only the legitimate client could have obtained that code. > > (This is not true for mobile clients using private-use URI schemes). > > Note that for both public and confidential clients, the confirmation of > the client identity happens after the user has gone through the > authorization flow. PAR fixes this for confidential clients, but not publ= ic > ones. So that is one reason to prefer a BFF pattern and a confidential > client. > > Confidential clients also have an extra layer of defence in depth: they > need a redirect_uri *and* client credentials. So that is another reason t= o > use a confidential client and BFF. > > A backend server may also have a more reliable connection to the AS. So > that may also be a good reason to use a BFF - eg to avoid having to > reauthorize with the user because an auth code or refresh request timed o= ut > due to a flaky network connection. > > So there may be many good reasons to use a BFF pattern. But if you just > want a reasonable assurance of client identity at the point of issuing > tokens, then IMO a public client + PKCE is fine for many cases. > > =E2=80=94 Neil > > On 14 Feb 2021, at 17:27, Stoycho Sleptsov > wrote: > > =EF=BB=BF > Thanks Warren, > > as I see you and Neil have the same idea, > but as of this moment I think this method is not a valid option for > authenticating > a client according to the draft-ietf-oauth-v2-1. > > On the other hand, authenticating the client through the BFF > seems conforming to the spec., but in the case when the access token is > used > in the browser in fact, I am afraid that it can be regarded as > some kind of "deception" of the AS. > > It seems the frontend SPA is not the easiest way to go with oauth... > > Stoycho. > > On Sun, 14 Feb 2021 at 17:35, Warren Parad wrote: > >> redirect_uri and use PKCE via the code verifier. >> >> Warren Parad >> >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress . >> >> >> On Sun, Feb 14, 2021 at 3:51 PM Stoycho Sleptsov < >> stoycho.sleptsov@gmail.com> wrote: >> >>> Thanks a lot for your answer Neil, >>> >>> as I am no expert (yet :-)) in security I was afraid to rely on >>> redirect_uri for authentication of the client, >>> but I will consider that option as more trustworthy now. >>> >>> (it is also not very clear for me which part of the app can be >>> regarded as the redirect_uri owner, the BFF or the loaded frontend >>> SPA, but maybe it is not so important) >>> >>> If you had the two options for authentication of the frontend SPA >>> client - the redirect_uri on the one hand, and the Basic >>> authentication with client secret through the BFF on the other, which >>> one would you recommend? >>> >>> On Sun, 14 Feb 2021 at 16:28, Neil Madden >>> wrote: >>> > >>> > Public clients are implicitly authenticated by their ownership of the >>> registered redirect_uri. This why it=E2=80=99s important to use a redir= ect_uri for >>> which ownership can be reasonably established, such as HTTPS endpoints = with >>> exact URI matching. >>> > >>> > There are more things that can go wrong with that (see the security >>> BCP), but it can be made reasonably secure. >>> > >>> > =E2=80=94 Neil >>> > >>> > > On 14 Feb 2021, at 13:48, Stoycho Sleptsov < >>> stoycho.sleptsov@gmail.com> wrote: >>> > > >>> > > =EF=BB=BF >>> > > I would like to add my reasons about the "Why are developers >>> creating BFF for their frontends to communicate with an AS", >>> > > with the objective to verify if they are valid. >>> > > >>> > > I need the client app. to be authenticated at the AS (to determine >>> if it is a first-party app., for example). >>> > > If we decide to implement our client as a frontend SPA , then we >>> have no other option except through a BFF, as PKCE does not help for >>> authentication. >>> > > >>> > > Or is it considered a bad practice to do that? >>> > > >>> > > Regards, >>> > > Stoycho. >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> > -- >>> > ForgeRock values your Privacy >>> >> > ForgeRock values your Privacy --00000000000004a48d05bb600ee5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the comprehensive answer, Neil.

Initially I said that "I need the client app. to be = authenticated at the AS", and I meant authenticated as by the spec (ex= plicit authentication).
It seems that the reason which= I gave as an example to explain why would I need that (to determine if it = is a first-party app.), taken alone, is weak to justify the decision for su= ch a constraint as an explicit authentication.
And I thank you fo= r that clarification.
But the question why would I (or somebody e= lse) need the client to be explicitly authenticated as a confidential clien= t at the=C2=A0AS is a different=C2=A0matter.
It is an importa= nt question, of course, and it would be very interesting for me to understa= nd what is the difference between the set of architectural properties induc= ed by an explicit authentication (credentials by the spec), and the propert= ies induced by an implicit (redirect_uri) authentication, but I am afraid t= o not abduct the conversation=C2=A0away from the original intent of the TMI= -BFF.

The main point for me was to verify that for= a proper (explicit) client authentication we need to go through the=C2=A0b= ackend, because PKCE doesn't help for that.
Which means that = a document like TMI-BFF could be very helpful while trying to consider all = the BFF options.

Regards,
Stoycho.
=


On Sun, 14 Feb 2021 at 20:30, Neil Madden <neil.madden@forgerock.com> wrote:
=
Within the spec =E2=80=9Cclient authentication= =E2=80=9D refers to explicit authentication of the client using credentials= . But you said initially that you wanted this to =E2=80=9Cdetermine if it i= s a first-party app, for example=E2=80=9D. You can determine this based on = the redirect_uri and the fact that only the legitimate client can receive a= n authorization code at that redirect_uri (if its HTTPS, exact matching of = URIs, etc). This is what I refer to as implicit authentication - the AS kno= ws at the point of auth code exchange that only the legitimate client could= have obtained that code.=C2=A0

(This is not true for mobile clients using private-use URI schemes).<= /div>

Note that for both public = and confidential clients, the confirmation of the client identity happens a= fter the user has gone through the authorization flow. PAR fixes this for c= onfidential clients, but not public ones. So that is one reason to prefer a= BFF pattern and a confidential client.=C2=A0

Confidential clients also have an extra layer of defenc= e in depth: they need a redirect_uri *and* client credentials. So that is a= nother reason to use a confidential client and BFF.=C2=A0

A backend server may also have a more relia= ble connection to the AS. So that may also be a good reason to use a BFF - = eg to avoid having to reauthorize with the user because an auth code or ref= resh request timed out due to a flaky network connection.=C2=A0

So there may be many good reasons to = use a BFF pattern. But if you just want a reasonable assurance of client id= entity at the point of issuing tokens, then IMO a public client + PKCE is f= ine for many cases.=C2=A0

= =E2=80=94 Neil

On 14 Feb 2021, at 17:27, Stoycho Sleptsov <stoycho.sleptsov@gmail.c= om> wrote:

=EF=BB=BF
Thanks Warren,

as = I see you and Neil have the same idea,
but as of this moment I th= ink this method is not a valid option for authenticating
a client= according to the=C2=A0draft-ietf-oauth-v2-1.

On t= he other hand, authenticating the client through the BFF
seems co= nforming to the spec., but=C2=A0in the=C2=A0case when=C2=A0the access token= is used
in the browser in fact, I am afraid that it can be regar= ded as
some kind of "deception" of the AS.
It seems the frontend SPA is not the easiest way to go with oa= uth...

Stoycho.

On Sun, 14 Feb 2021 at 17:35,= Warren Parad <wpa= rad@rhosys.ch> wrote:
redirect_uri and use PKCE via the code verifi= er.

Warren Parad=

Founder, CTO<= /span>

Secure your user data and complete your authorization architecture. Imple= ment=C2=A0Authress.<= br>


On Sun, Feb 14, 2021 at 3:51 PM Stoycho Slep= tsov <st= oycho.sleptsov@gmail.com> wrote:
Thanks a lot for your answer Neil,

as I am no expert (yet :-)) in security I was afraid to rely on
redirect_uri for authentication of the client,
but I will consider that option as more trustworthy now.

(it is also not very clear for me which part of the app can be
regarded as the redirect_uri owner, the BFF or the loaded frontend
SPA, but maybe it is not so important)

If you had the two options for authentication of the frontend SPA
client - the redirect_uri on the one hand, and the Basic
authentication with client secret through the BFF on the other, which
one would you recommend?

On Sun, 14 Feb 2021 at 16:28, Neil Madden <neil.madden@forgerock.com> wrote:<= br> >
> Public clients are implicitly authenticated by their ownership of the = registered redirect_uri. This why it=E2=80=99s important to use a redirect_= uri for which ownership can be reasonably established, such as HTTPS endpoi= nts with exact URI matching.
>
> There are more things that can go wrong with that (see the security BC= P), but it can be made reasonably secure.
>
> =E2=80=94 Neil
>
> > On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:
> >
> > =EF=BB=BF
> > I would like to add my reasons about the "Why are developers= creating BFF for their frontends to communicate with an AS",
> > with the objective to verify if they are valid.
> >
> > I need the client app. to be authenticated at the AS (to determin= e if it is a first-party app., for example).
> > If we decide to implement our client as a frontend SPA , then we = have no other option except through a BFF, as PKCE does not help for authen= tication.
> >
> > Or is it considered a bad practice to do that?
> >
> > Regards,
> > Stoycho.
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth=
>
> --
> ForgeRock values your Privacy <https://www.forgerock.c= om/your-privacy>

ForgeRock values your Privacy --00000000000004a48d05bb600ee5-- From nobody Mon Feb 15 08:49:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78DD3A0D7C for ; Mon, 15 Feb 2021 08:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2T7Y7DWnJPg for ; Mon, 15 Feb 2021 08:49:00 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDC13A0D7A for ; Mon, 15 Feb 2021 08:48:59 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id v14so9696923wro.7 for ; Mon, 15 Feb 2021 08:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=stBB5Tjm9JyDfqs42gVID2QmjZ/4oQ1vgykWwdT3yho=; b=3Cqx+fzNRjT0FqDSRlYd+Z3PMqpU1VzG1iSyKR3XaW8MV2xsN4g0iTKGvwfrF+H3/i tDssyeKIMs8GawvmmUGr+/gm9Uwp2Rtf0wKcVC88zxoa+hHHQZPf+o1pRnAckGgti15i vzmHKT96YcHwAQNPyMptkiJLu5XEN83J5FtLYiTOYcu83N7KHCs7hl4S6/ZwJ+JX1crM raeZWKSDKccQyGFPtCp0PaHOopSJSuy+a+q+9j4eg5KB7DQ146HlH5zuTrfttkLKHQMt QxwBakmsHJ32f9aY7VKGPM0LFc3fmb1lWD1ViEu7xstxa8O74OeHixZxsEy/yqA3Kpwm MT2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=stBB5Tjm9JyDfqs42gVID2QmjZ/4oQ1vgykWwdT3yho=; b=mG6fyUnyulBuIjzN2YlTQ8vaOQlaMcIHKzXfQ9nZB4CzPGSGPoH3uT/i+1GZw1Em2K bFuTBRiWJuZ1zb/v4+bSwTFv9cw9i+hkzMGMlcWJjWP7y+bXt0OvYy3SgVPMH2Lgrz5g qFJCNVMyqWdx+mcxfe8OQnJZx8lBJM0A8sEnTEXlg4gzXfwvvBo+5jispv7m+zC00HnW tTdCuyaVVwvXWzE1iZB1uYJqGtMHDqXmdqpN9slmwBh6UYFNvNzle1mYlM07wJjuv7x1 Y4/iBnjd/u4ui+jQ1GGLKEpGAERgiWxMYbxLbMHj+QFXRY2HkxVwnUqvdt84npbLat6P iIlQ== X-Gm-Message-State: AOAM531tXxiW0H+JEeRNflt8BHa0Th2QM58LnPKqpqbfVNyCbK5fwVXo aLPDZ5UP/hCtF4fdxEauJ0s2RQ== X-Google-Smtp-Source: ABdhPJyAcZeserSqUz/WhdmpOVfX0NRGuFBTPoouB5/v82DufJkmecB7ve3PZuT01Ae4eaZCiy5WKw== X-Received: by 2002:a05:6000:81:: with SMTP id m1mr19934919wrx.97.1613407738154; Mon, 15 Feb 2021 08:48:58 -0800 (PST) Received: from p200300eb8f0611668d558860be74ade1.dip0.t-ipconnect.de (p200300eb8f0611668d558860be74ade1.dip0.t-ipconnect.de. [2003:eb:8f06:1166:8d55:8860:be74:ade1]) by smtp.gmail.com with ESMTPSA id i3sm23150542wrr.19.2021.02.15.08.48.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Feb 2021 08:48:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Torsten Lodderstedt In-Reply-To: Date: Mon, 15 Feb 2021 17:48:56 +0100 Cc: "oauth@ietf.org" , Brian Campbell Content-Transfer-Encoding: quoted-printable Message-Id: <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> To: Vittorio Bertocci X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 16:49:03 -0000 Thank you again for the explanation.=20 I think your assumption about the overall flow should be described in = the draft.=20 As I understand it now the core contribution of your proposal is to move = refresh token management from frontend to backend. Is that correct? =20 > Am 14.02.2021 um 21:35 schrieb Vittorio Bertocci = : >=20 > Thanks! > I expect the frontend (as in JS code) not to kick in until the initial = authorization has been perfomed. Breaking it down as a classic possible = flow: >=20 > - User navigates to the app page, clicks "sign in" > - The backend redirects the user to the AS to perform a code grant = (for the sake of argument let's also say they ask for an IDtoken as well = tho it isn=E2=80=99t strictly necessary), with the purpose of gathering = consent for the scopes required. No frontend code involved.=20 > - The code grant concludes successfully, the backend now has a session = with the user agent and an AT, RT stored on the server side > - --> here TMI-BFF begins. Whenever the frontend needs a token to call = an API, they use TMI-BFF to ask for that token to the backend > - if the backend can return the requested token, via stored AT or by = using the RT, it does it > - if the backend cannot get the requested token with what it already = has without suer interaction, it fails > --> here there's where TMI-BFF ends- it's up to the backend to decide = how to meet the new requirements, eg by triggering another authorization = code grant for new scopes. The frontend is not involved apart from = perhaps offering affordances to the end upper to start such process >=20 > TMI-BFF does not include the actual authorization requests mostly for = simplicity. We don=E2=80=99t really know how the app is structured nor = the reasons for which a backend might be unable to get the requested = token. The RT might be expired; or the current scopes might be = insufficient; or the AS might decide that now issuing an AT with that = scope might require a different authentication method; and many other = reasons I can=E2=80=99t think of. If we were to provide a mechanism that = includes in the error message indications on what the frontent should do = to remediate the error, we might need to either scope down the scenarios = or create a very flexible mechanism. I am not opposed, but before = venturing into that we wanted to see what the reaction would be. =20 >=20 > =EF=BB=BFOn 2/14/21, 11:45, "Torsten Lodderstedt" = wrote: >=20 > Hi Vittorio, >=20 > thanks for the explanation. Do you assume the frontend passes the = code or initial refresh token to the backend using an application = specific mechanism? Why isn=E2=80=99t this part of the bff-token = request? >=20 > best regards, > Torsten. >=20 >> Am 14.02.2021 um 20:19 schrieb Vittorio Bertocci = : >>=20 >> =EF=BB=BFHi Torsten, thanks for looking into this! >> The idea is that the application backend performed all the = interactive token acquisition steps before TMI-BFF come into play. >> Imagine that a regular web app performs an authorization code grant, = requesting access token and refresh token in the process (and often also = setting its own session with the user agent in the process, if the AS is = also their IdP via OIDC or similar, but that's not strictly necessary). = Now the app backend has an access token and refresh token persisted on = the server side. >> All TMI-BFF does is to describe how the backend can share those = tokens with its fronted, either directly (if the persisted AT is still = valid) or indirectly (if it has to use an RT to obtain a new AT before = sending it back). >> The frontend provides resource and scope to select what token it = needs, but the current idea is that the backend already obtained both = consent and artifacts to obtain those tokens from the AS. And if it = doesn't, at the moment we simply fail and expect the app developer to = take the steps required to prompt the user with whatever is necessary = for updating the backend with the right permissions, eg creating a new = authorization request asking for a scope the frontend needs and that the = user wasn't prompted to consent yet. At the moment TMI-BFF does not = provide a mechanism for that prompt to occur, it just errors out saying = "you've got to update your authorization artifacts before the frontend = can get the token w the scopes it needs". >> Another way to think about this: in TMI-BFF the frontend treats the = backend is a tokens database. Indicating the resource and scopes is a = query. If the backend can serve that query (with the ATs it saved, or by = using the RTs it saved AND the grants the user already gave) it returns = a token. If it doesn't, it fails the query. The frontend does not play a = direct role into inserting in the DB more tokens. That is left to the = backend, that can do so by initiating a new authorization grant, not = described in TMI-BFF, that must conclude successfully for the frontend = to be able to repeat its query and this time get the token they want = out. Note that the backend might decide that it won=E2=80=99t try to get = the token requested, or it might unable to do so (eg the user/app cannot = meet some requirements as the AS is concerned), hence the request of it = might at times be permanently denied. This last part is to say that = providing in the error message details about the remediation might take = more work than one realizes at first, and ultimately acting on the error = situation to retrieve a new token is still up to the backend anyway, = hence providing elaborate machinery to inform the frontend beyond the = error situation might not be as effective as it might look at first = glance. I am totally open to it, just making sure we understand what it = can buy us. =20 >>=20 >> =EF=BB=BFOn 2/14/21, 06:11, "Torsten Lodderstedt" = wrote: >>=20 >> Hi, >>=20 >> I=E2=80=99m trying to understand your proposal.=20 >>=20 >> Section 1.2, bullet (B) states >>=20 >> (B) If the backend does not already have a suitable access token >> obtained in previous flows and cached, it requests to the >> authorization server a new access token with the required >> characteristics, using any artifacts previousy obtained (eg >> refresh token) and grants that will allow the authorization = server >> to issue the requested token without requiring user = interaction. >>=20 >> Can you please explain how the authorization process works towards = the AS, especially in case of the authorisation code grant type. I would = have expected to frontend to pass an authorisation code to the bff-token = request.=20 >>=20 >> But section 4.1. only defines the parameters =E2=80=9Eresource" and = =E2=80=9Escope" for the bff-token endpoint.=20 >>=20 >> thanks, >> Torsten.=20 >>=20 >>> Am 12.02.2021 um 21:46 schrieb Vittorio Bertocci = : >>>=20 >>> Dear all, >>> Brian and yours truly are proposing a new specification that shows = how the user agent frontend of a web app can delegate token acquisition = and persistence to its backend, and request such tokens when needed for = direct access of protected resources from the frontend code. >>>=20 >>> The pattern is already in use, in proprietary form, by various = modern development stacks, such as Next.JS. Variants of the pattern, = often discussed under the catch-all term BFF (backend for frontend), = have been often mentioned in this workgroup=E2=80=99s activity, but = always left all implementation details to the reader. >>> We believe the pattern has merit, as corroborated by its growing = adoption. By delegating access token acquisition to the backend, we = avoid many of the often brittle moving parts (and implied attack = surface) required to acquire access tokens from a user agent. The = topology also relieves the frontend from the need of persisting tokens = in local storage, a well known sore point of using OAuth directly in = JavaScript, by relying on its backend storage and session to preserve = tokens. >>>=20 >>> Although the specification is very simple, providing explicit = guidance on the scenario offers many advantages. =20 >>> - It makes it possible to create interoperable SDKs, where frontend = dev stacks (any JS flavor) can be mixed and matched with compliant = backend stacks (middlewares in node, java, ASP.NET, PHP etc) >>> - It allows us to provide guidance on how to properly tackle the = scenario and warn implementers against security risks (scope = escalations, using IDtokens instead of access tokens, etc) >>> - It allows us to discuss (and when appropriate, promote) this = pattern as part of the browser apps security guidance, and position the = scenario where frontend only calls API on its own backed (hence = doesn=E2=80=99t need access tokens) simply as a special case of this = more general pattern >>> - This approach makes mocking and testing apps very easy, possibly = preventing developers from weakening the security of their system (eg = turning on ROPG options) or turning to risky practices like scraping >>>=20 >>> Needless to say, this specification doesn=E2=80=99t entirely = eliminate the risks inherent to direct use of access tokens from a = browser. But reality is that the pattern is in widespread use, and the = circumstances leading to that (eg developers on a particular project = only work with frontend stacks; components like reverse proxies might = not always be viable; etc) aren=E2=80=99t going away any time soon. By = providing simple guidance on this pattern, we can simplify the life of = many developers while enshrining basic security hygiene in scenarios = that would have otherwise be left to their own device. >>>=20 >>> Looking forward for your feedback! >>>=20 >>> B&V =20 >>>=20 >>> =EF=BB=BFOn 2/12/21, 12:41, "internet-drafts@ietf.org" = wrote: >>>=20 >>>=20 >>> A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt >>> has been successfully submitted by Vittorio Bertocci and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-bertocci-oauth2-tmi-bff >>> Revision: 00 >>> Title: Token Mediating and session Information Backend For = Frontend >>> Document date: 2021-02-12 >>> Group: Individual Submission >>> Pages: 16 >>> URL: = https://www.google.com/url?q=3Dhttps://www.google.com/url?q%3Dhttps://www.= google.com/url?q%253Dhttps://www.ietf.org/archive/id/draft-bertocci-oauth2= -tmi-bff-00.txt%2526source%253Dgmail-imap%2526ust%253D1613767591000000%252= 6usg%253DAOvVaw3Rb-S0l6cEv0ytjDxtYLAP%26source%3Dgmail-imap%26ust%3D161393= 5165000000%26usg%3DAOvVaw3p5263a_rEePNbnX7jWFjq&source=3Dgmail-imap&ust=3D= 1613939757000000&usg=3DAOvVaw0jgXsBeXKFC9n31Rg06yE6 >>> Status: = https://www.google.com/url?q=3Dhttps://www.google.com/url?q%3Dhttps://www.= google.com/url?q%253Dhttps://datatracker.ietf.org/doc/draft-bertocci-oauth= 2-tmi-bff/%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%= 253DAOvVaw3-qg5MDtY7kD1HpR5jR2QY%26source%3Dgmail-imap%26ust%3D16139351650= 00000%26usg%3DAOvVaw1YZmVHpENHa-bqqtbezRpa&source=3Dgmail-imap&ust=3D16139= 39757000000&usg=3DAOvVaw0UWVw3PhVKKuwdIjaMHfce >>> Html: = https://www.google.com/url?q=3Dhttps://www.google.com/url?q%3Dhttps://www.= google.com/url?q%253Dhttps://www.ietf.org/archive/id/draft-bertocci-oauth2= -tmi-bff-00.html%2526source%253Dgmail-imap%2526ust%253D1613767591000000%25= 26usg%253DAOvVaw05WK4GSEKcWjZzNhvb1p5d%26source%3Dgmail-imap%26ust%3D16139= 35165000000%26usg%3DAOvVaw2HibfQtTYv3talGT379MOu&source=3Dgmail-imap&ust=3D= 1613939757000000&usg=3DAOvVaw3AuwQ6TPoW5MnsGXcMUh_S >>> Htmlized: = https://www.google.com/url?q=3Dhttps://www.google.com/url?q%3Dhttps://www.= google.com/url?q%253Dhttps://tools.ietf.org/html/draft-bertocci-oauth2-tmi= -bff-00%2526source%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253= DAOvVaw0qm45MWGbZf0zbBjZj3ggz%26source%3Dgmail-imap%26ust%3D16139351650000= 00%26usg%3DAOvVaw0gZZ0ZU8QVx7OBjxDcG8d-&source=3Dgmail-imap&ust=3D16139397= 57000000&usg=3DAOvVaw2fIy9b1bQxvnk5QK9Nl7QI >>>=20 >>>=20 >>> Abstract: >>> This document describes how a JavaScript frontend can delegate = access >>> token acquisition to a backend component. In so doing, the = frontend >>> can access resource servers directly without taking on the = burden of >>> communicating with the authorization server, persisting tokens, = and >>> performing operations that are fraught with security challenges = when >>> executed in a user agent, but are safe and well proven when = executed >>> by a confidential client running on a backend. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at = tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> = https://www.google.com/url?q=3Dhttps://www.google.com/url?q%3Dhttps://www.= google.com/url?q%253Dhttps://www.ietf.org/mailman/listinfo/oauth%2526sourc= e%253Dgmail-imap%2526ust%253D1613767591000000%2526usg%253DAOvVaw1Bfu9fJ2Fj= _BZJ3H9yw7od%26source%3Dgmail-imap%26ust%3D1613935165000000%26usg%3DAOvVaw= 3a73buBtPOBoDQ3SMH_XJW&source=3Dgmail-imap&ust=3D1613939757000000&usg=3DAO= vVaw3p0jGqda5qiL2KioFSSZ01 >>=20 >>=20 >=20 From nobody Mon Feb 15 09:18:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788F03A0E00 for ; Mon, 15 Feb 2021 09:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWzTlJ7R0NQB for ; Mon, 15 Feb 2021 09:17:58 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918173A0DFE for ; Mon, 15 Feb 2021 09:17:58 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id v15so9837729wrx.4 for ; Mon, 15 Feb 2021 09:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fBwYw/oJEwicc/GHtLoO7gXezMP2qJhCG3XneOTyEHY=; b=S03uXg8R2cUDLBkQwXx4QrVi1cUTazr6MxcNDxwV7L95j9WlAv5W5l91UYh6qFUchl AnbfAgMz9+RooFgqMO6fubXOYR7c90MIc/8hCTRAU5n3UvqaQqVMeXvU7vKSlGRiXcWu FPsPjDPdBWSOeiLBHWw6AJFQMhaZhkBDF31+u0zpI1iCZfbZubsGK+c+Q/IArCyeRj3r hxpSD82ux867+1qqX0Aze+oH+JIh+PN7mDj5hXQ/B/sluXOtwoP+PQcLDu506cezb43x MDYoxd56IaaNHrL46PD+Mz1MkwwrCaL6TrtBe/fyqDxuyJS7syPRlltgByaKpFBEqDAw wufg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fBwYw/oJEwicc/GHtLoO7gXezMP2qJhCG3XneOTyEHY=; b=D92Hjanke6oA8TGdkcrJvXvc9t8i3ey27gW0vRhR3l98ip6IAGZMOW2UUrYzNSB/mt YOOwAh3dLfaSZnoZV5AjiMW0/BlrmCGA/296vX3+EA1/5eBE6T5mHOGde6nnGRW8tdbf JbuU5S417lglXCWMFYaPWz8/eDY6PyzpjMaHoOMK3DMs3VzLuQOC63qlWeGsVpxO9++f PF3s7hYvdbBB3F7ThBNfAMDlKjyZv5ajEnao/04uGrlI8a3+G5s3DgvAFErG8/J/Ccwk Qn5O0yXZAQBjZYlXtVrFsP3vZgdqF9Py9tJW670CttyW5ndWZzW75MJMsk66d/b9hv1h MHIg== X-Gm-Message-State: AOAM531EOMujsoUdTAP4BXB97X6Oc+f+gXgse3BE4iyd7v5o4EXY2rdq V7JKAXljeqPfFsgRK2arI9rn+A== X-Google-Smtp-Source: ABdhPJy+LZvHGA9I04wbPOoYCbBGAJa92rf/Y9oha/nr2wTb042FTRsM7O4KrJDDRGN85BcLJbGLkg== X-Received: by 2002:a5d:50c8:: with SMTP id f8mr6119839wrt.69.1613409476929; Mon, 15 Feb 2021 09:17:56 -0800 (PST) Received: from p200300eb8f0611668d558860be74ade1.dip0.t-ipconnect.de (p200300eb8f0611668d558860be74ade1.dip0.t-ipconnect.de. [2003:eb:8f06:1166:8d55:8860:be74:ade1]) by smtp.gmail.com with ESMTPSA id u7sm23956996wrt.67.2021.02.15.09.17.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Feb 2021 09:17:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Torsten Lodderstedt In-Reply-To: Date: Mon, 15 Feb 2021 18:17:55 +0100 Cc: Francis Pouatcha , oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: <161270175060.8296.1897997883947486904@ietfa.amsl.com> <06504BA6-6065-4ADD-BE45-5E13DF00DC1A@lodderstedt.net> To: Brian Campbell X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 17:18:01 -0000 > Am 13.02.2021 um 00:38 schrieb Brian Campbell = : >=20 >=20 >=20 > On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha = wrote: > Find bellow my review of the draft: >=20 > =E2=80=A2 Redactional changes: > 2.2. Authorization Data Types >=20 > Interpretation of the value of the "type" parameter, and the object > elements that the "type" parameter allows =3D> allowed >=20 >=20 > The "allows" seems correct there.=20 >=20 > =20 >=20 > 9. Metadata > which is an > JSON array. =3D> which is a JSON array >=20 > Fixed this in the document source. Thanks! > =20 > =E2=80=A2 Application to existing APIs > reason-1: Current open banking initiatives are built on the of = existing Data Standards like ISO20022 (PAIN, CAMT) which are XML's that = do not provide direct translation to JSON. Some authorization server's = might even be able to parse an ISO PAIN file to display the proper = authorization request to the user. >=20 > That the APIs are XML doesn't necessarily mean that the details of the = authorization can't be represented in JSON. And, if really need be, XML = can be included as the value of some member in the authorization details = and defined as such by the type.=20 >=20 > =20 > reason-2: In some situation, it might be more privacy preserving to = have the authorization request content negotiated between the AS and the = RS. In this case the "scope" parameter shall only carry some sort of = "grant-id" (known in the Berlin Group spec as consent-id). This will = allow the AS to negotiate the data to be displayed directly with the RS. I think you are referring to different relationships, namely client to = AS vs AS to RS.=20 Authorization details carry the client=E2=80=99s request data (e.g. = amount to be transferred) to the AS. Whatever the AS wants to negotiate = with the RS to be displayed by the AS can be negotiated between AS and = RS if needed via a suitable interface. However, I would assume this = negotiation is informed by the client=E2=80=99s request data. So both = concepts are complementary in my opinion. =20 >=20 > RAR probably just isn't applicable in that kind of case.=20 =20 >=20 > =20 >=20 > Any idea how to consider these two edge cases? >=20 >=20 > =20 > Best regards. > /Francis >=20 >=20 > From: OAuth on behalf of Torsten Lodderstedt = > Sent: Sunday, February 7, 2021 12:49 PM > To: oauth > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt > =20 > Hi all, >=20 > here is the list of changes in revision -04: >=20 > =E2=80=A2 restructured draft for better readability > =E2=80=A2 simplified normative text about use of the resource = parameter with authorization_details=20 > =E2=80=A2 added implementation considerations for deployments = and products > =E2=80=A2 added type union language from GNAP =20 > =E2=80=A2 added recommendation to use PAR to cope with large = requests and for request protection >=20 > Your feedback is highly appreciated. >=20 > best regards, > Torsten.=20 >=20 >> Am 07.02.2021 um 13:42 schrieb internet-drafts@ietf.org: >>=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 WG of the = IETF. >>=20 >> Title : OAuth 2.0 Rich Authorization Requests >> Authors : Torsten Lodderstedt >> Justin Richer >> Brian Campbell >> Filename : draft-ietf-oauth-rar-04.txt >> Pages : 36 >> Date : 2021-02-07 >>=20 >> Abstract: >> This document specifies a new parameter "authorization_details" = that >> is used to carry fine grained authorization data in the OAuth >> authorization request. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-ietf= -oauth-rar/&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw3-4SmuM= Fgxbz-cDK2Ir_a7 >>=20 >> There is also an HTML version available at: >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf-= oauth-rar-04.html&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw1= J52xGTvk1ZAuBC_fUAIjJ >>=20 >> A diff from the previous version is available at: >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-i= etf-oauth-rar-04&source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw0T= YqmFwryvAYznR2Ho5Oj6 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1613306557000000&usg=3DAOvVaw06g1z6o36BkkaqkiWc= 1Lw9 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. From nobody Mon Feb 15 10:57:05 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342733A0FE8; Mon, 15 Feb 2021 10:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoHJDUDDFY96; Mon, 15 Feb 2021 10:57:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD063A0FDC; Mon, 15 Feb 2021 10:57:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id F2B80F4070D; Mon, 15 Feb 2021 10:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBPo4OnhUkYu; Mon, 15 Feb 2021 10:56:55 -0800 (PST) Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 827E0F406CD; Mon, 15 Feb 2021 10:56:55 -0800 (PST) Received: from 84.92.155.108 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Mon, 15 Feb 2021 10:56:55 -0800 Message-ID: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> Date: Mon, 15 Feb 2021 10:56:55 -0800 From: "RFC ISE (Adrian Farrel)" To: oauth@ietf.org Cc: "Adrian Farrel" , draft-ideskog-assisted-token@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 18:57:03 -0000 Hi OAuth, The authors of draft-ideskog-assisted-token [1] have approached me requesting that the draft be published as an Informational RFC in the Independent Submission Stream [2]. The draft extends the OAuth 2.0 framework to include an additional authorization flow for single page applications called the assisted token flow. It is intended to enable OAuth clients that are written in scripting languages (such as JavaScript) to request user authorization using a simplified method. Communication leverages HTML's iframe element, child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint. It is clear to me that this work could be in scope for OAuth and I want to be sure that both: - there is no interest within the WG in pursuing this approach - there is no perceived harm to existing OAuth work if this goes ahead I'd appreciate any opinions. Many thanks, Adrian -- Adrian Farrel (Independent Submissions Editor), rfc-ise@rfc-editor.org [1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/ [2] https://www.rfc-editor.org/about/independent/ From nobody Mon Feb 15 10:59:39 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECE03A0FED; Mon, 15 Feb 2021 10:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPjAjSmpQGS6; Mon, 15 Feb 2021 10:59:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC32D3A0FEC; Mon, 15 Feb 2021 10:59:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id BE1A9F4070D; Mon, 15 Feb 2021 10:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzLd1t4M8unM; Mon, 15 Feb 2021 10:59:30 -0800 (PST) Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id F0ACDF406DA; Mon, 15 Feb 2021 10:59:29 -0800 (PST) Received: from 84.92.155.108 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Mon, 15 Feb 2021 10:59:30 -0800 Message-ID: <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> In-Reply-To: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> References: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> Date: Mon, 15 Feb 2021 10:59:30 -0800 From: "RFC ISE (Adrian Farrel)" To: rfc-ise@rfc-editor.org Cc: oauth@ietf.org, draft-ideskog-assisted-token@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 18:59:38 -0000 Hi OAuth, The authors of draft-ideskog-assisted-token [1] have approached me requesting that the draft be published as an Informational RFC in the Independent Submission Stream [2]. The draft extends the OAuth 2.0 framework to include an additional authorization flow for single page applications called the assisted token flow. It is intended to enable OAuth clients that are written in scripting languages (such as JavaScript) to request user authorization using a simplified method. Communication leverages HTML's iframe element, child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint. It is clear to me that this work could be in scope for OAuth and I want to be sure that both: - there is no interest within the WG in pursuing this approach - there is no perceived harm to existing OAuth work if this goes ahead I'd appreciate any opinions. Many thanks, Adrian -- Adrian Farrel (Independent Submissions Editor), rfc-ise@rfc-editor.org [1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/ [2] https://www.rfc-editor.org/about/independent/ > > -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Mon Feb 15 11:58:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210963A106F for ; Mon, 15 Feb 2021 11:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPsJ9d481sXM for ; Mon, 15 Feb 2021 11:58:51 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1AE3A1076 for ; Mon, 15 Feb 2021 11:58:50 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id p193so8304569yba.4 for ; Mon, 15 Feb 2021 11:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8kda1FRmf2FQRtSftb1nuu7sDyefHvSvy1kR+0wnMms=; b=qa+/kYuq9peHQ/ue1vaHufnb86HksNe0clBzVpvpmS+Zg6tH98TTz1Y2ssdMxjFGpU pTAtZaRSrj7gQKpOTH/s605IWGRz3lCnA+2rEhJfWtS9U5HAv7fN5Irv/IZxL/d4rg7M 4Bg42xe3aKL5rhoDOduiif4x/8PUemY4bu7Sfy9jHC5pd7tMrpfdOTpSEe5jvrQVk91X OM53+C8jOG9U30tBa5iWodRLoUTRjN9BX55Z7RS+EIQhwzjD17K26J4xj8RY/WE8zaN2 CRMR9UTL1VLAItcnytYWmVJMZ33va1NVhSh2bIdP4jR+QcQ+2U9t1x4xvHYekdDOX92c f8Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8kda1FRmf2FQRtSftb1nuu7sDyefHvSvy1kR+0wnMms=; b=QPfuBbIyrbevDIAvjDx3NAxqpaI4wKD58a3LADP4xXlMVsHcJ7ziKErnfyuoCP5rNc olQOdSkFgWg1soZrY/1lnme2H++OE3TgR2Qwxmyn3ezcVNe8MxGvr1v0IjlDiIFRPC3k TzDDN4/zcTN2loUNPpiy9pY5EqEHzu37YP5dULTCk8LjfBsLnWjolqXe6iZW0T0GOuPO iNowe45gqAn7Np1eXued6OWZ6m20OIvvkNpKlimfYVkSdGltJMzgLvjMiCV3iCQ7nbGF q/vKWG5NpVCcZfCsIWmEQkpjZo2XFMeG7S03yrgYutNE+QgGb7LtOBzI2HOr38RStKzj BOfw== X-Gm-Message-State: AOAM531Mcg7SXuMCawRYZC+DqKONAY1rOCWZ/caKl7B5sWEYJMkcoUrZ NHYwfO2RUiQVyZfPgcmh24lmackI5oMrLUg+ZxEEMnlGQo0= X-Google-Smtp-Source: ABdhPJw9fDdaWrm8qsrx84JD9Gs704DS7uKST4VRpDWNvex40Z0WLpqbwoSnGlzUWFZ3kNX2EpFCIu4/jpPN/0o+ww8= X-Received: by 2002:a25:a541:: with SMTP id h59mr25712823ybi.203.1613419129656; Mon, 15 Feb 2021 11:58:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Joey Galvin Date: Mon, 15 Feb 2021 11:58:38 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000018daf205bb656a72" Archived-At: Subject: Re: [OAUTH-WG] OAuth Digest, Vol 148, Issue 45 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 19:58:54 -0000 --00000000000018daf205bb656a72 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 15, 2021 at 3:34 AM wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Token Mediating and session Information Backend For > Frontend (TMI BFF) (Philippe De Ryck) > 2. Re: Token Mediating and session Information Backend For > Frontend (TMI BFF) (Neil Madden) > 3. Re: Authorization Header Encoding (Vladimir Dzhuvinov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Feb 2021 12:09:10 +0100 > From: Philippe De Ryck > To: Neil Madden > Cc: Vittorio Bertocci , oauth@ietf.org > Subject: Re: [OAUTH-WG] Token Mediating and session Information > Backend For Frontend (TMI BFF) > Message-ID: > <8B710018-3605-483D-B4A8-191A5BBFFEBC@pragmaticwebsecurity.com> > Content-Type: text/plain; charset="utf-8" > > > > > On 15 Feb 2021, at 11:50, Neil Madden wrote: > > > >> On 15 Feb 2021, at 10:26, Philippe De Ryck < > philippe@pragmaticwebsecurity.com> wrote: > >> > >>> On 15 Feb 2021, at 11:14, Neil Madden > wrote: > >>> > >>>> On 15 Feb 2021, at 08:32, Philippe De Ryck < > philippe@pragmaticwebsecurity.com philippe@pragmaticwebsecurity.com>> wrote: > >>>> > >>>> [...] > >>>> > >>>> Compared to using a worker for handling RTs, I believe the TMI-BFF > only adds a single security benefit: an attacker is no longer able to run a > silent flow to obtain a fresh set of tokens (since the client is now a > confidential client). > >>> > >>> But they can just call the bff-token endpoint to do the same. If there > is a security advantage, IMO it is as a defence in depth against open > redirects, unicode normalisation attacks (ie not validating the > redirect_uri correctly at the AS), etc. > >> > >> A Web Worker and the TMI-BFF both encapsulate the RT and only expose > the (short-lived) AT. > > > > I don?t think this distinction matters at all from a security point of > view. It?s the AT that attackers are after - why bother with a RT if I can > just call the bff-token endpoint to get a new AT every time? > > Getting an AT from the BFF (or a worker) is an ?online? attack, which only > works as long as the application/malicious code is loaded in the browser of > the user. > > Stealing a working refresh token (e.g., with a silent flow) is an > ?offline? attack, which gives long-term access (lifetime of the RT), > independent of the state of the application in the user?s browser. > > There is a clear distinction, but whether that matters is a different > discussion. It depends on how the application used, and how token lifetimes > are configured. FWIW, the DPoP threat model makes the same distinction > ("Stolen token (XSS)? vs ?XSS (Victim is online)?) here: > https://danielfett.de/2020/05/04/dpop-attacker-model/ < > https://danielfett.de/2020/05/04/dpop-attacker-model/> > > Philippe > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/9caa8a97/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Mon, 15 Feb 2021 11:15:47 +0000 > From: Neil Madden > To: Philippe De Ryck > Cc: Vittorio Bertocci , oauth@ietf.org > Subject: Re: [OAUTH-WG] Token Mediating and session Information > Backend For Frontend (TMI BFF) > Message-ID: <17812F95-7350-4595-9867-EF9D9452CC07@forgerock.com> > Content-Type: text/plain; charset="utf-8" > > Yes, I?ve argued against this distinction for DPoP too. Since the first > days of HttpOnly attackers learnt to proxy requests through the browser (as > you know of course). This is not only to bypass the restrictions but it?s > also just much better for the attacker because it hides their traffic and > origin. People are online all the time now, so this is at best a mild > inconvenience. > > ? Neil > > > On 15 Feb 2021, at 11:09, Philippe De Ryck < > philippe@pragmaticwebsecurity.com> wrote: > > > > ? > >> > >>> On 15 Feb 2021, at 11:50, Neil Madden > wrote: > >>> > >>>> On 15 Feb 2021, at 10:26, Philippe De Ryck < > philippe@pragmaticwebsecurity.com> wrote: > >>> > >>>>> On 15 Feb 2021, at 11:14, Neil Madden > wrote: > >>>>> > >>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck < > philippe@pragmaticwebsecurity.com> wrote: > >>>>>> > >>>>> [...] > >>>>> > >>>>> Compared to using a worker for handling RTs, I believe the TMI-BFF > only adds a single security benefit: an attacker is no longer able to run a > silent flow to obtain a fresh set of tokens (since the client is now a > confidential client). > >>>> > >>>> But they can just call the bff-token endpoint to do the same. If > there is a security advantage, IMO it is as a defence in depth against open > redirects, unicode normalisation attacks (ie not validating the > redirect_uri correctly at the AS), etc. > >>> > >>> A Web Worker and the TMI-BFF both encapsulate the RT and only expose > the (short-lived) AT. > >> > >> I don?t think this distinction matters at all from a security point of > view. It?s the AT that attackers are after - why bother with a RT if I can > just call the bff-token endpoint to get a new AT every time? > > > > Getting an AT from the BFF (or a worker) is an ?online? attack, which > only works as long as the application/malicious code is loaded in the > browser of the user. > > > > Stealing a working refresh token (e.g., with a silent flow) is an > ?offline? attack, which gives long-term access (lifetime of the RT), > independent of the state of the application in the user?s browser. > > > > There is a clear distinction, but whether that matters is a different > discussion. It depends on how the application used, and how token lifetimes > are configured. FWIW, the DPoP threat model makes the same distinction > ("Stolen token (XSS)? vs ?XSS (Victim is online)?) here: > https://danielfett.de/2020/05/04/dpop-attacker-model/ > > > > Philippe > > > > > > -- > ForgeRock values your Privacy > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/6d5945f3/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Mon, 15 Feb 2021 13:34:10 +0200 > From: Vladimir Dzhuvinov > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Authorization Header Encoding > Message-ID: <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2id.com> > Content-Type: text/plain; charset="utf-8" > > Hi Justin, > > Thanks for alerting us on this development. > > +1 for keeping the updated HTTP semantics unencumbered by the > Authorization header formatting in RFC 6750. > > IMO revising the RFC 6750 to reflect that is too late now, as few people > will notice. So updating the Bearer header definition in OAuth 2.1 seems > like the most sensible move. I expect OAuth 2.0 implementers who > maintain their software to pick up the 2.1 spec, sooner or later. > > Vladimir > > > On 12/02/2021 00:01, Justin Richer wrote: > > The HTTP Working Group opened an issue for discussion in relation to > > the updated HTTP semantics specification. The core of the issue is the > > format of the ?Authorization? header, which of course gets used by the > > ?Bearer? scheme defined in RFC6750. > > > > https://github.com/httpwg/http-core/issues/733 > > > > As it turns out, Bearer defines a more limited character set than is > > allowed by core HTTP, and doesn?t follow the HTTP guidelines and > > definitions for the Authorization header. There were a few > > observations on the call: > > > > ?- The Bearer spec was limited because OAuth tokens were also allowed > > in HTTP URLs and form parameters (and therefore had to have a more > > limited character set) > > ?- In practice people don?t actually restrict the values they put into > > this field; pretty much any implementation is just going to > > concatenate whatever access token value they get to the magic word > > ?Bearer? and send it > > ?- It?s not likely (or in my opinion proper) for the HTTP spec to > > change to address the oddities of RFC6750 and decisions that were made > > many years ago > > > > So the question is, what do we do about it? We could do a revision of > > 6750 that reflects reality better, pretty much just changing the ABNF. > > > > Or, we could update the definition of the Bearer header in the > > upcoming OAuth 2.1 specification. > > > > Are there other options? > > > > ?? Justin > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- > Vladimir Dzhuvinov > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/10958cdf/attachment.htm > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4007 bytes > Desc: S/MIME Cryptographic Signature > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/10958cdf/attachment.p7s > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 148, Issue 45 > ************************************** > --00000000000018daf205bb656a72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 15, 2021 at 3:34 AM <oauth-request@ietf.org> wrote:
Send OAuth mailing list submi= ssions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Token Mediating and session Information Backend For
=C2=A0 =C2=A0 =C2=A0 Frontend (TMI BFF) (Philippe De Ryck)
=C2=A0 =C2=A02. Re: Token Mediating and session Information Backend For
=C2=A0 =C2=A0 =C2=A0 Frontend (TMI BFF) (Neil Madden)
=C2=A0 =C2=A03. Re: Authorization Header Encoding (Vladimir Dzhuvinov)


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

Message: 1
Date: Mon, 15 Feb 2021 12:09:10 +0100
From: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Mediating and session Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Backend For Frontend (TMI BFF)
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <8B710018-3605-483D-= B4A8-191A5BBFFEBC@pragmaticwebsecurity.com>
Content-Type: text/plain; charset=3D"utf-8"

>
> On 15 Feb 2021, at 11:50, Neil Madden <neil.madden@forgerock.com> wrote:=
>
>> On 15 Feb 2021, at 10:26, Philippe De Ryck <philippe@pragmaticwebse= curity.com> wrote:
>>
>>> On 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.com &l= t;mailto:nei= l.madden@forgerock.com>> wrote:
>>>
>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck <philippe@pragma= ticwebsecurity.com <mailto:philippe@pragmaticwebsecurity.com>>= wrote:
>>>>
>>>> [...]
>>>>
>>>> Compared to using a worker for handling RTs, I believe the= TMI-BFF only adds a single security benefit: an attacker is no longer able= to run a silent flow to obtain a fresh set of tokens (since the client is = now a confidential client).
>>>
>>> But they can just call the bff-token endpoint to do the same. = If there is a security advantage, IMO it is as a defence in depth against o= pen redirects, unicode normalisation attacks (ie not validating the redirec= t_uri correctly at the AS), etc.
>>
>> A Web Worker and the TMI-BFF both encapsulate the RT and only expo= se the (short-lived) AT.
>
> I don?t think this distinction matters at all from a security point of= view. It?s the AT that attackers are after - why bother with a RT if I can= just call the bff-token endpoint to get a new AT every time?

Getting an AT from the BFF (or a worker) is an ?online? attack, which only = works as long as the application/malicious code is loaded in the browser of= the user.

Stealing a working refresh token (e.g., with a silent flow) is an ?offline?= attack, which gives long-term access (lifetime of the RT), independent of = the state of the application in the user?s browser.

There is a clear distinction, but whether that matters is a different discu= ssion. It depends on how the application used, and how token lifetimes are = configured. FWIW, the DPoP threat model makes the same distinction ("S= tolen token (XSS)? vs ?XSS (Victim is online)?) here: https://danielfett.de/2020/05/04/dpop-attacker-model/ <https://danielfett.de/2020/05/04/dpop-attacker-model/= >

Philippe


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <= https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/9caa8a9= 7/attachment.htm>

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

Message: 2
Date: Mon, 15 Feb 2021 11:15:47 +0000
From: Neil Madden <neil.madden@forgerock.com>
To: Philippe De Ryck <philippe@pragmaticwebsecurity.com>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, oauth@ietf.org
Subject: Re: [OAUTH-WG] Token Mediating and session Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Backend For Frontend (TMI BFF)
Message-ID: <17812F95-7350-4595-9867-EF9D9452CC07@forgerock= .com>
Content-Type: text/plain; charset=3D"utf-8"

Yes, I?ve argued against this distinction for DPoP too. Since the first day= s of HttpOnly attackers learnt to proxy requests through the browser (as yo= u know of course). This is not only to bypass the restrictions but it?s als= o just much better for the attacker because it hides their traffic and orig= in. People are online all the time now, so this is at best a mild inconveni= ence.

? Neil

> On 15 Feb 2021, at 11:09, Philippe De Ryck <philippe@pragmaticwebsecuri= ty.com> wrote:
>
> ?
>>
>>> On 15 Feb 2021, at 11:50, Neil Madden <neil.madden@forgerock.com>= ; wrote:
>>>
>>>> On 15 Feb 2021, at 10:26, Philippe De Ryck <philippe@pragma= ticwebsecurity.com> wrote:
>>>
>>>>> On 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.co= m> wrote:
>>>>>
>>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck <philipp= e@pragmaticwebsecurity.com> wrote:
>>>>>>
>>>>> [...]
>>>>>
>>>>> Compared to using a worker for handling RTs, I believe= the TMI-BFF only adds a single security benefit: an attacker is no longer = able to run a silent flow to obtain a fresh set of tokens (since the client= is now a confidential client).
>>>>
>>>> But they can just call the bff-token endpoint to do the sa= me. If there is a security advantage, IMO it is as a defence in depth again= st open redirects, unicode normalisation attacks (ie not validating the red= irect_uri correctly at the AS), etc.
>>>
>>> A Web Worker and the TMI-BFF both encapsulate the RT and only = expose the (short-lived) AT.
>>
>> I don?t think this distinction matters at all from a security poin= t of view. It?s the AT that attackers are after - why bother with a RT if I= can just call the bff-token endpoint to get a new AT every time?
>
> Getting an AT from the BFF (or a worker) is an ?online? attack, which = only works as long as the application/malicious code is loaded in the brows= er of the user.
>
> Stealing a working refresh token (e.g., with a silent flow) is an ?off= line? attack, which gives long-term access (lifetime of the RT), independen= t of the state of the application in the user?s browser.
>
> There is a clear distinction, but whether that matters is a different = discussion. It depends on how the application used, and how token lifetimes= are configured. FWIW, the DPoP threat model makes the same distinction (&q= uot;Stolen token (XSS)? vs ?XSS (Victim is online)?) here: https://danielfett.de/2020/05/04/dpop-attacker-model/
>
> Philippe
>=C2=A0
>

--
ForgeRock values your Privacy <https://www.forgerock.com/yo= ur-privacy>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <= https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/6d5945f= 3/attachment.htm>

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

Message: 3
Date: Mon, 15 Feb 2021 13:34:10 +0200
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
To: oauth@ietf.org<= br> Subject: Re: [OAUTH-WG] Authorization Header Encoding
Message-ID: <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2= id.com>
Content-Type: text/plain; charset=3D"utf-8"

Hi Justin,

Thanks for alerting us on this development.

+1 for keeping the updated HTTP semantics unencumbered by the
Authorization header formatting in RFC 6750.

IMO revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAuth 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers who
maintain their software to pick up the 2.1 spec, sooner or later.

Vladimir


On 12/02/2021 00:01, Justin Richer wrote:
> The HTTP Working Group opened an issue for discussion in relation to > the updated HTTP semantics specification. The core of the issue is the=
> format of the ?Authorization? header, which of course gets used by the=
> ?Bearer? scheme defined in RFC6750.
>
> https://github.com/httpwg/http-core/issues/733
>
> As it turns out, Bearer defines a more limited character set than is > allowed by core HTTP, and doesn?t follow the HTTP guidelines and
> definitions for the Authorization header. There were a few
> observations on the call:
>
> ?- The Bearer spec was limited because OAuth tokens were also allowed<= br> > in HTTP URLs and form parameters (and therefore had to have a more
> limited character set)
> ?- In practice people don?t actually restrict the values they put into=
> this field; pretty much any implementation is just going to
> concatenate whatever access token value they get to the magic word
> ?Bearer? and send it
> ?- It?s not likely (or in my opinion proper) for the HTTP spec to
> change to address the oddities of RFC6750 and decisions that were made=
> many years ago
>
> So the question is, what do we do about it? We could do a revision of<= br> > 6750 that reflects reality better, pretty much just changing the ABNF.=
>
> Or, we could update the definition of the Bearer header in the
> upcoming OAuth 2.1 specification.
>
> Are there other options?
>
> ?? Justin
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

--
Vladimir Dzhuvinov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <= https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/10958cd= f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <= https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210215/10958cd= f/attachment.p7s>

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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 148, Issue 45
**************************************
--00000000000018daf205bb656a72-- From nobody Mon Feb 15 11:59:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552633A108B for ; Mon, 15 Feb 2021 11:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.147 X-Spam-Level: ** X-Spam-Status: No, score=2.147 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, EMPTY_MESSAGE=2.344, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00yFqv5gLn0n for ; Mon, 15 Feb 2021 11:59:05 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292303A10B8 for ; Mon, 15 Feb 2021 11:59:05 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id n195so8270182ybg.9 for ; Mon, 15 Feb 2021 11:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CIjLpbnlslJzYYwqz0w3nvBikbnlpDNzyoXgJPwT4HM=; b=rICk0r/JirgwuICvMJqOkVwbZB543bklXB4+rccFG8sWiCz6c6pe4ZB0dPLDMiRYk6 Wv+BM57JbiDyfvOJOSkoHeDNwdlcN/34qd7BN9YiAXdUSIAgBmzsjEs+sICN/RTUdK5f GN+E0VQlKyLhftcENeVGlN7rZeBDhZqBdZD9Nq9xjvhWRkIw0h2SLQziwMjY9g2p1aTR 4uXfxaHb+4hTZL0liGU7AYX6ZcLI8ndiYZNRjiwNcGNnoan8uedHdDApnCum9eBT5AKc 8fnbWSUkM8SVQHYbEUXZWIzVxBPcMgeikO5qBBwwRGXssmylSjE3pMeN+a4Mir1u6GIA EyKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CIjLpbnlslJzYYwqz0w3nvBikbnlpDNzyoXgJPwT4HM=; b=IkKr7F7OAJv8/fvuhSDdEVknxNAROYUqJJRBHZr2N0MQFdQMsODTuVZq+Q9hi4NmaG OPvF6bT5k23DmflbvW4ACRxTHvVI2x1jJq2HLoYvCgGJbMjGdY/EFqQPQpm3IMTGqLMt 3781b1GbLXyltaZF9nVfW+0ShR/sxRnfucI7+cCb4W/9xbMRyftbvNQtXf6SVi0V8veu LwiA6vAjy7PDqRAOvHKGFSbbeSodgUWSeeQspnFJACW13UO+Ysg3pypCzkpVN0rpnM+W 5B4hvFPPlIBOSjK/cL7P+XtYeL/wyd0wbmHG5e/8uf1HQnjmPk4OqWTUkwKYP6WxUxnp LTIw== X-Gm-Message-State: AOAM533xaJ7/m5NJUd84UE1bNYI74gHdTjBzPtfZp7IALQY6h8F5CrT9 z+ivQR1nA2DbsbxbQrmhoPFjTjZQMXgBxDqSbewXx8S3ljc= X-Google-Smtp-Source: ABdhPJwCNhkcRoPSVnaZTM3Vklh69ePK73RDX0zAdCri5LOobJoY7YHqSjN8mmJGh9RTOt1WDOvF+YTJpYRjrNUmfUU= X-Received: by 2002:a25:cbc8:: with SMTP id b191mr25454588ybg.61.1613419144236; Mon, 15 Feb 2021 11:59:04 -0800 (PST) MIME-Version: 1.0 From: Joey Galvin Date: Mon, 15 Feb 2021 11:58:53 -0800 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f7508805bb656acf" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 19:59:12 -0000 --000000000000f7508805bb656acf Content-Type: text/plain; charset="UTF-8" --000000000000f7508805bb656acf Content-Type: text/html; charset="UTF-8"

--000000000000f7508805bb656acf-- From nobody Tue Feb 16 09:00:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928893A0BB3 for ; Tue, 16 Feb 2021 09:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVDgrP5NQ6bi for ; Tue, 16 Feb 2021 08:59:58 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B253A0CE2 for ; Tue, 16 Feb 2021 08:59:48 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id o15so8845889ilt.6 for ; Tue, 16 Feb 2021 08:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qPAmAsx22+qMJVzPrChXxrH/cQ9oAuszjcZE01al6IE=; b=A0QQBZcxVkCO/GiahUmT4ARAQAlrYonHbV92gOmmdlgVATjes68VhfmDK8536+ZlYZ LF1h//m7AZarr3geUMnQNRcTHCcbSWdM7NF6sROZSQCJwtIE8crULf4jCXlE2vHg7tDs um4Uy4JBr4WRnh4MRHIw6/4McsTCoAIS55bA+/D0Y//QsDvsSmLQrHdMieaDfp+oL17M ZECtVoyJNZayHeT/ekZ21nGNLG8gUgm0WvFjWNQM/2XSsw+VQAuAygTWX8LPbe75SQFQ upHq1+YUQPMWOHziuMHc/8CjUY95p3Le4HEfNOulJNC19i5O8MI3NaSg5DDhI70iD7d0 Cg+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qPAmAsx22+qMJVzPrChXxrH/cQ9oAuszjcZE01al6IE=; b=RKljy2goaN3a+iCPNQlY6TM3eb0fzV34/2/UnnjSHTgVYuY6WDTZDvKWJOr+gLnbKT hXxD5glsLLou4Jy4jdPb2MwPLLkoigxCOGU1uoHBV5revUYQUpnzb23xIv1xYG1jxRER 5xp18JobJk2TK5N2e5mvfvn5OPksanZk9CiU3WVhWxRCdaZpvqqJVl3YC+Why4a6XZsW 3J/EttNYmQZzZbdI7cPvtBt9Of15NKWxnm2Fnq2QlEOLYd7jO5T6SgtI3MYAlzeAMBAA 7gVUopfc9DZbOtIpLOC6586eM4S6w4f2H1ErB4AdaB99LeZY/CF7tNHu3pHqfngn+ACG w//Q== X-Gm-Message-State: AOAM532qGvqVU7aks62qQ5Ye8kqQdkrT1xfeCiAXuI90Q0brrtkzcOdK 3ZBnWw8jin2J2++1vkrmxwHdJ5u9+MpmtvC491DkSzGHdEsOJg== X-Google-Smtp-Source: ABdhPJwu8j9HHg/6A4UH97tn7HH7RN3ycMj/0k9JXpxLx0nwi4PTajDgSy02flPYX4TlOEwvb7Dp40Z7q/fxvZCzaY8= X-Received: by 2002:a92:1e12:: with SMTP id e18mr17620055ile.270.1613494787111; Tue, 16 Feb 2021 08:59:47 -0800 (PST) MIME-Version: 1.0 From: Roberto Polli Date: Tue, 16 Feb 2021 17:59:36 +0100 Message-ID: To: oauth@ietf.org Cc: Giuseppe De Marco Content-Type: multipart/alternative; boundary="000000000000a2018405bb7707de" Archived-At: Subject: [OAUTH-WG] OAuth 2.1 and TLS X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 17:00:04 -0000 --000000000000a2018405bb7707de Content-Type: text/plain; charset="UTF-8" Hi everybody, I provided some feedback on TLS usage on OAuth 2.1. You can find it in this commentable PR: - https://github.com/aaronpk/oauth-v2-1/pull/30/files As a first-time reader of this I-D I found that the various references to TLS were a bit confusing because: - sometimes it was explicitly stated as MUST - sometimes it was not mentioned - in other parts it's MAY not use TLS (eg. `loopback`). Moreover various information on how to process TLS were given: I am not sure whether this makes the spec more secure or less secure, as there are spec related to TLS security including RFC8740 which does not seem to be included (it's not in BCP195, which applies to TLS<=1.2). Probably we need a way to delegate elsewhere all the quirks of TLS/whatever channel security mechanism is used. The general idea of the above PR is to: - move everything about TLS to a specific section; - state that MUST TLS unless `loopback`; - further quotes of TLS are expected to be non-normative. Feedback welcome, R --000000000000a2018405bb7707de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everybody,

I provided some feedback = on TLS usage on OAuth 2.1.
You can find it in this commentable PR= :



TLS/whatever channel security mechanism is used.

The general idea of the above PR is to:

=
- move everything about TLS to a specific section;
- s= tate that MUST TLS unless `loopback`;
- further quotes of TLS are= expected to be non-normative.

Feedback welcome,
R


--000000000000a2018405bb7707de-- From nobody Tue Feb 16 13:01:02 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C900E3A10F0 for ; Tue, 16 Feb 2021 13:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9aT82h3FtDR for ; Tue, 16 Feb 2021 13:00:57 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB09B3A1106 for ; Tue, 16 Feb 2021 13:00:27 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id e17so13574770ljl.8 for ; Tue, 16 Feb 2021 13:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WU7uP90TTa8iafQkCGeXChCLhiHB4ZuI2mPl2olaDD4=; b=TOz3/WtkXWXbJrKePDZrbJokY2FRDxYMiogQWoqO/LfFZJhaEv/YJ7uhHNnyFLGU4j jJsSpJ0YQthRNmY2xwMaQDnrFY2TXDM+j8MRy8QVId/5VeBNQKVU1jYDwC6or6Ta1VBV eTYOM5D9tnA11MdcsjAXc7PitgxYH/4UWuxMJX9YtlsxGTcSiTH8452G/ACHNaKsQ0zv B2jukJBwBgsVhL6YodHLTGS0GnIWLr2vLVQGvkKoaJIoP4QXd/VROWhRMgQqzWdi7cBG MiMwVLzGh3s4lH2cKgmPpkktSnX9eK1Iaa1YQTMghVLEc67QwDgEc9tZPBuYKdO8jiPq Zm8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WU7uP90TTa8iafQkCGeXChCLhiHB4ZuI2mPl2olaDD4=; b=LlyAsUHsuA116aTTkPBsP5IhTjmxy485++Vy1WYGoPAEuBIKVuh5+vX4OqpG92g6OM ohBgHGzkuvMpBtgBWRQ08EL9oog6qJjPUeJkhW3RqDxcG+YCgftsze04bdO05e3JPMY5 PS7D7GmMxULTnE+uAYF5d+nnJfgk3qifWgx4JJolcaYY5nNKuttpWiooPkD83jjZ8TmK /8Nq4mfbtY61HoY+bpkmvXY+OQjghoZ2ifDWgQ6/tqr5Ep8luzDEoaRinegML7TqFUV4 TmdHWFhTDY42zox4mdQ0VNLoh6zlMpFEZPq/9nwV1QEyIE8ewslmirwOrAbBptfJu5jp tmPA== X-Gm-Message-State: AOAM5307H9Oe+5anAIqPnXgSSI7jIp+Lrf995dGY931DduRzTfVUvnzY 4lHCWCBj6pA36EFLYn8XQdAgELGGFSTG7CiOCBd+LBVnEUxE1VOXEI1B6L3bIfodL+8zlqPhfHU IJl2rRNcv1rCrpA== X-Google-Smtp-Source: ABdhPJygKEjxmI/RJGjubJ268O4tc/qYJm8tz/KAHSAvIyzXyq3prGc3UINl29LozR4wOwVjx+vtwclsZnzyO9Xf9js= X-Received: by 2002:a2e:9893:: with SMTP id b19mr9683867ljj.489.1613509224282; Tue, 16 Feb 2021 13:00:24 -0800 (PST) MIME-Version: 1.0 References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> In-Reply-To: <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> From: Brian Campbell Date: Tue, 16 Feb 2021 13:59:57 -0700 Message-ID: To: Torsten Lodderstedt Cc: Vittorio Bertocci , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000027d7f805bb7a64a7" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 21:00:59 -0000 --00000000000027d7f805bb7a64a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt wrote: > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > We did attempt to capture the assumptions in the draft but clearly could have done a better job with it :) > > As I understand it now the core contribution of your proposal is to move > refresh token management from frontend to backend. Is that correct? > Taking that a bit further - the idea is that the backend takes on the responsibilities of being a confidential client (client creds, token acquisition, token management/persistence, etc.) to the external AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000027d7f805bb7a64a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Tha= nk you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000027d7f805bb7a64a7-- From nobody Tue Feb 16 15:53:57 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78D3A12F4; Tue, 16 Feb 2021 15:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyIwUD-JPvBR; Tue, 16 Feb 2021 15:53:46 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E733A12F8; Tue, 16 Feb 2021 15:53:46 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id d3so18696059lfg.10; Tue, 16 Feb 2021 15:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mEaEvD4I0M1y38cj3LRzGWbxz8pjwEbnkPW9OvARtK0=; b=eNbYQ5CXr9HPLCcKy8gitFhq7PhBzNCNN7QbSJn9HY0JaGRb36Mxg0hcq2Chym1i9R oQj4xrJQ69fqIDxAoWdMPVVoG9mFhuxBjM2H38hrcgObZAyrN/nAsUgqIiyC1Aa9J686 LL3XODNObQVisZk8WYVDaSFG0+kaudTttS5cHwfeGNqzjJnd1jPyXxZ9G5OwqLo3cc3K d0IsrJcPfgqIGrEYoiplZS6gyR++NTcr/sKTY8ZJNiCh/sqOxgu1a6yWvLKPjg5esRHO 5FiCjtFXywhqFxJxjuivHHa7HvcbxooxDnP+TLDAvp0+idrhmz/zIfXNf3X8Xt8rpB66 R+iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mEaEvD4I0M1y38cj3LRzGWbxz8pjwEbnkPW9OvARtK0=; b=m15FiOB5vG+NjGPihh8eoPLtENoP8AcnSOLHUYfxlxoaHyE4/+f0w+2KIICbHyPR95 DUcsUvzVn8Ro8yyl7Pa+2kbQA+rIwyEXBEIonhsJdyPhqrWRDO1UEsXbipzuizLBkYMj AQZ4qtn66+R3an11cS4y8N4WHuBPM5r9UHREkVY+Znh/OgYcY5QCJ25kJO0WWHGft/WQ HUYcCtGzfLRQWVhL5Y+n+s1EANxc1PDeMsNTQIUu1rcB2aB0kqgsls7B2ihC92fXhJt1 I8NumZQildgirhZQmqALDyhDago0uiPnken1JMjrk4V3nneuCU4k5onWZN5sFamDqodd UYGA== X-Gm-Message-State: AOAM5330LFK7Lt4Wbzv3xjHBI3HF4KY4WcVprmFV3cGXTCkcOarGBcLd YdYWQdP/+rExMz84a1NpaL0NMtFrEV7e2ynRjWr8I2O/O9Y= X-Google-Smtp-Source: ABdhPJwjDork1kJKRI2QygwlviHit+waOm6PBfYBAla0Uak5bgzGpCK+73TVD4xUOq+YAPguNOxwwFbHJCu0StIexRA= X-Received: by 2002:a19:9c1:: with SMTP id 184mr12770178lfj.582.1613519624660; Tue, 16 Feb 2021 15:53:44 -0800 (PST) MIME-Version: 1.0 References: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> In-Reply-To: <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> From: Rifaat Shekh-Yusef Date: Tue, 16 Feb 2021 18:53:33 -0500 Message-ID: To: rfc-ise@rfc-editor.org Cc: draft-ideskog-assisted-token@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000010ebb805bb7cd05e" Archived-At: Subject: Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 23:53:49 -0000 --00000000000010ebb805bb7cd05e Content-Type: text/plain; charset="UTF-8" Hi Adrian, This document is definitely in scope for the OAuth WG. We are planning a series of virtual interim meetings after the coming IETF conference, and we would be happy to schedule one of these meetings to discuss this document. Regards, Rifaat On Mon, Feb 15, 2021 at 1:59 PM RFC ISE (Adrian Farrel) < rfc-ise@rfc-editor.org> wrote: > Hi OAuth, > > The authors of draft-ideskog-assisted-token [1] have approached me > requesting that the draft be published as an Informational RFC in the > Independent Submission Stream [2]. > > The draft extends the OAuth 2.0 framework to include an additional > authorization flow for single page applications called the assisted token > flow. It is intended to enable OAuth clients that are written in > scripting languages (such as JavaScript) to request user authorization > using a simplified method. Communication leverages HTML's iframe element, > child windows, and the postMessage interface. This communication is done > using an additional endpoint, the assisted token endpoint. > > It is clear to me that this work could be in scope for OAuth and I want to > be sure that both: > - there is no interest within the WG in pursuing this approach > - there is no perceived harm to existing OAuth work if this goes ahead > > I'd appreciate any opinions. > > Many thanks, > Adrian > -- > Adrian Farrel (Independent Submissions Editor), > rfc-ise@rfc-editor.org > > [1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/ > [2] https://www.rfc-editor.org/about/independent/ > > > > > > > -- > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000010ebb805bb7cd05e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

This document is definitely = in scope for the OAuth WG.
We are planning a series of virtual in= terim meetings after the=C2=A0coming IETF conference, and we would be happy= to schedule one of these meetings to discuss this document.

=
Regards,
=C2=A0Rifaat


On Mon, Feb = 15, 2021 at 1:59 PM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org> wrote:
<= /div>
Hi OAuth,

The authors of draft-ideskog-assisted-token [1] have approached me
requesting that the draft be published as an Informational RFC in the
Independent Submission Stream [2].

The draft extends the OAuth 2.0 framework to include an additional
authorization flow for single page applications called the assisted token flow. It is intended to enable OAuth clients that are written in
scripting languages (such as JavaScript) to request user authorization
using a simplified method. Communication leverages HTML's iframe elemen= t,
child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint.

It is clear to me that this work could be in scope for OAuth and I want to<= br> be sure that both:
- there is no interest within the WG in pursuing this approach
- there is no perceived harm to existing OAuth work if this goes ahead

I'd appreciate any opinions.

Many thanks,
Adrian
--
Adrian Farrel (Independent Submissions Editor),
rfc-ise@rfc-edi= tor.org

[1] https://datatracker.ietf.org/doc/d= raft-ideskog-assisted-token/
[2] https://www.rfc-editor.org/about/independent/ >
>


--
Adrian Farrel (ISE),
rfc-ise@rfc-edi= tor.org

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000010ebb805bb7cd05e-- From nobody Wed Feb 17 00:27:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099BE3A17F8 for ; Wed, 17 Feb 2021 00:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzJ1BGgAGYBs for ; Wed, 17 Feb 2021 00:27:08 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655383A17F6 for ; Wed, 17 Feb 2021 00:27:08 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id p15so10570074ilq.8 for ; Wed, 17 Feb 2021 00:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=dbSePIKpmTOlnKVHuBGZCCjDalfganB+BIs2o+Pl4zo=; b=ivjy3HUTCKtyOFSoW7N7kaxePzj4SG7xgWhLhB74lJuhgD+GpgeIVxOgUN0mjav6UF zCFXhm3E2ufoozYq/cHfzYPuj7o/88yFx6PMCckA+s0XSsnIdZDSE0VLLwgjkp6fOBSw Mp0LqHCKtjEmJgT8zWh8WnEL2n52nMihzLqor0/UJO+iQgM6ZVRKl4V9kbZguV4qS8Kx 2jwHKIwp/zLXL06feMlu+JGMlOFAN4DIVb+ON6N3+RHiOmn84ujKSXbSBK7MK/12/mez Lpf2FwMlxqbKgqrQaxI+yfrdXWawOgoJyP9YzvdIrb9BYgbEzdC3CcKpULMb71/CqnL4 4WNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=dbSePIKpmTOlnKVHuBGZCCjDalfganB+BIs2o+Pl4zo=; b=f8W1HtWytFPF6XyuOEmV7Ap5qFG38qJM53LgOMFXPaIIAD/dIcBky0alx2orwzz4Bq OFyCoM8vaDvVYy0+upv/jOca7XswaKl6XN05HEyb70PamhUVqSrDxiHT95L9A+ZjS7Tp 5us5Gm3oCIdPACGQ8yOfw0qonD6wu0gdSj2fVxtZZND/yIKWEhVpU3sAAWLWknhE44TE VYjyeCAyR4MJuujFIIku8UcUTEqkYJdAA3Pi/hwtwMSrHlfb+K03OWyKoC22ilg4nUpU Toyv1kr4uVvZhElxZiO5Sk6h/svEN3JPvSUmxoJT2HyZheovrNnfkF9bevY4fUT1DScI fu0A== X-Gm-Message-State: AOAM531XbwLjcJlUKjeiXk+9DYHI0qs1yrbDg4VgDtuyp1ZG7e5r8fW5 zMVdA8VbYD4PmnqfvKznKrP2jheoneQunQjJGzEuOfu2LaGW X-Google-Smtp-Source: ABdhPJztgpXem+xShD13lt4gNgl4oXJwRo5mHma1tHXrh8TWzm+XMm1v0Pk+qa3LJImuwrRfNg3TpWjtcMpuib8mpDw= X-Received: by 2002:a92:d11:: with SMTP id 17mr21046670iln.57.1613550427429; Wed, 17 Feb 2021 00:27:07 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 00:27:06 -0800 From: Dominick Baier In-Reply-To: References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> MIME-Version: 1.0 Date: Wed, 17 Feb 2021 00:27:06 -0800 Message-ID: To: Brian Campbell , Torsten Lodderstedt Cc: Vittorio Bertocci , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000df56105bb83fceb" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 08:27:10 -0000 --0000000000000df56105bb83fceb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that is all you are aiming at. Wouldn=E2=80=99t that be just an extension to the= =E2=80=9COAuth for web apps BCP?=E2=80=9D. All I can add here is - this approach would not work for any of our customer. Because their real motivation is to implement a more and more common security guideline these days - namely: =E2=80=9Cno JS-accessible to= kens in the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. cheers =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 16. February 2021 at 22:01:37, Brian Campbell ( bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt wrote: > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > We did attempt to capture the assumptions in the draft but clearly could have done a better job with it :) > > As I understand it now the core contribution of your proposal is to move > refresh token management from frontend to backend. Is that correct? > Taking that a bit further - the idea is that the backend takes on the responsibilities of being a confidential client (client creds, token acquisition, token management/persistence, etc.) to the external AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend. *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0000000000000df56105bb83fceb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hey,= =C2=A0

<= /div>
Tbh - I have= a bit of a hard time to see why this requires a spec, if that is all you a= re aiming at. Wouldn=E2=80=99t that be just an extension to the =E2=80=9COA= uth for web apps BCP?=E2=80=9D.

All I can add here is - this approach would not work for any o= f our customer. Because their real motivation is to implement a more and mo= re common security guideline these days - namely: =E2=80=9Cno JS-accessible= tokens in the browser=E2=80=9D - but this document doesn=E2=80=99t cover t= his.

cheers=C2=A0
= =E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40pingident= ity.com@dmarc.ietf.org) wrote:


<= /div>


On Mon, Feb 15, 2021 at 9:48 AM = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Thank you again for the explanation.
I think your assumption about the overall flow should be described in the d= raft.

We did attempt to capture the as= sumptions in the draft but clearly could have done a better job with it :) =
=C2=A0
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--0000000000000df56105bb83fceb-- From nobody Wed Feb 17 09:30:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034523A1C13 for ; Wed, 17 Feb 2021 09:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZExhKqAYDW5X for ; Wed, 17 Feb 2021 09:30:25 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70533A1C05 for ; Wed, 17 Feb 2021 09:30:25 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id p21so3254215pgl.12 for ; Wed, 17 Feb 2021 09:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=XpNKWAHCAHCdIsOyDn5V+DZUAYhm3DjAENUkR8G3I1U=; b=YMF6U3uk2wKT6S+y3QozKe7ZSSLRsT1zkJK8aWo+Ymum4p94J8jFn98l40xlTaqFfK YCRF4xe5WM0d4L8+iZV1Xh6lBVlwIrjcWnjJLrYbEXKxd+rVGPi1X4iiAo1nzXc3jHFl e0wYBn6h/dZ/AUSLxzXbUmKC+Lznv1uy1z5VRua/Vh7WE4zCgfXpmJEZyc/6YKCGd0xh fX2fmMxIDrhlbFsI6503Cn8trcP9Gp4TksEU71GbSisVTKa8zPysJ7sJgGIGXOebPnUC vqmgnywCOwg2K8xhItwxuqamo0AyruqxnLN99zQPgMMkFek/DenR7G4flsvZbFR7V/d+ r5iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=XpNKWAHCAHCdIsOyDn5V+DZUAYhm3DjAENUkR8G3I1U=; b=F0NsJdOb1bsVjbvQzpZ6q/x3Q3Nhmt2xh1qih/546BvwuvKhG0doWclzJBlTikrS1o /wYc6tUEQfjuSoHOQxMGCTQpMzeIjEhgEil8PjWIO2+bAE4uwXu+GkmnsZ2DphEzsbt0 ywnu9bBwehz8qSW1IacuRFErJ5w0JAE/ZLd7LrJXy2JcZZmmgCXFnqVOLnhMTk7FjkOa 6OAz8v8BtrtkNRcKd6a2LvKNBD17nG/v1eBT2uXxCBIRj6M0HNgyktF5RQNciGmCgZwa jtE/xfxSAWQeXegVaNpcQwzIAByKT+rCwgcflpW8nnzmyUuFb4UggbEKSOPy7hVhdb1u vzeg== X-Gm-Message-State: AOAM530mrB+fNrNVfFeTVJRv/qKcywB7pgmtZlTEktcdGFxODezdk3Yz 344gCNNW5Fhp/DmMTh1TiIjZuw== X-Google-Smtp-Source: ABdhPJyytBPvA7LyUMB/0PyqMEERJf+yjBFgOfPiUAcYguikS/e8xhCD6cnwlJrmDVPzduMg9BJYqA== X-Received: by 2002:a65:43ca:: with SMTP id n10mr387016pgp.430.1613583022089; Wed, 17 Feb 2021 09:30:22 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id o24sm2776428pjs.52.2021.02.17.09.30.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2021 09:30:20 -0800 (PST) From: Vittorio Bertocci To: Dominick Baier , Brian Campbell , Torsten Lodderstedt CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Thread-Index: AQHXAYASMR57RiKGBkS9HwYUcalSA6pXs6oAgABV6O+AAAdRAIAADhHdgAFS8QCAAdh3gIAAv/0AgACXxo4= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Wed, 17 Feb 2021 17:30:19 +0000 Message-ID: References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_CO6PR18MB4052BA48231DA27E5C208514AE869CO6PR18MB4052namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 17:30:29 -0000 --_000_CO6PR18MB4052BA48231DA27E5C208514AE869CO6PR18MB4052namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Dominick, It is indeed a very simple spec, but as you can see from the discussion so = far, it doesn=92t appear to be trivial- and there might be some considerati= ons we consider obvious (eg scope escalation) that might not be super clear= otherwise. In terms of the guidance, just to make sure I get the scope right- that mea= ns that also code+PKCE+rotating RTs in JS would not be acceptable for your = customers? From: Dominick Baier Date: Wednesday, February 17, 2021 at 00:27 To: Brian Campbell , Torsten Lodderstedt Cc: Vittorio Bertocci , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For= Frontend (TMI BFF) Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that = is all you are aiming at. Wouldn=92t that be just an extension to the =93OA= uth for web apps BCP?=94. All I can add here is - this approach would not work for any of our custome= r. Because their real motivation is to implement a more and more common sec= urity guideline these days - namely: =93no JS-accessible tokens in the brow= ser=94 - but this document doesn=92t cover this. cheers =97=97=97 Dominick Baier On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40pingidentit= y.com@dmarc.ietf.org)= wrote: On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt > wrote: Thank you again for the explanation. I think your assumption about the overall flow should be described in the d= raft. We did attempt to capture the assumptions in the draft but clearly could ha= ve done a better job with it :) As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct? Taking that a bit further - the idea is that the backend takes on the resp= onsibilities of being a confidential client (client creds, token acquisitio= n, token management/persistence, etc.) to the external AS(s). And TMI BFF d= escribes a way for that backend to deliver access tokens to its own fronten= d. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, di= stribution or disclosure by others is strictly prohibited. If you have rec= eived this communication in error, please notify the sender immediately by = e-mail and delete the message and any file attachments from your computer. = Thank you._______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CO6PR18MB4052BA48231DA27E5C208514AE869CO6PR18MB4052namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=92t appear to be trivial- and there mi= ght be some considerations we consider obvious (eg scope escalation) that m= ight not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

 

From= : Dominick Baier &l= t;dbaier@leastprivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodde= rstedt <torsten@lodderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oau= th@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

 

Hey, 

 

Tbh - I have a bit of a hard time to see why this requires a spec, if th= at is all you are aiming at. Wouldn=92t that be just an extension to the = =93OAuth for web apps BCP?=94.

 

All I can add here is - this approach would not work for any of our cust= omer. Because their real motivation is to implement a more and more common = security guideline these days - namely: =93no JS-accessible tokens in the browser=94 - but this document doesn=92t= cover this.

 

cheers 

=97=97=97

Dominick Baier

 

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D= 40pingidentity.com@dmarc.ietf.org) wrote:

 

 

 

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft.

 

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

 


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct? 

 

 Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.  <= o:p>


CONFIDENTIALITY NOTICE: This email may contain confident= ial and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_CO6PR18MB4052BA48231DA27E5C208514AE869CO6PR18MB4052namp_-- From nobody Wed Feb 17 09:59:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B0E3A1C18 for ; Wed, 17 Feb 2021 09:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone-eu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGAV1o3zaNN4 for ; Wed, 17 Feb 2021 09:59:02 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578A33A1C15 for ; Wed, 17 Feb 2021 09:59:01 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id 68so7006799vsk.11 for ; Wed, 17 Feb 2021 09:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vLkSZ9rmio4EuCYNf+Ya/NVskuEMBMiN84esShUi+UE=; b=X5NvxTk8v05p1ko6TpG3Ud30k1lSw4xNkOyRZi+KLZZqKbd4m2Ar744PMNbc583irI y1qzyMx0yrNQpJurM8HOwMB4QpMTl78qmDK5dxsdNi2/Q8LoB00K2JRhJgVW/x7LDadY 7XFkvn/VPZKHeu3uh2kw8viZqXAgQObOERh6Q7berjpb9tjrCuuLiAAcn/DGEZtysCn7 GNCVSO6tZ91EnTGNOZl8NTQ9saSirFozeKjGVQrGYDXomx9Jjkgv0KORQN9PiJHCwy4L mZPKJVNOvI5yxrNOa98QNgmkHF/yyettW8n6fXZJ3MbAjMJqKiECwA1oHXNg4D9t5zd3 TjQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vLkSZ9rmio4EuCYNf+Ya/NVskuEMBMiN84esShUi+UE=; b=STOG2MEFqqyVfR7ouLzx8noqsP8fzI3p2ExZUH1cY15upn7gTCG5/tcuXRqNflcq6x sEUgL8+4++Q3ZV+QHSws3trsTrj47h9h2DkV0kJbIRz8zvz1flYgJVmGmAWNBMGEfKJx 9Emjs+t0vNOOX+ljQRfC8UzfeTirK2IGRTGeYyjtfufrIfakkvxqp9zmjeIRFzL6TEjL +bzCL5rJoWf3ouE3WfexTwOkPhIVPIWxYXkkI5GGJK9ClA7KMINwQmfbc1f7ZpAS2VQR do2IFARmb6H6A8IMXutBFVhJ07mW7ulbmI2bJQQvyXXrSj0nTJE213OCxaWbm0gd3IbO rRUw== X-Gm-Message-State: AOAM5302YMk3U33vqIEpCxB8SgVVdXvQh4LFMh0zw82oD+wDaWli4MJb ML+51dKvAfGgz5ttxTmzfmZBYHwKaA+4qZQI6BL7DyqVGbSqkdLE X-Google-Smtp-Source: ABdhPJzDwOm7MrocjhUQS/1aJwKFPtK0gFSKg7576PXSYOrKtbj0IKv9/iuYsYI3nGVQrDMyBgATZzAkr20QiPWX3Wg= X-Received: by 2002:a67:2f90:: with SMTP id v138mr359512vsv.2.1613584740784; Wed, 17 Feb 2021 09:59:00 -0800 (PST) MIME-Version: 1.0 References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> In-Reply-To: From: Hans Zandbelt Date: Wed, 17 Feb 2021 18:58:49 +0100 Message-ID: To: Brian Campbell , "oauth@ietf.org" , Vittorio Bertocci Content-Type: multipart/alternative; boundary="0000000000004a8eca05bb8bf91e" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 17:59:05 -0000 --0000000000004a8eca05bb8bf91e Content-Type: text/plain; charset="UTF-8" Thanks Vittorio and Brian for starting this work: I have deployed this pattern in the field on a number occasions, at security and tech savvy organizations, on their request. I'd describe it as a regular OAuth 2.0 web client with the addition of a well known endpoint meant for in-browser (counterpart) clients. Enterprise security architects seem to prefer this approach because of the confidential client involved and the ability to outsource a perceived cumbersome and security sensitive task to a backend infrastructure component under direct control of the organization rather than the end user. Even if there's no proven security advantage by letter of the OAuth 2 spec, it may still be a preferred way of deployment for some organizations because of the way they want to structure security sensitive software, the way they deal with software development, and the way they deal with application and infrastructure management. I very much agree with all of the arguments Vittorio brought up before and I really don't see any reason to reject this approach. It is very useful to list the considerations about this architectural pattern and to give guidance about when it can be used and when to avoid it, regardless of the complexity or length of such a spec. Hans. On Tue, Feb 16, 2021 at 10:02 PM Brian Campbell wrote: > > > > On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Thank you again for the explanation. >> >> I think your assumption about the overall flow should be described in the >> draft. >> > > We did attempt to capture the assumptions in the draft but clearly could > have done a better job with it :) > > >> >> As I understand it now the core contribution of your proposal is to move >> refresh token management from frontend to backend. Is that correct? >> > > Taking that a bit further - the idea is that the backend takes on the > responsibilities of being a confidential client (client creds, token > acquisition, token management/persistence, etc.) to the external AS(s). And > TMI BFF describes a way for that backend to deliver access tokens to its > own frontend. > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandbelt@zmartzone.eu ZmartZone IAM - www.zmartzone.eu --0000000000004a8eca05bb8bf91e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Vittorio and Brian for starting this work: I have d= eployed this pattern in the=C2=A0field on a number occasions, at security a= nd tech savvy organizations,=C2=A0on their request.
I'd describe it = as a regular OAuth 2.0 web client with the addition=C2=A0of a well known en= dpoint meant for in-browser (counterpart) clients.

Enterprise s= ecurity architects seem to prefer this approach because of the confidential= client involved and the ability to outsource a perceived cumbersome and se= curity sensitive task to a backend infrastructure=C2=A0component under dire= ct control of the organization rather than the end user. Even if there'= s no proven security advantage by letter of the OAuth 2 spec, it may still = be a preferred way of deployment for some organizations because of the way = they want to structure security sensitive software,=C2=A0the way they deal = with software development,=C2=A0and the way they deal with application and = infrastructure management.=C2=A0

I very much agree with= all of the arguments Vittorio brought up before and I really don't see= any reason to reject this approach. It is very useful to list the consider= ations about this architectural pattern and to give guidance about when it = can be used and when to avoid it, regardless of the complexity or length of= such a spec.

Hans.

On Tue, Feb 16, 2021 at 10:= 02 PM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:



On Mon, Feb 15, 20= 21 at 9:48 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Thank you again for the expl= anation.

I think your assumption about the overall flow should be described in the d= raft.

We did attempt to capture the as= sumptions in the draft but clearly could have done a better job with it :) =
=C2=A0
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
--0000000000004a8eca05bb8bf91e-- From nobody Wed Feb 17 11:43:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447C3A1CE5 for ; Wed, 17 Feb 2021 11:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbOGuIt_NTMd for ; Wed, 17 Feb 2021 11:43:22 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6513A1CE2 for ; Wed, 17 Feb 2021 11:43:22 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id p15so12374993ilq.8 for ; Wed, 17 Feb 2021 11:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=5worYElBP5wzL/Ubgm5ibQ8iBBiw42Ccu67AbPtOmzE=; b=zPTNeqAXO289B18+vp+fg8Bxl3FZAbyA1DXndyUwAn+oarP8wxue2B99rM1/2jya/z JEODt/T6r6cyiIRLdPMKqq0me0fUMSjnkvccOgotTP4qwh88H1JT6qsWMqBPJDQOaipt UeEe7hhfeeVPVg5JdCXC4zGBGC7vckfontTcwVoXUqQ27JLjFvU1rvhzvCEKdkXgeXL5 hVMeaI2dDajRSCD0Hls91hmjl4Ya5cChMrC5tynNMIeR0UoCfBlmdkkzW+pS//HsmXZv hxnQZCTbDxTH1LLsSFYkBv8bEfDAbwji/ASi+iX3jlqQlk8CEeBsggpOzZLrWEt6URzA 9plg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5worYElBP5wzL/Ubgm5ibQ8iBBiw42Ccu67AbPtOmzE=; b=EVU/qgiRUyiz9/QPq78tH4sF90z4OL/r6Rbi00ByLVA2mT6cvA1jBe4cTP/xdepByr 6NOASSrhisgnBQTesQooFSX+0SdUbKK5fEB9Zrtn7XrrAR21FmWNbo5jD6JBkrg7q6ws duzUz5IJl4ih3AMyhuYkfouRAfhSO5abWz4onV/dnr0+2wKNq0yfRHUdf6oCduMefdbm oipTIFMCpcAWLdTAZAbSkM81HBJJgF7Tsus++kmQ3XIudAWyKNs5cA2nn9WwuejEU3RW evHGStvJV5xxsuZjEJpm1n1YVHv+lRBTeC7jYX0oztUyRMzeIUAQNDFf1IdK3YgRYMbM Lv1w== X-Gm-Message-State: AOAM531KBDueDveWwWkstm7n8tpqSdf2P8sE+hOqH+9sWWTO/PoHee1h 0i8Wb/kzN4UHWurc9bDJldsMM3hCBpfWR4rz+Mzf X-Google-Smtp-Source: ABdhPJxZ+n6xQlacqROgURAoW2ttazJy7ovZfA06Zl5L51JB6oAK193UmBRKfglN872IR9/EEKaZaKaxOmeHM0LdWYw= X-Received: by 2002:a05:6e02:1888:: with SMTP id o8mr590175ilu.154.1613591001328; Wed, 17 Feb 2021 11:43:21 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 11:43:20 -0800 From: Dominick Baier In-Reply-To: References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> MIME-Version: 1.0 Date: Wed, 17 Feb 2021 11:43:20 -0800 Message-ID: To: Brian Campbell , Torsten Lodderstedt , Vittorio Bertocci Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000072993d05bb8d6ea1" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 19:43:25 -0000 --00000000000072993d05bb8d6ea1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all kept= server-side and the BFF proxies the API calls if necessary. Also the RT management happens server-side and is transparent to the SPA. I see that in lots of industries - finance, health, cloud providers While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the X= SS problem=E2=80=9D - this is absolutely correct. But when there are no tokens in the browser - you can simply eliminate that part of the threat model ;) =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 17. February 2021 at 18:30:23, Vittorio Bertocci ( vittorio.bertocci@auth0.com) wrote: Thanks Dominick, It is indeed a very simple spec, but as you can see from the discussion so far, it doesn=E2=80=99t appear to be trivial- and there might be some considerations we consider obvious (eg scope escalation) that might not be super clear otherwise. In terms of the guidance, just to make sure I get the scope right- that means that also code+PKCE+rotating RTs in JS would not be acceptable for your customers? *From: *Dominick Baier *Date: *Wednesday, February 17, 2021 at 00:27 *To: *Brian Campbell , Torsten Lodderstedt < torsten@lodderstedt.net> *Cc: *Vittorio Bertocci , "oauth@ietf.org" < oauth@ietf.org> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) Hey, Tbh - I have a bit of a hard time to see why this requires a spec, if that is all you are aiming at. Wouldn=E2=80=99t that be just an extension to the= =E2=80=9COAuth for web apps BCP?=E2=80=9D. All I can add here is - this approach would not work for any of our customer. Because their real motivation is to implement a more and more common security guideline these days - namely: =E2=80=9Cno JS-accessible to= kens in the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. cheers =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 16. February 2021 at 22:01:37, Brian Campbell ( bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt wrote: Thank you again for the explanation. I think your assumption about the overall flow should be described in the draft. We did attempt to capture the assumptions in the draft but clearly could have done a better job with it :) As I understand it now the core contribution of your proposal is to move refresh token management from frontend to backend. Is that correct? Taking that a bit further - the idea is that the backend takes on the responsibilities of being a confidential client (client creds, token acquisition, token management/persistence, etc.) to the external AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend. *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.*_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --00000000000072993d05bb8d6ea1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Yes = - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all kept ser= ver-side and the BFF proxies the API calls if necessary. Also the RT manage= ment happens server-side and is transparent to the SPA.

I see that in lots of industries - fin= ance, health, cloud providers

While someone will always say =E2=80=9Cbut this doesn=E2=80=99t = solve the XSS problem=E2=80=9D - this is absolutely correct. But when there= are no tokens in the browser - you can simply eliminate that part of the t= hreat model ;)

=E2=80=94=E2=80=94= =E2=80=94
Dominick Baier

On 17.= February 2021 at 18:30:23, Vittorio Bertocci (vittorio.bertocci@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=E2=80=99t appear to be trivial- and th= ere might be some considerations we consider obvious (eg scope escalation) = that might not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

=C2=A0

From= : Dominick Baier &l= t;dbaier@leastprivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <oauth= @ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Hey,=C2=A0

=C2=A0

Tbh - I have a bit of a hard time to see why this requires a spec, if th= at is all you are aiming at. Wouldn=E2=80=99t that be just an extension to = the =E2=80=9COAuth for web apps BCP?=E2=80=9D.

=C2=A0

All I can add here is - this approach would not work for any of our cust= omer. Because their real motivation is to implement a more and more common = security guideline these days - namely: =E2=80=9Cno JS-accessible tokens in the browser=E2=80=9D - but this docume= nt doesn=E2=80=99t cover this.

=C2=A0

cheers=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

=C2=A0

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D= 40pingidentity.com@dmarc.ietf.org) wrote:

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft.=20

=C2=A0

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

=C2=A0


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct?=C2=A0

=C2=A0

=C2=A0Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.=C2=A0 <= /p>


CONFIDENTIALITY NOTICE: This email may contain confident= ial and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--00000000000072993d05bb8d6ea1-- From nobody Wed Feb 17 11:46:58 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222F03A1CEA for ; Wed, 17 Feb 2021 11:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfwuvDy5cfsJ for ; Wed, 17 Feb 2021 11:46:54 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8CF3A1D96 for ; Wed, 17 Feb 2021 11:46:42 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id f6so1844543iop.11 for ; Wed, 17 Feb 2021 11:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j+aad7pj82XykXq29ZpHSpYT5SOnGqtP+uNBzoPupJA=; b=GGXcrKs6iPqBJui0enTx17aa5FiNUyYBK+4kdvgnEZJ+/kZghURw0ntZDYzTAoI0BS Sr765QaDHp75+kyHxuejnWehcUnAU4eUU/L5r00OoLydE4xvggjaIQ30TGGpJDWgZott 1unoVX7kyns5cP/L7P7PYuTH4NHoh0F7C+m9SD1tCLqwRpM4FfqidlRwUXfTjmRDaxOY VgD9bMhHU7NkCVNhQxmCYS93MveuaU95eN4xRYJngTSObUGR/+/4viLJNwF7UklAs93R lEd3iKWiSAxO5rljpvCrXtTMMOxpSG5T5QOYgtWEpbPRaKug72F8zO+h5y3RSdqBV9Dw VZwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j+aad7pj82XykXq29ZpHSpYT5SOnGqtP+uNBzoPupJA=; b=XYNuelDur20X7edg7swR26p1pge2Ca5kPX/R9YsehpbzVZsEgoR2HtQCBWF9kyykxu zUqTLnY/FcKIfmslIAsStCngMCtV6athRk5dZbcoe3hJaAiVKcQn08IfhIyS/d/4C2Lr /Mick6UckX2G/YhKt9IED915yYHXPixTNCt3D9hDVyPZujUoLVnbfXMGhXJgNcADtfjA aJwhdiCnV0UkHIq/4Gjs2xzvxWlLOaZiQrZhFQ2w9i4xWOUFzAK1IsZFjf8xUSekklax k3ygRvVAcR8aHTbIdxYJ3LZuaBlB8rZHAY8rHKmS4fmAt4+NqZoyuoXjYcpcyiPJpwZq K1Ww== X-Gm-Message-State: AOAM533UQ1P1A+mBYymydr3TyTbmrOFzUt4YrLZYv33FSLN+0bgt0TDT fM+1Af6Axa2lnNp2zLCSnqiUtZg1aCN2BlyZc/VB X-Google-Smtp-Source: ABdhPJwDIY33JVhhViRuuH3QQ1Cm96Gd5Ptb820iXY8/eAydk9f5C5WArI073xLIA4jFnMTvy8RgtvVxtEvXHovu/0Y= X-Received: by 2002:a6b:5505:: with SMTP id j5mr549633iob.148.1613591201544; Wed, 17 Feb 2021 11:46:41 -0800 (PST) MIME-Version: 1.0 References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> In-Reply-To: From: Warren Parad Date: Wed, 17 Feb 2021 20:46:30 +0100 Message-ID: To: Dominick Baier Cc: Brian Campbell , Torsten Lodderstedt , Vittorio Bertocci , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000061987f05bb8d7a31" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 19:46:56 -0000 --00000000000061987f05bb8d7a31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the= XSS problem=E2=80=9D - > this is absolutely correct. But when there are no tokens in the browser - > you can simply eliminate that part of the threat model ;) The point was it doesn't eliminate anything, it just changes the request/response data that is part of the attack. This doesn't increase security, as a matter of fact, with regard to the RFC, we shouldn't talk about security at all, since it has zero impact on it. It is worth talking about that pattern as *one* possible solution to maintaining sessions, but that's it. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier wrote: > Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all ke= pt server-side > and the BFF proxies the API calls if necessary. Also the RT management > happens server-side and is transparent to the SPA. > > I see that in lots of industries - finance, health, cloud providers > > While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the= XSS problem=E2=80=9D - > this is absolutely correct. But when there are no tokens in the browser - > you can simply eliminate that part of the threat model ;) > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 17. February 2021 at 18:30:23, Vittorio Bertocci ( > vittorio.bertocci@auth0.com) wrote: > > Thanks Dominick, > > It is indeed a very simple spec, but as you can see from the discussion s= o > far, it doesn=E2=80=99t appear to be trivial- and there might be some > considerations we consider obvious (eg scope escalation) that might not b= e > super clear otherwise. > > In terms of the guidance, just to make sure I get the scope right- that > means that also code+PKCE+rotating RTs in JS would not be acceptable for > your customers? > > > > *From: *Dominick Baier > *Date: *Wednesday, February 17, 2021 at 00:27 > *To: *Brian Campbell , Torsten Lodderstedt < > torsten@lodderstedt.net> > *Cc: *Vittorio Bertocci , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > Hey, > > > > Tbh - I have a bit of a hard time to see why this requires a spec, if tha= t > is all you are aiming at. Wouldn=E2=80=99t that be just an extension to t= he =E2=80=9COAuth > for web apps BCP?=E2=80=9D. > > > > All I can add here is - this approach would not work for any of our > customer. Because their real motivation is to implement a more and more > common security guideline these days - namely: =E2=80=9Cno JS-accessible = tokens in > the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. > > > > cheers > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick Baier > > > > On 16. February 2021 at 22:01:37, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > > > > > > > On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > > > > We did attempt to capture the assumptions in the draft but clearly could > have done a better job with it :) > > > > > As I understand it now the core contribution of your proposal is to move > refresh token management from frontend to backend. Is that correct? > > > > Taking that a bit further - the idea is that the backend takes on the > responsibilities of being a confidential client (client creds, token > acquisition, token management/persistence, etc.) to the external AS(s). A= nd > TMI BFF describes a way for that backend to deliver access tokens to its > own frontend. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000061987f05bb8d7a31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While so= meone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the XSS probl= em=E2=80=9D - this is absolutely correct. But when there are no tokens in t= he browser - you can simply eliminate that part of the threat model ;)The point was it doesn't eliminate anything, it just changes th= e request/response data that is part of the attack. This doesn't increa= se security, as a matter of fact, with regard to the RFC, we shouldn't = talk about security at all, since it has zero impact on it.

<= div>It is worth talking about that pattern as one=C2=A0possible solu= tion to maintaining sessions, but that's it.

Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a servi= ce. Implement=C2=A0Authress.


On Wed, Feb 17, 2021 at 8:43= PM Dominick Baier <dbaier@= leastprivilege.com> wrote:
Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are al= l kept server-side and the BFF proxies the API calls if necessary. Also the= RT management happens server-side and is transparent to the SPA.

I see that in lots of indus= tries - finance, health, cloud providers

While someone will always say =E2=80=9Cbut this doesn= =E2=80=99t solve the XSS problem=E2=80=9D - this is absolutely correct. But= when there are no tokens in the browser - you can simply eliminate that pa= rt of the threat model ;)

=E2=80=94=E2=80=94=E2=80=94
D= ominick Baier

On 17. February 2021 at 18:30:23, Vittorio= Bertocci (vittorio.bertocci@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=E2=80=99t appear to be trivial- and th= ere might be some considerations we consider obvious (eg scope escalation) = that might not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

=C2=A0

From: = Dominick Baier <dbaier@leastpr= ivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt = <torsten@lo= dderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org> Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Hey,=C2=A0

=C2=A0

Tbh - I have a bit of a hard time to see why this requires a spec, if that= is all you are aiming at. Wouldn=E2=80=99t that be just an extension to th= e =E2=80=9COAuth for web apps BCP?=E2=80=9D.

=C2=A0

All I can add here is - this approach would not work for any of our custom= er. Because their real motivation is to implement a more and more common se= curity guideline these days - namely: =E2=80=9Cno JS-accessible tokens in the browser=E2=80=9D - but this docume= nt doesn=E2=80=99t cover this.

=C2=A0

cheers=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

=C2=A0

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40= pingidentity.com@dmarc.ietf.org) wrote:

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft.=20

=C2=A0

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

=C2=A0


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct?=C2=A0

=C2=A0

=C2=A0Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.=C2=A0 <= /p>


CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
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
--00000000000061987f05bb8d7a31-- From nobody Wed Feb 17 11:50:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16DB3A1CEB for ; Wed, 17 Feb 2021 11:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JacHs3iVdl6r for ; Wed, 17 Feb 2021 11:50:27 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0233A1CE9 for ; Wed, 17 Feb 2021 11:50:27 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id a7so3923504iok.12 for ; Wed, 17 Feb 2021 11:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=X7W0ypts6muhYqnuEeWfKuavvyhrbDhJelAIRMe/BGo=; b=ACTmQJBRQ7Wzx/Xdmm40PRyK/FaDff9QZZP6v8XY6zOAC5RmOu5Zts5V3xnNW43Izl Ed7DoPcvYCNFXk7reQWZiVVoK72/RiIo7KJIk8UTQhvCv7Hh0Wl3fs+V+EPNPkUnkZM3 6xdhvyHDJDzl09z3iUhfFUrTJGvlY8AKLZQhsBNf4RsNenSuAdw71SMaGJjEdMFNPy3k /jllSff0qX4zu/U9c8UMw+TnyvuvfJR/+yHzyCaQ8Ylu1ArA9t1OCfT+nxiTlZ46pEM7 xKwXCt0IkR8xGOD6TOEt7sCHu7WTV8FrzaehP6xz0ClRussBBgIMGYNUDpCuCN0S9r1N tdwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=X7W0ypts6muhYqnuEeWfKuavvyhrbDhJelAIRMe/BGo=; b=cePnh8wXe1gEBugQTIj0Pmt4+YFA1WSMlXfd2BAbQbaoV8TVw1Q4PdZsl2bAttP9JQ m3dFmrs+GnlA+UFzBBqSp1MefG6guWaTRzxcrxsVbYlHjYKl1LMs9Djcy21CkKdxafzb y+8fUEqQNA5QaaR4yPNNDTvJexiibQCSTqJKFidtHlq9DP2jAIViBBDwxv9+HiIdKMuk 20pkdHQD/SsRFuzRDYmql7PZZZd8gNv/7VihVtcGeD1q+tPWfZTzkGxLP2RlCBUunJlM c4ZWgUZf3nztRETm59Y9gC4jl0uODiogzOJOSgRwCo83ZNkqBhShy0g+N+x1I+/XwQR+ iQtA== X-Gm-Message-State: AOAM530ykWDFXZaXC5ktLbsqpwZql0RDvvPZm/VaeTg7uKmkp7+5BCbO yWANRVzrWXDm+JwmS/+cUoca9B1uw0ljaB2t8kp9 X-Google-Smtp-Source: ABdhPJw5SPz8Ms+pV40EZHO/2C9NgNG4Hp4xYTi/6CcfThi1VRFK0FwK9jQkpxLXN2U76uEG1dVTjnk9nrFyrBkptfI= X-Received: by 2002:a05:6638:3803:: with SMTP id i3mr1077942jav.26.1613591426709; Wed, 17 Feb 2021 11:50:26 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 11:50:26 -0800 From: Dominick Baier In-Reply-To: References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> MIME-Version: 1.0 Date: Wed, 17 Feb 2021 11:50:26 -0800 Message-ID: To: Warren Parad Cc: Brian Campbell , Torsten Lodderstedt , Vittorio Bertocci , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cd690705bb8d87f6" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 19:50:30 -0000 --000000000000cd690705bb8d87f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well. Maybe it is at least worth while then to at least mention that you could also take a slightly different approach and eliminate all tokens in the browser - with the respective trade offs. =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote: While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the X= SS problem=E2=80=9D - > this is absolutely correct. But when there are no tokens in the browser - > you can simply eliminate that part of the threat model ;) The point was it doesn't eliminate anything, it just changes the request/response data that is part of the attack. This doesn't increase security, as a matter of fact, with regard to the RFC, we shouldn't talk about security at all, since it has zero impact on it. It is worth talking about that pattern as *one* possible solution to maintaining sessions, but that's it. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier wrote: > Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all ke= pt server-side > and the BFF proxies the API calls if necessary. Also the RT management > happens server-side and is transparent to the SPA. > > I see that in lots of industries - finance, health, cloud providers > > While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the= XSS problem=E2=80=9D - > this is absolutely correct. But when there are no tokens in the browser - > you can simply eliminate that part of the threat model ;) > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 17. February 2021 at 18:30:23, Vittorio Bertocci ( > vittorio.bertocci@auth0.com) wrote: > > Thanks Dominick, > > It is indeed a very simple spec, but as you can see from the discussion s= o > far, it doesn=E2=80=99t appear to be trivial- and there might be some > considerations we consider obvious (eg scope escalation) that might not b= e > super clear otherwise. > > In terms of the guidance, just to make sure I get the scope right- that > means that also code+PKCE+rotating RTs in JS would not be acceptable for > your customers? > > > > *From: *Dominick Baier > *Date: *Wednesday, February 17, 2021 at 00:27 > *To: *Brian Campbell , Torsten Lodderstedt < > torsten@lodderstedt.net> > *Cc: *Vittorio Bertocci , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > Hey, > > > > Tbh - I have a bit of a hard time to see why this requires a spec, if tha= t > is all you are aiming at. Wouldn=E2=80=99t that be just an extension to t= he =E2=80=9COAuth > for web apps BCP?=E2=80=9D. > > > > All I can add here is - this approach would not work for any of our > customer. Because their real motivation is to implement a more and more > common security guideline these days - namely: =E2=80=9Cno JS-accessible = tokens in > the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. > > > > cheers > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick Baier > > > > On 16. February 2021 at 22:01:37, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > > > > > > > On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > > > > We did attempt to capture the assumptions in the draft but clearly could > have done a better job with it :) > > > > > As I understand it now the core contribution of your proposal is to move > refresh token management from frontend to backend. Is that correct? > > > > Taking that a bit further - the idea is that the backend takes on the > responsibilities of being a confidential client (client creds, token > acquisition, token management/persistence, etc.) to the external AS(s). A= nd > TMI BFF describes a way for that backend to deliver access tokens to its > own frontend. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000cd690705bb8d87f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Well= . Maybe it is at least worth while then to at least mention that you could = also take a slightly different approach and eliminate all tokens in the bro= wser - with the respective trade offs.

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote:

While someone will alway= s say =E2=80=9Cbut this doesn=E2=80=99t solve the XSS problem=E2=80=9D - th= is is absolutely correct. But when there are no tokens in the browser - you= can simply eliminate that part of the threat model ;)
The poin= t was it doesn't eliminate anything, it just changes the request/respon= se data that is part of the attack. This doesn't increase security, as = a matter of fact, with regard to the RFC, we shouldn't talk about secur= ity at all, since it has zero impact on it.

It is worth = talking about that pattern as one=C2=A0possible solution to maintain= ing sessions, but that's it.

Warren Parad

Founder, C= TO

Secure your user data with IAM authorization as a service. Implement= =C2=A0Authress.
=


On Wed, Feb 17, 2021 at 8:43 PM Dominick = Baier <dbaier@leastprivileg= e.com> wrote:
Yes - = =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all kept serve= r-side and the BFF proxies the API calls if necessary. Also the RT manageme= nt happens server-side and is transparent to the SPA.

I see that in lots of industries - finan= ce, health, cloud providers

While someone will always say =E2=80=9Cbut this doesn=E2=80=99t so= lve the XSS problem=E2=80=9D - this is absolutely correct. But when there a= re no tokens in the browser - you can simply eliminate that part of the thr= eat model ;)

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier=

On 17. February 2021 at 18:30:23, Vittorio Bertocci (vittorio.ber= tocci@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=E2=80=99t appear to be trivial- and th= ere might be some considerations we consider obvious (eg scope escalation) = that might not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

=C2=A0

From: = Dominick Baier <dbaier@leastpr= ivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt = <torsten@lo= dderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org> Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Hey,=C2=A0

=C2=A0

Tbh - I have a bit of a hard time to see why this requires a spec, if that= is all you are aiming at. Wouldn=E2=80=99t that be just an extension to th= e =E2=80=9COAuth for web apps BCP?=E2=80=9D.

=C2=A0

All I can add here is - this approach would not work for any of our custom= er. Because their real motivation is to implement a more and more common se= curity guideline these days - namely: =E2=80=9Cno JS-accessible tokens in the browser=E2=80=9D - but this docume= nt doesn=E2=80=99t cover this.

=C2=A0

cheers=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

=C2=A0

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40= pingidentity.com@dmarc.ietf.org) wrote:

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft. =20

=C2=A0

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

=C2=A0


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct?=C2=A0

=C2=A0

=C2=A0Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.=C2=A0 <= /p>


CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
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
--000000000000cd690705bb8d87f6-- From nobody Wed Feb 17 12:01:07 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19713A1D30 for ; Wed, 17 Feb 2021 12:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJUpXguqMeV8 for ; Wed, 17 Feb 2021 12:00:59 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBEF3A1D09 for ; Wed, 17 Feb 2021 12:00:41 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id f6so15214705ioz.5 for ; Wed, 17 Feb 2021 12:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wH6WgVunV3R/qj8JWc9Ge6n0ymvuGyEkDmhXptcvV9E=; b=gf9s9+87GNxT6kLVMAL1H8QO/zske3C4h/P9NRH1tKF6Xjivt8VTehSnJ8K/02vl55 +5IKK2O/bSVuti7atxhOKibhvxkXRTN/zLL3tzAUh6ErbhGoqS5U7D5+72BfmUG293s6 T4b+Lj+20EsOJzDFu1qWLJMXVy6Jlonc7E4jj4zEyREU26j7KSTG9hTXtEQasH52257R X+3fQMgkWxxX1wE9/g8e+zIyHxjkjl05XIcu5EXZOTQnkzHQnCBUEgsK8TLsRMTXrHp2 SH32MIY61QtXUtdCkOn1wCANXw0IYNQusD4acIrWDdU9pEQh9PF6p2ZdLn880oeC6a5r Tc1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wH6WgVunV3R/qj8JWc9Ge6n0ymvuGyEkDmhXptcvV9E=; b=AMt/yonaTC1+wNQ/K0g3wjU7Pp3JRhzaqP4O3WbMcEXsehGXJbh6zRU+QvO2TZC44j K0oSL4QWHZLBdnGP9806i83XVRipDbT9dqrPKUis1+5LEfrGnxPkeG8ZYzdipQ48iLNc ZJ64mDJtWhnrYnYUzVZNzk60PRfld8B3V9QDOEjvt4KARY75RKIs14EMtfUyVqDBi6yp x7OnjpaIeov/flt9GbWaGSIFHRaBZIoqYRXOr/fEE2Xt1jkic2eKam0txBEDiJKRZm46 NJR/EcwfVqFneAA1MKEv2Gi52cuNlBx9K8URvngrETV7UyPQrmAvorFwNthpOa5zjb1K d6Zg== X-Gm-Message-State: AOAM532DxatGJOdeNwVPmgntlIrQXXFKclv7VB3UDzYxUfUx2zh7bhD2 iT+9eO8MXXrrRxiE28QWUs7qvPBpM8GuLDz/Vhb1 X-Google-Smtp-Source: ABdhPJwy/nKLOESeIaA4o4O32Ox2RrUIJJ9AEPnt/Wim5dS9HFo+Bhjez3yNUwVS+sfy6rH38GlwhKaWGpUmoy8mz0g= X-Received: by 2002:a5d:8249:: with SMTP id n9mr607452ioo.31.1613592040349; Wed, 17 Feb 2021 12:00:40 -0800 (PST) MIME-Version: 1.0 References: <5BE7C60F-84AB-431A-838F-D33459E551C6@lodderstedt.net> <16CA5346-48EF-4B29-8397-EE6312366C63@lodderstedt.net> In-Reply-To: From: Warren Parad Date: Wed, 17 Feb 2021 21:00:29 +0100 Message-ID: To: Dominick Baier Cc: Brian Campbell , Torsten Lodderstedt , Vittorio Bertocci , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000060d76e05bb8dac29" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 20:01:07 -0000 --00000000000060d76e05bb8dac29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You mean all but the access token and authorization code, right? Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed, Feb 17, 2021 at 8:50 PM Dominick Baier wrote: > Well. Maybe it is at least worth while then to at least mention that you > could also take a slightly different approach and eliminate all tokens in > the browser - with the respective trade offs. > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote: > > While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the= XSS problem=E2=80=9D - >> this is absolutely correct. But when there are no tokens in the browser = - >> you can simply eliminate that part of the threat model ;) > > The point was it doesn't eliminate anything, it just changes the > request/response data that is part of the attack. This doesn't increase > security, as a matter of fact, with regard to the RFC, we shouldn't talk > about security at all, since it has zero impact on it. > > It is worth talking about that pattern as *one* possible solution to > maintaining sessions, but that's it. > > Warren Parad > > Founder, CTO > Secure your user data with IAM authorization as a service. Implement > Authress . > > > On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier > wrote: > >> Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all k= ept server-side >> and the BFF proxies the API calls if necessary. Also the RT management >> happens server-side and is transparent to the SPA. >> >> I see that in lots of industries - finance, health, cloud providers >> >> While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve th= e XSS problem=E2=80=9D - >> this is absolutely correct. But when there are no tokens in the browser = - >> you can simply eliminate that part of the threat model ;) >> >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick Baier >> >> On 17. February 2021 at 18:30:23, Vittorio Bertocci ( >> vittorio.bertocci@auth0.com) wrote: >> >> Thanks Dominick, >> >> It is indeed a very simple spec, but as you can see from the discussion >> so far, it doesn=E2=80=99t appear to be trivial- and there might be some >> considerations we consider obvious (eg scope escalation) that might not = be >> super clear otherwise. >> >> In terms of the guidance, just to make sure I get the scope right- that >> means that also code+PKCE+rotating RTs in JS would not be acceptable for >> your customers? >> >> >> >> *From: *Dominick Baier >> *Date: *Wednesday, February 17, 2021 at 00:27 >> *To: *Brian Campbell , Torsten Lodderstedt < >> torsten@lodderstedt.net> >> *Cc: *Vittorio Bertocci , "oauth@ietf.org" = < >> oauth@ietf.org> >> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information >> Backend For Frontend (TMI BFF) >> >> >> >> Hey, >> >> >> >> Tbh - I have a bit of a hard time to see why this requires a spec, if >> that is all you are aiming at. Wouldn=E2=80=99t that be just an extensio= n to the >> =E2=80=9COAuth for web apps BCP?=E2=80=9D. >> >> >> >> All I can add here is - this approach would not work for any of our >> customer. Because their real motivation is to implement a more and more >> common security guideline these days - namely: =E2=80=9Cno JS-accessible= tokens in >> the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. >> >> >> >> cheers >> >> =E2=80=94=E2=80=94=E2=80=94 >> >> Dominick Baier >> >> >> >> On 16. February 2021 at 22:01:37, Brian Campbell ( >> bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: >> >> >> >> >> >> >> >> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> Thank you again for the explanation. >> >> I think your assumption about the overall flow should be described in th= e >> draft. >> >> >> >> We did attempt to capture the assumptions in the draft but clearly could >> have done a better job with it :) >> >> >> >> >> As I understand it now the core contribution of your proposal is to move >> refresh token management from frontend to backend. Is that correct? >> >> >> >> Taking that a bit further - the idea is that the backend takes on the >> responsibilities of being a confidential client (client creds, token >> acquisition, token management/persistence, etc.) to the external AS(s). = And >> TMI BFF describes a way for that backend to deliver access tokens to its >> own frontend. >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.*______________________________________________= _ >> >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --00000000000060d76e05bb8dac29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You mean all but the access token and authorization code, = right?

Warren Parad

Founder, CTO=

Secure your= user data with IAM authorization as a service. Implement=C2=A0A= uthress.
=

On Wed, Feb 17, 2021 at 8:50 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
=
Well. Maybe it is at least wort= h while then to at least mention that you could also take a slightly differ= ent approach and eliminate all tokens in the browser - with the respective = trade offs.

=E2=80=94=E2=80=94=E2=80=94
Dominick Baier<= /div>

On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote:=

=
While someone will always= say =E2=80=9Cbut this doesn=E2=80=99t solve the XSS problem=E2=80=9D - thi= s is absolutely correct. But when there are no tokens in the browser - you = can simply eliminate that part of the threat model ;)
The point= was it doesn't eliminate anything, it just changes the request/respons= e data that is part of the attack. This doesn't increase security, as a= matter of fact, with regard to the RFC, we shouldn't talk about securi= ty at all, since it has zero impact on it.

It is worth t= alking about that pattern as one=C2=A0possible solution to maintaini= ng sessions, but that's it.

=

<= span style=3D"font-size:11pt;font-family:Lato,sans-serif;background-color:t= ransparent;font-weight:700;vertical-align:baseline;white-space:pre-wrap">Wa= rren Parad

Founder, CTO

Secure your user data with IAM authorization as a servic= e. Implement=C2=A0Authress= .


On Wed, Feb 17, 2021 at 8:43 = PM Dominick Baier <dbaier@leastprivilege.com> wrote:
Yes - =E2=80=9Cno OAuth tokens in the browser=E2= =80=9D ;) They are all kept server-side and the BFF proxies the API calls i= f necessary. Also the RT management happens server-side and is transparent = to the SPA.
=
I see t= hat in lots of industries - finance, health, cloud providers

While someone will always say =E2= =80=9Cbut this doesn=E2=80=99t solve the XSS problem=E2=80=9D - this is abs= olutely correct. But when there are no tokens in the browser - you can simp= ly eliminate that part of the threat model ;)

=E2=80=94=E2= =80=94=E2=80=94
Dominick Baier

On 17. February 2021 = at 18:30:23, Vittorio Bertocci (vittorio.bertocci@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=E2=80=99t appear to be trivial- and th= ere might be some considerations we consider obvious (eg scope escalation) = that might not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

=C2=A0

From: = Dominick Baier <dbaier@leastpr= ivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt = <torsten@lo= dderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org> Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Hey,=C2=A0

=C2=A0

Tbh - I have a bit of a hard time to see why this requires a spec, if that= is all you are aiming at. Wouldn=E2=80=99t that be just an extension to th= e =E2=80=9COAuth for web apps BCP?=E2=80=9D.

=C2=A0

All I can add here is - this approach would not work for any of our custom= er. Because their real motivation is to implement a more and more common se= curity guideline these days - namely: =E2=80=9Cno JS-accessible tokens in the browser=E2=80=9D - but this docume= nt doesn=E2=80=99t cover this.

=C2=A0

cheers=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

=C2=A0

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40= pingidentity.com@dmarc.ietf.org) wrote:

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft. =20

=C2=A0

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

=C2=A0


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct?=C2=A0

=C2=A0

=C2=A0Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.=C2=A0 <= /p>


CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
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
--00000000000060d76e05bb8dac29-- From nobody Wed Feb 17 12:08:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAA63A1CFA for ; Wed, 17 Feb 2021 12:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpO0ghlsFaGa for ; Wed, 17 Feb 2021 12:08:39 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B61D3A1CFB for ; Wed, 17 Feb 2021 12:08:39 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id v15so18708835wrx.4 for ; Wed, 17 Feb 2021 12:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=e40ja4l8NS6Oij7TjnEAcodjIQQ+z0EClXIMKF8h4c4=; b=WM6rq2XU8w3R1aVthNghjxpiw6fvtgTIaq5VYTQTohumDA64Ofn0R4aHAt39VMUFwx nrwLb/SHGeeO6nXoHGqQo9cBBijZM0Zny7e8TT3gUAAWcDZDNMJ9fOTKfvdBihzQieuK tR0QIl/J5s3NkVj2qoH/f7FXuCTN8rQTalLoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=e40ja4l8NS6Oij7TjnEAcodjIQQ+z0EClXIMKF8h4c4=; b=Px77J9Y5HwdkbsZVGQnxX8zx7gcgTsjIfxrlfwplQ1YTP3ixhBY3MCxW2tueJMUuL4 05429xKQb+I9utW+SALOIA0qAC8KXWcLfeyb6xSAic9vY2+HHrkcSX3DrRaKSDmJlkrh lQ3C0/f7Sbs44a8/q1L0C5qrKOoGwGUrj4lQcHlT+8an8ksr8oy1xhUEtrt4Hn/4z3Ay 70Vcr0MtIodkv/W6MC43/6ZNgGzxiK4SXdDqDhYDQUyyF+MAv1BGZ8DJpnp0373fFC8R n2eJwotyMtu9HZGXx2O4dbcdoWsHf+jzyzBXCp4pb38/FnVtNjJTCP4AO6B50EllnsUC bmZQ== X-Gm-Message-State: AOAM531f/y7JBfsG833Oic1GSZrRCOtl++m5Y3/3frPOEPaqk4PGUc1m vEMfORbLu+r7KEgltdF0thptKya6Dp9eb6ofm6r90C7H0ssqJq8NUEZoLQMhHQZypcoZgYaqXg= = X-Google-Smtp-Source: ABdhPJx8K1GOLhZBnbSB8/6q6COuIg9R0pjT/UP+hfJSd59bG5xtRFz03CYSEd3QsklaBsBIY6qsvA== X-Received: by 2002:a5d:570a:: with SMTP id a10mr894869wrv.70.1613592517571; Wed, 17 Feb 2021 12:08:37 -0800 (PST) Received: from ?IPv6:2a01:4c8:62:ae76:a858:a8e7:1bf2:2da8? ([2a01:4c8:62:ae76:a858:a8e7:1bf2:2da8]) by smtp.gmail.com with ESMTPSA id n186sm4511513wmn.22.2021.02.17.12.08.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Feb 2021 12:08:37 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Wed, 17 Feb 2021 20:08:36 +0000 Message-Id: <98E38875-F022-419C-87FA-1218B4A16660@forgerock.com> References: Cc: Warren Parad , Vittorio Bertocci , oauth@ietf.org In-Reply-To: To: Dominick Baier X-Mailer: iPhone Mail (18D52) Content-Type: multipart/alternative; boundary=Apple-Mail-14816776-DE3A-48CB-A17E-7C51B65C73FB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 20:08:43 -0000 --Apple-Mail-14816776-DE3A-48CB-A17E-7C51B65C73FB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do you eliminate the cookies too? > On 17 Feb 2021, at 19:50, Dominick Baier wrot= e: >=20 > =EF=BB=BF > Well. Maybe it is at least worth while then to at least mention that you = could also take a slightly different approach and eliminate all tokens in t= he browser - with the respective trade offs. >=20 > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier >=20 >> On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote: >>=20 >>> While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve t= he XSS problem=E2=80=9D - this is absolutely correct. But when there are no= tokens in the browser - you can simply eliminate that part of the threat m= odel ;) >> The point was it doesn't eliminate anything, it just changes the request= /response data that is part of the attack. This doesn't increase security, = as a matter of fact, with regard to the RFC, we shouldn't talk about securi= ty at all, since it has zero impact on it. >>=20 >> It is worth talking about that pattern as one possible solution to maint= aining sessions, but that's it. >>=20 >>=20 >> Warren Parad >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement Aut= hress. >>=20 >>=20 >>> On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier wrote: >>> Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all = kept server-side and the BFF proxies the API calls if necessary. Also the R= T management happens server-side and is transparent to the SPA. >>>=20 >>> I see that in lots of industries - finance, health, cloud providers >>>=20 >>> While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve t= he XSS problem=E2=80=9D - this is absolutely correct. But when there are no= tokens in the browser - you can simply eliminate that part of the threat m= odel ;) >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94 >>> Dominick Baier >>>=20 >>>> On 17. February 2021 at 18:30:23, Vittorio Bertocci (vittorio.bertocci= @auth0.com) wrote: >>>>=20 >>>> Thanks Dominick, >>>>=20 >>>> It is indeed a very simple spec, but as you can see from the discussio= n so far, it doesn=E2=80=99t appear to be trivial- and there might be some = considerations we consider obvious (eg scope escalation) that might not be = super clear otherwise. >>>>=20 >>>> In terms of the guidance, just to make sure I get the scope right- tha= t means that also code+PKCE+rotating RTs in JS would not be acceptable for = your customers? >>>>=20 >>>> =20 >>>>=20 >>>> From: Dominick Baier >>>> Date: Wednesday, February 17, 2021 at 00:27 >>>> To: Brian Campbell , Torsten Lodderstedt <= torsten@lodderstedt.net> >>>> Cc: Vittorio Bertocci , "oauth@ietf.org" = >>>> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backen= d For Frontend (TMI BFF) >>>>=20 >>>> =20 >>>>=20 >>>> Hey,=20 >>>>=20 >>>> =20 >>>>=20 >>>> Tbh - I have a bit of a hard time to see why this requires a spec, if = that is all you are aiming at. Wouldn=E2=80=99t that be just an extension t= o the =E2=80=9COAuth for web apps BCP?=E2=80=9D. >>>>=20 >>>> =20 >>>>=20 >>>> All I can add here is - this approach would not work for any of our cu= stomer. Because their real motivation is to implement a more and more commo= n security guideline these days - namely: =E2=80=9Cno JS-accessible tokens = in the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. >>>>=20 >>>> =20 >>>>=20 >>>> cheers=20 >>>>=20 >>>> =E2=80=94=E2=80=94=E2=80=94 >>>>=20 >>>> Dominick Baier >>>>=20 >>>> =20 >>>>=20 >>>> On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40pingid= entity.com@dmarc.ietf.org) wrote: >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt wrote: >>>>=20 >>>> Thank you again for the explanation.=20 >>>>=20 >>>> I think your assumption about the overall flow should be described in = the draft. >>>>=20 >>>> =20 >>>>=20 >>>> We did attempt to capture the assumptions in the draft but clearly cou= ld have done a better job with it :) >>>>=20 >>>> =20 >>>>=20 >>>>=20 >>>> As I understand it now the core contribution of your proposal is to mo= ve refresh token management from frontend to backend. Is that correct?=20 >>>>=20 >>>> =20 >>>>=20 >>>> Taking that a bit further - the idea is that the backend takes on the= responsibilities of being a confidential client (client creds, token acqui= sition, token management/persistence, etc.) to the external AS(s). And TMI = BFF describes a way for that backend to deliver access tokens to its own fr= ontend.=20 >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited. If you hav= e received this communication in error, please notify the sender immediatel= y by e-mail and delete the message and any file attachments from your compu= ter. Thank you._______________________________________________=20 >>>> OAuth mailing list=20 >>>> OAuth@ietf.org=20 >>>> 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 ForgeRock values your Privacy --Apple-Mail-14816776-DE3A-48CB-A17E-7C51B65C73FB Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you eliminate the c= ookies too?

On 17 Feb 2= 021, at 19:50, Dominick Baier <dbaier@leastprivilege.com> wrote:
<= br>
=EF=BB=BF<= style>body{font-family:Helvetica,Arial;font-size:13px}
Well. Maybe it is at least wor= th while then to at least mention that you could also take a slightly diffe= rent approach and eliminate all tokens in the browser - with the respective= trade offs.

=E2=80=94=E2=80=94= =E2=80=94
Dominick Baier

On 17.= February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote:

While someone will always say =E2=80=9Cbut this do= esn=E2=80=99t solve the XSS problem=E2=80=9D - this is absolutely correct. = But when there are no tokens in the browser - you can simply eliminate that= part of the threat model ;)
The point was it doesn't eliminate= anything, it just changes the request/response data that is part of the at= tack. This doesn't increase security, as a matter of fact, with regard to t= he RFC, we shouldn't talk about security at all, since it has zero impact o= n it.

It is worth talking about that pattern as one possible solution to maintaining sessions, but that's it.
<= br class=3D"gmail-Apple-interchange-newline">

War= ren Parad

Founder, CTO

Secure yo= ur user data with IAM authorization as a service. Implement Authress.


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier <dbaier@leastprivilege.com> wr= ote:
Yes - =E2=80=9Cno OAuth= tokens in the browser=E2=80=9D ;) They are all kept server-side and the BF= F proxies the API calls if necessary. Also the RT management happens server= -side and is transparent to the SPA.

I see that in lots of industries - finance, health, cloud= providers
<= br>
While so= meone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the XSS probl= em=E2=80=9D - this is absolutely correct. But when there are no tokens in t= he browser - you can simply eliminate that part of the threat model ;)
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier

=

On 17. February 2021 at 18:30:23, Vittorio Bertocci (vittorio.bertocci@auth0.com) wrote:

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=E2=80=99t appear to be trivial- and th= ere might be some considerations we consider obvious (eg scope escalation) = that might not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

 

From: = Dominick Baier <dbaier@leastpr= ivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt = <torsten@lo= dderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

 

Hey, 

 

Tbh - I have a bit of a hard time to see why this requires a spec, if that= is all you are aiming at. Wouldn=E2=80=99t that be just an extension to th= e =E2=80=9COAuth for web apps BCP?=E2=80=9D.

 

All I can add here is - this approach would not work for any of our custom= er. Because their real motivation is to implement a more and more common se= curity guideline these days - namely: =E2=80=9Cno JS-accessible tokens in the browser=E2=80=9D - but this docume= nt doesn=E2=80=99t cover this.

 

cheers 

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

 

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40= pingidentity.com@dmarc.ietf.org) wrote:

 

 

 

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft. =20

 

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

 


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct? 

 

 Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.  <= /p>


CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
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
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth

ForgeRock values your Privacy --Apple-Mail-14816776-DE3A-48CB-A17E-7C51B65C73FB-- From nobody Wed Feb 17 13:54:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6A3A1DAE for ; Wed, 17 Feb 2021 13:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nzex_-dGSC6 for ; Wed, 17 Feb 2021 13:54:44 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16893A10F7 for ; Wed, 17 Feb 2021 13:54:43 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11HLsfPL030877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Feb 2021 16:54:42 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_49C41336-7023-426B-A1F1-CA8F0E34566C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <5A5EEBCB-0075-4F9E-B943-E6F142A6E84C@mit.edu> Date: Wed, 17 Feb 2021 16:54:41 -0500 To: oauth X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [OAUTH-WG] Digest for DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 21:54:45 -0000 --Apple-Mail=_49C41336-7023-426B-A1F1-CA8F0E34566C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Two different specifications (GNAP and FAPI signatures) have recently = profiled DPoP to use its signature method to protect a different kind of = protocol entirely. One thing these methods have in common is that they = both define an additional field for holding a digest of the HTTP Message = Body: = https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Mes= sage_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-= request-or-response-body = = https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name= -demonstration-of-proof-of-p = Both of these have the same semantics, and we=E2=80=99re changing the = name in GNAP to align with the FAPI one. This begs the question: do we = want to just define this field as an optional component in DPoP instead = of having these profiles do it separately? It would save them from = needing to align with each other, and anyone else from inventing it = again. Is it worth defining this in DPoP directly, or does that complicate the = spec too much? I=E2=80=99ve previously raised a similar question on = including a hash of the access token in the DPoP request to the RS. =E2=80=94 Justin= --Apple-Mail=_49C41336-7023-426B-A1F1-CA8F0E34566C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Two = different specifications (GNAP and FAPI signatures) have recently = profiled DPoP to use its signature method to protect a different kind of = protocol entirely. One thing these methods have in common is that they = both define an additional field for holding a digest of the HTTP Message = Body:

https://bitbucket.org/openid/fapi/src/master/Financial_API_Simp= le_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-o= f-the-http-request-or-response-body

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 3.html#name-demonstration-of-proof-of-p

Both of these have the same semantics, = and we=E2=80=99re changing the name in GNAP to align with the FAPI one. = This begs the question: do we want to just define this field as an = optional component in DPoP instead of having these profiles do it = separately? It would save them from needing to align with each other, = and anyone else from inventing it again.

Is it worth defining this in DPoP = directly, or does that complicate the spec too much? I=E2=80=99ve = previously raised a similar question on including a hash of the access = token in the DPoP request to the RS.

 =E2=80=94 = Justin
= --Apple-Mail=_49C41336-7023-426B-A1F1-CA8F0E34566C-- From nobody Wed Feb 17 14:48:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FA43A1E06 for ; Wed, 17 Feb 2021 14:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbzd1JofSifT for ; Wed, 17 Feb 2021 14:48:41 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0256B3A1E00 for ; Wed, 17 Feb 2021 14:48:40 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id w36so740656lfu.4 for ; Wed, 17 Feb 2021 14:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QqKZX9fRo9/GvuRzYuu7Ucg46z2YSwZxsuwWn67ndRw=; b=QE94mJTAPP3F34e4OA3ZQaAJOLV2efxkkWUiXoyqO9IfcLsG8FagFNLzxwhxB6gNtQ X/WlCffFveDB3po7eA/R/TcS4P/i1GaFyoL1SfaTmtK64yOrFh6nUhM93QvcKJIKoswh +6X7/Li2DQeIUGY3dFuNmVE5jUjhOZiFKtNuFbZhsk76BCGHbiS6hjLfDtI22CohZcvi 64Lle/wvAd4W28chaFcPy7IulfkYsK5HomA2Gw/oehiURnkPJ84EO2EIOwAyqVwgDn2v gTPDUYUX189icj9RGedczIczZaU1e2PHEBE4l5bTtkwtID10FZFmmuUrJKwqsnTMXQmv ipdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QqKZX9fRo9/GvuRzYuu7Ucg46z2YSwZxsuwWn67ndRw=; b=EW47m2VkjPu0a/s2BQ2zQ0Ej+Ye2a2FOZWyz7l9SUw44GTIfHBr6J4NWS7/vjtmd60 U4o2R2muvh2sNWVVe3EegQ2s9bYuY1k5zYCZGGJa9xbYju9FcpZ68kUwcvMn7ym6S8oI r56OD3bqw/dDFF6tq6RKTurq0ZEqjEmEesl5RdWjvzBsDgQzEBQH9ecgUelE/S0b3DL3 UsW6U8gn4a1uK09jJopQPMyGoiMYaWa8tDkB232suGO9bMojqrIet+9LrTvCDKlwVF6F BLQTKzuJb9+yrJyZCVXaLxiL8rGB8/HYFDgZIq1LfUEuDoHuvRcBI1GVSBvgDhqbyIHv VcjQ== X-Gm-Message-State: AOAM531EGwBIt0xuboU5uFC9qNoqvRPRrUd0YVTgA9sZwLEqDwYT/aEr zV4gDAdYg5ShO+QbJGfmowlB8dYWF1TuKWOguMpGTco37duT+rVm4AYrSEf9q4Rj/m2uVM3jp5J tOah8njjKqujkRQ== X-Google-Smtp-Source: ABdhPJxtLD1kjlmZb4cf2Ms6HiWsr3TBDb8ezywj6+UdZDP5PoUqKpZ+vYPeUDuinb8ti5MJQXx+KinGviwOBe/PWfA= X-Received: by 2002:ac2:555b:: with SMTP id l27mr640217lfk.173.1613602118711; Wed, 17 Feb 2021 14:48:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Wed, 17 Feb 2021 15:48:12 -0700 Message-ID: To: Neil Madden Cc: Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="00000000000018630f05bb900575" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 22:48:44 -0000 --00000000000018630f05bb900575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Always appreciate (and often learn from) your insights, Neil. I'd like to dig into the CSRF thing a bit more though to understand better and hopefully do the right thing in the draft. It seems to me that a GET at the bff-token endpoint is "safe" in that it's effectively just a read. There could be a "cache miss" where the backend attempts to use a refresh token it has to get a new access token from the remote AS, which will be more resource intensive but doesn't fundamentally alter the state of the backend so is still "safe". That in conjunction with your pointing to Cross-Origin Read Blocking makes me think your concern isn't so much about traditional CSRF used to take some malicious action but rather about somehow (speculative side-channel attacks, problems with javascript interpreters, other similar vectors that are somewhat beyond me) accessing the data of the response to a forged cross site request. Correct me if I'm wrong. I don't know if or how much the distinction matters in terms of mitigation approach but I'm keen to better understand. It sounds like your preference for only POST rests in an assumption that the larger app will already have in place some CSRF defenses and by using POST the bff-token endpoint will basically inherit said defenses. Or is POST by itself good enough (the CORB writeup seems to suggest that the context in which a POST could be made is more guarded against side channel stuff)? But perhaps then the draft should be more explicit about CSRF defense? Saying it just has to be done. Or like even mandating a non-standard header be in the request, "X-Neil-says-beware-CSRF: yuppers" as a strawman. With such a header it could remain a GET. And I kinda like GET because it is really a request for data. Or perhaps the request should be a POST with built-in CSRF protection by changing it to carry any parameters as JSON in the body with "{}" for the case of no parameters specified? Or just make it a PUT and call it good? Not sure any of these are good ideas but just trying to hash out the most appropriate thing to do. That got a little rambly, sorry. But hopefully it makes some sense. On Sun, Feb 14, 2021 at 1:17 AM Neil Madden wrote: > > The combination of the bff-token endpoint recommending the use of GET > requests together with the hint to use cookie-based authentication is > likely going to punch a hole in most CSRF defenses, which assume that GET= s > are safe. The only thing preventing this being exploitable is Cross-Origi= n > Read Blocking ( > https://chromium.googlesource.com/chromium/src/+/master/services/network/= cross_origin_read_blocking_explainer.md) > due to the JSON content-type. That makes me really nervous. We should at > least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel > more comfortable if this was a POST request only. > > =E2=80=94 Neil > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000018630f05bb900575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Always appreciate (and often learn from) your insight= s, Neil. I'd like to dig into the CSRF thing a bit more though to under= stand better and hopefully do the right thing in the draft.
=
It seems to me that a GET at the bff-token endpoint is "= ;safe" in that it's effectively just a read. There could be a &quo= t;cache miss" where the backend attempts to use a refresh token it has= to get a new access token from the remote AS, which will be more resource = intensive but doesn't fundamentally alter the state of the backend so i= s still "safe". That in conjunction with your pointing to Cross-O= rigin Read Blocking makes me think your concern isn't so much about tra= ditional CSRF used to take some malicious action but rather about somehow (= speculative side-channel attacks, problems with javascript interpreters, ot= her similar vectors that are somewhat beyond me) accessing the data of the = response to a forged cross site request. Correct me if I'm wrong. I don= 't know if or how much the distinction matters in terms of mitigation a= pproach but I'm keen to better understand.=C2=A0

It sounds like your preference for only POST rests in an assumptio= n that the larger app will already have in place some CSRF defenses and by = using POST the bff-token endpoint will basically inherit said defenses. Or = is POST by itself good enough (the CORB writeup seems to suggest that the c= ontext in which a POST could be made is more guarded against side channel s= tuff)?=C2=A0 But perhaps then the draft should be more explicit about CSRF = defense? Saying it just has to be done. Or like even mandating a non-standa= rd header be in the request, "X-Neil-says-beware-CSRF: yuppers" a= s a strawman. With such a header it could remain a GET. And I kinda like GE= T because it is really a request for data.=C2=A0 Or perhaps the request sho= uld be a POST with built-in CSRF protection by changing it to carry any par= ameters as JSON in the body with "{}" for the case of no paramete= rs specified?=C2=A0 Or just make it a PUT and call it good? Not sure any of= these are good ideas but just trying to hash out the most appropriate thin= g to do.

That got a little rambly, sorry. But= hopefully it makes some sense.

On Sun, Feb 14, 2021 at 1:17= AM Neil Madden <neil.madden@forgerock.com> wrote:

The combination of the bff-= token endpoint recommending the use of GET requests together with the hint = to use cookie-based authentication is likely going to punch a hole in most = CSRF defenses, which assume that GETs are safe. The only thing preventing t= his being exploitable is Cross-Origin Read Blocking (https://chromium.googlesource= .com/chromium/src/+/master/services/network/cross_origin_read_blocking_expl= ainer.md) due to the JSON content-type. That makes me really nervous. W= e should at least mandate X-Content-Type-Options: nosniff on that response.= I=E2=80=99d feel more comfortable if this was a POST request only.=C2=A0
=E2=80=94 Neil


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000018630f05bb900575-- From nobody Wed Feb 17 15:35:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9D13A1C46 for ; Wed, 17 Feb 2021 15:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwfr0I63I6YZ for ; Wed, 17 Feb 2021 15:35:51 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0B93A18F7 for ; Wed, 17 Feb 2021 15:35:51 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id e17so19249356ljl.8 for ; Wed, 17 Feb 2021 15:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DqJW61eqeAvoxB9zu9x1EMDJuiL99mLr9fdfzdRvUlk=; b=Ops9PUm+/4f49xR+72rK8+NdOi5MBY7q22wlO0pnprSfW7e5Ytkw1rvWVgwgPLYbuK 9rshWvK+QTUHlZOHpoWkG9LZ4OJxU9ORstsbTvaIxTwweeO1Okq/wytcVWan5+y6WC9n e1xuPXkPeYtzZDuUUuaDG6vQ92ipsU/e69OUBy9Iw4XJtnjMj+4kotTGBmzc7VKV5g3D LCzUBtPbafyLhSs5RRuu1zPPn6S/FFCwJ5abdzU1aiH1xkv6sUVQCwKjaUJjlDj2QB74 GG/KZzMRGIKHGNFDY3sUf6/uD9cFJ+PNEnvQ7R5QfYzKccq6JUFnwAEWFTsceQESNc4V bqdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DqJW61eqeAvoxB9zu9x1EMDJuiL99mLr9fdfzdRvUlk=; b=eJY4DEDXF0r5aYU2kPVODhn7xTOix1fjnaM6PC+ZTmoowyxy5BNAripMNTaakAAZPT /n3MJZBjOUQ1WzwJu+whQ//Hd9HlnnicLrQcq8rFeX4eOx84/I8bW0yzXEFsoTSXwbth 19groFMdG3/3Lhfc4WFGXBrxOu3pZtmdMR5UVLMcHMbOSXxpIn5HZzgqC7T1KlrdzsNl 2ya25HV5xGHf3LTJwQJquNMI3udb1W6/z5Rldul6xgW407bixHlL0AA1EujF8GLZuUiT lHbFJ8ZVptVs7tZi2PbdaB1KM9BKKuU/eTUAQEOk9fHXdCbpROHudIpZqdo4xL7k/C// Iqyg== X-Gm-Message-State: AOAM532hQrqXtz3jtkNbzu95zHkI8PDBGM650c1z/yMNEkT8aP4fN640 oQ/WB/FpnulybZs+t4P1m9kLFWbY4MolVwRqmtwam3WF376C24dCQYORD4C5M81TI+yT6zCDDLY s79RFYKL0YrtrFQ== X-Google-Smtp-Source: ABdhPJzX2QHNWqxW4BaLFKW21y9Ezy/N0BNvFqpaB9X2vCxMvCqBsf8wpNbyrYCTQ0XwdY06q6Wq/FeZZ/sCXarF5QI= X-Received: by 2002:a2e:a550:: with SMTP id e16mr918571ljn.264.1613604949106; Wed, 17 Feb 2021 15:35:49 -0800 (PST) MIME-Version: 1.0 References: <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2id.com> In-Reply-To: <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2id.com> From: Brian Campbell Date: Wed, 17 Feb 2021 16:35:22 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: oauth Content-Type: multipart/alternative; boundary="000000000000ccc3bb05bb90ad93" Archived-At: Subject: Re: [OAUTH-WG] Authorization Header Encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 23:35:54 -0000 --000000000000ccc3bb05bb90ad93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable AFAIK the character set for the "Bearer" scheme in RFC6750 is what it is to align with the token68 part of "credentials =3D auth-scheme [ 1*SP ( token6= 8 / #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1 (the draft that would become RFC7235 is referenced by RFC6750 in https://tools.ietf.org/html/rfc6750#section-2.1 where it says basically as much). Also it looks like https://github.com/httpwg/http-core/issues/733 was closed with no action. So I don't see what change would be made in OAuth 2.1 or elsewhere. Nor does it seem like any change is needed or appropriate. On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov wrote: > Hi Justin, > > Thanks for alerting us on this development. > > +1 for keeping the updated HTTP semantics unencumbered by the > Authorization header formatting in RFC 6750. > > IMO revising the RFC 6750 to reflect that is too late now, as few people > will notice. So updating the Bearer header definition in OAuth 2.1 seems > like the most sensible move. I expect OAuth 2.0 implementers who maintain > their software to pick up the 2.1 spec, sooner or later. > > Vladimir > > > On 12/02/2021 00:01, Justin Richer wrote: > > The HTTP Working Group opened an issue for discussion in relation to the > updated HTTP semantics specification. The core of the issue is the format > of the =E2=80=9CAuthorization=E2=80=9D header, which of course gets used = by the =E2=80=9CBearer=E2=80=9D > scheme defined in RFC6750. > > https://github.com/httpwg/http-core/issues/733 > > As it turns out, Bearer defines a more limited character set than is > allowed by core HTTP, and doesn=E2=80=99t follow the HTTP guidelines and > definitions for the Authorization header. There were a few observations o= n > the call: > > - The Bearer spec was limited because OAuth tokens were also allowed in > HTTP URLs and form parameters (and therefore had to have a more limited > character set) > - In practice people don=E2=80=99t actually restrict the values they put= into > this field; pretty much any implementation is just going to concatenate > whatever access token value they get to the magic word =E2=80=9CBearer=E2= =80=9D and send it > - It=E2=80=99s not likely (or in my opinion proper) for the HTTP spec to= change > to address the oddities of RFC6750 and decisions that were made many year= s > ago > > So the question is, what do we do about it? We could do a revision of 675= 0 > that reflects reality better, pretty much just changing the ABNF. > > Or, we could update the definition of the Bearer header in the upcoming > OAuth 2.1 specification. > > Are there other options? > > =E2=80=94 Justin > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > -- > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000ccc3bb05bb90ad93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
AFAIK the character set for the "Bearer" sc= heme in RFC6750 is what it is to align with the token68 part of "crede= ntials =3D auth-scheme [ 1*SP ( token68 / #auth-param ) ]" from htt= ps://tools.ietf.org/html/rfc7235#section-2.1 (the draft that would beco= me RFC7235 is referenced by RFC6750 in https://tools.ietf.org/html/rfc6750#section-2.1= where it says basically as much).

Also it l= ooks like https://github.com/httpwg/http-core/issues/733 was closed w= ith no action.

So I don't see what change= would be made in OAuth 2.1 or elsewhere. Nor does it seem like any change = is needed or appropriate.=C2=A0

On Mon, Feb 15, 2021 at 4:34 AM V= ladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20

Hi Justin,

Thanks for alerting us on this development.

+1 for keeping the updated HTTP semantics unencumbered by the Authorization header formatting in RFC 6750.

IMO revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAuth 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers who maintain their software to pick up the 2.1 spec, sooner or later.

Vladimir


On 12/02/2021 00:01, Justin Richer wrote:
=20 The HTTP Working Group opened an issue for discussion in relation to the updated HTTP semantics specification. The core of the issue is the format of the =E2=80=9CAuthorization=E2=80=9D header, which of= course gets used by the =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750.


As it turns out, Bearer defines a more limited character set than is allowed by core HTTP, and doesn=E2=80=99t fol= low the HTTP guidelines and definitions for the Authorization header. There were a few observations on the call:

=C2=A0- The Bearer spec was limited because OAuth tokens were also allowed in HTTP URLs and form parameters (and therefore had to have a more limited character set)
=C2=A0- In practice people don=E2=80=99t actually restrict the values they put into this field; pretty much any implementation is just going to concatenate whatever access token value they get to the magic word =E2=80=9CBearer=E2=80=9D and send it
=C2=A0- It=E2=80=99s not likely (or in my opinion proper) for th= e HTTP spec to change to address the oddities of RFC6750 and decisions that were made many years ago

So the question is, what do we do about it? We could do a revision of 6750 that reflects reality better, pretty much just changing the ABNF.

Or, we could update the definition of the Bearer header in the upcoming OAuth 2.1 specification.

Are there other options?

=C2=A0=E2=80=94 Justin


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

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000ccc3bb05bb90ad93-- From nobody Wed Feb 17 23:43:14 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19D33A0CE5 for ; Wed, 17 Feb 2021 23:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq5aKeAeKSbc for ; Wed, 17 Feb 2021 23:43:10 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B0A3A0CE8 for ; Wed, 17 Feb 2021 23:43:09 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id q5so674557ilc.10 for ; Wed, 17 Feb 2021 23:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=YU99IZyoNhkclwskPBnLojx3BKYRVzRymcn7vZc75fc=; b=c7wGVntv8URbQxI1YoySNPIrsg1IyEiwn827XUySfch2QSqclexbw1+air417TNNJq ySvxz/pIugmDxIECn8c3xIe01GxHHtlfB0/595Mq25RfmwTTFeES8PFdBjt8LV7eonqR kKpvFx6vTxXzAge8cLMTpo754CCWRqhJ+o0GFWnSnPkUYmT0aHgaKYEnOPJYZXRbTl/4 WVW5XAHuX33Dsu90RkCGuY55OwFwo2/5pCStXkrwE+ircB8EWQdv942AwBqMFPI+jPha z2CPBIcNjsMeKus5E/7NyWlLZToZS2i2imSydg0uzLNR5BixIayYhOFd/Oe+9giZ1Ueh smGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=YU99IZyoNhkclwskPBnLojx3BKYRVzRymcn7vZc75fc=; b=mvrcU1mVrUN6GD1KoHVUZeQ0jFc3wZMTZfvHW9oAGIO8rRNDkp9P13aBGeKxUUDS+p grw1hj2vTjSbcRYl2sYIz+pbTaOjKH9a1O9VI+ZhKiTfmxbs05ACjy5H3ODC5CJnG3BH FPUFtCeWDkxGRIWu2ExDvunhmRt5a6/wVtwiyeoWi+8Mtlen6BOq3eSzafXhooFm4Aij QEDYTNkLQx8EwPjZ6berxilOWvFfkGuKcbnwVbPzisKkW3ggY2cBjiGiMDR42uo0DCgX TgNGXUJqVITtPSsOUnfC//e5nyH4R9BBg4bKGX/t8Hvxe9lmlCW/pRvMcHpZbmSRHjyH XTmA== X-Gm-Message-State: AOAM531HlfiRs7iBmLzKRKy+QQ7oj3uaJFQQBvSrshThUqxGoEIzuqAP /rspD3JgnbkQcZSCBZjYK0DXQSU/SufS30/4abKN X-Google-Smtp-Source: ABdhPJzVb6PhjbqKLkwX/p3RL5gIAbs38Z+vddO63opSoNr8oeBYZU2bSxNQEsvOVq2UWad5hLXvRY92pN3axCB/t5k= X-Received: by 2002:a92:b00d:: with SMTP id x13mr2676145ilh.128.1613634189076; Wed, 17 Feb 2021 23:43:09 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 17 Feb 2021 23:43:08 -0800 From: Dominick Baier In-Reply-To: <98E38875-F022-419C-87FA-1218B4A16660@forgerock.com> References: <98E38875-F022-419C-87FA-1218B4A16660@forgerock.com> MIME-Version: 1.0 Date: Wed, 17 Feb 2021 23:43:08 -0800 Message-ID: To: Neil Madden Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000a3444605bb977c9e" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 07:43:13 -0000 --000000000000a3444605bb977c9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No. But they are CSRF protected (either SameSite or anti-forgery) and HttpOnly. =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 17. February 2021 at 21:08:37, Neil Madden (neil.madden@forgerock.com) wrote: Do you eliminate the cookies too? On 17 Feb 2021, at 19:50, Dominick Baier wrote: =EF=BB=BF Well. Maybe it is at least worth while then to at least mention that you could also take a slightly different approach and eliminate all tokens in the browser - with the respective trade offs. =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 17. February 2021 at 20:46:42, Warren Parad (wparad@rhosys.ch) wrote: While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the X= SS problem=E2=80=9D - > this is absolutely correct. But when there are no tokens in the browser - > you can simply eliminate that part of the threat model ;) The point was it doesn't eliminate anything, it just changes the request/response data that is part of the attack. This doesn't increase security, as a matter of fact, with regard to the RFC, we shouldn't talk about security at all, since it has zero impact on it. It is worth talking about that pattern as *one* possible solution to maintaining sessions, but that's it. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier wrote: > Yes - =E2=80=9Cno OAuth tokens in the browser=E2=80=9D ;) They are all ke= pt server-side > and the BFF proxies the API calls if necessary. Also the RT management > happens server-side and is transparent to the SPA. > > I see that in lots of industries - finance, health, cloud providers > > While someone will always say =E2=80=9Cbut this doesn=E2=80=99t solve the= XSS problem=E2=80=9D - > this is absolutely correct. But when there are no tokens in the browser - > you can simply eliminate that part of the threat model ;) > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 17. February 2021 at 18:30:23, Vittorio Bertocci ( > vittorio.bertocci@auth0.com) wrote: > > Thanks Dominick, > > It is indeed a very simple spec, but as you can see from the discussion s= o > far, it doesn=E2=80=99t appear to be trivial- and there might be some > considerations we consider obvious (eg scope escalation) that might not b= e > super clear otherwise. > > In terms of the guidance, just to make sure I get the scope right- that > means that also code+PKCE+rotating RTs in JS would not be acceptable for > your customers? > > > > *From: *Dominick Baier > *Date: *Wednesday, February 17, 2021 at 00:27 > *To: *Brian Campbell , Torsten Lodderstedt < > torsten@lodderstedt.net> > *Cc: *Vittorio Bertocci , "oauth@ietf.org" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend > For Frontend (TMI BFF) > > > > Hey, > > > > Tbh - I have a bit of a hard time to see why this requires a spec, if tha= t > is all you are aiming at. Wouldn=E2=80=99t that be just an extension to t= he =E2=80=9COAuth > for web apps BCP?=E2=80=9D. > > > > All I can add here is - this approach would not work for any of our > customer. Because their real motivation is to implement a more and more > common security guideline these days - namely: =E2=80=9Cno JS-accessible = tokens in > the browser=E2=80=9D - but this document doesn=E2=80=99t cover this. > > > > cheers > > =E2=80=94=E2=80=94=E2=80=94 > > Dominick Baier > > > > On 16. February 2021 at 22:01:37, Brian Campbell ( > bcampbell=3D40pingidentity.com@dmarc.ietf.org) wrote: > > > > > > > > On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Thank you again for the explanation. > > I think your assumption about the overall flow should be described in the > draft. > > > > We did attempt to capture the assumptions in the draft but clearly could > have done a better job with it :) > > > > > As I understand it now the core contribution of your proposal is to move > refresh token management from frontend to backend. Is that correct? > > > > Taking that a bit further - the idea is that the backend takes on the > responsibilities of being a confidential client (client creds, token > acquisition, token management/persistence, etc.) to the external AS(s). A= nd > TMI BFF describes a way for that backend to deliver access tokens to its > own frontend. > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing 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 ForgeRock values your Privacy --000000000000a3444605bb977c9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
No. = But they are CSRF protected (either SameSite or anti-forgery) and HttpOnly.=

=E2=80=94=E2=80=94=E2=80=94
= Dominick Baier

On 17. February 2021= at 21:08:37, Neil Madden (nei= l.madden@forgerock.com) wrote:

Do you el= iminate the cookies too?

On 17 Feb 2021, at 19:50, Dominick Baier <dbaier@leastprivilege.com> wrote:

=EF=BB=BF
Well. Maybe it is at least wort= h while then to at least mention that you could also take a slightly differ= ent approach and eliminate all tokens in the browser - with the respective = trade offs.

=E2=80=94=E2=80=94=E2= =80=94
Dominick Baier

On 17. Fe= bruary 2021 at 20:46:42, Warren Parad (= wparad@rhosys.ch) wrote:

While someone will always say =E2=80=9Cbut this doesn= =E2=80=99t solve the XSS problem=E2=80=9D - this is absolutely correct. But= when there are no tokens in the browser - you can simply eliminate that pa= rt of the threat model ;)
The point was it doesn't eliminat= e anything, it just changes the request/response data that is part of the a= ttack. This doesn't increase security, as a matter of fact, with regard= to the RFC, we shouldn't talk about security at all, since it has zero= impact on it.

It is worth talking about that pattern as= one=C2=A0possible solution to maintaining sessions, but that's = it.

<= td style=3D"border-left:solid #cccccc 1pt;border-right:solid #ffffff 1pt;bo= rder-bottom:solid #ffffff 1pt;border-top:solid #ffffff 1pt;vertical-align:t= op;padding:5pt 5pt 5pt 5pt;overflow:hidden">

Warren Parad

Founder, CTO

Secure your user data wi= th IAM authorization as a service. Implement=C2=A0Authress.


On Wed, Feb 17, 2021 at 8:43 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Yes - =E2=80=9Cno OAuth tokens in the = browser=E2=80=9D ;) They are all kept server-side and the BFF proxies the A= PI calls if necessary. Also the RT management happens server-side and is tr= ansparent to the SPA.

I see that in lots of industries - finance, health, cloud providers

While someone will alwa= ys say =E2=80=9Cbut this doesn=E2=80=99t solve the XSS problem=E2=80=9D - t= his is absolutely correct. But when there are no tokens in the browser - yo= u can simply eliminate that part of the threat model ;)

=E2= =80=94=E2=80=94=E2=80=94
Dominick Baier

On 17. Febru= ary 2021 at 18:30:23, Vittorio Bertocci (vittorio.bertocci@auth0.com) wrote:

=

Thanks Dominick,

It is indeed a very simple spec, but as you can see = from the discussion so far, it doesn=E2=80=99t appear to be trivial- and th= ere might be some considerations we consider obvious (eg scope escalation) = that might not be super clear otherwise.

In terms of the guidance, just to make sure I get th= e scope right- that means that also code+PKCE+rotating RTs in JS would not = be acceptable for your customers?

=C2=A0

From: = Dominick Baier <dbaier@leastpr= ivilege.com>
Date: Wednesday, February 17, 2021 at 00:27
To: Brian Campbell <bcampbell@pingidentity.com>, Torsten Lodderstedt = <torsten@lo= dderstedt.net>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, "oauth@ietf.org" <<= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org> Subject: Re: [OAUTH-WG] Token Mediating and session Information Back= end For Frontend (TMI BFF)

=C2=A0

Hey,=C2=A0

=C2=A0

Tbh - I have a bit of a hard time to see why this requires a spec, if that= is all you are aiming at. Wouldn=E2=80=99t that be just an extension to th= e =E2=80=9COAuth for web apps BCP?=E2=80=9D.

=C2=A0

All I can add here is - this approach would not work for any of our custom= er. Because their real motivation is to implement a more and more common se= curity guideline these days - namely: =E2=80=9Cno JS-accessible tokens in the browser=E2=80=9D - but this docume= nt doesn=E2=80=99t cover this.

=C2=A0

cheers=C2=A0

=E2=80=94=E2=80=94=E2=80=94

Dominick Baier

=C2=A0

On 16. February 2021 at 22:01:37, Brian Campbell (bcampbell=3D40= pingidentity.com@dmarc.ietf.org) wrote:

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 15, 2021 at 9:48 AM Torsten Lodderstedt = <torsten@lo= dderstedt.net> wrote:

Thank you again for the explanation.

I think your assumption about the overall flow should be described in the d= raft. =20

=C2=A0

We did attempt to capture the assumptions in the dra= ft but clearly could have done a better job with it :)

=C2=A0


As I understand it now the core contribution of your proposal is to move re= fresh token management from frontend to backend. Is that correct?=C2=A0

=C2=A0

=C2=A0Taking that a bit further - the idea is that t= he backend takes on the responsibilities of being a confidential client (cl= ient creds, token acquisition, token management/persistence, etc.) to the e= xternal AS(s). And TMI BFF describes a way for that backend to deliver access tokens to its own frontend.=C2=A0 <= /p>


CONFIDENTIALITY NOTICE: This email may contain confide= ntial and privileged material for the sole use of the intended recipient(s)= . Any review, use, distribution or disclosure by others is strictly prohibited.=C2=A0 If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you._______________________________________________
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
_______________________________________________
OAuth= mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth

ForgeRock values your Privacy --000000000000a3444605bb977c9e-- From nobody Thu Feb 18 04:09:05 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D73A115C for ; Thu, 18 Feb 2021 04:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4R5lysKvlyo for ; Thu, 18 Feb 2021 04:09:01 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5313A1157 for ; Thu, 18 Feb 2021 04:09:00 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id x16so3174434wmk.3 for ; Thu, 18 Feb 2021 04:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KL3tWaqWBrfGEbwDTz6bwdIVuh91yQTexkEKm+eZC4c=; b=ZLOlf2392heqIVZrj43jesCmzTjtjTSRnVePXxAORIxLjonD1KS39EbuFMSvs7Zlex RJsCe5Fcb5qBzskYxGeMnKA7eY5M1qsaK7jdpD1yHxwBd2DcQUfha1mLOKqCFcXqsGNR bmwtwx8QKRcH/WlHXNeRZ08Bo/L/qjWY2BUQU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KL3tWaqWBrfGEbwDTz6bwdIVuh91yQTexkEKm+eZC4c=; b=S8aPPP9PZui2ecMSkdgOcWtLr/8FDidfPaqzTotVdJCaowPMMHUYuDj9I1pUyJkvIo ans2VhobPdJkaXc/uDDUxULYB/44iT3dFAs3S9KWlmbJ580Y/9DUMAUFmOWergFi7MAG eVk3aISsrSW5dn2Vv3E357NZ3Ft1wwmWIwEmY3qDtSNj1zX+yvR1wiUeAEED8YsCSY6C 9ovLWsMflvt9IqJd49ed/iJIIOdxrQjqMCFfuAQfaDbSM1eIdpGKqYUrHsp3ke3g9fjw g/d6tOuaU8jetPh72C8J5xL3S5InSOs+uMNfKe9iMAS6KLPyIYn4OhWeiH3XtzYMiPAY ECuQ== X-Gm-Message-State: AOAM530K/L5+cVFz2egFYk1gpXijSEkNkdmpXYLbDWY4OE30SJh51SAS sExB9NC6H6lQ/nVqm5FWJYUkoRk84zRNTqoiRkn9aDrdzlvip2a7V/E4k27z7vIEjUZiV9o4YQ= = X-Google-Smtp-Source: ABdhPJyU/15nxdc3ZJy6mq7/MWKeFhF8sY11v5gwMqGd0+lla60By9Cx9ugUAxH+wzdOuttheZ8LLQ== X-Received: by 2002:a7b:c055:: with SMTP id u21mr3412289wmc.68.1613650138605; Thu, 18 Feb 2021 04:08:58 -0800 (PST) Received: from [10.0.0.6] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id 6sm11478055wra.63.2021.02.18.04.08.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 04:08:58 -0800 (PST) From: Neil Madden Message-Id: <35645BCD-A9F5-4A57-9771-836647F08444@forgerock.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 12:08:55 +0000 In-Reply-To: Cc: Vittorio Bertocci , oauth To: Brian Campbell References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Content-Type: multipart/alternative; boundary="Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 12:09:04 -0000 --Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Thanks for following up, Brian. Responses below. > On 17 Feb 2021, at 22:48, Brian Campbell wro= te: >=20 > Always appreciate (and often learn from) your insights, Neil. I'd like to= dig into the CSRF thing a bit more though to understand better and hopeful= ly do the right thing in the draft.=20 >=20 > It seems to me that a GET at the bff-token endpoint is "safe" in that it'= s effectively just a read. Well it=E2=80=99s a read that returns an access token. It=E2=80=99s =E2=80= =9Csafe=E2=80=9D in the sense of side-effects, but we absolutely want to pr= eserve the confidentiality of what is returned and only allow it to be acce= ssed by authorized clients (the legitimate frontend). At the moment the onl= y thing keeping that safe is the JSON content type. For example, imagine a = world in which the token-bff endpoint instead returned the access token as = HTML:
abcd
Then as an attacker I can simply embed an iframe on my site that refers to = your bff-endpoint and then parse the access token out of the DOM. The brows= er will happily load that iframe and send along the cookie when it makes th= e request. If you have CORS enabled on your site (with Access-Control-Allow= -Credentials) then any of the allowed CORS origins can directly call the bf= f-token endpoint and read the access token even in JSON form. There have al= so been historical same-origin policy bypasses using Flash, Adobe Reader, o= r other plugins (thankfully now largely eliminated), or by redefining JavaS= cript prototypes - see https://haacked.com/archive/2009/06/25/json-hijackin= g.aspx/ . The= se are largely fixed, but I wouldn=E2=80=99t bet on there never being anoth= er one. > There could be a "cache miss" where the backend attempts to use a refresh= token it has to get a new access token from the remote AS, which will be m= ore resource intensive but doesn't fundamentally alter the state of the bac= kend so is still "safe". That in conjunction with your pointing to Cross-Or= igin Read Blocking makes me think your concern isn't so much about traditio= nal CSRF used to take some malicious action but rather about somehow (specu= lative side-channel attacks, problems with javascript interpreters, other s= imilar vectors that are somewhat beyond me) accessing the data of the respo= nse to a forged cross site request. Correct me if I'm wrong. I don't know i= f or how much the distinction matters in terms of mitigation approach but I= 'm keen to better understand. =20 As explained above, because the endpoint returns JSON it _should_ be imposs= ible to directly read the response from a cross-origin read (unless explici= tly enabled with CORS). But you may still be able to embed that response in= an or similar. Because people are terrible at setting correct Conten= t-Type headers on responses, browsers often ignore them and instead try to = sniff what the real content type is: so if the response looks a bit like a = valid image format (or PDF or JavaScript or whatever) then it might try and= render it. No doubt this will fail, but at that point the data has already= been loaded into the address space of the renderer process for the attacke= r=E2=80=99s site. That means that it is then vulnerable to attacks like Spe= ctre that bypass normal memory protection. The browser vendors consider thi= s to be a real threat, hence CORB. The most important thing for a cookie-based JSON API to do is to return a c= orrect Content-Type header and to also return X-Content-Type-Options: nosni= ff to prevent browsers from trying to sniff the real content-type. (I have = an example in my book where the failure to do this can actually turn a JSON= API into a vector for XSS attacks, even if you have no SPA frontend compon= ent at all). (You should also mark the cookie as HttpOnly because this prevents the cook= ie ever entering the address space of a renderer process in modern browsers= - an actual genuine security benefit of HttpOnly cookies). But my worry is that this is still basically trusting the client to perform= critical security checks, and historically browsers have had plenty of byp= asses in this area. So for something as high-value as an access token I=E2= =80=99d prefer that any request using cookie-based authentication is protec= ted by proactive CSRF defences to prevent malicious requests being allowed = in the first place. >=20 > It sounds like your preference for only POST rests in an assumption that = the larger app will already have in place some CSRF defenses and by using P= OST the bff-token endpoint will basically inherit said defenses. Or is POST= by itself good enough (the CORB writeup seems to suggest that the context = in which a POST could be made is more guarded against side channel stuff)? = But perhaps then the draft should be more explicit about CSRF defense? Say= ing it just has to be done. Or like even mandating a non-standard header be= in the request, "X-Neil-says-beware-CSRF: yuppers" as a strawman. With suc= h a header it could remain a GET. And I kinda like GET because it is really= a request for data. Or perhaps the request should be a POST with built-in= CSRF protection by changing it to carry any parameters as JSON in the body= with "{}" for the case of no parameters specified? Or just make it a PUT = and call it good? Not sure any of these are good ideas but just trying to h= ash out the most appropriate thing to do.=20 Right, the preference for POST is because it's more likely to trigger CSRF = defences, which often consider GET/HEAD requests to be =E2=80=9Csafe=E2=80= =9D. Even before Spectre, there is a whole array of side-channel attacks fo= r extracting information from cross-site responses: https://xsleaks.dev . Note that even SameSite has a "GET-out clause" in the= form of =E2=80=9Clax=E2=80=9D. So yes, the real requirement is that the endpoint should have adequate CSRF= protection. Requiring a special header has had bypasses in the past (again= , mostly using Flash). So I think we should recommend the following: 1. The response MUST contain a correct Content-Type: application/json heade= r and X-Content-Type-Options: nosniff. 2. The cookie SHOULD be marked as HttpOnly. 3. The endpoint MUST NOT be accessible via CORS. 4. The endpoint SHOULD have adequate CSRF protections in place. At a minimu= m the cookie should be marked as SameSite.=20 We could perhaps add an informational reference to https://cheatsheetseries= .owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.ht= ml given that there is a changing landscape ar= ound cookies at the moment. If the browser vendors do eliminate 3rd-party c= ookies then 1, 3, and 4 become largely unnecessary (although 3 might still = be a risk due to sub-domain hijacking, and 1 will always be good practice). =E2=80=94 Neil >=20 > That got a little rambly, sorry. But hopefully it makes some sense.=20 >=20 > On Sun, Feb 14, 2021 at 1:17 AM Neil Madden > wrote: >=20 > The combination of the bff-token endpoint recommending the use of GET req= uests together with the hint to use cookie-based authentication is likely g= oing to punch a hole in most CSRF defenses, which assume that GETs are safe= . The only thing preventing this being exploitable is Cross-Origin Read Blo= cking (https://chromium.googlesource.com/chromium/src/+/master/services/net= work/cross_origin_read_blocking_explainer.md ) due to the JSON content-type. That makes me really nervous. We s= hould at least mandate X-Content-Type-Options: nosniff on that response. I= =E2=80=99d feel more comfortable if this was a POST request only.=20 >=20 > =E2=80=94 Neil >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. --=20 ForgeRock values your Privacy --Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Thanks for following up, B= rian. Responses below.

On= 17 Feb 2021, at 22:48, Brian Campbell <bcampbell@pingidentity.com> wrote:
Always appreciate (and often learn from) your insight= s, Neil. I'd like to dig into the CSRF thing a bit more though to understan= d better and hopefully do the right thing in the draft.

It seems to me that = a GET at the bff-token endpoint is "safe" in that it's effectively just a r= ead.

Well it= =E2=80=99s a read that returns an access token. It=E2=80=99s =E2=80=9Csafe= =E2=80=9D in the sense of side-effects, but we absolutely want to preserve = the confidentiality of what is returned and only allow it to be accessed by= authorized clients (the legitimate frontend). At the moment the only thing= keeping that safe is the JSON content type. For example, imagine a world i= n which the token-bff endpoint instead returned the access token as HTML:

<div id=3D=E2=80=9CaccessToken=E2=80= =9D>abcd</div>

Then as an atta= cker I can simply embed an iframe on my site that refers to your bff-endpoi= nt and then parse the access token out of the DOM. The browser will happily= load that iframe and send along the cookie when it makes the request. If y= ou have CORS enabled on your site (with Access-Control-Allow-Credentials) t= hen any of the allowed CORS origins can directly call the bff-token endpoin= t and read the access token even in JSON form. There have also been histori= cal same-origin policy bypasses using Flash, Adobe Reader, or other plugins= (thankfully now largely eliminated), or by redefining JavaScript prototype= s - see https://haacked.com/archive/2009/06/25/json-hijacking.= aspx/ . These are largely fixed, but I wouldn=E2=80=99t bet on the= re never being another one.


There could be a "cache miss" where the= backend attempts to use a refresh token it has to get a new access token f= rom the remote AS, which will be more resource intensive but doesn't fundam= entally alter the state of the backend so is still "safe". That in conjunct= ion with your pointing to Cross-Origin Read Blocking makes me think your co= ncern isn't so much about traditional CSRF used to take some malicious acti= on but rather about somehow (speculative side-channel attacks, problems wit= h javascript interpreters, other similar vectors that are somewhat beyond m= e) accessing the data of the response to a forged cross site request. Corre= ct me if I'm wrong. I don't know if or how much the distinction matters in = terms of mitigation approach but I'm keen to better understand. 

As = explained above, because the endpoint returns JSON it _should_ be impossibl= e to directly read the response from a cross-origin read (unless explicitly= enabled with CORS). But you may still be able to embed that response in an= <img> or similar. Because people are terrible at setting correct Con= tent-Type headers on responses, browsers often ignore them and instead try = to sniff what the real content type is: so if the response looks a bit like= a valid image format (or PDF or JavaScript or whatever) then it might try = and render it. No doubt this will fail, but at that point the data has alre= ady been loaded into the address space of the renderer process for the atta= cker=E2=80=99s site. That means that it is then vulnerable to attacks like = Spectre that bypass normal memory protection. The browser vendors consider = this to be a real threat, hence CORB.

T= he most important thing for a cookie-based JSON API to do is to return a co= rrect Content-Type header and to also return X-Content-Type-Options: nosnif= f to prevent browsers from trying to sniff the real content-type. (I have a= n example in my book where the failure to do this can actually turn a JSON = API into a vector for XSS attacks, even if you have no SPA frontend compone= nt at all).

(You should also mark the c= ookie as HttpOnly because this prevents the cookie ever entering the addres= s space of a renderer process in modern browsers - an actual genuine securi= ty benefit of HttpOnly cookies).

But my= worry is that this is still basically trusting the client to perform criti= cal security checks, and historically browsers have had plenty of bypasses = in this area. So for something as high-value as an access token I=E2=80=99d= prefer that any request using cookie-based authentication is protected by = proactive CSRF defences to prevent malicious requests being allowed in the = first place.


It sounds like your preference for only POST rests in an = assumption that the larger app will already have in place some CSRF defense= s and by using POST the bff-token endpoint will basically inherit said defe= nses. Or is POST by itself good enough (the CORB writeup seems to suggest t= hat the context in which a POST could be made is more guarded against side = channel stuff)?  But perhaps then the draft should be more explicit ab= out CSRF defense? Saying it just has to be done. Or like even mandating a n= on-standard header be in the request, "X-Neil-says-beware-CSRF: yuppers" as= a strawman. With such a header it could remain a GET. And I kinda like GET= because it is really a request for data.  Or perhaps the request shou= ld be a POST with built-in CSRF protection by changing it to carry any para= meters as JSON in the body with "{}" for the case of no parameters specifie= d?  Or just make it a PUT and call it good? Not sure any of these are = good ideas but just trying to hash out the most appropriate thing to do.

= Right, the preference for POST is because it's more likely to trigger CSRF = defences, which often consider GET/HEAD requests to be =E2=80=9Csafe=E2=80= =9D. Even before Spectre, there is a whole array of side-channel attacks fo= r extracting information from cross-site responses: https://xsleaks.dev . Note that even Same= Site has a "GET-out clause" in the form of =E2=80=9Clax=E2=80=9D.

So yes, the real requirement is that the endpoin= t should have adequate CSRF protection. Requiring a special header has had = bypasses in the past (again, mostly using Flash).

=
So I think we should recommend the following:

1. The response MUST contain a correct Content-Type: appl= ication/json header and X-Content-Type-Options: nosniff.
2. The c= ookie SHOULD be marked as HttpOnly.
3. The endpoint MUST NOT be a= ccessible via CORS.
4. The endpoint SHOULD have adequate CSRF pro= tections in place. At a minimum the cookie should be marked as SameSite.&nb= sp;

We could perhaps add an information= al reference to http= s://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Preve= ntion_Cheat_Sheet.html given that there is a changing landscape ar= ound cookies at the moment. If the browser vendors do eliminate 3rd-party c= ookies then 1, 3, and 4 become largely unnecessary (although 3 might still = be a risk due to sub-domain hijacking, and 1 will always be good practice).=

=E2=80=94 Neil


That got a little r= ambly, sorry. But hopefully it makes some sense.

On Sun, Feb 14, 2021 at 1:17 AM Neil Madden <neil.m= adden@forgerock.com> wrote:

The combination of the bff-token endpoi= nt recommending the use of GET requests together with the hint to use cooki= e-based authentication is likely going to punch a hole in most CSRF defense= s, which assume that GETs are safe. The only thing preventing this being ex= ploitable is Cross-Origin Read Blocking (https://chromium.googlesource.= com/chromium/src/+/master/services/network/cross_origin_read_blocking_expla= iner.md) due to the JSON content-type. That makes me really nervous. We= should at least mandate X-Content-Type-Options: nosniff on that response. = I=E2=80=99d feel more comfortable if this was a POST request only. 
=E2=80=94 Neil

<= /div>

CONFIDENTIALITY NOTICE: = This email may contain confidential and privileged material for the sole us= e of the intended recipient(s). Any review, use, distribution or disclosure= by others is strictly prohibited.  If you have received this communic= ation in error, please notify the sender immediately by e-mail and delete t= he message and any file attachments from your computer. Thank you.


ForgeRock values your Privacy --Apple-Mail=_E04D6C09-F3E2-4EB4-A150-D4E8E3A339D2-- From nobody Thu Feb 18 04:25:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBE23A1171 for ; Thu, 18 Feb 2021 04:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=oPvXI03G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qwr1kSiG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbDE5Mv-GytP for ; Thu, 18 Feb 2021 04:25:47 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB763A1172 for ; Thu, 18 Feb 2021 04:25:47 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4E0A48EF; Thu, 18 Feb 2021 07:25:44 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 18 Feb 2021 07:25:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=IB/ispCCI9wqX793WUBvkPJaLpWCIVlYrTwA3ogn/ms=; b=oPvXI03GPkBr WoCqccRECYuEufqjUM8T3zzwnJ247u0Pa9djyb7ZcDtRgvb399sW83mw2H4XqVNX Pjk2AVxqpgwr0HsHabwNztzYQXDWotExBlUOE4RCsz9zPoEe17wJ4aftbop6yFq6 QYfUWxX38xvEwx4XuFbIwBJPO52AEJchsZaHA0HAmmdhN2J2jKeqz7CT9Y8QaUnW K3EZ1Hp/Hu4F3ZGM2DH9LfO01fiyxVYhC/YFPL5sWxBxYPRwt9kyt8atTPq/1EoG Top0gJo3ZteZxy43laEpZdYh0PJVP0clnD8gQoplhkT0aCa3afKCTxNlzmku1XLt vCS1mp4fhg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=IB/isp CCI9wqX793WUBvkPJaLpWCIVlYrTwA3ogn/ms=; b=qwr1kSiGencwssHRfqP5fa rF4BflDbyihtFKi+/ZVkJqTgduEBdc376SC5eTHdsCyqwYn1fl69R/xAzKVt2Yt6 1pDEcZCtpUi7ZRsdwehN1k5KdnwysNkeq7sSE+75fsm6tcuVGztvgnKBrD9Op5B3 IU+78B+Eu6HjZAfWeiKOAWdhFbPD/L8VBUG8qVcWJO9NhfRRmjLU4C/j08PV0FQf Op9AW5lwLecSZGvZPzUD8ENlHms3fJgDMw3HFC68fwk5+9bGju8QHJNrQBWsD6PV dpfN0J9Yp656YFiXrdiYQHhvCKbr8F7WxuT6VgaUK50CqzuFRmoDbuWjZ/fTrO6Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjeeggdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhlihhp phgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvg gtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhepteelhfeghfevgfffjeefieeu geevffelleegtefgvdehudfhtdehvdethfdvgeeknecuffhomhgrihhnpehprhgrghhmrg htihgtfigvsghsvggtuhhrihhthidrtghomhenucfkphepkedurdduieegrdduvdelrdel heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphh hilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhm X-ME-Proxy: Received: from [192.168.1.10] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 5ECA3108005B; Thu, 18 Feb 2021 07:25:42 -0500 (EST) From: Philippe De Ryck Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EF7BB4D9-6385-4ED2-9D26-6E3CBFED946E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 13:25:40 +0100 In-Reply-To: <35645BCD-A9F5-4A57-9771-836647F08444@forgerock.com> Cc: Brian Campbell , Vittorio Bertocci , oauth To: Neil Madden References: <35645BCD-A9F5-4A57-9771-836647F08444@forgerock.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 12:25:49 -0000 --Apple-Mail=_EF7BB4D9-6385-4ED2-9D26-6E3CBFED946E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Feb 2021, at 13:08, Neil Madden = wrote: >=20 > Thanks for following up, Brian. Responses below. >=20 >> On 17 Feb 2021, at 22:48, Brian Campbell > wrote: >>=20 >> Always appreciate (and often learn from) your insights, Neil. I'd = like to dig into the CSRF thing a bit more though to understand better = and hopefully do the right thing in the draft.=20 >>=20 >> It seems to me that a GET at the bff-token endpoint is "safe" in that = it's effectively just a read.=20 >=20 > Well it=E2=80=99s a read that returns an access token. It=E2=80=99s = =E2=80=9Csafe=E2=80=9D in the sense of side-effects, but we absolutely = want to preserve the confidentiality of what is returned and only allow = it to be accessed by authorized clients (the legitimate frontend). At = the moment the only thing keeping that safe is the JSON content type. = For example, imagine a world in which the token-bff endpoint instead = returned the access token as HTML: >=20 >
abcd
>=20 > Then as an attacker I can simply embed an iframe on my site that = refers to your bff-endpoint and then parse the access token out of the = DOM. The browser will happily load that iframe and send along the cookie = when it makes the request. You are overlooking basic browser security measures like the Same-Origin = Policy here. The browser will only allow access to an iframe if it has = the same origin as the context accessing the frame. If an attacker = embeds this frame in their site, it will be a cross-origin frame, and = access will be denied. FYI, simple CORS requests follow the same security pattern (when headers = are missing, browsers do not expose the response). Preflighted CORS = requests cover "new features" (i.e., stuff you traditionally could not = do with HTML elements) and ask permission before sending a request.=20 Also, if you're worried about framing, it's much simpler to require the = token endpoint to send "X-Frame-Options: DENY" and = "Content-Security-Policy: frame-ancestors 'none'" response headers. This = denies framing altogether without going into complicated CORS territory. Philippe =E2=80=94 Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com/= --Apple-Mail=_EF7BB4D9-6385-4ED2-9D26-6E3CBFED946E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Feb 2021, at 13:08, Neil = Madden <neil.madden@forgerock.com> wrote:

Thanks for following up, Brian. = Responses below.

On 17 Feb 2021, at 22:48, Brian = Campbell <bcampbell@pingidentity.com> wrote:

Always appreciate (and often learn from) your = insights, Neil. I'd like to dig into the CSRF thing a bit more though to = understand better and hopefully do the right thing in the draft. 

It seems to me that a = GET at the bff-token endpoint is "safe" in that it's effectively just a = read. 

Well it=E2=80=99s = a read that returns an access token. It=E2=80=99s =E2=80=9Csafe=E2=80=9D = in the sense of side-effects, but we absolutely want to preserve the = confidentiality of what is returned and only allow it to be accessed by = authorized clients (the legitimate frontend). At the moment the only = thing keeping that safe is the JSON content type. For example, imagine a = world in which the token-bff endpoint instead returned the access token = as HTML:

<div= id=3D=E2=80=9CaccessToken=E2=80=9D>abcd</div>

Then as an attacker I = can simply embed an iframe on my site that refers to your bff-endpoint = and then parse the access token out of the DOM. The browser will happily = load that iframe and send along the cookie when it makes the request. =

You are = overlooking basic browser security measures like the Same-Origin Policy = here. The browser will only = allow access to an iframe if it has the same origin as the context = accessing the frame. = If an attacker embeds this frame in their site, it will be a = cross-origin frame, and access will be denied.

FYI, simple CORS requests follow the same = security pattern (when headers are missing, browsers do not expose = the response). Preflighted CORS requests cover "new features" (i.e., = stuff you traditionally could not do with HTML elements) and ask = permission before sending a request. 

Also, if you're worried about framing, it's much = simpler to require the token endpoint to send "X-Frame-Options: DENY" = and "Content-Security-Policy: frame-ancestors 'none'" response headers. = This denies framing altogether without going into complicated CORS = territory.

Philippe

=E2=80=94
Pragmatic Web = Security
Security for developers
https://pragmaticwebsecurity.com/
= --Apple-Mail=_EF7BB4D9-6385-4ED2-9D26-6E3CBFED946E-- From nobody Thu Feb 18 04:26:43 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86233A119D for ; Thu, 18 Feb 2021 04:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynTsnfteZKdS for ; Thu, 18 Feb 2021 04:26:31 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB783A1184 for ; Thu, 18 Feb 2021 04:26:30 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id v30so6280895lfq.6 for ; Thu, 18 Feb 2021 04:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/2JItpg9CXDAq7uPDV428S4FVrDb+RboK0v3La1tHi4=; b=pa4skQxx4tZujh7G4QGk454wbUljQhktW/s0zktYoZq5YgbC7NdxluJkB/euf6/k0a MtFVVsDVGsXg7Z2zxrae4riaAmH3+EC+Oe4uXjg0TBK45+Un1Gq76poTnjkBFYXR+lAs 5FHgWNyq+m7NOV9Iy8UUt2LvtFpT7BPdp1H4EC+oFYX5RFel1MBMq9nBU/d5qAdHp3B/ QFMDsDDkhE9KUPVxWAkGwzjxyKUxdNLSSJa81mgAhHPeuKKEBMh39rLvB4AP5iqzv6XO A+DsUz3REP2xZ8Qp8lhl3+2RaQIPpq7VQG20vj848MAZRhoTxk0gzylbm6pDOfMxOaKA F/SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/2JItpg9CXDAq7uPDV428S4FVrDb+RboK0v3La1tHi4=; b=optfNL88SW9RueovutpeS42qa46ah0GrYUtasArBmUHjQb0ImKli0ALhKzCWvEVp4Q peGlWdV7qMff29S4RhE50vSANDOS+41GKwrT5FGNQ6trAINxIun5lD6FoumDUjNjfJOj PHfavJ3BKDXPIFBJg4PH9/dUz+fRXuy4zPNtxR0Z8Ob384uL6XxqP6WCnaFv7Ll4KRBC m0LhGNlWRvUw3zPa4fn6aJsfCuagoiaqc7qjtZXfiIBOfqMW2ws13+/mZiN9dkUfQHuW nU6/q2QEfftTIq3ZkYO1Hm+rbSAi2HbmFCTV1l1zkNWevm0FkvMMDQPJJh3OMEOQZHMA vavA== X-Gm-Message-State: AOAM532zfRK1f0Km/qoANsNhF0nuv5gTzYBi+mVHxNYPHkhKQ+qRJ1Sq 1JwVFVKvkwF29zRn+C1Pw5YR8MMLUuhYH6j+mK21h7NYwHAw6g== X-Google-Smtp-Source: ABdhPJydS8JjEnixEEvPKdFz+0rxmBZG4Fd5YrDCmLDQVcDyvRmapneXDxvFXjptieBZaedJllnRYwofBgs1gsCiXCU= X-Received: by 2002:a05:6512:1054:: with SMTP id c20mr1994849lfb.170.1613651188929; Thu, 18 Feb 2021 04:26:28 -0800 (PST) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Thu, 18 Feb 2021 07:26:17 -0500 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000e8594e05bb9b7169" Archived-At: Subject: [OAUTH-WG] Multi-Subject JWT (aka Nested JWT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 12:26:42 -0000 --000000000000e8594e05bb9b7169 Content-Type: text/plain; charset="UTF-8" When I started working on the Nested JWT draft, I had a specific use case in mind (I no longer care about that initial use case). https://www.ietf.org/archive/id/draft-yusef-oauth-nested-jwt-03.txt I then dropped the ball on the Nested JWT draft, but every now and then I get some feedback, mainly offline, from different people about more use cases that clearly indicate that there is a need for a way to represent multiple subjects in one JWT. The following is a high level summary of these use cases: 1. Primary subject with secondary authority subject A primary subject with a related secondary subject that has authority over the primary subject, e.g. Child/Parent, Pet/Owner. In this case, both JWTs would be issued by the same issuer. 1. Delegation of authority A primary subject delegates authority over a resource to a secondary subject who acts on behalf of the primary subject. https://tools.ietf.org/html/rfc8693 In this case, both JWTs would be issued by the same issuer. 1. Multiple primary subjects Two primary related subjects e.g. a married couple https://www.w3.org/TR/vc-data-model/#credential-subject In this case, both JWTs would be issued by the same issuer. 1. Replaced primary subject A primary subject becomes a secondary subject and replaced with a new primary subject. For example, - An original called number replaced with a retargeted number. https://tools.ietf.org/html/draft-ietf-stir-passport-divert-09 - A number of network intermediaries that each become the primary subject when receiving a message from a previous network element. https://networkservicemesh.io/ In this case, the original JWT would be issued by one issuer and included as a nested JWT, while the enclosing JWT would be issued by a new issuer that has manipulated the original received message. 1. Supporting JWTs One primary JWT with supporting JWT https://github.com/martinpaljak/jose/blob/main/README.md *Question*: Is the WG interested in working on such a mechanism? If yes, are there any more use cases that need to be addressed? Are there use cases that require more than two subjects? Regards, Rifaat (no hats) --000000000000e8594e05bb9b7169 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When I started working on= the Nested JWT draft, I had a specific use case in mind (I no longer care = about that initial use case).=C2=A0

I then dropped the ball on the Nested JWT draft, = but every now and then I get some feedback, mainly offline, from different = people about more use cases that clearly indicate that there is a need for = a way to represent multiple subjects in one JWT.

The following is a high level summary of these use cases:
<= div>

  1. Primary= subject with secondary authority subject

A primary subject with a related secondary subject that= has authority over the primary subject, e.g. Child/Parent, Pet/Owner.

In this case, both JWTs would be iss= ued by the same issuer.


  1. Delegat= ion of authority

A pri= mary subject delegates authority over a resource to a secondary subject who= acts on behalf of the primary subject.=C2=A0

https://tools.ietf.org/html/rfc8693

In this case, both JWTs would = be issued by the same issuer.


  1. Mul= tiple primary subjects

Two primary related subjects e.g. a married couple

https://www.= w3.org/TR/vc-data-model/#credential-subject

= In this case, both JWTs would be issued by the same issuer.=


    <= li dir=3D"ltr" style=3D"list-style-type:decimal;color:rgb(0,0,0);background= -color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm= al;vertical-align:baseline;white-space:pre">

    Replaced primary subject<= /p>

A primary subject becomes a s= econdary subject and replaced with a new primary subject.


For example,=C2=A0

  • An original called number replaced with a retargeted number.<= /span>

https://tools.ietf.org/html/dr= aft-ietf-stir-passport-divert-09


  • A number of network intermediaries that each become the primary subje= ct when receiving a message from a previous network element.=C2=A0

https://networkservicemesh.io/


In this case, the original JWT would be issued by one issuer a= nd included as a nested JWT, while the enclosing JWT would be issued by a n= ew issuer that has manipulated the original received message.

  1. Supporting JWTs

One primary JWT with supporting JWT

http= s://github.com/martinpaljak/jose/blob/main/README.md

<= br class=3D"gmail-Apple-interchange-newline">

Question:=C2= =A0
Is the WG interes= ted in working on such a mechanism?
If yes, are there any more use cases that need to be addressed?<= /font>
Are there use cases that = require more than two subjects?

Regards,
=C2=A0Rifaat (no hats)=




--000000000000e8594e05bb9b7169-- From nobody Thu Feb 18 06:02:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E313A1269 for ; Thu, 18 Feb 2021 06:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwaoij7RoFpx for ; Thu, 18 Feb 2021 06:02:50 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAF23A1234 for ; Thu, 18 Feb 2021 06:02:50 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id f7so1950909wrt.12 for ; Thu, 18 Feb 2021 06:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=A/eIh3soKpIC18wTBJfeZq737+bZID0ugC/5CMlhI0Y=; b=LC3kZrEg2Io6nTS4F/inDymoZnuiYuvM0v+wMk4lCv0Jtk1daOoQizhHjY27Bhr2f4 pNmvg38nh59a0KhdglQ0w0IXdfPgblBcQQp2c/PuQWnE6muiALypIbWjZtHL98VMsrOO oRhDAfJj2bV1wu3tBYBa1ReSfeq4EKViLKcos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=A/eIh3soKpIC18wTBJfeZq737+bZID0ugC/5CMlhI0Y=; b=Xul3zK212rGv5JTYHQcCin/BeAKtHk51Ec2NeJR8EC2ynj7lPqMxfk4FoDMT2zh+Fi BlycVq1dk4ynGFPjCGqkrF3IU/3Sy2TRonLKlS/z/KUKqZ693AYYlmGXQXGu/mkbdNNX QKIC4e8XCJUCSdl2akwl4ksB2w3GQw/nWOXgHKh0pYzVgZ3U8oUYQqT5C5W/pyBS2wvN knu8Do/bh03DMERV08ZLIj2oCIaNu2oN67OYFfsVzKK5JqRWXV+q+kMA/G1GvqzNYZoc DRqaN1F6sA4xpJ6qo5q7Y8f/3a9ThA36ZdCMUoSceo2rbnyjj+xRkpPQvSd3YrR3K2co mbuQ== X-Gm-Message-State: AOAM532+9ViqTPHI0DfSUHj6v9eClC9F0jV8t4fyqgu3r7s6R6Yivwql KzoUGhtvhR7mBQH0tNPARqLygnrGV1tFquiYKioGlu0nL5EbPTOOQBCSBHSE40LnCZWCD/cpUc0 4boP76qSiKRbonTW4EepxUswYvHq4JbdIkxCVP4YyTS9YVYJgTmfNRav9haBMxEZoMQ== X-Google-Smtp-Source: ABdhPJy63WeNMkm0f6uRkUzZNs5OKXNhElecDst/WzNqXBBX/hKMawc0Gc/MDgWSpJ862gvwnc+LBw== X-Received: by 2002:adf:e809:: with SMTP id o9mr4482492wrm.137.1613656968305; Thu, 18 Feb 2021 06:02:48 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id y4sm2753927wrs.66.2021.02.18.06.02.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Feb 2021 06:02:47 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Thu, 18 Feb 2021 14:02:42 +0000 Message-Id: <29DF02C6-60E5-4FCC-9671-BED7B5145BA1@forgerock.com> References: Cc: Brian Campbell , Vittorio Bertocci , oauth In-Reply-To: To: Philippe De Ryck X-Mailer: iPhone Mail (18D52) Content-Type: multipart/alternative; boundary=Apple-Mail-1126639C-0400-447A-8519-6B296CDA34A5 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 14:02:53 -0000 --Apple-Mail-1126639C-0400-447A-8519-6B296CDA34A5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > On 18 Feb 2021, at 12:25, Philippe De Ryck wrote: >=20 >> On 18 Feb 2021, at 13:08, Neil Madden wrote: >>=20 >> Thanks for following up, Brian. Responses below. >>=20 >>> On 17 Feb 2021, at 22:48, Brian Campbell w= rote: >>>=20 >>> Always appreciate (and often learn from) your insights, Neil. I'd like = to dig into the CSRF thing a bit more though to understand better and hopef= ully do the right thing in the draft.=20 >>>=20 >>> It seems to me that a GET at the bff-token endpoint is "safe" in that i= t's effectively just a read.=20 >>=20 >> Well it=E2=80=99s a read that returns an access token. It=E2=80=99s =E2= =80=9Csafe=E2=80=9D in the sense of side-effects, but we absolutely want to= preserve the confidentiality of what is returned and only allow it to be a= ccessed by authorized clients (the legitimate frontend). At the moment the = only thing keeping that safe is the JSON content type. For example, imagine= a world in which the token-bff endpoint instead returned the access token = as HTML: >>=20 >>
abcd
>>=20 >> Then as an attacker I can simply embed an iframe on my site that refers = to your bff-endpoint and then parse the access token out of the DOM. The br= owser will happily load that iframe and send along the cookie when it makes= the request. >=20 > You are overlooking basic browser security measures like the Same-Origin = Policy here. The browser will only allow access to an iframe if it has the = same origin as the context accessing the frame. If an attacker embeds this = frame in their site, it will be a cross-origin frame, and access will be de= nied. Right, HTML was a bad example. But again remember that at this point the co= ntent is already loaded into the renderer process and so vulnerable to Spec= tre and other side-channel attacks.=20 As MDN says (https://developer.mozilla.org/en-US/docs/Web/Security/Same-ori= gin_policy): =E2=80=9CTo prevent cross-origin reads of a resource, ensure that it is not= embeddable. It is often necessary to prevent embedding because embedding a= resource always leaks some information about it.=E2=80=9D My point is that the server is performing essentially no real security chec= ks and relying on the user-agent for pretty much all security guarantees. T= his is ok when those mechanisms are robust, but they really aren=E2=80=99t = in the case of embeddable resources and browser vendors are still trying to= close all the holes.=20 >=20 > FYI, simple CORS requests follow the same security pattern (when headers = are missing, browsers do not expose the response). But many sites already return those CORS headers to enable cross-origin fun= ctionality. On those sites bff-token is completely insecure because cross-o= rigin clients can now use that access to get an access token intended for t= he first-party SPA and use it to access other APIs! I can=E2=80=99t emphasi= se enough how much of a security disaster this could be.=20 > Preflighted CORS requests cover "new features" (i.e., stuff you tradition= ally could not do with HTML elements) and ask permission before sending a r= equest.=20 But GET requests don=E2=80=99t trigger preflight unless they have custom he= aders. > Also, if you're worried about framing, it's much simpler to require the t= oken endpoint to send "X-Frame-Options: DENY" and "Content-Security-Policy:= frame-ancestors 'none'" response headers. This denies framing altogether w= ithout going into complicated CORS territory. You=E2=80=99re pretty much entirely missing the point of my message if you = think it=E2=80=99s about framing specifically. Think of all the possible wa= ys there are to embed cross-origin resources: CSS stylesheets, script embed= ding, images, video, audio, fonts, WebGL textures, objects, etc. If a new e= ndpoint requires setting 15 new CSP policies just to make it not obviously = insecure, it=E2=80=99s maybe a clue that it=E2=80=99s not a sensible design= .=20 To say that we=E2=80=99re not comfortable with tokens in localStorage but t= o then expose a simple GET endpoint for retrieving access tokens is IMO not= a good idea. The SOP protections applied to localStorage are *far* more ro= bust than those applied to GET requests.=20 =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail-1126639C-0400-447A-8519-6B296CDA34A5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 18 Feb 2021, at 12:25, Philippe De Ryck &= lt;philippe@pragmaticwebsecurity.com> wrote:

<= blockquote type=3D"cite">
On 18 Feb 2021, at 13:08, Neil Mad= den <neil.madden= @forgerock.com> wrote:

=
Thanks for following up, Brian. Responses below.

= On 17 Feb 2021, at 22:48, Brian Campbell <bcampbell@pingidentity.com> wrote:
<= br class=3D"Apple-interchange-newline">
Always appreciate (and often learn from) your insig= hts, Neil. I'd like to dig into the CSRF thing a bit more though to underst= and better and hopefully do the right thing in the draft. 

It seems to me that a GET at the bff-token = endpoint is "safe" in that it's effectively just a read. 

Well it=E2=80=99s a read that re= turns an access token. It=E2=80=99s =E2=80=9Csafe=E2=80=9D in the sense of = side-effects, but we absolutely want to preserve the confidentiality of wha= t is returned and only allow it to be accessed by authorized clients (the l= egitimate frontend). At the moment the only thing keeping that safe is the = JSON content type. For example, imagine a world in which the token-bff endp= oint instead returned the access token as HTML:

<div id=3D=E2=80=9CaccessToken=E2=80=9D&g= t;abcd</div>

Then as an attacker I can simply embed an iframe on my site that refers t= o your bff-endpoint and then parse the access token out of the DOM. The bro= wser will happily load that iframe and send along the cookie when it makes = the request.

= You are overlooking basic browser security measures like the Same-Origin Po= licy here. The browser will only= allow access to an iframe if it has the same origin as the context accessi= ng the frame. If an atta= cker embeds this frame in their site, it will be a cross-origin frame, and = access will be denied.

=
Right, HTML was a bad example. But again remember that at this p= oint the content is already loaded into the renderer process and so vulnera= ble to Spectre and other side-channel attacks. 

As MDN says (https://developer.mozilla.org/en-US/docs/Web/Secu= rity/Same-origin_policy):

=E2=80=9CTo prevent cross-origin reads = of a resource, ensure that it is not embeddable. It is often necessary to p= revent embedding because embedding a resource always leaks some information= about it.=E2=80=9D

My point is that the se= rver is performing essentially no real security checks and relying on the u= ser-agent for pretty much all security guarantees. This is ok when those me= chanisms are robust, but they really aren=E2=80=99t in the case of embeddab= le resources and browser vendors are still trying to close all the holes.&n= bsp;


FYI, simple CORS requests follow the same security pattern (wh= en headers are missing, browsers do not expose the response).

But many sites already retu= rn those CORS headers to enable cross-origin functionality. On those sites = bff-token is completely insecure because cross-origin clients can now use t= hat access to get an access token intended for the first-party SPA and use = it to access other APIs! I can=E2=80=99t emphasise enough how much of a sec= urity disaster this could be. 

Preflighted CORS requests= cover "new features" (i.e., stuff you traditionally could not do with HTML= elements) and ask permission before sending a request. 

But GET requests don=E2=80=99t t= rigger preflight unless they have custom headers.

Also, if you're worried about fr= aming, it's much simpler to require the token endpoint to send "X-Frame-Opt= ions: DENY" and "Content-Security-Policy: frame-ancestors 'none'" response = headers. This denies framing altogether without going into complicated CORS= territory.

You=E2=80=99re pret= ty much entirely missing the point of my message if you think it=E2=80=99s = about framing specifically. Think of all the possible ways there are to emb= ed cross-origin resources: CSS stylesheets, script embedding, images, video= , audio, fonts, WebGL textures, objects, etc. If a new endpoint requires se= tting 15 new CSP policies just to make it not obviously insecure, it=E2=80= =99s maybe a clue that it=E2=80=99s not a sensible design. 
=
To say that we=E2=80=99re not comfortable with tokens in loc= alStorage but to then expose a simple GET endpoint for retrieving access to= kens is IMO not a good idea. The SOP protections applied to localStorage ar= e *far* more robust than those applied to GET requests. 
=E2=80=94 Neil
=

ForgeRock values your Privacy --Apple-Mail-1126639C-0400-447A-8519-6B296CDA34A5-- From nobody Thu Feb 18 08:42:49 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D71B3A142D; Thu, 18 Feb 2021 08:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px4XJsC3tY2o; Thu, 18 Feb 2021 08:42:44 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02593A142C; Thu, 18 Feb 2021 08:42:43 -0800 (PST) Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11IGgd1B026920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Feb 2021 11:42:40 -0500 From: Justin Richer Message-Id: <09D9F690-52F6-4D6F-9F5F-EF9B1D64CF7D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2C675989-7971-44B4-83B9-FBC48503219F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 11:42:39 -0500 In-Reply-To: Cc: Vladimir Dzhuvinov , oauth To: Brian Campbell References: <97a82c6d-1410-a9a9-a7aa-e8cff61a1807@connect2id.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [OAUTH-WG] Authorization Header Encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 16:42:47 -0000 --Apple-Mail=_2C675989-7971-44B4-83B9-FBC48503219F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The issue was whether to remove the token68 portion and just use = auth-param as part of the syntax, as far as I know. Bearer goes a little = off from even the draft spec and admits as much in place. If we can = improve the definition in 2.1, or at least make it clearer what=E2=80=99s = expected, then I think that=E2=80=99s better. I=E2=80=99ll guarantee you = that developers aren=E2=80=99t following =E2=80=9Ctoken68=E2=80=9D = syntax in practice when making Bearer headers. =E2=80=94 Justin > On Feb 17, 2021, at 6:35 PM, Brian Campbell = wrote: >=20 > AFAIK the character set for the "Bearer" scheme in RFC6750 is what it = is to align with the token68 part of "credentials =3D auth-scheme [ 1*SP = ( token68 / #auth-param ) ]" from = https://tools.ietf.org/html/rfc7235#section-2.1 = (the draft that would = become RFC7235 is referenced by RFC6750 in = https://tools.ietf.org/html/rfc6750#section-2.1 = where it says = basically as much).=20 >=20 > Also it looks like https://github.com/httpwg/http-core/issues/733 = was closed with no = action.=20 >=20 > So I don't see what change would be made in OAuth 2.1 or elsewhere. = Nor does it seem like any change is needed or appropriate. =20 >=20 > On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov = > wrote: > Hi Justin, >=20 > Thanks for alerting us on this development. >=20 > +1 for keeping the updated HTTP semantics unencumbered by the = Authorization header formatting in RFC 6750. >=20 > IMO revising the RFC 6750 to reflect that is too late now, as few = people will notice. So updating the Bearer header definition in OAuth = 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers = who maintain their software to pick up the 2.1 spec, sooner or later. >=20 > Vladimir >=20 >=20 >=20 > On 12/02/2021 00:01, Justin Richer wrote: >> The HTTP Working Group opened an issue for discussion in relation to = the updated HTTP semantics specification. The core of the issue is the = format of the =E2=80=9CAuthorization=E2=80=9D header, which of course = gets used by the =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750. >>=20 >> https://github.com/httpwg/http-core/issues/733 = >>=20 >> As it turns out, Bearer defines a more limited character set than is = allowed by core HTTP, and doesn=E2=80=99t follow the HTTP guidelines and = definitions for the Authorization header. There were a few observations = on the call: >>=20 >> - The Bearer spec was limited because OAuth tokens were also allowed = in HTTP URLs and form parameters (and therefore had to have a more = limited character set) >> - In practice people don=E2=80=99t actually restrict the values they = put into this field; pretty much any implementation is just going to = concatenate whatever access token value they get to the magic word = =E2=80=9CBearer=E2=80=9D and send it >> - It=E2=80=99s not likely (or in my opinion proper) for the HTTP = spec to change to address the oddities of RFC6750 and decisions that = were made many years ago >>=20 >> So the question is, what do we do about it? We could do a revision of = 6750 that reflects reality better, pretty much just changing the ABNF. >>=20 >> Or, we could update the definition of the Bearer header in the = upcoming OAuth 2.1 specification. >>=20 >> Are there other options? >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > --=20 > Vladimir Dzhuvinov > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2C675989-7971-44B4-83B9-FBC48503219F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = issue was whether to remove the token68 portion and just use auth-param = as part of the syntax, as far as I know. Bearer goes a little off from = even the draft spec and admits as much in place. If we can improve the = definition in 2.1, or at least make it clearer what=E2=80=99s expected, = then I think that=E2=80=99s better. I=E2=80=99ll guarantee you that = developers aren=E2=80=99t following =E2=80=9Ctoken68=E2=80=9D syntax in = practice when making Bearer headers.

=E2=80=94 Justin

On Feb = 17, 2021, at 6:35 PM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> = wrote:

AFAIK the = character set for the "Bearer" scheme in RFC6750 is what it is to align = with the token68 part of "credentials =3D auth-scheme [ 1*SP ( token68 / = #auth-param ) ]" from https://tools.ietf.org/html/rfc7235#section-2.1 (the = draft that would become RFC7235 is referenced by RFC6750 in https://tools.ietf.org/html/rfc6750#section-2.1 where it = says basically as much).

Also it looks like https://github.com/httpwg/http-core/issues/733 was closed = with no action.

So I don't see what change would be = made in OAuth 2.1 or elsewhere. Nor does it seem like any change is = needed or appropriate. 

On Mon, Feb 15, 2021 at 4:34 AM Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:
=20 =20 =20

Hi Justin,

Thanks for = alerting us on this development.

+1 for keeping the = updated HTTP semantics unencumbered by the Authorization header formatting in RFC 6750.

IMO = revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAuth 2.1 seems like the most sensible move. I expect OAuth 2.0 implementers who maintain their software to pick up the 2.1 spec, sooner or later.

Vladimir


On 12/02/2021 00:01, Justin Richer wrote:
=20 The HTTP Working Group opened an issue for discussion in relation to the updated HTTP semantics specification. The core of the issue is the format of the =E2=80=9CAuthorization=E2=80=9D header, which = of course gets used by the =E2=80=9CBearer=E2=80=9D scheme defined in RFC6750.

https://github.com/httpwg/http-core/issues/733

As it turns out, Bearer defines a more limited character set than is allowed by core HTTP, and doesn=E2=80=99t = follow the HTTP guidelines and definitions for the Authorization header. There were a few observations on the call:

 - The Bearer spec was limited because OAuth = tokens were also allowed in HTTP URLs and form parameters (and therefore had to have a more limited character set)
 - In practice people don=E2=80=99t actually = restrict the values they put into this field; pretty much any implementation is just going to concatenate whatever access token value they get to the magic word =E2=80=9CBearer=E2=80=9D and send it
 - It=E2=80=99s not likely (or in my opinion = proper) for the HTTP spec to change to address the oddities of RFC6750 and decisions that were made many years ago

So the question is, what do we do about it? We = could do a revision of 6750 that reflects reality better, pretty much just changing the ABNF.

Or, we could update the definition of the Bearer header in the upcoming OAuth 2.1 specification.

Are there other options?

 =E2=80=94 Justin


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

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

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_2C675989-7971-44B4-83B9-FBC48503219F-- From nobody Fri Feb 19 09:16:54 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFF13A121B; Fri, 19 Feb 2021 09:16:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161375501326.27975.16934315947737150589@ietfa.amsl.com> Date: Fri, 19 Feb 2021 09:16:53 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-03-15 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:16:53 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-03-15 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: DPoP https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Fri Feb 19 09:17:32 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D3D3A1220; Fri, 19 Feb 2021 09:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161375503381.30505.4504565248241155826@ietfa.amsl.com> Date: Fri, 19 Feb 2021 09:17:13 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-03-22 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:17:20 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-03-22 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: OAuth 2.1 https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Fri Feb 19 09:18:37 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7406E3A1395; Fri, 19 Feb 2021 09:18:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161375510944.29021.18120356216747770315@ietfa.amsl.com> Date: Fri, 19 Feb 2021 09:18:29 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-03-29 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:18:36 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-03-29 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: TMI BFF https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Fri Feb 19 09:19:02 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 886FE3A128B; Fri, 19 Feb 2021 09:18:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161375512952.21792.16386134449832371643@ietfa.amsl.com> Date: Fri, 19 Feb 2021 09:18:49 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-04-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:18:55 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-04-05 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: RAR https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Fri Feb 19 09:19:12 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 308C73A1428; Fri, 19 Feb 2021 09:19:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161375514517.29993.10965264955551379408@ietfa.amsl.com> Date: Fri, 19 Feb 2021 09:19:05 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-04-12 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:19:11 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-04-12 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: Security BCP https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Fri Feb 19 09:19:28 2021 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 600E53A13C3; Fri, 19 Feb 2021 09:19:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161375515735.30159.6367320377498612705@ietfa.amsl.com> Date: Fri, 19 Feb 2021 09:19:17 -0800 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-04-19 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:19:24 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-04-19 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: Identity Use Cases in Browser https://datatracker.ietf.org/doc/html/draft-bertocci-identity-in-browser-00 Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b From nobody Fri Feb 19 10:25:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8623A12E2 for ; Fri, 19 Feb 2021 10:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0mvodhn_JjM for ; Fri, 19 Feb 2021 10:24:59 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F0C3A12DE for ; Fri, 19 Feb 2021 10:24:58 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id r23so25099513ljh.1 for ; Fri, 19 Feb 2021 10:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vHw/CxHgN2oXyscuXx+bqpDVMX2VCqbQpHlFwrunCFc=; b=RvQnK9JvJlxBm2Y70U1+TtzuBOPkfTaUunZh/ILKAKzNYLzKb1A0SLOjMDhEjUvQWD ePePPv+o0Q8RSzJ5xnTSC+vJN4HuUpQblpe/8VNvzt1dhwTCg3n1g059wXox4vr31hot 3vq9Lk5xtKHzOWqi5/zr9PWg9oy0+VamF7n38yni4KZkWYjRfaTeL5hGRgSIZDsOzj8W M8pXekHejwOyrTpOZFO/wCjDgRQOswRjs5dxzyruISL7JCTEMzrXFzVFtIE8dJ1HGxOu PINQzY+mAXmhyZlcUQJoVWK8zLhLCPsQnYwYTEf/ubssK+BvnZqp1hlSTjrq8Rdl4Y4p //GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vHw/CxHgN2oXyscuXx+bqpDVMX2VCqbQpHlFwrunCFc=; b=FZyVXiLj9IPC75r+hoY3ApgCcXk0V9Fif/e4DeFBHEuYyjTXExc6wInYt50XiiDeYd RbKh3cp4eYw1pTD8vz/V2VU6GuzfKXLCWjDjz+nfafWdk21gIxpuWusb3agT5fsPAlDC ZewgSmb5IgRwe6TtR2SqQwahCoo92LbiJMYNMZeOYpEm5gPJceq0kraaQAEtV0mnEqw5 CyzIeEVYEnNVK68c/ERYwF53aUOxjvf5YK/x1WZLY5fWquzb8AHsnMQEXuucE9foZC4l tsfPOckiJBHCbtdfsdhPXF/sP5+vETIT6RFg9D6lsoHMvGwoU3esVRmfh8W9h0bOn9/I 9p4w== X-Gm-Message-State: AOAM530+w91G+VeMq5mxllY5RMi+YeikcouCks+Vmx7c9t4ydQkUYKZ7 KKMfjuO7w65LWSii54ggtMjU5wdmlkjWraUsdlzEsnSv8b4= X-Google-Smtp-Source: ABdhPJySK1PZauPEu3E6GrqdkFHvgrk7UyZeSOq3Ovz+CjcF/R4apuP3C9rpLZOIdl86y6173Id8kLAQnYSnuX/s0a0= X-Received: by 2002:a05:6512:1054:: with SMTP id c20mr5850919lfb.170.1613759096031; Fri, 19 Feb 2021 10:24:56 -0800 (PST) MIME-Version: 1.0 References: <41295701.7314411613743122951.JavaMail.nobody@rva2rmd102.webex.com> In-Reply-To: <41295701.7314411613743122951.JavaMail.nobody@rva2rmd102.webex.com> From: Rifaat Shekh-Yusef Date: Fri, 19 Feb 2021 13:24:44 -0500 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="000000000000ac3e7805bbb49193" Archived-At: Subject: [OAUTH-WG] Fwd: (Forward to others) Webex meeting invitation: OAuth WG Interims X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 18:25:01 -0000 --000000000000ac3e7805bbb49193 Content-Type: multipart/alternative; boundary="000000000000ac3e7505bbb49191" --000000000000ac3e7505bbb49191 Content-Type: text/plain; charset="UTF-8" Following are the Webex meeting details for our upcoming 6 interim meetings, starting March 15th. Regards, Rifaat ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Fri, Feb 19, 2021 at 8:58 AM Subject: (Forward to others) Webex meeting invitation: OAuth WG Interims To: You can forward this invitation to others. Web Authorization Protocol Working Group is inviting you to a scheduled Webex meeting. Occurs every Monday effective Monday, March 15, 2021 until Monday, April 19, 2021 from 12:00 PM to 1:00 PM, (UTC-05:00) Eastern Time (US & Canada) 12:00 PM | (UTC-05:00) Eastern Time (US & Canada) | 1 hr Join meeting *More ways to join:* *Join from the meeting link* https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b *Join by meeting number* Meeting number (access code): 185 067 2252 Meeting password: nCgm6qTjH45 *Tap to join from a mobile device (attendees only)* +1-650-479-3208,,1850672252## <%2B1-650-479-3208,,*01*1850672252%23%23*01*> Call-in toll number (US/Canada) *Join by phone* 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers *Join from a video system or application* Dial 1850672252@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. *Join using Microsoft Lync or Microsoft Skype for Business* Dial 1850672252.ietf@lync.webex.com Need help? Go to https://help.webex.com --000000000000ac3e7505bbb49191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following are the Webex meeting details for our upcoming 6= interim meetings,=C2=A0starting March 15th.

Regards,
=C2=A0Rifaat


---------- Forwarded message ---------
Fro= m: Web Authorization Protoc= ol Working Group <messenger@webex.com>
Date: Fri, Feb 19, 2021 = at 8:58 AM
Subject: (Forward to others) Webex meeting invitation: OAuth = WG Interims
To: <oauth-chai= rs@ietf.org>


=C2=A0
=09
You can forward this invitation to others.

Web Authorization Protocol Working Group is inviting you to= a scheduled Webex meeting.
=C2= =A0
Occurs every Monday effective Monday, March 15, 2= 021 until Monday, April 19, 2021 from 12:00 PM to 1:00 PM, (UTC-05:00) East= ern Time (US & Canada)
12:00 PM=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05:00) East= ern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=C2=A0
Join meeting
=C2= =A0
More ways to join:
=C2=A0
Join from the meeting link<= /td>
ht= tps://ietf.webex.com/ietf/j.php?MTID=3Dm827c194bdcaa0077de44241f8001ce9b
=C2= =A0
Join by meeting number
Meeting number (access code): 185 067 2252
Meeting password: nCgm6qTjH45
=C2= =A0
=20
Tap to join from a mobile device = (attendees only)
+1-650-4= 79-3208,,1850672252## Call-in toll number (US/Canada)
=C2=A0
<= tr style=3D"margin:0px">=
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
Global call-in numbers
=C2= =A0
Dial 1850672252@ietf.webex= .com
Join = from a video system or application
You can also dial 173.243.2.6= 8 and enter your meeting number.
= =C2=A0
= =
Join using Microsoft Lync or Microsoft Sk= ype for Business
Dial 1850672252.ietf@lync.webex.com
=C2= =A0
=09
=C2=A0
Need help? Go to https://help.we= bex.com
=C2=A0
--000000000000ac3e7505bbb49191 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20210219T135842Z ATTENDEE;CN=3D"oauth";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:oauth-chair= s@ietf.org ORGANIZER;CN=3D"Web Authorization Protocol Working Group":MAILTO:oauth-chai= rs@ietf.org DTSTART;TZID=3DAmerica/New_York:20210315T120000 DTEND;TZID=3DAmerica/New_York:20210315T130000 LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm827c194bdcaa0077de44241f= 8001ce9b TRANSP:OPAQUE SEQUENCE:1613743122 UID:53db0ee3-46e3-46e3-a916-c2c449f93cf2 DESCRIPTION:\n\n\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php= ?MTID=3Dm827c194bdcaa0077de44241f8001ce9b\nMeeting number (access code): 18= 5 067 2252\n\nMeeting password: nCgm6qTjH45\n\n\n\nTAP TO JOIN FROM A MOBIL= E DEVICE (ATTENDEES ONLY)\n+1-650-479-3208,,1850672252## tel:%2B1-650-479-3= 208,,*01*1850672252%23%23*01* Call-in toll number (US/Canada)\n\n\nJOIN BY = PHONE\n1-650-479-3208 Call-in toll number (US/Canada)\n\nGlobal call-in num= bers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm77e918266bb065f3= aae029b765eb4c62\n\n\nJOIN FROM A VIDEO SYSTEM OR APPLICATION\nDial sip:185= 0672252@ietf.webex.com\nYou can also dial 173.243.2.68 and enter your meeti= ng number.\n\n\nJoin using Microsoft Lync or Microsoft Skype for Business\n= Dial sip:1850672252.ietf@lync.webex.com\n\n\n\n\n\nCan't join the meeting?\= nhttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIMPORTANT NO= TICE: Please note that this Webex service allows audio and other informatio= n sent during the session to be recorded, which may be discoverable in a le= gal matter. By joining this session, you automatically consent to such reco= rdings. If you do not consent to being recorded, discuss your concerns with= the host or do not join the session.\n X-ALT-DESC;FMTTYPE=3Dtext/html:\n\n\n \n \n \n \n\n SUMMARY:OAuth WG Interims PRIORITY:5 CLASS:PUBLIC RRULE:FREQ=3DWEEKLY;WKST=3DSU;UNTIL=3D20210419T120000Z;INTERVAL=3D1;BYDAY= =3DMO BEGIN:VALARM TRIGGER:-PT5M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --000000000000ac3e7505bbb49191-- --000000000000ac3e7805bbb49193 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <177bb87bc28c1ce7aee1> X-Attachment-Id: 177bb87bc28c1ce7aee1 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjEwMjE5 VDEzNTg0MloNCkFUVEVOREVFO0NOPSJvYXV0aCI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNWUD1U UlVFOk1BSUxUTzpvYXV0aC1jaGFpcnNAaWV0Zi5vcmcNCk9SR0FOSVpFUjtDTj0iV2ViIEF1dGhv cml6YXRpb24gUHJvdG9jb2wgV29ya2luZyBHcm91cCI6TUFJTFRPOm9hdXRoLWNoYWlyc0BpZXRm Lm9yZw0KRFRTVEFSVDtUWklEPUFtZXJpY2EvTmV3X1lvcms6MjAyMTAzMTVUMTIwMDAwDQpEVEVO RDtUWklEPUFtZXJpY2EvTmV3X1lvcms6MjAyMTAzMTVUMTMwMDAwDQpMT0NBVElPTjpodHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODI3YzE5NGJkY2FhMDA3N2RlNDQyNDFm ODAwMWNlOWINClRSQU5TUDpPUEFRVUUNClNFUVVFTkNFOjE2MTM3NDMxMjINClVJRDo1M2RiMGVl My00NmUzLTQ2ZTMtYTkxNi1jMmM0NDlmOTNjZjINCkRFU0NSSVBUSU9OOlxuXG5cblxuXG5KT0lO IFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04 MjdjMTk0YmRjYWEwMDc3ZGU0NDI0MWY4MDAxY2U5YlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBj b2RlKTogMTg1IDA2NyAyMjUyXG5cbk1lZXRpbmcgcGFzc3dvcmQ6IG5DZ202cVRqSDQ1XG5cblxu XG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9CSUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02 NTAtNDc5LTMyMDgsLDE4NTA2NzIyNTIjIyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoxODUw NjcyMjUyJTIzJTIzKjAxKiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cblxuSk9J TiBCWSBQSE9ORVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRh KVxuXG5HbG9iYWwgY2FsbC1pbiBudW1iZXJzXG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYv Z2xvYmFsY2FsbGluLnBocD9NVElEPW03N2U5MTgyNjZiYjA2NWYzYWFlMDI5Yjc2NWViNGM2Mlxu XG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MTg1 MDY3MjI1MkBpZXRmLndlYmV4LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFu ZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLlxuXG5cbkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5 bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzc1xuRGlhbCBzaXA6MTg1MDY3MjI1Mi5p ZXRmQGx5bmMud2ViZXguY29tXG5cblxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0 dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5c blxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2Ug YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLlxuDQpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0 ZXh0L2NzcyI+XG50YWJsZSB7XG4JYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEw MCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6 IDE4cHg7fVxuXG5hLCB0ZCB7XG4JZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7 CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJ cGFkZGluZzogMDt9XG5cbi50aXRsZSB7XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtc bgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYw NHB4O31cblxuLm1haW4ge1xuXG59QG1lZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6 IDgwMHB4KSB7XG4JLnRpdGxlIHtcbgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgku aW1hZ2Uge1xuCQl3aWR0aDogYXV0byAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBv cnRhbnQ7CX1cbgkuZm9vdGVyIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0 aDogNjA0cHggIWltcG9ydGFudFxuCX1cbgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRh bnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFi bGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVy OiAwOyB3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhw eCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9 InBhZGRpbmc6IDAgMjBweDsgbWFyZ2luOiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZG RkZGRiIgc3R5bGU9ImJvcmRlcjogMHB4OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4 OyBwYWRkaW5nLXJpZ2h0OiA1MHB4OyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8 dHI+XG4JCQkJCTx0ZCBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90 ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJ PHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9G T05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCTwvdGFibGU+XG4gICAgICAgIDx0YWJsZT5c biAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDph dXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDti YWNrZ3JvdW5kLWNvbG9yOiMwMDgyM0I7IGJvcmRlcjowcHggc29saWQgIzAwODIzQjsgYm9yZGVy LXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4J CQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhy ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04MjdjMTk0YmRjYWEw MDc3ZGU0NDI0MWY4MDAxY2U5YiIgc3R5bGU9ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4 OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90 cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5cbgkJPHRh YmxlPlxuCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBT SVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1vcmUgd2F5cyB0byBqb2luOjwv Rk9OVD5cbgkJCQk8L3RkPlxuICAgICAgICAJPC90cj5cbiAgICAgICAgICAgIDx0ciBzdHlsZT0i bGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDogMTBweDsiPiZuYnNwOzwvdGQ+ PC90cj5cbiAgICAgICAgCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIzIiBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSB0aGUgbWVldGluZyBsaW5rPC9GT05U PlxuCQkJCTwvdGQ+XG4gICAgICAgIAk8L3RyPlxuICAgICAgICAJPHRyPlxuCQkJCTx0ZD5cbgkJ CQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0n aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTgyN2MxOTRiZGNhYTAwNzdk ZTQ0MjQxZjgwMDFjZTliJyBzdHlsZT0nY29sb3I6IzAwNUU3RDsgIHRleHQtZGVjb3JhdGlvbjpu b25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4 Oyc+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTgyN2MxOTRiZGNhYTAw NzdkZTQ0MjQxZjgwMDFjZTliPC9hPjwvRk9OVD5cbgkJCQk8L3RkPlxuICAgICAgICAJPC90cj5c biAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdo dDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQg U0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IG1lZXRpbmcgbnVt YmVyPC9GT05UPlxuCQkJCTwvdGQ+XG4gICAgICAgIAk8L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZD5c bgkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5n IG51bWJlciAoYWNjZXNzIGNvZGUpOiAxODUgMDY3IDIyNTI8L0ZPTlQ+XG4JCQkJPC90ZD5cbgkJ CTwvdHI+XG4JCTwvdGFibGU+XG4JCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+ PEZPTlQgU0laRT0iMiIgIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+bkNnbTZxVGpINDU8 L0ZPTlQ+PC90ZD48L3RyPjwvdGFibGU+XG5cbiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAw MCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD5cblxuJm5ic3A7IDxCUj48Rk9O VCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj5UYXAgdG8gam9pbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9u bHkpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTg1MDY3MjI1MiUy MyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDA1RTdEOyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZv bnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02 NTAtNDc5LTMyMDgsLDE4NTA2NzIyNTIjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZP TlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9G T05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+MS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4g Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxh IGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01USUQ9 bTc3ZTkxODI2NmJiMDY1ZjNhYWUwMjliNzY1ZWI0YzYyIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9u Om5vbmU7Zm9udC1zaXplOjE0cHg7Y29sb3I6IzAwNUU3RCI+R2xvYmFsIGNhbGwtaW4gbnVtYmVy czwvYT48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJSPlxuXG48dGFibGU+PHRyIHN0eWxlPSJsaW5l LWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48 L3RhYmxlPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBw bGljYXRpb248L0ZPTlQ+PEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJh cmlhbCI+RGlhbDwvRk9OVD4gPGEgaHJlZj0ic2lwOjE4NTA2NzIyNTJAaWV0Zi53ZWJleC5jb20i PjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDA1RTdEIiBGQUNFPSJhcmlhbCI+MTg1MDY3MjI1MkBp ZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQg ZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZuYnNw OyA8QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxl PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250 LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBT a3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk IHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE4NTA2NzIyNTIuaWV0 ZkBseW5jLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAw NUU3RCI+MTg1MDY3MjI1Mi5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxl PlxuXG4JPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuCVxuXG4JCQk8dGFibGUgc3R5bGU9 IndpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAg ICA8dHIgc3R5bGU9ImhlaWdodDogMjBweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+ XG4JCQkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1p bHk6QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/ IEdvIHRvIDxhIGhyZWY9Imh0dHBzOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDA1 RTdEOyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHBzOi8vaGVscC53ZWJleC5jb208L2E+XG4J CQkJCTwvdGQ+XG4JCQkJPC90cj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDog NDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5c bjwvdGFibGU+XG4NClNVTU1BUlk6T0F1dGggV0cgSW50ZXJpbXMNClBSSU9SSVRZOjUNCkNMQVNT OlBVQkxJQw0KUlJVTEU6RlJFUT1XRUVLTFk7V0tTVD1TVTtVTlRJTD0yMDIxMDQxOVQxMjAwMDBa O0lOVEVSVkFMPTE7QllEQVk9TU8NCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9O OkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpF TkQ6VkNBTEVOREFSDQo= --000000000000ac3e7805bbb49193-- From nobody Fri Feb 19 13:09:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6393A0786 for ; Fri, 19 Feb 2021 13:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lclG7d190r39 for ; Fri, 19 Feb 2021 13:09:33 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3973A0652 for ; Fri, 19 Feb 2021 13:09:33 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id a17so28333728ljq.2 for ; Fri, 19 Feb 2021 13:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V6sJNE6E8pjYflineTVy7A1FnvpBARKudTAC0Qqvoy4=; b=Cf2pBHYfKsZlc0N90KNCa+svcsTs1tqmGyMEfBWyvY2IMtynSK0p2QX6GUTpBDq2H6 lgP5xj9W20fCyjpXyk83GSEMruwnVZGFlQdWQ3Ov+QUueA/Kb1NPwiN5GHM+zVlpbN5I I+01IkKAKY4GQ9D8MOB4kEdv/Lkf5+4nf9i8gYDKKny1oFabSe0ualBCLBY9gNmOslEE TX8LDzgHCnr3nvbJ4dC8wiDoNNEZLya1fRCKiblIPB0F9WHJer/jUtFJptII4aON3s+1 DVzvmNhRILNyx2rHLSK13FEQXFhTGNGRlXOHlnsJWZLTwPO+ITsvC5EX48SYzlxXFYY1 ehMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V6sJNE6E8pjYflineTVy7A1FnvpBARKudTAC0Qqvoy4=; b=RpqS8xKc7SfTFaCHSY6k4OWn7MI3p78Ez/+APatU2uaXE7GBhyFegsFZbNVtB3Ensc fZ9QvSyYxKcfS88HdrWoGtnTqbhqb4VM7QhGAGCqxfCr+siBC6X3cbTH1jv4HQN2nOca eTCULhtJMWItMPHgbgOJ6ksA0+tLzzl8CXCUVSk4gnxdmQaGfFORBdcENIZbzvS+IuiS f/ueuArl8yM3LmFOfHLm4r3Kn4Ef/Z/N+m9ZciF+HMqcv9wbR9TlOD+uexIPNJnbsJwM tpKfMuA2VlgzdA6y2nxR6sNnmKmiFoi6MTwcu+aGicd8A6sFWKaIvuF4Bcbs1o9g4CCl eXLw== X-Gm-Message-State: AOAM531WYk8F4o0y0C2/6VMMarYO0W60JEtRxYyB+1UWgCc9uGDr6JHa yMW5jw2T1pvHUtoi207YHG9kKPIZTWUZVX0vUpFuBIpfWhOehrGtk7Q1AemyT/wV9RF5mC5y4Hw QkGcWPXu1JLY8+g== X-Google-Smtp-Source: ABdhPJx0sQNvyN/QKrcTv2bqQb0v3yMt4iuAPZHTy0zFtpDM60OW6jMLJ0E266Knay1T/4SQ0JR/VHyKy04JrrEc9uE= X-Received: by 2002:a2e:8852:: with SMTP id z18mr7006148ljj.36.1613768970663; Fri, 19 Feb 2021 13:09:30 -0800 (PST) MIME-Version: 1.0 References: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> In-Reply-To: <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> From: Brian Campbell Date: Fri, 19 Feb 2021 14:09:03 -0700 Message-ID: To: rfc-ise@rfc-editor.org Cc: draft-ideskog-assisted-token@ietf.org, oauth Content-Type: multipart/alternative; boundary="0000000000003f0e5e05bbb6dec6" Archived-At: Subject: Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 21:09:37 -0000 --0000000000003f0e5e05bbb6dec6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, I believe this work was presented briefly to the WG in London during IETF 101. As far as I can recall, the general reaction/thinking at that time was that the WG really should be working on a document about OAuth and single page applications (that may or may not include something like the functionality in draft-ideskog-assisted-token). Since that time the WG adopted and is actively working on 'OAuth 2.0 for Browser-Based Apps' https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ which is intended as a BCP for single page applications acting as OAuth clients. The prospective BCP details security considerations and best practices around leveraging existing features of OAuth for single page apps. Whereas draft-ideskog-assisted-token introduces a new grant, new authorization server endpoint, and really a whole new interaction model between client and authorization server. Publishing an independent stream RFC that runs contrary to the BCP coming out of the WG does seem potentially harmful. On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) < rfc-ise@rfc-editor.org> wrote: > Hi OAuth, > > The authors of draft-ideskog-assisted-token [1] have approached me > requesting that the draft be published as an Informational RFC in the > Independent Submission Stream [2]. > > The draft extends the OAuth 2.0 framework to include an additional > authorization flow for single page applications called the assisted token > flow. It is intended to enable OAuth clients that are written in > scripting languages (such as JavaScript) to request user authorization > using a simplified method. Communication leverages HTML's iframe element, > child windows, and the postMessage interface. This communication is done > using an additional endpoint, the assisted token endpoint. > > It is clear to me that this work could be in scope for OAuth and I want t= o > be sure that both: > - there is no interest within the WG in pursuing this approach > - there is no perceived harm to existing OAuth work if this goes ahead > > I'd appreciate any opinions. > > Many thanks, > Adrian > -- > Adrian Farrel (Independent Submissions Editor), > rfc-ise@rfc-editor.org > > [1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/ > [2] https://www.rfc-editor.org/about/independent/ > > > > > > > -- > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000003f0e5e05bbb6dec6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

I believe this work was pres= ented briefly to the WG in London during IETF 101. As far as I can recall, = the general reaction/thinking at that time was that the WG really should be= working on a document about OAuth and single page applications (that may o= r may not include something like the functionality in draft-ideskog-assiste= d-token). Since that time the WG adopted and is actively working on 'OA= uth 2.0 for Browser-Based Apps' https://datatr= acker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ which is intend= ed as a BCP for single page applications acting as OAuth clients. The prosp= ective BCP details security considerations and best practices around levera= ging existing features of OAuth for single page apps. Whereas draft-ideskog= -assisted-token introduces a new grant, new authorization server endpoint, = and really a whole new interaction model between client and authorization s= erver. Publishing an independent stream RFC that runs contrary to the BCP c= oming out of the WG does seem potentially harmful.




On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (A= drian Farrel) <rfc-ise@rfc-editor.org> wrote:
Hi OAuth,

The authors of draft-ideskog-assisted-token [1] have approached me
requesting that the draft be published as an Informational RFC in the
Independent Submission Stream [2].

The draft extends the OAuth 2.0 framework to include an additional
authorization flow for single page applications called the assisted token flow. It is intended to enable OAuth clients that are written in
scripting languages (such as JavaScript) to request user authorization
using a simplified method. Communication leverages HTML's iframe elemen= t,
child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint.

It is clear to me that this work could be in scope for OAuth and I want to<= br> be sure that both:
- there is no interest within the WG in pursuing this approach
- there is no perceived harm to existing OAuth work if this goes ahead

I'd appreciate any opinions.

Many thanks,
Adrian
--
Adrian Farrel (Independent Submissions Editor),
rfc-ise@rfc-edi= tor.org

[1] https://datatracker.ietf.org/doc/d= raft-ideskog-assisted-token/
[2] https://www.rfc-editor.org/about/independent/ >
>


--
Adrian Farrel (ISE),
rfc-ise@rfc-edi= tor.org

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003f0e5e05bbb6dec6-- From nobody Fri Feb 19 13:51:26 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEFF3A0AE8 for ; Fri, 19 Feb 2021 13:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWmDpZHfuvcy for ; Fri, 19 Feb 2021 13:51:17 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8FC3A0A41 for ; Fri, 19 Feb 2021 13:51:17 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id c17so29184292ljn.0 for ; Fri, 19 Feb 2021 13:51:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JR2nqyy1Hfk/2gmouvjsO6Kw0EgTfpL4s7vwuG4mp/8=; b=ZDGjNZ/KbH6irQkRsk3ZtLXJjgvyOwYn16ewsDXe4FCYpMYJyCpVRb35rY4t+VQqls ejX46jDhFeMsRhHVhGSRrmWbYPI1tyAaqxiL1XzWQhTXrf0yfoitx8/YmFyV03Adpv9X vv4VJKND+Xyb9UmeDls0et2WJfnHTw9uxItKxPoprPbIs4twne47EaNkFpU+g3FHMT2J wA62H3ytPCNKFFnFAxzGN17A9DJeMZ78veja2q703YvFLlLe2iWZ38MR/oyldiYiqdPx SlNX9YU5PvI4nayCU03WbysNHpoSLDNemXt3QjvuFM5JQ9Kj5ju177glKkaQIth5c0BL sOdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JR2nqyy1Hfk/2gmouvjsO6Kw0EgTfpL4s7vwuG4mp/8=; b=DsydJjFs9cgUkwodU69PAsJWAYkfdv5L2MvLXvtA3R1OeYXImB1t/AerlIuhftoXVD kQZlpGAA9lLrKh6RFUgcMJnFvVfiXouyWYyTMVRooFUOe8htfALEUwnnlm4RMiF3auWx wtrGNWX9O1ELJ6ah8xxr1E8qFn9pt+L/CquzNBkt/yEYwYX8xRbxL9GMGfzv3Nsb4Vj0 gY2wcaBk0RaYzCC+MiEJAQNIwam1zpXDIUan0OcwK6snf4BJG3NVnab23zp91ZyA/9oS VSFTgaFO4NmVfGtToqd4NHAJnaQbcZJGGUnxhIu7fMoJKL5uhW1Xvpc+P54/ITLXmo1z WYVw== X-Gm-Message-State: AOAM531bqb6P1zji4BLOSUc9lW4ESplN8s4ie7Gc61wlmTSRHynLTtJt I9viAC7WmbeAx1dCldDbJtHCFf/bx8vsz0XxkVRpbWxQR9Eg44U1BLXteOAl+cn1lER8bC9+2d1 CIx2PaBlKSS2OLriGFQaxlA== X-Google-Smtp-Source: ABdhPJyjJDNsU+cBSu0lGjbEth+qH19eDdDilpMVV9HRmBbvhQqX2Edo/2An6z6XRS7AjI0rBYG+N3lnMaxpt372W24= X-Received: by 2002:a19:8111:: with SMTP id c17mr6546616lfd.574.1613771475768; Fri, 19 Feb 2021 13:51:15 -0800 (PST) MIME-Version: 1.0 References: <5A5EEBCB-0075-4F9E-B943-E6F142A6E84C@mit.edu> In-Reply-To: <5A5EEBCB-0075-4F9E-B943-E6F142A6E84C@mit.edu> From: Brian Campbell Date: Fri, 19 Feb 2021 14:50:49 -0700 Message-ID: To: Justin Richer Cc: oauth Content-Type: multipart/alternative; boundary="0000000000008ff3b305bbb77303" Archived-At: Subject: Re: [OAUTH-WG] Digest for DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 21:51:25 -0000 --0000000000008ff3b305bbb77303 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My inclination is to keep digest[1] out of the base DPoP document. I do believe that including it would add unneeded complexity to regular old DPoP (there are some subtleties around digest that make it more complicated than one might expect) and, from a design philosophy perspective, DPoP has always aspired to be only a proof-of-possession mechanism in and of itself and not venture into the realm of HTTP message integrity or general signatures. [1] Note that the digest header is defined in RFC3230 but there's work underway to obsolete that RFC with draft-ietf-httpbis-digest-headers-04 On Wed, Feb 17, 2021 at 2:54 PM Justin Richer wrote: > Two different specifications (GNAP and FAPI signatures) have recently > profiled DPoP to use its signature method to protect a different kind of > protocol entirely. One thing these methods have in common is that they bo= th > define an additional field for holding a digest of the HTTP Message Body: > > > https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Me= ssage_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-= request-or-response-body > > > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#nam= e-demonstration-of-proof-of-p > > Both of these have the same semantics, and we=E2=80=99re changing the nam= e in GNAP > to align with the FAPI one. This begs the question: do we want to just > define this field as an optional component in DPoP instead of having thes= e > profiles do it separately? It would save them from needing to align with > each other, and anyone else from inventing it again. > > Is it worth defining this in DPoP directly, or does that complicate the > spec too much? I=E2=80=99ve previously raised a similar question on inclu= ding a > hash of the access token in the DPoP request to the RS. > > =E2=80=94 Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008ff3b305bbb77303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My inclination is to keep digest[1] out of the base D= PoP document. I do believe that including it would add unneeded complexity = to regular old DPoP (there are some subtleties around digest that make it m= ore complicated than one might expect) and, from a design philosophy perspe= ctive, DPoP has always aspired to be only a proof-of-possession mechanism i= n and of itself and not venture into the realm of HTTP message integrity or= general signatures.


[1] Note = that the digest header is defined in RFC3230 but there's work underway = to obsolete that RFC with draft-ietf-httpbis-digest-headers-04


On = Wed, Feb 17, 2021 at 2:54 PM Justin Richer <jricher@mit.edu> wrote:
Two different specifications (= GNAP and FAPI signatures) have recently profiled DPoP to use its signature = method to protect a different kind of protocol entirely. One thing these me= thods have in common is that they both define an additional field for holdi= ng a digest of the HTTP Message Body:


Both of these have the = same semantics, and we=E2=80=99re changing the name in GNAP to align with t= he FAPI one. This begs the question: do we want to just define this field a= s an optional component in DPoP instead of having these profiles do it sepa= rately? It would save them from needing to align with each other, and anyon= e else from inventing it again.

Is it worth defini= ng this in DPoP directly, or does that complicate the spec too much? I=E2= =80=99ve previously raised a similar question on including a hash of the ac= cess token in the DPoP request to the RS.

=C2=A0= =E2=80=94 Justin
_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008ff3b305bbb77303-- From nobody Fri Feb 19 14:43:37 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0A93A0C6A for ; Fri, 19 Feb 2021 14:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekHFD4-5A-yU for ; Fri, 19 Feb 2021 14:43:33 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA2A3A0C64 for ; Fri, 19 Feb 2021 14:43:33 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id i8so7290574iog.7 for ; Fri, 19 Feb 2021 14:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1ryNWNEfrFUC1tk5dEwSVJf3tKcPyULJ3PsjZIj8VsQ=; b=jiOBlTQ8TErkgN1fAaTMDdfxkgh9eotBWebbRAwBJo+8hyeqR73Pjla2/JgB0pEDHy dMoKQvoFpuDKkdz+PnpWO+Vm3HSdlogNNEzdnSQHzDnCgPP/CMn5Wax8n53TRMwGsmil y4J5N7YM/1PdgtuqAWB/M3yjXhFxTJqOxizU/4rkU0JSMi/w/rk05/9ASG2e11b0pQG7 GHjtE8SRRAPGVNf6Ly1oROOVOIv4BBpUfz507KotYlox896pyTNKS/nQeZ/SoIO3vKtk YnxE3dC831c/X3BJVKmmjwr+aVhfDXDMZvAdRXbfETIpGuPcBgGzxcMZp3CWFgQqmnO/ UKfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1ryNWNEfrFUC1tk5dEwSVJf3tKcPyULJ3PsjZIj8VsQ=; b=fxecPxyWSaYjbvYuUp91b3ceeJoB5p3JfoX2lNB1xT2OuTgoUbqeY9YedTTghqmb8m JWOSc13SSnZyg6heurJ6g0awbd9cWxFM/0Ej6bumTBwg3+SWk4T/pjZo3PSXnFNX6oJO +fcjaxIKQ57snaZEo3P07Xuf7rrEdk3Pf3j47wGyOUdhzehdRCWlToz3pjQvZf+lfend QhXf57q33z0036KiyikPFKh0EmrKy39IX6puVOpSh80hPCvpTAx3UjFil2nN/Eu2BJ4b eC6jKAipSvMMx/4Dxe9g8e81/RCYU1Xb7002k+fLBwZDJTsU55G4iXv7fL9/L5k/GNF3 DmCw== X-Gm-Message-State: AOAM530Eh4W5k23/uH6GbPteVZjYKq9u9+5PhR1TDxreITNBj6IIYcdb 9zU48KseGouYlyeWAJxqQbdhIz+QXnC/teGnTkY= X-Google-Smtp-Source: ABdhPJzrL2vNOg09JSE481OGpp9dOeMoDbbvM8a5iuTrGtvMmmLsstCzatOloxbruWRFpry49NxzHA3hCtFC3/p+ahk= X-Received: by 2002:a02:cbcf:: with SMTP id u15mr11898323jaq.131.1613774612531; Fri, 19 Feb 2021 14:43:32 -0800 (PST) MIME-Version: 1.0 References: <5A5EEBCB-0075-4F9E-B943-E6F142A6E84C@mit.edu> In-Reply-To: From: Roberto Polli Date: Fri, 19 Feb 2021 23:43:21 +0100 Message-ID: To: Brian Campbell Cc: Justin Richer , oauth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Digest for DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 22:43:35 -0000 Hi @all, I'm planning to read those I-D as they might be useful in a project, and I'm happy to provide feedback on digest usage. In general, when building protocols over HTTP it is necessary to take into account the semantics (eg. range requests, caching, ...) because reverse proxies, WAF and api gateways implement them: this is true whether you use digest or other fields. Is there a git repo to provide feedback? I hope to do it in the next few we= eks.. Have a nice day, R: Il giorno ven 19 feb 2021 alle ore 22:51 Brian Campbell ha scritto: > > My inclination is to keep digest[1] out of the base DPoP document. I do b= elieve that including it would add unneeded complexity to regular old DPoP = (there are some subtleties around digest that make it more complicated than= one might expect) and, from a design philosophy perspective, DPoP has alwa= ys aspired to be only a proof-of-possession mechanism in and of itself and = not venture into the realm of HTTP message integrity or general signatures. > > > [1] Note that the digest header is defined in RFC3230 but there's work un= derway to obsolete that RFC with draft-ietf-httpbis-digest-headers-04 > > > On Wed, Feb 17, 2021 at 2:54 PM Justin Richer wrote: >> >> Two different specifications (GNAP and FAPI signatures) have recently pr= ofiled DPoP to use its signature method to protect a different kind of prot= ocol entirely. One thing these methods have in common is that they both def= ine an additional field for holding a digest of the HTTP Message Body: >> >> https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_M= essage_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http= -request-or-response-body >> >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#na= me-demonstration-of-proof-of-p >> >> Both of these have the same semantics, and we=E2=80=99re changing the na= me in GNAP to align with the FAPI one. This begs the question: do we want t= o just define this field as an optional component in DPoP instead of having= these profiles do it separately? It would save them from needing to align = with each other, and anyone else from inventing it again. >> >> Is it worth defining this in DPoP directly, or does that complicate the = spec too much? I=E2=80=99ve previously raised a similar question on includi= ng a hash of the access token in the DPoP request to the RS. >> >> =E2=80=94 Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Feb 19 15:18:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9323A0D6D for ; Fri, 19 Feb 2021 15:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN4tSecN51nb for ; Fri, 19 Feb 2021 15:18:16 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8BD3A0D70 for ; Fri, 19 Feb 2021 15:18:15 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id o16so26041405ljj.11 for ; Fri, 19 Feb 2021 15:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wcto6HRwKV0UAmDtJ4AqaiRBahvmunkG86SBTxYYXUQ=; b=bUouOMlVF048JV1bRzctZbl+l8liYcWqA6p9aPQLQdoyU5Fi2DosPCwYMD8xNSLwv4 5VDzBtsXpKnUoaWhlVl7zEldR+BX+8ll5ed+9JPhKXjSBRDpcsScY2O5e1uosW3y8Rrf hbMBGcAoC+/RL66+X7KOEyruX2vXUa0PJcTaxJG5OTgPg+wM1vEf9M8zCnHBhV1nk+Mk zUfttxXjZkgUZpH9efq23g5CIQDYv6tSFdg6BgACfz6eGCAKPw0eayVwSQM7u4YDyXo4 Leojr19hw4kQPx2tTgRPoS48oZlGJkW4XND1opi8GtAIY88oIGXhdIZhe65/XvX/RTz6 CVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wcto6HRwKV0UAmDtJ4AqaiRBahvmunkG86SBTxYYXUQ=; b=jqWt/LM1RZxFf9uu2yl1FqT4Q+rmVTLPKaGguwfOy4psLcz0ZPtua7X6/dwQ0wFFzh Kql7cdOFPr9waKTRWXSn7bA6vubDvP/iPMjA3MOHK1CIb9TlRPDescSW+eH2+pb0O02j AHAh9HWyx6jd+HHg0E7VVKcW9xbd9PIg0IibxCpDZggd5bbpzvEgxWaSIwjrrqyOxKYl 45vS4fuaF/E2uA8BZitVUjd2RwkMXm8FkTpDR+/5Zp9VNgtbLyhEZqJF5AIblTtNCF3I 6/fhM3ZcWwcTwIyuOFNBfwTXMQKbmKtlC5zNCZU2XyPEdPquYfCoV7/yrTGOaOUJluG4 M9jA== X-Gm-Message-State: AOAM53085LoVAV6LjuASM6vsk1PZphq1Q1qoz2njesbWfVNqZtvFro5l XYiZTZIM3tkDngsBrPiyJAsig72W6GheFbqfgxUqzPr7ASOtddr9Lr2OhZ+FD5QddICa201DXuj +hdVD0OD/qjb0XA== X-Google-Smtp-Source: ABdhPJzA8Kw13v8WJwdeJ1ubxISPcpzQ4FCe12hW4sZwNTMEcy34FwBEgTpeJ+z+k+oYlFxuewpjqYcsUUlrwfnQN8E= X-Received: by 2002:a19:3806:: with SMTP id f6mr7198586lfa.242.1613776693776; Fri, 19 Feb 2021 15:18:13 -0800 (PST) MIME-Version: 1.0 References: <35645BCD-A9F5-4A57-9771-836647F08444@forgerock.com> In-Reply-To: <35645BCD-A9F5-4A57-9771-836647F08444@forgerock.com> From: Brian Campbell Date: Fri, 19 Feb 2021 16:17:47 -0700 Message-ID: To: Neil Madden Cc: Vittorio Bertocci , oauth Content-Type: multipart/alternative; boundary="00000000000094708f05bbb8aa55" Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 23:18:19 -0000 --00000000000094708f05bbb8aa55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Neil, Appreciate the insight and recommendations. I think we can incorporate that, more or less, into the next revision. One point to dig into just a bit more, you said that 'SameSite has a "GET-out clause" in the form of =E2=80=9Clax=E2=80=9D'. As I understand it,= such a cookie would still only be sent on a cross-site GET resulting from a top-level navigation. And in the context of the bff-token endpoint, that significantly reduces the ways a cross-site request could be initiated and those ways (pop-up or full page redirection) further limits the likelihood of the malicious party being able to read response data. On Thu, Feb 18, 2021 at 5:08 AM Neil Madden wrote: > Thanks for following up, Brian. Responses below. > > On 17 Feb 2021, at 22:48, Brian Campbell > wrote: > > Always appreciate (and often learn from) your insights, Neil. I'd like to > dig into the CSRF thing a bit more though to understand better and > hopefully do the right thing in the draft. > > It seems to me that a GET at the bff-token endpoint is "safe" in that it'= s > effectively just a read. > > > Well it=E2=80=99s a read that returns an access token. It=E2=80=99s =E2= =80=9Csafe=E2=80=9D in the sense of > side-effects, but we absolutely want to preserve the confidentiality of > what is returned and only allow it to be accessed by authorized clients > (the legitimate frontend). At the moment the only thing keeping that safe > is the JSON content type. For example, imagine a world in which the > token-bff endpoint instead returned the access token as HTML: > >
abcd
> > Then as an attacker I can simply embed an iframe on my site that refers t= o > your bff-endpoint and then parse the access token out of the DOM. The > browser will happily load that iframe and send along the cookie when it > makes the request. If you have CORS enabled on your site (with > Access-Control-Allow-Credentials) then any of the allowed CORS origins ca= n > directly call the bff-token endpoint and read the access token even in JS= ON > form. There have also been historical same-origin policy bypasses using > Flash, Adobe Reader, or other plugins (thankfully now largely eliminated)= , > or by redefining JavaScript prototypes - see > https://haacked.com/archive/2009/06/25/json-hijacking.aspx/ . These are > largely fixed, but I wouldn=E2=80=99t bet on there never being another on= e. > > > There could be a "cache miss" where the backend attempts to use a refresh > token it has to get a new access token from the remote AS, which will be > more resource intensive but doesn't fundamentally alter the state of the > backend so is still "safe". That in conjunction with your pointing to > Cross-Origin Read Blocking makes me think your concern isn't so much abou= t > traditional CSRF used to take some malicious action but rather about > somehow (speculative side-channel attacks, problems with javascript > interpreters, other similar vectors that are somewhat beyond me) accessin= g > the data of the response to a forged cross site request. Correct me if I'= m > wrong. I don't know if or how much the distinction matters in terms of > mitigation approach but I'm keen to better understand. > > > As explained above, because the endpoint returns JSON it _should_ be > impossible to directly read the response from a cross-origin read (unless > explicitly enabled with CORS). But you may still be able to embed that > response in an or similar. Because people are terrible at setting > correct Content-Type headers on responses, browsers often ignore them and > instead try to sniff what the real content type is: so if the response > looks a bit like a valid image format (or PDF or JavaScript or whatever) > then it might try and render it. No doubt this will fail, but at that poi= nt > the data has already been loaded into the address space of the renderer > process for the attacker=E2=80=99s site. That means that it is then vulne= rable to > attacks like Spectre that bypass normal memory protection. The browser > vendors consider this to be a real threat, hence CORB. > > The most important thing for a cookie-based JSON API to do is to return a > correct Content-Type header and to also return X-Content-Type-Options: > nosniff to prevent browsers from trying to sniff the real content-type. (= I > have an example in my book where the failure to do this can actually turn= a > JSON API into a vector for XSS attacks, even if you have no SPA frontend > component at all). > > (You should also mark the cookie as HttpOnly because this prevents the > cookie ever entering the address space of a renderer process in modern > browsers - an actual genuine security benefit of HttpOnly cookies). > > But my worry is that this is still basically trusting the client to > perform critical security checks, and historically browsers have had plen= ty > of bypasses in this area. So for something as high-value as an access tok= en > I=E2=80=99d prefer that any request using cookie-based authentication is = protected > by proactive CSRF defences to prevent malicious requests being allowed in > the first place. > > > It sounds like your preference for only POST rests in an assumption that > the larger app will already have in place some CSRF defenses and by using > POST the bff-token endpoint will basically inherit said defenses. Or is > POST by itself good enough (the CORB writeup seems to suggest that the > context in which a POST could be made is more guarded against side channe= l > stuff)? But perhaps then the draft should be more explicit about CSRF > defense? Saying it just has to be done. Or like even mandating a > non-standard header be in the request, "X-Neil-says-beware-CSRF: yuppers" > as a strawman. With such a header it could remain a GET. And I kinda like > GET because it is really a request for data. Or perhaps the request shou= ld > be a POST with built-in CSRF protection by changing it to carry any > parameters as JSON in the body with "{}" for the case of no parameters > specified? Or just make it a PUT and call it good? Not sure any of these > are good ideas but just trying to hash out the most appropriate thing to > do. > > > Right, the preference for POST is because it's more likely to trigger CSR= F > defences, which often consider GET/HEAD requests to be =E2=80=9Csafe=E2= =80=9D. Even before > Spectre, there is a whole array of side-channel attacks for extracting > information from cross-site responses: https://xsleaks.dev . Note that > even SameSite has a "GET-out clause" in the form of =E2=80=9Clax=E2=80=9D= . > > So yes, the real requirement is that the endpoint should have adequate > CSRF protection. Requiring a special header has had bypasses in the past > (again, mostly using Flash). > > So I think we should recommend the following: > > 1. The response MUST contain a correct Content-Type: application/json > header and X-Content-Type-Options: nosniff. > 2. The cookie SHOULD be marked as HttpOnly. > 3. The endpoint MUST NOT be accessible via CORS. > 4. The endpoint SHOULD have adequate CSRF protections in place. At a > minimum the cookie should be marked as SameSite. > > We could perhaps add an informational reference to > https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery= _Prevention_Cheat_Sheet.html given > that there is a changing landscape around cookies at the moment. If the > browser vendors do eliminate 3rd-party cookies then 1, 3, and 4 become > largely unnecessary (although 3 might still be a risk due to sub-domain > hijacking, and 1 will always be good practice). > > =E2=80=94 Neil > > > That got a little rambly, sorry. But hopefully it makes some sense. > > On Sun, Feb 14, 2021 at 1:17 AM Neil Madden > wrote: > >> >> The combination of the bff-token endpoint recommending the use of GET >> requests together with the hint to use cookie-based authentication is >> likely going to punch a hole in most CSRF defenses, which assume that GE= Ts >> are safe. The only thing preventing this being exploitable is Cross-Orig= in >> Read Blocking ( >> https://chromium.googlesource.com/chromium/src/+/master/services/network= /cross_origin_read_blocking_explainer.md) >> due to the JSON content-type. That makes me really nervous. We should at >> least mandate X-Content-Type-Options: nosniff on that response. I=E2=80= =99d feel >> more comfortable if this was a POST request only. >> >> =E2=80=94 Neil >> >> > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > > ForgeRock values your Privacy --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000094708f05bbb8aa55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Neil,
Appreciate the insight an= d recommendations. I think we can incorporate that, more or less, into the = next revision.
One point to dig into just a bit more, you sa= id that 'SameSite has a "GET-out clause" in the form of =E2= =80=9Clax=E2=80=9D'. As I understand it, such a cookie would still only= be sent on a cross-site GET resulting from a top-level=C2=A0 navigation. A= nd in the context of the bff-token endpoint, that significantly reduces the= ways a cross-site request could be initiated and those ways (pop-up or ful= l page redirection) further limits the likelihood of the malicious party be= ing able to read response data.

On Thu, Feb 18, 2021 at 5:08 AM N= eil Madden <neil.madden@forgerock.com> wrote:
Thanks for following up, Brian. Responses = below.

On 17 Feb 2021, at 22:48, Brian Cam= pbell <b= campbell@pingidentity.com> wrote:

Always appreciate (and often learn from) your insights, Neil. I'd lik= e to dig into the CSRF thing a bit more though to understand better and hop= efully do the right thing in the draft.

It se= ems to me that a GET at the bff-token endpoint is "safe" in that = it's effectively just a read.

<= /div>
Well it=E2=80=99s a read that returns an access token. It=E2=80= =99s =E2=80=9Csafe=E2=80=9D in the sense of side-effects, but we absolutely= want to preserve the confidentiality of what is returned and only allow it= to be accessed by authorized clients (the legitimate frontend). At the mom= ent the only thing keeping that safe is the JSON content type. For example,= imagine a world in which the token-bff endpoint instead returned the acces= s token as HTML:

<div id=3D=E2=80=9CaccessToken= =E2=80=9D>abcd</div>

Then as an attacker = I can simply embed an iframe on my site that refers to your bff-endpoint an= d then parse the access token out of the DOM. The browser will happily load= that iframe and send along the cookie when it makes the request. If you ha= ve CORS enabled on your site (with Access-Control-Allow-Credentials) then a= ny of the allowed CORS origins can directly call the bff-token endpoint and= read the access token even in JSON form. There have also been historical s= ame-origin policy bypasses using Flash, Adobe Reader, or other plugins (tha= nkfully now largely eliminated), or by redefining JavaScript prototypes - s= ee=C2=A0https://haacked.com/archive/2009/06/25/json-hijackin= g.aspx/=C2=A0. These are largely fixed, but I wouldn=E2=80=99t bet on t= here never being another one.


There could be a "cache mis= s" where the backend attempts to use a refresh token it has to get a n= ew access token from the remote AS, which will be more resource intensive b= ut doesn't fundamentally alter the state of the backend so is still &qu= ot;safe". That in conjunction with your pointing to Cross-Origin Read = Blocking makes me think your concern isn't so much about traditional CS= RF used to take some malicious action but rather about somehow (speculative= side-channel attacks, problems with javascript interpreters, other similar= vectors that are somewhat beyond me) accessing the data of the response to= a forged cross site request. Correct me if I'm wrong. I don't know= if or how much the distinction matters in terms of mitigation approach but= I'm keen to better understand.=C2=A0

As explained above, because the endpoint returns JSON= it _should_ be impossible to directly read the response from a cross-origi= n read (unless explicitly enabled with CORS). But you may still be able to = embed that response in an <img> or similar. Because people are terrib= le at setting correct Content-Type headers on responses, browsers often ign= ore them and instead try to sniff what the real content type is: so if the = response looks a bit like a valid image format (or PDF or JavaScript or wha= tever) then it might try and render it. No doubt this will fail, but at tha= t point the data has already been loaded into the address space of the rend= erer process for the attacker=E2=80=99s site. That means that it is then vu= lnerable to attacks like Spectre that bypass normal memory protection. The = browser vendors consider this to be a real threat, hence CORB.
The most important thing for a cookie-based JSON API to do is = to return a correct Content-Type header and to also return X-Content-Type-O= ptions: nosniff to prevent browsers from trying to sniff the real content-t= ype. (I have an example in my book where the failure to do this can actuall= y turn a JSON API into a vector for XSS attacks, even if you have no SPA fr= ontend component at all).

(You should also mark th= e cookie as HttpOnly because this prevents the cookie ever entering the add= ress space of a renderer process in modern browsers - an actual genuine sec= urity benefit of HttpOnly cookies).

But my worry i= s that this is still basically trusting the client to perform critical secu= rity checks, and historically browsers have had plenty of bypasses in this = area. So for something as high-value as an access token I=E2=80=99d prefer = that any request using cookie-based authentication is protected by proactiv= e CSRF defences to prevent malicious requests being allowed in the first pl= ace.


It sounds like your preference for only POST rests in an assumption= that the larger app will already have in place some CSRF defenses and by u= sing POST the bff-token endpoint will basically inherit said defenses. Or i= s POST by itself good enough (the CORB writeup seems to suggest that the co= ntext in which a POST could be made is more guarded against side channel st= uff)?=C2=A0 But perhaps then the draft should be more explicit about CSRF d= efense? Saying it just has to be done. Or like even mandating a non-standar= d header be in the request, "X-Neil-says-beware-CSRF: yuppers" as= a strawman. With such a header it could remain a GET. And I kinda like GET= because it is really a request for data.=C2=A0 Or perhaps the request shou= ld be a POST with built-in CSRF protection by changing it to carry any para= meters as JSON in the body with "{}" for the case of no parameter= s specified?=C2=A0 Or just make it a PUT and call it good? Not sure any of = these are good ideas but just trying to hash out the most appropriate thing= to do.

Right, the p= reference for POST is because it's more likely to trigger CSRF defences= , which often consider GET/HEAD requests to be =E2=80=9Csafe=E2=80=9D. Even= before Spectre, there is a whole array of side-channel attacks for extract= ing information from cross-site responses:=C2=A0https://xsleaks.dev=C2=A0. Note that even SameSi= te has a "GET-out clause" in the form of =E2=80=9Clax=E2=80=9D.

So yes, the real requirement is that the endpoint s= hould have adequate CSRF protection. Requiring a special header has had byp= asses in the past (again, mostly using Flash).

So = I think we should recommend the following:

1. The = response MUST contain a correct Content-Type: application/json header and X= -Content-Type-Options: nosniff.
2. The cookie SHOULD be marked as= HttpOnly.
3. The endpoint MUST NOT be accessible via CORS.
=
4. The endpoint SHOULD have adequate CSRF protections in place. At a m= inimum the cookie should be marked as SameSite.=C2=A0

<= div>We could perhaps add an informational reference to=C2=A0https://cheatsheetseries.owasp.or= g/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html=C2= =A0given that there is a changing landscape around cookies at the moment. I= f the browser vendors do eliminate 3rd-party cookies then 1, 3, and 4 becom= e largely unnecessary (although 3 might still be a risk due to sub-domain h= ijacking, and 1 will always be good practice).

=E2= =80=94 Neil

<= br>
That got a little rambly, sorry. But hopefully it makes some = sense.

On Sun, Feb 14, 2021 at 1:17 AM Neil Madden <neil.madden@forge= rock.com> wrote:

The combination of the bff-token endpoint recommendi= ng the use of GET requests together with the hint to use cookie-based authe= ntication is likely going to punch a hole in most CSRF defenses, which assu= me that GETs are safe. The only thing preventing this being exploitable is = Cross-Origin Read Blocking (https://chromium.googlesource.com/chromium/src/+/maste= r/services/network/cross_origin_read_blocking_explainer.md) due to the = JSON content-type. That makes me really nervous. We should at least mandate= X-Content-Type-Options: nosniff on that response. I=E2=80=99d feel more co= mfortable if this was a POST request only.=C2=A0

= =E2=80=94 Neil

=

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.


ForgeRock values your Privacy

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000094708f05bbb8aa55-- From nobody Fri Feb 19 15:45:56 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A2D3A045E for ; Fri, 19 Feb 2021 15:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9GZVMV-caVu for ; Fri, 19 Feb 2021 15:45:52 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A46D3A040F for ; Fri, 19 Feb 2021 15:45:52 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id u4so31183557ljh.6 for ; Fri, 19 Feb 2021 15:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pFoKkKyXY6nZ6cge+oKM1FgW56ZvJ6YrmdsdZiAuTCg=; b=RW+josnjcFBGjVpHvfKKE1zIAZy161W8knSB9izC3M8/HY0baghZIOr+0+4lWkEfaH dqxZzMDApcub6VIkYrClMC2vyb25sW7JIBe6Jvg+sg0ywEQokPlgrORUjTHZoCxRcNJY Kt8P6oWN8UNJK1kWHUD8EHGkBdajjbalACyeQiCOGbXO5OO5Wm3p8jwjOlzP1A7HDUI+ TOFbUUc1AYdl/jvICIWxJiyoKrQRaX5mMlAWcWsdzafVz9qSi2k7tJb1zXfTeIDdYihy DaHF2wItWvoYCt5V0J5SIbZuQcQxcRz/BjmGQ3ztbc3Cb/oLc8NTYzAdP2hOLxVVI6Lm B+CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pFoKkKyXY6nZ6cge+oKM1FgW56ZvJ6YrmdsdZiAuTCg=; b=WT+ZVD8RzzSlFaFk+gQUhXClnc/KKkY5OLszXLBA7xjalQwbuYFj3TUGCHtYpYuOgJ UOS+QXcHBrVF4b6YPpZGs86qB7on4j9o2TSlBBmU6RIrbB5wMlpwkN7ILdLg47+ivkrr l19HZUQlT7111kw3ChNcriBER23M0tiafGZVhp4vWuR4rW6wgquWpWxCmdfLv57lvyWA Dc5eWFNxHKPjeGmphlqp6sz7iOQxOX2a/+xxtlX4phlMoBpSafVYL/4JulBM5Ca2BAlF D7V8snWPEixkAI5ZnA5A06KkUsXJ3Y8+oBu9Qjs1nUmj36OI4UdBY+xZqscXLUsFp3X2 DRfQ== X-Gm-Message-State: AOAM531N0sqZuKbSguIX1DLtGNoygxAvq+KYIs23JFryxk6gXGp7i2r+ 40JiSZQO+zEjOzyeEOYwmIyneHm2jwCV0AHZ0L3OY0Y0uCTuh7RFOu4LR7Af7YERBjsHL0566DV jRxBfwIKdymQYFg== X-Google-Smtp-Source: ABdhPJzn1/1KfFyqw+kZBjb08rh8dgmZQ5IaaYM3JnvtzF1SSsTWhBWg0nLrfV0a4MFmvZ68OemK6B5wp3uJZcn/hyk= X-Received: by 2002:a2e:8556:: with SMTP id u22mr7429679ljj.114.1613778350637; Fri, 19 Feb 2021 15:45:50 -0800 (PST) MIME-Version: 1.0 References: <5A5EEBCB-0075-4F9E-B943-E6F142A6E84C@mit.edu> In-Reply-To: From: Brian Campbell Date: Fri, 19 Feb 2021 16:45:24 -0700 Message-ID: To: Roberto Polli Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="00000000000056207c05bbb90d23" Archived-At: Subject: Re: [OAUTH-WG] Digest for DPoP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 23:45:55 -0000 --00000000000056207c05bbb90d23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roberto, The SHMIP draft is in the OIDF's FAPI repository https://bitbucket.org/openid/fapi/src/master/ and mailing list is https://lists.openid.net/mailman/listinfo/openid-specs-fapi The GNAP draft is out of the IETF WG of the same name and the git repo is https://github.com/ietf-wg-gnap/gnap-core-protocol/ The usage of digest by both builds on the OAuth WG 's DPoP draft and is in git at https://github.com/danielfett/draft-dpop On Fri, Feb 19, 2021 at 3:43 PM Roberto Polli wrote: > Hi @all, > > I'm planning to read those I-D as they might be useful in a project, > and I'm happy to provide feedback on digest usage. > In general, when building protocols over HTTP it is necessary to take > into account the semantics (eg. range requests, caching, ...) > because reverse proxies, WAF and api gateways implement them: this is > true whether you use digest or other fields. > > Is there a git repo to provide feedback? I hope to do it in the next few > weeks.. > > Have a nice day, > R: > > Il giorno ven 19 feb 2021 alle ore 22:51 Brian Campbell > ha scritto: > > > > My inclination is to keep digest[1] out of the base DPoP document. I do > believe that including it would add unneeded complexity to regular old DP= oP > (there are some subtleties around digest that make it more complicated th= an > one might expect) and, from a design philosophy perspective, DPoP has > always aspired to be only a proof-of-possession mechanism in and of itsel= f > and not venture into the realm of HTTP message integrity or general > signatures. > > > > > > [1] Note that the digest header is defined in RFC3230 but there's work > underway to obsolete that RFC with draft-ietf-httpbis-digest-headers-04 > > > > > > On Wed, Feb 17, 2021 at 2:54 PM Justin Richer wrote: > >> > >> Two different specifications (GNAP and FAPI signatures) have recently > profiled DPoP to use its signature method to protect a different kind of > protocol entirely. One thing these methods have in common is that they bo= th > define an additional field for holding a digest of the HTTP Message Body: > >> > >> > https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Me= ssage_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-= request-or-response-body > >> > >> > https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#nam= e-demonstration-of-proof-of-p > >> > >> Both of these have the same semantics, and we=E2=80=99re changing the = name in > GNAP to align with the FAPI one. This begs the question: do we want to ju= st > define this field as an optional component in DPoP instead of having thes= e > profiles do it separately? It would save them from needing to align with > each other, and anyone else from inventing it again. > >> > >> Is it worth defining this in DPoP directly, or does that complicate th= e > spec too much? I=E2=80=99ve previously raised a similar question on inclu= ding a > hash of the access token in the DPoP request to the RS. > >> > >> =E2=80=94 Justin > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000056207c05bbb90d23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roberto,



The usage of digest= by both builds on the OAuth WG's DPoP draft and is in git at https://github.com/danielfett/draft-dpop=C2=A0



=
On Fri, Feb 19, 2021 at 3:43 PM Rober= to Polli <robip= olli@gmail.com> wrote:
Hi @all,

I'm planning to read those I-D as they might be useful in a project, and I'm happy to provide feedback on digest usage.
In general, when building protocols over HTTP it is necessary to take
into account the semantics (eg. range requests, caching, ...)
because reverse proxies, WAF and api gateways implement them: this is
true whether you use digest or other fields.

Is there a git repo to provide feedback? I hope to do it in the next few we= eks..

Have a nice day,
R:

Il giorno ven 19 feb 2021 alle ore 22:51 Brian Campbell
<bcampbell=3D40pingidentity.com@dmarc.ietf.org> ha scritto:
>
> My inclination is to keep digest[1] out of the base DPoP document. I d= o believe that including it would add unneeded complexity to regular old DP= oP (there are some subtleties around digest that make it more complicated t= han one might expect) and, from a design philosophy perspective, DPoP has a= lways aspired to be only a proof-of-possession mechanism in and of itself a= nd not venture into the realm of HTTP message integrity or general signatur= es.
>
>
> [1] Note that the digest header is defined in RFC3230 but there's = work underway to obsolete that RFC with draft-ietf-httpbis-digest-headers-0= 4
>
>
> On Wed, Feb 17, 2021 at 2:54 PM Justin Richer <jricher@mit.edu> wrote:
>>
>> Two different specifications (GNAP and FAPI signatures) have recen= tly profiled DPoP to use its signature method to protect a different kind o= f protocol entirely. One thing these methods have in common is that they bo= th define an additional field for holding a digest of the HTTP Message Body= :
>>
>> https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTT= P_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-h= ttp-request-or-response-body
>>
>> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0= 3.html#name-demonstration-of-proof-of-p
>>
>> Both of these have the same semantics, and we=E2=80=99re changing = the name in GNAP to align with the FAPI one. This begs the question: do we = want to just define this field as an optional component in DPoP instead of = having these profiles do it separately? It would save them from needing to = align with each other, and anyone else from inventing it again.
>>
>> Is it worth defining this in DPoP directly, or does that complicat= e the spec too much? I=E2=80=99ve previously raised a similar question on i= ncluding a hash of the access token in the DPoP request to the RS.
>>
>>=C2=A0 =E2=80=94 Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately by e-mail and delete the message and any file attachments from your = computer. Thank you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000056207c05bbb90d23-- From nobody Sat Feb 20 00:42:17 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01D53A0CC3 for ; Sat, 20 Feb 2021 00:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V3wyISpWskT for ; Sat, 20 Feb 2021 00:42:14 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D4E3A0CBA for ; Sat, 20 Feb 2021 00:42:14 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id y3so1467572plg.4 for ; Sat, 20 Feb 2021 00:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=k9/zDVKvodQU1DSWMN4QOEjJjQ7/o/PoyvBi6i0eRms=; b=NSvBtzrvT4Agqb1KPCc6tK5+eJDUk2ZQoouSgOcYSy5OToMCT84e2m5UgUXmcS90OZ eI7ezQFdO+98CjFXDIkqezM0ODH4weBsVlhPB3Z+ZVruhRiuAwNxf3y+q5tNdGBA1mdw yTuwGFtY6yyiJG9QRYs4O2+eq/xhl5VOw/g7W9nZOAzd0jNc9l+8Nd+Vf8HhRdU/0Q1t ng1vFvF4FWyDctckZNcz8lRpCVZziaSR/6Zi+LY9cbgAy8BW39BoBo8saQvMO3lc9mb9 ETPda7cZl1rUF0cckwNtWk9X3WPPA8XP/tF9tX+zmT73y+PgmajNXkLyItbpqYLGHxmr 1Pzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=k9/zDVKvodQU1DSWMN4QOEjJjQ7/o/PoyvBi6i0eRms=; b=Q9wH62m8RHXrJg51riJGHmXr86+LTaZCTsPpRye8s+NKABAgnVYrCaL5swTJ43BBuO TO8UlgPdGjD+sXvtbaD2Ob4GcEff8ABPB+MCDVBaigdel5kUmdItGJkgJi1ojDSGu6pl UsfkYFDNoh6yA5TyEGuRkandzTuxUhmTM4ZdO958uxYbWzcyAl3NoIDZazJJ6O+haODj xA0ElBQoZIK/uf0uvEnqhgnVZvs/6ut/NjQSohlLEGkvRGXK/HiNV/t3bjKf0Aoy8g9t WqtQKacHWkA4v57JGzBP55roTl6oKTmraJHUKiiZBrPbBiGWToq2H5mdu8KW6LoCxun9 C7HQ== X-Gm-Message-State: AOAM532WsLo7vA6Q9+qgts8vMNG60PzHoFkCXUiBz8ocrQictUwwnlQT Fwj69Tn7YZuDWgdFa1Dr9Nskpw== X-Google-Smtp-Source: ABdhPJyW/u4kCQlTceUBS8D88mAu5c26b0dRwUirs2fjcoxZl7ogwgLEgNeBxyHBSeLHJ3Wpn+iBnw== X-Received: by 2002:a17:90a:4a84:: with SMTP id f4mr13332048pjh.231.1613810533816; Sat, 20 Feb 2021 00:42:13 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id c17sm10636552pjq.17.2021.02.20.00.42.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Feb 2021 00:42:12 -0800 (PST) From: Vittorio Bertocci To: Roni Even , "gen-art@ietf.org" CC: "draft-ietf-oauth-access-token-jwt.all@ietf.org" , "last-call@ietf.org" , "oauth@ietf.org" Thread-Topic: Genart last call review of draft-ietf-oauth-access-token-jwt-11 Thread-Index: ATg3Mzc4TJWLG/uoaKyYMhd/r5rdbr2gYiCC X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sat, 20 Feb 2021 08:42:11 +0000 Message-ID: References: <161269010849.30071.8142300590273121238@ietfa.amsl.com> In-Reply-To: <161269010849.30071.8142300590273121238@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Genart last call review of draft-ietf-oauth-access-token-jwt-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 08:42:16 -0000 VGhhbmsgeW91IFJvbmksDQpHcmVhdCBjYXRjaCEgSSBtYWRlIHRob3NlIHR3byBjbGllbnRfaWQg dmFsdWVzIGNvbnNpc3RlbnQsIHRoZSBjaGFuZ2Ugd2lsbCBhcHBlYXIgaW4gMTIuDQpUaGFua3MN ClYuDQoNCg0K77u/T24gMi83LzIxLCAwMToyOCwgIlJvbmkgRXZlbiB2aWEgRGF0YXRyYWNrZXIi IDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBSb25pIEV2ZW4NCiAg ICBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMNCiAgICANCiAgICBJIGFtIHRoZSBhc3Np Z25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQog ICAgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n IHByb2Nlc3NlZA0KICAgIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQogICAgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KICAgIA0KICAgIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBG QVEgYXQNCiAgICANCiAgICA8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2Vu QXJ0ZmFxPi4NCiAgICANCiAgICBEb2N1bWVudDogZHJhZnQtaWV0Zi1vYXV0aC1hY2Nlc3MtdG9r ZW4tand0LT8/DQogICAgUmV2aWV3ZXI6IFJvbmkgRXZlbg0KICAgIFJldmlldyBEYXRlOiAyMDIx LTAyLTA3DQogICAgSUVURiBMQyBFbmQgRGF0ZTogMjAyMS0wMi0wOQ0KICAgIElFU0cgVGVsZWNo YXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3IgYSB0ZWxlY2hhdA0KICAgIA0KICAgIFN1bW1hcnk6 DQogICAgVGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhcyBhIHN0YW5kYXJk IHRyYWNrIFJGQyB3aXRoIG5pdA0KICAgIA0KICAgIE1ham9yIGlzc3VlczoNCiAgICANCiAgICBN aW5vciBpc3N1ZXM6DQogICAgDQogICAgTml0cy9lZGl0b3JpYWwgY29tbWVudHM6DQogICAgSW4g c2VjdGlvbiAzIHRoZSBnZXQgZXhhbXBsZSBoYXMgY2xpZW50X2lkIGFzIHM2QmhkUmtxdDMgYW5k IHRoZSBjbGFpbXMgaGFzIHM2QmhkUmtxdDNfDQogICAgDQogICAgDQogICAgDQogICAgDQogICAg DQogICAgDQogICAgDQo= From nobody Sat Feb 20 00:42:28 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E455A3A0CC7 for ; Sat, 20 Feb 2021 00:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83OmWcy1Ylsq for ; Sat, 20 Feb 2021 00:42:20 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF26A3A0CCF for ; Sat, 20 Feb 2021 00:42:19 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id e9so4700984plh.3 for ; Sat, 20 Feb 2021 00:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=EJL2y5Zm0Y/YifYvveg85JkqPKWYnv+oNaR+2Ubf1OI=; b=gdtdca1l90pe/83qrlQqOGRVy1V+Sgx0gJQ2syGeMpiIRU9eo6VbXxbNYDhWnW28gq VpjT2xAK0UBZUhaNI+U+VbCtajvqDbJ5d50OcssyVCz8aRmqpSTShJDoV2aFfkdLR1Ze WL54MYWOju1XVc4PPYddq2KC/IfefODmRstF+2sS1rYlEG3q2Lce//a0uKFGPvA3ntuJ ZIhmvD8vSXTLPgH4e5D/Xs3rQPRSj+6kGY4zpMfTHwGcQjedyOmE7fJaZCQmXzahcmep w9kZsKgqi3bNbUZiAeUAbjiKRTirKjEGu/KXhxuqgnQ3lV001J59qQTz303wJr4fhHbc LSqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=EJL2y5Zm0Y/YifYvveg85JkqPKWYnv+oNaR+2Ubf1OI=; b=f41siY3HxsVNPd/x8MzetTGDaHxtsyWhXrJFy2Ff7c0pG3l5OtsSli6+y7MpqmbVcJ 3EoHrk7bXFQRHGyRMw40DjQgTtMbV/eL6l06idVRc5RO5nRdjCRDs5uxXAfzZT9jaVpL w4NC5pKYFzuoYcmIiJ+ISGYTA+x/QQ+6ZSzn385ZjkjhuV0qUqltQlKiIGwvMiX8ofIq rxGeASRE3PNV7SXsQpa2Z5PFDM6uSyqXcAjK3EVhiLr87Dn4yWNUr+RiL3no5BpMs4Ti 24okap9YZEp6LT8orpLkqSaeCVOPhnTb79idASUe3mhN0WzOZggFmXSJ52iwC6Ani0B+ k3Wg== X-Gm-Message-State: AOAM5338sqg13Hsbw1hsmjsEikKOjfQeBWd2H8xNaPucmw6/QR0CZbLc w6sWUs3W7tjqit6MZhHrQg3byg== X-Google-Smtp-Source: ABdhPJzbG8HQdteyuhWc4QVf4ywecEGTPVgQ/gXskqQCZoYcWMBEu67eGFdKD+y/+mAABCKRFZMGKQ== X-Received: by 2002:a17:90a:d14c:: with SMTP id t12mr9103176pjw.5.1613810539227; Sat, 20 Feb 2021 00:42:19 -0800 (PST) Received: from CO6PR18MB4052.namprd18.prod.outlook.com ([2603:1036:301:402a::5]) by smtp.gmail.com with ESMTPSA id b10sm9752268pgm.76.2021.02.20.00.42.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Feb 2021 00:42:18 -0800 (PST) From: Vittorio Bertocci To: Joseph Salowey , "secdir@ietf.org" CC: "draft-ietf-oauth-access-token-jwt.all@ietf.org" , "last-call@ietf.org" , "oauth@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-oauth-access-token-jwt-11 Thread-Index: ATI1NjY3HTXdqRcwZ27bx4dm5mgVQsmkXCXT X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sat, 20 Feb 2021 08:42:13 +0000 Message-ID: References: <161272369978.20616.15063633580755015902@ietfa.amsl.com> In-Reply-To: <161272369978.20616.15063633580755015902@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 08:42:27 -0000 VGhhbmsgeW91IEpvc2VwaCBmb3IgeW91ciBjb21tZW50cyENCg0KPiAxLiAgKEVkaXRvcmlhbCkg V2hhdCBpcyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQgUkZDIDc1 MjMuIA0KPiAgIFRoZXkgYXJlIHVzaW5nIEpXVCBmb3IgZGlmZmVyZW50IHB1cnBvc2VzLCBidXQg SSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8NCj4gICAgY2xhcmlmeSB0aGlzIGluIHRoZSBp bnRyb2R1Y3Rpb24uDQpHb29kIHBvaW50LCBJIGFncmVlIGl0IHdvdWxkIGJlIGdvb2QgdG8gcHJl ZW1wdCBkb3VidHMgb24gdGhpcy4gSSBhbSBzdWdnZXN0aW5nIHRvIGFwcGVuZCB0aGUgZm9sbG93 aW5nIGxhbmd1YWdlIHRvIHRoZSBjdXJyZW50IGludHJvZHVjdGlvbiAocGFyZG9uIHRoZSBYTUwp Lg0KDQpQbGVhc2Ugbm90ZTogYWx0aG91Z2ggYm90aCB0aGlzIGRvY3VtZW50IGFuZCA8eHJlZiB0 YXJnZXQ9IlJGQzc1MjMiLz4gYm90aCB1c2UgSlNPTiBXZWIgVG9rZW5zIGluIHRoZSBjb250ZXh0 IG9mIHRoZSBPQXV0aDIgZnJhbWV3b3JrLCB0aGUgdHdvIHNwZWNpZmljYXRpb25zIGRpZmZlciBp biBib3RoIGludGVudCBhbmQgbWVjaGFuaWNzLiBXaGVyZWFzIDx4cmVmIHRhcmdldD0iIFJGQzc1 MjMiLz4gZGVmaW5lcyBob3cgYSBKV1QgQmVhcmVyIFRva2VuIGNhbiBiZSB1c2VkIHRvIHJlcXVl c3QgYW4gYWNjZXNzIHRva2VuLCB0aGlzIGRvY3VtZW50cyBkZXNjcmliZXMgaG93IHRvIGVuY29k ZSBhY2Nlc3MgdG9rZW5zIGluIEpXVCBmb3JtYXQuDQoNCj4gICAgMi4gIChJc3N1ZSkgVGhlIHNw ZWNpZmljYXRpb24gZG9lcyBub3Qgc3BlY2lmeSBhbnkgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBm b3INCj4gICAgdGhlIHJlY29tbWVuZGVkIGFzeW1tZXRyaWMgYWxnb3JpdGhtcy4gIFRoaXMgd2ls bCBub3QgaGVscCBpbnRlcm9wLiAgUGVyaGFwcw0KPiAgICBzcGVjaWZ5IG9uZSBvciBib3RoIG9m ICAiUlMyNTYiIGFuZCAiRVMyNTYiLg0KVGhlIGN1cnJlbnQgdGV4dCBkb2VzbuKAmXQgbWFuZGF0 ZSBhIGZvcm1hdCBmb3IgdHdvIG1haW4gcmVhc29uczogDQotIHRoYW5rcyB0byB0aGUgQVMgbWV0 YWRhdGEgdGhlIG5lZ290aWF0aW9uIGJldHdlZW4gYSBSUyBhbmQgYW4gQVMgaXMgdmVyeSBlYXN5 IHRvIHBlcmZvcm0sIGhlbmNlIHRoZSBsaWtlbGlob29kIG9mIGludGVyb3AgaXNzdWVzIGF0IHJ1 bnRpbWUgaXMgdmVyeSBsb3cNCi0gd29ycmllcyB0aGF0IGFzIGNyeXB0byBhZHZhbmNlcywgd2hh dCB3ZSBtYW5kYXRlIGF0IHRoaXMgcG9pbnQgbWlnaHQgbm8gbG9uZ2VyIGJlIHN1aXRhYmxlLg0K VGhhdCBzYWlkLCBpZiB5b3UgZmVlbCBzdHJvbmdseSBhYm91dCB0aGlzIHBsZWFzZSBkbyBsZXQg bWUga25vdywgYW5kIEkgd2lsbCBiZSBPSyB3aXRoIGFkZGluZyBSUzI1NiBhcyBhIG1hbmRhdG9y eSBzdXBwb3J0ZWQgYWxnIGZvciBib3RoIEFTIGFuZCBSUy4NCkZyb20gYSBjdXJzb3J5IGNoZWNr LCBFUzI1NiBkb2VzbuKAmXQgc2VlbSB0byBlbmpveSBhcyB3aWRlc3ByZWFkIHN1cHBvcnQgYXQg dGhlIG1vbWVudCAoc2VlIGh0dHBzOi8vand0LmlvLyBsaWJyYXJpZXMgbGlzdCkgaGVuY2UgSSB3 b3VsZCBiZSBoZXNpdGFudCB0byBtYWtlIGl0IG1hbmRhdG9yeS4gDQoNCj4gICAgMy4gKFF1ZXN0 aW9uKSBJcyBpdCBjdXJyZW50bHkgcG9zc2libGUgdG8gdXNlIHRoZSBKV1QgYWNjZXNzIHRva2Vu IGluIGEgbW9kZQ0KPiAgICBvdGhlciB0aGFuIGEgYmVhcmVyIHRva2VuPyAgRm9yIGV4YW1wbGUg aXMgdGhlcmUgYSB3YXkgdG8gYmluZCB0aGUgSldUIHRvIGENCj4gICAgdmVyaWZpYWJsZSBrZXkg b3IgaWRlbnRpZmllci4gIElmIHRoZXJlIGlzLCB0aGVyZSBzaG91bGQgYmUgc29tZSBkaXNjdXNz aW9uIG9mDQo+ICAgIHRoaXMgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgSWYgbm90 LCBkbyB0aGUgYXV0aG9ycyBrbm93IGlmIHRoZXJlIGlzDQo+ICAgIGFueSB3b3JrIHBsYW5uZWQg aW4gdGhpcyBhcmVhPw0KQXQgdGhpcyB0aW1lLCB0aGUgbWFpbiBtZWNoYW5pc21zIHRoYXQgY2Fu IHdvcmsgd2l0aCBub24tYmVhcmVyIEFUcyBhcmUgZFBPUCBhbmQgTVRMUy4gSW4gYm90aCBjYXNl cywgdGhlIGJpbmRpbmcgbWVjaGFuaXNtIHJlbGllcyBvbiBhIGNuZiBjbGFpbSAob3IgcmVmZXJl bmNlIHRvIGl0KSAtIHdoaWNoIGNhbiBiZSBhZGRlZCB0byBhIEpXVCBhY2Nlc3MgdG9rZW4gd2l0 aG91dCBjaGFuZ2luZyBhbnkgb2YgdGhlIGd1aWRhbmNlIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4g VGhlcmUncyBhIHF1aWNrIHByaW1lciBmb3IgYm90aCBhcHByb2FjaGVzIGluIGh0dHBzOi8vYXV0 aDAuY29tL2Jsb2cvaWRlbnRpdHktdW5sb2NrZWQtZXhwbGFpbmVkLWVwaXNvZGUtMS8uIEdpdmVu IHRoYXQgdGhlcmUgYXJlIG5vIGNoYW5nZXMgaW4gdGhlIEFUIGZvcm1hdCBhbmQgdmVyaWZpY2F0 aW9uLCBhbmQgTVRMUy9EUE9QIHdvdWxkIGJlIHB1cmVseSBhZGRpdGl2ZSwgYW55IGxhbmd1YWdl IGhlcmUgd291bGQgbGlrZWx5IGJlIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IHRvICJZb3Ugc2hv dWxkIGJlIGF3YXJlIHRoYXQgTVRMUyBleGlzdHMsIGFuZCB0aGUgdG9rZW5zIGRlZmluZWQgaGVy ZSBkbyBub3QgYnJlYWsgaXQiIChEUE9QIGlzbuKAmXQgbWVudGlvbmVkIGJlY2F1c2UgaXQncyBz dGlsbCBpbiBwcm9ncmVzcykgYnV0IG15IGludHVpdGlvbiBpcyB0aGF0IHRoZSBjb21wYXRpYmls aXR5IHNob3VsZCBiZSBhc3N1bWVkLCB3aXRoIGEgbm90ZSBiZWluZyByZXF1aXJlZCB3aGVuIGl0 J3Mgbm90IHRoZSBjYXNlIGFuZCB0aGUgcmVhZGVyIHNob3VsZCBiZSBhd2FyZSBvZiBwb3RlbnRp YWwgcHJvYmxlbXMuIFdoYXQgZG8geW91IHRoaW5rPyAgDQoNCg0K77u/T24gMi83LzIxLCAxMDo0 OCwgIkpvc2VwaCBTYWxvd2V5IHZpYSBEYXRhdHJhY2tlciIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdy b3RlOg0KDQogICAgUmV2aWV3ZXI6IEpvc2VwaCBTYWxvd2V5DQogICAgUmV2aWV3IHJlc3VsdDog SGFzIElzc3Vlcw0KICAgIA0KICAgIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCiAgICBvbmdvaW5nIGVmZm9ydCB0byBy ZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCiAgICBJRVNH LiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlDQogICAgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQogICAgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgDQogICAgVGhlIHN1bW1hcnkgb2YgdGhl IHJldmlldyBpcyB0aGUgZG9jdW1lbnQgaGFzIGlzc3Vlcy4NCiAgICANCiAgICAxLiAgKEVkaXRv cmlhbCkgV2hhdCBpcyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQg UkZDIDc1MjMuIA0KICAgIFRoZXkgYXJlIHVzaW5nIEpXVCBmb3IgZGlmZmVyZW50IHB1cnBvc2Vz LCBidXQgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgdG8NCiAgICBjbGFyaWZ5IHRoaXMgaW4g dGhlIGludHJvZHVjdGlvbi4NCiAgICANCiAgICAyLiAgKElzc3VlKSBUaGUgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBzcGVjaWZ5IGFueSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50IGZvcg0KICAgIHRo ZSByZWNvbW1lbmRlZCBhc3ltbWV0cmljIGFsZ29yaXRobXMuICBUaGlzIHdpbGwgbm90IGhlbHAg aW50ZXJvcC4gIFBlcmhhcHMNCiAgICBzcGVjaWZ5IG9uZSBvciBib3RoIG9mICAiUlMyNTYiIGFu ZCAiRVMyNTYiLg0KICAgIA0KICAgIDMuIChRdWVzdGlvbikgSXMgaXQgY3VycmVudGx5IHBvc3Np YmxlIHRvIHVzZSB0aGUgSldUIGFjY2VzcyB0b2tlbiBpbiBhIG1vZGUNCiAgICBvdGhlciB0aGFu IGEgYmVhcmVyIHRva2VuPyAgRm9yIGV4YW1wbGUgaXMgdGhlcmUgYSB3YXkgdG8gYmluZCB0aGUg SldUIHRvIGENCiAgICB2ZXJpZmlhYmxlIGtleSBvciBpZGVudGlmaWVyLiAgSWYgdGhlcmUgaXMs IHRoZXJlIHNob3VsZCBiZSBzb21lIGRpc2N1c3Npb24gb2YNCiAgICB0aGlzIGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucy4gIElmIG5vdCwgZG8gdGhlIGF1dGhvcnMga25vdyBpZiB0aGVy ZSBpcw0KICAgIGFueSB3b3JrIHBsYW5uZWQgaW4gdGhpcyBhcmVhPw0KICAgIA0KICAgIDQuIEdl bmFydCByZXZpZXcgcG9pbnRlZCBvdXQgYSBuaXQgdGhhdCBzaG91bGQgYmUgZml4ZWQuDQogICAg DQogICAgDQogICAgDQogICAgDQo= From nobody Sat Feb 20 01:07:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F01E3A0D78 for ; Sat, 20 Feb 2021 01:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIw_s9UriGvM for ; Sat, 20 Feb 2021 01:07:49 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC4C3A0D7A for ; Sat, 20 Feb 2021 01:07:48 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id q10so14713840edt.7 for ; Sat, 20 Feb 2021 01:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=eotYQiL2sigozJGkisbu5WFX8MK6MeXZ8yyCVol5bsQ=; b=VBF1LGRucwM9duHU76h3Zlxy9fXcmEZcfEdIlMWcbEQOiu5lf/+3MCTbZ0cNxxEdJh jj/qG+rmWxHu+jbZj8Zeylwp3bwSedRD+4Zr+2+sTs+YD3t3t7nP7JMjDCuRRUC9lkQd xT+mre5rlARy1IJWGyOBzHREtz7RApgP1UW+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=eotYQiL2sigozJGkisbu5WFX8MK6MeXZ8yyCVol5bsQ=; b=lc8EZADeJvkdGYoFekdpcZ68KQmFzkTx9j/UeDNg1AsmakRHt2yXnO8YEbqpzAtUnI te2WA+X4USS4yzlsuOpl/DdVDVFAoKGGAAHSVjbj9B0D/dbI7PBGuPtfxuFRhcmf7QWQ JeLlnYpi3n6dsmXNdTQwWDdzojvnmHtKGrb/l7/vX3yVK0Zlurns1+wmeIjS5kkjM9hL F1RnZeJLFmHm2iYM7+9UOBprfHO1dVeh0OT2zYTjh9wP1SCS8l9G07N7StLDm/ghmbi2 MKJfGDAjvpjPuvL6FtxR9nf+xA0PWryDTumnFPcWfd9MHGEcX9EH78H8SDY7xxRP1vpE 9AuQ== X-Gm-Message-State: AOAM530NnvJDSvCMsNLz4Cdvrr2O56uadSznVzKbrGLIjS3uz2T8cLhz h2MdH/SSHRAR0cToiIGEx/HxiAuLpel9DljAHeVV7ToZRzSYNFPmzHZx5/Za9jGTvtDRhWEfog= = X-Google-Smtp-Source: ABdhPJy+5FlFfrNsulYMWUbFJ2SBRpVKEOhqLVutWwU4QLIY0N8eTw0LiWNRAyQBcfSCMSkrapFqZA== X-Received: by 2002:a05:6402:31a5:: with SMTP id dj5mr639181edb.388.1613812066711; Sat, 20 Feb 2021 01:07:46 -0800 (PST) Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id t19sm5970648ejc.62.2021.02.20.01.07.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Feb 2021 01:07:46 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sat, 20 Feb 2021 09:07:44 +0000 Message-Id: <0A6F50FE-2C69-43CA-BEC4-2DE68A7EDF2A@forgerock.com> References: Cc: Vittorio Bertocci , oauth In-Reply-To: To: Brian Campbell X-Mailer: iPhone Mail (18D52) Content-Type: multipart/alternative; boundary=Apple-Mail-7C35BA20-C1C0-4E52-AA6D-8CAE98F5B195 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 09:07:53 -0000 --Apple-Mail-7C35BA20-C1C0-4E52-AA6D-8CAE98F5B195 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was mentioning it primarily as another example of the assumption that GET= requests are safe. However, the draft rfc6265bis [1] does seem concerned a= bout this, and mentions as a possible attack vector.= This would again potentially pull the access token into the renderer=E2=80= =99s memory space (until site isolation becomes widespread).=20 I also have a general dislike of SameSite cookies as a defence against CSRF= . There are CSRF-like attacks that are not strictly cross-*site* but are cr= oss-origin (CORF?). For example, subdomain hijacking is relatively common [= 2] and completely defeats SameSite. As the draft itself says [3]: "SameSite" cookies offer a robust defense against CSRF attack when deployed in strict mode, and when supported by the client. It is, however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other attack vectors such as cross-site scripting. Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are idempotent, etc) to mitigate the risk more fully. If we recommend SameSite for this, IMO we should do so only with the same c= aveats expressed in the httpbis draft.=20 [1]: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-5= .3.7.1 [2]: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers# [3]: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-07#section-8= .8.1 Cheers, Neil > On 19 Feb 2021, at 23:18, Brian Campbell wro= te: >=20 > =EF=BB=BF > Thanks Neil,=20 > Appreciate the insight and recommendations. I think we can incorporate th= at, more or less, into the next revision.=20 > One point to dig into just a bit more, you said that 'SameSite has a "GET= -out clause" in the form of =E2=80=9Clax=E2=80=9D'. As I understand it, suc= h a cookie would still only be sent on a cross-site GET resulting from a to= p-level navigation. And in the context of the bff-token endpoint, that sig= nificantly reduces the ways a cross-site request could be initiated and tho= se ways (pop-up or full page redirection) further limits the likelihood of = the malicious party being able to read response data.=20 >=20 >> On Thu, Feb 18, 2021 at 5:08 AM Neil Madden = wrote: >> Thanks for following up, Brian. Responses below. >>=20 >>> On 17 Feb 2021, at 22:48, Brian Campbell w= rote: >>>=20 >>> Always appreciate (and often learn from) your insights, Neil. I'd like = to dig into the CSRF thing a bit more though to understand better and hopef= ully do the right thing in the draft.=20 >>>=20 >>> It seems to me that a GET at the bff-token endpoint is "safe" in that i= t's effectively just a read. >>=20 >> Well it=E2=80=99s a read that returns an access token. It=E2=80=99s =E2= =80=9Csafe=E2=80=9D in the sense of side-effects, but we absolutely want to= preserve the confidentiality of what is returned and only allow it to be a= ccessed by authorized clients (the legitimate frontend). At the moment the = only thing keeping that safe is the JSON content type. For example, imagine= a world in which the token-bff endpoint instead returned the access token = as HTML: >>=20 >>
abcd
>>=20 >> Then as an attacker I can simply embed an iframe on my site that refers = to your bff-endpoint and then parse the access token out of the DOM. The br= owser will happily load that iframe and send along the cookie when it makes= the request. If you have CORS enabled on your site (with Access-Control-Al= low-Credentials) then any of the allowed CORS origins can directly call the= bff-token endpoint and read the access token even in JSON form. There have= also been historical same-origin policy bypasses using Flash, Adobe Reader= , or other plugins (thankfully now largely eliminated), or by redefining Ja= vaScript prototypes - see https://haacked.com/archive/2009/06/25/json-hijac= king.aspx/ . These are largely fixed, but I wouldn=E2=80=99t bet on there n= ever being another one. >>=20 >>=20 >>> There could be a "cache miss" where the backend attempts to use a refre= sh token it has to get a new access token from the remote AS, which will be= more resource intensive but doesn't fundamentally alter the state of the b= ackend so is still "safe". That in conjunction with your pointing to Cross-= Origin Read Blocking makes me think your concern isn't so much about tradit= ional CSRF used to take some malicious action but rather about somehow (spe= culative side-channel attacks, problems with javascript interpreters, other= similar vectors that are somewhat beyond me) accessing the data of the res= ponse to a forged cross site request. Correct me if I'm wrong. I don't know= if or how much the distinction matters in terms of mitigation approach but= I'm keen to better understand. =20 >>=20 >> As explained above, because the endpoint returns JSON it _should_ be imp= ossible to directly read the response from a cross-origin read (unless expl= icitly enabled with CORS). But you may still be able to embed that response= in an or similar. Because people are terrible at setting correct Con= tent-Type headers on responses, browsers often ignore them and instead try = to sniff what the real content type is: so if the response looks a bit like= a valid image format (or PDF or JavaScript or whatever) then it might try = and render it. No doubt this will fail, but at that point the data has alre= ady been loaded into the address space of the renderer process for the atta= cker=E2=80=99s site. That means that it is then vulnerable to attacks like = Spectre that bypass normal memory protection. The browser vendors consider = this to be a real threat, hence CORB. >>=20 >> The most important thing for a cookie-based JSON API to do is to return = a correct Content-Type header and to also return X-Content-Type-Options: no= sniff to prevent browsers from trying to sniff the real content-type. (I ha= ve an example in my book where the failure to do this can actually turn a J= SON API into a vector for XSS attacks, even if you have no SPA frontend com= ponent at all). >>=20 >> (You should also mark the cookie as HttpOnly because this prevents the c= ookie ever entering the address space of a renderer process in modern brows= ers - an actual genuine security benefit of HttpOnly cookies). >>=20 >> But my worry is that this is still basically trusting the client to perf= orm critical security checks, and historically browsers have had plenty of = bypasses in this area. So for something as high-value as an access token I= =E2=80=99d prefer that any request using cookie-based authentication is pro= tected by proactive CSRF defences to prevent malicious requests being allow= ed in the first place. >>=20 >>>=20 >>> It sounds like your preference for only POST rests in an assumption tha= t the larger app will already have in place some CSRF defenses and by using= POST the bff-token endpoint will basically inherit said defenses. Or is PO= ST by itself good enough (the CORB writeup seems to suggest that the contex= t in which a POST could be made is more guarded against side channel stuff)= ? But perhaps then the draft should be more explicit about CSRF defense? S= aying it just has to be done. Or like even mandating a non-standard header = be in the request, "X-Neil-says-beware-CSRF: yuppers" as a strawman. With s= uch a header it could remain a GET. And I kinda like GET because it is real= ly a request for data. Or perhaps the request should be a POST with built-= in CSRF protection by changing it to carry any parameters as JSON in the bo= dy with "{}" for the case of no parameters specified? Or just make it a PU= T and call it good? Not sure any of these are good ideas but just trying to= hash out the most appropriate thing to do.=20 >>=20 >> Right, the preference for POST is because it's more likely to trigger CS= RF defences, which often consider GET/HEAD requests to be =E2=80=9Csafe=E2= =80=9D. Even before Spectre, there is a whole array of side-channel attacks= for extracting information from cross-site responses: https://xsleaks.dev = . Note that even SameSite has a "GET-out clause" in the form of =E2=80=9Cla= x=E2=80=9D. >>=20 >> So yes, the real requirement is that the endpoint should have adequate C= SRF protection. Requiring a special header has had bypasses in the past (ag= ain, mostly using Flash). >>=20 >> So I think we should recommend the following: >>=20 >> 1. The response MUST contain a correct Content-Type: application/json he= ader and X-Content-Type-Options: nosniff. >> 2. The cookie SHOULD be marked as HttpOnly. >> 3. The endpoint MUST NOT be accessible via CORS. >> 4. The endpoint SHOULD have adequate CSRF protections in place. At a min= imum the cookie should be marked as SameSite.=20 >>=20 >> We could perhaps add an informational reference to https://cheatsheetser= ies.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet= .html given that there is a changing landscape around cookies at the moment= . If the browser vendors do eliminate 3rd-party cookies then 1, 3, and 4 be= come largely unnecessary (although 3 might still be a risk due to sub-domai= n hijacking, and 1 will always be good practice). >>=20 >> =E2=80=94 Neil >>=20 >>>=20 >>> That got a little rambly, sorry. But hopefully it makes some sense.=20 >>>=20 >>>> On Sun, Feb 14, 2021 at 1:17 AM Neil Madden wrote: >>>>=20 >>>> The combination of the bff-token endpoint recommending the use of GET = requests together with the hint to use cookie-based authentication is likel= y going to punch a hole in most CSRF defenses, which assume that GETs are s= afe. The only thing preventing this being exploitable is Cross-Origin Read = Blocking (https://chromium.googlesource.com/chromium/src/+/master/services/= network/cross_origin_read_blocking_explainer.md) due to the JSON content-ty= pe. That makes me really nervous. We should at least mandate X-Content-Type= -Options: nosniff on that response. I=E2=80=99d feel more comfortable if th= is was a POST request only.=20 >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. >>=20 >>=20 >> ForgeRock values your Privacy >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d material for the sole use of the intended recipient(s). Any review, use, = distribution or disclosure by others is strictly prohibited. If you have r= eceived this communication in error, please notify the sender immediately b= y e-mail and delete the message and any file attachments from your computer= . Thank you. --=20 ForgeRock values your Privacy --Apple-Mail-7C35BA20-C1C0-4E52-AA6D-8CAE98F5B195 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was mentioning it pr= imarily as another example of the assumption that GET requests are safe. Ho= wever, the draft rfc6265bis [1] does seem concerned about this, and mention= s <link rel=3Dprerender> as a possible attack vector. This would agai= n potentially pull the access token into the renderer=E2=80=99s memory spac= e (until site isolation becomes widespread). 
I also have a general dislike of SameSite cookies = as a defence against CSRF. There are CSRF-like attacks that are not strictl= y cross-*site* but are cross-origin (CORF?). For example, subdomain hijacki= ng is relatively common [2] and completely defeats SameSite. As the draft i= tself says [3]:

<quote&= gt;

   "SameSite" cookies offer a robust defense against CSRF attac=
k when
   deployed in strict mode, and when supported by the client.  It is,
   however, prudent to ensure that this designation is not the extent of
   a site's defense against CSRF, as same-site navigations and
   submissions can certainly be executed in conjunction with other
   attack vectors such as cross-site scripting.

   Developers are strongly encouraged to deploy the usual server-side
   defenses (CSRF tokens, ensuring that "safe" HTTP methods are
   idempotent, etc) to mitigate the risk more fully.
</quote>

If we recommend SameSite for this,= IMO we should do so only with the same caveats expressed in the httpbis dr= aft. 



=
=EF=BB=BF
Thanks Neil,
Appreciate the insight and recommendations. I think we can incorporate tha= t, more or less, into the next revision.
One point to dig in= to just a bit more, you said that 'SameSite has a "GET-out clause" in the f= orm of =E2=80=9Clax=E2=80=9D'. As I understand it, such a cookie would stil= l only be sent on a cross-site GET resulting from a top-level  navigat= ion. And in the context of the bff-token endpoint, that significantly reduc= es the ways a cross-site request could be initiated and those ways (pop-up = or full page redirection) further limits the likelihood of the malicious pa= rty being able to read response data.

On Thu, Feb 18, 2021 at 5:0= 8 AM Neil Madden <neil.madden@forgerock.com> wrote:
Thanks for following up, Brian. Resp= onses below.

On 17 Feb 2021, at 22:48, Brian Cam= pbell <b= campbell@pingidentity.com> wrote:

Always appreciate (and often learn from) your insights, Neil. I'd like to= dig into the CSRF thing a bit more though to understand better and hopeful= ly do the right thing in the draft.

It seems = to me that a GET at the bff-token endpoint is "safe" in that it's effective= ly just a read.

Well it= =E2=80=99s a read that returns an access token. It=E2=80=99s =E2=80=9Csafe= =E2=80=9D in the sense of side-effects, but we absolutely want to preserve = the confidentiality of what is returned and only allow it to be accessed by= authorized clients (the legitimate frontend). At the moment the only thing= keeping that safe is the JSON content type. For example, imagine a world i= n which the token-bff endpoint instead returned the access token as HTML:

<div id=3D=E2=80=9CaccessToken=E2=80=9D>abcd&= lt;/div>

Then as an attacker I can simply embed= an iframe on my site that refers to your bff-endpoint and then parse the a= ccess token out of the DOM. The browser will happily load that iframe and s= end along the cookie when it makes the request. If you have CORS enabled on= your site (with Access-Control-Allow-Credentials) then any of the allowed = CORS origins can directly call the bff-token endpoint and read the access t= oken even in JSON form. There have also been historical same-origin policy = bypasses using Flash, Adobe Reader, or other plugins (thankfully now largel= y eliminated), or by redefining JavaScript prototypes - see https://haacked.com/archive/2009/06/25/json-hijacking.aspx/ .= These are largely fixed, but I wouldn=E2=80=99t bet on there never being a= nother one.


There could be a "cache miss" where the backend at= tempts to use a refresh token it has to get a new access token from the rem= ote AS, which will be more resource intensive but doesn't fundamentally alt= er the state of the backend so is still "safe". That in conjunction with yo= ur pointing to Cross-Origin Read Blocking makes me think your concern isn't= so much about traditional CSRF used to take some malicious action but rath= er about somehow (speculative side-channel attacks, problems with javascrip= t interpreters, other similar vectors that are somewhat beyond me) accessin= g the data of the response to a forged cross site request. Correct me if I'= m wrong. I don't know if or how much the distinction matters in terms of mi= tigation approach but I'm keen to better understand. 
=

As explained above, because the endp= oint returns JSON it _should_ be impossible to directly read the response f= rom a cross-origin read (unless explicitly enabled with CORS). But you may = still be able to embed that response in an <img> or similar. Because = people are terrible at setting correct Content-Type headers on responses, b= rowsers often ignore them and instead try to sniff what the real content ty= pe is: so if the response looks a bit like a valid image format (or PDF or = JavaScript or whatever) then it might try and render it. No doubt this will= fail, but at that point the data has already been loaded into the address = space of the renderer process for the attacker=E2=80=99s site. That means t= hat it is then vulnerable to attacks like Spectre that bypass normal memory= protection. The browser vendors consider this to be a real threat, hence C= ORB.

The most important thing for a cookie-based J= SON API to do is to return a correct Content-Type header and to also return= X-Content-Type-Options: nosniff to prevent browsers from trying to sniff t= he real content-type. (I have an example in my book where the failure to do= this can actually turn a JSON API into a vector for XSS attacks, even if y= ou have no SPA frontend component at all).

(You sh= ould also mark the cookie as HttpOnly because this prevents the cookie ever= entering the address space of a renderer process in modern browsers - an a= ctual genuine security benefit of HttpOnly cookies).

But my worry is that this is still basically trusting the client to perf= orm critical security checks, and historically browsers have had plenty of = bypasses in this area. So for something as high-value as an access token I= =E2=80=99d prefer that any request using cookie-based authentication is pro= tected by proactive CSRF defences to prevent malicious requests being allow= ed in the first place.

It sounds like your preference for only POST rest= s in an assumption that the larger app will already have in place some CSRF= defenses and by using POST the bff-token endpoint will basically inherit s= aid defenses. Or is POST by itself good enough (the CORB writeup seems to s= uggest that the context in which a POST could be made is more guarded again= st side channel stuff)?  But perhaps then the draft should be more exp= licit about CSRF defense? Saying it just has to be done. Or like even manda= ting a non-standard header be in the request, "X-Neil-says-beware-CSRF: yup= pers" as a strawman. With such a header it could remain a GET. And I kinda = like GET because it is really a request for data.  Or perhaps the requ= est should be a POST with built-in CSRF protection by changing it to carry = any parameters as JSON in the body with "{}" for the case of no parameters = specified?  Or just make it a PUT and call it good? Not sure any of th= ese are good ideas but just trying to hash out the most appropriate thing t= o do.

Right, the pre= ference for POST is because it's more likely to trigger CSRF defences, whic= h often consider GET/HEAD requests to be =E2=80=9Csafe=E2=80=9D. Even befor= e Spectre, there is a whole array of side-channel attacks for extracting in= formation from cross-site responses: https://xsleaks.dev . Note that even SameSite has= a "GET-out clause" in the form of =E2=80=9Clax=E2=80=9D.

So yes, the real requirement is that the endpoint should have adequ= ate CSRF protection. Requiring a special header has had bypasses in the pas= t (again, mostly using Flash).

So I think we shoul= d recommend the following:

1. The response MUST co= ntain a correct Content-Type: application/json header and X-Content-Type-Op= tions: nosniff.
2. The cookie SHOULD be marked as HttpOnly.
=
3. The endpoint MUST NOT be accessible via CORS.
4. The endp= oint SHOULD have adequate CSRF protections in place. At a minimum the cooki= e should be marked as SameSite. 

We could per= haps add an informational reference to https://cheatsheetseries.owasp.org/cheatsheets/Cr= oss-Site_Request_Forgery_Prevention_Cheat_Sheet.html given that th= ere is a changing landscape around cookies at the moment. If the browser ve= ndors do eliminate 3rd-party cookies then 1, 3, and 4 become largely unnece= ssary (although 3 might still be a risk due to sub-domain hijacking, and 1 = will always be good practice).

=E2=80=94 Neil

Th= at got a little rambly, sorry. But hopefully it makes some sense.

On Sun, Feb 14, 2021 at 1:17 AM Neil Madden <neil.madden@forgerock.com>= wrote:

The combination of the bff-token endpoint recommending the use of = GET requests together with the hint to use cookie-based authentication is l= ikely going to punch a hole in most CSRF defenses, which assume that GETs a= re safe. The only thing preventing this being exploitable is Cross-Origin R= ead Blocking (https://chromium.googlesource.com/chromium/src/+/master/services/net= work/cross_origin_read_blocking_explainer.md) due to the JSON content-t= ype. That makes me really nervous. We should at least mandate X-Content-Typ= e-Options: nosniff on that response. I=E2=80=99d feel more comfortable if t= his was a POST request only. 

=E2=80=94 Neil=


CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.  If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.


ForgeRock values your Privacy
<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .  If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
ForgeRock values your Privacy --Apple-Mail-7C35BA20-C1C0-4E52-AA6D-8CAE98F5B195-- From nobody Sat Feb 20 09:28:56 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1253A1564 for ; Sat, 20 Feb 2021 09:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEqVw2f0veNi for ; Sat, 20 Feb 2021 09:28:52 -0800 (PST) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F15D3A15B6 for ; Sat, 20 Feb 2021 09:28:51 -0800 (PST) Received: by mail-yb1-xb2c.google.com with SMTP id c131so8786813ybf.7 for ; Sat, 20 Feb 2021 09:28:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aN8iJ9QTKzoaVcfEIBSmKo9jpHn6dx9r8v955/vlmrk=; b=qx0bQ8BCm3Liwr15vjScDQmQXpfQ6xM8EVLP5S8dvE3ZRvj6PZYd2pdqDVP/luirG5 23zcQuVWQaqfp8QsHXSmmV0hV8s5BALUYn4Yx4yUf6vUKpi2pz/gom+cIUdGaULdJKRo RcaCxwfp4brP72pNVU2ZfE/vfGxLeSQ6sC16xVqUTG6wIWAhmkWQmkT4HQ+1SZy0PP/6 /7BF2ueBqDdGwim7sBcTFxfIFKxHa7mqSWX69JdA2v6AShJkpiuKuzcY4+d62R8UTJiJ xtC0TMnI6+3J6g1OR9Z9sdEf6EuZ9qJOwkW3Ajoq2WUlSKdacUwat/0dXdsdRn2EsW6O jFRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aN8iJ9QTKzoaVcfEIBSmKo9jpHn6dx9r8v955/vlmrk=; b=ACbAfxBGDSZ6f1FKo4ZsTBJeGDT5QUzzknJ9bfYSmhYvKP+04hQSHozRfEWl5v06Xp fNCTYLWVFhAIrzEsZ+38k1Ws7CrVtfMuN3r73KrdR4jp7fy3zbTnPiBtC7AUS1qkA7ko 9MT3TIf1m6poQ5s+kyKOvnp53PnAdHdS7W5249DGcH218GMp9+5e/N6nBcb0NLEtWz0+ 56Ib2AgvMK6lZWkM7rPjBYHG50vq6uf7FYizY3bV8TdPe4qxC+Wl7QXU0ZxNhOr9UOC7 dHCFLYgMi9MrA++kzmqRuhhfYycXxFRFG+W0+nF4LLkxG3JsbcCpM37zb+jBIHim3aN+ T5wA== X-Gm-Message-State: AOAM532n6Z7HxysO45DMGqVhTgBFiwMsKdd8U7U3YRyAtWRP2Qx+H7ey k9EQU/vDcI7hmN7uQV8Dij5cNXQqvQWm0HSLqo7HoIsxPqAbgA== X-Google-Smtp-Source: ABdhPJxvrjflJDHJqQdmFuWv2FHtp0SyP2XN3UxRtgFwMadrzbHf33Nr8zs8lcvH226mufqTA96gIfzPgXTyapBmUbg= X-Received: by 2002:a25:2186:: with SMTP id h128mr20522386ybh.369.1613842130853; Sat, 20 Feb 2021 09:28:50 -0800 (PST) MIME-Version: 1.0 References: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> In-Reply-To: From: Travis Spencer Date: Sat, 20 Feb 2021 18:28:40 +0100 Message-ID: To: Brian Campbell Cc: rfc-ise@rfc-editor.org, draft-ideskog-assisted-token@ietf.org, oauth Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 17:28:54 -0000 On Fri, Feb 19, 2021 at 10:09 PM Brian Campbell wrote: > Publishing an independent stream RFC that runs contrary to the BCP > coming out of the WG does seem potentially harmful. > > On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) wrote: >> I want to be sure that ... there is no perceived harm to existing >> OAuth work if this goes ahead It is my understanding that the procedure that an informational RFC goes through is that if "(a) the IESG recommends that the document be brought within the IETF and progressed within the IETF context, but the author declines to do so, or (b) the IESG considers that the document proposes something that conflicts with, or is actually inimical [i.e., 'harmful'] to, an established IETF effort, the document may still be published as an Experimental or Informational RFC," (RFC 2026, section 4.2.3). RFC 5742 updates this with a "compatible" description that states in section 3 that the IESG review of an independent submission may recommend not to publish the draft because the IESG "concluded that publication could potentially disrupt the IETF work done in WG ". My question is how could this draft disrupt this working group's work? Is it because it will be unclear to the market what advice they should follow when implementing single page applications? That could be a reason, some may argue, to not publish this document by this working group. This is not justification, in my opinion, however, for recommending that it not at least be published outside this working group. I say this because RFC 7221 says in section 5.3 that "[e]ngineering for interesting topics often produces competing, interesting proposals... Although it is far more comfortable to entertain only one proposal, a working group is free to pursue more than one. Often this is necessary until a clear preference develops. Sometimes, multiple versions are formally published, absent consensus among the alternatives." RFC 7221 goes on to describe how to deal with competing drafts. We feel that we have followed those guidelines for the betterment of all. For instance, we have contributed to the BCP that Brian mentioned[1], and agree that this is a good set of recommendations. The results proposed in the BCP are ones that our customers will hopefully follow when applicable. The combined results in the BCP do not detract from the usefulness of the assisted token protocol we have defined, in my opinion. This should not surprise us when we consider that we "IETF participants devise solutions for the global Internet that meet the needs of diverse technical and operational environments," (RFC 7153, section 3). This diversity will require multiple methods to solve a wide array of problems. This need is reflected in the enthusiasm of reviewers' comments I have received since draft 4 was published recently wherein one reviewer states, that they are "looking forward to see the assisted token endpoint being implemented by clients and IdPs." I have received similar comments before as well. This leads me to conclude that it isn't just me that thinks that this protocol is generally useful. Furthermore, RFC 7221 also says in section 5.2 that "If a working group drops a draft, then anyone is permitted to pursue it as an Individual or Independent Submission." While the working group never adopted this draft, the implication of the statement is that any I-D that the working group opted not to take up can also be submitted to the independent stream. One of the reasons for this non-standard track, as stated in RFC 4846 section 2, is to describe "Documents considered by IETF Working Groups but not standardized." Another is to give place to dissenting views, so they can reach the broader Internet community when consensus cannot be established within a working group. If a working group has the possibility to prevent publication outside of its boundaries (e.g., in the independent stream), this purpose of an alternative publication venue cannot be achieved. When I read RFC 4846, I am left with the view that this is one of the primary purposes of the independent stream. There it says in section 2: Independent Submissions are especially important as checks on the IETF processes even though such checks are not the only, or even a common, reason for them. That role is compromised if IETF- related entities are able to block or deprecate such documents to a degree beyond that needed to avoid difficulties with the standards process....Independent Submissions have become important....[because they include] ....Critiques and discussions of alternatives to IETF Standards-Track protocols. The potential for such critiques provides an important check on the IETF's standards processes and should be seen in that light. For this reason, I think the OAuth working group should either accept this document (though I'm not sure I'm willing to yield control of it any longer) or not hinder its publication outside the group. If the IESG recommends that it not be published as an independent publication, I would ask for very clear explanation of the harm it does to this working group's efforts beyond "we have a BCP for single page apps." Another purposes of the independent stream, also stated in RFC 4846 section 2, is for the "publication of vendor-specific protocols". Even if no other vendor or authorization server adopts the assisted token flow, it is useful to describe it in an open manner. This allows for open dialog and is our explicit request for comments on our work. A final reason to ratify this document as an RFC (in this working group or the independent stream) that I'll mention here is for the sake of interoperability. Our product supports this protocol already. To help with those seeking to interoperate with it, a ratified RFC would align with the broader Internet community's best interests, in my view. The fact that this protocol is already implemented by at least one vendor aligns with the IETF's credo that we, as an community, value running code.[2] Our adherence to this aim is further reflected in our publication of multiple open source client libraries[3] and explanations of the protocol in various other Internet forums.[4, 5] Therefore, I firmly believe that this working group cannot prevent publication of this I-D in the independent stream. I used to think that it would be better that it was worked on in this group, but have accepted the consensus opinion the body voiced at IETF 101 that they would not accept it. For this reason, we have submitted it outside of this group and expect that work to conclude without prevention by this working group. If this expectation is set by an incorrect understanding of the purpose of the independent stream, I welcome objective facts from cited RFCs, bylaws, etc. that will clarify how my view is inaccurate. If it is correct but this group believes this work should not be published independently because it would disrupt its own, I welcome a clear and complete explanation of how. [1] https://github.com/travisspencer/draft-ietf-oauth-security-topics/commit/ef94ccd0784341e4fedb4c6fdc5afb4fea058cd4 [2] https://tools.ietf.org/html/rfc7282#section-1 [3] https://github.com/curityio?q=assisted [4] https://www.youtube.com/watch?v=h_wT-58L5ZY [5] https://zisc.ethz.ch/oauth-security-workshop-2017/ From nobody Mon Feb 22 09:27:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BFB3A1F23 for ; Mon, 22 Feb 2021 09:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQHFM7hgPOvB for ; Mon, 22 Feb 2021 09:27:39 -0800 (PST) Received: from sonic304-21.consmr.mail.ne1.yahoo.com (sonic304-21.consmr.mail.ne1.yahoo.com [66.163.191.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5263A1EFF for ; Mon, 22 Feb 2021 09:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1614014848; bh=UVh65XIGIggG38ieUQVwXLtXwm5sr6vS10QWUqhUCyQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=bzyyJeB3qfyOjOsmKZ+jlqGp/Vuul+f0zsR8K0DwwuK8B2PV5OLyJVTBTN+CRDn2g10+w1MY0hw5LJk5qnpdYksaAqc209gPr6W6o5OuZUBzyqqbOrgwnRfvQ34vDEP0FFKH07jzPNBdbJ3aySEMdiH2ZignGxqcV6fCXg/v7ka+ACrv+CxsJ2poaLIwWicARgkMG0LX8i7Fz9SEidVE+Np5LKvCmh91YF1jAUUCismBOZKTVvqREdShEimhNi07qRnlGdtchbuenH4eol1NOB3ypGBKStPMveco7FwvemhQn51LJ57exBsFWoNnmdxXMnq98gBi6AWZjAxLoxwnTQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614014848; bh=rwOlJrZuOOtLwz1B8uGaydERIrXboS5y15nfe6MWi93=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=SsR26crohmDbbRfhlfUtJ6zJRtr88bitHpA1YnsFwwafv0vMf6MYzxFlk6u0fZkoTVVmflwQ0Wxb9kF0PnKkQKShRpr15vALOIB3YJ8yoXEcX/YCjCFtZ5WSeW/SI3q16LxrtbX6yD0ifwntPE+fy2xNxl/H23OXcZAA0JBMmnSSNTi/V/thfbA8TVX6NuEh6vcSfCd/2yK3b5l7zG9A/MLvyyDyJ9Dxh4D7RXi+y9dKaiZ1fBD07KlBgAq8U/TS2hc3kYMwkP0laBuRbgyExfP0TowSplWVPHD7razGWWj66w1FHkYvmjjN/jKxo+ivkJStha6jjjk8RIu9ee9KNw== X-YMail-OSG: ddt8tq0VM1nrMiCCGM5qa2Ihd8JA97s0LnORl2e9P.rtm3Su32p_HmdYKXBPCTw aPRG_la5ep1l0RUEoh4m5gXo3q.6iHmjW7no9imN.U41RloFmSxHu1_fW_m6xT5OUBYklG_1lj2g fMpgNwt6FI6.Ux85l5UBiMrKIAqyDJotiXtVrYIOMucTXLJI3HxHnidAtVNzULLxyQ.awNeaXO7j s1iGRyYceMHnFJLEtgowLg8wQwyc3X6W7qz3BJyzkmbuwLQ.C3OMwk3NGkbF648eMvQwqQA9_BJy lFsLLOgY9mVfieYLdyNGo92QuYCrFYORKa0ohcN6B382WDe6D5aziE77WoJj.0NOrLY69C8MT7nb iyFA1vNq12ifXmCpIxL7ROXaVK80R_emzQCsGdChODvd9RAYLHla6aWruCB7RFl_c5pFsmfytFAj U0pwpkljFoI_SBX.jehB1SKEQmH_ihoDSNOQAM4zw7KTK8g0jtnxsjt695YETpFmZMdBxMJW4A4W hW7g_rR1U8CCYbeUoTrM.wHR_xhogyoo3dtauFTAWiiw3cdr9vtWi_RO9RaZzyvBy4CLuVQ0HFu6 k7umM2hUSrjFqolRoM4ruwqzu2ZWi2YlN7HDe3C6jiZbh.IqOl.aBSqFpj4HWy1zfjKJM0AmGFRa bc7fvFC368KBKkcc_4rbPNsATfeJ5vWkYsomLb8WvXQQhrLoqSeuO7YQq5nHvKLuS0_AyB.GkRlw lYzFUnzcPipC_yiNKQ61GhPJjsBt4JhsOv7mFUCX1jtTZBjXVMGM1aoy_towGv.cxD.CGvnsSVzz XHLfqFhYt9x2wUJK7Ksd2u20xN1kEDquKi.BtXHKizq.H_dgCAiYTK.CF69YINWT1CBi7GBgzP4j fPDLdXXbAme9HZbjUs_m_L3uBk62sbNwMb_RR_ATCN0Q3qi6NAS4qL8YslcnuLtw80lHIdGLPDrd 8u0fDBu5Wc8592erzulnKZWKnezQn1PF2MKzxFacF6hBGFDjCJAWOxCZrc6s_C16YyrrhVhdw0FY COfHXX2UyloZWQ_ztKOshFoPpdtZVKCFdJAJzIfYbO8iVaqNGNngy0P9gfPsb5fw4XUrz78bTRxx W5FcHJ9NS8tlEIK5Hzuxtw.3pHpDWR4rpJAalc5z2TawwTJvRpOqW4l.DxW2jrE1zpPLUZrvxehZ CKHcZuulkyzJ_qkuHKSz_ak.WNHd.vMkstSPIuVx4Hhuv0bJCdZuYl9KKFU66YozJ9Dz4AX1szDv c1BkzgUB07gJZmVbX.syusCdrnITmm9GvQtRQElqGR2qNuqUXhGT0gmIgw7wG487qDB7O_koBeDc 6uMG4BvIDbyGg_l5ejvkNbTnK3nrJ0pFrZws2uLUrRwrsUXjJvpsFTFuRgQXOsX8gXWQbj1FHWGR ArjJtWShLWRKMH_.npX2KEsjhZ0nwzxaufxyX03FVXhARBwAtkDfTlMKzSv1qlB7RdrEzgOkK5Vb SpR9bIHHRXAGe0uLmSl2QhRkpBUCU07W9qPQ0X7UUCmB2bcdyx53DUrqrqNsk0GZDc7rYIyKrhI9 3RGMCrWnhV2F6aASd7vvEGo2ZvAyzxYjc7XzfXYI4EPYRGhq.U8FLlfO9HANcsTt2mJFP1f1jhJI W5P2LCFixVSaM4xkTb62vAoolQMV0v6ixkmrHfXyK8CvVcviKeQwDrxCNWRVSIpj1uUNk22VsLOB kJTZ5SiOVaUGCS03DyULh9yJe5SMnoqLl9xal9.zurh80ySKJPmHKURozmhojbWCht0_i.97hAF8 WSK7frTFzmkLbO41quGoK5.6ufWMTMkPSBCbksqy5OG17cuuz6SaD5wRbREWW5iWXjclfedlUZFY iLeZDkHsBLwV5TXmC9IjHzt.Zkjc5g1zgsHifbKGvUKwWnDmRBWtUI68mNgOO5QCM8Xr.9GeQzcC dMhd7w.kNJOot.OqsyNrDLQFPINR1RvInVnjt4NTLf7bJV7_BDorcAGAsKJrvjmjuuId66GaKyHS K9YL036dgwHtn2P84f2_0fYEReVn_vdQfWZBVrhNpypb6LSs7apAre6igLgAvu97izYNqSPH9fs1 p86QRjrtryTdfO03xG.Qh5u5.FAbYr6vZKaSal5hYd2F9oyQ8jXnE3ToegZnWLhx5p_rShFsaJ40 Jzbr3GbXkmJ8XC5ZC6sku6tmvP57Jjz0aI2wgqUWIxlvv67RR1AIdKSYSdhG1pBCqv2X22A_ZJTu .yVQBmZbIlg8MAgp3nQf3LmFuum4O98kwW9iOHM2eA3YSZ2coNk6HfShLVanwW8nHTn3Ey.USdmk WE7piS7Plt9zgOo83t869lENMoidBLI_vYEAUtRyK0ixNMvgUYwKUabJ4xXcvI3upRWKY92Mbb_w Z2Q9HeqF029gpqxENjGpgekbJslrr98CYIcP.L6SFnnN2TsUCoaFCIJKQ3ATgR175FgEZ6bZIpns tCViYL2Y3UZ2Ww5.lKW6BET1kYFpJZzNGR.Z5CZkyxYNr1_SymqzSymoN7bXae2oeFZwOXku5uS_ 9zftj54pk.6rdAKznZ0HPrBjEUvN_kOqn8VeNAbetbFlVoYY5yjSW2t6hRiM2R_UTwdgESp4tTiY wsIUfzUhFS.grefDivKvm6gF7U5zQRw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 Feb 2021 17:27:28 +0000 Received: by smtp406.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID baf7d28ac969a89e22cb5c40fe2bdb87; Mon, 22 Feb 2021 17:27:25 +0000 (UTC) To: Brian Campbell , rfc-ise@rfc-editor.org Cc: draft-ideskog-assisted-token@ietf.org, oauth References: <1e5f0e825a2580f68c92aa5a1d798090.squirrel@www.rfc-editor.org> <702cf2e8d762ba733becdb5c735f72a9.squirrel@www.rfc-editor.org> From: George Fletcher Organization: AOL LLC Message-ID: <5c6fdcdf-47f5-152f-f459-0d61b0527dff@aol.com> Date: Mon, 22 Feb 2021 12:27:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------956FA472611DBAF4430D6FD5" Content-Language: en-US X-Mailer: WebService/1.1.17712 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.9.1) Archived-At: Subject: Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 17:27:47 -0000 This is a multi-part message in MIME format. --------------956FA472611DBAF4430D6FD5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Adrian, I agree with Brian that the proposed document directly relates to ongoing work in the OAuth working group. Establishing a completely different mechanism for supporting Single Page Apps other than what is being proposed by the working group will lead to bifurcated implementations and potential confusion across the industry. I'd much prefer to see the work proposed to be considered for adoption by the OAuth working group such that it can go through the normal standardization process. This will also ensure that the security best practices document will cover any additional mechanisms and keep all that work together. Thanks, George On 2/19/21 4:09 PM, Brian Campbell wrote: > Hi Adrian, > > I believe this work was presented briefly to the WG in London during > IETF 101. As far as I can recall, the general reaction/thinking at > that time was that the WG really should be working on a document about > OAuth and single page applications (that may or may not include > something like the functionality in draft-ideskog-assisted-token). > Since that time the WG adopted and is actively working on 'OAuth 2.0 > for Browser-Based Apps' > https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ > > which is intended as a BCP for single page applications acting as > OAuth clients. The prospective BCP details security considerations and > best practices around leveraging existing features of OAuth for single > page apps. Whereas draft-ideskog-assisted-token introduces a new > grant, new authorization server endpoint, and really a whole new > interaction model between client and authorization server. Publishing > an independent stream RFC that runs contrary to the BCP coming out of > the WG does seem potentially harmful. > > > > > On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) > > wrote: > > Hi OAuth, > > The authors of draft-ideskog-assisted-token [1] have approached me > requesting that the draft be published as an Informational RFC in the > Independent Submission Stream [2]. > > The draft extends the OAuth 2.0 framework to include an additional > authorization flow for single page applications called the > assisted token > flow. It is intended to enable OAuth clients that are written in > scripting languages (such as JavaScript) to request user authorization > using a simplified method. Communication leverages HTML's iframe > element, > child windows, and the postMessage interface. This communication > is done > using an additional endpoint, the assisted token endpoint. > > It is clear to me that this work could be in scope for OAuth and I > want to > be sure that both: > - there is no interest within the WG in pursuing this approach > - there is no perceived harm to existing OAuth work if this goes ahead > > I'd appreciate any opinions. > > Many thanks, > Adrian > -- > Adrian Farrel (Independent Submissions Editor), > rfc-ise@rfc-editor.org > > [1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/ > > [2] https://www.rfc-editor.org/about/independent/ > > > > > > > > -- > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited.  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------956FA472611DBAF4430D6FD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Adrian,

I agree with Brian that the proposed document directly relates to ongoing work in the OAuth working group. Establishing a completely different mechanism for supporting Single Page Apps other than what is being proposed by the working group will lead to bifurcated implementations and potential confusion across the industry. I'd much prefer to see the work proposed to be considered for adoption by the OAuth working group such that it can go through the normal standardization process. This will also ensure that the security best practices document will cover any additional mechanisms and keep all that work together.

Thanks,
George

On 2/19/21 4:09 PM, Brian Campbell wrote:
Hi Adrian,

I believe this work was presented briefly to the WG in London during IETF 101. As far as I can recall, the general reaction/thinking at that time was that the WG really should be working on a document about OAuth and single page applications (that may or may not include something like the functionality in draft-ideskog-assisted-token). Since that time the WG adopted and is actively working on 'OAuth 2.0 for Browser-Based Apps' https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ which is intended as a BCP for single page applications acting as OAuth clients. The prospective BCP details security considerations and best practices around leveraging existing features of OAuth for single page apps. Whereas draft-ideskog-assisted-token introduces a new grant, new authorization server endpoint, and really a whole new interaction model between client and authorization server. Publishing an independent stream RFC that runs contrary to the BCP coming out of the WG does seem potentially harmful.




On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org> wrote:
Hi OAuth,

The authors of draft-ideskog-assisted-token [1] have approached me
requesting that the draft be published as an Informational RFC in the
Independent Submission Stream [2].

The draft extends the OAuth 2.0 framework to include an additional
authorization flow for single page applications called the assisted token
flow. It is intended to enable OAuth clients that are written in
scripting languages (such as JavaScript) to request user authorization
using a simplified method. Communication leverages HTML's iframe element,
child windows, and the postMessage interface. This communication is done
using an additional endpoint, the assisted token endpoint.

It is clear to me that this work could be in scope for OAuth and I want to
be sure that both:
- there is no interest within the WG in pursuing this approach
- there is no perceived harm to existing OAuth work if this goes ahead

I'd appreciate any opinions.

Many thanks,
Adrian
--
Adrian Farrel (Independent Submissions Editor),
rfc-ise@rfc-editor.org

[1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/
[2] https://www.rfc-editor.org/about/independent/
>
>


--
Adrian Farrel (ISE),
rfc-ise@rfc-editor.org

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

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------956FA472611DBAF4430D6FD5-- From nobody Tue Feb 23 03:00:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8E3A2A5D; Tue, 23 Feb 2021 03:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RAND_MKTG_HEADER=2.999, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=a9wkn6mh; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=a9wkn6mh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mEq_lSpnjUg; Tue, 23 Feb 2021 03:00:23 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00043.outbound.protection.outlook.com [40.107.0.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961B63A138A; Tue, 23 Feb 2021 03:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hvqJDA5WBv2Ne3+466uiW+g0/+2DnaxPz12Q1f6egKc=; b=a9wkn6mhaGSt0nphiOOVRldU0b9sU4mJbxOpB8ePurAygxdH+ARrKI8Y/4bMaL7UmTyQbRCZnHkMWTvqdxaPYc4jqvgOxcliwMwkhhbzOTu6BnSrpE9XsFTS0oeRG1CQxa6bMxKVYOrR3jjYlhLim5bz0LqsfcNNYjAswWcNs8I= Received: from DB8P191CA0011.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:130::21) by DB7PR08MB3385.eurprd08.prod.outlook.com (2603:10a6:10:4b::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Tue, 23 Feb 2021 11:00:14 +0000 Received: from DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:130:cafe::83) by DB8P191CA0011.outlook.office365.com (2603:10a6:10:130::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Tue, 23 Feb 2021 11:00:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT015.mail.protection.outlook.com (10.152.20.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Tue, 23 Feb 2021 11:00:13 +0000 Received: ("Tessian outbound 2db1bbc8a1d2:v71"); Tue, 23 Feb 2021 11:00:13 +0000 X-CR-MTA-TID: 64aa7808 Received: from ef68ab6b064a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 808B97F5-EA1D-40A1-829F-C43FD5ED2BB9.1; Tue, 23 Feb 2021 11:00:08 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ef68ab6b064a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 23 Feb 2021 11:00:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mSUUWwXvdFMYlWP2iGBa4Gwn+7GVDKzW2zWpkNVp5md2KYRDd3udYjyzq8Y07E1VPACpZZrNLa+xWCEz+tZdBx7TAW6nWIa1sl0fYvuqnF5utkdTL1r0YIjpDf8qOZJz58SHeY1cqpH6P+tKRW+nRb5sBjbPzn2t+CyRhs+w1cjaJx43+A21GsPHcg+ow2pPZBMm71VNvBqAKOC/taqElxvVS1uXmQV4KMR1tteg0+sdtBAdTc/tS6Oa7bpjynqw2g093LwC55418/Ws/oXX5Xgk1r4Skqt8/2YnQ7GYy7Wwbs57oHA/0qrD6/2XQUuJwC8T3xO2rqTK7HAS5MKNBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hvqJDA5WBv2Ne3+466uiW+g0/+2DnaxPz12Q1f6egKc=; b=ksMTFWTiwZztt3R/2ORFFy601I4vQfmxMWDwNkQYIHLkrWojKTb6ZOl0PYBhLmKAnzzo0pdv3sjxYKh/SZ+VNl+XESFmxlc0VXjQKqdRe9BldxUCynV9CmXA9w2lAcwUms9JePOIO2uAjg82Q4Ee1a4faYaYSnEzdce5j1RFBrGPve98KBCOLxHLdMczJgvDx9Z13OwG2478xIArRsmTfpu+n61h019qKIrjmjlUjWi7avRi1vIgj4M1xRAlciKKVZZAcWfrA48OpptPoETHLoIMX95aEujuJcTwRG1vCGBB/Bvl/oHJkI7q+i5hR81TtmYZr4ZNeQp/a8getu6YWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hvqJDA5WBv2Ne3+466uiW+g0/+2DnaxPz12Q1f6egKc=; b=a9wkn6mhaGSt0nphiOOVRldU0b9sU4mJbxOpB8ePurAygxdH+ARrKI8Y/4bMaL7UmTyQbRCZnHkMWTvqdxaPYc4jqvgOxcliwMwkhhbzOTu6BnSrpE9XsFTS0oeRG1CQxa6bMxKVYOrR3jjYlhLim5bz0LqsfcNNYjAswWcNs8I= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM8PR08MB6529.eurprd08.prod.outlook.com (2603:10a6:20b:354::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Tue, 23 Feb 2021 11:00:04 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::7484:8c2b:e664:648]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::7484:8c2b:e664:648%7]) with mapi id 15.20.3868.033; Tue, 23 Feb 2021 11:00:04 +0000 From: Hannes Tschofenig To: Bron Gondwana , "ietf@ietf.org" CC: "oauth@ietf.org" Thread-Topic: Diversity and Inclusiveness in the IETF Thread-Index: AQHXCXgbtlRdrPa6OEShU5hVFqdRTqplIz0AgABqRRA= Date: Tue, 23 Feb 2021 11:00:04 +0000 Message-ID: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> In-Reply-To: <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 8628E5505CC33F41BB1971E5BAC2EB20.0 x-checkrecipientchecked: true Authentication-Results-Original: fastmailteam.com; dkim=none (message not signed) header.d=none;fastmailteam.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.115.86] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 34da12ef-9f91-4ade-43c6-08d8d7ea3240 x-ms-traffictypediagnostic: AM8PR08MB6529:|DB7PR08MB3385: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: aLRldCcl0QZRD8fSLXW90AI+HegokpF97YrYjMTjUmwDNXSZ8eWs9zMbk0L8SLXU5I1LKKMnhyYlrbibk4DJWBDWCc4h/W5ODVNVWWF0YnBaV4gRBLMtVSRltfDdKG7lh4CcqdnDyg4piczuKL/j2oucFNpOHd2/eAc7wU/hi7ByQnV1NPnUntWki9WSsmlpuTzIyOmJbmxXq2/kSj4IXBmNAP53zG0R6d0Cl9hIiGkVNrCRDuUI8QZC5mWCj4a+gh6IL9t8v9oG5yUVGM5VXZZh+IpYr6R+wT2yXhmSGR3t/wD0/3Unix4RuvC748djk8o1SnoW0Jz7p+TyavCx7REDf3FKAcFh0CzRHJP4/cSFq4u14o1/mIpckYJTDPzvl39i6VgEz2eXiL6TYcVtwL9a8NdRtHjgpO8ssWhjbDdxv2aacSlsX+eEXBI8yUeskPUfl66ExZxUELFQkpyNrVGoTHWXfGTrsi4sn9rYQFNB8MQTZNdAAEqENtN+94PS6JoWmxuvszFk6rrmcoUnqCjV7+vxq4v4eqWhOr+qeh/sZuF9a31WMAtVW0kl0NRBH3vOWe5NMYGZSGOj3bJ/jCJLM1CNCcRW9FcDXhyuxQg= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(52536014)(7696005)(33656002)(966005)(86362001)(83380400001)(8936002)(2906002)(478600001)(55016002)(66446008)(26005)(53546011)(66476007)(76116006)(66946007)(64756008)(6506007)(186003)(110136005)(66556008)(166002)(316002)(4326008)(8676002)(71200400001)(5660300002)(9326002)(9686003)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?LUNvN364YVFzVIYz1ouOSB4li6nJn1SbtNrL7sAzAK2ZTIz972gMBnAf1/N2?= =?us-ascii?Q?xBMs1mjM+nr/yrWuxUw2ZKePDoniP8x/uEh/WhS7hf0i0b2AzydtqdnkFt78?= =?us-ascii?Q?M3L4/WRMDMLqr1TuqUEtRYYG6oCNs7wgyjh5zqzh71IQkOyBivTkMKjqdb3d?= =?us-ascii?Q?6QGpeKrHixUePbbCKYUAVIQaptpsGLuBXA+eLSk5gjQoDMONgLi031wZwRqb?= =?us-ascii?Q?2YSioJoM8BkhikwFvWL3DNewB7CODihxQOFaoCkt+cTiFmuZrMWvlsc3OM0K?= =?us-ascii?Q?h8TNTRgwA8lXJQCle3LBn+QhLANKQYM14A9SX3GqHDUB6vPgCxqdFnolER8V?= =?us-ascii?Q?RKEj7FuxOY6nBnwZfnLCrvy8/vlCyl+C6ijtb6cf/KtOP2oiXsR3LNwFNxGT?= =?us-ascii?Q?Oyz8Yf1G1pbW1wXJSLPQaRwCHobMUvVc0TOH1od+GteSlfkQSgazFjTfAs43?= =?us-ascii?Q?IwPoLwpl/ojttDsrKzzoPasmAlmZxv6/PKWRTfaZ0DEP2Yp4/WhHgk4ZmGqt?= =?us-ascii?Q?s2HXIc5xHKQ+tgjoYbt/I1aZBxI3Dddud3j5gogiKFwuf3+k3Cj2kCeH+luy?= =?us-ascii?Q?M7LLRYgn7vy0jsU2A0TriLeYi0Jzdu/BhUYx3k3dByeDv45gdp5B/WMRH0XA?= =?us-ascii?Q?ajclZLJZT71zrhR22p9t4XkTIoP6OOZBFR4Pia+2F3se6MWjHvEkijpMNmU6?= =?us-ascii?Q?GfQOaVhYRnDnRiwmzWQIqz0GkWqbmxhjLP6fwq08UYE4vEdnSuQVrFcWz2aP?= =?us-ascii?Q?R5APxVFkWK6/HZ4ioSSmdaDyex9thTBgmMVh+g+v+lH3OeYUkT96lqSZqsB6?= =?us-ascii?Q?g+Yh+WD0fHozU2wqxz9PZZEiFclpeIAGh1/U13fGYYJeIXsm75VGtQ5+e8Tl?= =?us-ascii?Q?f9zP5WBpCU4LFq2eHf3F85EPlZUJ/7vtuxN74OTcH0/1sEbePvaB9flj2XdW?= =?us-ascii?Q?VvyhPA3Quq4jDMQ/dOt1FVLqJ/K10F84nMgtDwazIZ6cSQOaGIzMIXBLksq4?= =?us-ascii?Q?OSswmek09jHb/3veEuUwok0s6vIohCUeEJ6V/PQdGtA2qktr2z3enRa0SFfV?= =?us-ascii?Q?GPMuLMhHuv3ozUzc1KmUYAv1OxS7AWTR0hrGo/zXNTLwbRL51fOXyAyjbGRo?= =?us-ascii?Q?9k7kGm0FG9UwWwzNipEF30AAPHi9uhVDBAU4DeHjGiaBA9BmlNKA0c8fQK0b?= =?us-ascii?Q?jVqUtCPHN735wMGHYaoIXCmur+TOaCM8V2aQFMSLudBOu5Tq8hyMFTFLH1Zo?= =?us-ascii?Q?2+TfRf9EQ9/GXDO/Qgq9h5fm+VwHFfSHILXmkuFwHUOpPG9mgct0ZeIEpMTc?= =?us-ascii?Q?4llRbayiq8IOP4ngD5FirfMb?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371669108E9CEA561BEC9EF6FA809AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6529 Original-Authentication-Results: fastmailteam.com; dkim=none (message not signed) header.d=none;fastmailteam.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: ba6ed54b-9bc4-43f1-b7ef-08d8d7ea2ccd X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dxoqYiRDdJV0QU1UeK4ZtwWClDCRBdJ1yn6yZdQmUX1oGJeBRUkX+D1WEum03xYxK6HL3cid6GfOvnFG/WR4JhUV7fSZ3Op4gbBUpeQi4jYO6XNCWbVvI/P2hVmbjb+/aq6K1pEmAFKau+uw1/vry8w8aach1GrIJs/QcL32kox88vixNGekzlEukp42a/2D/uebRDSGsl6CGrWX7RdUVaIke9mLK4uCDK0IhNOblg+oxiTD+fnf809GUWfVwSwVKkwmlYHH+aS3xTVzt+sYgXeGqS0ovpO1Orb235lpxvr22JaXXSKApwTsBAsmdiKs7b8v2thK0+855WV8ySKFCssDrX2kCq7lgc0C8KxyXwlqW1PxS34BaBcJnbZNdTHM5s8riVDNvmwI9i7jpEa2peLLq7IcuSavj4yjd49J9/FrxRD59U1gSj0WFUQ2BLb2Otyg2LFMk3l8Je/TsiPqbRCFkPezH0WF2DuGi/sQrQNeyOT8kt8wVRpZmO8rRK6KJQaKHq4usy5tu4ZAoRRAzeiLluMqocBvjKi5JMWEtgQd4sPGuGj6gOqtJmOl9ddeHXIhBpdSTuDzk9VFluxMM83L1luCwSOpEoD1wuWWvdtRoOCMLjuLiq4PNI5vy1qSjhrEATj3og3cXtHxGOIXUqMsZgN+DVdJ5FaBLN0vfK7Rc9zqKDH1Fr/wySUs+UWuVpGqx1M4SeEjP/ttxV7VF57BPxD9WBujDpw2XBmc98I= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(346002)(39860400002)(36840700001)(46966006)(2906002)(26005)(82310400003)(8936002)(53546011)(55016002)(82740400003)(5660300002)(9326002)(186003)(8676002)(86362001)(450100002)(47076005)(966005)(36860700001)(356005)(83380400001)(336012)(7696005)(33656002)(9686003)(81166007)(52536014)(70206006)(478600001)(110136005)(166002)(70586007)(316002)(66574015)(6506007)(4326008); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2021 11:00:13.8211 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 34da12ef-9f91-4ade-43c6-08d8d7ea3240 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT015.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3385 Archived-At: Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 11:00:29 -0000 --_000_AM0PR08MB371669108E9CEA561BEC9EF6FA809AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bron, I have to respond to your statements about the OAuth working group below. While we do not pay attention to keeping the charter page up-to-date, we ha= ve been able to advance our documents, produce many implementations, and go= t those deployed all over the Internet. The bar for acceptance of new work varies among working group in the IETF. = Some working groups develop technology that got widely deployed and hence r= andomly changing specs isn't such a great idea because you have to consider= the deployment situation as well. This is a situation many IETF working gr= oups face. Reaching (widespread) deployment is great on one hand and a pain= on the other. There are other groups, which are early in their lifecycle. In those groups= you do not need to worry about deployments, backwards compatibility or eve= n any source code. In general, Rifaat and I are always open for anyone in the IETF (and outsid= e) to reach out to us, if they want to bring new work forward to the group.= Sometimes proposed work fits into the group and sometimes it does not. The= work on JOSE, for example, was put into a separate working group even thou= gh it was initially developed for use with JSON Web Tokens. I don't recall having chatted with you or with someone from the JMAP commun= ity on the use of OAuth. Sorry if my memory does not serve me well today. = Typically, applications just use OAuth and therefore there is no need to re= ach out to the OAuth working group. Ciao Hannes From: ietf On Behalf Of Bron Gondwana Sent: Tuesday, February 23, 2021 5:20 AM To: ietf@ietf.org Subject: Re: Diversity and Inclusiveness in the IETF Thanks Fernando, I would add to this document something about inertia, backwards compatibili= ty and existing dysfunction. Many ideas are shut down because they aren't in the right place, or don't f= it comfortably into the existing corpus of IETF documents. When we brought JMAP to the IETF it was after a long process of socialisati= on, and still there was significant work in the first couple of meetings ju= st to convince people that "this is worth doing, the existing work the IETF= has done in this neighborhood is not sufficient". JMAP also had an authentication scheme in it originally. It was a good aut= hentication scheme, but applications don't do authentication schemes, that'= s the bailiwick of OAUTH, where ideas go to die (in my experience, that wor= king group has been dysfunctional for my entire time at IETF - exhibit 'A' = being the "Milestones" section of the about page, which lists 6 items all d= ue in 2017) So we just removed all mention of authentication method and handwaved "the = connection will be authenticated", because we wanted to publish something d= uring the decade with years starting '201'. ... all that to say. One of the biggest barriers to entry in the IETF is s= tumbling across an area in which no work is able to progress due to entrenc= hed issues within that area. And I'm not arguing for "no barriers to entry", because there needs to be a= sanity check that we're actually producing high quality specifications, an= d that our specifications are compatible with each other so the entirety of= the IETF's work product is a coherent whole. But it's hard to get started= if you don't already have the connections to have your work sponsored by s= omebody who already knows their way around the IETF's idiosyncrasies. I'm = doing some of that sponsoring myself now for the people from tc39 who are t= rying to get the IETF to look at defining an extended datetime format. Cheers, Bron. On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote: Folks, We have submitted a new I-D, entitled "Diversity and Inclusiveness in the IETF". The I-D is available at: https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt We expect that our document be discussed in the gendispatch wg (https://datatracker.ietf.org/wg/gendispatch/about/). But given the breadth of the topic and possible views, we'll be glad to discuss it where necessary/applicable/desired. As explicitly noted in our I-D, we're probably only scratching the surface here -- but we believe that our document is probably a good start to discuss many aspects of diversity that deserve discussion. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM0PR08MB371669108E9CEA561BEC9EF6FA809AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bron,

 

I have to respond to your statements about the OAuth= working group below.

 

While we do not pay attention to keeping the charter= page up-to-date, we have been able to advance our documents, produce many = implementations, and got those deployed all over the Internet.

 

The bar for acceptance of new work varies among work= ing group in the IETF. Some working groups develop technology that got wide= ly deployed and hence randomly changing specs isn’t such a great idea= because you have to consider the deployment situation as well. This is a situation many IETF working groups face. Reac= hing (widespread) deployment is great on one hand and a pain on the other.

 

There are other groups, which are early in their lif= ecycle. In those groups you do not need to worry about deployments, backwar= ds compatibility or even any source code.

 

In general, Rifaat and I are always open for anyone = in the IETF (and outside) to reach out to us, if they want to bring new wor= k forward to the group. Sometimes proposed work fits into the group and som= etimes it does not. The work on JOSE, for example, was put into a separate working group even though it was init= ially developed for use with JSON Web Tokens.

 

I don’t recall having chatted with you or with= someone from the JMAP community on the use of OAuth. Sorry if my memory do= es not serve me well today.  Typically, applications just use OAuth an= d therefore there is no need to reach out to the OAuth working group.

 

Ciao

Hannes

 

From: ietf <ietf-bounces@ietf.org> O= n Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: ietf@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

 

Thanks Fernando,

 

I would add to this document something about inertia, backwards compat= ibility and existing dysfunction.

 

Many ideas are shut down because they aren't in the right place, or do= n't fit comfortably into the existing corpus of IETF documents.<= /span>

 

When we brought JMAP to the IETF it was after a long process of social= isation, and still there was significant work in the first couple of meetin= gs just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not suf= ficient".

 

JMAP also had an authentication scheme in it originally.  It was = a good authentication scheme, but applications don't do authentication sche= mes, that's the bailiwick of OAUTH, where ideas go to die (in my experience, that working group has been dysfunctional for my= entire time at IETF - exhibit 'A' being the "Milestones" section= of the about page, which lists 6 items all due in 2017)<= /p>

 

So we just removed all mention of authentication method and handwaved = "the connection will be authenticated", because we wanted to publ= ish something during the decade with years starting '201'.

 

... all that to say.  One of the biggest barriers to entry in the= IETF is stumbling across an area in which no work is able to progress due = to entrenched issues within that area.

 

And I'm not arguing for "no barriers to entry", because ther= e needs to be a sanity check that we're actually producing high quality spe= cifications, and that our specifications are compatible with each other so the entirety of the IETF's work product is a coherent w= hole.  But it's hard to get started if you don't already have the conn= ections to have your work sponsored by somebody who already knows their way= around the IETF's idiosyncrasies.  I'm doing some of that sponsoring myself now for the people from tc39 who are = trying to get the IETF to look at defining an extended datetime format.

 

Cheers,

 

Bron.

 

On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote:=

Folks,

 

We have submitted a new I-D, entitled "Diversity and Inclusivenes= s in 

the IETF".

 

The I-D is available at: 

 

We expect that our document be discussed in the gendispatch wg 

breadth of the topic and possible views, we'll be glad to discuss it

where necessary/applicable/desired.

 

As explicitly noted in our I-D, we're probably only scratching the&nbs= p;

surface here -- but we believe that our document is probably a good&nb= sp;

start to discuss many aspects of diversity that deserve discussion.

 

Thanks!

 

Regards,

-- 

Fernando Gont

SI6 Networks

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

 

 

 

 

 

 

--

  Bron Gondwana, CEO, Fastmail Pty Ltd

 

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM0PR08MB371669108E9CEA561BEC9EF6FA809AM0PR08MB3716eurp_-- From nobody Tue Feb 23 03:51:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA793A2A2E; Tue, 23 Feb 2021 03:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=hXKizicP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KqfO2pUr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ1-PJQqKlRK; Tue, 23 Feb 2021 03:51:11 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C5A3A2A2C; Tue, 23 Feb 2021 03:51:11 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9C6E25C0113; Tue, 23 Feb 2021 06:51:10 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 06:51:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=kK+2 huJHr1IKGuPHlq4X9gVF0YMy8F2XSEdgMcDpK64=; b=hXKizicP12fFf6luxgPh lgSPr+abgcenQASkTRzBxRdqCV/svK3gRd5MRXwWQCRLl0hodEMhqMiyEYKm7063 MXBmJB6NbqtHF9hLscS0YejGm+Gx63q6d7SwV1Sy84TezPf6Xa40WZM08kbNwRVJ ClJ8mELRK9V9LK+0MiEwqJilFpi0GGNEOhTZdp7yNhT8MXXJLh2CcAod6kRXv5Sk USIUv67KK3ulnU9MCnafiUSjwLgVV/9+LgeaOIoxNJAy805n+/+ms1iCDjwdHu/L uQ6Zmx0I5ri7coqYh2AOnFupZLwPZhlHtF520s2nP2kWmNL6rVt6j+ok6UPH7kZV yg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kK+2hu JHr1IKGuPHlq4X9gVF0YMy8F2XSEdgMcDpK64=; b=KqfO2pUr8VR8Vo4unq1hrL GixADUsQ18QTqLegVFDOgSn1kv832qs5WHVPENCi6/gIIMrjDz6U4Sgq7nwcLRHh K8fYXeIyNwT0LSzfXTcl41Z0WUq7JUdGcHhywZ9+mtmqRCewDau1GpI3jwuaHe/I Kp7bc4NSL7nFl15/4JNvhQLQIGrI7ig7tUXtKb3nlp6qa4eOo5fIClcLiHUo8DRe b/Z7FkQG7JqtqI9ElnijQuvI8fE7N0seXdK6yPN4UsOLhkapX7b2AGko3kab/X6m gEEZkArqaDGAd8KnutxeRxT1BXTb4cCOKPnEc87JYv6t59IdJ9d07yU+xjEGhVxA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehtedtjedugfdtgeevffeludeljedvfffhtdfhhfffffdu veegkeejvdefveekfeenucffohhmrghinhepfihikhhiphgvughirgdrohhrghdpihgvth hfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B7C33604EE; Tue, 23 Feb 2021 06:51:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: In-Reply-To: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> Date: Tue, 23 Feb 2021 22:50:49 +1100 From: "Bron Gondwana" To: "Hannes Tschofenig" , "ietf@ietf.org" Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=61e0360afb2240f5b3ad96af2a1856fa Archived-At: Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 11:51:15 -0000 --61e0360afb2240f5b3ad96af2a1856fa Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Without wishing to litigate the entire issue here (happy to remove the w= ider IETF list and just talk on the OAuth group), we never brought any w= ork to the OAuth group because everybody who we spoke to warned us that = nothing would get done. There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_sta= ir which describes this phenomenon, where "everybody knows" something, b= ut new participants are forced to discover it through either having some= one tell them quietly, or just notice it for themselves. ... Just as an anecdote, the last time I bothered to attend an OAuth meeting= in person I had this to say about it on our internal slack channel when= asked:"they can't agree about what they don't agree on". The topic that had taken basically the entire meeting and had been total= ly unproductive - was a particular key in a JSON Web Token going to clas= h with a reserved word in either javascript itself or one of the other e= nvironments in which this token had to be evaluated. There were people = saying "this won't work, just rename the key" and others saying "I like = this name and insist upon us keeping it". No progress was made that day= . In fact, here's the extract of my report on the OAuth meeting at IETF102= (a detailed long email with pictures of poutine, icecream, and a report= on every session I attended). Names extracted to protect the others in= volved, but other text left exactly as it was, complete with typoes: > *Thursday 19th: (Aug 2018)* >=20 > *9:30am* OAUTH : Fecking OAUTH as they say. I came out of this sayin= g "they can't even agree about what they don't agree on". says it was even worse in the past. What a fustercluck. Don't expec= t anything workwhile out of this group unfortunately. and I were just looking at each other like WTF the entire time. Maybe it's become heaps better since then. But I wouldn't want to have = been a new participant trying to get anything done in that session. ... The authentication flow as originally put into JMAP (before it came to t= he IETF) can be seen in the initial draft here if you're interested: https://www.ietf.org/archive/id/draft-jenkins-jmap-00.txt But we decided in the interests of expediency to just drop it rather tha= n trying to progress that work anywhere at the IETF. Regards, Bron. On Tue, Feb 23, 2021, at 22:00, Hannes Tschofenig wrote: > Hi Bron, > =20 > I have to respond to your statements about the OAuth working group bel= ow. > =20 > While we do not pay attention to keeping the charter page up-to-date, = we have been able to advance our documents, produce many implementations= , and got those deployed all over the Internet. > =20 > The bar for acceptance of new work varies among working group in the I= ETF. Some working groups develop technology that got widely deployed and= hence randomly changing specs isn=E2=80=99t such a great idea because y= ou have to consider the deployment situation as well. This is a situatio= n many IETF working groups face. Reaching (widespread) deployment is gre= at on one hand and a pain on the other. > =20 > There are other groups, which are early in their lifecycle. In those g= roups you do not need to worry about deployments, backwards compatibilit= y or even any source code. > =20 > In general, Rifaat and I are always open for anyone in the IETF (and o= utside) to reach out to us, if they want to bring new work forward to th= e group. Sometimes proposed work fits into the group and sometimes it do= es not. The work on JOSE, for example, was put into a separate working g= roup even though it was initially developed for use with JSON Web Tokens= . > =20 > I don=E2=80=99t recall having chatted with you or with someone from th= e JMAP community on the use of OAuth. Sorry if my memory does not serve = me well today. Typically, applications just use OAuth and therefore the= re is no need to reach out to the OAuth working group. > =20 > Ciao > Hannes > =20 > *From:* ietf *On Behalf Of * Bron Gondwana > *Sent:* Tuesday, February 23, 2021 5:20 AM > *To:* ietf@ietf.org > *Subject:* Re: Diversity and Inclusiveness in the IETF > =20 > Thanks Fernando, > =20 > I would add to this document something about inertia, backwards compat= ibility and existing dysfunction. > =20 > Many ideas are shut down because they aren't in the right place, or do= n't fit comfortably into the existing corpus of IETF documents. > =20 > When we brought JMAP to the IETF it was after a long process of social= isation, and still there was significant work in the first couple of mee= tings just to convince people that "this is worth doing, the existing wo= rk the IETF has done in this neighborhood is not sufficient". > =20 > JMAP also had an authentication scheme in it originally. It was a goo= d authentication scheme, but applications don't do authentication scheme= s, that's the bailiwick of OAUTH, where ideas go to die (in my experienc= e, that working group has been dysfunctional for my entire time at IETF = - exhibit 'A' being the "Milestones" section of the about page, which li= sts 6 items all due in 2017) > =20 > So we just removed all mention of authentication method and handwaved = "the connection will be authenticated", because we wanted to publish som= ething during the decade with years starting '201'. > =20 > ... all that to say. One of the biggest barriers to entry in the IETF= is stumbling across an area in which no work is able to progress due to= entrenched issues within that area. > =20 > And I'm not arguing for "no barriers to entry", because there needs to= be a sanity check that we're actually producing high quality specificat= ions, and that our specifications are compatible with each other so the = entirety of the IETF's work product is a coherent whole. But it's hard = to get started if you don't already have the connections to have your wo= rk sponsored by somebody who already knows their way around the IETF's i= diosyncrasies. I'm doing some of that sponsoring myself now for the peo= ple from tc39 who are trying to get the IETF to look at defining an exte= nded datetime format. > =20 > Cheers, > =20 > Bron. > =20 > On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote: >> Folks, >> =20 >> We have submitted a new I-D, entitled "Diversity and Inclusiveness in= =20 >> the IETF". >> =20 >> The I-D is available at:=20 >> https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt >> =20 >> We expect that our document be discussed in the gendispatch wg=20 >> (https://datatracker.ietf.org/wg/gendispatch/about/). But given the=20= >> breadth of the topic and possible views, we'll be glad to discuss it >> where necessary/applicable/desired. >> =20 >> As explicitly noted in our I-D, we're probably only scratching the=20= >> surface here -- but we believe that our document is probably a good=20= >> start to discuss many aspects of diversity that deserve discussion. >> =20 >> Thanks! >> =20 >> Regards, >> --=20 >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> =20 >> =20 >> =20 >> =20 >> =20 > =20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > =20 > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended reci= pient, please notify the sender immediately and do not disclose the cont= ents to any other person, use it for any purpose, or store or copy the i= nformation in any medium. Thank you. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --61e0360afb2240f5b3ad96af2a1856fa Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Without wishing to litigate the entire issue here (ha= ppy to remove the wider IETF list and just talk on the OAuth group), we = never brought any work to the OAuth group because everybody who we spoke= to warned us that nothing would get done.

There's a term= "missing stair" https://en.wikipedia.org/wiki/Missing_stair which describes th= is phenomenon, where "everybody knows" something, but new participants a= re forced to discover it through either having someone tell them quietly= , or just notice it for themselves.

...

Ju= st as an anecdote, the last time I bothered to attend an OAuth meeting i= n person I had this to say about it on our internal slack channel when a= sked:"they can't agree about what they don't agree on".

T= he topic that had taken basically the entire meeting and had been totall= y unproductive - was a particular key in a JSON Web Token going to clash= with a reserved word in either javascript itself or one of the other en= vironments in which this token had to be evaluated.  There were peo= ple saying "this won't work, just rename the key" and others saying "I l= ike this name and insist upon us keeping it".  No progress was made= that day.

In fact, here's the extract of my report on th= e OAuth meeting at IETF102 (a detailed long email with pictures of pouti= ne, icecream, and a report on every session I attended).  Names ext= racted to protect the others involved, but other text left exactly as it= was, complete with typoes:
<= br>
= Thursday 19th: (Aug 2018)

9:30am OAUTH:  Fecking OAUTH as they say.  I came out of this = saying "they can't even agree about what they don't agree on".  <= ;Name redacted> says it was even worse in the past.  What a fust= ercluck.  Don't expect anything workwhile out of this group unfortu= nately.  <Other name redacted> and I were just looking at eac= h other like WTF the entire time.

Maybe it's= become heaps better since then.  But I wouldn't want to have been = a new participant trying to get anything done in that session.
=

...

The authentication flow as originally put into = JMAP (before it came to the IETF) can be seen in the initial draft here = if you're interested:


But we decided in the interests of e= xpediency to just drop it rather than trying to progress that work anywh= ere at the IETF.

Regards,

Bron.
<= div style=3D"font-family:Arial;">
On Tue, Feb 23, 2021, at= 22:00, Hannes Tschofenig wrote:
=

Hi Bron,

&nbs= p;

I have to respond to your statements= about the OAuth working group below.

&= nbsp;

While we do not pay attention to = keeping the charter page up-to-date, we have been able to advance our do= cuments, produce many implementations, and got those deployed all over t= he Internet.

 

The bar for acceptance of new work varies among working gr= oup in the IETF. Some working groups develop technology that got widely = deployed and hence randomly changing specs isn=E2=80=99t such a great id= ea because you have to consider the deployment situation as well. This is a situation many IETF working groups face. R= eaching (widespread) deployment is great on one hand and a pain on the o= ther.

 

There are other groups, which are early in their lifecycle. In th= ose groups you do not need to worry about deployments, backwards compati= bility or even any source code.

 <= br>

In general, Rifaat and I are always ope= n for anyone in the IETF (and outside) to reach out to us, if they want = to bring new work forward to the group. Sometimes proposed work fits int= o the group and sometimes it does not. The work on JOSE, for example, was put into a separate working group even though it was i= nitially developed for use with JSON Web Tokens.

 

I don=E2=80=99t recall= having chatted with you or with someone from the JMAP community on the = use of OAuth. Sorry if my memory does not serve me well today.  Typ= ically, applications just use OAuth and therefore there is no need to re= ach out to the OAuth working group.

 

Ciao

Hannes<= br>

 

From: ietf <ietf-bo= unces@ietf.org> On Behalf Of Bron Gondwana
= Sent: Tuesday, February 23, 2021 5:20 AM
To: i= etf@ietf.org
Subject: Re: Diversity and Inclusiven= ess in the IETF

&n= bsp;

Thanks Ferna= ndo,

 

I would add to this document something about inert= ia, backwards compatibility and existing dysfunction.
<= /p>

 =

M= any ideas are shut down because they aren't in the right place, or don't= fit comfortably into the existing corpus of IETF documents.

 =

When we brought JMAP to the IETF it was after a long process of soc= ialisation, and still there was significant work in the first couple of = meetings just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not = sufficient".

<= span style=3D""> 

JMAP also had an authentication scheme in = it originally.  It was a good authentication scheme, but applicatio= ns don't do authentication schemes, that's the bailiwick of OAUTH, where= ideas go to die (in my experience, that working group has been dysfunctional for= my entire time at IETF - exhibit 'A' being the "Milestones" section of = the about page, which lists 6 items all due in 2017)

 

So we just removed all mention of authentication method and handwaved= "the connection will be authenticated", because we wanted to publish so= mething during the decade with years starting '201'.

 <= /span>

..= . all that to say.  One of the biggest barriers to entry in the IET= F is stumbling across an area in which no work is able to progress due t= o entrenched issues within that area.

 

<= /div>

And I'm not argui= ng for "no barriers to entry", because there needs to be a sanity check = that we're actually producing high quality specifications, and that our = specifications are compatible with each other so the entirety of the IETF's work product is a coheren= t whole.  But it's hard to get started if you don't already have th= e connections to have your work sponsored by somebody who already knows = their way around the IETF's idiosyncrasies.  I'm doing some of that sponsoring myself now for the people from tc39 who a= re trying to get the IETF to look at defining an extended datetime forma= t.

 

Cheers,

 

=

Bron.

=

 

On Tue, Feb 23, 2= 021, at 11:07, Fernando Gont wrote:

Folks,

 

We have submitted a new I-D= , entitled "Diversity and Inclusiveness in 

the IETF".<= /span>

&n= bsp;

The I-D is available at: 

https://www.ietf.o= rg/archive/id/draft-gont-diversity-analysis-00.txt
=

 

= We expect that our document be discussed in the gendispatch wg 

= https:= //datatracker.ietf.org/wg/gendispatch/about/). But given the 

breadth of the topic and possible views, we'll be glad to discuss it=

where necessary/applicable/desired.

 

As explicitly n= oted in our I-D, we're probably only scratching the <= br>

surface h= ere -- but we believe that our document is probably a good <= /span>

st= art to discuss many aspects of diversity that deserve discussion.=

&= nbsp;

Thanks!

 

Regards,

-- 

Fernando Gon= t

SI6 Networks

PGP Fingerprint: 6666 31C6 D484 63B2 8= FB1 E3C4 AE25 0D55 1D4E 7492

 

 

 

&nb= sp;

 

 

--

  Bron Gondwana, CEO, Fastmail Pty Ltd=

 

 

IM= PORTANT NOTICE: The contents of this email and any attachments are confi= dential and may also be privileged. If you are not the intended recipien= t, please notify the sender immediately and do not disclose the contents= to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
&nbs= p; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--61e0360afb2240f5b3ad96af2a1856fa-- From nobody Tue Feb 23 04:41:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C13A2AA1; Tue, 23 Feb 2021 04:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUkL3nUigeBU; Tue, 23 Feb 2021 04:40:58 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A4E3A2AB2; Tue, 23 Feb 2021 04:40:57 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id u4so17352258lja.3; Tue, 23 Feb 2021 04:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VNSni7m8/7EHuLLjlbIlpvcZcUzuXlOMHXPQB/AC7Yo=; b=jgMiWouP8qStV6KknVYcCmI7oXtIuMeRzYP7hBGfm06BY/z8w5pUOmcN8uJHmEAPLW dwzsG0jQ9ayfthwLgfeWH4PyxL3jSzh3eutVQssfMy5dIKVvOaAJizna9neSERzDId5D gV0F1kcGkW8ZNVAPvGYAIr79PrCjn5kVCOBzezRsx2QzNB3kvWBbbI/gR5mDumjbJ4a0 UHCNFbq7L16ScKBmvi6umwk2fmUMj77n6ezYP6MBFagtKRKJufoRCytZrQAZiUAN8MEE tazlG84lJWgQOr2c6FBUQezAqSrvGIU9kPANQOt42OgZlK0lgrSpUl/yr99Gkz88npIU IqRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VNSni7m8/7EHuLLjlbIlpvcZcUzuXlOMHXPQB/AC7Yo=; b=mHYiGgeiYTTKbtJgnm/XMh8o0CGUmBOmv0l/B7jOTeakRsgiaF9NOiJCiAZzLInKA3 5jaj674ZWmAJRcs7RloB1Bsf55N7ksXdgx0AzIRX+MWy3BGrKSlL/dNDu8fdunAmcFk4 74Sy71FWTrxzultGspHsAchtx3zc4X69GtFgiCHpaU3QrRZbNcHlIOeOhFH6w09h4VQI o24MTeTYacgFaGVqpeQuRBWQCTDH/ltzl+c8cyTpa3YmmFawxTLTqbK890nqqY62H5lZ DnDuklzOU1s1Nu9kF40i0n1i1ZtkFWziwawvy2n+/+QId8lqw8DktVSAdyPYw+foKVDj Ohpw== X-Gm-Message-State: AOAM533I5fzxhiElVs2BVw1ytUAfsOFuDCUG7iz20wlE2tzEz+VjNLXp gam1O1JOazT0nCVl9h78PhtgphQe/ds1WO9VUx4= X-Google-Smtp-Source: ABdhPJzc0GOKRsk2CSVRGaIvGWYTnvpiqLS5C+6UAZi/hafYV0au5EdBHSCHZdHUPRt4ljRznk71iyZ8h8v0oQLPKbY= X-Received: by 2002:a05:651c:552:: with SMTP id q18mr17344543ljp.278.1614084055173; Tue, 23 Feb 2021 04:40:55 -0800 (PST) MIME-Version: 1.0 References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Tue, 23 Feb 2021 07:40:43 -0500 Message-ID: To: Bron Gondwana Cc: Hannes Tschofenig , "ietf@ietf.org" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf0e2a05bc003a16" Archived-At: Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 12:41:01 -0000 --000000000000bf0e2a05bc003a16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So you have never reached out to us to try to bring any work to the WG, and based on attending one meeting and hearing from a few people, you formed a strong opinion and declared that "nothing would get done"? that seems odd. For your information, last year we published 4 RFCs, and we already have 3 documents with the IESG and more to come. If you have anything you want to bring to the OAuth WG, Hannes and I would be happy to discuss this with you or anyone that wants to bring work to the OAuth WG. Regards, Rifaat On Tue, Feb 23, 2021 at 6:52 AM Bron Gondwana wrote: > Without wishing to litigate the entire issue here (happy to remove the > wider IETF list and just talk on the OAuth group), we never brought any > work to the OAuth group because everybody who we spoke to warned us that > nothing would get done. > > There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_stai= r > which describes this phenomenon, where "everybody knows" something, but n= ew > participants are forced to discover it through either having someone tell > them quietly, or just notice it for themselves. > > ... > > Just as an anecdote, the last time I bothered to attend an OAuth meeting > in person I had this to say about it on our internal slack channel when > asked:"they can't agree about what they don't agree on". > > The topic that had taken basically the entire meeting and had been totall= y > unproductive - was a particular key in a JSON Web Token going to clash wi= th > a reserved word in either javascript itself or one of the other > environments in which this token had to be evaluated. There were people > saying "this won't work, just rename the key" and others saying "I like > this name and insist upon us keeping it". No progress was made that day. > > In fact, here's the extract of my report on the OAuth meeting at IETF102 > (a detailed long email with pictures of poutine, icecream, and a report o= n > every session I attended). Names extracted to protect the others involve= d, > but other text left exactly as it was, complete with typoes: > > *Thursday 19th: (Aug 2018)* > > *9:30am* OAUTH > : > Fecking OAUTH as they say. I came out of this saying "they can't even > agree about what they don't agree on". says it was even > worse in the past. What a fustercluck. Don't expect anything workwhile > out of this group unfortunately. and I were just > looking at each other like WTF the entire time. > > > Maybe it's become heaps better since then. But I wouldn't want to have > been a new participant trying to get anything done in that session. > > ... > > The authentication flow as originally put into JMAP (before it came to th= e > IETF) can be seen in the initial draft here if you're interested: > > https://www.ietf.org/archive/id/draft-jenkins-jmap-00.txt > > But we decided in the interests of expediency to just drop it rather than > trying to progress that work anywhere at the IETF. > > Regards, > > Bron. > > On Tue, Feb 23, 2021, at 22:00, Hannes Tschofenig wrote: > > Hi Bron, > > > > I have to respond to your statements about the OAuth working group below. > > > > While we do not pay attention to keeping the charter page up-to-date, we > have been able to advance our documents, produce many implementations, an= d > got those deployed all over the Internet. > > > > The bar for acceptance of new work varies among working group in the IETF= . > Some working groups develop technology that got widely deployed and hence > randomly changing specs isn=E2=80=99t such a great idea because you have = to > consider the deployment situation as well. This is a situation many IETF > working groups face. Reaching (widespread) deployment is great on one han= d > and a pain on the other. > > > > There are other groups, which are early in their lifecycle. In those > groups you do not need to worry about deployments, backwards compatibilit= y > or even any source code. > > > > In general, Rifaat and I are always open for anyone in the IETF (and > outside) to reach out to us, if they want to bring new work forward to th= e > group. Sometimes proposed work fits into the group and sometimes it does > not. The work on JOSE, for example, was put into a separate working group > even though it was initially developed for use with JSON Web Tokens. > > > > I don=E2=80=99t recall having chatted with you or with someone from the J= MAP > community on the use of OAuth. Sorry if my memory does not serve me well > today. Typically, applications just use OAuth and therefore there is no > need to reach out to the OAuth working group. > > > > Ciao > > Hannes > > > > *From:* ietf *On Behalf Of * Bron Gondwana > *Sent:* Tuesday, February 23, 2021 5:20 AM > *To:* ietf@ietf.org > *Subject:* Re: Diversity and Inclusiveness in the IETF > > > > Thanks Fernando, > > > > I would add to this document something about inertia, backwards > compatibility and existing dysfunction. > > > > Many ideas are shut down because they aren't in the right place, or don't > fit comfortably into the existing corpus of IETF documents. > > > > When we brought JMAP to the IETF it was after a long process of > socialisation, and still there was significant work in the first couple o= f > meetings just to convince people that "this is worth doing, the existing > work the IETF has done in this neighborhood is not sufficient". > > > > JMAP also had an authentication scheme in it originally. It was a good > authentication scheme, but applications don't do authentication schemes, > that's the bailiwick of OAUTH, where ideas go to die (in my experience, > that working group has been dysfunctional for my entire time at IETF - > exhibit 'A' being the "Milestones" section of the about page, which lists= 6 > items all due in 2017) > > > > So we just removed all mention of authentication method and handwaved "th= e > connection will be authenticated", because we wanted to publish something > during the decade with years starting '201'. > > > > ... all that to say. One of the biggest barriers to entry in the IETF is > stumbling across an area in which no work is able to progress due to > entrenched issues within that area. > > > > And I'm not arguing for "no barriers to entry", because there needs to be > a sanity check that we're actually producing high quality specifications, > and that our specifications are compatible with each other so the entiret= y > of the IETF's work product is a coherent whole. But it's hard to get > started if you don't already have the connections to have your work > sponsored by somebody who already knows their way around the IETF's > idiosyncrasies. I'm doing some of that sponsoring myself now for the > people from tc39 who are trying to get the IETF to look at defining an > extended datetime format. > > > > Cheers, > > > > Bron. > > > > On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote: > > Folks, > > > > We have submitted a new I-D, entitled "Diversity and Inclusiveness in > > the IETF". > > > > The I-D is available at: > > https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt > > > > We expect that our document be discussed in the gendispatch wg > > (https://datatracker.ietf.org/wg/gendispatch/about/). But given the > > breadth of the topic and possible views, we'll be glad to discuss it > > where necessary/applicable/desired. > > > > As explicitly noted in our I-D, we're probably only scratching the > > surface here -- but we believe that our document is probably a good > > start to discuss many aspects of diversity that deserve discussion. > > > > Thanks! > > > > Regards, > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > > > > > -- > > Bron Gondwana, CEO, Fastmail Pty Ltd > > brong@fastmailteam.com > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > --000000000000bf0e2a05bc003a16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So you have never reached out t= o us to=C2=A0try to bring any work to the WG, and based on attending=C2=A0o= ne meeting and hearing from a few people, you formed a strong opinion and d= eclared that "nothing would get done"? that seems odd.
=
For your information, last year we published 4 RFCs, and we = already have 3 documents with the IESG and more to come.

If you have anything you want to bring to the OAuth WG, Hannes and I= would be happy to discuss this with you or anyone that wants to bring work= to the OAuth WG.

Regards,
=C2=A0Rifaat<= /div>
=C2=A0


On Tue, Feb 23, 2021= at 6:52 AM Bron Gondwana <bro= ng@fastmailteam.com> wrote:
Without wis= hing to litigate the entire issue here (happy to remove the wider IETF list= and just talk on the OAuth group), we never brought any work to the OAuth = group because everybody who we spoke to warned us that nothing would get do= ne.

There's a term "missing stair"=C2=A0https://en.w= ikipedia.org/wiki/Missing_stair which describes this phenomenon, where = "everybody knows" something, but new participants are forced to d= iscover it through either having someone tell them quietly, or just notice = it for themselves.

...
=
Just as an anecdote, the last ti= me I bothered to attend an OAuth meeting in person I had this to say about = it on our internal slack channel when asked:"they can't agree abou= t what they don't agree on".

The topic that had taken ba= sically the entire meeting and had been totally unproductive - was a partic= ular key in a JSON Web Token going to clash with a reserved word in either = javascript itself or one of the other environments in which this token had = to be evaluated.=C2=A0 There were people saying "this won't work, = just rename the key" and others saying "I like this name and insi= st upon us keeping it".=C2=A0 No progress was made that day.
=

In fact, here's the extract of my report on the OAuth meeting at IETF1= 02 (a detailed long email with pictures of poutine, icecream, and a report = on every session I attended).=C2=A0 Names extracted to protect the others i= nvolved, but other text left exactly as it was, complete with typoes:

Thur= sday 19th: (Aug 2018)

9:30am OAUTH:=C2=A0 Fecking OAUTH a= s they say.=C2=A0 I came out of this saying "they can't even agree= about what they don't agree on".=C2=A0 <Name redacted> says= it was even worse in the past.=C2=A0 What a fustercluck.=C2=A0 Don't e= xpect anything workwhile out of this group unfortunately.=C2=A0 <Other n= ame redacted> and I were just looking at each other like WTF the entire = time.

Maybe it's become heaps better since then.= =C2=A0 But I wouldn't want to have been a new participant trying to get= anything done in that session.
<= br>
...

The authentication = flow as originally put into JMAP (before it came to the IETF) can be seen i= n the initial draft here if you're interested:


But we d= ecided in the interests of expediency to just drop it rather than trying to= progress that work anywhere at the IETF.

Regards,

Bron= .

On Tue, Feb 23, = 2021, at 22:00, Hannes Tschofenig wrote:

Hi Bron,

=C2=A0

I have to respond to your statements about the OAuth working group b= elow.

=C2=A0

While we do not p= ay attention to keeping the charter page up-to-date, we have been able to a= dvance our documents, produce many implementations, and got those deployed = all over the Internet.

=C2=A0

= The bar for acceptance of new work varies among working group in the IETF. = Some working groups develop technology that got widely deployed and hence r= andomly changing specs isn=E2=80=99t such a great idea because you have to = consider the deployment situation as well. This is a situation many IETF working groups face. Reac= hing (widespread) deployment is great on one hand and a pain on the other.<= br>

=C2=A0

<= p class=3D"gmail-m_7037245004404460426qt-MsoNormal">There are other groups,= which are early in their lifecycle. In those groups you do not need to wor= ry about deployments, backwards compatibility or even any source code.
<= /p>

=C2=A0

In general, Rifaat and I ar= e always open for anyone in the IETF (and outside) to reach out to us, if t= hey want to bring new work forward to the group. Sometimes proposed work fi= ts into the group and sometimes it does not. The work on JOSE, for example, was put into a separate working group even though it was init= ially developed for use with JSON Web Tokens.

=C2=A0

I don=E2=80=99t recall having chatted with you or wi= th someone from the JMAP community on the use of OAuth. Sorry if my memory = does not serve me well today.=C2=A0 Typically, applications just use OAuth = and therefore there is no need to reach out to the OAuth working group.

=C2=A0

Ciao

Hannes<= br>

=C2=A0

<= div>

From:= ietf <ie= tf-bounces@ietf.org> On Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 5:20 AM
To: ietf@ietf.org
<= /div>
Subject: Re: Diversity and Inclusiveness in the IETF
<= /div>

=C2=A0

<= span>Thanks Fernando,

=C2=A0

I would add to this document = something about inertia, backwards compatibility and existing dysfunction.<= /span>

=C2=A0<= /span>

Many ideas are shut d= own because they aren't in the right place, or don't fit comfortabl= y into the existing corpus of IETF documents.

=C2=A0

When we brought JMAP to the IETF it was after a = long process of socialisation, and still there was significant work in the = first couple of meetings just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not suf= ficient".

=C2=A0

JMAP a= lso had an authentication scheme in it originally.=C2=A0 It was a good auth= entication scheme, but applications don't do authentication schemes, th= at's the bailiwick of OAUTH, where ideas go to die (in my experience, that working group has been dysfunctional for my= entire time at IETF - exhibit 'A' being the "Milestones"= section of the about page, which lists 6 items all due in 2017)

=C2=A0

So we just removed all men= tion of authentication method and handwaved "the connection will be au= thenticated", because we wanted to publish something during the decade= with years starting '201'.

=C2=A0

... all that to say.=C2=A0 One of the biggest barriers to en= try in the IETF is stumbling across an area in which no work is able to pro= gress due to entrenched issues within that area.

=C2=A0

<= p class=3D"gmail-m_7037245004404460426qt-MsoNormal">And I'm not arguing for "no barriers t= o entry", because there needs to be a sanity check that we're actu= ally producing high quality specifications, and that our specifications are= compatible with each other so the entirety of the IETF's work product is a cohere= nt whole.=C2=A0 But it's hard to get started if you don't already h= ave the connections to have your work sponsored by somebody who already kno= ws their way around the IETF's idiosyncrasies.=C2=A0 I'm doing some of that sponsoring myself now for the people from tc39 who are = trying to get the IETF to look at defining an extended datetime format.

=C2=A0

= Cheers,

= =C2=A0

Bron.

=C2=A0

=

On Tue, Feb 23, 2021, = at 11:07, Fernando Gont wrote:

Folks,

=C2=A0

We have submitted a new I-D, entitled "Diversity and Inclusiv= eness in=C2=A0

the IETF".

=C2=A0

The = I-D is available at:=C2=A0

=C2=A0

We expect that our document be discussed in the gendispatch w= g=C2=A0

breadth of= the topic and possible views, we'll be glad to discuss it

where necessary/applicable= /desired.

=C2= =A0

As explici= tly noted in our I-D, we're probably only scratching the=C2=A0

surface here -- but we= believe that our document is probably a good=C2=A0

start to discuss many aspects of dive= rsity that deserve discussion.

=C2=A0

Thanks!

=C2=A0

Reg= ards,

--=C2=A0=

Fernando Gont=

SI6 Networks<= /span>

e-mail:=C2=A0<= a href=3D"mailto:fgont@si6networks.com" target=3D"_blank">fgont@si6networks= .com

PGP F= ingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=

=C2=A0

=C2=A0

=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--

=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd

=C2=A0

=C2=A0=

IMPORTANT NOTICE: The contents of this emai= l and any attachments are confidential and may also be privileged. If you a= re not the intended recipient, please notify the sender immediately and do = not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
=C2=A0 Bron Gondwana, CEO, = Fastmail Pty Ltd

<= /div>

--000000000000bf0e2a05bc003a16-- From nobody Tue Feb 23 04:47:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C003A2AC7; Tue, 23 Feb 2021 04:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WGUmoohv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Couz7PSk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjSbvpkzWOQf; Tue, 23 Feb 2021 04:46:57 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4C53A2AC6; Tue, 23 Feb 2021 04:46:56 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 19AB75C0066; Tue, 23 Feb 2021 07:46:56 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 07:46:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=C3JN sB17OPuL+DcurAhKv6ngEPBDxXsVmb5fqqvyhcM=; b=WGUmoohvwusaN5LyfA/U 5z6U5Y/sYkxxElnEEJMkLwnrKQ462+FxfWNH/6/A0XRLe7wlNzcfyd51F3S3wtna xX8Zkw4NOZZGdP90VD/g70rr/VyAMmK8NpEBRkHEfz0fN4htbx7yBL5JP3s2fXkI dV6QWZCgDSH3P77kDXkhVU6EHa7WL3dBBhp0VHGA8xOonkfW/N4CB+o/CdEtx/48 7q0sT3ih6ffowG0eFiA084N3moDMO5zHytEGNYXfbR8EdXUyibe4yLeKhk6uo8eD dvi+BOdft9hFchw8awJTHSZiM01DY7Ap9O2LiLTJQpELLCigFSBYUE026oFVrw7D wA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=C3JNsB 17OPuL+DcurAhKv6ngEPBDxXsVmb5fqqvyhcM=; b=Couz7PSk8Ctxy7JZpFe1sw 8+HrP6CMgR/NPRERxgxVGTnFFE2e5GOQJ7hDOe31+8WPRpdgRyddMSlTaZJ0NmKT wvsNDr6ZRnL5ztMr8ZAsKqf9KDE91at+nORAd3qaY7LaZ792bV3A7daa3+iHsq53 PbdC3WFi3uXJt5A3dXpMUGdVbcm1KgyfPvnsaOSzCmBQvWxh3A+d+BKV9mHajwzS LFAXzmfzneHK85augl0DVnBQKQQFa2Fm6ELofKpo1yEz+iAwpcThtMGUxnLp2J90 Y9VwGcombw+VmSpQd+G8a3aq6Aiyl1D+pswLCQImVYHp0d7afg0VD7wQF1053pig == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpedvudeuieehgfdvheeuueejjeeuudfgiefgveetfeelteef fffgtdejjefgueduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3785A3604F6; Tue, 23 Feb 2021 07:46:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com> In-Reply-To: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> Date: Tue, 23 Feb 2021 23:46:34 +1100 From: "Bron Gondwana" To: "Rifaat Shekh-Yusef" Cc: "Hannes Tschofenig" , "ietf@ietf.org" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=1a1bc007cb7b428d912b49137431339d Archived-At: Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 12:46:59 -0000 --1a1bc007cb7b428d912b49137431339d Content-Type: text/plain On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote: > So you have never reached out to us to try to bring any work to the WG, and based on attending one meeting and hearing from a few people, you formed a strong opinion and declared that "nothing would get done"? that seems odd. Based on a few meetings, and having heard from many people. > For your information, last year we published 4 RFCs, and we already have 3 documents with the IESG and more to come. That's good to hear. > If you have anything you want to bring to the OAuth WG, Hannes and I would be happy to discuss this with you or anyone that wants to bring work to the OAuth WG. Thanks. I don't mean to pick on OAuth specifically, but I also would recommend that you ask around and see whether my view of the culture of the OAuth working group is widely shared within the IETF or whether I've managed to find myself inside a small echo chamber that has a poor opinion of the welcoming-ness of the working group. Either way, the fact that the participants of the JMAP working group (including myself) who were all new to the IETF at the time were warned that OAuth is not a place where you can reasonably expect to get your work advanced is an indictment of SOMETHING, and that's worth having a think about in terms of making the IETF a welcoming place. Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --1a1bc007cb7b428d912b49137431339d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote:<= br>
So you have never reached out to us to = try to bring any work to the WG, and based on attending one meeting= and hearing from a few people, you formed a strong opinion and declared= that "nothing would get done"? that seems odd.

Based on a few meetings, and having heard from many= people.

<= div>
For your information, last year we published 4 RFCs, and we alr= eady have 3 documents with the IESG and more to come.

That's good to hear.

If you have anything you = want to bring to the OAuth WG, Hannes and I would be happy to discuss th= is with you or anyone that wants to bring work to the OAuth WG.

Thanks.  I don't mean to pick= on OAuth specifically, but I also would recommend that you ask around a= nd see whether my view of the culture of the OAuth working group is wide= ly shared within the IETF or whether I've managed to find myself inside = a small echo chamber that has a poor opinion of the welcoming-ness of th= e working group.

Either way, the fact that the participan= ts of the JMAP working group (including myself) who were all new to the = IETF at the time were warned that OAuth is not a place where you can rea= sonably expect to get your work advanced is an indictment of SOMETHING, = and that's worth having a think about in terms of making the IETF a welc= oming place.

Regards,

Bron.

<= div id=3D"sig56629417">
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--1a1bc007cb7b428d912b49137431339d-- From nobody Tue Feb 23 04:47:13 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9F3A2AF6; Tue, 23 Feb 2021 04:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RAND_MKTG_HEADER=2.999, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dxpYb2oe; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dxpYb2oe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK2-K5fzjGea; Tue, 23 Feb 2021 04:47:01 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00055.outbound.protection.outlook.com [40.107.0.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995C73A2ACC; Tue, 23 Feb 2021 04:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sQFczHC5ibas5kgEXhbUMc+UeDDeyLuE4wFEVbYXtm4=; b=dxpYb2oeJzkyOa0LiTlJp+RmHsHFUQ1dzc3ot17XOrkzv1TfHlW0RCMx6M0519f4Uyzy6hjIIs2n1Bhr4wvoMRntwzQ70LprVzS2/MMReIX1Yr4cB85n/Y9y7EqqtJNHzMkJw9tydbVoCb2usj4Cnl1xoQS+8B7OcE3YKzqPGRo= Received: from DB8PR04CA0023.eurprd04.prod.outlook.com (2603:10a6:10:110::33) by HE1PR0802MB2219.eurprd08.prod.outlook.com (2603:10a6:3:c3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.29; Tue, 23 Feb 2021 12:46:55 +0000 Received: from DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:110:cafe::ef) by DB8PR04CA0023.outlook.office365.com (2603:10a6:10:110::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Tue, 23 Feb 2021 12:46:55 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT052.mail.protection.outlook.com (10.152.21.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Tue, 23 Feb 2021 12:46:55 +0000 Received: ("Tessian outbound fb307b4548b2:v71"); Tue, 23 Feb 2021 12:46:55 +0000 X-CR-MTA-TID: 64aa7808 Received: from 4d6303114c64.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6F555F1C-EBA3-4772-9260-47173B0DB090.1; Tue, 23 Feb 2021 12:46:50 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4d6303114c64.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 23 Feb 2021 12:46:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e1UYdU9qLImeVU5D4nWM+jO5lUk74NmYwDxTOcY3Vl8hfcuXqiiZnkKagYZFiE+TJEQ6oQs+S74oVSKVJ3JNksWLI860QESEAhMt4bnfy/IMlftNQ7uR2XaQzIp9pOu+EnCF1lbfzjucaRCtlnjbpAbhY0CTNZiwB2dJSUjx7o9RHX+gPjXAa/j9L7JGqLnCUk//h9eL95UBQ+P9XXQzafQzl+DkuoSF42cJ31Gd2z/XibjxqYl+rx5RC1BEx9s+J6LswPB/upWpK5c1P/EODZ7ktAVHbeHtxMS4u+LHqsz+/PA0UG45ODBXqcL8DGWIIFTc8piOL91l2MOIUSqWAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sQFczHC5ibas5kgEXhbUMc+UeDDeyLuE4wFEVbYXtm4=; b=Rag0cZN0zfgHmeqzNI0wixx3ZHVcubyhZpBpnYzL13NnEBw/trk/GUc/Iske1WPJukiRBPZU+HuSE6VBNa6p4RkXg0QAKhjmAC0wMWTkOdvFuKauqyDTiXfIdZbmKXO2dPkLINeplnD8XM/oI8X1jk/WCHWtnsZANEd2MAehxTic2HUxFAPf85LrnsxqO/bQaTYUjYfHXTt+uJ5Cw2V9v7WdHF/Ll7I/WKX8pTX39nHEgptugNArv3pf4oBlmzW9luIpNq4zMwSPSvYplULnjHYzD5OqghXXkpRBjBGcRX+WMbSe1OF/AtgqDKrdMrs9Zjm9/BE3lvrF2nWuszDcIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sQFczHC5ibas5kgEXhbUMc+UeDDeyLuE4wFEVbYXtm4=; b=dxpYb2oeJzkyOa0LiTlJp+RmHsHFUQ1dzc3ot17XOrkzv1TfHlW0RCMx6M0519f4Uyzy6hjIIs2n1Bhr4wvoMRntwzQ70LprVzS2/MMReIX1Yr4cB85n/Y9y7EqqtJNHzMkJw9tydbVoCb2usj4Cnl1xoQS+8B7OcE3YKzqPGRo= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3907.eurprd08.prod.outlook.com (2603:10a6:208:109::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.29; Tue, 23 Feb 2021 12:46:48 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::7484:8c2b:e664:648]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::7484:8c2b:e664:648%7]) with mapi id 15.20.3868.033; Tue, 23 Feb 2021 12:46:48 +0000 From: Hannes Tschofenig To: Bron Gondwana , "ietf@ietf.org" CC: "oauth@ietf.org" Thread-Topic: Diversity and Inclusiveness in the IETF Thread-Index: AQHXCXgbtlRdrPa6OEShU5hVFqdRTqplIz0AgABqRRCAABPPgIAABh3g Date: Tue, 23 Feb 2021 12:46:48 +0000 Message-ID: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 53FC5C4466259A4FB510A3E2BEEF471F.0 x-checkrecipientchecked: true Authentication-Results-Original: fastmailteam.com; dkim=none (message not signed) header.d=none;fastmailteam.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.115.86] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 55b8c082-efb1-4aa6-0273-08d8d7f91a0e x-ms-traffictypediagnostic: AM0PR08MB3907:|HE1PR0802MB2219: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:820;OLM:820; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: pCho264FVF3De02FeLeeWJ5bcxHPioTlJWHTG7AkXAJfuNqcwk3G4OB+rb9tjKiFduNyubJuEVlRphell9VMuYRFYtngHPT9rPOpp7bwKRXLwhbN3LqUcbjUhRUtFSwGCRFW7ENrFtPEsNJAzcBLAO+qQfN0Qf9rxTWiWsDutRLfkr2OfLB/WK8NXZa9YKTmKRVQThl+yYbiB0N+XeILc78/gE62m6PK6MIVR2h722THgPVW671ASlc4bsQkUPen+0GIA4iLvsH42s1moqWZwpLytHrK7e3Jy6RW3dqop0gNfIYkpqi0MVqqNjijkHWJFFxeBlwl8ifNYH9m3+vrJSdPvxX434PO6jxg3IUQUiwyxf59JdS9Ge4f8Nkc2GTplqmLC87xJJJAzgTbr0y4arZJMUje0+55PFtdbhI9kJvLXG9NjE0bZUnO7DbtYDcpGKMcmERf0Th1wM3Yms4WUxJO+2VweuIN+6N9ldxSGKArxrksfKHvBZE2WAKb8VO068OEFXIxDF9UzfMaK9aJ9a//2Z/zTLIHXTLJ7AIacaxN6n01veIL3X+H/TlKHCbiGvVObEIYBtadWhKo4Ms9x+7oLmnicyHjmifKuOWjZAE= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(39860400002)(366004)(396003)(66946007)(966005)(76116006)(71200400001)(86362001)(66476007)(478600001)(9326002)(8936002)(66556008)(66446008)(33656002)(64756008)(55016002)(52536014)(26005)(2906002)(66574015)(316002)(9686003)(110136005)(186003)(83380400001)(4326008)(6506007)(166002)(5660300002)(8676002)(53546011)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?R2JIejVuVkhxTDdUVytFVHVKNnMydDZHRGZNZDJCT0JKVjIrZWtDSWFndC9Q?= =?utf-8?B?RFp6UCtvR216ZE9tblc5SlY0dUZrYm1WamwxZkMxaThxeklSWGZrcGpheUdu?= =?utf-8?B?YWV1cmt6ODI2Ti9wMFlob0ZrQzF5Q0F6cXhqM2Z5UHdvZDFwb2Y3L05mY1Rz?= =?utf-8?B?cWU2Y2VmWGFyUFRRWmdmMXRYUCtWcDZFYklJMmlQRm9aSnBNeG9SdjYyK1JZ?= =?utf-8?B?dnVrUzBZeUNDc3NsTlYzbWcyWXNtK0hieEtCOHNWUnBuU3Z0aFFZekRneXZX?= =?utf-8?B?bUR3aEFxUDUyQ2lvTGlURS9UWFJVNWhNRDVQbmdzNFpEV3FqT01JWUljYWVz?= =?utf-8?B?dGNDMHJLdXVqMUpET0tCd0YyNTVOSjlTRDBDM2lNeDFMZElpaUJRK0JBbWlO?= =?utf-8?B?aDNjS0FUc1RZYzVMNldFTll2NTRLZDdYSTZSN0NKVmNLeU5MRUpuZWdyLzBh?= =?utf-8?B?QXlVNms0ODRzM1V4ajNvZFRMQm1BWFBJWDRyTlFxVmhiTU5MdHBrS1dHQzBD?= =?utf-8?B?RExYUUU1MTRGM0swQlo5UGhiZVFqWGkyVGlJVWVOcFBDYVB6dEVzSUVmVDhX?= =?utf-8?B?TitxdXFPOXYvN1Vud2hDM2grSW1GeTliN1JmbGZWQkRwS1hoNTFjZEp4Z1BQ?= =?utf-8?B?NHhjM3Y5d1dzL3psSWZTdHhCN25jOUJ4Z0Q5MmZvRDdzWkxNR21PK1YvWTI2?= =?utf-8?B?MUxDSTZsN2tXbHdNa05hRFE5YUxBMUpHQWtWK3BxcU5tRkdwcUVEdUR6SXF0?= =?utf-8?B?M1g0R0MrYVFaMzgrdkMrc3E5Qi8xb21lODZON1lEMlpac1FReldPa0MrQ0xo?= =?utf-8?B?eW5uajVSalB1blhvRm5lYitCOUx5TXN1MzJMSTNNME1MUXA4MldVd3JhN2V6?= =?utf-8?B?dlZpM0U4d3pjT0FESlN0S2JFZVdOb0R0dUtRcTZQVmlGNWY4anl2M3E5M04w?= =?utf-8?B?VlR4VHZEdmxtZHF6SkZXOCtmZzhlem4ycktFVTRwZFBhUE1BczhsY040ZDhm?= =?utf-8?B?VVA2b3J1M3hQRk9iaGJ6T1BVWmNja2VleUJjeVVia1BUbDRTQkFMYkl1Y01w?= =?utf-8?B?UE5yNmkrazJGMjkrUkJDcUxRdVdrSk1MbHFQaFNSUEJPVDcwU0dRT2xXSGQ3?= =?utf-8?B?N2FqZndEZVZFemEwdktMSkx6OHhQVTA3SUtTZTJ6eFE1WktiTFBueW1YTS9z?= =?utf-8?B?enZsWWJzNXJFMFNCL0pOWXEwYlptYlk3aG52SzJFamxicHE1a0JkaDR6WHR3?= =?utf-8?B?b1N3eVFlNE5aNHVTdE1KYjczTHlxcVlvaE93SmJ1NUJGazd4L1h5Vk02czNy?= =?utf-8?B?bUQxQnBIejlic3R2RlNmRVpyb3lVY004QWJXTUt5bmlyOU8yd29UQS9QNk5R?= =?utf-8?B?VTN3K3YzOW91aU5Vay9jMlM5TU9Rb1l6d2hnMDJoY1dmZ3FBOXIyNUlVTTJt?= =?utf-8?B?a2diK2NrWEE2am5RZjc2NmY4K1hDekpiN0RkRlNEWkcvMS83Z0QvTGJyaW01?= =?utf-8?B?VzJaTllUaUJIRzBHa2VoREh0a2xuRWp1Z0pBMlBwMERKQ1RCWHVwQVJab0Ru?= =?utf-8?B?MnBKOVQ3UlIwRVJrZXJOZ0VyZThKRE0ydFI5SGFHWDJ5YUxMTjZ0NkNzajRw?= =?utf-8?B?OXBwV2hUN0xRM0cwS0Y1NTZjLzh4VXRIbG1iSXRXVER6ZGN3UmZNTFlKUS8v?= =?utf-8?B?Q3lmL3gvVFBFRVJqUzhtOEg5VmVWYVBCTCt5T3phRXVTZDg0bGJRejVOUnJM?= =?utf-8?Q?Lt9wmPdAjUqVEWn8HvLpuRrrfoJb74A1FmkOf+G?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371608D64FF113417D8B3C2DFA809AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3907 Original-Authentication-Results: fastmailteam.com; dkim=none (message not signed) header.d=none;fastmailteam.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 7207b351-44a5-4bb4-ce8e-08d8d7f915b9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YNzFfE9lD17pQYudRZQosDX5ybDpBfTXwDV/Hw3zwAkjgIsDgCWI8ZywMfkkUO9epm6BREXU0cDdlwlNm0b6vQejgun4N5nwYe5hxBtKJhECBSLyGxvcLyO05I0u7sEdnDw74FQibR5XE2wTK43ORD9jxf4e15/fu4PdEjigkfzdOHiYkN66XkZ3KWr7bCcUYx9rGxdv4JVyJBJ9ockpVJO+z1MHGBLWeN+y0CB+iNIgo1FutsadA4S+rO+Bfj3IcB/hab8JfiZVuoAMyu+Hgv6WvVb7IF0OvWTDFb615aoCCAoXDSMmw21c9at6eHMrIWfnK5oYqreW5Ivbsiu9NSwoQDzedIgPtNZ4GPHPE0dSy4az1qUWIL1V1Y1XWUCvM0uoFTyraGkYBewazlWZxoaksZiiAIuNCTFvVpems0qsoka6Nxz77fjT+y1Ydosu4YPGjeOaVEbFEX64Bf05IH8HXvlnNE1Zhs0UQz29W0b7acxlCIzBK4xPBmRXa7H3tPs+iVSYsdYoPOfeF/2FRk+E+fdLfXqNjh8O2iTcYIZmlP4iVhL3wBDOqagh0duW3MEFqpvJf+QleB8iFOc/nBHqT16oBz8rvUm7JmW6goO609Z2k7V36HsEEb2g4DTrH1T2RDt/jjaYq/ZNJCQp88OprzC3ePOwnb9vEMEcbViHItHr/6WarGK8NxJyrLBMUcPJJsSWBmf4JSTFxb9bW5vYJzTZ6QveGngHk302zz8= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39860400002)(376002)(136003)(346002)(396003)(36840700001)(46966006)(82740400003)(82310400003)(83380400001)(86362001)(81166007)(166002)(356005)(110136005)(336012)(186003)(6506007)(33964004)(53546011)(66574015)(316002)(9686003)(36860700001)(55016002)(26005)(4326008)(7696005)(70206006)(450100002)(70586007)(5660300002)(8676002)(9326002)(8936002)(966005)(52536014)(30864003)(478600001)(33656002)(47076005)(2906002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2021 12:46:55.6779 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 55b8c082-efb1-4aa6-0273-08d8d7f91a0e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2219 Archived-At: Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 12:47:11 -0000 --_000_AM0PR08MB371608D64FF113417D8B3C2DFA809AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJvbiwNCg0KTGV0IG1lIGFsc28gdGVsbCB5b3UgYSBwZXJzb25hbCBzdG9yeS4gSSB3YXMg aW4gdGhlIGFybXkgaW4gQXVzdHJpYSBhbmQgYSBjb21tYW5kZXIgb2YgYSBzbWFsbCBncm91cC4g RXZlcnlvbmUgb24gdGhlIGJhc2Uga25ldyBhYm91dCBhIHB1YiBpbiB0aGUgY2l0eSB0aGF0IHdh cyBleHRyZW1lbHkgZGFuZ2Vyb3VzIGFuZCwgYWNjb3JkaW5nIHRvIHN0b3JpZXMsIHlvdSB3b3Vs ZCBtb3N0IGxpa2VseSBnZXQgc3RhYmJlZCB0aGVyZS4gSSB3YXMgd29uZGVyaW5nIGFib3V0IHRo YXQgcGxhY2UgYW5kIHdlbnQgdGhlcmUuIEd1ZXNzIHdoYXQ6IEkgd2FzIHRoZXJlIGFsb25lIHdp dGggdGhlIHdhaXRyZXNzLiBFdmVyeW9uZSB3YXMgdG9vIGFmcmFpZCB0byBnbyB0aGVyZS4NCg0K TWF5YmUgdGhlcmUgaXMgYSBsZXNzb24gaGVyZS4gSnVzdCBnaXZlIGl0IGEgdHJ5Ki4NCg0KR2V0 dGluZyBiYWNrIHRvIHRoZSBPQXV0aCBncm91cDogR3JvdXBzIHR5cGljYWxseSBnbyB0aHJvdWdo IGN5Y2xlcy4gQXQgdGhlIGJlZ2lubmluZyB3aGVuIHBhcnRpY2lwYW50cyBkbyBub3Qga25vdyBl YWNoIG90aGVyIHRoZSBkaXNjdXNzaW9ucyBhcmUgb2Z0ZW4gcm91Z2guIFdoZW4gdGhlcmUgaXMg bm90IG11Y2ggY29udGVudCAodHlwaWNhbGx5IGR1cmluZyBhIHJlcXVpcmVtZW50cyBnYXRoZXJp bmcgcGhhc2UpIGV2ZXJ5b25lIGhhcyBhbiBvcGluaW9uIHRvIHNoYXJlLiBBcyB0aW1lIGdvZXMg b24sIHRoZSBzaXR1YXRpb24gaW1wcm92ZXMgYW5kIGV2ZXJ5b25lIGdldHMgdG8ga25vdyBlYWNo IG90aGVyIGJldHRlciwgaGFuZ3MgYXJvdW5kIGFmdGVyIHRoZSBvZmZpY2lhbCBXRyBtZWV0aW5n cyBhbmQgbWVldHMgYXQgbm9uLUlFVEYgZXZlbnRzLiBUaGF04oCZcyB3aGVyZSBpdCBnZXRzIG1v cmUgY2l2aWxpemVkLiBXZSB3ZW50IHRocm91Z2ggdGhvc2Ugc3RhZ2VzIGFzIHdlbGwuDQoNCkdy b3VwcyB0aGF0IHdvcmsgb24gZXhjaXRpbmcgdGVjaG5vbG9naWVzIGFsc28gYXR0cmFjdCDigJxy b2NrIHN0YXJz4oCdIChhcyBJIGNhbGwgdGhlbSkuIFdlIGhhZCB0aG9zZSBpbiB0aGUgT0F1dGgg Z3JvdXAgYXMgd2VsbC4gSXQgY2F1c2VkIGEgbG90IG9mIHN0cmVzcyBmb3IgdGhlIGVudGlyZSBn cm91cCBidXQgYWxzbyBmb3IgdXMgY2hhaXJzLiBXaGVuIHlvdSBoYXZlIHNldmVyYWwgcGVvcGxl IHdobyBkbyBub3QgYWNjZXB0IGEgcHJvcG9zYWwgZGlmZmVyZW50IHRoYW4gdGhlaXIgb3duIHRo ZW4gaXQgZ2V0cyB0cmlja3kuIFVuZm9ydHVuYXRlbHksIGNoYWlycyBkb27igJl0IGhhdmUgbXVj aCB0byBzYXkgaW4gdGhlIElFVEYgZWl0aGVyLg0KDQpJIGJlbGlldmUgaXQgaGVscGVkIHVzIHRv IGdldCB0b2dldGhlciBpbiB3b3Jrc2hvcHMgKHdlIG9yZ2FuaXplZCBhIHNlcmllcyBvZiBPQXV0 aCB3b3Jrc2hvcHMpLCBtZXQgYXQgaW5kdXN0cnkgZXZlbnRzICh0aGUgSW50ZXJuZXQgSWRlbnRp dHkgV29ya3Nob3AsIGV0Yy4pIGFuZCBzY2hlZHVsZWQgcmVndWxhciDigJx2aXJ0dWFsIG9mZmlj ZSBob3Vyc+KAnS4gT2YgY291cnNlLCB3ZSBzdGlsbCBoYXZlIGRpc2FncmVlbWVudHMgYW5kIGl0 IHdvdWxkIGJlIGEgbGllIHRvIHNheSB0aGF0IGFsbCBvdXIgbWVldGluZ3MgaGF2ZSBiZWVuIHBy b2R1Y3RpdmUuIFByb2R1Y3Rpdml0eSBoYXMsIGhvd2V2ZXIsIGJlZW4gaW5jcmVhc2VkLiBUaGUg bWVldGluZ3Mgd2VyZSBjZXJ0YWlubHkgcGFzc2lvbmF0ZS4gT24gdGhlIG90aGVyIGhhbmQsIEkg aGF2ZSBiZWVuIGluIHdvcmtpbmcgZ3JvdXAgbWVldGluZ3Mgd2hlcmUgdGhlcmUgd2FzIG5vIHBh c3Npb24sIG5vIGRpc2N1c3Npb24gYW5kIG5vIHByb2R1Y3Rpdml0eS4gTm90IGdyZWF0IGVpdGhl ci4NCg0KSSBkb27igJl0IGtub3cgd2hldGhlciBpdCBpcyBhbHJlYWR5IHRvbyBsYXRlIGZvciB5 b3VyIGRvY3VtZW50ICh3aGljaCBpcyBkYXRlZCAyMDE2KSB0byBjb25zaWRlciB0aGUgdXNlIG9m IE9BdXRoIGJ1dCBSaWZhYXQgYW5kIEkgYXJlIGhhcHB5IHRvIHB1dCB5b3Ugb24gdGhlIHNwb3Qg aW4gb25lIG9mIG91ciBmdXR1cmUgdmlydHVhbCBvZmZpY2UgaG91cnMgb3IgdmlydHVhbCBpbnRl cmltIG1lZXRpbmdzLg0KDQpDaWFvDQpIYW5uZXMNCg0KUFM6IFRoaXMgaXMgbm90IGEgZ2VuZXJh bCBsaWZlIGFkdmljZS4gVGhlcmUgYXJlIG1hbnkgdGhpbmdzIHlvdSBiZXR0ZXIgc2tpcC4uLg0K DQpGcm9tOiBCcm9uIEdvbmR3YW5hIDxicm9uZ0BmYXN0bWFpbHRlYW0uY29tPg0KU2VudDogVHVl c2RheSwgRmVicnVhcnkgMjMsIDIwMjEgMTI6NTEgUE0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47IGlldGZAaWV0Zi5vcmcNCkNjOiBvYXV0aEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IERpdmVyc2l0eSBhbmQgSW5jbHVzaXZlbmVzcyBpbiB0aGUgSUVU Rg0KDQpXaXRob3V0IHdpc2hpbmcgdG8gbGl0aWdhdGUgdGhlIGVudGlyZSBpc3N1ZSBoZXJlICho YXBweSB0byByZW1vdmUgdGhlIHdpZGVyIElFVEYgbGlzdCBhbmQganVzdCB0YWxrIG9uIHRoZSBP QXV0aCBncm91cCksIHdlIG5ldmVyIGJyb3VnaHQgYW55IHdvcmsgdG8gdGhlIE9BdXRoIGdyb3Vw IGJlY2F1c2UgZXZlcnlib2R5IHdobyB3ZSBzcG9rZSB0byB3YXJuZWQgdXMgdGhhdCBub3RoaW5n IHdvdWxkIGdldCBkb25lLg0KDQpUaGVyZSdzIGEgdGVybSAibWlzc2luZyBzdGFpciIgaHR0cHM6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTWlzc2luZ19zdGFpciB3aGljaCBkZXNjcmliZXMgdGhp cyBwaGVub21lbm9uLCB3aGVyZSAiZXZlcnlib2R5IGtub3dzIiBzb21ldGhpbmcsIGJ1dCBuZXcg cGFydGljaXBhbnRzIGFyZSBmb3JjZWQgdG8gZGlzY292ZXIgaXQgdGhyb3VnaCBlaXRoZXIgaGF2 aW5nIHNvbWVvbmUgdGVsbCB0aGVtIHF1aWV0bHksIG9yIGp1c3Qgbm90aWNlIGl0IGZvciB0aGVt c2VsdmVzLg0KDQouLi4NCg0KSnVzdCBhcyBhbiBhbmVjZG90ZSwgdGhlIGxhc3QgdGltZSBJIGJv dGhlcmVkIHRvIGF0dGVuZCBhbiBPQXV0aCBtZWV0aW5nIGluIHBlcnNvbiBJIGhhZCB0aGlzIHRv IHNheSBhYm91dCBpdCBvbiBvdXIgaW50ZXJuYWwgc2xhY2sgY2hhbm5lbCB3aGVuIGFza2VkOiJ0 aGV5IGNhbid0IGFncmVlIGFib3V0IHdoYXQgdGhleSBkb24ndCBhZ3JlZSBvbiIuDQoNClRoZSB0 b3BpYyB0aGF0IGhhZCB0YWtlbiBiYXNpY2FsbHkgdGhlIGVudGlyZSBtZWV0aW5nIGFuZCBoYWQg YmVlbiB0b3RhbGx5IHVucHJvZHVjdGl2ZSAtIHdhcyBhIHBhcnRpY3VsYXIga2V5IGluIGEgSlNP TiBXZWIgVG9rZW4gZ29pbmcgdG8gY2xhc2ggd2l0aCBhIHJlc2VydmVkIHdvcmQgaW4gZWl0aGVy IGphdmFzY3JpcHQgaXRzZWxmIG9yIG9uZSBvZiB0aGUgb3RoZXIgZW52aXJvbm1lbnRzIGluIHdo aWNoIHRoaXMgdG9rZW4gaGFkIHRvIGJlIGV2YWx1YXRlZC4gIFRoZXJlIHdlcmUgcGVvcGxlIHNh eWluZyAidGhpcyB3b24ndCB3b3JrLCBqdXN0IHJlbmFtZSB0aGUga2V5IiBhbmQgb3RoZXJzIHNh eWluZyAiSSBsaWtlIHRoaXMgbmFtZSBhbmQgaW5zaXN0IHVwb24gdXMga2VlcGluZyBpdCIuICBO byBwcm9ncmVzcyB3YXMgbWFkZSB0aGF0IGRheS4NCg0KSW4gZmFjdCwgaGVyZSdzIHRoZSBleHRy YWN0IG9mIG15IHJlcG9ydCBvbiB0aGUgT0F1dGggbWVldGluZyBhdCBJRVRGMTAyIChhIGRldGFp bGVkIGxvbmcgZW1haWwgd2l0aCBwaWN0dXJlcyBvZiBwb3V0aW5lLCBpY2VjcmVhbSwgYW5kIGEg cmVwb3J0IG9uIGV2ZXJ5IHNlc3Npb24gSSBhdHRlbmRlZCkuICBOYW1lcyBleHRyYWN0ZWQgdG8g cHJvdGVjdCB0aGUgb3RoZXJzIGludm9sdmVkLCBidXQgb3RoZXIgdGV4dCBsZWZ0IGV4YWN0bHkg YXMgaXQgd2FzLCBjb21wbGV0ZSB3aXRoIHR5cG9lczoNCg0KVGh1cnNkYXkgMTl0aDogKEF1ZyAy MDE4KQ0KDQo5OjMwYW0gT0FVVEg8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n LzEwMi9tYXRlcmlhbHMvYWdlbmRhLTEwMi1vYXV0aC0wMz46ICBGZWNraW5nIE9BVVRIIGFzIHRo ZXkgc2F5LiAgSSBjYW1lIG91dCBvZiB0aGlzIHNheWluZyAidGhleSBjYW4ndCBldmVuIGFncmVl IGFib3V0IHdoYXQgdGhleSBkb24ndCBhZ3JlZSBvbiIuICA8TmFtZSByZWRhY3RlZD4gc2F5cyBp dCB3YXMgZXZlbiB3b3JzZSBpbiB0aGUgcGFzdC4gIFdoYXQgYSBmdXN0ZXJjbHVjay4gIERvbid0 IGV4cGVjdCBhbnl0aGluZyB3b3Jrd2hpbGUgb3V0IG9mIHRoaXMgZ3JvdXAgdW5mb3J0dW5hdGVs eS4gIDxPdGhlciBuYW1lIHJlZGFjdGVkPiBhbmQgSSB3ZXJlIGp1c3QgbG9va2luZyBhdCBlYWNo IG90aGVyIGxpa2UgV1RGIHRoZSBlbnRpcmUgdGltZS4NCg0KTWF5YmUgaXQncyBiZWNvbWUgaGVh cHMgYmV0dGVyIHNpbmNlIHRoZW4uICBCdXQgSSB3b3VsZG4ndCB3YW50IHRvIGhhdmUgYmVlbiBh IG5ldyBwYXJ0aWNpcGFudCB0cnlpbmcgdG8gZ2V0IGFueXRoaW5nIGRvbmUgaW4gdGhhdCBzZXNz aW9uLg0KDQouLi4NCg0KVGhlIGF1dGhlbnRpY2F0aW9uIGZsb3cgYXMgb3JpZ2luYWxseSBwdXQg aW50byBKTUFQIChiZWZvcmUgaXQgY2FtZSB0byB0aGUgSUVURikgY2FuIGJlIHNlZW4gaW4gdGhl IGluaXRpYWwgZHJhZnQgaGVyZSBpZiB5b3UncmUgaW50ZXJlc3RlZDoNCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1qZW5raW5zLWptYXAtMDAudHh0DQoNCkJ1dCB3ZSBk ZWNpZGVkIGluIHRoZSBpbnRlcmVzdHMgb2YgZXhwZWRpZW5jeSB0byBqdXN0IGRyb3AgaXQgcmF0 aGVyIHRoYW4gdHJ5aW5nIHRvIHByb2dyZXNzIHRoYXQgd29yayBhbnl3aGVyZSBhdCB0aGUgSUVU Ri4NCg0KUmVnYXJkcywNCg0KQnJvbi4NCg0KT24gVHVlLCBGZWIgMjMsIDIwMjEsIGF0IDIyOjAw LCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZToNCg0KSGkgQnJvbiwNCg0KDQoNCkkgaGF2ZSB0byBy ZXNwb25kIHRvIHlvdXIgc3RhdGVtZW50cyBhYm91dCB0aGUgT0F1dGggd29ya2luZyBncm91cCBi ZWxvdy4NCg0KDQoNCldoaWxlIHdlIGRvIG5vdCBwYXkgYXR0ZW50aW9uIHRvIGtlZXBpbmcgdGhl IGNoYXJ0ZXIgcGFnZSB1cC10by1kYXRlLCB3ZSBoYXZlIGJlZW4gYWJsZSB0byBhZHZhbmNlIG91 ciBkb2N1bWVudHMsIHByb2R1Y2UgbWFueSBpbXBsZW1lbnRhdGlvbnMsIGFuZCBnb3QgdGhvc2Ug ZGVwbG95ZWQgYWxsIG92ZXIgdGhlIEludGVybmV0Lg0KDQoNCg0KVGhlIGJhciBmb3IgYWNjZXB0 YW5jZSBvZiBuZXcgd29yayB2YXJpZXMgYW1vbmcgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4g U29tZSB3b3JraW5nIGdyb3VwcyBkZXZlbG9wIHRlY2hub2xvZ3kgdGhhdCBnb3Qgd2lkZWx5IGRl cGxveWVkIGFuZCBoZW5jZSByYW5kb21seSBjaGFuZ2luZyBzcGVjcyBpc27igJl0IHN1Y2ggYSBn cmVhdCBpZGVhIGJlY2F1c2UgeW91IGhhdmUgdG8gY29uc2lkZXIgdGhlIGRlcGxveW1lbnQgc2l0 dWF0aW9uIGFzIHdlbGwuIFRoaXMgaXMgYSBzaXR1YXRpb24gbWFueSBJRVRGIHdvcmtpbmcgZ3Jv dXBzIGZhY2UuIFJlYWNoaW5nICh3aWRlc3ByZWFkKSBkZXBsb3ltZW50IGlzIGdyZWF0IG9uIG9u ZSBoYW5kIGFuZCBhIHBhaW4gb24gdGhlIG90aGVyLg0KDQoNCg0KVGhlcmUgYXJlIG90aGVyIGdy b3Vwcywgd2hpY2ggYXJlIGVhcmx5IGluIHRoZWlyIGxpZmVjeWNsZS4gSW4gdGhvc2UgZ3JvdXBz IHlvdSBkbyBub3QgbmVlZCB0byB3b3JyeSBhYm91dCBkZXBsb3ltZW50cywgYmFja3dhcmRzIGNv bXBhdGliaWxpdHkgb3IgZXZlbiBhbnkgc291cmNlIGNvZGUuDQoNCg0KDQpJbiBnZW5lcmFsLCBS aWZhYXQgYW5kIEkgYXJlIGFsd2F5cyBvcGVuIGZvciBhbnlvbmUgaW4gdGhlIElFVEYgKGFuZCBv dXRzaWRlKSB0byByZWFjaCBvdXQgdG8gdXMsIGlmIHRoZXkgd2FudCB0byBicmluZyBuZXcgd29y ayBmb3J3YXJkIHRvIHRoZSBncm91cC4gU29tZXRpbWVzIHByb3Bvc2VkIHdvcmsgZml0cyBpbnRv IHRoZSBncm91cCBhbmQgc29tZXRpbWVzIGl0IGRvZXMgbm90LiBUaGUgd29yayBvbiBKT1NFLCBm b3IgZXhhbXBsZSwgd2FzIHB1dCBpbnRvIGEgc2VwYXJhdGUgd29ya2luZyBncm91cCBldmVuIHRo b3VnaCBpdCB3YXMgaW5pdGlhbGx5IGRldmVsb3BlZCBmb3IgdXNlIHdpdGggSlNPTiBXZWIgVG9r ZW5zLg0KDQoNCg0KSSBkb27igJl0IHJlY2FsbCBoYXZpbmcgY2hhdHRlZCB3aXRoIHlvdSBvciB3 aXRoIHNvbWVvbmUgZnJvbSB0aGUgSk1BUCBjb21tdW5pdHkgb24gdGhlIHVzZSBvZiBPQXV0aC4g U29ycnkgaWYgbXkgbWVtb3J5IGRvZXMgbm90IHNlcnZlIG1lIHdlbGwgdG9kYXkuICBUeXBpY2Fs bHksIGFwcGxpY2F0aW9ucyBqdXN0IHVzZSBPQXV0aCBhbmQgdGhlcmVmb3JlIHRoZXJlIGlzIG5v IG5lZWQgdG8gcmVhY2ggb3V0IHRvIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLg0KDQoNCg0KQ2lh bw0KDQpIYW5uZXMNCg0KDQpGcm9tOiBpZXRmIDxpZXRmLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmlldGYtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBCcm9uIEdvbmR3YW5hDQpTZW50 OiBUdWVzZGF5LCBGZWJydWFyeSAyMywgMjAyMSA1OjIwIEFNDQpUbzogaWV0ZkBpZXRmLm9yZzxt YWlsdG86aWV0ZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBEaXZlcnNpdHkgYW5kIEluY2x1c2l2 ZW5lc3MgaW4gdGhlIElFVEYNCg0KDQoNClRoYW5rcyBGZXJuYW5kbywNCg0KDQoNCkkgd291bGQg YWRkIHRvIHRoaXMgZG9jdW1lbnQgc29tZXRoaW5nIGFib3V0IGluZXJ0aWEsIGJhY2t3YXJkcyBj b21wYXRpYmlsaXR5IGFuZCBleGlzdGluZyBkeXNmdW5jdGlvbi4NCg0KDQoNCk1hbnkgaWRlYXMg YXJlIHNodXQgZG93biBiZWNhdXNlIHRoZXkgYXJlbid0IGluIHRoZSByaWdodCBwbGFjZSwgb3Ig ZG9uJ3QgZml0IGNvbWZvcnRhYmx5IGludG8gdGhlIGV4aXN0aW5nIGNvcnB1cyBvZiBJRVRGIGRv Y3VtZW50cy4NCg0KDQoNCldoZW4gd2UgYnJvdWdodCBKTUFQIHRvIHRoZSBJRVRGIGl0IHdhcyBh ZnRlciBhIGxvbmcgcHJvY2VzcyBvZiBzb2NpYWxpc2F0aW9uLCBhbmQgc3RpbGwgdGhlcmUgd2Fz IHNpZ25pZmljYW50IHdvcmsgaW4gdGhlIGZpcnN0IGNvdXBsZSBvZiBtZWV0aW5ncyBqdXN0IHRv IGNvbnZpbmNlIHBlb3BsZSB0aGF0ICJ0aGlzIGlzIHdvcnRoIGRvaW5nLCB0aGUgZXhpc3Rpbmcg d29yayB0aGUgSUVURiBoYXMgZG9uZSBpbiB0aGlzIG5laWdoYm9yaG9vZCBpcyBub3Qgc3VmZmlj aWVudCIuDQoNCg0KDQpKTUFQIGFsc28gaGFkIGFuIGF1dGhlbnRpY2F0aW9uIHNjaGVtZSBpbiBp dCBvcmlnaW5hbGx5LiAgSXQgd2FzIGEgZ29vZCBhdXRoZW50aWNhdGlvbiBzY2hlbWUsIGJ1dCBh cHBsaWNhdGlvbnMgZG9uJ3QgZG8gYXV0aGVudGljYXRpb24gc2NoZW1lcywgdGhhdCdzIHRoZSBi YWlsaXdpY2sgb2YgT0FVVEgsIHdoZXJlIGlkZWFzIGdvIHRvIGRpZSAoaW4gbXkgZXhwZXJpZW5j ZSwgdGhhdCB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIGR5c2Z1bmN0aW9uYWwgZm9yIG15IGVudGly ZSB0aW1lIGF0IElFVEYgLSBleGhpYml0ICdBJyBiZWluZyB0aGUgIk1pbGVzdG9uZXMiIHNlY3Rp b24gb2YgdGhlIGFib3V0IHBhZ2UsIHdoaWNoIGxpc3RzIDYgaXRlbXMgYWxsIGR1ZSBpbiAyMDE3 KQ0KDQoNCg0KU28gd2UganVzdCByZW1vdmVkIGFsbCBtZW50aW9uIG9mIGF1dGhlbnRpY2F0aW9u IG1ldGhvZCBhbmQgaGFuZHdhdmVkICJ0aGUgY29ubmVjdGlvbiB3aWxsIGJlIGF1dGhlbnRpY2F0 ZWQiLCBiZWNhdXNlIHdlIHdhbnRlZCB0byBwdWJsaXNoIHNvbWV0aGluZyBkdXJpbmcgdGhlIGRl Y2FkZSB3aXRoIHllYXJzIHN0YXJ0aW5nICcyMDEnLg0KDQoNCg0KLi4uIGFsbCB0aGF0IHRvIHNh eS4gIE9uZSBvZiB0aGUgYmlnZ2VzdCBiYXJyaWVycyB0byBlbnRyeSBpbiB0aGUgSUVURiBpcyBz dHVtYmxpbmcgYWNyb3NzIGFuIGFyZWEgaW4gd2hpY2ggbm8gd29yayBpcyBhYmxlIHRvIHByb2dy ZXNzIGR1ZSB0byBlbnRyZW5jaGVkIGlzc3VlcyB3aXRoaW4gdGhhdCBhcmVhLg0KDQoNCg0KQW5k IEknbSBub3QgYXJndWluZyBmb3IgIm5vIGJhcnJpZXJzIHRvIGVudHJ5IiwgYmVjYXVzZSB0aGVy ZSBuZWVkcyB0byBiZSBhIHNhbml0eSBjaGVjayB0aGF0IHdlJ3JlIGFjdHVhbGx5IHByb2R1Y2lu ZyBoaWdoIHF1YWxpdHkgc3BlY2lmaWNhdGlvbnMsIGFuZCB0aGF0IG91ciBzcGVjaWZpY2F0aW9u cyBhcmUgY29tcGF0aWJsZSB3aXRoIGVhY2ggb3RoZXIgc28gdGhlIGVudGlyZXR5IG9mIHRoZSBJ RVRGJ3Mgd29yayBwcm9kdWN0IGlzIGEgY29oZXJlbnQgd2hvbGUuICBCdXQgaXQncyBoYXJkIHRv IGdldCBzdGFydGVkIGlmIHlvdSBkb24ndCBhbHJlYWR5IGhhdmUgdGhlIGNvbm5lY3Rpb25zIHRv IGhhdmUgeW91ciB3b3JrIHNwb25zb3JlZCBieSBzb21lYm9keSB3aG8gYWxyZWFkeSBrbm93cyB0 aGVpciB3YXkgYXJvdW5kIHRoZSBJRVRGJ3MgaWRpb3N5bmNyYXNpZXMuICBJJ20gZG9pbmcgc29t ZSBvZiB0aGF0IHNwb25zb3JpbmcgbXlzZWxmIG5vdyBmb3IgdGhlIHBlb3BsZSBmcm9tIHRjMzkg d2hvIGFyZSB0cnlpbmcgdG8gZ2V0IHRoZSBJRVRGIHRvIGxvb2sgYXQgZGVmaW5pbmcgYW4gZXh0 ZW5kZWQgZGF0ZXRpbWUgZm9ybWF0Lg0KDQoNCg0KQ2hlZXJzLA0KDQoNCg0KQnJvbi4NCg0KDQoN Ck9uIFR1ZSwgRmViIDIzLCAyMDIxLCBhdCAxMTowNywgRmVybmFuZG8gR29udCB3cm90ZToNCg0K Rm9sa3MsDQoNCg0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBJLUQsIGVudGl0bGVkICJEaXZl cnNpdHkgYW5kIEluY2x1c2l2ZW5lc3MgaW4NCg0KdGhlIElFVEYiLg0KDQoNCg0KVGhlIEktRCBp cyBhdmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt Z29udC1kaXZlcnNpdHktYW5hbHlzaXMtMDAudHh0DQoNCg0KDQpXZSBleHBlY3QgdGhhdCBvdXIg ZG9jdW1lbnQgYmUgZGlzY3Vzc2VkIGluIHRoZSBnZW5kaXNwYXRjaCB3Zw0KDQooaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy9nZW5kaXNwYXRjaC9hYm91dC8pLiBCdXQgZ2l2ZW4gdGhl DQoNCmJyZWFkdGggb2YgdGhlIHRvcGljIGFuZCBwb3NzaWJsZSB2aWV3cywgd2UnbGwgYmUgZ2xh ZCB0byBkaXNjdXNzIGl0DQoNCndoZXJlIG5lY2Vzc2FyeS9hcHBsaWNhYmxlL2Rlc2lyZWQuDQoN Cg0KDQpBcyBleHBsaWNpdGx5IG5vdGVkIGluIG91ciBJLUQsIHdlJ3JlIHByb2JhYmx5IG9ubHkg c2NyYXRjaGluZyB0aGUNCg0Kc3VyZmFjZSBoZXJlIC0tIGJ1dCB3ZSBiZWxpZXZlIHRoYXQgb3Vy IGRvY3VtZW50IGlzIHByb2JhYmx5IGEgZ29vZA0KDQpzdGFydCB0byBkaXNjdXNzIG1hbnkgYXNw ZWN0cyBvZiBkaXZlcnNpdHkgdGhhdCBkZXNlcnZlIGRpc2N1c3Npb24uDQoNCg0KDQpUaGFua3Mh DQoNCg0KDQpSZWdhcmRzLA0KDQotLQ0KDQpGZXJuYW5kbyBHb250DQoNClNJNiBOZXR3b3Jrcw0K DQplLW1haWw6IGZnb250QHNpNm5ldHdvcmtzLmNvbTxtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3Mu Y29tPg0KDQpQR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZCMSBFM0M0IEFF MjUgMEQ1NSAxRDRFIDc0OTINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0NCg0KICBCcm9u IEdvbmR3YW5hLCBDRU8sIEZhc3RtYWlsIFB0eSBMdGQNCg0KICBicm9uZ0BmYXN0bWFpbHRlYW0u Y29tPG1haWx0bzpicm9uZ0BmYXN0bWFpbHRlYW0uY29tPg0KDQoNCg0KDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCi0tDQogIEJyb24gR29uZHdhbmEsIENFTywgRmFz dG1haWwgUHR5IEx0ZA0KICBicm9uZ0BmYXN0bWFpbHRlYW0uY29tPG1haWx0bzpicm9uZ0BmYXN0 bWFpbHRlYW0uY29tPg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N Cg== --_000_AM0PR08MB371608D64FF113417D8B3C2DFA809AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnF0LW1zb25vcm1h bDEsIGxpLnF0LW1zb25vcm1hbDEsIGRpdi5xdC1tc29ub3JtYWwxDQoJe21zby1zdHlsZS1uYW1l OnF0LW1zb25vcm1hbDE7DQoJbWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uc2l6ZQ0KCXttc28tc3R5bGUtbmFt ZTpzaXplO30NCnNwYW4uZm9udA0KCXttc28tc3R5bGUtbmFtZTpmb250O30NCnNwYW4uRW1haWxT dHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBCcm9uLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TGV0IG1lIGFsc28gdGVsbCB5b3UgYSBwZXJzb25hbCBzdG9yeS4gSSB3YXMgaW4gdGhlIGFy bXkgaW4gQXVzdHJpYSBhbmQgYSBjb21tYW5kZXIgb2YgYSBzbWFsbCBncm91cC4gRXZlcnlvbmUg b24gdGhlIGJhc2Uga25ldyBhYm91dCBhIHB1YiBpbiB0aGUgY2l0eSB0aGF0IHdhcyBleHRyZW1l bHkgZGFuZ2Vyb3VzIGFuZCwgYWNjb3JkaW5nIHRvIHN0b3JpZXMsIHlvdSB3b3VsZCBtb3N0IGxp a2VseSBnZXQgc3RhYmJlZA0KIHRoZXJlLiBJIHdhcyB3b25kZXJpbmcgYWJvdXQgdGhhdCBwbGFj ZSBhbmQgd2VudCB0aGVyZS4gR3Vlc3Mgd2hhdDogSSB3YXMgdGhlcmUgYWxvbmUgd2l0aCB0aGUg d2FpdHJlc3MuIEV2ZXJ5b25lIHdhcyB0b28gYWZyYWlkIHRvIGdvIHRoZXJlLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1heWJlIHRoZXJlIGlzIGEgbGVzc29uIGhlcmUuIEp1c3QgZ2l2ZSBp dCBhIHRyeSouPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdldHRpbmcgYmFjayB0byB0aGUgT0F1 dGggZ3JvdXA6IEdyb3VwcyB0eXBpY2FsbHkgZ28gdGhyb3VnaCBjeWNsZXMuIEF0IHRoZSBiZWdp bm5pbmcgd2hlbiBwYXJ0aWNpcGFudHMgZG8gbm90IGtub3cgZWFjaCBvdGhlciB0aGUgZGlzY3Vz c2lvbnMgYXJlIG9mdGVuIHJvdWdoLiBXaGVuIHRoZXJlIGlzIG5vdCBtdWNoIGNvbnRlbnQgKHR5 cGljYWxseSBkdXJpbmcgYSByZXF1aXJlbWVudHMgZ2F0aGVyaW5nIHBoYXNlKQ0KIGV2ZXJ5b25l IGhhcyBhbiBvcGluaW9uIHRvIHNoYXJlLiBBcyB0aW1lIGdvZXMgb24sIHRoZSBzaXR1YXRpb24g aW1wcm92ZXMgYW5kIGV2ZXJ5b25lIGdldHMgdG8ga25vdyBlYWNoIG90aGVyIGJldHRlciwgaGFu Z3MgYXJvdW5kIGFmdGVyIHRoZSBvZmZpY2lhbCBXRyBtZWV0aW5ncyBhbmQgbWVldHMgYXQgbm9u LUlFVEYgZXZlbnRzLiBUaGF04oCZcyB3aGVyZSBpdCBnZXRzIG1vcmUgY2l2aWxpemVkLiBXZSB3 ZW50IHRocm91Z2ggdGhvc2Ugc3RhZ2VzDQogYXMgd2VsbC4gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdyb3VwcyB0aGF0IHdvcmsgb24gZXhjaXRpbmcgdGVjaG5vbG9naWVzIGFsc28gYXR0cmFj dCDigJxyb2NrIHN0YXJz4oCdIChhcyBJIGNhbGwgdGhlbSkuIFdlIGhhZCB0aG9zZSBpbiB0aGUg T0F1dGggZ3JvdXAgYXMgd2VsbC4gSXQgY2F1c2VkIGEgbG90IG9mIHN0cmVzcyBmb3IgdGhlIGVu dGlyZSBncm91cCBidXQgYWxzbyBmb3IgdXMgY2hhaXJzLiBXaGVuIHlvdSBoYXZlIHNldmVyYWwg cGVvcGxlIHdobyBkbyBub3QNCiBhY2NlcHQgYSBwcm9wb3NhbCBkaWZmZXJlbnQgdGhhbiB0aGVp ciBvd24gdGhlbiBpdCBnZXRzIHRyaWNreS4gVW5mb3J0dW5hdGVseSwgY2hhaXJzIGRvbuKAmXQg aGF2ZSBtdWNoIHRvIHNheSBpbiB0aGUgSUVURiBlaXRoZXIuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYmVsaWV2ZSBpdCBoZWxwZWQgdXMgdG8gZ2V0IHRvZ2V0aGVyIGluIHdvcmtzaG9wcyAo d2Ugb3JnYW5pemVkIGEgc2VyaWVzIG9mIE9BdXRoIHdvcmtzaG9wcyksIG1ldCBhdCBpbmR1c3Ry eSBldmVudHMgKHRoZSBJbnRlcm5ldCBJZGVudGl0eSBXb3Jrc2hvcCwgZXRjLikgYW5kIHNjaGVk dWxlZCByZWd1bGFyIOKAnHZpcnR1YWwgb2ZmaWNlIGhvdXJz4oCdLiBPZiBjb3Vyc2UsIHdlIHN0 aWxsIGhhdmUgZGlzYWdyZWVtZW50cw0KIGFuZCBpdCB3b3VsZCBiZSBhIGxpZSB0byBzYXkgdGhh dCBhbGwgb3VyIG1lZXRpbmdzIGhhdmUgYmVlbiBwcm9kdWN0aXZlLiBQcm9kdWN0aXZpdHkgaGFz LCBob3dldmVyLCBiZWVuIGluY3JlYXNlZC4gVGhlIG1lZXRpbmdzIHdlcmUgY2VydGFpbmx5IHBh c3Npb25hdGUuIE9uIHRoZSBvdGhlciBoYW5kLCBJIGhhdmUgYmVlbiBpbiB3b3JraW5nIGdyb3Vw IG1lZXRpbmdzIHdoZXJlIHRoZXJlIHdhcyBubyBwYXNzaW9uLCBubyBkaXNjdXNzaW9uIGFuZA0K IG5vIHByb2R1Y3Rpdml0eS4gTm90IGdyZWF0IGVpdGhlci4gJm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IHdoZXRoZXIgaXQgaXMgYWxyZWFkeSB0b28gbGF0ZSBm b3IgeW91ciBkb2N1bWVudCAod2hpY2ggaXMgZGF0ZWQgMjAxNikgdG8gY29uc2lkZXIgdGhlIHVz ZSBvZiBPQXV0aCBidXQgUmlmYWF0IGFuZCBJIGFyZSBoYXBweSB0byBwdXQgeW91IG9uIHRoZSBz cG90IGluIG9uZSBvZiBvdXIgZnV0dXJlIHZpcnR1YWwgb2ZmaWNlIGhvdXJzIG9yIHZpcnR1YWwg aW50ZXJpbSBtZWV0aW5ncy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaWFvPGJyPg0KSGFu bmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBTOiBUaGlzIGlzIG5vdCBhIGdlbmVyYWwgbGlm ZSBhZHZpY2UuIFRoZXJlIGFyZSBtYW55IHRoaW5ncyB5b3UgYmV0dGVyIHNraXAuLi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBCcm9uIEdvbmR3YW5hICZsdDticm9uZ0BmYXN0bWFpbHRlYW0uY29tJmd0OyA8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMjMsIDIwMjEgMTI6NTEgUE08YnI+DQo8 Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t Jmd0OzsgaWV0ZkBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IERpdmVyc2l0eSBhbmQgSW5jbHVzaXZlbmVzcyBpbiB0aGUgSUVU RjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaXRob3V0IHdp c2hpbmcgdG8gbGl0aWdhdGUgdGhlIGVudGlyZSBpc3N1ZSBoZXJlIChoYXBweSB0byByZW1vdmUg dGhlIHdpZGVyIElFVEYgbGlzdCBhbmQganVzdCB0YWxrIG9uIHRoZSBPQXV0aCBncm91cCksIHdl IG5ldmVyIGJyb3VnaHQgYW55IHdvcmsgdG8gdGhlIE9BdXRoIGdyb3VwIGJlY2F1c2UgZXZlcnli b2R5IHdobyB3ZQ0KIHNwb2tlIHRvIHdhcm5lZCB1cyB0aGF0IG5vdGhpbmcgd291bGQgZ2V0IGRv bmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5UaGVyZSdzIGEgdGVybSAmcXVvdDttaXNzaW5nIHN0YWlyJnF1b3Q7Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTWlzc2luZ19zdGFpciI+aHR0 cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTWlzc2luZ19zdGFpcjwvYT4gd2hpY2ggZGVzY3Jp YmVzIHRoaXMgcGhlbm9tZW5vbiwgd2hlcmUgJnF1b3Q7ZXZlcnlib2R5IGtub3dzJnF1b3Q7IHNv bWV0aGluZywNCiBidXQgbmV3IHBhcnRpY2lwYW50cyBhcmUgZm9yY2VkIHRvIGRpc2NvdmVyIGl0 IHRocm91Z2ggZWl0aGVyIGhhdmluZyBzb21lb25lIHRlbGwgdGhlbSBxdWlldGx5LCBvciBqdXN0 IG5vdGljZSBpdCBmb3IgdGhlbXNlbHZlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi4uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SnVzdCBhcyBhbiBh bmVjZG90ZSwgdGhlIGxhc3QgdGltZSBJIGJvdGhlcmVkIHRvIGF0dGVuZCBhbiBPQXV0aCBtZWV0 aW5nIGluIHBlcnNvbiBJIGhhZCB0aGlzIHRvIHNheSBhYm91dCBpdCBvbiBvdXIgaW50ZXJuYWwg c2xhY2sgY2hhbm5lbCB3aGVuIGFza2VkOiZxdW90O3RoZXkgY2FuJ3QgYWdyZWUgYWJvdXQgd2hh dCB0aGV5IGRvbid0DQogYWdyZWUgb24mcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdG9waWMgdGhhdCBoYWQg dGFrZW4gYmFzaWNhbGx5IHRoZSBlbnRpcmUgbWVldGluZyBhbmQgaGFkIGJlZW4gdG90YWxseSB1 bnByb2R1Y3RpdmUgLSB3YXMgYSBwYXJ0aWN1bGFyIGtleSBpbiBhIEpTT04gV2ViIFRva2VuIGdv aW5nIHRvIGNsYXNoIHdpdGggYSByZXNlcnZlZCB3b3JkIGluIGVpdGhlciBqYXZhc2NyaXB0IGl0 c2VsZg0KIG9yIG9uZSBvZiB0aGUgb3RoZXIgZW52aXJvbm1lbnRzIGluIHdoaWNoIHRoaXMgdG9r ZW4gaGFkIHRvIGJlIGV2YWx1YXRlZC4mbmJzcDsgVGhlcmUgd2VyZSBwZW9wbGUgc2F5aW5nICZx dW90O3RoaXMgd29uJ3Qgd29yaywganVzdCByZW5hbWUgdGhlIGtleSZxdW90OyBhbmQgb3RoZXJz IHNheWluZyAmcXVvdDtJIGxpa2UgdGhpcyBuYW1lIGFuZCBpbnNpc3QgdXBvbiB1cyBrZWVwaW5n IGl0JnF1b3Q7LiZuYnNwOyBObyBwcm9ncmVzcyB3YXMgbWFkZSB0aGF0IGRheS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPklu IGZhY3QsIGhlcmUncyB0aGUgZXh0cmFjdCBvZiBteSByZXBvcnQgb24gdGhlIE9BdXRoIG1lZXRp bmcgYXQgSUVURjEwMiAoYSBkZXRhaWxlZCBsb25nIGVtYWlsIHdpdGggcGljdHVyZXMgb2YgcG91 dGluZSwgaWNlY3JlYW0sIGFuZCBhIHJlcG9ydCBvbiBldmVyeSBzZXNzaW9uIEkgYXR0ZW5kZWQp LiZuYnNwOyBOYW1lcyBleHRyYWN0ZWQNCiB0byBwcm90ZWN0IHRoZSBvdGhlcnMgaW52b2x2ZWQs IGJ1dCBvdGhlciB0ZXh0IGxlZnQgZXhhY3RseSBhcyBpdCB3YXMsIGNvbXBsZXRlIHdpdGggdHlw b2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJzaXplIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE2LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaHVy c2RheSAxOXRoOiAoQXVnIDIwMTgpPC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OTozMGFtPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAy L21hdGVyaWFscy9hZ2VuZGEtMTAyLW9hdXRoLTAzIiB0YXJnZXQ9Il9ibGFuayI+DQpPQVVUSDwv YT46Jm5ic3A7IEZlY2tpbmcgT0FVVEggYXMgdGhleSBzYXkuJm5ic3A7IEkgY2FtZSBvdXQgb2Yg dGhpcyBzYXlpbmcgJnF1b3Q7dGhleSBjYW4ndCBldmVuIGFncmVlIGFib3V0IHdoYXQgdGhleSBk b24ndCBhZ3JlZSBvbiZxdW90Oy4mbmJzcDsgJmx0O05hbWUgcmVkYWN0ZWQmZ3Q7IHNheXMgaXQg d2FzIGV2ZW4gd29yc2UgaW4gdGhlIHBhc3QuJm5ic3A7IFdoYXQgYSBmdXN0ZXJjbHVjay4mbmJz cDsgRG9uJ3QgZXhwZWN0IGFueXRoaW5nIHdvcmt3aGlsZSBvdXQgb2YgdGhpcyBncm91cCB1bmZv cnR1bmF0ZWx5LiZuYnNwOw0KICZsdDtPdGhlciBuYW1lIHJlZGFjdGVkJmd0OyBhbmQgSSB3ZXJl IGp1c3QgbG9va2luZyBhdCBlYWNoIG90aGVyIGxpa2UgV1RGIHRoZSBlbnRpcmUgdGltZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPk1heWJlIGl0J3MgYmVjb21lIGhlYXBzIGJldHRlciBzaW5jZSB0 aGVuLiZuYnNwOyBCdXQgSSB3b3VsZG4ndCB3YW50IHRvIGhhdmUgYmVlbiBhIG5ldyBwYXJ0aWNp cGFudCB0cnlpbmcgdG8gZ2V0IGFueXRoaW5nIGRvbmUgaW4gdGhhdCBzZXNzaW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5UaGUgYXV0aGVudGljYXRpb24gZmxvdyBhcyBvcmlnaW5hbGx5IHB1dCBpbnRv IEpNQVAgKGJlZm9yZSBpdCBjYW1lIHRvIHRoZSBJRVRGKSBjYW4gYmUgc2VlbiBpbiB0aGUgaW5p dGlhbCBkcmFmdCBoZXJlIGlmIHlvdSdyZSBpbnRlcmVzdGVkOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1qZW5raW5zLWptYXAtMDAudHh0Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWplbmtpbnMtam1hcC0wMC50eHQ8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5CdXQgd2UgZGVjaWRlZCBpbiB0aGUgaW50ZXJlc3RzIG9mIGV4cGVkaWVuY3kg dG8ganVzdCBkcm9wIGl0IHJhdGhlciB0aGFuIHRyeWluZyB0byBwcm9ncmVzcyB0aGF0IHdvcmsg YW55d2hlcmUgYXQgdGhlIElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QnJvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBGZWIgMjMsIDIwMjEsIGF0IDIyOjAwLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtvdmVyZmxvdy13cmFwOmJyZWFrLXdvcmQiIGlkPSJx dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPkhpIEJyb24sPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0icXQtbXNvbm9ybWFsMSI+SSBoYXZlIHRvIHJlc3BvbmQgdG8geW91ciBzdGF0ZW1lbnRz IGFib3V0IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9InF0LW1zb25vcm1hbDEiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InF0 LW1zb25vcm1hbDEiPldoaWxlIHdlIGRvIG5vdCBwYXkgYXR0ZW50aW9uIHRvIGtlZXBpbmcgdGhl IGNoYXJ0ZXIgcGFnZSB1cC10by1kYXRlLCB3ZSBoYXZlIGJlZW4gYWJsZSB0byBhZHZhbmNlIG91 ciBkb2N1bWVudHMsIHByb2R1Y2UgbWFueSBpbXBsZW1lbnRhdGlvbnMsIGFuZCBnb3QgdGhvc2Ug ZGVwbG95ZWQgYWxsIG92ZXIgdGhlIEludGVybmV0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 InF0LW1zb25vcm1hbDEiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InF0LW1zb25v cm1hbDEiPlRoZSBiYXIgZm9yIGFjY2VwdGFuY2Ugb2YgbmV3IHdvcmsgdmFyaWVzIGFtb25nIHdv cmtpbmcgZ3JvdXAgaW4gdGhlIElFVEYuIFNvbWUgd29ya2luZyBncm91cHMgZGV2ZWxvcCB0ZWNo bm9sb2d5IHRoYXQgZ290IHdpZGVseSBkZXBsb3llZCBhbmQgaGVuY2UgcmFuZG9tbHkgY2hhbmdp bmcgc3BlY3MgaXNu4oCZdCBzdWNoIGEgZ3JlYXQgaWRlYSBiZWNhdXNlIHlvdSBoYXZlIHRvIGNv bnNpZGVyIHRoZSBkZXBsb3ltZW50DQogc2l0dWF0aW9uIGFzIHdlbGwuIFRoaXMgaXMgYSBzaXR1 YXRpb24gbWFueSBJRVRGIHdvcmtpbmcgZ3JvdXBzIGZhY2UuIFJlYWNoaW5nICh3aWRlc3ByZWFk KSBkZXBsb3ltZW50IGlzIGdyZWF0IG9uIG9uZSBoYW5kIGFuZCBhIHBhaW4gb24gdGhlIG90aGVy LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPlRoZXJlIGFyZSBvdGhlciBncm91cHMs IHdoaWNoIGFyZSBlYXJseSBpbiB0aGVpciBsaWZlY3ljbGUuIEluIHRob3NlIGdyb3VwcyB5b3Ug ZG8gbm90IG5lZWQgdG8gd29ycnkgYWJvdXQgZGVwbG95bWVudHMsIGJhY2t3YXJkcyBjb21wYXRp YmlsaXR5IG9yIGV2ZW4gYW55IHNvdXJjZSBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 InF0LW1zb25vcm1hbDEiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InF0LW1zb25v cm1hbDEiPkluIGdlbmVyYWwsIFJpZmFhdCBhbmQgSSBhcmUgYWx3YXlzIG9wZW4gZm9yIGFueW9u ZSBpbiB0aGUgSUVURiAoYW5kIG91dHNpZGUpIHRvIHJlYWNoIG91dCB0byB1cywgaWYgdGhleSB3 YW50IHRvIGJyaW5nIG5ldyB3b3JrIGZvcndhcmQgdG8gdGhlIGdyb3VwLiBTb21ldGltZXMgcHJv cG9zZWQgd29yayBmaXRzIGludG8gdGhlIGdyb3VwIGFuZCBzb21ldGltZXMgaXQgZG9lcyBub3Qu IFRoZSB3b3JrIG9uDQogSk9TRSwgZm9yIGV4YW1wbGUsIHdhcyBwdXQgaW50byBhIHNlcGFyYXRl IHdvcmtpbmcgZ3JvdXAgZXZlbiB0aG91Z2ggaXQgd2FzIGluaXRpYWxseSBkZXZlbG9wZWQgZm9y IHVzZSB3aXRoIEpTT04gV2ViIFRva2Vucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJxdC1t c29ub3JtYWwxIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwx Ij5JIGRvbuKAmXQgcmVjYWxsIGhhdmluZyBjaGF0dGVkIHdpdGggeW91IG9yIHdpdGggc29tZW9u ZSBmcm9tIHRoZSBKTUFQIGNvbW11bml0eSBvbiB0aGUgdXNlIG9mIE9BdXRoLiBTb3JyeSBpZiBt eSBtZW1vcnkgZG9lcyBub3Qgc2VydmUgbWUgd2VsbCB0b2RheS4gJm5ic3A7VHlwaWNhbGx5LCBh cHBsaWNhdGlvbnMganVzdCB1c2UgT0F1dGggYW5kIHRoZXJlZm9yZSB0aGVyZSBpcyBubyBuZWVk IHRvIHJlYWNoIG91dA0KIHRvIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9InF0LW1zb25vcm1hbDEiPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJxdC1tc29u b3JtYWwxIj5IYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3Jk ZXItcmlnaHQtY29sb3I6Y3VycmVudGNvbG9yO2JvcmRlci1ib3R0b20tY29sb3I6Y3VycmVudGNv bG9yO2JvcmRlci1sZWZ0LWNvbG9yOmN1cnJlbnRjb2xvcjtib3JkZXItaW1hZ2Utb3V0c2V0OjA7 Ym9yZGVyLWltYWdlLXJlcGVhdDpzdHJldGNoO2JvcmRlci1pbWFnZS1zbGljZToxMDAlO2JvcmRl ci1pbWFnZS1zb3VyY2U6bm9uZTtib3JkZXItaW1hZ2Utd2lkdGg6MSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IGlldGYgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRm LWJvdW5jZXNAaWV0Zi5vcmciPmlldGYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkJyb24gR29uZHdhbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMywg MjAyMSA1OjIwIEFNPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+U3ViamVjdDo8L2I+IFJlOiBEaXZlcnNpdHkgYW5kIEluY2x1c2l2ZW5lc3MgaW4g dGhlIElFVEY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJxdC1tc29ub3JtYWwxIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i cXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MgRmVybmFuZG8sPC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3Jt YWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZv bnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5JIHdvdWxkIGFkZCB0byB0aGlzIGRvY3VtZW50IHNvbWV0aGluZyBhYm91dCBpbmVydGlhLCBi YWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhbmQgZXhpc3RpbmcgZHlzZnVuY3Rpb24uPC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3Jt YWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZv bnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5NYW55IGlkZWFzIGFyZSBzaHV0IGRvd24gYmVjYXVzZSB0aGV5IGFyZW4ndCBpbiB0aGUgcmln aHQgcGxhY2UsIG9yIGRvbid0IGZpdCBjb21mb3J0YWJseSBpbnRvIHRoZSBleGlzdGluZyBjb3Jw dXMgb2YgSUVURiBkb2N1bWVudHMuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i cXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5XaGVuIHdlIGJyb3VnaHQgSk1BUCB0byB0 aGUgSUVURiBpdCB3YXMgYWZ0ZXIgYSBsb25nIHByb2Nlc3Mgb2Ygc29jaWFsaXNhdGlvbiwgYW5k IHN0aWxsIHRoZXJlIHdhcyBzaWduaWZpY2FudCB3b3JrIGluIHRoZSBmaXJzdCBjb3VwbGUgb2Yg bWVldGluZ3MganVzdCB0byBjb252aW5jZSBwZW9wbGUNCiB0aGF0ICZxdW90O3RoaXMgaXMgd29y dGggZG9pbmcsIHRoZSBleGlzdGluZyB3b3JrIHRoZSBJRVRGIGhhcyBkb25lIGluIHRoaXMgbmVp Z2hib3Job29kIGlzIG5vdCBzdWZmaWNpZW50JnF1b3Q7Ljwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xh c3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Sk1BUCBhbHNvIGhh ZCBhbiBhdXRoZW50aWNhdGlvbiBzY2hlbWUgaW4gaXQgb3JpZ2luYWxseS4mbmJzcDsgSXQgd2Fz IGEgZ29vZCBhdXRoZW50aWNhdGlvbiBzY2hlbWUsIGJ1dCBhcHBsaWNhdGlvbnMgZG9uJ3QgZG8g YXV0aGVudGljYXRpb24gc2NoZW1lcywgdGhhdCdzIHRoZSBiYWlsaXdpY2sgb2YNCiBPQVVUSCwg d2hlcmUgaWRlYXMgZ28gdG8gZGllIChpbiBteSBleHBlcmllbmNlLCB0aGF0IHdvcmtpbmcgZ3Jv dXAgaGFzIGJlZW4gZHlzZnVuY3Rpb25hbCBmb3IgbXkgZW50aXJlIHRpbWUgYXQgSUVURiAtIGV4 aGliaXQgJ0EnIGJlaW5nIHRoZSAmcXVvdDtNaWxlc3RvbmVzJnF1b3Q7IHNlY3Rpb24gb2YgdGhl IGFib3V0IHBhZ2UsIHdoaWNoIGxpc3RzIDYgaXRlbXMgYWxsIGR1ZSBpbiAyMDE3KTwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0 LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBj bGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPlNvIHdlIGp1c3QgcmVtb3ZlZCBhbGwgbWVudGlvbiBvZiBhdXRoZW50aWNhdGlv biBtZXRob2QgYW5kIGhhbmR3YXZlZCAmcXVvdDt0aGUgY29ubmVjdGlvbiB3aWxsIGJlIGF1dGhl bnRpY2F0ZWQmcXVvdDssIGJlY2F1c2Ugd2Ugd2FudGVkIHRvIHB1Ymxpc2ggc29tZXRoaW5nIGR1 cmluZyB0aGUgZGVjYWRlIHdpdGgNCiB5ZWFycyBzdGFydGluZyAnMjAxJy48L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEi PjxzcGFuIGNsYXNzPSJmb250Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi4u LiBhbGwgdGhhdCB0byBzYXkuJm5ic3A7IE9uZSBvZiB0aGUgYmlnZ2VzdCBiYXJyaWVycyB0byBl bnRyeSBpbiB0aGUgSUVURiBpcyBzdHVtYmxpbmcgYWNyb3NzIGFuIGFyZWEgaW4gd2hpY2ggbm8g d29yayBpcyBhYmxlIHRvIHByb2dyZXNzIGR1ZSB0byBlbnRyZW5jaGVkIGlzc3VlcyB3aXRoaW4N CiB0aGF0IGFyZWEuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9y bWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BbmQgSSdtIG5vdCBhcmd1aW5nIGZvciAmcXVvdDtubyBi YXJyaWVycyB0byBlbnRyeSZxdW90OywgYmVjYXVzZSB0aGVyZSBuZWVkcyB0byBiZSBhIHNhbml0 eSBjaGVjayB0aGF0IHdlJ3JlIGFjdHVhbGx5IHByb2R1Y2luZyBoaWdoIHF1YWxpdHkgc3BlY2lm aWNhdGlvbnMsIGFuZCB0aGF0IG91ciBzcGVjaWZpY2F0aW9ucw0KIGFyZSBjb21wYXRpYmxlIHdp dGggZWFjaCBvdGhlciBzbyB0aGUgZW50aXJldHkgb2YgdGhlIElFVEYncyB3b3JrIHByb2R1Y3Qg aXMgYSBjb2hlcmVudCB3aG9sZS4mbmJzcDsgQnV0IGl0J3MgaGFyZCB0byBnZXQgc3RhcnRlZCBp ZiB5b3UgZG9uJ3QgYWxyZWFkeSBoYXZlIHRoZSBjb25uZWN0aW9ucyB0byBoYXZlIHlvdXIgd29y ayBzcG9uc29yZWQgYnkgc29tZWJvZHkgd2hvIGFscmVhZHkga25vd3MgdGhlaXIgd2F5IGFyb3Vu ZCB0aGUgSUVURidzIGlkaW9zeW5jcmFzaWVzLiZuYnNwOw0KIEknbSBkb2luZyBzb21lIG9mIHRo YXQgc3BvbnNvcmluZyBteXNlbGYgbm93IGZvciB0aGUgcGVvcGxlIGZyb20gdGMzOSB3aG8gYXJl IHRyeWluZyB0byBnZXQgdGhlIElFVEYgdG8gbG9vayBhdCBkZWZpbmluZyBhbiBleHRlbmRlZCBk YXRldGltZSBmb3JtYXQuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNv bm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFz cz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ccm9uLjwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9y bWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+T24gVHVl LCBGZWIgMjMsIDIwMjEsIGF0IDExOjA3LCBGZXJuYW5kbyBHb250IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0IiBpZD0icXQtcXQiPg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwx Ij48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPkZvbGtzLDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+V2UgaGF2ZSBzdWJtaXR0ZWQgYSBu ZXcgSS1ELCBlbnRpdGxlZCAmcXVvdDtEaXZlcnNpdHkgYW5kIEluY2x1c2l2ZW5lc3MgaW4mbmJz cDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+dGhlIElFVEYmcXVvdDsuPC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3Jt YWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZv bnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5UaGUgSS1EIGlzIGF2YWlsYWJsZSBhdDombmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNz PSJmb250Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1nb250 LWRpdmVyc2l0eS1hbmFseXNpcy0wMC50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUv aWQvZHJhZnQtZ29udC1kaXZlcnNpdHktYW5hbHlzaXMtMDAudHh0PC9hPjwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+ PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+V2Ug ZXhwZWN0IHRoYXQgb3VyIGRvY3VtZW50IGJlIGRpc2N1c3NlZCBpbiB0aGUgZ2VuZGlzcGF0Y2gg d2cmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+KDxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZ2VuZGlzcGF0Y2gvYWJvdXQvIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL3dnL2dlbmRpc3BhdGNoL2Fib3V0LzwvYT4pLiBCdXQgZ2l2ZW4gdGhl Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmJyZWFkdGggb2YgdGhlIHRvcGlj IGFuZCBwb3NzaWJsZSB2aWV3cywgd2UnbGwgYmUgZ2xhZCB0byBkaXNjdXNzIGl0PC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3Jt YWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPndoZXJlIG5lY2Vzc2FyeS9hcHBsaWNhYmxlL2Rlc2lyZWQu PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJx dC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4g Y2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5BcyBleHBsaWNpdGx5IG5vdGVkIGluIG91ciBJLUQsIHdlJ3JlIHByb2JhYmx5 IG9ubHkgc2NyYXRjaGluZyB0aGUmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ c3VyZmFjZSBoZXJlIC0tIGJ1dCB3ZSBiZWxpZXZlIHRoYXQgb3VyIGRvY3VtZW50IGlzIHByb2Jh Ymx5IGEgZ29vZCZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5zdGFydCB0byBk aXNjdXNzIG1hbnkgYXNwZWN0cyBvZiBkaXZlcnNpdHkgdGhhdCBkZXNlcnZlIGRpc2N1c3Npb24u PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJx dC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4g Y2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5UaGFua3MhPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQt bXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4g Y2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4tLSZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5GZXJuYW5k byBHb250PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNJNiBOZXR3b3Jrczwvc3Bhbj48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9y bWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5lLW1haWw6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmZnb250 QHNpNm5ldHdvcmtzLmNvbSI+ZmdvbnRAc2k2bmV0d29ya3MuY29tPC9hPjwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+ PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5QR1AgRmluZ2VycHJpbnQ6IDY2NjYgMzFDNiBENDg0IDYzQjIgOEZC MSBFM0M0IEFFMjUgMEQ1NSAxRDRFIDc0OTI8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0icXQtbXNvbm9ybWFsMSI+ PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJxdC1tc29ub3JtYWwxIj48c3BhbiBjbGFzcz0iZm9udCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0icXQt bXNvbm9ybWFsMSI+PHNwYW4gY2xhc3M9ImZvbnQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJxdC1zaWc1NjYyOTQxNyI+DQo8ZGl2Pg0KPHAgY2xh c3M9InF0LW1zb25vcm1hbDEiPi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0icXQtbXNvbm9ybWFsMSI+Jm5ic3A7IEJyb24gR29uZHdhbmEsIENFTywgRmFzdG1haWwg UHR5IEx0ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25v cm1hbDEiPiZuYnNwOyA8YSBocmVmPSJtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbSI+YnJv bmdAZmFzdG1haWx0ZWFtLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJxdC1tc29ub3JtYWwxIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9InF0LW1zb25vcm1hbDEiPjxzcGFuIGNsYXNzPSJmb250Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwNCiB1c2UgaXQgZm9yIGFueSBwdXJwb3Nl LCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5 b3UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJzaWc1NjYyOTQxNyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBCcm9uIEdv bmR3YW5hLCBDRU8sIEZhc3RtYWlsIFB0eSBMdGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyA8YSBocmVmPSJtYWlsdG86YnJvbmdAZmFz dG1haWx0ZWFtLmNvbSI+YnJvbmdAZmFzdG1haWx0ZWFtLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB371608D64FF113417D8B3C2DFA809AM0PR08MB3716eurp_-- From nobody Tue Feb 23 04:47:50 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E543A2AD7 for ; Tue, 23 Feb 2021 04:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.121 X-Spam-Level: ** X-Spam-Status: No, score=2.121 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTfBqLuuwJ3o for ; Tue, 23 Feb 2021 04:47:41 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC723A2B0D for ; Tue, 23 Feb 2021 04:47:41 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id u8so16872798ior.13 for ; Tue, 23 Feb 2021 04:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pMaV2Ick57t8vHAVGAxzAi6/O8CNR8c1AU5APiNcY7Y=; b=csXb7F8I4OGlOBZGWAWhjYdCCypSq1hWKAuAn742/EBhk1m+RZBPL0vZT/96O1fIpM iGQ4uqy9gU17AFn6V0BkJfPe/pKjTaopG6NF+7DqRXST0rPKej2D9Q5aX19VuEusEViv yvrb6ute+qkq1WS62QB/jZ3RgKyg0KYxwsOtsZkGSXX1m3K4tpnQ0n/joV58Ks4v8ANl hLtm2D4fwMyz2A5qilEjD+d54vm67oVNxwAm1Y8R1QblDIy80yVpduzdFTKBVVgUCINx hg5diZcfXjrJ5n2OXe8cbTJBSuUq6AtKOfg3vroXkNNTZpencoc43GI8m0u8Yqgd7yYz TCfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pMaV2Ick57t8vHAVGAxzAi6/O8CNR8c1AU5APiNcY7Y=; b=m6cXlKQCLVNWXQc59lDpfcuXcYUT722MA5L6EDXRODEvc5/jUNhWpPZSCxod10U2Ei bMINVIZosTBmu1j6jBga+d2JKpgrMgHLoto9lvmjNwv5R/9/DQojIiy58dEd6gUqC0ZN EYLT5QGSE0RrBxxxu2a2MKph4FNpfDuu2zRyxPM6lXpj4WDQtjUA58s3T5CEh+0DR5RS amM0p05FIxtP5OB0cpiJfA/9DgQmAU/N6n//sPnjla8F3/gQuKS2aEM/N0kcI8AlnB+D tL508+FZPBOc5gHhMR/DGqs4umo3tUK3BiItbGZJcgXXm/9Kh6lMNjQfJ9xga6mS82O/ oibA== X-Gm-Message-State: AOAM5319CtB1gv2mLkN4FXn5osYuYX9Rt2rvcP2VTQjhe/sDAVufLXj4 2LsmpNF4IWAbPufdAHU/WDw499Je3E4o0c91tS6DPxiGXic= X-Google-Smtp-Source: ABdhPJyjFXLhKR4b4U0/at9w9fRhU8oTL95O5Sthp1xthkpg1uYBXlVQbp7JeJTmxz3j7ecc1DL0/hZHLSm6qjL4vdQ= X-Received: by 2002:a5e:8d12:: with SMTP id m18mr15801053ioj.47.1614084460045; Tue, 23 Feb 2021 04:47:40 -0800 (PST) MIME-Version: 1.0 From: Halim Dimitry Halim Date: Tue, 23 Feb 2021 14:47:26 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e0e9cb05bc00520f" Archived-At: Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 12:47:49 -0000 --000000000000e0e9cb05bc00520f Content-Type: text/plain; charset="UTF-8" --000000000000e0e9cb05bc00520f Content-Type: text/html; charset="UTF-8"
--000000000000e0e9cb05bc00520f-- From nobody Tue Feb 23 05:03:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD66D3A2AEB for ; Tue, 23 Feb 2021 05:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FZJzb+qW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u3k0jrMT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8WbqPjsEYFy for ; Tue, 23 Feb 2021 05:03:18 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF3D3A2AE9 for ; Tue, 23 Feb 2021 05:03:18 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id CA2C95C008C; Tue, 23 Feb 2021 08:03:17 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 08:03:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=G4Sn cxe29R14ZJpwz2Nd9CL8MmzrHpbjEDX0Ks9kA0k=; b=FZJzb+qWUk4vYT8vpVYu 6oIQbkatI4/rSnIuVlp1Pv5NmC2iBqhcEUWnISI6lVaADR1tfj5MjEm2ifyctgtS TsyfD77GJEMFkKgy15T2yPuPZtX/QtEISraktPeP2uJM2KyHzFauj04l/YVpRX6j v/AS2RGo6xz36NMY1Qp0GtkrCPRS/mmSoZds5yPScWSct74p+VPQfsaGwrmelP5+ TnIQ6dhsDnqp8jnzM4pD1zbL75yJtgl4sWu6/QfZAPWUdAeDIaIxlPDIG7unBv4o hv3kwtNqobjVp6hgQyQBtsWFWyxYAO+H4f+HCZLt4qzbBjmYxTuqSy1KgdTsAfuo 2w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=G4Sncx e29R14ZJpwz2Nd9CL8MmzrHpbjEDX0Ks9kA0k=; b=u3k0jrMTbL9Na8VqGy0eTO JyYuy6lKvM05ci/2sdnec8HrSYWQ4A2oBBdoZTHnt7p7kD1YGyAzUYSOK0E0kNPU 0aMDM4h+SX/GCV4i4dXwJYfZGxqhGh2QPIlUl4egm55w1bHghxnvgkuT7i0EJqlg yo0dl/erOYwE1DgueGbmnx/FI+EP0ZmxZEnpBRWwbfatE/nCjFRetSiLKVJvzHK3 /JsGX1dBnLDyNZIxMpyQf2nvoWTwP/fdJlAEK7h5xlkaUe+xKMUykmmlIbBoF83R eahuIKjAXnKNKEGnbzdToEOoJKH8DO00pX0Gk3/QVfThFF6U1/wpJPflDA0JK4Yw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehffduieffuefffeeuuedtiefhleeuvdeihfefuedvgfeu hffgffdthfefjedvieenucffohhmrghinhepihgvthhfrdhorhhgpdhirghnrgdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhho nhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 043CB3604F6; Tue, 23 Feb 2021 08:03:17 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com> In-Reply-To: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> Date: Wed, 24 Feb 2021 00:01:43 +1100 From: "Bron Gondwana" To: "Hannes Tschofenig" Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=133c9b7726514212bc7d4cc9b293ac4c Archived-At: Subject: [OAUTH-WG] JMAP's experience with proposing an Authentication model X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 13:03:21 -0000 --133c9b7726514212bc7d4cc9b293ac4c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable (bringing this back to just the OAuth list) On Tue, Feb 23, 2021, at 23:46, Hannes Tschofenig wrote: > I don=E2=80=99t know whether it is already too late for your document = (which is dated 2016) to consider the use of OAuth but Rifaat and I are = happy to put you on the spot in one of our future virtual office hours o= r virtual interim meetings.=20 It's never "too late" - we could add a "how to Authenticate JMAP using O= Auth" document easily enough. That specific document which I mentioned went through many revisions and= a split to eventually become RFC8620 and RFC8621. The core JMAP spec s= ays this about Authentication: 8.2 . Authentication S= cheme A number of HTTP authentication schemes have been standardised (see ). Servers should take care to assess the security characteristics of different schemes in relation to their needs when deciding what to implement. Use of the Basic authentication scheme is NOT RECOMMENDED. Services that choose to use it are strongly recommended to require generation of a unique "app password" via some external mechanism for each client they wish to connect. This allows connections from different devices to be differentiated by the server and access to be individually revoked. What it doesn't have is something like what existed in the first draft, = which allowed out-of-band authentication in many ways, and *probably did= require security review - but security review from people who wanted it= to succeed rather than from people who wanted it to go away because it = wasn't OAuth*. At the time, that didn't sound like something achievable= . We were told that any authentication proposal would have to get past = the OAuth working group, who would shoot it down or stagnate it for year= s. Maybe that was wrong, but it was the impression we got from multiple= people in multiple conversations, both in our working group and in the = hallway track. The original authentication protocol started with a username and a servi= ce, and got back a session token plus list of authentication methods tha= t were allowed, or even a "we already authenticated you out of band - go= right ahead". The methods included password or password plus second factor, but also a= llowed for things like "here's a URL, go sign in there and when you're f= inished your session will be valid" or "a popup has been shown in your e= xisting sessions on other clients, confirm this code and click OK". The important thing was that there was no requirement that there be any = web context built into the client - it could happily just sit there wait= ing for a push event down the push channel to tell it that the session h= ad been authorised, or poll to see if it was allowed access yet. The au= thentication could be entirely out of band after the initial handshake. It's a quite different model than OAuth2. It's probably closer to GNAP,= which is why I've been watching that with interest, though not with eno= ugh time to engage closely. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --133c9b7726514212bc7d4cc9b293ac4c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
(bringing this back to just the OAuth list)
=

On Tue, Feb 23, 2021, at 23:46, Hannes Tschofenig wrote:
=
=

I don=E2=80=99t= know whether it is already too late for your document (which is dated 2= 016) to consider the use of OAuth but Rifaat and I are happy to put you = on the spot in one of our future virtual office hours or virtual interim= meetings. 


It's never "too late" -= we could add a "how to Authenticate JMAP using OAuth" document easily e= nough.

That specific document which I mentioned went throu= gh many revisions and a split to eventually become RFC8620 and RFC8621.&= nbsp; The core JMAP spec says this about Authentication:

8.2.  Authentication Scheme<=
br>


   A number of HTTP authentication schemes have been standardised (see
   <ht=
tps://www.iana.org/assignments/http-authschemes/>).  Servers
   should take care to assess the security characteristics of different
   schemes in relation to their needs when deciding what to implement.

   Use of the Basic authentication scheme is NOT RECOMMENDED.  Services
   that choose to use it are strongly recommended to require generation
   of a unique "app password" via some external mechanism for each
   client they wish to connect.  This allows connections from different
   devices to be differentiated by the server and access to be
   individually revoked.

What it doesn't have is so= mething like what existed in the first draft, which allowed out-of-band = authentication in many ways, and probably did require security review= - but security review from people who wanted it to succeed rather than = from people who wanted it to go away because it wasn't OAuth.  = At the time, that didn't sound like something achievable.  We were = told that any authentication proposal would have to get past the OAuth w= orking group, who would shoot it down or stagnate it for years.  Ma= ybe that was wrong, but it was the impression we got from multiple peopl= e in multiple conversations, both in our working group and in the hallwa= y track.

The original authentication protocol started wit= h a username and a service, and got back a session token plus list of au= thentication methods that were allowed, or even a "we already authentica= ted you out of band - go right ahead".

The methods includ= ed password or password plus second factor, but also allowed for things = like "here's a URL, go sign in there and when you're finished your sessi= on will be valid" or "a popup has been shown in your existing sessions o= n other clients, confirm this code and click OK".

The imp= ortant thing was that there was no requirement that there be any web con= text built into the client - it could happily just sit there waiting for= a push event down the push channel to tell it that the session had been= authorised, or poll to see if it was allowed access yet.  The auth= entication could be entirely out of band after the initial handshake.

It's a quite different model than OAuth2.  It's probab= ly closer to GNAP, which is why I've been watching that with interest, t= hough not with enough time to engage closely.

Cheers,
=

Bron.

<= div id=3D"sig56629417">
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--133c9b7726514212bc7d4cc9b293ac4c-- From nobody Tue Feb 23 05:15:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9EB3A2B09 for ; Tue, 23 Feb 2021 05:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fzzV6pbOFdk for ; Tue, 23 Feb 2021 05:15:00 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7833A2BF7 for ; Tue, 23 Feb 2021 05:14:11 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id a7so16973556iok.12 for ; Tue, 23 Feb 2021 05:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rOYOAquEGeeHQxF1XaswC0OkeXF4A9MKDW0wtFMwBHg=; b=XmNqkrd0NI55G+UBhaYjOr+VwxEj0UIApQx23OT0H3ts6prglrNLg6puu45ovJzxq6 2aQ4s5s0wGWt+njS7lxXlvWoHiUYLD2nBiAgrl5YxNP5F8BtZ5RvYSaEYeJK+fV5dG5c KvqDBQrKg0Qh3zBKXHdYNeJ9saxcBNmRFlyRRIPXJiTCvugOrlgPuwh5zgg4gZjU6u6B fdgdXmjt03c/uc/gssQNeZYExK1t3e6WDx+zplOrhKoXjywbjPEwCVvKF3GjeRPrN9gB kKrS1VHB9eWIVOh0OV91kipHwZ5//1rPb7ARIwVwoBEjRUWLwkuh8BI2SaqVTfle2l5S 4HRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rOYOAquEGeeHQxF1XaswC0OkeXF4A9MKDW0wtFMwBHg=; b=ZdVJAIyIw17O5WE0Bj2pIlQ2CKsbMDYqqCzHuWcO+aTvgpyUxtm685ToikJsb5aolz M7eeyB8JMn+pKaLhCRx9QH06GtlOsESr0nuRV7m9HqD8qcneBt6ef1zziom5jxagZY47 xvPNgMpX1xoepme/mXeJeW9tZc6ALoiQJZqcW69X8QE6P1z207GuXkrLb2VqpD9GarEg wTjWNsFd/az2h7XYUP/h1UmMVPLEt0pEaAim0uIwn4BjFFOSkHeWcTSkxX2kIpcZablV r7i9aJcUNOZjhhlx3SIWBxL/rIwm1hXV4jb1D5DlsL+gVYBsMGtRJtydfrBVNuQlGsck a2ZA== X-Gm-Message-State: AOAM531UjS970I3hiHE3w9ginIZ1/JkIVw3fH6LMBweEEoP/FLurNDBh Xdu/HHg+GTOXUwhTtO64NhqFwFu6lCC4iFH2ZpGNyfhHXjwwOMM= X-Google-Smtp-Source: ABdhPJwQYF/NuTTfPZRX5JcDKxqiueA9zoAytNm7rqSCLNRTc3D24w1RSBJ2dcHyzw7o6SXaJZVxkN/5CDJEb7hXVpk= X-Received: by 2002:a02:3b01:: with SMTP id c1mr27786445jaa.109.1614086050364; Tue, 23 Feb 2021 05:14:10 -0800 (PST) MIME-Version: 1.0 References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com> In-Reply-To: <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com> From: Warren Parad Date: Tue, 23 Feb 2021 14:13:59 +0100 Message-ID: To: Bron Gondwana Cc: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ab5fcc05bc00b176" Archived-At: Subject: Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 13:15:03 -0000 --000000000000ab5fcc05bc00b176 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Bron, (caveat: I only skimmed the other conversation) I'm trying to figure out how best to digest your message. I feel like I'm missing context in your message, is there something about JMAP required authentication that you're asking to be considered in OAuth. Help me figure out what I'm missing. - Warren Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Tue, Feb 23, 2021 at 2:03 PM Bron Gondwana wrote: > (bringing this back to just the OAuth list) > > On Tue, Feb 23, 2021, at 23:46, Hannes Tschofenig wrote: > > I don=E2=80=99t know whether it is already too late for your document (wh= ich is > dated 2016) to consider the use of OAuth but Rifaat and I are happy to pu= t > you on the spot in one of our future virtual office hours or virtual > interim meetings. > > > It's never "too late" - we could add a "how to Authenticate JMAP using > OAuth" document easily enough. > > That specific document which I mentioned went through many revisions and = a > split to eventually become RFC8620 and RFC8621. The core JMAP spec says > this about Authentication: > > 8.2 . Authentication Sc= heme > > > A number of HTTP authentication schemes have been standardised (see > ). Servers > should take care to assess the security characteristics of different > schemes in relation to their needs when deciding what to implement. > > Use of the Basic authentication scheme is NOT RECOMMENDED. Services > that choose to use it are strongly recommended to require generation > of a unique "app password" via some external mechanism for each > client they wish to connect. This allows connections from different > devices to be differentiated by the server and access to be > individually revoked. > > > What it doesn't have is something like what existed in the first draft, > which allowed out-of-band authentication in many ways, and *probably did > require security review - but security review from people who wanted it t= o > succeed rather than from people who wanted it to go away because it wasn'= t > OAuth*. At the time, that didn't sound like something achievable. We > were told that any authentication proposal would have to get past the OAu= th > working group, who would shoot it down or stagnate it for years. Maybe > that was wrong, but it was the impression we got from multiple people in > multiple conversations, both in our working group and in the hallway trac= k. > > The original authentication protocol started with a username and a > service, and got back a session token plus list of authentication methods > that were allowed, or even a "we already authenticated you out of band - = go > right ahead". > > The methods included password or password plus second factor, but also > allowed for things like "here's a URL, go sign in there and when you're > finished your session will be valid" or "a popup has been shown in your > existing sessions on other clients, confirm this code and click OK". > > The important thing was that there was no requirement that there be any > web context built into the client - it could happily just sit there waiti= ng > for a push event down the push channel to tell it that the session had be= en > authorised, or poll to see if it was allowed access yet. The > authentication could be entirely out of band after the initial handshake. > > It's a quite different model than OAuth2. It's probably closer to GNAP, > which is why I've been watching that with interest, though not with enoug= h > time to engage closely. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ab5fcc05bc00b176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Bron,

(caveat: I only=C2=A0skimmed = the other conversation)

I'm trying to figure o= ut how best to digest your message. I feel like I'm missing context in = your message, is there something about JMAP required authentication that yo= u're asking to be considered in OAuth. Help me figure out what I'm = missing.

- Warren

Secure your user data with IAM auth= orization as a service. Implement=C2=A0Authress.


On Tue, Feb = 23, 2021 at 2:03 PM Bron Gondwana <brong@fastmailteam.com> wrote:
(bringing this back to just the OAuth list)

On Tue= , Feb 23, 2021, at 23:46, Hannes Tschofenig wrote:

I don=E2=80=99t know whether it is already too late for your docum= ent (which is dated 2016) to consider the use of OAuth but Rifaat and I are= happy to put you on the spot in one of our future virtual office hours or = virtual interim meetings.=C2=A0


It's never &= quot;too late" - we could add a "how to Authenticate JMAP using O= Auth" document easily enough.

That specific document which I= mentioned went through many revisions and a split to eventually become RFC= 8620 and RFC8621.=C2=A0 The core JMAP spec says this about Authentication:<= br>

8.2.  Aut=
hentication Scheme


   A number of HTTP authentication schemes have been standardised (see
   <https://www.iana.org/assignments/http-authschemes/>).  =
Servers
   should take care to assess the security characteristics of different
   schemes in relation to their needs when deciding what to implement.

   Use of the Basic authentication scheme is NOT RECOMMENDED.  Services
   that choose to use it are strongly recommended to require generation
   of a unique "app password" via some external mechanism for eac=
h
   client they wish to connect.  This allows connections from different
   devices to be differentiated by the server and access to be
   individually revoked.
What it doesn't have is someth= ing like what existed in the first draft, which allowed out-of-band authent= ication in many ways, and probably did require security review - but sec= urity review from people who wanted it to succeed rather than from people w= ho wanted it to go away because it wasn't OAuth.=C2=A0 At the time,= that didn't sound like something achievable.=C2=A0 We were told that a= ny authentication proposal would have to get past the OAuth working group, = who would shoot it down or stagnate it for years.=C2=A0 Maybe that was wron= g, but it was the impression we got from multiple people in multiple conver= sations, both in our working group and in the hallway track.

The = original authentication protocol started with a username and a service, and= got back a session token plus list of authentication methods that were all= owed, or even a "we already authenticated you out of band - go right a= head".

The methods included password or password plus secon= d factor, but also allowed for things like "here's a URL, go sign = in there and when you're finished your session will be valid" or &= quot;a popup has been shown in your existing sessions on other clients, con= firm this code and click OK".

The important thing was that t= here was no requirement that there be any web context built into the client= - it could happily just sit there waiting for a push event down the push c= hannel to tell it that the session had been authorised, or poll to see if i= t was allowed access yet.=C2=A0 The authentication could be entirely out of= band after the initial handshake.

It's a quite different mod= el than OAuth2.=C2=A0 It's probably closer to GNAP, which is why I'= ve been watching that with interest, though not with enough time to engage = closely.

Cheers,

Bron.

--
=C2=A0 Bron Gondwana, CEO, Fa= stmail Pty Ltd


_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ab5fcc05bc00b176-- From nobody Tue Feb 23 05:25:35 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689F03A2B14 for ; Tue, 23 Feb 2021 05:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HJ4TFUtF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mD+bRbYr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1gYyHdqmZwm for ; Tue, 23 Feb 2021 05:25:32 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4483A2B13 for ; Tue, 23 Feb 2021 05:25:32 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D4C4A5C01F0; Tue, 23 Feb 2021 08:25:30 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 08:25:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=Kwum 2IUwNIpMDhz/Dp3dFYp77Xp3ccEfRwLyr0U68dY=; b=HJ4TFUtFbtwCdckdwLSO pRqbqCfipqP4conaXkEYS2J8zW7Xo+2j3iHXszSuaTahOahNnJfT4uBmKkY/CKHH KguiIDQDvoWgK3OLVOm/YHNEIck6OcWhQNeojDKv6/nl/DUIGvW3QntnVKK7PiT9 IoRgJ1V+rXi6Ag19CP9DIFR5vcZq+qhjk6KVs9xW5jjldGPWnNAKH8u0aOSMauZd 2P+wpQvbCVuBZga4YzZXsspmwgxt7GI6QuLHOTV1KiCE3kEhVbYc2NkPughlCHpJ UmYePK5Iu5Xq2uz7h3E1KLw0i9XWEGMk34OKpPDJNW0lYQba85mZcLrrifOiKPAh 1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Kwum2I UwNIpMDhz/Dp3dFYp77Xp3ccEfRwLyr0U68dY=; b=mD+bRbYrNLHWZ+sQ/6kPY2 Y6el5EU8AXOgIBiH81N5LSmh3YMKLLY8WiRLU1/66xbNrREPxtT7P+dhiJAS0bQl OfPJleWlEy25VpraghLh9LN+2C7uZW+s5WLmFWtKTdDnZxX1nEqa5YFX3v6NU16X VKtmuX1P8rdxgdFmHJpFs78ZEEZFN94qld55dgctn1qvC7Nhcyf7drlsCvVJjATH bQn3PwG6nqKgFCd1xaPihyOsYLgV7CdwPg5iAprxubHZpJo2/WjujVGD/ygeTUHi yNrqEBIROjZJ+iKDRqOSTQS5OnYyNxcPAbMYpHskcUV57jfpFKAZNSBH2jQOYhhg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpedtheetgeefveetudffveetheffgfehhfdvveekuefhheeu teduhefggeeikeejteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F1D7F3604F6; Tue, 23 Feb 2021 08:25:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com> In-Reply-To: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com> Date: Wed, 24 Feb 2021 00:25:08 +1100 From: "Bron Gondwana" To: "Warren Parad" Cc: "Hannes Tschofenig" , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=494c9bee0ee0469597fc342e6a12b4de Archived-At: Subject: Re: [OAUTH-WG] =?utf-8?q?JMAP=27s_experience_with_proposing_an_Authe?= =?utf-8?q?ntication_model?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 13:25:33 -0000 --494c9bee0ee0469597fc342e6a12b4de Content-Type: text/plain On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote: > Hey Bron, > > (caveat: I only skimmed the other conversation) > > I'm trying to figure out how best to digest your message. I feel like I'm missing context in your message, is there something about JMAP required authentication that you're asking to be considered in OAuth. Help me figure out what I'm missing. We were told at the time "if you're doing an authentication protocol over HTTP, it's going have to go to OAuth group". -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --494c9bee0ee0469597fc342e6a12b4de Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
= Hey Bron,

(caveat: I only skimmed the = other conversation)

I'm trying to figure ou= t how best to digest your message. I feel like I'm missing context in yo= ur message, is there something about JMAP required authentication that y= ou're asking to be considered in OAuth. Help me figure out what I'm miss= ing.

<= /div>
We were told at the time "if you'= re doing an authentication protocol over HTTP, it's going have to go to = OAuth group".

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--494c9bee0ee0469597fc342e6a12b4de-- From nobody Tue Feb 23 05:35:52 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7AF3A2B12 for ; Tue, 23 Feb 2021 05:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJRi0UTtbs3w for ; Tue, 23 Feb 2021 05:35:49 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD0E3A2B0D for ; Tue, 23 Feb 2021 05:35:48 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id f6so17043893iop.11 for ; Tue, 23 Feb 2021 05:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vLOhGCZxiQFXKjC1sZodsiKtVM3+auA0EE4C75Di7gY=; b=KBncRSUIyxwOu9FjyB+6PAoLgdJFnIFSW2jz1pFH/esEa5W20rpitYxgIIp7A3ihAN jt5zzTdJ74RdrSCsETlRVExe962hpa3rkYtPJAjkOf33lR732UcLyb+yDggOVqHGVqFx qfHq3LuZDx/ciUGl02jCY+Y1wkJgh+15+djC4O5YQFI5xuXsMd9EEzpqKbu9cqOwstUG KDTASBTkoWbF7PCmp6TdbIiQOlqPJG+RkYCytoPlTLoCn6zFeGvX258tvlIznT9mS4+5 5RNICvzRxm2NIRq11RQjX63aszsMCH02u5JWjNONHv9Ji4BNZ6DSTL2etRFjff8UdKj1 SeKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vLOhGCZxiQFXKjC1sZodsiKtVM3+auA0EE4C75Di7gY=; b=l2ImOWh4RizTGMsDA8nLmvJ2lc/xnnZKzKQCDDNYrSlOcv53wF0DUwXbRXPnh0/tzi q8hD/dRbh6Nqi2Fj/Ew/rB/wmfw5uTQ8gvq+zVaYDSdE4GGchap4MDNdEqlUPyfM8FcT NBYNpxxM3hY0MbR0Bm94YcFIY6CHKGWWuR03y6RfuFFlfMllG9q7zMTrjhzVRaTKcx7P kYZT1bXIUpbWKFfk4nsDTem99rbEw1kUldVHPWE4uF1tMIuh5KAYEiJXSyfatRFDZOhZ I9sk30Q+VHj/4cQ1lggPiet61IY76uVnNJpJb8WGpfz7T9Bejxmb/I1T+IM3GMaYE+Gb dokA== X-Gm-Message-State: AOAM533YsHTxUQD/MR9nu4cO8fdqKssgYmZUdOgZfWLNCa8OUlVQPOMD UVHna3zzcioygiDXmsrklbxwgVrusiC51doC3P6m X-Google-Smtp-Source: ABdhPJxFNhRdhUyf5cA8lo0yPvdHyyp5ZY/IjbJsDL5vru9nJ0GlpAaBgY/iW3wEPnLqUx0GsyKqS5FOql9JaJV2XOY= X-Received: by 2002:a5d:8249:: with SMTP id n9mr20071787ioo.31.1614087346191; Tue, 23 Feb 2021 05:35:46 -0800 (PST) MIME-Version: 1.0 References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com> <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com> In-Reply-To: <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com> From: Warren Parad Date: Tue, 23 Feb 2021 14:35:35 +0100 Message-ID: To: Bron Gondwana Cc: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e818de05bc00fe92" Archived-At: Subject: Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 13:35:51 -0000 --000000000000e818de05bc00fe92 Content-Type: text/plain; charset="UTF-8" I admit I haven't been present that long in this group, however it might help to start at the beginning. So far I see rfc8620 already exists, is there a draft or something else you want to discuss? Are you hoping to introduce a new authentication protocol? Any additional information would be appreciated. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana wrote: > On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote: > > Hey Bron, > > (caveat: I only skimmed the other conversation) > > I'm trying to figure out how best to digest your message. I feel like I'm > missing context in your message, is there something about JMAP required > authentication that you're asking to be considered in OAuth. Help me figure > out what I'm missing. > > > We were told at the time "if you're doing an authentication protocol over > HTTP, it's going have to go to OAuth group". > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > --000000000000e818de05bc00fe92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I admit I haven't been present that=C2=A0long in = this group, however it=C2=A0might help to start at the beginning. So far I = see rfc8620=C2=A0alread= y exists, is there a draft or something else you want to discuss?

Are you hoping to introduce a new authentication protocol?<= /div>

Any additional information would be appreciated.

 
\n \n\n\n\n\n\n = \n \n \n
\n When it's time, join the Webex meeting here.\n \n
\n \n \n \n \n \= n
 
\n \n \n \n \n
Join meeting
\n
\n \n \n \n \n = \n \n \n \= n \n \n \n \n \n \n \n \n \n
 
\n More ways to join:\n
 
\n Join from the meeting link\n
\n https://ietf.= webex.com/ietf/j.php?MTID=3Dm827c194bdcaa0077de44241f8001ce9b\n =
 
\n Join by meeting number\n \n
\n Meeting number (access code): 185 067 2252\n <= /td>\n
\n
Meeting password:nCgm6qTjH45
\n\n \n\n&nbs= p;
Tap to join from a mobile device (attendees only) &nbs= p;
+1-650= -479-3208,,1850672252## Call-in toll number (US/Canada) 
Join by phone  
1-650-479-3208 Call-in toll number (US/Canada) &= nbsp;
Global = call-in numbers 


\n\n
 
\n\n= Join from a video system or application
Dial 1850672252@ietf.webex= .com 
You can also dial 173.243.2.68 and enter your meeting number.  = ;
 
\n\n
 
<= /table>\n\n
Join using Microsoft Lync o= r Microsoft Skype for Business
Dial 1850672252.ietf@lync.webex.com
 
\n \n\n \n \n \n \n \n \n
 = ;
Need help? Go to https://help.webex.com\n
 
\n

Warren Parad

Founder, CTO

Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a servi= ce. Implement=C2=A0Authress.


On Tue, Feb 23, 2021 at 2:25 PM Br= on Gondwana <brong@fastmailtea= m.com> wrote:
On Wed, Feb 24, 2021, at = 00:13, Warren Parad wrote:
Hey Bron,

=
(caveat: I only=C2=A0skimmed the other conversation)

I'm trying to figure out how best to digest your mess= age. I feel like I'm missing context in your message, is there somethin= g about JMAP required authentication that you're asking to be considere= d in OAuth. Help me figure out what I'm missing.

We were told at the time "if you're doing an authentication= protocol over HTTP, it's going have to go to OAuth group".

--
=C2=A0 Bron Gondwana, CEO, Fas= tmail Pty Ltd


--000000000000e818de05bc00fe92-- From nobody Tue Feb 23 06:29:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D63A2BE2; Tue, 23 Feb 2021 06:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6FlukEs7vJN; Tue, 23 Feb 2021 06:29:47 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EC03A2B26; Tue, 23 Feb 2021 06:29:46 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 11NEThZY009168; Tue, 23 Feb 2021 09:29:43 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 11NEThZY009168 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1614090583; bh=JAQ2RKvBrdbjRhS4VqVSh17XkbTcM9qLmIpRP7iryk8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=XxxNGQ3VRgAjNWfPqsXJF44OfrSJORRLeXcpWD9yI5HG3E0NsYrCkVxduDiiE+3qG sUNg0qe+Dv/6p9L41jcfWAxdcN2+aQqqY3oOo6XeeFnY+geXXBYgvSLkUOfE3M9C8Q HPkWDb1+4Gp4uP2NM2+G5QTUR0ZJ7TIrYqxdzzM8= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 11NETgl0007819; Tue, 23 Feb 2021 09:29:42 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Feb 2021 09:29:41 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 23 Feb 2021 09:29:41 -0500 From: Roman Danyliw To: Bron Gondwana , Rifaat Shekh-Yusef CC: "ietf@ietf.org" , "oauth@ietf.org" Thread-Topic: Diversity and Inclusiveness in the IETF Thread-Index: AQHXCXgRHPZGlaGJs0aOOLS3WUQRDqpldw8AgABv5gCAAA4ugIAADfGAgAABogD//8HTEA== Date: Tue, 23 Feb 2021 14:29:40 +0000 Message-ID: References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com> In-Reply-To: <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.228] Content-Type: multipart/alternative; boundary="_000_c21477c8f68047cabac7aeae60a688f2certorg_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 14:29:49 -0000 --_000_c21477c8f68047cabac7aeae60a688f2certorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! From: ietf On Behalf Of Bron Gondwana Sent: Tuesday, February 23, 2021 7:47 AM To: Rifaat Shekh-Yusef Cc: ietf@ietf.org; oauth@ietf.org Subject: Re: Diversity and Inclusiveness in the IETF On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote: So you have never reached out to us to try to bring any work to the WG, and= based on attending one meeting and hearing from a few people, you formed a= strong opinion and declared that "nothing would get done"? that seems odd. Based on a few meetings, and having heard from many people. For your information, last year we published 4 RFCs, and we already have 3 = documents with the IESG and more to come. That's good to hear. [Roman] In addition to regular cadence of proposed standard publications no= ted above, I would additionally note that all of these documents came with = a model behavior of multiple implementations by WGLC - typically 3+. The W= G has not only managed to steadily complete its work items in the IETF but = also interest an implementor community to ensure this work is used. Regards, Roman --_000_c21477c8f68047cabac7aeae60a688f2certorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

From: ietf <ietf-bounces@ietf.org> O= n Behalf Of Bron Gondwana
Sent: Tuesday, February 23, 2021 7:47 AM
To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Cc: ietf@ietf.org; oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

 

On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote:

So you have never reached out to us to try to b= ring any work to the WG, and based on attending one meeting and hearin= g from a few people, you formed a strong opinion and declared that "no= thing would get done"? that seems odd.

 

Based on a few meetings, and having heard from many people.=

 

For your information, last year we published 4 RFCs,= and we already have 3 documents with the IESG and more to come.=

 

That's good to hear.

 

[Roman] In addition to regular cadence of proposed s= tandard publications noted above, I would additionally note that all of the= se documents came with a model behavior of multiple implementations by WGLC= – typically 3+.  The WG has not only managed to steadily complete its work items in the IETF but also interest = an implementor community to ensure this work is used.

 

Regards,

Roman

 

--_000_c21477c8f68047cabac7aeae60a688f2certorg_-- From nobody Tue Feb 23 07:10:03 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF53A2C15 for ; Tue, 23 Feb 2021 07:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggT0NyMnRChI for ; Tue, 23 Feb 2021 07:09:52 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B3B3A2C43 for ; Tue, 23 Feb 2021 07:09:42 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id g1so57462662ljj.13 for ; Tue, 23 Feb 2021 07:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1k8bsGfjrgHcr5Sf0kPBbMRHQYnkLR+IBpg5LBELqXk=; b=BAUrMWn3sbenz4tTrhiTuUng9ris8vnneM5oC/ZOz4XdJqXUQXEA/WKZprN5FRrI/G 7lVOr0dTGKyP7gh0hGgV6ZTNZFPmIVvdnE2SHlFpDkjB4xIEy9IssXShw8pEv4NKRK4T GA50QLNx2nVzbwSgIXr75DP4ZVi0snR61yK1yZJGAU5LThR6ETsqskFunhwDoWgmFJcI zasVWGYyKOdV6y8vMJGjvXFJipw5L+TnEFrMEbCO6zaMCYRLdNPqBg0GfkyiodQUQF99 W/KCFdY5Yvsw3xiRWvT9TfmwwwLBSlys1yEMbAuecCjE8fAJZFbmZTbqhfOX99i3S7P1 T6ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1k8bsGfjrgHcr5Sf0kPBbMRHQYnkLR+IBpg5LBELqXk=; b=JnF1unWKaNEGwws2ObhhgCVZRH7qGYmF+4LuGmiiGJym4G5JDFMpEJL9mj1KT0yOlU X+yXsmVFTAHaG2955tuftOo7VCrD6OXUmsXrb24OwfWVNyZJqx2brzEIfgTE0r4TDQrl 1uJ5Y5dUaqr/iPBCb/E03gYEiO913862de467uSuW6uf6ipHHj4ObQAKM49Qb66+kHUk +EJVeGzxHFLOJRu/sbhwLh6VR3B82562sFDduP1LuRqEr43UfzumC5su1PacfHUnOp+l jP44ztWeCR0Fiq5IKjpOR+si/YA4qWRttuELYubdyjM3o2XlUHXcVv2cEIekMX9yPRNn Z16g== X-Gm-Message-State: AOAM532ZmMD4fNplSQhL5hwPdkdWNldPghojWVMWdpBifjg80q1sDysg xXIVvqH23dQSU3RTQhR5TU0hXD9iZWDU8zRQ39dxpV3Z4YkTbGmUL7/ypTb6tzH9Na19xfg/8ez vbXtLuiT1PlK2E7Og4hU= X-Google-Smtp-Source: ABdhPJy7F2FxaDsAHxXVh6J75tzgE4kj4xexZc4zkPxfxwDTRaKmH1Vj+zgJ4zxmDAgrdd4iWMPyrQNt2p4MwyBJA54= X-Received: by 2002:a2e:8446:: with SMTP id u6mr15415306ljh.485.1614092980462; Tue, 23 Feb 2021 07:09:40 -0800 (PST) MIME-Version: 1.0 References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com> <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com> In-Reply-To: From: Brian Campbell Date: Tue, 23 Feb 2021 08:09:14 -0700 Message-ID: To: Warren Parad Cc: Bron Gondwana , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bc6a0f05bc024eac" Archived-At: Subject: Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 15:09:57 -0000 --000000000000bc6a0f05bc024eac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to add a little context - this is an offshoot of a discussion that's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/ On Tue, Feb 23, 2021 at 6:36 AM Warren Parad wrote: > I admit I haven't been present that long in this group, however it might > help to start at the beginning. So far I see rfc8620 > already exists, is there a draft or > something else you want to discuss? > > Are you hoping to introduce a new authentication protocol? > > Any additional information would be appreciated. > > Warren Parad > > Founder, CTO > Secure your user data with IAM authorization as a service. Implement > Authress . > > > On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana > wrote: > >> On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote: >> >> Hey Bron, >> >> (caveat: I only skimmed the other conversation) >> >> I'm trying to figure out how best to digest your message. I feel like I'= m >> missing context in your message, is there something about JMAP required >> authentication that you're asking to be considered in OAuth. Help me fig= ure >> out what I'm missing. >> >> >> We were told at the time "if you're doing an authentication protocol ove= r >> HTTP, it's going have to go to OAuth group". >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000bc6a0f05bc024eac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to add a little context - this is an offshoot of a di= scussion that's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnG= c/

On Tue, Feb 23, 2021 at 6:36 AM Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf= .org> wrote:
I admit I haven't been present that=C2=A0long= in this group, however it=C2=A0might help to start at the beginning. So fa= r I see r= fc8620=C2=A0already exists, is there a draft or something else you want= to discuss?

Are you hoping to introduce a new aut= hentication protocol?

Any additional information w= ould be appreciated.

<= colgroup>Secure your user data with IAM author= ization as a service. Implement=C2=A0Authress.


On Tue, Feb 23, = 2021 at 2:25 PM Bron Gondwana <brong@fastmailteam.com> wrote:
On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
Hey Bron,

(caveat: I only=C2=A0skimmed the other conversa= tion)

I'm trying to figure out how best to= digest your message. I feel like I'm missing context in your message, = is there something about JMAP required authentication that you're askin= g to be considered in OAuth. Help me figure out what I'm missing.

We were told at the time "if you're doing = an authentication protocol over HTTP, it's going have to go to OAuth gr= oup".

--
=C2=A0 Bron Gondwana, CEO, Fastm= ail Pty Ltd

=

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

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000bc6a0f05bc024eac-- From nobody Tue Feb 23 07:21:09 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1832E3A040F for ; Tue, 23 Feb 2021 07:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ2IkruhIHW4 for ; Tue, 23 Feb 2021 07:21:07 -0800 (PST) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B725A3A2C58 for ; Tue, 23 Feb 2021 07:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1614093648; bh=YRW0X+xaXromLOgvmOHIjHUY9ISZrNivjmgLhmV6Jl8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=GaZaOz7p78DcIedc811ZfiqPXEtrmtpgpi3nQDGM0tKHUHQYlEys7t9miegXGEXtP1UxTQtxDDKxsvuJK+vLuOLLUn+MhAsx8BeeP/UVnm/NVSNj20shrCp4faijuFTCbLBJzy16IXr1UMvwQmi3nH1bcWA1eP7v2pJBZEgsNh8xOIHSPi2P1mXhTCbc44jYSlV/NGFDI86HkEGrsI4yExKouoZ4FTT0jRyC6zfbd78B1YJ4OE+aYJ841o8OIt8w8e//PpObultXz9d+vlF+xkb6nBLjD/PI/5sWSqHZrUUTzKD3BBmn50JuicH7mEl1TshrftZgbXT7khUOdzYuMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1614093648; bh=rnuG5iG85oyGirOpjmbkRKs0QHPtgcvqYFHq/+oDQKS=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=H+9OuB/upwgG6XlJChuUZnNCGLDxX8B1j1zkYBU4c2lhu3YTlXKV7+HtEXlqCjSZrnCySC23Hu2j97jr/OWmAPi3RYVX8l8y9FkTqdvViExsNuWDIrHR21fmDOTraEWsNSOQTJvctl4HNQ7Xn5ahW+cXgZ/yxcxWXpFFC5WxKKcfQG4xbPrc+lYVYMzOIYgja5q1rllUkG4KNpDQjlb9w9doRMp7dlzKYe0hH1rCjzUsafh9AoezctkCjZdsbG+h82ZcM4QcanR2jqw6bRJM76+/YQcXWZSoFKrii6STuME4pqiZmGEM0qSYQvVXOhlrvl56idFSBe6kIkjjwTzmug== X-YMail-OSG: 2WRzi9YVM1lxGc.vTF5ylF3hONE4odmK8sVV9HXmLCkJfcK6SNC3clNGa1VGrRC URcdQ.oRmozFOi23GbyvFUHM0OkzAnImxe01WiruzXyfy.exk7Xxw6iT86oTp691y4ILQOqmV_3a GOURreP_0YdsBz5M6qcIXf3FgIjEzbSAQfCXgpB51l9K.keAqFk1Ug77CP4TyKsL6puPtxNyGGx9 dvY6UNwxmcTyJYkkI1I4weNvomGwarefrUdW_obYNKVtuRm7aXZL8ulWGNoBuw4ZyOsgc4z6t_ZC Wq_4cPcw7Z7U_BeAbRtWGx4me2bvL.OQAiQm33VKZEyWtSdGfLXaQcEg2WBZQ411D65t3WUnI3X8 Zn0XOtX1sXgkK3JgPHJbencY1aHW9vJplZf3OIrJ8RFEfeZSsL25XKBxWBNl7754thHET1l3Nd87 W6YInJvzW8zPDgEOdZ3TL5SpRZO7UiEn3YHXuGQEImxeruA0nkZzrpHEpOwnxbHlloEMnppbQOS. WlWlGcJ8jUqE1XUEQZW0Knl3.mLXIAes1skZKs4vzgpWjF_CcSDcyzNuFu6EDpcDQwiKJb113CC5 SoRmf_aHfKp_yjw8JyT5lbMmLm56HHlrZpugw1R1f2__5fbtnqjxWVW1SFWXNrBsyisp70M.Mgrg umhT18AH4a45T8kii5zzrxah3WPIX.xy4H_cTItrZkbQSnnQrhtAHtTnablbBeQHjE8k3OGTFn_z W2vmdA2HQWS2Dn6lHlPpHPha55mI6yE63zS1us.sFmJuBF_AzDw6oHLJj5GquM6_AfIqpO0Cd3cG Uq.lgqVXplAShANzaEI2mZz7ia6ep.RJoFBBeXQpBS5HaBYu_wFPKPXHW6sETje5_DFHOKcB95pI vUKY3G4uNy799HZZdX5z1It4LLUASz.1xBwGzxk1JZDwtWcwR_ltzcYBIFsx3jEJ9BstQfXZeeRc 0NTOUcchXC2xBu4j5VM9M.8QJo_05Ru8IX_m70tx.FOK2QQhq7ItZ0y2CURcUzNMSvskm8mkY1qv WwvBlaVjbdb.EDm0uc_Q.zEwJODCXKas4X0q4RC6LIASwcWwqSK3DrOE_6mFuV9khgBKWQghSB8P 4x4U5s7DBAJbMWDJnHkNLWDl8KfRJ.hSEn3q_J7jgJ_spzcBcoLoa1sE55wZL9fkpdTW9KHNCFsh kSCQu4c1aq_IuD5OWSA1nCu_u6x29USa0ZbBNHxSVitdo649jje81vT.izr4CIxvqDVcQFamnqvp _oZP.dw2JI_ZuYQueg7iYt8BNBdcIeuN2Y4o9xHQry3eYeM5KOEBXX3.9w5tddDDL9VQAv56DQnO 7chmz.d641y1gSpEFrfanH7PYMTQXhdZzRklS8iKcehNC8f6hGXOf9uYAs08CJpcGjbeIQSqAL1x v39bN3EB7dYTXnmUQXPfVX2XfuMVXWUPyJPW46_H_L89hS8Ybw7O8TJWoz8iLtQP7KitTdUWnXY2 DRSAKnv83Psy2DtSkOrfwAuV5GhiqKIjffaQSU3v87E5DFv54KVo9f76O8mFj6LAZI6Hif4jBQUn IiRnzXnyCS0ihPupRREGiUndTDLoEfJiUYquJ1OEZJdnZBIkGW82I69.9r.YE0EDYT8.5yqyvect IphP8Ec_IBa0.qgUtnPsDPmpKzcQ8yS5EYQ35z.WxxHV4Q6J5ak27bpczE8_efyZLUs_6M2zvi2m cmh.jBu9Ri8NLraXSVJxNhieByR9m24M.bBmlI3I02Ak3AWKc0vrfDRlAkbKXLD3rH3CIH2yplEm 1AMmqoPAbZQX7omhMxuHqatR9vY4bE091cEaYLgbR23zvdEQ5RewyqqMtdIGvRyBzUyu3u_3kLQ0 o.ZUTi2IMFN0gP.ELj1pamKeDAUrNC_hraxMyf81w6qGT9El50zw2LmXXvKIa3Fy1BoMCy6OnlWs n851ZZQq.tJ1aImqZ0e70SqTZcS2BqNWSPszCcl6d40y1yMCmSv5Zzu8hS7jxkbJIUVse3v1Z74t 5WKjPIcE0aQExIXzo69csILU.GYIHc2QVhTdcgOe5lkWrnQxdV5y8OS7FgFUHRuyMKNotSOcqk7L WoeYEHFLmnIoUQn8VMtmIVC0lVg3WSkcur3h0Opfb5s7Nwf8cWb0YlA7yVCSRPo1l5aCpdiNdx7D iqFv2R3Ld.3LhYpvH3R8cKfjmOKEfoP7gTubDR6alU1oVVf5EvZxNZ1ZYIlV3uKr7VVbwbWL5Uol lEEdbPRqR1ZQJuVHRTvl2JjxLt5K4J7YRIyTxBCjRfpnl6TvBFGedmNGVe3iQN__aRhDzPtoHOtp .zxh2D3pVYnP8qMoY.Ft7mA3vTcaFw.hhVWTOXLq8kCrOYoiNwuXxUOHg5FkUXtOvcmx97Bk7HWK W4T3fKXdgHAKiHg71VTL5_WHyxNscbNazVdOHa98FiZSMd_SiofuRj9MJt2lqcaTll4298o4Txa7 yvBrp6J0oKod0YaaXAraSR3g6SfjmckqLQYu.y9OXSp3hZc_6oeaOVsHeYYvFwkYRSTZET.ws_bX DNtJ6GSaCV4Ndsqmnc4CIJcSPGj1rLMdbG2p7nsjHJhYB_JTfjEXhVP5cV4fW5IVKrEiiPS62urP X8bgMxodZnaGkYu62Kbb9X6S8KIZQJMs19.yjWRK03iggU0zfh9dlAo1G0vMFEXvr3rDNyA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 23 Feb 2021 15:20:48 +0000 Received: by smtp424.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 62b5ae26315f8e5bb240206fd429aac5; Tue, 23 Feb 2021 15:20:43 +0000 (UTC) To: Neil Madden , Stoycho Sleptsov Cc: Vittorio Bertocci , oauth , Warren Parad References: From: George Fletcher Organization: AOL LLC Message-ID: <8b0b9840-1a80-d06f-316b-8a5273ad2124@aol.com> Date: Tue, 23 Feb 2021 10:20:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9418B008DA7290F9BFF16E3C" Content-Language: en-US X-Mailer: WebService/1.1.17712 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.9.1) Archived-At: Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 15:21:09 -0000 This is a multi-part message in MIME format. --------------9418B008DA7290F9BFF16E3C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that you want to ensure is "your" app then the most secure way is to look at "app attestation". This is however, way off topic for this thread :) On 2/14/21 9:28 AM, Neil Madden wrote: > Public clients are implicitly authenticated by their ownership of the registered redirect_uri. This why it’s important to use a redirect_uri for which ownership can be reasonably established, such as HTTPS endpoints with exact URI matching. > > There are more things that can go wrong with that (see the security BCP), but it can be made reasonably secure. > > — Neil > >> On 14 Feb 2021, at 13:48, Stoycho Sleptsov wrote: >> >>  >> I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS", >> with the objective to verify if they are valid. >> >> I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example). >> If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication. >> >> Or is it considered a bad practice to do that? >> >> Regards, >> Stoycho. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth --------------9418B008DA7290F9BFF16E3C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Unfortunately, in the mobile app world this isn't sufficient. On iOS using Universal Links will bind the https redirect_url to your app in a secure way but it doesn't work the same way on Android with App Links. There is still a problem with "mobile app impersonation". If you have an app that you want to ensure is "your" app then the most secure way is to look at "app attestation". This is however, way off topic for this thread :)

On 2/14/21 9:28 AM, Neil Madden wrote:
Public clients are implicitly authenticated by their ownership of the registered redirect_uri. This why it’s important to use a redirect_uri for which ownership can be reasonably established, such as HTTPS endpoints with exact URI matching. 

There are more things that can go wrong with that (see the security BCP), but it can be made reasonably secure. 

— Neil


On 14 Feb 2021, at 13:48, Stoycho Sleptsov <stoycho.sleptsov@gmail.com> wrote:


I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS",
with the objective to verify if they are valid.

I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example).
If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication.

Or is it considered a bad practice to do that?

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


    

    

  


--------------9418B008DA7290F9BFF16E3C--


From nobody Tue Feb 23 07:21:37 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904513A2C5C; Tue, 23 Feb 2021 07:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtoKGjNbKa4z; Tue, 23 Feb 2021 07:21:30 -0800 (PST)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB7B3A2C8F; Tue, 23 Feb 2021 07:21:29 -0800 (PST)
Received: by mail-ua1-x92f.google.com with SMTP id t15so5651551ual.6; Tue, 23 Feb 2021 07:21:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7pcvps3xOGwjcSGAtufYWPdsFnx3uuJpgOZqqZ+wsz0=; b=I9I9/Py5zQO2S5Sw22/UeNA8kgTHLYainOFGnEi/7rsI5BvbTqQQObmpusQZqaKttL 8ggnd/NDTZSvZ4ZYKnroWr2AYMTDsIRYA//YDnPGlBmvGINBCfc6YWGtf0lr4xoKV4WN 6BVVEobm1rIUvAkoIBgAGpKfO7Wu7hzeGAL+zpgCCyfXyP2py9Ei6Hj2ecXMv+CslQRH IAxOf2s27msLK9brGarQLXpAZHU0n9/GJZrEH5K1fNpzEogJ/JQ9l3KjgR4iWp3qkIuH xS4s8ZrBVSK+rO6mawSXQszJ2ponk2AivG4fkGv2C9dYTBWDBaaClPeRXPTOmkhRDo02 UTXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7pcvps3xOGwjcSGAtufYWPdsFnx3uuJpgOZqqZ+wsz0=; b=kTo5QbISQdQn/lYDrzDTCC6y/jH3hRZ0XM84WYdjhaFsAad5e2V3mV4AwuG3cAikUQ zC7U6BhzJCDpl8wdo42m++Ke5XC39QP30hT50dsNydZiBHHUYaM844mUDW8Vd95zHQAn 2QlM08gtFoR/F8MpQXuOlse1p2NHJe3ey3JCl/yEsozX5PhOFH1ZL4kv5sgdDa0AplYT a1GPh/6ovYL8k/pnl2L3rKZR7dYTDDm5Ts6vgGZp8EUo02VbuQtopNV6lYSV79lFakzv Q7AWPpGJp8sZ/nDZMpDOFyjj0JFBEeQH32awtiPdRrL+bB+605lUe/teKQPR5wv17O+S aXsA==
X-Gm-Message-State: AOAM530zdQkomZakUO47UXZwbtbJwPbSpCXkN4qcpGCnvfZGnzXm+o2i v+sOnwYtEzP9C2uiGqd4ZIc2TX7QhxZEXaeYzt1ATH/F
X-Google-Smtp-Source: ABdhPJzGhPYTx9/v+D3i/gLyPbAfgDJvkTQv+wkeRWYPwatYBvrZ2Ubxukfv4wnwGl4d0u7x+RzUhE+ZkD6Cv/rZe6w=
X-Received: by 2002:ab0:5963:: with SMTP id o32mr17685992uad.11.1614093687285;  Tue, 23 Feb 2021 07:21:27 -0800 (PST)
MIME-Version: 1.0
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com> 
In-Reply-To: 
From: Kathleen Moriarty 
Date: Tue, 23 Feb 2021 10:20:51 -0500
Message-ID: 
To: Roman Danyliw 
Cc: Bron Gondwana , Rifaat Shekh-Yusef ,  "ietf@ietf.org" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000dd6bbd05bc02780e"
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 15:21:33 -0000

--000000000000dd6bbd05bc02780e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 23, 2021 at 9:30 AM Roman Danyliw  wrote:

> Hi!
>
>
>
> *From:* ietf  *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 7:47 AM
> *To:* Rifaat Shekh-Yusef 
> *Cc:* ietf@ietf.org; oauth@ietf.org
> *Subject:* Re: Diversity and Inclusiveness in the IETF
>
>
>
> On Tue, Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote:
>
> So you have never reached out to us to try to bring any work to the WG,
> and based on attending one meeting and hearing from a few people, you
> formed a strong opinion and declared that "nothing would get done"? that
> seems odd.
>
>
>
> Based on a few meetings, and having heard from many people.
>
>
>
> For your information, last year we published 4 RFCs, and we already have =
3
> documents with the IESG and more to come.
>
>
>
> That's good to hear.
>
>
>
> [Roman] In addition to regular cadence of proposed standard publications
> noted above, I would additionally note that all of these documents came
> with a model behavior of multiple implementations by WGLC =E2=80=93 typic=
ally 3+.
> The WG has not only managed to steadily complete its work items in the IE=
TF
> but also interest an implementor community to ensure this work is used.
>

And way back when I was AD, OAuth was by far the most productive working
group I managed.  They put out what felt like about 3 documents a meeting
for full publication.  I was the AD for 3 years, ending in 2017 when EKR
became an AD.

There was a bit of management as a result of the number of experts and
varying use cases for their environments, but even with that, OAuth was
very productive.  Since your document was 2016, I was likely the AD.  Yes,
the meetings had challenges at times, but we worked through it and things
got done.

Best regards,
Kathleen


>
> Regards,
>
> Roman
>
>
>


--=20

Best regards,
Kathleen

--000000000000dd6bbd05bc02780e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Feb 23, 2021 at 9:30 AM Roman=
 Danyliw <rdd@cert.org> wrote:











Hi!


=C2=A0








From: ietf <ietf-bounces@ietf.org> On Behalf Of =

Bron Gondwana

Sent: Tuesday, February 23, 2021 7:47 AM

To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>

Cc: ietf@ietf.org=
; oauth@ietf.org

Subject: Re: Diversity and Inclusiveness in the IETF





=C2=A0




On Tue,=
 Feb 23, 2021, at 23:40, Rifaat Shekh-Yusef wrote:














So you have never reached out to us to=C2=A0try to b=
ring any work to the WG, and based on attending=C2=A0one meeting and hearin=
g from a few people, you formed a strong opinion and declared that "no=
thing would get done"? that seems odd.














=
=C2=A0






Based o=
n a few meetings, and having heard from many people.





=
=C2=A0














For your information, last year we published 4 RFCs,=
 and we already have 3 documents with the IESG and more to come.<=
/u>














=
=C2=A0






That=
9;s good to hear.


=C2=A0


[Roman] In addition to regular cadence of proposed s=
tandard publications noted above, I would additionally note that all of the=
se documents came with a model behavior of multiple implementations by WGLC=
 =E2=80=93 typically 3+.=C2=A0 The WG has not only
 managed to steadily complete its work items in the IETF but also interest =
an implementor community to ensure this work is used.
=









-- 

Best regards,
Kathleen


--000000000000dd6bbd05bc02780e--


From nobody Tue Feb 23 12:03:00 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A173A0853 for ; Tue, 23 Feb 2021 12:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level: 
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TTBHgMy6VU7 for ; Tue, 23 Feb 2021 12:02:58 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F0C3A0C4C for ; Tue, 23 Feb 2021 12:02:10 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id o63so13086636pgo.6 for ; Tue, 23 Feb 2021 12:02:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EccP5EEh5wIkUQQQXVJdZqZGCS1jDZcm36MzwL9fDVw=; b=LdPrR7v69LaiDCzcifJbc9HEX444vh6FNR0xFAICU0LX5X2JjetS4Zz6jjwPhrc3Js OY9ebQ+d1+5uBfQO6pXFvn8Oz0ln21KpURBslt/ooVxdc+ybKae/6D8yBkCC96KbaxHN NVjZsQI1oFGMqT4Z7EjkHmfcZ4Wih6r71nMbLu/Lc0WMtK8iEoTHpBytJHu2iu8HYcb2 1RKKvZN4IynCifymlrdUFcnQWr8qUCGI54FF2GW8ysZelsRgNrdWOojcX82/6ooMQJTP 2jlMTdzAsoKMr1I6MCMF+AdBC9dOuCqLpnyrFoZSA+LNw8dagWROZQdfVHNQ+jkaeMnv 2Vng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EccP5EEh5wIkUQQQXVJdZqZGCS1jDZcm36MzwL9fDVw=; b=tRxwdLok7QhDnxbjg8tOwMa+zgw8LRZ6TKCTeYkTvtsirjtOjWfDpb/Tfv33oStbSG 5+/9seZB0KPoFiOW9CF/GAMcCdeLUCod7TZ4AYxlrtf5edRDJwnWjLIfLVuMCW8lwM4A dNiJWFwlVtlrritenMPwBoMNqhPoXxR5PmvtDjcudbmImZrb0ffxUMUs66NfSijBZL5X jjZauANh+j6046Px8MAEgu6OGRohg1RiSmyUAmST6RlFbymbG1YsBXaixcQu5vy86PaU V15Mmsr2l68olIHTa4RiyJHHuUUJm09Y+uFiyYwTsOVPxkBpgZsdgqVjd2DwMN5rqXGC mv9A==
X-Gm-Message-State: AOAM53108LJrRsLr8l7VhZbxS2ZJCXhaPfmq88nMewYKdyJk010QmykA y25YF5KkSVXimWqBzyfSNbLAEg==
X-Google-Smtp-Source: ABdhPJxd47JSMmdJoMn9pNphNAUjhhEzZ87DTApi9zi5facWtzyNjXTA3fDdrHcnzlzMtD4bmnQC7w==
X-Received: by 2002:a63:1825:: with SMTP id y37mr2062460pgl.42.1614110530177;  Tue, 23 Feb 2021 12:02:10 -0800 (PST)
Received: from node-1w7jr9qrfoxx8mseaifwz8ydd.ipv6.telus.net (node-1w7jr9qrfoxx8mseaifwz8ydd.ipv6.telus.net. [2001:569:7a71:1d00:48e1:f746:b070:5301]) by smtp.gmail.com with ESMTPSA id s18sm4288481pjr.14.2021.02.23.12.02.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 12:02:09 -0800 (PST)
From: Phil Hunt 
Message-Id: <24452E46-B957-4C35-BAEC-BC2D75B25923@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_307C0662-66E7-413E-A319-E78876699F9C"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Tue, 23 Feb 2021 12:02:08 -0800
In-Reply-To: 
Cc: Warren Parad , Bron Gondwana , "oauth@ietf.org" 
To: Brian Campbell 
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com>  <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com>  
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: 
Subject: Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 20:03:00 -0000

--Apple-Mail=_307C0662-66E7-413E-A319-E78876699F9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Bron,

I notice that JMAP is a protocol built on top of HTTP.  Like JMAP, when =
the SCIM WG was developing SCIM (RFC7643/7644) we had a lot of =
participants wanting to define authentication within SCIM too.  This in =
part came from the popular use of the LDAP =E2=80=9Cbind=E2=80=9D =
feature as a general purpose authentication database.  =E2=80=9CBind=E2=80=
=9D was never intended to be used this way, it just happened.  In the =
HTTP world, we recognized we were building on top of HTTP with an =
already diverse set of authentication schemes.

The trade-off is that you ignore all of the schemes built on top of HTTP =
(RFC7230) *and* you loose any natural agility in the spec as HTTP and =
authentication techniques evolve over time.  One limitation of IETF =
specs is that =E2=80=9Cversioning=E2=80=9D specs is difficult. They are =
intended to reflect long-term stabilized practices after a period of =
agile-like ID spec iteration. =20

The downside to saying =E2=80=9Cany HTTP mechanism=E2=80=9D is usable is =
that it does create point-in-time interop challenges as parties have to =
agree on authentication schemes. However, this is less of an =
implementation problem as one might think. Most platforms (e.g. Spring, =
Quarkus) offer all of the popular mechanisms. The challenge therefor =
becomes one of deployment and configuration rather than implementation.

As an example, as OAuth evolves, the libraries pick up the changes and =
dependent systems like SCIM pick it up transparently. This speaks to =
some of the =E2=80=9Cexisting applications=E2=80=9D concerns that Hannes =
mentioned.

So yes, you could narrowly define authentication in JMAP but it=E2=80=99s =
lifespan will become severely limited as authentication requirements and =
risks evolve over time.  Case in point. the OAuth WG has had to maintain =
a sustained evolution of specs and best practices. Why bog JMAP down =
with such a huge domain as authentication?

Hope this helps.

Phil Hunt
@independentid
phil.hunt@independentid.com




> On Feb 23, 2021, at 7:09 AM, Brian Campbell =
 wrote:
>=20
> Just to add a little context - this is an offshoot of a discussion =
that's happening over on the ietf@ list: =
https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/ =

> On Tue, Feb 23, 2021 at 6:36 AM Warren Parad =
> wrote:
> I admit I haven't been present that long in this group, however it =
might help to start at the beginning. So far I see rfc8620 =
 already exists, is there a draft =
or something else you want to discuss?
>=20
> Are you hoping to introduce a new authentication protocol?
>=20
> Any additional information would be appreciated.
>=20
>=20
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement =
Authress .
>=20
>=20
> On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana > wrote:
> On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
>> Hey Bron,
>>=20
>> (caveat: I only skimmed the other conversation)
>>=20
>> I'm trying to figure out how best to digest your message. I feel like =
I'm missing context in your message, is there something about JMAP =
required authentication that you're asking to be considered in OAuth. =
Help me figure out what I'm missing.
>=20
> We were told at the time "if you're doing an authentication protocol =
over HTTP, it's going have to go to OAuth group".
>=20
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com 
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_307C0662-66E7-413E-A319-E78876699F9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Bron,

I notice that JMAP is a protocol built on top of HTTP. =
 Like JMAP, when the SCIM WG was developing SCIM (RFC7643/7644) we =
had a lot of participants wanting to define authentication within SCIM =
too.  This in part came from the popular use of the LDAP =E2=80=9Cbin=
d=E2=80=9D feature as a general purpose authentication database. =
 =E2=80=9CBind=E2=80=9D was never intended to be used this way, it =
just happened.  In the HTTP world, we recognized we were building =
on top of HTTP with an already diverse set of authentication =
schemes.

The =
trade-off is that you ignore all of the schemes built on top of HTTP =
(RFC7230) *and* you loose any natural agility in the spec as HTTP and =
authentication techniques evolve over time.  One limitation of IETF =
specs is that =E2=80=9Cversioning=E2=80=9D specs is difficult. They are =
intended to reflect long-term stabilized practices after a period of =
agile-like ID spec iteration.  

The downside to saying =E2=80=9Cany =
HTTP mechanism=E2=80=9D is usable is that it does create point-in-time =
interop challenges as parties have to agree on authentication schemes. =
However, this is less of an implementation problem as one might think. =
Most platforms (e.g. Spring, Quarkus) offer all of the popular =
mechanisms. The challenge therefor becomes one of deployment and =
configuration rather than implementation.

As an example, as OAuth evolves, the =
libraries pick up the changes and dependent systems like SCIM pick it up =
transparently. This speaks to some of the =E2=80=9Cexisting =
applications=E2=80=9D concerns that Hannes mentioned.

So yes, you could =
narrowly define authentication in JMAP but it=E2=80=99s lifespan will =
become severely limited as authentication requirements and risks evolve =
over time.  Case in point. the OAuth WG has had to maintain a =
sustained evolution of specs and best practices. Why bog JMAP down with =
such a huge domain as authentication?

Hope this helps.








On Feb 23, 2021, at 7:09 AM, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> =
wrote:

Just to add a little context - this is an =
offshoot of a discussion that's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUNOr7=
Pt-YnGc/

On Tue, Feb 23, 2021 at 6:36 AM Warren =
Parad <wparad=3D40rhosys.ch@dmarc.ietf.org> =
wrote:
I admit I haven't been present that long in this group, =
however it might help to start at the beginning. So far I see rfc8620 already exists, is there a draft or =
something else you want to discuss?

Are you hoping to introduce a new =
authentication protocol?

Any additional information would be appreciated.

Warren Parad
Founder, CTO




Warren Parad
Founder, =
CTO
Secure your user data with IAM =
authorization as a service. Implement Authress.


On Tue, Feb 23, 2021 at 2:25 PM Bron =
Gondwana <brong@fastmailteam.com> wrote:
On Wed, Feb 24, 2021, at 00:13, =
Warren Parad wrote:
Hey Bron,

(caveat: I only skimmed the other =
conversation)

I'm trying to figure out how best to =
digest your message. I feel like I'm missing context in your message, is =
there something about JMAP required authentication that you're asking to =
be considered in OAuth. Help me figure out what I'm missing.

We were told at the time "if you're doing an authentication =
protocol over HTTP, it's going have to go to OAuth group".

--
  Bron Gondwana, CEO, Fastmail Pty =
Ltd
  brong@fastmailteam.com



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





CONFIDENTIALITY NOTICE: This email may contain confidential =
and privileged material for the sole use of the intended recipient(s). =
Any review, use, distribution or disclosure by others is strictly =
prohibited.  If you have received this communication in error, =
please notify the sender immediately by e-mail and delete the message =
and any file attachments from your computer. Thank =
you._______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_307C0662-66E7-413E-A319-E78876699F9C--


From nobody Tue Feb 23 13:55:06 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B89D3A0CF9 for ; Tue, 23 Feb 2021 13:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=dbdb61pc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oV/JjqHb
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU6LlKf3LgEn for ; Tue, 23 Feb 2021 13:55:01 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D234C3A0CF1 for ; Tue, 23 Feb 2021 13:55:01 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 93258528; Tue, 23 Feb 2021 16:55:00 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 16:55:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=3MrP 0s7RGYC3N3MvhUL635VHvmGLzc5wMNwYQvP11Zs=; b=dbdb61pcbSgEC2sFypOl zxY2bfIGCfknr6iQB6L2L5R54dMxtoeOfpDsJbzL4S4hW6JBtdJLo5horoqJyA3E CLiHM9Y8MNYSphuoFy48UThc9mhR5XKgIxrHLmYBW1xQ9RgT2K0ccsuQJBCP8rgK tqUSl6VnlOoIUxSSs9XYf3flQp1Wogkp15EXITCopoFr9+smELO+Dx+guSrFDG8q bNcpx8uT847ZEjwzjw5ntZGCWFMcJiAPugvdrlnsBIVm4848e2Q9+gj7vV7ulm1M GhtQwvXyTXIAfIiq6he6ryYPlJf8LKuN9or96JWgZ1vxvvJAUvAU3hQbbfKbcizI Yw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3MrP0s 7RGYC3N3MvhUL635VHvmGLzc5wMNwYQvP11Zs=; b=oV/JjqHb2L7R+GbhRzjHWy Lt4o2HpCrR/2pEXIAw2O6PshvDgcYrGIphQCH3+6vPF/rZDabUPZSf7svRv0BSZ3 x2ArOCabAIbPMyDwWxq5txwbv9WP51hRXsjkhJvCtZHwDCuaW5nKwQadI0AEWTUN 82RTI9KC9iMlc+LYn2YzvRF3b7F9HRmh1lI7RFK670bPlE1E/SO93FpJE1Q5qyju tTvfmhnXas4pWuPGZOqpEXNKwpiOVKMtum4ZXiPEAaH/SJfLBxafmSEEBxh/BAcr UV/dnQfn5at3MX97hS62G390r1DhTtoNkMe+UZUsE4gFdTIh2iOHEUsGiKQtIN+g ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthfkmhhgffhomhgrihhnucdlfedtmdenucfjughrpefofgggkfgjfhff hffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuc eosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhn peekuefhffejgfffueeuueettdeguedtueelteetieelgfehhfdtiedufeduffehieenuc ffohhmrghinhephhhtthhprdhlihhkvgdphhhtthhprghnuggruhhthhgvnhhtihgtrght ihhonhhtvggthhhnihhquhgvshgvvhholhhvvghovhgvrhhtihhmvgdrohhnvgdpihgvth hfrdhorhhgpdgruhhthhhrvghsshdrihhonecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id F0176360512; Tue, 23 Feb 2021 16:54:58 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: <50a62bd2-5a1c-481a-b58b-3f90ec703f88@dogfood.fastmail.com>
In-Reply-To: <24452E46-B957-4C35-BAEC-BC2D75B25923@independentid.com>
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com>  <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com>   <24452E46-B957-4C35-BAEC-BC2D75B25923@independentid.com>
Date: Wed, 24 Feb 2021 08:54:36 +1100
From: "Bron Gondwana" 
To: "Phil Hunt" , "Brian Campbell" 
Cc: "Warren Parad" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=1e68cbf0b5d446da9f9eca03f27ba384
Archived-At: 
Subject: Re: [OAUTH-WG]  =?utf-8?q?JMAP=27s_experience_with_proposing_an_Authe?= =?utf-8?q?ntication_model?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 21:55:05 -0000

--1e68cbf0b5d446da9f9eca03f27ba384
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yeah - the discussion has wandered into the weeds (and I'm largely respo=
nsible for this) about whether the way JMAP was proposing doing Authenti=
cation was the right way, rather than the meta topic which started this =
which was "my impression on joining the IETF was that OAuth working grou=
p was toxic and unwelcoming to new work, and taking anything there was a=
 sure-fire way to make sure nothing got progressed".

And my experience of being a tourist in the OAuth face-to-face meetings =
was consistent with that impression.  There was an awfully large amount =
of talking and an awfully small amount of listening going on - with the =
IETF102 Thursday meeting being particularly bad (I had a clash for Tuesd=
ay's meeting, so I don't know how that one went).

Maybe it's a completely different place now - but one of two things must=
 be true:

a) the OAuth group is insular and unwelcoming; or
b) there's a false impression of the OAuth group that's been circulating=
 for years, at least within the applications area which is where I spend=
 most of my time.

Back on the specifics...

I do want to quote this: *"The challenge therefor becomes one of deploym=
ent and configuration rather than implementation."* because that's part =
of the impression that I got of OAuth. I come from a world where deploym=
ent and configuration are major hurdles, and in fact OAuth interoperabil=
ity is a major mess because it's such a flexible toolkit.  Just this wee=
k I've run into issues where Yahoo's SMTP "XOAUTH2" is behaving differen=
tly from Google's and we had delivery issues for authenticated sending.

If every client and every server needs to implement "*all the popular me=
chanisms*" then that's not such a big deal when you're shipping the clie=
nt code for your own server as part of a website, but it's a big deal if=
 you're trying to create a general client and don't want to have to hard=
-code the specific magic for each server provider.

So the reason to encode the authentication mechanism into JMAP was preci=
sely to reduce the number of possibilities.

Bron.

On Wed, Feb 24, 2021, at 07:02, Phil Hunt wrote:
> Bron,
>=20
> I notice that JMAP is a protocol built on top of HTTP.  Like JMAP, whe=
n the SCIM WG was developing SCIM (RFC7643/7644) we had a lot of partici=
pants wanting to define authentication within SCIM too.  This in part ca=
me from the popular use of the LDAP =E2=80=9Cbind=E2=80=9D feature as a =
general purpose authentication database.  =E2=80=9CBind=E2=80=9D was nev=
er intended to be used this way, it just happened.  In the HTTP world, w=
e recognized we were building on top of HTTP with an already diverse set=
 of authentication schemes.
>=20
> The trade-off is that you ignore all of the schemes built on top of HT=
TP (RFC7230) *and* you loose any natural agility in the spec as HTTP and=
 authentication techniques evolve over time.  One limitation of IETF spe=
cs is that =E2=80=9Cversioning=E2=80=9D specs is difficult. They are int=
ended to reflect long-term stabilized practices after a period of agile-=
like ID spec iteration. =20
>=20
> The downside to saying =E2=80=9Cany HTTP mechanism=E2=80=9D is usable =
is that it does create point-in-time interop challenges as parties have =
to agree on authentication schemes. However, this is less of an implemen=
tation problem as one might think. Most platforms (e.g. Spring, Quarkus)=
 offer all of the popular mechanisms. The challenge therefor becomes one=
 of deployment and configuration rather than implementation.
>=20
> As an example, as OAuth evolves, the libraries pick up the changes and=
 dependent systems like SCIM pick it up transparently. This speaks to so=
me of the =E2=80=9Cexisting applications=E2=80=9D concerns that Hannes m=
entioned.
>=20
> So yes, you could narrowly define authentication in JMAP but it=E2=80=99=
s lifespan will become severely limited as authentication requirements a=
nd risks evolve over time.  Case in point. the OAuth WG has had to maint=
ain a sustained evolution of specs and best practices. Why bog JMAP down=
 with such a huge domain as authentication?
>=20
> Hope this helps.
>=20
> Phil Hunt
> @independentid
> phil.hunt@independentid.com
>=20
>=20
>=20
>> On Feb 23, 2021, at 7:09 AM, Brian Campbell  wrote:
>>=20
>> Just to add a little context - this is an offshoot of a discussion th=
at's happening over on the ietf@ list: https://mailarchive.ietf.org/arch=
/msg/ietf/pTFOZjhuZfj45pnUNOr7Pt-YnGc/
>>=20
>> On Tue, Feb 23, 2021 at 6:36 AM Warren Parad  wrote:
>>> I admit I haven't been present that long in this group, however it m=
ight help to start at the beginning. So far I see rfc8620  already exists, is there a draft or something el=
se you want to discuss?
>>>=20
>>> Are you hoping to introduce a new authentication protocol?
>>>=20
>>> Any additional information would be appreciated.
>>>=20
>>>=20
>>> *Warren Parad*
>>> Founder, CTO
>>> Secure your user data with IAM authorization as a service. Implement=
 Authress .
>>>=20
>>>=20
>>> On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana  wrote:
>>>> __
>>>> On Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
>>>>> Hey Bron,
>>>>>=20
>>>>> (caveat: I only skimmed the other conversation)
>>>>>=20
>>>>> I'm trying to figure out how best to digest your message. I feel l=
ike I'm missing context in your message, is there something about JMAP r=
equired authentication that you're asking to be considered in OAuth. Hel=
p me figure out what I'm missing.
>>>>=20
>>>> We were told at the time "if you're doing an authentication protoco=
l over HTTP, it's going have to go to OAuth group".
>>>>=20
>>>> --
>>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>   brong@fastmailteam.com
>>>>=20
>>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and priv=
ileged material for the sole use of the intended recipient(s). Any revie=
w, use, distribution or disclosure by others is strictly prohibited.  If=
 you have received this communication in error, please notify the sender=
 immediately by e-mail and delete the message and any file attachments f=
rom your computer. Thank you.*__________________________________________=
_____
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--1e68cbf0b5d446da9f9eca03f27ba384
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable


Yeah - the discussion has wandered into the weeds (and I'm=
 largely responsible for this) about whether the way JMAP was proposing =
doing Authentication was the right way, rather than the meta topic which=
 started this which was "my impression on joining the IETF was that OAut=
h working group was toxic and unwelcoming to new work, and taking anythi=
ng there was a sure-fire way to make sure nothing got progressed".

And my experience of being a tourist in the OAuth face-to-face=
 meetings was consistent with that impression.  There was an awfull=
y large amount of talking and an awfully small amount of listening going=
 on - with the IETF102 Thursday meeting being particularly bad (I had a =
clash for Tuesday's meeting, so I don't know how that one went).

Maybe it's a completely different place now - but one of two thi=
ngs must be true:

<=
div style=3D"font-family:Arial;">a) the OAuth group is insular and unwel=
coming; or
b) there's a false=
 impression of the OAuth group that's been circulating for years, at lea=
st within the applications area which is where I spend most of my time.<=
br>

Back on the specifics...

I do want to quot=
e this: "The challenge therefor becomes one of deployment and configu=
ration rather than implementation." because that's part of the impre=
ssion that I got of OAuth. I come from a world where deployment and conf=
iguration are major hurdles, and in fact OAuth interoperability is a maj=
or mess because it's such a flexible toolkit.  Just this week I've =
run into issues where Yahoo's SMTP "XOAUTH2" is behaving differently fro=
m Google's and we had delivery issues for authenticated sending.

If every client and every server needs to implement "all the =
popular mechanisms" then that's not such a big deal when you're ship=
ping the client code for your own server as part of a website, but it's =
a big deal if you're trying to create a general client and don't want to=
 have to hard-code the specific magic for each server provider.

So the reason to encode the authentication mechanism into JMAP wa=
s precisely to reduce the number of possibilities.

Bron.

On Wed, Feb 24,=
 2021, at 07:02, Phil Hunt wrote:
Bron,

I notice that JMAP is=
 a protocol built on top of HTTP.  Like JMAP, when the SCIM WG was =
developing SCIM (RFC7643/7644) we had a lot of participants wanting to d=
efine authentication within SCIM too.  This in part came from the p=
opular use of the LDAP =E2=80=9Cbind=E2=80=9D feature as a general purpo=
se authentication database.  =E2=80=9CBind=E2=80=9D was never inten=
ded to be used this way, it just happened.  In the HTTP world, we r=
ecognized we were building on top of HTTP with an already diverse set of=
 authentication schemes.

The trade-off is that you ignore all of the schemes built on t=
op of HTTP (RFC7230) *and* you loose any natural agility in the spec as =
HTTP and authentication techniques evolve over time.  One limitatio=
n of IETF specs is that =E2=80=9Cversioning=E2=80=9D specs is difficult.=
 They are intended to reflect long-term stabilized practices after a per=
iod of agile-like ID spec iteration.  
=

The downside to saying =E2=80=9Cany HTTP me=
chanism=E2=80=9D is usable is that it does create point-in-time interop =
challenges as parties have to agree on authentication schemes. However, =
this is less of an implementation problem as one might think. Most platf=
orms (e.g. Spring, Quarkus) offer all of the popular mechanisms. The cha=
llenge therefor becomes one of deployment and configuration rather than =
implementation.

As an example, as OAuth evolves, the libraries pick up the changes and =
dependent systems like SCIM pick it up transparently. This speaks to som=
e of the =E2=80=9Cexisting applications=E2=80=9D concerns that Hannes me=
ntioned.

So yes=
, you could narrowly define authentication in JMAP but it=E2=80=99s life=
span will become severely limited as authentication requirements and ris=
ks evolve over time.  Case in point. the OAuth WG has had to mainta=
in a sustained evolution of specs and best practices. Why bog JMAP down =
with such a huge domain as authentication?
<=
br>
Hope this helps.

Phil Hunt

On Feb 23, 2021, at 7:09 AM, Brian Campbel=
l <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote=
:

Just to add a little context - this is an offshoot of a discussion t=
hat's happening over on the ietf@ list: https://mailarchive.ietf.org/arch/msg/ietf/pTFOZjhuZfj45pnUN=
Or7Pt-YnGc/

On Tue, Feb 23, 2021 at 6:36 AM W=
arren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org> wrote:=

I admit I ha=
ven't been present that long in this group, however it might h=
elp to start at the beginning. So far I see rfc8620 alr=
eady exists, is there a draft or something else you want to discuss?
=


Are you hoping to =
introduce a new authentication protocol?
Any additional information would be appreciate=
d.

Secure your user data with IAM authorization as a service=
. Implement Authress.

=


On Tue, Feb 23, 2021 at 2:25 PM Bron Gondwana <brong@fa=
stmailteam.com> wrote:

On=
 Wed, Feb 24, 2021, at 00:13, Warren Parad wrote:
Hey Bron,

=

(caveat: I only skimmed the other conversa=
tion)

I'm tryin=
g to figure out how best to digest your message. I feel like I'm missing=
 context in your message, is there something about JMAP required authent=
ication that you're asking to be considered in OAuth. Help me figure out=
 what I'm missing.

We were told at the time "if you're doing an authentication pro=
tocol over HTTP, it's going have to go to OAuth group".

--
  Bron Gondwana, CEO, Fastmail Pty Ltd


______________________________________=
_________
 OAuth mailing list

CONFIDENTIALITY NOTICE: This email may contain con=
fidential and privileged material for the sole use of the intended recip=
ient(s). Any review, use, distribution or disclosure by others is strict=
ly prohibited.  If you have received this communication in error, p=
lease notify the sender immediately by e-mail and delete the message and=
 any file attachments from your computer. Thank you._______________________________________________
OAuth=
 mailing list
https://www.ietf.org/mailman/listin=
fo/oauth

--
  Bron Gondwana, CE=
O, Fastmail Pty Ltd
  brong@fastm=
ailteam.com



--1e68cbf0b5d446da9f9eca03f27ba384--


From nobody Tue Feb 23 13:57:18 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7563A0D03; Tue, 23 Feb 2021 13:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=sp5iOLNv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H6/o2v7w
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL7m7Z11cxyy; Tue, 23 Feb 2021 13:57:14 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2323A0D02; Tue, 23 Feb 2021 13:57:14 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id EC58751E; Tue, 23 Feb 2021 16:57:12 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 16:57:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=R im+LiPF72ewXbzPnH5IUjmMtAeua292WrUsOvYy4t0=; b=sp5iOLNv+owU7F9O6 kQOeuuNPlZhHIsybJKAMJ9eyT4ZEEFRxdTRF2jqs3DKyUztdSQAo8LXBh4F9MbKL sNmQTiTaEO1HYmAhF7E373xKCuwBLldT2Ykwz9L7YrbRRgCIgkgshZGAIMNE/PTi 6rdRof9rXqS08M0sweDlAfHNaLWB4Zz0kp3Yl52aJsPZVV61EdAFMURsoeasOwzQ +prOZZ7IVHzwF9zXY6h7dbV0xfkT7Ukh/zLGSqEAZwjIn2VTS3b8y2nrHUUqACOS 3BMjPhk24vCxwrrpHuNcv5T/SwFO0W/ZGIt+7lsNR62yehzL+wZf14CwKYhehHdV PATvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Rim+LiPF72ewXbzPnH5IUjmMtAeua292WrUsOvYy4 t0=; b=H6/o2v7wD2N1pbfHwh3iIyxI3JaHKP4tEMh4Eek8ybuqoVIC8gOtF5cUj bvrVK5/cDtvLFOY9VTAYbFZgA9fXybPobKqThyRhpJI+PDT0HvXyyohwPvy0Mbc5 w6w08b2vwUG/EuQR6Ta99y5cPGRopORfVrHGjU49wLFmk8AMJO2ow/HvrcVRDC8C DGWe1BhidOpEZW+FPdJV45t4a+TwqeMf2vC1TmuOGZk1oQ9RUL/S153Tof+S24HB +0d8MRUTqbnRyCijj578gIzrYuSSSb0f7VUcrP1FWx7DF6IqVqB5we1mMkNpbKxV Uen/Qdx2pC3YlHu2GfPUELDWAZGKQ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepvefffffhudetveevhfeuffeigedtue dtheffleetffeftddtgeegjeehieeuteetnecuffhomhgrihhnpehmnhhothdrnhgvthen ucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy:    
Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id EF0CB108005F; Tue, 23 Feb 2021 16:57:08 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 24 Feb 2021 08:57:06 +1100
Cc: Roman Danyliw , "ietf@ietf.org" , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>  
To: Kathleen Moriarty 
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 21:57:16 -0000

> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty =
 wrote:
[...]
> And way back when I was AD, OAuth was by far the most productive =
working group I managed.  They put out what felt like about 3 documents =
a meeting for full publication.  I was the AD for 3 years, ending in =
2017 when EKR became an AD.
>=20
> There was a bit of management as a result of the number of experts and =
varying use cases for their environments, but even with that, OAuth was =
very productive.  Since your document was 2016, I was likely the AD.  =
Yes, the meetings had challenges at times, but we worked through it and =
things got done.

Measuring productivity through the number of documents published is not =
a good habit for us to get into; it gives incentive to all of the wrong =
kinds of behaviours. Having some success metrics for our work has come =
up in the IAB a few times, but we haven't made much progress. =20

Cheers,


--
Mark Nottingham   https://www.mnot.net/


From nobody Tue Feb 23 14:11:23 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38D3A0D62; Tue, 23 Feb 2021 14:11:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLuyUaw6UA0Q; Tue, 23 Feb 2021 14:11:16 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7953A0D60; Tue, 23 Feb 2021 14:11:16 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id h125so13612528lfd.7; Tue, 23 Feb 2021 14:11:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P61FMQ9MsmUUQpnHJoSnPczlEfv1+UHg2dta9aMvL18=; b=GAIx9SdTaJiHPHAsfLGBrR4krPgRlMaGB6zg+B8f1mGedWWmhbPHRx3DdEB/hWU0P3 EGAWYymGi0FKAurKLohC4v2BT9Ea5byFy/bArgUNdSqpRWvGTCgQNYvpG3QNCvJLjmna m8UY7gLIkCxly5xucq2IeWapsD2CEEFEQP2aSOnuv1OLACqnShGhGQseMCpt9kJUnfRA 6OOQWC73hEmb46ZyoSmaAC3ksO7m1BP5WAdFn1oPfiI4IzU9gzX4hM8bbvue8/1Vn4QA +xTBCF3PjatDEe0SS5jN47x+dCSGpGy5gZcOszEgiITYFbaTzjnooszQUuegoLy/E+di hd8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P61FMQ9MsmUUQpnHJoSnPczlEfv1+UHg2dta9aMvL18=; b=IMbRMMKxh4jAKDrsrQuRD0nikzqRHQX2FTMrvyxJAz1kn1HT1hlHUI8q3KjhiKNcUQ gSNZ/+erKQNIrTNRIM43tmFSbqXoahHhWsp46SJz5p3v/CHAZL3Pv7lwLoy0r3oiRjS+ PUO8kpOTeBvkAqbJdAfZU3EJjHu9HxP5PURGudz1UuABRdbOr0Fo87RCYz7zzKk5wST7 hncvfTBfC5ESBpquMe9GmOd8+d+THw0i8ulou+64JrP6XmEBFfSksXpXjiUlcAlRoRxB u9rnLlxJC+R0eBA4sK0h0dY16yV93XZdfmoJgLCnlo3FFCbodnA1hSWkE517aWlr7M78 zj8A==
X-Gm-Message-State: AOAM531shkrBjC58s2grsU+e7ntg2ac7w9FilIlqFoSRwsPpooqnqbsz l/pZdOJ1P01ZSCu5ARy+ntCaQT29w5lcUs7Us+s=
X-Google-Smtp-Source: ABdhPJxU73Y0xj5PF6oLjFIhKZH6TkkffgeHprGqhlWWCCh5pyeVdLCog/lSVpqd/g0WuV+miFo5vBh4Y/w8dBplDX8=
X-Received: by 2002:a05:6512:1054:: with SMTP id c20mr16841854lfb.170.1614118274585;  Tue, 23 Feb 2021 14:11:14 -0800 (PST)
MIME-Version: 1.0
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>   
In-Reply-To: 
From: Rifaat Shekh-Yusef 
Date: Tue, 23 Feb 2021 17:11:03 -0500
Message-ID: 
To: Mark Nottingham 
Cc: Kathleen Moriarty , "ietf@ietf.org" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000061d90f05bc0832c2"
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 22:11:18 -0000

--00000000000061d90f05bc0832c2
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham  wrote:

>
>
> > On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <
> kathleen.moriarty.ietf@gmail.com> wrote:
> [...]
> > And way back when I was AD, OAuth was by far the most productive working
> group I managed.  They put out what felt like about 3 documents a meeting
> for full publication.  I was the AD for 3 years, ending in 2017 when EKR
> became an AD.
> >
> > There was a bit of management as a result of the number of experts and
> varying use cases for their environments, but even with that, OAuth was
> very productive.  Since your document was 2016, I was likely the AD.  Yes,
> the meetings had challenges at times, but we worked through it and things
> got done.
>
> Measuring productivity through the number of documents published is not a
> good habit for us to get into;


The number of documents published was in response to a comment that
"nothing would get done" at the OAuth WG. Which is clearly not true.


> it gives incentive to all of the wrong kinds of behaviours.


Can you elaborate on these wrong behaviours?

Regards,
 Rifaat


> Having some success metrics for our work has come up in the IAB a few
> times, but we haven't made much progress.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--00000000000061d90f05bc0832c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tue, Feb 23, 2021 at 4:57 PM Mark Nott=
ingham <mnot@mnot.net> wrote:




> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <kathleen.moriarty.ietf@gm=
ail.com> wrote:

[...]

> And way back when I was AD, OAuth was by far the most productive worki=
ng group I managed.=C2=A0 They put out what felt like about 3 documents a m=
eeting for full publication.=C2=A0 I was the AD for 3 years, ending in 2017=
 when EKR became an AD.

> 

> There was a bit of management as a result of the number of experts and=
 varying use cases for their environments, but even with that, OAuth was ve=
ry productive.=C2=A0 Since your document was 2016, I was likely the AD.=C2=
=A0 Yes, the meetings had challenges at times, but we worked through it and=
 things got done.



Measuring productivity through the number of documents published is not a g=
ood habit for us to get into; 

The number o=
f documents published was in response to a comment that "nothing would=
 get done" at the OAuth WG. Which is clearly not true.
=C2=
=A0
it gives inc=
entive to all of the wrong kinds of behaviours. 

Can you elaborate on these wrong behaviours?

Regards,
=C2=A0Rifaat
=C2=A0
Having some success metrics for our work =
has come up in the IAB a few times, but we haven't made much progress.=
=C2=A0 



Cheers,





--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--00000000000061d90f05bc0832c2--


From nobody Tue Feb 23 14:36:32 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85CC3A0E0B for ; Tue, 23 Feb 2021 14:36:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=aPyNQI0h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t7uqGyf+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIrJmDFxKz6M for ; Tue, 23 Feb 2021 14:36:29 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FF53A0E09 for ; Tue, 23 Feb 2021 14:36:29 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9D7B85C00A8 for ; Tue, 23 Feb 2021 17:36:28 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 23 Feb 2021 17:36:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=FDn6hQTncgjOe6DdtU6roiv9 yUCNQkhzgSuviUAvaq4=; b=aPyNQI0hJesUqc2PO86bGfsiHhW1enoUaKXu5OF3 Rbk35MUp9eLYeCH2C7IxhZPzLTJkGMgZlX2iaxmvoleTXrSKFOjMUH6P8XZ+eHj+ Ee+3FTq1rpaslfEWsrUQpZ++CefHjRZy7foB9NXjwSoiToVyP3UFmSqxrYVxbYqi rjE=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=FDn6hQ TncgjOe6DdtU6roiv9yUCNQkhzgSuviUAvaq4=; b=t7uqGyf+a38s1fbHJBGVxZ zn/ShG+wQD/7Q6NkFdUZE6Rf5OUehopOYIGVlYrHxpJ29lJgctfWDtSp7OB1x3Wn 2BwdpeZJw6o/4VBV9Qb76ihySbeb/xmgoHLgVObzB8sa83Xq19D4N2Rz9YHezv4F omTCixHL6rCSZdk4F4P4qBqo+rsmV82CiP+jEih9SYdeihwMqpy5rlDzCaP36Fu3 RBbQ8gSMxl+scueIojJyw53Tf0XFasOUctxrEWiHy6yp1tC1ujW1wWlwFSK+RAGg VlZ+vFqWnWLSR7SJpGpJ3iytIAqufPDO8AjgfYz8oTC9kpDusbC4m7NqAJucE87w ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdduiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucggtffrrghtthgvrhhnpefhueehgfejtdduheehgeevveeijeffffejueefgf eiudekhffhvedukedvteeiudenucffohhmrghinhephhhtthhptghlihgvnhhtshgsuhht shgukhhsfhhorhgvrggthhhsvghrvhhitggvrdhtohenucfkphepudegvddruddviedrud eiiedrvddtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehmvgesvghvvghrthhpohhtrdgtohhm
X-ME-Proxy:    
Received: from [192.168.2.61] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id 550301080069 for ; Tue, 23 Feb 2021 17:36:28 -0500 (EST)
To: oauth@ietf.org
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com>  <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com>   <24452E46-B957-4C35-BAEC-BC2D75B25923@independentid.com> <50a62bd2-5a1c-481a-b58b-3f90ec703f88@dogfood.fastmail.com>
From: Evert Pot 
Message-ID: <7cc82198-4eed-50d3-4de4-30dc0919cdcc@evertpot.com>
Date: Tue, 23 Feb 2021 17:36:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <50a62bd2-5a1c-481a-b58b-3f90ec703f88@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------7C5F7D1643A80C064BF47411"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 22:36:31 -0000

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


> If every client and every server needs to implement "/all the popular 
> mechanisms/" then that's not such a big deal when you're shipping the 
> client code for your own server as part of a website, but it's a big 
> deal if you're trying to create a general client and don't want to 
> have to hard-code the specific magic for each server provider.
>
> So the reason to encode the authentication mechanism into JMAP was 
> precisely to reduce the number of possibilities.

I want to echo this as a something I also feel OAuth2 has failed at 
(thusfar). We used to be able to point our user-agent at an endpoint, 
get a WWW-Authenticate & 401, and the agent would be able to figure out 
how to log the user in. I can't point my browser to an OAuth2 protected 
endpoint and discover what an API offers.

With OAuth2 we need a ton of out-of-band information. I think this is 
partially contributing to people not building generic HTTP clients, but 
SDKs for each service. To some extent I think it's breaking the web.

I hope a future version of OAuth prioritizes server-driven oauth2 
configuration.

Evert

P.S.: I do appreciate all the work that has gone in OAuth2, and this 
specific criticism is not intended as an overall sentiment.


--------------7C5F7D1643A80C064BF47411
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

      
If every client and every server
        needs to implement "all the popular mechanisms" then
        that's not such a big deal when you're shipping the client code
        for your own server as part of a website, but it's a big deal if
        you're trying to create a general client and don't want to have
        to hard-code the specific magic for each server provider.

      

      


      

      
So the reason to encode the
        authentication mechanism into JMAP was precisely to reduce the
        number of possibilities.

      

    

    
I want to echo this as a something I also feel OAuth2 has failed
      at (thusfar). We used to be able to point our user-agent at an
      endpoint, get a WWW-Authenticate & 401, and the agent would be
      able to figure out how to log the user in. I can't point my
      browser to an OAuth2 protected endpoint and discover what an API
      offers. 

      

      With OAuth2 we need a ton of out-of-band information. I think this
      is partially contributing to people not building generic HTTP
      clients, but SDKs for each service. To some extent I think it's
      breaking the web. 

    

    
I hope a future version of OAuth prioritizes server-driven oauth2
      configuration.

    

    
Evert

      

      P.S.: I do appreciate all the work that has gone in OAuth2, and
      this specific criticism is not intended as an overall sentiment.

    

  


--------------7C5F7D1643A80C064BF47411--


From nobody Tue Feb 23 14:40:05 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B6F3A0E26 for ; Tue, 23 Feb 2021 14:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOZTtT11Vq6e for ; Tue, 23 Feb 2021 14:40:02 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412EA3A0E1F for ; Tue, 23 Feb 2021 14:40:02 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id c17so138258ljn.0 for ; Tue, 23 Feb 2021 14:40:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e7292WfIvWtKAW/4EJoUcGmlBa2DMKg+u55td5ZKix8=; b=evR9aJ9hdBgqUkhdBqvaE4s65yDiChgHPV3Snnv66ybyTc7UVUONFIh7RrQmBrgmwL 5TX0vn+Ym5fGmwY1HBPluSYcJJtk+8hmGIUqfkiXI7jJiyf0pPpXRgCyiAfkPH+u0Cwj PXoMH/kb+G22WG3vDaEHRDUKanf9cLnCX4YWOyvDlmgbwES7GgvtAoopVdM1bQd3bJ8X QffNJmc3qGJGHdk2dhWkvBzTutLJc8hHbtSlrZFJVEEVVjQXDcvfLq8wfZ0Q4cd8gKAy p6u2zj/2XO924W8XspEImul9y0WcX7pYU6HV6oP1Wvn+rnAlGnHjqZ185wHTXducL7RD S2bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e7292WfIvWtKAW/4EJoUcGmlBa2DMKg+u55td5ZKix8=; b=U8eqZJLFFvh1YcZRZAMEDHiDSLcxOzTBEtRepKHz74jP1wwcq5iHITWpZKmGXlhcBM J3NEuYbMmkgKiKjN7V6OqFiqsOMB+3GzOgqUMojrJRoigMEO2azGG3nU0y+yd0U4TLI/ J5rQBiPwjfUTO1iQD/cj/opzL68ypF5Zkcc6F4YKwIb/91/dPoAeY7pT4hbirbRH0M8E 8j4+rLmOalfct/YEz94Soheka97wz+0aG6OpQJAOEgAh5Oq6bvXIxx4Pgy86LULPDSQb A+IO/gJCxi1v0Qp4rSLUF2E+4PCn8PaounXG4VDbM8AbVrROzoX3YaV7iUuV5HTnkYxD k85Q==
X-Gm-Message-State: AOAM532lxsF+4TbsOQxbhAizBixasOVH5M0IIilGVPLm7qzrCjwRdAuV 3Y1767pitkza1Q9ViellwHz2H2vl7Aua5DvueJKWdQ==
X-Google-Smtp-Source: ABdhPJzMMpX83p+orvPA2LgfJbHi927rCz6BCa+Wfqhht7MO8FgYHhHCgtto38RiNF8N8gHZs24Gr2CLyi5CyhoqEm8=
X-Received: by 2002:a2e:9c12:: with SMTP id s18mr16563188lji.383.1614120000321;  Tue, 23 Feb 2021 14:40:00 -0800 (PST)
MIME-Version: 1.0
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>    
In-Reply-To: 
From: Eric Rescorla 
Date: Tue, 23 Feb 2021 14:39:24 -0800
Message-ID: 
To: Rifaat Shekh-Yusef 
Cc: Mark Nottingham , Kathleen Moriarty ,  "ietf@ietf.org" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000003e85cc05bc0899e2"
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 22:40:05 -0000

--0000000000003e85cc05bc0899e2
Content-Type: text/plain; charset="UTF-8"

Replying to Rifaat's e-mail but not replying to him specifically.

Hi folks,

I don't think the question of whether OAuth is a good or bad WG group is
really a productive one in general, and it's especially hard for me to see
how it's going to let us make progress on questions of DEI. This seems like
precisely the kind of thing that's going to lead to a bunch of hard
feelings without making progress. I think we can all agree that the IETF
culture isn't perfect and that there are cases where we make it hard for
new people to get involved, so maybe we could focus instead on those
aspects of our culture.

I would suggest that if people have problems with the way the OAuth WG is
being run they ought to take it up with the AD (Roman Danyliw), or, failing
that, on the IETF list.

-Ekr




On Tue, Feb 23, 2021 at 2:12 PM Rifaat Shekh-Yusef 
wrote:

>
> On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham  wrote:
>
>>
>>
>> > On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <
>> kathleen.moriarty.ietf@gmail.com> wrote:
>> [...]
>> > And way back when I was AD, OAuth was by far the most productive
>> working group I managed.  They put out what felt like about 3 documents a
>> meeting for full publication.  I was the AD for 3 years, ending in 2017
>> when EKR became an AD.
>> >
>> > There was a bit of management as a result of the number of experts and
>> varying use cases for their environments, but even with that, OAuth was
>> very productive.  Since your document was 2016, I was likely the AD.  Yes,
>> the meetings had challenges at times, but we worked through it and things
>> got done.
>>
>> Measuring productivity through the number of documents published is not a
>> good habit for us to get into;
>
>
> The number of documents published was in response to a comment that
> "nothing would get done" at the OAuth WG. Which is clearly not true.
>
>
>> it gives incentive to all of the wrong kinds of behaviours.
>
>
> Can you elaborate on these wrong behaviours?
>
> Regards,
>  Rifaat
>
>
>> Having some success metrics for our work has come up in the IAB a few
>> times, but we haven't made much progress.
>>
>> Cheers,
>>
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000003e85cc05bc0899e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Replying to Rifaat's e-mail but not replying to h=
im specifically.

Hi folks,

I don't think the question of whether OAuth is a good or bad WG group=
 is really a productive one in general, and it's especially hard for me=
 to see how it's going to let us make progress on questions of DEI. Thi=
s seems like precisely the kind of thing that's going to lead to a bunc=
h of hard feelings without making progress. I think we can all agree that t=
he IETF culture isn't perfect and that there are cases where we make it=
 hard for new people to get involved, so maybe we could focus instead on th=
ose aspects of our culture.

I would suggest th=
at if people have problems with the way the OAuth WG is being run they ough=
t to take it up with the AD (Roman Danyliw), or, failing that, on the IETF =
list.

-Ekr


=



On Tue, Feb 23, 2021 at 2:12 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrot=
e:

On Tue, Feb 23, 2021 at 4:57 PM Mark Nottingham <mnot@mnot.net> wrot=
e:




> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty <kathleen.moriarty.ietf@gm=
ail.com> wrote:

[...]

> And way back when I was AD, OAuth was by far the most productive worki=
ng group I managed.=C2=A0 They put out what felt like about 3 documents a m=
eeting for full publication.=C2=A0 I was the AD for 3 years, ending in 2017=
 when EKR became an AD.

> 

> There was a bit of management as a result of the number of experts and=
 varying use cases for their environments, but even with that, OAuth was ve=
ry productive.=C2=A0 Since your document was 2016, I was likely the AD.=C2=
=A0 Yes, the meetings had challenges at times, but we worked through it and=
 things got done.



Measuring productivity through the number of documents published is not a g=
ood habit for us to get into; 

The number o=
f documents published was in response to a comment that "nothing would=
 get done" at the OAuth WG. Which is clearly not true.
=C2=
=A0
it gives inc=
entive to all of the wrong kinds of behaviours. 

Can you elaborate on these wrong behaviours?

Regards,
=C2=A0Rifaat
=C2=A0
Having some success metrics for our work =
has come up in the IAB a few times, but we haven't made much progress.=
=C2=A0 



Cheers,





--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000003e85cc05bc0899e2--


From nobody Tue Feb 23 14:42:11 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BEB3A0E28 for ; Tue, 23 Feb 2021 14:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XMWzTepXhrl for ; Tue, 23 Feb 2021 14:42:09 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5393A0E27 for ; Tue, 23 Feb 2021 14:42:09 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id a22so11753ejv.9 for ; Tue, 23 Feb 2021 14:42:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=+o20UiNzfiMichHt2gPsUAdG9/qiXN3Sw6TZPPNNH+8=; b=UR7eIvVKG+xZC3NJ16QPlOtsuch8DLeqi0Zky9wFshzCC+9ONXl/fdaCV2JAUNrzrc U28g4v84CDCGVCgWLOu4aM4H1RmA0cFmaLMaaXbgm727CCH5BVtcyH74y9yBk3C6+9Qs KhwOB1O5slZhePLpZerpw2GQfD1l5UA9x4dAVZBghfpJLTBe1hWjIBUQa0XUYM5Q6nQW mgoC1SCI+WHmtECrK+2Yk7BVHzpF7zUpQHLlxR2GDDfw/bxjbHLQvXRXCink6T7jVwcc eT1/15ZXlqbyac4MeWUUymUC7qz26kBoRWd8Xhdt+JOPwsu+0x3DdnHs8LUgDc9qI1D0 2OYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=+o20UiNzfiMichHt2gPsUAdG9/qiXN3Sw6TZPPNNH+8=; b=QhYxy+fv5qmYS9eo8orw4qO7/ULHHiEUPZvWofknvlLXc86phWDUCc3aU6prb6Dc13 Q/Q/Wn9+BilZVigbvbJNB0zWOlQZeMdKc7RXSV8vfTakWYQH7FLf12G6DDCKUvY1lCH5 dA2GvupoXstXi041ZkrQzcHno7SNMH4ruRHviV+wfEUPXedCoJPuBCQpkhfYi2dXtMgn vv+tYDttIGgHMSFSbqd67sKA5fQGeSMhbfjUaw0K1hmxGR0P4U9ZuxU7GEMvTxeO3ZeG LPxAmZG1nRmtDSL9M2TMUoBh2Wd4aPVwi7fvJgZ0AftSVYnUzJ7HKtnKeXHlu69717Zc QoVg==
X-Gm-Message-State: AOAM531e/tCbY66fUYG3E7qOyQocJ8ItokvqJTdLTEYzHQvYow7XftgT c8CriiKiumN6ak1otoGuJD4y/Doy3rOQXUfFrbJsKTzF/2c=
X-Google-Smtp-Source: ABdhPJwAqVlWUiFzal4Y1AVYE+D3REOxPZUAENRqgC4g5WvtHCAss0GLJOpvcE0o76f1RZ2dXfLIfS4sDXZup4L2o0I=
X-Received: by 2002:a17:906:a896:: with SMTP id ha22mr545708ejb.503.1614120127740;  Tue, 23 Feb 2021 14:42:07 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:aa7:d615:0:0:0:0:0 with HTTP; Tue, 23 Feb 2021 14:42:07 -0800 (PST)
From: Jerry Leyendecker 
Date: Tue, 23 Feb 2021 14:42:07 -0800
Message-ID: 
To: "oauth@ietf.org" 
Cc: Jleyendeckeratx@gmail.com
Content-Type: multipart/alternative; boundary="000000000000d6bdb805bc08a090"
Archived-At: 
Subject: [OAUTH-WG] Auth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 22:42:11 -0000

--000000000000d6bdb805bc08a090
Content-Type: text/plain; charset="UTF-8"

Yeah

--000000000000d6bdb805bc08a090
Content-Type: text/html; charset="UTF-8"

Yeah

--000000000000d6bdb805bc08a090--


From nobody Tue Feb 23 15:14:38 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA8A3A0FCA for ; Tue, 23 Feb 2021 15:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTt1IxYRyqOl for ; Tue, 23 Feb 2021 15:14:35 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9FE3A0FC7 for ; Tue, 23 Feb 2021 15:14:35 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id f6so14078iop.11 for ; Tue, 23 Feb 2021 15:14:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WImEiMAangfyWPqGBxCL3R4QAySpXCB/a1Be3yznoRg=; b=dI07HrrgqBDr5yBEBVFP+6rDYHfkf6LOm0GeetiKsYtzQfepe3Whf9TZGOhPrQd4XU mFNFi6WcTfD/xDm1pZCpjKEaMR72hTxHpiigyAeCqNCCarMnNqLXA41vJ1iJzUFp8DDf kDdolPHJ8RXCFJUW0NSETJ479Oq+9Zk1yT4iVbaT20oJ2c9/A9ihUGvEVWAMY7i9YAwC UyJ3F5UwjNoqwXDMZCL3U//aD76mLu264lwdcfuFZdRDDk3/re4GrkcJ2slBEFQkl5Ch LDmqMvF8b/rToy4Z67sqlMsfDm5j9eCXZrG6xaH/I/5S28/xWA8FZY4h9mFAEwqrTZig KOVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WImEiMAangfyWPqGBxCL3R4QAySpXCB/a1Be3yznoRg=; b=oDEHbh4E3VsVKwBobYgepxhrCb/RU3ilTXabdVcDrdPiQK6fQqbPUldGQ2jY2vRVoi dl/KMHyne3W2dKR1Go9oZrtilGIVhC0bpDPzxlsqtp6bQreM5UHc70ERqvbmAvt7BaH0 EHGQ9l+6/gG5VjRJzeminFHA17xOnJnlrxoNQhoU04SjiEoxzy7NZMx9fCS4Jq+KanRN SE+TTrPk9lj4pQLisKHZOvX2aY0DGW0UW0jgv5fTmeLuFMRFDkJJQvykKqiU7TxvSz2p tpm3AThQMhfVMIGn1jp9lAApc56AEDLWP04gPKja3SelA7lp4ZyJjRbLb0aSUaYSkigY HM8g==
X-Gm-Message-State: AOAM5326Y46DBvO0Zz4mdAXICUf2oexmSodN8QjQVxYb88aQPhZ9vgxB /8+wJLriGipPwoz0aatwMgVhv8yiycWmVO0bH9nb
X-Google-Smtp-Source: ABdhPJxj5ezB0djLkOH0GO7gmj7mlf5lsXzm6ItiOUuuZYM23V3ipPjDv0t21hwyFKUw4NA3PneeOYfGYOjmmJMvF4I=
X-Received: by 2002:a5e:8817:: with SMTP id l23mr17032501ioj.41.1614122074422;  Tue, 23 Feb 2021 15:14:34 -0800 (PST)
MIME-Version: 1.0
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <98f539f4-1207-4a03-ae1f-f377d6964122@dogfood.fastmail.com>  <76e71db0-5cd5-4f95-8c44-9c476a1adb24@dogfood.fastmail.com>   <24452E46-B957-4C35-BAEC-BC2D75B25923@independentid.com> <50a62bd2-5a1c-481a-b58b-3f90ec703f88@dogfood.fastmail.com> <7cc82198-4eed-50d3-4de4-30dc0919cdcc@evertpot.com>
In-Reply-To: <7cc82198-4eed-50d3-4de4-30dc0919cdcc@evertpot.com>
From: Warren Parad 
Date: Wed, 24 Feb 2021 00:14:23 +0100
Message-ID: 
To: Evert Pot 
Cc: oauth 
Content-Type: multipart/alternative; boundary="000000000000ded4de05bc091406"
Archived-At: 
Subject: Re: [OAUTH-WG] JMAP's experience with proposing an Authentication model
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Feb 2021 23:14:37 -0000

--000000000000ded4de05bc091406
Content-Type: text/plain; charset="UTF-8"

Okay, now I'm lost, what's the point of this discussion? Is there something
we are actively trying to achieve?

The email subject is *JMAP's experience with proposing an Authentication
model*, sometimes sharing experiences is helpful, but I still lack the goal
we are attempting to accomplish by doing that. Are we hoping to change
something in particular, if so, what exactly is that? Is it the culture of
the group, how the OAuth specs are written, the goal of the WG, or
something else?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Tue, Feb 23, 2021 at 11:36 PM Evert Pot  wrote:

>
> If every client and every server needs to implement "*all the popular
> mechanisms*" then that's not such a big deal when you're shipping the
> client code for your own server as part of a website, but it's a big deal
> if you're trying to create a general client and don't want to have to
> hard-code the specific magic for each server provider.
>
> So the reason to encode the authentication mechanism into JMAP was
> precisely to reduce the number of possibilities.
>
> I want to echo this as a something I also feel OAuth2 has failed at
> (thusfar). We used to be able to point our user-agent at an endpoint, get a
> WWW-Authenticate & 401, and the agent would be able to figure out how to
> log the user in. I can't point my browser to an OAuth2 protected endpoint
> and discover what an API offers.
>
> With OAuth2 we need a ton of out-of-band information. I think this is
> partially contributing to people not building generic HTTP clients, but
> SDKs for each service. To some extent I think it's breaking the web.
>
> I hope a future version of OAuth prioritizes server-driven oauth2
> configuration.
>
> Evert
>
> P.S.: I do appreciate all the work that has gone in OAuth2, and this
> specific criticism is not intended as an overall sentiment.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000ded4de05bc091406
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Okay, now I'm lost, what's the point of this discu=
ssion? Is there something we are actively trying to achieve?

=

The email subject is=C2=A0JMAP's experience with proposing an A=
uthentication model, sometimes sharing experiences is helpful, but I st=
ill lack the goal we are attempting to accomplish by doing that. Are we hop=
ing to change something=C2=A0in particular, if so, what exactly is that? Is=
 it the culture of the group, how the OAuth specs are written, the goal of =
the WG, or something else?


Warren Parad
=

Founder, CTO
Warren Parad
<=
p dir=3D"ltr" style=3D"line-height:1.2;border-left:solid #ffffff 1pt;border=
-right:solid #ffffff 1pt;border-bottom:solid #ffffff 1pt;margin-top:0pt;mar=
gin-bottom:0pt">Founder, CTO
Secure your user data with IAM=
 authorization as a service. Implement=C2=A0Authress.


On =
Tue, Feb 23, 2021 at 11:36 PM Evert Pot <me@evertpot.com> wrote:

 =20
   =20
 =20
  

    

    

      
If every client and every server
        needs to implement "all the popular mechanisms" th=
en
        that's not such a big deal when you're shipping the client =
code
        for your own server as part of a website, but it's a big deal i=
f
        you're trying to create a general client and don't want to =
have
        to hard-code the specific magic for each server provider.

      

      


      

      
So the reason to encode the
        authentication mechanism into JMAP was precisely to reduce the
        number of possibilities.

      

    

    
I want to echo this as a something I also feel OAuth2 has failed
      at (thusfar). We used to be able to point our user-agent at an
      endpoint, get a WWW-Authenticate & 401, and the agent would be
      able to figure out how to log the user in. I can't point my
      browser to an OAuth2 protected endpoint and discover what an API
      offers. 

      

      With OAuth2 we need a ton of out-of-band information. I think this
      is partially contributing to people not building generic HTTP
      clients, but SDKs for each service. To some extent I think it's
      breaking the web. 

    

    
I hope a future version of OAuth prioritizes server-driven oauth2
      configuration.

    

    
Evert

      

      P.S.: I do appreciate all the work that has gone in OAuth2, and
      this specific criticism is not intended as an overall sentiment.

    

  


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000ded4de05bc091406--


From nobody Tue Feb 23 21:47:24 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5CF3A0ED3; Tue, 23 Feb 2021 21:47:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5rUxqijq_4t; Tue, 23 Feb 2021 21:47:15 -0800 (PST)
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1A43A0ED1; Tue, 23 Feb 2021 21:47:14 -0800 (PST)
Received: by mail-yb1-f179.google.com with SMTP id b10so732917ybn.3; Tue, 23 Feb 2021 21:47:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ksiww6hwtr+xTib2C0d/Ekmde5mKhPX2aWNQupDCx/s=; b=CNAh9woN+8vRb3TwEy6ikGoVFtqAspMeki74Oto1WMXi5lnPr2yykApzgyrfQ1AlLt +pTFoCXUSIS8kurs7ev9YTYWJubmSzpFT4aA17TuvfFubFyiwfmNuj4LxuHqx8Trov69 gx6im4XexpS6b6ShR+mRq5LGlFitm/3ixMrUcNIw09d8AcHZmcKuhQsfIZeBIzvb/zSh BPkN+t4+y3FaoftIc12NpwOAA5DhhM7V888vgydwN3g3NUBSweKjzrQN6An1tlqBz8xY HQV07hdC8FoUic0RseWQg0lxygG8pLDJ9GT8E3x/h5gIqmRJMBnHau705tgKwUygSmOZ q6jA==
X-Gm-Message-State: AOAM532Xomz0PIk0qC0GWn3IT/DzxUyoHWrtzbQ7Pq7hHE58+dP5YKNw Tfp7RQrm/sS7EniU9aEwLUK2KULTvt5Yc5Zff9E=
X-Google-Smtp-Source: ABdhPJx50qw4+0Cj13hEXO8AyCBkB9LaD6o3lcMlFh4uh7sYCKZe+Ly1MDGM/uljINVsBgcBFUd+mZqWso/qULne+Xc=
X-Received: by 2002:a25:dbc6:: with SMTP id g189mr36082170ybf.273.1614145633717;  Tue, 23 Feb 2021 21:47:13 -0800 (PST)
MIME-Version: 1.0
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>  
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Wed, 24 Feb 2021 00:47:03 -0500
Message-ID: 
To: Kathleen Moriarty 
Cc: Roman Danyliw , "ietf@ietf.org" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000001d131005bc0e913d"
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 05:47:17 -0000

--0000000000001d131005bc0e913d
Content-Type: text/plain; charset="UTF-8"

I am worried by the advice 'use OAUTH' but for a very different reason.

OAUTH and SAML are both attempts to provide a secure authentication scheme
that works within the very particular and very peculiar environment of Web
browsers. They are schemes that necessarily involve techniques that are
rightly regarded as alchemy if not outright witchcraft.

That is fine, that is more than fine if you are developing an
authentication scheme for use within Web browsers (or if you are developing
whatever SAML and OAUTH are these days, neither was originally billed as
authentication). But it is completely inappropriate to ever suggest let
alone demand that anyone use a technology whose primary design constraint
is to work around the voodoo of Javascript, URIs, HTTP cookies etc. etc. in
an application where none of those legacy issues apply.

One of the big problems of IETF is that a lot of people don't think about
how to get their scheme deployed and when they do, their plan is to tie it
to some other group as a boat anchor. Back when we were doing DKIM and SPF
we had to tell certain DNS folk that the fact that almost no DNS Registrars
offered customers the ability to specify new RRTypes was their problem and
was going to remain their problem no matter how loudly they tried to
complain that it should become our problem.

In the case of OAUTH, there is another problem in that OAUTH really isn't a
very open protocol from the standpoint of the user. I can use my Google or
my Facebook or my Twitter accounts to log in via OAUTH at a large number of
sites. But if I want to use any other OAUTH provider I am completely out of
luck. Or at least I will be until this becomes one of the multifaceted
complaints in the anti-trust hearings coming soon to a capitol hill near
you. And yes, that is a consequence of how the protocol has been deployed,
but that probably not going to get people very far on capitol hill.


The Internet is for everyone. The Internet is for end users.

I am really not that interested in who makes the ingredients except to the
extent that it determines what sort of cake emerges. One of the unexpected
side effects of Web 2.0 has been that it has greatly centralized power in
the hands of a tiny number of individuals. Individuals who are at best
accountable to shareholders, but in the case of some of them, a separate
share class ensures that they are accountable to nobody. In neither case
are the people with power accountable to end users because they are not
even customers, they are the product.

What I am interested in is the extent to which Internet technologies are
Technologies of Freedom. The question we need to ask ourselves is 'does
this technology increase end user autonomy or increase their reliance on
third parties'.

>

--0000000000001d131005bc0e913d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I a=
m worried by the advice 'use OAUTH' but for a very different reason=
.

OAUTH and SAML are both=
 attempts to provide a secure authentication scheme that works within the v=
ery particular and very peculiar environment of Web browsers. They are sche=
mes that necessarily involve techniques that are rightly regarded as alchem=
y if not outright witchcraft.

That is fine, that is more than fine if you are developing an authenti=
cation scheme for use within Web browsers (or if you are developing whateve=
r SAML and OAUTH are these days, neither was originally billed as authentic=
ation). But it is completely inappropriate to ever suggest let alone demand=
 that anyone use a technology whose primary design constraint is to work ar=
ound the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an applicati=
on where none of those legacy issues apply.

One of the big problems of IETF is that a lot of peopl=
e don't think about how to get their scheme deployed and when they do, =
their plan is to tie it to some other group as a boat anchor. Back when we =
were doing DKIM and SPF we had to tell certain DNS folk that the fact that =
almost no DNS Registrars offered customers the ability to specify new RRTyp=
es was their problem and was going to remain their problem no matter how lo=
udly they tried to complain that it should become our problem.=C2=A0
<=
div class=3D"gmail_default" style=3D"font-size:small">
In the case of OAUTH, there is=
 another problem in that OAUTH really isn't a very open protocol from t=
he standpoint of the user. I can use my Google or my Facebook or my Twitter=
 accounts to log in via OAUTH at a large number of sites. But if I want to =
use any other OAUTH provider I am completely out of luck. Or at least I wil=
l be until this becomes one of the multifaceted complaints in the anti-trus=
t hearings coming soon to a capitol hill near you. And yes, that is a conse=
quence of how the protocol has been deployed, but that probably not going t=
o get people very far on capitol hill.


The Internet is for everyone. The Internet is for end users.

I am really not that interested in =
who makes the ingredients except to the extent that it determines what sort=
 of cake emerges. One of the unexpected side effects of Web 2.0 has been th=
at it has greatly centralized power in the hands of a tiny number of indivi=
duals. Individuals who are at best accountable to shareholders, but in the =
case of some of them, a separate share class ensures that they are accounta=
ble to nobody. In neither case are the people with power accountable to end=
 users because they are not even customers, they are the product.

What I am interested in is the ext=
ent to which Internet technologies are Technologies of Freedom. The questio=
n we need to ask ourselves is 'does this technology increase end user a=
utonomy or increase their reliance on third parties'.




--0000000000001d131005bc0e913d--


From nobody Tue Feb 23 22:01:45 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC1A3A100D; Tue, 23 Feb 2021 22:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=sHom5JrL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ho4Ay5er
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnZJTcDVL5By; Tue, 23 Feb 2021 22:01:30 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2093A100A; Tue, 23 Feb 2021 22:01:30 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4F25E5C012B; Wed, 24 Feb 2021 01:01:29 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 01:01:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=V d8oksM+26OsF8fRnRxftRGHa2OaJR45JMws8jN6Jtg=; b=sHom5JrL36bGhfNvi loBlubK7/ILrX34WI8ggfRdn1lNBYOPPIls97SoFOlbYl2O5GfOYLNDKZlDYT5qs KAybIfsm0M/8DxnzXQnxkkBlszjeyclntL+vCuXwh5Arz01vMPcJndiRefmvcCsX RTLUnaZBUWZAm6jk01sohcvt1AT/lWw1grYRBdwvONc+eatERYOoQ+IIYFnHYLgI qS4XtcsD8Gz1GkwHZrwX/E1OsBLWA4SzH4ibYirIlOcfrVEARwKdb3m6swi7fsXk z7BeonjLUK5XInB/k3V868agKcDWx/SUoODE/J/3LITqxOm1jWe0aLZC0RlSjP36 0nkFw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Vd8oksM+26OsF8fRnRxftRGHa2OaJR45JMws8jN6J tg=; b=Ho4Ay5er/8e1tFVGWkewDwVaFclEgBQm9AGnAMngxyhSZHmAYB/Hjuwdh JpIS5SvXErt2SQEmJWwFTap+IHREAX/UtlOUCtShkHciFYzuJzuAbGPfTlGkdKgZ ehTijD6WRIKTajK4UH4Sp/MdI1bI2Vqkrugo2xTKfwfc1itYK9zLFN7X+kKOUoKq KVQIFdRWSrrMDoO7nRnhfhO2kAp4WFI+nEDXGTS2EiknqFuCUhMo9CEd/MWqkXUy ymwWlkun84BYZDArwnDnyJX+jGT1z9ehROiIstSbneyVzDbXt7ieHLIE9RLOHwK2 dNtxS+LYN1rZIX0yY23CD6+xLWJ/w==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeigdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepudejtddukeektddvjeevhffgudeuueffheeufedvleejudekheeuvedvieeihffh necuffhomhgrihhnpehmnhhothdrnhgvthdpvghttgdrihhnnecukfhppeduudelrdduje drudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy:    
Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id DBBD724005A; Wed, 24 Feb 2021 01:01:25 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Mark Nottingham 
In-Reply-To: 
Date: Wed, 24 Feb 2021 17:01:22 +1100
Cc: "ietf@ietf.org" , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DA4D2FA-1E2C-4DF1-ACA4-9359FF51ABF8@mnot.net>
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>   
To: Phillip Hallam-Baker 
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: 
Subject: [OAUTH-WG] Building Real Internet Platforms
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 06:01:34 -0000

Just to +1 and add my bit: in my mind one of the fundamental flaws of =
the Web is that it is basically a platform construction toolkit, without =
any of the checks or balances we put into *real* internet platforms to =
assure that there isn't one chokepoint with all of the power. As a =
result, it's tilted heavily towards winner-take-all economists through =
accrual of network effects and data advantages.

We should not follow this pattern in IETF specifications, whether or not =
they're associated with the Web. OAUTH-as-deployed might be one good =
example, but WEBRTC is equally problematic in this regard. WEBTRANS =
smells like it's primarily going to benefit big platforms who want to =
control the entire end user experience (and have the resources to =
exploit it), and let's not even get started about WPACK.

Yes, federation is hard. Yes, standards are slow and not as able to =
respond. Yes, the commercial incentives for silo'd platforms to invest =
aren't present. However, there's a *huge* push by competition =
authorities and regulators to find remedies for the concentrations of =
power in these few hands, and in many minds interoperability standards =
-- enforced by legal instruments -- are a primary means of getting =
there. This is potentially game-changing, in terms of the work that's =
possible to ship here.

I wrote a bit more about this recently:
  https://www.mnot.net/blog/2021/02/18/no-news

Cheers,



> On 24 Feb 2021, at 4:47 pm, Phillip Hallam-Baker =
 wrote:
>=20
> I am worried by the advice 'use OAUTH' but for a very different =
reason.
>=20
> OAUTH and SAML are both attempts to provide a secure authentication =
scheme that works within the very particular and very peculiar =
environment of Web browsers. They are schemes that necessarily involve =
techniques that are rightly regarded as alchemy if not outright =
witchcraft.
>=20
> That is fine, that is more than fine if you are developing an =
authentication scheme for use within Web browsers (or if you are =
developing whatever SAML and OAUTH are these days, neither was =
originally billed as authentication). But it is completely inappropriate =
to ever suggest let alone demand that anyone use a technology whose =
primary design constraint is to work around the voodoo of Javascript, =
URIs, HTTP cookies etc. etc. in an application where none of those =
legacy issues apply.
>=20
> One of the big problems of IETF is that a lot of people don't think =
about how to get their scheme deployed and when they do, their plan is =
to tie it to some other group as a boat anchor. Back when we were doing =
DKIM and SPF we had to tell certain DNS folk that the fact that almost =
no DNS Registrars offered customers the ability to specify new RRTypes =
was their problem and was going to remain their problem no matter how =
loudly they tried to complain that it should become our problem.=20
>=20
> In the case of OAUTH, there is another problem in that OAUTH really =
isn't a very open protocol from the standpoint of the user. I can use my =
Google or my Facebook or my Twitter accounts to log in via OAUTH at a =
large number of sites. But if I want to use any other OAUTH provider I =
am completely out of luck. Or at least I will be until this becomes one =
of the multifaceted complaints in the anti-trust hearings coming soon to =
a capitol hill near you. And yes, that is a consequence of how the =
protocol has been deployed, but that probably not going to get people =
very far on capitol hill.
>=20
>=20
> The Internet is for everyone. The Internet is for end users.
>=20
> I am really not that interested in who makes the ingredients except to =
the extent that it determines what sort of cake emerges. One of the =
unexpected side effects of Web 2.0 has been that it has greatly =
centralized power in the hands of a tiny number of individuals. =
Individuals who are at best accountable to shareholders, but in the case =
of some of them, a separate share class ensures that they are =
accountable to nobody. In neither case are the people with power =
accountable to end users because they are not even customers, they are =
the product.
>=20
> What I am interested in is the extent to which Internet technologies =
are Technologies of Freedom. The question we need to ask ourselves is =
'does this technology increase end user autonomy or increase their =
reliance on third parties'.

--
Mark Nottingham   https://www.mnot.net/


From nobody Tue Feb 23 22:08:11 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1933A006A; Tue, 23 Feb 2021 22:08:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level: 
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THBYsxzEM8TP; Tue, 23 Feb 2021 22:07:59 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E5C3A0045; Tue, 23 Feb 2021 22:07:59 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id 17so548484pli.10; Tue, 23 Feb 2021 22:07:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=qgUPjmOhW7VIcGJGzalTg+OrDHhdIVM3zhsW8EhB+xA=; b=AII174Yb+BZhN3SoFmNscV7yLKqqwHsul1GW19a/2B3ALzXH6NhULVlWrxNlpt3+P1 JBD8bE+lo/eMPmZdl2Y5kPxfnhLKfi3KG8LNV3FS+y5vlwiCyK5FC0ZkOKOhbZj8TY11 DCIbOKI6qYsIi0d6CUNdi2ENrtE0u4PObg9v30DgHir746Roa8N9DDJ2soUeUrBInHsW VBBZbPy3pu9Hc+RDACOpXRRlQSizxcoMT9gPpiUHhwnU0+D9sxdrzvhkULZ4mQEkf/w3 DbJzhhDBCr6PE9gY4I2DkEN9Bo2MjoOYaRG/NdtepVeyVUatZp+rRyz90kAissBk8cNU D5pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=qgUPjmOhW7VIcGJGzalTg+OrDHhdIVM3zhsW8EhB+xA=; b=WjO98EmCQLZdaYax6j9zCsjjfMGrv+1cCaqhzHDC2621sYM/fMVzwVpDTdmAF181km kZ4+Y4gmFkJvV8viZ8bXTiTYzRBZD/7rNWfk1fQZcLzYRre9gsQ8xddPVe7y07NgGr43 8xKBx0D9hgJh8VcJKHJ33D4yO/rl2ZpLdsWDGdjABALskCu2LJI8SSyoysDh4QBKU10i 3glh1O+QHudeVBU97aa+8jnz4yBTPkdj5xfm5k1hp5hdj0hi6YumAf1QYiKgK9YB3QCK 82P14gXPcWHXjqyouP4dABBFLl+ColkLq9xVWCUBZTrW4vKNeCzWXWwDQ6SztyJDe6XW ickw==
X-Gm-Message-State: AOAM530a30Tcx73a9kWAyNPCsRrwK2UmPqlKD4MYFxL6GCpcWigtjroC oyyWt9kWQAp30BIgn6j35DlqcPqEvlA=
X-Google-Smtp-Source: ABdhPJwq8LI8dNL2UXr2NA5CKG9NqRosXGgGJa6vdiCNuAAah8nbCYARb0ldVQHxCm/0ij/p2RaDCg==
X-Received: by 2002:a17:90a:67ca:: with SMTP id g10mr2864720pjm.28.1614146878269;  Tue, 23 Feb 2021 22:07:58 -0800 (PST)
Received: from TVPC (c-73-158-116-21.hsd1.ca.comcast.net. [73.158.116.21]) by smtp.gmail.com with ESMTPSA id gk14sm7114037pjb.2.2021.02.23.22.07.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 22:07:57 -0800 (PST)
Sender: Larry Masinter 
From: Larry Masinter 
X-Google-Original-From: "Larry Masinter" 
To: "'Phillip Hallam-Baker'" , "'Kathleen Moriarty'" 
Cc: , 
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>   
In-Reply-To: 
Date: Tue, 23 Feb 2021 22:07:56 -0800
Message-ID: <00b901d70a73$65f830c0$31e89240$@acm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01D70A30.57D5B410"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQLT1bdL7pqR2nvaftdkRCfHM2U8nwKGphCgAunXFDgBYaMquwHMl9O4AQMkYBcC8YDuIQGf13e1Axl8PAen4tIfQA==
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 06:08:02 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00BA_01D70A30.57D5B410
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Cogent argument that brings to focus on the  Subject:  topic what seemed =
like a =E2=80=9Cside=E2=80=9D conversation about friendliness of the =
OAUTH wg.=20

=20

=20

From: ietf  On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, February 23, 2021 9:47 PM
To: Kathleen Moriarty 
Cc: ietf@ietf.org; oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the IETF

=20

I am worried by the advice 'use OAUTH' but for a very different reason.

=20

OAUTH and SAML are both attempts to provide a secure authentication =
scheme that works within the very particular and very peculiar =
environment of Web browsers. They are schemes that necessarily involve =
techniques that are rightly regarded as alchemy if not outright =
witchcraft.

=20

That is fine, that is more than fine if you are developing an =
authentication scheme for use within Web browsers (or if you are =
developing whatever SAML and OAUTH are these days, neither was =
originally billed as authentication). But it is completely inappropriate =
to ever suggest let alone demand that anyone use a technology whose =
primary design constraint is to work around the voodoo of Javascript, =
URIs, HTTP cookies etc. etc. in an application where none of those =
legacy issues apply.

=20

One of the big problems of IETF is that a lot of people don't think =
about how to get their scheme deployed and when they do, their plan is =
to tie it to some other group as a boat anchor. Back when we were doing =
DKIM and SPF we had to tell certain DNS folk that the fact that almost =
no DNS Registrars offered customers the ability to specify new RRTypes =
was their problem and was going to remain their problem no matter how =
loudly they tried to complain that it should become our problem.=20

=20

In the case of OAUTH, there is another problem in that OAUTH really =
isn't a very open protocol from the standpoint of the user. I can use my =
Google or my Facebook or my Twitter accounts to log in via OAUTH at a =
large number of sites. But if I want to use any other OAUTH provider I =
am completely out of luck. Or at least I will be until this becomes one =
of the multifaceted complaints in the anti-trust hearings coming soon to =
a capitol hill near you. And yes, that is a consequence of how the =
protocol has been deployed, but that probably not going to get people =
very far on capitol hill.

=20

=20

The Internet is for everyone. The Internet is for end users.

=20

I am really not that interested in who makes the ingredients except to =
the extent that it determines what sort of cake emerges. One of the =
unexpected side effects of Web 2.0 has been that it has greatly =
centralized power in the hands of a tiny number of individuals. =
Individuals who are at best accountable to shareholders, but in the case =
of some of them, a separate share class ensures that they are =
accountable to nobody. In neither case are the people with power =
accountable to end users because they are not even customers, they are =
the product.

=20

What I am interested in is the extent to which Internet technologies are =
Technologies of Freedom. The question we need to ask ourselves is 'does =
this technology increase end user autonomy or increase their reliance on =
third parties'.


------=_NextPart_000_00BA_01D70A30.57D5B410
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Cogent argument that brings to focus on the =
=C2=A0Subject: =C2=A0topic what seemed like a =E2=80=9Cside=E2=80=9D =
conversation about friendliness of the OAUTH wg. 
 
 
From: ietf =
<ietf-bounces@ietf.org> On Behalf Of Phillip =
Hallam-Baker
Sent: Tuesday, February 23, 2021 9:47 =
PM
To: Kathleen Moriarty =
<kathleen.moriarty.ietf@gmail.com>
Cc: ietf@ietf.org; =
oauth@ietf.org
Subject: Re: Diversity and Inclusiveness in the =
IETF
 
I am worried by the =
advice 'use OAUTH' but for a very different =
reason.
 
OAUTH and SAML are =
both attempts to provide a secure authentication scheme that works =
within the very particular and very peculiar environment of Web =
browsers. They are schemes that necessarily involve techniques that are =
rightly regarded as alchemy if not outright =
witchcraft.
 
That is fine, that is =
more than fine if you are developing an authentication scheme for use =
within Web browsers (or if you are developing whatever SAML and OAUTH =
are these days, neither was originally billed as authentication). But it =
is completely inappropriate to ever suggest let alone demand that anyone =
use a technology whose primary design constraint is to work around the =
voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application =
where none of those legacy issues =
apply.
 
One of the big =
problems of IETF is that a lot of people don't think about how to get =
their scheme deployed and when they do, their plan is to tie it to some =
other group as a boat anchor. Back when we were doing DKIM and SPF we =
had to tell certain DNS folk that the fact that almost no DNS Registrars =
offered customers the ability to specify new RRTypes was their problem =
and was going to remain their problem no matter how loudly they tried to =
complain that it should become our =
problem. 
 
In the case of OAUTH, =
there is another problem in that OAUTH really isn't a very open protocol =
from the standpoint of the user. I can use my Google or my Facebook or =
my Twitter accounts to log in via OAUTH at a large number of sites. But =
if I want to use any other OAUTH provider I am completely out of luck. =
Or at least I will be until this becomes one of the multifaceted =
complaints in the anti-trust hearings coming soon to a capitol hill near =
you. And yes, that is a consequence of how the protocol has been =
deployed, but that probably not going to get people very far on capitol =
hill.
 
 
The Internet is for =
everyone. The Internet is for end =
users.
 
I am really not that =
interested in who makes the ingredients except to the extent that it =
determines what sort of cake emerges. One of the unexpected side effects =
of Web 2.0 has been that it has greatly centralized power in the hands =
of a tiny number of individuals. Individuals who are at best accountable =
to shareholders, but in the case of some of them, a separate share class =
ensures that they are accountable to nobody. In neither case are the =
people with power accountable to end users because they are not even =
customers, they are the product.
 
What I am interested =
in is the extent to which Internet technologies are Technologies of =
Freedom. The question we need to ask ourselves is 'does this technology =
increase end user autonomy or increase their reliance on third =
parties'.

------=_NextPart_000_00BA_01D70A30.57D5B410--


From nobody Tue Feb 23 22:26:39 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C103A09A5 for ; Tue, 23 Feb 2021 22:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtoy-9kJHYyH for ; Tue, 23 Feb 2021 22:26:35 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0623A098D for ; Tue, 23 Feb 2021 22:26:35 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id s3so552583qvn.7 for ; Tue, 23 Feb 2021 22:26:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=sFo4SbvJUmC/7TuwinRlABAIH8ZwrdZmI5xsc0nvZl4=; b=aZKC8g70VYDoObuppEX+yBa+Ffr7Qnvc+AeR/QnFw18mwLpfTum6otvxQ51AA9MPvD 3RC+wtE+c7ZsZrpchqRXtYIHHoBeA8YXi8iJ9Ze6v/aMQMIbaiYDJWxNjylvfIxp5Olc M5BUW7LWLeKTgvv4YYswcKHbxIG4bZCs7vBJDwLx7k+KyH2y+Z7Owr5Gw/xG0c6f6Ahh ++t9b9NvzOcI0oN64R1g/M8yVQifxtADihw4hmyOiYqPMXHcJRSGUOW7mtkOXgY8Gy/l miKNPWUFPGYmNdXmEUsDF3WK8m52cbhCmsnUnbtF8yiRfhJexac8EmAqOs/CDtC+PqpK 7FdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=sFo4SbvJUmC/7TuwinRlABAIH8ZwrdZmI5xsc0nvZl4=; b=F5FwJUgfC+OfuOp+DdEOJHkIhDsWvKj37xn/f+YOV6NwqFBDVG7fBoeKv+Ij5J1dBZ bTQkLHoxBfYYgvo2j0TSdLngjzwqudNeAtisDThAZahOYmDquL9nxYlL4dAKQaalgFzL F5gMXfd4OjQXUy9n18UPBYn6dN/XKkDKYQWGIPJ7EgK3HeA5TFvnCChnfz30Ysal5y/i ziOuQpTI86nYQNIcAi9Rppljn1tceSjFNZ3NmmgqDE2nvx8Y9lD7zFnizN2rdJhcCHH0 TkrgMnFdLqSXSrv2hoKm8QgfO0pPsq2adWvxHKcEHUOAB5s0VGiqnBqYbnK6mCXVCg1q PLEQ==
X-Gm-Message-State: AOAM533kDxVewMSYyFskRiC/1/sposG33Fl57whIOtLjPmm67VRdKNhe G3cPr1ud6wOvvgLbAejMW9rqgd1ME4ZFXA==
X-Google-Smtp-Source: ABdhPJwNzNoernNjGqHYPgZ8TeaPy3JHdDRdsLoZ8nKXaC8a04YmMUxwIN2KiqebY426geF/pWOyDg==
X-Received: by 2002:a0c:fc4b:: with SMTP id w11mr16552821qvp.41.1614147994689;  Tue, 23 Feb 2021 22:26:34 -0800 (PST)
Received: from [10.62.107.212] (mobile-166-172-63-24.mycingular.net. [166.172.63.24]) by smtp.gmail.com with ESMTPSA id i6sm719245qti.30.2021.02.23.22.26.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Feb 2021 22:26:33 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-D143320B-BF0C-47DD-9687-03FA1725EE4A
Content-Transfer-Encoding: 7bit
From: Jim Manico 
Mime-Version: 1.0 (1.0)
Date: Wed, 24 Feb 2021 01:26:32 -0500
Message-Id: 
References: 
Cc: Kathleen Moriarty , ietf@ietf.org, oauth@ietf.org
In-Reply-To: 
To: Phillip Hallam-Baker 
X-Mailer: iPhone Mail (18D52)
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 06:26:38 -0000

--Apple-Mail-D143320B-BF0C-47DD-9687-03FA1725EE4A
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think it=E2=80=99s important to point out that OAuth is not an authenticat=
ion protocol. It=E2=80=99s for delegation. OAuth is one of the most mis-used=
 protocols on the modern web. If you really want to support end users, a goo=
d place to start is to make it clear to developers what OAuth is really for s=
o secure solutions are built as opposed to the dumpster fire that OAuth solu=
tions have become today.

Regards,
--
Jim Manico
@Manicode
Secure Coding Education

> On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker =
 wrote:
>=20
> =EF=BB=BF
> I am worried by the advice 'use OAUTH' but for a very different reason.
>=20
> OAUTH and SAML are both attempts to provide a secure authentication scheme=
 that works within the very particular and very peculiar environment of Web b=
rowsers. They are schemes that necessarily involve techniques that are right=
ly regarded as alchemy if not outright witchcraft.
>=20
> That is fine, that is more than fine if you are developing an authenticati=
on scheme for use within Web browsers (or if you are developing whatever SAM=
L and OAUTH are these days, neither was originally billed as authentication)=
. But it is completely inappropriate to ever suggest let alone demand that a=
nyone use a technology whose primary design constraint is to work around the=
 voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where n=
one of those legacy issues apply.
>=20
> One of the big problems of IETF is that a lot of people don't think about h=
ow to get their scheme deployed and when they do, their plan is to tie it to=
 some other group as a boat anchor. Back when we were doing DKIM and SPF we h=
ad to tell certain DNS folk that the fact that almost no DNS Registrars offe=
red customers the ability to specify new RRTypes was their problem and was g=
oing to remain their problem no matter how loudly they tried to complain tha=
t it should become our problem.=20
>=20
> In the case of OAUTH, there is another problem in that OAUTH really isn't a=
 very open protocol from the standpoint of the user. I can use my Google or m=
y Facebook or my Twitter accounts to log in via OAUTH at a large number of s=
ites. But if I want to use any other OAUTH provider I am completely out of l=
uck. Or at least I will be until this becomes one of the multifaceted compla=
ints in the anti-trust hearings coming soon to a capitol hill near you. And y=
es, that is a consequence of how the protocol has been deployed, but that pr=
obably not going to get people very far on capitol hill.
>=20
>=20
> The Internet is for everyone. The Internet is for end users.
>=20
> I am really not that interested in who makes the ingredients except to the=
 extent that it determines what sort of cake emerges. One of the unexpected s=
ide effects of Web 2.0 has been that it has greatly centralized power in the=
 hands of a tiny number of individuals. Individuals who are at best accounta=
ble to shareholders, but in the case of some of them, a separate share class=
 ensures that they are accountable to nobody. In neither case are the people=
 with power accountable to end users because they are not even customers, th=
ey are the product.
>=20
> What I am interested in is the extent to which Internet technologies are T=
echnologies of Freedom. The question we need to ask ourselves is 'does this t=
echnology increase end user autonomy or increase their reliance on third par=
ties'.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-D143320B-BF0C-47DD-9687-03FA1725EE4A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think it=E2=80=99s important to point out=
 that OAuth is not an authentication protocol. It=E2=80=99s for delegation. O=
Auth is one of the most mis-used protocols on the modern web. If you really w=
ant to support end users, a good place to start is to make it clear to devel=
opers what OAuth is really for so secure solutions are built as opposed to t=
he dumpster fire that OAuth solutions have become today.

Regards,
=

--
Jim Manico
@Manicode
=
Secure Coding Education

On Feb 24, 2021, at 12:48 AM, Phillip Hallam-Baker <phill@hallambak=
er.com> wrote:

=EF=BB=BF
I am worried by the advice 'use OAUTH' but for a very differ=
ent reason.

=

OAUTH and SAML a=
re both attempts to provide a secure authentication scheme that works within=
 the very particular and very peculiar environment of Web browsers. They are=
 schemes that necessarily involve techniques that are rightly regarded as al=
chemy if not outright witchcraft.

That is fine, that is more than fine if you are developing an authent=
ication scheme for use within Web browsers (or if you are developing whateve=
r SAML and OAUTH are these days, neither was originally billed as authentica=
tion). But it is completely inappropriate to ever suggest let alone demand t=
hat anyone use a technology whose primary design constraint is to work aroun=
d the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application w=
here none of those legacy issues apply.

One of the big problems of IETF is that a lot of people don't t=
hink about how to get their scheme deployed and when they do, their plan is t=
o tie it to some other group as a boat anchor. Back when we were doing DKIM a=
nd SPF we had to tell certain DNS folk that the fact that almost no DNS Regi=
strars offered customers the ability to specify new RRTypes was their proble=
m and was going to remain their problem no matter how loudly they tried to c=
omplain that it should become our problem. 

In the case of OAUTH, there is another problem in that=
 OAUTH really isn't a very open protocol from the standpoint of the user. I c=
an use my Google or my Facebook or my Twitter accounts to log in via OAUTH a=
t a large number of sites. But if I want to use any other OAUTH provider I a=
m completely out of luck. Or at least I will be until this becomes one of th=
e multifaceted complaints in the anti-trust hearings coming soon to a capito=
l hill near you. And yes, that is a consequence of how the protocol has been=
 deployed, but that probably not going to get people very far on capitol hil=
l.


The Internet is for everyone. The I=
nternet is for end users.

I=
 am really not that interested in who makes the ingredients except to the ex=
tent that it determines what sort of cake emerges. One of the unexpected sid=
e effects of Web 2.0 has been that it has greatly centralized power in the h=
ands of a tiny number of individuals. Individuals who are at best accountabl=
e to shareholders, but in the case of some of them, a separate share class e=
nsures that they are accountable to nobody. In neither case are the people w=
ith power accountable to end users because they are not even customers, they=
 are the product.

What I am=
 interested in is the extent to which Internet technologies are Technologies=
 of Freedom. The question we need to ask ourselves is 'does this technology i=
ncrease end user autonomy or increase their reliance on third parties'.



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

--Apple-Mail-D143320B-BF0C-47DD-9687-03FA1725EE4A--


From nobody Tue Feb 23 23:07:29 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604DF3A0CB1; Tue, 23 Feb 2021 23:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=CaxhQC/t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=glCYN5D+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_EKMyfIguTf; Tue, 23 Feb 2021 23:07:15 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0B33A0CAF; Tue, 23 Feb 2021 23:07:15 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id BBED2C41; Wed, 24 Feb 2021 02:07:13 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 02:07:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=b0Vi SHARCaTV/mbrQY7acH01yIQkqnonmsMI51x8V6I=; b=CaxhQC/tjr/WOLrewKlx jlcGXvl4D6U2O+JxlET8aNXu+9SUCo7yyY0CdAFX1wwHM9c5PTpA30DfZlDpoHnV iC74cwKF2M8BvTPRUScjspEstD+/MtqbIi0L0EIxYpgicRH1RFxVUTzMpG6Qhsh7 m3IknIqN0Ts5TocK4qXRrm+bHMhJt+HInCbW7NnuVq58bMHuLoOFgj6F3v1nmymo +rqyN7zieyelu83NN3lKu4T3RhfWqBFbsCQgeK+wKf45NHmOx8XQyVQCiB5/WrAI TwOvQD5G3D0eTOsyu+1LhF6D8R9mNxN5oOrd40LmsVENisL0jIS643FLovjKE/Wj rA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=b0ViSH ARCaTV/mbrQY7acH01yIQkqnonmsMI51x8V6I=; b=glCYN5D+V+kOg461vzIhMs m8YYWGMfhRvT6EaSdMvGdDi6zAyRrBTU3MvRLQHmZfiTBT4TQIjl5DpoVN9jQqEt 79k+fY8nYxPfYijsVVielnwVljxkdE9Wo5ZBD1uJM5o7OsRhVTv/y09GHQaA0x0b j0yKV4pg/F9kp/wk2jKRCIZ/GcrVm4vgG9J8stK17ybIA6f3zlTzeVC1soFnOnDN M+WVk/Aa+WGwJz7FoTcncNSMHi2UV1UGVWs3Ia3VlOTCexXDuMPHwsys3VjR9QfI pYX6FkeAxzQxy3InQKOXExHVezP/Z5hTtbe0ZIzM30UQaWI/pq6FRxky4z8Or9fg ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeigdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeduffdvjeelgffhveelieduiefgfeehudehlefhueefledv ffefueeikeduheektdenucffohhmrghinhepfihikhhiphgvughirgdrohhrghdprghrtg hhihhvvgdrohhrghdphhhuvghnihhvvghrshgvrdgtohhmnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B048A3605A4; Wed, 24 Feb 2021 02:07:12 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:  
Date: Wed, 24 Feb 2021 18:06:52 +1100
From: "Bron Gondwana" 
To: "Jim Manico" , "Phillip Hallam-Baker" 
Cc: ietf@ietf.org, "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=27b38bd14ad548058a080b1be730e105
Archived-At: 
Subject: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 07:07:18 -0000

--27b38bd14ad548058a080b1be730e105
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 24, 2021, at 17:26, Jim Manico wrote:
> I think it=E2=80=99s important to point out that OAuth is not an authe=
ntication protocol. It=E2=80=99s for delegation. OAuth is one of the mos=
t mis-used protocols on the modern web. If you really want to support en=
d users, a good place to start is to make it clear to developers what OA=
uth is really for so secure solutions are built as opposed to the dumpst=
er fire that OAuth solutions have become today.

https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does

Which suggests that if the OAuth solutions deployed today are dumpster f=
ires, then ... well, that's what OAuth 2 does.

My biggest problem with OAuth as an outsider is that it doesn't solve th=
e NxM problem.  You can't build a client which can OAuth against any arb=
itrary OAuth service that provides a standard protocol, because you need=
 to get an API key for your particular application from each service pro=
vider.  This just doesn't scale, which is a large part of Phillip's comp=
laint as well.

Of course, I came into the IETF having already read https://web.archive.=
org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-and-the-r=
oad-to-hell/ - which was one of the things which made me wary of the IET=
F in the first place, and keen to not let everything I touched get over-=
complicated.

Bron.

--=20
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--27b38bd14ad548058a080b1be730e105
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Wed, Feb 24, 2021, at=
 17:26, Jim Manico wrote:
I think it=E2=80=99s important to point out that OAuth is=
 not an authentication protocol. It=E2=80=99s for delegation. OAuth is o=
ne of the most mis-used protocols on the modern web. If you really want =
to support end users, a good place to start is to make it clear to devel=
opers what OAuth is really for so secure solutions are built as opposed =
to the dumpster fire that OAuth solutions have become today.

=

Which suggests that if the O=
Auth solutions deployed today are dumpster fires, then ... well, that's =
what OAuth 2 does.

=

My biggest problem with OAuth as an ou=
tsider is that it doesn't solve the NxM problem.  You can't build a=
 client which can OAuth against any arbitrary OAuth service that provide=
s a standard protocol, because you need to get an API key for your parti=
cular application from each service provider.  This just doesn't sc=
ale, which is a large part of Phillip's complaint as well.

Of course, I came into the IETF having already read https://web.archive.org/web/20120731155632/ht=
tp://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ - which =
was one of the things which made me wary of the IETF in the first place,=
 and keen to not let everything I touched get over-complicated.

Bron.

=

-- 
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


=

--27b38bd14ad548058a080b1be730e105--


From nobody Wed Feb 24 01:09:33 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B93A1232 for ; Wed, 24 Feb 2021 01:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.1
X-Spam-Level: *
X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RAND_MKTG_HEADER=2.999, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=mJqF8S0N; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=mJqF8S0N
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ6154wTxLrK for ; Wed, 24 Feb 2021 01:09:28 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80042.outbound.protection.outlook.com [40.107.8.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FB63A1230 for ; Wed, 24 Feb 2021 01:09:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0/nOFX/WPVK2YQcReG99X/LEn7mJ8XEG2OTlWv8BA9M=; b=mJqF8S0NoDoMwyQpyrzJa+WB6RT2Mu+Kb/oaSJpCVO1rWdXPdiMjFXTf3WsnXnrMc0pEoU8g+tb3UYelc7a/+kAKvnENZd8QkDg1xvEiYbnIK4cvQC/RcbA3me+Dm3sbQJaNdJFegEBgcqE4x7OSzkLYLNZb8rCb1Ud/1+Lm9w8=
Received: from AM6PR0502CA0047.eurprd05.prod.outlook.com (2603:10a6:20b:56::24) by AM0PR08MB3971.eurprd08.prod.outlook.com (2603:10a6:208:132::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.32; Wed, 24 Feb 2021 09:09:23 +0000
Received: from AM5EUR03FT033.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:56:cafe::e7) by AM6PR0502CA0047.outlook.office365.com (2603:10a6:20b:56::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Wed, 24 Feb 2021 09:09:23 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT033.mail.protection.outlook.com (10.152.16.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Wed, 24 Feb 2021 09:09:23 +0000
Received: ("Tessian outbound edf60a9f3ac0:v71"); Wed, 24 Feb 2021 09:09:23 +0000
X-CR-MTA-TID: 64aa7808
Received: from 00c09f170cb1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8C4FDC24-EF68-4201-8800-8487A4799701.1;  Wed, 24 Feb 2021 09:09:18 +0000
Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 00c09f170cb1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 24 Feb 2021 09:09:18 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hxNhS9mbhymWJyUTBt9QVWAP/ACmFE+QTRKqgNcWYUasi51bmd/ZF9VNEizRdvhklv1iyCBI+2sjnnltEpGRtm9xq+kWOovIa4OtfYHm8GQHJceQOqLiETtqIX6G/MDINdcFH6EU5I04d0VQLlqB+CkRL7acvYkDpUOXGW9kufdCAZxWGTATK/cQ8PPSOzS6OzbQPo2yLvS7A4iokaSRmuANDgJqQ+LqvjrXJvd4kdQdUB+Iao3ENGiKayzKri4m7nLfYbaRK/3JEX1MzH86xJ6r/62QN+nr4TUY/SifXHsg93Z6yZ7omUeYqPBDSt1MlIb9A/6EPoWMEAJIQy4CMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0/nOFX/WPVK2YQcReG99X/LEn7mJ8XEG2OTlWv8BA9M=; b=fjU53FSj6ZhzV83/3ixMNjrwKYKZDYF+bVDeAKzeuQv9Bk02esMRnEvIpS+VOCadrsiA5Gki4lE/QfPa0iR8c+iPeXeA21/mfy8rveIEabwI6YB19TnV9D4Mi5L5EVW7dlbBm/kQoowG4aUkqCvnqzaEvihdgTbwCpVV//9H1fCo55/VkTT1zj5u2o4vv/wqHlVUireRje6bbRU8DO6TElOrR8c0G722sMsBFgZF6fbqBwvU/tL+EKj3LrHaj6eQmSOel0/9qilagXie/oadqbADq4YkxkI3I4vxupm+gukshGm2LLC4YAYx0M53FQcCnCthhZeQ4zn6GilwTBiVmQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;  s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0/nOFX/WPVK2YQcReG99X/LEn7mJ8XEG2OTlWv8BA9M=; b=mJqF8S0NoDoMwyQpyrzJa+WB6RT2Mu+Kb/oaSJpCVO1rWdXPdiMjFXTf3WsnXnrMc0pEoU8g+tb3UYelc7a/+kAKvnENZd8QkDg1xvEiYbnIK4cvQC/RcbA3me+Dm3sbQJaNdJFegEBgcqE4x7OSzkLYLNZb8rCb1Ud/1+Lm9w8=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM4PR0802MB2339.eurprd08.prod.outlook.com (2603:10a6:200:64::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.31; Wed, 24 Feb 2021 09:09:11 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::7484:8c2b:e664:648]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::7484:8c2b:e664:648%7]) with mapi id 15.20.3868.033; Wed, 24 Feb 2021 09:09:11 +0000
From: Hannes Tschofenig 
To: Phillip Hallam-Baker 
CC: "oauth@ietf.org" , Kathleen Moriarty 
Thread-Topic: Diversity and Inclusiveness in the IETF
Thread-Index: AQHXCXgbtlRdrPa6OEShU5hVFqdRTqplIz0AgABqRRCAABPPgIAADfGAgAABowCAABzOAIAADk2AgADyA4CAAB4IYA==
Date: Wed, 24 Feb 2021 09:09:11 +0000
Message-ID: 
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ts-tracking-id: 165A7427B810AF4C929689B7AC7C3E44.0
x-checkrecipientchecked: true
Authentication-Results-Original: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [80.92.115.86]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 5b3f6b49-a286-4891-73cc-08d8d8a3e0aa
x-ms-traffictypediagnostic: AM4PR0802MB2339:|AM0PR08MB3971:
X-Microsoft-Antispam-PRVS: 
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: i1p5MIYNb/+7abhPr5UizPmleF2www1u6WVZdN+BJYM1TjmqlrMkKv3H7bFIfj6zDMPUDqg9sh8Q2nJ4jR4tzxM5SC0YcSCv0qFHFXI+2hDG1QpUETwXQ4ajTLLUE0c9G7SOWPks3mcxzV28Ia+3xFsiAtQXa+zSP5ugvtZqPv70GO2N9RbPRvpRvvpy6PSZFC8xRfbfZ7LPLmoMcEH4NS9uGfmBnw02bbbA+4hk72ylg7JOFHhd+I9VtA+zMizjkWhf26Awk3R1ED/6eNG3/NekY1kj5olZukcOobuNtGFEmMniVFcHclG7fcFqrYG7I8f/OteKzNO2hpJRkIwsZCXwByTs3yBF1z5v59BefEHAqa8N1QZ7W2GkUq1WCi3pzEvfAoxH++nofph7clESIQqAy8i2KBGVUI1ceQGmaaKp4mzHpIZuhj8pSnCKDINTskvmsfQydmFnZjGHdSX5cd8IId5glC2/8ubM7th0ilY1mLHLSN1l7YSPXmadp6B3iAVRt4ZWieKr1PBVOKbW0A==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(39860400002)(136003)(346002)(76116006)(86362001)(53546011)(8676002)(8936002)(2906002)(5660300002)(6916009)(66946007)(6506007)(9326002)(52536014)(316002)(83380400001)(54906003)(478600001)(9686003)(186003)(71200400001)(66574015)(66446008)(55016002)(66476007)(64756008)(66556008)(4326008)(26005)(7696005)(33656002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?a0NsMXlxNEo1TXhqOHlUMjRsWUR4b1d2R2RKSy9zYkduM0NFdHJqS25vR3No?= =?utf-8?B?VEtyK2JiWW9kQlVBSlllRlhQNTUxMXd2STdxU1hPT25HUHcwVXgvV2dpZ1pk?= =?utf-8?B?ejRqTHpPdUp1RTFwZVAzU3gyVTdxcWRtMjFRd0QwRDNrSmJzdEdzNHBUOSs4?= =?utf-8?B?K3ZLdWNRR1FYcXVEbmF1S0lFL2dwYnZvRHpQMXpMbkcwbktEcS9BbHB0ZndR?= =?utf-8?B?WVNuUi90NHRRUmk2L1lxZDhCZHA4WFZaQUVLRkYvc2lUK3BqVStBUzUrT1pl?= =?utf-8?B?V3dKRUpuWHNzY2M2M3F1UENUYy83cUNHcmpnWno5RS9weTV4RlN0TnVkdTN6?= =?utf-8?B?OXdzZ1BIM1BrZExXYVA1TUI0S1VLeEZMd0pxdXp3aCt5bHpSOFc3VVZIUExN?= =?utf-8?B?RnQ2L0Q5S2JRUDdTZXhRVHNQTWsweGFiR0p6VkxkcnhPTitmNzF0YzUvMGVB?= =?utf-8?B?R2VHcjdGQWNrUzcvVUZNNHZSWkxwelNneERDMGtXY3JpaEcrZzlXS3d3VUZU?= =?utf-8?B?S213SGMrY29rNFpEUmIzRlI5VzV4UkFGODdlMUVHaTFDMTFKUE4vLy93bFhU?= =?utf-8?B?cllQa0s0aE1sM2FnYzdYUXRvWnY4cm8xLzk4aUE4UmRQZDJyR201cGFrMjBS?= =?utf-8?B?QlA2WktnejJ3YS9XcmFob2dkbHZTZ1FtQ1VyL0dwM3BiYk15WmRxT1BwQjZE?= =?utf-8?B?cVk1aE42K0cxYWVwOFAxYjd1Tlo5V3FlckxBRjViUHh4TloyTXpUdWpBSzZ4?= =?utf-8?B?dzRoUzJpYU00TlRub21zZi9EdUZBMVE2ajVyakRBV1dkOUE4MSt4cEVWS2Rw?= =?utf-8?B?WVNBczlGL09PamhDZzVuWjdHSWpwdk1xcFNpdTNWUmdaNDBTWFhibzBtZmt0?= =?utf-8?B?dHBnWCs2R0E1RjlSUDh4b0JtTzdUWExqNkNnY3pKMCtQRzdjcTRNaE4ydlhp?= =?utf-8?B?WDZ2RUpNZWVuMzJzUjVKeCtmTlZPNFJWU1hTQlNKWnFnazRRRnhXN3ZZN0JS?= =?utf-8?B?aGpUUHNYZHUza3dmKzFjOGx5Mnoxb01wRDRWT256OERJWUJyN1U5RE05WHI3?= =?utf-8?B?MXFZL2xkTUI5UkowZEtkV3JmUW5OMkQ2S2VLWnlqbmkrck93VUU3ODJFcWEy?= =?utf-8?B?bkJNR2ZrdTRId0lEZ3F4MDFJYWRoSm9PQ0c3ZTRqVGU5QU1jVlArQ0NsNDZi?= =?utf-8?B?NTk4Znl6enFxOTNIaXJidTBwSnJ2c3lqSjFPZy9QUHJGTVBGaEVnQ2txakMy?= =?utf-8?B?V3BsZmVDQmwxYnUzOExnNFlpcnQ5akp2MXlrMVZ2bGY3S0xvOElRWVZ1cC84?= =?utf-8?B?UE9JL2VWNTNBTS9MRWdmRkJ2Rml6QmlmUTNYcGVMNnlwUWF5MVEwbGRBRUE3?= =?utf-8?B?Z2ZPcXlCZnpIbVo2VkFSclBKamxuamVHOEkxMVFNY2xUZXFZaS9aaXpQS2Nk?= =?utf-8?B?ajdURzFMUlBpdDNCVERkUXc3c2JpNFBkN0k3QTlEUWp2RENYTnVqWkdyN3RY?= =?utf-8?B?ckhvMWErQkhzMkFoV2pVLy94TFZzUXY5UDcvd2hiN0x2QWRjUGFuV2VRMHFi?= =?utf-8?B?S3JqVU5tUFdHNFhiUjdKbkdveXNMWVpkTit5c2ZJdnJqZ2dwOHpmUldtc011?= =?utf-8?B?QVJRdUhHRk5lMGkyUUEyUXk3RStVQ2RyOWxhYTA2U0ZwTTZLdWJ0TUNUV2I4?= =?utf-8?B?a0c1WVU4YkpSVytGMGUzSVU1VWhqUEJWNVlUaFM4NW5mbGg4NEtFRThLd1lR?= =?utf-8?Q?EYLLPM0Fhioh+fe7SfGqaTLaToEuTxf4i5dj3ww?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37168F0895CC638ED5222E65FA9F9AM0PR08MB3716eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2339
Original-Authentication-Results: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT033.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 1de63107-9f37-4108-95e5-08d8d8a3d989
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: A5A93rmvJWd79udvEguiKvIr7rTPBM7Ljfq2zKraf+cpuaVPSa5/KlGyCH0J1OBarQzReYU1lMeZxQjDSUQ+/JRDQ23cXaIaMjwThqr9x0iry9ReyoaCrPhrzn5FwXymQqbqRzo5DNK46SGnX33L/jwrCWnoOXnZ0QR4DdUvYLiFdZsl5csXQk/r2X7/xVQ/oc67hKPPH8fCpxGiORp867foz1BYErmMhOA9Z40TUJouWS5aFoh4y7G3/msAos7DYg95c6OfRbqLG5rLzJhiLPMxauNdjiaUBM0pdK7VrP9wCUg+WqJaMwMh+XijeSuXTN0E7i88mmiKWtXXVwZa+N7J9Yt1buB6khQlDXTSrCer1qRHngwmHbI/bjrhQV6aBcC6DfzUKKrkDtvOnMTNdxbJUow9AvpfFyW/S+ArJdbKDTs5aacVcvM2Z3ANcjhnZVomUjerApNd8GhZDbz5Mi+fOpULgEOSb+UAIRAt5YndICY1f4CB/yaRTozKA/87UPsYpb6YQ0i9pWlYBDooKHh5KCblCQmmoQLifR5IcB3+rxMy8otsr14uPA3kjIA8Z3nGPbw0rIwk2B9fIKzhfPBIckRmRK6nGm5NIkhI0yCwchq0nMhvgvRAesLSBiXesqTrSM+FQNMet1bGhNJWIhHHMX2sJW7KPKhy52DdAdA=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:;  IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com;  PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(396003)(136003)(46966006)(36840700001)(83380400001)(33656002)(86362001)(8936002)(26005)(107886003)(8676002)(336012)(82740400003)(36860700001)(70206006)(47076005)(30864003)(2906002)(54906003)(316002)(9326002)(55016002)(4326008)(186003)(53546011)(66574015)(6506007)(478600001)(81166007)(33964004)(7696005)(9686003)(356005)(82310400003)(5660300002)(6862004)(52536014)(70586007); DIR:OUT; SFP:1101; 
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2021 09:09:23.2711 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3f6b49-a286-4891-73cc-08d8d8a3e0aa
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123];  Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT033.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3971
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 09:09:31 -0000

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

SGkgUGhpbCwNCg0KSSBhbSBtb3ZpbmcgdGhpcyB0byB0aGUgT0F1dGggZ3JvdXAgdG8gYXZvaWQg
Y29uZnVzaW5nIHRoZSBJRVRGIGxpc3QgYW55IGZ1cnRoZXIuDQoNClNlZSBteSBmZWVkYmFjayBi
ZWxvdy4NCg0KRnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg
UGhpbGxpcCBIYWxsYW0tQmFrZXINClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjQsIDIwMjEg
Njo0NyBBTQ0KVG86IEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt
YWlsLmNvbT4NCkNjOiBpZXRmQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IERpdmVyc2l0eSBhbmQgSW5jbHVzaXZlbmVzcyBpbiB0aGUgSUVURg0KDQpJIGFtIHdvcnJpZWQg
YnkgdGhlIGFkdmljZSAndXNlIE9BVVRIJyBidXQgZm9yIGEgdmVyeSBkaWZmZXJlbnQgcmVhc29u
Lg0KDQpPQVVUSCBhbmQgU0FNTCBhcmUgYm90aCBhdHRlbXB0cyB0byBwcm92aWRlIGEgc2VjdXJl
IGF1dGhlbnRpY2F0aW9uIHNjaGVtZSB0aGF0IHdvcmtzIHdpdGhpbiB0aGUgdmVyeSBwYXJ0aWN1
bGFyIGFuZCB2ZXJ5IHBlY3VsaWFyIGVudmlyb25tZW50IG9mIFdlYiBicm93c2Vycy4gVGhleSBh
cmUgc2NoZW1lcyB0aGF0IG5lY2Vzc2FyaWx5IGludm9sdmUgdGVjaG5pcXVlcyB0aGF0IGFyZSBy
aWdodGx5IHJlZ2FyZGVkIGFzIGFsY2hlbXkgaWYgbm90IG91dHJpZ2h0IHdpdGNoY3JhZnQuDQoN
CltIYW5uZXNdIE9BdXRoIGFuZCBTQU1MIHdlcmUgaW5pdGlhbGx5IGRldmVsb3BlZCBmb3IgdGhl
IFdlYiBiZWNhdXNlIHRoZSB3ZWIgaXMgYW4gaW1wb3J0YW50IGRlcGxveW1lbnQgdXNlIGNhc2Uu
IEJvdGggcHJvdG9jb2xzIGhhZCBhIHZlcnkgZGlmZmVyZW50IGhpc3RvcnkgYW5kIGFsc28gZGlm
ZmVyZW50IHVzZSBjYXNlcy4gT0F1dGggaXMgZm9yIGRlbGVnYXRlZCBhY2Nlc3MgYW5kIFNBTUwg
d2FzIGRldmVsb3BlZCBhcyBhIFdlYlNTTyBzb2x1dGlvbi4gT0F1dGggYW5kIFNBTUwgd2VyZSBs
YXRlciBleHRlbmRlZCB0byBvdGhlciBlbnZpcm9ubWVudHMgdG9vLiBJbiBjYXNlIG9mIE9BdXRo
IHlvdSBjYW4gZmluZCBzb21lIG9mIHRoaXMgaW5mbyBpbiBvdXIgZG9jdW1lbnRzLCBzdWNoIGFz
IHRoZSBPQXV0aCAyLjAgZm9yIG5hdGl2ZSBhcHBzLg0KDQpUaGF0IGlzIGZpbmUsIHRoYXQgaXMg
bW9yZSB0aGFuIGZpbmUgaWYgeW91IGFyZSBkZXZlbG9waW5nIGFuIGF1dGhlbnRpY2F0aW9uIHNj
aGVtZSBmb3IgdXNlIHdpdGhpbiBXZWIgYnJvd3NlcnMgKG9yIGlmIHlvdSBhcmUgZGV2ZWxvcGlu
ZyB3aGF0ZXZlciBTQU1MIGFuZCBPQVVUSCBhcmUgdGhlc2UgZGF5cywgbmVpdGhlciB3YXMgb3Jp
Z2luYWxseSBiaWxsZWQgYXMgYXV0aGVudGljYXRpb24pLg0KDQpbSGFubmVzXSBPQXV0aCBpcyBu
b3QgYW4gYXV0aGVudGljYXRpb24gc2NoZW1lLCBwYXJ0aWN1bGFybHkgd2hlbiByZWZlcnJpbmcg
dG8gdXNlcnMuIEl0IGlzIGV4cGxpY2l0bHkgdGhlIGludGVudGlvbiB0byBrZWVwIHRoZSB1c2Vy
IGF1dGhlbnRpY2F0aW9uIHBhcnQgb3V0c2lkZSBPQXV0aCwgd2hpY2ggYWxsb3dzIHVzIHRvIHVz
ZSB0aGUgbW9zdCBtb2Rlcm4gdXNlciBhdXRoZW50aWNhdGlvbiB0ZWNobm9sb2d5IGF2YWlsYWJs
ZSB3aXRob3V0IGhhdmluZyB0byB0b3VjaCBPQXV0aC4NCg0KQnV0IGl0IGlzIGNvbXBsZXRlbHkg
aW5hcHByb3ByaWF0ZSB0byBldmVyIHN1Z2dlc3QgbGV0IGFsb25lIGRlbWFuZCB0aGF0IGFueW9u
ZSB1c2UgYSB0ZWNobm9sb2d5IHdob3NlIHByaW1hcnkgZGVzaWduIGNvbnN0cmFpbnQgaXMgdG8g
d29yayBhcm91bmQgdGhlIHZvb2RvbyBvZiBKYXZhc2NyaXB0LCBVUklzLCBIVFRQIGNvb2tpZXMg
ZXRjLiBldGMuIGluIGFuIGFwcGxpY2F0aW9uIHdoZXJlIG5vbmUgb2YgdGhvc2UgbGVnYWN5IGlz
c3VlcyBhcHBseS4NCg0KW0hhbm5lc10gSXQgaXMgZGlmZmljdWx0IHRvIGNvbW1lbnQgb24gdGhp
cyBiZWNhdXNlIEkgZG9u4oCZdCBrbm93IHRoZSBjb250ZXh0LiBNYXliZSBPQXV0aCB3YXMgYSBm
aW5lIGNob2ljZSBhbmQgbWF5YmUgaXQgd2FzbuKAmXQuIEkgZG9u4oCZdCBrbm93LiBXZSBhbGwg
YWdyZWUgdGhhdCBPQXV0aCBpcyBub3QgZ29pbmcgdG8gYmUgdGhlIGFuc3dlciB0byBldmVyeSBx
dWVzdGlvbi4NCg0KT25lIG9mIHRoZSBiaWcgcHJvYmxlbXMgb2YgSUVURiBpcyB0aGF0IGEgbG90
IG9mIHBlb3BsZSBkb24ndCB0aGluayBhYm91dCBob3cgdG8gZ2V0IHRoZWlyIHNjaGVtZSBkZXBs
b3llZCBhbmQgd2hlbiB0aGV5IGRvLCB0aGVpciBwbGFuIGlzIHRvIHRpZSBpdCB0byBzb21lIG90
aGVyIGdyb3VwIGFzIGEgYm9hdCBhbmNob3IuDQoNCltIYW5uZXNdIEluIGdlbmVyYWwsIHN0YW5k
aW5nIG9uIHRoZSBzaG91bGRlcnMgb2YgZ2lhbnRzIGlzIG5vdCBhIGJhZCBhcHByb2FjaC4gQ2hh
bmdlcyBhcmUgdGhhdCB0aGVyZSBpcyBhIHBvdGVudGlhbCBmb3IgcmUtdXNlLiBPQXV0aCBhbHNv
IHdhc27igJl0IHByb2R1Y2VkIGluIGEgdmFjdXVtIGVpdGhlci4gV2UgdXNlIEpTT04gYXMgYW4g
ZW5jb2RpbmcgZm9yIHRoZSBhY2Nlc3MgdG9rZW5zIHdpdGggdGhlIEpXVCB3aGVuIHRoZSB3b3Jr
IGluIHRoZSBKT1NFIGdyb3VwIHdhcyBzdGFydGVkLiBXZSBhbHNvIGhhZCB0byB3b3JrIHdpdGgg
dGhlIG51YW5jZXMgb2YgSFRUUC4gV2UgbWFkZSB1c2Ugb2YgVExTLg0KDQpCYWNrIHdoZW4gd2Ug
d2VyZSBkb2luZyBES0lNIGFuZCBTUEYgd2UgaGFkIHRvIHRlbGwgY2VydGFpbiBETlMgZm9sayB0
aGF0IHRoZSBmYWN0IHRoYXQgYWxtb3N0IG5vIEROUyBSZWdpc3RyYXJzIG9mZmVyZWQgY3VzdG9t
ZXJzIHRoZSBhYmlsaXR5IHRvIHNwZWNpZnkgbmV3IFJSVHlwZXMgd2FzIHRoZWlyIHByb2JsZW0g
YW5kIHdhcyBnb2luZyB0byByZW1haW4gdGhlaXIgcHJvYmxlbSBubyBtYXR0ZXIgaG93IGxvdWRs
eSB0aGV5IHRyaWVkIHRvIGNvbXBsYWluIHRoYXQgaXQgc2hvdWxkIGJlY29tZSBvdXIgcHJvYmxl
bS4NCg0KW0hhbm5lc10gSSBjYW5ub3QgY29tbWVudCBvbiBES0lNIGFuZCBTUEsgYmVjYXVzZSBJ
IHdhcyBub3QgaW52b2x2ZWQgaW4gdGhhdCB3b3JrLg0KDQpJbiB0aGUgY2FzZSBvZiBPQVVUSCwg
dGhlcmUgaXMgYW5vdGhlciBwcm9ibGVtIGluIHRoYXQgT0FVVEggcmVhbGx5IGlzbid0IGEgdmVy
eSBvcGVuIHByb3RvY29sIGZyb20gdGhlIHN0YW5kcG9pbnQgb2YgdGhlIHVzZXIuIEkgY2FuIHVz
ZSBteSBHb29nbGUgb3IgbXkgRmFjZWJvb2sgb3IgbXkgVHdpdHRlciBhY2NvdW50cyB0byBsb2cg
aW4gdmlhIE9BVVRIIGF0IGEgbGFyZ2UgbnVtYmVyIG9mIHNpdGVzLiBCdXQgaWYgSSB3YW50IHRv
IHVzZSBhbnkgb3RoZXIgT0FVVEggcHJvdmlkZXIgSSBhbSBjb21wbGV0ZWx5IG91dCBvZiBsdWNr
LiBPciBhdCBsZWFzdCBJIHdpbGwgYmUgdW50aWwgdGhpcyBiZWNvbWVzIG9uZSBvZiB0aGUgbXVs
dGlmYWNldGVkIGNvbXBsYWludHMgaW4gdGhlIGFudGktdHJ1c3QgaGVhcmluZ3MgY29taW5nIHNv
b24gdG8gYSBjYXBpdG9sIGhpbGwgbmVhciB5b3UuIEFuZCB5ZXMsIHRoYXQgaXMgYSBjb25zZXF1
ZW5jZSBvZiBob3cgdGhlIHByb3RvY29sIGhhcyBiZWVuIGRlcGxveWVkLCBidXQgdGhhdCBwcm9i
YWJseSBub3QgZ29pbmcgdG8gZ2V0IHBlb3BsZSB2ZXJ5IGZhciBvbiBjYXBpdG9sIGhpbGwuDQoN
CltIYW5uZXNdIE9BdXRoIDIuMCBpcyBhIHNwZWNpZmljYXRpb24uIEl0IGhhcyBhIGNvdXBsZSBv
ZiBmbG93cy4gQSBwcm9kdWN0IGFuZCBhIHNlcnZpY2UgYWRkcyBtb3JlIHRvIE9BdXRoLCBpLmUu
IE9BdXRoIGlzIGp1c3QgYSBidWlsZGluZyBibG9jayBpbiBhIGxhcmdlciBlY29zeXN0ZW0uIFRo
YXQgZWNvc3lzdGVtIHdpbGwgY29udGFpbiB0aGUgYWN0dWFsIGFwcGxpY2F0aW9uIGFuZCBhbHNv
IHRoZSB1c2VyIGF1dGhlbnRpY2F0aW9uIGNvbXBvbmVudCAoYW1vbmcgb3RoZXIgdGhpbmdzKS4g
Q29tcGFuaWVzIG1ha2UgdGhlaXIgb3duIGRlY2lzaW9uIGFib3V0IGhvdyB0aGV5IHdhbnQgdG8g
dXNlIE9BdXRoIGluIHRoZWlyIHByb2R1Y3QuIEEgZml0bmVzcyBjb21wYW55IG1heSBkZWNpZGUg
dG8gYWxsb3cgaXRzIHVzZXJzIHRvIHNoYXJlIHRoZWlyIGhlYXJ0IHJhdGUgZGF0YSB3aXRoIG90
aGVycyAoYXNzdW1pbmcgY29uc2VudCBvZiB0aGUgdXNlcikuIEl0IG1heSBhbHNvIGRlY2lkZSBu
b3QgdG8gZG8gaXQuIEl0IGlzIGEgYnVzaW5lc3MgZGVjaXNpb24uIE9BdXRoIGFsbG93cyB5b3Ug
dG8gZG8gaXQgc2VjdXJlbHkgd2l0aCB0aGUgY29uc2VudCBvZiB0aGUgdXNlci4gTmVpdGhlciB0
aGUgT0F1dGggc3BlYyBub3IgdGhlIElFVEYgY2FuIHRlbGwgY29tcGFuaWVzIHdobyB0aGV5IHNo
b3VsZCB3b3JrIHdpdGguDQoNClRoZSBJbnRlcm5ldCBpcyBmb3IgZXZlcnlvbmUuIFRoZSBJbnRl
cm5ldCBpcyBmb3IgZW5kIHVzZXJzLg0KDQpbSGFubmVzXSBUaG9zZSBhcmUgZ3JlYXQgd29yZHMg
YnV0IHRoZXkgbWVhbiBub3RoaW5nIGluIHRoaXMgY29udGV4dC4gWW91IGtub3cgdGhhdC4NCg0K
DQpJIGFtIHJlYWxseSBub3QgdGhhdCBpbnRlcmVzdGVkIGluIHdobyBtYWtlcyB0aGUgaW5ncmVk
aWVudHMgZXhjZXB0IHRvIHRoZSBleHRlbnQgdGhhdCBpdCBkZXRlcm1pbmVzIHdoYXQgc29ydCBv
ZiBjYWtlIGVtZXJnZXMuIE9uZSBvZiB0aGUgdW5leHBlY3RlZCBzaWRlIGVmZmVjdHMgb2YgV2Vi
IDIuMCBoYXMgYmVlbiB0aGF0IGl0IGhhcyBncmVhdGx5IGNlbnRyYWxpemVkIHBvd2VyIGluIHRo
ZSBoYW5kcyBvZiBhIHRpbnkgbnVtYmVyIG9mIGluZGl2aWR1YWxzLiBJbmRpdmlkdWFscyB3aG8g
YXJlIGF0IGJlc3QgYWNjb3VudGFibGUgdG8gc2hhcmVob2xkZXJzLCBidXQgaW4gdGhlIGNhc2Ug
b2Ygc29tZSBvZiB0aGVtLCBhIHNlcGFyYXRlIHNoYXJlIGNsYXNzIGVuc3VyZXMgdGhhdCB0aGV5
IGFyZSBhY2NvdW50YWJsZSB0byBub2JvZHkuIEluIG5laXRoZXIgY2FzZSBhcmUgdGhlIHBlb3Bs
ZSB3aXRoIHBvd2VyIGFjY291bnRhYmxlIHRvIGVuZCB1c2VycyBiZWNhdXNlIHRoZXkgYXJlIG5v
dCBldmVuIGN1c3RvbWVycywgdGhleSBhcmUgdGhlIHByb2R1Y3QuDQoNCltIYW5uZXNdIEkgYmVs
aWV2ZSB0aGUgSUVURiBpcyBnb29kIGF0IHByb2R1Y2luZyBidWlsZGluZyBibG9ja3MsIGhhcyBs
aXR0bGUgZXhwZXJpZW5jZSBpbiBjb21wbGV0ZSBzeXN0ZW1zIGFuZCBubyBleHBlcmllbmNlIHdp
dGggYnVpbGRpbmcgYWN0dWFsIHByb2R1Y3RzLiBZb3UgYXJlIGNvbXBsYWluaW5nIGFib3V0IHRo
ZSBwcm9kdWN0cy4gWW91IGFyZSBibGFtaW5nIHRoZSB3cm9uZyBwZW9wbGUuDQoNCg0KV2hhdCBJ
IGFtIGludGVyZXN0ZWQgaW4gaXMgdGhlIGV4dGVudCB0byB3aGljaCBJbnRlcm5ldCB0ZWNobm9s
b2dpZXMgYXJlIFRlY2hub2xvZ2llcyBvZiBGcmVlZG9tLiBUaGUgcXVlc3Rpb24gd2UgbmVlZCB0
byBhc2sgb3Vyc2VsdmVzIGlzICdkb2VzIHRoaXMgdGVjaG5vbG9neSBpbmNyZWFzZSBlbmQgdXNl
ciBhdXRvbm9teSBvciBpbmNyZWFzZSB0aGVpciByZWxpYW5jZSBvbiB0aGlyZCBwYXJ0aWVzJy4N
Cg0KW0hhbm5lc10gT0F1dGggaXMgZmxleGlibGUuIFlvdSBjb3VsZCB1c2UgaW4geW91ciBvd24g
cGVyc29uYWwgZGF0YSBzdG9yZSBhbmQgcGVvcGxlIGhhdmUgZG9uZSB0aGF0LiBUaGVuLCB5b3Ug
YXJlIGNvbnRyb2xsaW5nIGV2ZXJ5dGhpbmcuIFlvdSBjYW4gYWxzbyBzZXR1cCBhIGNvbXBhbnkg
dG8gb2ZmZXIgdGhhdCBzZXJ2aWNlIHRvIG90aGVycyBiZWNhdXNlIHRoZXJlIHdpbGwgYmUgc29t
ZSB1c2VycyB3aG8gZG8gbm90IHdhbnQgdG8gcnVuIGV2ZXJ5dGhpbmcgdGhlbXNlbHZlcy4NCg0K
DQpJIHVuZGVyc3RhbmQgdGhhdCBzb21lIG9mIHRoZSBkZXZlbG9wbWVudHMgb24gdGhlIEludGVy
bmV0IGFyZSBjb25jZXJuaW5nIGFuZCBJIHNoYXJlIHlvdXIgY29uY2VybnMuIElmIHlvdSBiZWxp
ZXZlIE9BdXRoIGlzIGEgcmVhc29uIGZvciB0aGlzIGRldmVsb3BtZW50IHRoZW4gSSBoYXZlIHRv
IGRpc2FncmVlIHdpdGggeW91Lg0KDQpDaWFvDQpIYW5uZXMNCg0KSU1QT1JUQU5UIE5PVElDRTog
VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk
ZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k
IGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0
IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55
IG1lZGl1bS4gVGhhbmsgeW91Lg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx
IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg
NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i
Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJy
ZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkhpIFBoaWwsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG1vdmluZyB0aGlzIHRv
IHRoZSBPQXV0aCBncm91cCB0byBhdm9pZCBjb25mdXNpbmcgdGhlIElFVEYgbGlzdCBhbnkgZnVy
dGhlci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgbXkgZmVlZGJhY2sgYmVsb3cuIDxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t
OjwvYj4gaWV0ZiAmbHQ7aWV0Zi1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2Yg
PC9iPg0KUGhpbGxpcCBIYWxsYW0tQmFrZXI8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBG
ZWJydWFyeSAyNCwgMjAyMSA2OjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBLYXRobGVlbiBNb3JpYXJ0
eSAmbHQ7a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i
PiBpZXRmQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
RGl2ZXJzaXR5IGFuZCBJbmNsdXNpdmVuZXNzIGluIHRoZSBJRVRGPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dCI+SSBhbSB3b3JyaWVkIGJ5IHRoZSBhZHZpY2UgJ3VzZSBPQVVUSCcgYnV0IGZvciBhIHZlcnkg
ZGlmZmVyZW50IHJlYXNvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9BVVRIIGFuZCBTQU1MIGFyZSBib3Ro
IGF0dGVtcHRzIHRvIHByb3ZpZGUgYSBzZWN1cmUgYXV0aGVudGljYXRpb24gc2NoZW1lIHRoYXQg
d29ya3Mgd2l0aGluIHRoZSB2ZXJ5IHBhcnRpY3VsYXIgYW5kIHZlcnkgcGVjdWxpYXIgZW52aXJv
bm1lbnQgb2YgV2ViIGJyb3dzZXJzLiBUaGV5IGFyZSBzY2hlbWVzIHRoYXQgbmVjZXNzYXJpbHkg
aW52b2x2ZSB0ZWNobmlxdWVzDQogdGhhdCBhcmUgcmlnaHRseSByZWdhcmRlZCBhcyBhbGNoZW15
IGlmIG5vdCBvdXRyaWdodCB3aXRjaGNyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b
SGFubmVzXSBPQXV0aCBhbmQgU0FNTCB3ZXJlIGluaXRpYWxseSBkZXZlbG9wZWQgZm9yIHRoZSBX
ZWIgYmVjYXVzZSB0aGUgd2ViIGlzIGFuIGltcG9ydGFudCBkZXBsb3ltZW50IHVzZSBjYXNlLiBC
b3RoIHByb3RvY29scyBoYWQgYSB2ZXJ5IGRpZmZlcmVudCBoaXN0b3J5IGFuZCBhbHNvIGRpZmZl
cmVudCB1c2UgY2FzZXMuIE9BdXRoIGlzIGZvciBkZWxlZ2F0ZWQgYWNjZXNzIGFuZCBTQU1MIHdh
cyBkZXZlbG9wZWQNCiBhcyBhIFdlYlNTTyBzb2x1dGlvbi4gT0F1dGggYW5kIFNBTUwgd2VyZSBs
YXRlciBleHRlbmRlZCB0byBvdGhlciBlbnZpcm9ubWVudHMgdG9vLiBJbiBjYXNlIG9mIE9BdXRo
IHlvdSBjYW4gZmluZCBzb21lIG9mIHRoaXMgaW5mbyBpbiBvdXIgZG9jdW1lbnRzLCBzdWNoIGFz
IHRoZSBPQXV0aCAyLjAgZm9yIG5hdGl2ZSBhcHBzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoYXQg
aXMgZmluZSwgdGhhdCBpcyBtb3JlIHRoYW4gZmluZSBpZiB5b3UgYXJlIGRldmVsb3BpbmcgYW4g
YXV0aGVudGljYXRpb24gc2NoZW1lIGZvciB1c2Ugd2l0aGluIFdlYiBicm93c2VycyAob3IgaWYg
eW91IGFyZSBkZXZlbG9waW5nIHdoYXRldmVyIFNBTUwgYW5kIE9BVVRIIGFyZSB0aGVzZSBkYXlz
LCBuZWl0aGVyIHdhcyBvcmlnaW5hbGx5IGJpbGxlZA0KIGFzIGF1dGhlbnRpY2F0aW9uKS4gPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5bSGFubmVzXSBPQXV0aCBp
cyBub3QgYW4gYXV0aGVudGljYXRpb24gc2NoZW1lLCBwYXJ0aWN1bGFybHkgd2hlbiByZWZlcnJp
bmcgdG8gdXNlcnMuIEl0IGlzIGV4cGxpY2l0bHkgdGhlIGludGVudGlvbiB0byBrZWVwIHRoZSB1
c2VyIGF1dGhlbnRpY2F0aW9uIHBhcnQgb3V0c2lkZSBPQXV0aCwgd2hpY2ggYWxsb3dzIHVzIHRv
IHVzZSB0aGUgbW9zdCBtb2Rlcm4NCiB1c2VyIGF1dGhlbnRpY2F0aW9uIHRlY2hub2xvZ3kgYXZh
aWxhYmxlIHdpdGhvdXQgaGF2aW5nIHRvIHRvdWNoIE9BdXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QnV0IGl0IGlzIGNvbXBsZXRlbHkgaW5hcHByb3ByaWF0
ZSB0byBldmVyIHN1Z2dlc3QgbGV0IGFsb25lIGRlbWFuZCB0aGF0IGFueW9uZSB1c2UgYSB0ZWNo
bm9sb2d5IHdob3NlIHByaW1hcnkgZGVzaWduIGNvbnN0cmFpbnQgaXMgdG8gd29yayBhcm91bmQg
dGhlIHZvb2RvbyBvZiBKYXZhc2NyaXB0LCBVUklzLCBIVFRQIGNvb2tpZXMgZXRjLiBldGMuIGlu
DQogYW4gYXBwbGljYXRpb24gd2hlcmUgbm9uZSBvZiB0aG9zZSBsZWdhY3kgaXNzdWVzIGFwcGx5
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0hhbm5lc10gSXQgaXMgZGlmZmljdWx0
IHRvIGNvbW1lbnQgb24gdGhpcyBiZWNhdXNlIEkgZG9u4oCZdCBrbm93IHRoZSBjb250ZXh0LiBN
YXliZSBPQXV0aCB3YXMgYSBmaW5lIGNob2ljZSBhbmQgbWF5YmUgaXQgd2FzbuKAmXQuIEkgZG9u
4oCZdCBrbm93LiBXZSBhbGwgYWdyZWUgdGhhdCBPQXV0aCBpcyBub3QgZ29pbmcgdG8gYmUgdGhl
IGFuc3dlciB0byBldmVyeSBxdWVzdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T25lIG9mIHRoZSBiaWcg
cHJvYmxlbXMgb2YgSUVURiBpcyB0aGF0IGEgbG90IG9mIHBlb3BsZSBkb24ndCB0aGluayBhYm91
dCBob3cgdG8gZ2V0IHRoZWlyIHNjaGVtZSBkZXBsb3llZCBhbmQgd2hlbiB0aGV5IGRvLCB0aGVp
ciBwbGFuIGlzIHRvIHRpZSBpdCB0byBzb21lIG90aGVyIGdyb3VwIGFzIGEgYm9hdCBhbmNob3Iu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bSGFubmVzXSBJbiBnZW5lcmFsLCBzdGFu
ZGluZyBvbiB0aGUgc2hvdWxkZXJzIG9mIGdpYW50cyBpcyBub3QgYSBiYWQgYXBwcm9hY2guIENo
YW5nZXMgYXJlIHRoYXQgdGhlcmUgaXMgYSBwb3RlbnRpYWwgZm9yIHJlLXVzZS4gT0F1dGggYWxz
byB3YXNu4oCZdCBwcm9kdWNlZCBpbiBhIHZhY3V1bSBlaXRoZXIuIFdlIHVzZSBKU09OIGFzIGFu
IGVuY29kaW5nIGZvciB0aGUgYWNjZXNzIHRva2VucyB3aXRoIHRoZSBKV1QNCiB3aGVuIHRoZSB3
b3JrIGluIHRoZSBKT1NFIGdyb3VwIHdhcyBzdGFydGVkLiBXZSBhbHNvIGhhZCB0byB3b3JrIHdp
dGggdGhlIG51YW5jZXMgb2YgSFRUUC4gV2UgbWFkZSB1c2Ugb2YgVExTLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QmFjayB3aGVuIHdlIHdl
cmUgZG9pbmcgREtJTSBhbmQgU1BGIHdlIGhhZCB0byB0ZWxsIGNlcnRhaW4gRE5TIGZvbGsgdGhh
dCB0aGUgZmFjdCB0aGF0IGFsbW9zdCBubyBETlMgUmVnaXN0cmFycyBvZmZlcmVkIGN1c3RvbWVy
cyB0aGUgYWJpbGl0eSB0byBzcGVjaWZ5IG5ldyBSUlR5cGVzIHdhcyB0aGVpciBwcm9ibGVtIGFu
ZCB3YXMgZ29pbmcgdG8gcmVtYWluDQogdGhlaXIgcHJvYmxlbSBubyBtYXR0ZXIgaG93IGxvdWRs
eSB0aGV5IHRyaWVkIHRvIGNvbXBsYWluIHRoYXQgaXQgc2hvdWxkIGJlY29tZSBvdXIgcHJvYmxl
bS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltIYW5uZXNdIEkgY2Fubm90
IGNvbW1lbnQgb24gREtJTSBhbmQgU1BLIGJlY2F1c2UgSSB3YXMgbm90IGludm9sdmVkIGluIHRo
YXQgd29yay4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij5JbiB0aGUgY2FzZSBvZiBPQVVUSCwgdGhlcmUgaXMgYW5vdGhl
ciBwcm9ibGVtIGluIHRoYXQgT0FVVEggcmVhbGx5IGlzbid0IGEgdmVyeSBvcGVuIHByb3RvY29s
IGZyb20gdGhlIHN0YW5kcG9pbnQgb2YgdGhlIHVzZXIuIEkgY2FuIHVzZSBteSBHb29nbGUgb3Ig
bXkgRmFjZWJvb2sgb3IgbXkgVHdpdHRlciBhY2NvdW50cyB0byBsb2cgaW4gdmlhIE9BVVRIDQog
YXQgYSBsYXJnZSBudW1iZXIgb2Ygc2l0ZXMuIEJ1dCBpZiBJIHdhbnQgdG8gdXNlIGFueSBvdGhl
ciBPQVVUSCBwcm92aWRlciBJIGFtIGNvbXBsZXRlbHkgb3V0IG9mIGx1Y2suIE9yIGF0IGxlYXN0
IEkgd2lsbCBiZSB1bnRpbCB0aGlzIGJlY29tZXMgb25lIG9mIHRoZSBtdWx0aWZhY2V0ZWQgY29t
cGxhaW50cyBpbiB0aGUgYW50aS10cnVzdCBoZWFyaW5ncyBjb21pbmcgc29vbiB0byBhIGNhcGl0
b2wgaGlsbCBuZWFyIHlvdS4gQW5kIHllcywgdGhhdA0KIGlzIGEgY29uc2VxdWVuY2Ugb2YgaG93
IHRoZSBwcm90b2NvbCBoYXMgYmVlbiBkZXBsb3llZCwgYnV0IHRoYXQgcHJvYmFibHkgbm90IGdv
aW5nIHRvIGdldCBwZW9wbGUgdmVyeSBmYXIgb24gY2FwaXRvbCBoaWxsLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5bSGFubmVzXSBPQXV0aCAyLjAgaXMgYSBzcGVjaWZpY2F0aW9uLiBJdCBo
YXMgYSBjb3VwbGUgb2YgZmxvd3MuIEEgcHJvZHVjdCBhbmQgYSBzZXJ2aWNlIGFkZHMgbW9yZSB0
byBPQXV0aCwgaS5lLiBPQXV0aCBpcyBqdXN0IGEgYnVpbGRpbmcgYmxvY2sgaW4gYSBsYXJnZXIg
ZWNvc3lzdGVtLiBUaGF0IGVjb3N5c3RlbSB3aWxsIGNvbnRhaW4gdGhlIGFjdHVhbCBhcHBsaWNh
dGlvbiBhbmQgYWxzbyB0aGUgdXNlcg0KIGF1dGhlbnRpY2F0aW9uIGNvbXBvbmVudCAoYW1vbmcg
b3RoZXIgdGhpbmdzKS4gQ29tcGFuaWVzIG1ha2UgdGhlaXIgb3duIGRlY2lzaW9uIGFib3V0IGhv
dyB0aGV5IHdhbnQgdG8gdXNlIE9BdXRoIGluIHRoZWlyIHByb2R1Y3QuIEEgZml0bmVzcyBjb21w
YW55IG1heSBkZWNpZGUgdG8gYWxsb3cgaXRzIHVzZXJzIHRvIHNoYXJlIHRoZWlyIGhlYXJ0IHJh
dGUgZGF0YSB3aXRoIG90aGVycyAoYXNzdW1pbmcgY29uc2VudCBvZiB0aGUgdXNlcikuIEl0DQog
bWF5IGFsc28gZGVjaWRlIG5vdCB0byBkbyBpdC4gSXQgaXMgYSBidXNpbmVzcyBkZWNpc2lvbi4g
T0F1dGggYWxsb3dzIHlvdSB0byBkbyBpdCBzZWN1cmVseSB3aXRoIHRoZSBjb25zZW50IG9mIHRo
ZSB1c2VyLiBOZWl0aGVyIHRoZSBPQXV0aCBzcGVjIG5vciB0aGUgSUVURiBjYW4gdGVsbCBjb21w
YW5pZXMgd2hvIHRoZXkgc2hvdWxkIHdvcmsgd2l0aC4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGUgSW50ZXJuZXQg
aXMgZm9yIGV2ZXJ5b25lLiBUaGUgSW50ZXJuZXQgaXMgZm9yIGVuZCB1c2Vycy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+W0hhbm5lc10gVGhvc2UgYXJlIGdyZWF0IHdvcmRzIGJ1dCB0aGV5
IG1lYW4gbm90aGluZyBpbiB0aGlzIGNvbnRleHQuIFlvdSBrbm93IHRoYXQuDQo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSBhbSByZWFs
bHkgbm90IHRoYXQgaW50ZXJlc3RlZCBpbiB3aG8gbWFrZXMgdGhlIGluZ3JlZGllbnRzIGV4Y2Vw
dCB0byB0aGUgZXh0ZW50IHRoYXQgaXQgZGV0ZXJtaW5lcyB3aGF0IHNvcnQgb2YgY2FrZSBlbWVy
Z2VzLiBPbmUgb2YgdGhlIHVuZXhwZWN0ZWQgc2lkZSBlZmZlY3RzIG9mIFdlYiAyLjAgaGFzIGJl
ZW4gdGhhdCBpdCBoYXMgZ3JlYXRseSBjZW50cmFsaXplZA0KIHBvd2VyIGluIHRoZSBoYW5kcyBv
ZiBhIHRpbnkgbnVtYmVyIG9mIGluZGl2aWR1YWxzLiBJbmRpdmlkdWFscyB3aG8gYXJlIGF0IGJl
c3QgYWNjb3VudGFibGUgdG8gc2hhcmVob2xkZXJzLCBidXQgaW4gdGhlIGNhc2Ugb2Ygc29tZSBv
ZiB0aGVtLCBhIHNlcGFyYXRlIHNoYXJlIGNsYXNzIGVuc3VyZXMgdGhhdCB0aGV5IGFyZSBhY2Nv
dW50YWJsZSB0byBub2JvZHkuIEluIG5laXRoZXIgY2FzZSBhcmUgdGhlIHBlb3BsZSB3aXRoIHBv
d2VyIGFjY291bnRhYmxlDQogdG8gZW5kIHVzZXJzIGJlY2F1c2UgdGhleSBhcmUgbm90IGV2ZW4g
Y3VzdG9tZXJzLCB0aGV5IGFyZSB0aGUgcHJvZHVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPltIYW5uZXNdIEkgYmVsaWV2ZSB0aGUgSUVURiBpcyBnb29kIGF0IHByb2R1Y2luZyBi
dWlsZGluZyBibG9ja3MsIGhhcyBsaXR0bGUgZXhwZXJpZW5jZSBpbiBjb21wbGV0ZSBzeXN0ZW1z
IGFuZCBubyBleHBlcmllbmNlIHdpdGggYnVpbGRpbmcgYWN0dWFsIHByb2R1Y3RzLiBZb3UgYXJl
IGNvbXBsYWluaW5nIGFib3V0IHRoZSBwcm9kdWN0cy4gWW91IGFyZSBibGFtaW5nIHRoZSB3cm9u
ZyBwZW9wbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdCI+V2hhdCBJIGFtIGludGVyZXN0ZWQgaW4gaXMgdGhlIGV4dGVudCB0byB3aGljaCBJbnRl
cm5ldCB0ZWNobm9sb2dpZXMgYXJlIFRlY2hub2xvZ2llcyBvZiBGcmVlZG9tLiBUaGUgcXVlc3Rp
b24gd2UgbmVlZCB0byBhc2sgb3Vyc2VsdmVzIGlzICdkb2VzIHRoaXMgdGVjaG5vbG9neSBpbmNy
ZWFzZSBlbmQgdXNlciBhdXRvbm9teSBvciBpbmNyZWFzZSB0aGVpcg0KIHJlbGlhbmNlIG9uIHRo
aXJkIHBhcnRpZXMnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0hhbm5lc10gT0F1
dGggaXMgZmxleGlibGUuIFlvdSBjb3VsZCB1c2UgaW4geW91ciBvd24gcGVyc29uYWwgZGF0YSBz
dG9yZSBhbmQgcGVvcGxlIGhhdmUgZG9uZSB0aGF0LiBUaGVuLCB5b3UgYXJlIGNvbnRyb2xsaW5n
IGV2ZXJ5dGhpbmcuIFlvdSBjYW4gYWxzbyBzZXR1cCBhIGNvbXBhbnkgdG8gb2ZmZXIgdGhhdCBz
ZXJ2aWNlIHRvIG90aGVycyBiZWNhdXNlIHRoZXJlIHdpbGwgYmUgc29tZSB1c2VycyB3aG8NCiBk
byBub3Qgd2FudCB0byBydW4gZXZlcnl0aGluZyB0aGVtc2VsdmVzLiA8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVu
ZGVyc3RhbmQgdGhhdCBzb21lIG9mIHRoZSBkZXZlbG9wbWVudHMgb24gdGhlIEludGVybmV0IGFy
ZSBjb25jZXJuaW5nIGFuZCBJIHNoYXJlIHlvdXIgY29uY2VybnMuIElmIHlvdSBiZWxpZXZlIE9B
dXRoIGlzIGEgcmVhc29uIGZvciB0aGlzIGRldmVsb3BtZW50IHRoZW4gSSBoYXZlIHRvIGRpc2Fn
cmVlIHdpdGggeW91Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0
dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl
bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg
b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkg
dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_AM0PR08MB37168F0895CC638ED5222E65FA9F9AM0PR08MB3716eurp_--


From nobody Wed Feb 24 02:22:47 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8BA3A1357 for ; Wed, 24 Feb 2021 02:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swYv-z5p-UbF for ; Wed, 24 Feb 2021 02:22:43 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD8A3A1354 for ; Wed, 24 Feb 2021 02:22:43 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id y202so1480745iof.1 for ; Wed, 24 Feb 2021 02:22:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jlSVohIT1CVrh28tKruwY+uwuC4tra7URgAfHv+3ohE=; b=Kbk4gDcn9EqEBvOUz3+kai5OMvKYaV9ChgeWPHq8P2GHIHlodN0v/0aAJgc8kuXCh2 rgaDrDEHonD2eg7BUhKTGd7sse4gNoy7GarKmxpsrs36EU6JPS3wv/N8+fn6BpzBily6 mww9OWdnukaAP+/05Fmf1Zgs3niyP5XRakyqV6tLe6P3pllIQNDYiQHYsN7Xq/h6smqE TBvcMrNIGQHHo4kmXjhXxyX6MlIqtLCMdnZxa6+M5yp9x4jBQyL91mQPF8DxnXb2ROcB xR+aww0HnO/rCM8XHZNCUQyU5LeJIZ4WwyHaIh85ve7kzSJ8fea7YwjASnbN0uPIp6dY 8gCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jlSVohIT1CVrh28tKruwY+uwuC4tra7URgAfHv+3ohE=; b=Wpjk0NN2MqEuu66DIweZT6nwd9atvLMBgi3iLlZohmhhqoGFbxqcg77l7Q732cs1K9 rEbpH67zcLNDwYoLNyvmHVdMFrrdbVSHoea+IawgeIYuCdPOlC4rLk9wBdULkt/9RLwW xiOQHMoxyXQllfIYA7suzJjia9sQcGzRZkLiqVih7NqHoRR4kUIk2nLpSB46+oU67H4n U1kwYTwLwfa9N0KR8U1SkaTQ/DG1aFaDJgGveieUt5YCK35ZXtZXzilhO9c2vIeHOF4D dRGInsFXyyP2WO3k/LlsG5pO4SeaIfEtXC0h6Zs0Rp8cuQeNlBnUUn/JpqYH0dBjmJOI v0sg==
X-Gm-Message-State: AOAM533jP5K3mow0jjHTi+qMHMUtxmq1QcDkyfJwQLqCAmXBitCRq4vt YXpUC8sjrsXXmQMz4QKnCslmop/XjZfFRLh+kjLz
X-Google-Smtp-Source: ABdhPJwmGlzUSWYrXzwpLYDUxRzOb63QyVJanoV4WrgNhmWsC5tkfazSGZHN6LPgQ8tMUpZtqaZLh/vgoL2WG2nNwYI=
X-Received: by 2002:a5d:8249:: with SMTP id n9mr23988104ioo.31.1614162162240;  Wed, 24 Feb 2021 02:22:42 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Warren Parad 
Date: Wed, 24 Feb 2021 11:22:31 +0100
Message-ID: 
To: Bron Gondwana 
Cc: Jim Manico , Phillip Hallam-Baker , ietf@ietf.org, "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000004a631605bc126a5f"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 10:22:46 -0000

--0000000000004a631605bc126a5f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Should we solve the NxM problem, and if so, how do you propose we do that?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 24, 2021 at 8:08 AM Bron Gondwana 
wrote:

> On Wed, Feb 24, 2021, at 17:26, Jim Manico wrote:
>
> I think it=E2=80=99s important to point out that OAuth is not an authenti=
cation
> protocol. It=E2=80=99s for delegation. OAuth is one of the most mis-used =
protocols
> on the modern web. If you really want to support end users, a good place =
to
> start is to make it clear to developers what OAuth is really for so secur=
e
> solutions are built as opposed to the dumpster fire that OAuth solutions
> have become today.
>
>
> https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does
>
> Which suggests that if the OAuth solutions deployed today are dumpster
> fires, then ... well, that's what OAuth 2 does.
>
> My biggest problem with OAuth as an outsider is that it doesn't solve the
> NxM problem.  You can't build a client which can OAuth against any
> arbitrary OAuth service that provides a standard protocol, because you ne=
ed
> to get an API key for your particular application from each service
> provider.  This just doesn't scale, which is a large part of Phillip's
> complaint as well.
>
> Of course, I came into the IETF having already read
> https://web.archive.org/web/20120731155632/http://hueniverse.com/2012/07/=
oauth-2-0-and-the-road-to-hell/
> - which was one of the things which made me wary of the IETF in the first
> place, and keen to not let everything I touched get over-complicated.
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000004a631605bc126a5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Should we solve the NxM problem, and if so, how do you pro=
pose we do that?

=

Warren Parad
Founder, CTO
Secure your user data with IAM authorization=
 as a service. Implement=C2=A0Authress.


On Wed, Feb 24, 2021 at=
 8:08 AM Bron Gondwana <brong@=
fastmailteam.com> wrote:
On Wed, Feb 24, 2021, at 17:26, Jim Manico wrote:
I th=
ink it=E2=80=99s important to point out that OAuth is not an authentication=
 protocol. It=E2=80=99s for delegation. OAuth is one of the most mis-used p=
rotocols on the modern web. If you really want to support end users, a good=
 place to start is to make it clear to developers what OAuth is really for =
so secure solutions are built as opposed to the dumpster fire that OAuth so=
lutions have become today.


Which suggests that if the OAuth solutions deployed today are dump=
ster fires, then ... well, that's what OAuth 2 does.

My bigge=
st problem with OAuth as an outsider is that it doesn't solve the NxM p=
roblem.=C2=A0 You can't build a client which can OAuth against any arbi=
trary OAuth service that provides a standard protocol, because you need to =
get an API key for your particular application from each service provider.=
=C2=A0 This just doesn't scale, which is a large part of Phillip's =
complaint as well.

Of course, I came into the IETF having already=
 read https://w=
eb.archive.org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-a=
nd-the-road-to-hell/ - which was one of the things which made me wary o=
f the IETF in the first place, and keen to not let everything I touched get=
 over-complicated.

Bron.

-=
- 
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000004a631605bc126a5f--


From nobody Wed Feb 24 02:23:11 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA203A1370 for ; Wed, 24 Feb 2021 02:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.088
X-Spam-Level: 
X-Spam-Status: No, score=-7.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLWZX1gLG9lc for ; Wed, 24 Feb 2021 02:23:01 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375ED3A136B for ; Wed, 24 Feb 2021 02:23:01 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id n14so1472219iog.3 for ; Wed, 24 Feb 2021 02:23:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Es/VR3KD7LNRN3EfdMO5sYaX1dAvZ4BzI89SgjD1O8g=; b=eP2ipcVgknEX9SZ4NqMR9URJm0GO4s0dPGdJgtF5nvHc+HxqdRJaAt9ZI2JhMqmGWT jaa+oIql1T1hi+cyG1V/cb3cwsWWDo2YxqvoqXsyCPOOclyYnjnerzMP262qJVpLH9+2 axaHxM1oTu9rhuIARR0e7igzoUWiXURvHah3wAfm2Y0nv8WMY91vZp34AWdw6+8xEuQ/ Paf4KZoDvL0RjkCs7DqMfHg/9GGGy9cE1ReH4okxxK36gGDWsvY8kP5c58waC9udI8zD N3eRwNOdxs/MEHIvoSdaMQiHWVDYAWsAO7byeJ5FeiPWFHdFzCZKMXtMX2LdlPx8tMTb 90BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Es/VR3KD7LNRN3EfdMO5sYaX1dAvZ4BzI89SgjD1O8g=; b=LaoItvOta8ol1FZ66wlpg/u/sjF/p7W94XUcP1qc+V3LCnou0M7AKhD0kaaS3xgkI+ Q0xgl4TKfPTcRatMyMio4N8C9SYsmeXo2ygFO0PSUsOhvuVV002b2cEBbKGfkcWAeJ6n QuA78Bvpj+jNxuRoF3g+tSFOQfL2mu8/N4Qi+O4X1VMpBRWmoASTxDuhVR9fRw04aoLA betjQDZTzo2M+exqXn7qAbbMdnogXT82LmPUBytntdNUDpExVH7P9oH5HUfTHmm7wpPf XzaOSiHOvKJO4A/3p1gPrhoCKLEmnmHtZLG4kzQJlqi2ZAfh8PQiHWPZmeysATRl/Ugk usNQ==
X-Gm-Message-State: AOAM533+EOD91lG9Z5CrKvsUSbjXqO1BSSQrmfVC2rexwvswbwKMrFfB BcvnZ1e8xi0oYofWifrB5C4+hwXiE8RfkUHLkvNJ
X-Google-Smtp-Source: ABdhPJypwPYfAY1V6io8wbu2qxZSmxCku+GjkZBMttCsLyVyC+cqMInDmjgjX6mF4kf8WLAil3288hdUIVoMCvaeJjY=
X-Received: by 2002:a5d:9510:: with SMTP id d16mr23381104iom.81.1614162180341;  Wed, 24 Feb 2021 02:23:00 -0800 (PST)
MIME-Version: 1.0
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com>    <10fd9d2d-afb4-44aa-b618-fb5ce1efa69e@dogfood.fastmail.com>    
In-Reply-To: 
From: Warren Parad 
Date: Wed, 24 Feb 2021 11:22:49 +0100
Message-ID: 
To: Hannes Tschofenig 
Cc: Phillip Hallam-Baker ,  Kathleen Moriarty , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005e9a1705bc126b49"
Archived-At: 
Subject: Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 10:23:10 -0000

--0000000000005e9a1705bc126b49
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=F0=9F=91=8F

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 24, 2021 at 10:09 AM Hannes Tschofenig <
Hannes.Tschofenig@arm.com> wrote:

> Hi Phil,
>
>
>
> I am moving this to the OAuth group to avoid confusing the IETF list any
> further.
>
>
>
> See my feedback below.
>
>
>
> *From:* ietf  *On Behalf Of * Phillip Hallam-Baker
> *Sent:* Wednesday, February 24, 2021 6:47 AM
> *To:* Kathleen Moriarty 
> *Cc:* ietf@ietf.org; oauth@ietf.org
> *Subject:* Re: Diversity and Inclusiveness in the IETF
>
>
>
> I am worried by the advice 'use OAUTH' but for a very different reason.
>
>
>
> OAUTH and SAML are both attempts to provide a secure authentication schem=
e
> that works within the very particular and very peculiar environment of We=
b
> browsers. They are schemes that necessarily involve techniques that are
> rightly regarded as alchemy if not outright witchcraft.
>
>
>
> [Hannes] OAuth and SAML were initially developed for the Web because the
> web is an important deployment use case. Both protocols had a very
> different history and also different use cases. OAuth is for delegated
> access and SAML was developed as a WebSSO solution. OAuth and SAML were
> later extended to other environments too. In case of OAuth you can find
> some of this info in our documents, such as the OAuth 2.0 for native apps=
.
>
>
>
> That is fine, that is more than fine if you are developing an
> authentication scheme for use within Web browsers (or if you are developi=
ng
> whatever SAML and OAUTH are these days, neither was originally billed as
> authentication).
>
>
>
> [Hannes] OAuth is not an authentication scheme, particularly when
> referring to users. It is explicitly the intention to keep the user
> authentication part outside OAuth, which allows us to use the most modern
> user authentication technology available without having to touch OAuth.
>
>
>
> But it is completely inappropriate to ever suggest let alone demand that
> anyone use a technology whose primary design constraint is to work around
> the voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application
> where none of those legacy issues apply.
>
>
>
> [Hannes] It is difficult to comment on this because I don=E2=80=99t know =
the
> context. Maybe OAuth was a fine choice and maybe it wasn=E2=80=99t. I don=
=E2=80=99t know.
> We all agree that OAuth is not going to be the answer to every question.
>
>
>
> One of the big problems of IETF is that a lot of people don't think about
> how to get their scheme deployed and when they do, their plan is to tie i=
t
> to some other group as a boat anchor.
>
>
>
> [Hannes] In general, standing on the shoulders of giants is not a bad
> approach. Changes are that there is a potential for re-use. OAuth also
> wasn=E2=80=99t produced in a vacuum either. We use JSON as an encoding fo=
r the
> access tokens with the JWT when the work in the JOSE group was started. W=
e
> also had to work with the nuances of HTTP. We made use of TLS.
>
>
>
> Back when we were doing DKIM and SPF we had to tell certain DNS folk that
> the fact that almost no DNS Registrars offered customers the ability to
> specify new RRTypes was their problem and was going to remain their probl=
em
> no matter how loudly they tried to complain that it should become our
> problem.
>
>
>
> [Hannes] I cannot comment on DKIM and SPK because I was not involved in
> that work.
>
>
>
> In the case of OAUTH, there is another problem in that OAUTH really isn't
> a very open protocol from the standpoint of the user. I can use my Google
> or my Facebook or my Twitter accounts to log in via OAUTH at a large numb=
er
> of sites. But if I want to use any other OAUTH provider I am completely o=
ut
> of luck. Or at least I will be until this becomes one of the multifaceted
> complaints in the anti-trust hearings coming soon to a capitol hill near
> you. And yes, that is a consequence of how the protocol has been deployed=
,
> but that probably not going to get people very far on capitol hill.
>
>
>
> [Hannes] OAuth 2.0 is a specification. It has a couple of flows. A produc=
t
> and a service adds more to OAuth, i.e. OAuth is just a building block in =
a
> larger ecosystem. That ecosystem will contain the actual application and
> also the user authentication component (among other things). Companies ma=
ke
> their own decision about how they want to use OAuth in their product. A
> fitness company may decide to allow its users to share their heart rate
> data with others (assuming consent of the user). It may also decide not t=
o
> do it. It is a business decision. OAuth allows you to do it securely with
> the consent of the user. Neither the OAuth spec nor the IETF can tell
> companies who they should work with.
>
>
>
> The Internet is for everyone. The Internet is for end users.
>
>
>
> [Hannes] Those are great words but they mean nothing in this context. You
> know that.
>
>
>
>
>
> I am really not that interested in who makes the ingredients except to th=
e
> extent that it determines what sort of cake emerges. One of the unexpecte=
d
> side effects of Web 2.0 has been that it has greatly centralized power in
> the hands of a tiny number of individuals. Individuals who are at best
> accountable to shareholders, but in the case of some of them, a separate
> share class ensures that they are accountable to nobody. In neither case
> are the people with power accountable to end users because they are not
> even customers, they are the product.
>
>
>
> [Hannes] I believe the IETF is good at producing building blocks, has
> little experience in complete systems and no experience with building
> actual products. You are complaining about the products. You are blaming
> the wrong people.
>
>
>
>
>
> What I am interested in is the extent to which Internet technologies are
> Technologies of Freedom. The question we need to ask ourselves is 'does
> this technology increase end user autonomy or increase their reliance on
> third parties'.
>
>
>
> [Hannes] OAuth is flexible. You could use in your own personal data store
> and people have done that. Then, you are controlling everything. You can
> also setup a company to offer that service to others because there will b=
e
> some users who do not want to run everything themselves.
>
>
>
>
>
> I understand that some of the developments on the Internet are concerning
> and I share your concerns. If you believe OAuth is a reason for this
> development then I have to disagree with you.
>
>
>
> Ciao
>
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy th=
e
> information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000005e9a1705bc126b49
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


=F0=9F=91=8F
<=
span style=3D"border:none;display:inline-block;overflow:hidden;width:199px;=
height:34px">
Warren Parad
Founder, CTO
Secure your user data with IAM auth=
orization as a service. Implement=C2=A0Authress.


On Wed, Feb 24, 20=
21 at 10:09 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:











Hi Phil, 


=C2=A0


I am moving this to the OAuth group to avoid confusi=
ng the IETF list any further.



=C2=A0


See my feedback below. 


=C2=A0




From: ietf <ietf-bounces@ietf.org> On Behalf Of =

Phillip Hallam-Baker

Sent: Wednesday, February 24, 2021 6:47 AM

To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>

Cc: ietf@ietf.org=
; oauth@ietf.org

Subject: Re: Diversity and Inclusiveness in the IETF



=C2=A0






I am worried by the a=
dvice 'use OAUTH' but for a very different reason.






=C2=A0<=
/span>






OAUTH and SAML are bo=
th attempts to provide a secure authentication scheme that works within the=
 very particular and very peculiar environment of Web browsers. They are sc=
hemes that necessarily involve techniques
 that are rightly regarded as alchemy if not outright witchcraft.=







=C2=A0<=
/span>


[Hannes] OAuth and SAML were initially developed for=
 the Web because the web is an important deployment use case. Both protocol=
s had a very different history and also different use cases. OAuth is for d=
elegated access and SAML was developed
 as a WebSSO solution. OAuth and SAML were later extended to other environm=
ents too. In case of OAuth you can find some of this info in our documents,=
 such as the OAuth 2.0 for native apps. =C2=A0


=C2=A0






That is fine, that is=
 more than fine if you are developing an authentication scheme for use with=
in Web browsers (or if you are developing whatever SAML and OAUTH are these=
 days, neither was originally billed
 as authentication). 


=C2=A0<=
/span>


[Hannes] OAuth is not=
 an authentication scheme, particularly when referring to users. It is expl=
icitly the intention to keep the user authentication part outside OAuth, wh=
ich allows us to use the most modern
 user authentication technology available without having to touch OAuth.=



=C2=A0<=
/span>


But it is completely =
inappropriate to ever suggest let alone demand that anyone use a technology=
 whose primary design constraint is to work around the voodoo of Javascript=
, URIs, HTTP cookies etc. etc. in
 an application where none of those legacy issues apply.


=C2=A0


[Hannes] It is difficult to comment on this because =
I don=E2=80=99t know the context. Maybe OAuth was a fine choice and maybe i=
t wasn=E2=80=99t. I don=E2=80=99t know. We all agree that OAuth is not goin=
g to be the answer to every question.



=C2=A0






One of the big proble=
ms of IETF is that a lot of people don't think about how to get their s=
cheme deployed and when they do, their plan is to tie it to some other grou=
p as a boat anchor.


=C2=A0


[Hannes] In general, standing on the shoulders of gi=
ants is not a bad approach. Changes are that there is a potential for re-us=
e. OAuth also wasn=E2=80=99t produced in a vacuum either. We use JSON as an=
 encoding for the access tokens with the JWT
 when the work in the JOSE group was started. We also had to work with the =
nuances of HTTP. We made use of TLS.


=C2=A0


Back when we were doi=
ng DKIM and SPF we had to tell certain DNS folk that the fact that almost n=
o DNS Registrars offered customers the ability to specify new RRTypes was t=
heir problem and was going to remain
 their problem no matter how loudly they tried to complain that it should b=
ecome our problem.=C2=A0


=C2=A0


[Hannes] I cannot comment on DKIM and SPK because I =
was not involved in that work.







=C2=A0<=
/span>






In the case of OAUTH,=
 there is another problem in that OAUTH really isn't a very open protoc=
ol from the standpoint of the user. I can use my Google or my Facebook or m=
y Twitter accounts to log in via OAUTH
 at a large number of sites. But if I want to use any other OAUTH provider =
I am completely out of luck. Or at least I will be until this becomes one o=
f the multifaceted complaints in the anti-trust hearings coming soon to a c=
apitol hill near you. And yes, that
 is a consequence of how the protocol has been deployed, but that probably =
not going to get people very far on capitol hill.






=C2=A0<=
/span>


[Hannes] OAuth 2.0 is a specification. It has a coup=
le of flows. A product and a service adds more to OAuth, i.e. OAuth is just=
 a building block in a larger ecosystem. That ecosystem will contain the ac=
tual application and also the user
 authentication component (among other things). Companies make their own de=
cision about how they want to use OAuth in their product. A fitness company=
 may decide to allow its users to share their heart rate data with others (=
assuming consent of the user). It
 may also decide not to do it. It is a business decision. OAuth allows you =
to do it securely with the consent of the user. Neither the OAuth spec nor =
the IETF can tell companies who they should work with.







=C2=A0<=
/span>






The Internet is for e=
veryone. The Internet is for end users.






=C2=A0<=
/span>


[Hannes] Those are great words but they mean nothing=
 in this context. You know that.



=C2=A0


=C2=A0






I am really not that =
interested in who makes the ingredients except to the extent that it determ=
ines what sort of cake emerges. One of the unexpected side effects of Web 2=
.0 has been that it has greatly centralized
 power in the hands of a tiny number of individuals. Individuals who are at=
 best accountable to shareholders, but in the case of some of them, a separ=
ate share class ensures that they are accountable to nobody. In neither cas=
e are the people with power accountable
 to end users because they are not even customers, they are the product.=



=C2=A0


[Hannes] I believe the IETF is good at producing bui=
lding blocks, has little experience in complete systems and no experience w=
ith building actual products. You are complaining about the products. You a=
re blaming the wrong people.


=C2=A0






=C2=A0<=
/span>






What I am interested =
in is the extent to which Internet technologies are Technologies of Freedom=
. The question we need to ask ourselves is 'does this technology increa=
se end user autonomy or increase their
 reliance on third parties'.


=C2=A0


[Hannes] OAuth is flexible. You could use in your ow=
n personal data store and people have done that. Then, you are controlling =
everything. You can also setup a company to offer that service to others be=
cause there will be some users who
 do not want to run everything themselves. 


=C2=A0


=C2=A0


I understand that some of the developments on the In=
ternet are concerning and I share your concerns. If you believe OAuth is a =
reason for this development then I have to disagree with you.



=C2=A0


Ciao


Hannes


=C2=A0







IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose,
 or store or copy the information in any medium. Thank you.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000005e9a1705bc126b49--


From nobody Wed Feb 24 02:36:28 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A373A1381; Wed, 24 Feb 2021 02:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziuHwwzgd4V9; Wed, 24 Feb 2021 02:36:18 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1206C3A1382; Wed, 24 Feb 2021 02:36:17 -0800 (PST)
Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Dlslf6Gvqz1066; Wed, 24 Feb 2021 11:36:14 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 24 Feb 2021 11:36:13 +0100
Cc: Bron Gondwana , Phillip Hallam-Baker , "oauth@ietf.org" , ietf@ietf.org
X-Mao-Original-Outgoing-Id: 635855773.37514-761cd45eee528234ef1e127702ee3c74
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    
To: Warren Parad 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 10:36:22 -0000

On 2021-02-24, at 11:22, Warren Parad =
 wrote:
>=20
> Should we solve the NxM problem, and if so, how do you propose we do =
that?

Let GNAP do that.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Wed Feb 24 02:41:53 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4633A1388 for ; Wed, 24 Feb 2021 02:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-LIOmpNbxuz for ; Wed, 24 Feb 2021 02:41:51 -0800 (PST)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199403A1387 for ; Wed, 24 Feb 2021 02:41:51 -0800 (PST)
Received: by mail-ej1-x632.google.com with SMTP id u20so2211872ejb.7 for ; Wed, 24 Feb 2021 02:41:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=JvxpniuPNfdSUHvocafAGUfoP1fBpax2oOgc2Q1/UY0=; b=WW5tL/dX119qmL1YlGG9pr91uRkPYrBINavsxt1EkkI8Q8fqN6orC37Tg1B3kZy1Aq ZV8eGh0jXzebS+ta84GSXorN3puGT+1zNuYzqHoJn0XbDxXtYnhiUAuVxGMGf6Ybh0bA Cqf+j8cpRDmkGOTo5yXhxHixm3SfW9R62f9tjwWQAQ/A3u+Z+PE3jHzNnktdheuKEjiy 7Xn8Khh8YDJpZvYt26mbmHtSmvxZVX9Hd3xIZ7HWw0FxgWn/8x6qMy6PfodBJc/JugFh mkcIoTr2ufzhepom9gksH/18tQ6CGj+53jDwhmfMsQ7wCz/qNu5iRRnOuElQqkmt/wME cdIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JvxpniuPNfdSUHvocafAGUfoP1fBpax2oOgc2Q1/UY0=; b=mDET/sFFbkW41RnDmv8SN1xpFdmIF7a5QGLHsEki3m3hHBGU3rgf5up9qEFURcXfoI AWQl4R0gGxOam6UK/AhOn+O6v+4Japn1XeEOcZLVCrCtFNyVUpRr9r24zKZ+C4nTvFI5 OnnPz4kp+9H45Iq3KZsmhPf5tpXu8sudoh3d8oDPW0v0ruFUi9oJ3gMzK0upIqHn+8HP BvBxeVN2lxOKpQSK9Zhu6XIKQXV8FJ3qF4kQ5iVesNjoyLgIcsKF46f68z7xxmL4dbTk ll7QLfAhxwjcEB3bks/7ZqDOnoFwvbxvNVYcUiN9tUBmLZk70crHSI6TMkCe63pHrRlK 2HxA==
X-Gm-Message-State: AOAM533k3O7x6FidRplU2Cf1iEUPxw+4JOxjkI9dCLFvNrSRfkcrnYO6 5SWNcqKXRjIWAut6ykvMNjCAw9AyeQapUCIoNDISd98+IZ4=
X-Google-Smtp-Source: ABdhPJzGfzjhBJMCyBjxUFfYrAuGLOwTW3aRUqWOVD2i/4aHvy6tq6TpMviJxQCH2BF7R4SdEJw9qhxWhaqW5ZmnYCE=
X-Received: by 2002:a17:906:4b13:: with SMTP id y19mr23407602eju.139.1614163308751;  Wed, 24 Feb 2021 02:41:48 -0800 (PST)
MIME-Version: 1.0
From: Jerry Leyendecker 
Date: Wed, 24 Feb 2021 04:41:40 -0600
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a0aff805bc12ae3a"
Archived-At: 
Subject: [OAUTH-WG] Send me the autherized paperwork
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 10:41:52 -0000

--000000000000a0aff805bc12ae3a
Content-Type: text/plain; charset="UTF-8"

Approved

--000000000000a0aff805bc12ae3a
Content-Type: text/html; charset="UTF-8"


Approved


--000000000000a0aff805bc12ae3a--


From nobody Wed Feb 24 03:04:56 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DF93A13D2 for ; Wed, 24 Feb 2021 03:04:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9gQoJZq5SjR for ; Wed, 24 Feb 2021 03:04:52 -0800 (PST)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278113A13D1 for ; Wed, 24 Feb 2021 03:04:52 -0800 (PST)
Received: by mail-il1-x129.google.com with SMTP id c10so1342533ilo.8 for ; Wed, 24 Feb 2021 03:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iWqCBlH9sbYetg2YNZAjSd8zkk1yn20xy2RI7oTCwbg=; b=dm3drBWgz9Vt3hElnMhm7UrE0GIloo/j8CkhuuqZRM35EOGFGZ/s49/QRv4jb8ea8O A+AnRcCJk1i8Rl73jHib57BPZ09JWi5DvBmU59FY/n5rmeIfUBpwPsN65D7/qJWn+DFO woAsJVK9+pxywSUriMoNaklXkncAZfaxMA7oQi0qvR0L1vA6K80zd2ShRNOC7McsDBJU HnXx4N4cex3bXGNoF+2/Z9s/a8SL79gr8m2a2WEofzFcJS5plEJl/h/CTl9fprp8lcNh nirAylgBYVrnjqFeSs/LDPaSn8PicDa2r1wmaZlPRs4xVDjEBDGtvmRhfb8gI0Ammwsr dScw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iWqCBlH9sbYetg2YNZAjSd8zkk1yn20xy2RI7oTCwbg=; b=hTJUwOXfE5v8CQsTukmgPzxD7h+3jNvwOWYlItXa28e4jpidEVI5WQuCILv8krIX8+ Ivbto5V+qqkQQCfp1cslyXE9fPbyUC9lnkpYaWzzS+yil1a4A4EMOw8nUN+dibqJRwB2 k1x05bbOpz58rBWQyPZAceAd2MQNCJppafL6TLn8dPGHXf8gW+JFTcUYVH3QD9tFmXoR KALncnZPeHpzJC59lpVEBhXR4Lsk2MY7tkEWlQ3LiomAgP2c1VSCrrEpLMf1+VPGULvG 703QRTp/XAdQJlOYQ3k4QDD0NJ2Ve4yObgdTVp8Vv4aFj6/8PgDjw32QDtMTahvUWkxN 6Z0w==
X-Gm-Message-State: AOAM530FvMr2fn8vboW4QgWNmd7fws8Eb6fzb2zEn1fnqv67t0c/w0xg LT2EjpioxMelplXCUNSN3nkDcPJQIXmSJSaWaFF6
X-Google-Smtp-Source: ABdhPJwWd0euqp01Ne8FmpMFvbmfckXX69MQPPJ3kFhjsLHA16xhHKVQPMyYcm5L5k2RFAa7FPO9DbmF0gs6naT3m5U=
X-Received: by 2002:a05:6e02:1a29:: with SMTP id g9mr22767810ile.54.1614164691037;  Wed, 24 Feb 2021 03:04:51 -0800 (PST)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Warren Parad 
Date: Wed, 24 Feb 2021 12:04:40 +0100
Message-ID: 
To: Carsten Bormann 
Cc: Bron Gondwana , Phillip Hallam-Baker ,  "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/alternative; boundary="00000000000004ce5305bc130194"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 11:04:54 -0000

--00000000000004ce5305bc130194
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would prefer Bron to answer that question, as they are the one who
started this email thread.

However let's look at GNAP, I've honestly been struggling to understand at
least one fully documented case that GNAP supports. It seems in every
document the only thing that is clear is GNAP wants to allow "everything",
doesn't actually talk about an example.

By NxM, I assume we mean that the end user or client is free to select
whichever AS they want, in a way which the RS can verify the AS credential
and the user identity, without the RS having to (and really without the
ability to limit) which AS are allowed.

Would you agree with that statement?

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 24, 2021 at 11:36 AM Carsten Bormann  wrote:

> On 2021-02-24, at 11:22, Warren Parad 
> wrote:
> >
> > Should we solve the NxM problem, and if so, how do you propose we do
> that?
>
> Let GNAP do that.
>
> Gr=C3=BC=C3=9Fe, Carsten
>
>

--00000000000004ce5305bc130194
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I would prefer Bron to answer that question, as they are t=
he one who started this email thread.

However let's =
look at GNAP, I've honestly been struggling to understand at least one =
fully documented case that GNAP supports. It seems in every document the on=
ly thing that is clear is GNAP wants to allow "everything", doesn=
't actually talk about an example.

By NxM, I a=
ssume we mean that the end user or client is free to select whichever AS th=
ey want, in a way which the RS can verify the AS credential and the user id=
entity, without the RS having to (and really without the ability to limit) =
which AS are allowed.

Would you agree with that st=
atement?

<=
span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-=
color:transparent;vertical-align:baseline;white-space:pre-wrap">
Warren Parad
Founder, CTO
Secure your user data with IAM authorization =
as a service. Implement=C2=A0Authress.


On Wed, Feb 24, 2021 at=
 11:36 AM Carsten Bormann <cabo@tzi.org<=
/a>> wrote:
O=
n 2021-02-24, at 11:22, Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org> w=
rote:

> 

> Should we solve the NxM problem, and if so, how do you propose we do t=
hat?



Let GNAP do that.



Gr=C3=BC=C3=9Fe, Carsten






--00000000000004ce5305bc130194--


From nobody Wed Feb 24 03:40:03 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09A3A1446; Wed, 24 Feb 2021 03:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bdABPhpu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cwGjBewA
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aNBwz7CTccJ; Wed, 24 Feb 2021 03:39:55 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8804B3A1448; Wed, 24 Feb 2021 03:39:35 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 80CE3B47; Wed, 24 Feb 2021 06:39:34 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 06:39:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=yUvd npoJwPRzXPxDZkv1rG4dmLCfYIfChuY8x0ZL3OE=; b=bdABPhpu35BVXcEfUO4w dnvwYrHFvrK3ui283ludaN0yUNpWF4aFvT1GAHbjGpBQwkp4lZ2Tq1u8cCB0tTet 9GT4IS9fs4eGtXGkTl5aDprtI+MnZgF12G513yh3Ny9LlJU8Xg5u6s+ExZdLcQDA AHPye2AXnU0zsL9nmcQy0jGsv/lxkNZY19j6btIN1bLLvki0VYjUYSjfy/pMZZ2k nqmFKPIDRMfVqgJHJPkCh1o/sJU0OIvmfYA6OpY9lT4O9CHd00UXBoG4we938Hxm KlskEFK8ucO1j1iCgA6j2W1fJMeMskELMDhKPohyvbxlaJyWbkczc0Bv7G5pr19J 5w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yUvdnp oJwPRzXPxDZkv1rG4dmLCfYIfChuY8x0ZL3OE=; b=cwGjBewAXsa46JeIV4OIRV WXU2t1eAPKvQWSMckYY2BEgVnbcIcKdEyieTy3CzAJhTiNiySCUQXfttYrlQjYnF mtfV0C1HHPFUM4MotCK8Szovl6LRCKfsxj4T6IpVpe6RWC9TbmTbYYEPu7sFs9yS b6rJwoPxomp7VHnDWVQBURSpJ8c5P7vPDI1CDCpRU4xeHhwcBnAjbVL6YyNVcQgp ZKIVRF1cZII5ooMst9E1cg4E3YNeBy2GH2qLUcV17ALargrKvsW+zhipCCkFNwme HS2EsZOPEOOUEfEgfdCZduigH0sNxE4T8v2y478D9fTJT4F8mmgmelBitsZl7vww ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeejgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpedugefhlefghfeigeegueekhfekjeeludevuedvfeehvdeg tdejueetffeufefgtdenucffohhmrghinhepfhgrshhtmhgrihhlrdhhvghlphenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E7CF23605A5; Wed, 24 Feb 2021 06:39:32 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
In-Reply-To: 
References:      
Date: Wed, 24 Feb 2021 22:39:11 +1100
From: "Bron Gondwana" 
To: "Warren Parad" , "Carsten Bormann" 
Cc: "Phillip Hallam-Baker" , "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/alternative; boundary=6413e81e2f034588a4c333892e4c5dd8
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 11:39:57 -0000

--6413e81e2f034588a4c333892e4c5dd8
Content-Type: text/plain

On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
> I would prefer Bron to answer that question, as they are the one who started this email thread.

You can also use he when talking about me, or she for that matter - I do enough group fitness classes where it's roughly assumed that the entire class is female, and I have an ambiguous enough name that I'm used to it.  Most people use "he" most of the time.

> However let's look at GNAP, I've honestly been struggling to understand at least one fully documented case that GNAP supports. It seems in every document the only thing that is clear is GNAP wants to allow "everything", doesn't actually talk about an example.

That's my biggest fear for GNAP - it too will try to be everything to everybody and wind up being nothing to nobody because the super flexible "everything protocol" is the same as no protocol at all, since you have to special-case everybody you talk to anyway.

> By NxM, I assume we mean that the end user or client is free to select whichever AS they want, in a way which the RS can verify the AS credential and the user identity, without the RS having to (and really without the ability to limit) which AS are allowed.

Let's get down to use cases then, rather than talking in abstracts.

I'm an end user with a copy of {The Bat email client} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular open standard.  I want to be able to authenticate to each of those services without saving my plaintext passwords on my hard disk where the next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leaving me destitute.

But, {The Bat} doesn't have a trusted client cert from my isp, because who does - so there's no good protocol for me - it's either plaintext auth, or it's some architecture astronaut multi-party nonsense that's massively over specified and doesn't work half the time.  So I write a plain text password on a post-it note which is lying in the dust under my monitor because the glue has gone bad, and I hope I never accidentally click "remember me" when I type it in.

That's been the reality of the end user experience for very many years.

NxM means that you can authenticate an arbitrary client against an arbitrary server so long as they are both speaking a known public protocol, without needing to build a trust relationship between the client vendor and the server vendor first.

Any "trust relationship" is made through a user both who trusts the client and trusts the server, and it's not transitive over to other users of the same client and the same server.  The client author doesn't need to get a signed "I trust you" from every single server, and the server author doesn't have to go identify every single client.

That's what NxM means to a user, the ability to use arbitrary clients with arbitrary servers so long as they both implement a documented protocol.  Interoperability.

OAuth has not given interoperability in the NxM sense outside some simple web use cases.  They're nice and all, but they don't tend to be useful with open protocols - OAuth gets used for accessing proprietary API endpoints after getting an access key for a single provider.  At least you get Nx1 or 1xM out of it depending who's the N and who's the M, and maybe some of your code can rhyme so you're not doing everything from scratch each time.

This is the sorry story of real open protocols.  The floor for true interoperability is still username + password over cleartext, over hopefully a TLS tunnel that's providing some level of protection.  Most so than a few years ago when Fastmail wrote our "starttls considered harmful"[1] objection to the IETF's habit at the time of putting a "STARTTLS" upgrade into an initially plaintext protocol, where an active intercepter could just strip the "I support STARTTLS" indicator from the protocol and convince the client to send the credentials in the clear.

We're a little better mostly these days, but it's still a tirefire, and in my heart I do hold the OAuth working group's squatting on this area of the landscape while failing to address this burning need partially responsible.  The result (as Phillip pointed out upthread) has been a consolidation towards a few big players - because NxM becomes tractable when you reduce the N and M to small enough numbers.

Bron.

[1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--6413e81e2f034588a4c333892e4c5dd8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
=
I would prefer Bron to answer that question, as they are the one who sta=
rted this email thread.

You can also use he when talking about me, or she fo=
r that matter - I do enough group fitness classes where it's roughly ass=
umed that the entire class is female, and I have an ambiguous enough nam=
e that I'm used to it.  Most people use "he" most of the time.
<=
/div>

However let's look at =
GNAP, I've honestly been struggling to understand at least one fully doc=
umented case that GNAP supports. It seems in every document the only thi=
ng that is clear is GNAP wants to allow "everything", doesn't actually t=
alk about an example.

That's my bigges=
t fear for GNAP - it too will try to be everything to everybody and wind=
 up being nothing to nobody because the super flexible "everything proto=
col" is the same as no protocol at all, since you have to special-case e=
verybody you talk to anyway.
=

By NxM, I assume we mean that the end user or client is free to s=
elect whichever AS they want, in a way which the RS can verify the AS cr=
edential and the user identity, without the RS having to (and really wit=
hout the ability to limit) which AS are allowed.

Let's get down to use cases then, rather than talking in abst=
racts.

I'm an end user with a copy of {The Bat email clien=
t} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It su=
pports {POP3}, a widely popular open standard.  I want to be able t=
o authenticate to each of those services without saving my plaintext pas=
swords on my hard disk where the next {Windows ME} virus will exfiltrate=
 them to {Noextraditionistan} and all my {Dogecoin} will then be exfiltr=
ated from my {Paybuddy} account, leaving me destitute.

Bu=
t, {The Bat} doesn't have a trusted client cert from my isp, because who=
 does - so there's no good protocol for me - it's either plaintext auth,=
 or it's some architecture astronaut multi-party nonsense that's massive=
ly over specified and doesn't work half the time.  So I write a pla=
in text password on a post-it note which is lying in the dust under my m=
onitor because the glue has gone bad, and I hope I never accidentally cl=
ick "remember me" when I type it in.

That's been the real=
ity of the end user experience for very many years.

NxM mea=
ns that you can authenticate an arbitrary client against an arbitrary se=
rver so long as they are both speaking a known public protocol, without =
needing to build a trust relationship between the client vendor and the =
server vendor first.

Any "trust relationship" is made thr=
ough a user both who trusts the client and trusts the server, and it's n=
ot transitive over to other users of the same client and the same server=
.  The client author doesn't need to get a signed "I trust you" fro=
m every single server, and the server author doesn't have to go identify=
 every single client.

That's what NxM means to a user, th=
e ability to use arbitrary clients with arbitrary servers so long as the=
y both implement a documented protocol.  Interoperability.

OAuth has not given interoperability in the NxM sense outside som=
e simple web use cases.  They're nice and all, but they don't tend =
to be useful with open protocols - OAuth gets used for accessing proprie=
tary API endpoints after getting an access key for a single provider.&nb=
sp; At least you get Nx1 or 1xM out of it depending who's the N and who'=
s the M, and maybe some of your code can rhyme so you're not doing every=
thing from scratch each time.

This is the sorry story of =
real open protocols.  The floor for true interoperability is still =
username + password over cleartext, over hopefully a TLS tunnel that's p=
roviding some level of protection.  Most so than a few years ago wh=
en Fastmail wrote our "starttls considered harmful"[1] objection to the =
IETF's habit at the time of putting a "STARTTLS" upgrade into an initial=
ly plaintext protocol, where an active intercepter could just strip the =
"I support STARTTLS" indicator from the protocol and convince the client=
 to send the credentials in the clear.

We're a little bet=
ter mostly these days, but it's still a tirefire, and in my heart I do h=
old the OAuth working group's squatting on this area of the landscape wh=
ile failing to address this burning need partially responsible.  Th=
e result (as Phillip pointed out upthread) has been a consolidation towa=
rds a few big players - because NxM becomes tractable when you reduce th=
e N and M to small enough numbers.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--6413e81e2f034588a4c333892e4c5dd8--


From nobody Wed Feb 24 03:55:29 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968373A1487 for ; Wed, 24 Feb 2021 03:55:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fF8ITgoHeUB for ; Wed, 24 Feb 2021 03:55:24 -0800 (PST)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DA43A148F for ; Wed, 24 Feb 2021 03:55:24 -0800 (PST)
Received: by mail-ej1-x631.google.com with SMTP id t11so2573249ejx.6 for ; Wed, 24 Feb 2021 03:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=BZpDP22elGxf+Oy5axkpyEkwqQlq+bExgFIhOdRptbE=; b=P/hIU159i58J4KYg7WUvYF8OuMaYk930t7VY8dTfvFgpx4ZrZz469/5Md4FdNeDPW9 VAfQdnB1TD6F9U9jLwiVPrz43b7IXSmoBbp7vv2+vSkqK1MrffH1vt95V0oSXkr+4NyT CSxWfTD3qrgdXkxYtw5WjtIf34/9PSWrHW+UhC8PNwDY2iDQ79HY8Y+gC0XOpR9mDUQm KW/2u4v7rbcFIzxvqTc4mY60fOtaRqlJA56U8pFbPIj1rLI1A9e0MXaDAZ+1CvzWsByD R1VE9CI5ZKMehJvTYOoqODomG6dKARroN1lhLg2LjANqffr7XZOlNoeKzdbQR8CpjKoh H95Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BZpDP22elGxf+Oy5axkpyEkwqQlq+bExgFIhOdRptbE=; b=acDAtZq9fFdrs2ah8m5FmnfmCyof0uOugVgbMctKrzvyePMVU39ITnlQPLKtPPbfmt QPzGD0MUI4bSESuV+RulFhcNESfH/3m5DWP4R0XrF+Nw46mPtmak0hh+DRVs2xht26Zk ZFFyzJhjn7UirrD855170Lv2bh4CqRPFdEIrHkfQ6fQEZHqFXXm4l2IVPDIepPqolrnr CizOVlwgaaf4QU2RhrSoRwCUXjqRTgzZ0+ylKq+jD0fWqwVikYgTYtFI9sglJUp2uoT0 cvGjOYAG6Emy25LzNTRM5rbkfd8RKSm1M10mfvZmw/V6Y1DipQ+nKuL4d+0EoJ4KsVcn iLTg==
X-Gm-Message-State: AOAM530cigVM4uZL7lwZoqX9v0H55Rftm6PeVwzhk4ApnUCAIq/b6zun fGWtl2n7vqjHB+TGDRpTht4bnBETwfiiUu0F19YVO1oCg/c=
X-Google-Smtp-Source: ABdhPJxYbfQC+DwwBWXiJ/CftmqYdn00zbTVXvRsL5BCrrNqZOWoaf7Tdpc8oSpV8nK1/X3Qf9Kfz80+vKS6hRB2pBs=
X-Received: by 2002:a17:906:a896:: with SMTP id ha22mr2955675ejb.503.1614167722270;  Wed, 24 Feb 2021 03:55:22 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jerry Leyendecker 
Date: Wed, 24 Feb 2021 05:55:13 -0600
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b1a3ba05bc13b5ed"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 148, Issue 78
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 11:55:28 -0000

--000000000000b1a3ba05bc13b5ed
Content-Type: text/plain; charset="UTF-8"

My Name is Jerry L Leyendecker. could you please explain to me how, why,
and what am I suppose to be doing as litigating OAuth please. That would be
great.

On Wed, Feb 24, 2021, 5:41 AM  wrote:

> Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: We appear to still be litigating OAuth, oops (Carsten Bormann)
>    2. Send me the autherized paperwork (Jerry Leyendecker)
>    3. Re: We appear to still be litigating OAuth, oops (Warren Parad)
>    4. Re: We appear to still be litigating OAuth, oops (Bron Gondwana)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Feb 2021 11:36:13 +0100
> From: Carsten Bormann 
> To: Warren Parad 
> Cc: Bron Gondwana , Phillip Hallam-Baker
>         , "oauth@ietf.org" ,
>         ietf@ietf.org
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID: 
> Content-Type: text/plain;       charset=utf-8
>
> On 2021-02-24, at 11:22, Warren Parad 
> wrote:
> >
> > Should we solve the NxM problem, and if so, how do you propose we do
> that?
>
> Let GNAP do that.
>
> Gr??e, Carsten
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Feb 2021 04:41:40 -0600
> From: Jerry Leyendecker 
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Send me the autherized paperwork
> Message-ID:
>          64B6sJZODa8Kj0TNzkFAwB5_jdU5SBhUZcmg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Approved
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/6c850fa3/attachment.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 24 Feb 2021 12:04:40 +0100
> From: Warren Parad 
> To: Carsten Bormann 
> Cc: Bron Gondwana , Phillip Hallam-Baker
>         ,  "oauth@ietf.org" ,
>         ietf@ietf.org
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID:
>         <
> CAJot-L1e8GegjXjADRQ87tGqnSREoO4bEKLX+kPkZFsQpevGQA@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I would prefer Bron to answer that question, as they are the one who
> started this email thread.
>
> However let's look at GNAP, I've honestly been struggling to understand at
> least one fully documented case that GNAP supports. It seems in every
> document the only thing that is clear is GNAP wants to allow "everything",
> doesn't actually talk about an example.
>
> By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credential
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
>
> Would you agree with that statement?
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Feb 24, 2021 at 11:36 AM Carsten Bormann  wrote:
>
> > On 2021-02-24, at 11:22, Warren Parad  >
> > wrote:
> > >
> > > Should we solve the NxM problem, and if so, how do you propose we do
> > that?
> >
> > Let GNAP do that.
> >
> > Gr??e, Carsten
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/dbb69cff/attachment.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 24 Feb 2021 22:39:11 +1100
> From: "Bron Gondwana" 
> To: "Warren Parad" , "Carsten Bormann"
>         
> Cc: "Phillip Hallam-Baker" , "oauth@ietf.org"
>         , ietf@ietf.org
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID: <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
> > I would prefer Bron to answer that question, as they are the one who
> started this email thread.
>
> You can also use he when talking about me, or she for that matter - I do
> enough group fitness classes where it's roughly assumed that the entire
> class is female, and I have an ambiguous enough name that I'm used to it.
> Most people use "he" most of the time.
>
> > However let's look at GNAP, I've honestly been struggling to understand
> at least one fully documented case that GNAP supports. It seems in every
> document the only thing that is clear is GNAP wants to allow "everything",
> doesn't actually talk about an example.
>
> That's my biggest fear for GNAP - it too will try to be everything to
> everybody and wind up being nothing to nobody because the super flexible
> "everything protocol" is the same as no protocol at all, since you have to
> special-case everybody you talk to anyway.
>
> > By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credential
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
>
> Let's get down to use cases then, rather than talking in abstracts.
>
> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
>
> But, {The Bat} doesn't have a trusted client cert from my isp, because who
> does - so there's no good protocol for me - it's either plaintext auth, or
> it's some architecture astronaut multi-party nonsense that's massively over
> specified and doesn't work half the time.  So I write a plain text password
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" when
> I type it in.
>
> That's been the reality of the end user experience for very many years.
>
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
>
> Any "trust relationship" is made through a user both who trusts the client
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
>
> That's what NxM means to a user, the ability to use arbitrary clients with
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
>
> OAuth has not given interoperability in the NxM sense outside some simple
> web use cases.  They're nice and all, but they don't tend to be useful with
> open protocols - OAuth gets used for accessing proprietary API endpoints
> after getting an access key for a single provider.  At least you get Nx1 or
> 1xM out of it depending who's the N and who's the M, and maybe some of your
> code can rhyme so you're not doing everything from scratch each time.
>
> This is the sorry story of real open protocols.  The floor for true
> interoperability is still username + password over cleartext, over
> hopefully a TLS tunnel that's providing some level of protection.  Most so
> than a few years ago when Fastmail wrote our "starttls considered
> harmful"[1] objection to the IETF's habit at the time of putting a
> "STARTTLS" upgrade into an initially plaintext protocol, where an active
> intercepter could just strip the "I support STARTTLS" indicator from the
> protocol and convince the client to send the credentials in the clear.
>
> We're a little better mostly these days, but it's still a tirefire, and in
> my heart I do hold the OAuth working group's squatting on this area of the
> landscape while failing to address this burning need partially
> responsible.  The result (as Phillip pointed out upthread) has been a
> consolidation towards a few big players - because NxM becomes tractable
> when you reduce the N and M to small enough numbers.
>
> Bron.
>
> [1]
> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/c559b617/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 148, Issue 78
> **************************************
>

--000000000000b1a3ba05bc13b5ed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


M=
y Name is Jerry L Leyendecker. could you please explain to me how, why, and=
 what am I suppose to be doing as litigating OAuth please. That would be gr=
eat.=C2=A0

On Wed, Feb 24, 2021, 5:41 AM  <oauth-request@ietf.org> wrote:
Send OAuth mailing list submissions to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/oauth

or, via email, send a message with subject or body 'help' to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org



You can reach the person managing the list at

=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of OAuth digest..."





Today's Topics:



=C2=A0 =C2=A01. Re: We appear to still be litigating OAuth, oops (Carsten B=
ormann)

=C2=A0 =C2=A02. Send me the autherized paperwork (Jerry Leyendecker)

=C2=A0 =C2=A03. Re: We appear to still be litigating OAuth, oops (Warren Pa=
rad)

=C2=A0 =C2=A04. Re: We appear to still be litigating OAuth, oops (Bron Gond=
wana)





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



Message: 1

Date: Wed, 24 Feb 2021 11:36:13 +0100

From: Carsten Bormann <cabo@tzi.org>

To: Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org>
Cc: Bron Gondwana <brong@fastmailteam.com>, Phillip Hallam-Ba=
ker

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <phill@hallambaker.com>, "oauth@i=
etf.org" <oauth@ietf.org>,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf@ietf.org

Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Message-ID: <DAB127D7-809F-4EC2-A043-9B15E2DB8=
E07@tzi.org>

Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3Dutf-8



On 2021-02-24, at 11:22, Warren Parad <wparad=3D40rhosys.ch@dmar=
c.ietf.org> wrote:

> 

> Should we solve the NxM problem, and if so, how do you propose we do t=
hat?



Let GNAP do that.



Gr??e, Carsten







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



Message: 2

Date: Wed, 24 Feb 2021 04:41:40 -0600

From: Jerry Leyendecker <jleyendeckeratx@gmail.com>

To: =
oauth@ietf.org

Subject: [OAUTH-WG] Send me the autherized paperwork

Message-ID:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CABv2g9z5TL-6z=3D64B6sJZODa8Kj0TNzkFAwB5_jdU5SBhUZcmg@mail.gmail.com>

Content-Type: text/plain; charset=3D"utf-8"



Approved

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2021=
0224/6c850fa3/attachment.htm>



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



Message: 3

Date: Wed, 24 Feb 2021 12:04:40 +0100

From: Warren Parad <wparad@rhosys.ch>

To: Carsten Bormann <cabo@tzi.org>

Cc: Bron Gondwana <brong@fastmailteam.com>, Phillip Hallam-Ba=
ker

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <phill@hallambaker.com>,=C2=A0 &qu=
ot;o=
auth@ietf.org" <oauth@ietf.org>,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf@ietf.org

Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Message-ID:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAJot-L1e8GegjXjADRQ87tGqnSREoO4bEKLX+kPkZFsQpevGQA@mail.gmail.com>

Content-Type: text/plain; charset=3D"utf-8"



I would prefer Bron to answer that question, as they are the one who

started this email thread.



However let's look at GNAP, I've honestly been struggling to unders=
tand at

least one fully documented case that GNAP supports. It seems in every

document the only thing that is clear is GNAP wants to allow "everythi=
ng",

doesn't actually talk about an example.



By NxM, I assume we mean that the end user or client is free to select

whichever AS they want, in a way which the RS can verify the AS credential<=
br>
and the user identity, without the RS having to (and really without the

ability to limit) which AS are allowed.



Would you agree with that statement?



Warren Parad



Founder, CTO

Secure your user data with IAM authorization as a service. Implement

Authress <https://authress.io/>.





On Wed, Feb 24, 2021 at 11:36 AM Carsten Bormann <cabo@tzi.org> wrote:<=
br>


> On 2021-02-24, at 11:22, Warren Parad <wparad=3D40rhosys.ch=
@dmarc.ietf.org>

> wrote:

> >

> > Should we solve the NxM problem, and if so, how do you propose we=
 do

> that?

>

> Let GNAP do that.

>

> Gr??e, Carsten

>

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2021=
0224/dbb69cff/attachment.htm>



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



Message: 4

Date: Wed, 24 Feb 2021 22:39:11 +1100

From: "Bron Gondwana" <brong@fastmailteam.com>

To: "Warren Parad" <wparad@rhosys.ch>, "Carsten Borm=
ann"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <cabo@tzi.org>

Cc: "Phillip Hallam-Baker" <phill@hallambaker.com>, =
"oauth@ietf.org"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <oauth@ietf.org>, ietf@ietf.org

Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Message-ID: <66be0ffe-a638-45a0-ba05-=
1585ea02e6bf@www.fastmail.com>

Content-Type: text/plain; charset=3D"us-ascii"



On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:

> I would prefer Bron to answer that question, as they are the one who s=
tarted this email thread.



You can also use he when talking about me, or she for that matter - I do en=
ough group fitness classes where it's roughly assumed that the entire c=
lass is female, and I have an ambiguous enough name that I'm used to it=
.=C2=A0 Most people use "he" most of the time.



> However let's look at GNAP, I've honestly been struggling to u=
nderstand at least one fully documented case that GNAP supports. It seems i=
n every document the only thing that is clear is GNAP wants to allow "=
everything", doesn't actually talk about an example.



That's my biggest fear for GNAP - it too will try to be everything to e=
verybody and wind up being nothing to nobody because the super flexible &qu=
ot;everything protocol" is the same as no protocol at all, since you h=
ave to special-case everybody you talk to anyway.



> By NxM, I assume we mean that the end user or client is free to select=
 whichever AS they want, in a way which the RS can verify the AS credential=
 and the user identity, without the RS having to (and really without the ab=
ility to limit) which AS are allowed.



Let's get down to use cases then, rather than talking in abstracts.



I'm an end user with a copy of {The Bat email client} and I want to con=
nect it to {Gmail} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely=
 popular open standard.=C2=A0 I want to be able to authenticate to each of =
those services without saving my plaintext passwords on my hard disk where =
the next {Windows ME} virus will exfiltrate them to {Noextraditionistan} an=
d all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, le=
aving me destitute.



But, {The Bat} doesn't have a trusted client cert from my isp, because =
who does - so there's no good protocol for me - it's either plainte=
xt auth, or it's some architecture astronaut multi-party nonsense that&=
#39;s massively over specified and doesn't work half the time.=C2=A0 So=
 I write a plain text password on a post-it note which is lying in the dust=
 under my monitor because the glue has gone bad, and I hope I never acciden=
tally click "remember me" when I type it in.



That's been the reality of the end user experience for very many years.=




NxM means that you can authenticate an arbitrary client against an arbitrar=
y server so long as they are both speaking a known public protocol, without=
 needing to build a trust relationship between the client vendor and the se=
rver vendor first.



Any "trust relationship" is made through a user both who trusts t=
he client and trusts the server, and it's not transitive over to other =
users of the same client and the same server.=C2=A0 The client author doesn=
't need to get a signed "I trust you" from every single serve=
r, and the server author doesn't have to go identify every single clien=
t.



That's what NxM means to a user, the ability to use arbitrary clients w=
ith arbitrary servers so long as they both implement a documented protocol.=
=C2=A0 Interoperability.



OAuth has not given interoperability in the NxM sense outside some simple w=
eb use cases.=C2=A0 They're nice and all, but they don't tend to be=
 useful with open protocols - OAuth gets used for accessing proprietary API=
 endpoints after getting an access key for a single provider.=C2=A0 At leas=
t you get Nx1 or 1xM out of it depending who's the N and who's the =
M, and maybe some of your code can rhyme so you're not doing everything=
 from scratch each time.



This is the sorry story of real open protocols.=C2=A0 The floor for true in=
teroperability is still username + password over cleartext, over hopefully =
a TLS tunnel that's providing some level of protection.=C2=A0 Most so t=
han a few years ago when Fastmail wrote our "starttls considered harmf=
ul"[1] objection to the IETF's habit at the time of putting a &quo=
t;STARTTLS" upgrade into an initially plaintext protocol, where an act=
ive intercepter could just strip the "I support STARTTLS" indicat=
or from the protocol and convince the client to send the credentials in the=
 clear.



We're a little better mostly these days, but it's still a tirefire,=
 and in my heart I do hold the OAuth working group's squatting on this =
area of the landscape while failing to address this burning need partially =
responsible.=C2=A0 The result (as Phillip pointed out upthread) has been a =
consolidation towards a few big players - because NxM becomes tractable whe=
n you reduce the N and M to small enough numbers.



Bron.



[1] https://=
www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS


--

=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd

=C2=A0 brong@fastmailteam.com



-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2021=
0224/c559b617/attachment.htm>



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



Subject: Digest Footer



_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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





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



End of OAuth Digest, Vol 148, Issue 78

**************************************




--000000000000b1a3ba05bc13b5ed--


From nobody Wed Feb 24 04:09:31 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CA33A14C0 for ; Wed, 24 Feb 2021 04:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSHfQfgPLwuA for ; Wed, 24 Feb 2021 04:09:26 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3248F3A14BC for ; Wed, 24 Feb 2021 04:09:26 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id n14so1746232iog.3 for ; Wed, 24 Feb 2021 04:09:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GbAQR5VKohjmNQNdWyyof8g+21qbDiT3BsoJpZNFPoE=; b=F1AaizDukA7drvYMMgfwmgO2DN5/8f2QEjUFVqWXNYoBBbtZC8gfwOrA8Ila2FvXw3 KGCaZFXZTCKYyBpBocsBbZiNTBm3qcjxvhJzqvLL4zUWxD5gBY5MwHo46RutMSCpnCqg nVjsug/yKFx1zQt0vGsyerzSNJPeSLuDl9nZNKspAFO/P5/VOJkWVVJsACjEhxB/qjlm K+NRiGj/lofK3Ynnq9xBOPaBWywijryKY82GvJW1At3Fu4OjSkrclYNqs8F8FzVLQGTJ ESugoDIMSkcfGv0XwMpW+V2vx+LpS8t/YtSxXCk0Qeq+O2X6FCkRQvcgvF9gYAlaJap2 zFYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GbAQR5VKohjmNQNdWyyof8g+21qbDiT3BsoJpZNFPoE=; b=N2aYGvgK01HdBh4EmSJOSeiT9hZ1yXl9eSyegpl5DYX6V63oEGbZKicNZ+1lhncXDH wCmdBn3wdCZMA+u7bjm1XEn2otNxilFhfEcwVSs+UJHTggyrg8MSw4a6XKsqHIEHdMqE 2LXCi3+auVrhZRowGqqBMIri5U6y+jfoVx56mIqCj/c67UytXbfbb0hHHBjbnkDfOD9X paPnZWb0DqtM5i2BRhyVLcJIjekY92GwWMSWC5EoR87Wu7Zgav7ay4+KcV1nbG1cPf6D WM6P4yGrzNjouMK+LdurpygwJ6PfH7K4NsESemys7kPlv0kywH7GlavLINXv+LzW9AA0 MWzg==
X-Gm-Message-State: AOAM532Kj5OdzEXmy3HSAG5C6Dtxbnm55F3ZF2pDfJ09HxmGlLQ40f3C Q2/a2NQM9XtvugUw71VrgTqm5aogauMr/WlZaPkv
X-Google-Smtp-Source: ABdhPJyuzIg4fVLDRlZHCSHKIxVAtJtdmyt7hMqw+z2cbsfvvzDjV6DaDnWqkFOMxgPxCcFlv0TWWFciaZzCL2MntXo=
X-Received: by 2002:a05:6602:130a:: with SMTP id h10mr21944927iov.48.1614168565398;  Wed, 24 Feb 2021 04:09:25 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
In-Reply-To: <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
From: Warren Parad 
Date: Wed, 24 Feb 2021 13:09:14 +0100
Message-ID: 
To: Bron Gondwana 
Cc: Carsten Bormann , Phillip Hallam-Baker ,  "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f2d76505bc13e74a"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 12:09:29 -0000

--000000000000f2d76505bc13e74a
Content-Type: text/plain; charset="UTF-8"

(I tend to trend lightly in the pronoun area, mostly because I'm shocked
that openid included gender but not pronouns)

I hadn't heard that to be called the NxM problem, so that definitely
cleared up the potential confusion (at least for me).

I think GNAPs lack of clarity is a non sequitur for the handling or not of
the multitrust arbitrary-client with arbitrary-service, however it's lack
of clarity for me prevents me from knowing whether GNAP actually seeks to
solve this problem. So from an OAuth WG perspective we can still ask:

*Is this or should this problem be left to GNAP to solve, or is an OAuth WG
responsibility?*

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana 
wrote:

> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>
> I would prefer Bron to answer that question, as they are the one who
> started this email thread.
>
>
> You can also use he when talking about me, or she for that matter - I do
> enough group fitness classes where it's roughly assumed that the entire
> class is female, and I have an ambiguous enough name that I'm used to it.
> Most people use "he" most of the time.
>
> However let's look at GNAP, I've honestly been struggling to understand at
> least one fully documented case that GNAP supports. It seems in every
> document the only thing that is clear is GNAP wants to allow "everything",
> doesn't actually talk about an example.
>
>
> That's my biggest fear for GNAP - it too will try to be everything to
> everybody and wind up being nothing to nobody because the super flexible
> "everything protocol" is the same as no protocol at all, since you have to
> special-case everybody you talk to anyway.
>
> By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credential
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
>
>
> Let's get down to use cases then, rather than talking in abstracts.
>
> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
>
> But, {The Bat} doesn't have a trusted client cert from my isp, because who
> does - so there's no good protocol for me - it's either plaintext auth, or
> it's some architecture astronaut multi-party nonsense that's massively over
> specified and doesn't work half the time.  So I write a plain text password
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" when
> I type it in.
>
> That's been the reality of the end user experience for very many years.
>
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
>
> Any "trust relationship" is made through a user both who trusts the client
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
>
> That's what NxM means to a user, the ability to use arbitrary clients with
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
>
> OAuth has not given interoperability in the NxM sense outside some simple
> web use cases.  They're nice and all, but they don't tend to be useful with
> open protocols - OAuth gets used for accessing proprietary API endpoints
> after getting an access key for a single provider.  At least you get Nx1 or
> 1xM out of it depending who's the N and who's the M, and maybe some of your
> code can rhyme so you're not doing everything from scratch each time.
>
> This is the sorry story of real open protocols.  The floor for true
> interoperability is still username + password over cleartext, over
> hopefully a TLS tunnel that's providing some level of protection.  Most so
> than a few years ago when Fastmail wrote our "starttls considered
> harmful"[1] objection to the IETF's habit at the time of putting a
> "STARTTLS" upgrade into an initially plaintext protocol, where an active
> intercepter could just strip the "I support STARTTLS" indicator from the
> protocol and convince the client to send the credentials in the clear.
>
> We're a little better mostly these days, but it's still a tirefire, and in
> my heart I do hold the OAuth working group's squatting on this area of the
> landscape while failing to address this burning need partially
> responsible.  The result (as Phillip pointed out upthread) has been a
> consolidation towards a few big players - because NxM becomes tractable
> when you reduce the N and M to small enough numbers.
>
> Bron.
>
> [1]
> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
>

--000000000000f2d76505bc13e74a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=

On Wed, Feb 24, 2021 at 12:39 PM Bron=
 Gondwana <brong@fastmailteam.=
com> wrote:
On Wed, Feb 24, 2021, at 22=
:04, Warren Parad wrote:
I would prefer Bron to answer =
that question, as they are the one who started this email thread.
=


You can also use he wh=
en talking about me, or she for that matter - I do enough group fitness cla=
sses where it's roughly assumed that the entire class is female, and I =
have an ambiguous enough name that I'm used to it.=C2=A0 Most people us=
e "he" most of the time.

However let's look at GNAP, I've hones=
tly been struggling to understand at least one fully documented case that G=
NAP supports. It seems in every document the only thing that is clear is GN=
AP wants to allow "everything", doesn't actually talk about a=
n example.
That's my biggest fear for GNAP=
 - it too will try to be everything to everybody and wind up being nothing =
to nobody because the super flexible "everything protocol" is the=
 same as no protocol at all, since you have to special-case everybody you t=
alk to anyway.

By NxM, I assume we mean that the end user or client is free to select w=
hichever AS they want, in a way which the RS can verify the AS credential a=
nd the user identity, without the RS having to (and really without the abil=
ity to limit) which AS are allowed.

Let's=
 get down to use cases then, rather than talking in abstracts.

I&=
#39;m an end user with a copy of {The Bat email client} and I want to conne=
ct it to {Gmail} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely p=
opular open standard.=C2=A0 I want to be able to authenticate to each of th=
ose services without saving my plaintext passwords on my hard disk where th=
e next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and =
all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leav=
ing me destitute.

But, {The Bat} doesn't have a trusted clien=
t cert from my isp, because who does - so there's no good protocol for =
me - it's either plaintext auth, or it's some architecture astronau=
t multi-party nonsense that's massively over specified and doesn't =
work half the time.=C2=A0 So I write a plain text password on a post-it not=
e which is lying in the dust under my monitor because the glue has gone bad=
, and I hope I never accidentally click "remember me" when I type=
 it in.

That's been the reality of the end user experience fo=
r very many years.

NxM means that you can authenticate an arbitra=
ry client against an arbitrary server so long as they are both speaking a k=
nown public protocol, without needing to build a trust relationship between=
 the client vendor and the server vendor first.

Any "trust r=
elationship" is made through a user both who trusts the client and tru=
sts the server, and it's not transitive over to other users of the same=
 client and the same server.=C2=A0 The client author doesn't need to ge=
t a signed "I trust you" from every single server, and the server=
 author doesn't have to go identify every single client.

That=
's what NxM means to a user, the ability to use arbitrary clients with =
arbitrary servers so long as they both implement a documented protocol.=C2=
=A0 Interoperability.

<=
div style=3D"font-family:Arial">OAuth has not given interoperability in the=
 NxM sense outside some simple web use cases.=C2=A0 They're nice and al=
l, but they don't tend to be useful with open protocols - OAuth gets us=
ed for accessing proprietary API endpoints after getting an access key for =
a single provider.=C2=A0 At least you get Nx1 or 1xM out of it depending wh=
o's the N and who's the M, and maybe some of your code can rhyme so=
 you're not doing everything from scratch each time.

This is =
the sorry story of real open protocols.=C2=A0 The floor for true interopera=
bility is still username + password over cleartext, over hopefully a TLS tu=
nnel that's providing some level of protection.=C2=A0 Most so than a fe=
w years ago when Fastmail wrote our "starttls considered harmful"=
[1] objection to the IETF's habit at the time of putting a "STARTT=
LS" upgrade into an initially plaintext protocol, where an active inte=
rcepter could just strip the "I support STARTTLS" indicator from =
the protocol and convince the client to send the credentials in the clear.<=
br>

We're a little better mostly these days, but it's still a=
 tirefire, and in my heart I do hold the OAuth working group's squattin=
g on this area of the landscape while failing to address this burning need =
partially responsible.=C2=A0 The result (as Phillip pointed out upthread) h=
as been a consolidation towards a few big players - because NxM becomes tra=
ctable when you reduce the N and M to small enough numbers.

Bron.=



--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd
<=
/div>




--000000000000f2d76505bc13e74a--


From nobody Wed Feb 24 04:15:45 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4AE3A14CB; Wed, 24 Feb 2021 04:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level: 
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BHs9qQcZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L1PZvvEa
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnOBF8Lmmr0n; Wed, 24 Feb 2021 04:15:39 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63763A14C6; Wed, 24 Feb 2021 04:15:39 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 18C3AD3D; Wed, 24 Feb 2021 07:15:37 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 07:15:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=CfUi I2T4kBowliICxECW3T81QtAEzSdAnul5DLO/Yt0=; b=BHs9qQcZu0eRO1yPQCmz bZRh+/c/LfBRDNHu3JPbRx6AbohLaeZ9fmkOeGE4dlmFWY88ZYd3NCHR4aQjF+ii oy9rQ4nSlxpxhFPAWmBtjj1U2eoHuGMBPlU2gh7vhUdBx/Es8sjT/VMPI/FGKDJF cYGjmeEiPFRlyNkQfnNkfxQnctK37kukj69a4Z/pV51KE3lglquGhOFSxIvNHQob VDImKpKTF2hagiJyLDTlZXUEYeST9viiqwyW6zWvBsKZ5ZSsaXR61mkLvSdbYt6i uV7G6xVPUZkK/gMSpZeeX+Ja081d2lto+Gza6FMEdE0x2RPgLlPd6ya0/r8D+S50 nA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=CfUiI2 T4kBowliICxECW3T81QtAEzSdAnul5DLO/Yt0=; b=L1PZvvEapIiCiCQZKZJQKp CslGu6eUh3Oj51+bz2LNWIYInK7NNqbMhxdWmuYgGrNJUc7vclw+JW8FRxjHyDAT ouxwqDh7PgxEcgJ4S5HRc5w4mHDWsHaAKIBbpvYUTzcEVTAZYzSzmhCCbAgNenTV LvmRQnH/r5LZMMHMh98KB5L3eINq+0tTXuvmoX0NunwVUTqdyRiLOvyUIeFq/RLG 5qbwKp6qhy29xuJ5DdGcnNveBBQXiJBBsRKsd2EHiB9Anb7Yokk7JcS/vbZi4cdI 7ewc5LavfaLYoOb0YGvSMx+O/xdzyF5JDq7El+yG2xET96phVbhoFOOU7s/kx1Xw ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeejgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenog fuuhhsphgvtghtkfhmghffohhmrghinhculdeftddmnecujfgurhepofgfggfkjghffffh vffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoe gsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhep ieevffejudeiheffudetieejgeevfefhheehteegtdeghfefjeejledugeehieefnecuff homhgrihhnpegruhhthhhrvghsshdrihhopdhfrghsthhmrghilhdrhhgvlhhpnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfh grshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 800093605A4; Wed, 24 Feb 2021 07:15:35 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>
In-Reply-To: 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> 
Date: Wed, 24 Feb 2021 23:15:15 +1100
From: "Bron Gondwana" 
To: "Warren Parad" 
Cc: "Carsten Bormann" , "Phillip Hallam-Baker" , "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/alternative; boundary=15c3934dff084aa3a448abcc46af34e9
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 12:15:43 -0000

--15c3934dff084aa3a448abcc46af34e9
Content-Type: text/plain



On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
> (I tend to trend lightly in the pronoun area, mostly because I'm shocked that openid included gender but not pronouns)
> 
> I hadn't heard that to be called the NxM problem, so that definitely cleared up the potential confusion (at least for me).
> 
> I think GNAPs lack of clarity is a non sequitur for the handling or not of the multitrust arbitrary-client with arbitrary-service, however it's lack of clarity for me prevents me from knowing whether GNAP actually seeks to solve this problem. So from an OAuth WG perspective we can still ask:
> 
> *Is this or should this problem be left to GNAP to solve, or is an OAuth WG responsibility?*

Honestly I think the problem space is the whole ietf's responsibility. Protocols that allow an end user to safely transfer data between two parties that don't have a pre-existing trust relationship are a key part of enabling user freedom and user choice.

Bron.

> 

> *Warren Parad*

> Founder, CTO

> Secure your user data with IAM authorization as a service. Implement Authress .
> 
> 
> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana  wrote:
>> __
>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>>> I would prefer Bron to answer that question, as they are the one who started this email thread.
>> 
>> You can also use he when talking about me, or she for that matter - I do enough group fitness classes where it's roughly assumed that the entire class is female, and I have an ambiguous enough name that I'm used to it.  Most people use "he" most of the time.
>> 
>>> However let's look at GNAP, I've honestly been struggling to understand at least one fully documented case that GNAP supports. It seems in every document the only thing that is clear is GNAP wants to allow "everything", doesn't actually talk about an example.
>> 
>> That's my biggest fear for GNAP - it too will try to be everything to everybody and wind up being nothing to nobody because the super flexible "everything protocol" is the same as no protocol at all, since you have to special-case everybody you talk to anyway.
>> 
>>> By NxM, I assume we mean that the end user or client is free to select whichever AS they want, in a way which the RS can verify the AS credential and the user identity, without the RS having to (and really without the ability to limit) which AS are allowed.
>> 
>> Let's get down to use cases then, rather than talking in abstracts.
>> 
>> I'm an end user with a copy of {The Bat email client} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular open standard.  I want to be able to authenticate to each of those services without saving my plaintext passwords on my hard disk where the next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leaving me destitute.
>> 
>> But, {The Bat} doesn't have a trusted client cert from my isp, because who does - so there's no good protocol for me - it's either plaintext auth, or it's some architecture astronaut multi-party nonsense that's massively over specified and doesn't work half the time.  So I write a plain text password on a post-it note which is lying in the dust under my monitor because the glue has gone bad, and I hope I never accidentally click "remember me" when I type it in.
>> 
>> That's been the reality of the end user experience for very many years.
>> 
>> NxM means that you can authenticate an arbitrary client against an arbitrary server so long as they are both speaking a known public protocol, without needing to build a trust relationship between the client vendor and the server vendor first.
>> 
>> Any "trust relationship" is made through a user both who trusts the client and trusts the server, and it's not transitive over to other users of the same client and the same server.  The client author doesn't need to get a signed "I trust you" from every single server, and the server author doesn't have to go identify every single client.
>> 
>> That's what NxM means to a user, the ability to use arbitrary clients with arbitrary servers so long as they both implement a documented protocol.  Interoperability.
>> 
>> OAuth has not given interoperability in the NxM sense outside some simple web use cases.  They're nice and all, but they don't tend to be useful with open protocols - OAuth gets used for accessing proprietary API endpoints after getting an access key for a single provider.  At least you get Nx1 or 1xM out of it depending who's the N and who's the M, and maybe some of your code can rhyme so you're not doing everything from scratch each time.
>> 
>> This is the sorry story of real open protocols.  The floor for true interoperability is still username + password over cleartext, over hopefully a TLS tunnel that's providing some level of protection.  Most so than a few years ago when Fastmail wrote our "starttls considered harmful"[1] objection to the IETF's habit at the time of putting a "STARTTLS" upgrade into an initially plaintext protocol, where an active intercepter could just strip the "I support STARTTLS" indicator from the protocol and convince the client to send the credentials in the clear.
>> 
>> We're a little better mostly these days, but it's still a tirefire, and in my heart I do hold the OAuth working group's squatting on this area of the landscape while failing to address this burning need partially responsible.  The result (as Phillip pointed out upthread) has been a consolidation towards a few big players - because NxM becomes tractable when you reduce the N and M to small enough numbers.
>> 
>> Bron.
>> 
>> [1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
>> 
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com
>> 
>> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

--15c3934dff084aa3a448abcc46af34e9
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable




On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
(I tend to tr=
end lightly in the pronoun area, mostly because I'm shocked th=
at openid included gender but not pronouns)

I hadn't heard that to be called the NxM problem, so that definitely cl=
eared up the potential confusion (at least for me).

I think GNAPs lack of clarity is a non sequitur for the ha=
ndling or not of the multitrust arbitrary-client with arbitrary-service,=
 however it's lack of clarity for me prevents me from knowing whether GN=
AP actually seeks to solve this problem. So from an OAuth WG perspective=
 we can still ask:

Is this or shoul=
d this problem be left to GNAP to solve, or is an OAuth WG responsibilit=
y?

Honestly I think the prob=
lem space is the whole ietf's responsibility. Protocols that allow an en=
d user to safely transfer data between two parties that don't have a pre=
-existing trust relationship are a key part of enabling user freedom and=
 user choice.

Bron.


W=
arren Parad
Founder, CTO
Secure your user data with IAM authorization as a serv=
ice. Implement Authress<=
span class=3D"size" style=3D"font-size:x-small;">.


On We=
d, Feb 24, 2021 at 12:39 PM Bron Gondwana <brong@fastmailteam.com> wrote:
<=
/u>
On Wed, Feb 24, 2021=
, at 22:04, Warren Parad wrote:
I would prefer=
 Bron to answer that question, as they are the one who started this emai=
l thread.
=

You can also use he when talking about me, or she for that matter =
- I do enough group fitness classes where it's roughly assumed that the =
entire class is female, and I have an ambiguous enough name that I'm use=
d to it.  Most people use "he" most of the time.

However let's =
look at GNAP, I've honestly been struggling to understand at least one f=
ully documented case that GNAP supports. It seems in every document the =
only thing that is clear is GNAP wants to allow "everything", doesn't ac=
tually talk about an example.

That's m=
y biggest fear for GNAP - it too will try to be everything to everybody =
and wind up being nothing to nobody because the super flexible "everythi=
ng protocol" is the same as no protocol at all, since you have to specia=
l-case everybody you talk to anyway.

By NxM, I assume we mean that the end=
 user or client is free to select whichever AS they want, in a way which=
 the RS can verify the AS credential and the user identity, without the =
RS having to (and really without the ability to limit) which AS are allo=
wed.

<=
/div>
Let's get down to use cases then,=
 rather than talking in abstracts.

I'm an end user with a=
 copy of {The Bat email client} and I want to connect it to {Gmail} + {Y=
ahoo} + {My ISP}.  It supports {POP3}, a widely popular open standa=
rd.  I want to be able to authenticate to each of those services wi=
thout saving my plaintext passwords on my hard disk where the next {Wind=
ows ME} virus will exfiltrate them to {Noextraditionistan} and all my {D=
ogecoin} will then be exfiltrated from my {Paybuddy} account, leaving me=
 destitute.

But, {The Bat} doesn't have a trusted client =
cert from my isp, because who does - so there's no good protocol for me =
- it's either plaintext auth, or it's some architecture astronaut multi-=
party nonsense that's massively over specified and doesn't work half the=
 time.  So I write a plain text password on a post-it note which is=
 lying in the dust under my monitor because the glue has gone bad, and I=
 hope I never accidentally click "remember me" when I type it in.

That's been the reality of the end user experience for very man=
y years.

NxM means that you can authenticate an arbitrary=
 client against an arbitrary server so long as they are both speaking a =
known public protocol, without needing to build a trust relationship bet=
ween the client vendor and the server vendor first.

Any "tr=
ust relationship" is made through a user both who trusts the client and =
trusts the server, and it's not transitive over to other users of the sa=
me client and the same server.  The client author doesn't need to g=
et a signed "I trust you" from every single server, and the server autho=
r doesn't have to go identify every single client.

That's =
what NxM means to a user, the ability to use arbitrary clients with arbi=
trary servers so long as they both implement a documented protocol. =
; Interoperability.

OAuth has not given interoperability =
in the NxM sense outside some simple web use cases.  They're nice a=
nd all, but they don't tend to be useful with open protocols - OAuth get=
s used for accessing proprietary API endpoints after getting an access k=
ey for a single provider.  At least you get Nx1 or 1xM out of it de=
pending who's the N and who's the M, and maybe some of your code can rhy=
me so you're not doing everything from scratch each time.

This is the sorry story of real open protocols.  The floor for tru=
e interoperability is still username + password over cleartext, over hop=
efully a TLS tunnel that's providing some level of protection.  Mos=
t so than a few years ago when Fastmail wrote our "starttls considered h=
armful"[1] objection to the IETF's habit at the time of putting a "START=
TLS" upgrade into an initially plaintext protocol, where an active inter=
cepter could just strip the "I support STARTTLS" indicator from the prot=
ocol and convince the client to send the credentials in the clear.

We're a little better mostly these days, but it's still a tire=
fire, and in my heart I do hold the OAuth working group's squatting on t=
his area of the landscape while failing to address this burning need par=
tially responsible.  The result (as Phillip pointed out upthread) h=
as been a consolidation towards a few big players - because NxM becomes =
tractable when you reduce the N and M to small enough numbers.
=


Bron.


--
  Br=
on Gondwana, CEO, Fastmail Pty Ltd



--
=

  Bron Gondwana, CEO, Fastmail Pty Ltd
=

  brong@fastmailteam.com


--15c3934dff084aa3a448abcc46af34e9--


From nobody Wed Feb 24 04:21:04 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CF13A14DC for ; Wed, 24 Feb 2021 04:21:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYvgeaXmycky for ; Wed, 24 Feb 2021 04:21:00 -0800 (PST)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D0A3A14DA for ; Wed, 24 Feb 2021 04:20:59 -0800 (PST)
Received: by mail-ej1-x629.google.com with SMTP id u20so2695857ejb.7 for ; Wed, 24 Feb 2021 04:20:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ktmwHnKmyU7W+hV+tY55GMfwwXuI32BXDG1r+dDvJuI=; b=HmujXtWKGZ81JxOKJ3SrcZJgP1rmyQelzLDoD4np6NgWiqwQOCR2iMlA2zOQrpRI6r KAg7n72sZjSOQB39OCfhRKNWFvAyenccbllYksTD27m4PoLysEhHMunV4NwTiejdC4wI 0G1T3GjJv3SHf7FyS88OkeMngl2cv2i2yz5rY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ktmwHnKmyU7W+hV+tY55GMfwwXuI32BXDG1r+dDvJuI=; b=Tu/ZW4bDdwP8/+PlEo6Pn1qSffaIYkTqY0UOpc0WcCTDw/8pTkWjDWA08xQXzenZ9+ WcKlbVc1BvHz5HFRvN2WkpUIXwOVeb5OqScECutPMd366D1owU2AhkmeodYBcWircuGE gwqwy9TIVVNlqKfAQfex+th9xjwNyBsTw20TCkeA/JQtft7uPDu4yWbwhmSfFQ2Elvh1 O04HiAGJlUxHYu+4ZI2Et+k2v0nivm7LL2bnxmiMzhE+TM5a8gj3hx7MdNxXLDIrM3Ah ZB+sX12i7eRANRlifXzQg/MVx/hpl0K8lHML7LihOzQDtjO+jtTm3kTnfX219fOscdq6 VHPw==
X-Gm-Message-State: AOAM532YP+DKMe/uASfLUv/PNdIavX4lMYx6fwqOaoAoUGQbHEo5Bgbc lo/aaw+RJkDVyeKjEBQgYVuyqmD/lBSuIPXNFhxd2pnsxg3rJLMvVTASRpekmijgzmvcxet1FA= =
X-Google-Smtp-Source: ABdhPJz24dUdt1iR/LjyKzWoiP2D+uh5/CAK6xQE5/Usxkdaqd8YsHhhDHHFcoTVHovI3cAGQyAjGQ==
X-Received: by 2002:a17:906:6048:: with SMTP id p8mr7328786ejj.105.1614169257787;  Wed, 24 Feb 2021 04:20:57 -0800 (PST)
Received: from [10.0.0.6] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id x25sm1228658ejc.27.2021.02.24.04.20.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Feb 2021 04:20:57 -0800 (PST)
From: Neil Madden 
Message-Id: <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com>
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 24 Feb 2021 12:20:56 +0000
In-Reply-To: <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
Cc: Warren Parad , Carsten Bormann , Phillip Hallam-Baker , "oauth@ietf.org" , ietf@ietf.org
To: Bron Gondwana 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE4FA786-0A0A-48B5-81E7-AA3EFBFB7C23"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 12:21:02 -0000

--Apple-Mail=_DE4FA786-0A0A-48B5-81E7-AA3EFBFB7C23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
>=20
>>=20
>> [=E2=80=A6]
>=20
> Let's get down to use cases then, rather than talking in abstracts.
>=20
> I'm an end user with a copy of {The Bat email client} and I want to conne=
ct it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popula=
r open standard.  I want to be able to authenticate to each of those servic=
es without saving my plaintext passwords on my hard disk where the next {Wi=
ndows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Do=
gecoin} will then be exfiltrated from my {Paybuddy} account, leaving me des=
titute.
>=20
> But, {The Bat} doesn't have a trusted client cert from my isp, because wh=
o does - so there's no good protocol for me - it's either plaintext auth, o=
r it's some architecture astronaut multi-party nonsense that's massively ov=
er specified and doesn't work half the time.  So I write a plain text passw=
ord on a post-it note which is lying in the dust under my monitor because t=
he glue has gone bad, and I hope I never accidentally click "remember me" w=
hen I type it in.
>=20
> That's been the reality of the end user experience for very many years.
>=20
> NxM means that you can authenticate an arbitrary client against an arbitr=
ary server so long as they are both speaking a known public protocol, witho=
ut needing to build a trust relationship between the client vendor and the =
server vendor first.

Does the following meet your needs?

You type your email address into {The Bat} to begin configuration. {The Bat=
} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}. The d=
iscovery document reveals that {My ISP} supports open dynamic client regist=
ration [3][4] so {The Bat} registers and gets issued with a client id and c=
lient secret. {The Bat} then does a normal OAuth flow to get an access toke=
n to access your emails from {My ISP}. If you later stop using {The Bat} yo=
u can go to your page on {My ISP} and revoke its access because it has a un=
ique client id.

[1]: https://openid.net/specs/openid-connect-discovery-1_0.html 
[2]: https://tools.ietf.org/html/rfc8414 =20
[3]: https://openid.net/specs/openid-connect-registration-1_0.html 
[4]: https://tools.ietf.org/html/rfc7591 =20

>=20
> Any "trust relationship" is made through a user both who trusts the clien=
t and trusts the server, and it's not transitive over to other users of the=
 same client and the same server.  The client author doesn't need to get a =
signed "I trust you" from every single server, and the server author doesn'=
t have to go identify every single client.
>=20
> That's what NxM means to a user, the ability to use arbitrary clients wit=
h arbitrary servers so long as they both implement a documented protocol.  =
Interoperability.

That=E2=80=99s fine for your use-case, but that isn=E2=80=99t everybody=E2=
=80=99s use-case. Other use-cases (such as Open Banking) involve regulatory=
 or policy frameworks in which open dynamic client registration is not appr=
opriate. JMAP could have an RFC describing the use of OAuth with JMAP that =
mandates open dynamic client registration and discovery.


=E2=80=94 Neil


--=20
ForgeRock values your Privacy 

--Apple-Mail=_DE4FA786-0A0A-48B5-81E7-AA3EFBFB7C23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

On 24 Feb 2021, at 11:39, =
Bron Gondwana <bron=
g@fastmailteam.com> wrote:

Does the fo=
llowing meet your needs?

You type your =
email address into {The Bat} to begin configuration. {The Bat} does discove=
ry [1][2] to locate the OAuth/OIDC server for {My ISP}. The discovery docum=
ent reveals that {My ISP} supports open dynamic client registration [3][4] =
so {The Bat} registers and gets issued with a client id and client secret. =
{The Bat} then does a normal OAuth flow to get an access token to access yo=
ur emails from {My ISP}. If you later stop using {The Bat} you can go to yo=
ur page on {My ISP} and revoke its access because it has a unique client id=
.



<=
/div>
Any "trust relationship" is made t=
hrough a user both who trusts the client and trusts the server, and it's no=
t transitive over to other users of the same client and the same server.&nb=
sp; The client author doesn't need to get a signed "I trust you" from every=
 single server, and the server author doesn't have to go identify every sin=
gle client.

That's what NxM means to =
a user, the ability to use arbitrary clients with arbitrary servers so long=
 as they both implement a documented protocol.  Interoperability.

That=E2=
=80=99s fine for your use-case, but that isn=E2=80=99t everybody=E2=80=99s =
use-case. Other use-cases (such as Open Banking) involve regulatory or poli=
cy frameworks in which open dynamic client registration is not appropriate.=
 JMAP could have an RFC describing the use of OAuth with JMAP that mandates=
 open dynamic client registration and discovery.

<=
/div>

=E2=80=94 Neil




ForgeRock values your Privacy
--Apple-Mail=_DE4FA786-0A0A-48B5-81E7-AA3EFBFB7C23--


From nobody Wed Feb 24 04:29:35 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150E43A14EC for ; Wed, 24 Feb 2021 04:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHuiB_z8w9Co for ; Wed, 24 Feb 2021 04:29:31 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B823A14DA for ; Wed, 24 Feb 2021 04:29:30 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id g3so2215475edb.11 for ; Wed, 24 Feb 2021 04:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=B7C+ATMNQt1a2+SXWHdxTBfD0k1RF+yCylWISGljKwY=; b=qYNQ/0LZKTeFsZKYNRwJIuo8+3ifhbrQGSNVO+okpqRcCFmnrlscwGTH6/bVRhz4tx 8xqtDCEmkcHKmpAc2hi1lKXo4IyZ4SnYrRfkWf0nhmpGTyf52lue1QsrxXb8vp25uPqp JNyUw633Tg+k+K8/XD7tbfIvbJ/hMw4ZbC8yyJU4PyDZEVsqH8zDlvVRbeZz8aByj/TO H0xsdCHCa3QPkwdiirjrHjooO78g91bROXAP0oREgM5ojqCgxiILnul+8Nl/Hl2mS5mv fMa6PXZt4JHEAC+rP0EOvr8qrmxMo1W+sO+JeJRCT22mfUcklVeUrkdavUUWwLbj3opG 0RRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=B7C+ATMNQt1a2+SXWHdxTBfD0k1RF+yCylWISGljKwY=; b=tLK9lL/Rc6hKUCJO1dZL572BdAbwyDraDf+JcoP5Q46XuaSTSu96R03HmNZySyhTlZ K8x9n0KAzXrTsl4W7mLnFj0v62ise8JgupOlFJnRg5duXbYiZrukVjsveRaVN0SWUp6d QX+reEqzZP/ygPm7AdHLeWjZU5kX9WoAQa24Uji4GUU3kEeConmPgiA7mBGj+d8gc6Rg RdXZUYmnIE5kHc0RE8Q+KEGfgBpruG1ODBRjQ3xht7u/irzeSyslJaTclOpZD5mgPwVa 99azdWtoeS/j3xL2QFwqJ9DbtnmpjNdHdE6Le6BFNOtMSdwGwSX3L4znfwAXTg5951H/ TJ2A==
X-Gm-Message-State: AOAM533S10G5PRFrUOBVZ9v7mq20gsMGgvD89FbS38Z1xIgTHh6eiBlp 42LbEHmLLVh033EPKROXKV+4g9MaGh0ToZcHOB94rz/K//XQ1Q==
X-Google-Smtp-Source: ABdhPJxdENvh1scMhU5UWD0/G5sKEFdUP4Te7lONEFWC23johik7aEZjBFG7dyyQO1wfkA9NJDotN1AJYCLMkbke9ms=
X-Received: by 2002:a05:6402:3074:: with SMTP id bs20mr23091196edb.120.1614169768666;  Wed, 24 Feb 2021 04:29:28 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Jerry Leyendecker 
Date: Wed, 24 Feb 2021 06:29:17 -0600
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ab293305bc142f9f"
Archived-At: 
Subject: Re: [OAUTH-WG] subdomain
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 12:29:34 -0000

--000000000000ab293305bc142f9f
Content-Type: text/plain; charset="UTF-8"

What would be my subdomain when entering authress.api

On Wed, Feb 24, 2021, 6:21 AM  wrote:

> Send OAuth mailing list submissions to
>         oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         oauth-request@ietf.org
>
> You can reach the person managing the list at
>         oauth-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: We appear to still be litigating OAuth, oops (Bron Gondwana)
>    2. Re: We appear to still be litigating OAuth, oops (Neil Madden)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Feb 2021 23:15:15 +1100
> From: "Bron Gondwana" 
> To: "Warren Parad" 
> Cc: "Carsten Bormann" , "Phillip Hallam-Baker"
>         , "oauth@ietf.org" ,
>         ietf@ietf.org
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID: <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
> > (I tend to trend lightly in the pronoun area, mostly because I'm shocked
> that openid included gender but not pronouns)
> >
> > I hadn't heard that to be called the NxM problem, so that definitely
> cleared up the potential confusion (at least for me).
> >
> > I think GNAPs lack of clarity is a non sequitur for the handling or not
> of the multitrust arbitrary-client with arbitrary-service, however it's
> lack of clarity for me prevents me from knowing whether GNAP actually seeks
> to solve this problem. So from an OAuth WG perspective we can still ask:
> >
> > *Is this or should this problem be left to GNAP to solve, or is an OAuth
> WG responsibility?*
>
> Honestly I think the problem space is the whole ietf's responsibility.
> Protocols that allow an end user to safely transfer data between two
> parties that don't have a pre-existing trust relationship are a key part of
> enabling user freedom and user choice.
>
> Bron.
>
> >
>
> > *Warren Parad*
>
> > Founder, CTO
>
> > Secure your user data with IAM authorization as a service. Implement
> Authress .
> >
> >
> > On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana 
> wrote:
> >> __
> >> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
> >>> I would prefer Bron to answer that question, as they are the one who
> started this email thread.
> >>
> >> You can also use he when talking about me, or she for that matter - I
> do enough group fitness classes where it's roughly assumed that the entire
> class is female, and I have an ambiguous enough name that I'm used to it.
> Most people use "he" most of the time.
> >>
> >>> However let's look at GNAP, I've honestly been struggling to
> understand at least one fully documented case that GNAP supports. It seems
> in every document the only thing that is clear is GNAP wants to allow
> "everything", doesn't actually talk about an example.
> >>
> >> That's my biggest fear for GNAP - it too will try to be everything to
> everybody and wind up being nothing to nobody because the super flexible
> "everything protocol" is the same as no protocol at all, since you have to
> special-case everybody you talk to anyway.
> >>
> >>> By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credential
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
> >>
> >> Let's get down to use cases then, rather than talking in abstracts.
> >>
> >> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
> >>
> >> But, {The Bat} doesn't have a trusted client cert from my isp, because
> who does - so there's no good protocol for me - it's either plaintext auth,
> or it's some architecture astronaut multi-party nonsense that's massively
> over specified and doesn't work half the time.  So I write a plain text
> password on a post-it note which is lying in the dust under my monitor
> because the glue has gone bad, and I hope I never accidentally click
> "remember me" when I type it in.
> >>
> >> That's been the reality of the end user experience for very many years.
> >>
> >> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
> >>
> >> Any "trust relationship" is made through a user both who trusts the
> client and trusts the server, and it's not transitive over to other users
> of the same client and the same server.  The client author doesn't need to
> get a signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
> >>
> >> That's what NxM means to a user, the ability to use arbitrary clients
> with arbitrary servers so long as they both implement a documented
> protocol.  Interoperability.
> >>
> >> OAuth has not given interoperability in the NxM sense outside some
> simple web use cases.  They're nice and all, but they don't tend to be
> useful with open protocols - OAuth gets used for accessing proprietary API
> endpoints after getting an access key for a single provider.  At least you
> get Nx1 or 1xM out of it depending who's the N and who's the M, and maybe
> some of your code can rhyme so you're not doing everything from scratch
> each time.
> >>
> >> This is the sorry story of real open protocols.  The floor for true
> interoperability is still username + password over cleartext, over
> hopefully a TLS tunnel that's providing some level of protection.  Most so
> than a few years ago when Fastmail wrote our "starttls considered
> harmful"[1] objection to the IETF's habit at the time of putting a
> "STARTTLS" upgrade into an initially plaintext protocol, where an active
> intercepter could just strip the "I support STARTTLS" indicator from the
> protocol and convince the client to send the credentials in the clear.
> >>
> >> We're a little better mostly these days, but it's still a tirefire, and
> in my heart I do hold the OAuth working group's squatting on this area of
> the landscape while failing to address this burning need partially
> responsible.  The result (as Phillip pointed out upthread) has been a
> consolidation towards a few big players - because NxM becomes tractable
> when you reduce the N and M to small enough numbers.
> >>
> >> Bron.
> >>
> >> [1]
> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS
> >>
> >> --
> >>   Bron Gondwana, CEO, Fastmail Pty Ltd
> >>   brong@fastmailteam.com
> >>
> >>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/71b31a28/attachment.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Feb 2021 12:20:56 +0000
> From: Neil Madden 
> To: Bron Gondwana 
> Cc: Warren Parad , Carsten Bormann ,
>         Phillip Hallam-Baker , "oauth@ietf.org"
>         , ietf@ietf.org
> Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
> Message-ID: <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
> >
> >>
> >> [?]
> >
> > Let's get down to use cases then, rather than talking in abstracts.
> >
> > I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of those
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
> >
> > But, {The Bat} doesn't have a trusted client cert from my isp, because
> who does - so there's no good protocol for me - it's either plaintext auth,
> or it's some architecture astronaut multi-party nonsense that's massively
> over specified and doesn't work half the time.  So I write a plain text
> password on a post-it note which is lying in the dust under my monitor
> because the glue has gone bad, and I hope I never accidentally click
> "remember me" when I type it in.
> >
> > That's been the reality of the end user experience for very many years.
> >
> > NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protocol,
> without needing to build a trust relationship between the client vendor and
> the server vendor first.
>
> Does the following meet your needs?
>
> You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client id
> and client secret. {The Bat} then does a normal OAuth flow to get an access
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html <
> https://openid.net/specs/openid-connect-discovery-1_0.html>
> [2]: https://tools.ietf.org/html/rfc8414 <
> https://tools.ietf.org/html/rfc8414>
> [3]: https://openid.net/specs/openid-connect-registration-1_0.html <
> https://openid.net/specs/openid-connect-registration-1_0.html>
> [4]: https://tools.ietf.org/html/rfc7591 <
> https://tools.ietf.org/html/rfc7591>
>
> >
> > Any "trust relationship" is made through a user both who trusts the
> client and trusts the server, and it's not transitive over to other users
> of the same client and the same server.  The client author doesn't need to
> get a signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
> >
> > That's what NxM means to a user, the ability to use arbitrary clients
> with arbitrary servers so long as they both implement a documented
> protocol.  Interoperability.
>
> That?s fine for your use-case, but that isn?t everybody?s use-case. Other
> use-cases (such as Open Banking) involve regulatory or policy frameworks in
> which open dynamic client registration is not appropriate. JMAP could have
> an RFC describing the use of OAuth with JMAP that mandates open dynamic
> client registration and discovery.
>
>
> ? Neil
>
>
> --
> ForgeRock values your Privacy 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20210224/ac3ed3af/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 148, Issue 80
> **************************************
>

--000000000000ab293305bc142f9f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What would be my subdomain when entering authress.api
On W=
ed, Feb 24, 2021, 6:21 AM  <oa=
uth-request@ietf.org> wrote:
Send OAuth mailing list submissions to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.o=
rg/mailman/listinfo/oauth

or, via email, send a message with subject or body 'help' to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-request@ietf.org



You can reach the person managing the list at

=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of OAuth digest..."





Today's Topics:



=C2=A0 =C2=A01. Re: We appear to still be litigating OAuth, oops (Bron Gond=
wana)

=C2=A0 =C2=A02. Re: We appear to still be litigating OAuth, oops (Neil Madd=
en)





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



Message: 1

Date: Wed, 24 Feb 2021 23:15:15 +1100

From: "Bron Gondwana" <brong@fastmailteam.com>

To: "Warren Parad" <wparad@rhosys.ch>

Cc: "Carsten Bormann" <cabo@tzi.org>, "Phillip Hallam-B=
aker"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <phill@hallambaker.com>, "oauth@i=
etf.org" <oauth@ietf.org>,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf@ietf.org

Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Message-ID: <121f52be-4747-45f3-ad75=
-79fa2f693d75@beta.fastmail.com>

Content-Type: text/plain; charset=3D"us-ascii"







On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:

> (I tend to trend lightly in the pronoun area, mostly because I'm s=
hocked that openid included gender but not pronouns)

> 

> I hadn't heard that to be called the NxM problem, so that definite=
ly cleared up the potential confusion (at least for me).

> 

> I think GNAPs lack of clarity is a non sequitur for the handling or no=
t of the multitrust arbitrary-client with arbitrary-service, however it'=
;s lack of clarity for me prevents me from knowing whether GNAP actually se=
eks to solve this problem. So from an OAuth WG perspective we can still ask=
:

> 

> *Is this or should this problem be left to GNAP to solve, or is an OAu=
th WG responsibility?*



Honestly I think the problem space is the whole ietf's responsibility. =
Protocols that allow an end user to safely transfer data between two partie=
s that don't have a pre-existing trust relationship are a key part of e=
nabling user freedom and user choice.



Bron.



> 



> *Warren Parad*



> Founder, CTO



> Secure your user data with IAM authorization as a service. Implement A=
uthress <https://authress.io/>.

> 

> 

> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana <brong@fastmailt=
eam.com> wrote:

>> __

>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:

>>> I would prefer Bron to answer that question, as they are the o=
ne who started this email thread.

>> 

>> You can also use he when talking about me, or she for that matter =
- I do enough group fitness classes where it's roughly assumed that the=
 entire class is female, and I have an ambiguous enough name that I'm u=
sed to it.=C2=A0 Most people use "he" most of the time.

>> 

>>> However let's look at GNAP, I've honestly been struggl=
ing to understand at least one fully documented case that GNAP supports. It=
 seems in every document the only thing that is clear is GNAP wants to allo=
w "everything", doesn't actually talk about an example.

>> 

>> That's my biggest fear for GNAP - it too will try to be everyt=
hing to everybody and wind up being nothing to nobody because the super fle=
xible "everything protocol" is the same as no protocol at all, si=
nce you have to special-case everybody you talk to anyway.

>> 

>>> By NxM, I assume we mean that the end user or client is free t=
o select whichever AS they want, in a way which the RS can verify the AS cr=
edential and the user identity, without the RS having to (and really withou=
t the ability to limit) which AS are allowed.

>> 

>> Let's get down to use cases then, rather than talking in abstr=
acts.

>> 

>> I'm an end user with a copy of {The Bat email client} and I wa=
nt to connect it to {Gmail} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3},=
 a widely popular open standard.=C2=A0 I want to be able to authenticate to=
 each of those services without saving my plaintext passwords on my hard di=
sk where the next {Windows ME} virus will exfiltrate them to {Noextradition=
istan} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} ac=
count, leaving me destitute.

>> 

>> But, {The Bat} doesn't have a trusted client cert from my isp,=
 because who does - so there's no good protocol for me - it's eithe=
r plaintext auth, or it's some architecture astronaut multi-party nonse=
nse that's massively over specified and doesn't work half the time.=
=C2=A0 So I write a plain text password on a post-it note which is lying in=
 the dust under my monitor because the glue has gone bad, and I hope I neve=
r accidentally click "remember me" when I type it in.

>> 

>> That's been the reality of the end user experience for very ma=
ny years.

>> 

>> NxM means that you can authenticate an arbitrary client against an=
 arbitrary server so long as they are both speaking a known public protocol=
, without needing to build a trust relationship between the client vendor a=
nd the server vendor first.

>> 

>> Any "trust relationship" is made through a user both who=
 trusts the client and trusts the server, and it's not transitive over =
to other users of the same client and the same server.=C2=A0 The client aut=
hor doesn't need to get a signed "I trust you" from every sin=
gle server, and the server author doesn't have to go identify every sin=
gle client.

>> 

>> That's what NxM means to a user, the ability to use arbitrary =
clients with arbitrary servers so long as they both implement a documented =
protocol.=C2=A0 Interoperability.

>> 

>> OAuth has not given interoperability in the NxM sense outside some=
 simple web use cases.=C2=A0 They're nice and all, but they don't t=
end to be useful with open protocols - OAuth gets used for accessing propri=
etary API endpoints after getting an access key for a single provider.=C2=
=A0 At least you get Nx1 or 1xM out of it depending who's the N and who=
's the M, and maybe some of your code can rhyme so you're not doing=
 everything from scratch each time.

>> 

>> This is the sorry story of real open protocols.=C2=A0 The floor fo=
r true interoperability is still username + password over cleartext, over h=
opefully a TLS tunnel that's providing some level of protection.=C2=A0 =
Most so than a few years ago when Fastmail wrote our "starttls conside=
red harmful"[1] objection to the IETF's habit at the time of putti=
ng a "STARTTLS" upgrade into an initially plaintext protocol, whe=
re an active intercepter could just strip the "I support STARTTLS"=
; indicator from the protocol and convince the client to send the credentia=
ls in the clear.

>> 

>> We're a little better mostly these days, but it's still a =
tirefire, and in my heart I do hold the OAuth working group's squatting=
 on this area of the landscape while failing to address this burning need p=
artially responsible.=C2=A0 The result (as Phillip pointed out upthread) ha=
s been a consolidation towards a few big players - because NxM becomes trac=
table when you reduce the N and M to small enough numbers.

>> 

>> Bron.

>> 

>> [1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-START=
TLS

>> 

>> --

>>=C2=A0 =C2=A0Bron Gondwana, CEO, Fastmail Pty Ltd

>>=C2=A0 =C2=A0brong@fastmailteam.com

>> 

>> 



--

=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd

=C2=A0 brong@fastmailteam.com

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2021=
0224/71b31a28/attachment.htm>



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



Message: 2

Date: Wed, 24 Feb 2021 12:20:56 +0000

From: Neil Madden <neil.madden@forgerock.com>

To: Bron Gondwana <brong@fastmailteam.com>

Cc: Warren Parad <wparad@rhosys.ch>, Carsten Bormann <cabo@tzi.org=
>,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phillip Hallam-Baker <phill@hallambaker.c=
om>, "oauth@ietf.org"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <oauth@ietf.org>, ietf@ietf.org

Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Message-ID: <02A263F5-8109-4D3B-A684-D9B=
574260B50@forgerock.com>

Content-Type: text/plain; charset=3D"utf-8"



On 24 Feb 2021, at 11:39, Bron Gondwana <brong@fastmailteam.com&=
gt; wrote:

> 

>> 

>> [?]

> 

> Let's get down to use cases then, rather than talking in abstracts=
.

> 

> I'm an end user with a copy of {The Bat email client} and I want t=
o connect it to {Gmail} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3}, a w=
idely popular open standard.=C2=A0 I want to be able to authenticate to eac=
h of those services without saving my plaintext passwords on my hard disk w=
here the next {Windows ME} virus will exfiltrate them to {Noextraditionista=
n} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} accoun=
t, leaving me destitute.

> 

> But, {The Bat} doesn't have a trusted client cert from my isp, bec=
ause who does - so there's no good protocol for me - it's either pl=
aintext auth, or it's some architecture astronaut multi-party nonsense =
that's massively over specified and doesn't work half the time.=C2=
=A0 So I write a plain text password on a post-it note which is lying in th=
e dust under my monitor because the glue has gone bad, and I hope I never a=
ccidentally click "remember me" when I type it in.

> 

> That's been the reality of the end user experience for very many y=
ears.

> 

> NxM means that you can authenticate an arbitrary client against an arb=
itrary server so long as they are both speaking a known public protocol, wi=
thout needing to build a trust relationship between the client vendor and t=
he server vendor first.



Does the following meet your needs?



You type your email address into {The Bat} to begin configuration. {The Bat=
} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}. The d=
iscovery document reveals that {My ISP} supports open dynamic client regist=
ration [3][4] so {The Bat} registers and gets issued with a client id and c=
lient secret. {The Bat} then does a normal OAuth flow to get an access toke=
n to access your emails from {My ISP}. If you later stop using {The Bat} yo=
u can go to your page on {My ISP} and revoke its access because it has a un=
ique client id.



[1]: https://openid.net/specs/o=
penid-connect-discovery-1_0.html <https://openid.net/specs/openid-connect-discovery-1_0.html&=
gt;

[2]: https://tools.ietf.org/html/rfc8414 <https://tools.ietf.org/html/rfc8414> 

[3]: https://openid.net/spec=
s/openid-connect-registration-1_0.html <https://openid.net/specs/openid-connect-registration-1_0=
.html>

[4]: https://tools.ietf.org/html/rfc7591 <https://tools.ietf.org/html/rfc7591> 



> 

> Any "trust relationship" is made through a user both who tru=
sts the client and trusts the server, and it's not transitive over to o=
ther users of the same client and the same server.=C2=A0 The client author =
doesn't need to get a signed "I trust you" from every single =
server, and the server author doesn't have to go identify every single =
client.

> 

> That's what NxM means to a user, the ability to use arbitrary clie=
nts with arbitrary servers so long as they both implement a documented prot=
ocol.=C2=A0 Interoperability.



That?s fine for your use-case, but that isn?t everybody?s use-case. Other u=
se-cases (such as Open Banking) involve regulatory or policy frameworks in =
which open dynamic client registration is not appropriate. JMAP could have =
an RFC describing the use of OAuth with JMAP that mandates open dynamic cli=
ent registration and discovery.





? Neil





-- 

ForgeRock values your Privacy <https://www.forge=
rock.com/your-privacy>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/2021=
0224/ac3ed3af/attachment.htm>



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



Subject: Digest Footer



_______________________________________________

OAuth mailing list

OAut=
h@ietf.org

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





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



End of OAuth Digest, Vol 148, Issue 80

**************************************




--000000000000ab293305bc142f9f--


From nobody Wed Feb 24 05:45:14 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB153A15DA for ; Wed, 24 Feb 2021 05:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_auLdwURtA7 for ; Wed, 24 Feb 2021 05:45:06 -0800 (PST)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957233A15D9 for ; Wed, 24 Feb 2021 05:45:06 -0800 (PST)
Received: by mail-il1-x12b.google.com with SMTP id q5so1721049ilc.10 for ; Wed, 24 Feb 2021 05:45:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EffAmbWZfwFmvFsqfhpIW0638sLeFVG5R0SAoTjulKY=; b=WXQxDvtVf4E2p8Q4wiABqoxuWxp7oXw6iOl/ndoeaQ5grmsbF6HFSRQ3iiCm8qkfsS 3BLOqtWcrJEPAhoWfr6ZgVBvdhtsDTJ6gPTuI8+qZj8vCQNZ9I8KcfByr/Fe/KC5mmIg mzvCwy3Qf6hPhbox71ytCTFf9rB+XXVHRONJRSHwkX4T3lCQn6VC3EgUMVYZfWymrgTF nOfl/xTkCs6K8qPkb9G4GI9pFil/jPsm8WtE/mV0XC/0koe6i1orbYOwsOFlSCPJZL3s tZlLk1MKjEbuG+jtiSIvMmtciavxI8euVyJMZIQn+IGmtFxxYaFGteMbjLAQuYlJ6ANk IIhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EffAmbWZfwFmvFsqfhpIW0638sLeFVG5R0SAoTjulKY=; b=AER81+GpiFtS8k0CtsEB1KhC6sKKQDWltMKLR0Gi1acMoA5hM5p2fpdG16YQuGzXcK JLar3a23YpQwW90wk1Mr/+F+nByC/VRX6q5K4YzYMiOkoqMr5yKQEcBWPOrd0+ATsQu2 FCg4Pkwvmp17gepV5BV8J9UeSpYNJm5SmEifNVkoUSiQCu+8dskYXl0OwM7CdujmU+Kk FWcIIuhoC4m8vorhx6XeFLThwTzIQG6IB7vaOcTsBz5ZuE1ab1mFMt93UrhKnS0/mjnz kBIWT/qqc13hqBKeuyXxIiyDiontKeMka74i+xncTErjzv2TG1b48JuF9I3zphDEqa4K IimA==
X-Gm-Message-State: AOAM530a/jxGGMMKF8j+Zyl6qzvbys7PrL45BUJEiplcVRSdURxBoRTv bFpv0t19XUyUhk9IhZL0qe/AjA==
X-Google-Smtp-Source: ABdhPJw3ZqfBXERP44AgEaywYeyiLOjzaMYs8mJ2go2kaoiwTXlrNoRSmexXfzh3ZDuqByRLmXMFZQ==
X-Received: by 2002:a05:6e02:1d95:: with SMTP id h21mr24380541ila.151.1614174305597;  Wed, 24 Feb 2021 05:45:05 -0800 (PST)
Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id q15sm1651360ilt.30.2021.02.24.05.45.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Feb 2021 05:45:05 -0800 (PST)
Received: by mail-il1-f178.google.com with SMTP id h18so1749139ils.2; Wed, 24 Feb 2021 05:45:04 -0800 (PST)
X-Received: by 2002:a92:d7ce:: with SMTP id g14mr11252263ilq.255.1614174304419;  Wed, 24 Feb 2021 05:45:04 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com>
In-Reply-To: <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com>
From: Aaron Parecki 
Date: Wed, 24 Feb 2021 05:44:53 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Neil Madden 
Cc: Bron Gondwana , Phillip Hallam-Baker , ietf@ietf.org,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000000546fd05bc153e79"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 13:45:09 -0000

--0000000000000546fd05bc153e79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> You type your email address into {The Bat} to begin configuration. {The
Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
The discovery document reveals that {My ISP} supports open dynamic client
registration [3][4] so {The Bat} registers and gets issued with a client id
and client secret. {The Bat} then does a normal OAuth flow to get an access
token to access your emails from {My ISP}. If you later stop using {The
Bat} you can go to your page on {My ISP} and revoke its access because it
has a unique client id.

Like Neil says, the building blocks are all already there. The fact that
companies choose not to use them is not because the technology isn't there,
it's because it's a business problem.

I'd be thrilled if the NxM problem were solved in practice, but
unfortunately that doesn't seem to be what's happened in the market. The
technical solution has been there a long time, so there's something else
going on.

When I've brought up this topic in the past, most of the responses I've
gotten from the "big players" are along the lines of "lol we're not going
to let someone's software talk to us unless we have a legal arrangement
with the developer". The fact that dynamic client registration is barely
used is more because these service operators want the software developers
to agree to their terms of service before being able to access APIs.

This is all to say that I agree it'd be nice to solve this problem, but in
the end, the IETF can't tell companies what to do with their products and
services.

Aaron




On Wed, Feb 24, 2021 at 4:21 AM Neil Madden 
wrote:

> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
>
>
>
> [=E2=80=A6]
>
>
> Let's get down to use cases then, rather than talking in abstracts.
>
> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of thos=
e
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
>
> But, {The Bat} doesn't have a trusted client cert from my isp, because wh=
o
> does - so there's no good protocol for me - it's either plaintext auth, o=
r
> it's some architecture astronaut multi-party nonsense that's massively ov=
er
> specified and doesn't work half the time.  So I write a plain text passwo=
rd
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" wh=
en
> I type it in.
>
> That's been the reality of the end user experience for very many years.
>
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protoco=
l,
> without needing to build a trust relationship between the client vendor a=
nd
> the server vendor first.
>
>
> Does the following meet your needs?
>
> You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client =
id
> and client secret. {The Bat} then does a normal OAuth flow to get an acce=
ss
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
> [2]: https://tools.ietf.org/html/rfc8414
> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
> [4]: https://tools.ietf.org/html/rfc7591
>
>
> Any "trust relationship" is made through a user both who trusts the clien=
t
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
>
> That's what NxM means to a user, the ability to use arbitrary clients wit=
h
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
>
>
> That=E2=80=99s fine for your use-case, but that isn=E2=80=99t everybody=
=E2=80=99s use-case. Other
> use-cases (such as Open Banking) involve regulatory or policy frameworks =
in
> which open dynamic client registration is not appropriate. JMAP could hav=
e
> an RFC describing the use of OAuth with JMAP that mandates open dynamic
> client registration and discovery.
>
>
> =E2=80=94 Neil
>
>
> ForgeRock values your Privacy 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20
---
Aaron Parecki
https://aaronparecki.com

--0000000000000546fd05bc153e79
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


>=C2=A0You type your email address into {The Bat} to begin configuration. {T=
he Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.=
 The discovery document reveals that {My ISP} supports open dynamic client =
registration [3][4] so {The Bat} registers and gets issued with a client id=
 and client secret. {The Bat} then does a normal OAuth flow to get an acces=
s token to access your emails from {My ISP}. If you later stop using {The B=
at} you can go to your page on {My ISP} and revoke its access because it ha=
s a unique client id.

Like Neil says, the building blo=
cks are all already there. The fact that companies choose not to use them i=
s not because the technology isn't there, it's because it's a b=
usiness problem.=C2=A0

I'd be thrilled if the NxM =
problem were solved in practice, but unfortunately that doesn't seem to=
 be what's happened in the market. The technical solution has been ther=
e a long time, so there's something else going on.

<=
/div>
When I've brought up this topic in the past, most of the responses I&#=
39;ve gotten from the "big players" are along the lines of "=
lol we're not going to let someone's software talk to us unless we =
have a legal arrangement with the developer". The fact that dynamic cl=
ient registration is barely used is more because these service operators wa=
nt the software developers to agree to their terms of service before being =
able to access APIs.

This is all to say that I agree i=
t'd be nice to solve this problem, but in the end, the IETF can't t=
ell companies what to do with their products and services.

Aaron

=




On Wed, Feb 24=
, 2021 at 4:21 AM Neil Madden <neil.madden@forgerock.com> wrote:
=
On 24 Feb 2021, at 11:39, Bron Gondwana <brong@fastmailteam.com> wrote:
=



[=E2=80=A6]=


Let's get down to use cases then, rather than talking in abstracts.

I'm an end user with=
 a copy of {The Bat email client} and I want to connect it to {Gmail} + {Ya=
hoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely popular open standard.=
=C2=A0 I want to be able to authenticate to each of those services without =
saving my plaintext passwords on my hard disk where the next {Windows ME} v=
irus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} wil=
l then be exfiltrated from my {Paybuddy} account, leaving me destitute.
=


But, {The Bat} doesn'=
t have a trusted client cert from my isp, because who does - so there's=
 no good protocol for me - it's either plaintext auth, or it's some=
 architecture astronaut multi-party nonsense that's massively over spec=
ified and doesn't work half the time.=C2=A0 So I write a plain text pas=
sword on a post-it note which is lying in the dust under my monitor because=
 the glue has gone bad, and I hope I never accidentally click "remembe=
r me" when I type it in.

That's been the reality of the end user experience for very man=
y years.

NxM means tha=
t you can authenticate an arbitrary client against an arbitrary server so l=
ong as they are both speaking a known public protocol, without needing to b=
uild a trust relationship between the client vendor and the server vendor f=
irst.

Does the following me=
et your needs?

You type your email address into {T=
he Bat} to begin configuration. {The Bat} does discovery [1][2] to locate t=
he OAuth/OIDC server for {My ISP}. The discovery document reveals that {My =
ISP} supports open dynamic client registration [3][4] so {The Bat} register=
s and gets issued with a client id and client secret. {The Bat} then does a=
 normal OAuth flow to get an access token to access your emails from {My IS=
P}. If you later stop using {The Bat} you can go to your page on {My ISP} a=
nd revoke its access because it has a unique client id.

[2]:=C2=A0https://tools.ietf.org/html/rfc8414=C2=A0<=
/div>






ForgeRock values your Privacy__=
_____________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---
Aaron Par=
ecki



--0000000000000546fd05bc153e79--


From nobody Wed Feb 24 07:00:10 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D63A16B5 for ; Wed, 24 Feb 2021 07:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level: 
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82a97FVwpUiQ for ; Wed, 24 Feb 2021 07:00:01 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89DC63A16B6 for ; Wed, 24 Feb 2021 07:00:00 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id w36so3482855lfu.4 for ; Wed, 24 Feb 2021 07:00:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6sxvFnZ0GGl9DyQBTr64SScpYRkQy4Rk2Yy0q3fzSsw=; b=c9j5xMUAfaSn/a3QnM5Qkvbpoq1FBtUZzH/Z7Jav+eJATUz2HuOXFHAhh3UmIDAHA8 7wfuBNUjD/mHLi5hoGCFszMi9wE4iGn3XYGsy4FTx2OXZtc530AWmDkEgukIKVN+5JjH b89g+q8WFzMtB2aGt7Rk58rXj+znfyGGOJqD6khBShiVjAfwlHjWb/BIgWPy5PPJ+oz/ wlIRZVKzwxKb9gL9FPTv6Z3j8e5JFlGF8cG6Df3ao/XdCtV0EdvkyojDvToZBRXbZXf/ A6AQFHUDXIzrhSX2btbmreiH94y5NG6VKW4Nj5dUKr91F2VgwoFpKS2SrLUdoq6P2Jwo d+mQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6sxvFnZ0GGl9DyQBTr64SScpYRkQy4Rk2Yy0q3fzSsw=; b=LCRAwIhFNVv5i5FEWeXFKbw4l3RN/S0ewDUKMVr2/FwA+jWDbecIK4S92q89EgmNwx /zUEXoWeHmydUyhcFLZmeNyUAXdS46YDfc1ckNIZuzAd/+Qopbod5OCaE5Kq39x90cxg Ejh93SNTpeCPuOso/vgIR6B8NeBf2KErWFuhMD7nq4EyxIrumAPFS8UlaC8D6pspR/wO 45/5sMGiraLlil3p7TOybsDDiusBdoJ/obwu/ZFyIvfIxRzXRp2nnwqT2s73UksZWRUa Bh4vBNL6rWKNcy4AGTYXLYltA3jfNlqt7buMZQXvWbu2/r1Mz0EzfqQYu6wHPhya4Ztp EvJg==
X-Gm-Message-State: AOAM533kTG31tlicGJk7e3fQhpWdcWk+ic1O9RfsUbK/b1s7MEGMR1me 0uAitAS253JjufeLXAbnqOi0sqLqpuPcFWKJWe9Osara1c8Ojw==
X-Google-Smtp-Source: ABdhPJxylwEy2M6/IqIiYvfChtYPTAn12loSCNw5HAaNvb1mPpEQlM5z95bJyEXkqIUA7icCi/t7gUs8tEvdPQprPZM=
X-Received: by 2002:ac2:4147:: with SMTP id c7mr7141164lfi.405.1614178797834;  Wed, 24 Feb 2021 06:59:57 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com> 
In-Reply-To: 
From: Jim Willeke 
Date: Wed, 24 Feb 2021 09:59:21 -0500
Message-ID: 
To: "oauth@ietf.org" 
Cc: ietf@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d968df05bc1649c5"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 15:00:05 -0000

--000000000000d968df05bc1649c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

But in reality, Just "because the technology" is there there leaves out the
practicality of creating a secure implementation. Sure, you could write it
off as "a business problem" but many of the developers are small and not
unusually single person operations that do not have the resources to create
a specific team, or even a specific person, to work through all the
specifications that are involved.

I do believe, in general, specific implementations should not be within
the specifications but a "Best Practices" or "Common Implementations"
document to coincide with the specifications might be in order.

Just spend some time on https://stackexchange.com/filters/4229/oauth and
you will see the issue and struggles.


--
-jim
Jim Willeke


On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki  wrote:

> > You type your email address into {The Bat} to begin configuration. {The
> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
> The discovery document reveals that {My ISP} supports open dynamic client
> registration [3][4] so {The Bat} registers and gets issued with a client =
id
> and client secret. {The Bat} then does a normal OAuth flow to get an acce=
ss
> token to access your emails from {My ISP}. If you later stop using {The
> Bat} you can go to your page on {My ISP} and revoke its access because it
> has a unique client id.
>
> Like Neil says, the building blocks are all already there. The fact that
> companies choose not to use them is not because the technology isn't ther=
e,
> it's because it's a business problem.
>
> I'd be thrilled if the NxM problem were solved in practice, but
> unfortunately that doesn't seem to be what's happened in the market. The
> technical solution has been there a long time, so there's something else
> going on.
>
> When I've brought up this topic in the past, most of the responses I've
> gotten from the "big players" are along the lines of "lol we're not going
> to let someone's software talk to us unless we have a legal arrangement
> with the developer". The fact that dynamic client registration is barely
> used is more because these service operators want the software developers
> to agree to their terms of service before being able to access APIs.
>
> This is all to say that I agree it'd be nice to solve this problem, but i=
n
> the end, the IETF can't tell companies what to do with their products and
> services.
>
> Aaron
>
>
>
>
> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden 
> wrote:
>
>> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
>>
>>
>>
>> [=E2=80=A6]
>>
>>
>> Let's get down to use cases then, rather than talking in abstracts.
>>
>> I'm an end user with a copy of {The Bat email client} and I want to
>> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widel=
y
>> popular open standard.  I want to be able to authenticate to each of tho=
se
>> services without saving my plaintext passwords on my hard disk where the
>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>> leaving me destitute.
>>
>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>> who does - so there's no good protocol for me - it's either plaintext au=
th,
>> or it's some architecture astronaut multi-party nonsense that's massivel=
y
>> over specified and doesn't work half the time.  So I write a plain text
>> password on a post-it note which is lying in the dust under my monitor
>> because the glue has gone bad, and I hope I never accidentally click
>> "remember me" when I type it in.
>>
>> That's been the reality of the end user experience for very many years.
>>
>> NxM means that you can authenticate an arbitrary client against an
>> arbitrary server so long as they are both speaking a known public protoc=
ol,
>> without needing to build a trust relationship between the client vendor =
and
>> the server vendor first.
>>
>>
>> Does the following meet your needs?
>>
>> You type your email address into {The Bat} to begin configuration. {The
>> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}.
>> The discovery document reveals that {My ISP} supports open dynamic clien=
t
>> registration [3][4] so {The Bat} registers and gets issued with a client=
 id
>> and client secret. {The Bat} then does a normal OAuth flow to get an acc=
ess
>> token to access your emails from {My ISP}. If you later stop using {The
>> Bat} you can go to your page on {My ISP} and revoke its access because i=
t
>> has a unique client id.
>>
>> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
>> [2]: https://tools.ietf.org/html/rfc8414
>> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
>> [4]: https://tools.ietf.org/html/rfc7591
>>
>>
>> Any "trust relationship" is made through a user both who trusts the
>> client and trusts the server, and it's not transitive over to other user=
s
>> of the same client and the same server.  The client author doesn't need =
to
>> get a signed "I trust you" from every single server, and the server auth=
or
>> doesn't have to go identify every single client.
>>
>> That's what NxM means to a user, the ability to use arbitrary clients
>> with arbitrary servers so long as they both implement a documented
>> protocol.  Interoperability.
>>
>>
>> That=E2=80=99s fine for your use-case, but that isn=E2=80=99t everybody=
=E2=80=99s use-case. Other
>> use-cases (such as Open Banking) involve regulatory or policy frameworks=
 in
>> which open dynamic client registration is not appropriate. JMAP could ha=
ve
>> an RFC describing the use of OAuth with JMAP that mandates open dynamic
>> client registration and discovery.
>>
>>
>> =E2=80=94 Neil
>>
>>
>> ForgeRock values your Privacy 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> ---
> Aaron Parecki
> https://aaronparecki.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000d968df05bc1649c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


But in reality, Just "because the technology" is=
 there there leaves out the practicality of creating a secure implementatio=
n. Sure, you could=C2=A0write it off as "a business problem" but =
many of the developers are small and not unusually=C2=A0single person=C2=A0=
operations that do not have the resources to create a specific team, or eve=
n a specific person, to work through all the specifications that are involv=
ed.

I do believe, in general, specific implementations s=
hould=C2=A0not be within the=C2=A0specifications but a "Best Practices=
" or "Common Implementations" document to coincide with the=
=C2=A0specifications might be in order.

Just spend=
 some time=C2=A0on=C2=A0https://stackexchange.com/filters/4229/oauth and you will see the=
 issue and struggles.


--
-jim
Jim Willeke

=

On Wed=
, Feb 24, 2021 at 8:46 AM Aaron Parecki <aaron@parecki.com> wrote:
>=C2=A0You type your email address =
into {The Bat} to begin configuration. {The Bat} does discovery [1][2] to l=
ocate the OAuth/OIDC server for {My ISP}. The discovery document reveals th=
at {My ISP} supports open dynamic client registration [3][4] so {The Bat} r=
egisters and gets issued with a client id and client secret. {The Bat} then=
 does a normal OAuth flow to get an access token to access your emails from=
 {My ISP}. If you later stop using {The Bat} you can go to your page on {My=
 ISP} and revoke its access because it has a unique client id.
=


=

Like Neil says, the building blocks are all already there. The fac=
t that companies choose not to use them is not because the technology isn&#=
39;t there, it's because it's a business problem.=C2=A0
I'd be thrilled if the NxM problem were solved in practice, b=
ut unfortunately that doesn't seem to be what's happened in the mar=
ket. The technical solution has been there a long time, so there's some=
thing else going on.

When I've brought up this top=
ic in the past, most of the responses I've gotten from the "big pl=
ayers" are along the lines of "lol we're not going to let som=
eone's software talk to us unless we have a legal arrangement with the =
developer". The fact that dynamic client registration is barely used i=
s more because these service operators want the software developers to agre=
e to their terms of service before being able to access APIs.
<=
div dir=3D"auto">
<=
/span>
This is all to say that I agree it'd be nice to solve this prob=
lem, but in the end, the IETF can't tell companies what to do with thei=
r products and services.

Aaron




On Wed, Feb 24, 2021 at 4:21 AM Neil Madden &=
lt;neil.madd=
en@forgerock.com> wrote:
On 24 Feb 2021, at 11:39, Bron Gondwana <brong@fastmailteam.com> wrote:


[=E2=80=A6]


I'm an end user wit=
h a copy of {The Bat email client} and I want to connect it to {Gmail} + {Y=
ahoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely popular open standard.=
=C2=A0 I want to be able to authenticate to each of those services without =
saving my plaintext passwords on my hard disk where the next {Windows ME} v=
irus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} wil=
l then be exfiltrated from my {Paybuddy} account, leaving me destitute.
=


But, {The Bat} doesn'=
t have a trusted client cert from my isp, because who does - so there's=
 no good protocol for me - it's either plaintext auth, or it's some=
 architecture astronaut multi-party nonsense that's massively over spec=
ified and doesn't work half the time.=C2=A0 So I write a plain text pas=
sword on a post-it note which is lying in the dust under my monitor because=
 the glue has gone bad, and I hope I never accidentally click "remembe=
r me" when I type it in.

That's been the reality of the end user experience for very man=
y years.

NxM means tha=
t you can authenticate an arbitrary client against an arbitrary server so l=
ong as they are both speaking a known public protocol, without needing to b=
uild a trust relationship between the client vendor and the server vendor f=
irst.

Does the following me=
et your needs?

You type your email address into {T=
he Bat} to begin configuration. {The Bat} does discovery [1][2] to locate t=
he OAuth/OIDC server for {My ISP}. The discovery document reveals that {My =
ISP} supports open dynamic client registration [3][4] so {The Bat} register=
s and gets issued with a client id and client secret. {The Bat} then does a=
 normal OAuth flow to get an access token to access your emails from {My IS=
P}. If you later stop using {The Bat} you can go to your page on {My ISP} a=
nd revoke its access because it has a unique client id.

[2]:=C2=A0https://tools.ietf.org/html/rfc8414=C2=A0<=
/div>






ForgeRock values your Privacy__=
_____________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---<=
/div>Aaron Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000d968df05bc1649c5--


From nobody Wed Feb 24 07:18:41 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFD13A16EF; Wed, 24 Feb 2021 07:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyzR0xOJzT6Z; Wed, 24 Feb 2021 07:18:30 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FAF3A16EE; Wed, 24 Feb 2021 07:18:29 -0800 (PST)
Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11OFIMwk030722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Feb 2021 10:18:23 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_836960DE-9A94-44F8-BE83-DFD79296D11D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 24 Feb 2021 10:18:22 -0500
In-Reply-To: <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>
Cc: Warren Parad , Phillip Hallam-Baker , "oauth@ietf.org" , ietf@ietf.org
To: Bron Gondwana 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 15:18:34 -0000

--Apple-Mail=_836960DE-9A94-44F8-BE83-DFD79296D11D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree that the NxM problem is the purview of the whole IETF, but =
it=E2=80=99s something that we=E2=80=99re particularly interested in =
over in GNAP. As the editor of OAuth=E2=80=99s dynamic registration =
extension and the GNAP core protocol, I hope I can add to this =
conversation.

=46rom a technical standpoint, OAuth=E2=80=99s dynamic client =
registration lets arbitrary clients talk to an AS, but the trust isn=E2=80=
=99t there in practice. On top of that I think this problem is =
exacerbated by a fundamental protocol design element of OAuth: the =
client_id that=E2=80=99s required. That field means there=E2=80=99s an =
assumption that a relationship was set up between the pieces of =
software, implied to be trusted by admins at the AS. Sure you can get =
that client_id under special circumstances, but there=E2=80=99s still a =
special weight handed to that and the dynamic stuff feels like you=E2=80=99=
re giving up control as an AS. In GNAP, the relationship is inverted, =
and it=E2=80=99s designed as =E2=80=9Cdynamic-first=E2=80=9D, with =
pre-registered clients being an optimization on top of that.

Does this solve the NxM problem? No, because companies are still going =
to decide that they only talk to keys or identifiers that they know =
ahead of time. But the protocol puts the dynamic case forward as =
baseline and fits in much better with the likes of JMAP than OAuth ever =
could:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does discovery =
(maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP =
server and the GNAP endpoint for authentication as an option.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it just made =
up. {ISP} has never seen this key, but knows how to talk GNAP and get =
the user to authorize {Bat} to access email.
- {User} does this using GNAP and gets back an access token that=E2=80=99s=
 tied to the key {Bat} made back at the beginning. That token is tied =
(at the {ISP}) to the user=E2=80=99s account.

Yes, you can do all of this today with OAuth (and people have done so), =
but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and =
registration first and THEN talk to me=E2=80=9D is a trust impediment =
more than it is a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D =
part of the GNAP name comes from the philosophy of =E2=80=9Cstart =
talking first and figure out what you need as you go=E2=80=9D. Instead =
of jumping through hoops to get something you can trust, you just start =
in and then decide how much you trust it. A corporate rollout could use =
its own key distribution mechanism and static registration to limit =
which client instances talk back to the company server, regardless of =
which accounts would authorize access on top of that. An internet-facing =
service is going to be more likely to take a TLS approach, of =E2=80=9CI=E2=
=80=99ll talk to you in a secure fashion without caring who you are =
right now=E2=80=9D.

We really are trying to make GNAP a consistent protocol at its core and =
learn from problems with OAuth in the wild, all while letting GNAP =
address a wider variety of use cases. I agree that GNAP could be clearer =
about specific use cases, and we=E2=80=99re working on the spec still so =
any help here is appreciated.=20

 =E2=80=94 Justin

> On Feb 24, 2021, at 7:15 AM, Bron Gondwana  =
wrote:
>=20
>=20
>=20
> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
>> (I tend to trend lightly in the pronoun area, mostly because I'm =
shocked that openid included gender but not pronouns)
>>=20
>> I hadn't heard that to be called the NxM problem, so that definitely =
cleared up the potential confusion (at least for me).
>>=20
>> I think GNAPs lack of clarity is a non sequitur for the handling or =
not of the multitrust arbitrary-client with arbitrary-service, however =
it's lack of clarity for me prevents me from knowing whether GNAP =
actually seeks to solve this problem. So from an OAuth WG perspective we =
can still ask:
>>=20
>> Is this or should this problem be left to GNAP to solve, or is an =
OAuth WG responsibility?
>=20
> Honestly I think the problem space is the whole ietf's responsibility. =
Protocols that allow an end user to safely transfer data between two =
parties that don't have a pre-existing trust relationship are a key part =
of enabling user freedom and user choice.
>=20
> Bron.
>=20
>>=20
>>=20
>> Warren Parad
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement =
Authress .
>>=20
>>=20
>> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana =
> wrote:
>>=20
>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>>> I would prefer Bron to answer that question, as they are the one who =
started this email thread.
>>=20
>> You can also use he when talking about me, or she for that matter - I =
do enough group fitness classes where it's roughly assumed that the =
entire class is female, and I have an ambiguous enough name that I'm =
used to it.  Most people use "he" most of the time.
>>=20
>>> However let's look at GNAP, I've honestly been struggling to =
understand at least one fully documented case that GNAP supports. It =
seems in every document the only thing that is clear is GNAP wants to =
allow "everything", doesn't actually talk about an example.
>>=20
>> That's my biggest fear for GNAP - it too will try to be everything to =
everybody and wind up being nothing to nobody because the super flexible =
"everything protocol" is the same as no protocol at all, since you have =
to special-case everybody you talk to anyway.
>>=20
>>> By NxM, I assume we mean that the end user or client is free to =
select whichever AS they want, in a way which the RS can verify the AS =
credential and the user identity, without the RS having to (and really =
without the ability to limit) which AS are allowed.
>>=20
>> Let's get down to use cases then, rather than talking in abstracts.
>>=20
>> I'm an end user with a copy of {The Bat email client} and I want to =
connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a =
widely popular open standard.  I want to be able to authenticate to each =
of those services without saving my plaintext passwords on my hard disk =
where the next {Windows ME} virus will exfiltrate them to =
{Noextraditionistan} and all my {Dogecoin} will then be exfiltrated from =
my {Paybuddy} account, leaving me destitute.
>>=20
>> But, {The Bat} doesn't have a trusted client cert from my isp, =
because who does - so there's no good protocol for me - it's either =
plaintext auth, or it's some architecture astronaut multi-party nonsense =
that's massively over specified and doesn't work half the time.  So I =
write a plain text password on a post-it note which is lying in the dust =
under my monitor because the glue has gone bad, and I hope I never =
accidentally click "remember me" when I type it in.
>>=20
>> That's been the reality of the end user experience for very many =
years.
>>=20
>> NxM means that you can authenticate an arbitrary client against an =
arbitrary server so long as they are both speaking a known public =
protocol, without needing to build a trust relationship between the =
client vendor and the server vendor first.
>>=20
>> Any "trust relationship" is made through a user both who trusts the =
client and trusts the server, and it's not transitive over to other =
users of the same client and the same server.  The client author doesn't =
need to get a signed "I trust you" from every single server, and the =
server author doesn't have to go identify every single client.
>>=20
>> That's what NxM means to a user, the ability to use arbitrary clients =
with arbitrary servers so long as they both implement a documented =
protocol.  Interoperability.
>>=20
>> OAuth has not given interoperability in the NxM sense outside some =
simple web use cases.  They're nice and all, but they don't tend to be =
useful with open protocols - OAuth gets used for accessing proprietary =
API endpoints after getting an access key for a single provider.  At =
least you get Nx1 or 1xM out of it depending who's the N and who's the =
M, and maybe some of your code can rhyme so you're not doing everything =
from scratch each time.
>>=20
>> This is the sorry story of real open protocols.  The floor for true =
interoperability is still username + password over cleartext, over =
hopefully a TLS tunnel that's providing some level of protection.  Most =
so than a few years ago when Fastmail wrote our "starttls considered =
harmful"[1] objection to the IETF's habit at the time of putting a =
"STARTTLS" upgrade into an initially plaintext protocol, where an active =
intercepter could just strip the "I support STARTTLS" indicator from the =
protocol and convince the client to send the credentials in the clear.
>>=20
>> We're a little better mostly these days, but it's still a tirefire, =
and in my heart I do hold the OAuth working group's squatting on this =
area of the landscape while failing to address this burning need =
partially responsible.  The result (as Phillip pointed out upthread) has =
been a consolidation towards a few big players - because NxM becomes =
tractable when you reduce the N and M to small enough numbers.
>>=20
>> Bron.
>>=20
>> [1] =
https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-START=
TLS =

>>=20
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com 
>>=20
>>=20
>=20
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com 
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_836960DE-9A94-44F8-BE83-DFD79296D11D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
agree that the NxM problem is the purview of the whole IETF, but it=E2=80=99=
s something that we=E2=80=99re particularly interested in over in GNAP. =
As the editor of OAuth=E2=80=99s dynamic registration extension and the =
GNAP core protocol, I hope I can add to this conversation.

=46rom a technical =
standpoint, OAuth=E2=80=99s dynamic client registration lets arbitrary =
clients talk to an AS, but the trust isn=E2=80=99t there in practice. On =
top of that I think this problem is exacerbated by a fundamental =
protocol design element of OAuth: the client_id that=E2=80=99s required. =
That field means there=E2=80=99s an assumption that a relationship was =
set up between the pieces of software, implied to be trusted by admins =
at the AS. Sure you can get that client_id under special circumstances, =
but there=E2=80=99s still a special weight handed to that and the =
dynamic stuff feels like you=E2=80=99re giving up control as an AS. In =
GNAP, the relationship is inverted, and it=E2=80=99s designed as =
=E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an =
optimization on top of that.

Does this solve the NxM problem? No, =
because companies are still going to decide that they only talk to keys =
or identifiers that they know ahead of time. But the protocol puts the =
dynamic case forward as baseline and fits in much better with the likes =
of JMAP than OAuth ever could:

- {The Bat} creates a key =
pair.
- {User} enters their email address into =
{Bat}, {Bat} does discovery (maybe that=E2=80=99s a JMAP thing? =
Webfinger?) and finds the JMAP server and the GNAP endpoint for =
authentication as an option.
- {Bat} talks to the =
GNAP AS at {ISP} and presents the key it just made up. {ISP} has never =
seen this key, but knows how to talk GNAP and get the user to authorize =
{Bat} to access email.
- {User} does this using =
GNAP and gets back an access token that=E2=80=99s tied to the key {Bat} =
made back at the beginning. That token is tied (at the {ISP}) to the =
user=E2=80=99s account.

Yes, you can do all of this today with OAuth (and people have =
done so), but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery =
and registration first and THEN talk to me=E2=80=9D is a trust =
impediment more than it is a technical impediment. The =E2=80=9Cnegotiatio=
n=E2=80=9D part of the GNAP name comes from the philosophy of =E2=80=9Csta=
rt talking first and figure out what you need as you go=E2=80=9D. =
Instead of jumping through hoops to get something you can trust, you =
just start in and then decide how much you trust it. A corporate rollout =
could use its own key distribution mechanism and static registration to =
limit which client instances talk back to the company server, regardless =
of which accounts would authorize access on top of that. An =
internet-facing service is going to be more likely to take a TLS =
approach, of =E2=80=9CI=E2=80=99ll talk to you in a secure fashion =
without caring who you are right now=E2=80=9D.

We really are trying to make GNAP a =
consistent protocol at its core and learn from problems with OAuth in =
the wild, all while letting GNAP address a wider variety of use cases. I =
agree that GNAP could be clearer about specific use cases, and we=E2=80=99=
re working on the spec still so any help here is =
appreciated. 

 =E2=80=94 Justin

On Feb =
24, 2021, at 7:15 AM, Bron Gondwana <brong@fastmailteam.com> wrote:



On =
Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
(I tend to trend lightly in =
the pronoun area, mostly because I'm shocked that openid =
included gender but not pronouns)

I hadn't heard that to be called the =
NxM problem, so that definitely cleared up the potential confusion (at =
least for me).

I think GNAPs lack of clarity is =
a non sequitur for the handling or not of the multitrust =
arbitrary-client with arbitrary-service, however it's lack of clarity =
for me prevents me from knowing whether GNAP actually seeks to solve =
this problem. So from an OAuth WG perspective we can still ask:

Is this or should this problem be left to GNAP =
to solve, or is an OAuth WG responsibility?

Honestly I think =
the problem space is the whole ietf's responsibility. Protocols that =
allow an end user to safely transfer data between two parties that don't =
have a pre-existing trust relationship are a key part of enabling user =
freedom and user choice.

Bron.


Warren Parad
Founder, =
CTO
Secure =
your user data with IAM authorization as a service. =
Implement Authress.


On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana =
<brong@fastmailteam.com> wrote:

On Wed, Feb 24, 2021, at 22:04, =
Warren Parad wrote:
I would prefer Bron to answer that question, =
as they are the one who started this email thread.

You can also =
use he when talking about me, or she for that matter - I do enough group =
fitness classes where it's roughly assumed that the entire class is =
female, and I have an ambiguous enough name that I'm used to it.  =
Most people use "he" most of the time.

However let's look at GNAP, I've =
honestly been struggling to understand at least one fully documented =
case that GNAP supports. It seems in every document the only thing that =
is clear is GNAP wants to allow "everything", doesn't actually talk =
about an example.

That's my biggest fear for GNAP =
- it too will try to be everything to everybody and wind up being =
nothing to nobody because the super flexible "everything protocol" is =
the same as no protocol at all, since you have to special-case everybody =
you talk to anyway.

By NxM, I assume we mean that the end user or =
client is free to select whichever AS they want, in a way which the RS =
can verify the AS credential and the user identity, without the RS =
having to (and really without the ability to limit) which AS are =
allowed.

Let's get down to use cases then, rather than talking =
in abstracts.

I'm an end user with a copy of {The Bat email client} and I =
want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports =
{POP3}, a widely popular open standard.  I want to be able to =
authenticate to each of those services without saving my plaintext =
passwords on my hard disk where the next {Windows ME} virus will =
exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will then =
be exfiltrated from my {Paybuddy} account, leaving me destitute.

But, {The =
Bat} doesn't have a trusted client cert from my isp, because who does - =
so there's no good protocol for me - it's either plaintext auth, or it's =
some architecture astronaut multi-party nonsense that's massively over =
specified and doesn't work half the time.  So I write a plain text =
password on a post-it note which is lying in the dust under my monitor =
because the glue has gone bad, and I hope I never accidentally click =
"remember me" when I type it in.

That's been the reality of the =
end user experience for very many years.

NxM means that you can =
authenticate an arbitrary client against an arbitrary server so long as =
they are both speaking a known public protocol, without needing to build =
a trust relationship between the client vendor and the server vendor =
first.

Any "trust relationship" is made through a user both who =
trusts the client and trusts the server, and it's not transitive over to =
other users of the same client and the same server.  The client =
author doesn't need to get a signed "I trust you" from every single =
server, and the server author doesn't have to go identify every single =
client.

That's what NxM means to a user, the ability to use arbitrary =
clients with arbitrary servers so long as they both implement a =
documented protocol.  Interoperability.

OAuth has not given =
interoperability in the NxM sense outside some simple web use =
cases.  They're nice and all, but they don't tend to be useful with =
open protocols - OAuth gets used for accessing proprietary API endpoints =
after getting an access key for a single provider.  At least you =
get Nx1 or 1xM out of it depending who's the N and who's the M, and =
maybe some of your code can rhyme so you're not doing everything from =
scratch each time.

This is the sorry story of real open protocols.  =
The floor for true interoperability is still username + password over =
cleartext, over hopefully a TLS tunnel that's providing some level of =
protection.  Most so than a few years ago when Fastmail wrote our =
"starttls considered harmful"[1] objection to the IETF's habit at the =
time of putting a "STARTTLS" upgrade into an initially plaintext =
protocol, where an active intercepter could just strip the "I support =
STARTTLS" indicator from the protocol and convince the client to send =
the credentials in the clear.

We're a little better mostly =
these days, but it's still a tirefire, and in my heart I do hold the =
OAuth working group's squatting on this area of the landscape while =
failing to address this burning need partially responsible.  The =
result (as Phillip pointed out upthread) has been a consolidation =
towards a few big players - because NxM becomes tractable when you =
reduce the N and M to small enough numbers.

Bron.

[1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TL=
S-and-STARTTLS

--
  Bron Gondwana, =
CEO, Fastmail Pty Ltd
  brong@fastmailteam.com



--
  Bron Gondwana, CEO, =
Fastmail Pty Ltd
  brong@fastmailteam.com

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

=

--Apple-Mail=_836960DE-9A94-44F8-BE83-DFD79296D11D--


From nobody Wed Feb 24 07:22:36 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4683A16F4 for ; Wed, 24 Feb 2021 07:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibe60t4ihza6 for ; Wed, 24 Feb 2021 07:22:32 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369D83A16FB for ; Wed, 24 Feb 2021 07:21:45 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id u8so2323953ior.13 for ; Wed, 24 Feb 2021 07:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tCc3Ue+edzj4nsrVoYuuKtt+iN8MBkphfg3ekdhxjo0=; b=byLjen/KiOqRhvWn4EInCXl5T/smAwnYIS5R6jZavHES8vunKUvp/Erg1+6WZk5uht 90XQu5b82qsIt1VZnn+HeWClx8G5FzgJ8FmYhsQryHMtDWnzRiENjwbfy0ML2LF5W1N3 9Oe3MFji0pjI5uGdGXvTovh8a39+8M0DkYz7QMNXUEg7ccFeRUoNcjLHvMndCUpgFWDv S9n3ehB6Sx5haQ1W0QJ9gHYM1IgMTcoCevSrY+//Y6/u7vV0xHr7AEFEduke1vyBiXdr tZIDoTKF4BAz4BLOjt3tCMPYeLX0p9Y6kCeXz5Lmw43J3911mwg1V6kB4GAb16dbxMW1 x/Lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tCc3Ue+edzj4nsrVoYuuKtt+iN8MBkphfg3ekdhxjo0=; b=QBAgTc/tkMsFQTtZEzGAl7/YlKUhsmKbIEV2xbcCv/LeS0YLIzpfRz/8OR3Wm0BoAF 1g5Ju7guDoJKzmsT5eE+qb/xayHYW/bymVm3MRZ1Inhge5N7RgEOI0bF4/qNlsBTmYsj qiNiOYUBa8xhCFxzxhD54JIuu068z66SsBuoHwLfbpSd3YTgs2B2nYzhX2SfxKbdxReE +PWaOvTRycVSwfNzd/FFSPzb4N37gGfryT+YAB4HqdGsVIfSr544CEFNIV6o1Yce1pCz CcWKujTcdTaBdLnoC+xXCGB9ScLB1VGi8+Tr6dOjLsPUw4DWuhKbKRrqfAT5ESTwcMx/ Zgdg==
X-Gm-Message-State: AOAM531H3KVxC84NMbqoUOnBt+luZXtu86VSzXMzF97tlrlFZbtR9Zc1 Dv36XEu61AkdLAee7BJlDeFMpZVK67ivhQ==
X-Google-Smtp-Source: ABdhPJwD6fAd9dZXwxbcIpk9DbB/cb4JlUvE+G29M6ozXWkmtw77BrJcnGkJzRQXQug+dhMqz36dPQ==
X-Received: by 2002:a5d:9717:: with SMTP id h23mr24439027iol.4.1614180105177;  Wed, 24 Feb 2021 07:21:45 -0800 (PST)
Received: from mail-il1-f170.google.com (mail-il1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id m15sm1677327ilh.6.2021.02.24.07.21.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Feb 2021 07:21:44 -0800 (PST)
Received: by mail-il1-f170.google.com with SMTP id q5so2008913ilc.10; Wed, 24 Feb 2021 07:21:44 -0800 (PST)
X-Received: by 2002:a92:d7ce:: with SMTP id g14mr11616074ilq.255.1614180104249;  Wed, 24 Feb 2021 07:21:44 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com>  
In-Reply-To: 
From: Aaron Parecki 
Date: Wed, 24 Feb 2021 07:21:33 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Jim Willeke 
Cc: ietf@ietf.org, "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b7a5eb05bc1697bf"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 15:22:35 -0000

--000000000000b7a5eb05bc1697bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Sure, you could write it off as "a business problem" but

I did not mean to suggest that I was *writing it off* as a business
problem.

It *is* a very real problem, and I would very much like to see a solution,
however based on my experience it is not something that technology will
solve. This is demonstrated by the fact that there are all the pieces in
place already yet many organizations refuse to adopt them, and it=E2=80=99s
definitely not for a lack of understanding.

Aaron



On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke  wrote:

> But in reality, Just "because the technology" is there there leaves out
> the practicality of creating a secure implementation. Sure, you could wri=
te
> it off as "a business problem" but many of the developers are small and n=
ot
> unusually single person operations that do not have the resources to crea=
te
> a specific team, or even a specific person, to work through all the
> specifications that are involved.
>
> I do believe, in general, specific implementations should not be within
> the specifications but a "Best Practices" or "Common Implementations"
> document to coincide with the specifications might be in order.
>
> Just spend some time on https://stackexchange.com/filters/4229/oauth and
> you will see the issue and struggles.
>
>
> --
> -jim
>
> Jim Willeke
>
>
> On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki  wrote:
>
>> > You type your email address into {The Bat} to begin configuration.
>> {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My
>> ISP}. The discovery document reveals that {My ISP} supports open dynamic
>> client registration [3][4] so {The Bat} registers and gets issued with a
>> client id and client secret. {The Bat} then does a normal OAuth flow to =
get
>> an access token to access your emails from {My ISP}. If you later stop
>> using {The Bat} you can go to your page on {My ISP} and revoke its acces=
s
>> because it has a unique client id.
>>
>> Like Neil says, the building blocks are all already there. The fact that
>> companies choose not to use them is not because the technology isn't the=
re,
>> it's because it's a business problem.
>>
>> I'd be thrilled if the NxM problem were solved in practice, but
>> unfortunately that doesn't seem to be what's happened in the market. The
>> technical solution has been there a long time, so there's something else
>> going on.
>>
>> When I've brought up this topic in the past, most of the responses I've
>> gotten from the "big players" are along the lines of "lol we're not goin=
g
>> to let someone's software talk to us unless we have a legal arrangement
>> with the developer". The fact that dynamic client registration is barely
>> used is more because these service operators want the software developer=
s
>> to agree to their terms of service before being able to access APIs.
>>
>> This is all to say that I agree it'd be nice to solve this problem, but
>> in the end, the IETF can't tell companies what to do with their products
>> and services.
>>
>> Aaron
>>
>>
>>
>>
>> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden 
>> wrote:
>>
>>> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote:
>>>
>>>
>>>
>>> [=E2=80=A6]
>>>
>>>
>>> Let's get down to use cases then, rather than talking in abstracts.
>>>
>>> I'm an end user with a copy of {The Bat email client} and I want to
>>> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a wide=
ly
>>> popular open standard.  I want to be able to authenticate to each of th=
ose
>>> services without saving my plaintext passwords on my hard disk where th=
e
>>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} an=
d
>>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>>> leaving me destitute.
>>>
>>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>>> who does - so there's no good protocol for me - it's either plaintext a=
uth,
>>> or it's some architecture astronaut multi-party nonsense that's massive=
ly
>>> over specified and doesn't work half the time.  So I write a plain text
>>> password on a post-it note which is lying in the dust under my monitor
>>> because the glue has gone bad, and I hope I never accidentally click
>>> "remember me" when I type it in.
>>>
>>> That's been the reality of the end user experience for very many years.
>>>
>>> NxM means that you can authenticate an arbitrary client against an
>>> arbitrary server so long as they are both speaking a known public proto=
col,
>>> without needing to build a trust relationship between the client vendor=
 and
>>> the server vendor first.
>>>
>>>
>>> Does the following meet your needs?
>>>
>>> You type your email address into {The Bat} to begin configuration. {The
>>> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP}=
.
>>> The discovery document reveals that {My ISP} supports open dynamic clie=
nt
>>> registration [3][4] so {The Bat} registers and gets issued with a clien=
t id
>>> and client secret. {The Bat} then does a normal OAuth flow to get an ac=
cess
>>> token to access your emails from {My ISP}. If you later stop using {The
>>> Bat} you can go to your page on {My ISP} and revoke its access because =
it
>>> has a unique client id.
>>>
>>> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
>>> [2]: https://tools.ietf.org/html/rfc8414
>>> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
>>> [4]: https://tools.ietf.org/html/rfc7591
>>>
>>>
>>> Any "trust relationship" is made through a user both who trusts the
>>> client and trusts the server, and it's not transitive over to other use=
rs
>>> of the same client and the same server.  The client author doesn't need=
 to
>>> get a signed "I trust you" from every single server, and the server aut=
hor
>>> doesn't have to go identify every single client.
>>>
>>> That's what NxM means to a user, the ability to use arbitrary clients
>>> with arbitrary servers so long as they both implement a documented
>>> protocol.  Interoperability.
>>>
>>>
>>> That=E2=80=99s fine for your use-case, but that isn=E2=80=99t everybody=
=E2=80=99s use-case.
>>> Other use-cases (such as Open Banking) involve regulatory or policy
>>> frameworks in which open dynamic client registration is not appropriate=
.
>>> JMAP could have an RFC describing the use of OAuth with JMAP that manda=
tes
>>> open dynamic client registration and discovery.
>>>
>>>
>>> =E2=80=94 Neil
>>>
>>>
>>> ForgeRock values your Privacy 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> ---
>> Aaron Parecki
>> https://aaronparecki.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
>
--=20
---
Aaron Parecki
https://aaronparecki.com

--000000000000b7a5eb05bc1697bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> Sure, you could=C2=A0write it off as "a busines=
s problem" but=C2=A0

I did not mean to suggest that I was *writing it off* as a business probl=
em.=C2=A0

It *is* a very=
 real problem, and I would very much like to see a solution, however based =
on my experience it is not something that technology will solve. This is de=
monstrated by the fact that there are all the pieces in place already yet m=
any organizations refuse to adopt them, and it=E2=80=99s definitely not for=
 a lack of understanding.

Aaron



On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke <jim@willeke.com> wrote:
But in reality, Just "because th=
e technology" is there there leaves out the practicality of creating a=
 secure implementation. Sure, you could=C2=A0write it off as "a busine=
ss problem" but many of the developers are small and not unusually=C2=
=A0single person=C2=A0operations that do not have the resources to create a=
 specific team, or even a specific person, to work through all the specific=
ations that are involved.

I do believe, in general, spec=
ific implementations should=C2=A0not be within the=C2=A0specifications but =
a "Best Practices" or "Common Implementations" document=
 to coincide with the=C2=A0specifications might be in order.

=

Just spend some time=C2=A0on=C2=A0https://stackexchange.com/filt=
ers/4229/oauth and you will see the issue and struggles.


---jim

Jim Willeke


On Wed, Feb 24, 2021=
 at 8:46 AM Aaron Parecki <aaron@parecki.com> wrote:
>=C2=A0You type your email address into {The Ba=
t} to begin configuration. {The Bat} does discovery [1][2] to locate the OA=
uth/OIDC server for {My ISP}. The discovery document reveals that {My ISP} =
supports open dynamic client registration [3][4] so {The Bat} registers and=
 gets issued with a client id and client secret. {The Bat} then does a norm=
al OAuth flow to get an access token to access your emails from {My ISP}. I=
f you later stop using {The Bat} you can go to your page on {My ISP} and re=
voke its access because it has a unique client id.

Lik=
e Neil says, the building blocks are all already there. The fact that compa=
nies choose not to use them is not because the technology isn't there, =
it's because it's a business problem.=C2=A0

I&=
#39;d be thrilled if the NxM problem were solved in practice, but unfortuna=
tely that doesn't seem to be what's happened in the market. The tec=
hnical solution has been there a long time, so there's something else g=
oing on.

When I've brought up this topic in the pa=
st, most of the responses I've gotten from the "big players" =
are along the lines of "lol we're not going to let someone's s=
oftware talk to us unless we have a legal arrangement with the developer&qu=
ot;. The fact that dynamic client registration is barely used is more becau=
se these service operators want the software developers to agree to their t=
erms of service before being able to access APIs.

=

This=
 is all to say that I agree it'd be nice to solve this problem, but in =
the end, the IETF can't tell companies what to do with their products a=
nd services.

Aaro=
n




On Wed, Feb 24, 2021 at 4:21 AM Neil Madden <neil.madden@forgerock.c=
om> wrote:
brong@fastmailteam.com> wrote:


[=E2=80=A6=
]

Let's get down to use cases then, rather than talking in abstr=
acts.

I'm an end u=
ser with a copy of {The Bat email client} and I want to connect it to {Gmai=
l} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely popular open st=
andard.=C2=A0 I want to be able to authenticate to each of those services w=
ithout saving my plaintext passwords on my hard disk where the next {Window=
s ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogeco=
in} will then be exfiltrated from my {Paybuddy} account, leaving me destitu=
te.

But, {The Bat} doe=
sn't have a trusted client cert from my isp, because who does - so ther=
e's no good protocol for me - it's either plaintext auth, or it'=
;s some architecture astronaut multi-party nonsense that's massively ov=
er specified and doesn't work half the time.=C2=A0 So I write a plain t=
ext password on a post-it note which is lying in the dust under my monitor =
because the glue has gone bad, and I hope I never accidentally click "=
remember me" when I type it in.

That's been the reality of the end user experience for v=
ery many years.

NxM me=
ans that you can authenticate an arbitrary client against an arbitrary serv=
er so long as they are both speaking a known public protocol, without needi=
ng to build a trust relationship between the client vendor and the server v=
endor first.

Does the follo=
wing meet your needs?

You type your email address =
into {The Bat} to begin configuration. {The Bat} does discovery [1][2] to l=
ocate the OAuth/OIDC server for {My ISP}. The discovery document reveals th=
at {My ISP} supports open dynamic client registration [3][4] so {The Bat} r=
egisters and gets issued with a client id and client secret. {The Bat} then=
 does a normal OAuth flow to get an access token to access your emails from=
 {My ISP}. If you later stop using {The Bat} you can go to your page on {My=
 ISP} and revoke its access because it has a unique client id.


Any "trust relationship" is =
made through a user both who trusts the client and trusts the server, and i=
t's not transitive over to other users of the same client and the same =
server.=C2=A0 The client author doesn't need to get a signed "I tr=
ust you" from every single server, and the server author doesn't h=
ave to go identify every single client.

That's what NxM means to a user, the ability to use a=
rbitrary clients with arbitrary servers so long as they both implement a do=
cumented protocol.=C2=A0 Interoperability.

That=E2=80=99s fine for your use-case, but that isn=E2=80=
=99t everybody=E2=80=99s use-case. Other use-cases (such as Open Banking) i=
nvolve regulatory or policy frameworks in which open dynamic client registr=
ation is not appropriate. JMAP could have an RFC describing the use of OAut=
h with JMAP that mandates open dynamic client registration and discovery.


=E2=80=94 Neil




ForgeRock values your Privacy__=
_____________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---<=
/div>Aaron Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---
Aaron Par=
ecki



--000000000000b7a5eb05bc1697bf--


From nobody Wed Feb 24 07:35:10 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5A93A1723 for ; Wed, 24 Feb 2021 07:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9ZfjwDYh3ag for ; Wed, 24 Feb 2021 07:35:04 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFBF3A1710 for ; Wed, 24 Feb 2021 07:34:47 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id v17so2849829ljj.9 for ; Wed, 24 Feb 2021 07:34:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=+t94oc+veDdddb/XX4zvX9KD9o4K5aXcME4/IfNmEY0=; b=DqSwZdrEt42fp2xquCNNJ1CUtf2cD82GZ4GnjVAbFJ2fyuU0pJx4q2HvaTurgv7H94 H2JWUUEpyrXBIYsahu9AK2eZSy0VrueUg2jO/jvwKY0IijxOnF2oSIJLyQU64Dzt/dCn Gufzcte0ClVzRuSKzKDXyn975bnjeIiEIVqwWmsYq5iomHR7iNjqlxOuXs9j9Jm3X5p9 OgROC6HWRcPy/F+aBOdPEn7ELYmBlxmeoD5aM4CS3brqRckdOhDbt/fFiUOYYLOUVXbK QLBVKqy5IEvsx1JU7oktH3ZWjA11EAcsW84aKvYutuN+k44j/KFPE7qIK1KBpUDcjCqw Tbpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+t94oc+veDdddb/XX4zvX9KD9o4K5aXcME4/IfNmEY0=; b=nqqHBDmLfeVXxCoEJ+Yv3DLlCdjcsjKxIFil3HEODYL5Hua264vhfDKxLcqSMXdKRb riDcjrpcOlFl3lFxV4xOjWx/9ll13DtJ5LTCaGUAa0QlbqPMLC7hiifVgyxX+SsHEeQp Cgf8S+0eldsFj1T+ARJ+VgBE9QVvi5wxSpt57EeYby/tAjvCWCcAWPr7KqFOHj9gyOhy c445RYB5HFhx+rMVvDC/16HZiKng83orTB8xwLy77KVFRh4FtgVe+SeVsso4vJ5zZDWR eqPswbTQev2+PF7hWKzbU9vTMqulPeDB2QJtM6JkHidDMheQs5ly5BTDP/478lBWTF48 LGCw==
X-Gm-Message-State: AOAM5315n6tasnISOPY+f8Jt6nYJtmKjUK0KkTSCRs1v//GLqyLWfKpP EqNioVr7OZTNNxiA66zNn8ZH7pm5KQtLo3rW2GD5pjvL4Hs=
X-Google-Smtp-Source: ABdhPJxKph2HRZ7eEpm2RUjYoPJAIiZbxc5HN/+DJWRV7zh+KBT6MR7Y87agTAAe4NgoZclMbF97+KAkAaGoxYfeRfY=
X-Received: by 2002:a2e:8541:: with SMTP id u1mr20625454ljj.338.1614180884960;  Wed, 24 Feb 2021 07:34:44 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> <02A263F5-8109-4D3B-A684-D9B574260B50@forgerock.com>   
In-Reply-To: 
From: Jim Willeke 
Date: Wed, 24 Feb 2021 10:34:08 -0500
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary="000000000000406c9305bc16c697"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 15:35:08 -0000

--000000000000406c9305bc16c697
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I didn't mean to imply "you" were writing it off and you are probably right
technology may not be able to solve it, I was just looking for ways we
might help?

--
-jim
Jim Willeke


On Wed, Feb 24, 2021 at 10:21 AM Aaron Parecki  wrote:

> > Sure, you could write it off as "a business problem" but
>
> I did not mean to suggest that I was *writing it off* as a business
> problem.
>
> It *is* a very real problem, and I would very much like to see a solution=
,
> however based on my experience it is not something that technology will
> solve. This is demonstrated by the fact that there are all the pieces in
> place already yet many organizations refuse to adopt them, and it=E2=80=
=99s
> definitely not for a lack of understanding.
>
> Aaron
>
>
>
> On Wed, Feb 24, 2021 at 7:01 AM Jim Willeke  wrote:
>
>> But in reality, Just "because the technology" is there there leaves out
>> the practicality of creating a secure implementation. Sure, you could wr=
ite
>> it off as "a business problem" but many of the developers are small and =
not
>> unusually single person operations that do not have the resources to cre=
ate
>> a specific team, or even a specific person, to work through all the
>> specifications that are involved.
>>
>> I do believe, in general, specific implementations should not be within
>> the specifications but a "Best Practices" or "Common Implementations"
>> document to coincide with the specifications might be in order.
>>
>> Just spend some time on https://stackexchange.com/filters/4229/oauth and
>> you will see the issue and struggles.
>>
>>
>> --
>> -jim
>>
>> Jim Willeke
>>
>>
>> On Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki  wrote:
>>
>>> > You type your email address into {The Bat} to begin configuration.
>>> {The Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My
>>> ISP}. The discovery document reveals that {My ISP} supports open dynami=
c
>>> client registration [3][4] so {The Bat} registers and gets issued with =
a
>>> client id and client secret. {The Bat} then does a normal OAuth flow to=
 get
>>> an access token to access your emails from {My ISP}. If you later stop
>>> using {The Bat} you can go to your page on {My ISP} and revoke its acce=
ss
>>> because it has a unique client id.
>>>
>>> Like Neil says, the building blocks are all already there. The fact tha=
t
>>> companies choose not to use them is not because the technology isn't th=
ere,
>>> it's because it's a business problem.
>>>
>>> I'd be thrilled if the NxM problem were solved in practice, but
>>> unfortunately that doesn't seem to be what's happened in the market. Th=
e
>>> technical solution has been there a long time, so there's something els=
e
>>> going on.
>>>
>>> When I've brought up this topic in the past, most of the responses I've
>>> gotten from the "big players" are along the lines of "lol we're not goi=
ng
>>> to let someone's software talk to us unless we have a legal arrangement
>>> with the developer". The fact that dynamic client registration is barel=
y
>>> used is more because these service operators want the software develope=
rs
>>> to agree to their terms of service before being able to access APIs.
>>>
>>> This is all to say that I agree it'd be nice to solve this problem, but
>>> in the end, the IETF can't tell companies what to do with their product=
s
>>> and services.
>>>
>>> Aaron
>>>
>>>
>>>
>>>
>>> On Wed, Feb 24, 2021 at 4:21 AM Neil Madden 
>>> wrote:
>>>
>>>> On 24 Feb 2021, at 11:39, Bron Gondwana  wrote=
:
>>>>
>>>>
>>>>
>>>> [=E2=80=A6]
>>>>
>>>>
>>>> Let's get down to use cases then, rather than talking in abstracts.
>>>>
>>>> I'm an end user with a copy of {The Bat email client} and I want to
>>>> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a wid=
ely
>>>> popular open standard.  I want to be able to authenticate to each of t=
hose
>>>> services without saving my plaintext passwords on my hard disk where t=
he
>>>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} a=
nd
>>>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>>>> leaving me destitute.
>>>>
>>>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>>>> who does - so there's no good protocol for me - it's either plaintext =
auth,
>>>> or it's some architecture astronaut multi-party nonsense that's massiv=
ely
>>>> over specified and doesn't work half the time.  So I write a plain tex=
t
>>>> password on a post-it note which is lying in the dust under my monitor
>>>> because the glue has gone bad, and I hope I never accidentally click
>>>> "remember me" when I type it in.
>>>>
>>>> That's been the reality of the end user experience for very many years=
.
>>>>
>>>> NxM means that you can authenticate an arbitrary client against an
>>>> arbitrary server so long as they are both speaking a known public prot=
ocol,
>>>> without needing to build a trust relationship between the client vendo=
r and
>>>> the server vendor first.
>>>>
>>>>
>>>> Does the following meet your needs?
>>>>
>>>> You type your email address into {The Bat} to begin configuration. {Th=
e
>>>> Bat} does discovery [1][2] to locate the OAuth/OIDC server for {My ISP=
}.
>>>> The discovery document reveals that {My ISP} supports open dynamic cli=
ent
>>>> registration [3][4] so {The Bat} registers and gets issued with a clie=
nt id
>>>> and client secret. {The Bat} then does a normal OAuth flow to get an a=
ccess
>>>> token to access your emails from {My ISP}. If you later stop using {Th=
e
>>>> Bat} you can go to your page on {My ISP} and revoke its access because=
 it
>>>> has a unique client id.
>>>>
>>>> [1]: https://openid.net/specs/openid-connect-discovery-1_0.html
>>>> [2]: https://tools.ietf.org/html/rfc8414
>>>> [3]: https://openid.net/specs/openid-connect-registration-1_0.html
>>>> [4]: https://tools.ietf.org/html/rfc7591
>>>>
>>>>
>>>> Any "trust relationship" is made through a user both who trusts the
>>>> client and trusts the server, and it's not transitive over to other us=
ers
>>>> of the same client and the same server.  The client author doesn't nee=
d to
>>>> get a signed "I trust you" from every single server, and the server au=
thor
>>>> doesn't have to go identify every single client.
>>>>
>>>> That's what NxM means to a user, the ability to use arbitrary clients
>>>> with arbitrary servers so long as they both implement a documented
>>>> protocol.  Interoperability.
>>>>
>>>>
>>>> That=E2=80=99s fine for your use-case, but that isn=E2=80=99t everybod=
y=E2=80=99s use-case.
>>>> Other use-cases (such as Open Banking) involve regulatory or policy
>>>> frameworks in which open dynamic client registration is not appropriat=
e.
>>>> JMAP could have an RFC describing the use of OAuth with JMAP that mand=
ates
>>>> open dynamic client registration and discovery.
>>>>
>>>>
>>>> =E2=80=94 Neil
>>>>
>>>>
>>>> ForgeRock values your Privacy 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> --
>>> ---
>>> Aaron Parecki
>>> https://aaronparecki.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
>>
> --
> ---
> Aaron Parecki
> https://aaronparecki.com
>
>

--000000000000406c9305bc16c697
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I didn't mean to=C2=A0imply "you" were writi=
ng=C2=A0it off and you are probably right technology may not be able to sol=
ve it, I was just looking for ways we might help?

--
=
-jim
Jim Willeke


On Wed, Feb 24, 2021 at 10:21 AM Aaron Parecki <<=
a href=3D"mailto:aaron@parecki.com">aaron@parecki.com> wrote:
>=
 Sure, you could=C2=A0write it off as "a business problem" but=C2=
=A0

I did not mean to su=
ggest that I was *writing it off* as a business problem.=C2=A0

It *is* a very real problem, and I w=
ould very much like to see a solution, however based on my experience it is=
 not something that technology will solve. This is demonstrated by the fact=
 that there are all the pieces in place already yet many organizations refu=
se to adopt them, and it=E2=80=99s definitely not for a lack of understandi=
ng.

Aaron



On W=
ed, Feb 24, 2021 at 7:01 AM Jim Willeke <jim@willeke.com> wrote:
But in reality, Just =
"because the technology" is there there leaves out the practicali=
ty of creating a secure implementation. Sure, you could=C2=A0write it off a=
s "a business problem" but many of the developers are small and n=
ot unusually=C2=A0single person=C2=A0operations that do not have the resour=
ces to create a specific team, or even a specific person, to work through a=
ll the specifications that are involved.

I do believe, i=
n general, specific implementations should=C2=A0not be within the=C2=A0spec=
ifications but a "Best Practices" or "Common Implementations=
" document to coincide with the=C2=A0specifications might be in order.=


Just spend some time=C2=A0on=C2=A0https://stackex=
change.com/filters/4229/oauth and you will see the issue and struggles.=



--
-jim
=


Jim Willeke

<=
/div>
O=
n Wed, Feb 24, 2021 at 8:46 AM Aaron Parecki <aaron@parecki.com> wrote:
>=C2=A0<=
span style=3D"color:rgb(49,49,49);word-spacing:1px">You type your email add=
ress into {The Bat} to begin configuration. {The Bat} does discovery [1][2]=
 to locate the OAuth/OIDC server for {My ISP}. The discovery document revea=
ls that {My ISP} supports open dynamic client registration [3][4] so {The B=
at} registers and gets issued with a client id and client secret. {The Bat}=
 then does a normal OAuth flow to get an access token to access your emails=
 from {My ISP}. If you later stop using {The Bat} you can go to your page o=
n {My ISP} and revoke its access because it has a unique client id.<=
/div>

Like Neil says, the building blocks are all already there. Th=
e fact that companies choose not to use them is not because the technology =
isn't there, it's because it's a business problem.=C2=A0=


I'd be thrilled if the NxM problem were solved in practi=
ce, but unfortunately that doesn't seem to be what's happened in th=
e market. The technical solution has been there a long time, so there's=
 something else going on.

When I've brought up thi=
s topic in the past, most of the responses I've gotten from the "b=
ig players" are along the lines of "lol we're not going to le=
t someone's software talk to us unless we have a legal arrangement with=
 the developer". The fact that dynamic client registration is barely u=
sed is more because these service operators want the software developers to=
 agree to their terms of service before being able to access APIs.
=

This is all to say that I agree it'd be nice to solve this=
 problem, but in the end, the IETF can't tell companies what to do with=
 their products and services.

Aaron


<=
/div>


On Wed, Feb 24, 2021 at 4:21 AM Neil Madden=
 <neil.ma=
dden@forgerock.com> wrote:
On 24 Feb 2021, at 11:39, Bron Gondwana <brong@fastmailteam.com=
> wrote:


[=E2=80=A6]

Let's get down to=
 use cases then, rather than talking in abstracts.
I'm an end user with a copy of {The Bat em=
ail client} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.=C2=A0=
 It supports {POP3}, a widely popular open standard.=C2=A0 I want to be abl=
e to authenticate to each of those services without saving my plaintext pas=
swords on my hard disk where the next {Windows ME} virus will exfiltrate th=
em to {Noextraditionistan} and all my {Dogecoin} will then be exfiltrated f=
rom my {Paybuddy} account, leaving me destitute.
=

But, {The Bat} doesn't have a trusted client=
 cert from my isp, because who does - so there's no good protocol for m=
e - it's either plaintext auth, or it's some architecture astronaut=
 multi-party nonsense that's massively over specified and doesn't w=
ork half the time.=C2=A0 So I write a plain text password on a post-it note=
 which is lying in the dust under my monitor because the glue has gone bad,=
 and I hope I never accidentally click "remember me" when I type =
it in.

That's been=
 the reality of the end user experience for very many years.

NxM means that you can authenticate =
an arbitrary client against an arbitrary server so long as they are both sp=
eaking a known public protocol, without needing to build a trust relationsh=
ip between the client vendor and the server vendor first.

Does the following meet your needs?

You type your email address into {The Bat} to begin config=
uration. {The Bat} does discovery [1][2] to locate the OAuth/OIDC server fo=
r {My ISP}. The discovery document reveals that {My ISP} supports open dyna=
mic client registration [3][4] so {The Bat} registers and gets issued with =
a client id and client secret. {The Bat} then does a normal OAuth flow to g=
et an access token to access your emails from {My ISP}. If you later stop u=
sing {The Bat} you can go to your page on {My ISP} and revoke its access be=
cause it has a unique client id.

=


Any "trust relationship" is made through a user both who t=
rusts the client and trusts the server, and it's not transitive over to=
 other users of the same client and the same server.=C2=A0 The client autho=
r doesn't need to get a signed "I trust you" from every singl=
e server, and the server author doesn't have to go identify every singl=
e client.

That's w=
hat NxM means to a user, the ability to use arbitrary clients with arbitrar=
y servers so long as they both implement a documented protocol.=C2=A0 Inter=
operability.

That=E2=80=99s=
 fine for your use-case, but that isn=E2=80=99t everybody=E2=80=99s use-cas=
e. Other use-cases (such as Open Banking) involve regulatory or policy fram=
eworks in which open dynamic client registration is not appropriate. JMAP c=
ould have an RFC describing the use of OAuth with JMAP that mandates open d=
ynamic client registration and discovery.

=E2=80=94 Neil




ForgeRock values your Privacy__=
_____________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---<=
/div>Aaron Parecki


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


-- 
---<=
/div>Aaron Parecki





--000000000000406c9305bc16c697--


From nobody Wed Feb 24 08:34:54 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA933A17C6 for ; Wed, 24 Feb 2021 08:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level: 
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcCei88CHi4s for ; Wed, 24 Feb 2021 08:34:49 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369043A17C5 for ; Wed, 24 Feb 2021 08:34:49 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id z11so3935789lfb.9 for ; Wed, 24 Feb 2021 08:34:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AZuMFp7PsGgU7KkA0fIqaQ/CsSu3p23VCP2gJAZFRV8=; b=ey00CWCe7C+TdIld48gKy5Wi+Kv3Q5i4bLuPYaIoxi4r7etFyYNq0DG21HqDNDugP3 nxGXctN/+9fjkRa78EttR3qurpu6uEVQJwvdFdpjCoEnJGy9NmlypZw0n9znl0pLtCO3 RejQYzJ+OHwf3N2upKddpG8jIRtGjKZzgi+c5nKIJQCxVSA2dHN36eHbpr2Jl/64aOvj EL2eXILG3o5lnjiPHHDFzdb0wwaUO+GqvkakxB8HHE3m3jLZlkQGFcFjW31Kk91tIdLy PCt1noGmO9FhjFVBYCaaqrOr9kCDYATw0GX7xJc6WJfz4IsuaqHowC4Ax1Dq1axXgKz9 nhIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AZuMFp7PsGgU7KkA0fIqaQ/CsSu3p23VCP2gJAZFRV8=; b=SGYLQ12rEUCWrhpBDa0rcEbMT9NTL3AVNGG26MkT2q3r9I+ihzxNlqUkV5vaGsVAVt 4zuWFJ63DqxYLyTe4q9MhdS3hpfkETGMFWuaL7tUZ6KZL+7G1m94nS0usZV+FNQ1b8nB tywWx8egYr7JmOEapnWjosRWoZdIVd9hnVOrWgbc8bqmI6uGhhRe+Ow4w6Qt1wlomq34 Awy/G0+jVBmv0Hqr89NWQ4LBIhm7Blh7WnDsfF1HbLL8Co33kRL3J35Inea5G4xNQHWY FD+nKCgTnBZtNwuNqCvsTFQ+Qlv2UQXKTnLaicNtGtoF2wyxhGpj1g7zS5KaMnwzTNmA kzFQ==
X-Gm-Message-State: AOAM5319Pw1z2kM9G5vO0HMgCmJ3sa7LLqc9vxpV9F4Lh5eHU/VBJOaN GpGnFBfC3k37cT+FfU9QPJ6ct8ZNvV2UjkSQ26/c5A==
X-Google-Smtp-Source: ABdhPJykG4yl+AuzSDikiy6cYw8mV7qzwuaTxuYfA6TEhIAYYd19gUVtPLtIdbcdEfi+mrSbPYYphmS4ai8vgxxKx7I=
X-Received: by 2002:ac2:41ce:: with SMTP id d14mr16953743lfi.451.1614184487277;  Wed, 24 Feb 2021 08:34:47 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com> 
In-Reply-To: 
From: Tim Bray 
Date: Wed, 24 Feb 2021 08:34:35 -0800
Message-ID: 
To: Justin Richer 
Cc: Bron Gondwana , Phillip Hallam-Baker ,  Warren Parad , "oauth@ietf.org" ,  IETF-Discussion Discussion 
Content-Type: multipart/alternative; boundary="000000000000f769cf05bc179c3f"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 16:34:53 -0000

--000000000000f769cf05bc179c3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

 The OAuth work has successfully built a perfectly reasonable syntax and
protocol for exchanging identity and attribute assertions, and that's
fine.  What it hasn't done is opened up the world of Identity Provision,
but that's not a technical problem.

OAuth flowed out of OpenID back in the day. The core idea of OpenID,
beginning with the attractive but wrong notion that URIs are a good way for
people to identify themselves, was that service providers should be
prepared to trust arbitrary identity providers.  At the moment, nobody has
figured out an automated way for services to figure out which  identity
providers they want to trust. The counter-argument is that service
providers should just trust people to pick appropriate identity providers,
and it has never in my experience succeeded in convincing a single lawyer
or business-policy type.



On Wed, Feb 24, 2021 at 7:21 AM Justin Richer  wrote:

> I agree that the NxM problem is the purview of the whole IETF, but it=E2=
=80=99s
> something that we=E2=80=99re particularly interested in over in GNAP. As =
the editor
> of OAuth=E2=80=99s dynamic registration extension and the GNAP core proto=
col, I
> hope I can add to this conversation.
>
> From a technical standpoint, OAuth=E2=80=99s dynamic client registration =
lets
> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in pra=
ctice. On
> top of that I think this problem is exacerbated by a fundamental protocol
> design element of OAuth: the client_id that=E2=80=99s required. That fiel=
d means
> there=E2=80=99s an assumption that a relationship was set up between the =
pieces of
> software, implied to be trusted by admins at the AS. Sure you can get tha=
t
> client_id under special circumstances, but there=E2=80=99s still a specia=
l weight
> handed to that and the dynamic stuff feels like you=E2=80=99re giving up =
control as
> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed a=
s
> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an opt=
imization on top
> of that.
>
> Does this solve the NxM problem? No, because companies are still going to
> decide that they only talk to keys or identifiers that they know ahead of
> time. But the protocol puts the dynamic case forward as baseline and fits
> in much better with the likes of JMAP than OAuth ever could:
>
> - {The Bat} creates a key pair.
> - {User} enters their email address into {Bat}, {Bat} does discovery
> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP server=
 and the
> GNAP endpoint for authentication as an option.
> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
> up. {ISP} has never seen this key, but knows how to talk GNAP and get the
> user to authorize {Bat} to access email.
> - {User} does this using GNAP and gets back an access token that=E2=80=99=
s tied to
> the key {Bat} made back at the beginning. That token is tied (at the {ISP=
})
> to the user=E2=80=99s account.
>
> Yes, you can do all of this today with OAuth (and people have done so),
> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registrat=
ion first and THEN
> talk to me=E2=80=9D is a trust impediment more than it is a technical imp=
ediment.
> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the ph=
ilosophy of =E2=80=9Cstart
> talking first and figure out what you need as you go=E2=80=9D. Instead of=
 jumping
> through hoops to get something you can trust, you just start in and then
> decide how much you trust it. A corporate rollout could use its own key
> distribution mechanism and static registration to limit which client
> instances talk back to the company server, regardless of which accounts
> would authorize access on top of that. An internet-facing service is goin=
g
> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk t=
o you in a secure
> fashion without caring who you are right now=E2=80=9D.
>
> We really are trying to make GNAP a consistent protocol at its core and
> learn from problems with OAuth in the wild, all while letting GNAP addres=
s
> a wider variety of use cases. I agree that GNAP could be clearer about
> specific use cases, and we=E2=80=99re working on the spec still so any he=
lp here is
> appreciated.
>
>  =E2=80=94 Justin
>
> On Feb 24, 2021, at 7:15 AM, Bron Gondwana  wrote=
:
>
>
>
> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
>
> (I tend to trend lightly in the pronoun area, mostly because I'm shocked
> that openid included gender but not pronouns)
>
> I hadn't heard that to be called the NxM problem, so that definitely
> cleared up the potential confusion (at least for me).
>
> I think GNAPs lack of clarity is a non sequitur for the handling or not o=
f
> the multitrust arbitrary-client with arbitrary-service, however it's lack
> of clarity for me prevents me from knowing whether GNAP actually seeks to
> solve this problem. So from an OAuth WG perspective we can still ask:
>
> *Is this or should this problem be left to GNAP to solve, or is an OAuth
> WG responsibility?*
>
>
> Honestly I think the problem space is the whole ietf's responsibility.
> Protocols that allow an end user to safely transfer data between two
> parties that don't have a pre-existing trust relationship are a key part =
of
> enabling user freedom and user choice.
>
> Bron.
>
>
> *Warren Parad*
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana 
> wrote:
>
>
> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>
> I would prefer Bron to answer that question, as they are the one who
> started this email thread.
>
>
> You can also use he when talking about me, or she for that matter - I do
> enough group fitness classes where it's roughly assumed that the entire
> class is female, and I have an ambiguous enough name that I'm used to it.
> Most people use "he" most of the time.
>
> However let's look at GNAP, I've honestly been struggling to understand a=
t
> least one fully documented case that GNAP supports. It seems in every
> document the only thing that is clear is GNAP wants to allow "everything"=
,
> doesn't actually talk about an example.
>
>
> That's my biggest fear for GNAP - it too will try to be everything to
> everybody and wind up being nothing to nobody because the super flexible
> "everything protocol" is the same as no protocol at all, since you have t=
o
> special-case everybody you talk to anyway.
>
> By NxM, I assume we mean that the end user or client is free to select
> whichever AS they want, in a way which the RS can verify the AS credentia=
l
> and the user identity, without the RS having to (and really without the
> ability to limit) which AS are allowed.
>
>
> Let's get down to use cases then, rather than talking in abstracts.
>
> I'm an end user with a copy of {The Bat email client} and I want to
> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely
> popular open standard.  I want to be able to authenticate to each of thos=
e
> services without saving my plaintext passwords on my hard disk where the
> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
> leaving me destitute.
>
> But, {The Bat} doesn't have a trusted client cert from my isp, because wh=
o
> does - so there's no good protocol for me - it's either plaintext auth, o=
r
> it's some architecture astronaut multi-party nonsense that's massively ov=
er
> specified and doesn't work half the time.  So I write a plain text passwo=
rd
> on a post-it note which is lying in the dust under my monitor because the
> glue has gone bad, and I hope I never accidentally click "remember me" wh=
en
> I type it in.
>
> That's been the reality of the end user experience for very many years.
>
> NxM means that you can authenticate an arbitrary client against an
> arbitrary server so long as they are both speaking a known public protoco=
l,
> without needing to build a trust relationship between the client vendor a=
nd
> the server vendor first.
>
> Any "trust relationship" is made through a user both who trusts the clien=
t
> and trusts the server, and it's not transitive over to other users of the
> same client and the same server.  The client author doesn't need to get a
> signed "I trust you" from every single server, and the server author
> doesn't have to go identify every single client.
>
> That's what NxM means to a user, the ability to use arbitrary clients wit=
h
> arbitrary servers so long as they both implement a documented protocol.
> Interoperability.
>
> OAuth has not given interoperability in the NxM sense outside some simple
> web use cases.  They're nice and all, but they don't tend to be useful wi=
th
> open protocols - OAuth gets used for accessing proprietary API endpoints
> after getting an access key for a single provider.  At least you get Nx1 =
or
> 1xM out of it depending who's the N and who's the M, and maybe some of yo=
ur
> code can rhyme so you're not doing everything from scratch each time.
>
> This is the sorry story of real open protocols.  The floor for true
> interoperability is still username + password over cleartext, over
> hopefully a TLS tunnel that's providing some level of protection.  Most s=
o
> than a few years ago when Fastmail wrote our "starttls considered
> harmful"[1] objection to the IETF's habit at the time of putting a
> "STARTTLS" upgrade into an initially plaintext protocol, where an active
> intercepter could just strip the "I support STARTTLS" indicator from the
> protocol and convince the client to send the credentials in the clear.
>
> We're a little better mostly these days, but it's still a tirefire, and i=
n
> my heart I do hold the OAuth working group's squatting on this area of th=
e
> landscape while failing to address this burning need partially
> responsible.  The result (as Phillip pointed out upthread) has been a
> consolidation towards a few big players - because NxM becomes tractable
> when you reduce the N and M to small enough numbers.
>
> Bron.
>
> [1]
> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STAR=
TTLS
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

--000000000000f769cf05bc179c3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 The OAuth work=C2=A0has successfully built a perfectly reaso=
nable syntax and protocol for exchanging identity and attribute assertions,=
 and that's fine.=C2=A0 What it hasn't done is opened up the world =
of Identity Provision, but that's not a technical problem.=C2=A0
<=
div class=3D"gmail_default" style=3D"font-size:small">
OAuth flowed out of OpenID bac=
k in the day. The core idea of OpenID, beginning with the attractive but wr=
ong notion that URIs are a good way for people to identify themselves, was =
that service providers should be prepared to trust arbitrary identity provi=
ders.=C2=A0 At the moment, nobody has figured out an automated way for serv=
ices to figure out which=C2=A0 identity providers they want to trust. The c=
ounter-argument is that service providers should just trust people to pick =
appropriate identity providers, and it has never in my experience succeeded=
=C2=A0in convincing a single lawyer or business-policy type.



On Wed, Feb 24, 2021 at=
 7:21 AM Justin Richer <jricher@mit.e=
du> wrote:
I agree that the NxM problem is the purvi=
ew of the whole IETF, but it=E2=80=99s something that we=E2=80=99re particu=
larly interested in over in GNAP. As the editor of OAuth=E2=80=99s dynamic =
registration extension and the GNAP core protocol, I hope I can add to this=
 conversation.

From a technical standpoint, OAuth=E2=80=
=99s dynamic client registration lets arbitrary clients talk to an AS, but =
the trust isn=E2=80=99t there in practice. On top of that I think this prob=
lem is exacerbated by a fundamental protocol design element of OAuth: the c=
lient_id that=E2=80=99s required. That field means there=E2=80=99s an assum=
ption that a relationship was set up between the pieces of software, implie=
d to be trusted by admins at the AS. Sure you can get that client_id under =
special circumstances, but there=E2=80=99s still a special weight handed to=
 that and the dynamic stuff feels like you=E2=80=99re giving up control as =
an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed as =
=E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an optim=
ization on top of that.

Does this solve the NxM pr=
oblem? No, because companies are still going to decide that they only talk =
to keys or identifiers that they know ahead of time. But the protocol puts =
the dynamic case forward as baseline and fits in much better with the likes=
 of JMAP than OAuth ever could:

- {The Bat} create=
s a key pair.
- {User} enters their email address into {Bat}, {Ba=
t} does discovery (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds=
 the JMAP server and the GNAP endpoint for authentication as an option.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it just m=
ade up. {ISP} has never seen this key, but knows how to talk GNAP and get t=
he user to authorize {Bat} to access email.
- {User} does this us=
ing GNAP and gets back an access token that=E2=80=99s tied to the key {Bat}=
 made back at the beginning. That token is tied (at the {ISP}) to the user=
=E2=80=99s account.

Yes, you can do all of this to=
day with OAuth (and people have done so), but OAuth=E2=80=99s basic model o=
f =E2=80=9Cgo do discovery and registration first and THEN talk to me=E2=80=
=9D is a trust impediment more than it is a technical impediment. The =E2=
=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the philosophy =
of =E2=80=9Cstart talking first and figure out what you need as you go=E2=
=80=9D. Instead of jumping through hoops to get something you can trust, yo=
u just start in and then decide how much you trust it. A corporate rollout =
could use its own key distribution mechanism and static registration to lim=
it which client instances talk back to the company server, regardless of wh=
ich accounts would authorize access on top of that. An internet-facing serv=
ice is going to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=
=99ll talk to you in a secure fashion without caring who you are right now=
=E2=80=9D.

We really are trying to make GNAP a con=
sistent protocol at its core and learn from problems with OAuth in the wild=
, all while letting GNAP address a wider variety of use cases. I agree that=
 GNAP could be clearer about specific use cases, and we=E2=80=99re working =
on the spec still so any help here is appreciated.=C2=A0

=C2=A0=E2=80=94 Justin

On=
 Feb 24, 2021, at 7:15 AM, Bron Gondwana <brong@fastmailteam.com> wrote:


On Wed, Feb 24, =
2021, at 23:09, Warren Parad wrote:
(I =
tend to trend lightly in the=C2=A0pronoun area, mostly because I'm=C2=
=A0shocked that openid included gender but not pronouns)

=

I hadn't heard that to be called the NxM problem, so that de=
finitely cleared up the potential confusion (at least for me).

I think GNAPs lack of clarity is a=C2=A0non sequitur for t=
he handling or not of the multitrust arbitrary-client with arbitrary-servic=
e, however it's lack of clarity for me prevents me from knowing whether=
 GNAP actually seeks to solve this problem. So from an OAuth WG perspective=
 we can still ask:

Is this or should t=
his problem be left to GNAP to solve, or is an OAuth WG responsibility?=


Honestly I think the problem space is the whole ietf's responsibili=
ty. Protocols that allow an end user to safely transfer data between two pa=
rties that don't have a pre-existing trust relationship are a key part =
of enabling user freedom and user choice.

Bron.

<=
/span>
Warren Parad
Founder, CTO
Secure your user data with IAM authorization as a service. Im=
plement=C2=A0Authress.


On Wed, Feb 24, 2021 at 12:39=
 PM Bron Gondwana <brong@fastmailteam.com> wrote:

On Wed, Feb 24, 2021, at 22:04, Warren Pa=
rad wrote:
I would prefer =
Bron to answer that question, as they are the one who started this email th=
read.

You can=
 also use he when talking about me, or she for that matter - I do enough gr=
oup fitness classes where it's roughly assumed that the entire class is=
 female, and I have an ambiguous enough name that I'm used to it.=C2=A0=
 Most people use "he" most of the time.

Ho=
wever let's look at GNAP, I've honestly been struggling to understa=
nd at least one fully documented case that GNAP supports. It seems in every=
 document the only thing that is clear is GNAP wants to allow "everyth=
ing", doesn't actually talk about an example.

That's my biggest fear for GNAP - it too will try to be everyt=
hing to everybody and wind up being nothing to nobody because the super fle=
xible "everything protocol" is the same as no protocol at all, si=
nce you have to special-case everybody you talk to anyway.

By NxM, I assume we mean that the end user or client is free to select whi=
chever AS they want, in a way which the RS can verify the AS credential and=
 the user identity, without the RS having to (and really without the abilit=
y to limit) which AS are allowed.

Let's ge=
t down to use cases then, rather than talking in abstracts.

I'=
;m an end user with a copy of {The Bat email client} and I want to connect =
it to {Gmail} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely popu=
lar open standard.=C2=A0 I want to be able to authenticate to each of those=
 services without saving my plaintext passwords on my hard disk where the n=
ext {Windows ME} virus will exfiltrate them to {Noextraditionistan} and all=
 my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leaving=
 me destitute.

But, {The Bat} doesn't have a trusted client c=
ert from my isp, because who does - so there's no good protocol for me =
- it's either plaintext auth, or it's some architecture astronaut m=
ulti-party nonsense that's massively over specified and doesn't wor=
k half the time.=C2=A0 So I write a plain text password on a post-it note w=
hich is lying in the dust under my monitor because the glue has gone bad, a=
nd I hope I never accidentally click "remember me" when I type it=
 in.

That's been the reality of the end user experience for v=
ery many years.

NxM means that you can authenticate an arbitrary =
client against an arbitrary server so long as they are both speaking a know=
n public protocol, without needing to build a trust relationship between th=
e client vendor and the server vendor first.

Any "trust rela=
tionship" is made through a user both who trusts the client and trusts=
 the server, and it's not transitive over to other users of the same cl=
ient and the same server.=C2=A0 The client author doesn't need to get a=
 signed "I trust you" from every single server, and the server au=
thor doesn't have to go identify every single client.

That=
9;s what NxM means to a user, the ability to use arbitrary clients with arb=
itrary servers so long as they both implement a documented protocol.=C2=A0 =
Interoperability.

OAuth has not given interoperability in the NxM=
 sense outside some simple web use cases.=C2=A0 They're nice and all, b=
ut they don't tend to be useful with open protocols - OAuth gets used f=
or accessing proprietary API endpoints after getting an access key for a si=
ngle provider.=C2=A0 At least you get Nx1 or 1xM out of it depending who=
9;s the N and who's the M, and maybe some of your code can rhyme so you=
're not doing everything from scratch each time.

This is the =
sorry story of real open protocols.=C2=A0 The floor for true interoperabili=
ty is still username + password over cleartext, over hopefully a TLS tunnel=
 that's providing some level of protection.=C2=A0 Most so than a few ye=
ars ago when Fastmail wrote our "starttls considered harmful"[1] =
objection to the IETF's habit at the time of putting a "STARTTLS&q=
uot; upgrade into an initially plaintext protocol, where an active intercep=
ter could just strip the "I support STARTTLS" indicator from the =
protocol and convince the client to send the credentials in the clear.
<=
/div>

We're a little better mostly these days, but it's still a tir=
efire, and in my heart I do hold the OAuth working group's squatting on=
 this area of the landscape while failing to address this burning need part=
ially responsible.=C2=A0 The result (as Phillip pointed out upthread) has b=
een a consolidation towards a few big players - because NxM becomes tractab=
le when you reduce the N and M to small enough numbers.

Bron.
=


[1]=C2=A0https://www.f=
astmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS

--
=
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd


=

--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd

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

<=
/div>

--000000000000f769cf05bc179c3f--


From nobody Wed Feb 24 08:48:46 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB533A17E9 for ; Wed, 24 Feb 2021 08:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGj9LaKvnhbk for ; Wed, 24 Feb 2021 08:48:41 -0800 (PST)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763393A17EB for ; Wed, 24 Feb 2021 08:48:41 -0800 (PST)
Received: by mail-il1-x136.google.com with SMTP id o1so2269907ila.11 for ; Wed, 24 Feb 2021 08:48:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bYSmnpdczEgCtvBK56XkA/Agge/3wFSXb0DyUhLLI+I=; b=GwjAenfjjFkXgq07/AyIT22gkF/4/eHuUHAzDcbNnDztxk4SZEXy8e8AOLPBGJAUy4 XwDd99ERc9ymybX82GNeNZjaRNRzJgPIMk/zuqVor45iNJky3G0oX9BPszBV9r9zmVl6 Fhrh6ko5JcB8Tp000mknNmvVyxcwJLDNpI9BIVGl/4QuOYPeXFU7oslKz6f4HOoQnb8q 6APh5mlFeP6IOVthyN6eU53CvtxGHRrHJD+XwsdkcIXBHOCtswMDL6iHzYLE6ZwdOei0 oGN2NZRkC1MGw4uMWiRQyVNfgQQKNJ5qFqsOfLeTfL5egNhxSiDrVQ0hNxxv5GYUR3bo /Rfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bYSmnpdczEgCtvBK56XkA/Agge/3wFSXb0DyUhLLI+I=; b=tVLjrZlZdFihzqgdRBRtoaeC7kL0OVsUgFqjVx2+nJ99WUMhrAhI4z42ua8o5lfTfM crN7qrOGDiNUkUzX43cjB+vhAJGzTddOGSwYd480pR64hxFfS3Oajd3zyWNf+L15KPUc vmZQqbXVYHOxI1jisPbyvj8YnVIoE7ZsNTN/sNvVw3JToPXCPi6Q9oOqby37U9V0c9Uv isTEw1c2SMLs4+vPyDTwJpn43IDcaI8gJf0UtIZwyC8URVnBlw0pMxlx1EYl2eNlwGus XewkPvn2m6OYtF3lxMJSY2huUrNwIH0ZqF62Ur+YTDnJrW/3pOvqn374gkh/HmmmB6I4 Bltg==
X-Gm-Message-State: AOAM531LhZO+9Q9I7azH5UKuqpuTfIxvKfZdYIdFv/Uj6Re4ZxomBSqq HAc5+Hrm7/AT4hvVUqk6zB4joPwkH4xvCLkjwRrA
X-Google-Smtp-Source: ABdhPJwtohEeER+LKX8Xnhd5xQ9UHfCXp+lbNl//Z/SZiTGk90PDMNVxGtJwwtjzbtrck0IJzpQS8wEQCYZLvgyJK3M=
X-Received: by 2002:a92:c6ca:: with SMTP id v10mr18100671ilm.195.1614185320488;  Wed, 24 Feb 2021 08:48:40 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  
In-Reply-To: 
From: Warren Parad 
Date: Wed, 24 Feb 2021 17:48:29 +0100
Message-ID: 
To: Tim Bray 
Cc: Justin Richer , Bron Gondwana ,  Phillip Hallam-Baker , "oauth@ietf.org" ,  IETF-Discussion Discussion 
Content-Type: multipart/alternative; boundary="000000000000a13e0405bc17ce86"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 16:48:44 -0000

--000000000000a13e0405bc17ce86
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'll add just one more thing here, even if the protocol exists, the
clarity, and was supported, I'm not sure that it would even be that widely
used. Thinking about this from the user perspective, I just can't imagine
how many would really choose to even need or want to set up these other
mechanisms. There is a very small community dedicated to web3.0 which
supports browser extensions to log in to various tools via crypto
blockchains.

There's still only a handful, and identity providers, who are actually in
this WG, can attest to supporting N+ number of AS and WebAuthN, and
username/password, and likely anything else users want. As one of them, we
add anything and everything that application developers want to support. So
it isn't the lack of paradigms, RFCs, or general neglect (/lack of desire)
to implement these. The blocking factor is the symbiotic evolution of user
desires, platform capabilities, and AS features. So as all AS don't support
all features, and as it seems the capabilities are there, even if they were
supported by user facing applications, there is still further that the
community as a whole needs to go to adopt the mindset of wanting to bring
custom unverified AS to the table.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Wed, Feb 24, 2021 at 5:34 PM Tim Bray  wrote:

> The OAuth work has successfully built a perfectly reasonable syntax and
> protocol for exchanging identity and attribute assertions, and that's
> fine.  What it hasn't done is opened up the world of Identity Provision,
> but that's not a technical problem.
>
> OAuth flowed out of OpenID back in the day. The core idea of OpenID,
> beginning with the attractive but wrong notion that URIs are a good way f=
or
> people to identify themselves, was that service providers should be
> prepared to trust arbitrary identity providers.  At the moment, nobody ha=
s
> figured out an automated way for services to figure out which  identity
> providers they want to trust. The counter-argument is that service
> providers should just trust people to pick appropriate identity providers=
,
> and it has never in my experience succeeded in convincing a single lawyer
> or business-policy type.
>
>
>
> On Wed, Feb 24, 2021 at 7:21 AM Justin Richer  wrote:
>
>> I agree that the NxM problem is the purview of the whole IETF, but it=E2=
=80=99s
>> something that we=E2=80=99re particularly interested in over in GNAP. As=
 the editor
>> of OAuth=E2=80=99s dynamic registration extension and the GNAP core prot=
ocol, I
>> hope I can add to this conversation.
>>
>> From a technical standpoint, OAuth=E2=80=99s dynamic client registration=
 lets
>> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in pr=
actice. On
>> top of that I think this problem is exacerbated by a fundamental protoco=
l
>> design element of OAuth: the client_id that=E2=80=99s required. That fie=
ld means
>> there=E2=80=99s an assumption that a relationship was set up between the=
 pieces of
>> software, implied to be trusted by admins at the AS. Sure you can get th=
at
>> client_id under special circumstances, but there=E2=80=99s still a speci=
al weight
>> handed to that and the dynamic stuff feels like you=E2=80=99re giving up=
 control as
>> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed =
as
>> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an op=
timization on top
>> of that.
>>
>> Does this solve the NxM problem? No, because companies are still going t=
o
>> decide that they only talk to keys or identifiers that they know ahead o=
f
>> time. But the protocol puts the dynamic case forward as baseline and fit=
s
>> in much better with the likes of JMAP than OAuth ever could:
>>
>> - {The Bat} creates a key pair.
>> - {User} enters their email address into {Bat}, {Bat} does discovery
>> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP serve=
r and the
>> GNAP endpoint for authentication as an option.
>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
>> up. {ISP} has never seen this key, but knows how to talk GNAP and get th=
e
>> user to authorize {Bat} to access email.
>> - {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied
>> to the key {Bat} made back at the beginning. That token is tied (at the
>> {ISP}) to the user=E2=80=99s account.
>>
>> Yes, you can do all of this today with OAuth (and people have done so),
>> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registra=
tion first and THEN
>> talk to me=E2=80=9D is a trust impediment more than it is a technical im=
pediment.
>> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the p=
hilosophy of =E2=80=9Cstart
>> talking first and figure out what you need as you go=E2=80=9D. Instead o=
f jumping
>> through hoops to get something you can trust, you just start in and then
>> decide how much you trust it. A corporate rollout could use its own key
>> distribution mechanism and static registration to limit which client
>> instances talk back to the company server, regardless of which accounts
>> would authorize access on top of that. An internet-facing service is goi=
ng
>> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk =
to you in a secure
>> fashion without caring who you are right now=E2=80=9D.
>>
>> We really are trying to make GNAP a consistent protocol at its core and
>> learn from problems with OAuth in the wild, all while letting GNAP addre=
ss
>> a wider variety of use cases. I agree that GNAP could be clearer about
>> specific use cases, and we=E2=80=99re working on the spec still so any h=
elp here is
>> appreciated.
>>
>>  =E2=80=94 Justin
>>
>> On Feb 24, 2021, at 7:15 AM, Bron Gondwana 
>> wrote:
>>
>>
>>
>> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
>>
>> (I tend to trend lightly in the pronoun area, mostly because I'm shocked
>> that openid included gender but not pronouns)
>>
>> I hadn't heard that to be called the NxM problem, so that definitely
>> cleared up the potential confusion (at least for me).
>>
>> I think GNAPs lack of clarity is a non sequitur for the handling or not
>> of the multitrust arbitrary-client with arbitrary-service, however it's
>> lack of clarity for me prevents me from knowing whether GNAP actually se=
eks
>> to solve this problem. So from an OAuth WG perspective we can still ask:
>>
>> *Is this or should this problem be left to GNAP to solve, or is an OAuth
>> WG responsibility?*
>>
>>
>> Honestly I think the problem space is the whole ietf's responsibility.
>> Protocols that allow an end user to safely transfer data between two
>> parties that don't have a pre-existing trust relationship are a key part=
 of
>> enabling user freedom and user choice.
>>
>> Bron.
>>
>>
>> *Warren Parad*
>> Founder, CTO
>> Secure your user data with IAM authorization as a service. Implement
>> Authress .
>>
>>
>> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana 
>> wrote:
>>
>>
>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>>
>> I would prefer Bron to answer that question, as they are the one who
>> started this email thread.
>>
>>
>> You can also use he when talking about me, or she for that matter - I do
>> enough group fitness classes where it's roughly assumed that the entire
>> class is female, and I have an ambiguous enough name that I'm used to it=
.
>> Most people use "he" most of the time.
>>
>> However let's look at GNAP, I've honestly been struggling to understand
>> at least one fully documented case that GNAP supports. It seems in every
>> document the only thing that is clear is GNAP wants to allow "everything=
",
>> doesn't actually talk about an example.
>>
>>
>> That's my biggest fear for GNAP - it too will try to be everything to
>> everybody and wind up being nothing to nobody because the super flexible
>> "everything protocol" is the same as no protocol at all, since you have =
to
>> special-case everybody you talk to anyway.
>>
>> By NxM, I assume we mean that the end user or client is free to select
>> whichever AS they want, in a way which the RS can verify the AS credenti=
al
>> and the user identity, without the RS having to (and really without the
>> ability to limit) which AS are allowed.
>>
>>
>> Let's get down to use cases then, rather than talking in abstracts.
>>
>> I'm an end user with a copy of {The Bat email client} and I want to
>> connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widel=
y
>> popular open standard.  I want to be able to authenticate to each of tho=
se
>> services without saving my plaintext passwords on my hard disk where the
>> next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and
>> all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account,
>> leaving me destitute.
>>
>> But, {The Bat} doesn't have a trusted client cert from my isp, because
>> who does - so there's no good protocol for me - it's either plaintext au=
th,
>> or it's some architecture astronaut multi-party nonsense that's massivel=
y
>> over specified and doesn't work half the time.  So I write a plain text
>> password on a post-it note which is lying in the dust under my monitor
>> because the glue has gone bad, and I hope I never accidentally click
>> "remember me" when I type it in.
>>
>> That's been the reality of the end user experience for very many years.
>>
>> NxM means that you can authenticate an arbitrary client against an
>> arbitrary server so long as they are both speaking a known public protoc=
ol,
>> without needing to build a trust relationship between the client vendor =
and
>> the server vendor first.
>>
>> Any "trust relationship" is made through a user both who trusts the
>> client and trusts the server, and it's not transitive over to other user=
s
>> of the same client and the same server.  The client author doesn't need =
to
>> get a signed "I trust you" from every single server, and the server auth=
or
>> doesn't have to go identify every single client.
>>
>> That's what NxM means to a user, the ability to use arbitrary clients
>> with arbitrary servers so long as they both implement a documented
>> protocol.  Interoperability.
>>
>> OAuth has not given interoperability in the NxM sense outside some simpl=
e
>> web use cases.  They're nice and all, but they don't tend to be useful w=
ith
>> open protocols - OAuth gets used for accessing proprietary API endpoints
>> after getting an access key for a single provider.  At least you get Nx1=
 or
>> 1xM out of it depending who's the N and who's the M, and maybe some of y=
our
>> code can rhyme so you're not doing everything from scratch each time.
>>
>> This is the sorry story of real open protocols.  The floor for true
>> interoperability is still username + password over cleartext, over
>> hopefully a TLS tunnel that's providing some level of protection.  Most =
so
>> than a few years ago when Fastmail wrote our "starttls considered
>> harmful"[1] objection to the IETF's habit at the time of putting a
>> "STARTTLS" upgrade into an initially plaintext protocol, where an active
>> intercepter could just strip the "I support STARTTLS" indicator from the
>> protocol and convince the client to send the credentials in the clear.
>>
>> We're a little better mostly these days, but it's still a tirefire, and
>> in my heart I do hold the OAuth working group's squatting on this area o=
f
>> the landscape while failing to address this burning need partially
>> responsible.  The result (as Phillip pointed out upthread) has been a
>> consolidation towards a few big players - because NxM becomes tractable
>> when you reduce the N and M to small enough numbers.
>>
>> Bron.
>>
>> [1]
>> https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STA=
RTTLS
>>
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com
>>
>>
>>
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>

--000000000000a13e0405bc17ce86
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'll add just one more thing here, even if the protoco=
l exists, the clarity, and was supported, I'm not sure that it would ev=
en be that widely used. Thinking about this from the user perspective, I ju=
st can't imagine how many would really choose to even need or want to s=
et up these other mechanisms. There is a very small community dedicated to =
web3.0 which supports browser extensions to log in to various tools via cry=
pto blockchains.

There's still only a handful, and i=
dentity providers, who are actually in this WG, can attest to supporting N+=
 number of AS and WebAuthN, and username/password, and likely anything else=
 users want. As one of them, we add anything and everything that applicatio=
n developers want to support. So it isn't the lack of paradigms, RFCs, =
or general neglect (/lack of desire) to implement these. The blocking facto=
r is the symbiotic evolution of user desires, platform capabilities, and AS=
 features. So as all AS don't support all features, and as it seems the=
 capabilities are there, even if they were supported by user facing applica=
tions, there is still further that the community as a whole needs to go to =
adopt the mindset of wanting to bring custom unverified AS to the table.

Warren Parad
Founder, CTO=

Secure your=
 user data with IAM authorization as a service. Implement=C2=A0A=
uthress.
=


On Wed, Feb 24, 2021 at 5:34 PM Tim Bray <tbray@textuality.com> wrote:
 The OAu=
th work=C2=A0has successfully built a perfectly reasonable syntax and proto=
col for exchanging identity and attribute assertions, and that's fine.=
=C2=A0 What it hasn't done is opened up the world of Identity Provision=
, but that's not a technical problem.=C2=A0

OAuth flowed out of OpenID back in the day. The core=
 idea of OpenID, beginning with the attractive but wrong notion that URIs a=
re a good way for people to identify themselves, was that service providers=
 should be prepared to trust arbitrary identity providers.=C2=A0 At the mom=
ent, nobody has figured out an automated way for services to figure out whi=
ch=C2=A0 identity providers they want to trust. The counter-argument is tha=
t service providers should just trust people to pick appropriate identity p=
roviders, and it has never in my experience succeeded=C2=A0in convincing a =
single lawyer or business-policy type.



On Wed, Feb 24, 2021 at 7:21 AM Justin Richer=
 <jricher@mit.edu> wrote:
I agree that the NxM problem is the=
 purview of the whole IETF, but it=E2=80=99s something that we=E2=80=99re p=
articularly interested in over in GNAP. As the editor of OAuth=E2=80=99s dy=
namic registration extension and the GNAP core protocol, I hope I can add t=
o this conversation.

From a technical standpoint, OAuth=
=E2=80=99s dynamic client registration lets arbitrary clients talk to an AS=
, but the trust isn=E2=80=99t there in practice. On top of that I think thi=
s problem is exacerbated by a fundamental protocol design element of OAuth:=
 the client_id that=E2=80=99s required. That field means there=E2=80=99s an=
 assumption that a relationship was set up between the pieces of software, =
implied to be trusted by admins at the AS. Sure you can get that client_id =
under special circumstances, but there=E2=80=99s still a special weight han=
ded to that and the dynamic stuff feels like you=E2=80=99re giving up contr=
ol as an AS. In GNAP, the relationship is inverted, and it=E2=80=99s design=
ed as =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an=
 optimization on top of that.

Does this solve the =
NxM problem? No, because companies are still going to decide that they only=
 talk to keys or identifiers that they know ahead of time. But the protocol=
 puts the dynamic case forward as baseline and fits in much better with the=
 likes of JMAP than OAuth ever could:

- {The Bat} =
creates a key pair.
- {User} enters their email address into {Bat=
}, {Bat} does discovery (maybe that=E2=80=99s a JMAP thing? Webfinger?) and=
 finds the JMAP server and the GNAP endpoint for authentication as an optio=
n.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it =
just made up. {ISP} has never seen this key, but knows how to talk GNAP and=
 get the user to authorize {Bat} to access email.
- {User} does t=
his using GNAP and gets back an access token that=E2=80=99s tied to the key=
 {Bat} made back at the beginning. That token is tied (at the {ISP}) to the=
 user=E2=80=99s account.

Yes, you can do all of th=
is today with OAuth (and people have done so), but OAuth=E2=80=99s basic mo=
del of =E2=80=9Cgo do discovery and registration first and THEN talk to me=
=E2=80=9D is a trust impediment more than it is a technical impediment. The=
 =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the philoso=
phy of =E2=80=9Cstart talking first and figure out what you need as you go=
=E2=80=9D. Instead of jumping through hoops to get something you can trust,=
 you just start in and then decide how much you trust it. A corporate rollo=
ut could use its own key distribution mechanism and static registration to =
limit which client instances talk back to the company server, regardless of=
 which accounts would authorize access on top of that. An internet-facing s=
ervice is going to be more likely to take a TLS approach, of =E2=80=9CI=E2=
=80=99ll talk to you in a secure fashion without caring who you are right n=
ow=E2=80=9D.

We really are trying to make GNAP a c=
onsistent protocol at its core and learn from problems with OAuth in the wi=
ld, all while letting GNAP address a wider variety of use cases. I agree th=
at GNAP could be clearer about specific use cases, and we=E2=80=99re workin=
g on the spec still so any help here is appreciated.=C2=A0

=C2=A0=E2=80=94 Justin

=



On Wed, Feb 24=
, 2021, at 23:09, Warren Parad wrote:
(I tend to trend lightly in the=C2=A0pronoun area,=
 mostly because I'm=C2=A0shocked that openid included gender but not pr=
onouns)

I hadn't heard that to be called t=
he NxM problem, so that definitely cleared up the potential confusion (at l=
east for me).

I think GNAPs lack of clarity is=
 a=C2=A0non sequitur for the handling or not of the multitrust arbitrary-cl=
ient with arbitrary-service, however it's lack of clarity for me preven=
ts me from knowing whether GNAP actually seeks to solve this problem. So fr=
om an OAuth WG perspective we can still ask:

<=
div>Is this or should this problem be left to GNAP to solve, or is an OA=
uth WG responsibility?

Honestly I think the problem space is the who=
le ietf's responsibility. Protocols that allow an end user to safely tr=
ansfer data between two parties that don't have a pre-existing trust re=
lationship are a key part of enabling user freedom and user choice.

Bron.
<=
br>
<=
/span>
Warren Parad
Foun=
der, CTO
Secure your user data with IAM authoriza=
tion as a service. Implement=C2=A0Authress.


On Wed, =
Feb 24, 2021 at 12:39 PM Bron Gondwana <brong@fastmailteam.com> wrote:
=


On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
<=
blockquote type=3D"cite" id=3D"gmail-m_-2809553587203446152gmail-m_36374010=
0085753136qt-gmail-m_-2929514049700534293qt">
I would =
prefer Bron to answer that question, as they are the one who started this e=
mail thread.
<=
br>
=
You can also use he when talking about me, or she for that matter - I do en=
ough group fitness classes where it's roughly assumed that the entire c=
lass is female, and I have an ambiguous enough name that I'm used to it=
.=C2=A0 Most people use "he" most of the time.

However let's look at GNAP, I've h=
onestly been struggling to understand at least one fully documented case th=
at GNAP supports. It seems in every document the only thing that is clear i=
s GNAP wants to allow "everything", doesn't actually talk abo=
ut an example.

That's my biggest fear for =
GNAP - it too will try to be everything to everybody and wind up being noth=
ing to nobody because the super flexible "everything protocol" is=
 the same as no protocol at all, since you have to special-case everybody y=
ou talk to anyway.

By NxM, I a=
ssume we mean that the end user or client is free to select whichever AS th=
ey want, in a way which the RS can verify the AS credential and the user id=
entity, without the RS having to (and really without the ability to limit) =
which AS are allowed.

Let's get down to us=
e cases then, rather than talking in abstracts.

I'm an end us=
er with a copy of {The Bat email client} and I want to connect it to {Gmail=
} + {Yahoo} + {My ISP}.=C2=A0 It supports {POP3}, a widely popular open sta=
ndard.=C2=A0 I want to be able to authenticate to each of those services wi=
thout saving my plaintext passwords on my hard disk where the next {Windows=
 ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoi=
n} will then be exfiltrated from my {Paybuddy} account, leaving me destitut=
e.

But, {The Bat} doesn't have a trusted client cert from my =
isp, because who does - so there's no good protocol for me - it's e=
ither plaintext auth, or it's some architecture astronaut multi-party n=
onsense that's massively over specified and doesn't work half the t=
ime.=C2=A0 So I write a plain text password on a post-it note which is lyin=
g in the dust under my monitor because the glue has gone bad, and I hope I =
never accidentally click "remember me" when I type it in.

That's been the reality of the end user experience for very many yea=
rs.

NxM means that you can authenticate an arbitrary client again=
st an arbitrary server so long as they are both speaking a known public pro=
tocol, without needing to build a trust relationship between the client ven=
dor and the server vendor first.
=

Any "trust relationship&quo=
t; is made through a user both who trusts the client and trusts the server,=
 and it's not transitive over to other users of the same client and the=
 same server.=C2=A0 The client author doesn't need to get a signed &quo=
t;I trust you" from every single server, and the server author doesn&#=
39;t have to go identify every single client.

That's what NxM=
 means to a user, the ability to use arbitrary clients with arbitrary serve=
rs so long as they both implement a documented protocol.=C2=A0 Interoperabi=
lity.

OAuth has not given interoperability in the NxM sense outsi=
de some simple web use cases.=C2=A0 They're nice and all, but they don&=
#39;t tend to be useful with open protocols - OAuth gets used for accessing=
 proprietary API endpoints after getting an access key for a single provide=
r.=C2=A0 At least you get Nx1 or 1xM out of it depending who's the N an=
d who's the M, and maybe some of your code can rhyme so you're not =
doing everything from scratch each time.

This is the sorry story =
of real open protocols.=C2=A0 The floor for true interoperability is still =
username + password over cleartext, over hopefully a TLS tunnel that's =
providing some level of protection.=C2=A0 Most so than a few years ago when=
 Fastmail wrote our "starttls considered harmful"[1] objection to=
 the IETF's habit at the time of putting a "STARTTLS" upgrade=
 into an initially plaintext protocol, where an active intercepter could ju=
st strip the "I support STARTTLS" indicator from the protocol and=
 convince the client to send the credentials in the clear.

We'=
;re a little better mostly these days, but it's still a tirefire, and i=
n my heart I do hold the OAuth working group's squatting on this area o=
f the landscape while failing to address this burning need partially respon=
sible.=C2=A0 The result (as Phillip pointed out upthread) has been a consol=
idation towards a few big players - because NxM becomes tractable when you =
reduce the N and M to small enough numbers.

Bron.


--=

=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd


=


--
=C2=A0 =
Bron Gondwana, CEO, Fastmail Pty Ltd

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




--000000000000a13e0405bc17ce86--


From nobody Wed Feb 24 09:05:22 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAFA3A181A; Wed, 24 Feb 2021 09:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGqn6r26qAgm; Wed, 24 Feb 2021 09:05:17 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76383A1816; Wed, 24 Feb 2021 09:05:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 141AC38A2B; Wed, 24 Feb 2021 12:09:26 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kFomh5ZTpsbw; Wed, 24 Feb 2021 12:09:25 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8695638A29; Wed, 24 Feb 2021 12:09:25 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1604357B; Wed, 24 Feb 2021 12:05:14 -0500 (EST)
From: Michael Richardson 
To: "oauth\@ietf.org" , ietf@ietf.org
In-Reply-To: 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com> 
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 17:05:19 -0000

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


Justin Richer  wrote:
    > From a technical standpoint, OAuth=E2=80=99s dynamic client registrat=
ion lets
    > arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in
    > practice.

As an example of a fail even in a closed ecosystem: neither Google nor
Facebook nor LinkedIn nor .. permit one to login to them with themselves.
Even if we believe that there are business reasons why they wouldn't delega=
te
to another, the fact is that they don't delegate to themselves.

What's the use case?  I'll give you two:
  1) parent/child
  2) boss/secretary (*)

My kid is subject to Google Classroom.  A great idea, rather poorly impleme=
nted.
The parent interface is basically non-existent.  The advice, from *GOOGLE*
(and my school board) is, in order to find out what your child is
doing... have them share their password with you, the parent.  I read this,
and went WTF?  Doesn't that go against all of the authentication security
precepts that Google and others have been telling us?

(*) - yes there are limited abilities to do this within gmail.  But, it
      does not extend throughout the ecosystem.

=2D-
Michael Richardson    . o O ( IPv6 I=C3=B8T consulti=
ng )
           Sandelman Software Works Inc, Ottawa and Worldwide

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmA2h0kACgkQgItw+93Q
3WVdLwgAsZjr4jcLzOvfdhNuXhn+rhI+PGPbp9uTZEwt72ASmRSzo4/+wbrqfnv3
buqsU0UoP1k8Dl6OPxac+kgcm9mkIJu+nCWx9L/PB6Fb8rJE6/WHBr5w3KWn0UaP
vR4JoZNMZcZQHqOYU1IsRToazC37pCjfStdFmLGYBfiUZXIb9oasDx61znZGHRLD
NMnWISYPUeEzhzul4PgWW8iNtl34sZ8RlnKHdKaWlm3mQEfBKR6gmhgiJoymX/28
VuLW080yNo0aOlSAexe2UddZOVqHPyGYULtGVccuLnxGt2qIzdP7/4fFpaiWZnRA
HsOm0LW5tkLpdsC3biFbATm0g3V2BA==
=qFF9
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Feb 24 09:10:12 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320483A097D for ; Wed, 24 Feb 2021 09:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.864
X-Spam-Level: 
X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC_tozAR8tys for ; Wed, 24 Feb 2021 09:10:07 -0800 (PST)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A7B3A0936 for ; Wed, 24 Feb 2021 09:10:06 -0800 (PST)
Received: by mail-pg1-x533.google.com with SMTP id a4so1835627pgc.11 for ; Wed, 24 Feb 2021 09:10:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:message-id:date :cc; bh=kok6S1n+pzr4g4ak8jYjbY2DHl71KhcS0rNfFabvw24=; b=t3/cOYNhMtBrJ1CkVHRYRl8JRnTegK0ZnqAE+Q5f5Q7XRDdAC/d3R+bDH4ZluY+4uV 4bVDp3HctHbYj+/jPFKvC7JljuhWhE0MI7IzjbJXRmDd0ZIxTIJVlRAw5IaiQU/vylue 9pgB/zhtEiQdg12iFmf3YryieIy2kvR3MqC3s/R97yoJs/uryz1Uzt5JNM2/lwi/97OB Zjp1GGDthLGYt1StHpofl705BmKCz4zdrIqHPHzdX/QpE0o5Yj1+gQB6FD2BEW4lmWFC 4/rnqmLba/GFoEXPadsxbbzbeR7cBGBnCCUgGfy2QAo++cWnExm/Pzdlbx8wxWtYixA9 RCPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:cc; bh=kok6S1n+pzr4g4ak8jYjbY2DHl71KhcS0rNfFabvw24=; b=W6QbBERbXLc3MItUX7tIsE7/n4sD2R/gI33qybpqfxiS1BnY9jWrXpzyu1Yc252xKG 9BEhjmUFlkzRi7g+bUlyOghoyGzaAVatpUZHUNeKEDsiYojblJWHv1cleB4lSYGaCOEe 4bJKNq6pgObMcO6DAKcjugmDXSNnIHWz8yFZH8ejwwtb/IxUg0006kdGpgEK47g08RaW 7mA9OQKRRek2zqYq3cClycq1P7mFF8RI1ipm2mD/ERnW8S0/vOl4l6ZqtuNS4DIFQ0Ae vFNXJFg5ZfR3MJLxJhC3yPFYkz1KxpsGXNs/2mCVqJxQc2Rc+k7V9np0JHAJ1WmyAQ0R eHhw==
X-Gm-Message-State: AOAM530luEjceCNCBCVwHo4W2QzGqsjw8t0N28Kh32LLlx6T7jO3HIYD I7oHcF+pl7VTLlZpIxNcicX15w==
X-Google-Smtp-Source: ABdhPJyVzoh8F27g2vYGgWwAMTbLfJBT67hORUz7ye6M7OgYJrCEn4FBSKuH6NQSVc6MUsFKMp33YQ==
X-Received: by 2002:a05:6a00:9d:b029:1ed:c1d6:5042 with SMTP id c29-20020a056a00009db02901edc1d65042mr11712989pfj.71.1614186606334;  Wed, 24 Feb 2021 09:10:06 -0800 (PST)
Received: from ?IPv6:2001:569:7a71:1d00:f5c0:d87b:8984:9a74? (node-1w7jr9qrfoxxb9ffdavw7pnjo.ipv6.telus.net. [2001:569:7a71:1d00:f5c0:d87b:8984:9a74]) by smtp.gmail.com with ESMTPSA id w207sm1779804pff.62.2021.02.24.09.10.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Feb 2021 09:10:05 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-4FAEEA39-51CE-4BA2-B954-03FD113AFEA9
Content-Transfer-Encoding: 7bit
From: Phillip Hunt 
Mime-Version: 1.0 (1.0)
Message-Id: <2BA2F95F-2621-49C2-9D4B-C7431C78F6F3@independentid.com>
Date: Wed, 24 Feb 2021 09:10:05 -0800
Cc: Justin Richer , Bron Gondwana , Phillip Hallam-Baker , OAuth@ietf.org, IETF-Discussion Discussion 
X-Mailer: iPhone Mail (18D52)
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 17:10:10 -0000

--Apple-Mail-4FAEEA39-51CE-4BA2-B954-03FD113AFEA9
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

=EF=BB=BFOne thing that this thread is overlooking (Hannes and others have m=
entioned it) is that OAuth is an *authorization* protocol not intended for a=
uthentication.=20

OAuth is not really for federation and sharing of claims.  The idea is for a=
n authz server to issue short term tokens that contain enough information to=
 provide context (the subject) when an identified client accesses a relying p=
arty api.=20

This role of identity provisioning and the nxm discussion really belong over=
 in the OpenId Connect working group....unless the IETF wants to solve this p=
roblem too.=20

The IETF also has an OAuth enabled provisioning spec called SCIM (RFC7643/76=
44).  There is even a profile for using SCIM with OpenId Connect.  That said=
, we have JIT provisioning and on demand with OpenId Connect and we have dir=
ect provisioning with SCIM.=20

Regarding NxM for OAuth this does not usually work out the way people think.=
 Access control for APIs is almost alwayd =E2=80=9Clocal=E2=80=9D to the API=
. When i hear NxM what people usually mean is they want to accept externally=
 issues tokens. There are a number of flows including token exchange that th=
is group has published (RFC8693).=20

Finally in the federated authentication space a lot of work was done on UMA o=
r User Managed Access. It hasn=E2=80=99t really broken out. It has been depl=
oyed in a lot of communities/silos where nxm relations exist but for whateve=
r reason it has not gone mainstream. My theory is that every developer wants=
 to control the user experience so much they fight any form of delegation.=20=


Hope this helps.=20

Cheers,

Phil

> On Feb 24, 2021, at 8:35 AM, Tim Bray  wrote:
> =EF=BB=BF
> The OAuth work has successfully built a perfectly reasonable syntax and pr=
otocol for exchanging identity and attribute assertions, and that's fine.  W=
hat it hasn't done is opened up the world of Identity Provision, but that's n=
ot a technical problem.=20
>=20
> OAuth flowed out of OpenID back in the day. The core idea of OpenID, begin=
ning with the attractive but wrong notion that URIs are a good way for peopl=
e to identify themselves, was that service providers should be prepared to t=
rust arbitrary identity providers.  At the moment, nobody has figured out an=
 automated way for services to figure out which  identity providers they wan=
t to trust. The counter-argument is that service providers should just trust=
 people to pick appropriate identity providers, and it has never in my exper=
ience succeeded in convincing a single lawyer or business-policy type.
>=20
>=20
>=20
> On Wed, Feb 24, 2021 at 7:21 AM Justin Richer  wrote:
>> I agree that the NxM problem is the purview of the whole IETF, but it=E2=80=
=99s something that we=E2=80=99re particularly interested in over in GNAP. A=
s the editor of OAuth=E2=80=99s dynamic registration extension and the GNAP c=
ore protocol, I hope I can add to this conversation.
>>=20
>> =46rom a technical standpoint, OAuth=E2=80=99s dynamic client registratio=
n lets arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in=
 practice. On top of that I think this problem is exacerbated by a fundament=
al protocol design element of OAuth: the client_id that=E2=80=99s required. T=
hat field means there=E2=80=99s an assumption that a relationship was set up=
 between the pieces of software, implied to be trusted by admins at the AS. S=
ure you can get that client_id under special circumstances, but there=E2=80=99=
s still a special weight handed to that and the dynamic stuff feels like you=
=E2=80=99re giving up control as an AS. In GNAP, the relationship is inverte=
d, and it=E2=80=99s designed as =E2=80=9Cdynamic-first=E2=80=9D, with pre-re=
gistered clients being an optimization on top of that.
>>=20
>> Does this solve the NxM problem? No, because companies are still going to=
 decide that they only talk to keys or identifiers that they know ahead of t=
ime. But the protocol puts the dynamic case forward as baseline and fits in m=
uch better with the likes of JMAP than OAuth ever could:
>>=20
>> - {The Bat} creates a key pair.
>> - {User} enters their email address into {Bat}, {Bat} does discovery (may=
be that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP server and th=
e GNAP endpoint for authentication as an option.
>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made u=
p. {ISP} has never seen this key, but knows how to talk GNAP and get the use=
r to authorize {Bat} to access email.
>> - {User} does this using GNAP and gets back an access token that=E2=80=99=
s tied to the key {Bat} made back at the beginning. That token is tied (at t=
he {ISP}) to the user=E2=80=99s account.
>>=20
>> Yes, you can do all of this today with OAuth (and people have done so), b=
ut OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registration f=
irst and THEN talk to me=E2=80=9D is a trust impediment more than it is a te=
chnical impediment. The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name c=
omes from the philosophy of =E2=80=9Cstart talking first and figure out what=
 you need as you go=E2=80=9D. Instead of jumping through hoops to get someth=
ing you can trust, you just start in and then decide how much you trust it. A=
 corporate rollout could use its own key distribution mechanism and static r=
egistration to limit which client instances talk back to the company server,=
 regardless of which accounts would authorize access on top of that. An inte=
rnet-facing service is going to be more likely to take a TLS approach, of =E2=
=80=9CI=E2=80=99ll talk to you in a secure fashion without caring who you ar=
e right now=E2=80=9D.
>>=20
>> We really are trying to make GNAP a consistent protocol at its core and l=
earn from problems with OAuth in the wild, all while letting GNAP address a w=
ider variety of use cases. I agree that GNAP could be clearer about specific=
 use cases, and we=E2=80=99re working on the spec still so any help here is a=
ppreciated.=20
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Feb 24, 2021, at 7:15 AM, Bron Gondwana  wrot=
e:
>>>=20
>>>=20
>>>=20
>>> On Wed, Feb 24, 2021, at 23:09, Warren Parad wrote:
>>>> (I tend to trend lightly in the pronoun area, mostly because I'm shocke=
d that openid included gender but not pronouns)
>>>>=20
>>>> I hadn't heard that to be called the NxM problem, so that definitely cl=
eared up the potential confusion (at least for me).
>>>>=20
>>>> I think GNAPs lack of clarity is a non sequitur for the handling or not=
 of the multitrust arbitrary-client with arbitrary-service, however it's lac=
k of clarity for me prevents me from knowing whether GNAP actually seeks to s=
olve this problem. So from an OAuth WG perspective we can still ask:
>>>>=20
>>>> Is this or should this problem be left to GNAP to solve, or is an OAuth=
 WG responsibility?
>>>=20
>>> Honestly I think the problem space is the whole ietf's responsibility. P=
rotocols that allow an end user to safely transfer data between two parties t=
hat don't have a pre-existing trust relationship are a key part of enabling u=
ser freedom and user choice.
>>>=20
>>> Bron.
>>>=20
>>>>=20
>>>>=20
>>>> Warren Parad
>>>> Founder, CTO
>>>> Secure your user data with IAM authorization as a service. Implement Au=
thress.
>>>>=20
>>>>=20
>>>> On Wed, Feb 24, 2021 at 12:39 PM Bron Gondwana =
 wrote:
>>>>=20
>>>> On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
>>>>> I would prefer Bron to answer that question, as they are the one who s=
tarted this email thread.
>>>>=20
>>>> You can also use he when talking about me, or she for that matter - I d=
o enough group fitness classes where it's roughly assumed that the entire cl=
ass is female, and I have an ambiguous enough name that I'm used to it.  Mos=
t people use "he" most of the time.
>>>>=20
>>>>> However let's look at GNAP, I've honestly been struggling to understan=
d at least one fully documented case that GNAP supports. It seems in every d=
ocument the only thing that is clear is GNAP wants to allow "everything", do=
esn't actually talk about an example.
>>>>=20
>>>> That's my biggest fear for GNAP - it too will try to be everything to e=
verybody and wind up being nothing to nobody because the super flexible "eve=
rything protocol" is the same as no protocol at all, since you have to speci=
al-case everybody you talk to anyway.
>>>>=20
>>>>> By NxM, I assume we mean that the end user or client is free to select=
 whichever AS they want, in a way which the RS can verify the AS credential a=
nd the user identity, without the RS having to (and really without the abili=
ty to limit) which AS are allowed.
>>>>=20
>>>> Let's get down to use cases then, rather than talking in abstracts.
>>>>=20
>>>> I'm an end user with a copy of {The Bat email client} and I want to con=
nect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popul=
ar open standard.  I want to be able to authenticate to each of those servic=
es without saving my plaintext passwords on my hard disk where the next {Win=
dows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Doge=
coin} will then be exfiltrated from my {Paybuddy} account, leaving me destit=
ute.
>>>>=20
>>>> But, {The Bat} doesn't have a trusted client cert from my isp, because w=
ho does - so there's no good protocol for me - it's either plaintext auth, o=
r it's some architecture astronaut multi-party nonsense that's massively ove=
r specified and doesn't work half the time.  So I write a plain text passwor=
d on a post-it note which is lying in the dust under my monitor because the g=
lue has gone bad, and I hope I never accidentally click "remember me" when I=
 type it in.
>>>>=20
>>>> That's been the reality of the end user experience for very many years.=

>>>>=20
>>>> NxM means that you can authenticate an arbitrary client against an arbi=
trary server so long as they are both speaking a known public protocol, with=
out needing to build a trust relationship between the client vendor and the s=
erver vendor first.
>>>>=20
>>>> Any "trust relationship" is made through a user both who trusts the cli=
ent and trusts the server, and it's not transitive over to other users of th=
e same client and the same server.  The client author doesn't need to get a s=
igned "I trust you" from every single server, and the server author doesn't h=
ave to go identify every single client.
>>>>=20
>>>> That's what NxM means to a user, the ability to use arbitrary clients w=
ith arbitrary servers so long as they both implement a documented protocol. =
 Interoperability.
>>>>=20
>>>> OAuth has not given interoperability in the NxM sense outside some simp=
le web use cases.  They're nice and all, but they don't tend to be useful wi=
th open protocols - OAuth gets used for accessing proprietary API endpoints a=
fter getting an access key for a single provider.  At least you get Nx1 or 1=
xM out of it depending who's the N and who's the M, and maybe some of your c=
ode can rhyme so you're not doing everything from scratch each time.
>>>>=20
>>>> This is the sorry story of real open protocols.  The floor for true int=
eroperability is still username + password over cleartext, over hopefully a T=
LS tunnel that's providing some level of protection.  Most so than a few yea=
rs ago when Fastmail wrote our "starttls considered harmful"[1] objection to=
 the IETF's habit at the time of putting a "STARTTLS" upgrade into an initia=
lly plaintext protocol, where an active intercepter could just strip the "I s=
upport STARTTLS" indicator from the protocol and convince the client to send=
 the credentials in the clear.
>>>>=20
>>>> We're a little better mostly these days, but it's still a tirefire, and=
 in my heart I do hold the OAuth working group's squatting on this area of t=
he landscape while failing to address this burning need partially responsibl=
e.  The result (as Phillip pointed out upthread) has been a consolidation to=
wards a few big players - because NxM becomes tractable when you reduce the N=
 and M to small enough numbers.
>>>>=20
>>>> Bron.
>>>>=20
>>>> [1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-an=
d-STARTTLS
>>>>=20
>>>> --
>>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>   brong@fastmailteam.com
>>>>=20
>>>>=20
>>>=20
>>> --
>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>   brong@fastmailteam.com
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-4FAEEA39-51CE-4BA2-B954-03FD113AFEA9
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


=EF=BB=BFOne thing that this th=
read is overlooking (Hannes and others have mentioned it) is that OAuth is a=
n *authorization* protocol not intended for authentication. 

OAuth is not really for federation and=
 sharing of claims.  The idea is for an authz server to issue short ter=
m tokens that contain enough information to provide context (the subject) wh=
en an identified client accesses a relying party api. 

This role of identity provisioning and the nxm discussion really belong o=
ver in the OpenId Connect working group....unless the IETF wants to solve th=
is problem too. 

The IETF also has an OAuth en=
abled provisioning spec called SCIM (RFC7643/7644).  There is even a pr=
ofile for using SCIM with OpenId Connect.  That said, we have JIT provi=
sioning and on demand with OpenId Connect and we have direct provisioning wi=
th SCIM. 

Regarding NxM for OAuth this does no=
t usually work out the way people think. Access control for APIs is almost a=
lwayd =E2=80=9Clocal=E2=80=9D to the API. When i hear NxM what people usuall=
y mean is they want to accept externally issues tokens. There are a number o=
f flows including token exchange that this group has published (RFC8693).&nb=
sp;

Finally in the federated authentication space a=
 lot of work was done on UMA or User Managed Access. It hasn=E2=80=99t reall=
y broken out. It has been deployed in a lot of communities/silos where nxm r=
elations exist but for whatever reason it has not gone mainstream. My theory=
 is that every developer wants to control the user experience so much they f=
ight any form of delegation. 

Hope this helps.=
 

Cheers,

Phil

On Feb 24, 2021, at 8:35 AM, Ti=
m Bray <tbray@textuality.com> wrote:

=EF=BB=BF
 The OAuth work&nb=
sp;has successfully built a perfectly reasonable syntax and protocol for exc=
hanging identity and attribute assertions, and that's fine.  What it ha=
sn't done is opened up the world of Identity Provision, but that's not a tec=
hnical problem. 

OAuth=
 flowed out of OpenID back in the day. The core idea of OpenID, beginning wi=
th the attractive but wrong notion that URIs are a good way for people to id=
entify themselves, was that service providers should be prepared to trust ar=
bitrary identity providers.  At the moment, nobody has figured out an a=
utomated way for services to figure out which  identity providers they w=
ant to trust. The counter-argument is that service providers should just tru=
st people to pick appropriate identity providers, and it has never in my exp=
erience succeeded in convincing a single lawyer or business-policy type=
.


On Wed, Fe=
b 24, 2021 at 7:21 AM Justin Richer <j=
richer@mit.edu> wrote:
I agree that the NxM problem is t=
he purview of the whole IETF, but it=E2=80=99s something that we=E2=80=99re p=
articularly interested in over in GNAP. As the editor of OAuth=E2=80=99s dyn=
amic registration extension and the GNAP core protocol, I hope I can add to t=
his conversation.

=46rom a technical standpoint, OAuth=E2=
=80=99s dynamic client registration lets arbitrary clients talk to an AS, bu=
t the trust isn=E2=80=99t there in practice. On top of that I think this pro=
blem is exacerbated by a fundamental protocol design element of OAuth: the c=
lient_id that=E2=80=99s required. That field means there=E2=80=99s an assump=
tion that a relationship was set up between the pieces of software, implied t=
o be trusted by admins at the AS. Sure you can get that client_id under spec=
ial circumstances, but there=E2=80=99s still a special weight handed to that=
 and the dynamic stuff feels like you=E2=80=99re giving up control as an AS.=
 In GNAP, the relationship is inverted, and it=E2=80=99s designed as =E2=80=9C=
dynamic-first=E2=80=9D, with pre-registered clients being an optimization on=
 top of that.

Does this solve the NxM problem? No, b=
ecause companies are still going to decide that they only talk to keys or id=
entifiers that they know ahead of time. But the protocol puts the dynamic ca=
se forward as baseline and fits in much better with the likes of JMAP than O=
Auth ever could:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does discovery=
 (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP server a=
nd the GNAP endpoint for authentication as an option.
- {Bat} talk=
s to the GNAP AS at {ISP} and presents the key it just made up. {ISP} has ne=
ver seen this key, but knows how to talk GNAP and get the user to authorize {=
Bat} to access email.
- {User} does this using GNAP and gets back a=
n access token that=E2=80=99s tied to the key {Bat} made back at the beginni=
ng. That token is tied (at the {ISP}) to the user=E2=80=99s account.

Yes, you can do all of this today with OAuth (and people h=
ave done so), but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery an=
d registration first and THEN talk to me=E2=80=9D is a trust impediment more=
 than it is a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D part o=
f the GNAP name comes from the philosophy of =E2=80=9Cstart talking first an=
d figure out what you need as you go=E2=80=9D. Instead of jumping through ho=
ops to get something you can trust, you just start in and then decide how mu=
ch you trust it. A corporate rollout could use its own key distribution mech=
anism and static registration to limit which client instances talk back to t=
he company server, regardless of which accounts would authorize access on to=
p of that. An internet-facing service is going to be more likely to take a T=
LS approach, of =E2=80=9CI=E2=80=99ll talk to you in a secure fashion withou=
t caring who you are right now=E2=80=9D.

We really a=
re trying to make GNAP a consistent protocol at its core and learn from prob=
lems with OAuth in the wild, all while letting GNAP address a wider variety o=
f use cases. I agree that GNAP could be clearer about specific use cases, an=
d we=E2=80=99re working on the spec still so any help here is appreciated.&n=
bsp;

 =E2=80=94 Justin

On Feb 24, 2021, at 7:15 AM, Bron Gondwana <brong@fastmailteam.com=
> wrote:



On W=
ed, Feb 24, 2021, at 23:09, Warren Parad wrote:
(I tend to trend lightly in the pronoun area, mostly because I'm =
;shocked that openid included gender but not pronouns)

I hadn't heard that to be called the NxM problem, so that definitely=
 cleared up the potential confusion (at least for me).

I think GNAPs lack of clarity is a non sequitur for the handlin=
g or not of the multitrust arbitrary-client with arbitrary-service, however i=
t's lack of clarity for me prevents me from knowing whether GNAP actually se=
eks to solve this problem. So from an OAuth WG perspective we can still ask:=


Is this or should this problem be left=
 to GNAP to solve, or is an OAuth WG responsibility?

Honestly I think the pr=
oblem space is the whole ietf's responsibility. Protocols that allow an end u=
ser to safely transfer data between two parties that don't have a pre-existi=
ng trust relationship are a key part of enabling user freedom and user choic=
e.

Bron.
<=
br>

Warren Parad
Found=
er, CTO
<=
span style=3D"font-size:x-small">Secure your user data with IAM authorizatio=
n as a service. Implement Authress.

=


On Wed, Feb 24,=
 2021 at 12:39 PM Bron Gondwana <brong@fastmailteam.com> wrote:

=

On Wed, Feb 24, 2021, at 22:04, W=
arren Parad wrote:
I would p=
refer Bron to answer that question, as they are the one who started this ema=
il thread.

=

You c=
an also use he when talking about me, or she for that matter - I do enough g=
roup fitness classes where it's roughly assumed that the entire class is fem=
ale, and I have an ambiguous enough name that I'm used to it.  Most peo=
ple use "he" most of the time.

However let's look at GN=
AP, I've honestly been struggling to understand at least one fully documente=
d case that GNAP supports. It seems in every document the only thing that is=
 clear is GNAP wants to allow "everything", doesn't actually talk about an e=
xample.

That's my biggest fear for GNAP - it too=
 will try to be everything to everybody and wind up being nothing to nobody b=
ecause the super flexible "everything protocol" is the same as no protocol a=
t all, since you have to special-case everybody you talk to anyway.

By NxM, I assume we mean that the end user or client is free to selec=
t whichever AS they want, in a way which the RS can verify the AS credential=
 and the user identity, without the RS having to (and really without the abi=
lity to limit) which AS are allowed.

Let's get dow=
n to use cases then, rather than talking in abstracts.

I'm an end us=
er with a copy of {The Bat email client} and I want to connect it to {Gmail}=
 + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular open stand=
ard.  I want to be able to authenticate to each of those services witho=
ut saving my plaintext passwords on my hard disk where the next {Windows ME}=
 virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} wi=
ll then be exfiltrated from my {Paybuddy} account, leaving me destitute.
=


But, {The Bat} doesn't have a trusted client cert from my isp, because=
 who does - so there's no good protocol for me - it's either plaintext auth,=
 or it's some architecture astronaut multi-party nonsense that's massively o=
ver specified and doesn't work half the time.  So I write a plain text p=
assword on a post-it note which is lying in the dust under my monitor becaus=
e the glue has gone bad, and I hope I never accidentally click "remember me"=
 when I type it in.

That's been the reality of the end user experie=
nce for very many years.

NxM means that you can authenticate an arb=
itrary client against an arbitrary server so long as they are both speaking a=
 known public protocol, without needing to build a trust relationship betwee=
n the client vendor and the server vendor first.

Any "trust relatio=
nship" is made through a user both who trusts the client and trusts the serv=
er, and it's not transitive over to other users of the same client and the s=
ame server.  The client author doesn't need to get a signed "I trust yo=
u" from every single server, and the server author doesn't have to go identi=
fy every single client.

=

That's what NxM means to a user, the abilit=
y to use arbitrary clients with arbitrary servers so long as they both imple=
ment a documented protocol.  Interoperability.

OAuth has not g=
iven interoperability in the NxM sense outside some simple web use cases.&nb=
sp; They're nice and all, but they don't tend to be useful with open protoco=
ls - OAuth gets used for accessing proprietary API endpoints after getting a=
n access key for a single provider.  At least you get Nx1 or 1xM out of=
 it depending who's the N and who's the M, and maybe some of your code can r=
hyme so you're not doing everything from scratch each time.

This is=
 the sorry story of real open protocols.  The floor for true interopera=
bility is still username + password over cleartext, over hopefully a TLS tun=
nel that's providing some level of protection.  Most so than a few year=
s ago when Fastmail wrote our "starttls considered harmful"[1] objection to t=
he IETF's habit at the time of putting a "STARTTLS" upgrade into an initiall=
y plaintext protocol, where an active intercepter could just strip the "I su=
pport STARTTLS" indicator from the protocol and convince the client to send t=
he credentials in the clear.

<=
/div>
We're a little better mostly these day=
s, but it's still a tirefire, and in my heart I do hold the OAuth working gr=
oup's squatting on this area of the landscape while failing to address this b=
urning need partially responsible.  The result (as Phillip pointed out u=
pthread) has been a consolidation towards a few big players - because NxM be=
comes tractable when you reduce the N and M to small enough numbers.

Bron.


--
<=
div>  Bron Gondwana, CEO, Fastmail Pty Ltd



<=
/div>
--<=
br>
  Bron Gondwana, CEO, Fastmail Pty Ltd

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


_______________________________________________
OAuth m=
ailing list
OAuth@ietf.org
https://www.ietf.=
org/mailman/listinfo/oauth
<=
/html>=

--Apple-Mail-4FAEEA39-51CE-4BA2-B954-03FD113AFEA9--


From nobody Wed Feb 24 14:31:06 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8BD3A1CA0; Wed, 24 Feb 2021 14:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Anvpf44l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qsKYpQ0Y
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKLfwUOCP2k6; Wed, 24 Feb 2021 14:30:58 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979433A1C9E; Wed, 24 Feb 2021 14:30:58 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C6E6D5C00DA; Wed, 24 Feb 2021 17:30:57 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 17:30:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=ZRZC SzbcgcQfSUd0+eD539BCP8kLRsyQxDWjL+rmQwo=; b=Anvpf44ll48zrRStJPmH IYsZW0Pr9IFvBcONqRZItMTnVjF+/4U304VcxQ3ALSQAMg9WJ8XBkfdrgmCzAr2Q 02WXkkjRHahuUlOyLtFCkB8N3QckAKkNT/F4ccIQoSEEXpRKeciN1YtvViH/+kbY M0eEd2tgQcuJQHooxN+cxjbz7Z9q7IxQ0E0tDPJhf/N/h3/5XFXYJfIzulO4aTTm akK/3E6kfK+zdj3uvWq0dyI2HczIhjJcOuXpQ0+1KFG+H6QFKth7cK7gT5IJvy5D 5Twd7WiS9jpaOfF5+0B5IMa/CZGK9/hmqOY7HjsfkK+3OKEK66iV6idru6Dq54mc Dw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZRZCSz bcgcQfSUd0+eD539BCP8kLRsyQxDWjL+rmQwo=; b=qsKYpQ0YTCcd3b8+TGcNGW Hdo+QLJ30w9tS33B2/9Hb2Y5xZmy6NHXefXDxwD1he8xlbh53w3rE+uXgQYesPjZ 8ZMQhDaI800lgmcLKovCwbBmXHLrNIqYYaDsd5OGMgua5+2iFUl6meEEzw9nuEvt P7CIYQnVwZhf6bqVyGoUSvHG4WZCwMZvzGAw9/J6PKZ6QYxNqn4n07lAde9+zaIg dUJirnICjaYoIZriRwDRSQOHsWOY9I64qvveYPa3m6biSsBnIeld9r+S4NJUk2yi 5zNQLfs7MRn93EkZqNc/BktJgbprHXXiaj2b1eMbUnwGYSc84UljZTVI9oK9bgkg ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeejgdduiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnheptdehteegfeevteduffevteehfffghefhvdevkeeuhfeh ueetudehgfegieekjeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 23EEA3605AC; Wed, 24 Feb 2021 17:30:57 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>
In-Reply-To: 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com> 
Date: Thu, 25 Feb 2021 09:30:33 +1100
From: "Bron Gondwana" 
To: "Justin Richer" 
Cc: "Warren Parad" , "Phillip Hallam-Baker" , "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/alternative; boundary=8fee5ed3ff744ba3a90a56c03f03a7d4
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Feb 2021 22:31:01 -0000

--8fee5ed3ff744ba3a90a56c03f03a7d4
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
> I agree that the NxM problem is the purview of the whole IETF, but it=E2=
=80=99s something that we=E2=80=99re particularly interested in over in =
GNAP. As the editor of OAuth=E2=80=99s dynamic registration extension an=
d the GNAP core protocol, I hope I can add to this conversation.
>=20
> From a technical standpoint, OAuth=E2=80=99s dynamic client registrati=
on lets arbitrary clients talk to an AS, but the trust isn=E2=80=99t the=
re in practice. On top of that I think this problem is exacerbated by a =
fundamental protocol design element of OAuth: the client_id that=E2=80=99=
s required. That field means there=E2=80=99s an assumption that a relati=
onship was set up between the pieces of software, implied to be trusted =
by admins at the AS. Sure you can get that client_id under special circu=
mstances, but there=E2=80=99s still a special weight handed to that and =
the dynamic stuff feels like you=E2=80=99re giving up control as an AS. =
In GNAP, the relationship is inverted, and it=E2=80=99s designed as =E2=80=
=9Cdynamic-first=E2=80=9D, with pre-registered clients being an optimiza=
tion on top of that.

Yep, this is the big point - OAuth is designed to require the the third =
leg of trust that creates the NxM problem.



If that dotted line between client and server requires a pre-existing tr=
ust relationship rather than the trust being entirely mediated by the us=
er choosing to connect client A with server B, then you have the NxM pro=
blem.  This is the "you can only have your John Deere tractor serviced b=
y an approved John Deere service centre" problem.  You can only use this=
 client with servers who have pre-approved it.  Or fall back to the "cas=
h of the internet" - plain text passwords.

> Does this solve the NxM problem? No, because companies are still going=
 to decide that they only talk to keys or identifiers that they know ahe=
ad of time. But the protocol puts the dynamic case forward as baseline a=
nd fits in much better with the likes of JMAP than OAuth ever could:
>=20
> - {The Bat} creates a key pair.
> - {User} enters their email address into {Bat}, {Bat} does discovery (=
maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP server=
 and the GNAP endpoint for authentication as an option.
> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just mad=
e up. {ISP} has never seen this key, but knows how to talk GNAP and get =
the user to authorize {Bat} to access email.
> - {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied to the key {Bat} made back at the beginning. That token is tie=
d (at the {ISP}) to the user=E2=80=99s account.
>=20
> Yes, you can do all of this today with OAuth (and people have done so)=
, but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and regist=
ration first and THEN talk to me=E2=80=9D is a trust impediment more tha=
n it is a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D part o=
f the GNAP name comes from the philosophy of =E2=80=9Cstart talking firs=
t and figure out what you need as you go=E2=80=9D. Instead of jumping th=
rough hoops to get something you can trust, you just start in and then d=
ecide how much you trust it. A corporate rollout could use its own key d=
istribution mechanism and static registration to limit which client inst=
ances talk back to the company server, regardless of which accounts woul=
d authorize access on top of that. An internet-facing service is going t=
o be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk t=
o you in a secure fashion without caring who you are right now=E2=80=9D.=

>=20
> We really are trying to make GNAP a consistent protocol at its core an=
d learn from problems with OAuth in the wild, all while letting GNAP add=
ress a wider variety of use cases. I agree that GNAP could be clearer ab=
out specific use cases, and we=E2=80=99re working on the spec still so a=
ny help here is appreciated.=20

Excellent.  This is precisely what I've been waiting for for these very =
many years as a viable replacement for storing a password locally on dis=
k.  Just having the server able to distinguish between different client =
instances for the same user is a big start, because you can de-authorise=
 one without having to lock out every connection - even if the user is s=
till entering their password during the setup phase each time.

This is what Fastmail already do with our own app, creating a long-lived=
 access token and storing that on the device rather than storing the pas=
sword itself - and you can log out any one client from your security set=
tings page.  What's missing is a standard way to do that with any IMAP c=
lient.  The initial JMAP authentication proposal was a very simple case =
of pretty much this, build into to the protocol so everyone would do it.=


Making it easy to connect up arbitrary clients with per-client tokens th=
e default, and easy rather than almost impossible to do in practice is w=
here the big difference comes in.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--8fee5ed3ff744ba3a90a56c03f03a7d4
Content-Type: multipart/related;
 boundary=aae1533ae5b7498f93fc092776b88c7d

--aae1533ae5b7498f93fc092776b88c7d
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable


On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:<=
br>
I agree that the NxM problem is the purview of the whole I=
ETF, but it=E2=80=99s something that we=E2=80=99re particularly interest=
ed in over in GNAP. As the editor of OAuth=E2=80=99s dynamic registratio=
n extension and the GNAP core protocol, I hope I can add to this convers=
ation.

From a t=
echnical standpoint, OAuth=E2=80=99s dynamic client registration lets ar=
bitrary clients talk to an AS, but the trust isn=E2=80=99t there in prac=
tice. On top of that I think this problem is exacerbated by a fundamenta=
l protocol design element of OAuth: the client_id that=E2=80=99s require=
d. That field means there=E2=80=99s an assumption that a relationship wa=
s set up between the pieces of software, implied to be trusted by admins=
 at the AS. Sure you can get that client_id under special circumstances,=
 but there=E2=80=99s still a special weight handed to that and the dynam=
ic stuff feels like you=E2=80=99re giving up control as an AS. In GNAP, =
the relationship is inverted, and it=E2=80=99s designed as =E2=80=9Cdyna=
mic-first=E2=80=9D, with pre-registered clients being an optimization on=
 top of that.
Yep, this is the big point - O=
Auth is designed to require the the third leg of trust that creates the =
NxM problem.



If that dotted line between client and server requires =
a pre-existing trust relationship rather than the trust being entirely m=
ediated by the user choosing to connect client A with server B, then you=
 have the NxM problem.  This is the "you can only have your John De=
ere tractor serviced by an approved John Deere service centre" problem.&=
nbsp; You can only use this client with servers who have pre-approved it=
.  Or fall back to the "cash of the internet" - plain text password=
s.

Does this solve the NxM problem? No, because companies are still goin=
g to decide that they only talk to keys or identifiers that they know ah=
ead of time. But the protocol puts the dynamic case forward as baseline =
and fits in much better with the likes of JMAP than OAuth ever could:

- {The Bat} creat=
es a key pair.
- {User} enters their email a=
ddress into {Bat}, {Bat} does discovery (maybe that=E2=80=99s a JMAP thi=
ng? Webfinger?) and finds the JMAP server and the GNAP endpoint for auth=
entication as an option.
- {Bat} talks to th=
e GNAP AS at {ISP} and presents the key it just made up. {ISP} has never=
 seen this key, but knows how to talk GNAP and get the user to authorize=
 {Bat} to access email.
- {User} does this u=
sing GNAP and gets back an access token that=E2=80=99s tied to the key {=
Bat} made back at the beginning. That token is tied (at the {ISP}) to th=
e user=E2=80=99s account.

Yes, you can do all of this today with OAuth (and people have=
 done so), but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery a=
nd registration first and THEN talk to me=E2=80=9D is a trust impediment=
 more than it is a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D=
 part of the GNAP name comes from the philosophy of =E2=80=9Cstart talki=
ng first and figure out what you need as you go=E2=80=9D. Instead of jum=
ping through hoops to get something you can trust, you just start in and=
 then decide how much you trust it. A corporate rollout could use its ow=
n key distribution mechanism and static registration to limit which clie=
nt instances talk back to the company server, regardless of which accoun=
ts would authorize access on top of that. An internet-facing service is =
going to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll=
 talk to you in a secure fashion without caring who you are right now=E2=
=80=9D.

We real=
ly are trying to make GNAP a consistent protocol at its core and learn f=
rom problems with OAuth in the wild, all while letting GNAP address a wi=
der variety of use cases. I agree that GNAP could be clearer about speci=
fic use cases, and we=E2=80=99re working on the spec still so any help h=
ere is appreciated. 

Excellent.  T=
his is precisely what I've been waiting for for these very many years as=
 a viable replacement for storing a password locally on disk.  Just=
 having the server able to distinguish between different client instance=
s for the same user is a big start, because you can de-authorise one wit=
hout having to lock out every connection - even if the user is still ent=
ering their password during the setup phase each time.

Th=
is is what Fastmail already do with our own app, creating a long-lived a=
ccess token and storing that on the device rather than storing the passw=
ord itself - and you can log out any one client from your security setti=
ngs page.  What's missing is a standard way to do that with any IMA=
P client.  The initial JMAP authentication proposal was a very simp=
le case of pretty much this, build into to the protocol so everyone woul=
d do it.

Making it easy to connect up arbitrary clients w=
ith per-client tokens the default, and easy rather than almost impossibl=
e to do in practice is where the big difference comes in.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com
=



--aae1533ae5b7498f93fc092776b88c7d
Content-Id: <16142055119760.09058712623360687@content.messagingengine.com>
Content-Disposition: inline;filename="image.png"
Content-Type: image/png; name="image.png"
Content-Transfer-Encoding: BASE64

iVBORw0KGgoAAAANSUhEUgAABlEAAANCCAYAAAD2kOrdAAAABHNCSVQICAgIfAhkiAAAIABJ
REFUeF7s3Quy3DiSIMBSmy4xp9j7H2NPscfQilOV3dkUfwACID4+ZmU9L5MEIjxAECT0pB+/
fv/fX/6PAAECBAgQIECAAAECBAgQIECAAAECBAgQIEDgvwT+xYMAAQIECBAgQIAAAQIECBAg
QIAAAQIECBAgQOBPAZsof5r4hAABAgQIECBAgAABAgQIECBAgAABAgQIECDwl00Ug4AAAQIE
CBAgQIAAAQIECBAgQIAAAQIECBAgcCBgE+UAxUcECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA
AZsoxgABAgQIECBAgAABAgQIECBAgAABAgQIECBA4EDAJsoBio8IECBAgAABAgQIECBAgAAB
AgQIECBAgAABAjZRjAECBAgQIECAAAECBAgQIECAAAECBAgQIECAwIGATZQDFB8RIECAAAEC
BAgQIECAAAECBAgQIECAAAECBGyiGAMECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgQMBmygH
KD4iQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECNhEMQYIECBAgAABAgQIECBAgAABAgQIECBA
gAABAgcCNlEOUHxEgAABAgQIECBAgAABAgQIECBAgAABAgQIELCJYgwQIECAAAECBAgQIECA
AAECBAgQIECAAAECBA4EbKIcoPiIAAECBAgQIECAAAECBAgQIECAAAECBAgQIGATxRggQIAA
AQIECBAgQIAAAQIECBAgQIAAAQIECBwI2EQ5QPERAQIECBAgQIAAAQIECBAgQIAAAQIECBAg
QMAmijFAgAABAgQIECBAgAABAgQIECBAgAABAgQIEDgQsIlygOIjAgQIECBAgAABAgQIECBA
gAABAgQIECBAgIBNFGOAAAECBAgQIECAAAECBAgQIECAAAECBAgQIHAgYBPlAMVHBAgQIECA
AAECBAgQIECAAAECBAgQIECAAAGbKMYAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQOBAwCbK
AYqPCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQI2UYwBAgQIECBAgAABAgQIECBAgAABAgQI
ECBAgMCBgE2UAxQfESBAgAABAgQIECBAgAABAgQIECBAgAABAgRsohgDBAgQIECAAAECBAgQ
IECAAAECBAgQIECAAIEDAZsoByg+IkCAAAECBAgQIECAAAECBAgQIECAAAECBAjYRDEGCBAg
QIAAAQIECBAgQIAAAQIECBAgQIAAAQIHAjZRDlB8RIAAAQIECBAgQIAAAQIECBAgQIAAAQIE
CBCwiWIMECBAgAABAgQIECBAgAABAgQIECBAgAABAgQOBGyiHKD4iAABAgQIECBAgAABAgQI
ECBAgAABAgQIECBgE8UYIECAAAECBAgQIECAAAECBAgQIECAAAECBAgcCNhEOUDxEQECBAgQ
IECAAAECBAgQIECAAAECBAgQIEDAJooxQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBA4ELCJ
coDiIwIECBAgQIAAAQIECBAgQIAAAQIECBAgQICATRRjgAABAgQIECBAgAABAgQIECBAgAAB
AgQIECBwIPDz4DMfESBAgAABAgQIECBAgAABAgQIEBhS4MePH0PG/SToX79+PTnMMQQIECAQ
KGATJRBTUwQIECBAgAABAgQIECBAgAABAnECM2+I5CidedhcydF0DgECBJ4J2ER55uQoAgQI
ECBAgAABAgQIECBAgACBBgJnGwUNuh62iygzmzHDDgGBEyBQUcAmSkVcTRMgQIAAAQIECBAg
QIAAAQIEvgVKXnaP/oK7JHejqI3AUY1GH3dt5PRCgMDMAj9+T4T+MsWZKyw3AgQIECBAgAAB
AgQIECBA4BWBoxfSrwSiUwLBAl4nBoNqjgCBrgX8JkrX5REcAQIECBAgQIAAAQIECBAgMIKA
DZMRqiTGKIH9eLepEiWrHQIEehSwidJjVcREgAABAgQIECBAgAABAgQIvC6wf1H8ekACINCp
wNm1YnOl04IJiwCBJAGbKElcDiZAgAABAgQIECBAgAABAgRWEDh7KbxC7nIkECWwv45sqkTJ
aocAgZYCNlFaauuLAAECBAgQIECAAAECBAgQ6Fpg/9K362AFR2Awgf31ZVNlsAIKl8CiAjZR
Fi28tAkQIECAAAECBAgQIECAAIH/Fti/4OVDgEBdgf01Z1OlrrfWCRDIE/hX3mnOIkCAAAEC
BAgQIECAAAECBAjMI7B/mTtPZjIhMI7Adh26Fsepl0gJrCLgN1FWqbQ8CRAgQIAAAQIECBAg
QIAAgUMBL20PWab7cKTfclh9TG75j1Sv6S4WCREg8F8CP35PSL+YECBAYBNIXaTVmD5SYzir
XI3YzvryOQECBAgQIECAAAEC4wpEPYOMKzBm5Ks+8602Xlet85hXpagJzCtgE2Xe2sqsscBq
C5nGvM26s0BrRq0jAgQIECBAgAABAq8LeI57vQRJAXheu+Z6Op43x6fHXvfY5lt1b+OsFwIE
zgVsopzb+IbAfwmMtMBQuhgBC7UYR60QIECAAAECBAgQ6FGgp2e8/bNHT7G1qN0+/xZ96uNP
gV7HnfHxZ618QoBAWwGbKG299RYsUOsGv79B1+onmENzlQX246Jyd5onQIAAAQIECBAgQKCS
wNvPeJ4tKhVWs+ECb18rW0Kul/CyapAAgUQBmyiJYA5vJ9DDjbpdtnoiMJ6Ahex4NRMxAQIE
CBAgQGB1gTeeM62bVx91c+X/xjVUIuj6K9FzLgECHwGbKMZCFwKj3YS7QBMEgYEFLGQHLp7Q
CRAgQIAAAQKDCkQ+d1rPDjoIhF1NIPL6qhbkV8Ou4RbK+iAwj4BNlHlq2XUmo91Mu8YUHIFJ
BSxiJy2stAgQIECAAAECHQhEPpNat3ZQUCF0LxB5zbVO1jXeWlx/BPoXsInSf42GjHDkm+WQ
4IImMKGAheuERZUSAQIECBAgQKChQI3nUmvUhgXU1VQCNa7HUYHMI6NWTtwrC/xcOXm5xwq4
IcZ6ao3A6gJHc4rF5uqjQv4ECBAgQIAAgXuBo3Xk/Vn3R1iL3hs5ggCBe4GIOcp8dO/sCAKR
AjZRIjUXayti0l+MTLoECBQKfM87Fo2FmE4nQIAAAQIECEwiUPvZ1LpzkoEiDQITCdzNe+at
iYotlS4EbKJ0UYb+g7ibnPvPQIQECMwmsM1LFoazVVU+BAgQIECAAIF7gZbPp9ab9/VwBAEC
/QkczZPms/7qJKJxBGyijFOrqpEeTa5VO9Q4gUSBs5u9sZsIOdnhn/qfjY/J0pUOAQIECBAg
QGB5gZbrf2vM5YcbAAJTCRzNn+a5qUosmYoC/mH5iri9Nn00afYa6wxxuSH1WUXXQZ91KY3K
9VYq6HwCBAgQIECAQL8CLdfw1pX9jgORjSnQ8vodU6iPqM19fdRBFP0J2ETpryahEblJhXL+
uzE3lTqub7XqOnlLvl6/rtF6tlomQIAAAQIECLwh0HLNbi35RoX1uYJAy+t4Bc/aOZoLawtr
fyQBmygjVesmVjej/wA9nehzzZ62f1MyX3cskDs2Ok5pudBcp8uVXMIECBAgQIDApAIt1+bW
kJMOIml1I9Dyeu4m6UkCMT9OUkhpZAnYRMlie/+klW86tSbtp6a1+n9/VImAwLHA02vj+Ox3
P3W9vuuvdwIECBAgQIBAiUDLdah1Y0mlnEvgfYGW88X72b4XgbnyPXs9vytgE+Vd///q3YT/
ZzHemJyv6vBGPH+q+ITAOAJX11OrLFy3raT1Q4AAAQIECBAoE3hr7Wi9WFY3ZxPoWeCteaVn
k9LYzJmlgs4fUcAmyktVM4n/DW/ifWkA6pbAiwJvzH/mmhcLrmsCBAgQIECAwAOBN9aIW1jW
iQ+K4xACkwq8Ne/MwGnunKGKckgRsImSopV5rEn5P3Am2cxB5DQCEwu0mCPNPRMPIKkRIECA
AAECwwq0WAce4VgbHqn4jACBaIG35rjoPM7aM5eeyfh8RgGbKAFVnX1SLCUyqZYKOp/AegI1
5lVz0XrjSMYECBAgQIBAvwI11nt32VoP3gn5ngCB3gTemCtTDcytqWKOH1HAJkph1UaYzApT
TD7d5JlM5gQCBC4EIudZ89MFtK8IECBAgAABAo0EItd3VyFb+13p+I4AgRkEWs2nT63Mu0+l
HDeagE2Ugor1NlEVpJJ9qskxm86JBAgkCLSYb81nCQVxKAECBAgQIEAgQ6D2ms56LqMoTiFA
YDqB2nPtEzDz8RMlx4wkYBMls1o9TEiZoSedZtJL4nIwAQKVBd6ae82FlQureQIECBAgQGB6
gRbrOGu26YeRBAkQyBRoMQefhWZuPpPx+UgCNlEyqvXmxJMR7qNTTGiPmBxEgEAnAm/Ow+bL
TgaBMAgQIECAAIFhBFqs3azRhhkOAiVAoAOBFvPyUZrm6iMVn40gYBMloUpvTTAJIT4+tIdJ
69uzh3ge4zmQAIEuBHqYk81dXQwFQRAgQIAAAQIdC7RYs1mTdTwAhEaAQPcCLebpIwRz95GK
z3oVsInysDJvTSgPw7s8rMdJae/ZY4yXqL4kQKALgf1c8lZQ5rC35PVLgAABAgQI9CzQYq1m
HdbzCBAbAQIjCrSYu/cu5vK9iJ97E7CJ8qAib0weD8I6PMSkc8jiQwIEJhbodY42H0886KRG
gAABAgQI3ArUXKNZZ93yO4AAAQJFAjXn8KvAzO9XOr57U8AmygP9tyaOT2gmkAdFcggBAksL
vD1PP8E3lz9RcgwBAgQIECAwg0D02sw6aoZRIQcCBEYTiJ7Ln+Zvzn8q5biWAjZRbrRbTxgm
ipuC+JoAAQInAq3n65Mwkj827yeTOYEAAQIECBDoWCB6TWat1HGxhUaAwPQC0XN6Cpj5P0XL
sbUFbKLcCNecLEwGN/i+JkCAQKJAzTk7MZTsw90bsumcSIAAAQIECLwsELUWsx56uZC6J0CA
wJdA1Nxeguq+UKLn3AgBmygXiqWThAv8AtdXBAgQqCRQOndXCiu7WfeSbDonEiBAgAABAg0F
otZg1j4Ni6YrAgQIJAhEzfMJXR4e6j5xyOLDygI2UU6ASycGF/QJrI8JECDQQKB0Dm8QYlYX
7i1ZbE4iQIAAAQIEKgtErb2sdSoXSvMECBAIEoia90vDcd8oFXT+UwGbKAdSpROBC/gA1UcE
CBDoRKB0ju8kjb/ca3qphDgIECBAgMDaAhFrK+uatceQ7AkQGFcg4h4Qlb17SZSkdo4EbKLs
VEovfhfs0TDzGQECBMYQKL0HvJWle89b8volQIAAAQJrC0Ssnaxj1h5DsidAYB6BiHtClIZ7
S5Skdj4CNlF2Y6HkgneBurAIECAwj0DJ/eBNBfeiN/X1TYAAAQIE1hIoXS9Zt6w1XmRLgMA6
AqX3hygp95koSe3YRPkaA6UXuAvTBUWAAIE5BUrvD2+quDe9qa9vAgQIECAwr0Dp+sgaZd6x
ITMCBAh8C5TeLyI03XMiFNduwybKP/UvvaBdjGtfSLInQGANgdJ7RU9K7ls9VUMsBAgQIEBg
LIHSNZF1yFj1Fi0BAgSiBErvHyVxuPeU6DnXJso/Y6DkInYRupAIECCwrkDJ/aMnNfeynqoh
FgIECBAg0LdAyfrHmqPv2oqOAAECLQRK7iMl8bkHleitfa5NlN/1L7lwXXxrX0CyJ0CAwF6g
5J6yb+utn93b3pLXLwECBAgQGEMgd71jjTFGfUVJgACBFgK595KI2NyPIhTXasMmyu965160
Lri1LhbZEiBAoEQg915T0mfpue5zpYLOJ0CAAAEC8wnkrmmsK+YbCzIiQIBAhEDufaW0b/el
UsG1zv+5Vrp/ZvvWhfpnJD4hQIAAgZkF9gu0Ee4/3zHu45+5VnIjQIAAAQIECBAgQIAAgTYC
38+aLZ+Tt74857ap8Qy9LP2bKCUXpotshuEvBwIECPQjUHJPapmF+19LbX0RIECAAIH+BHLW
LNYP/dVRRAQIEOhdIOd+k5OTe1SO2nrnLLuJUnIhurjWu1BkTIAAgZYCJfeoVnG6F7aS1g8B
AgQIEOhLIHWdYs3QV/1EQ4AAgREFUu89OTm6X+WorXPOkn+dV4sLb50hJFMCBAgQiBb4Xrz1
es/6jstiM3oEaI8AAQIECBAgQIAAAQIEPgItnpG3Z1zPtsbcmcByv4lS+jLKxXQ2lHxOgAAB
ArUFSu9hteNzj6wtrH0CBAgQIPCuQM5axPrg3ZrpnQABAjML5NyX7jzct+6E1vx+yd9EWbPU
siZAgACB0QVa/OmbEiO/nVKi51wCBAgQIDCfgBdR89VURgQIEOhJ4HOfidxM8RspPVW4n1hs
oiTUwgIwAcuhBAgQIFBVYH9Pilw0RgT+iWcfZ0Tb2iBAgAABAgQIECBAgAABAh+B6M0UGynG
1l7AJspe5ORnL4FOYHxMgAABAl0InN2n3t5c8dspXQwPQRAgQIAAAQIECBAgQGB6ge25OOoZ
2EbK9MMlKcF/JR09+MG5F9HZi6nBOYRPgAABAgsIbPew7//eTDn3PvxmzPomQIAAAQIECBAg
QIAAgXEEIt/jeoYdp+61I11mEyV30EdeeLWLqX0CBAgQIHAn8PaGSu79+C4v3xMgQIAAAQIE
CBAgQIAAgU3g89wboeEZNkJx/DaW2ETJHew2UMYf4DIgQIAAgXOByIXleS9/fpN7X/6zJZ8Q
IECAAAECvQp4nu61MuIiQIDAOgJR9yLPsOuMmbNMl9hEOUve5wQIECBAgMB//pRO1ALzialF
6BMlxxAgQIAAAQIECBAgQIBAiUDL59ySOJ3bt8D0myhe0vQ9AEVHgAABAn0JtPztlO0e7T7d
V/1FQ4AAAQIECBAgQIAAgdkEIjZSPLvONirS8pl+EyWNw9EECBAgQIDAJtB6M4U6AQIECBAg
QIAAAQIECBCoJRDxjGsjpVZ1+m/XJspJjSJ2KE+a9jEBAgQIEBhG4LPQrH1ftBgdZkgIlAAB
AgQIECBAgAABAsMK1H62HRZG4JcCNlEOeFxMByg+IkCAAIHlBSL+5M4Voo2UKx3fESBAgACB
dwXcp9/11zsBAgQIxAmUvPt1P4yrw0gt/Rwp2BaxllxELeLTBwECBAgQeFvg+14ZvYDc2nMv
frvC+idAgAABAgR6FYhee33ytP7qteLiIkCglsA27+XOqZ5ba1Wl33ZtovRbG5ERIECAAIHu
BT4P3LmLz+4TFCABAgQIECBAoAOB2muto/ZtrHRQeCEQINCtgI2UbktTJbAfv2+Kv6q03Emj
RwuBs9AmpzhL2+cECBAgQCBUIOXee9axe/KZjM8JECBAgMA7Aqn3d/fysjqlepf1dn62Op7b
+IYAgTkESudb8+Qc4+Aui6n/TZTSi+AOz/cECBAgQIDAnwIWkX+a+IQAAQIECBAg8FSgp3cZ
PcXy1M9xBAgQSBEofX41T6Zoj3vs1Jso45ZF5AQIECBAYGyB0oXo2NmLngABAgQIzCXgBVG7
erJuZ60nAgQIECDwVMAmylMpxxEgQIAAAQJJAiUbKV4gJFE7mAABAgQIdCVQsgboKpHGwVj/
NAbXHQECBP4RKL1vmb/nH0o2UeavsQwJECBAgMBrAqWL0dcC1zEBAgQIECDwvwJeDNUfCJsx
5/rOeiBAgMCVgGfXKx3f2UQxBggQIECAAIGqArmLUS8TqpZF4wQIECBAgEAHAtY7HRRBCAQI
EPhHIPfZdTvdfD73MLKJMnd9ZUeAAAECBLoQKFmMdpGAIAgQIECAAAECwQJeuAWDao4AAQIB
Ap5dAxAnbMImyj9FdYFMOLqlRIAAAQIECBAgQIAAAQIEOhSwgdJhUYREgACBfwRy3xOb2+cd
Qj9nTc2gna+yUTXNnQjnE5URAQIE+hfY5n7zdv91EiEBAgQIEPgIuG9fj4Wo59rrXuK+Vc84
Sy0RILCGgGfYOes87SbKnOVaM6voRea+PYvCNceVrAkQaC+wzbf7OfhJFBahT5QcQ4AAAQIE
CPQskLMGSsnn6XNtShxP20yJ07EECBAYRSD3+XWU/MSZJmATJc3L0Y0FUhZ4uaF9+rBAzBV0
HgECBAgQIECAAAECBP7y26MHg6D2M23qc2zq8Qcp+YgAAQIEbgT8QcAboAG/tokyYNFWCbn2
YnPv+N2fheVex88ECBCIEcj90zwWoTH+WiFAgAABAgTaCNR8nvW82qaGeiFAgEDu8yu5+QT8
w/Lz1XTYjLZF5vd/byZSc8H7Zl76JkCAwMgC5uaRqyd2AgQIECCwjkDNNYsNlHXGkUwJEBhb
oOa9YGyZMaP3myhj1m2aqHueUD6xWaROM9wkQoAAAQIECBAgQIAAgaoCNZ9xPZtWLZ3GCRAg
cCjgt1EOWZb70CbK75JbiNQd9zUXkXUj/7v1LX5jpIW0PggQWEXAInSVSsuTAAECBAisJVDr
2dfz6FrjSLYECPQn4Bm2v5q0jshf59VafLH+ai0iWzPOkkdrN/0RIEDgTMDLgDMZnxMgQIAA
AQIjCtR4ZtzWS9ZMI44GMRMgQOBvgRr3BrbvCNhEecd96l63CeLz30yJmvhmqqZcCBAgQIAA
AQIECBC4E/AMdCf09/c1nGyePLN3FAECBFoJ5M7LNe4RrXLWz38EbKIYDaECJoZQTo0RIEBg
aoGcRaj7zNRDQnIECBAgQIDAb4GcNRI4AgQIECBAoJ6ATZR6tsu17MXWciWXMAECBIoFvCQo
JtQAAQIECBAgMJGAtdFExZQKAQLTCeTO0d6Zjj8U/MPy49ewiwzenAzOJrA3Y+qiKIIgQIAA
AQIECBAgQIAAgSEEzp5rhwhekAQIECBAYHIBmyiTF3j29K4WmvvvbKrMPhrkR4AAAQIECBAg
QIAAgbEE9s+tY0UvWgIECBB4KrC9lzTnP9Xq7zibKP3VREQPBVInns/xPWymXMWQmtdDLocR
IEBgGgGLz2lKKRECBAgQILCsgOe+ZUsvcQIEBhfY5u+r93qDpyf8EwH/JsoJjI+fCWyTRuuJ
Y5usShacpec/kzk/6s7r7vvzln1DgACBdQTMlevUWqYECBAgMIZAyTPaGBnGRPn282hMFloh
QIDA2gK59zzPseOOG7+JMm7tXo+81YWfOzHdAX3afZpHRBxP+9qOi+jvzsD3BGoJXI11Y7uW
+rjtbmPiasyMm5nICRAgQIAAAQIECBAgQIAAgdEF/CbK6BV8Kf7aL7s+fzqnxcvWT19XlC3i
uOrfdwRGEribH+6+HylXsb4rYCy96693AgQIECBAgAABAgQIrCrgXeFalfebKGvVu6tse5ts
eounq2IJhsBDgacvtf221UNQh90KGEu3RA4gQIAAAQIECBAgQIAAAQIECgT8JkoBnlPzBWxY
5Ns5k8AsAk83XGbJVx71BIylerZaJkCAAAECBAgQIECAAIFjAe83j11m/NQmyoxVrZxT6csq
E0zlAmmeAAECAwqU3htK700DkgmZAAECBAgQIECAAAECBAgQaCBgE6UBsi7+I1D6kowlAQIE
CMwr4B4xb21lRoAAAQIECPwtsP3BD3/4w2ggQIDAPAKeY+ep5VUmNlGudHz3h0DJYs+k8gen
DwgQIECAAAECBAgQIEBgQYGSZ+sFuaRMgAABAgReFbCJ8ir/Op3bQFmn1jIlkCLg4TFFa41j
3S/WqLMsCRAgQIAAgb/8RopBQIAAAQIEBhGwiTJIoXoIM/dlpxdiPVRPDAQIEBhHIPe+kXuf
GkdGpAQIECBAgMBsAtYvs1VUPgQIECAwo4BNlBmrKicCBAi8JJD78vulcHXbsYCx1HFxhEaA
AAECBAiECvh3UkI5NUaAAIGuBWyed12e0+B+nn7jCwJfArkXuJdghhEBAgQI5Aps95Dc+09u
nzXP+7//8z+Xzf+f//f/Lr/3JQECBAgQIDC3wLbu8Qw9d41lR4AAAQJjCvhNlDHr1jTqmV5g
NYXTGQECBAgQ+EfgbgNlO+zJMUAJECBAgACB/gQiNz48f/dXXxERIECAAAGbKMbApUDJAi5y
IXkZpC+zBD6/Mn70v1kNOokAAQIEDgVSNkdSjj3szIcECBAgQIDAKwKRz78lz+GvJK9TAgQI
ECAwuYC/zmvyApekZ+FWotf3uXe13b6PfAjoW0N00QKz/RVM0T7aqyvQ2/xlU6RuvbVOgACB
0QSu7gv+WsfRqvlnvJHr4O9nNs9mf1r7hAABAgQItBSwidJSe6G+LPL6LfbdBson8t5eRPYr
KjICBGoKRL6MqBnnUdtXL8qOjvcZAQIECMwtcHdf+HxvM2XscVBj7XL3DOf5e+wxI3oCBAgQ
6F/AJkr/NXolwrtF2itB6ZQAAQIECAwicPeibJA0hEmAAAECQQIp94XvY22oBBWgcTM1NlKu
Utg/v9tUudLyHQECBOIFWs/78Rlo8U7Av4nyW2i/4LhD8/21gAXbtY9vCRAgQGBugZQXZXNL
yI4AAQIESgXcU0oF3zt/ey5+69nYO4736q5nAgQIEJhTwCbKnHUtysqCq4jPyQQIECCwsICX
XQsXX+oECBCoJODeUgm2UbM2UhpB64YAAQIECFQUsIlSEXfEpks3UN5aII5oLWYCBAgQqCNQ
ei+rE5VWCRAgQIBAvoCNlHy7Hs586znZmqiH6ouBAAECBGYQsIkyQxWDcihdYL21MAxKXzME
CBAg0KnAKPeXiBdc/u77TgehsAgQINCBwHafibjXdJDKkiG8tZ4pfc5fsliSJkCAAAECOwGb
KP+AWFiUXRtvLQjLonY2AQIECBDoR8AGSj+1EAkBAgR6Fmi1keIZOX4UvPXcrJbxtdQiAQIE
CKwlYBPlq94rLyxKcn9rIbjWpRqX7dN6PT0uLjItESBAYFyB0hdaNlDGrb3ICRAg8IZA6X3n
jZj1+beA5ywjgQABAgQIjCcw7SaKhcl4g1HE7QTuro+779tFqicCBAiRy5RzAAAgAElEQVTk
CZT84YDUHktfZNlASRV3PAECBMYTqDHXl95/xlOcJ+I3nrdaro3mqZRMCBAgQIDA3wLTbqLk
FtjCIk3ujcVfWoSOPhPYanf239k5PidAgACB/xYofYFV46WaGhEgQIBAnwLm/D7r8lZUn2ex
t/p/s9/tvUvUf2/moW8CBAgQWEfAJso6tZYpAQIECBAYViBn0773PxjhZdqww1HgBAgQyBaI
nvv9Y/PZpejmxO8/2NZNUBUC+d40iWy+9/VeZK7aIkCAAIH3BH78vmH/eq/7uj2X3EwnZjlE
z7FazegQLvHDFGe+ibgO70rAWO+qHNMEkzKuPknXnEtLfgsl+iXaNEWWCAECBBYSKLmPHDFF
31tS77s177lH+a74WWpN9kZv1ag07n0eRz+/ldtRLD4jQGBNgZS5zpw13hiZehNlK0fKAP4u
32qDOdVpNZ+oSzvFmXGUunbeEDDW31Cfv8+UcVX7nl764iv6Rdf81ZchAQIE5hYova98dCLv
Lyn3Xc8u74zPlBp9Imxdq5wYczVb55Ybp/MIEJhTIGW+M1+NNwam/+u8cgdlysAfr+xlEeea
lvXqbAIECBAg0IdA6YuuyBdcfYiIggABAgRKBaLuDaX3qNI8nN+/QMt3HS372uRb99d/tUVI
gAABAlEC0/8mygZVciNdZcMgxWgVk6iL7LsdzjVUtdmjgLHeY1XmiCllbH1nHHHvingxFfWS
bI5qyoLAfwQirq+9Z0/X21V+PcW5Nzz7ebZ8zvJ84/Mr25R4IsZVyj034j6bkp9j/yOQUqfP
WS3qlRNXVF1b5BcVq3YIEJhHIGXeM0+NV/clNlG2sqQM5O8yrjKoU3xWMalxOXOuoarNHgWM
9R6rMkdMKWNrn3HJ/SvipVbEC619Tn4mMINAxPV15tDiuouIv0WcZ0ZPPk/NsVU+qXF9ci2N
72m/uf08bf+udrn9f9pNueeW3GPv8vD9tUBKnT4t1a5XTkzXWaZ/WzvH9IicQYDA7AIpc585
arzRYBPlpmarDGoX+s1ACPqacxCkZroXMNa7L9HQAaaMr+9Ec+/pvbzMGrpogu9C4Gosl75s
zU3wKqbcNvfn1cwtMv6ace5Nnv5ckl/tfEpi2/LPjS+131b9nNU0t/+tvZT7be499ixunz8X
SKnTd6s1a5Yb0/Os74+smd9979dHPPHpOf7r7J59e2cwe/7PlBw1msDduP7Oxxgfrbp//fVz
vJDzIt4GZ8pgzuvFWQQIECBAgECvAts6IHWxmvqy7Cz3kpdYZ22+8Xmux5v5P425ZoxPY9jX
NDKmuxi27yP72+cy4893piPn3HtuEfHljPmcfnP62cbOdj3m9DfyuBP7HALeu/ynjiUWT85N
Xdf2MsKe5Jazbu8lP3EQIDCnwDKbKLnlM3HnyjmPAAECBAjUEWj1ByOiXl5dvZhO6eOqnTrS
/2k1Jc6jWHJfIh61lfJZSty1YkyJYZ9bVExPY4jqb5+Hn/sVeDo2+s1g7shspMxd36jsctdF
Nd51PHk5HpV3z+20cqhRw9quKTYj5lfbT/sECLwn8K/3um7f86i79O2l9EiAAAECBOYUSHlw
ixC42vhIfXmZenxJ/Ftf3/+VtPU5t2X8W585/eWcc2UT0V5EG1cx+m5dAWNrjNpf3UfGyECU
LQS864hR3taJZ/897aH1WrN1f08dHEeAAIHZBJbaRNmKZ3Hx5xB20/3TpMYnnGuoapMAgVUF
RrifX734yn15mXteyjhp0UdKPI4lQCBewHUeb6pFAgTKBbb13f6/8laftXD3vH73/dbLk2Oe
RTPXUd8bU3Nl1kc23745/38fWYiCQP8C/jqv/mskQgIECBAgQOBAIPevrzhoKvyjqw2U8M4C
G/RiNRBTUwQIECgQMB8X4Dl1OIGjPxzTckPiaV/bcUexbuBP2xiuOIUBcykEvDk9wnffxtkY
vwnF1wSmF7CJ8qDEVzfKB6c7hIAFlTFAgACBjgRq39dH3UDpqERCIUCAwJICPW2c7F+qLVmQ
wZLu+Q+XXFEevbDtefwdrSN7jvfKvvZ3b7tE9X80Rmvb3bUfldtRP5+2e8z7KF6fEWglsNxf
59UKVj8ECBAgQIBAfYHeFvc2UOrXXA9zCdS+Zmq3H1WNUeJ8mu9s+TzNu+S4njZQSvJwLoEU
ge913Pbi9vNfShtHx7ZcH9Z8mX2U25PPvi33//+T8yOOedslsv/Itkay7S3vCDttECgRWHIT
JeeGOuvkMWteJReFcwkQIEBgfoEa9z8vDecfNzKsI1Dr2qnV7kchqv2odupUJ73VFvlE9JHT
Rq1zam2g5MSbXnFnEMgT2G+g5LXy3lmfzYn3Ijju+W6Ne/f9catpn7bo4yqiGv3XaPMqh7Pv
WsfR6zg/8/E5gZoC/jqvmrraJkCAAAECBKoLbA/hrR8ojpI6egnmBdaRlM9aC2zj8Gh87uN4
c7y+2ffeIeXnp7ZnbY6adw/5lNiXuKf0+6SfJ9fmmbfPCcwg0MMaLtWx15ifxrUdl/OHi584
PY3hSVs5MUb2/yTGlse8mVvNMdPSUF8ESgR+/J6UfpU0MOq5uZPPbFypDrPl32r8cm4lrZ9e
BFLGvHmll6qNHUfKmPvO9Gr8Rb3YOnqJVtL2UXtR1SuJ6y6GmnGf9Z2aT40YU2PY5xIZ01Us
kf3sc/BzfwJXYyEl2h7GTWouPcT8MU6NvWVtUu+rV/fTlLgdWybwdt1S+t/GTMrxT2VyxmKN
OJ7GW3rcd74peeQ43cWa0v9dW7nxRcawjzE3pn07OT/XzCslnjcNUuJ869iUOrF8q0r5/dpE
SbSbbZCnXOAb1Wz5J5Y/+3DO2XROHFQgZcybVwYtcmdhp4y579Cvxl/0y639i7uc9vdtRJch
J6YnMdSO+yqGpznVjPFpDPs8asa078vP6wnkjstNytgsHy8l/ne9R9Qn9b56dT+9i9f3MQKp
Ndt6ja5bSgxb3ynHP1HKzSc6jiexRhyzzzclj/25pfGk9P2kr9z4ouP4jjU3pif5Xh1TM6er
fs++e8vhLJ6ePk+pFceeKvcslmU3UTaelMH9zTnTQE81mCn3Z5dIzFEpzoxjzLXyrkDNMf+k
bdfRu/V/q/cnY+MotrPxUusF1/fLrZQ+Il6KHeW//ywlps+5rWLbx+pnAgTKBFKvd9d6mffn
7FT3lF6japRyTz27j6bE7dhygZSafXqLrl1ODOWZ/91CaS4tY38S6108R23cnfNtfXR+SS1S
+r7rJze2yBiOYsyN66itJ5/VzudJDGfHtLY4i6O3z1NqxrC36t3HYxPl3ujwiFkGe8oFvkHM
kvdhUSt+mOLMuGIhNN1MoMaYT2nTfNWs1F11lDpGPsGfzbs1X3JtfUe96KpRhKe595xDDRdt
EiBAoFTg6fya2k/kfJx6Pz27j6bm4Ph8gdSafXqKrl1uHPmZ/31mRB4tYo+I88oqJYfIWFL6
vYp/+y43rsgYzmLMje2svf3nLXLY91nyc22PktjeOjelhvzeqlJ+v0tvomxsKQN8zzzDgE/J
f4Z89zVs9TPnVtL66UUgasyntHOUu3nrSGXuz3LHzNFYqfWia1+ByBdf+7b9TIAAAQL9CNS4
r9S4h6TeS4/uof2ozx9Jar0+IjXqlhtLSZWi8qgde1ScV1apOUTFlNrvWQ658UT1fxZXzWvm
03arHO5yTPk+t14pfYx2bEod+Y1W3b/++td4IfcTccrF0U/U+ZGslm++lDMJECgR2Oaaz38l
7TiXwCgCNV6qjZK7OAkQILCKQI25vsYGyir1eCvP73Vuyf//Vvw99bu9gBzlJeQocabWt/SZ
7VPDklrO8J6qVg4RvqljwvEEZhZY/jdRtuKWTlgj3xBTcx851zcv5BTnWsZPYqjV95v2+n5H
4Ml4axGZMd1Cub8+csff0Xip8dLrTMzLsDMZnxMgQGB8gaj7SYt7Rep99Oj+OX7F4jNIdb2L
YHMvabNG3Uriucv3832NuD9t14i/Zrx7s9T4S2JL7Wsfa0nfNeu1j/P754iY9+2XOu7b+/z8
JNbSvp/0cRbfrJ+nmPIbbxTYRPlds5RBflTikQd+Tu6j5HuVW+scrmLZj6kasb3d/z5HP88v
kDLmamrUuJ5qxqvtGIHc8Xc2XqJefD3NrsULsqexOI4AAQIEygVK7yOt7wup99Gz+2e53Dwt
pJrWzrxWzWrnWSvuj3d0/LXj3Y+T1Phz40vtZx9nbr/f7ZTGsI/pyc8Rce/7ic4jJ8bcGHL6
2uc/288plvzGq76/zut3zUoHbspFMt4Q+TPiLd+ec34SX8/x/yle9klqrqnHl0X332d/apf6
v5ExaIsAgfEFcu/rZ/Nf65dXpS/bxq+gDAgQIEDgI9D6HkSeQIlA6hrs6fHbcU+PLYk/8tzR
4o3MvXZbZ2v22v1Gtx+dR+6Yyz0v2kN7BHoXsInyT4VKJ43oya/3gbPF12POKTGlHDtCPUaP
saQe27mf/0Z3ED8BAn0KbC+xWr7IspHS5zgQFQECBFoKtLzv5OZV+hyd26/z8gV6q9ldPHff
50v8eWbLvv7svf0nOc/QJc/tW4alxqX95yqXxr3vNzqP0vi280vb2OfoZwKzCfjrvHYVLZ3I
Rpt0SvPd+HrIOTePVrGnxBcdU0rfn8shOoa7iTMnxqs2W8d/Fcuq30XXNNfRWMiVm+O8nHGY
O2ZqbXqM8AJtjtEiCwIECNQTyLlHvDn/p9w/c++b9bT7bDnFtGYGLeqVmmuLmFJMU+M/avvN
nHLjfxJzbtvfRk/6OTL9fBYRw1X7Z9+Vxv3dbnQOkbFtcT6JL7rPM/fRPn9i98mJ4WjV/esv
v4myq1npIN4umJSL5u0hU5rvZ4Jtnfenv9b9vl2vGfuvcb3UaHNG++icvq/L6LZz2ouY33L6
dc6aArVeduW8eFuzArImQIDAPAK17inzCMmEAIFogatn6NXfu/T8XFkjtrs2776PHpvaI9CL
gE2Ug0pETAhXN6CDLqf5qNbN9fvl7Kq20wySr0Rq1rJm2zPW4mlO+2vx++enbbQ4LmIebxGn
PuoKtB4Htf7KLxspdceJ1gkQIECAwAoCrddFK5iukGPkc3XpGIyM5WntSmN+2k/OcTVj29o+
+y8nVucQmEHAX+d1UsWoybnmpHYSetbHUfnedZ7jUTO2nHjucjz6PiWH6JhS+v7EHh3Dkcn2
WU5sZ22dfd4ql7P+R/68RX0ifdQ6UnOetlLHceQ4qrn54U8pzzNGZUKAwPwCKfeDHub3lHtn
5H1z5pGQYlrDoWWdUnNtGdtT29Qc9u2+mVNk7KVtfbuUmkTGsq/X1c+lcR+1XZpLjZiO4vRZ
ukBKbdUx3fftM/wmykkFogZzygV0EkqTj6PyvQt280gxSTn2rm/frylgDKXXPfU6Te8h9oxt
/mo1h8VGrrUWAm+OjVq/mbK5pbyQa+GsDwIECBCYQ8DauU4d31yPvNl3Hc36rTKL/QOPo3r2
FPfnmbenmOpfiXog0JeA30S5qUfUInKUiS4q3xvWbr5uVZcU1+iYUvr+FCY6hrOC58R21tbV
563yuYphlO9a1aTUQ01LBdc6P2Vc1xxbNTY+evgTy2uNJtkSIEAgT+DJPaCHOT3lnrlJ1Lxv
5kn3fVaqb2k2b9QnNcc3YnzimprHp80e8smN/fuaLmnj2zfKIyqeJ7X/dnh6fMpxOblEOabE
6dh0gZTaqmm679tn2ER5UIGUi+CquVEukKh8ryx6+K5lPVJMo+NK6ftTl+gYjuqdE9dRO08+
a5HPkzhKcm6RQ0l8T/IvPaaFQWmMzu9TIGVs1x5nT16ipSr28NItNWbHEyBAYEWBq3tAL3N5
yj1zq2Ht++aK4+STc2ot9lZv1iY19jdj3buV+veQS6r/t8EWf8n5n7aiHSJiOqv1/vPo2Pft
5+RSO6Z9jH7OE0iprZrmGb95lk2Uh/opF8JZkyNdIBH5njn08HnrWqR4RseW0vdWm+j+j+qd
GtNRG6mftcjrKqaInGvnEBHjlcHT72rn+TQOx80jkDq2a4/Bq5doueq9vHzLjd95BAgQINCH
QG/3zD5U3ositR6fSGuvZe5EUuOuEe9VDE/6uzr/Kv8nbV+dH/VdbvwR/dcwaJVPjdj3pjm5
tIhrH6ef0wRS66qmab49HO3fRHlYhYjBnXpBPQytymER+VYJLKDRmXML4KnexEjXQRRGVM5R
7UTlFd3Odm26PqNVtdejgA2PHqsiJgIECBAg0J/AZ338dI1sPf13De+em+6+31p5at7fqPk7
otHjb+3q2mktrj8C4wnYREmo2Wo3oRnznTGnhCE89KGltXuyUE4F2to8+y+1rafH18jjad+1
jrNgrSWr3Z4FbKT0XB2xESBAgACB/gQ+a+ar/+0v6mcRRT7jPG3ryXGlz6DPsq931BvPWSOZ
fV9L9aqgZQIEZhGwiZJYyZFuCImpHR4+U74z5XJYrAE+fLJQvUrjjUXgWTx3uXy+vzvurP2r
z2u0edWf7wgQqCNgI6WOq1YJECBAoI2A56s2znqpJ+C5KtZ2lDmhp/cKsRXQGgECNQVsomTo
ltwYRrxJl+SbwRt6yufmOHIOoSCTNPZ2PZ9ex0+Pm6Qs2WlwyqZz4gQCNlImKKIUCBAgQIAA
gWKB0meC7fzSNoqTWLiBt5/Rr+i/3wv1HOdVDr4jQOB9AZsomTX4TMI5p494Yx/lpjNKnDnj
psU5NRcUJeO+ZlwtXGv0UeJZIx5tEiCQL2AjJd/OmQQIECBAgAABz0bvjoFen9dL3tu9K6p3
AgR6FLCJ8lJVRr/J93Qz+t44eamc03Tb47jsdUHWQ9F7qpcNzB5GhBjOBFLnkTeuLRspZ9Xz
OQECBAgQILCKwNM12Hbc93+r+PSYZ+o6u0UOPb2vapGvPsYT6PG6GU+xfcQ/fhfuV/tu5+rx
6Y1+n/XM9Lkme6O7n0cxTPGIziml7807uv9PDVPjuIolp62r9u7G2f773P737UT9HFmzJ7k9
6e9JO9/5P2kzyks7awqMOCb/7//8z6Ni2YB5xOQgAgQIEHggkHK/tH57ALrwISljac90NrZK
2tz38fn5rK/P9yl93rV1FkOLz1PyeBpPy3xT4m8Z11Or7+NScnk6TnPicE6sQEpdex+jsTLz
tGYTJaCWKRfKvrvZL5wSm73V98+juaU4ROeW0vdmHN3/p26pcZzFktPOJ4ao3EpiuBrXJd9F
5bbFcJXf036u2jjL82nbZ+f7nMCVQOqY7Gk8Xm2m2EC5qrrvCBAgQCBVIOV+2dO9MjVPx7cR
SBlP+4i+x1dJO/t29z8/GcdP+n/Szr7vlj8/ySElntb5psTfIra7eK5iuDv3qA5X7R0d77P2
Ail1Vc/29Yno0SZKgGLKhbLvzoWzF5nz55QxEj0mUvre9KP7/1Q0Io7UNvajKSq30jj2cUX9
HJVfRDw5Rj3FH2Ggjb4EUsek8dhX/URDgAABAm0EUu6X7pVtajJyLynj6a08n47jq1yetvFW
jlu/V/GnxvVGvinx147vaSxXcTxt41Obq7ZS6+f4OgIpNVXPOjWo3erP2h2s0P42+FMulm+T
7TwXzwqjRI6lArnX2Kff3q+zknnkk+PHqIdcI/IpHTPOJ0CAAAECBAgQIECAQIRAD89YEXmU
tDGKQc33bCnvJWrGUVJH5xIgkCfgH5bPc/vjrJKbScok/EfHPiAwocD39bRdH71dIyXX+1W5
otrtzesqZ98RIECAAAECBAiMKWDNOWbdWkYd9XxTK+be46uVd067rHLUnEOAwEwCNlECq+mm
EoipqaUFPhsnUQ9mK16bUXZLD0TJTyWQOg+4hqYqv2QIECBAgACBlwRS12Ctwuw1rlr5l+Rb
cm6tfO7atZa/E/I9AQKpAjZRUsUqHW+CrwSr2eX/urhaC77Idr/bimzXvGICIECAAAECBAgQ
IEDgbYHIZ5yIXHqLJyKnJ22slnfk8/DnD3o+cXYMAQJzCthECa5ryU0pcoIPTktzBAg0FCiZ
RxqGedvVLHncJuoAAgQIECBAgMCiAp5hFy38oGlvzyerP6OkGozu9dn8KJmrSs4d9FIRNgEC
BwI2UQ5QfESAwBwCIy/4omK34JtjLMuCAAECBAgQIECAwMgCUc83qQafTYO3+k+Nt9XxTzZT
ZjNLfTb22yetRqN+CIwh8HOMMMeKcrvRpE7Onwy382a7UY1VPdHOIjDDdfTJIXc+Ga2W5r/R
KiZeAgQIECBAgMBf//vsO8PaWy3rC5S8K8mJzri8VxvFKGrsnM1Xqzxz348IRxAgcCbgN1HO
ZAo/L7kRmbwL8Z2+vEDJ9ZeCN1s/Kbk7lsAKAu7HK1RZjgQIECDwLdBqfUt9XYFtjNUaZ5+2
a/axbuXmyfyzxt/+9/PfPNnJ5A0Bz41vqLfv0yZKe3M9EiBQUaDWgrxWyE/jfXpcrTi1S2AG
AdfRDFWUAwECBAj0KOAFUo9V6TumyHWZTZO+a91jdG/PWSnjP+XYHq3FRGAWAZsoFStZMtG9
PaFXZNE0gWoCJddcblAlfaaem3p8bk5vnmfue1Nf3wQIECBAgACBfAHruHy7Vc8sfb7Zzi9t
Y1X7EfMerdZ38d59v9XoyTEj1lLMBEYU8G+iVK7aNuHlLia380yYlQuk+WkEVrlWSuaUaYot
EQIECBAgQIAAgWoCJetNz7DVyjJtw0fPcXfvUI7OmRZIYv8lUDI/taR8OkafHtcydn2lCdzN
V2mtObpnAZsoPVfnd2wWoZ0XSHhdCLy98MhZyJXEnNqfeaSLYSoIAgQIECBAgAABAgQeCJQ8
Kz1o3iGDC6Q+D7dO1/htLa4/Am0E/HVeDZxLJ1C7mg2KpIvhBLbr6vPfcMEvFHDp/LcQlVQJ
ECBAgAABAt0IlKzhPL92U0aBEJhWoGSOqoXi/UQt2X7bdb/rtzY1IvObKDVUD9rcJtOSi8uf
JD9A9dFjgafjr8eFyFGSJXE+uQ5L2j+Kd/9Z7fb3/W0/m0OOVHy2osDT+XBFGzkTIECAAIEo
AWvPKEntECBwJvB5rn7yjH/WRtTnbzzjR8WunTyB3HFnrOR593CW30TpoQoPY8i9QB8277DJ
Be4m6rvvS3ki28+9Fp6e9/S4b5On+T09rtT76PycvI7a8RkBAgQIECBAgMD8AqXrVmvP+ceI
DAn0IFA6V5XksPX9Zv8lsTuXAIE0gR+/L/Zfaac4ukSgdCGpXCX67577pPYr1PeJQ26lzvxy
+zxr7yq+q75y2jvr66qfs3M+n0fGcdfX9n1qrK3je5KDY+YSMCbnqqdsCBAgQKCuQOp9cx+N
td1exM8ECNQSKJ2vUuIyt6VozXds7lgzbsYdCzZRXqhd7oX2CdUF90LRgrq8qv1Kdb1yCKL+
958GKemr55qU5LUZt8wtNdaWsUWNN+2MJWBMjlUv0RIgQIDA+wKp9859xNZ3exE/EyBQS6B0
vrqLy3x2JzT/97ljzNgZe2z4N1FeqN920eRecC+Eq8tAARPm35gtroHZr7FSw83HeAy8uDVF
gAABAgQIECBwKvBZm1t/nhL5ggCBIIHSZ+XvMMxZQUXRDIEJBPybKC8VsWQinv3l8Esl0W1j
gZJroHGouiNAgAABAgQIECCwtEDU2t2z7NLDSPIEmglsc1bOvPU5L/f8ZgnqaDiBnPE4XJKT
B+w3UV4s8HYB5S4i/SnyFwun6zCBkmsgLIiBG+I3cPGEToAAAQIECBAYTCBq7elZdrDCC5fA
wAJeXA9cvIlCNw7nKKbfRHm5ji6klwug+9cFtmvAdfB6GQRAgAABAgQIECBA4FYgat2+baTk
/oHC2yAdQIAAAQIEKgm4d1WCHaBZmygDFOksRAvPMxmfjygQ9UA2Yu4lMc/mNls+JbV1bj0B
46yerZYJECBAYH6ByPvo55nWS6n5x40MCRAgMLqAe9XoFSyL3yZKmV/I2aWLUBdxSBk00oFA
6bUQmUJPsdzl1XusT+N7etydh+8JECBAgAABAgTqCtRYt9lQqVszrRMgQIBAvkDuu9ca98v8
LJxZImATpUSvo3P9VkpHxRBKkUAPN5geYkhF3GLuOe672O6+T/VwPAECBAgQIECAQF2Bmus3
z7d1a6d1AgQIEHgukLuB8rwHR44g8OP3wufXCIGuEGPURamkK4yW+XOMuh5SpGa5dp7YzZJr
Sn0dS+Bb4Ml18jne9WLsECBAgACBc4GUe+p5K/ffuB/fGzmCAAECBGIFSu9x7l2x9XizNb+J
8qb+ru+oC6v0Au+IRCgLC2zXQ9Q18YSxZV9P4ik55i6Xu+9L+nYuAQIECBAgQIDAWgKt1pbb
c+7nv7WEZUuAAAECBAi8LfDz7QD0X0dgW1y2WszWyUCrBP4WOBrHURuFR23P4j5zbrPUSB4E
CBAgQIAAgVkEtrVn1Br9icmnL2veJ1qOIUCAAIE3BNyj3lCv16e/zquebXbL0YtPF212KZw4
gEDu9eK6GKC4QiRQUSBl7jBfVCyEpgkQIEBgKoGU+2t04u7X0aLaI0CAAIHc+5p70nxjxyZK
pzXNvUiv0nEBX+n4bnSBp9eM62D0SoufQIzA0zlj6828EWOuFQIECBBYRyDlPltDxb27hqo2
CRAgsJ5Azv3MPWjOcWITpeO65lyoT9NxQT+VchwBAgQIzCaQen91z5xtBMiHAAECBFoIpN5v
o2Ny/44W1R4BAgTWEsi5j7n3zDtG/MPyHde25oW3TQSf/zomEBoBAgQIECBAgAABAgQIDChQ
83n2CYfn3SdKjiFAgACBKIG373tReWjnWMAmyrFLN5+2uABtqHRTboEQIECAAAECBAgQIEBg
GoHtebbFM+0VWM6fJL5qz3cECBAgQIDAegI/10t5vIw/i84Wi7/vPt5e7I5XKRETIECAAAEC
BAgQIECAwF7g+9myxXPtvv+7Pj377sX8TIAAAQIECHwL2EQZaNGEoz8AACAASURBVDxsC7u7
xV9kOjZUIjW1RYAAAQIECBAgQIAAAQJvb6gcVeDz7Gsz5UjHZwQIECBAgIC/zmuwMbAt6t5Y
2G2LypYbOIOVRbgECBAgQIAAAQIECBAgkCjw1vPtWZieec9kfE6AAIG1BNwP1qr3k2x//F60
/HpyoGP6E3j7gjZ0+hsTIiJAgACBe4GU+6d73b2nIwgQIECAQKRAyn06st99W9YAexE/EyBA
YA2BnPuQe8b8Y8Nvogxc47cv0JxJZWBuoRMgQIAAAQIECBAgQIBAZYHPb6f08LzrmbdysTVP
gACBzgTM+50VpKNwbKJ0VIycUHpYWObE7RwCBAgQIPCGgEXxG+r6JECAAAECeQKfDZW8s2PO
2tYO1g8xllohQIBAzwLm+p6r835sNlHer0FxBG8vLE0yxSXUAAECBAgQIECAAAECBAicCPTw
2yk2U06K42MCBAgQILCAgE2UiYr85maKjZSJBpJUCBAgQIAAAQIECBAg0KnA2xsqnn07HRjC
IkCAAAECFQX8w/IVcXto+o0F3tt/xVgP7mIgQIAAgf4Ecu6J7mn91VFEBAgQIEDgWyDn/h4l
aJ0QJakdAgQIvCtQci9xL3i3dq16/9mqI/28I/B9IZdMCCnRH/VjQkkRdCwBAgQIECBAgAAB
AgQIPBH4PGsePYc+Ob/kmE+fnndLFJ1LgACBcQXM/+PWLjVyf51XqtjAx28X9ue/1mm8saBt
naP+CBAgQIAAAQIECBAgQOAdgTdfZG3Pu55536m7XgkQIPCWwJv3nbdyXrlff53XytX/J/fW
iz2TjEFHgAABAm8IpN7v3K/eqJI+CRAgQIBAPYHUtUBuJNYQuXLOI0CAQHuBnHuDeb59nd7u
0V/n9XYFOuj/+8LPmThSU/juw6STqud4AgQIEMgRaHF/y4nLOQQIECBAgEA7gc/zZ+11wad9
z7vtaqsnAgQIECBQU8AmSk3dAdtutaj80BwtXi00Bxw4QiZAgAABAgQIECBAgMAgAtsz59Gz
aHT4Wx+eb6NVtUeAAIE4gRb3grhotfSmgL/O6039QfruYUKx8BxksAiTAAECnQqk3svcdzot
pLAIECBAgECwQOoaIbd7a4tcOecRIECgnkDOPcB8Xq8ePbfsN1F6rk4nsbX6UzpX6R5Naiat
KzHfESBAgMBH4OgeQocAAQIECBAgsAl8nitrrxe+2/csa+wRIECAAIGxBP41VriifUugx0Ve
7UXuW9b6JUCAAAECBAgQIECAAIG2Atszb6vn3u1Z9vNf2yz1RoAAAQIfAe8VjYUUAZsoKVqL
H9tqQZnCbOGZouVYAgQIECBAgAABAgQIELgSaLmZssXhmfaqGr4jQIBAXwI9vhvtS2jeaGyi
zFvbKpn1OlnYPa5Sbo0SIEBgeIGc+0Ov97rhiyEBAgQIECAwkEDr9YDNlIEGh1AJEBheIOc5
cfikJVAk4N9EKeJb8+TPYrK3CecuntaL4DVHh6wJECBAgAABAgQIECAwh8Abz77751rPsXOM
JVkQIDC+gPl4/BqWZGATpURv8XOPJo/9gq8norPYjvLoKW6xECBAgAABAgQIECBAgMB7Am9s
pnyy/TzHem59r/56JkBgHoGzd4PzZCiTWgI/ft+If9VqXLtrCswwIbks1hy7siZAYC6BnPuR
+X+uMSAbAgQIECBQQyBnjREVh7VKlKR2CBBYRSBqzjb/rjJijvO0iXLs4tMAgahJKiCU0CZM
mqGcGiNAgEA1gZz7kDm+Wjk0TIAAAQIEphPIWWtEIVizRElqhwCBGQWi52dz7oyjJC0nmyhp
Xo7OFIievDLDqHaaybQarYYJECCQJZB73zGfZ3E7iQABAgQILC2Qu+6IQLN2iVDUBgECowvU
nofNtaOPkPL4baKUG2ohU6D2BJcZVthpJtgwSg0RIEAgSSD3/mLeTmJ2MAECBAgQIPAlkLv+
iEK0jomS1A4BAqMItJp3za+jjIi6cfqH5ev6av1C4GgSajUBXoQV9tVZLkd5h3WqIQIECBAg
QIAAAQIECBBoLvB5zjt7Dqwd0He/njlra2ufAIE3BN6aX9/IVZ/9CfhNlP5qIqKdwAqTpEWu
YU+AAIEYgZJ7hrk4pgZaIUCAAAECBP4WKFmXRBla30RJaocAgZYCPcyfW77m0JZV77svmyh9
10d0/wj0Mnm2LojJurW4/ggQGFmg5F5hvh258mInQIAAAQL9C5SsU6Kys96JktQOAQKlAj3M
iXc5mDPvhNb63ibKWvUePtsRJtmWyCb0ltr6IkCgd4GSe4T5tPfqio8AAQIECMwhULJeiRKw
7omS1A4BAk8Eepj3nsT5fYx5MlVs/uNtosxf4+kyHHHyfbsIJv+3K6B/AgRqC5TcG8yRtauj
fQIECBAgQGAvULJ22beV+7M1UK6c8wgQuBLoYX67iu/uO3PjndCa39tEWbPuU2c9+mTdU3Hc
OHqqhlgIEDgTKJn3zXNnqj4nQIAAAQIEWgqUrGci4rQmilDUBoH1BN6eu6LFzYXRovO0ZxNl
nlrK5EZgton9Jt3mX7vRNCfXIQEC/wiUzO/mLsOIAAECBAgQ6EmgZF0TmYc1UqSmtgjMI9DL
HBUtas6LFp2vPZso89VURgkCs07+CQTVDnUDqkarYQIEvgRK5nHzlKFEgAABAgQI9CpQssaJ
yslaKUpSOwTGFehhLqqlZ46rJTtnuzZR5qyrrAIEZr5RBPBkNeEGlcXmJAIEdgIR87P5yLAi
QIAAAQIERhCIWPeU5mndVCrofALjCPQw59TUMp/V1J27bZsoc9dXdsECs99Mgrkum3PjuuTx
JQECO4Ho+dccZIgRIECAAAECIwlEr4Vyc7eGypVzHoF+BXqZX2oImbNqqK7Zpk2UNesu60CB
mW82gUy3Tbmx3RI5gMCSAjXmWPPNkkNJ0gQIECBAYAqBGmujHBjrqRw15xB4T6CXuaOFgPmp
hfJ6fdhEWa/mMm4ksNINqhHpZTdukpc8viQwlEDN+dNcMdRQECwBAgQIECBwIVBzzXTRbchX
1mQhjBohcCsw8jxxm9w/B5hPnko5rkTAJkqJnnMJJAqscPNKJHn1cDfaV/l1TuAPgRZzpOv+
D3YfECBAgAABAhMItFhHRTNZl0WLao/AfwRGnBOe1M+88UTJMTUEbKLUUNUmgUSBWW9uiQzd
H+5m3X2JBNixQA/znGu44wEiNAIECBAgQCBMoId119NkrM+eSjmOwHOBkeaAfVbmhL2In3sR
sInSSyXEQeBCYOQb4EVa033lZj9dSSUUINDT/OUaDSioJggQIECAAIFhBHpah0Whjbaee1KD
0XKKqOUTl+9+ooxS+03JNSrGlD6Pjq2Z41F/JZ/1YlaSg3PXEbCJsk6tZbqAwEg3ywXK8UeK
NRYINWpeI84/MHwwtUCNcVkKZlyXCjqfAAECBAgQGFWgx7XZqJbiJhAlkPJ8Mss1nJJzlLN2
CEQJ2ESJktQOgYEFZrkhD1yCrkO30Om6PF0F1+tcYgx3NUwEQ4AAAQIECLwo0Ot67UUSXRMg
UEHAM1gFVE2+KmAT5VV+nRMYT8Cie7yaRUc8ymLoyVjd55JzTrTviO09cXsrr32N34pDvwQI
ECBAgACBHgV6Xsf16CUmAgSOBTx3Hbv4dB4Bmyjz1FImBF4RsOh+hV2nBAjcCFjE3wD5mgAB
AgQIECDwj4BnOkOBAIEUAc9aKVqOnUXAJsoslZQHgY4ELMI7KoZQCCwkYDG/ULGlSoAAAQIE
CIQLeI4LJ9UggWkEPGtNU0qJZArYRMmEcxoBAs8ELMSfOTmKAIE8AYv5PDdnESBAgAABAgSu
BDzHXen4jsAaAp611qizLJ8J2ER55uQoAgSCBCzGgyA1Q2BxAQv6xQeA9AkQIECAAIEmAp7f
mjDrhMBrAp6rXqPX8WACNlEGK5hwCawuYBG/+giQ/8oCFvgrV1/uBAgQIECAwIgCnt9GrJqY
VxDwbLVCleUYKWATJVJTWwQIdClg4d5lWQRF4LGABf5jKgcSIECAAAECBLoT8DzWXUkEtLCA
Z6uFiy/1IgGbKEV8TiZAYEYBi/wZqyqnXgUs4nutjLgIECBAgAABAnECnrHiLLVEIFfAs1eu
nPMI/PWXTRSjgAABAokCHgASwRxO4EDAAv4AxUcECBAgQIAAAQL/K+CZy0BoKZDybDLq2EzJ
saW9vgiMImATZZRKiZMAgWEEel9UfRZPvcc5TMEF+ljAwv0xlQMJECBAgAABAgQIEJhAoOZz
t+erCQaIFIYRsIkyTKkESoAAgboCNRd3dSPXeu8CFve9V0h8BAgQIECAAAECBAgQIECAwJnA
z7MvfE6AAAECawnsX3TbVFmr/jWy3Y+pGn1okwABAgQIECBAgAABAgQIECBQU8AmSk1dbRMg
QGBgAS/ABy6e0AkQIECAAAECBAgQIECAAAECBEIE/hXSikYIECBAgAABAgQIECBAgAABAgQI
ECBAgAABApMJ2ESZrKDSIUCAAAECBAgQIECAAAECBAgQIECAAAECBGIEbKLEOGqFAAECBAgQ
IECAAAECBAgQIECAAAECBAgQmEzAJspkBZUOAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECNg
EyXGUSsECBAgQIAAAQIECBAgQIAAAQIECBAgQIDAZAI2USYrqHQIECBAgAABAgQIECBAgAAB
AgQIECBAgACBGAGbKDGOWiFAgAABAgQIECBAgAABAgQIECBAgAABAgQmE7CJMllBpUOAAAEC
BAgQIECAAAECBAgQIECAAAECBAjECNhEiXHUCgECBAgQIECAAAECBAgQIECAAAECBAgQIDCZ
gE2UyQoqHQIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBGwCZKjKNWCBAgQIAAAQIECBAgQIAA
AQIECBAgQIAAgckEbKJMVlDpECBAgAABAgQIECBAgAABAgQIECBAgAABAjECNlFiHLVCgAAB
AgQIECBAgAABAgQIECBAgAABAgQITCZgE2WygkqHAAECBAgQIECAAAECBAgQIECAAAECBAgQ
iBGwiRLjqBUCBAgQIECAAAECBAgQIECAAAECBAgQIEBgMgGbKJMVVDoECBAgQIAAAQIECBAg
QIAAAQIECBAgQIBAjIBNlBhHrRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQKTCdhEmayg0iFA
gAABAgQIECBAgAABAgQIECBAgAABAgRiBGyixDhqhQABAgQIECBAgAABAgQIECBAgAABAgQI
EJhM4Odk+UiHAAECBAgQIECAAAECBAgQIFAs8OPHj9s2fv36dXuMAwgQIECAAIGxBWyijF0/
0RMgQIAAAQIECBAgQIAAAQLBAk82ULYur46zwRJcFM0RIECAAIGXBGyivASvWwIECBAgQIAA
AQIECBAgQKA/gauNkZRov9vJ3VB5Ektu2ym5OJYAAQIECKwsYBNl5erLnQABAgQIECBAgAAB
AgQIEKgucLYZst8AOTvuKsDtnH07V8f7jgABAgQIEEgTsImS5uVoAgQIECBAgAABAgQIECBA
gECIQM6myVHHNlKOVHxGgAABAgRiBP4V04xWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJz
CdhEmauesiFAgAABAgQIECBAgAABAgQIECBAgAABAgSCBGyiBEFqhgABAgQIECBAgAABAgQI
ECBAgAABAgQIEJhLwCbKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYBMlCFIzBAgQ
IECAAAECBAgQIECAwPgCv379Gj8JGRAgQIAAAQJhAjZRwig1RIAAAQIECBAgQIAAAQIECMwg
YCNlhirKgQABAgQIxAj8jGlGKwQIECBAgAABAgQIECBAgACBeQS+N1J+/PgxT2IyIUCAAAEC
BJIEbKIkcTmYAAECBAgQIECAAAECBAgQWE3g6jdTbLCsNhrkS4AAAQKrCdhEWa3i8iVAgAAB
AgQIECBAgAABAgTCBPzGShilhggQIECAQJcCNlG6LIugCBAgQIAAAQIECBAgQIAAgdEEbKiM
VjHxEiBAgACBewGbKPdGjiBAgAABAkMLXP0VE1d/NcXQSQcGf+W3dcMwEFtTBAgQIEBgEoG7
9cNRmjZgjlR8RoAAAQIE3hf41/shiIAAAQIECBCoJXD3AH/3fa24Rmh3s3ni8+SYEfIVIwEC
BAgQIBAj8MbawB/qiKmdVggQIECAwJGA30Q5UvEZAQIECBCYQODpA/zT445Ien9gL8ntKN+z
z7Z+erc4i93nBAgQIECAQIxAq3VHTLRaIUCAAAECBJ4K2ER5KuU4AgQIECBA4A8BLwv+IPEB
AQIECBAgsKCANdGCRZcyAQIECCwj4K/zWqbUEiVAgAABAgQIECBAgAABAgSiBSI2UPx7KNFV
0R4BAgQIEIgTsIkSZ6klAgQIECBAgAABAgQIECBAgEBTAX+laFNunREgQIDAggI2URYsupQJ
ECBAgAABAgQIECBAgACBPgRsgvRRB1EQIECAAIEzAZsoZzI+J0CAAAECBAgQIECAAAECBAhc
CJT+VV42UC5wfUWAAAECBDoRsInSSSGEQYAAAQIECBAgQIAAAQIECIwjYANlnFqJlAABAgQI
lAjYRCnRcy4BAgQIECBA4LeAP0VqGBAgQIAAgbUESjdQ1tKSLQECBAgQGFvAJsrY9RM9AQIE
CBAg8LKADZSXC6B7AgQIECDQWCBiA+Vs/ZDa9lk7jUl0R4AAAQIEphawiTJ1eSVHgAABAgQI
1BTw4qKmrrYJECBAgEB/AqmbHEcZnK0fIto+6s9nBAgQIECAQJnAz7LTnU2AAAECBAgQWEvg
7MXHWgqyJUCAAAEC6wlEbHKcrSMi2l6vIjImQIAAAQJtBGyitHHWCwECBAgQINCRwNkLjI5C
FAoBAgQIECDQkUDEJof1R0cFFQoBAgQIEEgQsImSgOVQAgQIECAwq8D2UB/xcuDMx0uDMxmf
EyBAgAABAr0LRKyRrIV6r7L4CBAgQIDAuYB/E+XcxjcECBAgQGApgZoP99vLh4gXEEsVRLIE
CBAgQIDA6wIR65eaa6zXgQRAgAABAgQWELCJskCRpUiAAAECBHoRiHgR0Usu4iBAgAABAgTm
FYj6AyA1N1Bqtj1vZWVGgAABAgTSBWyipJs5gwABAgQITCvQ4mHcRsq0w0diBAgQIEBgCoGo
tUrNdVXNtqcooiQIECBAgECggE2UQExNESBAgACBGQRaPJRHvZyYwVsOBAgQIECAQD8CUWuU
muupmm33UwmRECBAgACBfgRsovRTC5EQIECAAIFuBLaH89oP6FEvKbpBEwgBAgQIECAwtEDU
2qT2GmpoZMETIECAAIEBBWyiDFg0IRMgQIAAgVYCtV8CRL2saOWhHwIECBAgQGBOAWuSOesq
KwIECBAgECFgEyVCURsECBAgQGBigdq/leKlxcSDR2oECBAgQGAAgci1SO0/gDIApxAJECBA
gMB0AjZRpiuphAgQIECAQB2Bz2ZKjZcDkS8v6mSvVQIECBAgQGBGgcg1SI010ozmciJAgAAB
AqMJ2EQZrWLiJUCAAAECHQjU+O2UyJcYHRAJgQABAgQIEOhcIHLtYQOl82ILjwABAgQIFAjY
RCnAcyoBAgQIEFhdIHozJfJlxuq1kT8BAgQIECDQRsAGShtnvRAgQIAAgbcEbKK8Ja9fAgQI
ECAwkUDkZoqNlIkGhlQIECBAgECnAlHrDRsonRZYWAQIECBAIFDAJkogpqYIECBAgMDqAlGb
KVEvNlavh/wJECBAgACBPwWi1hk2UP609QkBAgQIEJhRwCbKjFWVEwECBAgQeFkg4qVC1AuO
lyl0T4AAAQIECEwmEPWHRiZjkQ4BAgQIEJhWwCbKtKWVGAECBAgQeFcgYiPl3Qz0ToAAAQIE
CMwmUPqHNKxvZhsR8iFAgAABAvcCNlHujRxBgAABAgQIZAqUvmgofdGRGbbTCBAgQIAAgQkF
StcVpeuaM9LSuM7a9TkBAgQIECAQI2ATJcZRKwQIECBAgMCJQK0XDifd+ZgAAQIECBAg8IdA
6UZFrfVMaVx/JOoDAgQIECBAIFzAJko4qQYJECBAgACBvUDJiwcvF/aafiZAgAABAgRSBErX
EiXrmKs4S+O6att3BAgQIECAQJyATZQ4Sy0RIECAAAECFwK1XkBcdOkrAgQIECBAYHGB0o0K
65fFB5D0CRAgQIDAbwGbKIYBAQIECBAg0Ewg90VE6QuQZgnqiAABAgQIEOhGwPqhm1IIhAAB
AgQIDC1gE2Xo8gmeAAECBAisI+BFyDq1likBAgQIECgViFg35P7hj9LYnU+AAAECBAj0JWAT
pa96iIYAAQIECEwv4IXE9CWWIAECBAgQGF7AemX4EkqAAAECBAiECdhECaPUEAECBAgQIFBb
IOJPldaOUfsECBAgQIDAuwKl6wUbKO/WT+8ECBAgQKA3AZsovVVEPAQIECBAYAGBkpcTpS9G
FuCVIgECBAgQIJApULJGyezSaQQIECBAgEDnAjZROi+Q8AgQIECAAIE/BWyk/GniEwIECBAg
QOCvv0ZaI+Rs2OScY1wQIECAAAECZQI2Ucr8nE2AAAECBLoUGOEFgpcAXQ4dQREgQIAAgWEF
Stc/b6xNUvpMOXbYIgqcAAECBAh0KPCzw5iERIAAAQIECCwisL0MyH3h8TnPC4VFBos0CRAg
QIDAhUDueuLT5JvriTf7viD1FQECBAgQIPCPgN9EMRQIECBAgACB7I2MHuhKX5r0kIMYCBAg
QIAAgXyB0rWATYx8e2cSIECAAIEVBGyirFBlORIgQIAAgQcCpS8gHnRxeEjEi4u3Yj9MyIcE
CBAgQIBAM4HSNUDEOqRZsjoiQIAAAQIEXhGwifIKu04JECBAgACBb4GIFxilL1FUhAABAgQI
EBhLwL1/rHqJlgABAgQIjCpgE2XUyombAAECBAhMJmAjZbKCSocAAQIECFQUiNhAiVh7VExR
0wQIECBAgEAnAjZROimEMAgQIECAAIEYgYiXKjGRaIUAAQIECBAgQIAAAQIECBAYXcAmyugV
FD8BAgQIEJhIIOpPhNpImWhQSIUAAQIECOwEIu7zUWsOxSFAgAABAgTmF7CJMn+NZUiAAAEC
CwqM/GJg5NgXHGpSJkCAAAECTQVsoDTl1hkBAgQIECDwW8AmimFAgAABAgQmFRh5MyIi9oiX
LJMODWkRIECAAIEhBSLu7RFrjCHxBE2AAAECBAhkC9hEyaZzIgECBAgQIFBTIOIlR8TLlpo5
apsAAQIECBB4JhBxT49YWzyL1lEECBAgQIDATAI2UWaqplwIECBAgMBOYPSXBRHxR7x0MbAI
ECBAgACB9wQi7uURa4r3BPRMgAABAgQIvClgE+VNfX0TIECAAIEGAk9fGjw9rkHI/9XFFlev
sbW20B8BAgQIEFhNwAbKahWXLwECBAgQ6E/AJkp/NRERAQIECBAIF7jbhLj7PjygjAZLYox4
AZMRslMIECBAgACBlwVK1g8vh657AgQIECBAoBOBn53EIQwCBAgQIECgssDqLxG2jZTVDSoP
Mc0TIECAAIGuBNz3uyqHYAgQIECAwLACfhNl2NIJnAABAgQIrCdQ+jLEb6SsN2ZkTIAAAQLj
CpTct0vXDOOqiZwAAQIECBCIFrCJEi2qPQIECBAgQKCqgJciVXk1ToAAAQIEuhCwgdJFGQRB
gAABAgQI/BawiWIYECBAgAABAsMJlGyklLyUGQ5KwAQIECBAYEAB9+oBiyZkAgQIECAwsYBN
lImLKzUCBAgQIEDgWMDLmWMXnxIgQIAAgdEFSv6gxei5i58AAQIECBCoI2ATpY6rVgkQIECA
AIHKAqUvSWykVC6Q5gkQIECAQIZAyf25dG2QEa5TCBAgQIAAgQUEbKIsUGQpEiBAgACBWQW8
LJm1svIiQIAAgRUFSjZQVvSSMwECBAgQINBGwCZKG2e9ECBAgAABApUESjZSvKypVBTNEiBA
gACBBIHtflx6Ty5ZDySE6lACBAgQIEBgQQGbKAsWXcoECBAgQIDAfwRKX9qwJECAAAECBPIF
Iu7DNlDy/Z1JgAABAgQI3AvYRLk3cgQBAgQIECDQuYCXJ50XSHgECBAgQOBAwAbKAYqPCBAg
QIAAge4EbKJ0VxIBESBAgAABAjkCJRspES9xcmJ2DgECBAgQWFXAvXfVysubAAECBAiMJ2AT
ZbyaiZgAAQIECBA4EbCRcgLjYwIECBAgMKFAyX1/Qg4pESBAgAABApUEbKJUgtUsAQIECBAg
QIAAAQIECBAg8KdAxG+h2ED509UnBAgQIECAQB0Bmyh1XLVKgAABAgQIvCRQ8lIl4qXOS2nr
lgABAgQILCNQcq9fBkmiBAgQIECAQJiATZQwSg0RIECAAAECvQiUvFyxkdJLFcVBgAABAjMK
lN5nS+7xM3rKiQABAgQIEKgvYBOlvrEeCBAgQIAAgcEESl/wDJaucAkQIECAQBOB0vurDZQm
ZdIJAQIECBAgsBOwiWJIECBAgAABAlMKlL5oKX3RMyWqpAgQIECAwEsCpff1l8LWLQECBAgQ
IDCBgE2UCYooBQIECBAgQOBYoPSFy7aRYjPl2NanBAgQIEAgRaDkflp6P0+J07EECBAgQIAA
gb2ATZS9iJ8JECBAgAABAjuBkhc/MAkQIECAwOoCJfdRGyirjx75EyBAgACB9wVsorxfAxEQ
IECAAAECFQWiXr6UvACqmJ6mCRAgQIBA1wLun12XR3AECBAgQIDAAwGbKA+QHEKAAAECBAiM
LWAjZez6iZ4AAQIExhOI+Csxo+7f4+mJmAABAgQIEOhJwCZKT9UQCwECBAgQINC9gD9R232J
BEiAAAECLwtE3CttoLxcRN0TIECAAAEC/xawiWIwECBAuEBFkQAAIABJREFUgAABAksIRL6M
iXg5tAS6JAkQIEBgOQH3yOVKLmECBAgQIDC9gE2U6UssQQIECBAgQOAjELmRQpUAAQIECBD4
b4GoDRT3ayOLAAECBAgQ6EnAJkpP1RALAQIECBAgUF0g6sVM1Iui6gnrgAABAgQIDCQQdZ8e
KGWhEiBAgAABAp0L2ETpvEDCI0CAAAECBOIFol7Q2EiJr40WCRAgQGBMgYh7YtT9eUxBURMg
QIAAAQK9CthE6bUy4iJAgAABAgSqCmwvaiJe1kS8NKqaqMYJECBAgEBlgYh7YcQ9uXKamidA
gAABAgQWFfjxe6Hya9HcpU2AAAECBAgQ+F+BiJc/WzuWVQYUAQIECKwk4P65UrXlSoAAAQIE
1hXwmyjr1l7mBAgQIECAwD8CfivFUCBAgAABAmkCNlDSvBxNgAABAgQIjCtgE2Xc2omcAAEC
BAgQ6FAg6qVSh6kJiQABAgQI/K9A1L3Ob3AaUAQIECBAgMAIAjZRRqiSGAkQIECAAIEmAlEv
c6JeLjVJWicECBAgQCBBIOoeF3XPTQjdoQQIECBAgACBLAGbKFlsTiJAgAABAgRmFYh6qRP1
kmlWZ3kRIECAwHgCUfe2qHvteIIiJkCAAAECBEYUsIkyYtXETIAAAQIECFQViHq5E/WyqWqy
GidAgAABAg8E3NMeIDmEAAECBAgQmFLAJsqUZZUUAQIECBAg0IuAl069VEIcBAgQIJArEHkv
i/qDCrm5OI8AAQIECBAgkCpgEyVVzPEECBAgQIDAEgKRL3kiXz4tgS9JAgQIEOhGIPIeFnlv
7QZIIAQIECBAgMD0AjZRpi+xBAkQIECAAIFcAS97cuWcR4AAAQIzCNhAmaGKciBAgAABAgRK
BWyilAo6nwABAgQIEJhawEbK1OWVHAECBAicCERtoGz3UffSE2QfEyBAgAABAkMI2EQZokyC
JECAAAECBN4UiHgBFPUy6k0HfRMgQIDAGgJR9yybJ2uMF1kSIECAAIHZBWyizF5h+REgQIAA
AQJhAl4GhVFqiAABAgQ6FYjYQIn4wwed8giLAAECBAgQWFDAJsqCRZcyAQIECBAgkC9QspES
8WIqP3JnEiBAgACBa4GI+1TJffI6Ot8SIECAAAECBN4RsInyjrteCRAgQIAAgYEFSl4QRbyg
GphO6AQIECDQqYD7U6eFERYBAgQIECDwuoBNlNdLIAACBAgQIEBgRIGSjZQR8xUzAQIECMwr
ELWB4t447xiRGQECBAgQWFng58rJy50AAQIECBAgQIAAAQIECKwqELV5svnZQFl1FMmbAAEC
BAjML+A3UeavsQwJECBAgACBSgJeGFWC1SwBAgQIVBewgVKdWAcECBAgQIDAJAI2USYppDQI
ECBAgACBcQQiX1yNk7VICRAgQKAXgaj70PaHCfyBgl6qKg4CBAgQIECgloBNlFqy2iVAgAAB
AgSWEMh9eRT1AmsJZEkSIECAQJhA1P0n9/4XloiGCBAgQIAAAQKNBGyiNILWDQECBAgQIDCv
gBdJ89ZWZgQIECDwp4D73p8mPiFAgAABAgTmFbCJMm9tZUaAAAECBAh0LhD1p4E7T1N4BAgQ
IDCRgA2UiYopFQIECBAgQOCRgE2UR0wOIkCAAAECBAgQIECAAAECYwuUbt7bQBm7/qInQIAA
AQIE8gRsouS5OYsAAQIECBAgECJQ+kIrJAiNECBAgMD0AqX3Gxso0w8RCRIgQIAAAQInAjZR
TmB8TIAAAQIECBBIEfByKUXLsQQIECDQUsAGSkttfREgQIAAAQKzCdhEma2i8iFAgAABAgRe
E8jdSCl9ufVawjomQIAAge4FSu8xufe27mEESIAAAQIECBB4KGAT5SGUwwgQIECAAAECNQVK
X3LVjE3bBAgQIDCmQOm9xQbKmHUXNQECBAgQIBArYBMl1lNrBAgQIECAwOICJS+cSl92LU4v
fQIECBD4EnBPMRwIECBAgAABAjECNlFiHLVCgAABAgQIEAgR8NIrhFEjBAgQWFog4l5S8ocC
lsaXPAECBAgQIDCdgE2U6UoqIQIECBAgQOBtgdIXTxEvv9420D8BAgQIjCtQeh8bN3OREyBA
gAABAgT+FLCJ8qeJTwgQIECAAAECBAgQIECAwJICNlCWLLukCRAgQIAAgQuBH78XSL8uvvcV
AQIECBAgQIBApkDUb5RYrmUWwGkECBBYUKDk3uN+s+CAkTIBAgQIECBwK+A3UW6JHECAAAEC
BAgQyBOIehlV8kIsL3JnESBAgMBqAlH3rNXc5EuAAAECBAjML2ATZf4ay5AAAQIECBCYQGDb
SLGZMkEhpUCAAIEOBWygdFgUIREgQIAAAQLdCNhE6aYUAiFAgAABAgRmFIh+MWUzZcZRIicC
BAjECORstkffp2Iy0QoBAgQIECBAoB8Bmyj91EIkBAgQIECAwKQCNV5Q5bwom5RXWgQIECBA
gAABAgQIECBAoJrAz2ota5gAAQIECBAgQODfAttGSvTGx769Gps1SkiAAAECBAgQIECAAAEC
BFYW8JsoK1df7gQIECBAgEBTgdqbHPtNlabJ6YwAAQIEhhOofV8aDkTABAgQIECAAIEDAZso
Byg+IkCAAAECBAjUEqj9wsq/mVKrctolQIAAAQIECBAgQIAAgRUFbKKsWHU5EyBAgAABAq8K
1N5I2ZLzWymvlljnBAgQaC5g3m9OrkMCBAgQIEBgEQGbKIsUWpoECBAgQIBAXwKtNlK8VOur
7qIhQIBADYGcub7FfahGrtokQIAAAQIECLQWsInSWlx/BAgQIECAAIF/BFq9wPJXfBlyBAgQ
mFcgZwNlXg2ZESBAgAABAgTiBX7GN6lFAgQIECBAgACBpwLfGym1X4R92m+1efPUwHEECBAg
QIAAAQIECBAgQKBXAb+J0mtlxEWAAAECBAgsJ9Bqc+Pzmym1N22WK6CECRAg0FjAPN4YXHcE
CBAgQIDAkgI2UZYsu6QJECBAgACBXgW2jZRWmymbgb/qq9eRIC4CBAhcC9hAufbxLQECBAgQ
IEAgSsAmSpSkdggQIECAAAECgQJvbKYEhq8pAgQIEOhYoOVmfccMQiNAgAABAgQIPBKwifKI
yUEECBAgQIAAgXcEWr7o8qea36mxXgkQIJAqUDJft7yvpObleAIECBAgQIBAjwL+YfkeqyIm
AgQIECBAgMCXwP6FV8nLszvYre19f3fn+J4AAQIExhAwv49RJ1ESIECAAAECfQn4TZS+6iEa
AgQIECBAgMCtQO2XYDU3aW6TcwABAgQIXAqYoy95fEmAAAECBAgQCBewiRJOqkECBAgQIECA
QH2B1v9mSv2M9ECAAAECdwIlGyi1N+DvYvc9AQIECBAgQGBUAZsoo1ZO3AQIECBAgACB3wK1
XoqVvKhTGAIECBCIFyiZl2vdK+Kz1CIBAgQIECBAoD8Bmyj91UREBAgQIECAAIEkgVq/lVLy
wi4pAQcTIECAAAECBAgQIECAAIFOBWyidFoYYREgQIAAAQIEUgVqbKbYSEmtguMJECDQl4Df
QumrHqIhQIAAAQIExhOwiTJezURMgAABAgQIELgUiN5MsZFyye1LAgQIECBAgAABAgQIEJhY
4OfEuUmNAAECBAgQILC0wPefPrYRsvRQkDwBAoML5M7hfgtl8MILnwABAgQIEOhCwG+idFEG
QRAgQIAAAQIE6gqUvkjbXuDlvsSrm5nWCRAgMLdA7txbOu/PrSo7AgQIECBAgMBzAZsoz60c
SYAAAQIECBAYWiDihVruy7yh4QRPgACBwQQi5vvBUhYuAQIECBAgQKCagE2UarQaJkCAAAEC
BAj0JxDxYu3zWyk2VPqrr4gIEJhLwDw7Vz1lQ4AAAQIECIwpYBNlzLqJmgABAgQIECCQLRCx
kfLp3Au+7DI4kQABApcC5tdLHl8SIECAAAECBJoJ2ERpRq0jAgQIECBAgEA/AjZS+qmFSAgQ
IECAAAECBAgQIECgXwGbKP3WRmQECBAgQIAAgWEEPn/F1zABC5QAAQIdC5T8FkrkJnnHREIj
QIAAAQIECDQTsInSjFpHBAgQIECAAIG+BGq8aCt58deXjmgIECDwjkDJPFpjXn9HQa8ECBAg
QIAAgX4EfvYTikgIECBAgAABAgRaC2wv3Epe2B3Fu7XnRd6RjM8IEOhR4GoObD2XXcXSo52Y
CBAgQIAAAQIrCPhNlBWqLEcCBAgQIECAwIVAjZeEXgRegPuKAIFuBO7mqrvvIxMp7avGXB6Z
n7YIECBAgAABAqMK2EQZtXLiJkCAAAECBAgECtR4+Vb6QjAwPU0RIEDgD4Gnc9TT4/7oIOGD
0j5qzOEJ4TuUAAECBAgQIDC1gE2UqcsrOQIECBAgQIDAc4EaL+FKXww+j96RBAgQGFPAPDlm
3URNgAABAgQIrCPw4/fD8q910pUpAQIECBAgQIDAE4EaL/Wil51XMUb39cTMMQQIjCVwNYcc
ZVJjXkmNoVVcR/34jAABAgQIECCwqoDfRFm18vImQIAAAQIECFwI1HpZuL0wjHhpeNfG3fcX
qfuKAAECTQQi5qkac3WT5HVCgAABAgQIEBhIwG+iDFQsoRIgQIAAAQIE3hKIeNm3jz335V9q
LLn97OP1MwECcwmkziVb9hHzSU6/R/IRsRy16zMCBAgQIECAAIH/FvCbKEYEAQIECBAgQIDA
rUCNl3VRLxLvgm/Vz10cvidAgEDUfFRjTlYdAgQIECBAgACBYwGbKMcuPiVAgAABAgQIENgJ
1HhpF/VC8a5Yrfq5i8P3BAisKxA1D9WYi9etiswJECBAgAABAvcCNlHujRxBgAABAgQIECDw
j8D28i76BV7Ui8W7Im39fP67O9b3BAgQiBSImuei59/IHLVFgAABAgQIEJhVwCbKrJWVFwEC
BAgQIECgokD0i7yoF4xPU27d39O4HEeAwHwCUfNN9Lw7n7SMCBAgQIAAAQJ1BH7WaVarBAgQ
IECAAAECswtsL/SiXg6+YbXF7qXkG/JlfUaMOXUvq8EsZ480hxmzs4w6eRAgQIAAAQIjCthE
GbFqYiZAgAABAgQIdCIQ+RLyjU2NN/rspHRDhRGxcfKd8FF7XlIPNSSGCfZorKUGb2ymijme
AAECBAgQIBArYBMl1lNrBAgQIECAAIHlBEbfSFmuYAMkHPHiOTXN7z69tE7VG/f4yPlrrxAx
jo3FvaqfCRAgQIAAAQLtBfybKO3N9UiAAAECBAgQmE4g8kXf3YvHyL62Qtz1N12xOk1oq8Pn
v7dD7CWOtx30ny8QMa9Ez3X52TiTAAECBAgQILC2gN9EWbv+sidAgAABAgQIhAl8XvhFvDy8
Cyr6T49vMXtheace/32LsVIS9Xd8xkeJ5FrnRoxr422tMSNbAgQIECBAoG+BH78XZ7/6DlF0
BAgQIECAAAECowqUvEx8skwtaf/I9EmfR+f57FwgukbnPbX9xlhp612zt5Qxelf3lLbOcrrr
4+w8nxMgQIAAAQIECNQR8JsodVy1SoAAAQIECBAgUCjweRl59ULx+7uIl5dbG1f9Faa0zOkR
tegdy1jpvULt44sY9+af9nXTIwECBAgQIEDgTsC/iXIn5HsCBAgQIECAAIFsgYgXgk9fTEb0
tSX6tL9slElP3Nw+/02a4h9prZbvHwA++LdAxLwRNYcpCwECBAgQIECAQKyATZRYT60RIECA
AAECBAjsBCJeDD59QRnR1xb+0/7+f3v3th23rQMAtM7K//+yT9R0TpzxjG4ESZDcD33wSCKB
DTorBSJbsX8LrO5lmLL2d0LE+Y/6s2vtSsieAAECBAgQIFBHwBCljqtVCRAgQIAAAQIEvghE
NAjPNiq3vVrut3KhDQ/+rv7ZM7rymZkt94iaR/x5NZurfAgQIECAAAECmQQMUTJVQywECBAg
QIAAAQK7Ao+m/ZnGZURj8sw+uwFPfJHN6+Jyee0y46cRtY74c2pGWzkRIECAAAECBDIJfPz6
S9tnpoDEQoAAAQIECBAgMK9ARNPxWefor7MRex7t8RzTzF9HeNbweVWjnrG+iqdG3tYsF7hy
Th51vfLMuwidkXcyPidAgAABAgQI5BIwRMlVD9EQIECAAAECBKYXiGg+PiMdNSNL9zxa/zme
Gb8uNaxhcqcuLfO4E18NJ2vuC1w5E1tNr9z/bmdn452MzwkQIECAAAEC+QQMUfLVREQECBAg
QIAAgekFIpqQz0hHTcnSPY/Wf45npq9L7aIsomvQIq/omKMsrfNHoMU5+OrtTDh9BAgQIECA
AIGxBAxRxqqXaAkQIECAAAEC0wjUaFweNScj9jzaY5oC/ZdIhFmJSQvv3jl+9WmRb0k9Zny2
Zf3Vd8YTJCcCBAgQIEBgdgFDlNkrLD8CBAgQIECAQGKB6OblmQZlxJ5n9knMfjq0CKvTm325
sadvr5xHc7oTb9ZnWtW857nOai8uAgQIECBAgMAIAoYoI1RJjAQIECBAgACBiQVqNDCPmpUR
ex7tMXrJIoz2DDL71c59z6XkWmbTkrxqP9uq3upTu5LWJ0CAAAECBAjUEfhRZ1mrEiBAgAAB
AgQIEDgnUKOxeNQUjdjzaI9z2ee8q1Zum/vjv5yZjx1VrbqNrZIj+og/c3JkIgoCBAgQIECA
wHoChijr1VzGBAgQIECAAIF0AjUajBrK98oc7WZwcq8Od5/a6hddw7uxeO63QI0/39gSIECA
AAECBAi0EzBEaWdtJwIECBAgQIAAgR2B1m8oRDQ2Z2tWR+cTYbxzZFzaEXgMU6JrurOlSy8E
fA+8QPERAQIECBAgQGAwgZ+DxStcAgQIECBAgACByQW2pmOrxm/EXlusMzRKI81n8Jjp22yW
MzpaTbJ9Hxx9j2eLd7R6i5cAAQIECBCYV8CbKPPWVmYECBAgQIAAgWEFtmZeq4ZexD5Hzcns
hYiMP8Izu9eI8UXWeMT8V4x5q/nX/44MnJEjIdcJECBAgACBVQUMUVatvLwJECBAgAABAgMI
tBqmRDT+R21ARsXdqlYDHFshDiQQdf6fU474M+V5zbNfPwYnZ+//el8tjzuxeIYAAQIECBAg
kEXAECVLJcRBgAABAgQIECDwVqBFQzJij9EakBHxzjg8iTgLbw9zxwsR9e4Y/jBb9zo/JcOT
YXAFSoAAAQIECBDoIGCI0gHdlgQIECBAgAABAjkFIpqfozSqI+KM8Mp5Ev5p9uPksua/QlwR
3wMZnAxPMlRBDAQIECBAgMDMAn6x/MzVlRsBAgQIECBAYCKBrWF/pel5t8F/dZ+JiC+lctf3
0iadb66Z45WzHMmw7Vszr8hYa67Vy/9uTqPFezdPzxEgQIAAAQIEMgp8/PoL9GfGwMREgAAB
AgQIECBA4JXAmWZixF9xz+zzKr7HZxEx7K1fcm3m3Epcsj5bWq9XeWU+n6/ijfyshufX+CJs
a8e45xkR/976rhEgQIAAAQIERhMwRBmtYuIlQIAAAQIECBBoJlDayMzYjJwxp2YHIslGpTV8
pJHxfNYmjrLbi3PPtcX+e7GdubYX/5nn3UOAAAECBAgQmE3Aj/OaraLyIUCAAAECBAgQCBPY
mokjND3PJlyai+bqWem690Wdy8d5UNe4en21LP1+i4vKSgQIECBAgAABAiUC3kQp0fMsAQIE
CBAgQIDAbYG9BmO2pu5erHsAmfK4m8Mjv0y57Jmvdq20rqvVN8pr1nPm+3zWysqLAAECBAgQ
KBH4UfKwZwkQIECAAAECBAjcEThqZB5dv7NnyTN3G4tZ8iiN427+JeaePScQVZvtjJSek3MR
97tr9vxKZaPOUmkcnidAgAABAgQIZBMwRMlWEfEQIECAAAECBCYXONvIPHtfdq5Z8sjuLL4Y
gccwxbmN8RxhlW14YoAyQqXESIAAAQIECPQS8DtResnblwABAgQIECBA4FBga+S2bO5pHH8v
SUv/77v75IzAVqMaZ7f199+ZXN1TLuB7utzQCgQIECBAgMBaAoYoa9VbtgQIECBAgACB4QSu
NnJrNJOHQ/sScImHZus4la85SNkUnIVxzsK7SNXwnYzPCRAgQIAAAQL7An6x/L6PqwQIECBA
gAABAsECJU3951C+NgUj133eJ+LrHg3MEpMe8UY4r75GSc2P7EY/EzVtjux6Xh+9bj3t7E2A
AAECBAgQ2AS8ieIcECBAgAABAgQIDCuwalP0TMFKbDRdzwjnvGerXUnt97J6ta6zsifW95ra
9PW3OwECBAgQIDCPgCHKPLWUCQECBAgQIECAAIF/BV41u8/SaLyelcp7X81BynPWz2fN+XkW
qvs177q+VidAgAABAgQIbAKGKM4BAQIECBAgQIAAgYkEnpvaE6UmlQsCLQcpX8Pazp/G/oVC
XbyV7UUwtxMgQIAAAQIEAgQMUQIQLUGAAAECBAgQIEAgg4ABSoYq5Imh5yBlU9DwP38WWJ23
cicBAgQIECBAoLWAIUprcfsRIECAAAECBBYX6NXYXZxd+osKfG3Otx6yeSvl9aEzMHnt4lMC
BAgQIECAQFYBQ5SslREXAQIECBAgQGBiAYOU+OJGNMg1d+PrkmnFHt93sw9SfM9kOuFiIUCA
AAECBAjUEfhRZ1mrEiBAgAABAgQIENgXWKn5OEKuI8S4f6JcPSOw1bl1rSMGfGdyO7onMu8e
jkf5uU6AAAECBAgQIFBH4OPXX/4+6yxtVQIECBAgQIAAAQLHAlkarMeR3rujxV+3Sw1bxHhP
z1MtBErPz9kYs5yzknyz5HDW3H0ECBAgQIAAAQLlAoYo5YZWIECAAAECBAgQKBQoaWoWbn3q
8eyN0xK/7LmdKpCbigVKztCVzZ23K1ruJUCAAAECBAgQyCBgiJKhCmIgQIAAAQIECBD4p3YT
d9bm7V23WT18K5UJ3D1PV3Z19q5ouZcAAQIECBAgQKC3gF8s37sC9idAgAABAgQIEPhXYK+x
WtLY3VsXPQECfwts3y8l329nPLf1fV+ekXIPAQIECBAgQIBABgFDlAxVEAMBAgQIECBAgMCu
gIbrLs/lizwvky31wKvzUXuwshSwZAkQIECAAAECBIYSMEQZqlyCJUCAAAECBAgQIPBHQGPb
aWgl8DxYKT173kZpVTn7ECBAgAABAgQIlAr8KF3A8wQIECBAgAABAgQIjCPw3AwfJ3KRZhKI
OEelg5hMHmIhQIAAAQIECBCYV8AQZd7ayowAAQIECBAgQGBiAQ3oiYs7SGrbIKV0mOIcD1Js
YRIgQIAAAQIEFhYwRFm4+FInQIAAAQIECBBYS6C04b2WlmzPCpSeK4OUs9LuI0CAAAECBAgQ
6CFgiNJD3Z4ECBAgQIAAAQIECBCYSMAgZaJiSoUAAQIECBAgQOAvAUMUB4IAAQIECBAgQIAA
AQIEugt4I6V7CQRAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAjMJlD6psBsHvKJF3DG4k2t
SIAAAQIECBAg0F/AEKV/DURAgAABAgQIECBAgACBKQRKByneRpniGEiCAAECBAgQIDCVgCHK
VOWUDAECBAgQIECAAIHvAqWN7e8r+oTAe4HS87YNUgxT3vu6QoAAAQIECBAg0FbAEKWtt90I
ECBAgAABAgQIFAtoMBcTWqCyQOkgZQvPOa9cJMsTIECAAAECBAicEjBEOcXkJgIECBAgQIAA
AQI5BDSWc9RBFMcCBinHRu4gQIAAAQIECBDIL2CIkr9GIiRAgAABAgQIECDwr4ABioMwmoBB
ymgVEy8BAgQIECBAgMCzgCHKs4ivCRAgQIAAAQIECBAgQCCVgAFiqnIIhgABAgQIECCwlIAh
ylLlliwBAgQIECBAgAABAgTaCkS8jbJFbJDStm52I0CAAAECBAgQ+C1giOIkECBAgAABAgQI
ECBAgEBVgahBStUgLU6AAAECBAgQIEDghYAhygsUHxEgQIAAAQIECBDIJnD3X+FrXmer5Lrx
OIvr1l7mBAgQIECAAIGRBQxRRq6e2AkQIECAAAECBAjsCGha7+C41EWg9EzeHSZ2SdamBAgQ
IECAAAECUwgYokxRRkkQIECAAAECBAjMLHCncVzarJ7ZU259BZzNvv52J0CAAAECBAgQuCZg
iHLNy90ECBAgQIAAAQIECBAgUChQMki5M1QsDNfjBAgQIECAAAECCwsYoixcfKkTIECAAAEC
BAgQIECgl8A2SCkZpvSK274ECBAgQIAAAQJrCRiirFVv2RIgQIAAAQIECBAgQIAAAQIECBAg
QIAAAQInBQxRTkK5jQABAgQIECBAgMAoAv51/yiVEicBAgQIECBAgAABAtkFDFGyV0h8BAgQ
IECAAAECBAgQmFjA0G/i4kqNAAECBAgQIDCBgCHKBEWUAgECBAgQIECAAIGHgIa0s0CAAAEC
BAgQIECAAIE4AUOUOEsrESBAgAABAgQIECBAgMANAcO/G2geIUCAAAECBAgQaCJgiNKE2SYE
CBAgQIAAAQIECBAgECXw8fERtZR1CBAgQIAAAQIECOwKGKLs8rhIgAABAgQIECBAoK+AZnFf
f7sTIECAAAECBAgQILC2gCHK2vWXPQECBAgQIECAAAECBAgQIECAAAECBAgQIPBGwBDlDYyP
CRAgQIAAAQIECBAgQIAAAQIECBAgQIAAgbUFDFHWrr/sCRAgQIAAAQIECBAgQIAAAQIECBAg
QIAAgTcChihvYHxMgAABAgQIECBAgAABAnkF/L6gvLURGQECBAgQIEBgJgFDlJmqKRcCBAgQ
IECAAAECBAgMKvD5+Xk5coOUy2QeIECAAAECBAgQuChgiHIRzO0ECBAgQIAAAQIEsgrcaUJn
zUVcBM4KGKSclXIfAQIECBAgQIDAHQFDlDtqniFAgAABAgQIECBAgAABAgQIECBAgAABAgSm
FzBEmb7EEiRAgAABAgQIEBhVwL+wH7Vy4m4t4Ht9CHEEAAAgAElEQVSltbj9CBAgQIAAAQLr
CPxcJ1WZEiBAgAABAgQIEBhHQFN4nFrVjPToHPgRbn/0NyseNU+jtQkQIECAAAECawp4E2XN
usuaAAECBAgQIECAAIHkAkcDlC38M/ckT/Ov8EqHILN5jFQ7sRIgQIAAAQIEZhUwRJm1svIi
QIAAAQIECBAYVkAjeNjShQV+5QxcuTcswIoLGaRUxLU0AQIECBAgQIDAZQE/zusymQcIECBA
gAABAgQI1BOYrSFeT+r9ymcNS5v17yNwpVRgq83ZOpbu5XkCBAgQIECAAAECewLeRNnTcY0A
AQIECBAgQIAAgaEErjTer9w7FIJgDWCcAQIECBAgQIAAgTABQ5QwSgsRIECAAAECBAgQ6Cfg
rYp7vx/EIKXfmbUzAQIECBAgQIAAgREEDFFGqJIYCRAgQIAAAQIElhC429A3QFnieCyXZOm5
vvv9tBy0hAkQIECAAAECBHYFDFF2eVwkQIAAAQIECBAgQIAAgV4CBim95O1LgAABAgQIECDw
EDBEcRYIECBAgAABAgQIDCxQ2mQeOHWhLyLgjC9SaGkSIECAAAECBJIKGKIkLYywCBAgQIAA
AQIECBwJaC4fCY17/Uptr9w7qkhJjn6s16hVFzcBAgQIECBAIIeAIUqOOoiCAAECBAgQIECA
AAECfwmcGRycuWcW1pVynaVm8iBAgAABAgQIzCDwc4Yk5ECAAAECBAgQIEBgdAH/Wn70CtaJ
3+AgxnX7/mIZY2kVAgQIECBAgMBqAt5EWa3i8iVAgAABAgQIEJhCQEM4powcYxxbraJeraTt
Q4AAAQIECBAg8BAwRHEWCBAgQIAAAQIECBCYQuBqg/3q/VMgTZCEuk1QRCkQIECAAAECBAYS
8OO8BiqWUAkQIECAAAECBAgQ2BfYGux7PxpNA37fz1UCBAgQIECAAAECBP4WMERxIggQIECA
AAECBAgQmErAoGSqcr5M5mhY9uohvxfllYrPCBAgQIAAAQIEjgT8OK8jIdcJECBAgAABAgQI
VBbYe3Oi8taWJ0CAAAECBAgQIECAAIEdAUOUHRyXCBAgQIAAAQIECGQU8KZFxqqIqbWA74PW
4vYjQIAAAQIECKwpYIiyZt1lTYAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwIGKIcALlMgAAB
AgQIECBAgAABAgQIECBAgAABAgQIrClgiLJm3WVNgAABAgQIECBAgAABAgQIECBAgAABAgQI
HAgYohwAuUyAAAECBAgQIECgpsDVXyrv90DUrIa1RxPw/TBaxcRLgAABAgQIEBhPwBBlvJqJ
mAABAgQIECBAYBKBqwOUSdKWBgECBAgQIECAAAECBIYRMEQZplQCJUCAAAECBAgQIECAAAEC
BAgQIECAAAECBFoKGKK01LYXAQIECBAgQIAAgf8EvIXiKBAgQIAAAQIECBAgQCC/gCFK/hqJ
kAABAgQIECBAYDIBA5TJCiodAgQIECBAgAABAgSmFTBEmba0EiNAgAABAgQIECBAgMDcAgaS
c9dXdgQIECBAgACBDAKGKBmqIAYCBAgQIECAAAECJwQ+Pz9P3OUWAgQIECBAgAABAgQIEIgS
MESJkrQOAQIECBAgQIAAgYoCBigVcS1NgAABAgQIECBAgACBNwKGKG9gfEyAAAECBAgQIECA
AAECBAgQIECAAAECBAisLWCIsnb9ZU+AAAECBAgQIDCAgLdQBiiSEAkQIECAAAECBAgQmFLA
EGXKskqKAAECBAgQIEBgFgEDlFkqKQ8CBAgQIECAAAECBEYUMEQZsWpiJkCAAAECBAgQIECA
AIFLAgaSl7jcTIAAAQIECBAg8J+AIYqjQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBB4IWCI
8gLFRwQIECBAgAABAgQIECBAgAABAgQIECBAgAABQxRngAABAgQIECBAgAABAgQIECBAgAAB
AgQIECDwQsAQ5QWKjwgQIECAAAECBAgQIECAAAECBAgQIECAAAEChijOAAECBAgQIECAAAEC
BAgMJ/Dx8TFczAImQIAAAQIECBAYT8AQZbyaiZgAAQIECBAgQIAAAQIECBAgQIAAAQIECBBo
IGCI0gDZFgQIECBAgAABAgQIECBAgAABAgQIECBAgMB4AoYo49VMxAQIECBAgAABAgQIECBA
gAABAgQIECBAgEADAUOUBsi2IECAAAECBAgQIECAAAECBAgQIECAAAECBMYTMEQZr2YiJkCA
AAECBAgQIECAAAECBAgQIECAAAECBBoIGKI0QLYFAQIECBAgQIAAAQIECPQT+Pz87Le5nQkQ
IECAAAECBIYWMEQZunyCJ0CAAAECBAgQIECAAAECBAgQIECAAAECBGoJGKLUkrUuAQIECBAg
QIAAAQIECBAgQIAAAQIECBAgMLSAIcrQ5RM8AQIECBAgQIAAAQIECBAgQIAAAQIECBAgUEvA
EKWWrHUJECBAgAABAgQIECBAgAABAgQIECBAgACBoQUMUYYun+AJECBAgAABAgQIECBAgAAB
AgQIECBAgACBWgI/ay1sXQIECBAgQIAAAQIECBBoI/Dx8fF2o8/Pz7fXXCBAgAABAgQIECBA
YF/Amyj7Pq4SIECAAAECBAgQIEAgtcDeAGUL/Oh66uQER4AAAQIECBAgQKCzgCFK5wLYngAB
AgQIECBAgMCegAb4no5rZ8/H2fuIEiBAgAABAgQIECDwt4Af5+VEECBAgAABAgQIECCwlMDe
QGGkH321l8dSBZUsAQIECBAgQIAAgYoC3kSpiGtpAgQIECBAgAABAgRyCRwNHo6uZ8lmlDiz
eImDAAECBAgQIECAwF0BQ5S7cp4jQIAAAQIECBAgQGAogbODh+2+s/f2AMgcWw8PexIgQIAA
AQIECBCoKWCIUlPX2gQIECBAgAABAgQIDCuQcViRMaZhCyxwAgQIECBAgAABAicEDFFOILmF
AAECBAgQIECAAIE1BTINLTLFsuZpkDUBAgQIECBAgMCKAoYoK1ZdzgQIECBAgAABAl0FRvrl
5V2hkmyeYXiRIYYk5RAGAQIECBAgQIAAgaYChihNuW1GgAABAgQIECBA4LqABvp1s+gnthr0
qEPUvgZ30SfCegQIECBAgAABAqsIGKKsUml5EiBAgAABAgQIECBQLNBykBK1lwFKcdktQIAA
AQIECBAgsLCAIcrCxZc6AQIECBAgQIAAAQLXBaKGG3s7R+1hgLKn7BoBAgQIECBAgACBYwFD
lGMjdxAgQIAAAQIECBAgQOAvgaghxzNr1I/vel7X1wQIECBAgAABAgQI3BMwRLnn5ikCBAgQ
IECAAAECBAYTiH4rI3rgET2Yic53sHILlwABAgQIECBAgECIgCFKCKNFCBAgQIAAAQIECBAY
QaDGYCFimGKAMsLpESMBAgQIECBAgMCKAoYoK1ZdzgQIECBAgAABAt0FajTzuyc1SAC17O8O
UwxQBjk4wiRAgAABAgQIEFhS4OeSWUuaAAECBAgQIECAwGACW6O9VvN/MIqQcL9aRg8xntdr
WbeWe4UUwiIECBAgQIAAAQIEkgsYoiQvkPAIECBAgAABAgQIEKgrsA0engcfkTvWXPsRp+FJ
ZMWsRYAAAQIECBAgQOCPgB/n5TQQIECAAAECBAgQILC8wMhDiJFjX/7gASBAgAABAgQIEEgv
YIiSvkQCJECAAAECBAgQIPBboMUbDStbjziMGDHmlc+Y3AkQIECAAAECBMYTMEQZr2YiJkCA
AAECBAgQIECgksAoQ4ktzlFirVQqyxIgQIAAAQIECBBoImCI0oTZJgQIECBAgAABAgS+C9xp
gnsb5btj9Cd36hIdw9562ePbi901AgQIECBAgAABAqMJGKKMVjHxEiBAgAABAgQILC9gkFL/
CGQdVGSNq35F7ECAAAECBAgQIECgj4AhSh93uxIgQIAAAQIECBAgkFzAj8xKXiDhESBAgAAB
AgQIEGggYIjSANkWBAgQIECAAAECBKIFvI0SLfp+vSzDFG+hvK+RKwQIECBAgAABAgRqCRii
1JK1LgECBAgQIECAAIETAhrjJ5CS3NJzmOKcJDkEwiBAgAABAgQIEFhOwBBluZJLmAABAgQI
ECBAgACBEoHWwxQDlJJqeZYAAQIECBAgQIBAmYAhSpmfpwkQIECAAAECBAgUC9xtkvuRXsX0
RQs8hik1hyp3z0ZRYh4mQIAAAQIECBAgQOD/Aj9ZECBAgAABAgQIECDQX2BrlhuK9K9DSQQG
HiV6niVAgAABAgQIECCQU8CbKDnrIioCBAgQIECAAAECBAgQIECAAAECBAgQIECgs4AhSucC
2J4AAQIECBAgQIDAQ8CbDM4CgXMC3to65+QuAgQIECBAgACBcgFDlHJDKxAgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQITChiiTFhUKREgQIAAAQIECBAgQGBWAW+hzFpZeREgQIAAAQIEcgoY
ouSsi6gIECBAgAABAgQWFbj6I700lBc9KNImQIAAAQIECBAgQKCJgCFKE2abECBAgAABAgQI
EKgnYJBSz9bKBAgQIECAAAECBAisLWCIsnb9ZU+AAAECBAgQIDCJgEHKJIWUxq6Ac77L4yIB
AgQIECBAgEAFAUOUCqiWJECAAAECBAgQIECAAIEcAld/RF6OqEVBgAABAgQIECCQRcAQJUsl
xEGAAAECBAgQIECgUMC/0i8E9DgBAgQIECBAgAABAgSeBAxRHAkCBAgQIECAAAECBAgQSC9w
Z0joLZT0ZRUgAQIECBAgQCC9gCFK+hIJkAABAgQIECBAYDUBjd/VKi7fI4E7A5SjNV0nQIAA
AQIECBAgcEbAEOWMknsIECBAgAABAgQINBYwSGkMbru0AgYoaUsjMAIECBAgQIDAEgKGKEuU
WZIECBAgQIAAAQIjCtwZpGg4j1hpMb8TKDnPd75/3sXhcwIECBAgQIAAgXUFDFHWrb3MCRAg
QIAAAQIEJhUoaTxPSiItAgQIECBAgAABAgQI3BIwRLnF5iECBAgQIECAAAECbQT8a/o2znYh
QIAAAQIECBAgQIDAK4Gfrz70GQECBAgQIECAAAECYws83kYxhBm7jqtGX/o2lXO/6smRNwEC
BAgQIEAgXsCbKPGmViRAgAABAgQIECCQRqC0GZ0mEYEsI1B6Zg1QljkqEiVAgAABAgQINBEw
RGnCbBMCBAgQIECAAAEC/QRKm9L9IrfzagKlZ9UAZbUTI18CBAgQIECAQH0BQ5T6xnYgQIAA
AQIECBAgUCQQ0RjemtOlDeqiJDxM4ECg9HxGfJ8chOgyAQIECBAgQIDAggKGKAsWXcoECBAg
QIAAAQLjCUQ1iEsb1ePJiTi7gAFf9gqJjwABAgQIECCwtoAhytr1lz0BAgQIECBAgMCCAgYp
CxY9acrOYtLCCIsAAQIECBAgQOD/AoYoDgMBAgQIECBAgACBQQSi3kbZ0tW8HqToE4cZeQYj
vzcmJpcaAQIECBAgQIDADQFDlBtoHiFAgAABAgQIECDQSyCyWRzZxO7lYd8xBSLPXuT3xJia
oiZAgAABAgQIEKgpYIhSU9faBAgQIECAAAECBCoIRDaNI5vZFVK15GQC0b//JPJ7YTJq6RAg
QIAAAQIECAQJfPz6S+dn0FqWIUCAAAECBAgQIECgoUD0AMT/GjQs3mJbRZ/Vjc95XewQSZcA
AQIECBAg0EnAEKUTvG0JECBAgAABAgQIRAhoTkcoWqOWQI3zucVqgFKrYtYlQIAAAQIECBB4
FjBEeRbxNQECBAgQIECAAIEBBWo0qzWqBzwIiUJ2JhMVQygECBAgQIAAAQK3BQxRbtN5kAAB
AgQIECBAgEAugRpN668ZGqrkqnfmaGqcRecvc8XFRoAAAQIECBCYV8Avlp+3tjIjQIAAAQIE
CBBYTKB2k3lrjNdoji9WpunTrXFGap/t6YsiQQIECBAgQIAAgdsC3kS5TedBAgQIECBAgAAB
AnkFajSyn7PV2H4WWe9r52y9msuYAAECBAgQILCagCHKahWXLwECBAgQIECAwDICLRrcG6Zh
Ss4jVVr/57qWrndV6Xn/q8+7nwABAgQIECBAgECEgCFKhKI1CBAgQIAAAQIECCQV0PhOWpjA
sFrXODD0t0sZoLylcYEAAQIECBAgQKCxgCFKY3DbESBAgAABAgQIEGgt0KPJrgler8o96lkv
m+8rOzvfTXxCgAABAgQIECDQT8AQpZ+9nQkQIECAAAECBAg0E+jZeNcULytzz9qVRX79aWfl
upknCBAgQIAAAQIE6goYotT1tToBAgQIECBAgACBNAIZmvGa5OeOQ4ZanYs05i7nIsbRKgQI
ECBAgAABAvEChijxplYkQIAAAQIECBAgkFogS4Ne4/z3MclSjx6H1hnooW5PAgQIECBAgACB
KwKGKFe03EuAAAECBAgQIEBgIoGMzfsVmuoZ3Vsf6xXq3NrUfgQIECBAgAABAnUEDFHquFqV
AAECBAgQIECAwDACqzb1azXyV/U8e+BruZ/d330ECBAgQIAAAQIErggYolzRci8BAgQIECBA
gACBBQQMARYocqcUDVA6wduWAAECBAgQIEDgtsCP2096kAABAgQIECBAgACBKQW2Rrdm95Sl
7ZqUM9WV3+YECBAgQIAAAQI3BX7efM5jBAgQIECAAAECBAhMLvBoenszZfJCV0jPwKQCqiUJ
ECBAgAABAgS6CBiidGG3KQECBAgQIECAAIFxBAxTxqnVmUifBxylQ7Ln9c7E4B4CBAgQIECA
AAECowj4nSijVEqcBAgQIECAAAECBBIJlDbeE6UybSiGG9OWVmIECBAgQIAAAQINBbyJ0hDb
VgQIECBAgAABAgRmEfB2Sr5KGprkq4mICBAgQIAAAQIExhcwRBm/hjIgQIAAAQIECBAg0E3g
a+Pe2ylty2Bo0tbbbgQIECBAgAABAmsKGKKsWXdZEyBAgAABAgQIEAgXMFAJJ/22oMHJNxIf
ECBAgAABAgQIEKgqYIhSldfiBAgQIECAAAECBNYUMFApr7uBSbmhFQgQIECAAAECBAiUChii
lAp6ngABAgQIECBAgACBXYF3wwA//utvtndOu7guEiBAgAABAgQIECBQVcAQpSqvxQkQIECA
AAECBAgQeCfQcmiQYWDTMt935j4nQIAAAQIECBAgQOCagCHKNS93EyBAgAABAgQIECAwoIAB
xoBFEzIBAgQIECBAgACBBAI/EsQgBAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQl
ERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMVxECAAAECBAgQIECAAAECBAgQIECA
AAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIZBAxRMlRBDAQIECBAgAAB
AgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQIECAAAECBAgQIJBBwBAl
QxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAABAgQIECBAgAABAgQI
ECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDoBQ5R0JREQAQIECBAg
QIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQIECBAgAABAgQIpBMw
RElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAAAQIECBAgQIAA
AQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMVxECAAAEC
BAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIZ
BAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQ
IECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBA
gAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECA
QDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAAB
AgQIECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQI
ECCQQcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUR
EAECBAgQIECAAAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIECKQTMERJVxIBESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAEC
BAgQIECAAAECBAgQIECAQDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVD
FcRAgAABAgQIECBAgAABAgQIECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQ
IECAAAECGQQMUTJUQQwECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBA
gAABAgQIECBAgAABAgQIECCQQcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBE
SVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAAB
AgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIE
CBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAABAgQIECBAgAABAgQIECBAgAABAhkE
DFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDqBn+kiEhABAgQIECBAgACBxQQ+Pj52
M/78/Ny97iIBAgQIECBAgAABAgQI1BHwJkodV6sSIECAAAECBAgQOCVwNEDZFjlzz6nN3ESA
AAECBAgQIECAAAEClwS8iXKJy80ECBAgQIAAAQIE4gSuDEe2e2u8kbIXQ4394vSsRIAAAQIE
CBAgQIAAgfoC3kSpb2wHAgQIECBAgAABAikF9gYoW8BH11MmJSgCBAgQIECAAAECBAgEChii
BGJaigABAgQIECBAgMBZgd4DirP7n73vbN7uI0CAAAECBAgQIECAwEgChigjVUusBAgQIECA
AAECBAgQIECAAAECBAgQIECAQDMBQ5Rm1DYiQIAAAQIECBAgQIAAAQIECBAgQIAAAQIERhIw
RBmpWmIlQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEmgkYojSjthEBAgQIECBAgACB3wJ+z4iT
QIAAAQIECBAgQIAAgTEEDFHGqJMoCRAgQIAAAQIEJhG4O0D5/PycREAaBAgQIECAAAECBAgQ
GEfAEGWcWomUAAECBAgQIEBgUQEDlEULL20CBAgQIECAAAECBLoLGKJ0L4EACBAgQIAAAQIE
VhG4+xZKb59R4+7tZn8CBAgQIECAAAECBMYXMEQZv4YyIECAAAECBAgQIFBdwCClOrENCBAg
QIAAAQIECBBIKGCIkrAoQiJAgAABAgQIECBAgAABAgQIECBAgAABAgT6Cxii9K+BCAgQIECA
AAECBAi8Fcj0+1C8jfK2TC4QIECAAAECBAgQIDCpgCHKpIWVFgECBAgQIECAwPgCmQYo42vK
gAABAgQIECBAgAABAtcFfl5/xBMECBAgQIAAAQIECKwqsL2Ncme4k+Utljuxr1preRMgQIAA
AQIECBAg8M8/3kRxCggQIECAAAECBAgkFKjd7K+9/lfSLAOULaZMsSQ8dkIiQIAAAQIECBAg
QOBJwJsojgQBAgQIECBAgACBRQW2QUrtoULt9e+U7u7bNHf28sxrgZJzcebcthwSvs7QpwQI
ECBAgAABArMIGKLMUkl5ECBAgAABAgQIEEgmUNIoT5bKt3Ba5TbTMCDK7Mw6BmXfjqwPCBAg
QIAAAQIEbgr4cV434TxGgAABAgQIECBAYAaBWk36M43uEf22vFrm1nKvmvXokUePPWsaWpsA
AQIECBAgQKCPgCFKH3e7EiBAgAABAgQIEJhWYMbmdevhydfDMbrn6PFP+40qMQIECBAgQIAA
gVMCfpzXKSY3ESBAgAABAgQIEJhX4MzvmJg3+/eZZWr+b7HUemvovcC9K5nc7mXgKQIECBAg
QIAAAQJ/BLyJ4jQQIECAAAECBAgQIEDgSSDjICBjTM8HZ4QYn2P2NQECBAgQIECAAIE9AUOU
PR3XCBAgQIAAAQIECBBYTiDzIEBsyx1HCRMgQIAAAQIECHQWMETpXADbEyBAgAABAgQIECDQ
VmDvx2JlHlK0Vbq2G7drXu4mQIAAAQIECBAYR8DvRBmnViIlQIAAAQIECBAgUEVgpQa4Acqf
I3Sm7nte20pn1qhyaC1KgAABAgQIECBAoJGAIUojaNsQIECAAAECBAgQIHAscNS0P17h3h2r
DQPO5rvd964mZ9e4V5Hyp97FXb6yFQgQIECAAAECBFYSMERZqdpyJUCAAAECBAgQIPAkkK0R
/jUeTfA6x/VqzZ8HKVefr5PF/qrOzr6Pq0jXF6AAAA3PSURBVAQIECBAgAABAucFDFHOW7mT
AAECBAgQIECAwDQCIzTCj2KMapQf7TNN0QMSqW31taZ39oo6EwFUliBAgAABAgQIEJhEwBBl
kkJKgwABAgQIECBAgMCRwJ2m9NGaPa9/zSdL8/xsHKPVoma878zefd7zzNmbAAECBAgQIEBg
PYEf66UsYwIECBAgQIAAAQLrCdRsgmfQ7J3f1vDX9L9+EphdN/MEAQIECBAgQIBAWwFDlLbe
diNAgAABAgQIECBwSiByKBC5Vuamd2Sep4r066Y7w5MecZ7Np+V9mc9SSwd7ESBAgAABAgQI
5Bbw47xy10d0BAgQIECAAAECBIoEVmvYb/nWbs7XXr+o4MkfZpe8QMIjQIAAAQIECBD4JmCI
8o3EBwQIECBAgAABAgTGF6gxPNEA738uRq7ByLH3r7wICBAgQIAAAQIEegn4cV695O1LgAAB
AgQIECBAoJJA7wFK72Z5jfwfpSrNrSS20r0rHbdTy44c+6kE3USAAAECBAgQIDCtgCHKtKWV
GAECBAgQIECAwIoCJU36d153GuB3nnm3/53PazjciSPqmd6eJXmMHHtJ3p4lQIAAAQIECBCY
Q8CP85qjjrIgQIAAAQIECBCYUODq7/eoMTgoaYB/fbZGbEclv+p3tN7d66W5l9TgVczbeqUx
vVr362fRMR/t5zoBAgQIECBAgACBWgKGKLVkrUuAAAECBAgQIEDgSaBm87pGUzyyEf68Vo14
Wxy4d3E/5/eI5d39Z2N9t+7Z59/dV/MsvtvT5wQIECBAgAABAgRGFDBEGbFqYiZAgAABAgQI
EFhG4MzbFKWN+leYtZr3j72+rl8j/lc51fzskcMjrxFyqhVr7bNTs47WJkCAAAECBAgQIPAs
YIjyLOJrAgQIECBAgAABAskE9gYp0c36Hg3woz2jc6xZ3pFirelgbQIECBAgQIAAAQKzCPjF
8rNUUh4ECBAgQIAAAQJTC7xqzr/67A7CNsR4/Hfn+drPZI6tZu5Hw6WovVvtExWvdQgQIECA
AAECBAi0FDBEaaltLwIECBAgQIAAAQIFAl+HJpEDlIKQPDqJgEHKJIWUBgECBAgQIECAQLiA
IUo4qQUJECBAgAABAgQIvBcobVZvw5MVByhROb+vTK4rpeckVzaiIUCAAAECBAgQIDCugCHK
uLUTOQECBAgQIECAAIHbApr0t+mqP9irNr32rQ5qAwIECBAgQIAAAQIFAoYoBXgeJUCAAAEC
BAgQIHBHoGezetu75/53vGo/k8kjUyy13a1PgAABAgQIECBAYAQBQ5QRqiRGAgQIECBAgACB
6QR6NMt77BlRuBY/yiuDjRgiTos1CBAgQIAAAQIECMQKGKLEelqNAAECBAgQIECAwGmBlk3z
lnudBjhxY8kAZaScR4r1RNncQoAAAQIECBAgQGAagZ/TZCIRAgQIECBAgAABAgReCozaoJ99
gJK1LltcJfYvD6EPCRAgQIAAAQIECAwq4E2UQQsnbAIECBAgQIAAgTkEajfSa69fqwolTfy7
Od997o5By71mjO9OTp4hQIAAAQIECBAgcEfAEOWOmmcIECBAgAABAgQIBArUaqjXWjcw9ZdL
lQxQXi544cPaZtv6tfe4kO7uraPEuZuEiwQIECBAgAABAgQKBfw4r0JAjxMgQIAAAQIECBCI
ENga1pHDAw3w+1WJqAX/+/6eJECAAAECBAgQIJBJwBAlUzXEQoAAAQIECBAgsLRARPN+A2zd
wN8b/rSOJWq/qFrUOtCZzGvlaF0CBAgQIECAAAECGQQ+fv3PwWeGQMRAgAABAgQIECBAgMA/
xW+jtP7r/V4z/1HPo5jOrHHmbBztc2aN53tKY+sVU9S+d/OP2v+5Hr4mQIAAAQIECBAg0FrA
70RpLW4/AgQIECBAgAABAjsCJc3nkmd3Qnp76WyD/fm+7euv/73d4MKFWrmXrvuc+4WUXt56
dr2z973cxIcECBAgQIAAAQIECPxfwBDFYSBAgAABAgQIECCQTOBO4/7OM63TfgxOWu/be7+R
8757rgxxep86+xMgQIAAAQIECEQJGKJESVqHAAECBAgQIECAQKDAleb1lXsDQ7y0VM2meu38
o9avaXCpGBdvjsr/4rZuJ0CAAAECBAgQIJBCwC+WT1EGQRAgQIAAAQIECBD4LqB5/d3k+ZNW
Rts+EUOQxxp34o7Y/9nP1wQIECBAgAABAgQI7At4E2Xfx1UCBAgQIECAAAECBAiEC1wZiIz8
48DC4SxIgAABAgQIECBAoLGAN1Eag9uOAAECBAgQIECAAIEYgTtvc5TsHPU2yiOGK4OUkrg9
S4AAAQIECBAgQIDAfQFvoty38yQBAgQIECBAgAABAp0EWg9QHmn22rcTs20JECBAgAABAgQI
LC9giLL8EQBAgAABAgQIECBAYCyB3oOM3vv3qNaKOfdwticBAgQIECBAgEA+AUOUfDUREQEC
BAgQIECAAAECbwSyNPOzxPGGqcrHV3K+cm+VYC1KgAABAgQIECBAIEjAECUI0jIECBAgQIAA
AQIECNQVyNaYzxZPXf3fq5/J+cw9LWK1BwECBAgQIECAAIEIgY9ff8H9jFjIGgQIECBAgAAB
AgQIrCdQ85ejj/S/KjUd7pyqkezu5OcZAgQIECBAgAABAq0EDFFaSduHAAECBAgQIECAwKQC
UQOE0Rv/UQ6lx2R0x9L8PU+AAAECBAgQIEAgUsAQJVLTWgQIECBAgAABAgQWFrg7RJip6X/X
IOrYzGQZZWIdAgQIECBAgAABAiUChiglep4lQIAAAQIECBAgQOAvgStDhFkb/lcMoo7PrJZR
PtYhQIAAAQIECBAgcFfAEOWunOcIECBAgAABAgQIECBwINBioGKAclAElwkQIECAAAECBAgU
CPwoeNajBAgQIECAAAECBAgQILAjUHPAsa1dc/2dtFwiQIAAAQIECBAgsIzAz2UylSgBAgQI
ECBAgAABAgQ6CBh0dEC3JQECBAgQIECAAIEgAW+iBEFahgABAgQIECBAgAABAgQIECBAgAAB
AgQIEJhLwBBlrnrKhgABAgQIECBAgAABAgQIECBAgAABAgQIEAgSMEQJgrQMAQIECBAgQIAA
AQIECBAgQIAAAQIECBAgMJeAIcpc9ZQNAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECRgiBIE
aRkCBAgQIECAAAECBAgQIECAAAECBAgQIEBgLgFDlLnqKRsCBAgQIECAAAECBAgQIECAAAEC
BAgQIEAgSMAQJQjSMgQIECBAgAABAgQIECBAgAABAgQIECBAgMBcAoYoc9VTNgQIECBAgAAB
AgQIECBAgAABAgQIECBAgECQgCFKEKRlCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgbkEDFHm
qqdsCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgSABQ5QgSMsQIECAAAECBAgQIECAAAECBAgQ
IECAAAECcwkYosxVT9kQIECAAAECBAgQIECAAAECBAgQIECAAAECQQKGKEGQliFAgAABAgQI
ECBAgAABAgQIECBAgAABAgTmEjBEmauesiFAgAABAgQIECBAgAABAgQIECBAgAABAgSCBAxR
giAtQ4AAAQIECBAgQIAAAQIECBAgQIAAAQIECMwlYIgyVz1lQ4AAAQIECBAgQIAAAQIECBAg
QIAAAQIECAQJGKIEQVqGAAECBAgQIECAAAECBAgQIECAAAECBAgQmEvAEGWuesqGAAECBAgQ
IECAAAECBAgQIECAAAECBAgQCBIwRAmCtAwBAgQIECBAgAABAgQIECBAgAABAgQIECAwl4Ah
ylz1lA0BAgQIECBAgAABAgQIECBAgAABAgQIECAQJGCIEgRpGQIECBAgQIAAAQIECBAgQIAA
AQIECBAgQGAuAUOUueopGwIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBIwBAlCNIyBAgQIECA
AAECBAgQIECAAAECBAgQIECAwFwChihz1VM2BAgQIECAAAECBAgQIECAAAECBAgQIECAQJCA
IUoQpGUIECBAgAABAgQIECBAgAABAgQIECBAgACBuQQMUeaqp2wIECBAgAABAgQIECBAgAAB
AgQIECBAgACBIAFDlCBIyxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCRiizFVP2RAgQIAA
AQIECBAgQIAAAQIECBAgQIAAAQJBAoYoQZCWIUCAAAECBAgQIECAAAECBAgQIECAAAECBOYS
MESZq56yIUCAAAECBAgQIECAAAECBAgQIECAAAECBIIEDFGCIC1DgAABAgQIECBAgAABAgQI
ECBAgAABAgQIzCVgiDJXPWVDgAABAgQIECBAgAABAgQIECBAgAABAgQIBAkYogRBWoYAAQIE
CBAgQIAAAQIECBAgQIAAAQIECBCYS8AQZa56yoYAAQIECBAgQIAAAQIECBAgQIAAAQIECBAI
EjBECYK0DAECBAgQIECAAAECBAgQIECAAAECBAgQIDCXgCHKXPWUDQECBAgQIECAAAECBAgQ
IECAAAECBAgQIBAkYIgSBGkZAgQIECBAgAABAgQIECBAgAABAgQIECBAYC4BQ5S56ikbAgQI
ECBAgAABAgQIECBAgAABAgQIECBAIEjAECUI0jIECBAgQIAAAQIECBAgQIAAAQIECBAgQIDA
XAL/A42ghxLmmMjjAAAAAElFTkSuQmCC

--aae1533ae5b7498f93fc092776b88c7d--

--8fee5ed3ff744ba3a90a56c03f03a7d4--


From nobody Wed Feb 24 18:11:00 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7683A0C7D for ; Wed, 24 Feb 2021 18:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tWQzLCFjdpn for ; Wed, 24 Feb 2021 18:10:52 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7B53A0C6D for ; Wed, 24 Feb 2021 18:10:52 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id w36so6197059lfu.4 for ; Wed, 24 Feb 2021 18:10:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=48YcDm9c/I0Gs87VMmNMcSN0unJHvvNeyXB+nXJk8TY=; b=buEq94Kp/+1bWD5QZGMN0HfoyKu2Dhtug4cR1p0F8ZeXWAfvPefj/9PjjzJqC1hz/C ULprzXUCEOjrBf9hzcARoZ4roUC9c5cyXju0VDmXCQOxtMVGNN3hcQpyYalaUoyx6px7 s83AZNSiAVKtIbxuZxoXsFdqCPHZLJBN+vQ6fKEANVbZtISN209GLylEEuT4c+mJXFpy JB6gQasK9fvS7cA7MD+IoQBQonkkx2d2H/WznAhCTfSzrGTjq9WW8haRdzqNjK6rflhQ GZji4m0ePgw5DfVj+Rsc+VR0w4+s9nsJ7gXVnlkXe+ijbwvBKeFJp9p/HlXjqjgiJp6u FjIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=48YcDm9c/I0Gs87VMmNMcSN0unJHvvNeyXB+nXJk8TY=; b=QdPWErGGVe/QnGNOJKzXC1Ns2J2MUSrLmmlAOOIP3uLFNf2hPBYEm4sC2m1013W6GT kUSH54DpQkICbwkl3IjGfvE7gV7D7jOJX3Hv6sC3L57/7Maj5rxfcit130Z7KnHxDVTq fOFlY2euUvwzd0pne6KzOpFVJQru02Q2ij+3nfmd0MOiX44qcC5ep5ynN+5CZXhEi9Rk fNo7Q6Un2ZMtjESGQ2ouwf5OCqstsyR55XQ9Q2ZpxlOPb22ZZdXNwDtyL8anpzEg0Q+d L53snCim9e3xhbchCuBZlnpcz+hLgB0S8vqlsP0ZhzFC4ZCDfsDzmdgee0ov+RuKRNdu vt8A==
X-Gm-Message-State: AOAM530INcFaR0Eh7nRLBispC9C1UbFiZc9Mm3ZiQpqlL7HmFrcHPuWZ f0rMFXWX15M5mlnapUOPFhZikHlCpAp3t+p6bmlLUA==
X-Google-Smtp-Source: ABdhPJz5kgxz0lVvkNg/TN+lKBGTnghmLz0AgCUVWLqBqV3vWnnMM028RvxI7Vivr9/uLz7wl38thPnFLPh2H/rykl4=
X-Received: by 2002:a05:6512:38ce:: with SMTP id p14mr533458lft.428.1614219050457;  Wed, 24 Feb 2021 18:10:50 -0800 (PST)
MIME-Version: 1.0
References: <161272369978.20616.15063633580755015902@ietfa.amsl.com> 
In-Reply-To: 
From: Joseph Salowey 
Date: Wed, 24 Feb 2021 18:10:39 -0800
Message-ID: 
To: Vittorio Bertocci 
Cc: "secdir@ietf.org" ,  "draft-ietf-oauth-access-token-jwt.all@ietf.org" ,  "last-call@ietf.org" , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000017aaba05bc1fa905"
Archived-At: 
Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2021 02:10:54 -0000

--00000000000017aaba05bc1fa905
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 20, 2021 at 12:42 AM Vittorio Bertocci <
vittorio.bertocci@auth0.com> wrote:

> Thank you Joseph for your comments!
>
>
[Joe] Thanks for your response, comments inline below:


> > 1.  (Editorial) What is the relationship between this document and RFC
> 7523.
> >   They are using JWT for different purposes, but I think it would be
> useful to
> >    clarify this in the introduction.
> Good point, I agree it would be good to preempt doubts on this. I am
> suggesting to append the following language to the current introduction
> (pardon the XML).
>
> Please note: although both this document and  b=
oth
> use JSON Web Tokens in the context of the OAuth2 framework, the two
> specifications differ in both intent and mechanics. Whereas  RFC7523"/> defines how a JWT Bearer Token can be used to request an acces=
s
> token, this documents describes how to encode access tokens in JWT format=
.
>
>
[Joe] Yes, that looks good to me.


> >    2.  (Issue) The specification does not specify any mandatory to
> implement for
> >    the recommended asymmetric algorithms.  This will not help interop.
> Perhaps
> >    specify one or both of  "RS256" and "ES256".
> The current text doesn=E2=80=99t mandate a format for two main reasons:
> - thanks to the AS metadata the negotiation between a RS and an AS is ver=
y
> easy to perform, hence the likelihood of interop issues at runtime is ver=
y
> low
> - worries that as crypto advances, what we mandate at this point might no
> longer be suitable.
> That said, if you feel strongly about this please do let me know, and I
> will be OK with adding RS256 as a mandatory supported alg for both AS and
> RS.
> From a cursory check, ES256 doesn=E2=80=99t seem to enjoy as widespread s=
upport at
> the moment (see https://jwt.io/ libraries list) hence I would be hesitant
> to make it mandatory.
>
>
[Joe] I think you should add RS256 as mandatory to implement.  Since RFC
7518 does not mandate an asymmetric algorithm it's possible that two
implementations make different choices on which one to support.


> >    3. (Question) Is it currently possible to use the JWT access token i=
n
> a mode
> >    other than a bearer token?  For example is there a way to bind the
> JWT to a
> >    verifiable key or identifier.  If there is, there should be some
> discussion of
> >    this in the security considerations.  If not, do the authors know if
> there is
> >    any work planned in this area?
> At this time, the main mechanisms that can work with non-bearer ATs are
> dPOP and MTLS. In both cases, the binding mechanism relies on a cnf claim
> (or reference to it) - which can be added to a JWT access token without
> changing any of the guidance in this specification. There's a quick prime=
r
> for both approaches in
> https://auth0.com/blog/identity-unlocked-explained-episode-1/. Given that
> there are no changes in the AT format and verification, and MTLS/DPOP wou=
ld
> be purely additive, any language here would likely be functionally
> equivalent to "You should be aware that MTLS exists, and the tokens defin=
ed
> here do not break it" (DPOP isn=E2=80=99t mentioned because it's still in=
 progress)
> but my intuition is that the compatibility should be assumed, with a note
> being required when it's not the case and the reader should be aware of
> potential problems. What do you think?
>
>
[Joe] Thanks for the explanation. I don't think there needs to be anything
added to the document for this.

--00000000000017aaba05bc1fa905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sat, Feb 20, 2021 at 12:42 AM Vitt=
orio Bertocci <vittorio.b=
ertocci@auth0.com> wrote:
Thank you Joseph for your comments!



=

[Joe] Thanks for your=C2=A0respons=
e, comments inline below:
=C2=A0
> 1.=C2=
=A0 (Editorial) What is the relationship between this document and RFC 7523=
.
>=C2=A0 =C2=A0They are using JWT for different purposes, but I thin=
k it would be useful to
>=C2=A0 =C2=A0 clarify this in the introducti=
on.
Good point, I agree it would be good to preempt doubts on this. I am=
 suggesting to append the following language to the current introduction (p=
ardon the XML).

Please note: although both this document and <xre=
f target=3D"RFC7523"/> both use JSON Web Tokens in the context=
 of the OAuth2 framework, the two specifications differ in both intent and =
mechanics. Whereas <xref target=3D" RFC7523"/> defines how =
a JWT Bearer Token can be used to request an access token, this documents d=
escribes how to encode access tokens in JWT format.


[Joe] Yes, that looks good to me.=C2=A0
=C2=A0
>=C2=A0 =C2=A0 2.=C2=A0 (Issue) =
The specification does not specify any mandatory to implement for
>=
=C2=A0 =C2=A0 the recommended asymmetric algorithms.=C2=A0 This will not he=
lp interop.=C2=A0 Perhaps
>=C2=A0 =C2=A0 specify one or both of=C2=A0=
 "RS256" and "ES256".
The current text doesn=E2=80=
=99t mandate a format for two main reasons:
- thanks to the AS metadata =
the negotiation between a RS and an AS is very easy to perform, hence the l=
ikelihood of interop issues at runtime is very low
- worries that as cry=
pto advances, what we mandate at this point might no longer be suitable.That said, if you feel strongly about this please do let me know, and I wi=
ll be OK with adding RS256 as a mandatory supported alg for both AS and RS.=

From a cursory check, ES256 doesn=E2=80=99t seem to enjoy as widespread=
 support at the moment (see=C2=A0https://jwt.io/=C2=A0libraries list) hence I wou=
ld be hesitant to make it mandatory.


[Joe] I think you should add RS256 as mandatory to implement.=C2=
=A0 Since RFC 7518 does not mandate an asymmetric algorithm it's possib=
le that two implementations make different choices on which one to support.=
=C2=A0=C2=A0
=C2=A0
>=C2=A0 =
=C2=A0 3. (Question) Is it currently possible to use the JWT access token i=
n a mode
>=C2=A0 =C2=A0 other than a bearer token?=C2=A0 For example =
is there a way to bind the JWT to a
>=C2=A0 =C2=A0 verifiable key or =
identifier.=C2=A0 If there is, there should be some discussion of
>=
=C2=A0 =C2=A0 this in the security considerations.=C2=A0 If not, do the aut=
hors know if there is
>=C2=A0 =C2=A0 any work planned in this area?At this time, the main mechanisms that can work with non-bearer ATs are d=
POP and MTLS. In both cases, the binding mechanism relies on a cnf claim (o=
r reference to it) - which can be added to a JWT access token without chang=
ing any of the guidance in this specification. There's a quick primer f=
or both approaches in=C2=A0https://auth=
0.com/blog/identity-unlocked-explained-episode-1/. Given that there are=
 no changes in the AT format and verification, and MTLS/DPOP would be purel=
y additive, any language here would likely be functionally equivalent to &q=
uot;You should be aware that MTLS exists, and the tokens defined here do no=
t break it" (DPOP isn=E2=80=99t mentioned because it's still in pr=
ogress) but my intuition is that the compatibility should be assumed, with =
a note being required when it's not the case and the reader should be a=
ware of potential problems. What do you think?=C2=A0


[Joe] Thanks for the explanation. I don't thin=
k there needs to be anything added to the document for this.=C2=A0=C2=A0

=C2=A0


--00000000000017aaba05bc1fa905--


From nobody Thu Feb 25 00:22:46 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C1D3A15C3 for ; Thu, 25 Feb 2021 00:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=trustap-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cEJGlHN1nqb for ; Thu, 25 Feb 2021 00:22:35 -0800 (PST)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172C13A15C2 for ; Thu, 25 Feb 2021 00:22:33 -0800 (PST)
Received: by mail-ej1-x629.google.com with SMTP id k13so7333829ejs.10 for ; Thu, 25 Feb 2021 00:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustap-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZEOOgJxmdrNZXf/vUxKtEyqjCS868VSl/V8BNRYAGY=; b=pGVfOuAS/KwiDTEtJVZDUuk9DbiHP7Qga4Kqey2ZWwyd9ylqPTH3K9pZStWRKDaNLC 8njTN2sq7XhTxAKNxtaJKtgcHP+fRPMnbA3Apq6gFKCO39a3BIfPuIz3RHp0lREuNs4u ZP9Bro4sOOw+l0zmG3okCD0D6U/pFg5bySa7z8dQls+HSvW+xL2/8+J0gfz+2NOjAOjX ZPxgKqLnXAAkfQwvXNfYwN/Ze21tm+bqq2ZTLsnnTQqi8OxRpSQ8Srs7SjoSSmvn2C6q kK/8mGSNx/cF0zuwov9Du98DE23m5+vcO0V5Y+vqiElhf510aLONrbDfOoVQdBgTFh4K qibw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZEOOgJxmdrNZXf/vUxKtEyqjCS868VSl/V8BNRYAGY=; b=TVZ8VYADQNUbH0xPwGY96Z0J8UNZKLidgTumJXhIMO0pA0OOmVxi7Yb7vIrncoejcD 8KARV6+fnSWxnDG+9a441Rfn3rCMNvJvkl2nj3pnB9mnDnH1szdpzky5o2pSdcE1HYLA ZJNOUVG1zefi83LkrTBn9+KUuP4cWUys3Q/v8a4erqJXqbtTZZQD34HqSiDdZKOOq/H7 QfYO4y8KGiWEShIjEF4FdYy7PECuWGH/Q7PgknyHVeKvmH8q+2074SgayPISNw8v0P1J 6IeDnoopcDOSC0+8BrDubZATvDjMHUngGxllrQbKFgMDU2essXuwxrQJgJrbQn5kuohj YHag==
X-Gm-Message-State: AOAM532FBRW9MEN2vNVXsCIJb25lXbHYVAZOs54JTnlp78nFeJcyEIRM gD9a/gFCudIGychNFsuEAzHgHWkyiT9CTIuY+FzfuA==
X-Google-Smtp-Source: ABdhPJwBuP6bQYMVmHDpLTfXaXGDLoLTy1Vd54xb77Knqt0TeVe/OaBpMvm9Kfg91K08eMopSDWtlf809LcrNToILJE=
X-Received: by 2002:a17:906:644f:: with SMTP id l15mr1631070ejn.229.1614241350959;  Thu, 25 Feb 2021 00:22:30 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>
In-Reply-To: <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>
From: =?UTF-8?Q?Se=C3=A1n_Kelleher?= 
Date: Thu, 25 Feb 2021 08:22:20 +0000
Message-ID: 
To: Bron Gondwana 
Cc: Justin Richer , Phillip Hallam-Baker ,  "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/related; boundary="0000000000004e772305bc24da13"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2021 08:22:45 -0000

--0000000000004e772305bc24da13
Content-Type: multipart/alternative; boundary="0000000000004e772205bc24da12"

--0000000000004e772205bc24da12
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just to clarify, I assume in this discourse that the "server" in this
client and server relationship refers to an AS/RS pair in OAuth
terminology? Based on this, one big sticking point for me on the
applicability of NxM, or even 1xM, is that all of the "M" RSs need to
publish the same interface for any meaningful implementation in the first
place.

It probably makes more sense with email clients, since as Bron said, there
is the common standard of POP. If we assume that all the email services
that we want to connect to publish the same POP interface, and would accept
tokens in the same way, then the way the authZ is handled is indeed the
point of divergence that needs to be resolved.

However, we're talking about NxM in the general case here. I feel like
using the likes of discovery and dynamic registration, etc. that's already
supported by OAuth, the "N" part of this equation is surmountable. But each
of the "M" servers also need to export the same interface, otherwise a
client is going to have to write custom code to deal with talking to the
service after the authZ step anyway, reintroducing the "problem" part of
the NxM problem.

As such, I would actually suggest constraining this discussion to just the
POP NxM problem rather than NxM in general because, for me at least, the
authZ part of the general case is the most "solved" part of the problem,
and the outstanding work lies more in consolidating the "M" RS interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana  wrote:

> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>
> I agree that the NxM problem is the purview of the whole IETF, but it=E2=
=80=99s
> something that we=E2=80=99re particularly interested in over in GNAP. As =
the editor
> of OAuth=E2=80=99s dynamic registration extension and the GNAP core proto=
col, I
> hope I can add to this conversation.
>
> From a technical standpoint, OAuth=E2=80=99s dynamic client registration =
lets
> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in pra=
ctice. On
> top of that I think this problem is exacerbated by a fundamental protocol
> design element of OAuth: the client_id that=E2=80=99s required. That fiel=
d means
> there=E2=80=99s an assumption that a relationship was set up between the =
pieces of
> software, implied to be trusted by admins at the AS. Sure you can get tha=
t
> client_id under special circumstances, but there=E2=80=99s still a specia=
l weight
> handed to that and the dynamic stuff feels like you=E2=80=99re giving up =
control as
> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed a=
s
> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an opt=
imization on top
> of that.
>
>
> Yep, this is the big point - OAuth is designed to require the the third
> leg of trust that creates the NxM problem.
>
>
>
> If that dotted line between client and server requires a pre-existing
> trust relationship rather than the trust being entirely mediated by the
> user choosing to connect client A with server B, then you have the NxM
> problem.  This is the "you can only have your John Deere tractor serviced
> by an approved John Deere service centre" problem.  You can only use this
> client with servers who have pre-approved it.  Or fall back to the "cash =
of
> the internet" - plain text passwords.
>
> Does this solve the NxM problem? No, because companies are still going to
> decide that they only talk to keys or identifiers that they know ahead of
> time. But the protocol puts the dynamic case forward as baseline and fits
> in much better with the likes of JMAP than OAuth ever could:
>
> - {The Bat} creates a key pair.
> - {User} enters their email address into {Bat}, {Bat} does discovery
> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP server=
 and the
> GNAP endpoint for authentication as an option.
> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
> up. {ISP} has never seen this key, but knows how to talk GNAP and get the
> user to authorize {Bat} to access email.
> - {User} does this using GNAP and gets back an access token that=E2=80=99=
s tied to
> the key {Bat} made back at the beginning. That token is tied (at the {ISP=
})
> to the user=E2=80=99s account.
>
> Yes, you can do all of this today with OAuth (and people have done so),
> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registrat=
ion first and THEN
> talk to me=E2=80=9D is a trust impediment more than it is a technical imp=
ediment.
> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the ph=
ilosophy of =E2=80=9Cstart
> talking first and figure out what you need as you go=E2=80=9D. Instead of=
 jumping
> through hoops to get something you can trust, you just start in and then
> decide how much you trust it. A corporate rollout could use its own key
> distribution mechanism and static registration to limit which client
> instances talk back to the company server, regardless of which accounts
> would authorize access on top of that. An internet-facing service is goin=
g
> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk t=
o you in a secure
> fashion without caring who you are right now=E2=80=9D.
>
> We really are trying to make GNAP a consistent protocol at its core and
> learn from problems with OAuth in the wild, all while letting GNAP addres=
s
> a wider variety of use cases. I agree that GNAP could be clearer about
> specific use cases, and we=E2=80=99re working on the spec still so any he=
lp here is
> appreciated.
>
>
> Excellent.  This is precisely what I've been waiting for for these very
> many years as a viable replacement for storing a password locally on disk=
.
> Just having the server able to distinguish between different client
> instances for the same user is a big start, because you can de-authorise
> one without having to lock out every connection - even if the user is sti=
ll
> entering their password during the setup phase each time.
>
> This is what Fastmail already do with our own app, creating a long-lived
> access token and storing that on the device rather than storing the
> password itself - and you can log out any one client from your security
> settings page.  What's missing is a standard way to do that with any IMAP
> client.  The initial JMAP authentication proposal was a very simple case =
of
> pretty much this, build into to the protocol so everyone would do it.
>
> Making it easy to connect up arbitrary clients with per-client tokens the
> default, and easy rather than almost impossible to do in practice is wher=
e
> the big difference comes in.
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000004e772205bc24da12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Just to clarify, I assume in this discourse that the =
"server" in this client and server relationship refers to an AS/R=
S pair in OAuth terminology? Based on this, one big sticking=C2=A0point for=
 me on the applicability of NxM, or even 1xM, is that all of the "M&qu=
ot; RSs need to publish the same interface for any meaningful implementatio=
n in the first place.

It probably makes more sense=
 with email clients, since as Bron said, there is the common standard of PO=
P. If we assume that all the email services that we want to connect to publ=
ish the same POP interface, and would accept tokens in the same way, then t=
he way the authZ is handled is indeed the point of divergence that needs to=
 be resolved.

However, we're talking about NxM=
 in the general=C2=A0case here. I feel like using the likes of discovery an=
d dynamic registration, etc. that's already supported by OAuth, the &qu=
ot;N" part of this=C2=A0equation=C2=A0is surmountable. But each of the=
 "M" servers also need to export the same interface, otherwise a =
client is going to have to write custom code to deal with talking to the se=
rvice after the authZ step anyway, reintroducing the "problem" pa=
rt of the NxM problem.

As such, I would actually s=
uggest constraining this discussion to just the POP NxM problem rather than=
 NxM in general because, for me at least, the authZ part of the general cas=
e is the most "solved" part of the problem, and the outstanding w=
ork lies more in consolidating the "M" RS interfaces.
=

On Wed=
, 24 Feb 2021 at 22:32, Bron Gondwana <brong@fastmailteam.com> wrote:
On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
I agree that the =
NxM problem is the purview of the whole IETF, but it=E2=80=99s something th=
at we=E2=80=99re particularly interested in over in GNAP. As the editor of =
OAuth=E2=80=99s dynamic registration extension and the GNAP core protocol, =
I hope I can add to this conversation.

From a =
technical standpoint, OAuth=E2=80=99s dynamic client registration lets arbi=
trary clients talk to an AS, but the trust isn=E2=80=99t there in practice.=
 On top of that I think this problem is exacerbated by a fundamental protoc=
ol design element of OAuth: the client_id that=E2=80=99s required. That fie=
ld means there=E2=80=99s an assumption that a relationship was set up betwe=
en the pieces of software, implied to be trusted by admins at the AS. Sure =
you can get that client_id under special circumstances, but there=E2=80=99s=
 still a special weight handed to that and the dynamic stuff feels like you=
=E2=80=99re giving up control as an AS. In GNAP, the relationship is invert=
ed, and it=E2=80=99s designed as =E2=80=9Cdynamic-first=E2=80=9D, with pre-=
registered clients being an optimization on top of that.

Yep, this is the big point - OAuth is designed to require the the thir=
d leg of trust that creates the NxM problem.



If that dotted line betwee=
n client and server requires a pre-existing trust relationship rather than =
the trust being entirely mediated by the user choosing to connect client A =
with server B, then you have the NxM problem.=C2=A0 This is the "you c=
an only have your John Deere tractor serviced by an approved John Deere ser=
vice centre" problem.=C2=A0 You can only use this client with servers =
who have pre-approved it.=C2=A0 Or fall back to the "cash of the inter=
net" - plain text passwords.

<=
div>Does this solve the NxM problem? No, because companies are still going =
to decide that they only talk to keys or identifiers that they know ahead o=
f time. But the protocol puts the dynamic case forward as baseline and fits=
 in much better with the likes of JMAP than OAuth ever could:

- {The Bat} creates a key pair.
- {User} ente=
rs their email address into {Bat}, {Bat} does discovery (maybe that=E2=80=
=99s a JMAP thing? Webfinger?) and finds the JMAP server and the GNAP endpo=
int for authentication as an option.
- {Bat} talks to the GNA=
P AS at {ISP} and presents the key it just made up. {ISP} has never seen th=
is key, but knows how to talk GNAP and get the user to authorize {Bat} to a=
ccess email.
- {User} does this using GNAP and gets back an a=
ccess token that=E2=80=99s tied to the key {Bat} made back at the beginning=
. That token is tied (at the {ISP}) to the user=E2=80=99s account.

Yes, you can do all of this today with OAuth (and peop=
le have done so), but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discove=
ry and registration first and THEN talk to me=E2=80=9D is a trust impedimen=
t more than it is a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D=
 part of the GNAP name comes from the philosophy of =E2=80=9Cstart talking =
first and figure out what you need as you go=E2=80=9D. Instead of jumping t=
hrough hoops to get something you can trust, you just start in and then dec=
ide how much you trust it. A corporate rollout could use its own key distri=
bution mechanism and static registration to limit which client instances ta=
lk back to the company server, regardless of which accounts would authorize=
 access on top of that. An internet-facing service is going to be more like=
ly to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk to you in a secure=
 fashion without caring who you are right now=E2=80=9D.

<=
/div>
We really are trying to make GNAP a consistent protocol at its co=
re and learn from problems with OAuth in the wild, all while letting GNAP a=
ddress a wider variety of use cases. I agree that GNAP could be clearer abo=
ut specific use cases, and we=E2=80=99re working on the spec still so any h=
elp here is appreciated.=C2=A0

Excellent.=C2=A0 This=
 is precisely what I've been waiting for for these very many years as a=
 viable replacement for storing a password locally on disk.=C2=A0 Just havi=
ng the server able to distinguish between different client instances for th=
e same user is a big start, because you can de-authorise one without having=
 to lock out every connection - even if the user is still entering their pa=
ssword during the setup phase each time.

This is what Fastmail al=
ready do with our own app, creating a long-lived access token and storing t=
hat on the device rather than storing the password itself - and you can log=
 out any one client from your security settings page.=C2=A0 What's miss=
ing is a standard way to do that with any IMAP client.=C2=A0 The initial JM=
AP authentication proposal was a very simple case of pretty much this, buil=
d into to the protocol so everyone would do it.

Making it easy to=
 connect up arbitrary clients with per-client tokens the default, and easy =
rather than almost impossible to do in practice is where the big difference=
 comes in.

Bron.

=

--
<=
div>=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000004e772205bc24da12--

--0000000000004e772305bc24da13
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <177d829913ecb971f161>
X-Attachment-Id: 177d829913ecb971f161

iVBORw0KGgoAAAANSUhEUgAABlEAAANCCAYAAAD2kOrdAAAABHNCSVQICAgIfAhkiAAAIABJREFU
eF7s3Quy3DiSIMBSmy4xp9j7H2NPscfQilOV3dkUfwACID4+ZmU9L5MEIjxAECT0pB+/fv/fX/6P
AAECBAgQIECAAAECBAgQIECAAAECBAgQIEDgvwT+xYMAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg
QOBPAZsof5r4hAABAgQIECBAgAABAgQIECBAgAABAgQIECDwl00Ug4AAAQIECBAgQIAAAQIECBAg
QIAAAQIECBAgcCBgE+UAxUcECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAZsoxgABAgQIECBAgAAB
AgQIECBAgAABAgQIECBA4EDAJsoBio8IECBAgAABAgQIECBAgAABAgQIECBAgAABAjZRjAECBAgQ
IECAAAECBAgQIECAAAECBAgQIECAwIGATZQDFB8RIECAAAECBAgQIECAAAECBAgQIECAAAECBGyi
GAMECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgQMBmygHKD4iQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIECNhEMQYIECBAgAABAgQIECBAgAABAgQIECBAgAABAgcCNlEOUHxEgAABAgQIECBAgAABAgQI
ECBAgAABAgQIELCJYgwQIECAAAECBAgQIECAAAECBAgQIECAAAECBA4EbKIcoPiIAAECBAgQIECA
AAECBAgQIECAAAECBAgQIGATxRggQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwI2EQ5QPERAQIE
CBAgQIAAAQIECBAgQIAAAQIECBAgQMAmijFAgAABAgQIECBAgAABAgQIECBAgAABAgQIEDgQsIly
gOIjAgQIECBAgAABAgQIECBAgAABAgQIECBAgIBNFGOAAAECBAgQIECAAAECBAgQIECAAAECBAgQ
IHAgYBPlAMVHBAgQIECAAAECBAgQIECAAAECBAgQIECAAAGbKMYAAQIECBAgQIAAAQIECBAgQIAA
AQIECBAgQOBAwCbKAYqPCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQI2UYwBAgQIECBAgAABAgQI
ECBAgAABAgQIECBAgMCBgE2UAxQfESBAgAABAgQIECBAgAABAgQIECBAgAABAgRsohgDBAgQIECA
AAECBAgQIECAAAECBAgQIECAAIEDAZsoByg+IkCAAAECBAgQIECAAAECBAgQIECAAAECBAjYRDEG
CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIHAjZRDlB8RIAAAQIECBAgQIAAAQIECBAgQIAAAQIE
CBCwiWIMECBAgAABAgQIECBAgAABAgQIECBAgAABAgQOBGyiHKD4iAABAgQIECBAgAABAgQIECBA
gAABAgQIECBgE8UYIECAAAECBAgQIECAAAECBAgQIECAAAECBAgcCNhEOUDxEQECBAgQIECAAAEC
BAgQIECAAAECBAgQIEDAJooxQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBA4ELCJcoDiIwIECBAg
QIAAAQIECBAgQIAAAQIECBAgQICATRRjgAABAgQIECBAgAABAgQIECBAgAABAgQIECBwIPDz4DMf
ESBAgAABAgQIECBAgAABAgQIEBhS4MePH0PG/SToX79+PTnMMQQIECAQKGATJRBTUwQIECBAgAAB
AgQIECBAgAABAnECM2+I5CidedhcydF0DgECBJ4J2ER55uQoAgQIECBAgAABAgQIECBAgACBBgJn
GwUNuh62iygzmzHDDgGBEyBQUcAmSkVcTRMgQIAAAQIECBAgQIAAAQIEvgVKXnaP/oK7JHejqI3A
UY1GH3dt5PRCgMDMAj9+T4T+MsWZKyw3AgQIECBAgAABAgQIECBA4BWBoxfSrwSiUwLBAl4nBoNq
jgCBrgX8JkrX5REcAQIECBAgQIAAAQIECBAgMIKADZMRqiTGKIH9eLepEiWrHQIEehSwidJjVcRE
gAABAgQIECBAgAABAgQIvC6wf1H8ekACINCpwNm1YnOl04IJiwCBJAGbKElcDiZAgAABAgQIECBA
gAABAgRWEDh7KbxC7nIkECWwv45sqkTJaocAgZYCNlFaauuLAAECBAgQIECAAAECBAgQ6Fpg/9K3
62AFR2Awgf31ZVNlsAIKl8CiAjZRFi28tAkQIECAAAECBAgQIECAAIH/Fti/4OVDgEBdgf01Z1Ol
rrfWCRDIE/hX3mnOIkCAAAECBAgQIECAAAECBAjMI7B/mTtPZjIhMI7Adh26Fsepl0gJrCLgN1FW
qbQ8CRAgQIAAAQIECBAgQIAAgUMBL20PWab7cKTfclh9TG75j1Sv6S4WCREg8F8CP35PSL+YECBA
YBNIXaTVmD5SYzirXI3YzvryOQECBAgQIECAAAEC4wpEPYOMKzBm5Ks+8602Xlet85hXpagJzCtg
E2Xe2sqsscBqC5nGvM26s0BrRq0jAgQIECBAgAABAq8LeI57vQRJAXheu+Z6Op43x6fHXvfY5lt1
b+OsFwIEzgVsopzb+IbAfwmMtMBQuhgBC7UYR60QIECAAAECBAgQ6FGgp2e8/bNHT7G1qN0+/xZ9
6uNPgV7HnfHxZ618QoBAWwGbKG299RYsUOsGv79B1+onmENzlQX246Jyd5onQIAAAQIECBAgQKCS
wNvPeJ4tKhVWs+ECb18rW0Kul/CyapAAgUQBmyiJYA5vJ9DDjbpdtnoiMJ6Ahex4NRMxAQIECBAg
QGB1gTeeM62bVx91c+X/xjVUIuj6K9FzLgECHwGbKMZCFwKj3YS7QBMEgYEFLGQHLp7QCRAgQIAA
AQKDCkQ+d1rPDjoIhF1NIPL6qhbkV8Ou4RbK+iAwj4BNlHlq2XUmo91Mu8YUHIFJBSxiJy2stAgQ
IECAAAECHQhEPpNat3ZQUCF0LxB5zbVO1jXeWlx/BPoXsInSf42GjHDkm+WQ4IImMKGAheuERZUS
AQIECBAgQKChQI3nUmvUhgXU1VQCNa7HUYHMI6NWTtwrC/xcOXm5xwq4IcZ6ao3A6gJHc4rF5uqj
Qv4ECBAgQIAAgXuBo3Xk/Vn3R1iL3hs5ggCBe4GIOcp8dO/sCAKRAjZRIjUXayti0l+MTLoECBQK
fM87Fo2FmE4nQIAAAQIECEwiUPvZ1LpzkoEiDQITCdzNe+atiYotlS4EbKJ0UYb+g7ibnPvPQIQE
CMwmsM1LFoazVVU+BAgQIECAAIF7gZbPp9ab9/VwBAEC/QkczZPms/7qJKJxBGyijFOrqpEeTa5V
O9Q4gUSBs5u9sZsIOdnhn/qfjY/J0pUOAQIECBAgQGB5gZbrf2vM5YcbAAJTCRzNn+a5qUosmYoC
/mH5iri9Nn00afYa6wxxuSH1WUXXQZ91KY3K9VYq6HwCBAgQIECAQL8CLdfw1pX9jgORjSnQ8vod
U6iPqM19fdRBFP0J2ETpryahEblJhXL+uzE3lTqub7XqOnlLvl6/rtF6tlomQIAAAQIECLwh0HLN
bi35RoX1uYJAy+t4Bc/aOZoLawtrfyQBmygjVesmVjej/wA9nehzzZ62f1MyX3cskDs2Ok5pudBc
p8uVXMIECBAgQIDApAIt1+bWkJMOIml1I9Dyeu4m6UkCMT9OUkhpZAnYRMlie/+klW86tSbtp6a1
+n9/VImAwLHA02vj+Ox3P3W9vuuvdwIECBAgQIBAiUDLdah1Y0mlnEvgfYGW88X72b4XgbnyPXs9
vytgE+Vd///q3YT/ZzHemJyv6vBGPH+q+ITAOAJX11OrLFy3raT1Q4AAAQIECBAoE3hr7Wi9WFY3
ZxPoWeCteaVnk9LYzJmlgs4fUcAmyktVM4n/DW/ifWkA6pbAiwJvzH/mmhcLrmsCBAgQIECAwAOB
N9aIW1jWiQ+K4xACkwq8Ne/MwGnunKGKckgRsImSopV5rEn5P3Am2cxB5DQCEwu0mCPNPRMPIKkR
IECAAAECwwq0WAce4VgbHqn4jACBaIG35rjoPM7aM5eeyfh8RgGbKAFVnX1SLCUyqZYKOp/AegI1
5lVz0XrjSMYECBAgQIBAvwI11nt32VoP3gn5ngCB3gTemCtTDcytqWKOH1HAJkph1UaYzApTTD7d
5JlM5gQCBC4EIudZ89MFtK8IECBAgAABAo0EItd3VyFb+13p+I4AgRkEWs2nT63Mu0+lHDeagE2U
gor1NlEVpJJ9qskxm86JBAgkCLSYb81nCQVxKAECBAgQIEAgQ6D2ms56LqMoTiFAYDqB2nPtEzDz
8RMlx4wkYBMls1o9TEiZoSedZtJL4nIwAQKVBd6ae82FlQureQIECBAgQGB6gRbrOGu26YeRBAkQ
yBRoMQefhWZuPpPx+UgCNlEyqvXmxJMR7qNTTGiPmBxEgEAnAm/Ow+bLTgaBMAgQIECAAIFhBFqs
3azRhhkOAiVAoAOBFvPyUZrm6iMVn40gYBMloUpvTTAJIT4+tIdJ69uzh3ge4zmQAIEuBHqYk81d
XQwFQRAgQIAAAQIdC7RYs1mTdTwAhEaAQPcCLebpIwRz95GKz3oVsInysDJvTSgPw7s8rMdJae/Z
Y4yXqL4kQKALgf1c8lZQ5rC35PVLgAABAgQI9CzQYq1mHdbzCBAbAQIjCrSYu/cu5vK9iJ97E7CJ
8qAib0weD8I6PMSkc8jiQwIEJhbodY42H0886KRGgAABAgQI3ArUXKNZZ93yO4AAAQJFAjXn8KvA
zO9XOr57U8AmygP9tyaOT2gmkAdFcggBAksLvD1PP8E3lz9RcgwBAgQIECAwg0D02sw6aoZRIQcC
BEYTiJ7Ln+Zvzn8q5biWAjZRbrRbTxgmipuC+JoAAQInAq3n65Mwkj827yeTOYEAAQIECBDoWCB6
TWat1HGxhUaAwPQC0XN6Cpj5P0XLsbUFbKLcCNecLEwGN/i+JkCAQKJAzTk7MZTsw90bsumcSIAA
AQIECLwsELUWsx56uZC6J0CAwJdA1Nxeguq+UKLn3AgBmygXiqWThAv8AtdXBAgQqCRQOndXCiu7
WfeSbDonEiBAgAABAg0FotZg1j4Ni6YrAgQIJAhEzfMJXR4e6j5xyOLDygI2UU6ASycGF/QJrI8J
ECDQQKB0Dm8QYlYX7i1ZbE4iQIAAAQIEKgtErb2sdSoXSvMECBAIEoia90vDcd8oFXT+UwGbKAdS
pROBC/gA1UcECBDoRKB0ju8kjb/ca3qphDgIECBAgMDaAhFrK+uatceQ7AkQGFcg4h4Qlb17SZSk
do4EbKLsVEovfhfs0TDzGQECBMYQKL0HvJWle89b8volQIAAAQJrC0Ssnaxj1h5DsidAYB6BiHtC
lIZ7S5Skdj4CNlF2Y6HkgneBurAIECAwj0DJ/eBNBfeiN/X1TYAAAQIE1hIoXS9Zt6w1XmRLgMA6
AqX3hygp95koSe3YRPkaA6UXuAvTBUWAAIE5BUrvD2+quDe9qa9vAgQIECAwr0Dp+sgaZd6xITMC
BAh8C5TeLyI03XMiFNduwybKP/UvvaBdjGtfSLInQGANgdJ7RU9K7ls9VUMsBAgQIEBgLIHSNZF1
yFj1Fi0BAgSiBErvHyVxuPeU6DnXJso/Y6DkInYRupAIECCwrkDJ/aMnNfeynqohFgIECBAg0LdA
yfrHmqPv2oqOAAECLQRK7iMl8bkHleitfa5NlN/1L7lwXXxrX0CyJ0CAwF6g5J6yb+utn93b3pLX
LwECBAgQGEMgd71jjTFGfUVJgACBFgK595KI2NyPIhTXasMmyu965160Lri1LhbZEiBAoEQg915T
0mfpue5zpYLOJ0CAAAEC8wnkrmmsK+YbCzIiQIBAhEDufaW0b/elUsG1zv+5Vrp/ZvvWhfpnJD4h
QIAAgZkF9gu0Ee4/3zHu45+5VnIjQIAAAQIECBAgQIAAgTYC38+aLZ+Tt74857ap8Qy9LP2bKCUX
potshuEvBwIECPQjUHJPapmF+19LbX0RIECAAIH+BHLWLNYP/dVRRAQIEOhdIOd+k5OTe1SO2nrn
LLuJUnIhurjWu1BkTIAAgZYCJfeoVnG6F7aS1g8BAgQIEOhLIHWdYs3QV/1EQ4AAgREFUu89OTm6
X+WorXPOkn+dV4sLb50hJFMCBAgQiBb4Xrz1es/6jstiM3oEaI8AAQIECBAgQIAAAQIEPgItnpG3
Z1zPtsbcmcByv4lS+jLKxXQ2lHxOgAABArUFSu9hteNzj6wtrH0CBAgQIPCuQM5axPrg3ZrpnQAB
AjML5NyX7jzct+6E1vx+yd9EWbPUsiZAgACB0QVa/OmbEiO/nVKi51wCBAgQIDCfgBdR89VURgQI
EOhJ4HOfidxM8RspPVW4n1hsoiTUwgIwAcuhBAgQIFBVYH9Pilw0RgT+iWcfZ0Tb2iBAgAABAgQI
ECBAgAABAh+B6M0UGynG1l7AJspe5ORnL4FOYHxMgAABAl0InN2n3t5c8dspXQwPQRAgQIAAAQIE
CBAgQGB6ge25OOoZ2EbK9MMlKcF/JR09+MG5F9HZi6nBOYRPgAABAgsIbPew7//eTDn3PvxmzPom
QIAAAQIECBAgQIAAgXEEIt/jeoYdp+61I11mEyV30EdeeLWLqX0CBAgQIHAn8PaGSu79+C4v3xMg
QIAAAQIECBAgQIAAgU3g89wboeEZNkJx/DaW2ETJHew2UMYf4DIgQIAAgXOByIXleS9/fpN7X/6z
JZ8QIECAAAECvQp4nu61MuIiQIDAOgJR9yLPsOuMmbNMl9hEOUve5wQIECBAgMB//pRO1ALzialF
6BMlxxAgQIAAAQIECBAgQIBAiUDL59ySOJ3bt8D0myhe0vQ9AEVHgAABAn0JtPztlO0e7T7dV/1F
Q4AAAQIECBAgQIAAgdkEIjZSPLvONirS8pl+EyWNw9EECBAgQIDAJtB6M4U6AQIECBAgQIAAAQIE
CBCoJRDxjGsjpVZ1+m/XJspJjSJ2KE+a9jEBAgQIEBhG4LPQrH1ftBgdZkgIlAABAgQIECBAgAAB
AsMK1H62HRZG4JcCNlEOeFxMByg+IkCAAIHlBSL+5M4Voo2UKx3fESBAgACBdwXcp9/11zsBAgQI
xAmUvPt1P4yrw0gt/Rwp2BaxllxELeLTBwECBAgQeFvg+14ZvYDc2nMvfrvC+idAgAABAgR6FYhe
e33ytP7qteLiIkCglsA27+XOqZ5ba1Wl33ZtovRbG5ERIECAAIHuBT4P3LmLz+4TFCABAgQIECBA
oAOB2muto/ZtrHRQeCEQINCtgI2UbktTJbAfv2+Kv6q03EmjRwuBs9AmpzhL2+cECBAgQCBUIOXe
e9axe/KZjM8JECBAgMA7Aqn3d/fysjqlepf1dn62Op7b+IYAgTkESudb8+Qc4+Aui6n/TZTSi+AO
z/cECBAgQIDAnwIWkX+a+IQAAQIECBAg8FSgp3cZPcXy1M9xBAgQSBEofX41T6Zoj3vs1Jso45ZF
5AQIECBAYGyB0oXo2NmLngABAgQIzCXgBVG7erJuZ60nAgQIECDwVMAmylMpxxEgQIAAAQJJAiUb
KV4gJFE7mAABAgQIdCVQsgboKpHGwVj/NAbXHQECBP4RKL1vmb/nH0o2UeavsQwJECBAgMBrAqWL
0dcC1zEBAgQIECDwvwJeDNUfCJsx5/rOeiBAgMCVgGfXKx3f2UQxBggQIECAAIGqArmLUS8TqpZF
4wQIECBAgEAHAtY7HRRBCAQIEPhHIPfZdTvdfD73MLKJMnd9ZUeAAAECBLoQKFmMdpGAIAgQIECA
AAECwQJeuAWDao4AAQIBAp5dAxAnbMImyj9FdYFMOLqlRIAAAQIECBAgQIAAAQIEOhSwgdJhUYRE
gACBfwRy3xOb2+cdQj9nTc2gna+yUTXNnQjnE5URAQIE+hfY5n7zdv91EiEBAgQIEPgIuG9fj4Wo
59rrXuK+Vc84Sy0RILCGgGfYOes87SbKnOVaM6voRea+PYvCNceVrAkQaC+wzbf7OfhJFBahT5Qc
Q4AAAQIECPQskLMGSsnn6XNtShxP20yJ07EECBAYRSD3+XWU/MSZJmATJc3L0Y0FUhZ4uaF9+rBA
zBV0HgECBAgQIECAAAECBP7y26MHg6D2M23qc2zq8Qcp+YgAAQIEbgT8QcAboAG/tokyYNFWCbn2
YnPv+N2fheVex88ECBCIEcj90zwWoTH+WiFAgAABAgTaCNR8nvW82qaGeiFAgEDu8yu5+QT8w/Lz
1XTYjLZF5vd/byZSc8H7Zl76JkCAwMgC5uaRqyd2AgQIECCwjkDNNYsNlHXGkUwJEBhboOa9YGyZ
MaP3myhj1m2aqHueUD6xWaROM9wkQoAAAQIECBAgQIAAgaoCNZ9xPZtWLZ3GCRAgcCjgt1EOWZb7
0CbK75JbiNQd9zUXkXUj/7v1LX5jpIW0PggQWEXAInSVSsuTAAECBAisJVDr2dfz6FrjSLYECPQn
4Bm2v5q0jshf59VafLH+ai0iWzPOkkdrN/0RIEDgTMDLgDMZnxMgQIAAAQIjCtR4ZtzWS9ZMI44G
MRMgQOBvgRr3BrbvCNhEecd96l63CeLz30yJmvhmqqZcCBAgQIAAAQIECBC4E/AMdCf09/c1nGye
PLN3FAECBFoJ5M7LNe4RrXLWz38EbKIYDaECJoZQTo0RIEBgaoGcRaj7zNRDQnIECBAgQIDAb4Gc
NRI4AgQIECBAoJ6ATZR6tsu17MXWciWXMAECBIoFvCQoJtQAAQIECBAgMJGAtdFExZQKAQLTCeTO
0d6Zjj8U/MPy49ewiwzenAzOJrA3Y+qiKIIgQIAAAQIECBAgQIAAgSEEzp5rhwhekAQIECBAYHIB
myiTF3j29K4WmvvvbKrMPhrkR4AAAQIECBAgQIAAgbEE9s+tY0UvWgIECBB4KrC9lzTnP9Xq7zib
KP3VREQPBVInns/xPWymXMWQmtdDLocRIEBgGgGLz2lKKRECBAgQILCsgOe+ZUsvcQIEBhfY5u+r
93qDpyf8EwH/JsoJjI+fCWyTRuuJY5usShacpec/kzk/6s7r7vvzln1DgACBdQTMlevUWqYECBAg
MIZAyTPaGBnGRPn282hMFlohQIDA2gK59zzPseOOG7+JMm7tXo+81YWfOzHdAX3afZpHRBxP+9qO
i+jvzsD3BGoJXI11Y7uW+rjtbmPiasyMm5nICRAgQIAAAQIECBAgQIAAgdEF/CbK6BV8Kf7aL7s+
fzqnxcvWT19XlC3iuOrfdwRGEribH+6+HylXsb4rYCy96693AgQIECBAgAABAgQIrCrgXeFalfeb
KGvVu6tse5tseounq2IJhsBDgacvtf221UNQh90KGEu3RA4gQIAAAQIECBAgQIAAAQIECgT8JkoB
nlPzBWxY5Ns5k8AsAk83XGbJVx71BIylerZaJkCAAAECBAgQIECAAIFjAe83j11m/NQmyoxVrZxT
6csqE0zlAmmeAAECAwqU3htK700DkgmZAAECBAgQIECAAAECBAgQaCBgE6UBsi7+I1D6kowlAQIE
CMwr4B4xb21lRoAAAQIECPwtsP3BD3/4w2ggQIDAPAKeY+ep5VUmNlGudHz3h0DJYs+k8genDwgQ
IECAAAECBAgQIEBgQYGSZ+sFuaRMgAABAgReFbCJ8ir/Op3bQFmn1jIlkCLg4TFFa41j3S/WqLMs
CRAgQIAAgb/8RopBQIAAAQIEBhGwiTJIoXoIM/dlpxdiPVRPDAQIEBhHIPe+kXufGkdGpAQIECBA
gMBsAtYvs1VUPgQIECAwo4BNlBmrKicCBAi8JJD78vulcHXbsYCx1HFxhEaAAAECBAiECvh3UkI5
NUaAAIGuBWyed12e0+B+nn7jCwJfArkXuJdghhEBAgQI5Aps95Dc+09unzXP+7//8z+Xzf+f//f/
Lr/3JQECBAgQIDC3wLbu8Qw9d41lR4AAAQJjCvhNlDHr1jTqmV5gNYXTGQECBAgQ+EfgbgNlO+zJ
MUAJECBAgACB/gQiNz48f/dXXxERIECAAAGbKMbApUDJAi5yIXkZpC+zBD6/Mn70v1kNOokAAQIE
DgVSNkdSjj3szIcECBAgQIDAKwKRz78lz+GvJK9TAgQIECAwuYC/zmvyApekZ+FWotf3uXe13b6P
fAjoW0N00QKz/RVM0T7aqyvQ2/xlU6RuvbVOgACB0QSu7gv+WsfRqvlnvJHr4O9nNs9mf1r7hAAB
AgQItBSwidJSe6G+LPL6LfbdBson8t5eRPYrKjICBGoKRL6MqBnnUdtXL8qOjvcZAQIECMwtcHdf
+HxvM2XscVBj7XL3DOf5e+wxI3oCBAgQ6F/AJkr/NXolwrtF2itB6ZQAAQIECAwicPeibJA0hEmA
AAECQQIp94XvY22oBBWgcTM1NlKuUtg/v9tUudLyHQECBOIFWs/78Rlo8U7Av4nyW2i/4LhD8/21
gAXbtY9vCRAgQGBugZQXZXNLyI4AAQIESgXcU0oF3zt/ey5+69nYO4736q5nAgQIEJhTwCbKnHUt
ysqCq4jPyQQIECCwsICXXQsXX+oECBCoJODeUgm2UbM2UhpB64YAAQIECFQUsIlSEXfEpks3UN5a
II5oLWYCBAgQqCNQei+rE5VWCRAgQIBAvoCNlHy7Hs586znZmqiH6ouBAAECBGYQsIkyQxWDcihd
YL21MAxKXzMECBAg0KnAKPeXiBdc/u77TgehsAgQINCBwHafibjXdJDKkiG8tZ4pfc5fsliSJkCA
AAECOwGbKP+AWFiUXRtvLQjLonY2AQIECBDoR8AGSj+1EAkBAgR6Fmi1keIZOX4UvPXcrJbxtdQi
AQIECKwlYBPlq94rLyxKcn9rIbjWpRqX7dN6PT0uLjItESBAYFyB0hdaNlDGrb3ICRAg8IZA6X3n
jZj1+beA5ywjgQABAgQIjCcw7SaKhcl4g1HE7QTuro+779tFqicCBAiRy5RzAAAgAElEQVTkCZT8
4YDUHktfZNlASRV3PAECBMYTqDHXl95/xlOcJ+I3nrdaro3mqZRMCBAgQIDA3wLTbqLkFtjCIk3u
jcVfWoSOPhPYanf239k5PidAgACB/xYofYFV46WaGhEgQIBAnwLm/D7r8lZUn2ext/p/s9/tvUvU
f2/moW8CBAgQWEfAJso6tZYpAQIECBAYViBn0773PxjhZdqww1HgBAgQyBaInvv9Y/PZpejmxO8/
2NZNUBUC+d40iWy+9/VeZK7aIkCAAIH3BH78vmH/eq/7uj2X3EwnZjlEz7FazegQLvHDFGe+ibgO
70rAWO+qHNMEkzKuPknXnEtLfgsl+iXaNEWWCAECBBYSKLmPHDFF31tS77s177lH+a74WWpN9kZv
1ag07n0eRz+/ldtRLD4jQGBNgZS5zpw13hiZehNlK0fKAP4u32qDOdVpNZ+oSzvFmXGUunbeEDDW
31Cfv8+UcVX7nl764iv6Rdf81ZchAQIE5hYova98dCLvLyn3Xc8u74zPlBp9Imxdq5wYczVb55Yb
p/MIEJhTIGW+M1+NNwam/+u8cgdlysAfr+xlEeealvXqbAIECBAg0IdA6YuuyBdcfYiIggABAgRK
BaLuDaX3qNI8nN+/QMt3HS372uRb99d/tUVIgAABAlEC0/8mygZVciNdZcMgxWgVk6iL7LsdzjVU
tdmjgLHeY1XmiCllbH1nHHHvingxFfWSbI5qyoLAfwQirq+9Z0/X21V+PcW5Nzz7ebZ8zvJ84/Mr
25R4IsZVyj034j6bkp9j/yOQUqfPWS3qlRNXVF1b5BcVq3YIEJhHIGXeM0+NV/clNlG2sqQM5O8y
rjKoU3xWMalxOXOuoarNHgWM9R6rMkdMKWNrn3HJ/SvipVbEC619Tn4mMINAxPV15tDiuouIv0Wc
Z0ZPPk/NsVU+qXF9ci2N72m/uf08bf+udrn9f9pNueeW3GPv8vD9tUBKnT4t1a5XTkzXWaZ/WzvH
9IicQYDA7AIpc585arzRYBPlpmarDGoX+s1ACPqacxCkZroXMNa7L9HQAaaMr+9Ec+/pvbzMGrpo
gu9C4Gosl75szU3wKqbcNvfn1cwtMv6ace5Nnv5ckl/tfEpi2/LPjS+131b9nNU0t/+tvZT7be49
9ixunz8XSKnTd6s1a5Yb0/Os74+smd9979dHPPHpOf7r7J59e2cwe/7PlBw1msDduP7Oxxgfrbp/
/fVzvJDzIt4GZ8pgzuvFWQQIECBAgECvAts6IHWxmvqy7Cz3kpdYZ22+8Xmux5v5P425ZoxPY9jX
NDKmuxi27yP72+cy4893piPn3HtuEfHljPmcfnP62cbOdj3m9DfyuBP7HALeu/ynjiUWT85NXdf2
MsKe5Jazbu8lP3EQIDCnwDKbKLnlM3HnyjmPAAECBAjUEWj1ByOiXl5dvZhO6eOqnTrS/2k1Jc6j
WHJfIh61lfJZSty1YkyJYZ9bVExPY4jqb5+Hn/sVeDo2+s1g7shspMxd36jsctdFNd51PHk5HpV3
z+20cqhRw9quKTYj5lfbT/sECLwn8K/3um7f86i79O2l9EiAAAECBOYUSHlwixC42vhIfXmZenxJ
/Ftf3/+VtPU5t2X8W585/eWcc2UT0V5EG1cx+m5dAWNrjNpf3UfGyECULQS864hR3taJZ/897aH1
WrN1f08dHEeAAIHZBJbaRNmKZ3Hx5xB20/3TpMYnnGuoapMAgVUFRrifX734yn15mXteyjhp0UdK
PI4lQCBewHUeb6pFAgTKBbb13f6/8laftXD3vH73/dbLk2OeRTPXUd8bU3Nl1kc23745/38fWYiC
QP8C/jqv/mskQgIECBAgQOBAIPevrzhoKvyjqw2U8M4CG/RiNRBTUwQIECgQMB8X4Dl1OIGjPxzT
ckPiaV/bcUexbuBP2xiuOIUBcykEvDk9wnffxtkYvwnF1wSmF7CJ8qDEVzfKB6c7hIAFlTFAgACB
jgRq39dH3UDpqERCIUCAwJICPW2c7F+qLVmQwZLu+Q+XXFEevbDtefwdrSN7jvfKvvZ3b7tE9X80
Rmvb3bUfldtRP5+2e8z7KF6fEWglsNxf59UKVj8ECBAgQIBAfYHeFvc2UOrXXA9zCdS+Zmq3H1WN
UeJ8mu9s+TzNu+S4njZQSvJwLoEUge913Pbi9vNfShtHx7ZcH9Z8mX2U25PPvi33//+T8yOOedsl
sv/Itkay7S3vCDttECgRWHITJeeGOuvkMWteJReFcwkQIEBgfoEa9z8vDecfNzKsI1Dr2qnV7kch
qv2odupUJ73VFvlE9JHTRq1zam2g5MSbXnFnEMgT2G+g5LXy3lmfzYn3Ijju+W6Ne/f9catpn7bo
4yqiGv3XaPMqh7PvWsfR6zg/8/E5gZoC/jqvmrraJkCAAAECBKoLbA/hrR8ojpI6egnmBdaRlM9a
C2zj8Gh87uN4c7y+2ffeIeXnp7ZnbY6adw/5lNiXuKf0+6SfJ9fmmbfPCcwg0MMaLtWx15ifxrUd
l/OHi584PY3hSVs5MUb2/yTGlse8mVvNMdPSUF8ESgR+/J6UfpU0MOq5uZPPbFypDrPl32r8cm4l
rZ9eBFLGvHmll6qNHUfKmPvO9Gr8Rb3YOnqJVtL2UXtR1SuJ6y6GmnGf9Z2aT40YU2PY5xIZ01Us
kf3sc/BzfwJXYyEl2h7GTWouPcT8MU6NvWVtUu+rV/fTlLgdWybwdt1S+t/GTMrxT2VyxmKNOJ7G
W3rcd74peeQ43cWa0v9dW7nxRcawjzE3pn07OT/XzCslnjcNUuJ869iUOrF8q0r5/dpESbSbbZCn
XOAb1Wz5J5Y/+3DO2XROHFQgZcybVwYtcmdhp4y579Cvxl/0y639i7uc9vdtRJchJ6YnMdSO+yqG
pznVjPFpDPs8asa078vP6wnkjstNytgsHy8l/ne9R9Qn9b56dT+9i9f3MQKpNdt6ja5bSgxb3ynH
P1HKzSc6jiexRhyzzzclj/25pfGk9P2kr9z4ouP4jjU3pif5Xh1TM6erfs++e8vhLJ6ePk+pFcee
KvcslmU3UTaelMH9zTnTQE81mCn3Z5dIzFEpzoxjzLXyrkDNMf+kbdfRu/V/q/cnY+MotrPxUusF
1/fLrZQ+Il6KHeW//ywlps+5rWLbx+pnAgTKBFKvd9d6mffn7FT3lF6japRyTz27j6bE7dhygZSa
fXqLrl1ODOWZ/91CaS4tY38S6108R23cnfNtfXR+SS1S+r7rJze2yBiOYsyN66itJ5/VzudJDGfH
tLY4i6O3z1NqxrC36t3HYxPl3ujwiFkGe8oFvkHMkvdhUSt+mOLMuGIhNN1MoMaYT2nTfNWs1F11
lDpGPsGfzbs1X3JtfUe96KpRhKe595xDDRdtEiBAoFTg6fya2k/kfJx6Pz27j6bm4Ph8gdSafXqK
rl1uHPmZ/31mRB4tYo+I88oqJYfIWFL6vYp/+y43rsgYzmLMje2svf3nLXLY91nyc22PktjeOjel
hvzeqlJ+v0tvomxsKQN8zzzDgE/Jf4Z89zVs9TPnVtL66UUgasyntHOUu3nrSGXuz3LHzNFYqfWi
a1+ByBdf+7b9TIAAAQL9CNS4r9S4h6TeS4/uof2ozx9Jar0+IjXqlhtLSZWi8qgde1ScV1apOUTF
lNrvWQ658UT1fxZXzWvm03arHO5yTPk+t14pfYx2bEod+Y1W3b/++td4IfcTccrF0U/U+ZGslm++
lDMJECgR2Oaaz38l7TiXwCgCNV6qjZK7OAkQILCKQI25vsYGyir1eCvP73Vuyf//Vvw99bu9gBzl
JeQocabWt/SZ7VPDklrO8J6qVg4RvqljwvEEZhZY/jdRtuKWTlgj3xBTcx851zcv5BTnWsZPYqjV
95v2+n5H4Ml4axGZMd1Cub8+csff0Xip8dLrTMzLsDMZnxMgQGB8gaj7SYt7Rep99Oj+OX7F4jNI
db2LYHMvabNG3Uriucv3832NuD9t14i/Zrx7s9T4S2JL7Wsfa0nfNeu1j/P754iY9+2XOu7b+/z8
JNbSvp/0cRbfrJ+nmPIbbxTYRPlds5RBflTikQd+Tu6j5HuVW+scrmLZj6kasb3d/z5HP88vkDLm
amrUuJ5qxqvtGIHc8Xc2XqJefD3NrsULsqexOI4AAQIEygVK7yOt7wup99Gz+2e53DwtpJrWzrxW
zWrnWSvuj3d0/LXj3Y+T1Phz40vtZx9nbr/f7ZTGsI/pyc8Rce/7ic4jJ8bcGHL62uc/288plvzG
q76/zut3zUoHbspFMt4Q+TPiLd+ec34SX8/x/yle9klqrqnHl0X332d/apf6v5ExaIsAgfEFcu/r
Z/Nf65dXpS/bxq+gDAgQIEDgI9D6HkSeQIlA6hrs6fHbcU+PLYk/8tzR4o3MvXZbZ2v22v1Gtx+d
R+6Yyz0v2kN7BHoXsInyT4VKJ43oya/3gbPF12POKTGlHDtCPUaPsaQe27mf/0Z3ED8BAn0KbC+x
Wr7IspHS5zgQFQECBFoKtLzv5OZV+hyd26/z8gV6q9ldPHff50v8eWbLvv7svf0nOc/QJc/tW4al
xqX95yqXxr3vNzqP0vi280vb2OfoZwKzCfjrvHYVLZ3IRpt0SvPd+HrIOTePVrGnxBcdU0rfn8sh
Ooa7iTMnxqs2W8d/Fcuq30XXNNfRWMiVm+O8nHGYO2ZqbXqM8AJtjtEiCwIECNQTyLlHvDn/p9w/
c++b9bT7bDnFtGYGLeqVmmuLmFJMU+M/avvNnHLjfxJzbtvfRk/6OTL9fBYRw1X7Z9+Vxv3dbnQO
kbFtcT6JL7rPM/fRPn9i98mJ4WjV/esvv4myq1npIN4umJSL5u0hU5rvZ4Jtnfenv9b9vl2vGfuv
cb3UaHNG++icvq/L6LZz2ouY33L6dc6aArVeduW8eFuzArImQIDAPAK17inzCMmEAIFogatn6NXf
u/T8XFkjtrs2776PHpvaI9CLgE2Ug0pETAhXN6CDLqf5qNbN9fvl7Kq20wySr0Rq1rJm2zPW4mlO
+2vx++enbbQ4LmIebxGnPuoKtB4Htf7KLxspdceJ1gkQIECAwAoCrddFK5iukGPkc3XpGIyM5Wnt
SmN+2k/OcTVj29o++y8nVucQmEHAX+d1UsWoybnmpHYSetbHUfnedZ7jUTO2nHjucjz6PiWH6JhS
+v7EHh3Dkcn2WU5sZ22dfd4ql7P+R/68RX0ifdQ6UnOetlLHceQ4qrn54U8pzzNGZUKAwPwCKfeD
Hub3lHtn5H1z5pGQYlrDoWWdUnNtGdtT29Qc9u2+mVNk7KVtfbuUmkTGsq/X1c+lcR+1XZpLjZiO
4vRZukBKbdUx3fftM/wmykkFogZzygV0EkqTj6PyvQt280gxSTn2rm/frylgDKXXPfU6Te8h9oxt
/mo1h8VGrrUWAm+OjVq/mbK5pbyQa+GsDwIECBCYQ8DauU4d31yPvNl3Hc36rTKL/QOPo3r2FPfn
mbenmOpfiXog0JeA30S5qUfUInKUiS4q3xvWbr5uVZcU1+iYUvr+FCY6hrOC58R21tbV563yuYph
lO9a1aTUQ01LBdc6P2Vc1xxbNTY+evgTy2uNJtkSIEAgT+DJPaCHOT3lnrlJ1Lxv5kn3fVaqb2k2
b9QnNcc3YnzimprHp80e8smN/fuaLmnj2zfKIyqeJ7X/dnh6fMpxOblEOabE6dh0gZTaqmm679tn
2ER5UIGUi+CquVEukKh8ryx6+K5lPVJMo+NK6ftTl+gYjuqdE9dRO08+a5HPkzhKcm6RQ0l8T/Iv
PaaFQWmMzu9TIGVs1x5nT16ipSr28NItNWbHEyBAYEWBq3tAL3N5yj1zq2Ht++aK4+STc2ot9lZv
1iY19jdj3buV+veQS6r/t8EWf8n5n7aiHSJiOqv1/vPo2Pft5+RSO6Z9jH7OE0iprZrmGb95lk2U
h/opF8JZkyNdIBH5njn08HnrWqR4RseW0vdWm+j+j+qdGtNRG6mftcjrKqaInGvnEBHjlcHT72rn
+TQOx80jkDq2a4/Bq5doueq9vHzLjd95BAgQINCHQG/3zD5U3ositR6fSGuvZe5EUuOuEe9VDE/6
uzr/Kv8nbV+dH/VdbvwR/dcwaJVPjdj3pjm5tIhrH6ef0wRS66qmab49HO3fRHlYhYjBnXpBPQyt
ymER+VYJLKDRmXML4KnexEjXQRRGVM5R7UTlFd3Odm26PqNVtdejgA2PHqsiJgIECBAg0J/AZ338
dI1sPf13De+em+6+31p5at7fqPk7otHjb+3q2mktrj8C4wnYREmo2Wo3oRnznTGnhCE89KGltXuy
UE4F2to8+y+1rafH18jjad+1jrNgrSWr3Z4FbKT0XB2xESBAgACB/gQ+a+ar/+0v6mcRRT7jPG3r
yXGlz6DPsq931BvPWSOZfV9L9aqgZQIEZhGwiZJYyZFuCImpHR4+U74z5XJYrAE+fLJQvUrjjUXg
WTx3uXy+vzvurP2rz2u0edWf7wgQqCNgI6WOq1YJECBAoI2A56s2znqpJ+C5KtZ2lDmhp/cKsRXQ
GgECNQVsomToltwYRrxJl+SbwRt6yufmOHIOoSCTNPZ2PZ9ex0+Pm6Qs2WlwyqZz4gQCNlImKKIU
CBAgQIAAgWKB0meC7fzSNoqTWLiBt5/Rr+i/3wv1HOdVDr4jQOB9AZsomTX4TMI5p494Yx/lpjNK
nDnjpsU5NRcUJeO+ZlwtXGv0UeJZIx5tEiCQL2AjJd/OmQQIECBAgAABz0bvjoFen9dL3tu9K6p3
AgR6FLCJ8lJVRr/J93Qz+t44eamc03Tb47jsdUHWQ9F7qpcNzB5GhBjOBFLnkTeuLRspZ9XzOQEC
BAgQILCKwNM12Hbc93+r+PSYZ+o6u0UOPb2vapGvPsYT6PG6GU+xfcQ/fhfuV/tu5+rx6Y1+n/XM
9Lkme6O7n0cxTPGIziml7807uv9PDVPjuIolp62r9u7G2f773P737UT9HFmzJ7k96e9JO9/5P2kz
yks7awqMOCb/7//8z6Ni2YB5xOQgAgQIEHggkHK/tH57ALrwISljac90NrZK2tz38fn5rK/P9yl9
3rV1FkOLz1PyeBpPy3xT4m8Z11Or7+NScnk6TnPicE6sQEpdex+jsTLztGYTJaCWKRfKvrvZL5wS
m73V98+juaU4ROeW0vdmHN3/p26pcZzFktPOJ4ao3EpiuBrXJd9F5bbFcJXf036u2jjL82nbZ+f7
nMCVQOqY7Gk8Xm2m2EC5qrrvCBAgQCBVIOV+2dO9MjVPx7cRSBlP+4i+x1dJO/t29z8/GcdP+n/S
zr7vlj8/ySElntb5psTfIra7eK5iuDv3qA5X7R0d77P2Ail1Vc/29Yno0SZKgGLKhbLvzoWzF5nz
55QxEj0mUvre9KP7/1Q0Io7UNvajKSq30jj2cUX9HJVfRDw5Rj3FH2Ggjb4EUsek8dhX/URDgAAB
Am0EUu6X7pVtajJyLynj6a08n47jq1yetvFWjlu/V/GnxvVGvinx147vaSxXcTxt41Obq7ZS6+f4
OgIpNVXPOjWo3erP2h2s0P42+FMulm+T7TwXzwqjRI6lArnX2Kff3q+zknnkk+PHqIdcI/IpHTPO
J0CAAAECBAgQIECAQIRAD89YEXmUtDGKQc33bCnvJWrGUVJH5xIgkCfgH5bPc/vjrJKbScok/EfH
PiAwocD39bRdH71dIyXX+1W5otrtzesqZ98RIECAAAECBAiMKWDNOWbdWkYd9XxTK+be46uVd067
rHLUnEOAwEwCNlECq+mmEoipqaUFPhsnUQ9mK16bUXZLD0TJTyWQOg+4hqYqv2QIECBAgACBlwRS
12Ctwuw1rlr5l+Rbcm6tfO7atZa/E/I9AQKpAjZRUsUqHW+CrwSr2eX/urhaC77Idr/bimzXvGIC
IECAAAECBAgQIEDgbYHIZ5yIXHqLJyKnJ22slnfk8/DnD3o+cXYMAQJzCthECa5ryU0pcoIPTktz
BAg0FCiZRxqGedvVLHncJuoAAgQIECBAgMCiAp5hFy38oGlvzyerP6OkGozu9dn8KJmrSs4d9FIR
NgECBwI2UQ5QfESAwBwCIy/4omK34JtjLMuCAAECBAgQIECAwMgCUc83qQafTYO3+k+Nt9XxTzZT
ZjNLfTb22yetRqN+CIwh8HOMMMeKcrvRpE7Onwy382a7UY1VPdHOIjDDdfTJIXc+Ga2W5r/RKiZe
AgQIECBAgMBf//vsO8PaWy3rC5S8K8mJzri8VxvFKGrsnM1Xqzxz348IRxAgcCbgN1HOZAo/L7kR
mbwL8Z2+vEDJ9ZeCN1s/Kbk7lsAKAu7HK1RZjgQIECDwLdBqfUt9XYFtjNUaZ5+2a/axbuXmyfyz
xt/+9/PfPNnJ5A0Bz41vqLfv0yZKe3M9EiBQUaDWgrxWyE/jfXpcrTi1S2AGAdfRDFWUAwECBAj0
KOAFUo9V6TumyHWZTZO+a91jdG/PWSnjP+XYHq3FRGAWAZsoFStZMtG9PaFXZNE0gWoCJddcblAl
faaem3p8bk5vnmfue1Nf3wQIECBAgACBfAHruHy7Vc8sfb7Zzi9tY1X7EfMerdZ38d59v9XoyTEj
1lLMBEYU8G+iVK7aNuHlLia380yYlQuk+WkEVrlWSuaUaYotEQIECBAgQIAAgWoCJetNz7DVyjJt
w0fPcXfvUI7OmRZIYv8lUDI/taR8OkafHtcydn2lCdzNV2mtObpnAZsoPVfnd2wWoZ0XSHhdCLy9
8MhZyJXEnNqfeaSLYSoIAgQIECBAgAABAgQeCJQ8Kz1o3iGDC6Q+D7dO1/htLa4/Am0E/HVeDZxL
J1C7mg2KpIvhBLbr6vPfcMEvFHDp/LcQlVQJECBAgAABAt0IlKzhPL92U0aBEJhWoGSOqoXi/UQt
2X7bdb/rtzY1IvObKDVUD9rcJtOSi8ufJD9A9dFjgafjr8eFyFGSJXE+uQ5L2j+Kd/9Z7fb3/W0/
m0OOVHy2osDT+XBFGzkTIECAAIEoAWvPKEntECBwJvB5rn7yjH/WRtTnbzzjR8WunTyB3HFnrOR5
93CW30TpoQoPY8i9QB8277DJBe4m6rvvS3ki28+9Fp6e9/S4b5On+T09rtT76PycvI7a8RkBAgQI
ECBAgMD8AqXrVmvP+ceIDAn0IFA6V5XksPX9Zv8lsTuXAIE0gR+/L/Zfaac4ukSgdCGpXCX67577
pPYr1PeJQ26lzvxy+zxr7yq+q75y2jvr66qfs3M+n0fGcdfX9n1qrK3je5KDY+YSMCbnqqdsCBAg
QKCuQOp9cx+Ntd1exM8ECNQSKJ2vUuIyt6VozXds7lgzbsYdCzZRXqhd7oX2CdUF90LRgrq8qv1K
db1yCKL+958GKemr55qU5LUZt8wtNdaWsUWNN+2MJWBMjlUv0RIgQIDA+wKp9859xNZ3exE/EyBQ
S6B0vrqLy3x2JzT/97ljzNgZe2z4N1FeqN920eRecC+Eq8tAARPm35gtroHZr7FSw83HeAy8uDVF
gAABAgQIECBwKvBZm1t/nhL5ggCBIIHSZ+XvMMxZQUXRDIEJBPybKC8VsWQinv3l8Esl0W1jgZJr
oHGouiNAgAABAgQIECCwtEDU2t2z7NLDSPIEmglsc1bOvPU5L/f8ZgnqaDiBnPE4XJKTB+w3UV4s
8HYB5S4i/SnyFwun6zCBkmsgLIiBG+I3cPGEToAAAQIECBAYTCBq7elZdrDCC5fAwAJeXA9cvIlC
Nw7nKKbfRHm5ji6klwug+9cFtmvAdfB6GQRAgAABAgQIECBA4FYgat2+baTk/oHC2yAdQIAAAQIE
Kgm4d1WCHaBZmygDFOksRAvPMxmfjygQ9UA2Yu4lMc/mNls+JbV1bj0B46yerZYJECBAYH6ByPvo
55nWS6n5x40MCRAgMLqAe9XoFSyL3yZKmV/I2aWLUBdxSBk00oFA6bUQmUJPsdzl1XusT+N7etyd
h+8JECBAgAABAgTqCtRYt9lQqVszrRMgQIBAvkDuu9ca98v8LJxZImATpUSvo3P9VkpHxRBKkUAP
N5geYkhF3GLuOe672O6+T/VwPAECBAgQIECAQF2Bmus3z7d1a6d1AgQIEHgukLuB8rwHR44g8OP3
wufXCIGuEGPURamkK4yW+XOMuh5SpGa5dp7YzZJrSn0dS+Bb4Ml18jne9WLsECBAgACBc4GUe+p5
K/ffuB/fGzmCAAECBGIFSu9x7l2x9XizNb+J8qb+ru+oC6v0Au+IRCgLC2zXQ9Q18YSxZV9P4ik5
5i6Xu+9L+nYuAQIECBAgQIDAWgKt1pbbc+7nv7WEZUuAAAECBAi8LfDz7QD0X0dgW1y2WszWyUCr
BP4WOBrHURuFR23P4j5zbrPUSB4ECBAgQIAAgVkEtrVn1Br9icmnL2veJ1qOIUCAAIE3BNyj3lCv
16e/zquebXbL0YtPF212KZw4gEDu9eK6GKC4QiRQUSBl7jBfVCyEpgkQIEBgKoGU+2t04u7X0aLa
I0CAAIHc+5p70nxjxyZKpzXNvUiv0nEBX+n4bnSBp9eM62D0SoufQIzA0zlj6828EWOuFQIECBBY
RyDlPltDxb27hqo2CRAgsJ5Azv3MPWjOcWITpeO65lyoT9NxQT+VchwBAgQIzCaQen91z5xtBMiH
AAECBFoIpN5vo2Ny/44W1R4BAgTWEsi5j7n3zDtG/MPyHde25oW3TQSf/zomEBoBAgQIECBAgAAB
AgQIDChQ83n2CYfn3SdKjiFAgACBKIG373tReWjnWMAmyrFLN5+2uABtqHRTboEQIECAAAECBAgQ
IEBgGoHtebbFM+0VWM6fJL5qz3cECBAgQIDAegI/10t5vIw/i84Wi7/vPt5e7I5XKRETIECAAAEC
BAgQIECAwF7g+9myxXPtvv+7Pj377sX8TIAAAQIECHwL2EQZaNGEoz8AACAASURBVDxsC7u7xV9k
OjZUIjW1RYAAAQIECBAgQIAAAQJvb6gcVeDz7Gsz5UjHZwQIECBAgIC/zmuwMbAt6t5Y2G2LypYb
OIOVRbgECBAgQIAAAQIECBAgkCjw1vPtWZieec9kfE6AAIG1BNwP1qr3k2x//F60/HpyoGP6E3j7
gjZ0+hsTIiJAgACBe4GU+6d73b2nIwgQIECAQKRAyn06st99W9YAexE/EyBAYA2BnPuQe8b8Y8Nv
ogxc47cv0JxJZWBuoRMgQIAAAQIECBAgQIBAZYHPb6f08LzrmbdysTVPgACBzgTM+50VpKNwbKJ0
VIycUHpYWObE7RwCBAgQIPCGgEXxG+r6JECAAAECeQKfDZW8s2PO2tYO1g8xllohQIBAzwLm+p6r
835sNlHer0FxBG8vLE0yxSXUAAECBAgQIECAAAECBAicCPTw2yk2U06K42MCBAgQILCAgE2UiYr8
5maKjZSJBpJUCBAgQIAAAQIECBAg0KnA2xsqnn07HRjCIkCAAAECFQX8w/IVcXto+o0F3tt/xVgP
7mIgQIAAgf4Ecu6J7mn91VFEBAgQIEDgWyDn/h4laJ0QJakdAgQIvCtQci9xL3i3dq16/9mqI/28
I/B9IZdMCCnRH/VjQkkRdCwBAgQIECBAgAABAgQIPBH4PGsePYc+Ob/kmE+fnndLFJ1LgACBcQXM
/+PWLjVyf51XqtjAx28X9ue/1mm8saBtnaP+CBAgQIAAAQIECBAgQOAdgTdfZG3Pu55536m7XgkQ
IPCWwJv3nbdyXrlff53XytX/J/fWiz2TjEFHgAABAm8IpN7v3K/eqJI+CRAgQIBAPYHUtUBuJNYQ
uXLOI0CAQHuBnHuDeb59nd7u0V/n9XYFOuj/+8LPmThSU/juw6STqud4AgQIEMgRaHF/y4nLOQQI
ECBAgEA7gc/zZ+11wad9z7vtaqsnAgQIECBQU8AmSk3dAdtutaj80BwtXi00Bxw4QiZAgAABAgQI
ECBAgMAgAtsz59GzaHT4Wx+eb6NVtUeAAIE4gRb3grhotfSmgL/O6039QfruYUKx8BxksAiTAAEC
nQqk3svcdzotpLAIECBAgECwQOoaIbd7a4tcOecRIECgnkDOPcB8Xq8ePbfsN1F6rk4nsbX6UzpX
6R5NaiatKzHfESBAgMBH4OgeQocAAQIECBAgsAl8nitrrxe+2/csa+wRIECAAIGxBP41VriifUug
x0Ve7UXuW9b6JUCAAAECBAgQIECAAIG2Atszb6vn3u1Z9vNf2yz1RoAAAQIfAe8VjYUUAZsoKVqL
H9tqQZnCbOGZouVYAgQIECBAgAABAgQIELgSaLmZssXhmfaqGr4jQIBAXwI9vhvtS2jeaGyizFvb
Kpn1OlnYPa5Sbo0SIEBgeIGc+0Ov97rhiyEBAgQIECAwkEDr9YDNlIEGh1AJEBheIOc5cfikJVAk
4N9EKeJb8+TPYrK3CecuntaL4DVHh6wJECBAgAABAgQIECAwh8Abz77751rPsXOMJVkQIDC+gPl4
/BqWZGATpURv8XOPJo/9gq8norPYjvLoKW6xECBAgAABAgQIECBAgMB7Am9spnyy/TzHem59r/56
JkBgHoGzd4PzZCiTWgI/ft+If9VqXLtrCswwIbks1hy7siZAYC6BnPuR+X+uMSAbAgQIECBQQyBn
jREVh7VKlKR2CBBYRSBqzjb/rjJijvO0iXLs4tMAgahJKiCU0CZMmqGcGiNAgEA1gZz7kDm+Wjk0
TIAAAQIEphPIWWtEIVizRElqhwCBGQWi52dz7oyjJC0nmyhpXo7OFIievDLDqHaaybQarYYJECCQ
JZB73zGfZ3E7iQABAgQILC2Qu+6IQLN2iVDUBgECowvUnofNtaOPkPL4baKUG2ohU6D2BJcZVthp
JtgwSg0RIEAgSSD3/mLeTmJ2MAECBAgQIPAlkLv+iEK0jomS1A4BAqMItJp3za+jjIi6cfqH5ev6
av1C4GgSajUBXoQV9tVZLkd5h3WqIQIECBAgQIAAAQIECBBoLvB5zjt7Dqwd0He/njlra2ufAIE3
BN6aX9/IVZ/9CfhNlP5qIqKdwAqTpEWuYU+AAIEYgZJ7hrk4pgZaIUCAAAECBP4WKFmXRBla30RJ
aocAgZYCPcyfW77m0JZV77svmyh910d0/wj0Mnm2LojJurW4/ggQGFmg5F5hvh258mInQIAAAQL9
C5SsU6Kys96JktQOAQKlAj3MiXc5mDPvhNb63ibKWvUePtsRJtmWyCb0ltr6IkCgd4GSe4T5tPfq
io8AAQIECMwhULJeiRKw7omS1A4BAk8Eepj3nsT5fYx5MlVs/uNtosxf4+kyHHHyfbsIJv+3K6B/
AgRqC5TcG8yRtaujfQIECBAgQGAvULJ22beV+7M1UK6c8wgQuBLoYX67iu/uO3PjndCa39tEWbPu
U2c9+mTdU3HcOHqqhlgIEDgTKJn3zXNnqj4nQIAAAQIEWgqUrGci4rQmilDUBoH1BN6eu6LFzYXR
ovO0ZxNlnlrK5EZgton9Jt3mX7vRNCfXIQEC/wiUzO/mLsOIAAECBAgQ6EmgZF0TmYc1UqSmtgjM
I9DLHBUtas6LFp2vPZso89VURgkCs07+CQTVDnUDqkarYQIEvgRK5nHzlKFEgAABAgQI9CpQssaJ
yslaKUpSOwTGFehhLqqlZ46rJTtnuzZR5qyrrAIEZr5RBPBkNeEGlcXmJAIEdgIR87P5yLAiQIAA
AQIERhCIWPeU5mndVCrofALjCPQw59TUMp/V1J27bZsoc9dXdsECs99Mgrkum3PjuuTxJQECO4Ho
+dccZIgRIECAAAECIwlEr4Vyc7eGypVzHoF+BXqZX2oImbNqqK7Zpk2UNesu60CBmW82gUy3Tbmx
3RI5gMCSAjXmWPPNkkNJ0gQIECBAYAqBGmujHBjrqRw15xB4T6CXuaOFgPmphfJ6fdhEWa/mMm4k
sNINqhHpZTdukpc8viQwlEDN+dNcMdRQECwBAgQIECBwIVBzzXTRbchX1mQhjBohcCsw8jxxm9w/
B5hPnko5rkTAJkqJnnMJJAqscPNKJHn1cDfaV/l1TuAPgRZzpOv+D3YfECBAgAABAhMItFhHRTNZ
l0WLao/AfwRGnBOe1M+88UTJMTUEbKLUUNUmgUSBWW9uiQzdH+5m3X2JBNixQA/znGu44wEiNAIE
CBAgQCBMoId119NkrM+eSjmOwHOBkeaAfVbmhL2In3sRsInSSyXEQeBCYOQb4EVa033lZj9dSSUU
INDT/OUaDSioJggQIECAAIFhBHpah0Whjbaee1KD0XKKqOUTl+9+ooxS+03JNSrGlD6Pjq2Z41F/
JZ/1YlaSg3PXEbCJsk6tZbqAwEg3ywXK8UeKNRYINWpeI84/MHwwtUCNcVkKZlyXCjqfAAECBAgQ
GFWgx7XZqJbiJhAlkPJ8Mss1nJJzlLN2CEQJ2ESJktQOgYEFZrkhD1yCrkO30Om6PF0F1+tcYgx3
NUwEQ4AAAQIECLwo0Ot67UUSXRMgUEHAM1gFVE2+KmAT5VV+nRMYT8Cie7yaRUc8ymLoyVjd55Jz
TrTviO09cXsrr32N34pDvwQIECBAgACBHgV6Xsf16CUmAgSOBTx3Hbv4dB4Bmyjz1FImBF4RsOh+
hV2nBAjcCFjE3wD5mgABAgQIECDwj4BnOkOBAIEUAc9aKVqOnUXAJsoslZQHgY4ELMI7KoZQCCwk
YDG/ULGlSoAAAQIECIQLeI4LJ9UggWkEPGtNU0qJZArYRMmEcxoBAs8ELMSfOTmKAIE8AYv5PDdn
ESBAgAABAgSuBDzHXen4jsAaAp611qizLJ8J2ER55uQoAgSCBCzGgyA1Q2BxAQv6xQeA9AkQIECA
AIEmAp7fmjDrhMBrAp6rXqPX8WACNlEGK5hwCawuYBG/+giQ/8oCFvgrV1/uBAgQIECAwIgCnt9G
rJqYVxDwbLVCleUYKWATJVJTWwQIdClg4d5lWQRF4LGABf5jKgcSIECAAAECBLoT8DzWXUkEtLCA
Z6uFiy/1IgGbKEV8TiZAYEYBi/wZqyqnXgUs4nutjLgIECBAgAABAnECnrHiLLVEIFfAs1eunPMI
/PWXTRSjgAABAokCHgASwRxO4EDAAv4AxUcECBAgQIAAAQL/K+CZy0BoKZDybDLq2EzJsaW9vgiM
ImATZZRKiZMAgWEEel9UfRZPvcc5TMEF+ljAwv0xlQMJECBAgAABAgQIEJhAoOZzt+erCQaIFIYR
sIkyTKkESoAAgboCNRd3dSPXeu8CFve9V0h8BAgQIECAAAECBAgQIECAwJnAz7MvfE6AAAECawns
X3TbVFmr/jWy3Y+pGn1okwABAgQIECBAgAABAgQIECBQU8AmSk1dbRMgQGBgAS/ABy6e0AkQIECA
AAECBAgQIECAAAECBEIE/hXSikYIECBAgAABAgQIECBAgAABAgQIECBAgAABApMJ2ESZrKDSIUCA
AAECBAgQIECAAAECBAgQIECAAAECBGIEbKLEOGqFAAECBAgQIECAAAECBAgQIECAAAECBAgQmEzA
JspkBZUOAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECNgEyXGUSsECBAgQIAAAQIECBAgQIAAAQIE
CBAgQIDAZAI2USYrqHQIECBAgAABAgQIECBAgAABAgQIECBAgACBGAGbKDGOWiFAgAABAgQIECBA
gAABAgQIECBAgAABAgQmE7CJMllBpUOAAAECBAgQIECAAAECBAgQIECAAAECBAjECNhEiXHUCgEC
BAgQIECAAAECBAgQIECAAAECBAgQIDCZgE2UyQoqHQIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBG
wCZKjKNWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgckEbKJMVlDpECBAgAABAgQIECBAgAABAgQI
ECBAgAABAjECNlFiHLVCgAABAgQIECBAgAABAgQIECBAgAABAgQITCZgE2WygkqHAAECBAgQIECA
AAECBAgQIECAAAECBAgQiBGwiRLjqBUCBAgQIECAAAECBAgQIECAAAECBAgQIEBgMgGbKJMVVDoE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAjIBNlBhHrRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQKT
CdhEmayg0iFAgAABAgQIECBAgAABAgQIECBAgAABAgRiBGyixDhqhQABAgQIECBAgAABAgQIECBA
gAABAgQIEJhM4Odk+UiHAAECBAgQIECAAAECBAgQIFAs8OPHj9s2fv36dXuMAwgQIECAAIGxBWyi
jF0/0RMgQIAAAQIECBAgQIAAAQLBAk82ULYur46zwRJcFM0RIECAAIGXBGyivASvWwIECBAgQIAA
AQIECBAgQKA/gauNkZRov9vJ3VB5Ektu2ym5OJYAAQIECKwsYBNl5erLnQABAgQIECBAgAABAgQI
EKgucLYZst8AOTvuKsDtnH07V8f7jgABAgQIEEgTsImS5uVoAgQIECBAgAABAgQIECBAgECIQM6m
yVHHNlKOVHxGgAABAgRiBP4V04xWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCdhEmauesiFA
gAABAgQIECBAgAABAgQIECBAgAABAgSCBGyiBEFqhgABAgQIECBAgAABAgQIECBAgAABAgQIEJhL
wCbKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYBMlCFIzBAgQIECAAAECBAgQIECAwPgC
v379Gj8JGRAgQIAAAQJhAjZRwig1RIAAAQIECBAgQIAAAQIECMwgYCNlhirKgQABAgQIxAj8jGlG
KwQIECBAgAABAgQIECBAgACBeQS+N1J+/PgxT2IyIUCAAAECBJIEbKIkcTmYAAECBAgQIECAAAEC
BAgQWE3g6jdTbLCsNhrkS4AAAQKrCdhEWa3i8iVAgAABAgQIECBAgAABAgTCBPzGShilhggQIECA
QJcCNlG6LIugCBAgQIAAAQIECBAgQIAAgdEEbKiMVjHxEiBAgACBewGbKPdGjiBAgAABAkMLXP0V
E1d/NcXQSQcGf+W3dcMwEFtTBAgQIEBgEoG79cNRmjZgjlR8RoAAAQIE3hf41/shiIAAAQIECBCo
JXD3AH/3fa24Rmh3s3ni8+SYEfIVIwECBAgQIBAj8MbawB/qiKmdVggQIECAwJGA30Q5UvEZAQIE
CBCYQODpA/zT445Ien9gL8ntKN+zz7Z+erc4i93nBAgQIECAQIxAq3VHTLRaIUCAAAECBJ4K2ER5
KuU4AgQIECBA4A8BLwv+IPEBAQIECBAgsKCANdGCRZcyAQIECCwj4K/zWqbUEiVAgAABAgQIECBA
gAABAgSiBSI2UPx7KNFV0R4BAgQIEIgTsIkSZ6klAgQIECBAgAABAgQIECBAgEBTAX+laFNunREg
QIDAggI2URYsupQJECBAgAABAgQIECBAgACBPgRsgvRRB1EQIECAAIEzAZsoZzI+J0CAAAECBAgQ
IECAAAECBAhcCJT+VV42UC5wfUWAAAECBDoRsInSSSGEQYAAAQIECBAgQIAAAQIECIwjYANlnFqJ
lAABAgQIlAjYRCnRcy4BAgQIECBA4LeAP0VqGBAgQIAAgbUESjdQ1tKSLQECBAgQGFvAJsrY9RM9
AQIECBAg8LKADZSXC6B7AgQIECDQWCBiA+Vs/ZDa9lk7jUl0R4AAAQIEphawiTJ1eSVHgAABAgQI
1BTw4qKmrrYJECBAgEB/AqmbHEcZnK0fIto+6s9nBAgQIECAQJnAz7LTnU2AAAECBAgQWEvg7MXH
WgqyJUCAAAEC6wlEbHKcrSMi2l6vIjImQIAAAQJtBGyitHHWCwECBAgQINCRwNkLjI5CFAoBAgQI
ECDQkUDEJof1R0cFFQoBAgQIEEgQsImSgOVQAgQIECAwq8D2UB/xcuDMx0uDMxmfEyBAgAABAr0L
RKyRrIV6r7L4CBAgQIDAuYB/E+XcxjcECBAgQGApgZoP99vLh4gXEEsVRLIECBAgQIDA6wIR65ea
a6zXgQRAgAABAgQWELCJskCRpUiAAAECBHoRiHgR0Usu4iBAgAABAgTmFYj6AyA1N1Bqtj1vZWVG
gAABAgTSBWyipJs5gwABAgQITCvQ4mHcRsq0w0diBAgQIEBgCoGotUrNdVXNtqcooiQIECBAgECg
gE2UQExNESBAgACBGQRaPJRHvZyYwVsOBAgQIECAQD8CUWuUmuupmm33UwmRECBAgACBfgRsovRT
C5EQIECAAIFuBLaH89oP6FEvKbpBEwgBAgQIECAwtEDU2qT2GmpoZMETIECAAIEBBWyiDFg0IRMg
QIAAgVYCtV8CRL2saOWhHwIECBAgQGBOAWuSOesqKwIECBAgECFgEyVCURsECBAgQGBigdq/leKl
xcSDR2oECBAgQGAAgci1SO0/gDIApxAJECBAgMB0AjZRpiuphAgQIECAQB2Bz2ZKjZcDkS8v6mSv
VQIECBAgQGBGgcg1SI010ozmciJAgAABAqMJ2EQZrWLiJUCAAAECHQjU+O2UyJcYHRAJgQABAgQI
EOhcIHLtYQOl82ILjwABAgQIFAjYRCnAcyoBAgQIEFhdIHozJfJlxuq1kT8BAgQIECDQRsAGShtn
vRAgQIAAgbcEbKK8Ja9fAgQIECAwkUDkZoqNlIkGhlQIECBAgECnAlHrDRsonRZYWAQIECBAIFDA
JkogpqYIECBAgMDqAlGbKVEvNlavh/wJECBAgACBPwWi1hk2UP609QkBAgQIEJhRwCbKjFWVEwEC
BAgQeFkg4qVC1AuOlyl0T4AAAQIECEwmEPWHRiZjkQ4BAgQIEJhWwCbKtKWVGAECBAgQeFcgYiPl
3Qz0ToAAAQIECMwmUPqHNKxvZhsR8iFAgAABAvcCNlHujRxBgAABAgQIZAqUvmgofdGRGbbTCBAg
QIAAgQkFStcVpeuaM9LSuM7a9TkBAgQIECAQI2ATJcZRKwQIECBAgMCJQK0XDifd+ZgAAQIECBAg
8IdA6UZFrfVMaVx/JOoDAgQIECBAIFzAJko4qQYJECBAgACBvUDJiwcvF/aafiZAgAABAgRSBErX
EiXrmKs4S+O6att3BAgQIECAQJyATZQ4Sy0RIECAAAECFwK1XkBcdOkrAgQIECBAYHGB0o0K65fF
B5D0CRAgQIDAbwGbKIYBAQIECBAg0Ewg90VE6QuQZgnqiAABAgQIEOhGwPqhm1IIhAABAgQIDC1g
E2Xo8gmeAAECBAisI+BFyDq1likBAgQIECgViFg35P7hj9LYnU+AAAECBAj0JWATpa96iIYAAQIE
CEwv4IXE9CWWIAECBAgQGF7AemX4EkqAAAECBAiECdhECaPUEAECBAgQIFBbIOJPldaOUfsECBAg
QIDAuwKl6wUbKO/WT+8ECBAgQKA3AZsovVVEPAQIECBAYAGBkpcTpS9GFuCVIgECBAgQIJApULJG
yezSaQQIECBAgEDnAjZROi+Q8AgQIECAAIE/BWyk/GniEwIECBAgQOCvv0ZaI+Rs2OScY1wQIECA
AAECZQI2Ucr8nE2AAAECBLoUGOEFgpcAXQ4dQREgQIAAgWEFStc/b6xNUvpMOXbYIgqcAAECBAh0
KPCzw5iERIAAAQIECCwisL0MyH3h8TnPC4VFBos0CRAgQIDAhUDueuLT5JvriTf7viD1FQECBAgQ
IPCPgN9EMRQIECBAgACB7I2MHuhKX5r0kIMYCBAgQIAAgXyB0rWATYx8e2cSIECAAIEVBGyirFBl
ORIgQIAAgQcCpS8gHnRxeEjEi4u3Yj9MyIcECBAgQIBAM4HSNUDEOqRZsjoiQIAAAQIEXhGwifIK
u04JECBAgACBb4GIFxilL1FUhAABAgQIEBhLwL1/rHqJlgABAgQIjCpgE2XUyombAAECBAhMJmAj
ZbKCSocAAQIECFQUiNhAiVh7VExR0wQIECBAgEAnAjZROimEMAgQIECAAIEYgYiXKjGRaIUAAQIE
CBAgQIAAAQIECBAYXcAmyugVFD8BAgQIEJhIIOpPhNpImWhQSIUAAQIECOwEIu7zUWsOxSFAgAAB
AgTmF7CJMn+NZUiAAAECCwqM/GJg5NgXHGpSJkCAAAECTQVsoDTl1hkBAgQIECDwW8AmimFAgAAB
AgQmFRh5MyIi9oiXLJMODWkRIECAAIEhBSLu7RFrjCHxBE2AAAECBAhkC9hEyaZzIgECBAgQIFBT
IOIlR8TLlpo5apsAAQIECBB4JhBxT49YWzyL1lEECBAgQIDATAI2UWaqplwIECBAgMBOYPSXBRHx
R7x0MbAIECBAgACB9wQi7uURa4r3BPRMgAABAgQIvClgE+VNfX0TIECAAIEGAk9fGjw9rkHI/9XF
FlevsbW20B8BAgQIEFhNwAbKahWXLwECBAgQ6E/AJkp/NRERAQIECBAIF7jbhLj7PjygjAZLYox4
AZMRslMIECBAgACBlwVK1g8vh657AgQIECBAoBOBn53EIQwCBAgQIECgssDqLxG2jZTVDSoPMc0T
IECAAIGuBNz3uyqHYAgQIECAwLACfhNl2NIJnAABAgQIrCdQ+jLEb6SsN2ZkTIAAAQLjCpTct0vX
DOOqiZwAAQIECBCIFrCJEi2qPQIECBAgQKCqgJciVXk1ToAAAQIEuhCwgdJFGQRBgAABAgQI/Baw
iWIYECBAgAABAsMJlGyklLyUGQ5KwAQIECBAYEAB9+oBiyZkAgQIECAwsYBNlImLKzUCBAgQIEDg
WMDLmWMXnxIgQIAAgdEFSv6gxei5i58AAQIECBCoI2ATpY6rVgkQIECAAIHKAqUvSWykVC6Q5gkQ
IECAQIZAyf25dG2QEa5TCBAgQIAAgQUEbKIsUGQpEiBAgACBWQW8LJm1svIiQIAAgRUFSjZQVvSS
MwECBAgQINBGwCZKG2e9ECBAgAABApUESjZSvKypVBTNEiBAgACBBIHtflx6Ty5ZDySE6lACBAgQ
IEBgQQGbKAsWXcoECBAgQIDAfwRKX9qwJECAAAECBPIFIu7DNlDy/Z1JgAABAgQI3AvYRLk3cgQB
AgQIECDQuYCXJ50XSHgECBAgQOBAwAbKAYqPCBAgQIAAge4EbKJ0VxIBESBAgAABAjkCJRspES9x
cmJ2DgECBAgQWFXAvXfVysubAAECBAiMJ2ATZbyaiZgAAQIECBA4EbCRcgLjYwIECBAgMKFAyX1/
Qg4pESBAgAABApUEbKJUgtUsAQIECBAgQIAAAQIECBAg8KdAxG+h2ED509UnBAgQIECAQB0Bmyh1
XLVKgAABAgQIvCRQ8lIl4qXOS2nrlgABAgQILCNQcq9fBkmiBAgQIECAQJiATZQwSg0RIECAAAEC
vQiUvFyxkdJLFcVBgAABAjMKlN5nS+7xM3rKiQABAgQIEKgvYBOlvrEeCBAgQIAAgcEESl/wDJau
cAkQIECAQBOB0vurDZQmZdIJAQIECBAgsBOwiWJIECBAgAABAlMKlL5oKX3RMyWqpAgQIECAwEsC
pff1l8LWLQECBAgQIDCBgE2UCYooBQIECBAgQOBYoPSFy7aRYjPl2NanBAgQIEAgRaDkflp6P0+J
07EECBAgQIAAgb2ATZS9iJ8JECBAgAABAjuBkhc/MAkQIECAwOoCJfdRGyirjx75EyBAgACB9wVs
orxfAxEQIECAAAECFQWiXr6UvACqmJ6mCRAgQIBA1wLun12XR3AECBAgQIDAAwGbKA+QHEKAAAEC
BAiMLWAjZez6iZ4AAQIExhOI+Csxo+7f4+mJmAABAgQIEOhJwCZKT9UQCwECBAgQINC9gD9R232J
BEiAAAECLwtE3CttoLxcRN0TIECAAAEC/xawiWIwECBAuEBFkQAAIABJREFUgAABAksIRL6MiXg5
tAS6JAkQIEBgOQH3yOVKLmECBAgQIDC9gE2U6UssQQIECBAgQOAjELmRQpUAAQIECBD4b4GoDRT3
ayOLAAECBAgQ6EnAJkpP1RALAQIECBAgUF0g6sVM1Iui6gnrgAABAgQIDCQQdZ8eKGWhEiBAgAAB
Ap0L2ETpvEDCI0CAAAECBOIFol7Q2EiJr40WCRAgQGBMgYh7YtT9eUxBURMgQIAAAQK9CthE6bUy
4iJAgAABAgSqCmwvaiJe1kS8NKqaqMYJECBAgEBlgYh7YcQ9uXKamidAgAABAgQWFfjxe6Hya9Hc
pU2AAAECBAgQ+F+BiJc/WzuWVQYUAQIECKwk4P65UrXlSoAAAQIE1hXwmyjr1l7mBAgQIECAwD8C
fivFUCBAgAABAmkCNlDSvBxNgAABAgQIjCtgE2Xc2omcAAECBAgQ6FAg6qVSh6kJiQABAgQI/K9A
1L3Ob3AaUAQIECBAgMAIAjZRRqiSGAkQIECAAIEmAlEvc6JeLjVJWicECBAgQCBBIOoeF3XPTQjd
oQQIECBAgACBLAGbKFlsTiJAgAABAgRmFYh6qRP1kmlWZ3kRIECAwHgCUfe2qHvteIIiJkCAAAEC
BEYUsIkyYtXETIAAAQIECFQViHq5E/WyqWqyGidAgAABAg8E3NMeIDmEAAECBAgQmFLAJsqUZZUU
AQIECBAg0IuAl069VEIcBAgQIJArEHkvi/qDCrm5OI8AAQIECBAgkCpgEyVVzPEECBAgQIDAEgKR
L3kiXz4tgS9JAgQIEOhGIPIeFnlv7QZIIAQIECBAgMD0AjZRpi+xBAkQIECAAIFcAS97cuWcR4AA
AQIzCNhAmaGKciBAgAABAgRKBWyilAo6nwABAgQIEJhawEbK1OWVHAECBAicCERtoGz3UffSE2Qf
EyBAgAABAkMI2EQZokyCJECAAAECBN4UiHgBFPUy6k0HfRMgQIDAGgJR9yybJ2uMF1kSIECAAIHZ
BWyizF5h+REgQIAAAQJhAl4GhVFqiAABAgQ6FYjYQIn4wwed8giLAAECBAgQWFDAJsqCRZcyAQIE
CBAgkC9QspES8WIqP3JnEiBAgACBa4GI+1TJffI6Ot8SIECAAAECBN4RsInyjrteCRAgQIAAgYEF
Sl4QRbygGphO6AQIECDQqYD7U6eFERYBAgQIECDwuoBNlNdLIAACBAgQIEBgRIGSjZQR8xUzAQIE
CMwrELWB4t447xiRGQECBAgQWFng58rJy50AAQIECBAgQIAAAQIECKwqELV5svnZQFl1FMmbAAEC
BAjML+A3UeavsQwJECBAgACBSgJeGFWC1SwBAgQIVBewgVKdWAcECBAgQIDAJAI2USYppDQIECBA
gACBcQQiX1yNk7VICRAgQKAXgaj70PaHCfyBgl6qKg4CBAgQIECgloBNlFqy2iVAgAABAgSWEMh9
eRT1AmsJZEkSIECAQJhA1P0n9/4XloiGCBAgQIAAAQKNBGyiNILWDQECBAgQIDCvgBdJ89ZWZgQI
ECDwp4D73p8mPiFAgAABAgTmFbCJMm9tZUaAAAECBAh0LhD1p4E7T1N4BAgQIDCRgA2UiYopFQIE
CBAgQOCRgE2UR0wOIkCAAAECBAgQIECAAAECYwuUbt7bQBm7/qInQIAAAQIE8gRsouS5OYsAAQIE
CBAgECJQ+kIrJAiNECBAgMD0AqX3Gxso0w8RCRIgQIAAAQInAjZRTmB8TIAAAQIECBBIEfByKUXL
sQQIECDQUsAGSkttfREgQIAAAQKzCdhEma2i8iFAgAABAgReE8jdSCl9ufVawjomQIAAge4FSu8x
ufe27mEESIAAAQIECBB4KGAT5SGUwwgQIECAAAECNQVKX3LVjE3bBAgQIDCmQOm9xQbKmHUXNQEC
BAgQIBArYBMl1lNrBAgQIECAwOICJS+cSl92LU4vfQIECBD4EnBPMRwIECBAgAABAjECNlFiHLVC
gAABAgQIEAgR8NIrhFEjBAgQWFog4l5S8ocClsaXPAECBAgQIDCdgE2U6UoqIQIECBAgQOBtgdIX
TxEvv9420D8BAgQIjCtQeh8bN3OREyBAgAABAgT+FLCJ8qeJTwgQIECAAAECBAgQIECAwJICNlCW
LLukCRAgQIAAgQuBH78XSL8uvvcVAQIECBAgQIBApkDUb5RYrmUWwGkECBBYUKDk3uN+s+CAkTIB
AgQIECBwK+A3UW6JHECAAAECBAgQyBOIehlV8kIsL3JnESBAgMBqAlH3rNXc5EuAAAECBAjML2AT
Zf4ay5AAAQIECBCYQGDbSLGZMkEhpUCAAIEOBWygdFgUIREgQIAAAQLdCNhE6aYUAiFAgAABAgRm
FIh+MWUzZcZRIicCBAjECORstkffp2Iy0QoBAgQIECBAoB8Bmyj91EIkBAgQIECAwKQCNV5Q5bwo
m5RXWgQIECBAgAABAgQIECBAoJrAz2ota5gAAQIECBAgQODfAttGSvTGx769Gps1SkiAAAECBAgQ
IECAAAECBFYW8JsoK1df7gQIECBAgEBTgdqbHPtNlabJ6YwAAQIEhhOofV8aDkTABAgQIECAAIED
AZsoByg+IkCAAAECBAjUEqj9wsq/mVKrctolQIAAAQIECBAgQIAAgRUFbKKsWHU5EyBAgAABAq8K
1N5I2ZLzWymvlljnBAgQaC5g3m9OrkMCBAgQIEBgEQGbKIsUWpoECBAgQIBAXwKtNlK8VOur7qIh
QIBADYGcub7FfahGrtokQIAAAQIECLQWsInSWlx/BAgQIECAAIF/BFq9wPJXfBlyBAgQmFcgZwNl
Xg2ZESBAgAABAgTiBX7GN6lFAgQIECBAgACBpwLfGym1X4R92m+1efPUwHEECBAgQIAAAQIECBAg
QKBXAb+J0mtlxEWAAAECBAgsJ9Bqc+Pzmym1N22WK6CECRAg0FjAPN4YXHcECBAgQIDAkgI2UZYs
u6QJECBAgACBXgW2jZRWmymbgb/qq9eRIC4CBAhcC9hAufbxLQECBAgQIEAgSsAmSpSkdggQIECA
AAECgQJvbKYEhq8pAgQIEOhYoOVmfccMQiNAgAABAgQIPBKwifKIyUEECBAgQIAAgXcEWr7o8qea
36mxXgkQIJAqUDJft7yvpObleAIECBAgQIBAjwL+YfkeqyImAgQIECBAgMCXwP6FV8nLszvYre19
f3fn+J4AAQIExhAwv49RJ1ESIECAAAECfQn4TZS+6iEaAgQIECBAgMCtQO2XYDU3aW6TcwABAgQI
XAqYoy95fEmAAAECBAgQCBewiRJOqkECBAgQIECAQH2B1v9mSv2M9ECAAAECdwIlGyi1N+DvYvc9
AQIECBAgQGBUAZsoo1ZO3AQIECBAgACB3wK1XoqVvKhTGAIECBCIFyiZl2vdK+Kz1CIBAgQIECBA
oD8Bmyj91UREBAgQIECAAIEkgVq/lVLywi4pAQcTIECAAAECBAgQIECAAIFOBWyidFoYYREgQIAA
AQIEUgVqbKbYSEmtguMJECDQl4DfQumrHqIhQIAAAQIExhOwiTJezURMgAABAgQIELgUiN5MsZFy
ye1LAgQIECBAgAABAgQIEJhY4OfEuUmNAAECBAgQILC0wPefPrYRsvRQkDwBAoML5M7hfgtl8MIL
nwABAgQIEOhCwG+idFEGQRAgQIAAAQIE6gqUvkjbXuDlvsSrm5nWCRAgMLdA7txbOu/PrSo7AgQI
ECBAgMBzAZsoz60cSYAAAQIECBAYWiDihVruy7yh4QRPgACBwQQi5vvBUhYuAQIECBAgQKCagE2U
arQaJkCAAAECBAj0JxDxYu3zWyk2VPqrr4gIEJhLwDw7Vz1lQ4AAAQIECIwpYBNlzLqJmgABAgQI
ECCQLRCxkfLp3Au+7DI4kQABApcC5tdLHl8SIECAAAECBJoJ2ERpRq0jAgQIECBAgEA/AjZS+qmF
SAgQIECAAAECBAgQIECgXwGbKP3WRmQECBAgQIAAgWEEPn/F1zABC5QAAQIdC5T8FkrkJnnHREIj
QIAAAQIECDQTsInSjFpHBAgQIECAAIG+BGq8aCt58deXjmgIECDwjkDJPFpjXn9HQa8ECBAgQIAA
gX4EfvYTikgIECBAgAABAgRaC2wv3Epe2B3Fu7XnRd6RjM8IEOhR4GoObD2XXcXSo52YCBAgQIAA
AQIrCPhNlBWqLEcCBAgQIECAwIVAjZeEXgRegPuKAIFuBO7mqrvvIxMp7avGXB6Zn7YIECBAgAAB
AqMK2EQZtXLiJkCAAAECBAgECtR4+Vb6QjAwPU0RIEDgD4Gnc9TT4/7oIOGD0j5qzOEJ4TuUAAEC
BAgQIDC1gE2UqcsrOQIECBAgQIDAc4EaL+FKXww+j96RBAgQGFPAPDlm3URNgAABAgQIrCPw4/fD
8q910pUpAQIECBAgQIDAE4EaL/Wil51XMUb39cTMMQQIjCVwNYccZVJjXkmNoVVcR/34jAABAgQI
ECCwqoDfRFm18vImQIAAAQIECFwI1HpZuL0wjHhpeNfG3fcXqfuKAAECTQQi5qkac3WT5HVCgAAB
AgQIEBhIwG+iDFQsoRIgQIAAAQIE3hKIeNm3jz335V9qLLn97OP1MwECcwmkziVb9hHzSU6/R/IR
sRy16zMCBAgQIECAAIH/FvCbKEYEAQIECBAgQIDArUCNl3VRLxLvgm/Vz10cvidAgEDUfFRjTlYd
AgQIECBAgACBYwGbKMcuPiVAgAABAgQIENgJ1HhpF/VC8a5Yrfq5i8P3BAisKxA1D9WYi9etiswJ
ECBAgAABAvcCNlHujRxBgAABAgQIECDwj8D28i76BV7Ui8W7Im39fP67O9b3BAgQiBSImuei59/I
HLVFgAABAgQIEJhVwCbKrJWVFwECBAgQIECgokD0i7yoF4xPU27d39O4HEeAwHwCUfNN9Lw7n7SM
CBAgQIAAAQJ1BH7WaVarBAgQIECAAAECswtsL/SiXg6+YbXF7qXkG/JlfUaMOXUvq8EsZ480hxmz
s4w6eRAgQIAAAQIjCthEGbFqYiZAgAABAgQIdCIQ+RLyjU2NN/rspHRDhRGxcfKd8FF7XlIPNSSG
CfZorKUGb2ymijmeAAECBAgQIBArYBMl1lNrBAgQIECAAIHlBEbfSFmuYAMkHPHiOTXN7z69tE7V
G/f4yPlrrxAxjo3FvaqfCRAgQIAAAQLtBfybKO3N9UiAAAECBAgQmE4g8kXf3YvHyL62Qtz1N12x
Ok1oq8Pnv7dD7CWOtx30ny8QMa9Ez3X52TiTAAECBAgQILC2gN9EWbv+sidAgAABAgQIhAl8XvhF
vDy8Cyr6T49vMXtheace/32LsVIS9Xd8xkeJ5FrnRoxr422tMSNbAgQIECBAoG+BH78XZ7/6DlF0
BAgQIECAAAECowqUvEx8skwtaf/I9EmfR+f57FwgukbnPbX9xlhp612zt5Qxelf3lLbOcrrr4+w8
nxMgQIAAAQIECNQR8JsodVy1SoAAAQIECBAgUCjweRl59ULx+7uIl5dbG1f9Faa0zOkRtegdy1jp
vULt44sY9+af9nXTIwECBAgQIEDgTsC/iXIn5HsCBAgQIECAAIFsgYgXgk9fTEb0tSX6tL9slElP
3Nw+/02a4h9prZbvHwA++LdAxLwRNYcpCwECBAgQIECAQKyATZRYT60RIECAAAECBAjsBCJeDD59
QRnR1xb+0/7+f3v3th23rQMAtM7K//+yT9R0TpzxjG4ESZDcD33wSCKBDTorBSJbsX8LrO5lmLL2
d0LE+Y/6s2vtSsieAAECBAgQIFBHwBCljqtVCRAgQIAAAQIEvghENAjPNiq3vVrut3KhDQ/+rv7Z
M7rymZkt94iaR/x5NZurfAgQIECAAAECmQQMUTJVQywECBAgQIAAAQK7Ao+m/ZnGZURj8sw+uwFP
fJHN6+Jyee0y46cRtY74c2pGWzkRIECAAAECBDIJfPz6S9tnpoDEQoAAAQIECBAgMK9ARNPxWefo
r7MRex7t8RzTzF9HeNbweVWjnrG+iqdG3tYsF7hyTh51vfLMuwidkXcyPidAgAABAgQI5BIwRMlV
D9EQIECAAAECBKYXiGg+PiMdNSNL9zxa/zmeGb8uNaxhcqcuLfO4E18NJ2vuC1w5E1tNr9z/bmdn
452MzwkQIECAAAEC+QQMUfLVREQECBAgQIAAgekFIpqQz0hHTcnSPY/Wf45npq9L7aIsomvQIq/o
mKMsrfNHoMU5+OrtTDh9BAgQIECAAIGxBAxRxqqXaAkQIECAAAEC0wjUaFweNScj9jzaY5oC/ZdI
hFmJSQvv3jl+9WmRb0k9Zny2Zf3Vd8YTJCcCBAgQIEBgdgFDlNkrLD8CBAgQIECAQGKB6OblmQZl
xJ5n9knMfjq0CKvTm325sadvr5xHc7oTb9ZnWtW857nOai8uAgQIECBAgMAIAoYoI1RJjAQIECBA
gACBiQVqNDCPmpURex7tMXrJIoz2DDL71c59z6XkWmbTkrxqP9uq3upTu5LWJ0CAAAECBAjUEfhR
Z1mrEiBAgAABAgQIEDgnUKOxeNQUjdjzaI9z2ee8q1Zum/vjv5yZjx1VrbqNrZIj+og/c3JkIgoC
BAgQIECAwHoChijr1VzGBAgQIECAAIF0AjUajBrK98oc7WZwcq8Od5/a6hddw7uxeO63QI0/39gS
IECAAAECBAi0EzBEaWdtJwIECBAgQIAAgR2B1m8oRDQ2Z2tWR+cTYbxzZFzaEXgMU6JrurOlSy8E
fA+8QPERAQIECBAgQGAwgZ+DxStcAgQIECBAgACByQW2pmOrxm/EXlusMzRKI81n8Jjp22yWMzpa
TbJ9Hxx9j2eLd7R6i5cAAQIECBCYV8CbKPPWVmYECBAgQIAAgWEFtmZeq4ZexD5HzcnshYiMP8Iz
u9eI8UXWeMT8V4x5q/nX/44MnJEjIdcJECBAgACBVQUMUVatvLwJECBAgAABAgMItBqmRDT+R21A
RsXdqlYDHFshDiQQdf6fU474M+V5zbNfPwYnZ+//el8tjzuxeIYAAQIECBAgkEXAECVLJcRBgAAB
AgQIECDwVqBFQzJij9EakBHxzjg8iTgLbw9zxwsR9e4Y/jBb9zo/JcOTYXAFSoAAAQIECBDoIGCI
0gHdlgQIECBAgAABAjkFIpqfozSqI+KM8Mp5Ev5p9uPksua/QlwR3wMZnAxPMlRBDAQIECBAgMDM
An6x/MzVlRsBAgQIECBAYCKBrWF/pel5t8F/dZ+JiC+lctf30iadb66Z45WzHMmw7Vszr8hYa67V
y/9uTqPFezdPzxEgQIAAAQIEMgp8/PoL9GfGwMREgAABAgQIECBA4JXAmWZixF9xz+zzKr7HZxEx
7K1fcm3m3Epcsj5bWq9XeWU+n6/ijfyshufX+CJsa8e45xkR/976rhEgQIAAAQIERhMwRBmtYuIl
QIAAAQIECBBoJlDayMzYjJwxp2YHIslGpTV8pJHxfNYmjrLbi3PPtcX+e7GdubYX/5nn3UOAAAEC
BAgQmE3Aj/OaraLyIUCAAAECBAgQCBPYmokjND3PJlyai+bqWem690Wdy8d5UNe4en21LP1+i4vK
SgQIECBAgAABAiUC3kQp0fMsAQIECBAgQIDAbYG9BmO2pu5erHsAmfK4m8Mjv0y57Jmvdq20rqvV
N8pr1nPm+3zWysqLAAECBAgQKBH4UfKwZwkQIECAAAECBAjcEThqZB5dv7NnyTN3G4tZ8iiN427+
JeaePScQVZvtjJSek3MR97tr9vxKZaPOUmkcnidAgAABAgQIZBMwRMlWEfEQIECAAAECBCYXONvI
PHtfdq5Z8sjuLL4YgccwxbmN8RxhlW14YoAyQqXESIAAAQIECPQS8DtResnblwABAgQIECBA4FBg
a+S2bO5pHH8vSUv/77v75IzAVqMaZ7f199+ZXN1TLuB7utzQCgQIECBAgMBaAoYoa9VbtgQIECBA
gACB4QSuNnJrNJOHQ/sScImHZus4la85SNkUnIVxzsK7SNXwnYzPCRAgQIAAAQL7An6x/L6PqwQI
ECBAgAABAsECJU3951C+NgUj133eJ+LrHg3MEpMe8UY4r75GSc2P7EY/EzVtjux6Xh+9bj3t7E2A
AAECBAgQ2AS8ieIcECBAgAABAgQIDCuwalP0TMFKbDRdzwjnvGerXUnt97J6ta6zsifW95ra9PW3
OwECBAgQIDCPgCHKPLWUCQECBAgQIECAAIF/BV41u8/SaLyelcp7X81BynPWz2fN+XkWqvs177q+
VidAgAABAgQIbAKGKM4BAQIECBAgQIAAgYkEnpvaE6UmlQsCLQcpX8Pazp/G/oVCXbyV7UUwtxMg
QIAAAQIEAgQMUQIQLUGAAAECBAgQIEAgg4ABSoYq5Imh5yBlU9DwP38WWJ23cicBAgQIECBAoLWA
IUprcfsRIECAAAECBBYX6NXYXZxd+osKfG3Otx6yeSvl9aEzMHnt4lMCBAgQIECAQFYBQ5SslREX
AQIECBAgQGBiAYOU+OJGNMg1d+PrkmnFHt93sw9SfM9kOuFiIUCAAAECBAjUEfhRZ1mrEiBAgAAB
AgQIENgXWKn5OEKuI8S4f6JcPSOw1bl1rSMGfGdyO7onMu8ejkf5uU6AAAECBAgQIFBH4OPXX/4+
6yxtVQIECBAgQIAAAQLHAlkarMeR3rujxV+3Sw1bxHhPz1MtBErPz9kYs5yzknyz5HDW3H0ECBAg
QIAAAQLlAoYo5YZWIECAAAECBAgQKBQoaWoWbn3q8eyN0xK/7LmdKpCbigVKztCVzZ23K1ruJUCA
AAECBAgQyCBgiJKhCmIgQIAAAQIECBD4p3YTd9bm7V23WT18K5UJ3D1PV3Z19q5ouZcAAQIECBAg
QKC3gF8s37sC9idAgAABAgQIEPhXYK+xWtLY3VsXPQECfwts3y8l329nPLf1fV+ekXIPAQIECBAg
QIBABgFDlAxVEAMBAgQIECBAgMCugIbrLs/lizwvky31wKvzUXuwshSwZAkQIECAAAECBIYSMEQZ
qlyCJUCAAAECBAgQIPBHQGPbaWgl8DxYKT173kZpVTn7ECBAgAABAgQIlAr8KF3A8wQIECBAgAAB
AgQIjCPw3AwfJ3KRZhKIOEelg5hMHmIhQIAAAQIECBCYV8AQZd7ayowAAQIECBAgQGBiAQ3oiYs7
SGrbIKV0mOIcD1JsYRIgQIAAAQIEFhYwRFm4+FInQIAAAQIECBBYS6C04b2WlmzPCpSeK4OUs9Lu
I0CAAAECBAgQ6CFgiNJD3Z4ECBAgQIAAAQIECBCYSMAgZaJiSoUAAQIECBAgQOAvAUMUB4IAAQIE
CBAgQIAAAQIEugt4I6V7CQRAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAjMJlD6psBsHvKJF3DG
4k2tSIAAAQIECBAg0F/AEKV/DURAgAABAgQIECBAgACBKQRKByneRpniGEiCAAECBAgQIDCVgCHK
VOWUDAECBAgQIECAAIHvAqWN7e8r+oTAe4HS87YNUgxT3vu6QoAAAQIECBAg0FbAEKWtt90IECBA
gAABAgQIFAtoMBcTWqCyQOkgZQvPOa9cJMsTIECAAAECBAicEjBEOcXkJgIECBAgQIAAAQI5BDSW
c9RBFMcCBinHRu4gQIAAAQIECBDIL2CIkr9GIiRAgAABAgQIECDwr4ABioMwmoBBymgVEy8BAgQI
ECBAgMCzgCHKs4ivCRAgQIAAAQIECBAgQCCVgAFiqnIIhgABAgQIECCwlIAhylLlliwBAgQIECBA
gAABAgTaCkS8jbJFbJDStm52I0CAAAECBAgQ+C1giOIkECBAgAABAgQIECBAgEBVgahBStUgLU6A
AAECBAgQIEDghYAhygsUHxEgQIAAAQIECBDIJnD3X+FrXmer5LrxOIvr1l7mBAgQIECAAIGRBQxR
Rq6e2AkQIECAAAECBAjsCGha7+C41EWg9EzeHSZ2SdamBAgQIECAAAECUwgYokxRRkkQIECAAAEC
BAjMLHCncVzarJ7ZU259BZzNvv52J0CAAAECBAgQuCZgiHLNy90ECBAgQIAAAQIECBAgUChQMki5
M1QsDNfjBAgQIECAAAECCwsYoixcfKkTIECAAAECBAgQIECgl8A2SCkZpvSK274ECBAgQIAAAQJr
CRiirFVv2RIgQIAAAQIECBAgQIAAAQIECBAgQIAAAQInBQxRTkK5jQABAgQIECBAgMAoAv51/yiV
EicBAgQIECBAgAABAtkFDFGyV0h8BAgQIECAAAECBAgQmFjA0G/i4kqNAAECBAgQIDCBgCHKBEWU
AgECBAgQIECAAIGHgIa0s0CAAAECBAgQIECAAIE4AUOUOEsrESBAgAABAgQIECBAgMANAcO/G2ge
IUCAAAECBAgQaCJgiNKE2SYECBAgQIAAAQIECBAgECXw8fERtZR1CBAgQIAAAQIECOwKGKLs8rhI
gAABAgQIECBAoK+AZnFff7sTIECAAAECBAgQILC2gCHK2vWXPQECBAgQIECAAAECBAgQIECAAAEC
BAgQIPBGwBDlDYyPCRAgQIAAAQIECBAgQIAAAQIECBAgQIAAgbUFDFHWrr/sCRAgQIAAAQIECBAg
QIAAAQIECBAgQIAAgTcChihvYHxMgAABAgQIECBAgAABAnkF/L6gvLURGQECBAgQIEBgJgFDlJmq
KRcCBAgQIECAAAECBAgMKvD5+Xk5coOUy2QeIECAAAECBAgQuChgiHIRzO0ECBAgQIAAAQIEsgrc
aUJnzUVcBM4KGKSclXIfAQIECBAgQIDAHQFDlDtqniFAgAABAgQIECBAgAABAgQIECBAgAABAgSm
FzBEmb7EEiRAgAABAgQIEBhVwL+wH7Vy4m4t4Ht9CHEEAAAgAElEQVSltbj9CBAgQIAAAQLrCPxc
J1WZEiBAgAABAgQIEBhHQFN4nFrVjPToHPgRbn/0NyseNU+jtQkQIECAAAECawp4E2XNusuaAAEC
BAgQIECAAIHkAkcDlC38M/ckT/Ov8EqHILN5jFQ7sRIgQIAAAQIEZhUwRJm1svIiQIAAAQIECBAY
VkAjeNjShQV+5QxcuTcswIoLGaRUxLU0AQIECBAgQIDAZQE/zusymQcIECBAgAABAgQI1BOYrSFe
T+r9ymcNS5v17yNwpVRgq83ZOpbu5XkCBAgQIECAAAECewLeRNnTcY0AAQIECBAgQIAAgaEErjTe
r9w7FIJgDWCcAQIECBAgQIAAgTABQ5QwSgsRIECAAAECBAgQ6CfgrYp7vx/EIKXfmbUzAQIECBAg
QIAAgREEDFFGqJIYCRAgQIAAAQIElhC429A3QFnieCyXZOm5vvv9tBy0hAkQIECAAAECBHYFDFF2
eVwkQIAAAQIECBAgQIAAgV4CBim95O1LgAABAgQIECDwEDBEcRYIECBAgAABAgQIDCxQ2mQeOHWh
LyLgjC9SaGkSIECAAAECBJIKGKIkLYywCBAgQIAAAQIECBwJaC4fCY17/Uptr9w7qkhJjn6s16hV
FzcBAgQIECBAIIeAIUqOOoiCAAECBAgQIECAAAECfwmcGRycuWcW1pVynaVm8iBAgAABAgQIzCDw
c4Yk5ECAAAECBAgQIEBgdAH/Wn70CtaJ3+AgxnX7/mIZY2kVAgQIECBAgMBqAt5EWa3i8iVAgAAB
AgQIEJhCQEM4powcYxxbraJeraTtQ4AAAQIECBAg8BAwRHEWCBAgQIAAAQIECBCYQuBqg/3q/VMg
TZCEuk1QRCkQIECAAAECBAYS8OO8BiqWUAkQIECAAAECBAgQ2BfYGux7PxpNA37fz1UCBAgQIECA
AAECBP4WMERxIggQIECAAAECBAgQmErAoGSqcr5M5mhY9uohvxfllYrPCBAgQIAAAQIEjgT8OK8j
IdcJECBAgAABAgQIVBbYe3Oi8taWJ0CAAAECBAgQIECAAIEdAUOUHRyXCBAgQIAAAQIECGQU8KZF
xqqIqbWA74PW4vYjQIAAAQIECKwpYIiyZt1lTYAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwIGKIc
ALlMgAABAgQIECBAgAABAgQIECBAgAABAgQIrClgiLJm3WVNgAABAgQIECBAgAABAgQIECBAgAAB
AgQIHAgYohwAuUyAAAECBAgQIECgpsDVXyrv90DUrIa1RxPw/TBaxcRLgAABAgQIEBhPwBBlvJqJ
mAABAgQIECBAYBKBqwOUSdKWBgECBAgQIECAAAECBIYRMEQZplQCJUCAAAECBAgQIECAAAECBAgQ
IECAAAECBFoKGKK01LYXAQIECBAgQIAAgf8EvIXiKBAgQIAAAQIECBAgQCC/gCFK/hqJkAABAgQI
ECBAYDIBA5TJCiodAgQIECBAgAABAgSmFTBEmba0EiNAgAABAgQIECBAgMDcAgaSc9dXdgQIECBA
gACBDAKGKBmqIAYCBAgQIECAAAECJwQ+Pz9P3OUWAgQIECBAgAABAgQIEIgSMESJkrQOAQIECBAg
QIAAgYoCBigVcS1NgAABAgQIECBAgACBNwKGKG9gfEyAAAECBAgQIECAAAECBAgQIECAAAECBAis
LWCIsnb9ZU+AAAECBAgQIDCAgLdQBiiSEAkQIECAAAECBAgQmFLAEGXKskqKAAECBAgQIEBgFgED
lFkqKQ8CBAgQIECAAAECBEYUMEQZsWpiJkCAAAECBAgQIECAAIFLAgaSl7jcTIAAAQIECBAg8J+A
IYqjQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBB4IWCI8gLFRwQIECBAgAABAgQIECBAgAABAgQI
ECBAgAABQxRngAABAgQIECBAgAABAgQIECBAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAgQIECA
AAECBAgQIECAAAEChijOAAECBAgQIECAAAECBAgMJ/Dx8TFczAImQIAAAQIECBAYT8AQZbyaiZgA
AQIECBAgQIAAAQIECBAgQIAAAQIECBBoIGCI0gDZFgQIECBAgAABAgQIECBAgAABAgQIECBAgMB4
AoYo49VMxAQIECBAgAABAgQIECBAgAABAgQIECBAgEADAUOUBsi2IECAAAECBAgQIECAAAECBAgQ
IECAAAECBMYTMEQZr2YiJkCAAAECBAgQIECAAAECBAgQIECAAAECBBoIGKI0QLYFAQIECBAgQIAA
AQIECPQT+Pz87Le5nQkQIECAAAECBIYWMEQZunyCJ0CAAAECBAgQIECAAAECBAgQIECAAAECBGoJ
GKLUkrUuAQIECBAgQIAAAQIECBAgQIAAAQIECBAgMLSAIcrQ5RM8AQIECBAgQIAAAQIECBAgQIAA
AQIECBAgUEvAEKWWrHUJECBAgAABAgQIECBAgAABAgQIECBAgACBoQUMUYYun+AJECBAgAABAgQI
ECBAgAABAgQIECBAgACBWgI/ay1sXQIECBAgQIAAAQIECBBoI/Dx8fF2o8/Pz7fXXCBAgAABAgQI
ECBAYF/Amyj7Pq4SIECAAAECBAgQIEAgtcDeAGUL/Oh66uQER4AAAQIECBAgQKCzgCFK5wLYngAB
AgQIECBAgMCegAb4no5rZ8/H2fuIEiBAgAABAgQIECDwt4Af5+VEECBAgAABAgQIECCwlMDeQGGk
H321l8dSBZUsAQIECBAgQIAAgYoC3kSpiGtpAgQIECBAgAABAgRyCRwNHo6uZ8lmlDizeImDAAEC
BAgQIECAwF0BQ5S7cp4jQIAAAQIECBAgQGAogbODh+2+s/f2AMgcWw8PexIgQIAAAQIECBCoKWCI
UlPX2gQIECBAgAABAgQIDCuQcViRMaZhCyxwAgQIECBAgAABAicEDFFOILmFAAECBAgQIECAAIE1
BTINLTLFsuZpkDUBAgQIECBAgMCKAoYoK1ZdzgQIECBAgAABAl0FRvrl5V2hkmyeYXiRIYYk5RAG
AQIECBAgQIAAgaYChihNuW1GgAABAgQIECBA4LqABvp1s+gnthr0qEPUvgZ30SfCegQIECBAgAAB
AqsIGKKsUml5EiBAgAABAgQIECBQLNBykBK1lwFKcdktQIAAAQIECBAgsLCAIcrCxZc6AQIECBAg
QIAAAQLXBaKGG3s7R+1hgLKn7BoBAgQIECBAgACBYwFDlGMjdxAgQIAAAQIECBAgQOAvgaghxzNr
1I/vel7X1wQIECBAgAABAgQI3BMwRLnn5ikCBAgQIECAAAECBAYTiH4rI3rgET2Yic53sHILlwAB
AgQIECBAgECIgCFKCKNFCBAgQIAAAQIECBAYQaDGYCFimGKAMsLpESMBAgQIECBAgMCKAoYoK1Zd
zgQIECBAgAABAt0FajTzuyc1SAC17O8OUwxQBjk4wiRAgAABAgQIEFhS4OeSWUuaAAECBAgQIECA
wGACW6O9VvN/MIqQcL9aRg8xntdrWbeWe4UUwiIECBAgQIAAAQIEkgsYoiQvkPAIECBAgAABAgQI
EKgrsA0engcfkTvWXPsRp+FJZMWsRYAAAQIECBAgQOCPgB/n5TQQIECAAAECBAgQILC8wMhDiJFj
X/7gASBAgAABAgQIEEgvYIiSvkQCJECAAAECBAgQIPBboMUbDStbjziMGDHmlc+Y3AkQIECAAAEC
BMYTMEQZr2YiJkCAAAECBAgQIECgksAoQ4ktzlFirVQqyxIgQIAAAQIECBBoImCI0oTZJgQIECBA
gAABAgS+C9xpgnsb5btj9Cd36hIdw9562ePbi901AgQIECBAgAABAqMJGKKMVjHxEiBAgAABAgQI
LC9gkFL/CGQdVGSNq35F7ECAAAECBAgQIECgj4AhSh93uxIgQIAAAQIECBAgkFzAj8xKXiDhESBA
gAABAgQIEGggYIjSANkWBAgQIECAAAECBKIFvI0SLfp+vSzDFG+hvK+RKwQIECBAgAABAgRqCRii
1JK1LgECBAgQIECAAIETAhrjJ5CS3NJzmOKcJDkEwiBAgAABAgQIEFhOwBBluZJLmAABAgQIECBA
gACBEoHWwxQDlJJqeZYAAQIECBAgQIBAmYAhSpmfpwkQIECAAAECBAgUC9xtkvuRXsX0RQs8hik1
hyp3z0ZRYh4mQIAAAQIECBAgQOD/Aj9ZECBAgAABAgQIECDQX2BrlhuK9K9DSQQGHiV6niVAgAAB
AgQIECCQU8CbKDnrIioCBAgQIECAAAECBAgQIECAAAECBAgQIECgs4AhSucC2J4AAQIECBAgQIDA
Q8CbDM4CgXMC3to65+QuAgQIECBAgACBcgFDlHJDKxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIT
ChiiTFhUKREgQIAAAQIECBAgQGBWAW+hzFpZeREgQIAAAQIEcgoYouSsi6gIECBAgAABAgQWFbj6
I700lBc9KNImQIAAAQIECBAgQKCJgCFKE2abECBAgAABAgQIEKgnYJBSz9bKBAgQIECAAAECBAis
LWCIsnb9ZU+AAAECBAgQIDCJgEHKJIWUxq6Ac77L4yIBAgQIECBAgEAFAUOUCqiWJECAAAECBAgQ
IECAAIEcAld/RF6OqEVBgAABAgQIECCQRcAQJUslxEGAAAECBAgQIECgUMC/0i8E9DgBAgQIECBA
gAABAgSeBAxRHAkCBAgQIECAAAECBAgQSC9wZ0joLZT0ZRUgAQIECBAgQCC9gCFK+hIJkAABAgQI
ECBAYDUBjd/VKi7fI4E7A5SjNV0nQIAAAQIECBAgcEbAEOWMknsIECBAgAABAgQINBYwSGkMbru0
AgYoaUsjMAIECBAgQIDAEgKGKEuUWZIECBAgQIAAAQIjCtwZpGg4j1hpMb8TKDnPd75/3sXhcwIE
CBAgQIAAgXUFDFHWrb3MCRAgQIAAAQIEJhUoaTxPSiItAgQIECBAgAABAgQI3BIwRLnF5iECBAgQ
IECAAAECbQT8a/o2znYhQIAAAQIECBAgQIDAK4Gfrz70GQECBAgQIECAAAECYws83kYxhBm7jqtG
X/o2lXO/6smRNwECBAgQIEAgXsCbKPGmViRAgAABAgQIECCQRqC0GZ0mEYEsI1B6Zg1QljkqEiVA
gAABAgQINBEwRGnCbBMCBAgQIECAAAEC/QRKm9L9IrfzagKlZ9UAZbUTI18CBAgQIECAQH0BQ5T6
xnYgQIAAAQIECBAgUCQQ0RjemtOlDeqiJDxM4ECg9HxGfJ8chOgyAQIECBAgQIDAggKGKAsWXcoE
CBAgQIAAAQLjCUQ1iEsb1ePJiTi7gAFf9gqJjwABAgQIECCwtoAhytr1lz0BAgQIECBAgMCCAgYp
CxY9acrOYtLCCIsAAQIECBAgQOD/AoYoDgMBAgQIECBAgACBQQSi3kbZ0tW8HqToE4cZeQYjvzcm
JpcaAQIECBAgQIDADQFDlBtoHiFAgAABAgQIECDQSyCyWRzZxO7lYd8xBSLPXuT3xJiaoiZAgAAB
AgQIEKgpYIhSU9faBAgQIECAAAECBCoIRDaNI5vZFVK15GQC0b//JPJ7YTJq6RAgQIAAAQIECAQJ
fPz6S+dn0FqWIUCAAAECBAgQIECgoUD0AMT/GjQs3mJbRZ/Vjc95XewQSZcAAQIECBAg0EnAEKUT
vG0JECBAgAABAgQIRAhoTkcoWqOWQI3zucVqgFKrYtYlQIAAAQIECBB4FjBEeRbxNQECBAgQIECA
AIEBBWo0qzWqBzwIiUJ2JhMVQygECBAgQIAAAQK3BQxRbtN5kAABAgQIECBAgEAugRpN668ZGqrk
qnfmaGqcRecvc8XFRoAAAQIECBCYV8Avlp+3tjIjQIAAAQIECBBYTKB2k3lrjNdoji9WpunTrXFG
ap/t6YsiQQIECBAgQIAAgdsC3kS5TedBAgQIECBAgAABAnkFajSyn7PV2H4WWe9r52y9msuYAAEC
BAgQILCagCHKahWXLwECBAgQIECAwDICLRrcG6ZhSs4jVVr/57qWrndV6Xn/q8+7nwABAgQIECBA
gECEgCFKhKI1CBAgQIAAAQIECCQV0PhOWpjAsFrXODD0t0sZoLylcYEAAQIECBAgQKCxgCFKY3Db
ESBAgAABAgQIEGgt0KPJrgler8o96lkvm+8rOzvfTXxCgAABAgQIECDQT8AQpZ+9nQkQIECAAAEC
BAg0E+jZeNcULytzz9qVRX79aWflupknCBAgQIAAAQIE6goYotT1tToBAgQIECBAgACBNAIZmvGa
5OeOQ4ZanYs05i7nIsbRKgQIECBAgAABAvEChijxplYkQIAAAQIECBAgkFogS4Ne4/z3MclSjx6H
1hnooW5PAgQIECBAgACBKwKGKFe03EuAAAECBAgQIEBgIoGMzfsVmuoZ3Vsf6xXq3NrUfgQIECBA
gAABAnUEDFHquFqVAAECBAgQIECAwDACqzb1azXyV/U8e+BruZ/d330ECBAgQIAAAQIErggYolzR
ci8BAgQIECBAgACBBQQMARYocqcUDVA6wduWAAECBAgQIEDgtsCP2096kAABAgQIECBAgACBKQW2
Rrdm95Sl7ZqUM9WV3+YECBAgQIAAAQI3BX7efM5jBAgQIECAAAECBAhMLvBoenszZfJCV0jPwKQC
qiUJECBAgAABAgS6CBiidGG3KQECBAgQIECAAIFxBAxTxqnVmUifBxylQ7Ln9c7E4B4CBAgQIECA
AAECowj4nSijVEqcBAgQIECAAAECBBIJlDbeE6UybSiGG9OWVmIECBAgQIAAAQINBbyJ0hDbVgQI
ECBAgAABAgRmEfB2Sr5KGprkq4mICBAgQIAAAQIExhcwRBm/hjIgQIAAAQIECBAg0E3ga+Pe2ylt
y2Bo0tbbbgQIECBAgAABAmsKGKKsWXdZEyBAgAABAgQIEAgXMFAJJ/22oMHJNxIfECBAgAABAgQI
EKgqYIhSldfiBAgQIECAAAECBNYUMFApr7uBSbmhFQgQIECAAAECBAiUChiilAp6ngABAgQIECBA
gACBXYF3wwA//utvtndOu7guEiBAgAABAgQIECBQVcAQpSqvxQkQIECAAAECBAgQeCfQcmiQYWDT
Mt935j4nQIAAAQIECBAgQOCagCHKNS93EyBAgAABAgQIECAwoIABxoBFEzIBAgQIECBAgACBBAI/
EsQgBAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAAB
AgQIECCQQcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAEC
BAgQIECAAAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQT
MERJVxIBESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAEC
BAgQIECAQDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBA
gAABAgQIECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQ
QcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIE
CBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECA
AAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIB
ESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECA
QDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQI
ECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAA
AQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMV
xECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQ
IECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAAB
AgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDoBQ5R0
JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQIECBAgAAB
AgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAAAQIECBAg
QIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMVxECAAAEC
BAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIZBAxR
MlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQIECAAAEC
BAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAABAgQIECBA
gAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDqBn+kiEhABAgQI
ECBAgACBxQQ+Pj52M/78/Ny97iIBAgQIECBAgAABAgQI1BHwJkodV6sSIECAAAECBAgQOCVwNEDZ
Fjlzz6nN3ESAAAECBAgQIECAAAEClwS8iXKJy80ECBAgQIAAAQIE4gSuDEe2e2u8kbIXQ4394vSs
RIAAAQIECBAgQIAAgfoC3kSpb2wHAgQIECBAgAABAikF9gYoW8BH11MmJSgCBAgQIECAAAECBAgE
ChiiBGJaigABAgQIECBAgMBZgd4DirP7n73vbN7uI0CAAAECBAgQIECAwEgChigjVUusBAgQIECA
AAECBAgQIECAAAECBAgQIECAQDMBQ5Rm1DYiQIAAAQIECBAgQIAAAQIECBAgQIAAAQIERhIwRBmp
WmIlQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEmgkYojSjthEBAgQIECBAgACB3wJ+z4iTQIAAAQIE
CBAgQIAAgTEEDFHGqJMoCRAgQIAAAQIEJhG4O0D5/PycREAaBAgQIECAAAECBAgQGEfAEGWcWomU
AAECBAgQIEBgUQEDlEULL20CBAgQIECAAAECBLoLGKJ0L4EACBAgQIAAAQIEVhG4+xZKb59R4+7t
Zn8CBAgQIECAAAECBMYXMEQZv4YyIECAAAECBAgQIFBdwCClOrENCBAgQIAAAQIECBBIKGCIkrAo
QiJAgAABAgQIECBAgAABAgQIECBAgAABAgT6Cxii9K+BCAgQIECAAAECBAi8Fcj0+1C8jfK2TC4Q
IECAAAECBAgQIDCpgCHKpIWVFgECBAgQIECAwPgCmQYo42vKgAABAgQIECBAgAABAtcFfl5/xBME
CBAgQIAAAQIECKwqsL2Ncme4k+Utljuxr1preRMgQIAAAQIECBAg8M8/3kRxCggQIECAAAECBAgk
FKjd7K+9/lfSLAOULaZMsSQ8dkIiQIAAAQIECBAgQOBJwJsojgQBAgQIECBAgACBRQW2QUrtoULt
9e+U7u7bNHf28sxrgZJzcebcthwSvs7QpwQIECBAgAABArMIGKLMUkl5ECBAgAABAgQIEEgmUNIo
T5bKt3Ba5TbTMCDK7Mw6BmXfjqwPCBAgQIAAAQIEbgr4cV434TxGgAABAgQIECBAYAaBWk36M43u
Ef22vFrm1nKvmvXokUePPWsaWpsAAQIECBAgQKCPgCFKH3e7EiBAgAABAgQIEJhWYMbmdevhydfD
Mbrn6PFP+40qMQIECBAgQIAAgVMCfpzXKSY3ESBAgAABAgQIEJhX4MzvmJg3+/eZZWr+b7HUemvo
vcC9K5nc7mXgKQIECBAgQIAAAQJ/BLyJ4jQQIECAAAECBAgQIEDgSSDjICBjTM8HZ4QYn2P2NQEC
BAgQIECAAIE9AUOUPR3XCBAgQIAAAQIECBBYTiDzIEBsyx1HCRMgQIAAAQIECHQWMETpXADbEyBA
gAABAgQIECDQVmDvx2JlHlK0Vbq2G7drXu4mQIAAAQIECBAYR8DvRBmnViIlQIAAAQIECBAgUEVg
pQa4AcqfI3Sm7nte20pn1qhyaC1KgAABAgQIECBAoJGAIUojaNsQIECAAAECBAgQIHAscNS0P17h
3h2rDQPO5rvd964mZ9e4V5Hyp97FXb6yFQgQIECAAAECBFYSMERZqdpyJUCAAAECBAgQIPAkkK0R
/jUeTfA6x/VqzZ8HKVefr5PF/qrOzr6Pq0jXF6AAAA3PSURBVAQIECBAgAABAucFDFHOW7mTAAEC
BAgQIECAwDQCIzTCj2KMapQf7TNN0QMSqW31taZ39oo6EwFUliBAgAABAgQIEJhEwBBlkkJKgwAB
AgQIECBAgMCRwJ2m9NGaPa9/zSdL8/xsHKPVoma878zefd7zzNmbAAECBAgQIEBgPYEf66UsYwIE
CBAgQIAAAQLrCdRsgmfQ7J3f1vDX9L9+EphdN/MEAQIECBAgQIBAWwFDlLbediNAgAABAgQIECBw
SiByKBC5Vuamd2Sep4r066Y7w5MecZ7Np+V9mc9SSwd7ESBAgAABAgQI5Bbw47xy10d0BAgQIECA
AAECBIoEVmvYb/nWbs7XXr+o4MkfZpe8QMIjQIAAAQIECBD4JmCI8o3EBwQIECBAgAABAgTGF6gx
PNEA738uRq7ByLH3r7wICBAgQIAAAQIEegn4cV695O1LgAABAgQIECBAoJJA7wFK72Z5jfwfpSrN
rSS20r0rHbdTy44c+6kE3USAAAECBAgQIDCtgCHKtKWVGAECBAgQIECAwIoCJU36d153GuB3nnm3
/53PazjciSPqmd6eJXmMHHtJ3p4lQIAAAQIECBCYQ8CP85qjjrIgQIAAAQIECBCYUODq7/eoMTgo
aYB/fbZGbEclv+p3tN7d66W5l9TgVczbeqUxvVr362fRMR/t5zoBAgQIECBAgACBWgKGKLVkrUuA
AAECBAgQIEDgSaBm87pGUzyyEf68Vo14Wxy4d3E/5/eI5d39Z2N9t+7Z59/dV/MsvtvT5wQIECBA
gAABAgRGFDBEGbFqYiZAgAABAgQIEFhG4MzbFKWN+leYtZr3j72+rl8j/lc51fzskcMjrxFyqhVr
7bNTs47WJkCAAAECBAgQIPAsYIjyLOJrAgQIECBAgAABAskE9gYp0c36Hg3woz2jc6xZ3pFirelg
bQIECBAgQIAAAQKzCPjF8rNUUh4ECBAgQIAAAQJTC7xqzr/67A7CNsR4/Hfn+drPZI6tZu5Hw6Wo
vVvtExWvdQgQIECAAAECBAi0FDBEaaltLwIECBAgQIAAAQIFAl+HJpEDlIKQPDqJgEHKJIWUBgEC
BAgQIECAQLiAIUo4qQUJECBAgAABAgQIvBcobVZvw5MVByhROb+vTK4rpeckVzaiIUCAAAECBAgQ
IDCugCHKuLUTOQECBAgQIECAAIHbApr0t+mqP9irNr32rQ5qAwIECBAgQIAAAQIFAoYoBXgeJUCA
AAECBAgQIHBHoGezetu75/53vGo/k8kjUyy13a1PgAABAgQIECBAYAQBQ5QRqiRGAgQIECBAgACB
6QR6NMt77BlRuBY/yiuDjRgiTos1CBAgQIAAAQIECMQKGKLEelqNAAECBAgQIECAwGmBlk3zlnud
BjhxY8kAZaScR4r1RNncQoAAAQIECBAgQGAagZ/TZCIRAgQIECBAgAABAgReCozaoJ99gJK1Lltc
JfYvD6EPCRAgQIAAAQIECAwq4E2UQQsnbAIECBAgQIAAgTkEajfSa69fqwolTfy7Od997o5By71m
jO9OTp4hQIAAAQIECBAgcEfAEOWOmmcIECBAgAABAgQIBArUaqjXWjcw9ZdLlQxQXi544cPaZtv6
tfe4kO7uraPEuZuEiwQIECBAgAABAgQKBfw4r0JAjxMgQIAAAQIECBCIENga1pHDAw3w+1WJqAX/
+/6eJECAAAECBAgQIJBJwBAlUzXEQoAAAQIECBAgsLRARPN+A2zdwN8b/rSOJWq/qFrUOtCZzGvl
aF0CBAgQIECAAAECGQQ+fv3PwWeGQMRAgAABAgQIECBAgMA/xW+jtP7r/V4z/1HPo5jOrHHmbBzt
c2aN53tKY+sVU9S+d/OP2v+5Hr4mQIAAAQIECBAg0FrA70RpLW4/AgQIECBAgAABAjsCJc3nkmd3
Qnp76WyD/fm+7euv/73d4MKFWrmXrvuc+4WUXt56dr2z973cxIcECBAgQIAAAQIECPxfwBDFYSBA
gAABAgQIECCQTOBO4/7OM63TfgxOWu/be7+R8757rgxxep86+xMgQIAAAQIECEQJGKJESVqHAAEC
BAgQIECAQKDAleb1lXsDQ7y0VM2meu38o9avaXCpGBdvjsr/4rZuJ0CAAAECBAgQIJBCwC+WT1EG
QRAgQIAAAQIECBD4LqB5/d3k+ZNWRts+EUOQxxp34o7Y/9nP1wQIECBAgAABAgQI7At4E2Xfx1UC
BAgQIECAAAECBAiEC1wZiIz848DC4SxIgAABAgQIECBAoLGAN1Eag9uOAAECBAgQIECAAIEYgTtv
c5TsHPU2yiOGK4OUkrg9S4AAAQIECBAgQIDAfQFvoty38yQBAgQIECBAgAABAp0EWg9QHmn22rcT
s20JECBAgAABAgQILC9giLL8EQBAgAABAgQIECBAYCyB3oOM3vv3qNaKOfdwticBAgQIECBAgEA+
AUOUfDUREQECBAgQIECAAAECbwSyNPOzxPGGqcrHV3K+cm+VYC1KgAABAgQIECBAIEjAECUI0jIE
CBAgQIAAAQIECNQVyNaYzxZPXf3fq5/J+cw9LWK1BwECBAgQIECAAIEIgY9ff8H9jFjIGgQIECBA
gAABAgQIrCdQ85ejj/S/KjUd7pyqkezu5OcZAgQIECBAgAABAq0EDFFaSduHAAECBAgQIECAwKQC
UQOE0Rv/UQ6lx2R0x9L8PU+AAAECBAgQIEAgUsAQJVLTWgQIECBAgAABAgQWFrg7RJip6X/XIOrY
zGQZZWIdAgQIECBAgAABAiUChiglep4lQIAAAQIECBAgQOAvgStDhFkb/lcMoo7PrJZRPtYhQIAA
AQIECBAgcFfAEOWunOcIECBAgAABAgQIECBwINBioGKAclAElwkQIECAAAECBAgUCPwoeNajBAgQ
IECAAAECBAgQILAjUHPAsa1dc/2dtFwiQIAAAQIECBAgsIzAz2UylSgBAgQIECBAgAABAgQ6CBh0
dEC3JQECBAgQIECAAIEgAW+iBEFahgABAgQIECBAgAABAgQIECBAgAABAgQIEJhLwBBlrnrKhgAB
AgQIECBAgAABAgQIECBAgAABAgQIEAgSMEQJgrQMAQIECBAgQIAAAQIECBAgQIAAAQIECBAgMJeA
Icpc9ZQNAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECRgiBIEaRkCBAgQIECAAAECBAgQIECAAAEC
BAgQIEBgLgFDlLnqKRsCBAgQIECAAAECBAgQIECAAAECBAgQIEAgSMAQJQjSMgQIECBAgAABAgQI
ECBAgAABAgQIECBAgMBcAoYoc9VTNgQIECBAgAABAgQIECBAgAABAgQIECBAgECQgCFKEKRlCBAg
QIAAAQIECBAgQIAAAQIECBAgQIAAgbkEDFHmqqdsCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgSAB
Q5QgSMsQIECAAAECBAgQIECAAAECBAgQIECAAAECcwkYosxVT9kQIECAAAECBAgQIECAAAECBAgQ
IECAAAECQQKGKEGQliFAgAABAgQIECBAgAABAgQIECBAgAABAgTmEjBEmauesiFAgAABAgQIECBA
gAABAgQIECBAgAABAgSCBAxRgiAtQ4AAAQIECBAgQIAAAQIECBAgQIAAAQIECMwlYIgyVz1lQ4AA
AQIECBAgQIAAAQIECBAgQIAAAQIECAQJGKIEQVqGAAECBAgQIECAAAECBAgQIECAAAECBAgQmEvA
EGWuesqGAAECBAgQIECAAAECBAgQIECAAAECBAgQCBIwRAmCtAwBAgQIECBAgAABAgQIECBAgAAB
AgQIECAwl4Ahylz1lA0BAgQIECBAgAABAgQIECBAgAABAgQIECAQJGCIEgRpGQIECBAgQIAAAQIE
CBAgQIAAAQIECBAgQGAuAUOUueopGwIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBIwBAlCNIyBAgQ
IECAAAECBAgQIECAAAECBAgQIECAwFwChihz1VM2BAgQIECAAAECBAgQIECAAAECBAgQIECAQJCA
IUoQpGUIECBAgAABAgQIECBAgAABAgQIECBAgACBuQQMUeaqp2wIECBAgAABAgQIECBAgAABAgQI
ECBAgACBIAFDlCBIyxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCRiizFVP2RAgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQJBAoYoQZCWIUCAAAECBAgQIECAAAECBAgQIECAAAECBOYSMESZq56yIUCA
AAECBAgQIECAAAECBAgQIECAAAECBIIEDFGCIC1DgAABAgQIECBAgAABAgQIECBAgAABAgQIzCVg
iDJXPWVDgAABAgQIECBAgAABAgQIECBAgAABAgQIBAkYogRBWoYAAQIECBAgQIAAAQIECBAgQIAA
AQIECBCYS8AQZa56yoYAAQIECBAgQIAAAQIECBAgQIAAAQIECBAIEjBECYK0DAECBAgQIECAAAEC
BAgQIECAAAECBAgQIDCXgCHKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYIgSBGkZAgQI
ECBAgAABAgQIECBAgAABAgQIECBAYC4BQ5S56ikbAgQIECBAgAABAgQIECBAgAABAgQIECBAIEjA
ECUI0jIECBAgQIAAAQIECBAgQIAAAQIECBAgQIDAXAL/A42ghxLmmMjjAAAAAElFTkSuQmCC
--0000000000004e772305bc24da13--


From nobody Thu Feb 25 00:41:24 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7A3A15C8 for ; Thu, 25 Feb 2021 00:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=trustap-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8SYwNaFZK1g for ; Thu, 25 Feb 2021 00:41:18 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7683A15CC for ; Thu, 25 Feb 2021 00:41:18 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id h19so5754190edb.9 for ; Thu, 25 Feb 2021 00:41:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trustap-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0O9QvV+W+9bCFHwuk6gY94fmynrV2CKJ7rSPZOjvwU0=; b=MTFTyKtV6+4dAUyIv0yp0UTbJ0/lkGtd/vxHqFIaDFfpN3ZkyTq4GJzRmKrOCv6zgs gMbfmVJNQywQUvgq0a3kBpsuBOR5CxtZzjWeuvR7Qq7ANzcIlJRQygbA+1ZNIx6lZsHg HryvApoxOaCcohbqxzkBgkU1o1UuOueW+0IV6IAZyOjFolsmjJAl2nprxNe2SGS5iGR/ xXhARLrOwtOx9nqD3fJn30HG3mX96VMmWRosEpxkBntQLRp5MtURwSs3CzyUPqXr3+v9 y9GUYG4XyCTtSn74cYSQn553lR8eMB0llxD/v3PAX6ynQkPNx0CuYPo1oaItEZS9g7BY YyyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0O9QvV+W+9bCFHwuk6gY94fmynrV2CKJ7rSPZOjvwU0=; b=tq+CN9aF3kAJnGw60ftxWBwfhR+RZJrK+ikYykCQ3BXe5EaShOMGkc9CcnUfuX1RNq o2rOhhItbeqgZhE61YQ3z6GgUbbMA6O+jaK13LdCPp3UTJv6Klyn7ImzJkwpkFBIsS/T /KcsdvAGZQzOA+INaKfpJJEcglRnAc2M2Hyo5Um2LmTYUp/dAR9s1R+trzOfCCh5apRU kAKWdoDIIZxg5Bi+kfrgO2IKWrnut99acoOZ2CjhzVZIhh7mt/jOU/xiGQzdXn2v6OrG VjfTe03xuAfegrzIBANpuaNn2flk4DXcDDs6gR0WuUIQTuBioOj9j7En0d3KzOJj3yc0 ZhNg==
X-Gm-Message-State: AOAM5310oPWibIEt86XowsmL6vswrz9guKyEAkVbjMsJUnKXc67QIXTf 8dbX/Olanlnj9jS5t9UnGjk3stClsdVZEK1SebaVPA==
X-Google-Smtp-Source: ABdhPJwknyy/dEXHpvAKUq04yjRahyj5be6xzXgU/cpdoMIG3OFFYLYxdG7QIzxUzzORlDHMBrQn18Cw79Ft7k1iOgk=
X-Received: by 2002:aa7:c58a:: with SMTP id g10mr1794497edq.243.1614242476610;  Thu, 25 Feb 2021 00:41:16 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com> 
In-Reply-To: 
From: =?UTF-8?Q?Se=C3=A1n_Kelleher?= 
Date: Thu, 25 Feb 2021 08:41:05 +0000
Message-ID: 
To: Bron Gondwana 
Cc: Justin Richer , Phillip Hallam-Baker ,  "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/related; boundary="00000000000066818705bc251d32"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2021 08:41:23 -0000

--00000000000066818705bc251d32
Content-Type: multipart/alternative; boundary="00000000000066818605bc251d31"

--00000000000066818605bc251d31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Yep, this is the big point - OAuth is designed to require the the third
> leg of trust that creates the NxM problem.


I believe the snippet of Justin's that you quoted actually shows you how
you can forgo the trust element using dynamic client registration. It still
allows a "server" to identify requests and impose security policies via the
client ID, but without requiring the client author to manually register the
client in advance of using it (e.g. in the case where the client author
doesn't even know what servers the client is going to be connecting to).
You still need the client ID, but anyone can get one whenever they need it.

I'm also feeling a bit of confusion arising from a conflation of terms
between the regular client/server model and the terminology used in OAuth.
To be clear, in OAuth, the level of trust between the client and authZ
server only really depends on policy; as mentioned, dynamic client
registration can be used if you don't need any trust between the client and
AS.

On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher  wrote:

> Just to clarify, I assume in this discourse that the "server" in this
> client and server relationship refers to an AS/RS pair in OAuth
> terminology? Based on this, one big sticking point for me on the
> applicability of NxM, or even 1xM, is that all of the "M" RSs need to
> publish the same interface for any meaningful implementation in the first
> place.
>
> It probably makes more sense with email clients, since as Bron said, ther=
e
> is the common standard of POP. If we assume that all the email services
> that we want to connect to publish the same POP interface, and would acce=
pt
> tokens in the same way, then the way the authZ is handled is indeed the
> point of divergence that needs to be resolved.
>
> However, we're talking about NxM in the general case here. I feel like
> using the likes of discovery and dynamic registration, etc. that's alread=
y
> supported by OAuth, the "N" part of this equation is surmountable. But ea=
ch
> of the "M" servers also need to export the same interface, otherwise a
> client is going to have to write custom code to deal with talking to the
> service after the authZ step anyway, reintroducing the "problem" part of
> the NxM problem.
>
> As such, I would actually suggest constraining this discussion to just th=
e
> POP NxM problem rather than NxM in general because, for me at least, the
> authZ part of the general case is the most "solved" part of the problem,
> and the outstanding work lies more in consolidating the "M" RS interfaces=
.
>
> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana 
> wrote:
>
>> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>>
>> I agree that the NxM problem is the purview of the whole IETF, but it=E2=
=80=99s
>> something that we=E2=80=99re particularly interested in over in GNAP. As=
 the editor
>> of OAuth=E2=80=99s dynamic registration extension and the GNAP core prot=
ocol, I
>> hope I can add to this conversation.
>>
>> From a technical standpoint, OAuth=E2=80=99s dynamic client registration=
 lets
>> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in pr=
actice. On
>> top of that I think this problem is exacerbated by a fundamental protoco=
l
>> design element of OAuth: the client_id that=E2=80=99s required. That fie=
ld means
>> there=E2=80=99s an assumption that a relationship was set up between the=
 pieces of
>> software, implied to be trusted by admins at the AS. Sure you can get th=
at
>> client_id under special circumstances, but there=E2=80=99s still a speci=
al weight
>> handed to that and the dynamic stuff feels like you=E2=80=99re giving up=
 control as
>> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed =
as
>> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an op=
timization on top
>> of that.
>>
>>
>> Yep, this is the big point - OAuth is designed to require the the third
>> leg of trust that creates the NxM problem.
>>
>>
>>
>> If that dotted line between client and server requires a pre-existing
>> trust relationship rather than the trust being entirely mediated by the
>> user choosing to connect client A with server B, then you have the NxM
>> problem.  This is the "you can only have your John Deere tractor service=
d
>> by an approved John Deere service centre" problem.  You can only use thi=
s
>> client with servers who have pre-approved it.  Or fall back to the "cash=
 of
>> the internet" - plain text passwords.
>>
>> Does this solve the NxM problem? No, because companies are still going t=
o
>> decide that they only talk to keys or identifiers that they know ahead o=
f
>> time. But the protocol puts the dynamic case forward as baseline and fit=
s
>> in much better with the likes of JMAP than OAuth ever could:
>>
>> - {The Bat} creates a key pair.
>> - {User} enters their email address into {Bat}, {Bat} does discovery
>> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP serve=
r and the
>> GNAP endpoint for authentication as an option.
>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
>> up. {ISP} has never seen this key, but knows how to talk GNAP and get th=
e
>> user to authorize {Bat} to access email.
>> - {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied
>> to the key {Bat} made back at the beginning. That token is tied (at the
>> {ISP}) to the user=E2=80=99s account.
>>
>> Yes, you can do all of this today with OAuth (and people have done so),
>> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registra=
tion first and THEN
>> talk to me=E2=80=9D is a trust impediment more than it is a technical im=
pediment.
>> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the p=
hilosophy of =E2=80=9Cstart
>> talking first and figure out what you need as you go=E2=80=9D. Instead o=
f jumping
>> through hoops to get something you can trust, you just start in and then
>> decide how much you trust it. A corporate rollout could use its own key
>> distribution mechanism and static registration to limit which client
>> instances talk back to the company server, regardless of which accounts
>> would authorize access on top of that. An internet-facing service is goi=
ng
>> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk =
to you in a secure
>> fashion without caring who you are right now=E2=80=9D.
>>
>> We really are trying to make GNAP a consistent protocol at its core and
>> learn from problems with OAuth in the wild, all while letting GNAP addre=
ss
>> a wider variety of use cases. I agree that GNAP could be clearer about
>> specific use cases, and we=E2=80=99re working on the spec still so any h=
elp here is
>> appreciated.
>>
>>
>> Excellent.  This is precisely what I've been waiting for for these very
>> many years as a viable replacement for storing a password locally on dis=
k.
>> Just having the server able to distinguish between different client
>> instances for the same user is a big start, because you can de-authorise
>> one without having to lock out every connection - even if the user is st=
ill
>> entering their password during the setup phase each time.
>>
>> This is what Fastmail already do with our own app, creating a long-lived
>> access token and storing that on the device rather than storing the
>> password itself - and you can log out any one client from your security
>> settings page.  What's missing is a standard way to do that with any IMA=
P
>> client.  The initial JMAP authentication proposal was a very simple case=
 of
>> pretty much this, build into to the protocol so everyone would do it.
>>
>> Making it easy to connect up arbitrary clients with per-client tokens th=
e
>> default, and easy rather than almost impossible to do in practice is whe=
re
>> the big difference comes in.
>>
>> Bron.
>>
>> --
>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>   brong@fastmailteam.com
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>

--00000000000066818605bc251d31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yep, this is the big point - OAuth is designed to=
 require the the third leg of trust that creates the NxM problem.

I believe the snippet of Justin's that yo=
u quoted actually shows you how you can forgo the trust element using dynam=
ic client registration. It still allows a "server" to identify re=
quests and impose security policies via the client ID, but without requirin=
g=C2=A0the client author to manually register the client in advance of usin=
g it (e.g. in the case where the client author doesn't even know what s=
ervers the client is going to be connecting to). You still need the client =
ID, but anyone can get one whenever they need it.

=
I'm also feeling a bit of confusion arising from a conflation of terms =
between the regular client/server model and the terminology used in OAuth. =
To be clear, in OAuth, the level of trust between the client and authZ serv=
er only really depends on policy; as mentioned, dynamic client registration=
 can be used if you don't need any trust between the client and AS.

On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher <sean@trustap.com> wrote:
Just to clarify, I a=
ssume in this discourse that the "server" in this client and serv=
er relationship refers to an AS/RS pair in OAuth terminology? Based on this=
, one big sticking=C2=A0point for me on the applicability of NxM, or even 1=
xM, is that all of the "M" RSs need to publish the same interface=
 for any meaningful implementation in the first place.

=

It probably makes more sense with email clients, since as Bron said, t=
here is the common standard of POP. If we assume that all the email service=
s that we want to connect to publish the same POP interface, and would acce=
pt tokens in the same way, then the way the authZ is handled is indeed the =
point of divergence that needs to be resolved.

How=
ever, we're talking about NxM in the general=C2=A0case here. I feel lik=
e using the likes of discovery and dynamic registration, etc. that's al=
ready supported by OAuth, the "N" part of this=C2=A0equation=C2=
=A0is surmountable. But each of the "M" servers also need to expo=
rt the same interface, otherwise a client is going to have to write custom =
code to deal with talking to the service after the authZ step anyway, reint=
roducing the "problem" part of the NxM problem.

As such, I would actually suggest constraining this discussion to j=
ust the POP NxM problem rather than NxM in general because, for me at least=
, the authZ part of the general case is the most "solved" part of=
 the problem, and the outstanding work lies more in consolidating the "=
;M" RS interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana &=
lt;brong@fastma=
ilteam.com> wrote:
On Thu, Feb 25, 202=
1, at 02:18, Justin Richer wrote:
I agree that=
 the NxM problem is the purview of the whole IETF, but it=E2=80=99s somethi=
ng that we=E2=80=99re particularly interested in over in GNAP. As the edito=
r of OAuth=E2=80=99s dynamic registration extension and the GNAP core proto=
col, I hope I can add to this conversation.

Fr=
om a technical standpoint, OAuth=E2=80=99s dynamic client registration lets=
 arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in prac=
tice. On top of that I think this problem is exacerbated by a fundamental p=
rotocol design element of OAuth: the client_id that=E2=80=99s required. Tha=
t field means there=E2=80=99s an assumption that a relationship was set up =
between the pieces of software, implied to be trusted by admins at the AS. =
Sure you can get that client_id under special circumstances, but there=E2=
=80=99s still a special weight handed to that and the dynamic stuff feels l=
ike you=E2=80=99re giving up control as an AS. In GNAP, the relationship is=
 inverted, and it=E2=80=99s designed as =E2=80=9Cdynamic-first=E2=80=9D, wi=
th pre-registered clients being an optimization on top of that.

Yep, this is the big point - OAuth is designed to require the t=
he third leg of trust that creates the NxM problem.



If that dotted line=
 between client and server requires a pre-existing trust relationship rathe=
r than the trust being entirely mediated by the user choosing to connect cl=
ient A with server B, then you have the NxM problem.=C2=A0 This is the &quo=
t;you can only have your John Deere tractor serviced by an approved John De=
ere service centre" problem.=C2=A0 You can only use this client with s=
ervers who have pre-approved it.=C2=A0 Or fall back to the "cash of th=
e internet" - plain text passwords.

Does this solve the NxM problem? No, =
because companies are still going to decide that they only talk to keys or =
identifiers that they know ahead of time. But the protocol puts the dynamic=
 case forward as baseline and fits in much better with the likes of JMAP th=
an OAuth ever could:

- {The Bat} creates a key=
 pair.
- {User} enters their email address into {Bat}, {Bat} =
does discovery (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds th=
e JMAP server and the GNAP endpoint for authentication as an option.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it just =
made up. {ISP} has never seen this key, but knows how to talk GNAP and get =
the user to authorize {Bat} to access email.
- {User} does th=
is using GNAP and gets back an access token that=E2=80=99s tied to the key =
{Bat} made back at the beginning. That token is tied (at the {ISP}) to the =
user=E2=80=99s account.

Yes, you can do all of=
 this today with OAuth (and people have done so), but OAuth=E2=80=99s basic=
 model of =E2=80=9Cgo do discovery and registration first and THEN talk to =
me=E2=80=9D is a trust impediment more than it is a technical impediment. T=
he =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the philo=
sophy of =E2=80=9Cstart talking first and figure out what you need as you g=
o=E2=80=9D. Instead of jumping through hoops to get something you can trust=
, you just start in and then decide how much you trust it. A corporate roll=
out could use its own key distribution mechanism and static registration to=
 limit which client instances talk back to the company server, regardless o=
f which accounts would authorize access on top of that. An internet-facing =
service is going to be more likely to take a TLS approach, of =E2=80=9CI=E2=
=80=99ll talk to you in a secure fashion without caring who you are right n=
ow=E2=80=9D.

We really are trying to make GNAP=
 a consistent protocol at its core and learn from problems with OAuth in th=
e wild, all while letting GNAP address a wider variety of use cases. I agre=
e that GNAP could be clearer about specific use cases, and we=E2=80=99re wo=
rking on the spec still so any help here is appreciated.=C2=A0

Excellent.=C2=A0 This is precisely what I've been waiting fo=
r for these very many years as a viable replacement for storing a password =
locally on disk.=C2=A0 Just having the server able to distinguish between d=
ifferent client instances for the same user is a big start, because you can=
 de-authorise one without having to lock out every connection - even if the=
 user is still entering their password during the setup phase each time.

This is what Fastmail already do with our own app, creating a long-=
lived access token and storing that on the device rather than storing the p=
assword itself - and you can log out any one client from your security sett=
ings page.=C2=A0 What's missing is a standard way to do that with any I=
MAP client.=C2=A0 The initial JMAP authentication proposal was a very simpl=
e case of pretty much this, build into to the protocol so everyone would do=
 it.

Making it easy to connect up arbitrary clients with per-clie=
nt tokens the default, and easy rather than almost impossible to do in prac=
tice is where the big difference comes in.

Bron.

--
=C2=A0 Bron Go=
ndwana, CEO, Fastmail Pty Ltd


________=
_______________________________________

OAuth mailing list

OAuth@ietf.org

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






--00000000000066818605bc251d31--

--00000000000066818705bc251d32
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <177d829913ecb971f161>
X-Attachment-Id: 177d829913ecb971f161

iVBORw0KGgoAAAANSUhEUgAABlEAAANCCAYAAAD2kOrdAAAABHNCSVQICAgIfAhkiAAAIABJREFU
eF7s3Quy3DiSIMBSmy4xp9j7H2NPscfQilOV3dkUfwACID4+ZmU9L5MEIjxAECT0pB+/fv/fX/6P
AAECBAgQIECAAAECBAgQIECAAAECBAgQIEDgvwT+xYMAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg
QOBPAZsof5r4hAABAgQIECBAgAABAgQIECBAgAABAgQIECDwl00Ug4AAAQIECBAgQIAAAQIECBAg
QIAAAQIECBAgcCBgE+UAxUcECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAZsoxgABAgQIECBAgAAB
AgQIECBAgAABAgQIECBA4EDAJsoBio8IECBAgAABAgQIECBAgAABAgQIECBAgAABAjZRjAECBAgQ
IECAAAECBAgQIECAAAECBAgQIECAwIGATZQDFB8RIECAAAECBAgQIECAAAECBAgQIECAAAECBGyi
GAMECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgQMBmygHKD4iQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIECNhEMQYIECBAgAABAgQIECBAgAABAgQIECBAgAABAgcCNlEOUHxEgAABAgQIECBAgAABAgQI
ECBAgAABAgQIELCJYgwQIECAAAECBAgQIECAAAECBAgQIECAAAECBA4EbKIcoPiIAAECBAgQIECA
AAECBAgQIECAAAECBAgQIGATxRggQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwI2EQ5QPERAQIE
CBAgQIAAAQIECBAgQIAAAQIECBAgQMAmijFAgAABAgQIECBAgAABAgQIECBAgAABAgQIEDgQsIly
gOIjAgQIECBAgAABAgQIECBAgAABAgQIECBAgIBNFGOAAAECBAgQIECAAAECBAgQIECAAAECBAgQ
IHAgYBPlAMVHBAgQIECAAAECBAgQIECAAAECBAgQIECAAAGbKMYAAQIECBAgQIAAAQIECBAgQIAA
AQIECBAgQOBAwCbKAYqPCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQI2UYwBAgQIECBAgAABAgQI
ECBAgAABAgQIECBAgMCBgE2UAxQfESBAgAABAgQIECBAgAABAgQIECBAgAABAgRsohgDBAgQIECA
AAECBAgQIECAAAECBAgQIECAAIEDAZsoByg+IkCAAAECBAgQIECAAAECBAgQIECAAAECBAjYRDEG
CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIHAjZRDlB8RIAAAQIECBAgQIAAAQIECBAgQIAAAQIE
CBCwiWIMECBAgAABAgQIECBAgAABAgQIECBAgAABAgQOBGyiHKD4iAABAgQIECBAgAABAgQIECBA
gAABAgQIECBgE8UYIECAAAECBAgQIECAAAECBAgQIECAAAECBAgcCNhEOUDxEQECBAgQIECAAAEC
BAgQIECAAAECBAgQIEDAJooxQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBA4ELCJcoDiIwIECBAg
QIAAAQIECBAgQIAAAQIECBAgQICATRRjgAABAgQIECBAgAABAgQIECBAgAABAgQIECBwIPDz4DMf
ESBAgAABAgQIECBAgAABAgQIEBhS4MePH0PG/SToX79+PTnMMQQIECAQKGATJRBTUwQIECBAgAAB
AgQIECBAgAABAnECM2+I5CidedhcydF0DgECBJ4J2ER55uQoAgQIECBAgAABAgQIECBAgACBBgJn
GwUNuh62iygzmzHDDgGBEyBQUcAmSkVcTRMgQIAAAQIECBAgQIAAAQIEvgVKXnaP/oK7JHejqI3A
UY1GH3dt5PRCgMDMAj9+T4T+MsWZKyw3AgQIECBAgAABAgQIECBA4BWBoxfSrwSiUwLBAl4nBoNq
jgCBrgX8JkrX5REcAQIECBAgQIAAAQIECBAgMIKADZMRqiTGKIH9eLepEiWrHQIEehSwidJjVcRE
gAABAgQIECBAgAABAgQIvC6wf1H8ekACINCpwNm1YnOl04IJiwCBJAGbKElcDiZAgAABAgQIECBA
gAABAgRWEDh7KbxC7nIkECWwv45sqkTJaocAgZYCNlFaauuLAAECBAgQIECAAAECBAgQ6Fpg/9K3
62AFR2Awgf31ZVNlsAIKl8CiAjZRFi28tAkQIECAAAECBAgQIECAAIH/Fti/4OVDgEBdgf01Z1Ol
rrfWCRDIE/hX3mnOIkCAAAECBAgQIECAAAECBAjMI7B/mTtPZjIhMI7Adh26Fsepl0gJrCLgN1FW
qbQ8CRAgQIAAAQIECBAgQIAAgUMBL20PWab7cKTfclh9TG75j1Sv6S4WCREg8F8CP35PSL+YECBA
YBNIXaTVmD5SYzirXI3YzvryOQECBAgQIECAAAEC4wpEPYOMKzBm5Ks+8602Xlet85hXpagJzCtg
E2Xe2sqsscBqC5nGvM26s0BrRq0jAgQIECBAgAABAq8LeI57vQRJAXheu+Z6Op43x6fHXvfY5lt1
b+OsFwIEzgVsopzb+IbAfwmMtMBQuhgBC7UYR60QIECAAAECBAgQ6FGgp2e8/bNHT7G1qN0+/xZ9
6uNPgV7HnfHxZ618QoBAWwGbKG299RYsUOsGv79B1+onmENzlQX246Jyd5onQIAAAQIECBAgQKCS
wNvPeJ4tKhVWs+ECb18rW0Kul/CyapAAgUQBmyiJYA5vJ9DDjbpdtnoiMJ6Ahex4NRMxAQIECBAg
QGB1gTeeM62bVx91c+X/xjVUIuj6K9FzLgECHwGbKMZCFwKj3YS7QBMEgYEFLGQHLp7QCRAgQIAA
AQKDCkQ+d1rPDjoIhF1NIPL6qhbkV8Ou4RbK+iAwj4BNlHlq2XUmo91Mu8YUHIFJBSxiJy2stAgQ
IECAAAECHQhEPpNat3ZQUCF0LxB5zbVO1jXeWlx/BPoXsInSf42GjHDkm+WQ4IImMKGAheuERZUS
AQIECBAgQKChQI3nUmvUhgXU1VQCNa7HUYHMI6NWTtwrC/xcOXm5xwq4IcZ6ao3A6gJHc4rF5uqj
Qv4ECBAgQIAAgXuBo3Xk/Vn3R1iL3hs5ggCBe4GIOcp8dO/sCAKRAjZRIjUXayti0l+MTLoECBQK
fM87Fo2FmE4nQIAAAQIECEwiUPvZ1LpzkoEiDQITCdzNe+atiYotlS4EbKJ0UYb+g7ibnPvPQIQE
CMwmsM1LFoazVVU+BAgQIECAAIF7gZbPp9ab9/VwBAEC/QkczZPms/7qJKJxBGyijFOrqpEeTa5V
O9Q4gUSBs5u9sZsIOdnhn/qfjY/J0pUOAQIECBAgQGB5gZbrf2vM5YcbAAJTCRzNn+a5qUosmYoC
/mH5iri9Nn00afYa6wxxuSH1WUXXQZ91KY3K9VYq6HwCBAgQIECAQL8CLdfw1pX9jgORjSnQ8vod
U6iPqM19fdRBFP0J2ETpryahEblJhXL+uzE3lTqub7XqOnlLvl6/rtF6tlomQIAAAQIECLwh0HLN
bi35RoX1uYJAy+t4Bc/aOZoLawtrfyQBmygjVesmVjej/wA9nehzzZ62f1MyX3cskDs2Ok5pudBc
p8uVXMIECBAgQIDApAIt1+bWkJMOIml1I9Dyeu4m6UkCMT9OUkhpZAnYRMlie/+klW86tSbtp6a1
+n9/VImAwLHA02vj+Ox3P3W9vuuvdwIECBAgQIBAiUDLdah1Y0mlnEvgfYGW88X72b4XgbnyPXs9
vytgE+Vd///q3YT/ZzHemJyv6vBGPH+q+ITAOAJX11OrLFy3raT1Q4AAAQIECBAoE3hr7Wi9WFY3
ZxPoWeCteaVnk9LYzJmlgs4fUcAmyktVM4n/DW/ifWkA6pbAiwJvzH/mmhcLrmsCBAgQIECAwAOB
N9aIW1jWiQ+K4xACkwq8Ne/MwGnunKGKckgRsImSopV5rEn5P3Am2cxB5DQCEwu0mCPNPRMPIKkR
IECAAAECwwq0WAce4VgbHqn4jACBaIG35rjoPM7aM5eeyfh8RgGbKAFVnX1SLCUyqZYKOp/AegI1
5lVz0XrjSMYECBAgQIBAvwI11nt32VoP3gn5ngCB3gTemCtTDcytqWKOH1HAJkph1UaYzApTTD7d
5JlM5gQCBC4EIudZ89MFtK8IECBAgAABAo0EItd3VyFb+13p+I4AgRkEWs2nT63Mu0+lHDeagE2U
gor1NlEVpJJ9qskxm86JBAgkCLSYb81nCQVxKAECBAgQIEAgQ6D2ms56LqMoTiFAYDqB2nPtEzDz
8RMlx4wkYBMls1o9TEiZoSedZtJL4nIwAQKVBd6ae82FlQureQIECBAgQGB6gRbrOGu26YeRBAkQ
yBRoMQefhWZuPpPx+UgCNlEyqvXmxJMR7qNTTGiPmBxEgEAnAm/Ow+bLTgaBMAgQIECAAIFhBFqs
3azRhhkOAiVAoAOBFvPyUZrm6iMVn40gYBMloUpvTTAJIT4+tIdJ69uzh3ge4zmQAIEuBHqYk81d
XQwFQRAgQIAAAQIdC7RYs1mTdTwAhEaAQPcCLebpIwRz95GKz3oVsInysDJvTSgPw7s8rMdJae/Z
Y4yXqL4kQKALgf1c8lZQ5rC35PVLgAABAgQI9CzQYq1mHdbzCBAbAQIjCrSYu/cu5vK9iJ97E7CJ
8qAib0weD8I6PMSkc8jiQwIEJhbodY42H0886KRGgAABAgQI3ArUXKNZZ93yO4AAAQJFAjXn8KvA
zO9XOr57U8AmygP9tyaOT2gmkAdFcggBAksLvD1PP8E3lz9RcgwBAgQIECAwg0D02sw6aoZRIQcC
BEYTiJ7Ln+Zvzn8q5biWAjZRbrRbTxgmipuC+JoAAQInAq3n65Mwkj827yeTOYEAAQIECBDoWCB6
TWat1HGxhUaAwPQC0XN6Cpj5P0XLsbUFbKLcCNecLEwGN/i+JkCAQKJAzTk7MZTsw90bsumcSIAA
AQIECLwsELUWsx56uZC6J0CAwJdA1Nxeguq+UKLn3AgBmygXiqWThAv8AtdXBAgQqCRQOndXCiu7
WfeSbDonEiBAgAABAg0FotZg1j4Ni6YrAgQIJAhEzfMJXR4e6j5xyOLDygI2UU6ASycGF/QJrI8J
ECDQQKB0Dm8QYlYX7i1ZbE4iQIAAAQIEKgtErb2sdSoXSvMECBAIEoia90vDcd8oFXT+UwGbKAdS
pROBC/gA1UcECBDoRKB0ju8kjb/ca3qphDgIECBAgMDaAhFrK+uatceQ7AkQGFcg4h4Qlb17SZSk
do4EbKLsVEovfhfs0TDzGQECBMYQKL0HvJWle89b8volQIAAAQJrC0Ssnaxj1h5DsidAYB6BiHtC
lIZ7S5Skdj4CNlF2Y6HkgneBurAIECAwj0DJ/eBNBfeiN/X1TYAAAQIE1hIoXS9Zt6w1XmRLgMA6
AqX3hygp95koSe3YRPkaA6UXuAvTBUWAAIE5BUrvD2+quDe9qa9vAgQIECAwr0Dp+sgaZd6xITMC
BAh8C5TeLyI03XMiFNduwybKP/UvvaBdjGtfSLInQGANgdJ7RU9K7ls9VUMsBAgQIEBgLIHSNZF1
yFj1Fi0BAgSiBErvHyVxuPeU6DnXJso/Y6DkInYRupAIECCwrkDJ/aMnNfeynqohFgIECBAg0LdA
yfrHmqPv2oqOAAECLQRK7iMl8bkHleitfa5NlN/1L7lwXXxrX0CyJ0CAwF6g5J6yb+utn93b3pLX
LwECBAgQGEMgd71jjTFGfUVJgACBFgK595KI2NyPIhTXasMmyu965160Lri1LhbZEiBAoEQg915T
0mfpue5zpYLOJ0CAAAEC8wnkrmmsK+YbCzIiQIBAhEDufaW0b/elUsG1zv+5Vrp/ZvvWhfpnJD4h
QIAAgZkF9gu0Ee4/3zHu45+5VnIjQIAAAQIECBAgQIAAgTYC38+aLZ+Tt74857ap8Qy9LP2bKCUX
potshuEvBwIECPQjUHJPapmF+19LbX0RIECAAIH+BHLWLNYP/dVRRAQIEOhdIOd+k5OTe1SO2nrn
LLuJUnIhurjWu1BkTIAAgZYCJfeoVnG6F7aS1g8BAgQIEOhLIHWdYs3QV/1EQ4AAgREFUu89OTm6
X+WorXPOkn+dV4sLb50hJFMCBAgQiBb4Xrz1es/6jstiM3oEaI8AAQIECBAgQIAAAQIEPgItnpG3
Z1zPtsbcmcByv4lS+jLKxXQ2lHxOgAABArUFSu9hteNzj6wtrH0CBAgQIPCuQM5axPrg3ZrpnQAB
AjML5NyX7jzct+6E1vx+yd9EWbPUsiZAgACB0QVa/OmbEiO/nVKi51wCBAgQIDCfgBdR89VURgQI
EOhJ4HOfidxM8RspPVW4n1hsoiTUwgIwAcuhBAgQIFBVYH9Pilw0RgT+iWcfZ0Tb2iBAgAABAgQI
ECBAgAABAh+B6M0UGynG1l7AJspe5ORnL4FOYHxMgAABAl0InN2n3t5c8dspXQwPQRAgQIAAAQIE
CBAgQGB6ge25OOoZ2EbK9MMlKcF/JR09+MG5F9HZi6nBOYRPgAABAgsIbPew7//eTDn3PvxmzPom
QIAAAQIECBAgQIAAgXEEIt/jeoYdp+61I11mEyV30EdeeLWLqX0CBAgQIHAn8PaGSu79+C4v3xMg
QIAAAQIECBAgQIAAgU3g89wboeEZNkJx/DaW2ETJHew2UMYf4DIgQIAAgXOByIXleS9/fpN7X/6z
JZ8QIECAAAECvQp4nu61MuIiQIDAOgJR9yLPsOuMmbNMl9hEOUve5wQIECBAgMB//pRO1ALzialF
6BMlxxAgQIAAAQIECBAgQIBAiUDL59ySOJ3bt8D0myhe0vQ9AEVHgAABAn0JtPztlO0e7T7dV/1F
Q4AAAQIECBAgQIAAgdkEIjZSPLvONirS8pl+EyWNw9EECBAgQIDAJtB6M4U6AQIECBAgQIAAAQIE
CBCoJRDxjGsjpVZ1+m/XJspJjSJ2KE+a9jEBAgQIEBhG4LPQrH1ftBgdZkgIlAABAgQIECBAgAAB
AsMK1H62HRZG4JcCNlEOeFxMByg+IkCAAIHlBSL+5M4Voo2UKx3fESBAgACBdwXcp9/11zsBAgQI
xAmUvPt1P4yrw0gt/Rwp2BaxllxELeLTBwECBAgQeFvg+14ZvYDc2nMvfrvC+idAgAABAgR6FYhe
e33ytP7qteLiIkCglsA27+XOqZ5ba1Wl33ZtovRbG5ERIECAAIHuBT4P3LmLz+4TFCABAgQIECBA
oAOB2muto/ZtrHRQeCEQINCtgI2UbktTJbAfv2+Kv6q03EmjRwuBs9AmpzhL2+cECBAgQCBUIOXe
e9axe/KZjM8JECBAgMA7Aqn3d/fysjqlepf1dn62Op7b+IYAgTkESudb8+Qc4+Aui6n/TZTSi+AO
z/cECBAgQIDAnwIWkX+a+IQAAQIECBAg8FSgp3cZPcXy1M9xBAgQSBEofX41T6Zoj3vs1Jso45ZF
5AQIECBAYGyB0oXo2NmLngABAgQIzCXgBVG7erJuZ60nAgQIECDwVMAmylMpxxEgQIAAAQJJAiUb
KV4gJFE7mAABAgQIdCVQsgboKpHGwVj/NAbXHQECBP4RKL1vmb/nH0o2UeavsQwJECBAgMBrAqWL
0dcC1zEBAgQIECDwvwJeDNUfCJsx5/rOeiBAgMCVgGfXKx3f2UQxBggQIECAAIGqArmLUS8TqpZF
4wQIECBAgEAHAtY7HRRBCAQIEPhHIPfZdTvdfD73MLKJMnd9ZUeAAAECBLoQKFmMdpGAIAgQIECA
AAECwQJeuAWDao4AAQIBAp5dAxAnbMImyj9FdYFMOLqlRIAAAQIECBAgQIAAAQIEOhSwgdJhUYRE
gACBfwRy3xOb2+cdQj9nTc2gna+yUTXNnQjnE5URAQIE+hfY5n7zdv91EiEBAgQIEPgIuG9fj4Wo
59rrXuK+Vc84Sy0RILCGgGfYOes87SbKnOVaM6voRea+PYvCNceVrAkQaC+wzbf7OfhJFBahT5Qc
Q4AAAQIECPQskLMGSsnn6XNtShxP20yJ07EECBAYRSD3+XWU/MSZJmATJc3L0Y0FUhZ4uaF9+rBA
zBV0HgECBAgQIECAAAECBP7y26MHg6D2M23qc2zq8Qcp+YgAAQIEbgT8QcAboAG/tokyYNFWCbn2
YnPv+N2fheVex88ECBCIEcj90zwWoTH+WiFAgAABAgTaCNR8nvW82qaGeiFAgEDu8yu5+QT8w/Lz
1XTYjLZF5vd/byZSc8H7Zl76JkCAwMgC5uaRqyd2AgQIECCwjkDNNYsNlHXGkUwJEBhboOa9YGyZ
MaP3myhj1m2aqHueUD6xWaROM9wkQoAAAQIECBAgQIAAgaoCNZ9xPZtWLZ3GCRAgcCjgt1EOWZb7
0CbK75JbiNQd9zUXkXUj/7v1LX5jpIW0PggQWEXAInSVSsuTAAECBAisJVDr2dfz6FrjSLYECPQn
4Bm2v5q0jshf59VafLH+ai0iWzPOkkdrN/0RIEDgTMDLgDMZnxMgQIAAAQIjCtR4ZtzWS9ZMI44G
MRMgQOBvgRr3BrbvCNhEecd96l63CeLz30yJmvhmqqZcCBAgQIAAAQIECBC4E/AMdCf09/c1nGye
PLN3FAECBFoJ5M7LNe4RrXLWz38EbKIYDaECJoZQTo0RIEBgaoGcRaj7zNRDQnIECBAgQIDAb4Gc
NRI4AgQIECBAoJ6ATZR6tsu17MXWciWXMAECBIoFvCQoJtQAAQIECBAgMJGAtdFExZQKAQLTCeTO
0d6Zjj8U/MPy49ewiwzenAzOJrA3Y+qiKIIgQIAAAQIECBAgQIAAgSEEzp5rhwhekAQIECBAYHIB
myiTF3j29K4WmvvvbKrMPhrkR4AAAQIECBAgQIAAgbEE9s+tY0UvWgIECBB4KrC9lzTnP9Xq7zib
KP3VREQPBVInns/xPWymXMWQmtdDLocRIEBgGgGLz2lKKRECBAgQILCsgOe+ZUsvcQIEBhfY5u+r
93qDpyf8EwH/JsoJjI+fCWyTRuuJY5usShacpec/kzk/6s7r7vvzln1DgACBdQTMlevUWqYECBAg
MIZAyTPaGBnGRPn282hMFlohQIDA2gK59zzPseOOG7+JMm7tXo+81YWfOzHdAX3afZpHRBxP+9qO
i+jvzsD3BGoJXI11Y7uW+rjtbmPiasyMm5nICRAgQIAAAQIECBAgQIAAgdEF/CbK6BV8Kf7aL7s+
fzqnxcvWT19XlC3iuOrfdwRGEribH+6+HylXsb4rYCy96693AgQIECBAgAABAgQIrCrgXeFalfeb
KGvVu6tse5tseounq2IJhsBDgacvtf221UNQh90KGEu3RA4gQIAAAQIECBAgQIAAAQIECgT8JkoB
nlPzBWxY5Ns5k8AsAk83XGbJVx71BIylerZaJkCAAAECBAgQIECAAIFjAe83j11m/NQmyoxVrZxT
6csqE0zlAmmeAAECAwqU3htK700DkgmZAAECBAgQIECAAAECBAgQaCBgE6UBsi7+I1D6kowlAQIE
CMwr4B4xb21lRoAAAQIECPwtsP3BD3/4w2ggQIDAPAKeY+ep5VUmNlGudHz3h0DJYs+k8genDwgQ
IECAAAECBAgQIEBgQYGSZ+sFuaRMgAABAgReFbCJ8ir/Op3bQFmn1jIlkCLg4TFFa41j3S/WqLMs
CRAgQIAAgb/8RopBQIAAAQIEBhGwiTJIoXoIM/dlpxdiPVRPDAQIEBhHIPe+kXufGkdGpAQIECBA
gMBsAtYvs1VUPgQIECAwo4BNlBmrKicCBAi8JJD78vulcHXbsYCx1HFxhEaAAAECBAiECvh3UkI5
NUaAAIGuBWyed12e0+B+nn7jCwJfArkXuJdghhEBAgQI5Aps95Dc+09unzXP+7//8z+Xzf+f//f/
Lr/3JQECBAgQIDC3wLbu8Qw9d41lR4AAAQJjCvhNlDHr1jTqmV5gNYXTGQECBAgQ+EfgbgNlO+zJ
MUAJECBAgACB/gQiNz48f/dXXxERIECAAAGbKMbApUDJAi5yIXkZpC+zBD6/Mn70v1kNOokAAQIE
DgVSNkdSjj3szIcECBAgQIDAKwKRz78lz+GvJK9TAgQIECAwuYC/zmvyApekZ+FWotf3uXe13b6P
fAjoW0N00QKz/RVM0T7aqyvQ2/xlU6RuvbVOgACB0QSu7gv+WsfRqvlnvJHr4O9nNs9mf1r7hAAB
AgQItBSwidJSe6G+LPL6LfbdBson8t5eRPYrKjICBGoKRL6MqBnnUdtXL8qOjvcZAQIECMwtcHdf
+HxvM2XscVBj7XL3DOf5e+wxI3oCBAgQ6F/AJkr/NXolwrtF2itB6ZQAAQIECAwicPeibJA0hEmA
AAECQQIp94XvY22oBBWgcTM1NlKuUtg/v9tUudLyHQECBOIFWs/78Rlo8U7Av4nyW2i/4LhD8/21
gAXbtY9vCRAgQGBugZQXZXNLyI4AAQIESgXcU0oF3zt/ey5+69nYO4736q5nAgQIEJhTwCbKnHUt
ysqCq4jPyQQIECCwsICXXQsXX+oECBCoJODeUgm2UbM2UhpB64YAAQIECFQUsIlSEXfEpks3UN5a
II5oLWYCBAgQqCNQei+rE5VWCRAgQIBAvoCNlHy7Hs586znZmqiH6ouBAAECBGYQsIkyQxWDcihd
YL21MAxKXzMECBAg0KnAKPeXiBdc/u77TgehsAgQINCBwHafibjXdJDKkiG8tZ4pfc5fsliSJkCA
AAECOwGbKP+AWFiUXRtvLQjLonY2AQIECBDoR8AGSj+1EAkBAgR6Fmi1keIZOX4UvPXcrJbxtdQi
AQIECKwlYBPlq94rLyxKcn9rIbjWpRqX7dN6PT0uLjItESBAYFyB0hdaNlDGrb3ICRAg8IZA6X3n
jZj1+beA5ywjgQABAgQIjCcw7SaKhcl4g1HE7QTuro+779tFqicCBAiRy5RzAAAgAElEQVTkCZT8
4YDUHktfZNlASRV3PAECBMYTqDHXl95/xlOcJ+I3nrdaro3mqZRMCBAgQIDA3wLTbqLkFtjCIk3u
jcVfWoSOPhPYanf239k5PidAgACB/xYofYFV46WaGhEgQIBAnwLm/D7r8lZUn2ext/p/s9/tvUvU
f2/moW8CBAgQWEfAJso6tZYpAQIECBAYViBn0773PxjhZdqww1HgBAgQyBaInvv9Y/PZpejmxO8/
2NZNUBUC+d40iWy+9/VeZK7aIkCAAIH3BH78vmH/eq/7uj2X3EwnZjlEz7FazegQLvHDFGe+ibgO
70rAWO+qHNMEkzKuPknXnEtLfgsl+iXaNEWWCAECBBYSKLmPHDFF31tS77s177lH+a74WWpN9kZv
1ag07n0eRz+/ldtRLD4jQGBNgZS5zpw13hiZehNlK0fKAP4u32qDOdVpNZ+oSzvFmXGUunbeEDDW
31Cfv8+UcVX7nl764iv6Rdf81ZchAQIE5hYova98dCLvLyn3Xc8u74zPlBp9Imxdq5wYczVb55Yb
p/MIEJhTIGW+M1+NNwam/+u8cgdlysAfr+xlEeealvXqbAIECBAg0IdA6YuuyBdcfYiIggABAgRK
BaLuDaX3qNI8nN+/QMt3HS372uRb99d/tUVIgAABAlEC0/8mygZVciNdZcMgxWgVk6iL7LsdzjVU
tdmjgLHeY1XmiCllbH1nHHHvingxFfWSbI5qyoLAfwQirq+9Z0/X21V+PcW5Nzz7ebZ8zvJ84/Mr
25R4IsZVyj034j6bkp9j/yOQUqfPWS3qlRNXVF1b5BcVq3YIEJhHIGXeM0+NV/clNlG2sqQM5O8y
rjKoU3xWMalxOXOuoarNHgWM9R6rMkdMKWNrn3HJ/SvipVbEC619Tn4mMINAxPV15tDiuouIv0Wc
Z0ZPPk/NsVU+qXF9ci2N72m/uf08bf+udrn9f9pNueeW3GPv8vD9tUBKnT4t1a5XTkzXWaZ/WzvH
9IicQYDA7AIpc585arzRYBPlpmarDGoX+s1ACPqacxCkZroXMNa7L9HQAaaMr+9Ec+/pvbzMGrpo
gu9C4Gosl75szU3wKqbcNvfn1cwtMv6ace5Nnv5ckl/tfEpi2/LPjS+131b9nNU0t/+tvZT7be49
9ixunz8XSKnTd6s1a5Yb0/Os74+smd9979dHPPHpOf7r7J59e2cwe/7PlBw1msDduP7Oxxgfrbp/
/fVzvJDzIt4GZ8pgzuvFWQQIECBAgECvAts6IHWxmvqy7Cz3kpdYZ22+8Xmux5v5P425ZoxPY9jX
NDKmuxi27yP72+cy4893piPn3HtuEfHljPmcfnP62cbOdj3m9DfyuBP7HALeu/ynjiUWT85NXdf2
MsKe5Jazbu8lP3EQIDCnwDKbKLnlM3HnyjmPAAECBAjUEWj1ByOiXl5dvZhO6eOqnTrS/2k1Jc6j
WHJfIh61lfJZSty1YkyJYZ9bVExPY4jqb5+Hn/sVeDo2+s1g7shspMxd36jsctdFNd51PHk5HpV3
z+20cqhRw9quKTYj5lfbT/sECLwn8K/3um7f86i79O2l9EiAAAECBOYUSHlwixC42vhIfXmZenxJ
/Ftf3/+VtPU5t2X8W585/eWcc2UT0V5EG1cx+m5dAWNrjNpf3UfGyECULQS864hR3taJZ/897aH1
WrN1f08dHEeAAIHZBJbaRNmKZ3Hx5xB20/3TpMYnnGuoapMAgVUFRrifX734yn15mXteyjhp0UdK
PI4lQCBewHUeb6pFAgTKBbb13f6/8laftXD3vH73/dbLk2OeRTPXUd8bU3Nl1kc23745/38fWYiC
QP8C/jqv/mskQgIECBAgQOBAIPevrzhoKvyjqw2U8M4CG/RiNRBTUwQIECgQMB8X4Dl1OIGjPxzT
ckPiaV/bcUexbuBP2xiuOIUBcykEvDk9wnffxtkYvwnF1wSmF7CJ8qDEVzfKB6c7hIAFlTFAgACB
jgRq39dH3UDpqERCIUCAwJICPW2c7F+qLVmQwZLu+Q+XXFEevbDtefwdrSN7jvfKvvZ3b7tE9X80
Rmvb3bUfldtRP5+2e8z7KF6fEWglsNxf59UKVj8ECBAgQIBAfYHeFvc2UOrXXA9zCdS+Zmq3H1WN
UeJ8mu9s+TzNu+S4njZQSvJwLoEUge913Pbi9vNfShtHx7ZcH9Z8mX2U25PPvi33//+T8yOOedsl
sv/Itkay7S3vCDttECgRWHITJeeGOuvkMWteJReFcwkQIEBgfoEa9z8vDecfNzKsI1Dr2qnV7kch
qv2odupUJ73VFvlE9JHTRq1zam2g5MSbXnFnEMgT2G+g5LXy3lmfzYn3Ijju+W6Ne/f9catpn7bo
4yqiGv3XaPMqh7PvWsfR6zg/8/E5gZoC/jqvmrraJkCAAAECBKoLbA/hrR8ojpI6egnmBdaRlM9a
C2zj8Gh87uN4c7y+2ffeIeXnp7ZnbY6adw/5lNiXuKf0+6SfJ9fmmbfPCcwg0MMaLtWx15ifxrUd
l/OHi584PY3hSVs5MUb2/yTGlse8mVvNMdPSUF8ESgR+/J6UfpU0MOq5uZPPbFypDrPl32r8cm4l
rZ9eBFLGvHmll6qNHUfKmPvO9Gr8Rb3YOnqJVtL2UXtR1SuJ6y6GmnGf9Z2aT40YU2PY5xIZ01Us
kf3sc/BzfwJXYyEl2h7GTWouPcT8MU6NvWVtUu+rV/fTlLgdWybwdt1S+t/GTMrxT2VyxmKNOJ7G
W3rcd74peeQ43cWa0v9dW7nxRcawjzE3pn07OT/XzCslnjcNUuJ869iUOrF8q0r5/dpESbSbbZCn
XOAb1Wz5J5Y/+3DO2XROHFQgZcybVwYtcmdhp4y579Cvxl/0y639i7uc9vdtRJchJ6YnMdSO+yqG
pznVjPFpDPs8asa078vP6wnkjstNytgsHy8l/ne9R9Qn9b56dT+9i9f3MQKpNdt6ja5bSgxb3ynH
P1HKzSc6jiexRhyzzzclj/25pfGk9P2kr9z4ouP4jjU3pif5Xh1TM6erfs++e8vhLJ6ePk+pFcee
KvcslmU3UTaelMH9zTnTQE81mCn3Z5dIzFEpzoxjzLXyrkDNMf+kbdfRu/V/q/cnY+MotrPxUusF
1/fLrZQ+Il6KHeW//ywlps+5rWLbx+pnAgTKBFKvd9d6mffn7FT3lF6japRyTz27j6bE7dhygZSa
fXqLrl1ODOWZ/91CaS4tY38S6108R23cnfNtfXR+SS1S+r7rJze2yBiOYsyN66itJ5/VzudJDGfH
tLY4i6O3z1NqxrC36t3HYxPl3ujwiFkGe8oFvkHMkvdhUSt+mOLMuGIhNN1MoMaYT2nTfNWs1F11
lDpGPsGfzbs1X3JtfUe96KpRhKe595xDDRdtEiBAoFTg6fya2k/kfJx6Pz27j6bm4Ph8gdSafXqK
rl1uHPmZ/31mRB4tYo+I88oqJYfIWFL6vYp/+y43rsgYzmLMje2svf3nLXLY91nyc22PktjeOjel
hvzeqlJ+v0tvomxsKQN8zzzDgE/Jf4Z89zVs9TPnVtL66UUgasyntHOUu3nrSGXuz3LHzNFYqfWi
a1+ByBdf+7b9TIAAAQL9CNS4r9S4h6TeS4/uof2ozx9Jar0+IjXqlhtLSZWi8qgde1ScV1apOUTF
lNrvWQ658UT1fxZXzWvm03arHO5yTPk+t14pfYx2bEod+Y1W3b/++td4IfcTccrF0U/U+ZGslm++
lDMJECgR2Oaaz38l7TiXwCgCNV6qjZK7OAkQILCKQI25vsYGyir1eCvP73Vuyf//Vvw99bu9gBzl
JeQocabWt/SZ7VPDklrO8J6qVg4RvqljwvEEZhZY/jdRtuKWTlgj3xBTcx851zcv5BTnWsZPYqjV
95v2+n5H4Ml4axGZMd1Cub8+csff0Xip8dLrTMzLsDMZnxMgQGB8gaj7SYt7Rep99Oj+OX7F4jNI
db2LYHMvabNG3Uriucv3832NuD9t14i/Zrx7s9T4S2JL7Wsfa0nfNeu1j/P754iY9+2XOu7b+/z8
JNbSvp/0cRbfrJ+nmPIbbxTYRPlds5RBflTikQd+Tu6j5HuVW+scrmLZj6kasb3d/z5HP88vkDLm
amrUuJ5qxqvtGIHc8Xc2XqJefD3NrsULsqexOI4AAQIEygVK7yOt7wup99Gz+2e53DwtpJrWzrxW
zWrnWSvuj3d0/LXj3Y+T1Phz40vtZx9nbr/f7ZTGsI/pyc8Rce/7ic4jJ8bcGHL62uc/288plvzG
q76/zut3zUoHbspFMt4Q+TPiLd+ec34SX8/x/yle9klqrqnHl0X332d/apf6v5ExaIsAgfEFcu/r
Z/Nf65dXpS/bxq+gDAgQIEDgI9D6HkSeQIlA6hrs6fHbcU+PLYk/8tzR4o3MvXZbZ2v22v1Gtx+d
R+6Yyz0v2kN7BHoXsInyT4VKJ43oya/3gbPF12POKTGlHDtCPUaPsaQe27mf/0Z3ED8BAn0KbC+x
Wr7IspHS5zgQFQECBFoKtLzv5OZV+hyd26/z8gV6q9ldPHff50v8eWbLvv7svf0nOc/QJc/tW4al
xqX95yqXxr3vNzqP0vi280vb2OfoZwKzCfjrvHYVLZ3IRpt0SvPd+HrIOTePVrGnxBcdU0rfn8sh
Ooa7iTMnxqs2W8d/Fcuq30XXNNfRWMiVm+O8nHGYO2ZqbXqM8AJtjtEiCwIECNQTyLlHvDn/p9w/
c++b9bT7bDnFtGYGLeqVmmuLmFJMU+M/avvNnHLjfxJzbtvfRk/6OTL9fBYRw1X7Z9+Vxv3dbnQO
kbFtcT6JL7rPM/fRPn9i98mJ4WjV/esvv4myq1npIN4umJSL5u0hU5rvZ4Jtnfenv9b9vl2vGfuv
cb3UaHNG++icvq/L6LZz2ouY33L6dc6aArVeduW8eFuzArImQIDAPAK17inzCMmEAIFogatn6NXf
u/T8XFkjtrs2776PHpvaI9CLgE2Ug0pETAhXN6CDLqf5qNbN9fvl7Kq20wySr0Rq1rJm2zPW4mlO
+2vx++enbbQ4LmIebxGnPuoKtB4Htf7KLxspdceJ1gkQIECAwAoCrddFK5iukGPkc3XpGIyM5Wnt
SmN+2k/OcTVj29o++y8nVucQmEHAX+d1UsWoybnmpHYSetbHUfnedZ7jUTO2nHjucjz6PiWH6JhS
+v7EHh3Dkcn2WU5sZ22dfd4ql7P+R/68RX0ifdQ6UnOetlLHceQ4qrn54U8pzzNGZUKAwPwCKfeD
Hub3lHtn5H1z5pGQYlrDoWWdUnNtGdtT29Qc9u2+mVNk7KVtfbuUmkTGsq/X1c+lcR+1XZpLjZiO
4vRZukBKbdUx3fftM/wmykkFogZzygV0EkqTj6PyvQt280gxSTn2rm/frylgDKXXPfU6Te8h9oxt
/mo1h8VGrrUWAm+OjVq/mbK5pbyQa+GsDwIECBCYQ8DauU4d31yPvNl3Hc36rTKL/QOPo3r2FPfn
mbenmOpfiXog0JeA30S5qUfUInKUiS4q3xvWbr5uVZcU1+iYUvr+FCY6hrOC58R21tbV563yuYph
lO9a1aTUQ01LBdc6P2Vc1xxbNTY+evgTy2uNJtkSIEAgT+DJPaCHOT3lnrlJ1Lxv5kn3fVaqb2k2
b9QnNcc3YnzimprHp80e8smN/fuaLmnj2zfKIyqeJ7X/dnh6fMpxOblEOabE6dh0gZTaqmm679tn
2ER5UIGUi+CquVEukKh8ryx6+K5lPVJMo+NK6ftTl+gYjuqdE9dRO08+a5HPkzhKcm6RQ0l8T/Iv
PaaFQWmMzu9TIGVs1x5nT16ipSr28NItNWbHEyBAYEWBq3tAL3N5yj1zq2Ht++aK4+STc2ot9lZv
1iY19jdj3buV+veQS6r/t8EWf8n5n7aiHSJiOqv1/vPo2Pft5+RSO6Z9jH7OE0iprZrmGb95lk2U
h/opF8JZkyNdIBH5njn08HnrWqR4RseW0vdWm+j+j+qdGtNRG6mftcjrKqaInGvnEBHjlcHT72rn
+TQOx80jkDq2a4/Bq5doueq9vHzLjd95BAgQINCHQG/3zD5U3ositR6fSGuvZe5EUuOuEe9VDE/6
uzr/Kv8nbV+dH/VdbvwR/dcwaJVPjdj3pjm5tIhrH6ef0wRS66qmab49HO3fRHlYhYjBnXpBPQyt
ymER+VYJLKDRmXML4KnexEjXQRRGVM5R7UTlFd3Odm26PqNVtdejgA2PHqsiJgIECBAg0J/AZ338
dI1sPf13De+em+6+31p5at7fqPk7otHjb+3q2mktrj8C4wnYREmo2Wo3oRnznTGnhCE89KGltXuy
UE4F2to8+y+1rafH18jjad+1jrNgrSWr3Z4FbKT0XB2xESBAgACB/gQ+a+ar/+0v6mcRRT7jPG3r
yXGlz6DPsq931BvPWSOZfV9L9aqgZQIEZhGwiZJYyZFuCImpHR4+U74z5XJYrAE+fLJQvUrjjUXg
WTx3uXy+vzvurP2rz2u0edWf7wgQqCNgI6WOq1YJECBAoI2A56s2znqpJ+C5KtZ2lDmhp/cKsRXQ
GgECNQVsomToltwYRrxJl+SbwRt6yufmOHIOoSCTNPZ2PZ9ex0+Pm6Qs2WlwyqZz4gQCNlImKKIU
CBAgQIAAgWKB0meC7fzSNoqTWLiBt5/Rr+i/3wv1HOdVDr4jQOB9AZsomTX4TMI5p494Yx/lpjNK
nDnjpsU5NRcUJeO+ZlwtXGv0UeJZIx5tEiCQL2AjJd/OmQQIECBAgAABz0bvjoFen9dL3tu9K6p3
AgR6FLCJ8lJVRr/J93Qz+t44eamc03Tb47jsdUHWQ9F7qpcNzB5GhBjOBFLnkTeuLRspZ9XzOQEC
BAgQILCKwNM12Hbc93+r+PSYZ+o6u0UOPb2vapGvPsYT6PG6GU+xfcQ/fhfuV/tu5+rx6Y1+n/XM
9Lkme6O7n0cxTPGIziml7807uv9PDVPjuIolp62r9u7G2f773P737UT9HFmzJ7k96e9JO9/5P2kz
yks7awqMOCb/7//8z6Ni2YB5xOQgAgQIEHggkHK/tH57ALrwISljac90NrZK2tz38fn5rK/P9yl9
3rV1FkOLz1PyeBpPy3xT4m8Z11Or7+NScnk6TnPicE6sQEpdex+jsTLztGYTJaCWKRfKvrvZL5wS
m73V98+juaU4ROeW0vdmHN3/p26pcZzFktPOJ4ao3EpiuBrXJd9F5bbFcJXf036u2jjL82nbZ+f7
nMCVQOqY7Gk8Xm2m2EC5qrrvCBAgQCBVIOV+2dO9MjVPx7cRSBlP+4i+x1dJO/t29z8/GcdP+n/S
zr7vlj8/ySElntb5psTfIra7eK5iuDv3qA5X7R0d77P2Ail1Vc/29Yno0SZKgGLKhbLvzoWzF5nz
55QxEj0mUvre9KP7/1Q0Io7UNvajKSq30jj2cUX9HJVfRDw5Rj3FH2Ggjb4EUsek8dhX/URDgAAB
Am0EUu6X7pVtajJyLynj6a08n47jq1yetvFWjlu/V/GnxvVGvinx147vaSxXcTxt41Obq7ZS6+f4
OgIpNVXPOjWo3erP2h2s0P42+FMulm+T7TwXzwqjRI6lArnX2Kff3q+zknnkk+PHqIdcI/IpHTPO
J0CAAAECBAgQIECAQIRAD89YEXmUtDGKQc33bCnvJWrGUVJH5xIgkCfgH5bPc/vjrJKbScok/EfH
PiAwocD39bRdH71dIyXX+1W5otrtzesqZ98RIECAAAECBAiMKWDNOWbdWkYd9XxTK+be46uVd067
rHLUnEOAwEwCNlECq+mmEoipqaUFPhsnUQ9mK16bUXZLD0TJTyWQOg+4hqYqv2QIECBAgACBlwRS
12Ctwuw1rlr5l+Rbcm6tfO7atZa/E/I9AQKpAjZRUsUqHW+CrwSr2eX/urhaC77Idr/bimzXvGIC
IECAAAECBAgQIEDgbYHIZ5yIXHqLJyKnJ22slnfk8/DnD3o+cXYMAQJzCthECa5ryU0pcoIPTktz
BAg0FCiZRxqGedvVLHncJuoAAgQIECBAgMCiAp5hFy38oGlvzyerP6OkGozu9dn8KJmrSs4d9FIR
NgECBwI2UQ5QfESAwBwCIy/4omK34JtjLMuCAAECBAgQIECAwMgCUc83qQafTYO3+k+Nt9XxTzZT
ZjNLfTb22yetRqN+CIwh8HOMMMeKcrvRpE7Onwy382a7UY1VPdHOIjDDdfTJIXc+Ga2W5r/RKiZe
AgQIECBAgMBf//vsO8PaWy3rC5S8K8mJzri8VxvFKGrsnM1Xqzxz348IRxAgcCbgN1HOZAo/L7kR
mbwL8Z2+vEDJ9ZeCN1s/Kbk7lsAKAu7HK1RZjgQIECDwLdBqfUt9XYFtjNUaZ5+2a/axbuXmyfyz
xt/+9/PfPNnJ5A0Bz41vqLfv0yZKe3M9EiBQUaDWgrxWyE/jfXpcrTi1S2AGAdfRDFWUAwECBAj0
KOAFUo9V6TumyHWZTZO+a91jdG/PWSnjP+XYHq3FRGAWAZsoFStZMtG9PaFXZNE0gWoCJddcblAl
faaem3p8bk5vnmfue1Nf3wQIECBAgACBfAHruHy7Vc8sfb7Zzi9tY1X7EfMerdZ38d59v9XoyTEj
1lLMBEYU8G+iVK7aNuHlLia380yYlQuk+WkEVrlWSuaUaYotEQIECBAgQIAAgWoCJetNz7DVyjJt
w0fPcXfvUI7OmRZIYv8lUDI/taR8OkafHtcydn2lCdzNV2mtObpnAZsoPVfnd2wWoZ0XSHhdCLy9
8MhZyJXEnNqfeaSLYSoIAgQIECBAgAABAgQeCJQ8Kz1o3iGDC6Q+D7dO1/htLa4/Am0E/HVeDZxL
J1C7mg2KpIvhBLbr6vPfcMEvFHDp/LcQlVQJECBAgAABAt0IlKzhPL92U0aBEJhWoGSOqoXi/UQt
2X7bdb/rtzY1IvObKDVUD9rcJtOSi8ufJD9A9dFjgafjr8eFyFGSJXE+uQ5L2j+Kd/9Z7fb3/W0/
m0OOVHy2osDT+XBFGzkTIECAAIEoAWvPKEntECBwJvB5rn7yjH/WRtTnbzzjR8WunTyB3HFnrOR5
93CW30TpoQoPY8i9QB8277DJBe4m6rvvS3ki28+9Fp6e9/S4b5On+T09rtT76PycvI7a8RkBAgQI
ECBAgMD8AqXrVmvP+ceIDAn0IFA6V5XksPX9Zv8lsTuXAIE0gR+/L/Zfaac4ukSgdCGpXCX67577
pPYr1PeJQ26lzvxy+zxr7yq+q75y2jvr66qfs3M+n0fGcdfX9n1qrK3je5KDY+YSMCbnqqdsCBAg
QKCuQOp9cx+Ntd1exM8ECNQSKJ2vUuIyt6VozXds7lgzbsYdCzZRXqhd7oX2CdUF90LRgrq8qv1K
db1yCKL+958GKemr55qU5LUZt8wtNdaWsUWNN+2MJWBMjlUv0RIgQIDA+wKp9859xNZ3exE/EyBQ
S6B0vrqLy3x2JzT/97ljzNgZe2z4N1FeqN920eRecC+Eq8tAARPm35gtroHZr7FSw83HeAy8uDVF
gAABAgQIECBwKvBZm1t/nhL5ggCBIIHSZ+XvMMxZQUXRDIEJBPybKC8VsWQinv3l8Esl0W1jgZJr
oHGouiNAgAABAgQIECCwtEDU2t2z7NLDSPIEmglsc1bOvPU5L/f8ZgnqaDiBnPE4XJKTB+w3UV4s
8HYB5S4i/SnyFwun6zCBkmsgLIiBG+I3cPGEToAAAQIECBAYTCBq7elZdrDCC5fAwAJeXA9cvIlC
Nw7nKKbfRHm5ji6klwug+9cFtmvAdfB6GQRAgAABAgQIECBA4FYgat2+baTk/oHC2yAdQIAAAQIE
Kgm4d1WCHaBZmygDFOksRAvPMxmfjygQ9UA2Yu4lMc/mNls+JbV1bj0B46yerZYJECBAYH6ByPvo
55nWS6n5x40MCRAgMLqAe9XoFSyL3yZKmV/I2aWLUBdxSBk00oFA6bUQmUJPsdzl1XusT+N7etyd
h+8JECBAgAABAgTqCtRYt9lQqVszrRMgQIBAvkDuu9ca98v8LJxZImATpUSvo3P9VkpHxRBKkUAP
N5geYkhF3GLuOe672O6+T/VwPAECBAgQIECAQF2Bmus3z7d1a6d1AgQIEHgukLuB8rwHR44g8OP3
wufXCIGuEGPURamkK4yW+XOMuh5SpGa5dp7YzZJrSn0dS+Bb4Ml18jne9WLsECBAgACBc4GUe+p5
K/ffuB/fGzmCAAECBGIFSu9x7l2x9XizNb+J8qb+ru+oC6v0Au+IRCgLC2zXQ9Q18YSxZV9P4ik5
5i6Xu+9L+nYuAQIECBAgQIDAWgKt1pbbc+7nv7WEZUuAAAECBAi8LfDz7QD0X0dgW1y2WszWyUCr
BP4WOBrHURuFR23P4j5zbrPUSB4ECBAgQIAAgVkEtrVn1Br9icmnL2veJ1qOIUCAAIE3BNyj3lCv
16e/zquebXbL0YtPF212KZw4gEDu9eK6GKC4QiRQUSBl7jBfVCyEpgkQIEBgKoGU+2t04u7X0aLa
I0CAAIHc+5p70nxjxyZKpzXNvUiv0nEBX+n4bnSBp9eM62D0SoufQIzA0zlj6828EWOuFQIECBBY
RyDlPltDxb27hqo2CRAgsJ5Azv3MPWjOcWITpeO65lyoT9NxQT+VchwBAgQIzCaQen91z5xtBMiH
AAECBFoIpN5vo2Ny/44W1R4BAgTWEsi5j7n3zDtG/MPyHde25oW3TQSf/zomEBoBAgQIECBAgAAB
AgQIDChQ83n2CYfn3SdKjiFAgACBKIG373tReWjnWMAmyrFLN5+2uABtqHRTboEQIECAAAECBAgQ
IEBgGoHtebbFM+0VWM6fJL5qz3cECBAgQIDAegI/10t5vIw/i84Wi7/vPt5e7I5XKRETIECAAAEC
BAgQIECAwF7g+9myxXPtvv+7Pj377sX8TIAAAQIECHwL2EQZaNGEoz8AACAASURBVDxsC7u7xV9k
OjZUIjW1RYAAAQIECBAgQIAAAQJvb6gcVeDz7Gsz5UjHZwQIECBAgIC/zmuwMbAt6t5Y2G2LypYb
OIOVRbgECBAgQIAAAQIECBAgkCjw1vPtWZieec9kfE6AAIG1BNwP1qr3k2x//F60/HpyoGP6E3j7
gjZ0+hsTIiJAgACBe4GU+6d73b2nIwgQIECAQKRAyn06st99W9YAexE/EyBAYA2BnPuQe8b8Y8Nv
ogxc47cv0JxJZWBuoRMgQIAAAQIECBAgQIBAZYHPb6f08LzrmbdysTVPgACBzgTM+50VpKNwbKJ0
VIycUHpYWObE7RwCBAgQIPCGgEXxG+r6JECAAAECeQKfDZW8s2PO2tYO1g8xllohQIBAzwLm+p6r
835sNlHer0FxBG8vLE0yxSXUAAECBAgQIECAAAECBAicCPTw2yk2U06K42MCBAgQILCAgE2UiYr8
5maKjZSJBpJUCBAgQIAAAQIECBAg0KnA2xsqnn07HRjCIkCAAAECFQX8w/IVcXto+o0F3tt/xVgP
7mIgQIAAgf4Ecu6J7mn91VFEBAgQIEDgWyDn/h4laJ0QJakdAgQIvCtQci9xL3i3dq16/9mqI/28
I/B9IZdMCCnRH/VjQkkRdCwBAgQIECBAgAABAgQIPBH4PGsePYc+Ob/kmE+fnndLFJ1LgACBcQXM
/+PWLjVyf51XqtjAx28X9ue/1mm8saBtnaP+CBAgQIAAAQIECBAgQOAdgTdfZG3Pu55536m7XgkQ
IPCWwJv3nbdyXrlff53XytX/J/fWiz2TjEFHgAABAm8IpN7v3K/eqJI+CRAgQIBAPYHUtUBuJNYQ
uXLOI0CAQHuBnHuDeb59nd7u0V/n9XYFOuj/+8LPmThSU/juw6STqud4AgQIEMgRaHF/y4nLOQQI
ECBAgEA7gc/zZ+11wad9z7vtaqsnAgQIECBQU8AmSk3dAdtutaj80BwtXi00Bxw4QiZAgAABAgQI
ECBAgMAgAtsz59GzaHT4Wx+eb6NVtUeAAIE4gRb3grhotfSmgL/O6039QfruYUKx8BxksAiTAAEC
nQqk3svcdzotpLAIECBAgECwQOoaIbd7a4tcOecRIECgnkDOPcB8Xq8ePbfsN1F6rk4nsbX6UzpX
6R5NaiatKzHfESBAgMBH4OgeQocAAQIECBAgsAl8nitrrxe+2/csa+wRIECAAIGxBP41VriifUug
x0Ve7UXuW9b6JUCAAAECBAgQIECAAIG2Atszb6vn3u1Z9vNf2yz1RoAAAQIfAe8VjYUUAZsoKVqL
H9tqQZnCbOGZouVYAgQIECBAgAABAgQIELgSaLmZssXhmfaqGr4jQIBAXwI9vhvtS2jeaGyizFvb
Kpn1OlnYPa5Sbo0SIEBgeIGc+0Ov97rhiyEBAgQIECAwkEDr9YDNlIEGh1AJEBheIOc5cfikJVAk
4N9EKeJb8+TPYrK3CecuntaL4DVHh6wJECBAgAABAgQIECAwh8Abz77751rPsXOMJVkQIDC+gPl4
/BqWZGATpURv8XOPJo/9gq8norPYjvLoKW6xECBAgAABAgQIECBAgMB7Am9spnyy/TzHem59r/56
JkBgHoGzd4PzZCiTWgI/ft+If9VqXLtrCswwIbks1hy7siZAYC6BnPuR+X+uMSAbAgQIECBQQyBn
jREVh7VKlKR2CBBYRSBqzjb/rjJijvO0iXLs4tMAgahJKiCU0CZMmqGcGiNAgEA1gZz7kDm+Wjk0
TIAAAQIEphPIWWtEIVizRElqhwCBGQWi52dz7oyjJC0nmyhpXo7OFIievDLDqHaaybQarYYJECCQ
JZB73zGfZ3E7iQABAgQILC2Qu+6IQLN2iVDUBgECowvUnofNtaOPkPL4baKUG2ohU6D2BJcZVthp
JtgwSg0RIEAgSSD3/mLeTmJ2MAECBAgQIPAlkLv+iEK0jomS1A4BAqMItJp3za+jjIi6cfqH5ev6
av1C4GgSajUBXoQV9tVZLkd5h3WqIQIECBAgQIAAAQIECBBoLvB5zjt7Dqwd0He/njlra2ufAIE3
BN6aX9/IVZ/9CfhNlP5qIqKdwAqTpEWuYU+AAIEYgZJ7hrk4pgZaIUCAAAECBP4WKFmXRBla30RJ
aocAgZYCPcyfW77m0JZV77svmyh910d0/wj0Mnm2LojJurW4/ggQGFmg5F5hvh258mInQIAAAQL9
C5SsU6Kys96JktQOAQKlAj3MiXc5mDPvhNb63ibKWvUePtsRJtmWyCb0ltr6IkCgd4GSe4T5tPfq
io8AAQIECMwhULJeiRKw7omS1A4BAk8Eepj3nsT5fYx5MlVs/uNtosxf4+kyHHHyfbsIJv+3K6B/
AgRqC5TcG8yRtaujfQIECBAgQGAvULJ22beV+7M1UK6c8wgQuBLoYX67iu/uO3PjndCa39tEWbPu
U2c9+mTdU3HcOHqqhlgIEDgTKJn3zXNnqj4nQIAAAQIEWgqUrGci4rQmilDUBoH1BN6eu6LFzYXR
ovO0ZxNlnlrK5EZgton9Jt3mX7vRNCfXIQEC/wiUzO/mLsOIAAECBAgQ6EmgZF0TmYc1UqSmtgjM
I9DLHBUtas6LFp2vPZso89VURgkCs07+CQTVDnUDqkarYQIEvgRK5nHzlKFEgAABAgQI9CpQssaJ
yslaKUpSOwTGFehhLqqlZ46rJTtnuzZR5qyrrAIEZr5RBPBkNeEGlcXmJAIEdgIR87P5yLAiQIAA
AQIERhCIWPeU5mndVCrofALjCPQw59TUMp/V1J27bZsoc9dXdsECs99Mgrkum3PjuuTxJQECO4Ho
+dccZIgRIECAAAECIwlEr4Vyc7eGypVzHoF+BXqZX2oImbNqqK7Zpk2UNesu60CBmW82gUy3Tbmx
3RI5gMCSAjXmWPPNkkNJ0gQIECBAYAqBGmujHBjrqRw15xB4T6CXuaOFgPmphfJ6fdhEWa/mMm4k
sNINqhHpZTdukpc8viQwlEDN+dNcMdRQECwBAgQIECBwIVBzzXTRbchX1mQhjBohcCsw8jxxm9w/
B5hPnko5rkTAJkqJnnMJJAqscPNKJHn1cDfaV/l1TuAPgRZzpOv+D3YfECBAgAABAhMItFhHRTNZ
l0WLao/AfwRGnBOe1M+88UTJMTUEbKLUUNUmgUSBWW9uiQzdH+5m3X2JBNixQA/znGu44wEiNAIE
CBAgQCBMoId119NkrM+eSjmOwHOBkeaAfVbmhL2In3sRsInSSyXEQeBCYOQb4EVa033lZj9dSSUU
INDT/OUaDSioJggQIECAAIFhBHpah0Whjbaee1KD0XKKqOUTl+9+ooxS+03JNSrGlD6Pjq2Z41F/
JZ/1YlaSg3PXEbCJsk6tZbqAwEg3ywXK8UeKNRYINWpeI84/MHwwtUCNcVkKZlyXCjqfAAECBAgQ
GFWgx7XZqJbiJhAlkPJ8Mss1nJJzlLN2CEQJ2ESJktQOgYEFZrkhD1yCrkO30Om6PF0F1+tcYgx3
NUwEQ4AAAQIECLwo0Ot67UUSXRMgUEHAM1gFVE2+KmAT5VV+nRMYT8Cie7yaRUc8ymLoyVjd55Jz
TrTviO09cXsrr32N34pDvwQIECBAgACBHgV6Xsf16CUmAgSOBTx3Hbv4dB4Bmyjz1FImBF4RsOh+
hV2nBAjcCFjE3wD5mgABAgQIECDwj4BnOkOBAIEUAc9aKVqOnUXAJsoslZQHgY4ELMI7KoZQCCwk
YDG/ULGlSoAAAQIECIQLeI4LJ9UggWkEPGtNU0qJZArYRMmEcxoBAs8ELMSfOTmKAIE8AYv5PDdn
ESBAgAABAgSuBDzHXen4jsAaAp611qizLJ8J2ER55uQoAgSCBCzGgyA1Q2BxAQv6xQeA9AkQIECA
AIEmAp7fmjDrhMBrAp6rXqPX8WACNlEGK5hwCawuYBG/+giQ/8oCFvgrV1/uBAgQIECAwIgCnt9G
rJqYVxDwbLVCleUYKWATJVJTWwQIdClg4d5lWQRF4LGABf5jKgcSIECAAAECBLoT8DzWXUkEtLCA
Z6uFiy/1IgGbKEV8TiZAYEYBi/wZqyqnXgUs4nutjLgIECBAgAABAnECnrHiLLVEIFfAs1eunPMI
/PWXTRSjgAABAokCHgASwRxO4EDAAv4AxUcECBAgQIAAAQL/K+CZy0BoKZDybDLq2EzJsaW9vgiM
ImATZZRKiZMAgWEEel9UfRZPvcc5TMEF+ljAwv0xlQMJECBAgAABAgQIEJhAoOZzt+erCQaIFIYR
sIkyTKkESoAAgboCNRd3dSPXeu8CFve9V0h8BAgQIECAAAECBAgQIECAwJnAz7MvfE6AAAECawns
X3TbVFmr/jWy3Y+pGn1okwABAgQIECBAgAABAgQIECBQU8AmSk1dbRMgQGBgAS/ABy6e0AkQIECA
AAECBAgQIECAAAECBEIE/hXSikYIECBAgAABAgQIECBAgAABAgQIECBAgAABApMJ2ESZrKDSIUCA
AAECBAgQIECAAAECBAgQIECAAAECBGIEbKLEOGqFAAECBAgQIECAAAECBAgQIECAAAECBAgQmEzA
JspkBZUOAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECNgEyXGUSsECBAgQIAAAQIECBAgQIAAAQIE
CBAgQIDAZAI2USYrqHQIECBAgAABAgQIECBAgAABAgQIECBAgACBGAGbKDGOWiFAgAABAgQIECBA
gAABAgQIECBAgAABAgQmE7CJMllBpUOAAAECBAgQIECAAAECBAgQIECAAAECBAjECNhEiXHUCgEC
BAgQIECAAAECBAgQIECAAAECBAgQIDCZgE2UyQoqHQIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBG
wCZKjKNWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgckEbKJMVlDpECBAgAABAgQIECBAgAABAgQI
ECBAgAABAjECNlFiHLVCgAABAgQIECBAgAABAgQIECBAgAABAgQITCZgE2WygkqHAAECBAgQIECA
AAECBAgQIECAAAECBAgQiBGwiRLjqBUCBAgQIECAAAECBAgQIECAAAECBAgQIEBgMgGbKJMVVDoE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAjIBNlBhHrRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQKT
CdhEmayg0iFAgAABAgQIECBAgAABAgQIECBAgAABAgRiBGyixDhqhQABAgQIECBAgAABAgQIECBA
gAABAgQIEJhM4Odk+UiHAAECBAgQIECAAAECBAgQIFAs8OPHj9s2fv36dXuMAwgQIECAAIGxBWyi
jF0/0RMgQIAAAQIECBAgQIAAAQLBAk82ULYur46zwRJcFM0RIECAAIGXBGyivASvWwIECBAgQIAA
AQIECBAgQKA/gauNkZRov9vJ3VB5Ektu2ym5OJYAAQIECKwsYBNl5erLnQABAgQIECBAgAABAgQI
EKgucLYZst8AOTvuKsDtnH07V8f7jgABAgQIEEgTsImS5uVoAgQIECBAgAABAgQIECBAgECIQM6m
yVHHNlKOVHxGgAABAgRiBP4V04xWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCdhEmauesiFA
gAABAgQIECBAgAABAgQIECBAgAABAgSCBGyiBEFqhgABAgQIECBAgAABAgQIECBAgAABAgQIEJhL
wCbKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYBMlCFIzBAgQIECAAAECBAgQIECAwPgC
v379Gj8JGRAgQIAAAQJhAjZRwig1RIAAAQIECBAgQIAAAQIECMwgYCNlhirKgQABAgQIxAj8jGlG
KwQIECBAgAABAgQIECBAgACBeQS+N1J+/PgxT2IyIUCAAAECBJIEbKIkcTmYAAECBAgQIECAAAEC
BAgQWE3g6jdTbLCsNhrkS4AAAQKrCdhEWa3i8iVAgAABAgQIECBAgAABAgTCBPzGShilhggQIECA
QJcCNlG6LIugCBAgQIAAAQIECBAgQIAAgdEEbKiMVjHxEiBAgACBewGbKPdGjiBAgAABAkMLXP0V
E1d/NcXQSQcGf+W3dcMwEFtTBAgQIEBgEoG79cNRmjZgjlR8RoAAAQIE3hf41/shiIAAAQIECBCo
JXD3AH/3fa24Rmh3s3ni8+SYEfIVIwECBAgQIBAj8MbawB/qiKmdVggQIECAwJGA30Q5UvEZAQIE
CBCYQODpA/zT445Ien9gL8ntKN+zz7Z+erc4i93nBAgQIECAQIxAq3VHTLRaIUCAAAECBJ4K2ER5
KuU4AgQIECBA4A8BLwv+IPEBAQIECBAgsKCANdGCRZcyAQIECCwj4K/zWqbUEiVAgAABAgQIECBA
gAABAgSiBSI2UPx7KNFV0R4BAgQIEIgTsIkSZ6klAgQIECBAgAABAgQIECBAgEBTAX+laFNunREg
QIDAggI2URYsupQJECBAgAABAgQIECBAgACBPgRsgvRRB1EQIECAAIEzAZsoZzI+J0CAAAECBAgQ
IECAAAECBAhcCJT+VV42UC5wfUWAAAECBDoRsInSSSGEQYAAAQIECBAgQIAAAQIECIwjYANlnFqJ
lAABAgQIlAjYRCnRcy4BAgQIECBA4LeAP0VqGBAgQIAAgbUESjdQ1tKSLQECBAgQGFvAJsrY9RM9
AQIECBAg8LKADZSXC6B7AgQIECDQWCBiA+Vs/ZDa9lk7jUl0R4AAAQIEphawiTJ1eSVHgAABAgQI
1BTw4qKmrrYJECBAgEB/AqmbHEcZnK0fIto+6s9nBAgQIECAQJnAz7LTnU2AAAECBAgQWEvg7MXH
WgqyJUCAAAEC6wlEbHKcrSMi2l6vIjImQIAAAQJtBGyitHHWCwECBAgQINCRwNkLjI5CFAoBAgQI
ECDQkUDEJof1R0cFFQoBAgQIEEgQsImSgOVQAgQIECAwq8D2UB/xcuDMx0uDMxmfEyBAgAABAr0L
RKyRrIV6r7L4CBAgQIDAuYB/E+XcxjcECBAgQGApgZoP99vLh4gXEEsVRLIECBAgQIDA6wIR65ea
a6zXgQRAgAABAgQWELCJskCRpUiAAAECBHoRiHgR0Usu4iBAgAABAgTmFYj6AyA1N1Bqtj1vZWVG
gAABAgTSBWyipJs5gwABAgQITCvQ4mHcRsq0w0diBAgQIEBgCoGotUrNdVXNtqcooiQIECBAgECg
gE2UQExNESBAgACBGQRaPJRHvZyYwVsOBAgQIECAQD8CUWuUmuupmm33UwmRECBAgACBfgRsovRT
C5EQIECAAIFuBLaH89oP6FEvKbpBEwgBAgQIECAwtEDU2qT2GmpoZMETIECAAIEBBWyiDFg0IRMg
QIAAgVYCtV8CRL2saOWhHwIECBAgQGBOAWuSOesqKwIECBAgECFgEyVCURsECBAgQGBigdq/leKl
xcSDR2oECBAgQGAAgci1SO0/gDIApxAJECBAgMB0AjZRpiuphAgQIECAQB2Bz2ZKjZcDkS8v6mSv
VQIECBAgQGBGgcg1SI010ozmciJAgAABAqMJ2EQZrWLiJUCAAAECHQjU+O2UyJcYHRAJgQABAgQI
EOhcIHLtYQOl82ILjwABAgQIFAjYRCnAcyoBAgQIEFhdIHozJfJlxuq1kT8BAgQIECDQRsAGShtn
vRAgQIAAgbcEbKK8Ja9fAgQIECAwkUDkZoqNlIkGhlQIECBAgECnAlHrDRsonRZYWAQIECBAIFDA
JkogpqYIECBAgMDqAlGbKVEvNlavh/wJECBAgACBPwWi1hk2UP609QkBAgQIEJhRwCbKjFWVEwEC
BAgQeFkg4qVC1AuOlyl0T4AAAQIECEwmEPWHRiZjkQ4BAgQIEJhWwCbKtKWVGAECBAgQeFcgYiPl
3Qz0ToAAAQIECMwmUPqHNKxvZhsR8iFAgAABAvcCNlHujRxBgAABAgQIZAqUvmgofdGRGbbTCBAg
QIAAgQkFStcVpeuaM9LSuM7a9TkBAgQIECAQI2ATJcZRKwQIECBAgMCJQK0XDifd+ZgAAQIECBAg
8IdA6UZFrfVMaVx/JOoDAgQIECBAIFzAJko4qQYJECBAgACBvUDJiwcvF/aafiZAgAABAgRSBErX
EiXrmKs4S+O6att3BAgQIECAQJyATZQ4Sy0RIECAAAECFwK1XkBcdOkrAgQIECBAYHGB0o0K65fF
B5D0CRAgQIDAbwGbKIYBAQIECBAg0Ewg90VE6QuQZgnqiAABAgQIEOhGwPqhm1IIhAABAgQIDC1g
E2Xo8gmeAAECBAisI+BFyDq1likBAgQIECgViFg35P7hj9LYnU+AAAECBAj0JWATpa96iIYAAQIE
CEwv4IXE9CWWIAECBAgQGF7AemX4EkqAAAECBAiECdhECaPUEAECBAgQIFBbIOJPldaOUfsECBAg
QIDAuwKl6wUbKO/WT+8ECBAgQKA3AZsovVVEPAQIECBAYAGBkpcTpS9GFuCVIgECBAgQIJApULJG
yezSaQQIECBAgEDnAjZROi+Q8AgQIECAAIE/BWyk/GniEwIECBAgQOCvv0ZaI+Rs2OScY1wQIECA
AAECZQI2Ucr8nE2AAAECBLoUGOEFgpcAXQ4dQREgQIAAgWEFStc/b6xNUvpMOXbYIgqcAAECBAh0
KPCzw5iERIAAAQIECCwisL0MyH3h8TnPC4VFBos0CRAgQIDAhUDueuLT5JvriTf7viD1FQECBAgQ
IPCPgN9EMRQIECBAgACB7I2MHuhKX5r0kIMYCBAgQIAAgXyB0rWATYx8e2cSIECAAIEVBGyirFBl
ORIgQIAAgQcCpS8gHnRxeEjEi4u3Yj9MyIcECBAgQIBAM4HSNUDEOqRZsjoiQIAAAQIEXhGwifIK
u04JECBAgACBb4GIFxilL1FUhAABAgQIEBhLwL1/rHqJlgABAgQIjCpgE2XUyombAAECBAhMJmAj
ZbKCSocAAQIECFQUiNhAiVh7VExR0wQIECBAgEAnAjZROimEMAgQIECAAIEYgYiXKjGRaIUAAQIE
CBAgQIAAAQIECBAYXcAmyugVFD8BAgQIEJhIIOpPhNpImWhQSIUAAQIECOwEIu7zUWsOxSFAgAAB
AgTmF7CJMn+NZUiAAAECCwqM/GJg5NgXHGpSJkCAAAECTQVsoDTl1hkBAgQIECDwW8AmimFAgAAB
AgQmFRh5MyIi9oiXLJMODWkRIECAAIEhBSLu7RFrjCHxBE2AAAECBAhkC9hEyaZzIgECBAgQIFBT
IOIlR8TLlpo5apsAAQIECBB4JhBxT49YWzyL1lEECBAgQIDATAI2UWaqplwIECBAgMBOYPSXBRHx
R7x0MbAIECBAgACB9wQi7uURa4r3BPRMgAABAgQIvClgE+VNfX0TIECAAIEGAk9fGjw9rkHI/9XF
FlevsbW20B8BAgQIEFhNwAbKahWXLwECBAgQ6E/AJkp/NRERAQIECBAIF7jbhLj7PjygjAZLYox4
AZMRslMIECBAgACBlwVK1g8vh657AgQIECBAoBOBn53EIQwCBAgQIECgssDqLxG2jZTVDSoPMc0T
IECAAIGuBNz3uyqHYAgQIECAwLACfhNl2NIJnAABAgQIrCdQ+jLEb6SsN2ZkTIAAAQLjCpTct0vX
DOOqiZwAAQIECBCIFrCJEi2qPQIECBAgQKCqgJciVXk1ToAAAQIEuhCwgdJFGQRBgAABAgQI/Baw
iWIYECBAgAABAsMJlGyklLyUGQ5KwAQIECBAYEAB9+oBiyZkAgQIECAwsYBNlImLKzUCBAgQIEDg
WMDLmWMXnxIgQIAAgdEFSv6gxei5i58AAQIECBCoI2ATpY6rVgkQIECAAIHKAqUvSWykVC6Q5gkQ
IECAQIZAyf25dG2QEa5TCBAgQIAAgQUEbKIsUGQpEiBAgACBWQW8LJm1svIiQIAAgRUFSjZQVvSS
MwECBAgQINBGwCZKG2e9ECBAgAABApUESjZSvKypVBTNEiBAgACBBIHtflx6Ty5ZDySE6lACBAgQ
IEBgQQGbKAsWXcoECBAgQIDAfwRKX9qwJECAAAECBPIFIu7DNlDy/Z1JgAABAgQI3AvYRLk3cgQB
AgQIECDQuYCXJ50XSHgECBAgQOBAwAbKAYqPCBAgQIAAge4EbKJ0VxIBESBAgAABAjkCJRspES9x
cmJ2DgECBAgQWFXAvXfVysubAAECBAiMJ2ATZbyaiZgAAQIECBA4EbCRcgLjYwIECBAgMKFAyX1/
Qg4pESBAgAABApUEbKJUgtUsAQIECBAgQIAAAQIECBAg8KdAxG+h2ED509UnBAgQIECAQB0Bmyh1
XLVKgAABAgQIvCRQ8lIl4qXOS2nrlgABAgQILCNQcq9fBkmiBAgQIECAQJiATZQwSg0RIECAAAEC
vQiUvFyxkdJLFcVBgAABAjMKlN5nS+7xM3rKiQABAgQIEKgvYBOlvrEeCBAgQIAAgcEESl/wDJau
cAkQIECAQBOB0vurDZQmZdIJAQIECBAgsBOwiWJIECBAgAABAlMKlL5oKX3RMyWqpAgQIECAwEsC
pff1l8LWLQECBAgQIDCBgE2UCYooBQIECBAgQOBYoPSFy7aRYjPl2NanBAgQIEAgRaDkflp6P0+J
07EECBAgQIAAgb2ATZS9iJ8JECBAgAABAjuBkhc/MAkQIECAwOoCJfdRGyirjx75EyBAgACB9wVs
orxfAxEQIECAAAECFQWiXr6UvACqmJ6mCRAgQIBA1wLun12XR3AECBAgQIDAAwGbKA+QHEKAAAEC
BAiMLWAjZez6iZ4AAQIExhOI+Csxo+7f4+mJmAABAgQIEOhJwCZKT9UQCwECBAgQINC9gD9R232J
BEiAAAECLwtE3CttoLxcRN0TIECAAAEC/xawiWIwECBAuEBFkQAAIABJREFUgAABAksIRL6MiXg5
tAS6JAkQIEBgOQH3yOVKLmECBAgQIDC9gE2U6UssQQIECBAgQOAjELmRQpUAAQIECBD4b4GoDRT3
ayOLAAECBAgQ6EnAJkpP1RALAQIECBAgUF0g6sVM1Iui6gnrgAABAgQIDCQQdZ8eKGWhEiBAgAAB
Ap0L2ETpvEDCI0CAAAECBOIFol7Q2EiJr40WCRAgQGBMgYh7YtT9eUxBURMgQIAAAQK9CthE6bUy
4iJAgAABAgSqCmwvaiJe1kS8NKqaqMYJECBAgEBlgYh7YcQ9uXKamidAgAABAgQWFfjxe6Hya9Hc
pU2AAAECBAgQ+F+BiJc/WzuWVQYUAQIECKwk4P65UrXlSoAAAQIE1hXwmyjr1l7mBAgQIECAwD8C
fivFUCBAgAABAmkCNlDSvBxNgAABAgQIjCtgE2Xc2omcAAECBAgQ6FAg6qVSh6kJiQABAgQI/K9A
1L3Ob3AaUAQIECBAgMAIAjZRRqiSGAkQIECAAIEmAlEvc6JeLjVJWicECBAgQCBBIOoeF3XPTQjd
oQQIECBAgACBLAGbKFlsTiJAgAABAgRmFYh6qRP1kmlWZ3kRIECAwHgCUfe2qHvteIIiJkCAAAEC
BEYUsIkyYtXETIAAAQIECFQViHq5E/WyqWqyGidAgAABAg8E3NMeIDmEAAECBAgQmFLAJsqUZZUU
AQIECBAg0IuAl069VEIcBAgQIJArEHkvi/qDCrm5OI8AAQIECBAgkCpgEyVVzPEECBAgQIDAEgKR
L3kiXz4tgS9JAgQIEOhGIPIeFnlv7QZIIAQIECBAgMD0AjZRpi+xBAkQIECAAIFcAS97cuWcR4AA
AQIzCNhAmaGKciBAgAABAgRKBWyilAo6nwABAgQIEJhawEbK1OWVHAECBAicCERtoGz3UffSE2Qf
EyBAgAABAkMI2EQZokyCJECAAAECBN4UiHgBFPUy6k0HfRMgQIDAGgJR9yybJ2uMF1kSIECAAIHZ
BWyizF5h+REgQIAAAQJhAl4GhVFqiAABAgQ6FYjYQIn4wwed8giLAAECBAgQWFDAJsqCRZcyAQIE
CBAgkC9QspES8WIqP3JnEiBAgACBa4GI+1TJffI6Ot8SIECAAAECBN4RsInyjrteCRAgQIAAgYEF
Sl4QRbygGphO6AQIECDQqYD7U6eFERYBAgQIECDwuoBNlNdLIAACBAgQIEBgRIGSjZQR8xUzAQIE
CMwrELWB4t447xiRGQECBAgQWFng58rJy50AAQIECBAgQIAAAQIECKwqELV5svnZQFl1FMmbAAEC
BAjML+A3UeavsQwJECBAgACBSgJeGFWC1SwBAgQIVBewgVKdWAcECBAgQIDAJAI2USYppDQIECBA
gACBcQQiX1yNk7VICRAgQKAXgaj70PaHCfyBgl6qKg4CBAgQIECgloBNlFqy2iVAgAABAgSWEMh9
eRT1AmsJZEkSIECAQJhA1P0n9/4XloiGCBAgQIAAAQKNBGyiNILWDQECBAgQIDCvgBdJ89ZWZgQI
ECDwp4D73p8mPiFAgAABAgTmFbCJMm9tZUaAAAECBAh0LhD1p4E7T1N4BAgQIDCRgA2UiYopFQIE
CBAgQOCRgE2UR0wOIkCAAAECBAgQIECAAAECYwuUbt7bQBm7/qInQIAAAQIE8gRsouS5OYsAAQIE
CBAgECJQ+kIrJAiNECBAgMD0AqX3Gxso0w8RCRIgQIAAAQInAjZRTmB8TIAAAQIECBBIEfByKUXL
sQQIECDQUsAGSkttfREgQIAAAQKzCdhEma2i8iFAgAABAgReE8jdSCl9ufVawjomQIAAge4FSu8x
ufe27mEESIAAAQIECBB4KGAT5SGUwwgQIECAAAECNQVKX3LVjE3bBAgQIDCmQOm9xQbKmHUXNQEC
BAgQIBArYBMl1lNrBAgQIECAwOICJS+cSl92LU4vfQIECBD4EnBPMRwIECBAgAABAjECNlFiHLVC
gAABAgQIEAgR8NIrhFEjBAgQWFog4l5S8ocClsaXPAECBAgQIDCdgE2U6UoqIQIECBAgQOBtgdIX
TxEvv9420D8BAgQIjCtQeh8bN3OREyBAgAABAgT+FLCJ8qeJTwgQIECAAAECBAgQIECAwJICNlCW
LLukCRAgQIAAgQuBH78XSL8uvvcVAQIECBAgQIBApkDUb5RYrmUWwGkECBBYUKDk3uN+s+CAkTIB
AgQIECBwK+A3UW6JHECAAAECBAgQyBOIehlV8kIsL3JnESBAgMBqAlH3rNXc5EuAAAECBAjML2AT
Zf4ay5AAAQIECBCYQGDbSLGZMkEhpUCAAIEOBWygdFgUIREgQIAAAQLdCNhE6aYUAiFAgAABAgRm
FIh+MWUzZcZRIicCBAjECORstkffp2Iy0QoBAgQIECBAoB8Bmyj91EIkBAgQIECAwKQCNV5Q5bwo
m5RXWgQIECBAgAABAgQIECBAoJrAz2ota5gAAQIECBAgQODfAttGSvTGx769Gps1SkiAAAECBAgQ
IECAAAECBFYW8JsoK1df7gQIECBAgEBTgdqbHPtNlabJ6YwAAQIEhhOofV8aDkTABAgQIECAAIED
AZsoByg+IkCAAAECBAjUEqj9wsq/mVKrctolQIAAAQIECBAgQIAAgRUFbKKsWHU5EyBAgAABAq8K
1N5I2ZLzWymvlljnBAgQaC5g3m9OrkMCBAgQIEBgEQGbKIsUWpoECBAgQIBAXwKtNlK8VOur7qIh
QIBADYGcub7FfahGrtokQIAAAQIECLQWsInSWlx/BAgQIECAAIF/BFq9wPJXfBlyBAgQmFcgZwNl
Xg2ZESBAgAABAgTiBX7GN6lFAgQIECBAgACBpwLfGym1X4R92m+1efPUwHEECBAgQIAAAQIECBAg
QKBXAb+J0mtlxEWAAAECBAgsJ9Bqc+Pzmym1N22WK6CECRAg0FjAPN4YXHcECBAgQIDAkgI2UZYs
u6QJECBAgACBXgW2jZRWmymbgb/qq9eRIC4CBAhcC9hAufbxLQECBAgQIEAgSsAmSpSkdggQIECA
AAECgQJvbKYEhq8pAgQIEOhYoOVmfccMQiNAgAABAgQIPBKwifKIyUEECBAgQIAAgXcEWr7o8qea
36mxXgkQIJAqUDJft7yvpObleAIECBAgQIBAjwL+YfkeqyImAgQIECBAgMCXwP6FV8nLszvYre19
f3fn+J4AAQIExhAwv49RJ1ESIECAAAECfQn4TZS+6iEaAgQIECBAgMCtQO2XYDU3aW6TcwABAgQI
XAqYoy95fEmAAAECBAgQCBewiRJOqkECBAgQIECAQH2B1v9mSv2M9ECAAAECdwIlGyi1N+DvYvc9
AQIECBAgQGBUAZsoo1ZO3AQIECBAgACB3wK1XoqVvKhTGAIECBCIFyiZl2vdK+Kz1CIBAgQIECBA
oD8Bmyj91UREBAgQIECAAIEkgVq/lVLywi4pAQcTIECAAAECBAgQIECAAIFOBWyidFoYYREgQIAA
AQIEUgVqbKbYSEmtguMJECDQl4DfQumrHqIhQIAAAQIExhOwiTJezURMgAABAgQIELgUiN5MsZFy
ye1LAgQIECBAgAABAgQIEJhY4OfEuUmNAAECBAgQILC0wPefPrYRsvRQkDwBAoML5M7hfgtl8MIL
nwABAgQIEOhCwG+idFEGQRAgQIAAAQIE6gqUvkjbXuDlvsSrm5nWCRAgMLdA7txbOu/PrSo7AgQI
ECBAgMBzAZsoz60cSYAAAQIECBAYWiDihVruy7yh4QRPgACBwQQi5vvBUhYuAQIECBAgQKCagE2U
arQaJkCAAAECBAj0JxDxYu3zWyk2VPqrr4gIEJhLwDw7Vz1lQ4AAAQIECIwpYBNlzLqJmgABAgQI
ECCQLRCxkfLp3Au+7DI4kQABApcC5tdLHl8SIECAAAECBJoJ2ERpRq0jAgQIECBAgEA/AjZS+qmF
SAgQIECAAAECBAgQIECgXwGbKP3WRmQECBAgQIAAgWEEPn/F1zABC5QAAQIdC5T8FkrkJnnHREIj
QIAAAQIECDQTsInSjFpHBAgQIECAAIG+BGq8aCt58deXjmgIECDwjkDJPFpjXn9HQa8ECBAgQIAA
gX4EfvYTikgIECBAgAABAgRaC2wv3Epe2B3Fu7XnRd6RjM8IEOhR4GoObD2XXcXSo52YCBAgQIAA
AQIrCPhNlBWqLEcCBAgQIECAwIVAjZeEXgRegPuKAIFuBO7mqrvvIxMp7avGXB6Zn7YIECBAgAAB
AqMK2EQZtXLiJkCAAAECBAgECtR4+Vb6QjAwPU0RIEDgD4Gnc9TT4/7oIOGD0j5qzOEJ4TuUAAEC
BAgQIDC1gE2UqcsrOQIECBAgQIDAc4EaL+FKXww+j96RBAgQGFPAPDlm3URNgAABAgQIrCPw4/fD
8q910pUpAQIECBAgQIDAE4EaL/Wil51XMUb39cTMMQQIjCVwNYccZVJjXkmNoVVcR/34jAABAgQI
ECCwqoDfRFm18vImQIAAAQIECFwI1HpZuL0wjHhpeNfG3fcXqfuKAAECTQQi5qkac3WT5HVCgAAB
AgQIEBhIwG+iDFQsoRIgQIAAAQIE3hKIeNm3jz335V9qLLn97OP1MwECcwmkziVb9hHzSU6/R/IR
sRy16zMCBAgQIECAAIH/FvCbKEYEAQIECBAgQIDArUCNl3VRLxLvgm/Vz10cvidAgEDUfFRjTlYd
AgQIECBAgACBYwGbKMcuPiVAgAABAgQIENgJ1HhpF/VC8a5Yrfq5i8P3BAisKxA1D9WYi9etiswJ
ECBAgAABAvcCNlHujRxBgAABAgQIECDwj8D28i76BV7Ui8W7Im39fP67O9b3BAgQiBSImuei59/I
HLVFgAABAgQIEJhVwCbKrJWVFwECBAgQIECgokD0i7yoF4xPU27d39O4HEeAwHwCUfNN9Lw7n7SM
CBAgQIAAAQJ1BH7WaVarBAgQIECAAAECswtsL/SiXg6+YbXF7qXkG/JlfUaMOXUvq8EsZ480hxmz
s4w6eRAgQIAAAQIjCthEGbFqYiZAgAABAgQIdCIQ+RLyjU2NN/rspHRDhRGxcfKd8FF7XlIPNSSG
CfZorKUGb2ymijmeAAECBAgQIBArYBMl1lNrBAgQIECAAIHlBEbfSFmuYAMkHPHiOTXN7z69tE7V
G/f4yPlrrxAxjo3FvaqfCRAgQIAAAQLtBfybKO3N9UiAAAECBAgQmE4g8kXf3YvHyL62Qtz1N12x
Ok1oq8Pnv7dD7CWOtx30ny8QMa9Ez3X52TiTAAECBAgQILC2gN9EWbv+sidAgAABAgQIhAl8XvhF
vDy8Cyr6T49vMXtheace/32LsVIS9Xd8xkeJ5FrnRoxr422tMSNbAgQIECBAoG+BH78XZ7/6DlF0
BAgQIECAAAECowqUvEx8skwtaf/I9EmfR+f57FwgukbnPbX9xlhp612zt5Qxelf3lLbOcrrr4+w8
nxMgQIAAAQIECNQR8JsodVy1SoAAAQIECBAgUCjweRl59ULx+7uIl5dbG1f9Faa0zOkRtegdy1jp
vULt44sY9+af9nXTIwECBAgQIEDgTsC/iXIn5HsCBAgQIECAAIFsgYgXgk9fTEb0tSX6tL9slElP
3Nw+/02a4h9prZbvHwA++LdAxLwRNYcpCwECBAgQIECAQKyATZRYT60RIECAAAECBAjsBCJeDD59
QRnR1xb+0/7+f3v3th23rQMAtM7K//+yT9R0TpzxjG4ESZDcD33wSCKBDTorBSJbsX8LrO5lmLL2
d0LE+Y/6s2vtSsieAAECBAgQIFBHwBCljqtVCRAgQIAAAQIEvghENAjPNiq3vVrut3KhDQ/+rv7Z
M7rymZkt94iaR/x5NZurfAgQIECAAAECmQQMUTJVQywECBAgQIAAAQK7Ao+m/ZnGZURj8sw+uwFP
fJHN6+Jyee0y46cRtY74c2pGWzkRIECAAAECBDIJfPz6S9tnpoDEQoAAAQIECBAgMK9ARNPxWefo
r7MRex7t8RzTzF9HeNbweVWjnrG+iqdG3tYsF7hyTh51vfLMuwidkXcyPidAgAABAgQI5BIwRMlV
D9EQIECAAAECBKYXiGg+PiMdNSNL9zxa/zmeGb8uNaxhcqcuLfO4E18NJ2vuC1w5E1tNr9z/bmdn
452MzwkQIECAAAEC+QQMUfLVREQECBAgQIAAgekFIpqQz0hHTcnSPY/Wf45npq9L7aIsomvQIq/o
mKMsrfNHoMU5+OrtTDh9BAgQIECAAIGxBAxRxqqXaAkQIECAAAEC0wjUaFweNScj9jzaY5oC/ZdI
hFmJSQvv3jl+9WmRb0k9Zny2Zf3Vd8YTJCcCBAgQIEBgdgFDlNkrLD8CBAgQIECAQGKB6OblmQZl
xJ5n9knMfjq0CKvTm325sadvr5xHc7oTb9ZnWtW857nOai8uAgQIECBAgMAIAoYoI1RJjAQIECBA
gACBiQVqNDCPmpURex7tMXrJIoz2DDL71c59z6XkWmbTkrxqP9uq3upTu5LWJ0CAAAECBAjUEfhR
Z1mrEiBAgAABAgQIEDgnUKOxeNQUjdjzaI9z2ee8q1Zum/vjv5yZjx1VrbqNrZIj+og/c3JkIgoC
BAgQIECAwHoChijr1VzGBAgQIECAAIF0AjUajBrK98oc7WZwcq8Od5/a6hddw7uxeO63QI0/39gS
IECAAAECBAi0EzBEaWdtJwIECBAgQIAAgR2B1m8oRDQ2Z2tWR+cTYbxzZFzaEXgMU6JrurOlSy8E
fA+8QPERAQIECBAgQGAwgZ+DxStcAgQIECBAgACByQW2pmOrxm/EXlusMzRKI81n8Jjp22yWMzpa
TbJ9Hxx9j2eLd7R6i5cAAQIECBCYV8CbKPPWVmYECBAgQIAAgWEFtmZeq4ZexD5HzcnshYiMP8Iz
u9eI8UXWeMT8V4x5q/nX/44MnJEjIdcJECBAgACBVQUMUVatvLwJECBAgAABAgMItBqmRDT+R21A
RsXdqlYDHFshDiQQdf6fU474M+V5zbNfPwYnZ+//el8tjzuxeIYAAQIECBAgkEXAECVLJcRBgAAB
AgQIECDwVqBFQzJij9EakBHxzjg8iTgLbw9zxwsR9e4Y/jBb9zo/JcOTYXAFSoAAAQIECBDoIGCI
0gHdlgQIECBAgAABAjkFIpqfozSqI+KM8Mp5Ev5p9uPksua/QlwR3wMZnAxPMlRBDAQIECBAgMDM
An6x/MzVlRsBAgQIECBAYCKBrWF/pel5t8F/dZ+JiC+lctf30iadb66Z45WzHMmw7Vszr8hYa67V
y/9uTqPFezdPzxEgQIAAAQIEMgp8/PoL9GfGwMREgAABAgQIECBA4JXAmWZixF9xz+zzKr7HZxEx
7K1fcm3m3Epcsj5bWq9XeWU+n6/ijfyshufX+CJsa8e45xkR/976rhEgQIAAAQIERhMwRBmtYuIl
QIAAAQIECBBoJlDayMzYjJwxp2YHIslGpTV8pJHxfNYmjrLbi3PPtcX+e7GdubYX/5nn3UOAAAEC
BAgQmE3Aj/OaraLyIUCAAAECBAgQCBPYmokjND3PJlyai+bqWem690Wdy8d5UNe4en21LP1+i4vK
SgQIECBAgAABAiUC3kQp0fMsAQIECBAgQIDAbYG9BmO2pu5erHsAmfK4m8Mjv0y57Jmvdq20rqvV
N8pr1nPm+3zWysqLAAECBAgQKBH4UfKwZwkQIECAAAECBAjcEThqZB5dv7NnyTN3G4tZ8iiN427+
JeaePScQVZvtjJSek3MR97tr9vxKZaPOUmkcnidAgAABAgQIZBMwRMlWEfEQIECAAAECBCYXONvI
PHtfdq5Z8sjuLL4YgccwxbmN8RxhlW14YoAyQqXESIAAAQIECPQS8DtResnblwABAgQIECBA4FBg
a+S2bO5pHH8vSUv/77v75IzAVqMaZ7f199+ZXN1TLuB7utzQCgQIECBAgMBaAoYoa9VbtgQIECBA
gACB4QSuNnJrNJOHQ/sScImHZus4la85SNkUnIVxzsK7SNXwnYzPCRAgQIAAAQL7An6x/L6PqwQI
ECBAgAABAsECJU3951C+NgUj133eJ+LrHg3MEpMe8UY4r75GSc2P7EY/EzVtjux6Xh+9bj3t7E2A
AAECBAgQ2AS8ieIcECBAgAABAgQIDCuwalP0TMFKbDRdzwjnvGerXUnt97J6ta6zsifW95ra9PW3
OwECBAgQIDCPgCHKPLWUCQECBAgQIECAAIF/BV41u8/SaLyelcp7X81BynPWz2fN+XkWqvs177q+
VidAgAABAgQIbAKGKM4BAQIECBAgQIAAgYkEnpvaE6UmlQsCLQcpX8Pazp/G/oVCXbyV7UUwtxMg
QIAAAQIEAgQMUQIQLUGAAAECBAgQIEAgg4ABSoYq5Imh5yBlU9DwP38WWJ23cicBAgQIECBAoLWA
IUprcfsRIECAAAECBBYX6NXYXZxd+osKfG3Otx6yeSvl9aEzMHnt4lMCBAgQIECAQFYBQ5SslREX
AQIECBAgQGBiAYOU+OJGNMg1d+PrkmnFHt93sw9SfM9kOuFiIUCAAAECBAjUEfhRZ1mrEiBAgAAB
AgQIENgXWKn5OEKuI8S4f6JcPSOw1bl1rSMGfGdyO7onMu8ejkf5uU6AAAECBAgQIFBH4OPXX/4+
6yxtVQIECBAgQIAAAQLHAlkarMeR3rujxV+3Sw1bxHhPz1MtBErPz9kYs5yzknyz5HDW3H0ECBAg
QIAAAQLlAoYo5YZWIECAAAECBAgQKBQoaWoWbn3q8eyN0xK/7LmdKpCbigVKztCVzZ23K1ruJUCA
AAECBAgQyCBgiJKhCmIgQIAAAQIECBD4p3YTd9bm7V23WT18K5UJ3D1PV3Z19q5ouZcAAQIECBAg
QKC3gF8s37sC9idAgAABAgQIEPhXYK+xWtLY3VsXPQECfwts3y8l329nPLf1fV+ekXIPAQIECBAg
QIBABgFDlAxVEAMBAgQIECBAgMCugIbrLs/lizwvky31wKvzUXuwshSwZAkQIECAAAECBIYSMEQZ
qlyCJUCAAAECBAgQIPBHQGPbaWgl8DxYKT173kZpVTn7ECBAgAABAgQIlAr8KF3A8wQIECBAgAAB
AgQIjCPw3AwfJ3KRZhKIOEelg5hMHmIhQIAAAQIECBCYV8AQZd7ayowAAQIECBAgQGBiAQ3oiYs7
SGrbIKV0mOIcD1JsYRIgQIAAAQIEFhYwRFm4+FInQIAAAQIECBBYS6C04b2WlmzPCpSeK4OUs9Lu
I0CAAAECBAgQ6CFgiNJD3Z4ECBAgQIAAAQIECBCYSMAgZaJiSoUAAQIECBAgQOAvAUMUB4IAAQIE
CBAgQIAAAQIEugt4I6V7CQRAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAjMJlD6psBsHvKJF3DG
4k2tSIAAAQIECBAg0F/AEKV/DURAgAABAgQIECBAgACBKQRKByneRpniGEiCAAECBAgQIDCVgCHK
VOWUDAECBAgQIECAAIHvAqWN7e8r+oTAe4HS87YNUgxT3vu6QoAAAQIECBAg0FbAEKWtt90IECBA
gAABAgQIFAtoMBcTWqCyQOkgZQvPOa9cJMsTIECAAAECBAicEjBEOcXkJgIECBAgQIAAAQI5BDSW
c9RBFMcCBinHRu4gQIAAAQIECBDIL2CIkr9GIiRAgAABAgQIECDwr4ABioMwmoBBymgVEy8BAgQI
ECBAgMCzgCHKs4ivCRAgQIAAAQIECBAgQCCVgAFiqnIIhgABAgQIECCwlIAhylLlliwBAgQIECBA
gAABAgTaCkS8jbJFbJDStm52I0CAAAECBAgQ+C1giOIkECBAgAABAgQIECBAgEBVgahBStUgLU6A
AAECBAgQIEDghYAhygsUHxEgQIAAAQIECBDIJnD3X+FrXmer5LrxOIvr1l7mBAgQIECAAIGRBQxR
Rq6e2AkQIECAAAECBAjsCGha7+C41EWg9EzeHSZ2SdamBAgQIECAAAECUwgYokxRRkkQIECAAAEC
BAjMLHCncVzarJ7ZU259BZzNvv52J0CAAAECBAgQuCZgiHLNy90ECBAgQIAAAQIECBAgUChQMki5
M1QsDNfjBAgQIECAAAECCwsYoixcfKkTIECAAAECBAgQIECgl8A2SCkZpvSK274ECBAgQIAAAQJr
CRiirFVv2RIgQIAAAQIECBAgQIAAAQIECBAgQIAAAQInBQxRTkK5jQABAgQIECBAgMAoAv51/yiV
EicBAgQIECBAgAABAtkFDFGyV0h8BAgQIECAAAECBAgQmFjA0G/i4kqNAAECBAgQIDCBgCHKBEWU
AgECBAgQIECAAIGHgIa0s0CAAAECBAgQIECAAIE4AUOUOEsrESBAgAABAgQIECBAgMANAcO/G2ge
IUCAAAECBAgQaCJgiNKE2SYECBAgQIAAAQIECBAgECXw8fERtZR1CBAgQIAAAQIECOwKGKLs8rhI
gAABAgQIECBAoK+AZnFff7sTIECAAAECBAgQILC2gCHK2vWXPQECBAgQIECAAAECBAgQIECAAAEC
BAgQIPBGwBDlDYyPCRAgQIAAAQIECBAgQIAAAQIECBAgQIAAgbUFDFHWrr/sCRAgQIAAAQIECBAg
QIAAAQIECBAgQIAAgTcChihvYHxMgAABAgQIECBAgAABAnkF/L6gvLURGQECBAgQIEBgJgFDlJmq
KRcCBAgQIECAAAECBAgMKvD5+Xk5coOUy2QeIECAAAECBAgQuChgiHIRzO0ECBAgQIAAAQIEsgrc
aUJnzUVcBM4KGKSclXIfAQIECBAgQIDAHQFDlDtqniFAgAABAgQIECBAgAABAgQIECBAgAABAgSm
FzBEmb7EEiRAgAABAgQIEBhVwL+wH7Vy4m4t4Ht9CHEEAAAgAElEQVSltbj9CBAgQIAAAQLrCPxc
J1WZEiBAgAABAgQIEBhHQFN4nFrVjPToHPgRbn/0NyseNU+jtQkQIECAAAECawp4E2XNusuaAAEC
BAgQIECAAIHkAkcDlC38M/ckT/Ov8EqHILN5jFQ7sRIgQIAAAQIEZhUwRJm1svIiQIAAAQIECBAY
VkAjeNjShQV+5QxcuTcswIoLGaRUxLU0AQIECBAgQIDAZQE/zusymQcIECBAgAABAgQI1BOYrSFe
T+r9ymcNS5v17yNwpVRgq83ZOpbu5XkCBAgQIECAAAECewLeRNnTcY0AAQIECBAgQIAAgaEErjTe
r9w7FIJgDWCcAQIECBAgQIAAgTABQ5QwSgsRIECAAAECBAgQ6CfgrYp7vx/EIKXfmbUzAQIECBAg
QIAAgREEDFFGqJIYCRAgQIAAAQIElhC429A3QFnieCyXZOm5vvv9tBy0hAkQIECAAAECBHYFDFF2
eVwkQIAAAQIECBAgQIAAgV4CBim95O1LgAABAgQIECDwEDBEcRYIECBAgAABAgQIDCxQ2mQeOHWh
LyLgjC9SaGkSIECAAAECBJIKGKIkLYywCBAgQIAAAQIECBwJaC4fCY17/Uptr9w7qkhJjn6s16hV
FzcBAgQIECBAIIeAIUqOOoiCAAECBAgQIECAAAECfwmcGRycuWcW1pVynaVm8iBAgAABAgQIzCDw
c4Yk5ECAAAECBAgQIEBgdAH/Wn70CtaJ3+AgxnX7/mIZY2kVAgQIECBAgMBqAt5EWa3i8iVAgAAB
AgQIEJhCQEM4powcYxxbraJeraTtQ4AAAQIECBAg8BAwRHEWCBAgQIAAAQIECBCYQuBqg/3q/VMg
TZCEuk1QRCkQIECAAAECBAYS8OO8BiqWUAkQIECAAAECBAgQ2BfYGux7PxpNA37fz1UCBAgQIECA
AAECBP4WMERxIggQIECAAAECBAgQmErAoGSqcr5M5mhY9uohvxfllYrPCBAgQIAAAQIEjgT8OK8j
IdcJECBAgAABAgQIVBbYe3Oi8taWJ0CAAAECBAgQIECAAIEdAUOUHRyXCBAgQIAAAQIECGQU8KZF
xqqIqbWA74PW4vYjQIAAAQIECKwpYIiyZt1lTYAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwIGKIc
ALlMgAABAgQIECBAgAABAgQIECBAgAABAgQIrClgiLJm3WVNgAABAgQIECBAgAABAgQIECBAgAAB
AgQIHAgYohwAuUyAAAECBAgQIECgpsDVXyrv90DUrIa1RxPw/TBaxcRLgAABAgQIEBhPwBBlvJqJ
mAABAgQIECBAYBKBqwOUSdKWBgECBAgQIECAAAECBIYRMEQZplQCJUCAAAECBAgQIECAAAECBAgQ
IECAAAECBFoKGKK01LYXAQIECBAgQIAAgf8EvIXiKBAgQIAAAQIECBAgQCC/gCFK/hqJkAABAgQI
ECBAYDIBA5TJCiodAgQIECBAgAABAgSmFTBEmba0EiNAgAABAgQIECBAgMDcAgaSc9dXdgQIECBA
gACBDAKGKBmqIAYCBAgQIECAAAECJwQ+Pz9P3OUWAgQIECBAgAABAgQIEIgSMESJkrQOAQIECBAg
QIAAgYoCBigVcS1NgAABAgQIECBAgACBNwKGKG9gfEyAAAECBAgQIECAAAECBAgQIECAAAECBAis
LWCIsnb9ZU+AAAECBAgQIDCAgLdQBiiSEAkQIECAAAECBAgQmFLAEGXKskqKAAECBAgQIEBgFgED
lFkqKQ8CBAgQIECAAAECBEYUMEQZsWpiJkCAAAECBAgQIECAAIFLAgaSl7jcTIAAAQIECBAg8J+A
IYqjQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBB4IWCI8gLFRwQIECBAgAABAgQIECBAgAABAgQI
ECBAgAABQxRngAABAgQIECBAgAABAgQIECBAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAgQIECA
AAECBAgQIECAAAEChijOAAECBAgQIECAAAECBAgMJ/Dx8TFczAImQIAAAQIECBAYT8AQZbyaiZgA
AQIECBAgQIAAAQIECBAgQIAAAQIECBBoIGCI0gDZFgQIECBAgAABAgQIECBAgAABAgQIECBAgMB4
AoYo49VMxAQIECBAgAABAgQIECBAgAABAgQIECBAgEADAUOUBsi2IECAAAECBAgQIECAAAECBAgQ
IECAAAECBMYTMEQZr2YiJkCAAAECBAgQIECAAAECBAgQIECAAAECBBoIGKI0QLYFAQIECBAgQIAA
AQIECPQT+Pz87Le5nQkQIECAAAECBIYWMEQZunyCJ0CAAAECBAgQIECAAAECBAgQIECAAAECBGoJ
GKLUkrUuAQIECBAgQIAAAQIECBAgQIAAAQIECBAgMLSAIcrQ5RM8AQIECBAgQIAAAQIECBAgQIAA
AQIECBAgUEvAEKWWrHUJECBAgAABAgQIECBAgAABAgQIECBAgACBoQUMUYYun+AJECBAgAABAgQI
ECBAgAABAgQIECBAgACBWgI/ay1sXQIECBAgQIAAAQIECBBoI/Dx8fF2o8/Pz7fXXCBAgAABAgQI
ECBAYF/Amyj7Pq4SIECAAAECBAgQIEAgtcDeAGUL/Oh66uQER4AAAQIECBAgQKCzgCFK5wLYngAB
AgQIECBAgMCegAb4no5rZ8/H2fuIEiBAgAABAgQIECDwt4Af5+VEECBAgAABAgQIECCwlMDeQGGk
H321l8dSBZUsAQIECBAgQIAAgYoC3kSpiGtpAgQIECBAgAABAgRyCRwNHo6uZ8lmlDizeImDAAEC
BAgQIECAwF0BQ5S7cp4jQIAAAQIECBAgQGAogbODh+2+s/f2AMgcWw8PexIgQIAAAQIECBCoKWCI
UlPX2gQIECBAgAABAgQIDCuQcViRMaZhCyxwAgQIECBAgAABAicEDFFOILmFAAECBAgQIECAAIE1
BTINLTLFsuZpkDUBAgQIECBAgMCKAoYoK1ZdzgQIECBAgAABAl0FRvrl5V2hkmyeYXiRIYYk5RAG
AQIECBAgQIAAgaYChihNuW1GgAABAgQIECBA4LqABvp1s+gnthr0qEPUvgZ30SfCegQIECBAgAAB
AqsIGKKsUml5EiBAgAABAgQIECBQLNBykBK1lwFKcdktQIAAAQIECBAgsLCAIcrCxZc6AQIECBAg
QIAAAQLXBaKGG3s7R+1hgLKn7BoBAgQIECBAgACBYwFDlGMjdxAgQIAAAQIECBAgQOAvgaghxzNr
1I/vel7X1wQIECBAgAABAgQI3BMwRLnn5ikCBAgQIECAAAECBAYTiH4rI3rgET2Yic53sHILlwAB
AgQIECBAgECIgCFKCKNFCBAgQIAAAQIECBAYQaDGYCFimGKAMsLpESMBAgQIECBAgMCKAoYoK1Zd
zgQIECBAgAABAt0FajTzuyc1SAC17O8OUwxQBjk4wiRAgAABAgQIEFhS4OeSWUuaAAECBAgQIECA
wGACW6O9VvN/MIqQcL9aRg8xntdrWbeWe4UUwiIECBAgQIAAAQIEkgsYoiQvkPAIECBAgAABAgQI
EKgrsA0engcfkTvWXPsRp+FJZMWsRYAAAQIECBAgQOCPgB/n5TQQIECAAAECBAgQILC8wMhDiJFj
X/7gASBAgAABAgQIEEgvYIiSvkQCJECAAAECBAgQIPBboMUbDStbjziMGDHmlc+Y3AkQIECAAAEC
BMYTMEQZr2YiJkCAAAECBAgQIECgksAoQ4ktzlFirVQqyxIgQIAAAQIECBBoImCI0oTZJgQIECBA
gAABAgS+C9xpgnsb5btj9Cd36hIdw9562ePbi901AgQIECBAgAABAqMJGKKMVjHxEiBAgAABAgQI
LC9gkFL/CGQdVGSNq35F7ECAAAECBAgQIECgj4AhSh93uxIgQIAAAQIECBAgkFzAj8xKXiDhESBA
gAABAgQIEGggYIjSANkWBAgQIECAAAECBKIFvI0SLfp+vSzDFG+hvK+RKwQIECBAgAABAgRqCRii
1JK1LgECBAgQIECAAIETAhrjJ5CS3NJzmOKcJDkEwiBAgAABAgQIEFhOwBBluZJLmAABAgQIECBA
gACBEoHWwxQDlJJqeZYAAQIECBAgQIBAmYAhSpmfpwkQIECAAAECBAgUC9xtkvuRXsX0RQs8hik1
hyp3z0ZRYh4mQIAAAQIECBAgQOD/Aj9ZECBAgAABAgQIECDQX2BrlhuK9K9DSQQGHiV6niVAgAAB
AgQIECCQU8CbKDnrIioCBAgQIECAAAECBAgQIECAAAECBAgQIECgs4AhSucC2J4AAQIECBAgQIDA
Q8CbDM4CgXMC3to65+QuAgQIECBAgACBcgFDlHJDKxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIT
ChiiTFhUKREgQIAAAQIECBAgQGBWAW+hzFpZeREgQIAAAQIEcgoYouSsi6gIECBAgAABAgQWFbj6
I700lBc9KNImQIAAAQIECBAgQKCJgCFKE2abECBAgAABAgQIEKgnYJBSz9bKBAgQIECAAAECBAis
LWCIsnb9ZU+AAAECBAgQIDCJgEHKJIWUxq6Ac77L4yIBAgQIECBAgEAFAUOUCqiWJECAAAECBAgQ
IECAAIEcAld/RF6OqEVBgAABAgQIECCQRcAQJUslxEGAAAECBAgQIECgUMC/0i8E9DgBAgQIECBA
gAABAgSeBAxRHAkCBAgQIECAAAECBAgQSC9wZ0joLZT0ZRUgAQIECBAgQCC9gCFK+hIJkAABAgQI
ECBAYDUBjd/VKi7fI4E7A5SjNV0nQIAAAQIECBAgcEbAEOWMknsIECBAgAABAgQINBYwSGkMbru0
AgYoaUsjMAIECBAgQIDAEgKGKEuUWZIECBAgQIAAAQIjCtwZpGg4j1hpMb8TKDnPd75/3sXhcwIE
CBAgQIAAgXUFDFHWrb3MCRAgQIAAAQIEJhUoaTxPSiItAgQIECBAgAABAgQI3BIwRLnF5iECBAgQ
IECAAAECbQT8a/o2znYhQIAAAQIECBAgQIDAK4Gfrz70GQECBAgQIECAAAECYws83kYxhBm7jqtG
X/o2lXO/6smRNwECBAgQIEAgXsCbKPGmViRAgAABAgQIECCQRqC0GZ0mEYEsI1B6Zg1QljkqEiVA
gAABAgQINBEwRGnCbBMCBAgQIECAAAEC/QRKm9L9IrfzagKlZ9UAZbUTI18CBAgQIECAQH0BQ5T6
xnYgQIAAAQIECBAgUCQQ0RjemtOlDeqiJDxM4ECg9HxGfJ8chOgyAQIECBAgQIDAggKGKAsWXcoE
CBAgQIAAAQLjCUQ1iEsb1ePJiTi7gAFf9gqJjwABAgQIECCwtoAhytr1lz0BAgQIECBAgMCCAgYp
CxY9acrOYtLCCIsAAQIECBAgQOD/AoYoDgMBAgQIECBAgACBQQSi3kbZ0tW8HqToE4cZeQYjvzcm
JpcaAQIECBAgQIDADQFDlBtoHiFAgAABAgQIECDQSyCyWRzZxO7lYd8xBSLPXuT3xJiaoiZAgAAB
AgQIEKgpYIhSU9faBAgQIECAAAECBCoIRDaNI5vZFVK15GQC0b//JPJ7YTJq6RAgQIAAAQIECAQJ
fPz6S+dn0FqWIUCAAAECBAgQIECgoUD0AMT/GjQs3mJbRZ/Vjc95XewQSZcAAQIECBAg0EnAEKUT
vG0JECBAgAABAgQIRAhoTkcoWqOWQI3zucVqgFKrYtYlQIAAAQIECBB4FjBEeRbxNQECBAgQIECA
AIEBBWo0qzWqBzwIiUJ2JhMVQygECBAgQIAAAQK3BQxRbtN5kAABAgQIECBAgEAugRpN668ZGqrk
qnfmaGqcRecvc8XFRoAAAQIECBCYV8Avlp+3tjIjQIAAAQIECBBYTKB2k3lrjNdoji9WpunTrXFG
ap/t6YsiQQIECBAgQIAAgdsC3kS5TedBAgQIECBAgAABAnkFajSyn7PV2H4WWe9r52y9msuYAAEC
BAgQILCagCHKahWXLwECBAgQIECAwDICLRrcG6ZhSs4jVVr/57qWrndV6Xn/q8+7nwABAgQIECBA
gECEgCFKhKI1CBAgQIAAAQIECCQV0PhOWpjAsFrXODD0t0sZoLylcYEAAQIECBAgQKCxgCFKY3Db
ESBAgAABAgQIEGgt0KPJrgler8o96lkvm+8rOzvfTXxCgAABAgQIECDQT8AQpZ+9nQkQIECAAAEC
BAg0E+jZeNcULytzz9qVRX79aWflupknCBAgQIAAAQIE6goYotT1tToBAgQIECBAgACBNAIZmvGa
5OeOQ4ZanYs05i7nIsbRKgQIECBAgAABAvEChijxplYkQIAAAQIECBAgkFogS4Ne4/z3MclSjx6H
1hnooW5PAgQIECBAgACBKwKGKFe03EuAAAECBAgQIEBgIoGMzfsVmuoZ3Vsf6xXq3NrUfgQIECBA
gAABAnUEDFHquFqVAAECBAgQIECAwDACqzb1azXyV/U8e+BruZ/d330ECBAgQIAAAQIErggYolzR
ci8BAgQIECBAgACBBQQMARYocqcUDVA6wduWAAECBAgQIEDgtsCP2096kAABAgQIECBAgACBKQW2
Rrdm95Sl7ZqUM9WV3+YECBAgQIAAAQI3BX7efM5jBAgQIECAAAECBAhMLvBoenszZfJCV0jPwKQC
qiUJECBAgAABAgS6CBiidGG3KQECBAgQIECAAIFxBAxTxqnVmUifBxylQ7Ln9c7E4B4CBAgQIECA
AAECowj4nSijVEqcBAgQIECAAAECBBIJlDbeE6UybSiGG9OWVmIECBAgQIAAAQINBbyJ0hDbVgQI
ECBAgAABAgRmEfB2Sr5KGprkq4mICBAgQIAAAQIExhcwRBm/hjIgQIAAAQIECBAg0E3ga+Pe2ylt
y2Bo0tbbbgQIECBAgAABAmsKGKKsWXdZEyBAgAABAgQIEAgXMFAJJ/22oMHJNxIfECBAgAABAgQI
EKgqYIhSldfiBAgQIECAAAECBNYUMFApr7uBSbmhFQgQIECAAAECBAiUChiilAp6ngABAgQIECBA
gACBXYF3wwA//utvtndOu7guEiBAgAABAgQIECBQVcAQpSqvxQkQIECAAAECBAgQeCfQcmiQYWDT
Mt935j4nQIAAAQIECBAgQOCagCHKNS93EyBAgAABAgQIECAwoIABxoBFEzIBAgQIECBAgACBBAI/
EsQgBAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAAB
AgQIECCQQcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAEC
BAgQIECAAAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQT
MERJVxIBESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAEC
BAgQIECAQDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBA
gAABAgQIECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQ
QcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIE
CBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECA
AAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIB
ESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECA
QDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQI
ECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAA
AQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMV
xECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQ
IECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAAB
AgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDoBQ5R0
JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQIECBAgAAB
AgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAAAQIECBAg
QIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMVxECAAAEC
BAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIZBAxR
MlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQIECAAAEC
BAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAABAgQIECBA
gAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDqBn+kiEhABAgQI
ECBAgACBxQQ+Pj52M/78/Ny97iIBAgQIECBAgAABAgQI1BHwJkodV6sSIECAAAECBAgQOCVwNEDZ
Fjlzz6nN3ESAAAECBAgQIECAAAEClwS8iXKJy80ECBAgQIAAAQIE4gSuDEe2e2u8kbIXQ4394vSs
RIAAAQIECBAgQIAAgfoC3kSpb2wHAgQIECBAgAABAikF9gYoW8BH11MmJSgCBAgQIECAAAECBAgE
ChiiBGJaigABAgQIECBAgMBZgd4DirP7n73vbN7uI0CAAAECBAgQIECAwEgChigjVUusBAgQIECA
AAECBAgQIECAAAECBAgQIECAQDMBQ5Rm1DYiQIAAAQIECBAgQIAAAQIECBAgQIAAAQIERhIwRBmp
WmIlQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEmgkYojSjthEBAgQIECBAgACB3wJ+z4iTQIAAAQIE
CBAgQIAAgTEEDFHGqJMoCRAgQIAAAQIEJhG4O0D5/PycREAaBAgQIECAAAECBAgQGEfAEGWcWomU
AAECBAgQIEBgUQEDlEULL20CBAgQIECAAAECBLoLGKJ0L4EACBAgQIAAAQIEVhG4+xZKb59R4+7t
Zn8CBAgQIECAAAECBMYXMEQZv4YyIECAAAECBAgQIFBdwCClOrENCBAgQIAAAQIECBBIKGCIkrAo
QiJAgAABAgQIECBAgAABAgQIECBAgAABAgT6Cxii9K+BCAgQIECAAAECBAi8Fcj0+1C8jfK2TC4Q
IECAAAECBAgQIDCpgCHKpIWVFgECBAgQIECAwPgCmQYo42vKgAABAgQIECBAgAABAtcFfl5/xBME
CBAgQIAAAQIECKwqsL2Ncme4k+Utljuxr1preRMgQIAAAQIECBAg8M8/3kRxCggQIECAAAECBAgk
FKjd7K+9/lfSLAOULaZMsSQ8dkIiQIAAAQIECBAgQOBJwJsojgQBAgQIECBAgACBRQW2QUrtoULt
9e+U7u7bNHf28sxrgZJzcebcthwSvs7QpwQIECBAgAABArMIGKLMUkl5ECBAgAABAgQIEEgmUNIo
T5bKt3Ba5TbTMCDK7Mw6BmXfjqwPCBAgQIAAAQIEbgr4cV434TxGgAABAgQIECBAYAaBWk36M43u
Ef22vFrm1nKvmvXokUePPWsaWpsAAQIECBAgQKCPgCFKH3e7EiBAgAABAgQIEJhWYMbmdevhydfD
Mbrn6PFP+40qMQIECBAgQIAAgVMCfpzXKSY3ESBAgAABAgQIEJhX4MzvmJg3+/eZZWr+b7HUemvo
vcC9K5nc7mXgKQIECBAgQIAAAQJ/BLyJ4jQQIECAAAECBAgQIEDgSSDjICBjTM8HZ4QYn2P2NQEC
BAgQIECAAIE9AUOUPR3XCBAgQIAAAQIECBBYTiDzIEBsyx1HCRMgQIAAAQIECHQWMETpXADbEyBA
gAABAgQIECDQVmDvx2JlHlK0Vbq2G7drXu4mQIAAAQIECBAYR8DvRBmnViIlQIAAAQIECBAgUEVg
pQa4AcqfI3Sm7nte20pn1qhyaC1KgAABAgQIECBAoJGAIUojaNsQIECAAAECBAgQIHAscNS0P17h
3h2rDQPO5rvd964mZ9e4V5Hyp97FXb6yFQgQIECAAAECBFYSMERZqdpyJUCAAAECBAgQIPAkkK0R
/jUeTfA6x/VqzZ8HKVefr5PF/qrOzr6Pq0jXF6AAAA3PSURBVAQIECBAgAABAucFDFHOW7mTAAEC
BAgQIECAwDQCIzTCj2KMapQf7TNN0QMSqW31taZ39oo6EwFUliBAgAABAgQIEJhEwBBlkkJKgwAB
AgQIECBAgMCRwJ2m9NGaPa9/zSdL8/xsHKPVoma878zefd7zzNmbAAECBAgQIEBgPYEf66UsYwIE
CBAgQIAAAQLrCdRsgmfQ7J3f1vDX9L9+EphdN/MEAQIECBAgQIBAWwFDlLbediNAgAABAgQIECBw
SiByKBC5Vuamd2Sep4r066Y7w5MecZ7Np+V9mc9SSwd7ESBAgAABAgQI5Bbw47xy10d0BAgQIECA
AAECBIoEVmvYb/nWbs7XXr+o4MkfZpe8QMIjQIAAAQIECBD4JmCI8o3EBwQIECBAgAABAgTGF6gx
PNEA738uRq7ByLH3r7wICBAgQIAAAQIEegn4cV695O1LgAABAgQIECBAoJJA7wFK72Z5jfwfpSrN
rSS20r0rHbdTy44c+6kE3USAAAECBAgQIDCtgCHKtKWVGAECBAgQIECAwIoCJU36d153GuB3nnm3
/53PazjciSPqmd6eJXmMHHtJ3p4lQIAAAQIECBCYQ8CP85qjjrIgQIAAAQIECBCYUODq7/eoMTgo
aYB/fbZGbEclv+p3tN7d66W5l9TgVczbeqUxvVr362fRMR/t5zoBAgQIECBAgACBWgKGKLVkrUuA
AAECBAgQIEDgSaBm87pGUzyyEf68Vo14Wxy4d3E/5/eI5d39Z2N9t+7Z59/dV/MsvtvT5wQIECBA
gAABAgRGFDBEGbFqYiZAgAABAgQIEFhG4MzbFKWN+leYtZr3j72+rl8j/lc51fzskcMjrxFyqhVr
7bNTs47WJkCAAAECBAgQIPAsYIjyLOJrAgQIECBAgAABAskE9gYp0c36Hg3woz2jc6xZ3pFirelg
bQIECBAgQIAAAQKzCPjF8rNUUh4ECBAgQIAAAQJTC7xqzr/67A7CNsR4/Hfn+drPZI6tZu5Hw6Wo
vVvtExWvdQgQIECAAAECBAi0FDBEaaltLwIECBAgQIAAAQIFAl+HJpEDlIKQPDqJgEHKJIWUBgEC
BAgQIECAQLiAIUo4qQUJECBAgAABAgQIvBcobVZvw5MVByhROb+vTK4rpeckVzaiIUCAAAECBAgQ
IDCugCHKuLUTOQECBAgQIECAAIHbApr0t+mqP9irNr32rQ5qAwIECBAgQIAAAQIFAoYoBXgeJUCA
AAECBAgQIHBHoGezetu75/53vGo/k8kjUyy13a1PgAABAgQIECBAYAQBQ5QRqiRGAgQIECBAgACB
6QR6NMt77BlRuBY/yiuDjRgiTos1CBAgQIAAAQIECMQKGKLEelqNAAECBAgQIECAwGmBlk3zlnud
BjhxY8kAZaScR4r1RNncQoAAAQIECBAgQGAagZ/TZCIRAgQIECBAgAABAgReCozaoJ99gJK1Lltc
JfYvD6EPCRAgQIAAAQIECAwq4E2UQQsnbAIECBAgQIAAgTkEajfSa69fqwolTfy7Od997o5By71m
jO9OTp4hQIAAAQIECBAgcEfAEOWOmmcIECBAgAABAgQIBArUaqjXWjcw9ZdLlQxQXi544cPaZtv6
tfe4kO7uraPEuZuEiwQIECBAgAABAgQKBfw4r0JAjxMgQIAAAQIECBCIENga1pHDAw3w+1WJqAX/
+/6eJECAAAECBAgQIJBJwBAlUzXEQoAAAQIECBAgsLRARPN+A2zdwN8b/rSOJWq/qFrUOtCZzGvl
aF0CBAgQIECAAAECGQQ+fv3PwWeGQMRAgAABAgQIECBAgMA/xW+jtP7r/V4z/1HPo5jOrHHmbBzt
c2aN53tKY+sVU9S+d/OP2v+5Hr4mQIAAAQIECBAg0FrA70RpLW4/AgQIECBAgAABAjsCJc3nkmd3
Qnp76WyD/fm+7euv/73d4MKFWrmXrvuc+4WUXt56dr2z973cxIcECBAgQIAAAQIECPxfwBDFYSBA
gAABAgQIECCQTOBO4/7OM63TfgxOWu/be7+R8757rgxxep86+xMgQIAAAQIECEQJGKJESVqHAAEC
BAgQIECAQKDAleb1lXsDQ7y0VM2meu38o9avaXCpGBdvjsr/4rZuJ0CAAAECBAgQIJBCwC+WT1EG
QRAgQIAAAQIECBD4LqB5/d3k+ZNWRts+EUOQxxp34o7Y/9nP1wQIECBAgAABAgQI7At4E2Xfx1UC
BAgQIECAAAECBAiEC1wZiIz848DC4SxIgAABAgQIECBAoLGAN1Eag9uOAAECBAgQIECAAIEYgTtv
c5TsHPU2yiOGK4OUkrg9S4AAAQIECBAgQIDAfQFvoty38yQBAgQIECBAgAABAp0EWg9QHmn22rcT
s20JECBAgAABAgQILC9giLL8EQBAgAABAgQIECBAYCyB3oOM3vv3qNaKOfdwticBAgQIECBAgEA+
AUOUfDUREQECBAgQIECAAAECbwSyNPOzxPGGqcrHV3K+cm+VYC1KgAABAgQIECBAIEjAECUI0jIE
CBAgQIAAAQIECNQVyNaYzxZPXf3fq5/J+cw9LWK1BwECBAgQIECAAIEIgY9ff8H9jFjIGgQIECBA
gAABAgQIrCdQ85ejj/S/KjUd7pyqkezu5OcZAgQIECBAgAABAq0EDFFaSduHAAECBAgQIECAwKQC
UQOE0Rv/UQ6lx2R0x9L8PU+AAAECBAgQIEAgUsAQJVLTWgQIECBAgAABAgQWFrg7RJip6X/XIOrY
zGQZZWIdAgQIECBAgAABAiUChiglep4lQIAAAQIECBAgQOAvgStDhFkb/lcMoo7PrJZRPtYhQIAA
AQIECBAgcFfAEOWunOcIECBAgAABAgQIECBwINBioGKAclAElwkQIECAAAECBAgUCPwoeNajBAgQ
IECAAAECBAgQILAjUHPAsa1dc/2dtFwiQIAAAQIECBAgsIzAz2UylSgBAgQIECBAgAABAgQ6CBh0
dEC3JQECBAgQIECAAIEgAW+iBEFahgABAgQIECBAgAABAgQIECBAgAABAgQIEJhLwBBlrnrKhgAB
AgQIECBAgAABAgQIECBAgAABAgQIEAgSMEQJgrQMAQIECBAgQIAAAQIECBAgQIAAAQIECBAgMJeA
Icpc9ZQNAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECRgiBIEaRkCBAgQIECAAAECBAgQIECAAAEC
BAgQIEBgLgFDlLnqKRsCBAgQIECAAAECBAgQIECAAAECBAgQIEAgSMAQJQjSMgQIECBAgAABAgQI
ECBAgAABAgQIECBAgMBcAoYoc9VTNgQIECBAgAABAgQIECBAgAABAgQIECBAgECQgCFKEKRlCBAg
QIAAAQIECBAgQIAAAQIECBAgQIAAgbkEDFHmqqdsCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgSAB
Q5QgSMsQIECAAAECBAgQIECAAAECBAgQIECAAAECcwkYosxVT9kQIECAAAECBAgQIECAAAECBAgQ
IECAAAECQQKGKEGQliFAgAABAgQIECBAgAABAgQIECBAgAABAgTmEjBEmauesiFAgAABAgQIECBA
gAABAgQIECBAgAABAgSCBAxRgiAtQ4AAAQIECBAgQIAAAQIECBAgQIAAAQIECMwlYIgyVz1lQ4AA
AQIECBAgQIAAAQIECBAgQIAAAQIECAQJGKIEQVqGAAECBAgQIECAAAECBAgQIECAAAECBAgQmEvA
EGWuesqGAAECBAgQIECAAAECBAgQIECAAAECBAgQCBIwRAmCtAwBAgQIECBAgAABAgQIECBAgAAB
AgQIECAwl4Ahylz1lA0BAgQIECBAgAABAgQIECBAgAABAgQIECAQJGCIEgRpGQIECBAgQIAAAQIE
CBAgQIAAAQIECBAgQGAuAUOUueopGwIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBIwBAlCNIyBAgQ
IECAAAECBAgQIECAAAECBAgQIECAwFwChihz1VM2BAgQIECAAAECBAgQIECAAAECBAgQIECAQJCA
IUoQpGUIECBAgAABAgQIECBAgAABAgQIECBAgACBuQQMUeaqp2wIECBAgAABAgQIECBAgAABAgQI
ECBAgACBIAFDlCBIyxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCRiizFVP2RAgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQJBAoYoQZCWIUCAAAECBAgQIECAAAECBAgQIECAAAECBOYSMESZq56yIUCA
AAECBAgQIECAAAECBAgQIECAAAECBIIEDFGCIC1DgAABAgQIECBAgAABAgQIECBAgAABAgQIzCVg
iDJXPWVDgAABAgQIECBAgAABAgQIECBAgAABAgQIBAkYogRBWoYAAQIECBAgQIAAAQIECBAgQIAA
AQIECBCYS8AQZa56yoYAAQIECBAgQIAAAQIECBAgQIAAAQIECBAIEjBECYK0DAECBAgQIECAAAEC
BAgQIECAAAECBAgQIDCXgCHKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYIgSBGkZAgQI
ECBAgAABAgQIECBAgAABAgQIECBAYC4BQ5S56ikbAgQIECBAgAABAgQIECBAgAABAgQIECBAIEjA
ECUI0jIECBAgQIAAAQIECBAgQIAAAQIECBAgQIDAXAL/A42ghxLmmMjjAAAAAElFTkSuQmCC
--00000000000066818705bc251d32--


From nobody Thu Feb 25 04:30:28 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305803A16A7; Thu, 25 Feb 2021 04:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7BnBMne9_-0; Thu, 25 Feb 2021 04:30:23 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11olkn2091.outbound.protection.outlook.com [40.92.20.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD77C3A1474; Thu, 25 Feb 2021 04:30:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dRgsaVly5rB+OKsRZ5Mvghw+2+h7Vjz16uPa5qu6FNCfjrr9mGoQG+6++ag5+qRYX7MIxIT0EgnDwL4azkcz22j/lJeF4rj2rSB0lAqe0hDZxq11BLSFO7nRKe9YzOoHK0zuZRSrxb4stSqyUdsKXudP89tRdroeN2JGzKSz+G9DKHLtabbkxIZDcrnM6ei4QjWYVA08A3W4oAWu7tU08pycYDkuIXWrmmXgGSnt+fD0+5j6mnw+2jWW367t/9OGrqn3Y3WkYPPIb44VCdfvd5ZxVn8fCsxEupmusVwiRF5YblFfPe9v+DAJGx6fspBRfUq/jUMli7j/KCbrtcTCbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sTWAhLKlkVr5GupuBI0TD4TmLimzczoSePgAt2bLxPc=; b=mpedMlqGYsC5TM208ZggR0msvXcATqflCy6nElOCouatD3RnKZp/6krtwzoIeg1DDqMoCOPzgycrUI4wrsjfjTeo4pR8DW38ejCuUtMKTwoEHCZ63OuBV+uq1QQVY5dVlXogy0vm1jskNA6y4pwwq+RDnP+BnFLpDtXrpfeiNOCIuDA4SXdmsSkQSKMy9JEeiTzOoElkxWLE135KUR5O/1/RCiRAKwkFPj/lKtuHvpHwiPji+Q49FFOK1GHkl45PUST7F6J7tnQp1njelS+nCJhxVkXC/A8lYS592w+KJIZY/NH6Wz8GHNRz+JEtZ1BctAc6yPXrLeUzVzzyRijxbQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sTWAhLKlkVr5GupuBI0TD4TmLimzczoSePgAt2bLxPc=; b=hZhN/YoXXlCUknqakXtDMzKmSHXGedbW/U8JDgqxmwY3XxrHm2aAZEDsICKKusx6muVtJv/QbzvC2bO0IQ8rXcKmj3AEOuPGlifMsdeJ56JztcnLPcuddPwR+xEQHdffE1y8CxjG1nXAdK0dsbbY3Y+v9GPa4d1rsK3TAPO3OmpYeK8/K4Wr/WP1RuXD/kZcKtdEpCu6Fgm3avZpRgZFGsgi84LoAxFOxYrvt9exkn75UmYTxK3BJJcywC1ava11YN+NPl8qi7QK6CQ28IP2BIsGebxaLPfhnWpE2yddIZpVMVasGgdNM/BQ1Ooqx5gO/mWuJQT+VMiFjtmnSPQf7Q==
Received: from DM6NAM11FT005.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::47) by DM6NAM11HT075.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::392) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Thu, 25 Feb 2021 12:30:21 +0000
Received: from BYAPR05MB3941.namprd05.prod.outlook.com (2a01:111:e400:fc4d::47) by DM6NAM11FT005.mail.protection.outlook.com (2a01:111:e400:fc4d::238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 12:30:21 +0000
Received: from BYAPR05MB3941.namprd05.prod.outlook.com ([fe80::bcb4:5932:3435:f4dc]) by BYAPR05MB3941.namprd05.prod.outlook.com ([fe80::bcb4:5932:3435:f4dc%6]) with mapi id 15.20.3912.009; Thu, 25 Feb 2021 12:30:21 +0000
From: ST GERMAIN 
To: Bron Gondwana , Justin Richer 
CC: Phillip Hallam-Baker , "oauth@ietf.org" , "ietf@ietf.org" 
Thread-Topic: [OAUTH-WG] We appear to still be litigating OAuth, oops
Thread-Index: AQHXCnviFuP3ykJL6kShrDRkP51bl6pnGPOAgAAD1ICAAAfyAIAACaWAgAAIZgCAAAGugIAAMykAgAB4wYCAAOo0mg==
Date: Thu, 25 Feb 2021 12:30:21 +0000
Message-ID: 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com> , <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>
In-Reply-To: <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:BCE159F67631A1EDF68C1D467767C359805E6526524733CCCA0CE338CC488380; UpperCasedChecksum:F629F1237B19BFF37414E1DE9227893256BAF54DA9ACCBA35B16B13BDA3DD54B; SizeAsReceived:7629; Count:44
x-tmn: [fLNCGn6fFlEGihqMpATVRlj56Lyxj5Cs]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: f6987fb8-193a-43f5-d5ad-08d8d9891e4a
x-ms-traffictypediagnostic: DM6NAM11HT075:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: owhtApZAkAZ9JNpQTtm7T+oWrN2qzpjCzMsC5s10usgbSuKTy4YCK30ebyVl0oVAuQCiRl5IMqLAOd/fExL+UmQBohtYC1fMHYn67Om+qGTLpFoGZevZwjhDY+fEEVu0f56pMHxfQnWJVW7Vwm1Fd2kogBD5DRiJxytIS5D+Z6RO467ZCZ2muriEugCYQcwn+cb8Za6UVKGhzUYx5QT4XJGP5BUyKny7n7ElM4gb83Xp3la19IhsDKbJPFwDINE5Hjmivh5WjS19knZnx01DNoENnAHP1Taz3154bg7m2P5uhYaFmFDVXWEbEsfkaOilQxUghwrv1JbOiHmIUR/0smCoiyzBNsDBKgt0cGRmHLZVuCQhem/kaHdI3m/c4ackINGHEGOoPKPpvsRIlVWhaR93bRisOSqGRKgjkyIdOFnchaowqhLhCL25wWl5sYZu
x-ms-exchange-antispam-messagedata: TVjP10x4rbKciPvyRzdDI6ZAynkDzseM5TwcTBFUOmgZ/FthxcgW7Z9Djd8q26lp9Aj2VnT3Eeb8ujE4/+E89SKNxjXva8m/VZodw4zptpGE2d6qwcdcC+WbQx/d2r7YUSqb6vswemKpv82Cupkbgw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT005.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: f6987fb8-193a-43f5-d5ad-08d8d9891e4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 12:30:21.4213 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT075
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2021 12:30:26 -0000

--_004_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_
Content-Type: multipart/alternative;
 boundary="_000_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_"

--_000_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

My apologies, I=92m just a near homeless guy who can=92t access any funds d=
o to one reason or another who in addition ate pizza from a dumpster just r=
ecently. Peace. MSBRA

Get Outlook for iOS
________________________________
From: OAuth  on behalf of Bron Gondwana 
Sent: Wednesday, February 24, 2021 3:30:33 PM
To: Justin Richer 
Cc: Phillip Hallam-Baker ; oauth@ietf.org ; ietf@ietf.org 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
I agree that the NxM problem is the purview of the whole IETF, but it=92s s=
omething that we=92re particularly interested in over in GNAP. As the edito=
r of OAuth=92s dynamic registration extension and the GNAP core protocol, I=
 hope I can add to this conversation.

>From a technical standpoint, OAuth=92s dynamic client registration lets arb=
itrary clients talk to an AS, but the trust isn=92t there in practice. On t=
op of that I think this problem is exacerbated by a fundamental protocol de=
sign element of OAuth: the client_id that=92s required. That field means th=
ere=92s an assumption that a relationship was set up between the pieces of =
software, implied to be trusted by admins at the AS. Sure you can get that =
client_id under special circumstances, but there=92s still a special weight=
 handed to that and the dynamic stuff feels like you=92re giving up control=
 as an AS. In GNAP, the relationship is inverted, and it=92s designed as =
=93dynamic-first=94, with pre-registered clients being an optimization on t=
op of that.

Yep, this is the big point - OAuth is designed to require the the third leg=
 of trust that creates the NxM problem.


[cid:16142055119760.09058712623360687@content.messagingengine.com]

If that dotted line between client and server requires a pre-existing trust=
 relationship rather than the trust being entirely mediated by the user cho=
osing to connect client A with server B, then you have the NxM problem.  Th=
is is the "you can only have your John Deere tractor serviced by an approve=
d John Deere service centre" problem.  You can only use this client with se=
rvers who have pre-approved it.  Or fall back to the "cash of the internet"=
 - plain text passwords.

Does this solve the NxM problem? No, because companies are still going to d=
ecide that they only talk to keys or identifiers that they know ahead of ti=
me. But the protocol puts the dynamic case forward as baseline and fits in =
much better with the likes of JMAP than OAuth ever could:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does discovery (maybe=
 that=92s a JMAP thing? Webfinger?) and finds the JMAP server and the GNAP =
endpoint for authentication as an option.
- {Bat} talks to the GNAP AS at {ISP} and presents the key it just made up.=
 {ISP} has never seen this key, but knows how to talk GNAP and get the user=
 to authorize {Bat} to access email.
- {User} does this using GNAP and gets back an access token that=92s tied t=
o the key {Bat} made back at the beginning. That token is tied (at the {ISP=
}) to the user=92s account.

Yes, you can do all of this today with OAuth (and people have done so), but=
 OAuth=92s basic model of =93go do discovery and registration first and THE=
N talk to me=94 is a trust impediment more than it is a technical impedimen=
t. The =93negotiation=94 part of the GNAP name comes from the philosophy of=
 =93start talking first and figure out what you need as you go=94. Instead =
of jumping through hoops to get something you can trust, you just start in =
and then decide how much you trust it. A corporate rollout could use its ow=
n key distribution mechanism and static registration to limit which client =
instances talk back to the company server, regardless of which accounts wou=
ld authorize access on top of that. An internet-facing service is going to =
be more likely to take a TLS approach, of =93I=92ll talk to you in a secure=
 fashion without caring who you are right now=94.

We really are trying to make GNAP a consistent protocol at its core and lea=
rn from problems with OAuth in the wild, all while letting GNAP address a w=
ider variety of use cases. I agree that GNAP could be clearer about specifi=
c use cases, and we=92re working on the spec still so any help here is appr=
eciated.

Excellent.  This is precisely what I've been waiting for for these very man=
y years as a viable replacement for storing a password locally on disk.  Ju=
st having the server able to distinguish between different client instances=
 for the same user is a big start, because you can de-authorise one without=
 having to lock out every connection - even if the user is still entering t=
heir password during the setup phase each time.

This is what Fastmail already do with our own app, creating a long-lived ac=
cess token and storing that on the device rather than storing the password =
itself - and you can log out any one client from your security settings pag=
e.  What's missing is a standard way to do that with any IMAP client.  The =
initial JMAP authentication proposal was a very simple case of pretty much =
this, build into to the protocol so everyone would do it.

Making it easy to connect up arbitrary clients with per-client tokens the d=
efault, and easy rather than almost impossible to do in practice is where t=
he big difference comes in.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com



--_000_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable












My apologies, I=92m just a near homeless guy who can=92t access any funds d=
o to one reason or another who in addition ate pizza from a dumpster just r=
ecently. Peace. MSBRA









Get Outlook for iOS






From: OAuth <oauth-bounc=
es@ietf.org> on behalf of Bron Gondwana <brong@fastmailteam.com>
Sent: Wednesday, February 24, 2021 3:30:33 PM

To: Justin Richer <jricher@mit.edu>

Cc: Phillip Hallam-Baker <phill@hallambaker.com>; oauth@ietf.o=
rg <oauth@ietf.org>; ietf@ietf.org <ietf@ietf.org>

Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops=


 







On Thu, Feb 25, 2021, at 02:18, Justin Ric=
her wrote:






I agree that the NxM problem is the purview of the whole IETF, but it=
=92s something that we=92re particularly interested in over in GNAP. As the=
 editor of OAuth=92s dynamic registration extension and the GNAP core proto=
col, I hope I can add to this conversation.









From a technical standpoint, OAuth=92s dynamic client =
registration lets arbitrary clients talk to an AS, but the trust isn=92t th=
ere in practice. On top of that I think this problem is exacerbated by a fu=
ndamental protocol design element of OAuth:
 the client_id that=92s required. That field means there=92s an assumption =
that a relationship was set up between the pieces of software, implied to b=
e trusted by admins at the AS. Sure you can get that client_id under specia=
l circumstances, but there=92s still a
 special weight handed to that and the dynamic stuff feels like you=92re gi=
ving up control as an AS. In GNAP, the relationship is inverted, and it=92s=
 designed as =93dynamic-first=94, with pre-registered clients being an opti=
mization on top of that.











Yep, this is the big point - OAuth is desi=
gned to require the the third leg of trust that creates the NxM problem.






















If that dotted line between client and ser=
ver requires a pre-existing trust relationship rather than the trust being =
entirely mediated by the user choosing to connect client A with server B, t=
hen you have the NxM problem.  This
 is the "you can only have your John Deere tractor serviced by an appr=
oved John Deere service centre" problem.  You can only use this c=
lient with servers who have pre-approved it.  Or fall back to the &quo=
t;cash of the internet" - plain text passwords.











Does this solve the NxM problem? No, because companies=
 are still going to decide that they only talk to keys or identifiers that =
they know ahead of time. But the protocol puts the dynamic case forward as =
baseline and fits in much better with
 the likes of JMAP than OAuth ever could:









- {The Bat} creates a key pair.




- {User} enters their email address into {Bat}, {Bat} =
does discovery (maybe that=92s a JMAP thing? Webfinger?) and finds the JMAP=
 server and the GNAP endpoint for authentication as an option.




- {Bat} talks to the GNAP AS at {ISP} and presents the=
 key it just made up. {ISP} has never seen this key, but knows how to talk =
GNAP and get the user to authorize {Bat} to access email.




- {User} does this using GNAP and gets back an access =
token that=92s tied to the key {Bat} made back at the beginning. That token=
 is tied (at the {ISP}) to the user=92s account.









Yes, you can do all of this today with OAuth (and peop=
le have done so), but OAuth=92s basic model of =93go do discovery and regis=
tration first and THEN talk to me=94 is a trust impediment more than it is =
a technical impediment. The =93negotiation=94
 part of the GNAP name comes from the philosophy of =93start talking first =
and figure out what you need as you go=94. Instead of jumping through hoops=
 to get something you can trust, you just start in and then decide how much=
 you trust it. A corporate rollout could
 use its own key distribution mechanism and static registration to limit wh=
ich client instances talk back to the company server, regardless of which a=
ccounts would authorize access on top of that. An internet-facing service i=
s going to be more likely to take
 a TLS approach, of =93I=92ll talk to you in a secure fashion without carin=
g who you are right now=94.









We really are trying to make GNAP a consistent protoco=
l at its core and learn from problems with OAuth in the wild, all while let=
ting GNAP address a wider variety of use cases. I agree that GNAP could be =
clearer about specific use cases,
 and we=92re working on the spec still so any help here is appreciated.&nbs=
p;











Excellent.  This is precisely what I'=
ve been waiting for for these very many years as a viable replacement for s=
toring a password locally on disk.  Just having the server able to dis=
tinguish between different client instances
 for the same user is a big start, because you can de-authorise one without=
 having to lock out every connection - even if the user is still entering t=
heir password during the setup phase each time.









This is what Fastmail already do with our =
own app, creating a long-lived access token and storing that on the device =
rather than storing the password itself - and you can log out any one clien=
t from your security settings page. 
 What's missing is a standard way to do that with any IMAP client.  Th=
e initial JMAP authentication proposal was a very simple case of pretty muc=
h this, build into to the protocol so everyone would do it.









Making it easy to connect up arbitrary cli=
ents with per-client tokens the default, and easy rather than almost imposs=
ible to do in practice is where the big difference comes in.









Bron.











--




  Bron Gondwana, CEO, Fastmail Pty Ltd




  brong@fastmailteam.com




















--_000_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_--

--_004_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_
Content-Type: image/png; name="image.png"
Content-Description: image.png
Content-Disposition: inline; filename="image.png"; size=44628;
 creation-date="Wed, 24 Feb 2021 22:32:23 GMT";
 modification-date="Wed, 24 Feb 2021 22:32:23 GMT"
Content-ID: <16142055119760.09058712623360687@content.messagingengine.com>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAABlEAAANCCAYAAAD2kOrdAAAABHNCSVQICAgIfAhkiAAAIABJREFU
eF7s3Quy3DiSIMBSmy4xp9j7H2NPscfQilOV3dkUfwACID4+ZmU9L5MEIjxAECT0pB+/fv/fX/6P
AAECBAgQIECAAAECBAgQIECAAAECBAgQIEDgvwT+xYMAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg
QOBPAZsof5r4hAABAgQIECBAgAABAgQIECBAgAABAgQIECDwl00Ug4AAAQIECBAgQIAAAQIECBAg
QIAAAQIECBAgcCBgE+UAxUcECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAZsoxgABAgQIECBAgAAB
AgQIECBAgAABAgQIECBA4EDAJsoBio8IECBAgAABAgQIECBAgAABAgQIECBAgAABAjZRjAECBAgQ
IECAAAECBAgQIECAAAECBAgQIECAwIGATZQDFB8RIECAAAECBAgQIECAAAECBAgQIECAAAECBGyi
GAMECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgQMBmygHKD4iQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIECNhEMQYIECBAgAABAgQIECBAgAABAgQIECBAgAABAgcCNlEOUHxEgAABAgQIECBAgAABAgQI
ECBAgAABAgQIELCJYgwQIECAAAECBAgQIECAAAECBAgQIECAAAECBA4EbKIcoPiIAAECBAgQIECA
AAECBAgQIECAAAECBAgQIGATxRggQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwI2EQ5QPERAQIE
CBAgQIAAAQIECBAgQIAAAQIECBAgQMAmijFAgAABAgQIECBAgAABAgQIECBAgAABAgQIEDgQsIly
gOIjAgQIECBAgAABAgQIECBAgAABAgQIECBAgIBNFGOAAAECBAgQIECAAAECBAgQIECAAAECBAgQ
IHAgYBPlAMVHBAgQIECAAAECBAgQIECAAAECBAgQIECAAAGbKMYAAQIECBAgQIAAAQIECBAgQIAA
AQIECBAgQOBAwCbKAYqPCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQI2UYwBAgQIECBAgAABAgQI
ECBAgAABAgQIECBAgMCBgE2UAxQfESBAgAABAgQIECBAgAABAgQIECBAgAABAgRsohgDBAgQIECA
AAECBAgQIECAAAECBAgQIECAAIEDAZsoByg+IkCAAAECBAgQIECAAAECBAgQIECAAAECBAjYRDEG
CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIHAjZRDlB8RIAAAQIECBAgQIAAAQIECBAgQIAAAQIE
CBCwiWIMECBAgAABAgQIECBAgAABAgQIECBAgAABAgQOBGyiHKD4iAABAgQIECBAgAABAgQIECBA
gAABAgQIECBgE8UYIECAAAECBAgQIECAAAECBAgQIECAAAECBAgcCNhEOUDxEQECBAgQIECAAAEC
BAgQIECAAAECBAgQIEDAJooxQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBA4ELCJcoDiIwIECBAg
QIAAAQIECBAgQIAAAQIECBAgQICATRRjgAABAgQIECBAgAABAgQIECBAgAABAgQIECBwIPDz4DMf
ESBAgAABAgQIECBAgAABAgQIEBhS4MePH0PG/SToX79+PTnMMQQIECAQKGATJRBTUwQIECBAgAAB
AgQIECBAgAABAnECM2+I5CidedhcydF0DgECBJ4J2ER55uQoAgQIECBAgAABAgQIECBAgACBBgJn
GwUNuh62iygzmzHDDgGBEyBQUcAmSkVcTRMgQIAAAQIECBAgQIAAAQIEvgVKXnaP/oK7JHejqI3A
UY1GH3dt5PRCgMDMAj9+T4T+MsWZKyw3AgQIECBAgAABAgQIECBA4BWBoxfSrwSiUwLBAl4nBoNq
jgCBrgX8JkrX5REcAQIECBAgQIAAAQIECBAgMIKADZMRqiTGKIH9eLepEiWrHQIEehSwidJjVcRE
gAABAgQIECBAgAABAgQIvC6wf1H8ekACINCpwNm1YnOl04IJiwCBJAGbKElcDiZAgAABAgQIECBA
gAABAgRWEDh7KbxC7nIkECWwv45sqkTJaocAgZYCNlFaauuLAAECBAgQIECAAAECBAgQ6Fpg/9K3
62AFR2Awgf31ZVNlsAIKl8CiAjZRFi28tAkQIECAAAECBAgQIECAAIH/Fti/4OVDgEBdgf01Z1Ol
rrfWCRDIE/hX3mnOIkCAAAECBAgQIECAAAECBAjMI7B/mTtPZjIhMI7Adh26Fsepl0gJrCLgN1FW
qbQ8CRAgQIAAAQIECBAgQIAAgUMBL20PWab7cKTfclh9TG75j1Sv6S4WCREg8F8CP35PSL+YECBA
YBNIXaTVmD5SYzirXI3YzvryOQECBAgQIECAAAEC4wpEPYOMKzBm5Ks+8602Xlet85hXpagJzCtg
E2Xe2sqsscBqC5nGvM26s0BrRq0jAgQIECBAgAABAq8LeI57vQRJAXheu+Z6Op43x6fHXvfY5lt1
b+OsFwIEzgVsopzb+IbAfwmMtMBQuhgBC7UYR60QIECAAAECBAgQ6FGgp2e8/bNHT7G1qN0+/xZ9
6uNPgV7HnfHxZ618QoBAWwGbKG299RYsUOsGv79B1+onmENzlQX246Jyd5onQIAAAQIECBAgQKCS
wNvPeJ4tKhVWs+ECb18rW0Kul/CyapAAgUQBmyiJYA5vJ9DDjbpdtnoiMJ6Ahex4NRMxAQIECBAg
QGB1gTeeM62bVx91c+X/xjVUIuj6K9FzLgECHwGbKMZCFwKj3YS7QBMEgYEFLGQHLp7QCRAgQIAA
AQKDCkQ+d1rPDjoIhF1NIPL6qhbkV8Ou4RbK+iAwj4BNlHlq2XUmo91Mu8YUHIFJBSxiJy2stAgQ
IECAAAECHQhEPpNat3ZQUCF0LxB5zbVO1jXeWlx/BPoXsInSf42GjHDkm+WQ4IImMKGAheuERZUS
AQIECBAgQKChQI3nUmvUhgXU1VQCNa7HUYHMI6NWTtwrC/xcOXm5xwq4IcZ6ao3A6gJHc4rF5uqj
Qv4ECBAgQIAAgXuBo3Xk/Vn3R1iL3hs5ggCBe4GIOcp8dO/sCAKRAjZRIjUXayti0l+MTLoECBQK
fM87Fo2FmE4nQIAAAQIECEwiUPvZ1LpzkoEiDQITCdzNe+atiYotlS4EbKJ0UYb+g7ibnPvPQIQE
CMwmsM1LFoazVVU+BAgQIECAAIF7gZbPp9ab9/VwBAEC/QkczZPms/7qJKJxBGyijFOrqpEeTa5V
O9Q4gUSBs5u9sZsIOdnhn/qfjY/J0pUOAQIECBAgQGB5gZbrf2vM5YcbAAJTCRzNn+a5qUosmYoC
/mH5iri9Nn00afYa6wxxuSH1WUXXQZ91KY3K9VYq6HwCBAgQIECAQL8CLdfw1pX9jgORjSnQ8vod
U6iPqM19fdRBFP0J2ETpryahEblJhXL+uzE3lTqub7XqOnlLvl6/rtF6tlomQIAAAQIECLwh0HLN
bi35RoX1uYJAy+t4Bc/aOZoLawtrfyQBmygjVesmVjej/wA9nehzzZ62f1MyX3cskDs2Ok5pudBc
p8uVXMIECBAgQIDApAIt1+bWkJMOIml1I9Dyeu4m6UkCMT9OUkhpZAnYRMlie/+klW86tSbtp6a1
+n9/VImAwLHA02vj+Ox3P3W9vuuvdwIECBAgQIBAiUDLdah1Y0mlnEvgfYGW88X72b4XgbnyPXs9
vytgE+Vd///q3YT/ZzHemJyv6vBGPH+q+ITAOAJX11OrLFy3raT1Q4AAAQIECBAoE3hr7Wi9WFY3
ZxPoWeCteaVnk9LYzJmlgs4fUcAmyktVM4n/DW/ifWkA6pbAiwJvzH/mmhcLrmsCBAgQIECAwAOB
N9aIW1jWiQ+K4xACkwq8Ne/MwGnunKGKckgRsImSopV5rEn5P3Am2cxB5DQCEwu0mCPNPRMPIKkR
IECAAAECwwq0WAce4VgbHqn4jACBaIG35rjoPM7aM5eeyfh8RgGbKAFVnX1SLCUyqZYKOp/AegI1
5lVz0XrjSMYECBAgQIBAvwI11nt32VoP3gn5ngCB3gTemCtTDcytqWKOH1HAJkph1UaYzApTTD7d
5JlM5gQCBC4EIudZ89MFtK8IECBAgAABAo0EItd3VyFb+13p+I4AgRkEWs2nT63Mu0+lHDeagE2U
gor1NlEVpJJ9qskxm86JBAgkCLSYb81nCQVxKAECBAgQIEAgQ6D2ms56LqMoTiFAYDqB2nPtEzDz
8RMlx4wkYBMls1o9TEiZoSedZtJL4nIwAQKVBd6ae82FlQureQIECBAgQGB6gRbrOGu26YeRBAkQ
yBRoMQefhWZuPpPx+UgCNlEyqvXmxJMR7qNTTGiPmBxEgEAnAm/Ow+bLTgaBMAgQIECAAIFhBFqs
3azRhhkOAiVAoAOBFvPyUZrm6iMVn40gYBMloUpvTTAJIT4+tIdJ69uzh3ge4zmQAIEuBHqYk81d
XQwFQRAgQIAAAQIdC7RYs1mTdTwAhEaAQPcCLebpIwRz95GKz3oVsInysDJvTSgPw7s8rMdJae/Z
Y4yXqL4kQKALgf1c8lZQ5rC35PVLgAABAgQI9CzQYq1mHdbzCBAbAQIjCrSYu/cu5vK9iJ97E7CJ
8qAib0weD8I6PMSkc8jiQwIEJhbodY42H0886KRGgAABAgQI3ArUXKNZZ93yO4AAAQJFAjXn8KvA
zO9XOr57U8AmygP9tyaOT2gmkAdFcggBAksLvD1PP8E3lz9RcgwBAgQIECAwg0D02sw6aoZRIQcC
BEYTiJ7Ln+Zvzn8q5biWAjZRbrRbTxgmipuC+JoAAQInAq3n65Mwkj827yeTOYEAAQIECBDoWCB6
TWat1HGxhUaAwPQC0XN6Cpj5P0XLsbUFbKLcCNecLEwGN/i+JkCAQKJAzTk7MZTsw90bsumcSIAA
AQIECLwsELUWsx56uZC6J0CAwJdA1Nxeguq+UKLn3AgBmygXiqWThAv8AtdXBAgQqCRQOndXCiu7
WfeSbDonEiBAgAABAg0FotZg1j4Ni6YrAgQIJAhEzfMJXR4e6j5xyOLDygI2UU6ASycGF/QJrI8J
ECDQQKB0Dm8QYlYX7i1ZbE4iQIAAAQIEKgtErb2sdSoXSvMECBAIEoia90vDcd8oFXT+UwGbKAdS
pROBC/gA1UcECBDoRKB0ju8kjb/ca3qphDgIECBAgMDaAhFrK+uatceQ7AkQGFcg4h4Qlb17SZSk
do4EbKLsVEovfhfs0TDzGQECBMYQKL0HvJWle89b8volQIAAAQJrC0Ssnaxj1h5DsidAYB6BiHtC
lIZ7S5Skdj4CNlF2Y6HkgneBurAIECAwj0DJ/eBNBfeiN/X1TYAAAQIE1hIoXS9Zt6w1XmRLgMA6
AqX3hygp95koSe3YRPkaA6UXuAvTBUWAAIE5BUrvD2+quDe9qa9vAgQIECAwr0Dp+sgaZd6xITMC
BAh8C5TeLyI03XMiFNduwybKP/UvvaBdjGtfSLInQGANgdJ7RU9K7ls9VUMsBAgQIEBgLIHSNZF1
yFj1Fi0BAgSiBErvHyVxuPeU6DnXJso/Y6DkInYRupAIECCwrkDJ/aMnNfeynqohFgIECBAg0LdA
yfrHmqPv2oqOAAECLQRK7iMl8bkHleitfa5NlN/1L7lwXXxrX0CyJ0CAwF6g5J6yb+utn93b3pLX
LwECBAgQGEMgd71jjTFGfUVJgACBFgK595KI2NyPIhTXasMmyu965160Lri1LhbZEiBAoEQg915T
0mfpue5zpYLOJ0CAAAEC8wnkrmmsK+YbCzIiQIBAhEDufaW0b/elUsG1zv+5Vrp/ZvvWhfpnJD4h
QIAAgZkF9gu0Ee4/3zHu45+5VnIjQIAAAQIECBAgQIAAgTYC38+aLZ+Tt74857ap8Qy9LP2bKCUX
potshuEvBwIECPQjUHJPapmF+19LbX0RIECAAIH+BHLWLNYP/dVRRAQIEOhdIOd+k5OTe1SO2nrn
LLuJUnIhurjWu1BkTIAAgZYCJfeoVnG6F7aS1g8BAgQIEOhLIHWdYs3QV/1EQ4AAgREFUu89OTm6
X+WorXPOkn+dV4sLb50hJFMCBAgQiBb4Xrz1es/6jstiM3oEaI8AAQIECBAgQIAAAQIEPgItnpG3
Z1zPtsbcmcByv4lS+jLKxXQ2lHxOgAABArUFSu9hteNzj6wtrH0CBAgQIPCuQM5axPrg3ZrpnQAB
AjML5NyX7jzct+6E1vx+yd9EWbPUsiZAgACB0QVa/OmbEiO/nVKi51wCBAgQIDCfgBdR89VURgQI
EOhJ4HOfidxM8RspPVW4n1hsoiTUwgIwAcuhBAgQIFBVYH9Pilw0RgT+iWcfZ0Tb2iBAgAABAgQI
ECBAgAABAh+B6M0UGynG1l7AJspe5ORnL4FOYHxMgAABAl0InN2n3t5c8dspXQwPQRAgQIAAAQIE
CBAgQGB6ge25OOoZ2EbK9MMlKcF/JR09+MG5F9HZi6nBOYRPgAABAgsIbPew7//eTDn3PvxmzPom
QIAAAQIECBAgQIAAgXEEIt/jeoYdp+61I11mEyV30EdeeLWLqX0CBAgQIHAn8PaGSu79+C4v3xMg
QIAAAQIECBAgQIAAgU3g89wboeEZNkJx/DaW2ETJHew2UMYf4DIgQIAAgXOByIXleS9/fpN7X/6z
JZ8QIECAAAECvQp4nu61MuIiQIDAOgJR9yLPsOuMmbNMl9hEOUve5wQIECBAgMB//pRO1ALzialF
6BMlxxAgQIAAAQIECBAgQIBAiUDL59ySOJ3bt8D0myhe0vQ9AEVHgAABAn0JtPztlO0e7T7dV/1F
Q4AAAQIECBAgQIAAgdkEIjZSPLvONirS8pl+EyWNw9EECBAgQIDAJtB6M4U6AQIECBAgQIAAAQIE
CBCoJRDxjGsjpVZ1+m/XJspJjSJ2KE+a9jEBAgQIEBhG4LPQrH1ftBgdZkgIlAABAgQIECBAgAAB
AsMK1H62HRZG4JcCNlEOeFxMByg+IkCAAIHlBSL+5M4Voo2UKx3fESBAgACBdwXcp9/11zsBAgQI
xAmUvPt1P4yrw0gt/Rwp2BaxllxELeLTBwECBAgQeFvg+14ZvYDc2nMvfrvC+idAgAABAgR6FYhe
e33ytP7qteLiIkCglsA27+XOqZ5ba1Wl33ZtovRbG5ERIECAAIHuBT4P3LmLz+4TFCABAgQIECBA
oAOB2muto/ZtrHRQeCEQINCtgI2UbktTJbAfv2+Kv6q03EmjRwuBs9AmpzhL2+cECBAgQCBUIOXe
e9axe/KZjM8JECBAgMA7Aqn3d/fysjqlepf1dn62Op7b+IYAgTkESudb8+Qc4+Aui6n/TZTSi+AO
z/cECBAgQIDAnwIWkX+a+IQAAQIECBAg8FSgp3cZPcXy1M9xBAgQSBEofX41T6Zoj3vs1Jso45ZF
5AQIECBAYGyB0oXo2NmLngABAgQIzCXgBVG7erJuZ60nAgQIECDwVMAmylMpxxEgQIAAAQJJAiUb
KV4gJFE7mAABAgQIdCVQsgboKpHGwVj/NAbXHQECBP4RKL1vmb/nH0o2UeavsQwJECBAgMBrAqWL
0dcC1zEBAgQIECDwvwJeDNUfCJsx5/rOeiBAgMCVgGfXKx3f2UQxBggQIECAAIGqArmLUS8TqpZF
4wQIECBAgEAHAtY7HRRBCAQIEPhHIPfZdTvdfD73MLKJMnd9ZUeAAAECBLoQKFmMdpGAIAgQIECA
AAECwQJeuAWDao4AAQIBAp5dAxAnbMImyj9FdYFMOLqlRIAAAQIECBAgQIAAAQIEOhSwgdJhUYRE
gACBfwRy3xOb2+cdQj9nTc2gna+yUTXNnQjnE5URAQIE+hfY5n7zdv91EiEBAgQIEPgIuG9fj4Wo
59rrXuK+Vc84Sy0RILCGgGfYOes87SbKnOVaM6voRea+PYvCNceVrAkQaC+wzbf7OfhJFBahT5Qc
Q4AAAQIECPQskLMGSsnn6XNtShxP20yJ07EECBAYRSD3+XWU/MSZJmATJc3L0Y0FUhZ4uaF9+rBA
zBV0HgECBAgQIECAAAECBP7y26MHg6D2M23qc2zq8Qcp+YgAAQIEbgT8QcAboAG/tokyYNFWCbn2
YnPv+N2fheVex88ECBCIEcj90zwWoTH+WiFAgAABAgTaCNR8nvW82qaGeiFAgEDu8yu5+QT8w/Lz
1XTYjLZF5vd/byZSc8H7Zl76JkCAwMgC5uaRqyd2AgQIECCwjkDNNYsNlHXGkUwJEBhboOa9YGyZ
MaP3myhj1m2aqHueUD6xWaROM9wkQoAAAQIECBAgQIAAgaoCNZ9xPZtWLZ3GCRAgcCjgt1EOWZb7
0CbK75JbiNQd9zUXkXUj/7v1LX5jpIW0PggQWEXAInSVSsuTAAECBAisJVDr2dfz6FrjSLYECPQn
4Bm2v5q0jshf59VafLH+ai0iWzPOkkdrN/0RIEDgTMDLgDMZnxMgQIAAAQIjCtR4ZtzWS9ZMI44G
MRMgQOBvgRr3BrbvCNhEecd96l63CeLz30yJmvhmqqZcCBAgQIAAAQIECBC4E/AMdCf09/c1nGye
PLN3FAECBFoJ5M7LNe4RrXLWz38EbKIYDaECJoZQTo0RIEBgaoGcRaj7zNRDQnIECBAgQIDAb4Gc
NRI4AgQIECBAoJ6ATZR6tsu17MXWciWXMAECBIoFvCQoJtQAAQIECBAgMJGAtdFExZQKAQLTCeTO
0d6Zjj8U/MPy49ewiwzenAzOJrA3Y+qiKIIgQIAAAQIECBAgQIAAgSEEzp5rhwhekAQIECBAYHIB
myiTF3j29K4WmvvvbKrMPhrkR4AAAQIECBAgQIAAgbEE9s+tY0UvWgIECBB4KrC9lzTnP9Xq7zib
KP3VREQPBVInns/xPWymXMWQmtdDLocRIEBgGgGLz2lKKRECBAgQILCsgOe+ZUsvcQIEBhfY5u+r
93qDpyf8EwH/JsoJjI+fCWyTRuuJY5usShacpec/kzk/6s7r7vvzln1DgACBdQTMlevUWqYECBAg
MIZAyTPaGBnGRPn282hMFlohQIDA2gK59zzPseOOG7+JMm7tXo+81YWfOzHdAX3afZpHRBxP+9qO
i+jvzsD3BGoJXI11Y7uW+rjtbmPiasyMm5nICRAgQIAAAQIECBAgQIAAgdEF/CbK6BV8Kf7aL7s+
fzqnxcvWT19XlC3iuOrfdwRGEribH+6+HylXsb4rYCy96693AgQIECBAgAABAgQIrCrgXeFalfeb
KGvVu6tse5tseounq2IJhsBDgacvtf221UNQh90KGEu3RA4gQIAAAQIECBAgQIAAAQIECgT8JkoB
nlPzBWxY5Ns5k8AsAk83XGbJVx71BIylerZaJkCAAAECBAgQIECAAIFjAe83j11m/NQmyoxVrZxT
6csqE0zlAmmeAAECAwqU3htK700DkgmZAAECBAgQIECAAAECBAgQaCBgE6UBsi7+I1D6kowlAQIE
CMwr4B4xb21lRoAAAQIECPwtsP3BD3/4w2ggQIDAPAKeY+ep5VUmNlGudHz3h0DJYs+k8genDwgQ
IECAAAECBAgQIEBgQYGSZ+sFuaRMgAABAgReFbCJ8ir/Op3bQFmn1jIlkCLg4TFFa41j3S/WqLMs
CRAgQIAAgb/8RopBQIAAAQIEBhGwiTJIoXoIM/dlpxdiPVRPDAQIEBhHIPe+kXufGkdGpAQIECBA
gMBsAtYvs1VUPgQIECAwo4BNlBmrKicCBAi8JJD78vulcHXbsYCx1HFxhEaAAAECBAiECvh3UkI5
NUaAAIGuBWyed12e0+B+nn7jCwJfArkXuJdghhEBAgQI5Aps95Dc+09unzXP+7//8z+Xzf+f//f/
Lr/3JQECBAgQIDC3wLbu8Qw9d41lR4AAAQJjCvhNlDHr1jTqmV5gNYXTGQECBAgQ+EfgbgNlO+zJ
MUAJECBAgACB/gQiNz48f/dXXxERIECAAAGbKMbApUDJAi5yIXkZpC+zBD6/Mn70v1kNOokAAQIE
DgVSNkdSjj3szIcECBAgQIDAKwKRz78lz+GvJK9TAgQIECAwuYC/zmvyApekZ+FWotf3uXe13b6P
fAjoW0N00QKz/RVM0T7aqyvQ2/xlU6RuvbVOgACB0QSu7gv+WsfRqvlnvJHr4O9nNs9mf1r7hAAB
AgQItBSwidJSe6G+LPL6LfbdBson8t5eRPYrKjICBGoKRL6MqBnnUdtXL8qOjvcZAQIECMwtcHdf
+HxvM2XscVBj7XL3DOf5e+wxI3oCBAgQ6F/AJkr/NXolwrtF2itB6ZQAAQIECAwicPeibJA0hEmA
AAECQQIp94XvY22oBBWgcTM1NlKuUtg/v9tUudLyHQECBOIFWs/78Rlo8U7Av4nyW2i/4LhD8/21
gAXbtY9vCRAgQGBugZQXZXNLyI4AAQIESgXcU0oF3zt/ey5+69nYO4736q5nAgQIEJhTwCbKnHUt
ysqCq4jPyQQIECCwsICXXQsXX+oECBCoJODeUgm2UbM2UhpB64YAAQIECFQUsIlSEXfEpks3UN5a
II5oLWYCBAgQqCNQei+rE5VWCRAgQIBAvoCNlHy7Hs586znZmqiH6ouBAAECBGYQsIkyQxWDcihd
YL21MAxKXzMECBAg0KnAKPeXiBdc/u77TgehsAgQINCBwHafibjXdJDKkiG8tZ4pfc5fsliSJkCA
AAECOwGbKP+AWFiUXRtvLQjLonY2AQIECBDoR8AGSj+1EAkBAgR6Fmi1keIZOX4UvPXcrJbxtdQi
AQIECKwlYBPlq94rLyxKcn9rIbjWpRqX7dN6PT0uLjItESBAYFyB0hdaNlDGrb3ICRAg8IZA6X3n
jZj1+beA5ywjgQABAgQIjCcw7SaKhcl4g1HE7QTuro+779tFqicCBAiRy5RzAAAgAElEQVTkCZT8
4YDUHktfZNlASRV3PAECBMYTqDHXl95/xlOcJ+I3nrdaro3mqZRMCBAgQIDA3wLTbqLkFtjCIk3u
jcVfWoSOPhPYanf239k5PidAgACB/xYofYFV46WaGhEgQIBAnwLm/D7r8lZUn2ext/p/s9/tvUvU
f2/moW8CBAgQWEfAJso6tZYpAQIECBAYViBn0773PxjhZdqww1HgBAgQyBaInvv9Y/PZpejmxO8/
2NZNUBUC+d40iWy+9/VeZK7aIkCAAIH3BH78vmH/eq/7uj2X3EwnZjlEz7FazegQLvHDFGe+ibgO
70rAWO+qHNMEkzKuPknXnEtLfgsl+iXaNEWWCAECBBYSKLmPHDFF31tS77s177lH+a74WWpN9kZv
1ag07n0eRz+/ldtRLD4jQGBNgZS5zpw13hiZehNlK0fKAP4u32qDOdVpNZ+oSzvFmXGUunbeEDDW
31Cfv8+UcVX7nl764iv6Rdf81ZchAQIE5hYova98dCLvLyn3Xc8u74zPlBp9Imxdq5wYczVb55Yb
p/MIEJhTIGW+M1+NNwam/+u8cgdlysAfr+xlEeealvXqbAIECBAg0IdA6YuuyBdcfYiIggABAgRK
BaLuDaX3qNI8nN+/QMt3HS372uRb99d/tUVIgAABAlEC0/8mygZVciNdZcMgxWgVk6iL7LsdzjVU
tdmjgLHeY1XmiCllbH1nHHHvingxFfWSbI5qyoLAfwQirq+9Z0/X21V+PcW5Nzz7ebZ8zvJ84/Mr
25R4IsZVyj034j6bkp9j/yOQUqfPWS3qlRNXVF1b5BcVq3YIEJhHIGXeM0+NV/clNlG2sqQM5O8y
rjKoU3xWMalxOXOuoarNHgWM9R6rMkdMKWNrn3HJ/SvipVbEC619Tn4mMINAxPV15tDiuouIv0Wc
Z0ZPPk/NsVU+qXF9ci2N72m/uf08bf+udrn9f9pNueeW3GPv8vD9tUBKnT4t1a5XTkzXWaZ/WzvH
9IicQYDA7AIpc585arzRYBPlpmarDGoX+s1ACPqacxCkZroXMNa7L9HQAaaMr+9Ec+/pvbzMGrpo
gu9C4Gosl75szU3wKqbcNvfn1cwtMv6ace5Nnv5ckl/tfEpi2/LPjS+131b9nNU0t/+tvZT7be49
9ixunz8XSKnTd6s1a5Yb0/Os74+smd9979dHPPHpOf7r7J59e2cwe/7PlBw1msDduP7Oxxgfrbp/
/fVzvJDzIt4GZ8pgzuvFWQQIECBAgECvAts6IHWxmvqy7Cz3kpdYZ22+8Xmux5v5P425ZoxPY9jX
NDKmuxi27yP72+cy4893piPn3HtuEfHljPmcfnP62cbOdj3m9DfyuBP7HALeu/ynjiUWT85NXdf2
MsKe5Jazbu8lP3EQIDCnwDKbKLnlM3HnyjmPAAECBAjUEWj1ByOiXl5dvZhO6eOqnTrS/2k1Jc6j
WHJfIh61lfJZSty1YkyJYZ9bVExPY4jqb5+Hn/sVeDo2+s1g7shspMxd36jsctdFNd51PHk5HpV3
z+20cqhRw9quKTYj5lfbT/sECLwn8K/3um7f86i79O2l9EiAAAECBOYUSHlwixC42vhIfXmZenxJ
/Ftf3/+VtPU5t2X8W585/eWcc2UT0V5EG1cx+m5dAWNrjNpf3UfGyECULQS864hR3taJZ/897aH1
WrN1f08dHEeAAIHZBJbaRNmKZ3Hx5xB20/3TpMYnnGuoapMAgVUFRrifX734yn15mXteyjhp0UdK
PI4lQCBewHUeb6pFAgTKBbb13f6/8laftXD3vH73/dbLk2OeRTPXUd8bU3Nl1kc23745/38fWYiC
QP8C/jqv/mskQgIECBAgQOBAIPevrzhoKvyjqw2U8M4CG/RiNRBTUwQIECgQMB8X4Dl1OIGjPxzT
ckPiaV/bcUexbuBP2xiuOIUBcykEvDk9wnffxtkYvwnF1wSmF7CJ8qDEVzfKB6c7hIAFlTFAgACB
jgRq39dH3UDpqERCIUCAwJICPW2c7F+qLVmQwZLu+Q+XXFEevbDtefwdrSN7jvfKvvZ3b7tE9X80
Rmvb3bUfldtRP5+2e8z7KF6fEWglsNxf59UKVj8ECBAgQIBAfYHeFvc2UOrXXA9zCdS+Zmq3H1WN
UeJ8mu9s+TzNu+S4njZQSvJwLoEUge913Pbi9vNfShtHx7ZcH9Z8mX2U25PPvi33//+T8yOOedsl
sv/Itkay7S3vCDttECgRWHITJeeGOuvkMWteJReFcwkQIEBgfoEa9z8vDecfNzKsI1Dr2qnV7kch
qv2odupUJ73VFvlE9JHTRq1zam2g5MSbXnFnEMgT2G+g5LXy3lmfzYn3Ijju+W6Ne/f9catpn7bo
4yqiGv3XaPMqh7PvWsfR6zg/8/E5gZoC/jqvmrraJkCAAAECBKoLbA/hrR8ojpI6egnmBdaRlM9a
C2zj8Gh87uN4c7y+2ffeIeXnp7ZnbY6adw/5lNiXuKf0+6SfJ9fmmbfPCcwg0MMaLtWx15ifxrUd
l/OHi584PY3hSVs5MUb2/yTGlse8mVvNMdPSUF8ESgR+/J6UfpU0MOq5uZPPbFypDrPl32r8cm4l
rZ9eBFLGvHmll6qNHUfKmPvO9Gr8Rb3YOnqJVtL2UXtR1SuJ6y6GmnGf9Z2aT40YU2PY5xIZ01Us
kf3sc/BzfwJXYyEl2h7GTWouPcT8MU6NvWVtUu+rV/fTlLgdWybwdt1S+t/GTMrxT2VyxmKNOJ7G
W3rcd74peeQ43cWa0v9dW7nxRcawjzE3pn07OT/XzCslnjcNUuJ869iUOrF8q0r5/dpESbSbbZCn
XOAb1Wz5J5Y/+3DO2XROHFQgZcybVwYtcmdhp4y579Cvxl/0y639i7uc9vdtRJchJ6YnMdSO+yqG
pznVjPFpDPs8asa078vP6wnkjstNytgsHy8l/ne9R9Qn9b56dT+9i9f3MQKpNdt6ja5bSgxb3ynH
P1HKzSc6jiexRhyzzzclj/25pfGk9P2kr9z4ouP4jjU3pif5Xh1TM6erfs++e8vhLJ6ePk+pFcee
KvcslmU3UTaelMH9zTnTQE81mCn3Z5dIzFEpzoxjzLXyrkDNMf+kbdfRu/V/q/cnY+MotrPxUusF
1/fLrZQ+Il6KHeW//ywlps+5rWLbx+pnAgTKBFKvd9d6mffn7FT3lF6japRyTz27j6bE7dhygZSa
fXqLrl1ODOWZ/91CaS4tY38S6108R23cnfNtfXR+SS1S+r7rJze2yBiOYsyN66itJ5/VzudJDGfH
tLY4i6O3z1NqxrC36t3HYxPl3ujwiFkGe8oFvkHMkvdhUSt+mOLMuGIhNN1MoMaYT2nTfNWs1F11
lDpGPsGfzbs1X3JtfUe96KpRhKe595xDDRdtEiBAoFTg6fya2k/kfJx6Pz27j6bm4Ph8gdSafXqK
rl1uHPmZ/31mRB4tYo+I88oqJYfIWFL6vYp/+y43rsgYzmLMje2svf3nLXLY91nyc22PktjeOjel
hvzeqlJ+v0tvomxsKQN8zzzDgE/Jf4Z89zVs9TPnVtL66UUgasyntHOUu3nrSGXuz3LHzNFYqfWi
a1+ByBdf+7b9TIAAAQL9CNS4r9S4h6TeS4/uof2ozx9Jar0+IjXqlhtLSZWi8qgde1ScV1apOUTF
lNrvWQ658UT1fxZXzWvm03arHO5yTPk+t14pfYx2bEod+Y1W3b/++td4IfcTccrF0U/U+ZGslm++
lDMJECgR2Oaaz38l7TiXwCgCNV6qjZK7OAkQILCKQI25vsYGyir1eCvP73Vuyf//Vvw99bu9gBzl
JeQocabWt/SZ7VPDklrO8J6qVg4RvqljwvEEZhZY/jdRtuKWTlgj3xBTcx851zcv5BTnWsZPYqjV
95v2+n5H4Ml4axGZMd1Cub8+csff0Xip8dLrTMzLsDMZnxMgQGB8gaj7SYt7Rep99Oj+OX7F4jNI
db2LYHMvabNG3Uriucv3832NuD9t14i/Zrx7s9T4S2JL7Wsfa0nfNeu1j/P754iY9+2XOu7b+/z8
JNbSvp/0cRbfrJ+nmPIbbxTYRPlds5RBflTikQd+Tu6j5HuVW+scrmLZj6kasb3d/z5HP88vkDLm
amrUuJ5qxqvtGIHc8Xc2XqJefD3NrsULsqexOI4AAQIEygVK7yOt7wup99Gz+2e53DwtpJrWzrxW
zWrnWSvuj3d0/LXj3Y+T1Phz40vtZx9nbr/f7ZTGsI/pyc8Rce/7ic4jJ8bcGHL62uc/288plvzG
q76/zut3zUoHbspFMt4Q+TPiLd+ec34SX8/x/yle9klqrqnHl0X332d/apf6v5ExaIsAgfEFcu/r
Z/Nf65dXpS/bxq+gDAgQIEDgI9D6HkSeQIlA6hrs6fHbcU+PLYk/8tzR4o3MvXZbZ2v22v1Gtx+d
R+6Yyz0v2kN7BHoXsInyT4VKJ43oya/3gbPF12POKTGlHDtCPUaPsaQe27mf/0Z3ED8BAn0KbC+x
Wr7IspHS5zgQFQECBFoKtLzv5OZV+hyd26/z8gV6q9ldPHff50v8eWbLvv7svf0nOc/QJc/tW4al
xqX95yqXxr3vNzqP0vi280vb2OfoZwKzCfjrvHYVLZ3IRpt0SvPd+HrIOTePVrGnxBcdU0rfn8sh
Ooa7iTMnxqs2W8d/Fcuq30XXNNfRWMiVm+O8nHGYO2ZqbXqM8AJtjtEiCwIECNQTyLlHvDn/p9w/
c++b9bT7bDnFtGYGLeqVmmuLmFJMU+M/avvNnHLjfxJzbtvfRk/6OTL9fBYRw1X7Z9+Vxv3dbnQO
kbFtcT6JL7rPM/fRPn9i98mJ4WjV/esvv4myq1npIN4umJSL5u0hU5rvZ4Jtnfenv9b9vl2vGfuv
cb3UaHNG++icvq/L6LZz2ouY33L6dc6aArVeduW8eFuzArImQIDAPAK17inzCMmEAIFogatn6NXf
u/T8XFkjtrs2776PHpvaI9CLgE2Ug0pETAhXN6CDLqf5qNbN9fvl7Kq20wySr0Rq1rJm2zPW4mlO
+2vx++enbbQ4LmIebxGnPuoKtB4Htf7KLxspdceJ1gkQIECAwAoCrddFK5iukGPkc3XpGIyM5Wnt
SmN+2k/OcTVj29o++y8nVucQmEHAX+d1UsWoybnmpHYSetbHUfnedZ7jUTO2nHjucjz6PiWH6JhS
+v7EHh3Dkcn2WU5sZ22dfd4ql7P+R/68RX0ifdQ6UnOetlLHceQ4qrn54U8pzzNGZUKAwPwCKfeD
Hub3lHtn5H1z5pGQYlrDoWWdUnNtGdtT29Qc9u2+mVNk7KVtfbuUmkTGsq/X1c+lcR+1XZpLjZiO
4vRZukBKbdUx3fftM/wmykkFogZzygV0EkqTj6PyvQt280gxSTn2rm/frylgDKXXPfU6Te8h9oxt
/mo1h8VGrrUWAm+OjVq/mbK5pbyQa+GsDwIECBCYQ8DauU4d31yPvNl3Hc36rTKL/QOPo3r2FPfn
mbenmOpfiXog0JeA30S5qUfUInKUiS4q3xvWbr5uVZcU1+iYUvr+FCY6hrOC58R21tbV563yuYph
lO9a1aTUQ01LBdc6P2Vc1xxbNTY+evgTy2uNJtkSIEAgT+DJPaCHOT3lnrlJ1Lxv5kn3fVaqb2k2
b9QnNcc3YnzimprHp80e8smN/fuaLmnj2zfKIyqeJ7X/dnh6fMpxOblEOabE6dh0gZTaqmm679tn
2ER5UIGUi+CquVEukKh8ryx6+K5lPVJMo+NK6ftTl+gYjuqdE9dRO08+a5HPkzhKcm6RQ0l8T/Iv
PaaFQWmMzu9TIGVs1x5nT16ipSr28NItNWbHEyBAYEWBq3tAL3N5yj1zq2Ht++aK4+STc2ot9lZv
1iY19jdj3buV+veQS6r/t8EWf8n5n7aiHSJiOqv1/vPo2Pft5+RSO6Z9jH7OE0iprZrmGb95lk2U
h/opF8JZkyNdIBH5njn08HnrWqR4RseW0vdWm+j+j+qdGtNRG6mftcjrKqaInGvnEBHjlcHT72rn
+TQOx80jkDq2a4/Bq5doueq9vHzLjd95BAgQINCHQG/3zD5U3ositR6fSGuvZe5EUuOuEe9VDE/6
uzr/Kv8nbV+dH/VdbvwR/dcwaJVPjdj3pjm5tIhrH6ef0wRS66qmab49HO3fRHlYhYjBnXpBPQyt
ymER+VYJLKDRmXML4KnexEjXQRRGVM5R7UTlFd3Odm26PqNVtdejgA2PHqsiJgIECBAg0J/AZ338
dI1sPf13De+em+6+31p5at7fqPk7otHjb+3q2mktrj8C4wnYREmo2Wo3oRnznTGnhCE89KGltXuy
UE4F2to8+y+1rafH18jjad+1jrNgrSWr3Z4FbKT0XB2xESBAgACB/gQ+a+ar/+0v6mcRRT7jPG3r
yXGlz6DPsq931BvPWSOZfV9L9aqgZQIEZhGwiZJYyZFuCImpHR4+U74z5XJYrAE+fLJQvUrjjUXg
WTx3uXy+vzvurP2rz2u0edWf7wgQqCNgI6WOq1YJECBAoI2A56s2znqpJ+C5KtZ2lDmhp/cKsRXQ
GgECNQVsomToltwYRrxJl+SbwRt6yufmOHIOoSCTNPZ2PZ9ex0+Pm6Qs2WlwyqZz4gQCNlImKKIU
CBAgQIAAgWKB0meC7fzSNoqTWLiBt5/Rr+i/3wv1HOdVDr4jQOB9AZsomTX4TMI5p494Yx/lpjNK
nDnjpsU5NRcUJeO+ZlwtXGv0UeJZIx5tEiCQL2AjJd/OmQQIECBAgAABz0bvjoFen9dL3tu9K6p3
AgR6FLCJ8lJVRr/J93Qz+t44eamc03Tb47jsdUHWQ9F7qpcNzB5GhBjOBFLnkTeuLRspZ9XzOQEC
BAgQILCKwNM12Hbc93+r+PSYZ+o6u0UOPb2vapGvPsYT6PG6GU+xfcQ/fhfuV/tu5+rx6Y1+n/XM
9Lkme6O7n0cxTPGIziml7807uv9PDVPjuIolp62r9u7G2f773P737UT9HFmzJ7k96e9JO9/5P2kz
yks7awqMOCb/7//8z6Ni2YB5xOQgAgQIEHggkHK/tH57ALrwISljac90NrZK2tz38fn5rK/P9yl9
3rV1FkOLz1PyeBpPy3xT4m8Z11Or7+NScnk6TnPicE6sQEpdex+jsTLztGYTJaCWKRfKvrvZL5wS
m73V98+juaU4ROeW0vdmHN3/p26pcZzFktPOJ4ao3EpiuBrXJd9F5bbFcJXf036u2jjL82nbZ+f7
nMCVQOqY7Gk8Xm2m2EC5qrrvCBAgQCBVIOV+2dO9MjVPx7cRSBlP+4i+x1dJO/t29z8/GcdP+n/S
zr7vlj8/ySElntb5psTfIra7eK5iuDv3qA5X7R0d77P2Ail1Vc/29Yno0SZKgGLKhbLvzoWzF5nz
55QxEj0mUvre9KP7/1Q0Io7UNvajKSq30jj2cUX9HJVfRDw5Rj3FH2Ggjb4EUsek8dhX/URDgAAB
Am0EUu6X7pVtajJyLynj6a08n47jq1yetvFWjlu/V/GnxvVGvinx147vaSxXcTxt41Obq7ZS6+f4
OgIpNVXPOjWo3erP2h2s0P42+FMulm+T7TwXzwqjRI6lArnX2Kff3q+zknnkk+PHqIdcI/IpHTPO
J0CAAAECBAgQIECAQIRAD89YEXmUtDGKQc33bCnvJWrGUVJH5xIgkCfgH5bPc/vjrJKbScok/EfH
PiAwocD39bRdH71dIyXX+1W5otrtzesqZ98RIECAAAECBAiMKWDNOWbdWkYd9XxTK+be46uVd067
rHLUnEOAwEwCNlECq+mmEoipqaUFPhsnUQ9mK16bUXZLD0TJTyWQOg+4hqYqv2QIECBAgACBlwRS
12Ctwuw1rlr5l+Rbcm6tfO7atZa/E/I9AQKpAjZRUsUqHW+CrwSr2eX/urhaC77Idr/bimzXvGIC
IECAAAECBAgQIEDgbYHIZ5yIXHqLJyKnJ22slnfk8/DnD3o+cXYMAQJzCthECa5ryU0pcoIPTktz
BAg0FCiZRxqGedvVLHncJuoAAgQIECBAgMCiAp5hFy38oGlvzyerP6OkGozu9dn8KJmrSs4d9FIR
NgECBwI2UQ5QfESAwBwCIy/4omK34JtjLMuCAAECBAgQIECAwMgCUc83qQafTYO3+k+Nt9XxTzZT
ZjNLfTb22yetRqN+CIwh8HOMMMeKcrvRpE7Onwy382a7UY1VPdHOIjDDdfTJIXc+Ga2W5r/RKiZe
AgQIECBAgMBf//vsO8PaWy3rC5S8K8mJzri8VxvFKGrsnM1Xqzxz348IRxAgcCbgN1HOZAo/L7kR
mbwL8Z2+vEDJ9ZeCN1s/Kbk7lsAKAu7HK1RZjgQIECDwLdBqfUt9XYFtjNUaZ5+2a/axbuXmyfyz
xt/+9/PfPNnJ5A0Bz41vqLfv0yZKe3M9EiBQUaDWgrxWyE/jfXpcrTi1S2AGAdfRDFWUAwECBAj0
KOAFUo9V6TumyHWZTZO+a91jdG/PWSnjP+XYHq3FRGAWAZsoFStZMtG9PaFXZNE0gWoCJddcblAl
faaem3p8bk5vnmfue1Nf3wQIECBAgACBfAHruHy7Vc8sfb7Zzi9tY1X7EfMerdZ38d59v9XoyTEj
1lLMBEYU8G+iVK7aNuHlLia380yYlQuk+WkEVrlWSuaUaYotEQIECBAgQIAAgWoCJetNz7DVyjJt
w0fPcXfvUI7OmRZIYv8lUDI/taR8OkafHtcydn2lCdzNV2mtObpnAZsoPVfnd2wWoZ0XSHhdCLy9
8MhZyJXEnNqfeaSLYSoIAgQIECBAgAABAgQeCJQ8Kz1o3iGDC6Q+D7dO1/htLa4/Am0E/HVeDZxL
J1C7mg2KpIvhBLbr6vPfcMEvFHDp/LcQlVQJECBAgAABAt0IlKzhPL92U0aBEJhWoGSOqoXi/UQt
2X7bdb/rtzY1IvObKDVUD9rcJtOSi8ufJD9A9dFjgafjr8eFyFGSJXE+uQ5L2j+Kd/9Z7fb3/W0/
m0OOVHy2osDT+XBFGzkTIECAAIEoAWvPKEntECBwJvB5rn7yjH/WRtTnbzzjR8WunTyB3HFnrOR5
93CW30TpoQoPY8i9QB8277DJBe4m6rvvS3ki28+9Fp6e9/S4b5On+T09rtT76PycvI7a8RkBAgQI
ECBAgMD8AqXrVmvP+ceIDAn0IFA6V5XksPX9Zv8lsTuXAIE0gR+/L/Zfaac4ukSgdCGpXCX67577
pPYr1PeJQ26lzvxy+zxr7yq+q75y2jvr66qfs3M+n0fGcdfX9n1qrK3je5KDY+YSMCbnqqdsCBAg
QKCuQOp9cx+Ntd1exM8ECNQSKJ2vUuIyt6VozXds7lgzbsYdCzZRXqhd7oX2CdUF90LRgrq8qv1K
db1yCKL+958GKemr55qU5LUZt8wtNdaWsUWNN+2MJWBMjlUv0RIgQIDA+wKp9859xNZ3exE/EyBQ
S6B0vrqLy3x2JzT/97ljzNgZe2z4N1FeqN920eRecC+Eq8tAARPm35gtroHZr7FSw83HeAy8uDVF
gAABAgQIECBwKvBZm1t/nhL5ggCBIIHSZ+XvMMxZQUXRDIEJBPybKC8VsWQinv3l8Esl0W1jgZJr
oHGouiNAgAABAgQIECCwtEDU2t2z7NLDSPIEmglsc1bOvPU5L/f8ZgnqaDiBnPE4XJKTB+w3UV4s
8HYB5S4i/SnyFwun6zCBkmsgLIiBG+I3cPGEToAAAQIECBAYTCBq7elZdrDCC5fAwAJeXA9cvIlC
Nw7nKKbfRHm5ji6klwug+9cFtmvAdfB6GQRAgAABAgQIECBA4FYgat2+baTk/oHC2yAdQIAAAQIE
Kgm4d1WCHaBZmygDFOksRAvPMxmfjygQ9UA2Yu4lMc/mNls+JbV1bj0B46yerZYJECBAYH6ByPvo
55nWS6n5x40MCRAgMLqAe9XoFSyL3yZKmV/I2aWLUBdxSBk00oFA6bUQmUJPsdzl1XusT+N7etyd
h+8JECBAgAABAgTqCtRYt9lQqVszrRMgQIBAvkDuu9ca98v8LJxZImATpUSvo3P9VkpHxRBKkUAP
N5geYkhF3GLuOe672O6+T/VwPAECBAgQIECAQF2Bmus3z7d1a6d1AgQIEHgukLuB8rwHR44g8OP3
wufXCIGuEGPURamkK4yW+XOMuh5SpGa5dp7YzZJrSn0dS+Bb4Ml18jne9WLsECBAgACBc4GUe+p5
K/ffuB/fGzmCAAECBGIFSu9x7l2x9XizNb+J8qb+ru+oC6v0Au+IRCgLC2zXQ9Q18YSxZV9P4ik5
5i6Xu+9L+nYuAQIECBAgQIDAWgKt1pbbc+7nv7WEZUuAAAECBAi8LfDz7QD0X0dgW1y2WszWyUCr
BP4WOBrHURuFR23P4j5zbrPUSB4ECBAgQIAAgVkEtrVn1Br9icmnL2veJ1qOIUCAAIE3BNyj3lCv
16e/zquebXbL0YtPF212KZw4gEDu9eK6GKC4QiRQUSBl7jBfVCyEpgkQIEBgKoGU+2t04u7X0aLa
I0CAAIHc+5p70nxjxyZKpzXNvUiv0nEBX+n4bnSBp9eM62D0SoufQIzA0zlj6828EWOuFQIECBBY
RyDlPltDxb27hqo2CRAgsJ5Azv3MPWjOcWITpeO65lyoT9NxQT+VchwBAgQIzCaQen91z5xtBMiH
AAECBFoIpN5vo2Ny/44W1R4BAgTWEsi5j7n3zDtG/MPyHde25oW3TQSf/zomEBoBAgQIECBAgAAB
AgQIDChQ83n2CYfn3SdKjiFAgACBKIG373tReWjnWMAmyrFLN5+2uABtqHRTboEQIECAAAECBAgQ
IEBgGoHtebbFM+0VWM6fJL5qz3cECBAgQIDAegI/10t5vIw/i84Wi7/vPt5e7I5XKRETIECAAAEC
BAgQIECAwF7g+9myxXPtvv+7Pj377sX8TIAAAQIECHwL2EQZaNGEoz8AACAASURBVDxsC7u7xV9k
OjZUIjW1RYAAAQIECBAgQIAAAQJvb6gcVeDz7Gsz5UjHZwQIECBAgIC/zmuwMbAt6t5Y2G2LypYb
OIOVRbgECBAgQIAAAQIECBAgkCjw1vPtWZieec9kfE6AAIG1BNwP1qr3k2x//F60/HpyoGP6E3j7
gjZ0+hsTIiJAgACBe4GU+6d73b2nIwgQIECAQKRAyn06st99W9YAexE/EyBAYA2BnPuQe8b8Y8Nv
ogxc47cv0JxJZWBuoRMgQIAAAQIECBAgQIBAZYHPb6f08LzrmbdysTVPgACBzgTM+50VpKNwbKJ0
VIycUHpYWObE7RwCBAgQIPCGgEXxG+r6JECAAAECeQKfDZW8s2PO2tYO1g8xllohQIBAzwLm+p6r
835sNlHer0FxBG8vLE0yxSXUAAECBAgQIECAAAECBAicCPTw2yk2U06K42MCBAgQILCAgE2UiYr8
5maKjZSJBpJUCBAgQIAAAQIECBAg0KnA2xsqnn07HRjCIkCAAAECFQX8w/IVcXto+o0F3tt/xVgP
7mIgQIAAgf4Ecu6J7mn91VFEBAgQIEDgWyDn/h4laJ0QJakdAgQIvCtQci9xL3i3dq16/9mqI/28
I/B9IZdMCCnRH/VjQkkRdCwBAgQIECBAgAABAgQIPBH4PGsePYc+Ob/kmE+fnndLFJ1LgACBcQXM
/+PWLjVyf51XqtjAx28X9ue/1mm8saBtnaP+CBAgQIAAAQIECBAgQOAdgTdfZG3Pu55536m7XgkQ
IPCWwJv3nbdyXrlff53XytX/J/fWiz2TjEFHgAABAm8IpN7v3K/eqJI+CRAgQIBAPYHUtUBuJNYQ
uXLOI0CAQHuBnHuDeb59nd7u0V/n9XYFOuj/+8LPmThSU/juw6STqud4AgQIEMgRaHF/y4nLOQQI
ECBAgEA7gc/zZ+11wad9z7vtaqsnAgQIECBQU8AmSk3dAdtutaj80BwtXi00Bxw4QiZAgAABAgQI
ECBAgMAgAtsz59GzaHT4Wx+eb6NVtUeAAIE4gRb3grhotfSmgL/O6039QfruYUKx8BxksAiTAAEC
nQqk3svcdzotpLAIECBAgECwQOoaIbd7a4tcOecRIECgnkDOPcB8Xq8ePbfsN1F6rk4nsbX6UzpX
6R5NaiatKzHfESBAgMBH4OgeQocAAQIECBAgsAl8nitrrxe+2/csa+wRIECAAIGxBP41VriifUug
x0Ve7UXuW9b6JUCAAAECBAgQIECAAIG2Atszb6vn3u1Z9vNf2yz1RoAAAQIfAe8VjYUUAZsoKVqL
H9tqQZnCbOGZouVYAgQIECBAgAABAgQIELgSaLmZssXhmfaqGr4jQIBAXwI9vhvtS2jeaGyizFvb
Kpn1OlnYPa5Sbo0SIEBgeIGc+0Ov97rhiyEBAgQIECAwkEDr9YDNlIEGh1AJEBheIOc5cfikJVAk
4N9EKeJb8+TPYrK3CecuntaL4DVHh6wJECBAgAABAgQIECAwh8Abz77751rPsXOMJVkQIDC+gPl4
/BqWZGATpURv8XOPJo/9gq8norPYjvLoKW6xECBAgAABAgQIECBAgMB7Am9spnyy/TzHem59r/56
JkBgHoGzd4PzZCiTWgI/ft+If9VqXLtrCswwIbks1hy7siZAYC6BnPuR+X+uMSAbAgQIECBQQyBn
jREVh7VKlKR2CBBYRSBqzjb/rjJijvO0iXLs4tMAgahJKiCU0CZMmqGcGiNAgEA1gZz7kDm+Wjk0
TIAAAQIEphPIWWtEIVizRElqhwCBGQWi52dz7oyjJC0nmyhpXo7OFIievDLDqHaaybQarYYJECCQ
JZB73zGfZ3E7iQABAgQILC2Qu+6IQLN2iVDUBgECowvUnofNtaOPkPL4baKUG2ohU6D2BJcZVthp
JtgwSg0RIEAgSSD3/mLeTmJ2MAECBAgQIPAlkLv+iEK0jomS1A4BAqMItJp3za+jjIi6cfqH5ev6
av1C4GgSajUBXoQV9tVZLkd5h3WqIQIECBAgQIAAAQIECBBoLvB5zjt7Dqwd0He/njlra2ufAIE3
BN6aX9/IVZ/9CfhNlP5qIqKdwAqTpEWuYU+AAIEYgZJ7hrk4pgZaIUCAAAECBP4WKFmXRBla30RJ
aocAgZYCPcyfW77m0JZV77svmyh910d0/wj0Mnm2LojJurW4/ggQGFmg5F5hvh258mInQIAAAQL9
C5SsU6Kys96JktQOAQKlAj3MiXc5mDPvhNb63ibKWvUePtsRJtmWyCb0ltr6IkCgd4GSe4T5tPfq
io8AAQIECMwhULJeiRKw7omS1A4BAk8Eepj3nsT5fYx5MlVs/uNtosxf4+kyHHHyfbsIJv+3K6B/
AgRqC5TcG8yRtaujfQIECBAgQGAvULJ22beV+7M1UK6c8wgQuBLoYX67iu/uO3PjndCa39tEWbPu
U2c9+mTdU3HcOHqqhlgIEDgTKJn3zXNnqj4nQIAAAQIEWgqUrGci4rQmilDUBoH1BN6eu6LFzYXR
ovO0ZxNlnlrK5EZgton9Jt3mX7vRNCfXIQEC/wiUzO/mLsOIAAECBAgQ6EmgZF0TmYc1UqSmtgjM
I9DLHBUtas6LFp2vPZso89VURgkCs07+CQTVDnUDqkarYQIEvgRK5nHzlKFEgAABAgQI9CpQssaJ
yslaKUpSOwTGFehhLqqlZ46rJTtnuzZR5qyrrAIEZr5RBPBkNeEGlcXmJAIEdgIR87P5yLAiQIAA
AQIERhCIWPeU5mndVCrofALjCPQw59TUMp/V1J27bZsoc9dXdsECs99Mgrkum3PjuuTxJQECO4Ho
+dccZIgRIECAAAECIwlEr4Vyc7eGypVzHoF+BXqZX2oImbNqqK7Zpk2UNesu60CBmW82gUy3Tbmx
3RI5gMCSAjXmWPPNkkNJ0gQIECBAYAqBGmujHBjrqRw15xB4T6CXuaOFgPmphfJ6fdhEWa/mMm4k
sNINqhHpZTdukpc8viQwlEDN+dNcMdRQECwBAgQIECBwIVBzzXTRbchX1mQhjBohcCsw8jxxm9w/
B5hPnko5rkTAJkqJnnMJJAqscPNKJHn1cDfaV/l1TuAPgRZzpOv+D3YfECBAgAABAhMItFhHRTNZ
l0WLao/AfwRGnBOe1M+88UTJMTUEbKLUUNUmgUSBWW9uiQzdH+5m3X2JBNixQA/znGu44wEiNAIE
CBAgQCBMoId119NkrM+eSjmOwHOBkeaAfVbmhL2In3sRsInSSyXEQeBCYOQb4EVa033lZj9dSSUU
INDT/OUaDSioJggQIECAAIFhBHpah0Whjbaee1KD0XKKqOUTl+9+ooxS+03JNSrGlD6Pjq2Z41F/
JZ/1YlaSg3PXEbCJsk6tZbqAwEg3ywXK8UeKNRYINWpeI84/MHwwtUCNcVkKZlyXCjqfAAECBAgQ
GFWgx7XZqJbiJhAlkPJ8Mss1nJJzlLN2CEQJ2ESJktQOgYEFZrkhD1yCrkO30Om6PF0F1+tcYgx3
NUwEQ4AAAQIECLwo0Ot67UUSXRMgUEHAM1gFVE2+KmAT5VV+nRMYT8Cie7yaRUc8ymLoyVjd55Jz
TrTviO09cXsrr32N34pDvwQIECBAgACBHgV6Xsf16CUmAgSOBTx3Hbv4dB4Bmyjz1FImBF4RsOh+
hV2nBAjcCFjE3wD5mgABAgQIECDwj4BnOkOBAIEUAc9aKVqOnUXAJsoslZQHgY4ELMI7KoZQCCwk
YDG/ULGlSoAAAQIECIQLeI4LJ9UggWkEPGtNU0qJZArYRMmEcxoBAs8ELMSfOTmKAIE8AYv5PDdn
ESBAgAABAgSuBDzHXen4jsAaAp611qizLJ8J2ER55uQoAgSCBCzGgyA1Q2BxAQv6xQeA9AkQIECA
AIEmAp7fmjDrhMBrAp6rXqPX8WACNlEGK5hwCawuYBG/+giQ/8oCFvgrV1/uBAgQIECAwIgCnt9G
rJqYVxDwbLVCleUYKWATJVJTWwQIdClg4d5lWQRF4LGABf5jKgcSIECAAAECBLoT8DzWXUkEtLCA
Z6uFiy/1IgGbKEV8TiZAYEYBi/wZqyqnXgUs4nutjLgIECBAgAABAnECnrHiLLVEIFfAs1eunPMI
/PWXTRSjgAABAokCHgASwRxO4EDAAv4AxUcECBAgQIAAAQL/K+CZy0BoKZDybDLq2EzJsaW9vgiM
ImATZZRKiZMAgWEEel9UfRZPvcc5TMEF+ljAwv0xlQMJECBAgAABAgQIEJhAoOZzt+erCQaIFIYR
sIkyTKkESoAAgboCNRd3dSPXeu8CFve9V0h8BAgQIECAAAECBAgQIECAwJnAz7MvfE6AAAECawns
X3TbVFmr/jWy3Y+pGn1okwABAgQIECBAgAABAgQIECBQU8AmSk1dbRMgQGBgAS/ABy6e0AkQIECA
AAECBAgQIECAAAECBEIE/hXSikYIECBAgAABAgQIECBAgAABAgQIECBAgAABApMJ2ESZrKDSIUCA
AAECBAgQIECAAAECBAgQIECAAAECBGIEbKLEOGqFAAECBAgQIECAAAECBAgQIECAAAECBAgQmEzA
JspkBZUOAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECNgEyXGUSsECBAgQIAAAQIECBAgQIAAAQIE
CBAgQIDAZAI2USYrqHQIECBAgAABAgQIECBAgAABAgQIECBAgACBGAGbKDGOWiFAgAABAgQIECBA
gAABAgQIECBAgAABAgQmE7CJMllBpUOAAAECBAgQIECAAAECBAgQIECAAAECBAjECNhEiXHUCgEC
BAgQIECAAAECBAgQIECAAAECBAgQIDCZgE2UyQoqHQIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBG
wCZKjKNWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgckEbKJMVlDpECBAgAABAgQIECBAgAABAgQI
ECBAgAABAjECNlFiHLVCgAABAgQIECBAgAABAgQIECBAgAABAgQITCZgE2WygkqHAAECBAgQIECA
AAECBAgQIECAAAECBAgQiBGwiRLjqBUCBAgQIECAAAECBAgQIECAAAECBAgQIEBgMgGbKJMVVDoE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAjIBNlBhHrRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQKT
CdhEmayg0iFAgAABAgQIECBAgAABAgQIECBAgAABAgRiBGyixDhqhQABAgQIECBAgAABAgQIECBA
gAABAgQIEJhM4Odk+UiHAAECBAgQIECAAAECBAgQIFAs8OPHj9s2fv36dXuMAwgQIECAAIGxBWyi
jF0/0RMgQIAAAQIECBAgQIAAAQLBAk82ULYur46zwRJcFM0RIECAAIGXBGyivASvWwIECBAgQIAA
AQIECBAgQKA/gauNkZRov9vJ3VB5Ektu2ym5OJYAAQIECKwsYBNl5erLnQABAgQIECBAgAABAgQI
EKgucLYZst8AOTvuKsDtnH07V8f7jgABAgQIEEgTsImS5uVoAgQIECBAgAABAgQIECBAgECIQM6m
yVHHNlKOVHxGgAABAgRiBP4V04xWCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCdhEmauesiFA
gAABAgQIECBAgAABAgQIECBAgAABAgSCBGyiBEFqhgABAgQIECBAgAABAgQIECBAgAABAgQIEJhL
wCbKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYBMlCFIzBAgQIECAAAECBAgQIECAwPgC
v379Gj8JGRAgQIAAAQJhAjZRwig1RIAAAQIECBAgQIAAAQIECMwgYCNlhirKgQABAgQIxAj8jGlG
KwQIECBAgAABAgQIECBAgACBeQS+N1J+/PgxT2IyIUCAAAECBJIEbKIkcTmYAAECBAgQIECAAAEC
BAgQWE3g6jdTbLCsNhrkS4AAAQKrCdhEWa3i8iVAgAABAgQIECBAgAABAgTCBPzGShilhggQIECA
QJcCNlG6LIugCBAgQIAAAQIECBAgQIAAgdEEbKiMVjHxEiBAgACBewGbKPdGjiBAgAABAkMLXP0V
E1d/NcXQSQcGf+W3dcMwEFtTBAgQIEBgEoG79cNRmjZgjlR8RoAAAQIE3hf41/shiIAAAQIECBCo
JXD3AH/3fa24Rmh3s3ni8+SYEfIVIwECBAgQIBAj8MbawB/qiKmdVggQIECAwJGA30Q5UvEZAQIE
CBCYQODpA/zT445Ien9gL8ntKN+zz7Z+erc4i93nBAgQIECAQIxAq3VHTLRaIUCAAAECBJ4K2ER5
KuU4AgQIECBA4A8BLwv+IPEBAQIECBAgsKCANdGCRZcyAQIECCwj4K/zWqbUEiVAgAABAgQIECBA
gAABAgSiBSI2UPx7KNFV0R4BAgQIEIgTsIkSZ6klAgQIECBAgAABAgQIECBAgEBTAX+laFNunREg
QIDAggI2URYsupQJECBAgAABAgQIECBAgACBPgRsgvRRB1EQIECAAIEzAZsoZzI+J0CAAAECBAgQ
IECAAAECBAhcCJT+VV42UC5wfUWAAAECBDoRsInSSSGEQYAAAQIECBAgQIAAAQIECIwjYANlnFqJ
lAABAgQIlAjYRCnRcy4BAgQIECBA4LeAP0VqGBAgQIAAgbUESjdQ1tKSLQECBAgQGFvAJsrY9RM9
AQIECBAg8LKADZSXC6B7AgQIECDQWCBiA+Vs/ZDa9lk7jUl0R4AAAQIEphawiTJ1eSVHgAABAgQI
1BTw4qKmrrYJECBAgEB/AqmbHEcZnK0fIto+6s9nBAgQIECAQJnAz7LTnU2AAAECBAgQWEvg7MXH
WgqyJUCAAAEC6wlEbHKcrSMi2l6vIjImQIAAAQJtBGyitHHWCwECBAgQINCRwNkLjI5CFAoBAgQI
ECDQkUDEJof1R0cFFQoBAgQIEEgQsImSgOVQAgQIECAwq8D2UB/xcuDMx0uDMxmfEyBAgAABAr0L
RKyRrIV6r7L4CBAgQIDAuYB/E+XcxjcECBAgQGApgZoP99vLh4gXEEsVRLIECBAgQIDA6wIR65ea
a6zXgQRAgAABAgQWELCJskCRpUiAAAECBHoRiHgR0Usu4iBAgAABAgTmFYj6AyA1N1Bqtj1vZWVG
gAABAgTSBWyipJs5gwABAgQITCvQ4mHcRsq0w0diBAgQIEBgCoGotUrNdVXNtqcooiQIECBAgECg
gE2UQExNESBAgACBGQRaPJRHvZyYwVsOBAgQIECAQD8CUWuUmuupmm33UwmRECBAgACBfgRsovRT
C5EQIECAAIFuBLaH89oP6FEvKbpBEwgBAgQIECAwtEDU2qT2GmpoZMETIECAAIEBBWyiDFg0IRMg
QIAAgVYCtV8CRL2saOWhHwIECBAgQGBOAWuSOesqKwIECBAgECFgEyVCURsECBAgQGBigdq/leKl
xcSDR2oECBAgQGAAgci1SO0/gDIApxAJECBAgMB0AjZRpiuphAgQIECAQB2Bz2ZKjZcDkS8v6mSv
VQIECBAgQGBGgcg1SI010ozmciJAgAABAqMJ2EQZrWLiJUCAAAECHQjU+O2UyJcYHRAJgQABAgQI
EOhcIHLtYQOl82ILjwABAgQIFAjYRCnAcyoBAgQIEFhdIHozJfJlxuq1kT8BAgQIECDQRsAGShtn
vRAgQIAAgbcEbKK8Ja9fAgQIECAwkUDkZoqNlIkGhlQIECBAgECnAlHrDRsonRZYWAQIECBAIFDA
JkogpqYIECBAgMDqAlGbKVEvNlavh/wJECBAgACBPwWi1hk2UP609QkBAgQIEJhRwCbKjFWVEwEC
BAgQeFkg4qVC1AuOlyl0T4AAAQIECEwmEPWHRiZjkQ4BAgQIEJhWwCbKtKWVGAECBAgQeFcgYiPl
3Qz0ToAAAQIECMwmUPqHNKxvZhsR8iFAgAABAvcCNlHujRxBgAABAgQIZAqUvmgofdGRGbbTCBAg
QIAAgQkFStcVpeuaM9LSuM7a9TkBAgQIECAQI2ATJcZRKwQIECBAgMCJQK0XDifd+ZgAAQIECBAg
8IdA6UZFrfVMaVx/JOoDAgQIECBAIFzAJko4qQYJECBAgACBvUDJiwcvF/aafiZAgAABAgRSBErX
EiXrmKs4S+O6att3BAgQIECAQJyATZQ4Sy0RIECAAAECFwK1XkBcdOkrAgQIECBAYHGB0o0K65fF
B5D0CRAgQIDAbwGbKIYBAQIECBAg0Ewg90VE6QuQZgnqiAABAgQIEOhGwPqhm1IIhAABAgQIDC1g
E2Xo8gmeAAECBAisI+BFyDq1likBAgQIECgViFg35P7hj9LYnU+AAAECBAj0JWATpa96iIYAAQIE
CEwv4IXE9CWWIAECBAgQGF7AemX4EkqAAAECBAiECdhECaPUEAECBAgQIFBbIOJPldaOUfsECBAg
QIDAuwKl6wUbKO/WT+8ECBAgQKA3AZsovVVEPAQIECBAYAGBkpcTpS9GFuCVIgECBAgQIJApULJG
yezSaQQIECBAgEDnAjZROi+Q8AgQIECAAIE/BWyk/GniEwIECBAgQOCvv0ZaI+Rs2OScY1wQIECA
AAECZQI2Ucr8nE2AAAECBLoUGOEFgpcAXQ4dQREgQIAAgWEFStc/b6xNUvpMOXbYIgqcAAECBAh0
KPCzw5iERIAAAQIECCwisL0MyH3h8TnPC4VFBos0CRAgQIDAhUDueuLT5JvriTf7viD1FQECBAgQ
IPCPgN9EMRQIECBAgACB7I2MHuhKX5r0kIMYCBAgQIAAgXyB0rWATYx8e2cSIECAAIEVBGyirFBl
ORIgQIAAgQcCpS8gHnRxeEjEi4u3Yj9MyIcECBAgQIBAM4HSNUDEOqRZsjoiQIAAAQIEXhGwifIK
u04JECBAgACBb4GIFxilL1FUhAABAgQIEBhLwL1/rHqJlgABAgQIjCpgE2XUyombAAECBAhMJmAj
ZbKCSocAAQIECFQUiNhAiVh7VExR0wQIECBAgEAnAjZROimEMAgQIECAAIEYgYiXKjGRaIUAAQIE
CBAgQIAAAQIECBAYXcAmyugVFD8BAgQIEJhIIOpPhNpImWhQSIUAAQIECOwEIu7zUWsOxSFAgAAB
AgTmF7CJMn+NZUiAAAECCwqM/GJg5NgXHGpSJkCAAAECTQVsoDTl1hkBAgQIECDwW8AmimFAgAAB
AgQmFRh5MyIi9oiXLJMODWkRIECAAIEhBSLu7RFrjCHxBE2AAAECBAhkC9hEyaZzIgECBAgQIFBT
IOIlR8TLlpo5apsAAQIECBB4JhBxT49YWzyL1lEECBAgQIDATAI2UWaqplwIECBAgMBOYPSXBRHx
R7x0MbAIECBAgACB9wQi7uURa4r3BPRMgAABAgQIvClgE+VNfX0TIECAAIEGAk9fGjw9rkHI/9XF
FlevsbW20B8BAgQIEFhNwAbKahWXLwECBAgQ6E/AJkp/NRERAQIECBAIF7jbhLj7PjygjAZLYox4
AZMRslMIECBAgACBlwVK1g8vh657AgQIECBAoBOBn53EIQwCBAgQIECgssDqLxG2jZTVDSoPMc0T
IECAAIGuBNz3uyqHYAgQIECAwLACfhNl2NIJnAABAgQIrCdQ+jLEb6SsN2ZkTIAAAQLjCpTct0vX
DOOqiZwAAQIECBCIFrCJEi2qPQIECBAgQKCqgJciVXk1ToAAAQIEuhCwgdJFGQRBgAABAgQI/Baw
iWIYECBAgAABAsMJlGyklLyUGQ5KwAQIECBAYEAB9+oBiyZkAgQIECAwsYBNlImLKzUCBAgQIEDg
WMDLmWMXnxIgQIAAgdEFSv6gxei5i58AAQIECBCoI2ATpY6rVgkQIECAAIHKAqUvSWykVC6Q5gkQ
IECAQIZAyf25dG2QEa5TCBAgQIAAgQUEbKIsUGQpEiBAgACBWQW8LJm1svIiQIAAgRUFSjZQVvSS
MwECBAgQINBGwCZKG2e9ECBAgAABApUESjZSvKypVBTNEiBAgACBBIHtflx6Ty5ZDySE6lACBAgQ
IEBgQQGbKAsWXcoECBAgQIDAfwRKX9qwJECAAAECBPIFIu7DNlDy/Z1JgAABAgQI3AvYRLk3cgQB
AgQIECDQuYCXJ50XSHgECBAgQOBAwAbKAYqPCBAgQIAAge4EbKJ0VxIBESBAgAABAjkCJRspES9x
cmJ2DgECBAgQWFXAvXfVysubAAECBAiMJ2ATZbyaiZgAAQIECBA4EbCRcgLjYwIECBAgMKFAyX1/
Qg4pESBAgAABApUEbKJUgtUsAQIECBAgQIAAAQIECBAg8KdAxG+h2ED509UnBAgQIECAQB0Bmyh1
XLVKgAABAgQIvCRQ8lIl4qXOS2nrlgABAgQILCNQcq9fBkmiBAgQIECAQJiATZQwSg0RIECAAAEC
vQiUvFyxkdJLFcVBgAABAjMKlN5nS+7xM3rKiQABAgQIEKgvYBOlvrEeCBAgQIAAgcEESl/wDJau
cAkQIECAQBOB0vurDZQmZdIJAQIECBAgsBOwiWJIECBAgAABAlMKlL5oKX3RMyWqpAgQIECAwEsC
pff1l8LWLQECBAgQIDCBgE2UCYooBQIECBAgQOBYoPSFy7aRYjPl2NanBAgQIEAgRaDkflp6P0+J
07EECBAgQIAAgb2ATZS9iJ8JECBAgAABAjuBkhc/MAkQIECAwOoCJfdRGyirjx75EyBAgACB9wVs
orxfAxEQIECAAAECFQWiXr6UvACqmJ6mCRAgQIBA1wLun12XR3AECBAgQIDAAwGbKA+QHEKAAAEC
BAiMLWAjZez6iZ4AAQIExhOI+Csxo+7f4+mJmAABAgQIEOhJwCZKT9UQCwECBAgQINC9gD9R232J
BEiAAAECLwtE3CttoLxcRN0TIECAAAEC/xawiWIwECBAuEBFkQAAIABJREFUgAABAksIRL6MiXg5
tAS6JAkQIEBgOQH3yOVKLmECBAgQIDC9gE2U6UssQQIECBAgQOAjELmRQpUAAQIECBD4b4GoDRT3
ayOLAAECBAgQ6EnAJkpP1RALAQIECBAgUF0g6sVM1Iui6gnrgAABAgQIDCQQdZ8eKGWhEiBAgAAB
Ap0L2ETpvEDCI0CAAAECBOIFol7Q2EiJr40WCRAgQGBMgYh7YtT9eUxBURMgQIAAAQK9CthE6bUy
4iJAgAABAgSqCmwvaiJe1kS8NKqaqMYJECBAgEBlgYh7YcQ9uXKamidAgAABAgQWFfjxe6Hya9Hc
pU2AAAECBAgQ+F+BiJc/WzuWVQYUAQIECKwk4P65UrXlSoAAAQIE1hXwmyjr1l7mBAgQIECAwD8C
fivFUCBAgAABAmkCNlDSvBxNgAABAgQIjCtgE2Xc2omcAAECBAgQ6FAg6qVSh6kJiQABAgQI/K9A
1L3Ob3AaUAQIECBAgMAIAjZRRqiSGAkQIECAAIEmAlEvc6JeLjVJWicECBAgQCBBIOoeF3XPTQjd
oQQIECBAgACBLAGbKFlsTiJAgAABAgRmFYh6qRP1kmlWZ3kRIECAwHgCUfe2qHvteIIiJkCAAAEC
BEYUsIkyYtXETIAAAQIECFQViHq5E/WyqWqyGidAgAABAg8E3NMeIDmEAAECBAgQmFLAJsqUZZUU
AQIECBAg0IuAl069VEIcBAgQIJArEHkvi/qDCrm5OI8AAQIECBAgkCpgEyVVzPEECBAgQIDAEgKR
L3kiXz4tgS9JAgQIEOhGIPIeFnlv7QZIIAQIECBAgMD0AjZRpi+xBAkQIECAAIFcAS97cuWcR4AA
AQIzCNhAmaGKciBAgAABAgRKBWyilAo6nwABAgQIEJhawEbK1OWVHAECBAicCERtoGz3UffSE2Qf
EyBAgAABAkMI2EQZokyCJECAAAECBN4UiHgBFPUy6k0HfRMgQIDAGgJR9yybJ2uMF1kSIECAAIHZ
BWyizF5h+REgQIAAAQJhAl4GhVFqiAABAgQ6FYjYQIn4wwed8giLAAECBAgQWFDAJsqCRZcyAQIE
CBAgkC9QspES8WIqP3JnEiBAgACBa4GI+1TJffI6Ot8SIECAAAECBN4RsInyjrteCRAgQIAAgYEF
Sl4QRbygGphO6AQIECDQqYD7U6eFERYBAgQIECDwuoBNlNdLIAACBAgQIEBgRIGSjZQR8xUzAQIE
CMwrELWB4t447xiRGQECBAgQWFng58rJy50AAQIECBAgQIAAAQIECKwqELV5svnZQFl1FMmbAAEC
BAjML+A3UeavsQwJECBAgACBSgJeGFWC1SwBAgQIVBewgVKdWAcECBAgQIDAJAI2USYppDQIECBA
gACBcQQiX1yNk7VICRAgQKAXgaj70PaHCfyBgl6qKg4CBAgQIECgloBNlFqy2iVAgAABAgSWEMh9
eRT1AmsJZEkSIECAQJhA1P0n9/4XloiGCBAgQIAAAQKNBGyiNILWDQECBAgQIDCvgBdJ89ZWZgQI
ECDwp4D73p8mPiFAgAABAgTmFbCJMm9tZUaAAAECBAh0LhD1p4E7T1N4BAgQIDCRgA2UiYopFQIE
CBAgQOCRgE2UR0wOIkCAAAECBAgQIECAAAECYwuUbt7bQBm7/qInQIAAAQIE8gRsouS5OYsAAQIE
CBAgECJQ+kIrJAiNECBAgMD0AqX3Gxso0w8RCRIgQIAAAQInAjZRTmB8TIAAAQIECBBIEfByKUXL
sQQIECDQUsAGSkttfREgQIAAAQKzCdhEma2i8iFAgAABAgReE8jdSCl9ufVawjomQIAAge4FSu8x
ufe27mEESIAAAQIECBB4KGAT5SGUwwgQIECAAAECNQVKX3LVjE3bBAgQIDCmQOm9xQbKmHUXNQEC
BAgQIBArYBMl1lNrBAgQIECAwOICJS+cSl92LU4vfQIECBD4EnBPMRwIECBAgAABAjECNlFiHLVC
gAABAgQIEAgR8NIrhFEjBAgQWFog4l5S8ocClsaXPAECBAgQIDCdgE2U6UoqIQIECBAgQOBtgdIX
TxEvv9420D8BAgQIjCtQeh8bN3OREyBAgAABAgT+FLCJ8qeJTwgQIECAAAECBAgQIECAwJICNlCW
LLukCRAgQIAAgQuBH78XSL8uvvcVAQIECBAgQIBApkDUb5RYrmUWwGkECBBYUKDk3uN+s+CAkTIB
AgQIECBwK+A3UW6JHECAAAECBAgQyBOIehlV8kIsL3JnESBAgMBqAlH3rNXc5EuAAAECBAjML2AT
Zf4ay5AAAQIECBCYQGDbSLGZMkEhpUCAAIEOBWygdFgUIREgQIAAAQLdCNhE6aYUAiFAgAABAgRm
FIh+MWUzZcZRIicCBAjECORstkffp2Iy0QoBAgQIECBAoB8Bmyj91EIkBAgQIECAwKQCNV5Q5bwo
m5RXWgQIECBAgAABAgQIECBAoJrAz2ota5gAAQIECBAgQODfAttGSvTGx769Gps1SkiAAAECBAgQ
IECAAAECBFYW8JsoK1df7gQIECBAgEBTgdqbHPtNlabJ6YwAAQIEhhOofV8aDkTABAgQIECAAIED
AZsoByg+IkCAAAECBAjUEqj9wsq/mVKrctolQIAAAQIECBAgQIAAgRUFbKKsWHU5EyBAgAABAq8K
1N5I2ZLzWymvlljnBAgQaC5g3m9OrkMCBAgQIEBgEQGbKIsUWpoECBAgQIBAXwKtNlK8VOur7qIh
QIBADYGcub7FfahGrtokQIAAAQIECLQWsInSWlx/BAgQIECAAIF/BFq9wPJXfBlyBAgQmFcgZwNl
Xg2ZESBAgAABAgTiBX7GN6lFAgQIECBAgACBpwLfGym1X4R92m+1efPUwHEECBAgQIAAAQIECBAg
QKBXAb+J0mtlxEWAAAECBAgsJ9Bqc+Pzmym1N22WK6CECRAg0FjAPN4YXHcECBAgQIDAkgI2UZYs
u6QJECBAgACBXgW2jZRWmymbgb/qq9eRIC4CBAhcC9hAufbxLQECBAgQIEAgSsAmSpSkdggQIECA
AAECgQJvbKYEhq8pAgQIEOhYoOVmfccMQiNAgAABAgQIPBKwifKIyUEECBAgQIAAgXcEWr7o8qea
36mxXgkQIJAqUDJft7yvpObleAIECBAgQIBAjwL+YfkeqyImAgQIECBAgMCXwP6FV8nLszvYre19
f3fn+J4AAQIExhAwv49RJ1ESIECAAAECfQn4TZS+6iEaAgQIECBAgMCtQO2XYDU3aW6TcwABAgQI
XAqYoy95fEmAAAECBAgQCBewiRJOqkECBAgQIECAQH2B1v9mSv2M9ECAAAECdwIlGyi1N+DvYvc9
AQIECBAgQGBUAZsoo1ZO3AQIECBAgACB3wK1XoqVvKhTGAIECBCIFyiZl2vdK+Kz1CIBAgQIECBA
oD8Bmyj91UREBAgQIECAAIEkgVq/lVLywi4pAQcTIECAAAECBAgQIECAAIFOBWyidFoYYREgQIAA
AQIEUgVqbKbYSEmtguMJECDQl4DfQumrHqIhQIAAAQIExhOwiTJezURMgAABAgQIELgUiN5MsZFy
ye1LAgQIECBAgAABAgQIEJhY4OfEuUmNAAECBAgQILC0wPefPrYRsvRQkDwBAoML5M7hfgtl8MIL
nwABAgQIEOhCwG+idFEGQRAgQIAAAQIE6gqUvkjbXuDlvsSrm5nWCRAgMLdA7txbOu/PrSo7AgQI
ECBAgMBzAZsoz60cSYAAAQIECBAYWiDihVruy7yh4QRPgACBwQQi5vvBUhYuAQIECBAgQKCagE2U
arQaJkCAAAECBAj0JxDxYu3zWyk2VPqrr4gIEJhLwDw7Vz1lQ4AAAQIECIwpYBNlzLqJmgABAgQI
ECCQLRCxkfLp3Au+7DI4kQABApcC5tdLHl8SIECAAAECBJoJ2ERpRq0jAgQIECBAgEA/AjZS+qmF
SAgQIECAAAECBAgQIECgXwGbKP3WRmQECBAgQIAAgWEEPn/F1zABC5QAAQIdC5T8FkrkJnnHREIj
QIAAAQIECDQTsInSjFpHBAgQIECAAIG+BGq8aCt58deXjmgIECDwjkDJPFpjXn9HQa8ECBAgQIAA
gX4EfvYTikgIECBAgAABAgRaC2wv3Epe2B3Fu7XnRd6RjM8IEOhR4GoObD2XXcXSo52YCBAgQIAA
AQIrCPhNlBWqLEcCBAgQIECAwIVAjZeEXgRegPuKAIFuBO7mqrvvIxMp7avGXB6Zn7YIECBAgAAB
AqMK2EQZtXLiJkCAAAECBAgECtR4+Vb6QjAwPU0RIEDgD4Gnc9TT4/7oIOGD0j5qzOEJ4TuUAAEC
BAgQIDC1gE2UqcsrOQIECBAgQIDAc4EaL+FKXww+j96RBAgQGFPAPDlm3URNgAABAgQIrCPw4/fD
8q910pUpAQIECBAgQIDAE4EaL/Wil51XMUb39cTMMQQIjCVwNYccZVJjXkmNoVVcR/34jAABAgQI
ECCwqoDfRFm18vImQIAAAQIECFwI1HpZuL0wjHhpeNfG3fcXqfuKAAECTQQi5qkac3WT5HVCgAAB
AgQIEBhIwG+iDFQsoRIgQIAAAQIE3hKIeNm3jz335V9qLLn97OP1MwECcwmkziVb9hHzSU6/R/IR
sRy16zMCBAgQIECAAIH/FvCbKEYEAQIECBAgQIDArUCNl3VRLxLvgm/Vz10cvidAgEDUfFRjTlYd
AgQIECBAgACBYwGbKMcuPiVAgAABAgQIENgJ1HhpF/VC8a5Yrfq5i8P3BAisKxA1D9WYi9etiswJ
ECBAgAABAvcCNlHujRxBgAABAgQIECDwj8D28i76BV7Ui8W7Im39fP67O9b3BAgQiBSImuei59/I
HLVFgAABAgQIEJhVwCbKrJWVFwECBAgQIECgokD0i7yoF4xPU27d39O4HEeAwHwCUfNN9Lw7n7SM
CBAgQIAAAQJ1BH7WaVarBAgQIECAAAECswtsL/SiXg6+YbXF7qXkG/JlfUaMOXUvq8EsZ480hxmz
s4w6eRAgQIAAAQIjCthEGbFqYiZAgAABAgQIdCIQ+RLyjU2NN/rspHRDhRGxcfKd8FF7XlIPNSSG
CfZorKUGb2ymijmeAAECBAgQIBArYBMl1lNrBAgQIECAAIHlBEbfSFmuYAMkHPHiOTXN7z69tE7V
G/f4yPlrrxAxjo3FvaqfCRAgQIAAAQLtBfybKO3N9UiAAAECBAgQmE4g8kXf3YvHyL62Qtz1N12x
Ok1oq8Pnv7dD7CWOtx30ny8QMa9Ez3X52TiTAAECBAgQILC2gN9EWbv+sidAgAABAgQIhAl8XvhF
vDy8Cyr6T49vMXtheace/32LsVIS9Xd8xkeJ5FrnRoxr422tMSNbAgQIECBAoG+BH78XZ7/6DlF0
BAgQIECAAAECowqUvEx8skwtaf/I9EmfR+f57FwgukbnPbX9xlhp612zt5Qxelf3lLbOcrrr4+w8
nxMgQIAAAQIECNQR8JsodVy1SoAAAQIECBAgUCjweRl59ULx+7uIl5dbG1f9Faa0zOkRtegdy1jp
vULt44sY9+af9nXTIwECBAgQIEDgTsC/iXIn5HsCBAgQIECAAIFsgYgXgk9fTEb0tSX6tL9slElP
3Nw+/02a4h9prZbvHwA++LdAxLwRNYcpCwECBAgQIECAQKyATZRYT60RIECAAAECBAjsBCJeDD59
QRnR1xb+0/7+f3v3th23rQMAtM7K//+yT9R0TpzxjG4ESZDcD33wSCKBDTorBSJbsX8LrO5lmLL2
d0LE+Y/6s2vtSsieAAECBAgQIFBHwBCljqtVCRAgQIAAAQIEvghENAjPNiq3vVrut3KhDQ/+rv7Z
M7rymZkt94iaR/x5NZurfAgQIECAAAECmQQMUTJVQywECBAgQIAAAQK7Ao+m/ZnGZURj8sw+uwFP
fJHN6+Jyee0y46cRtY74c2pGWzkRIECAAAECBDIJfPz6S9tnpoDEQoAAAQIECBAgMK9ARNPxWefo
r7MRex7t8RzTzF9HeNbweVWjnrG+iqdG3tYsF7hyTh51vfLMuwidkXcyPidAgAABAgQI5BIwRMlV
D9EQIECAAAECBKYXiGg+PiMdNSNL9zxa/zmeGb8uNaxhcqcuLfO4E18NJ2vuC1w5E1tNr9z/bmdn
452MzwkQIECAAAEC+QQMUfLVREQECBAgQIAAgekFIpqQz0hHTcnSPY/Wf45npq9L7aIsomvQIq/o
mKMsrfNHoMU5+OrtTDh9BAgQIECAAIGxBAxRxqqXaAkQIECAAAEC0wjUaFweNScj9jzaY5oC/ZdI
hFmJSQvv3jl+9WmRb0k9Zny2Zf3Vd8YTJCcCBAgQIEBgdgFDlNkrLD8CBAgQIECAQGKB6OblmQZl
xJ5n9knMfjq0CKvTm325sadvr5xHc7oTb9ZnWtW857nOai8uAgQIECBAgMAIAoYoI1RJjAQIECBA
gACBiQVqNDCPmpURex7tMXrJIoz2DDL71c59z6XkWmbTkrxqP9uq3upTu5LWJ0CAAAECBAjUEfhR
Z1mrEiBAgAABAgQIEDgnUKOxeNQUjdjzaI9z2ee8q1Zum/vjv5yZjx1VrbqNrZIj+og/c3JkIgoC
BAgQIECAwHoChijr1VzGBAgQIECAAIF0AjUajBrK98oc7WZwcq8Od5/a6hddw7uxeO63QI0/39gS
IECAAAECBAi0EzBEaWdtJwIECBAgQIAAgR2B1m8oRDQ2Z2tWR+cTYbxzZFzaEXgMU6JrurOlSy8E
fA+8QPERAQIECBAgQGAwgZ+DxStcAgQIECBAgACByQW2pmOrxm/EXlusMzRKI81n8Jjp22yWMzpa
TbJ9Hxx9j2eLd7R6i5cAAQIECBCYV8CbKPPWVmYECBAgQIAAgWEFtmZeq4ZexD5HzcnshYiMP8Iz
u9eI8UXWeMT8V4x5q/nX/44MnJEjIdcJECBAgACBVQUMUVatvLwJECBAgAABAgMItBqmRDT+R21A
RsXdqlYDHFshDiQQdf6fU474M+V5zbNfPwYnZ+//el8tjzuxeIYAAQIECBAgkEXAECVLJcRBgAAB
AgQIECDwVqBFQzJij9EakBHxzjg8iTgLbw9zxwsR9e4Y/jBb9zo/JcOTYXAFSoAAAQIECBDoIGCI
0gHdlgQIECBAgAABAjkFIpqfozSqI+KM8Mp5Ev5p9uPksua/QlwR3wMZnAxPMlRBDAQIECBAgMDM
An6x/MzVlRsBAgQIECBAYCKBrWF/pel5t8F/dZ+JiC+lctf30iadb66Z45WzHMmw7Vszr8hYa67V
y/9uTqPFezdPzxEgQIAAAQIEMgp8/PoL9GfGwMREgAABAgQIECBA4JXAmWZixF9xz+zzKr7HZxEx
7K1fcm3m3Epcsj5bWq9XeWU+n6/ijfyshufX+CJsa8e45xkR/976rhEgQIAAAQIERhMwRBmtYuIl
QIAAAQIECBBoJlDayMzYjJwxp2YHIslGpTV8pJHxfNYmjrLbi3PPtcX+e7GdubYX/5nn3UOAAAEC
BAgQmE3Aj/OaraLyIUCAAAECBAgQCBPYmokjND3PJlyai+bqWem690Wdy8d5UNe4en21LP1+i4vK
SgQIECBAgAABAiUC3kQp0fMsAQIECBAgQIDAbYG9BmO2pu5erHsAmfK4m8Mjv0y57Jmvdq20rqvV
N8pr1nPm+3zWysqLAAECBAgQKBH4UfKwZwkQIECAAAECBAjcEThqZB5dv7NnyTN3G4tZ8iiN427+
JeaePScQVZvtjJSek3MR97tr9vxKZaPOUmkcnidAgAABAgQIZBMwRMlWEfEQIECAAAECBCYXONvI
PHtfdq5Z8sjuLL4YgccwxbmN8RxhlW14YoAyQqXESIAAAQIECPQS8DtResnblwABAgQIECBA4FBg
a+S2bO5pHH8vSUv/77v75IzAVqMaZ7f199+ZXN1TLuB7utzQCgQIECBAgMBaAoYoa9VbtgQIECBA
gACB4QSuNnJrNJOHQ/sScImHZus4la85SNkUnIVxzsK7SNXwnYzPCRAgQIAAAQL7An6x/L6PqwQI
ECBAgAABAsECJU3951C+NgUj133eJ+LrHg3MEpMe8UY4r75GSc2P7EY/EzVtjux6Xh+9bj3t7E2A
AAECBAgQ2AS8ieIcECBAgAABAgQIDCuwalP0TMFKbDRdzwjnvGerXUnt97J6ta6zsifW95ra9PW3
OwECBAgQIDCPgCHKPLWUCQECBAgQIECAAIF/BV41u8/SaLyelcp7X81BynPWz2fN+XkWqvs177q+
VidAgAABAgQIbAKGKM4BAQIECBAgQIAAgYkEnpvaE6UmlQsCLQcpX8Pazp/G/oVCXbyV7UUwtxMg
QIAAAQIEAgQMUQIQLUGAAAECBAgQIEAgg4ABSoYq5Imh5yBlU9DwP38WWJ23cicBAgQIECBAoLWA
IUprcfsRIECAAAECBBYX6NXYXZxd+osKfG3Otx6yeSvl9aEzMHnt4lMCBAgQIECAQFYBQ5SslREX
AQIECBAgQGBiAYOU+OJGNMg1d+PrkmnFHt93sw9SfM9kOuFiIUCAAAECBAjUEfhRZ1mrEiBAgAAB
AgQIENgXWKn5OEKuI8S4f6JcPSOw1bl1rSMGfGdyO7onMu8ejkf5uU6AAAECBAgQIFBH4OPXX/4+
6yxtVQIECBAgQIAAAQLHAlkarMeR3rujxV+3Sw1bxHhPz1MtBErPz9kYs5yzknyz5HDW3H0ECBAg
QIAAAQLlAoYo5YZWIECAAAECBAgQKBQoaWoWbn3q8eyN0xK/7LmdKpCbigVKztCVzZ23K1ruJUCA
AAECBAgQyCBgiJKhCmIgQIAAAQIECBD4p3YTd9bm7V23WT18K5UJ3D1PV3Z19q5ouZcAAQIECBAg
QKC3gF8s37sC9idAgAABAgQIEPhXYK+xWtLY3VsXPQECfwts3y8l329nPLf1fV+ekXIPAQIECBAg
QIBABgFDlAxVEAMBAgQIECBAgMCugIbrLs/lizwvky31wKvzUXuwshSwZAkQIECAAAECBIYSMEQZ
qlyCJUCAAAECBAgQIPBHQGPbaWgl8DxYKT173kZpVTn7ECBAgAABAgQIlAr8KF3A8wQIECBAgAAB
AgQIjCPw3AwfJ3KRZhKIOEelg5hMHmIhQIAAAQIECBCYV8AQZd7ayowAAQIECBAgQGBiAQ3oiYs7
SGrbIKV0mOIcD1JsYRIgQIAAAQIEFhYwRFm4+FInQIAAAQIECBBYS6C04b2WlmzPCpSeK4OUs9Lu
I0CAAAECBAgQ6CFgiNJD3Z4ECBAgQIAAAQIECBCYSMAgZaJiSoUAAQIECBAgQOAvAUMUB4IAAQIE
CBAgQIAAAQIEugt4I6V7CQRAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAjMJlD6psBsHvKJF3DG
4k2tSIAAAQIECBAg0F/AEKV/DURAgAABAgQIECBAgACBKQRKByneRpniGEiCAAECBAgQIDCVgCHK
VOWUDAECBAgQIECAAIHvAqWN7e8r+oTAe4HS87YNUgxT3vu6QoAAAQIECBAg0FbAEKWtt90IECBA
gAABAgQIFAtoMBcTWqCyQOkgZQvPOa9cJMsTIECAAAECBAicEjBEOcXkJgIECBAgQIAAAQI5BDSW
c9RBFMcCBinHRu4gQIAAAQIECBDIL2CIkr9GIiRAgAABAgQIECDwr4ABioMwmoBBymgVEy8BAgQI
ECBAgMCzgCHKs4ivCRAgQIAAAQIECBAgQCCVgAFiqnIIhgABAgQIECCwlIAhylLlliwBAgQIECBA
gAABAgTaCkS8jbJFbJDStm52I0CAAAECBAgQ+C1giOIkECBAgAABAgQIECBAgEBVgahBStUgLU6A
AAECBAgQIEDghYAhygsUHxEgQIAAAQIECBDIJnD3X+FrXmer5LrxOIvr1l7mBAgQIECAAIGRBQxR
Rq6e2AkQIECAAAECBAjsCGha7+C41EWg9EzeHSZ2SdamBAgQIECAAAECUwgYokxRRkkQIECAAAEC
BAjMLHCncVzarJ7ZU259BZzNvv52J0CAAAECBAgQuCZgiHLNy90ECBAgQIAAAQIECBAgUChQMki5
M1QsDNfjBAgQIECAAAECCwsYoixcfKkTIECAAAECBAgQIECgl8A2SCkZpvSK274ECBAgQIAAAQJr
CRiirFVv2RIgQIAAAQIECBAgQIAAAQIECBAgQIAAAQInBQxRTkK5jQABAgQIECBAgMAoAv51/yiV
EicBAgQIECBAgAABAtkFDFGyV0h8BAgQIECAAAECBAgQmFjA0G/i4kqNAAECBAgQIDCBgCHKBEWU
AgECBAgQIECAAIGHgIa0s0CAAAECBAgQIECAAIE4AUOUOEsrESBAgAABAgQIECBAgMANAcO/G2ge
IUCAAAECBAgQaCJgiNKE2SYECBAgQIAAAQIECBAgECXw8fERtZR1CBAgQIAAAQIECOwKGKLs8rhI
gAABAgQIECBAoK+AZnFff7sTIECAAAECBAgQILC2gCHK2vWXPQECBAgQIECAAAECBAgQIECAAAEC
BAgQIPBGwBDlDYyPCRAgQIAAAQIECBAgQIAAAQIECBAgQIAAgbUFDFHWrr/sCRAgQIAAAQIECBAg
QIAAAQIECBAgQIAAgTcChihvYHxMgAABAgQIECBAgAABAnkF/L6gvLURGQECBAgQIEBgJgFDlJmq
KRcCBAgQIECAAAECBAgMKvD5+Xk5coOUy2QeIECAAAECBAgQuChgiHIRzO0ECBAgQIAAAQIEsgrc
aUJnzUVcBM4KGKSclXIfAQIECBAgQIDAHQFDlDtqniFAgAABAgQIECBAgAABAgQIECBAgAABAgSm
FzBEmb7EEiRAgAABAgQIEBhVwL+wH7Vy4m4t4Ht9CHEEAAAgAElEQVSltbj9CBAgQIAAAQLrCPxc
J1WZEiBAgAABAgQIEBhHQFN4nFrVjPToHPgRbn/0NyseNU+jtQkQIECAAAECawp4E2XNusuaAAEC
BAgQIECAAIHkAkcDlC38M/ckT/Ov8EqHILN5jFQ7sRIgQIAAAQIEZhUwRJm1svIiQIAAAQIECBAY
VkAjeNjShQV+5QxcuTcswIoLGaRUxLU0AQIECBAgQIDAZQE/zusymQcIECBAgAABAgQI1BOYrSFe
T+r9ymcNS5v17yNwpVRgq83ZOpbu5XkCBAgQIECAAAECewLeRNnTcY0AAQIECBAgQIAAgaEErjTe
r9w7FIJgDWCcAQIECBAgQIAAgTABQ5QwSgsRIECAAAECBAgQ6CfgrYp7vx/EIKXfmbUzAQIECBAg
QIAAgREEDFFGqJIYCRAgQIAAAQIElhC429A3QFnieCyXZOm5vvv9tBy0hAkQIECAAAECBHYFDFF2
eVwkQIAAAQIECBAgQIAAgV4CBim95O1LgAABAgQIECDwEDBEcRYIECBAgAABAgQIDCxQ2mQeOHWh
LyLgjC9SaGkSIECAAAECBJIKGKIkLYywCBAgQIAAAQIECBwJaC4fCY17/Uptr9w7qkhJjn6s16hV
FzcBAgQIECBAIIeAIUqOOoiCAAECBAgQIECAAAECfwmcGRycuWcW1pVynaVm8iBAgAABAgQIzCDw
c4Yk5ECAAAECBAgQIEBgdAH/Wn70CtaJ3+AgxnX7/mIZY2kVAgQIECBAgMBqAt5EWa3i8iVAgAAB
AgQIEJhCQEM4powcYxxbraJeraTtQ4AAAQIECBAg8BAwRHEWCBAgQIAAAQIECBCYQuBqg/3q/VMg
TZCEuk1QRCkQIECAAAECBAYS8OO8BiqWUAkQIECAAAECBAgQ2BfYGux7PxpNA37fz1UCBAgQIECA
AAECBP4WMERxIggQIECAAAECBAgQmErAoGSqcr5M5mhY9uohvxfllYrPCBAgQIAAAQIEjgT8OK8j
IdcJECBAgAABAgQIVBbYe3Oi8taWJ0CAAAECBAgQIECAAIEdAUOUHRyXCBAgQIAAAQIECGQU8KZF
xqqIqbWA74PW4vYjQIAAAQIECKwpYIiyZt1lTYAAAQIECBAgQIAAAQIECBAgQIAAAQIECBwIGKIc
ALlMgAABAgQIECBAgAABAgQIECBAgAABAgQIrClgiLJm3WVNgAABAgQIECBAgAABAgQIECBAgAAB
AgQIHAgYohwAuUyAAAECBAgQIECgpsDVXyrv90DUrIa1RxPw/TBaxcRLgAABAgQIEBhPwBBlvJqJ
mAABAgQIECBAYBKBqwOUSdKWBgECBAgQIECAAAECBIYRMEQZplQCJUCAAAECBAgQIECAAAECBAgQ
IECAAAECBFoKGKK01LYXAQIECBAgQIAAgf8EvIXiKBAgQIAAAQIECBAgQCC/gCFK/hqJkAABAgQI
ECBAYDIBA5TJCiodAgQIECBAgAABAgSmFTBEmba0EiNAgAABAgQIECBAgMDcAgaSc9dXdgQIECBA
gACBDAKGKBmqIAYCBAgQIECAAAECJwQ+Pz9P3OUWAgQIECBAgAABAgQIEIgSMESJkrQOAQIECBAg
QIAAgYoCBigVcS1NgAABAgQIECBAgACBNwKGKG9gfEyAAAECBAgQIECAAAECBAgQIECAAAECBAis
LWCIsnb9ZU+AAAECBAgQIDCAgLdQBiiSEAkQIECAAAECBAgQmFLAEGXKskqKAAECBAgQIEBgFgED
lFkqKQ8CBAgQIECAAAECBEYUMEQZsWpiJkCAAAECBAgQIECAAIFLAgaSl7jcTIAAAQIECBAg8J+A
IYqjQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBB4IWCI8gLFRwQIECBAgAABAgQIECBAgAABAgQI
ECBAgAABQxRngAABAgQIECBAgAABAgQIECBAgAABAgQIECDwQsAQ5QWKjwgQIECAAAECBAgQIECA
AAECBAgQIECAAAEChijOAAECBAgQIECAAAECBAgMJ/Dx8TFczAImQIAAAQIECBAYT8AQZbyaiZgA
AQIECBAgQIAAAQIECBAgQIAAAQIECBBoIGCI0gDZFgQIECBAgAABAgQIECBAgAABAgQIECBAgMB4
AoYo49VMxAQIECBAgAABAgQIECBAgAABAgQIECBAgEADAUOUBsi2IECAAAECBAgQIECAAAECBAgQ
IECAAAECBMYTMEQZr2YiJkCAAAECBAgQIECAAAECBAgQIECAAAECBBoIGKI0QLYFAQIECBAgQIAA
AQIECPQT+Pz87Le5nQkQIECAAAECBIYWMEQZunyCJ0CAAAECBAgQIECAAAECBAgQIECAAAECBGoJ
GKLUkrUuAQIECBAgQIAAAQIECBAgQIAAAQIECBAgMLSAIcrQ5RM8AQIECBAgQIAAAQIECBAgQIAA
AQIECBAgUEvAEKWWrHUJECBAgAABAgQIECBAgAABAgQIECBAgACBoQUMUYYun+AJECBAgAABAgQI
ECBAgAABAgQIECBAgACBWgI/ay1sXQIECBAgQIAAAQIECBBoI/Dx8fF2o8/Pz7fXXCBAgAABAgQI
ECBAYF/Amyj7Pq4SIECAAAECBAgQIEAgtcDeAGUL/Oh66uQER4AAAQIECBAgQKCzgCFK5wLYngAB
AgQIECBAgMCegAb4no5rZ8/H2fuIEiBAgAABAgQIECDwt4Af5+VEECBAgAABAgQIECCwlMDeQGGk
H321l8dSBZUsAQIECBAgQIAAgYoC3kSpiGtpAgQIECBAgAABAgRyCRwNHo6uZ8lmlDizeImDAAEC
BAgQIECAwF0BQ5S7cp4jQIAAAQIECBAgQGAogbODh+2+s/f2AMgcWw8PexIgQIAAAQIECBCoKWCI
UlPX2gQIECBAgAABAgQIDCuQcViRMaZhCyxwAgQIECBAgAABAicEDFFOILmFAAECBAgQIECAAIE1
BTINLTLFsuZpkDUBAgQIECBAgMCKAoYoK1ZdzgQIECBAgAABAl0FRvrl5V2hkmyeYXiRIYYk5RAG
AQIECBAgQIAAgaYChihNuW1GgAABAgQIECBA4LqABvp1s+gnthr0qEPUvgZ30SfCegQIECBAgAAB
AqsIGKKsUml5EiBAgAABAgQIECBQLNBykBK1lwFKcdktQIAAAQIECBAgsLCAIcrCxZc6AQIECBAg
QIAAAQLXBaKGG3s7R+1hgLKn7BoBAgQIECBAgACBYwFDlGMjdxAgQIAAAQIECBAgQOAvgaghxzNr
1I/vel7X1wQIECBAgAABAgQI3BMwRLnn5ikCBAgQIECAAAECBAYTiH4rI3rgET2Yic53sHILlwAB
AgQIECBAgECIgCFKCKNFCBAgQIAAAQIECBAYQaDGYCFimGKAMsLpESMBAgQIECBAgMCKAoYoK1Zd
zgQIECBAgAABAt0FajTzuyc1SAC17O8OUwxQBjk4wiRAgAABAgQIEFhS4OeSWUuaAAECBAgQIECA
wGACW6O9VvN/MIqQcL9aRg8xntdrWbeWe4UUwiIECBAgQIAAAQIEkgsYoiQvkPAIECBAgAABAgQI
EKgrsA0engcfkTvWXPsRp+FJZMWsRYAAAQIECBAgQOCPgB/n5TQQIECAAAECBAgQILC8wMhDiJFj
X/7gASBAgAABAgQIEEgvYIiSvkQCJECAAAECBAgQIPBboMUbDStbjziMGDHmlc+Y3AkQIECAAAEC
BMYTMEQZr2YiJkCAAAECBAgQIECgksAoQ4ktzlFirVQqyxIgQIAAAQIECBBoImCI0oTZJgQIECBA
gAABAgS+C9xpgnsb5btj9Cd36hIdw9562ePbi901AgQIECBAgAABAqMJGKKMVjHxEiBAgAABAgQI
LC9gkFL/CGQdVGSNq35F7ECAAAECBAgQIECgj4AhSh93uxIgQIAAAQIECBAgkFzAj8xKXiDhESBA
gAABAgQIEGggYIjSANkWBAgQIECAAAECBKIFvI0SLfp+vSzDFG+hvK+RKwQIECBAgAABAgRqCRii
1JK1LgECBAgQIECAAIETAhrjJ5CS3NJzmOKcJDkEwiBAgAABAgQIEFhOwBBluZJLmAABAgQIECBA
gACBEoHWwxQDlJJqeZYAAQIECBAgQIBAmYAhSpmfpwkQIECAAAECBAgUC9xtkvuRXsX0RQs8hik1
hyp3z0ZRYh4mQIAAAQIECBAgQOD/Aj9ZECBAgAABAgQIECDQX2BrlhuK9K9DSQQGHiV6niVAgAAB
AgQIECCQU8CbKDnrIioCBAgQIECAAAECBAgQIECAAAECBAgQIECgs4AhSucC2J4AAQIECBAgQIDA
Q8CbDM4CgXMC3to65+QuAgQIECBAgACBcgFDlHJDKxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIT
ChiiTFhUKREgQIAAAQIECBAgQGBWAW+hzFpZeREgQIAAAQIEcgoYouSsi6gIECBAgAABAgQWFbj6
I700lBc9KNImQIAAAQIECBAgQKCJgCFKE2abECBAgAABAgQIEKgnYJBSz9bKBAgQIECAAAECBAis
LWCIsnb9ZU+AAAECBAgQIDCJgEHKJIWUxq6Ac77L4yIBAgQIECBAgEAFAUOUCqiWJECAAAECBAgQ
IECAAIEcAld/RF6OqEVBgAABAgQIECCQRcAQJUslxEGAAAECBAgQIECgUMC/0i8E9DgBAgQIECBA
gAABAgSeBAxRHAkCBAgQIECAAAECBAgQSC9wZ0joLZT0ZRUgAQIECBAgQCC9gCFK+hIJkAABAgQI
ECBAYDUBjd/VKi7fI4E7A5SjNV0nQIAAAQIECBAgcEbAEOWMknsIECBAgAABAgQINBYwSGkMbru0
AgYoaUsjMAIECBAgQIDAEgKGKEuUWZIECBAgQIAAAQIjCtwZpGg4j1hpMb8TKDnPd75/3sXhcwIE
CBAgQIAAgXUFDFHWrb3MCRAgQIAAAQIEJhUoaTxPSiItAgQIECBAgAABAgQI3BIwRLnF5iECBAgQ
IECAAAECbQT8a/o2znYhQIAAAQIECBAgQIDAK4Gfrz70GQECBAgQIECAAAECYws83kYxhBm7jqtG
X/o2lXO/6smRNwECBAgQIEAgXsCbKPGmViRAgAABAgQIECCQRqC0GZ0mEYEsI1B6Zg1QljkqEiVA
gAABAgQINBEwRGnCbBMCBAgQIECAAAEC/QRKm9L9IrfzagKlZ9UAZbUTI18CBAgQIECAQH0BQ5T6
xnYgQIAAAQIECBAgUCQQ0RjemtOlDeqiJDxM4ECg9HxGfJ8chOgyAQIECBAgQIDAggKGKAsWXcoE
CBAgQIAAAQLjCUQ1iEsb1ePJiTi7gAFf9gqJjwABAgQIECCwtoAhytr1lz0BAgQIECBAgMCCAgYp
CxY9acrOYtLCCIsAAQIECBAgQOD/AoYoDgMBAgQIECBAgACBQQSi3kbZ0tW8HqToE4cZeQYjvzcm
JpcaAQIECBAgQIDADQFDlBtoHiFAgAABAgQIECDQSyCyWRzZxO7lYd8xBSLPXuT3xJiaoiZAgAAB
AgQIEKgpYIhSU9faBAgQIECAAAECBCoIRDaNI5vZFVK15GQC0b//JPJ7YTJq6RAgQIAAAQIECAQJ
fPz6S+dn0FqWIUCAAAECBAgQIECgoUD0AMT/GjQs3mJbRZ/Vjc95XewQSZcAAQIECBAg0EnAEKUT
vG0JECBAgAABAgQIRAhoTkcoWqOWQI3zucVqgFKrYtYlQIAAAQIECBB4FjBEeRbxNQECBAgQIECA
AIEBBWo0qzWqBzwIiUJ2JhMVQygECBAgQIAAAQK3BQxRbtN5kAABAgQIECBAgEAugRpN668ZGqrk
qnfmaGqcRecvc8XFRoAAAQIECBCYV8Avlp+3tjIjQIAAAQIECBBYTKB2k3lrjNdoji9WpunTrXFG
ap/t6YsiQQIECBAgQIAAgdsC3kS5TedBAgQIECBAgAABAnkFajSyn7PV2H4WWe9r52y9msuYAAEC
BAgQILCagCHKahWXLwECBAgQIECAwDICLRrcG6ZhSs4jVVr/57qWrndV6Xn/q8+7nwABAgQIECBA
gECEgCFKhKI1CBAgQIAAAQIECCQV0PhOWpjAsFrXODD0t0sZoLylcYEAAQIECBAgQKCxgCFKY3Db
ESBAgAABAgQIEGgt0KPJrgler8o96lkvm+8rOzvfTXxCgAABAgQIECDQT8AQpZ+9nQkQIECAAAEC
BAg0E+jZeNcULytzz9qVRX79aWflupknCBAgQIAAAQIE6goYotT1tToBAgQIECBAgACBNAIZmvGa
5OeOQ4ZanYs05i7nIsbRKgQIECBAgAABAvEChijxplYkQIAAAQIECBAgkFogS4Ne4/z3MclSjx6H
1hnooW5PAgQIECBAgACBKwKGKFe03EuAAAECBAgQIEBgIoGMzfsVmuoZ3Vsf6xXq3NrUfgQIECBA
gAABAnUEDFHquFqVAAECBAgQIECAwDACqzb1azXyV/U8e+BruZ/d330ECBAgQIAAAQIErggYolzR
ci8BAgQIECBAgACBBQQMARYocqcUDVA6wduWAAECBAgQIEDgtsCP2096kAABAgQIECBAgACBKQW2
Rrdm95Sl7ZqUM9WV3+YECBAgQIAAAQI3BX7efM5jBAgQIECAAAECBAhMLvBoenszZfJCV0jPwKQC
qiUJECBAgAABAgS6CBiidGG3KQECBAgQIECAAIFxBAxTxqnVmUifBxylQ7Ln9c7E4B4CBAgQIECA
AAECowj4nSijVEqcBAgQIECAAAECBBIJlDbeE6UybSiGG9OWVmIECBAgQIAAAQINBbyJ0hDbVgQI
ECBAgAABAgRmEfB2Sr5KGprkq4mICBAgQIAAAQIExhcwRBm/hjIgQIAAAQIECBAg0E3ga+Pe2ylt
y2Bo0tbbbgQIECBAgAABAmsKGKKsWXdZEyBAgAABAgQIEAgXMFAJJ/22oMHJNxIfECBAgAABAgQI
EKgqYIhSldfiBAgQIECAAAECBNYUMFApr7uBSbmhFQgQIECAAAECBAiUChiilAp6ngABAgQIECBA
gACBXYF3wwA//utvtndOu7guEiBAgAABAgQIECBQVcAQpSqvxQkQIECAAAECBAgQeCfQcmiQYWDT
Mt935j4nQIAAAQIECBAgQOCagCHKNS93EyBAgAABAgQIECAwoIABxoBFEzIBAgQIECBAgACBBAI/
EsQgBAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAAB
AgQIECCQQcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAEC
BAgQIECAAAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQT
MERJVxIBESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAEC
BAgQIECAQDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBA
gAABAgQIECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwE
CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQ
QcAQJUMVxECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIE
CBAgQIAAAQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECA
AAECBAgQIECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIB
ESBAgAABAgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECA
QDoBQ5R0JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQI
ECBAgAABAgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAA
AQIECBAgQIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMV
xECAAAECBAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAA
AQIZBAxRMlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQ
IECAAAECBAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAAB
AgQIECBAgAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDoBQ5R0
JREQAQIECBAgQIAAAQIECBAgQIAAAQIECBAgkEHAECVDFcRAgAABAgQIECBAgAABAgQIECBAgAAB
AgQIpBMwRElXEgERIECAAAECBAgQIECAAAECBAgQIECAAAECGQQMUTJUQQwECBAgQIAAAQIECBAg
QIAAAQIECBAgQIBAOgFDlHQlERABAgQIECBAgAABAgQIECBAgAABAgQIECCQQcAQJUMVxECAAAEC
BAgQIECAAAECBAgQIECAAAECBAikEzBESVcSAREgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIZBAxR
MlRBDAQIECBAgAABAgQIECBAgAABAgQIECBAgEA6AUOUdCUREAECBAgQIECAAAECBAgQIECAAAEC
BAgQIJBBwBAlQxXEQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECKQTMERJVxIBESBAgAABAgQIECBA
gAABAgQIECBAgAABAhkEDFEyVEEMBAgQIECAAAECBAgQIECAAAECBAgQIECAQDqBn+kiEhABAgQI
ECBAgACBxQQ+Pj52M/78/Ny97iIBAgQIECBAgAABAgQI1BHwJkodV6sSIECAAAECBAgQOCVwNEDZ
Fjlzz6nN3ESAAAECBAgQIECAAAEClwS8iXKJy80ECBAgQIAAAQIE4gSuDEe2e2u8kbIXQ4394vSs
RIAAAQIECBAgQIAAgfoC3kSpb2wHAgQIECBAgAABAikF9gYoW8BH11MmJSgCBAgQIECAAAECBAgE
ChiiBGJaigABAgQIECBAgMBZgd4DirP7n73vbN7uI0CAAAECBAgQIECAwEgChigjVUusBAgQIECA
AAECBAgQIECAAAECBAgQIECAQDMBQ5Rm1DYiQIAAAQIECBAgQIAAAQIECBAgQIAAAQIERhIwRBmp
WmIlQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEmgkYojSjthEBAgQIECBAgACB3wJ+z4iTQIAAAQIE
CBAgQIAAgTEEDFHGqJMoCRAgQIAAAQIEJhG4O0D5/PycREAaBAgQIECAAAECBAgQGEfAEGWcWomU
AAECBAgQIEBgUQEDlEULL20CBAgQIECAAAECBLoLGKJ0L4EACBAgQIAAAQIEVhG4+xZKb59R4+7t
Zn8CBAgQIECAAAECBMYXMEQZv4YyIECAAAECBAgQIFBdwCClOrENCBAgQIAAAQIECBBIKGCIkrAo
QiJAgAABAgQIECBAgAABAgQIECBAgAABAgT6Cxii9K+BCAgQIECAAAECBAi8Fcj0+1C8jfK2TC4Q
IECAAAECBAgQIDCpgCHKpIWVFgECBAgQIECAwPgCmQYo42vKgAABAgQIECBAgAABAtcFfl5/xBME
CBAgQIAAAQIECKwqsL2Ncme4k+Utljuxr1preRMgQIAAAQIECBAg8M8/3kRxCggQIECAAAECBAgk
FKjd7K+9/lfSLAOULaZMsSQ8dkIiQIAAAQIECBAgQOBJwJsojgQBAgQIECBAgACBRQW2QUrtoULt
9e+U7u7bNHf28sxrgZJzcebcthwSvs7QpwQIECBAgAABArMIGKLMUkl5ECBAgAABAgQIEEgmUNIo
T5bKt3Ba5TbTMCDK7Mw6BmXfjqwPCBAgQIAAAQIEbgr4cV434TxGgAABAgQIECBAYAaBWk36M43u
Ef22vFrm1nKvmvXokUePPWsaWpsAAQIECBAgQKCPgCFKH3e7EiBAgAABAgQIEJhWYMbmdevhydfD
Mbrn6PFP+40qMQIECBAgQIAAgVMCfpzXKSY3ESBAgAABAgQIEJhX4MzvmJg3+/eZZWr+b7HUemvo
vcC9K5nc7mXgKQIECBAgQIAAAQJ/BLyJ4jQQIECAAAECBAgQIEDgSSDjICBjTM8HZ4QYn2P2NQEC
BAgQIECAAIE9AUOUPR3XCBAgQIAAAQIECBBYTiDzIEBsyx1HCRMgQIAAAQIECHQWMETpXADbEyBA
gAABAgQIECDQVmDvx2JlHlK0Vbq2G7drXu4mQIAAAQIECBAYR8DvRBmnViIlQIAAAQIECBAgUEVg
pQa4AcqfI3Sm7nte20pn1qhyaC1KgAABAgQIECBAoJGAIUojaNsQIECAAAECBAgQIHAscNS0P17h
3h2rDQPO5rvd964mZ9e4V5Hyp97FXb6yFQgQIECAAAECBFYSMERZqdpyJUCAAAECBAgQIPAkkK0R
/jUeTfA6x/VqzZ8HKVefr5PF/qrOzr6Pq0jXF6AAAA3PSURBVAQIECBAgAABAucFDFHOW7mTAAEC
BAgQIECAwDQCIzTCj2KMapQf7TNN0QMSqW31taZ39oo6EwFUliBAgAABAgQIEJhEwBBlkkJKgwAB
AgQIECBAgMCRwJ2m9NGaPa9/zSdL8/xsHKPVoma878zefd7zzNmbAAECBAgQIEBgPYEf66UsYwIE
CBAgQIAAAQLrCdRsgmfQ7J3f1vDX9L9+EphdN/MEAQIECBAgQIBAWwFDlLbediNAgAABAgQIECBw
SiByKBC5Vuamd2Sep4r066Y7w5MecZ7Np+V9mc9SSwd7ESBAgAABAgQI5Bbw47xy10d0BAgQIECA
AAECBIoEVmvYb/nWbs7XXr+o4MkfZpe8QMIjQIAAAQIECBD4JmCI8o3EBwQIECBAgAABAgTGF6gx
PNEA738uRq7ByLH3r7wICBAgQIAAAQIEegn4cV695O1LgAABAgQIECBAoJJA7wFK72Z5jfwfpSrN
rSS20r0rHbdTy44c+6kE3USAAAECBAgQIDCtgCHKtKWVGAECBAgQIECAwIoCJU36d153GuB3nnm3
/53PazjciSPqmd6eJXmMHHtJ3p4lQIAAAQIECBCYQ8CP85qjjrIgQIAAAQIECBCYUODq7/eoMTgo
aYB/fbZGbEclv+p3tN7d66W5l9TgVczbeqUxvVr362fRMR/t5zoBAgQIECBAgACBWgKGKLVkrUuA
AAECBAgQIEDgSaBm87pGUzyyEf68Vo14Wxy4d3E/5/eI5d39Z2N9t+7Z59/dV/MsvtvT5wQIECBA
gAABAgRGFDBEGbFqYiZAgAABAgQIEFhG4MzbFKWN+leYtZr3j72+rl8j/lc51fzskcMjrxFyqhVr
7bNTs47WJkCAAAECBAgQIPAsYIjyLOJrAgQIECBAgAABAskE9gYp0c36Hg3woz2jc6xZ3pFirelg
bQIECBAgQIAAAQKzCPjF8rNUUh4ECBAgQIAAAQJTC7xqzr/67A7CNsR4/Hfn+drPZI6tZu5Hw6Wo
vVvtExWvdQgQIECAAAECBAi0FDBEaaltLwIECBAgQIAAAQIFAl+HJpEDlIKQPDqJgEHKJIWUBgEC
BAgQIECAQLiAIUo4qQUJECBAgAABAgQIvBcobVZvw5MVByhROb+vTK4rpeckVzaiIUCAAAECBAgQ
IDCugCHKuLUTOQECBAgQIECAAIHbApr0t+mqP9irNr32rQ5qAwIECBAgQIAAAQIFAoYoBXgeJUCA
AAECBAgQIHBHoGezetu75/53vGo/k8kjUyy13a1PgAABAgQIECBAYAQBQ5QRqiRGAgQIECBAgACB
6QR6NMt77BlRuBY/yiuDjRgiTos1CBAgQIAAAQIECMQKGKLEelqNAAECBAgQIECAwGmBlk3zlnud
BjhxY8kAZaScR4r1RNncQoAAAQIECBAgQGAagZ/TZCIRAgQIECBAgAABAgReCozaoJ99gJK1Lltc
JfYvD6EPCRAgQIAAAQIECAwq4E2UQQsnbAIECBAgQIAAgTkEajfSa69fqwolTfy7Od997o5By71m
jO9OTp4hQIAAAQIECBAgcEfAEOWOmmcIECBAgAABAgQIBArUaqjXWjcw9ZdLlQxQXi544cPaZtv6
tfe4kO7uraPEuZuEiwQIECBAgAABAgQKBfw4r0JAjxMgQIAAAQIECBCIENga1pHDAw3w+1WJqAX/
+/6eJECAAAECBAgQIJBJwBAlUzXEQoAAAQIECBAgsLRARPN+A2zdwN8b/rSOJWq/qFrUOtCZzGvl
aF0CBAgQIECAAAECGQQ+fv3PwWeGQMRAgAABAgQIECBAgMA/xW+jtP7r/V4z/1HPo5jOrHHmbBzt
c2aN53tKY+sVU9S+d/OP2v+5Hr4mQIAAAQIECBAg0FrA70RpLW4/AgQIECBAgAABAjsCJc3nkmd3
Qnp76WyD/fm+7euv/73d4MKFWrmXrvuc+4WUXt56dr2z973cxIcECBAgQIAAAQIECPxfwBDFYSBA
gAABAgQIECCQTOBO4/7OM63TfgxOWu/be7+R8757rgxxep86+xMgQIAAAQIECEQJGKJESVqHAAEC
BAgQIECAQKDAleb1lXsDQ7y0VM2meu38o9avaXCpGBdvjsr/4rZuJ0CAAAECBAgQIJBCwC+WT1EG
QRAgQIAAAQIECBD4LqB5/d3k+ZNWRts+EUOQxxp34o7Y/9nP1wQIECBAgAABAgQI7At4E2Xfx1UC
BAgQIECAAAECBAiEC1wZiIz848DC4SxIgAABAgQIECBAoLGAN1Eag9uOAAECBAgQIECAAIEYgTtv
c5TsHPU2yiOGK4OUkrg9S4AAAQIECBAgQIDAfQFvoty38yQBAgQIECBAgAABAp0EWg9QHmn22rcT
s20JECBAgAABAgQILC9giLL8EQBAgAABAgQIECBAYCyB3oOM3vv3qNaKOfdwticBAgQIECBAgEA+
AUOUfDUREQECBAgQIECAAAECbwSyNPOzxPGGqcrHV3K+cm+VYC1KgAABAgQIECBAIEjAECUI0jIE
CBAgQIAAAQIECNQVyNaYzxZPXf3fq5/J+cw9LWK1BwECBAgQIECAAIEIgY9ff8H9jFjIGgQIECBA
gAABAgQIrCdQ85ejj/S/KjUd7pyqkezu5OcZAgQIECBAgAABAq0EDFFaSduHAAECBAgQIECAwKQC
UQOE0Rv/UQ6lx2R0x9L8PU+AAAECBAgQIEAgUsAQJVLTWgQIECBAgAABAgQWFrg7RJip6X/XIOrY
zGQZZWIdAgQIECBAgAABAiUChiglep4lQIAAAQIECBAgQOAvgStDhFkb/lcMoo7PrJZRPtYhQIAA
AQIECBAgcFfAEOWunOcIECBAgAABAgQIECBwINBioGKAclAElwkQIECAAAECBAgUCPwoeNajBAgQ
IECAAAECBAgQILAjUHPAsa1dc/2dtFwiQIAAAQIECBAgsIzAz2UylSgBAgQIECBAgAABAgQ6CBh0
dEC3JQECBAgQIECAAIEgAW+iBEFahgABAgQIECBAgAABAgQIECBAgAABAgQIEJhLwBBlrnrKhgAB
AgQIECBAgAABAgQIECBAgAABAgQIEAgSMEQJgrQMAQIECBAgQIAAAQIECBAgQIAAAQIECBAgMJeA
Icpc9ZQNAQIECBAgQIAAAQIECBAgQIAAAQIECBAgECRgiBIEaRkCBAgQIECAAAECBAgQIECAAAEC
BAgQIEBgLgFDlLnqKRsCBAgQIECAAAECBAgQIECAAAECBAgQIEAgSMAQJQjSMgQIECBAgAABAgQI
ECBAgAABAgQIECBAgMBcAoYoc9VTNgQIECBAgAABAgQIECBAgAABAgQIECBAgECQgCFKEKRlCBAg
QIAAAQIECBAgQIAAAQIECBAgQIAAgbkEDFHmqqdsCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgSAB
Q5QgSMsQIECAAAECBAgQIECAAAECBAgQIECAAAECcwkYosxVT9kQIECAAAECBAgQIECAAAECBAgQ
IECAAAECQQKGKEGQliFAgAABAgQIECBAgAABAgQIECBAgAABAgTmEjBEmauesiFAgAABAgQIECBA
gAABAgQIECBAgAABAgSCBAxRgiAtQ4AAAQIECBAgQIAAAQIECBAgQIAAAQIECMwlYIgyVz1lQ4AA
AQIECBAgQIAAAQIECBAgQIAAAQIECAQJGKIEQVqGAAECBAgQIECAAAECBAgQIECAAAECBAgQmEvA
EGWuesqGAAECBAgQIECAAAECBAgQIECAAAECBAgQCBIwRAmCtAwBAgQIECBAgAABAgQIECBAgAAB
AgQIECAwl4Ahylz1lA0BAgQIECBAgAABAgQIECBAgAABAgQIECAQJGCIEgRpGQIECBAgQIAAAQIE
CBAgQIAAAQIECBAgQGAuAUOUueopGwIECBAgQIAAAQIECBAgQIAAAQIECBAgQCBIwBAlCNIyBAgQ
IECAAAECBAgQIECAAAECBAgQIECAwFwChihz1VM2BAgQIECAAAECBAgQIECAAAECBAgQIECAQJCA
IUoQpGUIECBAgAABAgQIECBAgAABAgQIECBAgACBuQQMUeaqp2wIECBAgAABAgQIECBAgAABAgQI
ECBAgACBIAFDlCBIyxAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJzCRiizFVP2RAgQIAAAQIECBAg
QIAAAQIECBAgQIAAAQJBAoYoQZCWIUCAAAECBAgQIECAAAECBAgQIECAAAECBOYSMESZq56yIUCA
AAECBAgQIECAAAECBAgQIECAAAECBIIEDFGCIC1DgAABAgQIECBAgAABAgQIECBAgAABAgQIzCVg
iDJXPWVDgAABAgQIECBAgAABAgQIECBAgAABAgQIBAkYogRBWoYAAQIECBAgQIAAAQIECBAgQIAA
AQIECBCYS8AQZa56yoYAAQIECBAgQIAAAQIECBAgQIAAAQIECBAIEjBECYK0DAECBAgQIECAAAEC
BAgQIECAAAECBAgQIDCXgCHKXPWUDQECBAgQIECAAAECBAgQIECAAAECBAgQIBAkYIgSBGkZAgQI
ECBAgAABAgQIECBAgAABAgQIECBAYC4BQ5S56ikbAgQIECBAgAABAgQIECBAgAABAgQIECBAIEjA
ECUI0jIECBAgQIAAAQIECBAgQIAAAQIECBAgQIDAXAL/A42ghxLmmMjjAAAAAElFTkSuQmCC

--_004_BYAPR05MB39417295658C832B82359CA1CD9E9BYAPR05MB3941namp_--


From nobody Thu Feb 25 11:50:12 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD93A1F28 for ; Thu, 25 Feb 2021 11:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=aq8owPcu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kSlVrnFc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59LuBCIre1uz for ; Thu, 25 Feb 2021 11:50:09 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58ECC3A1F2F for ; Thu, 25 Feb 2021 11:49:47 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B6DE55C0130 for ; Thu, 25 Feb 2021 14:49:46 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 25 Feb 2021 14:49:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=WPC4hQX4dmJN8vmZojuqYSZ/ ouaAQ/eKoF5tzomkgO8=; b=aq8owPcuX5yROVgAic3Hl3m5a/Pu45E/pBllwbPh UYsTghb6YZfbUvrCELTzDEFHB60uJnmsVosAp8hrfk3+XWNkdM7XfNZvL019VWup heICWC4I8x3QupdAPGz48L5lD3Mn7uhrAkCyIrya1CCaQNTmuTwcdagXuRUe77ta QXI=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=WPC4hQ X4dmJN8vmZojuqYSZ/ouaAQ/eKoF5tzomkgO8=; b=kSlVrnFcXS1wF1JCpK6vDf SM0p17oOWKkzNZWcfO3si5zDF+WvyxhRgvwIVSQKtcJc5P/tKNMMwOdLl1xB2akt ONjb9/DRSTA5gfZYoaCQn9TwCbD6pDcPLPHNtobemVSzOeOXz1u1ppk0Cg/VC8gJ 4NoFFm6TFGI4YnxnnQ6sJYiqHRkyivRaHT5knDO4TWKMiKB33PKbxR1JceibfjUg 1Z2Fetk1LwJkN5R4h+fnLAkF44F0DpkVe6cGG1EMxya5FEmTZIKUm0vW59Kk70l/ wy+dYZJowhJIs/YpHLb3fxdf/rB0e0z83zzR6mcBYUxZfz1C+nIo7O7D2hLIFxtw ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeelgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucggtffrrghtthgvrhhnpeethfekfeelvdejudeugeeugefgteeiheeivddvtd dtheelvddtgeduhfelheeitdenucfkphepudegvddruddviedrudeiiedrvddtjeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesvghvvg hrthhpohhtrdgtohhm
X-ME-Proxy:    
Received: from [192.168.2.61] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id EBE0824005A for ; Thu, 25 Feb 2021 14:49:45 -0500 (EST)
To: oauth@ietf.org
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com> 
From: Evert Pot 
Message-ID: <6573391f-fb72-3175-5f70-3e4c00977dc6@evertpot.com>
Date: Thu, 25 Feb 2021 14:49:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A5285F7AC20DC22826ED5776"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2021 19:50:11 -0000

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

On 2021-02-25 3:22 a.m., Seán Kelleher wrote:

> Just to clarify, I assume in this discourse that the "server" in this 
> client and server relationship refers to an AS/RS pair in OAuth 
> terminology? Based on this, one big sticking point for me on the 
> applicability of NxM, or even 1xM, is that all of the "M" RSs need to 
> publish the same interface for any meaningful implementation in the 
> first place.
>
> It probably makes more sense with email clients, since as Bron said, 
> there is the common standard of POP. If we assume that all the email 
> services that we want to connect to publish the same POP interface, 
> and would accept tokens in the same way, then the way the authZ is 
> handled is indeed the point of divergence that needs to be resolved.

The usefulness of this goes beyond standardized protocols / multiple 
implementors of an API. Some examples of what's possible with Basic 
auth, and not with OAuth2:

 1. I can point my browser to a Basic Auth-protected endpoint. I get a
    pop-up and it will let me log in.
 2. Basic auth is supported in tools like Curl.
 3. It makes generic clients more viable for things like APIs. SDKs for
    specific APIs can be helpful, but HTTP is the universal interface. I
    should be able to use a generic HTTP client and point it to a
    generic HTTP destination and for this to work.
 4. Similarly for the cases where there is a common standard
    server-side, implementors should not have to decide on an
    authentication system. If Auth is baked into the HTTP layer and
    widely supported, POP can be agnostic about how Auth is performed.
    This allows independent upgrading/decoupling of 'POP' and 'Auth'.
    Imagine if we had to update *every client* if a new TLS version is
    released? That's what OAuth2 is like now.

Evert


--------------A5285F7AC20DC22826ED5776
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 2021-02-25 3:22 a.m., Seán Kelleher wrote:

    

    

      
      

        
Just to clarify, I assume in this discourse that the
          "server" in this client and server relationship refers to an
          AS/RS pair in OAuth terminology? Based on this, one big
          sticking point for me on the applicability of NxM, or even
          1xM, is that all of the "M" RSs need to publish the same
          interface for any meaningful implementation in the first
          place.

        


        

        
It probably makes more sense with email clients, since as
          Bron said, there is the common standard of POP. If we assume
          that all the email services that we want to connect to publish
          the same POP interface, and would accept tokens in the same
          way, then the way the authZ is handled is indeed the point of
          divergence that needs to be resolved.

      

    

    
The usefulness of this goes beyond standardized protocols /
      multiple implementors of an API. Some examples of what's possible
      with Basic auth, and not with OAuth2:

    
    
      
  1. I can point my browser to a Basic Auth-protected endpoint. I
        get a pop-up and it will let me log in.
    2. 
      
  2. Basic auth is supported in tools like Curl.
    3. 
      
  3. It makes generic clients more viable for things like APIs.
        SDKs for specific APIs can be helpful, but HTTP is the universal
        interface. I should be able to use a generic HTTP client and
        point it to a generic HTTP destination and for this to work.
    4. 
      
  4. Similarly for the cases where there is a common standard
        server-side, implementors should not have to decide on an
        authentication system. If Auth is baked into the HTTP layer and
        widely supported, POP can be agnostic about how Auth is
        performed. This allows independent upgrading/decoupling of 'POP'
        and 'Auth'. Imagine if we had to update *every client* if a new
        TLS version is released? That's what OAuth2 is like now.
    5. 
    

    
Evert

    

  


--------------A5285F7AC20DC22826ED5776--


From nobody Thu Feb 25 11:59:56 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5AC3A1F44 for ; Thu, 25 Feb 2021 11:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=BjEnLtc3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eoFzI+50
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMm_xyJkFV_V for ; Thu, 25 Feb 2021 11:59:53 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753D33A1F43 for ; Thu, 25 Feb 2021 11:59:53 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BFF8A5C0143 for ; Thu, 25 Feb 2021 14:59:51 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 25 Feb 2021 14:59:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=jzfdxwV9rvxgGuMJsgOCuFKQ gcjLsBjPHx6B/J+67Ok=; b=BjEnLtc3cwxq/g71Gn0Tsrn2OJGMfI64lvoARcPb J5a387qhSrYW5pO1w+sJH2YznUAvy6BI1G69RUGXq9uRElOTEYrdE9+rdBGbi4Xo LljUwVepUwI6J4iXwVyKfih/+oVK89/Ft8p4QWB544drmD4hz7mlPIOSHmKTz0C5 XP8=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jzfdxw V9rvxgGuMJsgOCuFKQgcjLsBjPHx6B/J+67Ok=; b=eoFzI+50Jty4k9JDeMdOOQ Ztockm/oMI9Nl/6r647UXYuVH5plqJg3C2/FUKGz4t9J1kG9jLYdR8PT54nA2UJ5 t2PFd3z0Jk6vvZVGoA/VeHVmAvUU98vrZ8pBI5lFW1ztdguDGyCB8U82uwKkrXrf TALnQGjAPxsyCs8/P622X/VO98HcKxJuJOH6ZBnlLBTugaN8eQ1fTiW9uX59XO7G 1eOZYp/fjNWh7ljCWRxWS5Sbph//S4U2Oj9bjCS4117fXEnDimh4pNJc+brbQ04L S0jzoq1soBkhkGh7OaVEa52aVWwrEKKuZRskmyElsig7x59C87hYotozkLjA6HzQ ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeelgddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgt ohhmqeenucggtffrrghtthgvrhhnpeethfekfeelvdejudeugeeugefgteeiheeivddvtd dtheelvddtgeduhfelheeitdenucfkphepudegvddruddviedrudeiiedrvddtjeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesvghvvg hrthhpohhtrdgtohhm
X-ME-Proxy:    
Received: from [192.168.2.61] (unknown [142.126.166.207]) by mail.messagingengine.com (Postfix) with ESMTPA id 05A8D240065 for ; Thu, 25 Feb 2021 14:59:50 -0500 (EST)
To: oauth@ietf.org
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>  
From: Evert Pot 
Message-ID: <1c6aad47-c588-a25e-fbf6-3cf80f557a3d@evertpot.com>
Date: Thu, 25 Feb 2021 14:59:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F5B39942858CFDD54FF3E64B"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Feb 2021 19:59:55 -0000

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


On 2021-02-25 3:41 a.m., Seán Kelleher wrote:
>
>     Yep, this is the big point - OAuth is designed to require the the
>     third leg of trust that creates the NxM problem.
>
>
> I believe the snippet of Justin's that you quoted actually shows you 
> how you can forgo the trust element using dynamic client registration. 
> It still allows a "server" to identify requests and impose security 
> policies via the client ID, but without requiring the client author to 
> manually register the client in advance of using it (e.g. in the case 
> where the client author doesn't even know what servers the client is 
> going to be connecting to). You still need the client ID, but anyone 
> can get one whenever they need it.

Apologies if this a dumb question, but how would you discover the 
dynamic client registration endpoint after getting a 401 unauthorized?

I couldn't really find anything in RFC7591 about this.


--------------F5B39942858CFDD54FF3E64B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 2021-02-25 3:41 a.m., Seán Kelleher
      wrote:

    

    

      
      

        
Yep, this is the big point - OAuth
            is designed to require the the third leg of trust that
            creates the NxM problem.

        


        

        
I believe the snippet of Justin's that you quoted actually
          shows you how you can forgo the trust element using dynamic
          client registration. It still allows a "server" to identify
          requests and impose security policies via the client ID, but
          without requiring the client author to manually register the
          client in advance of using it (e.g. in the case where the
          client author doesn't even know what servers the client is
          going to be connecting to). You still need the client ID, but
          anyone can get one whenever they need it.

      

    

    
Apologies if this a dumb question, but how would you discover the
      dynamic client registration endpoint after getting a 401
      unauthorized?

    
I couldn't really find anything in RFC7591 about this.

    

  


--------------F5B39942858CFDD54FF3E64B--


From nobody Fri Feb 26 05:16:26 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678983A0597 for ; Fri, 26 Feb 2021 05:16:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rr2zY7aofRn for ; Fri, 26 Feb 2021 05:16:21 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0E83A046B for ; Fri, 26 Feb 2021 05:16:21 -0800 (PST)
Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11QDGGmg025699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 08:16:17 -0500
From: Justin Richer 
Message-Id: <23724275-78F0-4F12-9D91-C4F2BE96802A@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC8F432B-A9B8-40C6-94D6-10935E063B14"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 26 Feb 2021 08:16:16 -0500
In-Reply-To: <1c6aad47-c588-a25e-fbf6-3cf80f557a3d@evertpot.com>
Cc: oauth@ietf.org
To: Evert Pot 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <1c6aad47-c588-a25e-fbf6-3cf80f557a3d@evertpot.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 13:16:24 -0000

--Apple-Mail=_DC8F432B-A9B8-40C6-94D6-10935E063B14
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Feb 25, 2021, at 2:59 PM, Evert Pot  wrote:
> On 2021-02-25 3:41 a.m., Se=C3=A1n Kelleher wrote:
>> Yep, this is the big point - OAuth is designed to require the the =
third leg of trust that creates the NxM problem.
>>=20
>> I believe the snippet of Justin's that you quoted actually shows you =
how you can forgo the trust element using dynamic client registration. =
It still allows a "server" to identify requests and impose security =
policies via the client ID, but without requiring the client author to =
manually register the client in advance of using it (e.g. in the case =
where the client author doesn't even know what servers the client is =
going to be connecting to). You still need the client ID, but anyone can =
get one whenever they need it.
> Apologies if this a dumb question, but how would you discover the =
dynamic client registration endpoint after getting a 401 unauthorized?
>=20
> I couldn't really find anything in RFC7591 about this.
>=20
We deliberately left that level of discovery out of the registration =
spec (7591) because, as it turns out, RS-first discovery is a lot harder =
than it looks on the surface. There are some tricky privacy =
considerations around divulging an AS to an unknown party, and while not =
a dead-stop there you=E2=80=99ve got a lot of use cases where it hurts =
more than it helps.

In the end, we decided not to solve those aspects together and leave =
discovery for another spec. I think the call made sense at the time. =
Now, obviously, this assumption goes halfway out the window when you =
start doing the registration programmatically, and so discovery on a =
static relationship vs. discovery on a dynamic relationship are pretty =
different.=20

We=E2=80=99re taking a different approach in GNAP, based on work that =
was done in User Manage Access (UMA):

=
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-04.html#name=
-requesting-resources-with-i =


Caveat, there are still a lot of open questions about the details of =
this, the focus in GNAP has been on the core delegation protocol so far, =
but it=E2=80=99s on our radar and we welcome the input.

And then there=E2=80=99s the considerations about hooking up more RS=E2=80=
=99s in real time, or even having the user/client SPECIFY the AS for the =
RS to talk to. So ultimately it=E2=80=99s an NxMxP problem, with client, =
AS, and RS in each slot varying differently depending on the API in =
question. In most OAuth use cases, the AS and RS have a pre-existing =
relationship that the client doesn=E2=80=99t know or care about. The =
client=E2=80=99s just trying to =E2=80=9Ccall this API=E2=80=9D and so =
it gets configured with all the bits it needs to ahead of time when it =
gets registered. But with a common API, like POP or IMAP, the client =
just needs to know how to get to the next step to keep going.=20

This is one thing I=E2=80=99ve found security engineers simply Do Not =
Get more often than not: client developers don=E2=80=99t care about your =
security protocol. Your security is what gets in the way of them doing =
what they want to do, which is use the API and build an awesome thing. =
The simpler-to-follow we can make the security process, the better it =
will be for everyone.

 =E2=80=94 Justin=

--Apple-Mail=_DC8F432B-A9B8-40C6-94D6-10935E063B14
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
Feb 25, 2021, at 2:59 PM, Evert Pot <me@evertpot.com> wrote:

    
On 2021-02-25 3:41 a.m., Se=C3=A1n =
Kelleher
      wrote:

    

    

     =20
      

        
Yep, this is the big point - OAuth
            is designed to require the the third leg of trust that
            creates the NxM problem.

        


        

        
I believe the snippet of Justin's that you =
quoted actually
          shows you how you can forgo the trust element using dynamic
          client registration. It still allows a "server" to identify
          requests and impose security policies via the client ID, but
          without requiring the client author to manually register =
the
          client in advance of using it (e.g. in the case where the
          client author doesn't even know what servers the client is
          going to be connecting to). You still need the client ID, but
          anyone can get one whenever they need it.

      

    
Apologies if this a dumb question, but =
how would you discover the
      dynamic client registration endpoint after getting a 401
      unauthorized?
I couldn't really find anything in =
RFC7591 about this.
We =
deliberately left that level of discovery out of the registration spec =
(7591) because, as it turns out, RS-first discovery is a lot harder than =
it looks on the surface. There are some tricky privacy considerations =
around divulging an AS to an unknown party, and while not a dead-stop =
there you=E2=80=99ve got a lot of use cases where it hurts more than it =
helps.

In the end, =
we decided not to solve those aspects together and leave discovery for =
another spec. I think the call made sense at the time. Now, obviously, =
this assumption goes halfway out the window when you start doing the =
registration programmatically, and so discovery on a static relationship =
vs. discovery on a dynamic relationship are pretty =
different. 

We=E2=80=99re taking a different approach in GNAP, based on =
work that was done in User Manage Access (UMA):

https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-0=
4.html#name-requesting-resources-with-i

Caveat, there are still a lot of open =
questions about the details of this, the focus in GNAP has been on the =
core delegation protocol so far, but it=E2=80=99s on our radar and we =
welcome the input.

And then there=E2=80=99s the considerations about hooking up =
more RS=E2=80=99s in real time, or even having the user/client SPECIFY =
the AS for the RS to talk to. So ultimately it=E2=80=99s an NxMxP =
problem, with client, AS, and RS in each slot varying differently =
depending on the API in question. In most OAuth use cases, the AS and RS =
have a pre-existing relationship that the client doesn=E2=80=99t know or =
care about. The client=E2=80=99s just trying to =E2=80=9Ccall this =
API=E2=80=9D and so it gets configured with all the bits it needs to =
ahead of time when it gets registered. But with a common API, like POP =
or IMAP, the client just needs to know how to get to the next step to =
keep going. 

This is one thing I=E2=80=99ve found security engineers =
simply Do Not Get more often than not: client developers don=E2=80=99t =
care about your security protocol. Your security is what gets in the way =
of them doing what they want to do, which is use the API and build an =
awesome thing. The simpler-to-follow we can make the security process, =
the better it will be for everyone.

 =E2=80=94 =
Justin
=

--Apple-Mail=_DC8F432B-A9B8-40C6-94D6-10935E063B14--


From nobody Fri Feb 26 08:09:31 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4C23A0DEA; Fri, 26 Feb 2021 08:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfvfzvQSqDyw; Fri, 26 Feb 2021 08:09:21 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93343A0DC6; Fri, 26 Feb 2021 08:08:54 -0800 (PST)
Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11QG8k9K012576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 11:08:47 -0500
From: Justin Richer 
Message-Id: <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B35D023D-47B5-4C8B-9C65-9A8893586D5B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 26 Feb 2021 11:08:46 -0500
In-Reply-To: 
Cc: Bron Gondwana , Phillip Hallam-Baker , "oauth@ietf.org" , ietf@ietf.org
To: =?utf-8?Q?Se=C3=A1n_Kelleher?= 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>  
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 16:09:25 -0000

--Apple-Mail=_B35D023D-47B5-4C8B-9C65-9A8893586D5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Right, it=E2=80=99s possible to patch OAuth to do this, but the whole =
=E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth =
at a really core level. That=E2=80=99s one of the main reasons there=E2=80=
=99s been hesitance at deploying dynamic registration. It=E2=80=99s an =
extension that changes your trust model=E2=80=99s assumptions, and does =
so in a way that is challenging for a lot of large scale providers.

That=E2=80=99s why I personally think it=E2=80=99s really important that =
we get away from that registration model in GNAP, so we don=E2=80=99t =
repeat that same problem in the same way. Some people will still deploy =
GNAP with static registration, but this model becomes more exceptional =
than baseline. The philosophy of what=E2=80=99s considered an extension =
vs. default is important.

 =E2=80=94 Justin

> On Feb 25, 2021, at 3:41 AM, Se=C3=A1n Kelleher  =
wrote:
>=20
> Yep, this is the big point - OAuth is designed to require the the =
third leg of trust that creates the NxM problem.
>=20
> I believe the snippet of Justin's that you quoted actually shows you =
how you can forgo the trust element using dynamic client registration. =
It still allows a "server" to identify requests and impose security =
policies via the client ID, but without requiring the client author to =
manually register the client in advance of using it (e.g. in the case =
where the client author doesn't even know what servers the client is =
going to be connecting to). You still need the client ID, but anyone can =
get one whenever they need it.
>=20
> I'm also feeling a bit of confusion arising from a conflation of terms =
between the regular client/server model and the terminology used in =
OAuth. To be clear, in OAuth, the level of trust between the client and =
authZ server only really depends on policy; as mentioned, dynamic client =
registration can be used if you don't need any trust between the client =
and AS.
>=20
> On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher > wrote:
> Just to clarify, I assume in this discourse that the "server" in this =
client and server relationship refers to an AS/RS pair in OAuth =
terminology? Based on this, one big sticking point for me on the =
applicability of NxM, or even 1xM, is that all of the "M" RSs need to =
publish the same interface for any meaningful implementation in the =
first place.
>=20
> It probably makes more sense with email clients, since as Bron said, =
there is the common standard of POP. If we assume that all the email =
services that we want to connect to publish the same POP interface, and =
would accept tokens in the same way, then the way the authZ is handled =
is indeed the point of divergence that needs to be resolved.
>=20
> However, we're talking about NxM in the general case here. I feel like =
using the likes of discovery and dynamic registration, etc. that's =
already supported by OAuth, the "N" part of this equation is =
surmountable. But each of the "M" servers also need to export the same =
interface, otherwise a client is going to have to write custom code to =
deal with talking to the service after the authZ step anyway, =
reintroducing the "problem" part of the NxM problem.
>=20
> As such, I would actually suggest constraining this discussion to just =
the POP NxM problem rather than NxM in general because, for me at least, =
the authZ part of the general case is the most "solved" part of the =
problem, and the outstanding work lies more in consolidating the "M" RS =
interfaces.
>=20
> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana > wrote:
> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>> I agree that the NxM problem is the purview of the whole IETF, but =
it=E2=80=99s something that we=E2=80=99re particularly interested in =
over in GNAP. As the editor of OAuth=E2=80=99s dynamic registration =
extension and the GNAP core protocol, I hope I can add to this =
conversation.
>>=20
>> =46rom a technical standpoint, OAuth=E2=80=99s dynamic client =
registration lets arbitrary clients talk to an AS, but the trust isn=E2=80=
=99t there in practice. On top of that I think this problem is =
exacerbated by a fundamental protocol design element of OAuth: the =
client_id that=E2=80=99s required. That field means there=E2=80=99s an =
assumption that a relationship was set up between the pieces of =
software, implied to be trusted by admins at the AS. Sure you can get =
that client_id under special circumstances, but there=E2=80=99s still a =
special weight handed to that and the dynamic stuff feels like you=E2=80=99=
re giving up control as an AS. In GNAP, the relationship is inverted, =
and it=E2=80=99s designed as =E2=80=9Cdynamic-first=E2=80=9D, with =
pre-registered clients being an optimization on top of that.
>=20
> Yep, this is the big point - OAuth is designed to require the the =
third leg of trust that creates the NxM problem.
>=20
>=20
> 
>=20
> If that dotted line between client and server requires a pre-existing =
trust relationship rather than the trust being entirely mediated by the =
user choosing to connect client A with server B, then you have the NxM =
problem.  This is the "you can only have your John Deere tractor =
serviced by an approved John Deere service centre" problem.  You can =
only use this client with servers who have pre-approved it.  Or fall =
back to the "cash of the internet" - plain text passwords.
>=20
>> Does this solve the NxM problem? No, because companies are still =
going to decide that they only talk to keys or identifiers that they =
know ahead of time. But the protocol puts the dynamic case forward as =
baseline and fits in much better with the likes of JMAP than OAuth ever =
could:
>>=20
>> - {The Bat} creates a key pair.
>> - {User} enters their email address into {Bat}, {Bat} does discovery =
(maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP =
server and the GNAP endpoint for authentication as an option.
>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just =
made up. {ISP} has never seen this key, but knows how to talk GNAP and =
get the user to authorize {Bat} to access email.
>> - {User} does this using GNAP and gets back an access token that=E2=80=99=
s tied to the key {Bat} made back at the beginning. That token is tied =
(at the {ISP}) to the user=E2=80=99s account.
>>=20
>> Yes, you can do all of this today with OAuth (and people have done =
so), but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and =
registration first and THEN talk to me=E2=80=9D is a trust impediment =
more than it is a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D =
part of the GNAP name comes from the philosophy of =E2=80=9Cstart =
talking first and figure out what you need as you go=E2=80=9D. Instead =
of jumping through hoops to get something you can trust, you just start =
in and then decide how much you trust it. A corporate rollout could use =
its own key distribution mechanism and static registration to limit =
which client instances talk back to the company server, regardless of =
which accounts would authorize access on top of that. An internet-facing =
service is going to be more likely to take a TLS approach, of =E2=80=9CI=E2=
=80=99ll talk to you in a secure fashion without caring who you are =
right now=E2=80=9D.
>>=20
>> We really are trying to make GNAP a consistent protocol at its core =
and learn from problems with OAuth in the wild, all while letting GNAP =
address a wider variety of use cases. I agree that GNAP could be clearer =
about specific use cases, and we=E2=80=99re working on the spec still so =
any help here is appreciated.=20
>=20
> Excellent.  This is precisely what I've been waiting for for these =
very many years as a viable replacement for storing a password locally =
on disk.  Just having the server able to distinguish between different =
client instances for the same user is a big start, because you can =
de-authorise one without having to lock out every connection - even if =
the user is still entering their password during the setup phase each =
time.
>=20
> This is what Fastmail already do with our own app, creating a =
long-lived access token and storing that on the device rather than =
storing the password itself - and you can log out any one client from =
your security settings page.  What's missing is a standard way to do =
that with any IMAP client.  The initial JMAP authentication proposal was =
a very simple case of pretty much this, build into to the protocol so =
everyone would do it.
>=20
> Making it easy to connect up arbitrary clients with per-client tokens =
the default, and easy rather than almost impossible to do in practice is =
where the big difference comes in.
>=20
> Bron.
>=20
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com 
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =



--Apple-Mail=_B35D023D-47B5-4C8B-9C65-9A8893586D5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Right, it=E2=80=99s possible to patch OAuth to do this, but =
the whole =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked =
into OAuth at a really core level. That=E2=80=99s one of the main =
reasons there=E2=80=99s been hesitance at deploying dynamic =
registration. It=E2=80=99s an extension that changes your trust =
model=E2=80=99s assumptions, and does so in a way that is challenging =
for a lot of large scale providers.

That=E2=80=99s why I personally think =
it=E2=80=99s really important that we get away from that registration =
model in GNAP, so we don=E2=80=99t repeat that same problem in the same =
way. Some people will still deploy GNAP with static registration, but =
this model becomes more exceptional than baseline. The philosophy of =
what=E2=80=99s considered an extension vs. default is =
important.

 =E2=80=94 Justin

On Feb =
25, 2021, at 3:41 AM, Se=C3=A1n Kelleher <sean@trustap.com> =
wrote:

Yep, this is the big point - OAuth is designed to require the =
the third leg of trust that creates the NxM =
problem.

I believe the snippet of Justin's that you quoted actually =
shows you how you can forgo the trust element using dynamic client =
registration. It still allows a "server" to identify requests and impose =
security policies via the client ID, but without requiring the =
client author to manually register the client in advance of using it =
(e.g. in the case where the client author doesn't even know what servers =
the client is going to be connecting to). You still need the client ID, =
but anyone can get one whenever they need it.

I'm also feeling a bit of confusion =
arising from a conflation of terms between the regular client/server =
model and the terminology used in OAuth. To be clear, in OAuth, the =
level of trust between the client and authZ server only really depends =
on policy; as mentioned, dynamic client registration can be used if you =
don't need any trust between the client and AS.

On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher =
<sean@trustap.com> wrote:
Just to clarify, I assume in this discourse that the "server" =
in this client and server relationship refers to an AS/RS pair in OAuth =
terminology? Based on this, one big sticking point for me on the =
applicability of NxM, or even 1xM, is that all of the "M" RSs need to =
publish the same interface for any meaningful implementation in the =
first place.

It =
probably makes more sense with email clients, since as Bron said, there =
is the common standard of POP. If we assume that all the email services =
that we want to connect to publish the same POP interface, and would =
accept tokens in the same way, then the way the authZ is handled is =
indeed the point of divergence that needs to be resolved.

However, we're talking =
about NxM in the general case here. I feel like using the likes of =
discovery and dynamic registration, etc. that's already supported by =
OAuth, the "N" part of this equation is surmountable. But each =
of the "M" servers also need to export the same interface, otherwise a =
client is going to have to write custom code to deal with talking to the =
service after the authZ step anyway, reintroducing the "problem" part of =
the NxM problem.

As such, I would actually suggest constraining this =
discussion to just the POP NxM problem rather than NxM in general =
because, for me at least, the authZ part of the general case is the most =
"solved" part of the problem, and the outstanding work lies more in =
consolidating the "M" RS interfaces.

On Wed, 24 =
Feb 2021 at 22:32, Bron Gondwana <brong@fastmailteam.com> wrote:
On Thu, Feb 25, 2021, at 02:18, =
Justin Richer wrote:
I agree that the NxM problem is the purview =
of the whole IETF, but it=E2=80=99s something that we=E2=80=99re =
particularly interested in over in GNAP. As the editor of OAuth=E2=80=99s =
dynamic registration extension and the GNAP core protocol, I hope I can =
add to this conversation.

=46rom a technical standpoint, =
OAuth=E2=80=99s dynamic client registration lets arbitrary clients talk =
to an AS, but the trust isn=E2=80=99t there in practice. On top of that =
I think this problem is exacerbated by a fundamental protocol design =
element of OAuth: the client_id that=E2=80=99s required. That field =
means there=E2=80=99s an assumption that a relationship was set up =
between the pieces of software, implied to be trusted by admins at the =
AS. Sure you can get that client_id under special circumstances, but =
there=E2=80=99s still a special weight handed to that and the dynamic =
stuff feels like you=E2=80=99re giving up control as an AS. In GNAP, the =
relationship is inverted, and it=E2=80=99s designed as =
=E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an =
optimization on top of that.

Yep, this is the big point - =
OAuth is designed to require the the third leg of trust that creates the =
NxM problem.


<image.png>

If that dotted line between =
client and server requires a pre-existing trust relationship rather than =
the trust being entirely mediated by the user choosing to connect client =
A with server B, then you have the NxM problem.  This is the "you =
can only have your John Deere tractor serviced by an approved John Deere =
service centre" problem.  You can only use this client with servers =
who have pre-approved it.  Or fall back to the "cash of the =
internet" - plain text passwords.

Does this solve the NxM problem? No, because =
companies are still going to decide that they only talk to keys or =
identifiers that they know ahead of time. But the protocol puts the =
dynamic case forward as baseline and fits in much better with the likes =
of JMAP than OAuth ever could:

- {The Bat} creates a key pair.
- {User} enters their email address =
into {Bat}, {Bat} does discovery (maybe that=E2=80=99s a JMAP thing? =
Webfinger?) and finds the JMAP server and the GNAP endpoint for =
authentication as an option.
- {Bat} =
talks to the GNAP AS at {ISP} and presents the key it just made up. =
{ISP} has never seen this key, but knows how to talk GNAP and get the =
user to authorize {Bat} to access email.
- {User} does this using GNAP and gets back an access token =
that=E2=80=99s tied to the key {Bat} made back at the beginning. That =
token is tied (at the {ISP}) to the user=E2=80=99s account.

Yes,=
 you can do all of this today with OAuth (and people have done so), but =
OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registration =
first and THEN talk to me=E2=80=9D is a trust impediment more than it is =
a technical impediment. The =E2=80=9Cnegotiation=E2=80=9D part of the =
GNAP name comes from the philosophy of =E2=80=9Cstart talking first and =
figure out what you need as you go=E2=80=9D. Instead of jumping through =
hoops to get something you can trust, you just start in and then decide =
how much you trust it. A corporate rollout could use its own key =
distribution mechanism and static registration to limit which client =
instances talk back to the company server, regardless of which accounts =
would authorize access on top of that. An internet-facing service is =
going to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll =
talk to you in a secure fashion without caring who you are right =
now=E2=80=9D.

We really are trying to make GNAP a =
consistent protocol at its core and learn from problems with OAuth in =
the wild, all while letting GNAP address a wider variety of use cases. I =
agree that GNAP could be clearer about specific use cases, and we=E2=80=99=
re working on the spec still so any help here is appreciated. 

Excellent.  This is precisely what I've been waiting for =
for these very many years as a viable replacement for storing a password =
locally on disk.  Just having the server able to distinguish =
between different client instances for the same user is a big start, =
because you can de-authorise one without having to lock out every =
connection - even if the user is still entering their password during =
the setup phase each time.

This is what Fastmail already do =
with our own app, creating a long-lived access token and storing that on =
the device rather than storing the password itself - and you can log out =
any one client from your security settings page.  What's missing is =
a standard way to do that with any IMAP client.  The initial JMAP =
authentication proposal was a very simple case of pretty much this, =
build into to the protocol so everyone would do it.

Making it =
easy to connect up arbitrary clients with per-client tokens the default, =
and easy rather than almost impossible to do in practice is where the =
big difference comes in.

Bron.

--
  =
Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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







=

--Apple-Mail=_B35D023D-47B5-4C8B-9C65-9A8893586D5B--


From nobody Fri Feb 26 08:22:36 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D243A0EF0 for ; Fri, 26 Feb 2021 08:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1VpxYb7rwOz for ; Fri, 26 Feb 2021 08:22:31 -0800 (PST)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C633A0ED3 for ; Fri, 26 Feb 2021 08:22:31 -0800 (PST)
Received: by mail-il1-x131.google.com with SMTP id v8so4838729ilh.12 for ; Fri, 26 Feb 2021 08:22:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKsmtjF6uzdq0aCiqTPvex2SMjNFMgJWrC6sZZ/sGJk=; b=CZ6eCt/R4z8DeESEx1P4NDs6KL+OJQ0UYOSCh7794AC2EfhPIWckrKRNRKvA5FSvq1 U9z7wI9l8DsaIsRTEJIeTEd/88ot1yhV9XJXg5ce5e5yw8X9ZJ68ofNV+CsKHfFhlF9S OoK8baImhJL6a5XKDs/Q173t/Rax8iFEDz+OnL6kb4HSBe6P7x1dMzxf0+Nq2iZ9qhNz 9kOw2Uj/jpGI8Z8qLgFYNmtIEJbUkNmcb5NFzSqu/1bpw9bbxScPtFRkZocbcKglF39P ceWyjgWGpgNxJxWwJicBT5YrGNts0Xva1r+BkH6ETOjL4GL4SLGUcsw5b25Cw+GugV67 nz6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKsmtjF6uzdq0aCiqTPvex2SMjNFMgJWrC6sZZ/sGJk=; b=a8VdBTsslqmHaOhNvox5Yupn/pXtSmdUaRjS+7B8CkDjGEERaFG17bYWYOCAbEG05I vQL9llUrA/hxsFqxjpfoRVQGuhRG2MnR2+mbHxXxxYs4fgSY3JSPpBS+6OmwTSjRlJIr CzZkZPd7/HcXW9wXnD5aRaooSs3KjWdlNYUjMas4kV8AMGQNJY4oZwtP722gCIJkzsHd hfjS22kgHgG8eBCzbGBp3Sc41BhWKSTHJRAfrgDXKPJB5bU6mzVY6Rwzvp/twgZWgiHH 80mFznLtFFZNeJ8XGRX7UIJeifY+FEtP5F/mCZh/vWvX5HIzr2rO8lKvZUPINbV/qHnl 3Piw==
X-Gm-Message-State: AOAM5312/+a7xqUAXcoGmAbXo0Q9GI5CaDlWDrgKt2VD17G3KVup0BFZ l5GjPSv2k7+3W8wS6qloQFBbno5ZFWWq/U0cnv/u
X-Google-Smtp-Source: ABdhPJxXg6dWYtHOlDnyAFZ6z65hO8lPX+8ilhxemPwoERkc+iwhKssqm4ZRdfF0m9atovk4azCo1vHJCkTiKbaXmMk=
X-Received: by 2002:a92:c6ca:: with SMTP id v10mr3084720ilm.195.1614356550568;  Fri, 26 Feb 2021 08:22:30 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>
In-Reply-To: <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>
From: Warren Parad 
Date: Fri, 26 Feb 2021 17:22:19 +0100
Message-ID: 
To: Justin Richer 
Cc: =?UTF-8?Q?Se=C3=A1n_Kelleher?= ,  Bron Gondwana , Phillip Hallam-Baker ,  "oauth@ietf.org" , IETF-Discussion Discussion 
Content-Type: multipart/alternative; boundary="000000000000bcdf7505bc3facf2"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 16:22:35 -0000

--000000000000bcdf7505bc3facf2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A) I don't think it is helpful to talk about what other WGs are doing, or
how GNAP attempts to fix or not fix these problems.
B) Sharing statements like this:

> Right, it=E2=80=99s possible to patch OAuth to do this, but the whole
> =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth a=
t a really core
> level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesita=
nce at deploying
> dynamic registration

Don't help everyone come to the same conclusion, Who is "we" here, it begs
the question "is there a mindset baked into OAuth", I think to work
effectively we need to be talking about how to best to tackle challenges
everyone and anyone brings up and not fallback on arbitrary statements. It
would be one thing to point to a document which outlines the exact issues
with dynamic registration and then we could potentially have a valuable
conversation about "are those reasons still relevant or do we need to
revisit."

Right now it seems there is "Someone in the past decided this was a bad
idea, so we can't do it", rather than actually having the conversation
about it.

Just based on the conversation, it seems like the obvious right thing to do
is provide dynamic registration in OAuth. Will client developers do the
wrong thing, sure. Might it be challenging to support in a simple way,
maybe. But having the addition to OAuth to solve the problem is better than
nothing, and further it starts to change the mindset that dynamic
registration is and should be provided when appropriate.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Fri, Feb 26, 2021 at 5:11 PM Justin Richer  wrote:

> Right, it=E2=80=99s possible to patch OAuth to do this, but the whole
> =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth a=
t a really core
> level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesita=
nce at deploying
> dynamic registration. It=E2=80=99s an extension that changes your trust m=
odel=E2=80=99s
> assumptions, and does so in a way that is challenging for a lot of large
> scale providers.
>
> That=E2=80=99s why I personally think it=E2=80=99s really important that =
we get away from
> that registration model in GNAP, so we don=E2=80=99t repeat that same pro=
blem in
> the same way. Some people will still deploy GNAP with static registration=
,
> but this model becomes more exceptional than baseline. The philosophy of
> what=E2=80=99s considered an extension vs. default is important.
>
>  =E2=80=94 Justin
>
> On Feb 25, 2021, at 3:41 AM, Se=C3=A1n Kelleher  wrote:
>
> Yep, this is the big point - OAuth is designed to require the the third
>> leg of trust that creates the NxM problem.
>
>
> I believe the snippet of Justin's that you quoted actually shows you how
> you can forgo the trust element using dynamic client registration. It sti=
ll
> allows a "server" to identify requests and impose security policies via t=
he
> client ID, but without requiring the client author to manually register t=
he
> client in advance of using it (e.g. in the case where the client author
> doesn't even know what servers the client is going to be connecting to).
> You still need the client ID, but anyone can get one whenever they need i=
t.
>
> I'm also feeling a bit of confusion arising from a conflation of terms
> between the regular client/server model and the terminology used in OAuth=
.
> To be clear, in OAuth, the level of trust between the client and authZ
> server only really depends on policy; as mentioned, dynamic client
> registration can be used if you don't need any trust between the client a=
nd
> AS.
>
> On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher  wrote=
:
>
>> Just to clarify, I assume in this discourse that the "server" in this
>> client and server relationship refers to an AS/RS pair in OAuth
>> terminology? Based on this, one big sticking point for me on the
>> applicability of NxM, or even 1xM, is that all of the "M" RSs need to
>> publish the same interface for any meaningful implementation in the firs=
t
>> place.
>>
>> It probably makes more sense with email clients, since as Bron said,
>> there is the common standard of POP. If we assume that all the email
>> services that we want to connect to publish the same POP interface, and
>> would accept tokens in the same way, then the way the authZ is handled i=
s
>> indeed the point of divergence that needs to be resolved.
>>
>> However, we're talking about NxM in the general case here. I feel like
>> using the likes of discovery and dynamic registration, etc. that's alrea=
dy
>> supported by OAuth, the "N" part of this equation is surmountable. But e=
ach
>> of the "M" servers also need to export the same interface, otherwise a
>> client is going to have to write custom code to deal with talking to the
>> service after the authZ step anyway, reintroducing the "problem" part of
>> the NxM problem.
>>
>> As such, I would actually suggest constraining this discussion to just
>> the POP NxM problem rather than NxM in general because, for me at least,
>> the authZ part of the general case is the most "solved" part of the
>> problem, and the outstanding work lies more in consolidating the "M" RS
>> interfaces.
>>
>> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana 
>> wrote:
>>
>>> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>>>
>>> I agree that the NxM problem is the purview of the whole IETF, but it=
=E2=80=99s
>>> something that we=E2=80=99re particularly interested in over in GNAP. A=
s the editor
>>> of OAuth=E2=80=99s dynamic registration extension and the GNAP core pro=
tocol, I
>>> hope I can add to this conversation.
>>>
>>> From a technical standpoint, OAuth=E2=80=99s dynamic client registratio=
n lets
>>> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in p=
ractice. On
>>> top of that I think this problem is exacerbated by a fundamental protoc=
ol
>>> design element of OAuth: the client_id that=E2=80=99s required. That fi=
eld means
>>> there=E2=80=99s an assumption that a relationship was set up between th=
e pieces of
>>> software, implied to be trusted by admins at the AS. Sure you can get t=
hat
>>> client_id under special circumstances, but there=E2=80=99s still a spec=
ial weight
>>> handed to that and the dynamic stuff feels like you=E2=80=99re giving u=
p control as
>>> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed=
 as
>>> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an o=
ptimization on top
>>> of that.
>>>
>>>
>>> Yep, this is the big point - OAuth is designed to require the the third
>>> leg of trust that creates the NxM problem.
>>>
>>>
>>> 
>>>
>>> If that dotted line between client and server requires a pre-existing
>>> trust relationship rather than the trust being entirely mediated by the
>>> user choosing to connect client A with server B, then you have the NxM
>>> problem.  This is the "you can only have your John Deere tractor servic=
ed
>>> by an approved John Deere service centre" problem.  You can only use th=
is
>>> client with servers who have pre-approved it.  Or fall back to the "cas=
h of
>>> the internet" - plain text passwords.
>>>
>>> Does this solve the NxM problem? No, because companies are still going
>>> to decide that they only talk to keys or identifiers that they know ahe=
ad
>>> of time. But the protocol puts the dynamic case forward as baseline and
>>> fits in much better with the likes of JMAP than OAuth ever could:
>>>
>>> - {The Bat} creates a key pair.
>>> - {User} enters their email address into {Bat}, {Bat} does discovery
>>> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP serv=
er and the
>>> GNAP endpoint for authentication as an option.
>>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
>>> up. {ISP} has never seen this key, but knows how to talk GNAP and get t=
he
>>> user to authorize {Bat} to access email.
>>> - {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied
>>> to the key {Bat} made back at the beginning. That token is tied (at the
>>> {ISP}) to the user=E2=80=99s account.
>>>
>>> Yes, you can do all of this today with OAuth (and people have done so),
>>> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registr=
ation first and THEN
>>> talk to me=E2=80=9D is a trust impediment more than it is a technical i=
mpediment.
>>> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the =
philosophy of =E2=80=9Cstart
>>> talking first and figure out what you need as you go=E2=80=9D. Instead =
of jumping
>>> through hoops to get something you can trust, you just start in and the=
n
>>> decide how much you trust it. A corporate rollout could use its own key
>>> distribution mechanism and static registration to limit which client
>>> instances talk back to the company server, regardless of which accounts
>>> would authorize access on top of that. An internet-facing service is go=
ing
>>> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk=
 to you in a secure
>>> fashion without caring who you are right now=E2=80=9D.
>>>
>>> We really are trying to make GNAP a consistent protocol at its core and
>>> learn from problems with OAuth in the wild, all while letting GNAP addr=
ess
>>> a wider variety of use cases. I agree that GNAP could be clearer about
>>> specific use cases, and we=E2=80=99re working on the spec still so any =
help here is
>>> appreciated.
>>>
>>>
>>> Excellent.  This is precisely what I've been waiting for for these very
>>> many years as a viable replacement for storing a password locally on di=
sk.
>>> Just having the server able to distinguish between different client
>>> instances for the same user is a big start, because you can de-authoris=
e
>>> one without having to lock out every connection - even if the user is s=
till
>>> entering their password during the setup phase each time.
>>>
>>> This is what Fastmail already do with our own app, creating a long-live=
d
>>> access token and storing that on the device rather than storing the
>>> password itself - and you can log out any one client from your security
>>> settings page.  What's missing is a standard way to do that with any IM=
AP
>>> client.  The initial JMAP authentication proposal was a very simple cas=
e of
>>> pretty much this, build into to the protocol so everyone would do it.
>>>
>>> Making it easy to connect up arbitrary clients with per-client tokens
>>> the default, and easy rather than almost impossible to do in practice i=
s
>>> where the big difference comes in.
>>>
>>> Bron.
>>>
>>> --
>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>   brong@fastmailteam.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
>

--000000000000bcdf7505bc3facf2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


A) I don't think it is helpful to talk about what othe=
r WGs are doing, or how GNAP attempts to fix or not fix these problems.B) Sharing statements like this:
Right, it=E2=80=99s possible to patch OAuth to do this, but t=
he whole =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into =
OAuth at a really core level. That=E2=80=99s one of the main reasons there=
=E2=80=99s been hesitance at deploying dynamic registration
Don't help everyone come to the same conclusion, Who is "we"=
; here, it begs the question "is there a mindset baked into OAuth"=
;, I think to work effectively we need to be talking about how to best to t=
ackle challenges everyone and anyone brings up and not fallback on arbitrar=
y statements. It would be one thing to point to a document which outlines t=
he exact issues with dynamic registration and then we could potentially=C2=
=A0have a valuable conversation about "are those reasons still relevan=
t or do we need to revisit."

Right now it see=
ms there is "Someone in the past decided this was a bad idea, so we ca=
n't do it", rather than actually having the conversation about it.=


Just based on the conversation, it seems like the=
 obvious right thing to do is provide dynamic registration in OAuth. Will c=
lient developers do the wrong thing, sure. Might it be challenging to suppo=
rt in a simple way, maybe. But having the addition to OAuth to solve the pr=
oblem is better than nothing, and further it starts to change the mindset t=
hat dynamic registration is and should be provided when appropriate.
<=
div>
<=
/colgroup>
Warren Parad
F=
ounder, CTO
Secure your user data with IAM authorization as a service. Im=
plement=C2=A0Authress.


On Fri, Feb 26, 2021 at 5:11 PM Justin R=
icher <jricher@mit.edu> wrote:=

Right, it=E2=80=99s possible to patch OAuth to d=
o this, but the whole =E2=80=9Cregistration equals trust=E2=80=9D mindset i=
s baked into OAuth at a really core level. That=E2=80=99s one of the main r=
easons there=E2=80=99s been hesitance at deploying dynamic registration. It=
=E2=80=99s an extension that changes your trust model=E2=80=99s assumptions=
, and does so in a way that is challenging for a lot of large scale provide=
rs.

That=E2=80=99s why I personally think it=E2=80=99s r=
eally important that we get away from that registration model in GNAP, so w=
e don=E2=80=99t repeat that same problem in the same way. Some people will =
still deploy GNAP with static registration, but this model becomes more exc=
eptional than baseline. The philosophy of what=E2=80=99s considered an exte=
nsion vs. default is important.

=C2=A0=E2=80=94 Ju=
stin

On Feb 25, 2021, at 3:41 AM=
, Se=C3=A1n Kelleher <sean@trustap.com> wrote:

Yep, this is the big point - OAuth is designed to require the the third le=
g of trust that creates the NxM problem.

=

I believe the snippet of Justin's that you quoted actually shows y=
ou how you can forgo the trust element using dynamic client registration. I=
t still allows a "server" to identify requests and impose securit=
y policies via the client ID, but without requiring=C2=A0the client author =
to manually register the client in advance of using it (e.g. in the case wh=
ere the client author doesn't even know what servers the client is goin=
g to be connecting to). You still need the client ID, but anyone can get on=
e whenever they need it.

I'm also feeling a bi=
t of confusion arising from a conflation of terms between the regular clien=
t/server model and the terminology used in OAuth. To be clear, in OAuth, th=
e level of trust between the client and authZ server only really depends on=
 policy; as mentioned, dynamic client registration can be used if you don&#=
39;t need any trust between the client and AS.

On Thu, 25 Feb 2021 at =
08:22, Se=C3=A1n Kelleher <sean@trustap.com> wrote:
Just to clarify, I assume in=
 this discourse that the "server" in this client and server relat=
ionship refers to an AS/RS pair in OAuth terminology? Based on this, one bi=
g sticking=C2=A0point for me on the applicability of NxM, or even 1xM, is t=
hat all of the "M" RSs need to publish the same interface for any=
 meaningful implementation in the first place.

It =
probably makes more sense with email clients, since as Bron said, there is =
the common standard of POP. If we assume that all the email services that w=
e want to connect to publish the same POP interface, and would accept token=
s in the same way, then the way the authZ is handled is indeed the point of=
 divergence that needs to be resolved.

However, we=
're talking about NxM in the general=C2=A0case here. I feel like using =
the likes of discovery and dynamic registration, etc. that's already su=
pported by OAuth, the "N" part of this=C2=A0equation=C2=A0is surm=
ountable. But each of the "M" servers also need to export the sam=
e interface, otherwise a client is going to have to write custom code to de=
al with talking to the service after the authZ step anyway, reintroducing t=
he "problem" part of the NxM problem.

As=
 such, I would actually suggest constraining this discussion to just the PO=
P NxM problem rather than NxM in general because, for me at least, the auth=
Z part of the general case is the most "solved" part of the probl=
em, and the outstanding work lies more in consolidating the "M" R=
S interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <brong@fastmailteam.com=
> wrote:
=

On Thu, Feb 25, 2021, at 02:18=
, Justin Richer wrote:
=

I agree that the NxM problem is the purview of the whole IETF, but it=
=E2=80=99s something that we=E2=80=99re particularly interested in over in =
GNAP. As the editor of OAuth=E2=80=99s dynamic registration extension and t=
he GNAP core protocol, I hope I can add to this conversation.

From a technical standpoint, OAuth=E2=80=99s dynamic client=
 registration lets arbitrary clients talk to an AS, but the trust isn=E2=80=
=99t there in practice. On top of that I think this problem is exacerbated =
by a fundamental protocol design element of OAuth: the client_id that=E2=80=
=99s required. That field means there=E2=80=99s an assumption that a relati=
onship was set up between the pieces of software, implied to be trusted by =
admins at the AS. Sure you can get that client_id under special circumstanc=
es, but there=E2=80=99s still a special weight handed to that and the dynam=
ic stuff feels like you=E2=80=99re giving up control as an AS. In GNAP, the=
 relationship is inverted, and it=E2=80=99s designed as =E2=80=9Cdynamic-fi=
rst=E2=80=9D, with pre-registered clients being an optimization on top of t=
hat.

Yep, this is the big point - OAuth is designed =
to require the the third leg of trust that creates the NxM problem.


<image.png>

If that dotted line between client and server requires a pre-existi=
ng trust relationship rather than the trust being entirely mediated by the =
user choosing to connect client A with server B, then you have the NxM prob=
lem.=C2=A0 This is the "you can only have your John Deere tractor serv=
iced by an approved John Deere service centre" problem.=C2=A0 You can =
only use this client with servers who have pre-approved it.=C2=A0 Or fall b=
ack to the "cash of the internet" - plain text passwords.

Does this solve the NxM problem? No, because companies =
are still going to decide that they only talk to keys or identifiers that t=
hey know ahead of time. But the protocol puts the dynamic case forward as b=
aseline and fits in much better with the likes of JMAP than OAuth ever coul=
d:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does discovery (ma=
ybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP server and =
the GNAP endpoint for authentication as an option.
- {Bat} ta=
lks to the GNAP AS at {ISP} and presents the key it just made up. {ISP} has=
 never seen this key, but knows how to talk GNAP and get the user to author=
ize {Bat} to access email.
- {User} does this using GNAP and =
gets back an access token that=E2=80=99s tied to the key {Bat} made back at=
 the beginning. That token is tied (at the {ISP}) to the user=E2=80=99s acc=
ount.

Yes, you can do all of this today with O=
Auth (and people have done so), but OAuth=E2=80=99s basic model of =E2=80=
=9Cgo do discovery and registration first and THEN talk to me=E2=80=9D is a=
 trust impediment more than it is a technical impediment. The =E2=80=9Cnego=
tiation=E2=80=9D part of the GNAP name comes from the philosophy of =E2=80=
=9Cstart talking first and figure out what you need as you go=E2=80=9D. Ins=
tead of jumping through hoops to get something you can trust, you just star=
t in and then decide how much you trust it. A corporate rollout could use i=
ts own key distribution mechanism and static registration to limit which cl=
ient instances talk back to the company server, regardless of which account=
s would authorize access on top of that. An internet-facing service is goin=
g to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk t=
o you in a secure fashion without caring who you are right now=E2=80=9D.

We really are trying to make GNAP a consistent p=
rotocol at its core and learn from problems with OAuth in the wild, all whi=
le letting GNAP address a wider variety of use cases. I agree that GNAP cou=
ld be clearer about specific use cases, and we=E2=80=99re working on the sp=
ec still so any help here is appreciated.=C2=A0

Exce=
llent.=C2=A0 This is precisely what I've been waiting for for these ver=
y many years as a viable replacement for storing a password locally on disk=
.=C2=A0 Just having the server able to distinguish between different client=
 instances for the same user is a big start, because you can de-authorise o=
ne without having to lock out every connection - even if the user is still =
entering their password during the setup phase each time.

This is=
 what Fastmail already do with our own app, creating a long-lived access to=
ken and storing that on the device rather than storing the password itself =
- and you can log out any one client from your security settings page.=C2=
=A0 What's missing is a standard way to do that with any IMAP client.=
=C2=A0 The initial JMAP authentication proposal was a very simple case of p=
retty much this, build into to the protocol so everyone would do it.

Making it easy to connect up arbitrary clients with per-client tokens t=
he default, and easy rather than almost impossible to do in practice is whe=
re the big difference comes in.
<=
br>
Bron.

--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





__________________________________=
_____________

OAuth mailing list

OAuth@ietf.org

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



--000000000000bcdf7505bc3facf2--


From nobody Fri Feb 26 08:32:12 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C5B3A1007 for ; Fri, 26 Feb 2021 08:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl0i3klB6BRL for ; Fri, 26 Feb 2021 08:32:09 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84DA23A0FD1 for ; Fri, 26 Feb 2021 08:32:08 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id 2so6738002ljr.5 for ; Fri, 26 Feb 2021 08:32:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CJDhQfm46zO9SyWCIwXLJpD6etya0RMj0zy0bLfiuss=; b=SNOorr/ef0xsyRp0lsLpsRfoGHX14bdVkY5LF6e02Yg3hjcljmoHxHESIbPQuAZSz2 zd48jDQwiWN1N/HapwSnl5oxaj6G7D8nZgUaLgQAM7NH5O0O2kFYIl4lEoNazzqEaWFF tOD4aKOBK3X8N1e/X1YvWyBu2DmUXeA8VadDgHuwJ4QPAPbEH33ZnYHjY66MUnU6lz5t MOCUuAxEJkssid4uYsTUoS1RR5GQdtNhFVsYEO8beSybLyBiYNLCTIrjo+mVM4RHGXyl iC4cuVxpwl747/ktS5psAp789KILMV3XaDpWVCfjxk7ASzbCh+yaxA3L/6b57IoIAR+4 HK1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CJDhQfm46zO9SyWCIwXLJpD6etya0RMj0zy0bLfiuss=; b=IRA5sbXVp4tqgw3kn7e2ovmTWYoQY+ulEGmPLWb27dBw1lzIl/sna/UrhLZ+2zvs3Y NcSkCujW63oAY6VCWZZaZfOjCPkGbg7oq4rnLZNPTfHynyccbCSUYlLC8UE/njZNnRL1 FtG2pOJvcX83I+l0SstZIrF2qXEh2SdTWKo5cQDYr3Jfu6kBqV9W0phkElpvguBP6uQ2 4K7BNUgjiyNVpooAByFVj0p1Ppx+RA32ErfszhK9Zeqn6DDEjGBkOmVsywR08RXI2sTU lfIbyi/QX3m47OGOJ3i0nlTH4BRTJXlsOwghSJh6BxxlOM8BeYCSOsZHg4Bhm+cfq8dE jQZA==
X-Gm-Message-State: AOAM531Ls3B5+D24uVE17RWnR44YBhpKQGkI95NjKMsoImci/p/JC+eR QXLyrdouA/dYbYsd8vjJiU7o/x4Vvl/BL/xIxWRkPQ==
X-Google-Smtp-Source: ABdhPJx3sIh8CHNRqXzFMTKyMzfMXUhomqJIM8O61/p+RMHbXQb9Ju8aeTV4BB2p5OBPlL1z4Aw1KVnqH6jc+cmWtIw=
X-Received: by 2002:a2e:b80c:: with SMTP id u12mr2236434ljo.154.1614357126716;  Fri, 26 Feb 2021 08:32:06 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>
In-Reply-To: <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>
From: Tim Bray 
Date: Fri, 26 Feb 2021 08:31:55 -0800
Message-ID: 
To: Justin Richer 
Cc: =?UTF-8?Q?Se=C3=A1n_Kelleher?= ,  Phillip Hallam-Baker , "oauth@ietf.org" , IETF-Discussion Discussion 
Content-Type: multipart/alternative; boundary="00000000000014372505bc3fcff0"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 16:32:12 -0000

--00000000000014372505bc3fcff0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 26, 2021 at 8:10 AM Justin Richer  wrote:

> Right, it=E2=80=99s possible to patch OAuth to do this, but the whole
> =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth a=
t a really core
> level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesita=
nce at deploying
> dynamic registration. It=E2=80=99s an extension that changes your trust m=
odel=E2=80=99s
> assumptions, and does so in a way that is challenging for a lot of large
> scale providers.
>

Justin is correct but being extremely diplomatic. =E2=80=9CThere=E2=80=99s =
been hesitance=E2=80=9D,
as he puts it, translates in practice to some lawyer or VP saying =E2=80=9C=
You want
to accept auth assertions for business transactions from unknown parties?
I have no interest in jail time, so forget it.=E2=80=9D



>
> That=E2=80=99s why I personally think it=E2=80=99s really important that =
we get away from
> that registration model in GNAP, so we don=E2=80=99t repeat that same pro=
blem in
> the same way. Some people will still deploy GNAP with static registration=
,
> but this model becomes more exceptional than baseline. The philosophy of
> what=E2=80=99s considered an extension vs. default is important.
>
>  =E2=80=94 Justin
>
> On Feb 25, 2021, at 3:41 AM, Se=C3=A1n Kelleher  wrote:
>
> Yep, this is the big point - OAuth is designed to require the the third
>> leg of trust that creates the NxM problem.
>
>
> I believe the snippet of Justin's that you quoted actually shows you how
> you can forgo the trust element using dynamic client registration. It sti=
ll
> allows a "server" to identify requests and impose security policies via t=
he
> client ID, but without requiring the client author to manually register t=
he
> client in advance of using it (e.g. in the case where the client author
> doesn't even know what servers the client is going to be connecting to).
> You still need the client ID, but anyone can get one whenever they need i=
t.
>
> I'm also feeling a bit of confusion arising from a conflation of terms
> between the regular client/server model and the terminology used in OAuth=
.
> To be clear, in OAuth, the level of trust between the client and authZ
> server only really depends on policy; as mentioned, dynamic client
> registration can be used if you don't need any trust between the client a=
nd
> AS.
>
> On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher  wrote=
:
>
>> Just to clarify, I assume in this discourse that the "server" in this
>> client and server relationship refers to an AS/RS pair in OAuth
>> terminology? Based on this, one big sticking point for me on the
>> applicability of NxM, or even 1xM, is that all of the "M" RSs need to
>> publish the same interface for any meaningful implementation in the firs=
t
>> place.
>>
>> It probably makes more sense with email clients, since as Bron said,
>> there is the common standard of POP. If we assume that all the email
>> services that we want to connect to publish the same POP interface, and
>> would accept tokens in the same way, then the way the authZ is handled i=
s
>> indeed the point of divergence that needs to be resolved.
>>
>> However, we're talking about NxM in the general case here. I feel like
>> using the likes of discovery and dynamic registration, etc. that's alrea=
dy
>> supported by OAuth, the "N" part of this equation is surmountable. But e=
ach
>> of the "M" servers also need to export the same interface, otherwise a
>> client is going to have to write custom code to deal with talking to the
>> service after the authZ step anyway, reintroducing the "problem" part of
>> the NxM problem.
>>
>> As such, I would actually suggest constraining this discussion to just
>> the POP NxM problem rather than NxM in general because, for me at least,
>> the authZ part of the general case is the most "solved" part of the
>> problem, and the outstanding work lies more in consolidating the "M" RS
>> interfaces.
>>
>> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana 
>> wrote:
>>
>>> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>>>
>>> I agree that the NxM problem is the purview of the whole IETF, but it=
=E2=80=99s
>>> something that we=E2=80=99re particularly interested in over in GNAP. A=
s the editor
>>> of OAuth=E2=80=99s dynamic registration extension and the GNAP core pro=
tocol, I
>>> hope I can add to this conversation.
>>>
>>> From a technical standpoint, OAuth=E2=80=99s dynamic client registratio=
n lets
>>> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in p=
ractice. On
>>> top of that I think this problem is exacerbated by a fundamental protoc=
ol
>>> design element of OAuth: the client_id that=E2=80=99s required. That fi=
eld means
>>> there=E2=80=99s an assumption that a relationship was set up between th=
e pieces of
>>> software, implied to be trusted by admins at the AS. Sure you can get t=
hat
>>> client_id under special circumstances, but there=E2=80=99s still a spec=
ial weight
>>> handed to that and the dynamic stuff feels like you=E2=80=99re giving u=
p control as
>>> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designed=
 as
>>> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an o=
ptimization on top
>>> of that.
>>>
>>>
>>> Yep, this is the big point - OAuth is designed to require the the third
>>> leg of trust that creates the NxM problem.
>>>
>>>
>>> 
>>>
>>> If that dotted line between client and server requires a pre-existing
>>> trust relationship rather than the trust being entirely mediated by the
>>> user choosing to connect client A with server B, then you have the NxM
>>> problem.  This is the "you can only have your John Deere tractor servic=
ed
>>> by an approved John Deere service centre" problem.  You can only use th=
is
>>> client with servers who have pre-approved it.  Or fall back to the "cas=
h of
>>> the internet" - plain text passwords.
>>>
>>> Does this solve the NxM problem? No, because companies are still going
>>> to decide that they only talk to keys or identifiers that they know ahe=
ad
>>> of time. But the protocol puts the dynamic case forward as baseline and
>>> fits in much better with the likes of JMAP than OAuth ever could:
>>>
>>> - {The Bat} creates a key pair.
>>> - {User} enters their email address into {Bat}, {Bat} does discovery
>>> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP serv=
er and the
>>> GNAP endpoint for authentication as an option.
>>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just made
>>> up. {ISP} has never seen this key, but knows how to talk GNAP and get t=
he
>>> user to authorize {Bat} to access email.
>>> - {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied
>>> to the key {Bat} made back at the beginning. That token is tied (at the
>>> {ISP}) to the user=E2=80=99s account.
>>>
>>> Yes, you can do all of this today with OAuth (and people have done so),
>>> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registr=
ation first and THEN
>>> talk to me=E2=80=9D is a trust impediment more than it is a technical i=
mpediment.
>>> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the =
philosophy of =E2=80=9Cstart
>>> talking first and figure out what you need as you go=E2=80=9D. Instead =
of jumping
>>> through hoops to get something you can trust, you just start in and the=
n
>>> decide how much you trust it. A corporate rollout could use its own key
>>> distribution mechanism and static registration to limit which client
>>> instances talk back to the company server, regardless of which accounts
>>> would authorize access on top of that. An internet-facing service is go=
ing
>>> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll talk=
 to you in a secure
>>> fashion without caring who you are right now=E2=80=9D.
>>>
>>> We really are trying to make GNAP a consistent protocol at its core and
>>> learn from problems with OAuth in the wild, all while letting GNAP addr=
ess
>>> a wider variety of use cases. I agree that GNAP could be clearer about
>>> specific use cases, and we=E2=80=99re working on the spec still so any =
help here is
>>> appreciated.
>>>
>>>
>>> Excellent.  This is precisely what I've been waiting for for these very
>>> many years as a viable replacement for storing a password locally on di=
sk.
>>> Just having the server able to distinguish between different client
>>> instances for the same user is a big start, because you can de-authoris=
e
>>> one without having to lock out every connection - even if the user is s=
till
>>> entering their password during the setup phase each time.
>>>
>>> This is what Fastmail already do with our own app, creating a long-live=
d
>>> access token and storing that on the device rather than storing the
>>> password itself - and you can log out any one client from your security
>>> settings page.  What's missing is a standard way to do that with any IM=
AP
>>> client.  The initial JMAP authentication proposal was a very simple cas=
e of
>>> pretty much this, build into to the protocol so everyone would do it.
>>>
>>> Making it easy to connect up arbitrary clients with per-client tokens
>>> the default, and easy rather than almost impossible to do in practice i=
s
>>> where the big difference comes in.
>>>
>>> Bron.
>>>
>>> --
>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>   brong@fastmailteam.com
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>

--00000000000014372505bc3fcff0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Feb 26, 2021 at 8:10 AM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">
Right, it=E2=80=99s possible to patch OAuth to do this, but the whole=
 =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth at=
 a really core level. That=E2=80=99s one of the main reasons there=E2=80=99=
s been hesitance at deploying dynamic registration. It=E2=80=99s an extensi=
on that changes your trust model=E2=80=99s assumptions, and does so in a wa=
y that is challenging for a lot of large scale providers.

Justin is correct but being extremely diplomatic. =E2=80=9CThere=E2=80=99s=
 been hesitance=E2=80=9D, as he puts it, translates in practice to some law=
yer or VP saying =E2=80=9CYou want to accept auth assertions for business t=
ransactions from unknown parties?=C2=A0 I have no interest in jail time, so=
 forget it.=E2=80=9D =C2=A0

=C2=A0
That=E2=80=99s why I personally think it=E2=80=99s really impor=
tant that we get away from that registration model in GNAP, so we don=E2=80=
=99t repeat that same problem in the same way. Some people will still deplo=
y GNAP with static registration, but this model becomes more exceptional th=
an baseline. The philosophy of what=E2=80=99s considered an extension vs. d=
efault is important.

=C2=A0=E2=80=94 Justin

On Feb 25, 2021, at 3:41 AM, Se=C3=A1n=
 Kelleher <sean@tr=
ustap.com> wrote:

=
Yep, this is the big point - OAuth is des=
igned to require the the third leg of trust that creates the NxM problem.

I believe the snippet of Justin's=
 that you quoted actually shows you how you can forgo the trust element usi=
ng dynamic client registration. It still allows a "server" to ide=
ntify requests and impose security policies via the client ID, but without =
requiring=C2=A0the client author to manually register the client in advance=
 of using it (e.g. in the case where the client author doesn't even kno=
w what servers the client is going to be connecting to). You still need the=
 client ID, but anyone can get one whenever they need it.

I'm also feeling a bit of confusion arising from a conflation o=
f terms between the regular client/server model and the terminology used in=
 OAuth. To be clear, in OAuth, the level of trust between the client and au=
thZ server only really depends on policy; as mentioned, dynamic client regi=
stration can be used if you don't need any trust between the client and=
 AS.

On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher <sean@trustap.com> wrote:
Just to clarify, I assume in=
 this discourse that the "server" in this client and server relat=
ionship refers to an AS/RS pair in OAuth terminology? Based on this, one bi=
g sticking=C2=A0point for me on the applicability of NxM, or even 1xM, is t=
hat all of the "M" RSs need to publish the same interface for any=
 meaningful implementation in the first place.

It =
probably makes more sense with email clients, since as Bron said, there is =
the common standard of POP. If we assume that all the email services that w=
e want to connect to publish the same POP interface, and would accept token=
s in the same way, then the way the authZ is handled is indeed the point of=
 divergence that needs to be resolved.

However, we=
're talking about NxM in the general=C2=A0case here. I feel like using =
the likes of discovery and dynamic registration, etc. that's already su=
pported by OAuth, the "N" part of this=C2=A0equation=C2=A0is surm=
ountable. But each of the "M" servers also need to export the sam=
e interface, otherwise a client is going to have to write custom code to de=
al with talking to the service after the authZ step anyway, reintroducing t=
he "problem" part of the NxM problem.

As=
 such, I would actually suggest constraining this discussion to just the PO=
P NxM problem rather than NxM in general because, for me at least, the auth=
Z part of the general case is the most "solved" part of the probl=
em, and the outstanding work lies more in consolidating the "M" R=
S interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <brong@fastmailteam.com=
> wrote:
On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
<=
blockquote type=3D"cite" id=3D"gmail-m_-791049092973914516gmail-m_132413302=
1155432545gmail-m_1167406493498167402qt">
I agree that the NxM problem =
is the purview of the whole IETF, but it=E2=80=99s something that we=E2=80=
=99re particularly interested in over in GNAP. As the editor of OAuth=E2=80=
=99s dynamic registration extension and the GNAP core protocol, I hope I ca=
n add to this conversation.

From a technical s=
tandpoint, OAuth=E2=80=99s dynamic client registration lets arbitrary clien=
ts talk to an AS, but the trust isn=E2=80=99t there in practice. On top of =
that I think this problem is exacerbated by a fundamental protocol design e=
lement of OAuth: the client_id that=E2=80=99s required. That field means th=
ere=E2=80=99s an assumption that a relationship was set up between the piec=
es of software, implied to be trusted by admins at the AS. Sure you can get=
 that client_id under special circumstances, but there=E2=80=99s still a sp=
ecial weight handed to that and the dynamic stuff feels like you=E2=80=99re=
 giving up control as an AS. In GNAP, the relationship is inverted, and it=
=E2=80=99s designed as =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered=
 clients being an optimization on top of that.

Yep, =
this is the big point - OAuth is designed to require the the third leg of t=
rust that creates the NxM problem.


<image.png>

If that dotted line betwee=
n client and server requires a pre-existing trust relationship rather than =
the trust being entirely mediated by the user choosing to connect client A =
with server B, then you have the NxM problem.=C2=A0 This is the "you c=
an only have your John Deere tractor serviced by an approved John Deere ser=
vice centre" problem.=C2=A0 You can only use this client with servers =
who have pre-approved it.=C2=A0 Or fall back to the "cash of the inter=
net" - plain text passwords.

Does this solve t=
he NxM problem? No, because companies are still going to decide that they o=
nly talk to keys or identifiers that they know ahead of time. But the proto=
col puts the dynamic case forward as baseline and fits in much better with =
the likes of JMAP than OAuth ever could:

- {Th=
e Bat} creates a key pair.
- {User} enters their email addres=
s into {Bat}, {Bat} does discovery (maybe that=E2=80=99s a JMAP thing? Webf=
inger?) and finds the JMAP server and the GNAP endpoint for authentication =
as an option.
- {Bat} talks to the GNAP AS at {ISP} and prese=
nts the key it just made up. {ISP} has never seen this key, but knows how t=
o talk GNAP and get the user to authorize {Bat} to access email.
<=
div>- {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied to the key {Bat} made back at the beginning. That token is tied (=
at the {ISP}) to the user=E2=80=99s account.

Y=
es, you can do all of this today with OAuth (and people have done so), but =
OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and registration fi=
rst and THEN talk to me=E2=80=9D is a trust impediment more than it is a te=
chnical impediment. The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name=
 comes from the philosophy of =E2=80=9Cstart talking first and figure out w=
hat you need as you go=E2=80=9D. Instead of jumping through hoops to get so=
mething you can trust, you just start in and then decide how much you trust=
 it. A corporate rollout could use its own key distribution mechanism and s=
tatic registration to limit which client instances talk back to the company=
 server, regardless of which accounts would authorize access on top of that=
. An internet-facing service is going to be more likely to take a TLS appro=
ach, of =E2=80=9CI=E2=80=99ll talk to you in a secure fashion without carin=
g who you are right now=E2=80=9D.

We really ar=
e trying to make GNAP a consistent protocol at its core and learn from prob=
lems with OAuth in the wild, all while letting GNAP address a wider variety=
 of use cases. I agree that GNAP could be clearer about specific use cases,=
 and we=E2=80=99re working on the spec still so any help here is appreciate=
d.=C2=A0

<=
div style=3D"font-family:Arial">Excellent.=C2=A0 This is precisely what I&#=
39;ve been waiting for for these very many years as a viable replacement fo=
r storing a password locally on disk.=C2=A0 Just having the server able to =
distinguish between different client instances for the same user is a big s=
tart, because you can de-authorise one without having to lock out every con=
nection - even if the user is still entering their password during the setu=
p phase each time.

This is what Fastmail already do with our own =
app, creating a long-lived access token and storing that on the device rath=
er than storing the password itself - and you can log out any one client fr=
om your security settings page.=C2=A0 What's missing is a standard way =
to do that with any IMAP client.=C2=A0 The initial JMAP authentication prop=
osal was a very simple case of pretty much this, build into to the protocol=
 so everyone would do it.

Making it easy to connect up arbitrary =
clients with per-client tokens the default, and easy rather than almost imp=
ossible to do in practice is where the big difference comes in.

B=
ron.

--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty L=
td


___________________________________=
____________

OAuth mailing list

OAuth@ietf.org

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









--00000000000014372505bc3fcff0--


From nobody Fri Feb 26 08:33:22 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8B63A1268 for ; Fri, 26 Feb 2021 08:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6HPPgMuBio0 for ; Fri, 26 Feb 2021 08:33:11 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35D33A11D6 for ; Fri, 26 Feb 2021 08:33:05 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id z13so10213932iox.8 for ; Fri, 26 Feb 2021 08:33:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5lG4VH5IQIXDYRIlPnfjVvrFDfUuFmq+Up73Oz2NhIs=; b=GAMZlId9lPPKufv6WIQNcYuQHJtRA0JCfRadodDjReBHTgcUHJnsecKMsXq6adqVGP ic+4kM00H8Ne22LEEq9cgiMnPUfei3iV5mrj+lh9Ap00Gmzmj8a9+tY7sNhtmlCTm2Mu r8s5xE2C4POVUkk9kSyduvhyUXPZJ48IFfhvDLaMqP2XsyEQywioJFi6uMNMn9dxbKTW VdnZjlSEHkQ9RJ0if9jrgZcU8kWEMTSA3mWi9i1FWsnl59/cl7QxzbKUb79dSagvZuy8 2AMOHWl7S+8fakfSlX/euPLU5ezSZBDuVPAR8h1q8XhGCN+YDMXvnKvt1rvyGXga+iaY pbkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5lG4VH5IQIXDYRIlPnfjVvrFDfUuFmq+Up73Oz2NhIs=; b=Lh+KwKtQAgGzLTbAsyglHc+FAmyjNYF8rtdg6prwMx0UVk8w9sMlL5eaX+enL46esj VGLaIP3shZkHexlW0kD7DfrVBwPYdFVffY38+Kak5MlN6xjuqgPhRs1xAdQyq06ICGSt jeIkvHs3/BB8sS+m2Pl/JBUk+qyiwrdkIyoUmX5ags/EE/2DBVhFOt/Dwh/h6RM5z1Ku yILmNEF/pT+fRTac+re38/SDy7nyb7tYJQM/6TxLvAAj+cltZxAQhNmoF2yRmwr3QAxk ECONWe1nvO/tzl1Uf34bE/KAqZsrbeCRM0fkzSVEfYHyouhSsfzmrJqkjGLJAFjmzhXY +DIw==
X-Gm-Message-State: AOAM533fzC5KFSaAHlE8NK4ONuRrJHb1sfZNzWZK715A1HEyqH6/W+i5 d+snycDqoxbQn2qtZedD1QnbHRpI7ePkKg==
X-Google-Smtp-Source: ABdhPJwJNyRLe0TSMFl1U4uTimg37B6V6gbAxOo4jn4ceU8rM+u7at7g+XndRSa/kUE0O1rKVd+FYg==
X-Received: by 2002:a02:3541:: with SMTP id y1mr3704775jae.66.1614357183627; Fri, 26 Feb 2021 08:33:03 -0800 (PST)
Received: from mail-io1-f52.google.com (mail-io1-f52.google.com. [209.85.166.52]) by smtp.gmail.com with ESMTPSA id m19sm4950967ila.81.2021.02.26.08.33.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Feb 2021 08:33:03 -0800 (PST)
Received: by mail-io1-f52.google.com with SMTP id n14so10230559iog.3; Fri, 26 Feb 2021 08:33:02 -0800 (PST)
X-Received: by 2002:a6b:7e02:: with SMTP id i2mr3387744iom.120.1614357182437;  Fri, 26 Feb 2021 08:33:02 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu> 
In-Reply-To: 
From: Aaron Parecki 
Date: Fri, 26 Feb 2021 08:32:51 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Warren Parad 
Cc: Justin Richer , Phillip Hallam-Baker ,  IETF-Discussion Discussion , "oauth@ietf.org" ,  Bron Gondwana 
Content-Type: multipart/alternative; boundary="00000000000066639105bc3fd2be"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 16:33:21 -0000

--00000000000066639105bc3fd2be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dynamic client registration does exist in OAuth:
https://tools.ietf.org/html/rfc7591

The point is that basically nobody uses it because they don't want to allow
arbitrary client registration at their ASs. That's likely due to a
combination of pre-registration being the default model in OAuth for so
long (the Dynamic Client Registration draft was published several years
after OAuth 2.0), as well as how large corporations have decided to run
their ASs where they want to have (what feels like) more control over the
things talking to their servers.

On Fri, Feb 26, 2021 at 8:22 AM Warren Parad  wrote:

> A) I don't think it is helpful to talk about what other WGs are doing, or
> how GNAP attempts to fix or not fix these problems.
> B) Sharing statements like this:
>
>> Right, it=E2=80=99s possible to patch OAuth to do this, but the whole
>> =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth =
at a really core
>> level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesit=
ance at deploying
>> dynamic registration
>
> Don't help everyone come to the same conclusion, Who is "we" here, it beg=
s
> the question "is there a mindset baked into OAuth", I think to work
> effectively we need to be talking about how to best to tackle challenges
> everyone and anyone brings up and not fallback on arbitrary statements. I=
t
> would be one thing to point to a document which outlines the exact issues
> with dynamic registration and then we could potentially have a valuable
> conversation about "are those reasons still relevant or do we need to
> revisit."
>
> Right now it seems there is "Someone in the past decided this was a bad
> idea, so we can't do it", rather than actually having the conversation
> about it.
>
> Just based on the conversation, it seems like the obvious right thing to
> do is provide dynamic registration in OAuth. Will client developers do th=
e
> wrong thing, sure. Might it be challenging to support in a simple way,
> maybe. But having the addition to OAuth to solve the problem is better th=
an
> nothing, and further it starts to change the mindset that dynamic
> registration is and should be provided when appropriate.
>
> Warren Parad
>
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress .
>
>
> On Fri, Feb 26, 2021 at 5:11 PM Justin Richer  wrote:
>
>> Right, it=E2=80=99s possible to patch OAuth to do this, but the whole
>> =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth =
at a really core
>> level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesit=
ance at deploying
>> dynamic registration. It=E2=80=99s an extension that changes your trust =
model=E2=80=99s
>> assumptions, and does so in a way that is challenging for a lot of large
>> scale providers.
>>
>> That=E2=80=99s why I personally think it=E2=80=99s really important that=
 we get away from
>> that registration model in GNAP, so we don=E2=80=99t repeat that same pr=
oblem in
>> the same way. Some people will still deploy GNAP with static registratio=
n,
>> but this model becomes more exceptional than baseline. The philosophy of
>> what=E2=80=99s considered an extension vs. default is important.
>>
>>  =E2=80=94 Justin
>>
>> On Feb 25, 2021, at 3:41 AM, Se=C3=A1n Kelleher  wrote=
:
>>
>> Yep, this is the big point - OAuth is designed to require the the third
>>> leg of trust that creates the NxM problem.
>>
>>
>> I believe the snippet of Justin's that you quoted actually shows you how
>> you can forgo the trust element using dynamic client registration. It st=
ill
>> allows a "server" to identify requests and impose security policies via =
the
>> client ID, but without requiring the client author to manually register =
the
>> client in advance of using it (e.g. in the case where the client author
>> doesn't even know what servers the client is going to be connecting to).
>> You still need the client ID, but anyone can get one whenever they need =
it.
>>
>> I'm also feeling a bit of confusion arising from a conflation of terms
>> between the regular client/server model and the terminology used in OAut=
h.
>> To be clear, in OAuth, the level of trust between the client and authZ
>> server only really depends on policy; as mentioned, dynamic client
>> registration can be used if you don't need any trust between the client =
and
>> AS.
>>
>> On Thu, 25 Feb 2021 at 08:22, Se=C3=A1n Kelleher  wrot=
e:
>>
>>> Just to clarify, I assume in this discourse that the "server" in this
>>> client and server relationship refers to an AS/RS pair in OAuth
>>> terminology? Based on this, one big sticking point for me on the
>>> applicability of NxM, or even 1xM, is that all of the "M" RSs need to
>>> publish the same interface for any meaningful implementation in the fir=
st
>>> place.
>>>
>>> It probably makes more sense with email clients, since as Bron said,
>>> there is the common standard of POP. If we assume that all the email
>>> services that we want to connect to publish the same POP interface, and
>>> would accept tokens in the same way, then the way the authZ is handled =
is
>>> indeed the point of divergence that needs to be resolved.
>>>
>>> However, we're talking about NxM in the general case here. I feel like
>>> using the likes of discovery and dynamic registration, etc. that's alre=
ady
>>> supported by OAuth, the "N" part of this equation is surmountable. But =
each
>>> of the "M" servers also need to export the same interface, otherwise a
>>> client is going to have to write custom code to deal with talking to th=
e
>>> service after the authZ step anyway, reintroducing the "problem" part o=
f
>>> the NxM problem.
>>>
>>> As such, I would actually suggest constraining this discussion to just
>>> the POP NxM problem rather than NxM in general because, for me at least=
,
>>> the authZ part of the general case is the most "solved" part of the
>>> problem, and the outstanding work lies more in consolidating the "M" RS
>>> interfaces.
>>>
>>> On Wed, 24 Feb 2021 at 22:32, Bron Gondwana 
>>> wrote:
>>>
>>>> On Thu, Feb 25, 2021, at 02:18, Justin Richer wrote:
>>>>
>>>> I agree that the NxM problem is the purview of the whole IETF, but it=
=E2=80=99s
>>>> something that we=E2=80=99re particularly interested in over in GNAP. =
As the editor
>>>> of OAuth=E2=80=99s dynamic registration extension and the GNAP core pr=
otocol, I
>>>> hope I can add to this conversation.
>>>>
>>>> From a technical standpoint, OAuth=E2=80=99s dynamic client registrati=
on lets
>>>> arbitrary clients talk to an AS, but the trust isn=E2=80=99t there in =
practice. On
>>>> top of that I think this problem is exacerbated by a fundamental proto=
col
>>>> design element of OAuth: the client_id that=E2=80=99s required. That f=
ield means
>>>> there=E2=80=99s an assumption that a relationship was set up between t=
he pieces of
>>>> software, implied to be trusted by admins at the AS. Sure you can get =
that
>>>> client_id under special circumstances, but there=E2=80=99s still a spe=
cial weight
>>>> handed to that and the dynamic stuff feels like you=E2=80=99re giving =
up control as
>>>> an AS. In GNAP, the relationship is inverted, and it=E2=80=99s designe=
d as
>>>> =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients being an =
optimization on top
>>>> of that.
>>>>
>>>>
>>>> Yep, this is the big point - OAuth is designed to require the the thir=
d
>>>> leg of trust that creates the NxM problem.
>>>>
>>>>
>>>> 
>>>>
>>>> If that dotted line between client and server requires a pre-existing
>>>> trust relationship rather than the trust being entirely mediated by th=
e
>>>> user choosing to connect client A with server B, then you have the NxM
>>>> problem.  This is the "you can only have your John Deere tractor servi=
ced
>>>> by an approved John Deere service centre" problem.  You can only use t=
his
>>>> client with servers who have pre-approved it.  Or fall back to the "ca=
sh of
>>>> the internet" - plain text passwords.
>>>>
>>>> Does this solve the NxM problem? No, because companies are still going
>>>> to decide that they only talk to keys or identifiers that they know ah=
ead
>>>> of time. But the protocol puts the dynamic case forward as baseline an=
d
>>>> fits in much better with the likes of JMAP than OAuth ever could:
>>>>
>>>> - {The Bat} creates a key pair.
>>>> - {User} enters their email address into {Bat}, {Bat} does discovery
>>>> (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP ser=
ver and the
>>>> GNAP endpoint for authentication as an option.
>>>> - {Bat} talks to the GNAP AS at {ISP} and presents the key it just mad=
e
>>>> up. {ISP} has never seen this key, but knows how to talk GNAP and get =
the
>>>> user to authorize {Bat} to access email.
>>>> - {User} does this using GNAP and gets back an access token that=E2=80=
=99s tied
>>>> to the key {Bat} made back at the beginning. That token is tied (at th=
e
>>>> {ISP}) to the user=E2=80=99s account.
>>>>
>>>> Yes, you can do all of this today with OAuth (and people have done so)=
,
>>>> but OAuth=E2=80=99s basic model of =E2=80=9Cgo do discovery and regist=
ration first and THEN
>>>> talk to me=E2=80=9D is a trust impediment more than it is a technical =
impediment.
>>>> The =E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the=
 philosophy of =E2=80=9Cstart
>>>> talking first and figure out what you need as you go=E2=80=9D. Instead=
 of jumping
>>>> through hoops to get something you can trust, you just start in and th=
en
>>>> decide how much you trust it. A corporate rollout could use its own ke=
y
>>>> distribution mechanism and static registration to limit which client
>>>> instances talk back to the company server, regardless of which account=
s
>>>> would authorize access on top of that. An internet-facing service is g=
oing
>>>> to be more likely to take a TLS approach, of =E2=80=9CI=E2=80=99ll tal=
k to you in a secure
>>>> fashion without caring who you are right now=E2=80=9D.
>>>>
>>>> We really are trying to make GNAP a consistent protocol at its core an=
d
>>>> learn from problems with OAuth in the wild, all while letting GNAP add=
ress
>>>> a wider variety of use cases. I agree that GNAP could be clearer about
>>>> specific use cases, and we=E2=80=99re working on the spec still so any=
 help here is
>>>> appreciated.
>>>>
>>>>
>>>> Excellent.  This is precisely what I've been waiting for for these ver=
y
>>>> many years as a viable replacement for storing a password locally on d=
isk.
>>>> Just having the server able to distinguish between different client
>>>> instances for the same user is a big start, because you can de-authori=
se
>>>> one without having to lock out every connection - even if the user is =
still
>>>> entering their password during the setup phase each time.
>>>>
>>>> This is what Fastmail already do with our own app, creating a
>>>> long-lived access token and storing that on the device rather than sto=
ring
>>>> the password itself - and you can log out any one client from your sec=
urity
>>>> settings page.  What's missing is a standard way to do that with any I=
MAP
>>>> client.  The initial JMAP authentication proposal was a very simple ca=
se of
>>>> pretty much this, build into to the protocol so everyone would do it.
>>>>
>>>> Making it easy to connect up arbitrary clients with per-client tokens
>>>> the default, and easy rather than almost impossible to do in practice =
is
>>>> where the big difference comes in.
>>>>
>>>> Bron.
>>>>
>>>> --
>>>>   Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>   brong@fastmailteam.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
>

--00000000000066639105bc3fd2be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dynamic client registration does exist in OAuth:=C2=A0https://tools.ietf.org/html/rfc=
7591

The point is that basically nobody uses it beca=
use they don't want to allow arbitrary client registration at their ASs=
. That's likely due to a combination of pre-registration being the defa=
ult model in OAuth for so long (the Dynamic Client Registration draft was p=
ublished several years after OAuth 2.0), as well as how large corporations =
have decided to run their ASs where they want to have (what feels like) mor=
e control over the things talking to their servers.

On Fri, Feb 26, 20=
21 at 8:22 AM Warren Parad <wparad=3D40rhosys.ch@dmarc.ietf.org> wrote:
A) I don't think =
it is helpful to talk about what other WGs are doing, or how GNAP attempts =
to fix or not fix these problems.
B) Sharing statements like this:
Right, it=E2=80=99s poss=
ible to patch OAuth to do this, but the whole =E2=80=9Cregistration equals =
trust=E2=80=9D mindset is baked into OAuth at a really core level. That=E2=
=80=99s one of the main reasons there=E2=80=99s been hesitance at deploying=
 dynamic registration
Don't help everyone come to the =
same conclusion, Who is "we" here, it begs the question "is =
there a mindset baked into OAuth", I think to work effectively we need=
 to be talking about how to best to tackle challenges everyone and anyone b=
rings up and not fallback on arbitrary statements. It would be one thing to=
 point to a document which outlines the exact issues with dynamic registrat=
ion and then we could potentially=C2=A0have a valuable conversation about &=
quot;are those reasons still relevant or do we need to revisit."
=


Right now it seems there is "Someone in the past d=
ecided this was a bad idea, so we can't do it", rather than actual=
ly having the conversation about it.

Just based on=
 the conversation, it seems like the obvious right thing to do is provide d=
ynamic registration in OAuth. Will client developers do the wrong thing, su=
re. Might it be challenging to support in a simple way, maybe. But having t=
he addition to OAuth to solve the problem is better than nothing, and furth=
er it starts to change the mindset that dynamic registration is and should =
be provided when appropriate.

Warren Parad
Founder, CTO
Secure your user data with IAM authorizatio=
n as a service. Implement=C2=A0Authress.


On Fri, Feb 26, 2021=
 at 5:11 PM Justin Richer <jricher@mit.edu> wrote:
Right, it=E2=80=99s possible to patch OAuth to =
do this, but the whole =E2=80=9Cregistration equals trust=E2=80=9D mindset =
is baked into OAuth at a really core level. That=E2=80=99s one of the main =
reasons there=E2=80=99s been hesitance at deploying dynamic registration. I=
t=E2=80=99s an extension that changes your trust model=E2=80=99s assumption=
s, and does so in a way that is challenging for a lot of large scale provid=
ers.

That=E2=80=99s why I personally think it=E2=80=99s =
really important that we get away from that registration model in GNAP, so =
we don=E2=80=99t repeat that same problem in the same way. Some people will=
 still deploy GNAP with static registration, but this model becomes more ex=
ceptional than baseline. The philosophy of what=E2=80=99s considered an ext=
ension vs. default is important.

=C2=A0=E2=80=94 J=
ustin

On Feb 25, 2021, at 3:41 A=
M, Se=C3=A1n Kelleher <sean@trustap.com> wrote:

Yep, this is the big point - OAuth is designed to require the the third l=
eg of trust that creates the NxM problem.

I believe the snippet of Justin's that you quoted actually shows =
you how you can forgo the trust element using dynamic client registration. =
It still allows a "server" to identify requests and impose securi=
ty policies via the client ID, but without requiring=C2=A0the client author=
 to manually register the client in advance of using it (e.g. in the case w=
here the client author doesn't even know what servers the client is goi=
ng to be connecting to). You still need the client ID, but anyone can get o=
ne whenever they need it.

I'm also feeling a b=
it of confusion arising from a conflation of terms between the regular clie=
nt/server model and the terminology used in OAuth. To be clear, in OAuth, t=
he level of trust between the client and authZ server only really depends o=
n policy; as mentioned, dynamic client registration can be used if you don&=
#39;t need any trust between the client and AS.

On Thu, 25 Feb 2021 =
at 08:22, Se=C3=A1n Kelleher <sean@trustap.com> wrote:
Just to clarify, I assume=
 in this discourse that the "server" in this client and server re=
lationship refers to an AS/RS pair in OAuth terminology? Based on this, one=
 big sticking=C2=A0point for me on the applicability of NxM, or even 1xM, i=
s that all of the "M" RSs need to publish the same interface for =
any meaningful implementation in the first place.

=
It probably makes more sense with email clients, since as Bron said, there =
is the common standard of POP. If we assume that all the email services tha=
t we want to connect to publish the same POP interface, and would accept to=
kens in the same way, then the way the authZ is handled is indeed the point=
 of divergence that needs to be resolved.

However,=
 we're talking about NxM in the general=C2=A0case here. I feel like usi=
ng the likes of discovery and dynamic registration, etc. that's already=
 supported by OAuth, the "N" part of this=C2=A0equation=C2=A0is s=
urmountable. But each of the "M" servers also need to export the =
same interface, otherwise a client is going to have to write custom code to=
 deal with talking to the service after the authZ step anyway, reintroducin=
g the "problem" part of the NxM problem.

As such, I would actually suggest constraining this discussion to just the=
 POP NxM problem rather than NxM in general because, for me at least, the a=
uthZ part of the general case is the most "solved" part of the pr=
oblem, and the outstanding work lies more in consolidating the "M"=
; RS interfaces.

On Wed, 24 Feb 2021 at 22:32, Bron Gondwana <brong@fastmailteam.c=
om> wrote:
On Thu, Feb 25, 2021, at 02:=
18, Justin Richer wrote:
I agree that the NxM problem is the purv=
iew of the whole IETF, but it=E2=80=99s something that we=E2=80=99re partic=
ularly interested in over in GNAP. As the editor of OAuth=E2=80=99s dynamic=
 registration extension and the GNAP core protocol, I hope I can add to thi=
s conversation.

From a technical standpoint, O=
Auth=E2=80=99s dynamic client registration lets arbitrary clients talk to a=
n AS, but the trust isn=E2=80=99t there in practice. On top of that I think=
 this problem is exacerbated by a fundamental protocol design element of OA=
uth: the client_id that=E2=80=99s required. That field means there=E2=80=99=
s an assumption that a relationship was set up between the pieces of softwa=
re, implied to be trusted by admins at the AS. Sure you can get that client=
_id under special circumstances, but there=E2=80=99s still a special weight=
 handed to that and the dynamic stuff feels like you=E2=80=99re giving up c=
ontrol as an AS. In GNAP, the relationship is inverted, and it=E2=80=99s de=
signed as =E2=80=9Cdynamic-first=E2=80=9D, with pre-registered clients bein=
g an optimization on top of that.

Yep, this is the b=
ig point - OAuth is designed to require the the third leg of trust that cre=
ates the NxM problem.

<=
div style=3D"font-family:Arial">
<image.png>

If that d=
otted line between client and server requires a pre-existing trust relation=
ship rather than the trust being entirely mediated by the user choosing to =
connect client A with server B, then you have the NxM problem.=C2=A0 This i=
s the "you can only have your John Deere tractor serviced by an approv=
ed John Deere service centre" problem.=C2=A0 You can only use this cli=
ent with servers who have pre-approved it.=C2=A0 Or fall back to the "=
cash of the internet" - plain text passwords.

Does this solve the NxM problem? No, because c=
ompanies are still going to decide that they only talk to keys or identifie=
rs that they know ahead of time. But the protocol puts the dynamic case for=
ward as baseline and fits in much better with the likes of JMAP than OAuth =
ever could:

- {The Bat} creates a key pair.
- {User} enters their email address into {Bat}, {Bat} does disc=
overy (maybe that=E2=80=99s a JMAP thing? Webfinger?) and finds the JMAP se=
rver and the GNAP endpoint for authentication as an option.
-=
 {Bat} talks to the GNAP AS at {ISP} and presents the key it just made up. =
{ISP} has never seen this key, but knows how to talk GNAP and get the user =
to authorize {Bat} to access email.
- {User} does this using =
GNAP and gets back an access token that=E2=80=99s tied to the key {Bat} mad=
e back at the beginning. That token is tied (at the {ISP}) to the user=E2=
=80=99s account.

Yes, you can do all of this t=
oday with OAuth (and people have done so), but OAuth=E2=80=99s basic model =
of =E2=80=9Cgo do discovery and registration first and THEN talk to me=E2=
=80=9D is a trust impediment more than it is a technical impediment. The =
=E2=80=9Cnegotiation=E2=80=9D part of the GNAP name comes from the philosop=
hy of =E2=80=9Cstart talking first and figure out what you need as you go=
=E2=80=9D. Instead of jumping through hoops to get something you can trust,=
 you just start in and then decide how much you trust it. A corporate rollo=
ut could use its own key distribution mechanism and static registration to =
limit which client instances talk back to the company server, regardless of=
 which accounts would authorize access on top of that. An internet-facing s=
ervice is going to be more likely to take a TLS approach, of =E2=80=9CI=E2=
=80=99ll talk to you in a secure fashion without caring who you are right n=
ow=E2=80=9D.

We really are trying to make GNAP=
 a consistent protocol at its core and learn from problems with OAuth in th=
e wild, all while letting GNAP address a wider variety of use cases. I agre=
e that GNAP could be clearer about specific use cases, and we=E2=80=99re wo=
rking on the spec still so any help here is appreciated.=C2=A0

Excellent.=C2=A0 This is precisely what I've been waiting fo=
r for these very many years as a viable replacement for storing a password =
locally on disk.=C2=A0 Just having the server able to distinguish between d=
ifferent client instances for the same user is a big start, because you can=
 de-authorise one without having to lock out every connection - even if the=
 user is still entering their password during the setup phase each time.

This is what Fastmail already do with our own app, creating a long-=
lived access token and storing that on the device rather than storing the p=
assword itself - and you can log out any one client from your security sett=
ings page.=C2=A0 What's missing is a standard way to do that with any I=
MAP client.=C2=A0 The initial JMAP authentication proposal was a very simpl=
e case of pretty much this, build into to the protocol so everyone would do=
 it.

Making it easy to connect up arbitrary clients with per-clie=
nt tokens the default, and easy rather than almost impossible to do in prac=
tice is where the big difference comes in.

Bron.

--
=C2=A0 Bron Gondwana, CEO, Fastma=
il Pty Ltd

<=
div style=3D"font-family:Arial">
___________________________=
____________________

OAuth mailing 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



--00000000000066639105bc3fd2be--


From nobody Fri Feb 26 08:41:02 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56B63A10D4; Fri, 26 Feb 2021 08:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-MBs5F-sS8E; Fri, 26 Feb 2021 08:40:55 -0800 (PST)
Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF8F3A10B8; Fri, 26 Feb 2021 08:40:54 -0800 (PST)
Received: by mail-yb1-f174.google.com with SMTP id u75so9457646ybi.10; Fri, 26 Feb 2021 08:40:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uSzxVJ+FJ3QJccMSoZ3iB7bOtYBhYSMcb6oHY1OMYqA=; b=hWac3Rvm0ynV6WuXmOUbyO9hTC7gm41FEaMWqDyRd8oTE1yPO2jrciPypumWNftDZP 1omdLAhoNMYKx4v9b26IVpwzjVIT5wxWwjXGhhd9tj/OpjlYsd3ABypZP/bLhCStGvKP 5CGbXnKaXYAcCxa0nLAbArLK6RFQTn29cKMNwbZ3Syohgeebp0/8NN2DQxV61jIvvJrg s3CwpkyjeiT4G/yJ73ui61pxVAR8teW4kbGB1hSh3GBSV0AyYF4cqPi9E2Yd/y483JAH 7U+mUMTPLGWP5s43ed+cfvxAd1zrc2EwbZnKCDET/J3WH2zon2ML/9/lXNiYt7fn0Vw2 teiw==
X-Gm-Message-State: AOAM530HkvbHJiAiCNhWKX0c4MZzpzaa0B+i42B/mOimpg4gxbJCMX7Y JeIn52+U6ogtNBgI3yZIfE7+JkiVu1G7xS4+i+Zl0GCBuxM=
X-Google-Smtp-Source: ABdhPJwIPH0w2JpE64vRS4sFEO8xp8Tjn54zZG57NL9eM/PtfVvmvOexT6W5kST5jW0qtHfi9DqNzpjiml8eCCETlCg=
X-Received: by 2002:a25:aa6d:: with SMTP id s100mr5891863ybi.523.1614357653822;  Fri, 26 Feb 2021 08:40:53 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Fri, 26 Feb 2021 11:40:43 -0500
Message-ID: 
To: Bron Gondwana 
Cc: Jim Manico , IETF Discussion Mailing List , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000007f217905bc3feed5"
Archived-At: 
Subject: [OAUTH-WG] How to tell people... Was: We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 16:40:57 -0000

--0000000000007f217905bc3feed5
Content-Type: text/plain; charset="UTF-8"

I spend rather too much time doing disinformation analysis these days. But
one of the issues that keeps coming up is what Sartre called a 'bad faith'
argument which is an unfortunate term in that people end up doing it
without being aware of it, no malice involved.

What Sartre was describing was an argument in which there are two separate
frames of reference used. The first frame is used to establish that X
applies, then once that is achieved the first frame is discarded and X is
interpreted in the second frame.

To take an example:

Frame 1: Tony Blair implemented many polices that are described in a paper
by Milton Friedman when the latter was shilling for a position in the
Democratic administration of Harry Truman: Blair is a 'neoliberal'.

Frame 2: Neoliberal Milton Friedman shilled for and was successful in
getting a consulting role in the Pinochet regime. Therefore neoliberals
support Pinochet. Therefore Blair supports Pinochet. Therefore Blair
supports the mass murder of 30,000 people.

I am seeing similar in the OAUTH discussion:

Frame 1: X must use OAUTH it is simple!

Frame 2: You have to understand how to apply OAUTH correctly. The
Turbo-encabulator mode is very powerful let me stroke my beard while you
come to that understanding.


And yes, folk are going to get upset about having their arguments presented
in this fashion but I really don't know how else to get through to them the
reasons why the people on the receiving end of those arguments are getting
upset.

There is a real problem in trying to get across unwelcome information. The
ground problem for many of us with OAUTH is that we simply cannot
understand it. And we rather suspect the problem isn't on our side. I have
come to find that not being able to understand things that exceed a certain
complexity is actually a profound advantage in architecture. The real value
of formal methods turns out to be they force people to reduce the problem
to something simple enough to write proofs about.

This is one of the reasons I would like to see the IETF move towards a W3C
style plenary in which WGs are required to provide short introductions to
what they do. No, not status reports: an elevator pitch. Because if nobody
in the group can describe what is going on with clarity, well perhaps they
don't know themselves.

it is really difficult to know what to do in these circumstances. I tell
people my criteria for adopting a technology early on. If they meet my
criteria, I will attempt to make use of their work product. But I feel
absolutely no obligation to do so if they don't.

--0000000000007f217905bc3feed5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I s=
pend rather too much time doing disinformation analysis these days. But one=
 of the issues that keeps coming up is what Sartre called a 'bad faith&=
#39; argument which is an unfortunate term in that people end up doing it w=
ithout being aware of it, no malice involved.

What Sartre was describing was an argument=C2=A0in whi=
ch there are two separate frames of reference used. The first frame is used=
 to establish that X applies, then once that is achieved the first frame is=
 discarded and X is interpreted in the second frame.

To take an example:=C2=A0

Frame 1: Tony Blair implemented many polices=
=C2=A0that are described in a paper by Milton Friedman when the latter was =
shilling for a position in the Democratic administration of Harry Truman: B=
lair is a 'neoliberal'.=C2=A0

Frame 2: Neoliberal Milton Friedman shilled for and was succes=
sful in getting a consulting role in the Pinochet regime. Therefore neolibe=
rals support Pinochet. Therefore Blair supports Pinochet. Therefore Blair s=
upports the mass murder of 30,000 people.

I am seeing similar in the OAUTH discussion:

Frame 1: X must use OAUTH it is simple=
!

Frame 2: You have to un=
derstand how to apply OAUTH correctly. The Turbo-encabulator mode is very p=
owerful let me stroke my beard while you come to that understanding.
<=
div class=3D"gmail_default" style=3D"font-size:small">

And yes, folk are going to get upset abo=
ut having their arguments presented in this fashion but I really don't =
know how else to get through to them the reasons why the people on the rece=
iving end of those arguments are getting upset.

There is a real problem in trying to get across unwe=
lcome information. The ground problem for many of us with OAUTH is that we =
simply cannot understand it. And we rather suspect the problem isn't on=
 our side. I have come to find that not being able to understand things tha=
t exceed a certain complexity is actually a profound advantage in architect=
ure. The real value of formal methods turns out to be they force people to =
reduce the problem to something simple enough to write proofs about.
<=
div class=3D"gmail_default" style=3D"font-size:small">
This is one of the reasons I w=
ould like to see the IETF move towards a W3C style plenary in which WGs are=
 required to provide short introductions to what they do. No, not status re=
ports: an elevator pitch. Because if nobody in the group can describe what =
is going on with clarity, well perhaps they don't know themselves.=C2=
=A0

<=
div class=3D"gmail_default" style=3D"font-size:small">it is really difficul=
t to know what to do in these circumstances. I tell people my criteria for =
adopting a technology early on. If they meet my criteria, I will attempt to=
 make use of their work product. But I feel absolutely no obligation to do =
so if they don't.=C2=A0

--0000000000007f217905bc3feed5--


From nobody Fri Feb 26 12:11:47 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5249B3A166D for ; Fri, 26 Feb 2021 12:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-UvbmnAotbj for ; Fri, 26 Feb 2021 12:11:39 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4AB3A166F for ; Fri, 26 Feb 2021 12:11:38 -0800 (PST)
Received: from xse487.mail2web.com ([66.113.197.233] helo=xse.mail2web.com) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1lFjSW-0013ay-Up for oauth@ietf.org; Fri, 26 Feb 2021 21:11:36 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4DnLQV3MGPz1RWp for ; Fri, 26 Feb 2021 12:11:30 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1lFjSU-0006JX-BO for oauth@ietf.org; Fri, 26 Feb 2021 12:11:30 -0800
Received: (qmail 23270 invoked from network); 26 Feb 2021 20:11:29 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.109]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2021 20:11:29 -0000
To: Tim Bray , Justin Richer 
Cc: =?UTF-8?Q?Se=c3=a1n_Kelleher?= , Phillip Hallam-Baker , "oauth@ietf.org" , IETF-Discussion Discussion 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu> 
From: Christian Huitema 
Message-ID: <5956005f-7817-bb9f-0b43-40a6f70bd2d6@huitema.net>
Date: Fri, 26 Feb 2021 12:11:27 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------48E3803F2B4E0F219BF5EDD8"
Content-Language: en-US
X-Originating-IP: 66.113.197.233
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8uEaMc9v2z//gxoDgwFDrHPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yor/eCA3dHrmTLi/t2S44TfYzfQXcfqmra3dmoHS4ygqt2 eVsmjp+9Ijq5HCI5CwJWuRWrkPihq53YqAd1ENNqBHtNXu1E6L4+KyOXc4QYanQOD0r6/AaHZiEt dTMtMlia0Lmg/jgHfCNZd+W+PXf6Pjb130VX+iieImINR22zmiue9TLOhN8AYRsvkjfngQDbNI0R 22tddiGKm8EgkM9zzDkBvlIN1pUDU5DU5DggD98cjIN3reG9z0FKKQ5m2Qpw7sOVVcM1Xk+Tdz6g /UMvfWqyN3veeFIMJz/vumcqAwMU9kjfE7EFo+kP5riIEUmxU01QhuxnshSbl6nxbLZ35/xY0uvo WBEOfzq3RG28wI7w4vcwqZanLHsZM8r4s5ZjlHoGly8aneNxj+pRyx6DAzHPcWsnfqGSaNoXhWPo OpFVgpT1b21uZVckGp0ccOZtuBWXiK6eoWgQZnNLL6SbpUc7peFeo3eDQNYbhOKhzzgqmaDn5SlD Y9mmtv6e91aWBLor1oCWetcUjeG94V2XjoV9/BLvlyUvLzL6lsKk96TeVLW3pB0Q/PTyowo5AfvG OBMN2od+PeP79VOTtEEkCFXoGKtafvOtcW/mP16byrL/nwvREHuP3/Ps3A4Pt7hRyBl07OVp2D/S 9ogT8aIX6abOyKlLsxs8P4CT3FEuG1XPGkvWCCTmYu1mXbT/IvWC1AI9a3irbifzymzQYX+Pr3ZM ctiC/YQAlJjw8umpOJTjAZmlRsj5gYoNz52VfvCKuZkMyFBGaEBYeh6pTEjUL/n+3uEzmvwRmti3 9+fizX6m+UeFXprlCOm3BAEbJtAT1BYHStA0OogdNtRxnRSLF+XCKxIG9XMEgRDdaWpvCv+zESlk TxdSCNcDfRohcehWBb39uS1TjWG2Inx+Ts2QNOYPIz4ynMa7pZQ4hi/HGtuWeHzx9sLaQmDwvYQn 76e9NXttZBkk6PeFqH6So31P
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 20:11:41 -0000

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

On 2/26/2021 8:31 AM, Tim Bray wrote:

> On Fri, Feb 26, 2021 at 8:10 AM Justin Richer  > wrote:
>
>     Right, it’s possible to patch OAuth to do this, but the whole
>     “registration equals trust” mindset is baked into OAuth at a
>     really core level. That’s one of the main reasons there’s been
>     hesitance at deploying dynamic registration. It’s an extension
>     that changes your trust model’s assumptions, and does so in a way
>     that is challenging for a lot of large scale providers.
>
>
> Justin is correct but being extremely diplomatic. “There’s been 
> hesitance”, as he puts it, translates in practice to some lawyer or VP 
> saying “You want to accept auth assertions for business transactions 
> from unknown parties?  I have no interest in jail time, so forget it.”


Tim's point is very important. It shows a tension between "blindly 
accepting authentication claims from unknown parties", which would 
indeed lead to adversarial business consequences, and "only accepting 
authentication claims from parties that have been marked as trusted by 
my organization", which in theory looks safe but in practice drives 
concentration. If the trust decision is delegated to each site, we have 
the recipe for a network effect, in which only a very small set of big 
organizations can provide authentication for everybody, and collect the 
corresponding data and statistics.

This is both a very hard problem and an urgent problem. An IETF working 
group works on a hard issue and produces an incomplete solution. Big 
companies can fill the gaps by providing their own value. The result is 
further concentration of the Internet.

Such problems are very hard, but they are not impossible to solve. Look 
for example at PKI and its supporting infrastructure like the CAB Forum. 
It is not perfect, but at least it had the property of allowing web 
sites to use HTTPS without routing all authentication transactions 
through third parties. Wouldn't it be nice if we had a federation system 
on top of OAUTH? I suppose that is difficult. Not a reason to not try...

-- Christian Huitema


--------------48E3803F2B4E0F219BF5EDD8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 2/26/2021 8:31 AM, Tim Bray wrote:

    

    

      
On Fri, Feb 26, 2021 at 8:10 AM
        Justin Richer <jricher@mit.edu> wrote:

      

      

        
Right,
          it’s possible to patch OAuth to do this, but the whole
          “registration equals trust” mindset is baked into OAuth at a
          really core level. That’s one of the main reasons there’s been
          hesitance at deploying dynamic registration. It’s an extension
          that changes your trust model’s assumptions, and does so in a
          way that is challenging for a lot of large scale providers.

      

      


      

      

        
Justin is
          correct but being extremely diplomatic. “There’s been
          hesitance”, as he puts it, translates in practice to some
          lawyer or VP saying “You want to accept auth assertions for
          business transactions from unknown parties?  I have no
          interest in jail time, so forget it.”  

        

      

    

    


    

    
Tim's point is very important. It shows a tension between
      "blindly accepting authentication claims from unknown parties",
      which would indeed lead to adversarial business consequences, and
      "only accepting authentication claims from parties that have been
      marked as trusted by my organization", which in theory looks safe
      but in practice drives concentration. If the trust decision is
      delegated to each site, we have the recipe for a network effect,
      in which only a very small set of big organizations can provide
      authentication for everybody, and collect the corresponding data
      and statistics.

    

    
This is both a very hard problem and an urgent problem. An IETF
      working group works on a hard issue and produces an incomplete
      solution. Big companies can fill the gaps by providing their own
      value. The result is further concentration of the Internet.

    
Such problems are very hard, but they are not impossible to
      solve. Look for example at PKI and its supporting infrastructure
      like the CAB Forum. It is not perfect, but at least it had the
      property of allowing web sites to use HTTPS without routing all
      authentication transactions through third parties. Wouldn't it be
      nice if we had a federation system on top of OAUTH? I suppose that
      is difficult. Not a reason to not try...

    
-- Christian Huitema

    

  


--------------48E3803F2B4E0F219BF5EDD8--


From nobody Fri Feb 26 12:54:43 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E091C3A0890; Fri, 26 Feb 2021 12:54:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level: 
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwYpXagweZjx; Fri, 26 Feb 2021 12:54:37 -0800 (PST)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640106.outbound.protection.outlook.com [40.107.64.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877F03A0888; Fri, 26 Feb 2021 12:54:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y3/l4dB0vPrYpfAaFsVCjWKTYf3ZiOu5PRtEFlACyuWzaqRTNB0RY5AYWHvzdiDYaPEhJCSb3KdkpqgyBLHA97j4klPAGlcqxmQNoY6HdUW4bJdiG016h1PE3guCA1i7xGMo8iJPZ8tEO2zw9IlCaLtx38Av+KOeEhQkTV8kqdX/aWnrCpA0Sm9Py/b4LNc/NXaI5JfesW61ioKqD0g6N6LtYgsiD8+4ERSFcmAywWQjzMjDG6Q0BJpGJcCk70gNa0JPkwbblPsy5pULZ3B6X+lYFdu0wT0MT5B5LRJg+lJ8n+p2tt5GPGa7gIvY585G04F4Jxzm+qccfAAAl4W/fg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VfttT5tRZM7MrLQXfIDGBUEW93ioQS747HuhHuM1ONU=; b=N7Pk3GegSmUwhcsRaa8ion32yowibpzScjrONIIzYpCuu5Qk+46K43+T/jZjClqfYCx50f1P2rO+9AW7JI793kb5VuIwBzjCmTwoR+oTETNlBY0VLB1mssvhqcPGobjVwLHcDiKG81duOkPKB5v1rUuwI8h3DPxkXDOv/08p6rOIJpv1I2mnszU4m07Ob9E4k7ZeHA5iCUN4CA7JIGZ3cJ+f0uEE6RZo3nxzItDSENTCDcuLJHwzoTgAwfczPDbByAIhyk9oulgCvfQwDmfLThfZNFDO0NSn0xcz4SVs5qulZojwonkFOlHTp6tieB/FjyA/2c2JEufAhCf/TxP5AQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VfttT5tRZM7MrLQXfIDGBUEW93ioQS747HuhHuM1ONU=; b=Bk1ZxCteAuhWF2Y9J6Ah6Fr+TAItavGOPtde1fuzEUPgE6cS+iOBRL62KK17AKwfsuCGDvB4RIyyTZxstQ3wqsRo3rexZDU7+8D3YE/uAOwSKZAIj0sy0bIgTOsY+42zSeZfsNfBx6ZDzaA/cnrWEmwRJ7YHUjugrbYvnBfhxZw=
Received: from SN6PR00MB0429.namprd00.prod.outlook.com (2603:10b6:805:d::12) by SN2PR00MB0191.namprd00.prod.outlook.com (2603:10b6:804:14::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.0; Fri, 26 Feb 2021 20:54:34 +0000
Received: from SN6PR00MB0429.namprd00.prod.outlook.com ([fe80::3d4a:f218:c10c:e4f]) by SN6PR00MB0429.namprd00.prod.outlook.com ([fe80::3d4a:f218:c10c:e4f%4]) with mapi id 15.20.3935.000; Fri, 26 Feb 2021 20:54:34 +0000
From: Mike Jones 
To: "watsonbladd@gmail.com" , nat ,  "rdd@cert.org" 
CC: "secdir@ietf.org" , "oauth@ietf.org" , "last-call@ietf.org" , "draft-ietf-oauth-jwsreq.all@ietf.org" 
Thread-Topic: Secdir last call review of draft-ietf-oauth-jwsreq-30
Thread-Index: AdcMgZCvYIwrbG0eQzWUUepTetS2xA==
Date: Fri, 26 Feb 2021 20:54:34 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-02-26T18:45:46Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d0870aa9-8291-4ab0-8ef5-bbc0f75710c3; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2607:fb90:b2a9:d916:758c:2f2d:f93b:98de]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e11448f7-d2a1-436d-1e67-08d8da98b8dc
x-ms-traffictypediagnostic: SN2PR00MB0191:
x-ms-exchange-minimumurldomainage: arxiv.org#8096
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: g3R0uebJe6qA/zFiI71ro5wPir1hYevIcLBhf/gV2S7H3y8NuvLgF4/HrCRfjsHuAfJdbRf9AqO18FZmHZesV/SyCwWXWeY18ejyBC5+TXaETcYcAghmtTBc9wclPqv1FQzP19QwTPgcdTUtkv9tnF6jUAcLHnGylZt7/Qy/tshn4TeCJjPi4vVAsZzPSyjxv8eegELsgAPfT5RKnB6usCvfqMorjDALI8Qltd6i6+BiG8ZNCyTakudsJxxpF+G4Q5wVYAdBzRmICoB57N2VXQ8n40VwygPMaJI99mK1yWZI4tnOf3d0vdKqsyjNgbKy5vtSr7SzgDutVqpfCSVh4w8fTfN5fxeOTUA0x3kcJKB3/ONHoqm17yr0+cjBF8KjoNzd6fdKs5NkfSPena3ljW7L4MnX6S6UNuYBa4jaGZZoZxyLCZSk2KmHQAfVF6AQUdPANSCozd2q0/fGbTa70ELfxRrw6o71UK52cy5DUys+E9r2bY1JFHi3Z2zZ8ntUCICRJoRNO4yoIwgePX623gdEG/eiPM6FRY0bW47WFoiY34Sbx5cd/oaL1wSVtelgI/QNUV8ONfKqNjD2eThYWeJbtP6/4/GpL4hVEWtePIgxBBttTqkZbAb3xavf8KBFBSHotMWjtv54A7ptOuMtVPw/TFQkfpXljmCyM3Y8aMn51TgQX1AAGXmaEtHRadJu
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:SN6PR00MB0429.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFS:(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(66946007)(82950400001)(66574015)(186003)(166002)(66476007)(76116006)(86362001)(82960400001)(64756008)(966005)(478600001)(110136005)(7696005)(66556008)(316002)(83380400001)(54906003)(66446008)(8936002)(30864003)(33656002)(5660300002)(71200400001)(9686003)(55016002)(6506007)(10290500003)(52536014)(8676002)(8990500004)(4326008)(2906002)(53546011)(546114003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: =?utf-8?B?Zy9CcytEeTVCTERBMTFPclBPOXVIelllQjhQblZmNFVSaHNtVHRqZlRPV2Nr?= =?utf-8?B?TnIrMGlDYzl6Tk5pblRPOXA5Y2dhaHRiSHFId011cDVacnh4WDVLSHNMenJY?= =?utf-8?B?TVd4QndIaERnbTNUQ3lDNWhjdVowUFR2QW1LbSs3a2crTHFtSUdPMWV5QVNT?= =?utf-8?B?RElWNGFKNHlicnVzLzNwbVRlVUpwd3ovTnFpcVduWjZKSzZRWUVUV1JVNjdH?= =?utf-8?B?MU9nUVd6ZmpEeGsyYjdyZitacnFBWTlSZ1lSOHJ3OGVFRlgxc3V2V0txbktB?= =?utf-8?B?cHorWVRrcnBwa1E0d0pDcURUOUZyWFNhZUZQeG4vbHZtSnpSeVR5bTUwUjZh?= =?utf-8?B?OGN6amVPUDduczBkaFFqeml2SC9tZkx6ZlMrR2ZLNkZtb01vTS85YzRMT0ZH?= =?utf-8?B?TUhPc0wrYXdDWU1uYXVGZjA5ckt2RHRMV2lNY2lPc1BlR09wOHkvcTA0NTdZ?= =?utf-8?B?YmNDVmdpOFdTYzNzcVQ3THpkaUZrOWF1RFZsYUNib2g5MXQzaXN1b2tjbWFD?= =?utf-8?B?bnNzVGt1bUJyNVVBcDNBZ3BuN21VN28xTG53aEhDRWJJTDVpVzRma3FkZmdo?= =?utf-8?B?MzZ4U0NOZUZRak80WU1ZbzBxSEExenBIMVRJN1dkNkp6dUliV2QzU3MvR1pK?= =?utf-8?B?elRnVTBuRm93S0txTmI1Q05pbC9EbU9zMWU5ZG90WXV6b3B3ZVRrQmthSHBD?= =?utf-8?B?RnE3NGZlSSsxeHFZTjBpL0JNVVNxTGRwckFxSWJHWXpEbDZEZzlSdkRkdWRK?= =?utf-8?B?S3ByYW1VMzlZVERlbmp3VytVcnl6TS9pNk9uRUQ4TnBFV3VMUVkxdFViZERU?= =?utf-8?B?eVZUb0FVNGtjTklpUDA2WitaU2N1ZUR5UnNUb3czZ2xXUVVxNElIQVdyWnhG?= =?utf-8?B?eUJLdkxVSGNwN09DQy9MTTZvOEFNTndIemN1WWp0UE5xWkZhcDZTZDVHSTVx?= =?utf-8?B?S2FsUW9ENFhxRUd3RjhIN2NUNG1SOWN5amRmd21ZUnBDdm5PNmFyMnEvekFD?= =?utf-8?B?aW81NTBVYlQ4LzZoaWpmRkxsLzA3MWtqQTdoYjBpbDlUYWxucVVMVTRLMERu?= =?utf-8?B?N1B3WHVuZFErYmkxa2VoQ08zUGZ6WStMQTJPWElTcnBBd3JiZGFuV2QwYkUw?= =?utf-8?B?aFJPdVpNVGo4WlR6N0xaUVZUTEVWSWpCektHaWptejgrVGROdFdkLy9WT1pR?= =?utf-8?B?RzZGdXY2YWl2NVBTZDd6RjIvMmc3Rkp1RjFYZkdzZ09NUU5RYm1zeDd6azVy?= =?utf-8?B?dmI5dHltQndBOWdaa0dnZnNXckJwV2gzY2dzbWJzdGhjRmJLcDFnSXpVSWd3?= =?utf-8?B?ME1TMVVmeCtFa3pBcm94aEYwUUluVDdGVTU3Sk9sNXl6QUtkV2psanhXTXov?= =?utf-8?B?MzlyVWhETFJISDJqOW1oNi82OXRCb0lPMkpHUlRsRysraVhGWjc5d0UwVmZF?= =?utf-8?B?VnVLeEt5U3IvK1dZQm95WWVHbjFiQzhENzQ2dVExU0JYWnVwaC80N1pNYzQy?= =?utf-8?B?c0hqeDZlNGZ4R2N1L2NoZlMycE12dEltb3BlZFVVNlRhQk9xNGw3d1ZlOHph?= =?utf-8?B?bnRXekpWRjhhK0dDKzgzSGh0RVM1eHQ2aThuU09ubnFvSDV4bzFkOHg0VUlu?= =?utf-8?B?Rjg3Rkl5dmQ4S1ZXNzc1bXZUQkpjQk15UThWWkVqbmRMZERCSk5rL1hvVVVm?= =?utf-8?B?Y01lZFV4WFo5ZWtVV3dKNm9CZWRtQWxpTmdMbE0wYmxsWmYrNE1COVB0VXhv?= =?utf-8?B?WEgrR1UreEErQ080WVZXalNwTFp3NDdpbmY3eDFvK211VTNJVnQ4TGZJZ1Fq?= =?utf-8?B?WTNMNWZKQnVnZTFmUDA3TnduY0tGblREcWo0M0drN3Q5RU9PcVJLYy9xdDly?= =?utf-8?Q?q8cxkmzPeH7CH?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SN6PR00MB042990C1C9C0DAE300E79A48F59D9SN6PR00MB0429namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN6PR00MB0429.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e11448f7-d2a1-436d-1e67-08d8da98b8dc
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 20:54:34.3393 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ayF/8uu0rXwLuGGeVSmL/pyBV1l5RvgYYHOOhW5jvb7mWmUf7fDORLnTe8gDhRaog4cRROyzuEYXCioZNmQi5Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR00MB0191
Archived-At: 
Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 20:54:42 -0000

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

VGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgV2F0c29uLiAgTXkgcmVwbGllcyB0byB5b3Vy
IGNvbW1lbnRzIGJlbG93IGFyZSBwcmVmaXhlZCBieSAiTWlrZT4iLg0KDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRkIDx3YXRzb25ibGFkZEBnbWFpbC5j
b20+DQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNSwgMjAyMCA5OjAxIFBNDQpUbzogTmF0IFNh
a2ltdXJhIDxuYXRAbmF0LmNvbnN1bHRpbmc+DQpDYzogc2VjZGlyIDxzZWNkaXJAaWV0Zi5vcmc+
OyBJRVRGIG9hdXRoIFdHIDxvYXV0aEBpZXRmLm9yZz47IGxhc3QtY2FsbEBpZXRmLm9yZzsgZHJh
ZnQtaWV0Zi1vYXV0aC1qd3NyZXEuYWxsQGlldGYub3JnDQpTdWJqZWN0OiBbRVhURVJOQUxdIFJl
OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0zMA0K
DQoNCg0KT24gU2F0LCBPY3QgMzEsIDIwMjAgYXQgNjoxMyBBTSBOYXQgU2FraW11cmEgPG5hdEBu
YXQuY29uc3VsdGluZzxtYWlsdG86bmF0QG5hdC5jb25zdWx0aW5nPj4gd3JvdGU6DQoNCj4NCg0K
PiBIaSBXYXRzb24sDQoNCj4NCg0KPiBUaGFua3MgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3LiBJ
IHRob3VnaHQgSSBoYXZlIHNlbnQgbXkgcmVzcG9uc2UNCg0KPiBlYXJsaWVyLCB3aGljaCBJIGFj
dHVhbGx5IGRpZCBub3QuIEl0IHdhcyBzaXR0aW5nIGluIG15IGRyYWZ0IGJveC4gSQ0KDQo+IGFw
b2xvZ2l6ZSBmb3IgaXQuDQoNCg0KDQpNeSBhcG9sb2dpZXMgZm9yIG1pc3NpbmcgaXQgaW4gbXkg
aW5ib3ggZm9yIGEgbnVtYmVyIG9mIG1vbnRocy4NCg0KPg0KDQo+IE15IHJlc3BvbnNlcyBpbmxp
bmU6DQoNCj4NCg0KPiBPbiBTYXQsIFNlcCAyNiwgMjAyMCBhdCA5OjQ2IEFNIFdhdHNvbiBMYWRk
IHZpYSBEYXRhdHJhY2tlcg0KDQo+IDxub3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGll
dGYub3JnPj4gd3JvdGU6DQoNCj4gPg0KDQo+ID4gUmV2aWV3ZXI6IFdhdHNvbiBMYWRkDQoNCj4g
PiBSZXZpZXcgcmVzdWx0OiBTZXJpb3VzIElzc3Vlcw0KDQo+ID4NCg0KPiA+IEkgZ2VuZXJhdGVk
IHRoaXMgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkNCg0K
PiA+IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt
ZW50cyBiZWluZw0KDQo+ID4gcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMg
d2VyZSB3cml0dGVuIHdpdGggdGhlIGludGVudA0KDQo+ID4gb2YgaW1wcm92aW5nIHNlY3VyaXR5
IHJlcXVpcmVtZW50cyBhbmQgY29uc2lkZXJhdGlvbnMgaW4gSUVURg0KDQo+ID4gZHJhZnRzLiAg
Q29tbWVudHMgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkIGluIEFE
DQoNCj4gPiByZXZpZXdzIGR1cmluZyB0aGUgSUVTRyByZXZpZXcuICBEb2N1bWVudCBlZGl0b3Jz
IGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkg
b3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQo+ID4NCg0KPiA+IFR3byBtaW5vciBpc3N1ZXM6
IE9uIHBhZ2UgNCwgIlRoaXMgb2ZmZXJzIGFuIGFkZGl0aW9uYWwgZGVncmVlIG9mDQoNCj4gPiBw
cml2YWN5IHByb3RlY3Rpb24uIiBzaG91bGQgYmUgcmV3b3JkZWQuIEkgZG9uJ3QgdGhpbmsgaXQg
bWFrZXMNCg0KPiA+IHNlbnNlIGluIGNvbnRleHQsIHdoZXJlIGF1dGhlbnRpY2l0eSB3YXMgZGlz
Y3Vzc2VkLg0KDQo+DQoNCj4NCg0KPiBJbiB0aGUgY291cnNlIG9mIHRoZSBlZGl0LCBleHBsYW5h
dGlvbiBhYm91dCB0d28gZGlzdGluY3QgcHJpdmFjeQ0KDQo+IGJlbmVmaXRzIHdhcyBjb2xsYXRl
ZCBpbiBvbmUgc2VudGVuY2UgYW5kIGhhcyBiZWNvbWUgdmVyeSBkaWZmaWN1bHQgdG8NCg0KPiBw
YXJzZS4NCg0KPg0KDQo+IFdoYXQgaXQgaXMgdHJ5aW5nIHRvIGV4cHJlc3MgYXMgcHJpdmFjeSBi
ZW5lZml0cyBhcmUgdGhlIGZvbGxvd2luZy4NCg0KPg0KDQo+IDEpIFRoZSBhdXRob3JpemF0aW9u
IHJlcXVlc3QgY29udGVudCBpcyBzZW50IHRvIHRoZSBBUyBpbiB0aGUNCg0KPiBiYWNrY2hhbm5l
bCBzbyBpdCB3aWxsIG5vdCBiZSBleHBvc2VkIHRocm91Z2ggdGhlIGJyb3dzZXIgdG8gdGhlIGV5
ZXMNCg0KPiBvZiBhbiBhY3RpdmUgb3IgcGFzc2l2ZSBvdXRzaWRlciBvYnNlcnZpbmcgd2hhdCBp
cyBnb2luZyBvbiBpbiB0aGUNCg0KPiBicm93c2VyLiAgSW4gdGhlIFJGQzY3NDkgZnJhbWV3b3Jr
IGNhc2UsIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QNCg0KPiBnb2VzIHRocm91Z2ggdGhlIGJy
b3dzZXIgcmVkaXJlY3QgYW5kIGl0IGNvdWxkIGxlYWsgdG8gdGhlIGFkdmVyc2FyeQ0KDQo+IHZp
YSBXUEFEL1BBQyBBdHRhY2ssIHJlZmVycmVyLCBicm93c2VyIGhpc3RvcnksIGV0Yy4gQWxzbywg
aWYgdGhlDQoNCj4gYnJvd3NlciB3YXMgaW5mZWN0ZWQgYnkgYW4gYWR2ZXJzYXJ5IGNvbnRyb2xs
ZWQgbWFsd2FyZSwgdGhlIGNvbnRlbnQNCg0KPiBjYW4gYmUgc25pZmZlZCBieSB0aGUgYWR2ZXJz
YXJ5LiBJbiB0aGUgY2FzZSBvZiBKQVIsIGl0IGRvZXMgbm90DQoNCj4gaGFwcGVuLiBUaGlzIGlz
IG9uZSBwcml2YWN5IGJlbmVmaXQgaXQgaXMgdHJ5aW5nIHRvIGV4cGxhaW4uDQoNCj4NCg0KPiAy
KSBUaGUgbG9jYXRpb24gdGhhdCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIGdldHRpbmcg
cHVzaGVkIHRvDQoNCj4gZG9lcyBub3QgaGF2ZSB0byBiZSB0aGUgQVMuIEEgdHJ1c3RlZCB0aGly
ZCBwYXJ0eSB0aGF0IGV4YW1pbmVzIHRoZQ0KDQo+IGNvbnRlbnQgZm9yIHRoZSBjb25mb3JtYW5j
ZSB0byB0aGUgY29sbGVjdGlvbiBtaW5pbWl6YXRpb24gcHJpbmNpcGxlDQoNCj4gbWF5IGFjdCBh
cyB0aGUgcGFydHkgdGhhdCBhY2NlcHRzIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgYW5kIGlz
c3Vlcw0KDQo+IHRoZSByZXF1ZXN0X3VyaS4gQVMgY2FuIHRoZW4ganVzdCBldmFsdWF0ZSB0aGUg
ZG9tYWluIHBhcnQgb2YNCg0KPiByZXF1ZXN0X3VyaSB0byBldmFsdWF0ZSB0aGF0IHRoZSBhdXRo
b3JpemF0aW9uIHJlcXVlc3QgaXMgY29uZm9ybWFudA0KDQo+IHRvIHRoaXMgcHJpbmNpcGxlLiBU
aGlzIGlzIGFub3RoZXIgcHJpdmFjeSBiZW5lZml0IGZyb20gdGhlIHBvaW50IG9mDQoNCj4gdmll
dyBvZiB0aGUgaW5kaXZpZHVhbCB1c2VyLg0KDQoNCg0KSSdtIGZpbmUgd2l0aCBhbnkgZml4IHRv
IHRoZSBzZW50ZW5jZSB0aGF0IG1ha2VzIHNlbnNlLiBEb24ndCB0aGluayB3ZSBuZWVkIHRvIGlu
c2VydCB0aGUgYWJvdmUgYnV0IEkgdmVyeSBtdWNoIGFwcHJlY2lhdGUgdGhlIGV4cGxhbmF0aW9u
Lg0KDQoNCg0KTWlrZT4gR2l2ZW4gdGhhdCBpdHMgbWVhbmluZyBpcyBmYWlybHkgaW5zY3J1dGFi
bGUsIGFuZCB0aGF0IHRoZSB0d28gYmVuZWZpdHMgZGVzY3JpYmVkIGJ5IE5hdCBhYm92ZSBhcmUg
cGFydGlhbGx5IHJlbGF0ZWQgdG8gcGFyYWdyYXBocyBvdGhlciB0aGFuIHRoZSBvbmUgd2l0aCB0
aGUgcHJpdmFjeSBzdGF0ZW1lbnQsIEkgcHJvcG9zZSB0aGF0IHdlIHNpbXBseSBkZWxldGUgdGhl
IHNlbnRlbmNlICJUaGlzIG9mZmVycyBhbiBhZGRpdGlvbmFsIGRlZ3JlZSBvZiBwcml2YWN5IHBy
b3RlY3Rpb24uIiBmcm9tIHRoaXMgcGFyYWdyYXBoLg0KDQoNCg0KPiA+IEl0IHRvb2sgbWUgYSB3
aGlsZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhlIGJ5IHJlZmVyZW5jZSBtZXRob2QgaXM6DQoNCj4g
PiBtYXliZSB0aGUgaW50cm8gc2hvdWxkIHNheSB2aWEgVVJMIGluc3RlYWQgb2YgYnkgcmVmZXJl
bmNlLg0KDQo+DQoNCj4NCg0KPiByZXF1ZXN0X3VyaSBjYW4gYmUgVVJMIG9yIGEgaGFuZGxlIHN1
Y2ggYXMgVVJOLiBUaGF0IGlzIHdoeSB0aGUgImJ5DQoNCj4gcmVmZXJlbmNlIiB3b3JkIGlzIGJl
aW5nIHVzZWQsIHBlciB0aGUgc3VnZ2VzdGlvbiBvZiB0aGUgV0cuDQoNCg0KDQpJJ20gZmluZSB3
aXRoIHRoYXQsIGp1c3Qgbm90aW5nIG15IGNvbmZ1c2lvbi4NCg0KDQoNCk1pa2U+IFVuZGVyc3Rv
b2QuICBJIGxvb2tlZCBhdCB3YXlzIHRvIHBvc3NpYmx5IG1vdmUgdGhlICJieSByZWZlcmVuY2Ui
IHRleHQgdGhhdCBmb2xsb3dzIGluIGEgZmV3IHBhcmFncmFwaHMgZWFybGllciB0byBwb3NzaWJs
eSBtYWtlIHRoaXMgY2xlYXJlciwgYnV0IGl0IHdvdWxkIG1lc3MgdXAgdGhlIGxvZ2ljYWwgZmxv
dyBvZiB0aGUgSW50cm9kdWN0aW9uLiAgVW5sZXNzIHlvdSBoYXZlIGEgYmV0dGVyIHN1Z2dlc3Rp
b24sIEkgcHJvcG9zZSB0aGF0IHdlIGxlYXZlIHRoaXMgYXMtaXMuDQoNCg0KDQo+ID4gQW5kIG5v
dyBmb3IgdGhlIHRob3JueSBpc3N1ZXMgd2l0aCB0aGlzIGRyYWZ0LiBTaWduYXR1cmVzIGFuZA0K
DQo+ID4gZW5jcnlwdGlvbiBhcmUgZGlmZmVyZW50LiBBbmQgZW5jcnlwdGluZyBhIHNpZ25lZCBi
bG9iIGRvZXNuJ3QgbWVhbiB0aGUgc2lnbmVyIGVuY3J5cHRlZCBpdC4NCg0KPiA+IFRoZW4gdGhl
cmUgYXJlIGEgcGxldGhvcmEgb2YgbWV0aG9kcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0ICB0bw0K
DQo+ID4gYXV0aGVudGljYXRlIHRoZSBibG9iLCB3aGljaCB3aWxsIGdpdmUgZGlmZmVyZW50IHJl
c3VsdHMgaW4NCg0KPiA+IG1hbGljaW91c2x5IGNvbnN0cnVjdGVkIGV4YW1wbGVzLiBUaGUgc2Vj
dXJpdHkgY29uc2lkZXJhdGlvbnMNCg0KPiA+IHNlY3Rpb24gc2hvdWxkIGRpc2N1c3Mgd2hhdCB0
aGUgZW5jcnlwdGVkIHZzIHNpZ25lZCBjaG9pY2VzIGdpdmUgaW4NCg0KPiA+IHRoZSB3YXkgb2Yg
c2VjdXJpdHksIGFuZCBpdCBkb2Vzbid0LiBUaGlzIG1ha2VzIG1lIHdvcnJ5Lg0KDQo+DQoNCj4g
V2UgZG9u4oCZdCBleHBlY3QgdGhlIGVuY3J5cHRpb24gdG8gZW5zdXJlIGF1dGhlbnRpY2l0eSwg
dGhhdOKAmXMgd2hhdCB0aGUNCg0KPiBzaWduYXR1cmVzIGFyZSB1c2VkIGZvci4NCg0KDQoNClRo
aXMgbmVlZHMgdG8gYmUgdmVyeSBjbGVhcmx5IHNwZWxsZWQgb3V0IGluIHRoZSB0ZXh0LiBMb3Rz
IG9mIHBlb3BsZSB3aWxsIG5vdCB1bmRlcnN0YW5kIHRoaXMuIFRoZSB3b3JkaW5nIG9mIHNlY3Rp
b24gMTAuMiBpcyBhdCBiZXN0IGFtYml2YWxlbnQsIHdpdGggbXVsdGlwbGUgYWx0ZXJuYXRpdmVz
IHByZXNlbnRlZCBhcyBhY2NlcHRhYmxlLg0KDQoNCg0KTWlrZT4gQWZ0ZXIgdGhlIHNlbnRlbmNl
IGF0IDEwLjIgKGIpIGFib3V0IHN5bW1ldHJpYyBlbmNyeXB0aW9uLCBJIHByb3Bvc2UgdGhhdCB3
ZSBhZGQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSB0byBlbXBoYXNpemUgdGhlIHBvaW50IHlvdSdy
ZSByYWlzaW5nOiAgIk5vdGUgaG93ZXZlciwgdGhhdCBpZiBwdWJsaWMga2V5IGVuY3J5cHRpb24g
aXMgdXNlZCwgbm8gc291cmNlIGF1dGhlbnRpY2F0aW9uIGlzIGVuYWJsZWQgYnkgdGhlIGVuY3J5
cHRpb24sIGFzIGFueSBwYXJ0eSBjYW4gZW5jcnlwdCBjb250ZW50IHRvIHRoZSBwdWJsaWMga2V5
LiINCg0KDQoNCjxjaG9wPg0KDQo+DQoNCj4gSSBkaWRuJ3QgcXVpdGUgZ2V0IHdoYXQgaXMgbWVh
bnQgYnkgInBsZXRob3JhIG9mIG1ldGhvZHMgc3BlY2lmaWVkIGluDQoNCj4gdGhlIGRyYWZ0IHRv
IGF1dGhlbnRpY2F0ZSB0aGUgYmxvYiAuLi4gIg0KDQo+IFRoZXJlIGlzIGEgYml0IG9mIHRleHQg
YWJvdXQgYXV0aGVudGljYXRpbmcgdGhlIHNvdXJjZSAoPWNsaWVudCkgYnV0DQoNCj4gbm90IG11
Y2ggb24gdGhlIGJsb2IgaXRzZWxmLg0KDQo+IFRoZSBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgc2ln
bmF0dXJlIGFuZC9vciBlbmNyeXB0aW9uIGlzIGNvdmVyZWQgaW4NCg0KPiBSRkM3NTE5IChKV1Qp
LCB0aGUgZm9ybWF0IHRoYXQgdGhlIHJlcXVlc3Qgb2JqZWN0IGFzc3VtZXMuDQoNCj4gVGhpcyBp
cyByZXF1aXJlZCByZWFkaW5nIHdoZW4gaW1wbGVtZW50aW5nIHRoaXMgc3BlYywgc28gV0cgdGhv
dWdodCBpdA0KDQo+IGlzIG5vdCB3b3J0aCByZXBlYXRpbmcgaGVyZS4NCg0KPiBBdHRhY2tzIGV0
Yy4gb24gdGhlIHNpZ25hdHVyZSBhbmQgZW5jcnlwdGlvbiBhcmUgY292ZXJlZCBpbiBSRkM3NTE1
DQoNCj4gYW5kIFJGQzc1MTYgcmVzcGVjdGl2ZWx5Lg0KDQoNCg0KV2VsbCwgdGhlIGRyYWZ0IGhh
cHBlbnMgdG8gaW5jbHVkZSB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCiAgICJUaGUgQXV0aG9yaXph
dGlvbiBTZXJ2ZXIgTVVTVCB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlIG9mIHRoZSBKU09OIFdlYg0K
DQogICBTaWduYXR1cmUgW1JGQzc1MTVdIHNpZ25lZCBSZXF1ZXN0IE9iamVjdC4gIFRoZSBzaWdu
YXR1cmUgTVVTVCBiZQ0KDQogICB2YWxpZGF0ZWQgdXNpbmcgdGhlIGtleSBmb3IgdGhhdCAiY2xp
ZW50X2lkIiBhbmQgdGhlIGFsZ29yaXRobQ0KDQogICBzcGVjaWZpZWQgaW4gdGhlICJhbGciIEhl
YWRlciBQYXJhbWV0ZXIuIg0KDQoNCg0KU2hvdWxkbid0IHRoZSBrZXkgYmUgYXNzb2NpYXRlZCB3
aXRoIGEgc2luZ2xlIGFsZ29yaXRobT8gSG93IGRvIHdlIGVuc3VyZSB0aGF0IHRoZSBjb21tb24g
YXR0YWNrIG9mIHRlbGxpbmcgdGhlIHNlcnZlciB0byB1c2UgaG1hYyB0byB2ZXJpZnkgdGhlIHNp
Z25hdHVyZSBkb2Vzbid0IHdvcmsgaGVyZT8NCg0KDQoNCk1pa2U+IEdvb2QgcG9pbnQuICBUaGlz
IGF0dGFjayBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEgb2YgUkZDIDg3MjUgYW5kIG1pdGln
YXRlZCBieSB0aGUgcHJhY3RpY2VzIGluIFNlY3Rpb25zIDMuMSBhbmQgMy4yIG9mIHRoZSBzYW1l
LiAgSSBwcm9wb3NlIHRoYXQgd2UgcmVwbGFjZSB0aGUgc2VudGVuY2U6DQoNCiAgICAiVGhlIHNp
Z25hdHVyZSBNVVNUIGJlIHZhbGlkYXRlZCB1c2luZyB0aGUga2V5IGZvciB0aGF0ICJjbGllbnRf
aWQiIGFuZCB0aGUgYWxnb3JpdGhtIHNwZWNpZmllZCBpbiB0aGUgImFsZyIgSGVhZGVyIFBhcmFt
ZXRlci4iDQoNCndpdGg6DQoNCiAgICAiVGhlIHNpZ25hdHVyZSBNVVNUIGJlIHZhbGlkYXRlZCB1
c2luZyBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudCBhbmQgdGhlIGFsZ29yaXRobSBz
cGVjaWZpZWQgaW4gdGhlICJhbGciIEhlYWRlciBQYXJhbWV0ZXIuICBJZiBhICJraWQiIEhlYWRl
ciBQYXJhbWV0ZXIgaXMgcHJlc2VudCwgdGhlIGtleSBpZGVudGlmaWVkIE1VU1QgYmUgdGhlIGtl
eSB1c2VkLCBhbmQgTVVTVCBiZSBhIGtleSBhc3NvY2lhdGVkIHdpdGggdGhlIGNsaWVudC4gIEFs
Z29yaXRobSB2ZXJpZmljYXRpb24gTVVTVCBiZSBwZXJmb3JtZWQsIGFzIHNwZWNpZmllZCBpbiBT
ZWN0aW9ucyAzLjEgYW5kIDMuMiBvZiBSRkMgODcyNS4iDQoNCg0KDQo+ID4gTG9va2luZyBhdCB0
aGUgY2l0ZWQgcmVmZXJlbmNlIGZvciBhdHRhY2tzLCBJIHNlZSB0aGUgZml4IGlzIHRvDQoNCj4g
PiBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0IHdoaWNoIElQRCB3YXMgdXNlZCBieSB0aGUgUlAu
IEJ1dCB0aGUNCg0KPiA+IGRyYWZ0IGJlZm9yZSB1cyBkb2Vzbid0IG1hbmRhdGUgdGhhdC4gSXQn
cyBub3QgY2xlYXIgdGhhbiBob3cgdGhlDQoNCj4gPiBjaXRlZCBhdHRhY2sgaXMgcHJldmVudGVk
IGJ5IHRoZSBkcmFmdC4gU2F5aW5nIHRoYXQgdGhlDQoNCj4gPiBjb21tdW5pY2F0aW9uIHRocm91
Z2ggdGhlIHVzZXItYWdlbnQgaXMgc3ViamVjdCB0bw0KDQo+DQoNCj4gVGhlIG1lbnRpb24gb2Yg
bWl4LXVwIGF0dGFjayB3YXMgaW50cm9kdWNlZCBhZnRlciB0aGUgTGFzdCBjYWxsIGJ5IG9uZQ0K
DQo+IG9mIHRoZSBjb21tZW50LiBJdCBqdXN0IGFkZGVkIGl0IGluIHRoZSBzZW50ZW5jZSB3aXRo
IGEgcmVmZXJlbmNlLiBJDQoNCj4gYW0gb2sgdG8gcmVtb3ZlIGl0Lg0KDQoNCg0KVGhhdCB3b3Jr
cyBmb3IgbWUuDQoNCg0KDQpNaWtlPiBJIHdpbGwgcmVtb3ZlIHRoZSBtaXgtdXAgYXR0YWNrIHJl
ZmVyZW5jZSBpbiB0aGUgbmV4dCBkcmFmdC4NCg0KDQoNCj4gSGF2aW5nIHNhaWQgdGhhdCwgdGhl
IGhlYXJ0IG9mIG1peC11cCBhdHRhY2sgaXMgdGhhdCB0aGUgY29tYmluYXRpb24NCg0KPiBvZiB0
aGUgY2xpZW50IGJlbGlldmVzIHRoYXQgaXQgaXMgY29tbXVuaWNhdGluZyB3aXRoIHRoZQ0KDQo+
IGF0dGFja2VyLWNvbnRyb2xsZWQgQVMgKEFBUykgd2hpbGUgaXQgaW4tZmFjdCBpcyB0YWxraW5n
IHRvIEhvbmVzdCBBUw0KDQo+IChIQVMpLCBBTkQgSEFTIHVuYWJsZSB0byBmaW5kIG91dCB0aGF0
IHRoZSBjbGllbnQgaXMgdGhpbmtpbmcgdGhhdCBpdA0KDQo+IGlzIHRhbGtpbmcgdG8gQUFTIG5v
dCBoaW0uDQoNCj4NCg0KPiBPQXV0aCBKQVIgc2VlbXMgdG8gbWl0aWdhdGUgaXQgaW4gdHdvIHdh
eXM6DQoNCj4NCg0KPiBhKSBVc2UgcmVxdWVzdF91cmkgd2hpY2ggaXMgaG9zdGVkIGJ5IHRoZSBB
Uy4gVGhlbiwgaWYgdGhlIGNsaWVudCBpcw0KDQo+IHRoaW5raW5nIHRoYXQgaXQgaXMgdGFsa2lu
ZyB0byB0aGUgQUFTLCB0aGVuIGl0IHdpbGwgcHVzaCBpdCB0byBBQVMNCg0KPiBhbmQgd2hlbiB0
aGUgdXNlciBpcyByZWRpcmVjdGVkIHRvIEhBUywgSEFTIHdpbGwgZmluZCBvdXQgdGhhdCB0aGUN
Cg0KPiByZXF1ZXN0X3VyaSBpcyBub3QgY3JlYXRlZCBieSBoZXJzZWxmIGFuZCByZXR1cm4gYW4g
ZXJyb3IsIG1ha2luZyB0aGUNCg0KPiBtaXgtdXAgYXR0YWNrIGZhaWwuDQoNCj4NCg0KPiBiKSBJ
bmNsdWRlIGBhdWRgIGluIHRoZSByZXF1ZXN0LiBUaGVuLCB3aGVuIHRoZSBIQVMgd2lsbCBmaW5k
IHRoYXQgdGhlDQoNCj4gcmVxdWVzdCB3YXMgbWludGVkIHRvIEFBUyBhbmQgbm90IGhlci4gU28s
IGl0IHdpbGwgcmVzdWx0IGluIGFuIGVycm9yLA0KDQo+IG1ha2luZyB0aGUgbWl4LXVwIGF0dGFj
ayBmYWlsLg0KDQoNCg0KSWYgdGhlIGRyYWZ0IG1hbmRhdGVzIGRvaW5nIHRoaXMgaXQgYWRkcmVz
c2VzIHRoZSBhdHRhY2sgYW5kIHRoZSBzZW50ZW5jZSBjYW4gc3RheS4NCg0KDQoNCk1pa2U+IFRo
ZSBkcmFmdCBtYW5kYXRlcyB1c2Ugb2YgImF1ZCIgYnV0IGl0IGRvZXMgbm90IG1hbmRhdGUgdGhh
dCB0aGUgcmVxdWVzdF91cmkgYmUgaG9zdGVkIGJ5IHRoZSBBUy4gIFRoZXJlZm9yZSwgSSB0aGlu
ayB3ZSBzaG91bGQgcmVtb3ZlIHRoZSBtaXgtdXAgYXR0YWNrIHJlZmVyZW5jZS4NCg0KDQoNCj4g
U28sIEkgYWRkZWQgbWl4LXVwIGF0dGFjayB0byB0aGUgc2VudGVuY2UgdGhpbmtpbmcgdGhlIGNv
bW1lbnRlcidzDQoNCj4gcmVxdWVzdCB0byBhZGQgaXQgaXMgZmluZSwgYnV0IEkgYW0gZmluZSB3
aXRoIHJlbW92aW5nIGl0Lg0KDQo+DQoNCj4gPiBtYW5pcHVsYXRpb24sIGFuZCB0aGlzIHByZXZl
bnRzIGl0LCBpZ25vcmVzIHRoYXQgdGhlIGF0dGFja2VyIGluDQoNCj4gPiB0aGF0IHBvc2l0aW9u
IHNlZXMgYSBsb3QgbW9yZS4gVGhlIHVzZXItYWdlbnQgYXMgcmVzb3VyY2Ugb3duZXINCg0KPiA+
IG1vZGlmeWluZyB0aGUgcmVxdWVzdGVkIHJlc291cmNlcyBpcyBhIHZlcnkgZnVubnkgc29ydCBv
ZiBhdHRhY2s6DQoNCj4gPiBjYW4ndCB0aGV5IGRvIHdoYXQgdGhleSB3YW50IHdpdGggdGhlIHJl
c291cmNlcyBzaW5jZSB0aGV5IGNvbnRyb2wgdGhlIGFjY2Vzcz8NCg0KPg0KDQo+IElmIHRoZSBj
bGllbnQgaXMgaW4gdGhlIGJyb3dzZXIsIHllcy4NCg0KPiBCdXQgaW4gdGhlIG1haW5zdHJlYW0g
Y2FzZSwgdGhlIGNsaWVudCBpcyBub3QgaW4gdGhlIGJyb3dzZXIgYnV0IHRoZQ0KDQo+IHdlYi1z
ZXJ2ZXIgdGhhdCB0aGUgYnJvd3NlciBpcyBjb21tdW5pY2F0aW5nIHdpdGggYW5kIHRoZSByZXNv
dXJjZQ0KDQo+IGFjY2VzcyBoYXBwZW5zIHdpdGhvdXQgYmVpbmcgbWVkaWF0ZWQgYnkgdGhlIGJy
b3dzZXIuDQoNCg0KDQpNeSBjb25jZXJuIG9uIHRoaXMgcG9pbnQgaXMgcmVzb2x2ZWQuDQoNCg0K
DQpNaWtlPiBUaGFua3MNCg0KDQoNCj4gPiBLZXkgbWFuYWdlbWVudCBpcyBpZ25vcmVkLiBUaGlz
IGlzIGEgdmVyeSBpbXBvcnRhbnQgaXNzdWUsDQoNCj4gPiBlc3BlY2lhbGx5DQoNCj4NCg0KPiBB
IGxvdCBvZiBncm91bmQgaXMgY292ZXJlZCBieSBSRkMgNzUxNSwgNzUxNiwgNzUxNywgNzUxOCwg
NzUxOSwgNzU5MSwNCg0KPiBhbmQgODQxNCBzbyB0aGlzIGRvY3VtZW50IGlzIG5vdCBzcGVjaWZp
Y2FsbHkgcmVzdGF0aW5nIHRoZW0uDQoNCj4NCg0KPiA+DQoNCj4gPiBjb25zaWRlcmluZyB0aGUg
cG90ZW50aWFsIHByb2JsZW1zIHdpdGggdGhlIHJldXNlIG9mIEpXVC4gSSdkIGxpa2UNCg0KPiA+
IHRvIHNlZSBhDQoNCj4NCg0KPiBBcmUgeW91IHRhbGtpbmcgYWJvdXQgdGhlIHJldXNlIG9mIHRo
ZSByZXF1ZXN0IG9iamVjdCBieSBhbiBhZHZlcnNhcnkNCg0KPiB0cnlpbmcgdG8gYWN0IGFzIGFu
IGhvbmVzdCBjbGllbnQ/DQoNCj4gRXZlbiBpZiBpdCBoYXBwZW5zLCB0aGUgbWFsaWNpb3VzIGNs
aWVudCBkb2VzIG5vdCBoYXZlIHRoZSBwcm9wZXINCg0KPiBjbGllbnQgY3JlZGVudGlhbCBzbyBp
dCBjYW5ub3QgcmVkZWVtIHRoZSBjb2RlIGl0IG9idGFpbmVkIHdpdGggdGhlDQoNCj4gdG9rZW4u
IEl0IGlzIG5vIGRpZmZlcmVudCB0aGFuIFJGQzY3NDkgY29kZSBncmFudC4gUHJvdG9jb2xzIHRo
YXQNCg0KPiBleHRlbmQgaXQsIHN1Y2ggYXMgT3BlbklEIENvbm5lY3QsIGhhdmUgaW50cm9kdWNl
ZCBub25jZSB0byBwcmV2ZW50DQoNCj4gdGhlIHJldXNlIGFuZCB1c2VkIEpBUiAoaXQgaXMgY2Fs
bGVkIHJlcXVlc3Qgb2JqZWN0IHRoZXJlKSB0byBmdXJ0aGVyDQoNCj4gcHJvdGVjdCB0YW1wZXJp
bmcgYW5kIGFjaGlldmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGV2ZW4gaW4gdGhlIGZyb250DQoN
Cj4gY2hhbm5lbC4NCg0KPg0KDQo+ID4gcmVjb21tZW5kYXRpb24gdGhhdCBrZXlzIGJlIHNlcGFy
YXRlZCBieSBpbnRlbmRlZCB1c2VzLCByYXRoZXIgdGhhbg0KDQo+ID4gbGltaXRpbmcgcGFydGlj
dWxhciBmaWVsZHMgaW4gYW4gYWQtaG9jIG1hbm5lci4NCg0KPg0KDQo+IENvdWxkIHlvdSBraW5k
bHkgZWxhYm9yYXRlIG9uIHRoZSAiYWQtaG9jIG1hbm5lciIgcGFydCBzbyB0aGF0IEkgY2FuDQoN
Cj4gdW5kZXJzdGFuZCBpdCBtb3JlIGZ1bGx5Pw0KDQoNCg0KMTAuOCwgQ3Jvc3MtSldUIENvbmZ1
c2lvbiBkaXNjdXNzZXMgYXZvaWRpbmcgc2lnbmluZyBjZXJ0YWluIGZpZWxkcywgcmF0aGVyIHRo
YW4gc3VnZ2VzdGluZyBnb29kIGtleSB1c2FnZSBhcyBhIHNvbHV0aW9uLg0KDQoNCg0KTWlrZT4g
SSBwcm9wb3NlIHRvIGFkZCB0aGlzIG5ldyBwYXJhZ3JhcGggYXQgdGhlIGVuZCBvZiBTZWN0aW9u
IDEwLjggdG8gaW1wbGVtZW50IHlvdXIgc3VnZ2VzdGlvbjoNCg0KICAgICJGaW5hbGx5LCBhbm90
aGVyIHdheSB0byBwcmV2ZW50IGNyb3NzLUpXVCBjb25mdXNpb24gaXMgdG8gdXNlIGEga2V5IG1h
bmFnZW1lbnQgcmVnaW1lIGluIHdoaWNoIGtleXMgdXNlZCB0byBzaWduIFJlcXVlc3QgT2JqZWN0
cyBhcmUgaWRlbnRpZmlhYmx5IGRpc3RpbmN0IGZyb20gdGhvc2UgdXNlZCBmb3Igb3RoZXIgcHVy
cG9zZXMuICBUaGVuLCBpZiBhbiBhZHZlcnNhcnkgYXR0ZW1wdHMgdG8gcmVwdXJwb3NlIHRoZSBS
ZXF1ZXN0IE9iamVjdCBpbiBhbm90aGVyIGNvbnRleHQsIGEga2V5IG1pc21hdGNoIHdpbGwgb2Nj
dXIsIHRod2FydGluZyB0aGUgYXR0YWNrLiINCg0KDQoNCj4gPiBUaGVuIHdlIGhhdmUgc2VjdGlv
biAxMS4gV2hhdCBzZWN0aW9uIDExIGludHJvZHVjZXMgaXMgYW4gZW50aXJlIG5ldw0KDQo+ID4g
ZHJhbWF0aXMgcGVyc29uYWUsIHRoZSBUcnVzdCBGcmFtZXdvcmsgUHJvdmlkZXIsIHdpdGggbm8g
cHJpb3INCg0KPiA+IGRpc2N1c3Npb24gb2Ygd2hhdCBpdCBpcyBvciBhIHJlZmVyZW5jZSB0byB3
aGVyZSBpdCBpcyBkZWZpbmVkIGFuZCBhDQoNCj4gPiBnb29kIG51bWJlciBvZiBzdGF0ZW1lbnRz
IGFib3V0IGhvdyBpdCB3b3JrcyB0aGF0IGFyZW4ndCByZWFsbHkgIGNsZWFyIHdoYXQgdGhleSBt
ZWFuIGZyb20gdGhlIGRvY3VtZW50IHRvIG1lLg0KDQo+DQoNCj4gVHJ1c3QgRnJhbWV3b3JrIFBy
b3ZpZGVyIGZpcnN0IGFwcGVhcnMgaW4gNS4yLjEuDQoNCj4gQXQgdGhlIHRpbWUgb2Ygd3JpdGlu
ZyB0aGUgcmVsYXRlZCB0ZXh0LCBpdCB3YXMgYSBwcmV0dHkgd2VsbC1rbm93bg0KDQo+IGNvbmNl
cHQuIEluIHRoZSBVbml0ZWQgU3RhdGUsIGl0IHdhcyBwYXJ0IG9mIGl0cyBOYXRpb25hbCBTdHJh
dGVneQ0KDQo+IChOU1RJQykgYW5kIGludGVybmF0aW9uYWxseSwgaXQgd2FzIGV2ZW4gdGFrZW4g
dXAgYXQgV0VGIERhdm9zDQoNCj4gbWVldGluZy4gSXQgaXMgcXVpdGUgc3VycHJpc2luZyB0aGF0
IHN1Y2ggYSBtYWluc3RyZWFtIGNvbmNlcHQgZmFkZWQNCg0KPiBpbnRvIG9ic2N1cml0eSBzbyBx
dWlja2x5LiBUaGUgcmVhc29uIGZvciBpbnRyb2R1Y2luZyBpdCB3YXMgdG8gYSkNCg0KPiBqdXN0
aWZ5IHJlcXVlc3RfdXJpIGFzIHNvbWUgV0cgbWVtYmVycyB3YW50ZWQgaXQgdG8gYmUgcmVtb3Zl
ZCwgYikNCg0KPiBqdXN0aWZ5IHRoYXQgcmVxdXN0X3VyaSB0byBiZSBzZXJ2ZWQgZnJvbSBhIGRp
ZmZlcmVudCBkb21haW4uIE5vdyB0aGF0DQoNCj4gcGVvcGxlIGFwcHJlY2lhdGUgaXQsIGUuZy4s
IGl0IGNhbiBiZSBzZWVuIGZyb20gUEFSLCB0aGUganVzdGlmaWNhdGlvbg0KDQo+IGZvciBhKSBw
cm9iYWJseSBpcyBubyBsb25nZXIgcmVxdWlyZWQuIEEgZnVsbCBleHBsYW5hdGlvbiBmb3IgYikg
d291bGQNCg0KPiBwcm9iYWJseSBiZSBhIG11Y2ggbG9uZ2VyIHRleHQgYnV0IEkgZG91YnQgaWYg
aXQgYmVsb25ncyB0byB0aGlzDQoNCj4gZG9jdW1lbnQuIEkgYW0gZmluZSB3aXRoIHJlbW92aW5n
IHRoZSByZWZlcmVuY2UgdG8gVHJ1c3QgZnJhbWV3b3JrDQoNCj4gZXRjLiBhcyBsb25nIGFzIHRo
ZSBjYXBhYmlsaXR5IHRvIHB1c2ggdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0byBhDQoNCj4g
cGxhY2Ugb3RoZXIgdGhhbiB0aGUgY2xpZW50IG9yIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBp
cyBub3QNCg0KPiByZW1vdmVkLg0KDQoNCg0KTGV0J3MgcmVtb3ZlIHRoZSB0ZXh0IHRoZW4sIGJ1
dCBrZWVwIHRoZSBjYXBhYmlsaXR5Lg0KDQoNCg0KTWlrZT4gSSBwcm9wb3NlIHRvIHJlbW92ZSB1
c2VzIG9mIHRoZSB0ZXJtICJUcnVzdCBGcmFtZXdvcmsgUHJvdmlkZXIiIGFuZCBpbnN0ZWFkIHJl
cGxhY2UgdGhlbSBieSB0aGUgbW9yZSBnZW5lcmljIHRlcm0gInRydXN0ZWQgdGhpcmQtcGFydHkg
c2VydmljZSIuDQoNCg0KDQo+ID4gTXkgYmlnZ2VzdCBjb25jZXJuIGlzIHRoYXQgdGhlc2UgaXNz
dWVzIGFyZSBzaWducyB0aGF0IHRoZSBwcm9ibGVtDQoNCj4gPiB0aGlzIGRyYWZ0IGlzIHRyeWlu
ZyB0byBzb2x2ZSBhbmQgdGhlIG1lY2hhbmlzbXMgdG8gc29sdmUgaXQgaGF2ZW4ndA0KDQo+ID4g
YmVlbiBhbmFseXplZCBhcyB0aG9yb3VnaGx5IGFzIHRoZXkgc2hvdWxkIGhhdmUgYmVlbi4gV2l0
aG91dCB0aGF0DQoNCj4gPiBzb3J0IG9mIHRob3JvdWdoIGFuYWx5c2lzIGl0J3Mgbm90IGNlcnRh
aW4gdGhhdCB0aGUgbWVjaGFuaXNtcw0KDQo+ID4gYWN0dWFsbHkgc29sdmUgdGhlIHByb2JsZW0g
YW5kIGl0J3Mgbm90IGNsZWFyIHdoYXQgdGhlDQoNCj4gPiByZWNvbW1lbmRhdGlvbnMgdG8gaW1w
bGVtZW50ZXJzIGhhdmUgdG8gYmUgdG8gcHJlc2VydmUgdGhvc2UgcHJvcGVydGllcy4NCg0KPg0K
DQo+IE9BdXRoIEpBUiwgYXMgdGhlIG5hbWUgIlRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBG
cmFtZXdvcms6IEpXVA0KDQo+IFNlY3VyZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpIiBz
dWdnZXN0cywgaXMgYSBmcmFtZXdvcmsgYW5kIG5vdA0KDQo+IGEgaG91c2UgaXRzZWxmLiBPbmUg
c3VjaCBleGFtcGxlIGlzIEZBUEkgWzFdIHdoaWNoIHdhcyBmb3JtYWxseQ0KDQo+IHZlcmlmaWVk
IFsyXS4NCg0KDQoNCiJJdCdzIHBvc3NpYmxlIHRvIHVzZSB0aGlzIGRyYWZ0IHNlY3VyaXR5IiBJ
IGRvbid0IHRoaW5rIHNob3VsZCBiZSBlbm91Z2ggYW55bW9yZS4gUmF0aGVyIGl0IHNob3VsZCBi
ZSBpbXBvc3NpYmxlIHRvIHVzZSBpbnNlY3VyZWx5Lg0KDQoNCg0KTWlrZT4gVGhlIGRyYWZ0IGRl
c2NyaWJlcyBob3cgdG8gdXNlIHRoZSBtZWNoYW5pc20gc2VjdXJlbHkuICBZZXMsIGlmIHBvcnRp
b25zIG9mIHRoZSBkcmFmdCAoYW5kIHRob3NlIGl0IGRlcGVuZHMgdXBvbikgYXJlIG5vdCBmb2xs
b3dlZCwgaW5zZWN1cmUgdXNhZ2UgY2FuIHJlc3VsdC4gIFRoYXQncyB0cnVlIG9mIGFueSBzZWN1
cml0eSBkcmFmdC4gIElmIHRoZXJlIGFyZSBhZGRpdGlvbmFsIHNwZWNpZmljIHJlcXVpcmVtZW50
cyBhbmQvb3IgcmVjb21tZW5kYXRpb25zIG5lZWRlZCwgd2UnZCBiZSBnbGFkIHRvIGFkZCB0aGVt
LiAgSWYgc28sIHBsZWFzZSBpZGVudGlmeSB0aGVtLiAgKEluZGVlZCwgd2UncmUgYWxyZWFkeSBk
b2luZyBzbyBpbiByZXNwb25zZSB0byB5b3VyIGV4aXN0aW5nIHNwZWNpZmljIGZlZWRiYWNrLikN
Cg0KDQoNCk1pa2U+IEFzIGZvciBwYXN0IEpXVCBwcm9ibGVtcywgdGhlIEpXVCBCQ1AgW1JGQyA4
NzI1XSB3YXMgd3JpdHRlbiBhdCB0aGUgcmVxdWVzdCBvZiB0aGUgSUVTRyB0byBpZGVudGlmeSBh
bmQgbWl0aWdhdGUgdGhlbSAtIGVzcGVjaWFsbHkgaW4gbGlnaHQgb2YgSldUcyBiZWluZyB1c2Vk
IGZvciBhZGRpdGlvbmFsIHVzZSBjYXNlcywgc3VjaCBhcyBTVElSIHNlY3VyZWQgdGVsZXBob255
IGFuZCBzZWN1cmluZyBmaXJzdC1yZXNwb25kZXIgc2VydmljZXMuICBJZiB5b3UgYmVsaWV2ZSB0
aGF0IGFkZGl0aW9uYWwgZ2VuZXJpYyBKV1QgaXNzdWVzIHNob3VsZCBiZSBkaXNjdXNzZWQgYW5k
IGFkZHJlc3NlZCwgd2UgY291bGQgYWx3YXlzIHJldmlzZSB0aGlzIEJDUC4gIEJ1dCBkb2luZyBz
byBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgUkZDLg0KDQoNCg0KPiBbMV0NCg0KPiBodHRw
czovL2JpdGJ1Y2tldC5vcmcvb3BlbmlkL2ZhcGkvc3JjL21hc3Rlci9GaW5hbmNpYWxfQVBJX1dE
XzAwMi5tZA0KDQo+IFsyXSBodHRwczovL2FyeGl2Lm9yZy9hYnMvMTkwMS4xMTUyMA0KDQo+DQoN
Cj4gPg0KDQo+ID4gT2J2aW91c2x5IHRoaXMgZHJhZnQgaGFzIGhhZCBhIGxvbmcgYW5kIHRvcnR1
cmVkIGhpc3Rvcnkgd2l0aA0KDQo+ID4gbXVsdGlwbGUgcmV2aWV3cywgIGFuZCB3aGF0IEknbSBz
dWdnZXN0aW5nIG5lZWRzIHRvIGhhcHBlbiBpcyBhIGxvdA0KDQo+ID4gb2Ygd29yay4gQnV0IGl0
J3MgZXNzZW50aWFsIGluIGFueSBzZWN1cml0eSBwcm90b2NvbCB0byBkbyB0aGlzDQoNCj4gPiBh
bmFseXNpcyBhbmQgYmUgY2xlYXIgYWJvdXQgd2hhdCBpcywgYW5kIHdoYXQgaXMgbm90LCBwcm90
ZWN0ZWQgYnkgdGhlIHByb3RvY29sLg0KDQo+DQoNCj4gT0F1dGggSkFSIGlzIG5vdGhpbmcgYnV0
IGp1c3QgYW5vdGhlciBiaW5kaW5nIHRvIE9BdXRoIDIuMC4gV2hlcmUNCg0KPiBSRkM2NzQ5IGJp
bmRzIGl0IHRvIGZvcm0gZW5jb2RpbmcsIGl0IHByb3ZpZGVzIHR3byBhZGRpdGlvbmFsIGJpbmRp
bmdzOg0KDQo+ICAgICAxKSBiaW5kaW5nIHRvIEpXVCwgYW5kDQoNCj4gICAgIDIpIGJpbmRpbmcg
dG8gdGhlIHB1c2hlZCBhdXRob3JpemF0aW9uIHJlcXVlc3QgdGhhdCBpcyByZWZlcmVuY2VkIGJ5
IGEgVVJJLg0KDQo+IEl0IGlzIHRoaXMgc2ltcGxlLiBBcyBzdWNoLCBpdCB3b3VsZCBhbHNvIGlu
aGVyaXQgc29tZSBvZiB0aGUNCg0KPiBzaG9ydGNvbWluZ3MgaW4gUkZDNjc0OS4gSG93ZXZlciwg
aXQgaXMgbm90IHRoaXMgZG9jdW1lbnQgdG8gYWRkcmVzcw0KDQo+IHRoZW0uIEl0IHNob3VsZCBi
ZSBkb25lIGJ5IG90aGVyIGRvY3VtZW50cyBzbyB0aGF0IHRoZSByZXN1bHQgY2FuIGJlDQoNCj4g
ZW5jb2RlZCB1c2luZyB0aGUgbWVjaGFuaXNtcyBwcm92aWRlZCBpbiB0aGlzIGRvY3VtZW50Lg0K
DQoNCg0KVGhpcyBpcyBub3QgYSBzaW1wbGUgbWF0dGVyLiBKV1QgaGFzIGEgbG9uZyBhbmQgdHdp
c3RlZCBoaXN0b3J5IHdpdGggc29tZSBwZXJ2YXNpdmUgZXJyb3JzIGluIGNvbW1vbiBsaWJyYXJp
ZXMsIGFuZCBpcyBhIGZhaXJseSBsYXJnZSBzdGFuZGFyZC4gT0F1dGggMi4wIGlzIGFsc28gbGFy
Z2UuIEVuc3VyaW5nIHRoYXQgdGhlIG1hcHBpbmcgaGFzIHRoZSByaWdodCBwcm9wZXJ0aWVzIGlz
IGdvaW5nIHRvIGJlIGEgbWVzcy4gSWYgdGhlIGVuY29kaW5nIGRvZXMgbm90IHJlc3BlY3QgdGhl
IHNlbWFudGljcyB3ZSBoYXZlIGEgc2VyaW91cyBzZWN1cml0eSBpc3N1ZS4gSWYgaW1wbGVtZW50
b3JzIGFzc3VtZSB0aGUgZW5jb2RpbmcgcHJvdmlkZXMgcHJvcGVydGllcyBpdCBkb2VzIG5vdCwg
d2UgYWdhaW4gaGF2ZSBhIHNlY3VyaXR5IGlzc3VlLg0KDQoNCg0KTWlrZT4gU2VlIG15IHByZXZp
b3VzIGNvbW1lbnRzIG9uIHBhc3QgSldUIGltcGxlbWVudGF0aW9uIGVycm9ycyBhbmQgdGhlIHdy
aXRpbmcgb2YgdGhlIEpXVCBCQ1AgW1JGQyA4NzI1XSB0byBhZGRyZXNzIHRoZXNlLg0KDQoNCg0K
PiBJdCBpcyBxdWl0ZSBzdXJwcmlzaW5nIHRoYXQgdGhpcyBmYWN0IGlzIG5vdCBnZXR0aW5nIGFw
cHJlY2lhdGVkIGFuZA0KDQo+IGlzIHRha2luZyBzdWNoIGEgbG9uZyB0aW1lIHRvIGNvbXBsZXRl
Lg0KDQo+IE1heWJlIEkgc2hvdWxkIGRlbGV0ZSBhbGwgdGhlIGV4cGxhbmF0aW9uIHRleHQgYW5k
IGxlYXZlIGl0IHdpdGgganVzdA0KDQo+IHRoZSBjb3JlIHRleHQuIEV4cGxhbmF0aW9uIGFuZCBq
dXN0aWZpY2F0aW9uIHRleHQgZm9yIGRlZmluaW5nDQoNCj4gYWRkaXRpb25hbCBiaW5kaW5ncyBw
cm9iYWJseSBhcmUganVzdCBkaXN0cmFjdGlvbnMgbm93IGFzIGl0IGlzIG5vdw0KDQo+IGFwcHJl
Y2lhdGVkIGFuZCB1c2VkIGFsbCBvdmVyIHRoZSB3b3JsZCB1bmxpa2Ugd2hlbiB0aGUgcHJvamVj
dCB3YXMNCg0KPiBzdGFydGVkLg0KDQoNCg0KTWlrZT4gSSB3b3VsZCBwcm9wb3NlIHRoYXQgd2Ug
bWFrZSBvbmx5IG5lY2Vzc2FyeSBjaGFuZ2VzIHRvIHRoZSBkcmFmdCBhdCB0aGlzIHBvaW50LiAg
TGV0J3MgZmluaXNoIHRoaXMgbG9uZy1vdmVyZHVlIHNwZWNpZmljYXRpb24hDQoNCg0KDQo+DQoN
Cj4gPg0KDQo+ID4gU2luY2VyZWx5LA0KDQo+ID4gV2F0c29uIExhZGQNCg0KPiA+DQoNCj4NCg0K
PiBUaGFua3MgYWdhaW4gZm9yIHlvdXIgZGV0YWlsZWQgY29tbWVudHMuDQoNCj4NCg0KPiBCZXN0
IHdpc2hlcywNCg0KPg0KDQo+IC0tDQoNCj4gTmF0IFNha2ltdXJhDQoNCj4gTkFULkNvbnN1bHRp
bmcgTExDDQoNCg0KDQpNaWtlPiBJIG5vdyBwbGFuIHRvIGNyZWF0ZSBlZGl0cyBpbmNvcnBvcmF0
aW5nIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9ucyBhYm92ZSBmb3IgcmV2aWV3Lg0KDQoNCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qg
d2lzaGVzLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KLS0NCg0KQXN0cmEgbW9ydGVtcXVlIHByYWVzdGFyZSBn
cmFkYXRpbQ0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp
blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJZm9udC1zaXplOjEx
LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4
dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu
MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+
PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9
ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0
PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K
PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy
IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x
Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyBhZ2FpbiBmb3IgeW91ciByZXZpZXcs
IFdhdHNvbi4mbmJzcDsgTXkgcmVwbGllcyB0byB5b3VyIGNvbW1lbnRzIGJlbG93IGFyZSBwcmVm
aXhlZCBieSAmcXVvdDs8c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDs8L3NwYW4+
JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTxicj4NCkZyb206IFdhdHNvbiBMYWRkICZsdDt3YXRzb25ibGFkZEBnbWFpbC5jb20m
Z3Q7IDxicj4NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE1LCAyMDIwIDk6MDEgUE08YnI+DQpU
bzogTmF0IFNha2ltdXJhICZsdDtuYXRAbmF0LmNvbnN1bHRpbmcmZ3Q7PGJyPg0KQ2M6IHNlY2Rp
ciAmbHQ7c2VjZGlyQGlldGYub3JnJmd0OzsgSUVURiBvYXV0aCBXRyAmbHQ7b2F1dGhAaWV0Zi5v
cmcmZ3Q7OyBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLmFsbEBp
ZXRmLm9yZzxicj4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2
aWV3IG9mIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTMwPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PbiBT
YXQsIE9jdCAzMSwgMjAyMCBhdCA2OjEzIEFNIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOm5hdEBuYXQuY29uc3VsdGluZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4
dC1kZWNvcmF0aW9uOm5vbmUiPm5hdEBuYXQuY29uc3VsdGluZzwvc3Bhbj48L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSGkgV2F0c29uLDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGFua3MgdmVyeSBtdWNoIGZvciB0
aGUgcmV2aWV3LiBJIHRob3VnaHQgSSBoYXZlIHNlbnQgbXkgcmVzcG9uc2UNCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBlYXJsaWVyLCB3aGljaCBJIGFjdHVh
bGx5IGRpZCBub3QuIEl0IHdhcyBzaXR0aW5nIGluIG15IGRyYWZ0IGJveC4gSQ0KPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFwb2xvZ2l6ZSBmb3IgaXQuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk15IGFwb2xvZ2llcyBmb3IgbWlzc2luZyBpdCBp
biBteSBpbmJveCBmb3IgYSBudW1iZXIgb2YgbW9udGhzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OyBNeSByZXNwb25zZXMgaW5saW5lOjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyBPbiBTYXQsIFNlcCAyNiwgMjAyMCBhdCA5OjQ2IEFNIFdhdHNv
biBMYWRkIHZpYSBEYXRhdHJhY2tlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyI+PHNwYW4g
c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm5vcmVwbHlAaWV0
Zi5vcmc8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgJmd0OyBSZXZpZXdlcjogV2F0c29uIExhZGQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBSZXZpZXcgcmVzdWx0OiBTZXJpb3VzIElzc3Vl
czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgSSBnZW5lcmF0ZWQg
dGhpcyByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eQ0KPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgZGlyZWN0b3Jh
dGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nDQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBwcm9jZXNz
ZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiB3aXRoIHRo
ZSBpbnRlbnQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm
Z3Q7IG9mIGltcHJvdmluZyBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIGNvbnNpZGVyYXRpb25z
IGluIElFVEYNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm
Z3Q7IGRyYWZ0cy4mbmJzcDsgQ29tbWVudHMgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5
IGJlIGluY2x1ZGVkIGluIEFEDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgJmd0OyByZXZpZXdzIGR1cmluZyB0aGUgSUVTRyByZXZpZXcuJm5ic3A7IERvY3Vt
ZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVz
dCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgJmd0OyBUd28gbWlub3IgaXNzdWVzOiBPbiBwYWdlIDQsICZxdW90
O1RoaXMgb2ZmZXJzIGFuIGFkZGl0aW9uYWwgZGVncmVlIG9mDQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBwcml2YWN5IHByb3RlY3Rpb24uJnF1b3Q7
IHNob3VsZCBiZSByZXdvcmRlZC4gSSBkb24ndCB0aGluayBpdCBtYWtlcw0KPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgc2Vuc2UgaW4gY29udGV4dCwg
d2hlcmUgYXV0aGVudGljaXR5IHdhcyBkaXNjdXNzZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij4mZ3Q7IEluIHRoZSBjb3Vyc2Ugb2YgdGhlIGVkaXQsIGV4cGxhbmF0aW9uIGFib3V0IHR3
byBkaXN0aW5jdCBwcml2YWN5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgYmVuZWZpdHMgd2FzIGNvbGxhdGVkIGluIG9uZSBzZW50ZW5jZSBhbmQgaGFzIGJl
Y29tZSB2ZXJ5IGRpZmZpY3VsdCB0bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IHBhcnNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0
OyBXaGF0IGl0IGlzIHRyeWluZyB0byBleHByZXNzIGFzIHByaXZhY3kgYmVuZWZpdHMgYXJlIHRo
ZSBmb2xsb3dpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDEpIFRo
ZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgY29udGVudCBpcyBzZW50IHRvIHRoZSBBUyBpbiB0aGUN
CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBiYWNrY2hhbm5l
bCBzbyBpdCB3aWxsIG5vdCBiZSBleHBvc2VkIHRocm91Z2ggdGhlIGJyb3dzZXIgdG8gdGhlIGV5
ZXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBvZiBhbiBh
Y3RpdmUgb3IgcGFzc2l2ZSBvdXRzaWRlciBvYnNlcnZpbmcgd2hhdCBpcyBnb2luZyBvbiBpbiB0
aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBicm93c2Vy
LiZuYnNwOyBJbiB0aGUgUkZDNjc0OSBmcmFtZXdvcmsgY2FzZSwgdGhlIGF1dGhvcml6YXRpb24g
cmVxdWVzdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGdv
ZXMgdGhyb3VnaCB0aGUgYnJvd3NlciByZWRpcmVjdCBhbmQgaXQgY291bGQgbGVhayB0byB0aGUg
YWR2ZXJzYXJ5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
dmlhIFdQQUQvUEFDIEF0dGFjaywgcmVmZXJyZXIsIGJyb3dzZXIgaGlzdG9yeSwgZXRjLiBBbHNv
LCBpZiB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBi
cm93c2VyIHdhcyBpbmZlY3RlZCBieSBhbiBhZHZlcnNhcnkgY29udHJvbGxlZCBtYWx3YXJlLCB0
aGUgY29udGVudA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
IGNhbiBiZSBzbmlmZmVkIGJ5IHRoZSBhZHZlcnNhcnkuIEluIHRoZSBjYXNlIG9mIEpBUiwgaXQg
ZG9lcyBub3QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBo
YXBwZW4uIFRoaXMgaXMgb25lIHByaXZhY3kgYmVuZWZpdCBpdCBpcyB0cnlpbmcgdG8gZXhwbGFp
bi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMikgVGhlIGxvY2F0aW9u
IHRoYXQgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBnZXR0aW5nIHB1c2hlZCB0bw0KPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRvZXMgbm90IGhhdmUg
dG8gYmUgdGhlIEFTLiBBIHRydXN0ZWQgdGhpcmQgcGFydHkgdGhhdCBleGFtaW5lcyB0aGUNCjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBjb250ZW50IGZvciB0
aGUgY29uZm9ybWFuY2UgdG8gdGhlIGNvbGxlY3Rpb24gbWluaW1pemF0aW9uIHByaW5jaXBsZQ0K
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1heSBhY3QgYXMg
dGhlIHBhcnR5IHRoYXQgYWNjZXB0cyB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGFuZCBpc3N1
ZXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgcmVx
dWVzdF91cmkuIEFTIGNhbiB0aGVuIGp1c3QgZXZhbHVhdGUgdGhlIGRvbWFpbiBwYXJ0IG9mDQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVxdWVzdF91cmkg
dG8gZXZhbHVhdGUgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIGNvbmZvcm1hbnQN
CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0byB0aGlzIHBy
aW5jaXBsZS4gVGhpcyBpcyBhbm90aGVyIHByaXZhY3kgYmVuZWZpdCBmcm9tIHRoZSBwb2ludCBv
Zg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHZpZXcgb2Yg
dGhlIGluZGl2aWR1YWwgdXNlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSdtIGZp
bmUgd2l0aCBhbnkgZml4IHRvIHRoZSBzZW50ZW5jZSB0aGF0IG1ha2VzIHNlbnNlLiBEb24ndCB0
aGluayB3ZSBuZWVkIHRvIGluc2VydCB0aGUgYWJvdmUgYnV0IEkgdmVyeSBtdWNoIGFwcHJlY2lh
dGUgdGhlIGV4cGxhbmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz
dHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgR2l2ZW4gdGhhdCBpdHMgbWVhbmluZyBpcyBm
YWlybHkgaW5zY3J1dGFibGUsIGFuZCB0aGF0IHRoZSB0d28gYmVuZWZpdHMgZGVzY3JpYmVkIGJ5
IE5hdCBhYm92ZSBhcmUgcGFydGlhbGx5IHJlbGF0ZWQgdG8gcGFyYWdyYXBocyBvdGhlciB0aGFu
IHRoZSBvbmUgd2l0aCB0aGUgcHJpdmFjeSBzdGF0ZW1lbnQsIEkgcHJvcG9zZSB0aGF0IHdlIHNp
bXBseQ0KIGRlbGV0ZSB0aGUgc2VudGVuY2UgJnF1b3Q7VGhpcyBvZmZlcnMgYW4gYWRkaXRpb25h
bCBkZWdyZWUgb2YgcHJpdmFjeSBwcm90ZWN0aW9uLiZxdW90OyBmcm9tIHRoaXMgcGFyYWdyYXBo
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEl0IHRvb2sg
bWUgYSB3aGlsZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhlIGJ5IHJlZmVyZW5jZSBtZXRob2QgaXM6
DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBtYXli
ZSB0aGUgaW50cm8gc2hvdWxkIHNheSB2aWEgVVJMIGluc3RlYWQgb2YgYnkgcmVmZXJlbmNlLjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZXF1ZXN0X3VyaSBjYW4gYmUgVVJMIG9y
IGEgaGFuZGxlIHN1Y2ggYXMgVVJOLiBUaGF0IGlzIHdoeSB0aGUgJnF1b3Q7YnkNCjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZWZlcmVuY2UmcXVvdDsgd29y
ZCBpcyBiZWluZyB1c2VkLCBwZXIgdGhlIHN1Z2dlc3Rpb24gb2YgdGhlIFdHLjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij5JJ20gZmluZSB3aXRoIHRoYXQsIGp1c3Qgbm90aW5nIG15IGNv
bmZ1c2lvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMEIwNTAiPk1pa2UmZ3Q7IFVuZGVyc3Rvb2QuJm5ic3A7IEkgbG9va2VkIGF0IHdheXMgdG8g
cG9zc2libHkgbW92ZSB0aGUgJnF1b3Q7YnkgcmVmZXJlbmNlJnF1b3Q7IHRleHQgdGhhdCBmb2xs
b3dzIGluIGEgZmV3IHBhcmFncmFwaHMgZWFybGllciB0byBwb3NzaWJseSBtYWtlIHRoaXMgY2xl
YXJlciwgYnV0IGl0IHdvdWxkIG1lc3MgdXAgdGhlIGxvZ2ljYWwgZmxvdyBvZiB0aGUgSW50cm9k
dWN0aW9uLiZuYnNwOw0KIFVubGVzcyB5b3UgaGF2ZSBhIGJldHRlciBzdWdnZXN0aW9uLCBJIHBy
b3Bvc2UgdGhhdCB3ZSBsZWF2ZSB0aGlzIGFzLWlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IEFuZCBub3cgZm9yIHRoZSB0aG9ybnkgaXNzdWVzIHdpdGgg
dGhpcyBkcmFmdC4gU2lnbmF0dXJlcyBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGVuY3J5cHRpb24gYXJlIGRpZmZlcmVudC4gQW5kIGVuY3J5
cHRpbmcgYSBzaWduZWQgYmxvYiBkb2Vzbid0IG1lYW4gdGhlIHNpZ25lciBlbmNyeXB0ZWQgaXQu
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgVGhlbiB0
aGVyZSBhcmUgYSBwbGV0aG9yYSBvZiBtZXRob2RzIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQmbmJz
cDsgdG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7
IGF1dGhlbnRpY2F0ZSB0aGUgYmxvYiwgd2hpY2ggd2lsbCBnaXZlIGRpZmZlcmVudCByZXN1bHRz
IGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBt
YWxpY2lvdXNseSBjb25zdHJ1Y3RlZCBleGFtcGxlcy4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp
b25zDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBz
ZWN0aW9uIHNob3VsZCBkaXNjdXNzIHdoYXQgdGhlIGVuY3J5cHRlZCB2cyBzaWduZWQgY2hvaWNl
cyBnaXZlIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
Jmd0OyB0aGUgd2F5IG9mIHNlY3VyaXR5LCBhbmQgaXQgZG9lc24ndC4gVGhpcyBtYWtlcyBtZSB3
b3JyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgV2UgZG9u4oCZdCBl
eHBlY3QgdGhlIGVuY3J5cHRpb24gdG8gZW5zdXJlIGF1dGhlbnRpY2l0eSwgdGhhdOKAmXMgd2hh
dCB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzaWdu
YXR1cmVzIGFyZSB1c2VkIGZvci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBu
ZWVkcyB0byBiZSB2ZXJ5IGNsZWFybHkgc3BlbGxlZCBvdXQgaW4gdGhlIHRleHQuIExvdHMgb2Yg
cGVvcGxlIHdpbGwgbm90IHVuZGVyc3RhbmQgdGhpcy4gVGhlIHdvcmRpbmcgb2Ygc2VjdGlvbiAx
MC4yIGlzIGF0IGJlc3QgYW1iaXZhbGVudCwgd2l0aCBtdWx0aXBsZSBhbHRlcm5hdGl2ZXMgcHJl
c2VudGVkIGFzIGFjY2VwdGFibGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBBZnRlciB0aGUgc2VudGVuY2UgYXQgMTAu
MiAoYikgYWJvdXQgc3ltbWV0cmljIGVuY3J5cHRpb24sIEkgcHJvcG9zZSB0aGF0IHdlIGFkZCB0
aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIGVtcGhhc2l6ZSB0aGUgcG9pbnQgeW91J3JlIHJhaXNp
bmc6ICZuYnNwOyZxdW90O05vdGUgaG93ZXZlciwgdGhhdCBpZiBwdWJsaWMga2V5IGVuY3J5cHRp
b24gaXMgdXNlZCwgbm8NCiBzb3VyY2UgYXV0aGVudGljYXRpb24gaXMgZW5hYmxlZCBieSB0aGUg
ZW5jcnlwdGlvbiwgYXMgYW55IHBhcnR5IGNhbiBlbmNyeXB0IGNvbnRlbnQgdG8gdGhlIHB1Ymxp
YyBrZXkuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7Y2hvcCZndDs8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgSSBkaWRuJ3QgcXVpdGUgZ2V0IHdoYXQgaXMgbWVhbnQgYnkg
JnF1b3Q7cGxldGhvcmEgb2YgbWV0aG9kcyBzcGVjaWZpZWQgaW4NCjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgZHJhZnQgdG8gYXV0aGVudGljYXRlIHRo
ZSBibG9iIC4uLiAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDsgVGhlcmUgaXMgYSBiaXQgb2YgdGV4dCBhYm91dCBhdXRoZW50aWNhdGluZyB0aGUgc291
cmNlICg9Y2xpZW50KSBidXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyBub3QgbXVjaCBvbiB0aGUgYmxvYiBpdHNlbGYuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZSBkaXNjdXNzaW9uIGFyb3VuZCB0aGUgc2lnbmF0
dXJlIGFuZC9vciBlbmNyeXB0aW9uIGlzIGNvdmVyZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZndDsgUkZDNzUxOSAoSldUKSwgdGhlIGZvcm1hdCB0aGF0IHRo
ZSByZXF1ZXN0IG9iamVjdCBhc3N1bWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jmd0OyBUaGlzIGlzIHJlcXVpcmVkIHJlYWRpbmcgd2hlbiBpbXBsZW1lbnRpbmcg
dGhpcyBzcGVjLCBzbyBXRyB0aG91Z2h0IGl0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgaXMgbm90IHdvcnRoIHJlcGVhdGluZyBoZXJlLjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBdHRhY2tzIGV0Yy4gb24gdGhlIHNp
Z25hdHVyZSBhbmQgZW5jcnlwdGlvbiBhcmUgY292ZXJlZCBpbiBSRkM3NTE1DQo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYW5kIFJGQzc1MTYgcmVzcGVjdGl2
ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZWxsLCB0aGUgZHJhZnQgaGFwcGVu
cyB0byBpbmNsdWRlIHRoZSBmb2xsb3dpbmcgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgQXV0aG9yaXphdGlvbiBTZXJ2
ZXIgTVVTVCB2YWxpZGF0ZSB0aGUgc2lnbmF0dXJlIG9mIHRoZSBKU09OIFdlYjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFNpZ25hdHVyZSBbUkZD
NzUxNV0gc2lnbmVkIFJlcXVlc3QgT2JqZWN0LiZuYnNwOyBUaGUgc2lnbmF0dXJlIE1VU1QgYmU8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB2YWxp
ZGF0ZWQgdXNpbmcgdGhlIGtleSBmb3IgdGhhdCAmcXVvdDtjbGllbnRfaWQmcXVvdDsgYW5kIHRo
ZSBhbGdvcml0aG08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw
OyZuYnNwOyBzcGVjaWZpZWQgaW4gdGhlICZxdW90O2FsZyZxdW90OyBIZWFkZXIgUGFyYW1ldGVy
LiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TaG91bGRuJ3QgdGhlIGtleSBi
ZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgYWxnb3JpdGhtPyBIb3cgZG8gd2UgZW5zdXJlIHRo
YXQgdGhlIGNvbW1vbiBhdHRhY2sgb2YgdGVsbGluZyB0aGUgc2VydmVyIHRvIHVzZSBobWFjIHRv
IHZlcmlmeSB0aGUgc2lnbmF0dXJlIGRvZXNuJ3Qgd29yayBoZXJlPzxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgR29vZCBw
b2ludC4mbmJzcDsgVGhpcyBhdHRhY2sgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xIG9mIFJG
QyA4NzI1IGFuZCBtaXRpZ2F0ZWQgYnkgdGhlIHByYWN0aWNlcyBpbiBTZWN0aW9ucyAzLjEgYW5k
IDMuMiBvZiB0aGUgc2FtZS4mbmJzcDsgSSBwcm9wb3NlIHRoYXQgd2UgcmVwbGFjZSB0aGUgc2Vu
dGVuY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgc2ln
bmF0dXJlIE1VU1QgYmUgdmFsaWRhdGVkIHVzaW5nIHRoZSBrZXkgZm9yIHRoYXQgJnF1b3Q7Y2xp
ZW50X2lkJnF1b3Q7IGFuZCB0aGUgYWxnb3JpdGhtIHNwZWNpZmllZCBpbiB0aGUgJnF1b3Q7YWxn
JnF1b3Q7IEhlYWRlciBQYXJhbWV0ZXIuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPndpdGg6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgc2lnbmF0dXJlIE1V
U1QgYmUgdmFsaWRhdGVkIHVzaW5nIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50IGFu
ZCB0aGUgYWxnb3JpdGhtIHNwZWNpZmllZCBpbiB0aGUgJnF1b3Q7YWxnJnF1b3Q7IEhlYWRlciBQ
YXJhbWV0ZXIuJm5ic3A7IElmIGEgJnF1b3Q7a2lkJnF1b3Q7IEhlYWRlciBQYXJhbWV0ZXIgaXMg
cHJlc2VudCwgdGhlIGtleSBpZGVudGlmaWVkIE1VU1QgYmUgdGhlDQoga2V5IHVzZWQsIGFuZCBN
VVNUIGJlIGEga2V5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50LiZuYnNwOyBBbGdvcml0aG0g
dmVyaWZpY2F0aW9uIE1VU1QgYmUgcGVyZm9ybWVkLCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbnMg
My4xIGFuZCAzLjIgb2YgUkZDIDg3MjUuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7ICZndDsgTG9va2luZyBhdCB0aGUgY2l0ZWQgcmVmZXJlbmNlIGZvciBh
dHRhY2tzLCBJIHNlZSB0aGUgZml4IGlzIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgJmd0OyBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0IHdoaWNoIElQ
RCB3YXMgdXNlZCBieSB0aGUgUlAuIEJ1dCB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGRyYWZ0IGJlZm9yZSB1cyBkb2Vzbid0IG1hbmRhdGUg
dGhhdC4gSXQncyBub3QgY2xlYXIgdGhhbiBob3cgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBjaXRlZCBhdHRhY2sgaXMgcHJldmVudGVkIGJ5
IHRoZSBkcmFmdC4gU2F5aW5nIHRoYXQgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgJmd0OyBjb21tdW5pY2F0aW9uIHRocm91Z2ggdGhlIHVzZXItYWdl
bnQgaXMgc3ViamVjdCB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBU
aGUgbWVudGlvbiBvZiBtaXgtdXAgYXR0YWNrIHdhcyBpbnRyb2R1Y2VkIGFmdGVyIHRoZSBMYXN0
IGNhbGwgYnkgb25lDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgb2YgdGhlIGNvbW1lbnQuIEl0IGp1c3QgYWRkZWQgaXQgaW4gdGhlIHNlbnRlbmNlIHdpdGgg
YSByZWZlcmVuY2UuIEkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OyBhbSBvayB0byByZW1vdmUgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo
YXQgd29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgSSB3aWxsIHJlbW92ZSB0aGUgbWl4LXVwIGF0dGFj
ayByZWZlcmVuY2UgaW4gdGhlIG5leHQgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7IEhhdmluZyBzYWlkIHRoYXQsIHRoZSBoZWFydCBvZiBtaXgtdXAgYXR0
YWNrIGlzIHRoYXQgdGhlIGNvbWJpbmF0aW9uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgb2YgdGhlIGNsaWVudCBiZWxpZXZlcyB0aGF0IGl0IGlzIGNvbW11
bmljYXRpbmcgd2l0aCB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyBhdHRhY2tlci1jb250cm9sbGVkIEFTIChBQVMpIHdoaWxlIGl0IGluLWZhY3QgaXMg
dGFsa2luZyB0byBIb25lc3QgQVMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jmd0OyAoSEFTKSwgQU5EIEhBUyB1bmFibGUgdG8gZmluZCBvdXQgdGhhdCB0aGUgY2xp
ZW50IGlzIHRoaW5raW5nIHRoYXQgaXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jmd0OyBpcyB0YWxraW5nIHRvIEFBUyBub3QgaGltLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPQXV0aCBKQVIgc2VlbXMgdG8gbWl0aWdhdGUgaXQgaW4g
dHdvIHdheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGEpIFVzZSBy
ZXF1ZXN0X3VyaSB3aGljaCBpcyBob3N0ZWQgYnkgdGhlIEFTLiBUaGVuLCBpZiB0aGUgY2xpZW50
IGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhpbmtp
bmcgdGhhdCBpdCBpcyB0YWxraW5nIHRvIHRoZSBBQVMsIHRoZW4gaXQgd2lsbCBwdXNoIGl0IHRv
IEFBUw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFuZCB3
aGVuIHRoZSB1c2VyIGlzIHJlZGlyZWN0ZWQgdG8gSEFTLCBIQVMgd2lsbCBmaW5kIG91dCB0aGF0
IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHJlcXVl
c3RfdXJpIGlzIG5vdCBjcmVhdGVkIGJ5IGhlcnNlbGYgYW5kIHJldHVybiBhbiBlcnJvciwgbWFr
aW5nIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1p
eC11cCBhdHRhY2sgZmFpbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
YikgSW5jbHVkZSBgYXVkYCBpbiB0aGUgcmVxdWVzdC4gVGhlbiwgd2hlbiB0aGUgSEFTIHdpbGwg
ZmluZCB0aGF0IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
Z3Q7IHJlcXVlc3Qgd2FzIG1pbnRlZCB0byBBQVMgYW5kIG5vdCBoZXIuIFNvLCBpdCB3aWxsIHJl
c3VsdCBpbiBhbiBlcnJvciwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyBtYWtpbmcgdGhlIG1peC11cCBhdHRhY2sgZmFpbC48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+SWYgdGhlIGRyYWZ0IG1hbmRhdGVzIGRvaW5nIHRoaXMgaXQgYWRkcmVzc2Vz
IHRoZSBhdHRhY2sgYW5kIHRoZSBzZW50ZW5jZSBjYW4gc3RheS48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IFRoZSBkcmFm
dCBtYW5kYXRlcyB1c2Ugb2YgJnF1b3Q7YXVkJnF1b3Q7IGJ1dCBpdCBkb2VzIG5vdCBtYW5kYXRl
IHRoYXQgdGhlIHJlcXVlc3RfdXJpIGJlIGhvc3RlZCBieSB0aGUgQVMuJm5ic3A7IFRoZXJlZm9y
ZSwgSSB0aGluayB3ZSBzaG91bGQgcmVtb3ZlIHRoZSBtaXgtdXAgYXR0YWNrIHJlZmVyZW5jZS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgU28sIEkgYWRkZWQgbWl4
LXVwIGF0dGFjayB0byB0aGUgc2VudGVuY2UgdGhpbmtpbmcgdGhlIGNvbW1lbnRlcidzDQo8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVxdWVzdCB0byBhZGQg
aXQgaXMgZmluZSwgYnV0IEkgYW0gZmluZSB3aXRoIHJlbW92aW5nIGl0LjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IG1hbmlwdWxhdGlvbiwgYW5kIHRoaXMgcHJl
dmVudHMgaXQsIGlnbm9yZXMgdGhhdCB0aGUgYXR0YWNrZXIgaW4NCjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHRoYXQgcG9zaXRpb24gc2VlcyBhIGxv
dCBtb3JlLiBUaGUgdXNlci1hZ2VudCBhcyByZXNvdXJjZSBvd25lcg0KPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgbW9kaWZ5aW5nIHRoZSByZXF1ZXN0
ZWQgcmVzb3VyY2VzIGlzIGEgdmVyeSBmdW5ueSBzb3J0IG9mIGF0dGFjazoNCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGNhbid0IHRoZXkgZG8gd2hh
dCB0aGV5IHdhbnQgd2l0aCB0aGUgcmVzb3VyY2VzIHNpbmNlIHRoZXkgY29udHJvbCB0aGUgYWNj
ZXNzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJZiB0aGUgY2xpZW50
IGlzIGluIHRoZSBicm93c2VyLCB5ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IEJ1dCBpbiB0aGUgbWFpbnN0cmVhbSBjYXNlLCB0aGUgY2xpZW50IGlzIG5v
dCBpbiB0aGUgYnJvd3NlciBidXQgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsgd2ViLXNlcnZlciB0aGF0IHRoZSBicm93c2VyIGlzIGNvbW11bmljYXRp
bmcgd2l0aCBhbmQgdGhlIHJlc291cmNlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsgYWNjZXNzIGhhcHBlbnMgd2l0aG91dCBiZWluZyBtZWRpYXRlZCBieSB0
aGUgYnJvd3Nlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TXkgY29uY2VybiBvbiB0
aGlzIHBvaW50IGlzIHJlc29sdmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsgVGhhbmtzPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
ICZndDsgS2V5IG1hbmFnZW1lbnQgaXMgaWdub3JlZC4gVGhpcyBpcyBhIHZlcnkgaW1wb3J0YW50
IGlzc3VlLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZn
dDsgZXNwZWNpYWxseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0
OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBBIGxv
dCBvZiBncm91bmQgaXMgY292ZXJlZCBieSBSRkMgNzUxNSwgNzUxNiwgNzUxNywgNzUxOCwgNzUx
OSwgNzU5MSwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBh
bmQgODQxNCBzbyB0aGlzIGRvY3VtZW50IGlzIG5vdCBzcGVjaWZpY2FsbHkgcmVzdGF0aW5nIHRo
ZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBjb25zaWRlcmluZyB0aGUg
cG90ZW50aWFsIHByb2JsZW1zIHdpdGggdGhlIHJldXNlIG9mIEpXVC4gSSdkIGxpa2UNCjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHRvIHNlZSBhPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEFyZSB5b3UgdGFsa2luZyBhYm91
dCB0aGUgcmV1c2Ugb2YgdGhlIHJlcXVlc3Qgb2JqZWN0IGJ5IGFuIGFkdmVyc2FyeQ0KPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRyeWluZyB0byBhY3QgYXMg
YW4gaG9uZXN0IGNsaWVudD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDsgRXZlbiBpZiBpdCBoYXBwZW5zLCB0aGUgbWFsaWNpb3VzIGNsaWVudCBkb2VzIG5vdCBo
YXZlIHRoZSBwcm9wZXINCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OyBjbGllbnQgY3JlZGVudGlhbCBzbyBpdCBjYW5ub3QgcmVkZWVtIHRoZSBjb2RlIGl0IG9i
dGFpbmVkIHdpdGggdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDsgdG9rZW4uIEl0IGlzIG5vIGRpZmZlcmVudCB0aGFuIFJGQzY3NDkgY29kZSBncmFudC4g
UHJvdG9jb2xzIHRoYXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
Jmd0OyBleHRlbmQgaXQsIHN1Y2ggYXMgT3BlbklEIENvbm5lY3QsIGhhdmUgaW50cm9kdWNlZCBu
b25jZSB0byBwcmV2ZW50DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PiZndDsgdGhlIHJldXNlIGFuZCB1c2VkIEpBUiAoaXQgaXMgY2FsbGVkIHJlcXVlc3Qgb2JqZWN0
IHRoZXJlKSB0byBmdXJ0aGVyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgcHJvdGVjdCB0YW1wZXJpbmcgYW5kIGFjaGlldmUgY2xpZW50IGF1dGhlbnRpY2F0
aW9uIGV2ZW4gaW4gdGhlIGZyb250DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDsgY2hhbm5lbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgJmd0OyByZWNvbW1lbmRhdGlvbiB0aGF0IGtleXMgYmUgc2VwYXJhdGVkIGJ5IGludGVuZGVk
IHVzZXMsIHJhdGhlciB0aGFuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgJmd0OyBsaW1pdGluZyBwYXJ0aWN1bGFyIGZpZWxkcyBpbiBhbiBhZC1ob2MgbWFu
bmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBDb3VsZCB5b3Uga2lu
ZGx5IGVsYWJvcmF0ZSBvbiB0aGUgJnF1b3Q7YWQtaG9jIG1hbm5lciZxdW90OyBwYXJ0IHNvIHRo
YXQgSSBjYW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB1
bmRlcnN0YW5kIGl0IG1vcmUgZnVsbHk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjEw
LjgsIENyb3NzLUpXVCBDb25mdXNpb24gZGlzY3Vzc2VzIGF2b2lkaW5nIHNpZ25pbmcgY2VydGFp
biBmaWVsZHMsIHJhdGhlciB0aGFuIHN1Z2dlc3RpbmcgZ29vZCBrZXkgdXNhZ2UgYXMgYSBzb2x1
dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MEIwNTAiPk1pa2UmZ3Q7IEkgcHJvcG9zZSB0byBhZGQgdGhpcyBuZXcgcGFyYWdyYXBoIGF0IHRo
ZSBlbmQgb2YgU2VjdGlvbiAxMC44IHRvIGltcGxlbWVudCB5b3VyIHN1Z2dlc3Rpb246PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMEIwNTAiPiZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtGaW5hbGx5LCBhbm90aGVyIHdh
eSB0byBwcmV2ZW50IGNyb3NzLUpXVCBjb25mdXNpb24gaXMgdG8gdXNlIGEga2V5IG1hbmFnZW1l
bnQgcmVnaW1lIGluIHdoaWNoIGtleXMgdXNlZCB0byBzaWduIFJlcXVlc3QgT2JqZWN0cyBhcmUg
aWRlbnRpZmlhYmx5IGRpc3RpbmN0IGZyb20gdGhvc2UgdXNlZCBmb3Igb3RoZXIgcHVycG9zZXMu
Jm5ic3A7IFRoZW4sIGlmDQogYW4gYWR2ZXJzYXJ5IGF0dGVtcHRzIHRvIHJlcHVycG9zZSB0aGUg
UmVxdWVzdCBPYmplY3QgaW4gYW5vdGhlciBjb250ZXh0LCBhIGtleSBtaXNtYXRjaCB3aWxsIG9j
Y3VyLCB0aHdhcnRpbmcgdGhlIGF0dGFjay4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgJmd0OyBUaGVuIHdlIGhhdmUgc2VjdGlvbiAxMS4gV2hhdCBzZWN0
aW9uIDExIGludHJvZHVjZXMgaXMgYW4gZW50aXJlIG5ldw0KPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgZHJhbWF0aXMgcGVyc29uYWUsIHRoZSBUcnVz
dCBGcmFtZXdvcmsgUHJvdmlkZXIsIHdpdGggbm8gcHJpb3INCjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGRpc2N1c3Npb24gb2Ygd2hhdCBpdCBpcyBv
ciBhIHJlZmVyZW5jZSB0byB3aGVyZSBpdCBpcyBkZWZpbmVkIGFuZCBhDQo8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBnb29kIG51bWJlciBvZiBzdGF0
ZW1lbnRzIGFib3V0IGhvdyBpdCB3b3JrcyB0aGF0IGFyZW4ndCByZWFsbHkmbmJzcDsgY2xlYXIg
d2hhdCB0aGV5IG1lYW4gZnJvbSB0aGUgZG9jdW1lbnQgdG8gbWUuPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRydXN0IEZyYW1ld29yayBQcm92aWRlciBmaXJzdCBhcHBl
YXJzIGluIDUuMi4xLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0
OyBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoZSByZWxhdGVkIHRleHQsIGl0IHdhcyBhIHByZXR0
eSB3ZWxsLWtub3duDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgY29uY2VwdC4gSW4gdGhlIFVuaXRlZCBTdGF0ZSwgaXQgd2FzIHBhcnQgb2YgaXRzIE5hdGlv
bmFsIFN0cmF0ZWd5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
IChOU1RJQykgYW5kIGludGVybmF0aW9uYWxseSwgaXQgd2FzIGV2ZW4gdGFrZW4gdXAgYXQgV0VG
IERhdm9zDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgbWVl
dGluZy4gSXQgaXMgcXVpdGUgc3VycHJpc2luZyB0aGF0IHN1Y2ggYSBtYWluc3RyZWFtIGNvbmNl
cHQgZmFkZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBp
bnRvIG9ic2N1cml0eSBzbyBxdWlja2x5LiBUaGUgcmVhc29uIGZvciBpbnRyb2R1Y2luZyBpdCB3
YXMgdG8gYSkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBq
dXN0aWZ5IHJlcXVlc3RfdXJpIGFzIHNvbWUgV0cgbWVtYmVycyB3YW50ZWQgaXQgdG8gYmUgcmVt
b3ZlZCwgYikNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBq
dXN0aWZ5IHRoYXQgcmVxdXN0X3VyaSB0byBiZSBzZXJ2ZWQgZnJvbSBhIGRpZmZlcmVudCBkb21h
aW4uIE5vdyB0aGF0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgcGVvcGxlIGFwcHJlY2lhdGUgaXQsIGUuZy4sIGl0IGNhbiBiZSBzZWVuIGZyb20gUEFSLCB0
aGUganVzdGlmaWNhdGlvbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7IGZvciBhKSBwcm9iYWJseSBpcyBubyBsb25nZXIgcmVxdWlyZWQuIEEgZnVsbCBleHBs
YW5hdGlvbiBmb3IgYikgd291bGQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jmd0OyBwcm9iYWJseSBiZSBhIG11Y2ggbG9uZ2VyIHRleHQgYnV0IEkgZG91YnQgaWYg
aXQgYmVsb25ncyB0byB0aGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgZG9jdW1lbnQuIEkgYW0gZmluZSB3aXRoIHJlbW92aW5nIHRoZSByZWZlcmVuY2Ug
dG8gVHJ1c3QgZnJhbWV3b3JrDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgZXRjLiBhcyBsb25nIGFzIHRoZSBjYXBhYmlsaXR5IHRvIHB1c2ggdGhlIGF1dGhv
cml6YXRpb24gcmVxdWVzdCB0byBhDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDsgcGxhY2Ugb3RoZXIgdGhhbiB0aGUgY2xpZW50IG9yIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlciBpcyBub3QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+Jmd0OyByZW1vdmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5MZXQncyByZW1v
dmUgdGhlIHRleHQgdGhlbiwgYnV0IGtlZXAgdGhlIGNhcGFiaWxpdHkuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWlrZSZndDsgSSBwcm9w
b3NlIHRvIHJlbW92ZSB1c2VzIG9mIHRoZSB0ZXJtICZxdW90O1RydXN0IEZyYW1ld29yayBQcm92
aWRlciZxdW90OyBhbmQgaW5zdGVhZCByZXBsYWNlIHRoZW0gYnkgdGhlIG1vcmUgZ2VuZXJpYyB0
ZXJtICZxdW90O3RydXN0ZWQgdGhpcmQtcGFydHkgc2VydmljZSZxdW90Oy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBNeSBiaWdnZXN0IGNvbmNlcm4gaXMg
dGhhdCB0aGVzZSBpc3N1ZXMgYXJlIHNpZ25zIHRoYXQgdGhlIHByb2JsZW0NCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHRoaXMgZHJhZnQgaXMgdHJ5
aW5nIHRvIHNvbHZlIGFuZCB0aGUgbWVjaGFuaXNtcyB0byBzb2x2ZSBpdCBoYXZlbid0DQo8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBiZWVuIGFuYWx5
emVkIGFzIHRob3JvdWdobHkgYXMgdGhleSBzaG91bGQgaGF2ZSBiZWVuLiBXaXRob3V0IHRoYXQN
CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHNvcnQg
b2YgdGhvcm91Z2ggYW5hbHlzaXMgaXQncyBub3QgY2VydGFpbiB0aGF0IHRoZSBtZWNoYW5pc21z
DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBhY3R1
YWxseSBzb2x2ZSB0aGUgcHJvYmxlbSBhbmQgaXQncyBub3QgY2xlYXIgd2hhdCB0aGUNCjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IHJlY29tbWVuZGF0
aW9ucyB0byBpbXBsZW1lbnRlcnMgaGF2ZSB0byBiZSB0byBwcmVzZXJ2ZSB0aG9zZSBwcm9wZXJ0
aWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPQXV0aCBKQVIsIGFz
IHRoZSBuYW1lICZxdW90O1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcms6IEpX
VA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFNlY3VyZWQg
QXV0aG9yaXphdGlvbiBSZXF1ZXN0IChKQVIpJnF1b3Q7IHN1Z2dlc3RzLCBpcyBhIGZyYW1ld29y
ayBhbmQgbm90DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
YSBob3VzZSBpdHNlbGYuIE9uZSBzdWNoIGV4YW1wbGUgaXMgRkFQSSBbMV0gd2hpY2ggd2FzIGZv
cm1hbGx5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdmVy
aWZpZWQgWzJdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mcXVvdDtJdCdzIHBvc3Np
YmxlIHRvIHVzZSB0aGlzIGRyYWZ0IHNlY3VyaXR5JnF1b3Q7IEkgZG9uJ3QgdGhpbmsgc2hvdWxk
IGJlIGVub3VnaCBhbnltb3JlLiBSYXRoZXIgaXQgc2hvdWxkIGJlIGltcG9zc2libGUgdG8gdXNl
IGluc2VjdXJlbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMDBCMDUwIj5NaWtlJmd0OyBUaGUgZHJhZnQgZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhl
IG1lY2hhbmlzbSBzZWN1cmVseS4mbmJzcDsgWWVzLCBpZiBwb3J0aW9ucyBvZiB0aGUgZHJhZnQg
KGFuZCB0aG9zZSBpdCBkZXBlbmRzIHVwb24pIGFyZSBub3QgZm9sbG93ZWQsIGluc2VjdXJlIHVz
YWdlIGNhbiByZXN1bHQuJm5ic3A7IFRoYXQncyB0cnVlIG9mIGFueSBzZWN1cml0eSBkcmFmdC4m
bmJzcDsgSWYNCiB0aGVyZSBhcmUgYWRkaXRpb25hbCBzcGVjaWZpYyByZXF1aXJlbWVudHMgYW5k
L29yIHJlY29tbWVuZGF0aW9ucyBuZWVkZWQsIHdlJ2QgYmUgZ2xhZCB0byBhZGQgdGhlbS4mbmJz
cDsgSWYgc28sIHBsZWFzZSBpZGVudGlmeSB0aGVtLiZuYnNwOyAoSW5kZWVkLCB3ZSdyZSBhbHJl
YWR5IGRvaW5nIHNvIGluIHJlc3BvbnNlIHRvIHlvdXIgZXhpc3Rpbmcgc3BlY2lmaWMgZmVlZGJh
Y2suKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+TWlrZSZndDsg
QXMgZm9yIHBhc3QgSldUIHByb2JsZW1zLCB0aGUgSldUIEJDUCBbUkZDIDg3MjVdIHdhcyB3cml0
dGVuIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBJRVNHIHRvIGlkZW50aWZ5IGFuZCBtaXRpZ2F0ZSB0
aGVtIC0gZXNwZWNpYWxseSBpbiBsaWdodCBvZiBKV1RzIGJlaW5nIHVzZWQgZm9yIGFkZGl0aW9u
YWwgdXNlIGNhc2VzLCBzdWNoIGFzIFNUSVIgc2VjdXJlZA0KIHRlbGVwaG9ueSBhbmQgc2VjdXJp
bmcgZmlyc3QtcmVzcG9uZGVyIHNlcnZpY2VzLiZuYnNwOyBJZiB5b3UgYmVsaWV2ZSB0aGF0IGFk
ZGl0aW9uYWwgZ2VuZXJpYyBKV1QgaXNzdWVzIHNob3VsZCBiZSBkaXNjdXNzZWQgYW5kIGFkZHJl
c3NlZCwgd2UgY291bGQgYWx3YXlzIHJldmlzZSB0aGlzIEJDUC4mbmJzcDsgQnV0IGRvaW5nIHNv
IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBSRkMuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFsxXSA8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPGEgaHJlZj0iaHR0
cHM6Ly9iaXRidWNrZXQub3JnL29wZW5pZC9mYXBpL3NyYy9tYXN0ZXIvRmluYW5jaWFsX0FQSV9X
RF8wMDIubWQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u
Om5vbmUiPmh0dHBzOi8vYml0YnVja2V0Lm9yZy9vcGVuaWQvZmFwaS9zcmMvbWFzdGVyL0ZpbmFu
Y2lhbF9BUElfV0RfMDAyLm1kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPiZndDsgWzJdIDxhIGhyZWY9Imh0dHBzOi8vYXJ4aXYub3JnL2Ficy8xOTAx
LjExNTIwIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u
ZSI+aHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE5MDEuMTE1MjA8L3NwYW4+PC9hPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgT2J2aW91c2x5IHRoaXMgZHJhZnQgaGFzIGhhZCBh
IGxvbmcgYW5kIHRvcnR1cmVkIGhpc3Rvcnkgd2l0aA0KPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgbXVsdGlwbGUgcmV2aWV3cywmbmJzcDsgYW5kIHdo
YXQgSSdtIHN1Z2dlc3RpbmcgbmVlZHMgdG8gaGFwcGVuIGlzIGEgbG90DQo8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OyBvZiB3b3JrLiBCdXQgaXQncyBl
c3NlbnRpYWwgaW4gYW55IHNlY3VyaXR5IHByb3RvY29sIHRvIGRvIHRoaXMNCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAmZ3Q7IGFuYWx5c2lzIGFuZCBiZSBj
bGVhciBhYm91dCB3aGF0IGlzLCBhbmQgd2hhdCBpcyBub3QsIHByb3RlY3RlZCBieSB0aGUgcHJv
dG9jb2wuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE9BdXRoIEpBUiBp
cyBub3RoaW5nIGJ1dCBqdXN0IGFub3RoZXIgYmluZGluZyB0byBPQXV0aCAyLjAuIFdoZXJlDQo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUkZDNjc0OSBiaW5k
cyBpdCB0byBmb3JtIGVuY29kaW5nLCBpdCBwcm92aWRlcyB0d28gYWRkaXRpb25hbCBiaW5kaW5n
czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgMSkgYmluZGluZyB0byBKV1QsIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyKSBiaW5k
aW5nIHRvIHRoZSBwdXNoZWQgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRoYXQgaXMgcmVmZXJlbmNl
ZCBieSBhIFVSSS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg
SXQgaXMgdGhpcyBzaW1wbGUuIEFzIHN1Y2gsIGl0IHdvdWxkIGFsc28gaW5oZXJpdCBzb21lIG9m
IHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHNob3J0
Y29taW5ncyBpbiBSRkM2NzQ5LiBIb3dldmVyLCBpdCBpcyBub3QgdGhpcyBkb2N1bWVudCB0byBh
ZGRyZXNzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhl
bS4gSXQgc2hvdWxkIGJlIGRvbmUgYnkgb3RoZXIgZG9jdW1lbnRzIHNvIHRoYXQgdGhlIHJlc3Vs
dCBjYW4gYmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBl
bmNvZGVkIHVzaW5nIHRoZSBtZWNoYW5pc21zIHByb3ZpZGVkIGluIHRoaXMgZG9jdW1lbnQuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgaXMgbm90IGEgc2ltcGxlIG1hdHRlci4g
SldUIGhhcyBhIGxvbmcgYW5kIHR3aXN0ZWQgaGlzdG9yeSB3aXRoIHNvbWUgcGVydmFzaXZlIGVy
cm9ycyBpbiBjb21tb24gbGlicmFyaWVzLCBhbmQgaXMgYSBmYWlybHkgbGFyZ2Ugc3RhbmRhcmQu
IE9BdXRoIDIuMCBpcyBhbHNvIGxhcmdlLiBFbnN1cmluZyB0aGF0IHRoZSBtYXBwaW5nIGhhcyB0
aGUgcmlnaHQgcHJvcGVydGllcyBpcyBnb2luZyB0byBiZQ0KIGEgbWVzcy4gSWYgdGhlIGVuY29k
aW5nIGRvZXMgbm90IHJlc3BlY3QgdGhlIHNlbWFudGljcyB3ZSBoYXZlIGEgc2VyaW91cyBzZWN1
cml0eSBpc3N1ZS4gSWYgaW1wbGVtZW50b3JzIGFzc3VtZSB0aGUgZW5jb2RpbmcgcHJvdmlkZXMg
cHJvcGVydGllcyBpdCBkb2VzIG5vdCwgd2UgYWdhaW4gaGF2ZSBhIHNlY3VyaXR5IGlzc3VlLjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwQjA1MCI+
TWlrZSZndDsgU2VlIG15IHByZXZpb3VzIGNvbW1lbnRzIG9uIHBhc3QgSldUIGltcGxlbWVudGF0
aW9uIGVycm9ycyBhbmQgdGhlIHdyaXRpbmcgb2YgdGhlIEpXVCBCQ1AgW1JGQyA4NzI1XSB0byBh
ZGRyZXNzIHRoZXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBJ
dCBpcyBxdWl0ZSBzdXJwcmlzaW5nIHRoYXQgdGhpcyBmYWN0IGlzIG5vdCBnZXR0aW5nIGFwcHJl
Y2lhdGVkIGFuZA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
IGlzIHRha2luZyBzdWNoIGEgbG9uZyB0aW1lIHRvIGNvbXBsZXRlLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBNYXliZSBJIHNob3VsZCBkZWxldGUgYWxsIHRo
ZSBleHBsYW5hdGlvbiB0ZXh0IGFuZCBsZWF2ZSBpdCB3aXRoIGp1c3QNCjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGUgY29yZSB0ZXh0LiBFeHBsYW5hdGlv
biBhbmQganVzdGlmaWNhdGlvbiB0ZXh0IGZvciBkZWZpbmluZw0KPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGFkZGl0aW9uYWwgYmluZGluZ3MgcHJvYmFibHkg
YXJlIGp1c3QgZGlzdHJhY3Rpb25zIG5vdyBhcyBpdCBpcyBub3cNCjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhcHByZWNpYXRlZCBhbmQgdXNlZCBhbGwgb3Zl
ciB0aGUgd29ybGQgdW5saWtlIHdoZW4gdGhlIHByb2plY3Qgd2FzDQo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc3RhcnRlZC48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEIwNTAiPk1pa2UmZ3Q7IEkgd291bGQg
cHJvcG9zZSB0aGF0IHdlIG1ha2Ugb25seSBuZWNlc3NhcnkgY2hhbmdlcyB0byB0aGUgZHJhZnQg
YXQgdGhpcyBwb2ludC4mbmJzcDsgTGV0J3MgZmluaXNoIHRoaXMgbG9uZy1vdmVyZHVlIHNwZWNp
ZmljYXRpb24hPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDsgJmd0OyBTaW5jZXJlbHksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij4mZ3Q7ICZndDsgV2F0c29uIExhZGQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZndDsgJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jmd0OyBUaGFua3MgYWdhaW4gZm9yIHlvdXIgZGV0YWlsZWQgY29tbWVudHMuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+Jmd0OyBOYXQgU2FraW11cmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgTkFULkNvbnN1bHRpbmcgTExDPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj5NaWtlJmd0OyBJIG5vdyBw
bGFuIHRvIGNyZWF0ZSBlZGl0cyBpbmNvcnBvcmF0aW5nIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9u
cyBhYm92ZSBmb3IgcmV2aWV3LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBCMDUwIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAw
QjA1MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDBCMDUwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS08bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFzdHJhIG1vcnRlbXF1ZSBwcmFlc3Rh
cmUgZ3JhZGF0aW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_SN6PR00MB042990C1C9C0DAE300E79A48F59D9SN6PR00MB0429namp_--


From nobody Fri Feb 26 13:36:17 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFEF3A0C28; Fri, 26 Feb 2021 13:36:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alkaline-solutions.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq9G8G4ZB9qA; Fri, 26 Feb 2021 13:36:08 -0800 (PST)
Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F013A0C23; Fri, 26 Feb 2021 13:36:08 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id D83B120511C; Fri, 26 Feb 2021 21:36:03 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1614375365; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XzNa/FeuwVfR8Bay5xW5Z/Cz6ylpXzhPFHfObgrQKl4=; b=j26VsexMM9UZWirBA10U4IbT/ggf3nhYnW5r733RIWigsepWklxR3l9ubbNp745821IJ3d lO+mSD+QnSWXVBCpZvWxOEW6ylKrKGZQGmQAvIWlcy/EZQ8A7vuAbVJlbTPTY3BQhqARyF 6uh2YXI9zZZX5egu6EQ0TvS4Lasqf2w=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0
From: David Waite 
In-Reply-To: 
Date: Fri, 26 Feb 2021 14:36:02 -0700
Cc: Warren Parad , Bron Gondwana , Phillip Hallam-Baker , IETF-Discussion Discussion , "oauth@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A4ABDE3-7175-4E5B-8807-437EE3CE427D@alkaline-solutions.com>
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>  
To: Aaron Parecki 
Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 21:36:10 -0000

> On Feb 26, 2021, at 9:32 AM, Aaron Parecki  wrote:

> The point is that basically nobody uses it because they don't want to =
allow arbitrary client registration at their ASs. That's likely due to a =
combination of pre-registration being the default model in OAuth for so =
long (the Dynamic Client Registration draft was published several years =
after OAuth 2.0), as well as how large corporations have decided to run =
their ASs where they want to have (what feels like) more control over =
the things talking to their servers.

Do you disagree that this gives them control over which things talk to =
their servers?

FWIW my personal mental model here is pretty simple:

With users, there are services you provide anonymously and services you =
provide only to registered/authenticated/trusted parties for various =
reasons. Once you are delegating user access, you still have many of the =
same reasons to provide access to anonymous or =
registered/authenticated/trusted delegates.

Dynamic registration arriving later and requiring additional complexity =
has unfortunately encouraged registration in use cases where anonymous =
clients might have been acceptable, but shifting the timelines or =
complexity balance would not  have changed business needs for =
authentication and trust of delegates. Omitting registration would have =
caused businesses to use other protocols that met their needs.

If AS=E2=80=99s are only getting what feels like proper control for =
their business needs, we should attempt to give them the actual control =
they require.

-DW=


From nobody Fri Feb 26 13:49:51 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0B23A0CA0 for ; Fri, 26 Feb 2021 13:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CrvDkDIVMTX for ; Fri, 26 Feb 2021 13:49:43 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F433A0C9E for ; Fri, 26 Feb 2021 13:49:42 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id i8so11191630iog.7 for ; Fri, 26 Feb 2021 13:49:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CHENElNI5uFUfxiROWSb7tFUiH0J3GnBfAV37tiA43g=; b=caaCxMqa5oOBDJK87y6emH22wmP9TWrWzcIfhbEIu5zY+uTVtiLNUqTgbDfaNVJ/Hw A3yTHtrkcy0yyhQaxfrkE8pzYwv6J2YS1fQoJchEuz56YCJ9Vcz57MQQa5TSvCSzf3yJ /LsI5JqKewnBsaIHN2P7NVPqJGXVjYPHhJzgwp3c9dw3CLK9sbaRF1yfkE+KsiGEx37i e0tIXdOqqhMm+YBt/e6BwgFgaB9v1bct35HSejRMDqdTGTdiLIHovaUwg2Wm+nMw1vIF IPRxd9nU9fNlKjh8SKJyQaWwW8c/ZbvRyJR2XbQJzfBzzUZ8XYp+XiGiYVfWFUfvfNx3 N7tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CHENElNI5uFUfxiROWSb7tFUiH0J3GnBfAV37tiA43g=; b=QRMw4mPSgJnBVPK4ErFQ0WgPMyaaHR+GGD8M14DRL9GWA7yLNdR3ORhrlOqrti+1Ec w89KHvCVJckttS55VHIxxHFSyMu4RU8nkwFq/4nugNJKTVncsVewIcWAsR4GzqQDWQ3H c4kCIdFdVoO90llcMNqY2MEz4WZE85JeBGDYWhPGsLW/2T5HWEH0GVLyvYBxKp5dHuHT Ae8Xw1eEVVsaT5egyBeLbK5NyKiaFIZql3qFTt4KMZyZDAW1T8Zt1cBOfcZYuik89IEb /tGP+mcymprukfo9iEAfYL+R4m4n4DBXVlxj2u9Zu2g4WbsnjWH2/lsxU0dleLeP6tDQ Iw5Q==
X-Gm-Message-State: AOAM530Vn5CuKnQEJikVCHFWccX7bITzNp0um/b9E6ITQwG1khvU1C7L oQwQhqX+9Y50PDu3H4fLarJLUrMLFz0S4w==
X-Google-Smtp-Source: ABdhPJyILmNXKdwqJ/CVEWhnR5o+EBOcdC89IiaGGo499wBvbawlBntBZqVSbPjszhFNAIEOp4yQlQ==
X-Received: by 2002:a5d:81d1:: with SMTP id t17mr4513071iol.208.1614376182070;  Fri, 26 Feb 2021 13:49:42 -0800 (PST)
Received: from mail-il1-f175.google.com (mail-il1-f175.google.com. [209.85.166.175]) by smtp.gmail.com with ESMTPSA id q2sm5834860ioh.20.2021.02.26.13.49.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Feb 2021 13:49:41 -0800 (PST)
Received: by mail-il1-f175.google.com with SMTP id c10so9311699ilo.8; Fri, 26 Feb 2021 13:49:41 -0800 (PST)
X-Received: by 2002:a05:6e02:1c2a:: with SMTP id m10mr4069474ilh.17.1614376181245;  Fri, 26 Feb 2021 13:49:41 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>   <6A4ABDE3-7175-4E5B-8807-437EE3CE427D@alkaline-solutions.com>
In-Reply-To: <6A4ABDE3-7175-4E5B-8807-437EE3CE427D@alkaline-solutions.com>
From: Aaron Parecki 
Date: Fri, 26 Feb 2021 13:49:30 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: David Waite 
Cc: Warren Parad ,  Bron Gondwana , Phillip Hallam-Baker ,  IETF-Discussion Discussion , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000d12f6d05bc443ed4"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 21:49:46 -0000

--000000000000d12f6d05bc443ed4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Do you disagree that this gives them control over which things talk to
their servers?

Yes -- with a public client, I can impersonate a "real" app and it's
basically non-detectable by the AS. For a theoretical example, if I wanted
to use the Instagram API but they restrict which apps can upload photos to
only their own mobile apps, I can find the client ID of their own app, then
do an OAuth flow using their own client ID, and without a client secret it
looks the same as their own client. I'm unlikely to be able to get
arbitrary users to authorize my app because of limits and checks on the
redirect URI, but I can certainly do it myself for my own account. This is
the sort of false sense of security provided by the client registration
step I'm talking about.

I'd love to solve the app identity problem too, but that's only possible
with cooperation from the mobile OSs.

Aaron

On Fri, Feb 26, 2021 at 1:36 PM David Waite 
wrote:

>
>
> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki  wrote:
>
> > The point is that basically nobody uses it because they don't want to
> allow arbitrary client registration at their ASs. That's likely due to a
> combination of pre-registration being the default model in OAuth for so
> long (the Dynamic Client Registration draft was published several years
> after OAuth 2.0), as well as how large corporations have decided to run
> their ASs where they want to have (what feels like) more control over the
> things talking to their servers.
>
> Do you disagree that this gives them control over which things talk to
> their servers?
>
> FWIW my personal mental model here is pretty simple:
>
> With users, there are services you provide anonymously and services you
> provide only to registered/authenticated/trusted parties for various
> reasons. Once you are delegating user access, you still have many of the
> same reasons to provide access to anonymous or
> registered/authenticated/trusted delegates.
>
> Dynamic registration arriving later and requiring additional complexity
> has unfortunately encouraged registration in use cases where anonymous
> clients might have been acceptable, but shifting the timelines or
> complexity balance would not  have changed business needs for
> authentication and trust of delegates. Omitting registration would have
> caused businesses to use other protocols that met their needs.
>
> If AS=E2=80=99s are only getting what feels like proper control for their=
 business
> needs, we should attempt to give them the actual control they require.
>
> -DW

--000000000000d12f6d05bc443ed4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


> Do you disagree that this gives them control over whi=
ch things talk to their servers?

Yes -- with a public cl=
ient, I can impersonate a "real" app and it's basically non-d=
etectable by the AS. For a theoretical example, if I wanted to use the Inst=
agram API but they restrict which apps can upload photos to only their own =
mobile apps, I can find the client ID of their own app, then do an OAuth fl=
ow using their own client ID, and without a client secret it looks the same=
 as their own client. I'm unlikely to be able to get arbitrary users to=
 authorize my app because of limits and checks on the redirect URI, but I c=
an certainly do it myself for my own account. This is the sort of false sen=
se of security provided by the client registration step I'm talking abo=
ut.

I'd love to solve the app identity problem=
 too, but that's only possible with cooperation from the mobile OSs.

Aaron

On Fri, Feb 26, 2021 at 1:36 PM David Wai=
te <david@alkaline-solut=
ions.com> wrote:




> On Feb 26, 2021, at 9:32 AM, Aaron Parecki <aaron@parecki.com> wrote:



> The point is that basically nobody uses it because they don't want=
 to allow arbitrary client registration at their ASs. That's likely due=
 to a combination of pre-registration being the default model in OAuth for =
so long (the Dynamic Client Registration draft was published several years =
after OAuth 2.0), as well as how large corporations have decided to run the=
ir ASs where they want to have (what feels like) more control over the thin=
gs talking to their servers.



Do you disagree that this gives them control over which things talk to thei=
r servers?



FWIW my personal mental model here is pretty simple:



With users, there are services you provide anonymously and services you pro=
vide only to registered/authenticated/trusted parties for various reasons. =
Once you are delegating user access, you still have many of the same reason=
s to provide access to anonymous or registered/authenticated/trusted delega=
tes.



Dynamic registration arriving later and requiring additional complexity has=
 unfortunately encouraged registration in use cases where anonymous clients=
 might have been acceptable, but shifting the timelines or complexity balan=
ce would not=C2=A0 have changed business needs for authentication and trust=
 of delegates. Omitting registration would have caused businesses to use ot=
her protocols that met their needs.



If AS=E2=80=99s are only getting what feels like proper control for their b=
usiness needs, we should attempt to give them the actual control they requi=
re.



-DW


--000000000000d12f6d05bc443ed4--


From nobody Fri Feb 26 13:59:31 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459473A0CC1 for ; Fri, 26 Feb 2021 13:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level: 
X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6IVWsHpKq4j for ; Fri, 26 Feb 2021 13:59:21 -0800 (PST)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5626A3A0CD9 for ; Fri, 26 Feb 2021 13:59:11 -0800 (PST)
Received: by mail-il1-x131.google.com with SMTP id o1so9293844ila.11 for ; Fri, 26 Feb 2021 13:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mo5kSM5uOXr0KRtpFXNSYSKx376YyXV/5Cp7AlExrA=; b=q9HYQ4ycrxZcyveBuCm3zTTwOTt2uPtej6Xb01sE4p7M0MiPQ8K0Uu7qsKE9o/3L0f 3lV8J9SJ6dx2zDthauHSMI1Za0EhUxhw/DMdkdpvnYiFVGrq4OUYSmlzM/Nk6GlADrX5 JAH1usrIfl+ivRiPBegEKbCyO2xIb90VHFrF2nlFNDXwcWXptoG9sCvX/WqJDwmceLAB Moyr/iw4pQq+Q+8yABP3wSzN2BH8KWikgUO9BDEoiSmi7UCsFGAlfVPrIocPHtX4wSYv 2unhavvuL+NslXqGGC+RjIQSelcPKINOKxtODSqLuYf/agx7kbXL90ccAwHlyNvpPhoa STQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0mo5kSM5uOXr0KRtpFXNSYSKx376YyXV/5Cp7AlExrA=; b=lWqjAgJDQvidi4Vdgs+V1Y2PBXDx+udIsgJu6me7IKy4sXdfqJqKSxh2ZhsH3iLwID /CJe3AtuJvIh/s+DH93kaPlVLEl6ORvjAFJ1YDPjwfa4hZaunMAfUloHAPj6NOZ8RUaX 1iHL3TUAs5c9sOL4OXsvtIhzZOEW3yJvDYsEC9MjsNZdntk+kCOBkZckkpLoYbLmSUXo uk/Okz/auFgXReUwhtIIZW+a4ro3rej2t+LgrAoeNTdllQvgGfHOdNUptiz+xKNxK96p QswZvUvrfNUci9CZElfW7Yult8xEHKgrL3G5zxlFyrw+kESbSdG6jGswyRCMGY1V7e0g h8/g==
X-Gm-Message-State: AOAM533IIjVnjFcd4zu3AbB99YXy8aMFfUwNlWEXIkpv9LYXqfYcQEHy nOMq3FP6Q0B4ADWbnsM/qNSkgxqr61LJupNTROyHLA==
X-Google-Smtp-Source: ABdhPJyN7yFOxvYdKLz1gj8sj86qjbl0ZTToCVb4nInqSRO3OOf1IzaTiuh7LrhiWz9o/qk4qDfQyDgNzf3YfNd+mmc=
X-Received: by 2002:a92:cb49:: with SMTP id f9mr4006813ilq.0.1614376750338; Fri, 26 Feb 2021 13:59:10 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu>   <6A4ABDE3-7175-4E5B-8807-437EE3CE427D@alkaline-solutions.com> 
In-Reply-To: 
From: Jeff Craig 
Date: Fri, 26 Feb 2021 15:58:58 -0600
Message-ID: 
To: Aaron Parecki 
Cc: David Waite , Bron Gondwana ,  Phillip Hallam-Baker , "oauth@ietf.org" , IETF-Discussion Discussion , Warren Parad 
Content-Type: multipart/alternative; boundary="000000000000bd3aec05bc4460df"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Feb 2021 21:59:25 -0000

--000000000000bd3aec05bc4460df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 26, 2021 at 3:50 PM Aaron Parecki  wrote:

> > Do you disagree that this gives them control over which things talk to
> their servers?
>
> Yes -- with a public client, I can impersonate a "real" app and it's
> basically non-detectable by the AS. For a theoretical example, if I wante=
d
> to use the Instagram API but they restrict which apps can upload photos t=
o
> only their own mobile apps, I can find the client ID of their own app, th=
en
> do an OAuth flow using their own client ID, and without a client secret i=
t
> looks the same as their own client. I'm unlikely to be able to get
> arbitrary users to authorize my app because of limits and checks on the
> redirect URI, but I can certainly do it myself for my own account. This i=
s
> the sort of false sense of security provided by the client registration
> step I'm talking about.
>

The fact that you're unlikely to be able to get arbitrary users authorized
as the client is precisely the attack vector that registration is meant to
avoid. The fact that any reasonably sophisticated AS is going to use
additional signals (Referer headers, etc) to limit the scope of the Public
Client to make hijacking harder, which is only possible with registration,
is another line of defense. OAuth doesn't need to protect *your* data from
you, it needs to protect other people's data from you, and registration
offers more opportunities to collect signals that can be used to protect
users.

None of it's perfect, and I agree that there are problems in the
app-identification space that need some additional work, but the
registration friction does serve a purpose in a lot of cases.


>
> I'd love to solve the app identity problem too, but that's only possible
> with cooperation from the mobile OSs.
>
> Aaron
>
> On Fri, Feb 26, 2021 at 1:36 PM David Waite 
> wrote:
>
>>
>>
>> > On Feb 26, 2021, at 9:32 AM, Aaron Parecki  wrote:
>>
>> > The point is that basically nobody uses it because they don't want to
>> allow arbitrary client registration at their ASs. That's likely due to a
>> combination of pre-registration being the default model in OAuth for so
>> long (the Dynamic Client Registration draft was published several years
>> after OAuth 2.0), as well as how large corporations have decided to run
>> their ASs where they want to have (what feels like) more control over th=
e
>> things talking to their servers.
>>
>> Do you disagree that this gives them control over which things talk to
>> their servers?
>>
>> FWIW my personal mental model here is pretty simple:
>>
>> With users, there are services you provide anonymously and services you
>> provide only to registered/authenticated/trusted parties for various
>> reasons. Once you are delegating user access, you still have many of the
>> same reasons to provide access to anonymous or
>> registered/authenticated/trusted delegates.
>>
>> Dynamic registration arriving later and requiring additional complexity
>> has unfortunately encouraged registration in use cases where anonymous
>> clients might have been acceptable, but shifting the timelines or
>> complexity balance would not  have changed business needs for
>> authentication and trust of delegates. Omitting registration would have
>> caused businesses to use other protocols that met their needs.
>>
>> If AS=E2=80=99s are only getting what feels like proper control for thei=
r
>> business needs, we should attempt to give them the actual control they
>> require.
>>
>> -DW
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--000000000000bd3aec05bc4460df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Fri, Feb 26, 2021 at 3:50 PM Aaron Par=
ecki <aaron@parecki.com> wro=
te:
> Do you disagree that this gives them c=
ontrol over which things talk to their servers?

Yes -- w=
ith a public client, I can impersonate a "real" app and it's =
basically non-detectable by the AS. For a theoretical example, if I wanted =
to use the Instagram API but they restrict which apps can upload photos to =
only their own mobile apps, I can find the client ID of their own app, then=
 do an OAuth flow using their own client ID, and without a client secret it=
 looks the same as their own client. I'm unlikely to be able to get arb=
itrary users to authorize my app because of limits and checks on the redire=
ct URI, but I can certainly do it myself for my own account. This is the so=
rt of false sense of security provided by the client registration step I=
9;m talking about.

The fact tha=
t you're unlikely to be able to get arbitrary users authorized as the c=
lient is precisely the attack vector that registration is meant to avoid. T=
he fact that any reasonably sophisticated AS is going to use additional sig=
nals (Referer headers, etc) to limit the scope of the Public Client to make=
 hijacking harder, which is only possible with registration, is another lin=
e of defense. OAuth doesn't need to protect *your* data from you, it ne=
eds to protect other people's data from you, and registration offers mo=
re opportunities to collect signals that can be used to protect users.

None of it's perfect, and I agree that there are p=
roblems in the app-identification space that need some additional work, but=
 the registration friction does serve a purpose in a lot of cases.
=C2=A0

I'd love to solve the app identity problem to=
o, but that's only possible with cooperation from the mobile OSs.
=


Aaron

On Fri, Feb 26, 2021 at 1:36 PM David Waite =
<david=
@alkaline-solutions.com> wrote:




> On Feb 26, 2021, at 9:32 AM, Aaron Parecki <aaron@parecki.com> wrote:



> The point is that basically nobody uses it because they don't want=
 to allow arbitrary client registration at their ASs. That's likely due=
 to a combination of pre-registration being the default model in OAuth for =
so long (the Dynamic Client Registration draft was published several years =
after OAuth 2.0), as well as how large corporations have decided to run the=
ir ASs where they want to have (what feels like) more control over the thin=
gs talking to their servers.



Do you disagree that this gives them control over which things talk to thei=
r servers?



FWIW my personal mental model here is pretty simple:



With users, there are services you provide anonymously and services you pro=
vide only to registered/authenticated/trusted parties for various reasons. =
Once you are delegating user access, you still have many of the same reason=
s to provide access to anonymous or registered/authenticated/trusted delega=
tes.



Dynamic registration arriving later and requiring additional complexity has=
 unfortunately encouraged registration in use cases where anonymous clients=
 might have been acceptable, but shifting the timelines or complexity balan=
ce would not=C2=A0 have changed business needs for authentication and trust=
 of delegates. Omitting registration would have caused businesses to use ot=
her protocols that met their needs.



If AS=E2=80=99s are only getting what feels like proper control for their b=
usiness needs, we should attempt to give them the actual control they requi=
re.



-DW

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--000000000000bd3aec05bc4460df--


From nobody Sat Feb 27 08:16:11 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEC3A0C98; Sat, 27 Feb 2021 08:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFMQ5JuLzYmZ; Sat, 27 Feb 2021 08:16:04 -0800 (PST)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EA83A0C94; Sat, 27 Feb 2021 08:16:03 -0800 (PST)
Received: by mail-yb1-f169.google.com with SMTP id x19so12225999ybe.0; Sat, 27 Feb 2021 08:16:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sQt9GlbRaLotfNR9rfajZbw1fcGoA1siDoeSEzo9r4s=; b=c/2G5goGmL/3PqNHSSejUZ6yJH25Mminx4y3N1cs18XRfkLeBSkk3Q7/oWX4O5rcbn JyBVj6sEMzGmo5r6NFuy7Zi3u2d+nXLDww8qbBLZ+wekNUHy9OEgT1Cyb553l9u2cmzP AmbWRstePyJaGmoXoITGkz6f5penixj/5qvM4Po9H2stTLIIiLa0giP+sQqzGSo9mF1G NoIgxDA+I6wbI9RDhtJwaVW9t8+8iVnLhAK+jhNXhq3DRMliIFcvriEjCR5I11ryqIRL KnwTJJyVg1DEWQ0ZvOgQfNX/IU2tgDoDYWSuFw9c0SRMCyThPPGM0VO/47MKdEYIns4K ZabQ==
X-Gm-Message-State: AOAM5312REe1hpTEVd/FNTPUgnhJiwSjBok+k+lqUkbQgew6vzI7UpXI ZXSNY2AJ9qMcomO+HYjZhwAXl12xbUUXRrfl8uQ=
X-Google-Smtp-Source: ABdhPJzAP1wPITiA6devBSWAje/ASX9gVgUKKRb7MUQJr1xnjQtp9gub8FjQ2UfdmhHweOYr/DVflQMdR4XPgqd2sTI=
X-Received: by 2002:a25:50d8:: with SMTP id e207mr11177063ybb.56.1614442562749;  Sat, 27 Feb 2021 08:16:02 -0800 (PST)
MIME-Version: 1.0
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com>   <6E2CD5EE-55D9-403A-835D-032ECA39CBFB@mit.edu> 
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Sat, 27 Feb 2021 11:15:51 -0500
Message-ID: 
To: Tim Bray 
Cc: Justin Richer , =?UTF-8?Q?Se=C3=A1n_Kelleher?= ,  "oauth@ietf.org" , IETF-Discussion Discussion 
Content-Type: multipart/alternative; boundary="0000000000007688e305bc53b379"
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 Feb 2021 16:16:06 -0000

--0000000000007688e305bc53b379
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 26, 2021 at 11:32 AM Tim Bray  wrote:

>
>
> On Fri, Feb 26, 2021 at 8:10 AM Justin Richer  wrote:
>
>> Right, it=E2=80=99s possible to patch OAuth to do this, but the whole
>> =E2=80=9Cregistration equals trust=E2=80=9D mindset is baked into OAuth =
at a really core
>> level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesit=
ance at deploying
>> dynamic registration. It=E2=80=99s an extension that changes your trust =
model=E2=80=99s
>> assumptions, and does so in a way that is challenging for a lot of large
>> scale providers.
>>
>
> Justin is correct but being extremely diplomatic. =E2=80=9CThere=E2=80=99=
s been
> hesitance=E2=80=9D, as he puts it, translates in practice to some lawyer =
or VP
> saying =E2=80=9CYou want to accept auth assertions for business transacti=
ons from
> unknown parties?  I have no interest in jail time, so forget it.=E2=80=9D
>

Getting back to the general case rather than litigating one particular
protocol. I have on many occasions found that the response to raising an
issue in the IETF is to be told that the solution is I should go and
'educate them' to understand that their concern doesn't matter.

--0000000000007688e305bc53b379
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Feb 26, 2021 at 11:32 AM Tim Bray <tbray@textuality.com> wrote:
<=
/div>


On Fri, Feb 26, 2021=
 at 8:10 AM Justin Richer <jricher@mit.edu> wrote:
Right, it=
=E2=80=99s possible to patch OAuth to do this, but the whole =E2=80=9Cregis=
tration equals trust=E2=80=9D mindset is baked into OAuth at a really core =
level. That=E2=80=99s one of the main reasons there=E2=80=99s been hesitanc=
e at deploying dynamic registration. It=E2=80=99s an extension that changes=
 your trust model=E2=80=99s assumptions, and does so in a way that is chall=
enging for a lot of large scale providers.

Justin is correct but being extremely =
diplomatic. =E2=80=9CThere=E2=80=99s been hesitance=E2=80=9D, as he puts it=
, translates in practice to some lawyer or VP saying =E2=80=9CYou want to a=
ccept auth assertions for business transactions from unknown parties?=C2=A0=
 I have no interest in jail time, so forget it.=E2=80=9D=C2=A0=C2=A0
<=
/div>

Getting back to the general case rather than =
litigating one particular protocol. I have on many occasions found that the=
 response to raising an issue in the IETF is to be told that the solution i=
s I should go and 'educate them' to understand that their concern d=
oesn't matter.


=C2=A0


--0000000000007688e305bc53b379--


From nobody Sun Feb 28 20:36:03 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9569B3A1496; Sun, 28 Feb 2021 20:35:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level: 
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FProOofa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mvv7/yBe
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU7QbmUs7CsD; Sun, 28 Feb 2021 20:35:55 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB13A1495; Sun, 28 Feb 2021 20:35:55 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2F4855C00B4; Sun, 28 Feb 2021 23:35:54 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Sun, 28 Feb 2021 23:35:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=VUmn 2RIrpI0Fq6S1qfBgpEnnQbMhWqJrkDweQIM9Kj8=; b=FProOofakGlOB/T97imj OQqK1R9shIunnzlCn0ORKyqb5Q/KXXDGw5T97zJEUqMQIPKe7LlwzFNDbXFEjY2Z lO/rIi9+dSPEt7sRS8szlbwEr2vjKEEnwZdlVNJq6/BjDgXIyJzPwnvTnY3X9eyL d2ZSUfaGTcCq05rKfAXO5f5uTcplCc0VUjhvchDG+fMUDL+ZSpWfYYcp3r0iEPXg m22P00N6uD8JCwVzZHDDQyENToL6z3sxAdhj2havp2jWU5ASIWhPrbY4vCpRjddL O3tl0aZHF5g60Jbr8XzJsXp6YsVhyF2pLHSxym2brqLDgFUBq7BNYGdbyVAf1+2p JA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=VUmn2R IrpI0Fq6S1qfBgpEnnQbMhWqJrkDweQIM9Kj8=; b=mvv7/yBeDbL6bHQnHoV04V oV47X5LF62Kh7I+XAFTZRg6cgiWp081Za5yNsHI4guyxFaUntbDo+WxxQMsJwYDq 7zDyIZ2V9IzZdPs6yIRCdogqo31dPfrAMRWAVjv9luGNKsURqr/2X5UDszZ/r9NH 8KXGth8OuLk3Rlom9XjJvxKF2srmt1bZV2mPBQYEdnimy+4tWWUcGz7fug3AFL/n Cd7FYxjTW6FjlNzBWtcNePW6qrTYSs9Ui+6F0/NaHyCvp3tmppvU9dTIcEuX4/vU aZOU24cCQUDr1axhsOOVGPkSK8mr7rj5xoxvmv08CEMuKsGCbDAJP1qu6CIIC12A ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleejgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpefgteeutdeftedtffeftdduudfhkedvffeuhfejjeevueev tedvudduueeifedtffenucffohhmrghinhepfihikhhiphgvughirgdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E114360592; Sun, 28 Feb 2021 23:35:53 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd
Mime-Version: 1.0
Message-Id: <7ee21778-2ab2-40f5-9273-775f8a88744b@beta.fastmail.com>
In-Reply-To: 
References:       <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>  <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com>  <6b5d0e34-340f-4f93-83ef-817d4624ec7d@dogfood.fastmail.com> 
Date: Mon, 01 Mar 2021 15:35:23 +1100
From: "Bron Gondwana" 
To: =?UTF-8?Q?Se=C3=A1n_Kelleher?= 
Cc: "Justin Richer" , "Phillip Hallam-Baker" , "oauth@ietf.org" , ietf@ietf.org
Content-Type: multipart/alternative; boundary=c792c58e39f145ceaadf3ef6c453c130
Archived-At: 
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Mar 2021 04:35:58 -0000

--c792c58e39f145ceaadf3ef6c453c130
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Feb 25, 2021, at 19:22, Se=C3=A1n Kelleher wrote:
> Just to clarify, I assume in this discourse that the "server" in this =
client and server relationship refers to an AS/RS pair in OAuth terminol=
ogy? Based on this, one big sticking point for me on the applicability o=
f NxM, or even 1xM, is that all of the "M" RSs need to publish the same =
interface for any meaningful implementation in the first place.
>=20
> It probably makes more sense with email clients, since as Bron said, t=
here is the common standard of POP. If we assume that all the email serv=
ices that we want to connect to publish the same POP interface, and woul=
d accept tokens in the same way, then the way the authZ is handled is in=
deed the point of divergence that needs to be resolved.
>=20
> However, we're talking about NxM in the general case here. I feel like=
 using the likes of discovery and dynamic registration, etc. that's alre=
ady supported by OAuth, the "N" part of this equation is surmountable. B=
ut each of the "M" servers also need to export the same interface, other=
wise a client is going to have to write custom code to deal with talking=
 to the service after the authZ step anyway, reintroducing the "problem"=
 part of the NxM problem.
>=20
> As such, I would actually suggest constraining this discussion to just=
 the POP NxM problem rather than NxM in general because, for me at least=
, the authZ part of the general case is the most "solved" part of the pr=
oblem, and the outstanding work lies more in consolidating the "M" RS in=
terfaces.

Sorry for the delay in responding - real life got in they way of this ge=
neral discussion.

Yes, the common standard of POP - or indeed any common standard.  A fine=
 example of common standards is the move towards many devices being char=
ged by USB-C these days.  Previously, there was this:

https://en.wikipedia.org/wiki/Common_external_power_supply

Why?  So you that you don't need a new charger for each new device.

The whole point of being a standards org is to try to guide each "M" tow=
ards exporting the same interface when providing the same (or similar en=
ough) underlying service, so that the network effects of interoperabilit=
y are realised.

So yes, constrain to POP (and IMAP, and SMTP submission, and file storag=
e, and calendars, and ... everything where there's enough similarity tha=
t clients should be able to portably interoperate with multiple services=
).

Right now the problem with POP/IMAP/etc is that the interoperable authen=
tication choice is "username+password".  There's nothing better than tha=
t because there's no Micro-USB-like thing that has sufficient technical =
and political clout behind it that everyone implements it.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--c792c58e39f145ceaadf3ef6c453c130
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 25, 2021, at 19:22, Se=C3=A1n Kelleher wrote:
Ju=
st to clarify, I assume in this discourse that the "server" in this clie=
nt and server relationship refers to an AS/RS pair in OAuth terminology?=
 Based on this, one big sticking point for me on the applicability =
of NxM, or even 1xM, is that all of the "M" RSs need to publish the same=
 interface for any meaningful implementation in the first place.

It probably makes more sense with email clients, s=
ince as Bron said, there is the common standard of POP. If we assume tha=
t all the email services that we want to connect to publish the same POP=
 interface, and would accept tokens in the same way, then the way the au=
thZ is handled is indeed the point of divergence that needs to be resolv=
ed.

However, we're talking about NxM in the=
 general case here. I feel like using the likes of discovery and dy=
namic registration, etc. that's already supported by OAuth, the "N" part=
 of this equation is surmountable. But each of the "M" servers=
 also need to export the same interface, otherwise a client is going to =
have to write custom code to deal with talking to the service after the =
authZ step anyway, reintroducing the "problem" part of the NxM problem.<=
br>

As such, I would actually suggest constrain=
ing this discussion to just the POP NxM problem rather than NxM in gener=
al because, for me at least, the authZ part of the general case is the m=
ost "solved" part of the problem, and the outstanding work lies more in =
consolidating the "M" RS interfaces.

S=
orry for the delay in responding - real life got in they way of this gen=
eral discussion.

Yes, the common standard of POP - or ind=
eed any common standard.  A fine example of common standards is the=
 move towards many devices being charged by USB-C these days.  Prev=
iously, there was this:

<=
/div>
=

Why?  So you that you d=
on't need a new charger for each new device.

The whole po=
int of being a standards org is to try to guide each "M" towards exporti=
ng the same interface when providing the same (or similar enough) underl=
ying service, so that the network effects of interoperability are realis=
ed.

So yes, constrain to POP (and IMAP, and SMTP submissi=
on, and file storage, and calendars, and ... everything where there's en=
ough similarity that clients should be able to portably interoperate wit=
h multiple services).

Right now the problem with POP/IMAP=
/etc is that the interoperable authentication choice is "username+passwo=
rd".  There's nothing better than that because there's no Micro-USB=
-like thing that has sufficient technical and political clout behind it =
that everyone implements it.
=

Bron.

--
  Bron Gondwana, CEO, =
Fastmail Pty Ltd
  brong@fastmail=
team.com



--c792c58e39f145ceaadf3ef6c453c130--


From nobody Sun Feb 28 22:21:52 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C763A1624; Sun, 28 Feb 2021 22:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSzKFHAOmoKo; Sun, 28 Feb 2021 22:21:48 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5DE3A161F; Sun, 28 Feb 2021 22:21:48 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id p1so14618250edy.2; Sun, 28 Feb 2021 22:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gcL3+LUYTQuq67Xmhai6446kW8AtUV4CuqPfzNkoJIE=; b=e4yZeRxv8n0IWK53DLYSpBsYHxTzbddpTIHGoRdmByupLnZn6e6Cll07WQ40DhMiht LxeoIQk6JawY2hxUaRvSD5pNc7IZfKeLvx9BmZ8I20crF82HD9L2hpI4wY01C0obS5CS uSyBpqMAxhhYlcU5LKNw+7PsD8nHd6INKVsFDSW+hkc7gye2Fer5+vH91SxBxp68T3MD rjhFwRLDELAvyjovTBiKa0ed38bFxhNUEz0PR2nKHMesx/lHxV7aPVZ8OmPvouQSzGdH bbJgs9kOIz2sMJZnktdZcd+krFj3jAARng2ywoM/eNoxH/jLdpcZ+2MeXTLgk2F8dFau +gvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gcL3+LUYTQuq67Xmhai6446kW8AtUV4CuqPfzNkoJIE=; b=MzuLbq2aQ9jU8X0hQI3zcKXzSPYcSzwolvHP8Ae2mMYufeh+EW0wSHvY9ScKY5iDhg RcU+siqpQDQBn51tta6FlZaNqY35XFS0rQmK1FxYoipTjXriNihGwpeFggyUcSUFz88I /g8ywArD5/dksIW8MGmjlah2wNWpngCxVMcAXDETIpJNZy+/vVu9tAB7+hSoet6iBYZa ZlAa+AZ/vsJMZr/3w7/x5HSLrr3DLtpLbff+XBusMclaN+m7ANTv/kPsgSc0LICx4Xfw 2la+IeOxuqKXyMuN4rvdCbrEdgRpCBUs/FQVZPHp1udg5pwvvdDc2DK5wFsHmd3QpVnF KyAQ==
X-Gm-Message-State: AOAM530039Vj+AtBjY15ueo0i6hJxYyXE688Wx48COUvBtStQ+kHntzZ 2l5MsK3U1zDTHpcMt/6R1fKtCe72DtMtTCbU2/9g3k5iqGw=
X-Google-Smtp-Source: ABdhPJxeYoFF/ezYPcoRyJeb5fYIGs0hfEQLwTOh4No/c32ZylunZ3nWPlhqnKt7wTj2A8t3/qUFpWoRlShE3u74FYE=
X-Received: by 2002:a05:6402:84b:: with SMTP id b11mr5905815edz.56.1614579705450;  Sun, 28 Feb 2021 22:21:45 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Watson Ladd 
Date: Sun, 28 Feb 2021 22:21:33 -0800
Message-ID: 
To: Mike Jones 
Cc: nat , "rdd@cert.org" ,  "secdir@ietf.org" , "oauth@ietf.org" ,  "last-call@ietf.org" ,  "draft-ietf-oauth-jwsreq.all@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Mar 2021 06:21:51 -0000

On Fri, Feb 26, 2021 at 12:54 PM Mike Jones  w=
rote:
>
> Thanks again for your review, Watson.  My replies to your comments below =
are prefixed by "Mike>".

Thank you for the work on the draft. I've removed places where we
agree in the interest of readability, so the result may be more
contentious than it ought to be.

>
>
>
> > > And now for the thorny issues with this draft. Signatures and
>
> > > encryption are different. And encrypting a signed blob doesn't mean t=
he signer encrypted it.
>
> > > Then there are a plethora of methods specified in the draft  to
>
> > > authenticate the blob, which will give different results in
>
> > > maliciously constructed examples. The security considerations
>
> > > section should discuss what the encrypted vs signed choices give in
>
> > > the way of security, and it doesn't. This makes me worry.
>
> >
>
> > We don=E2=80=99t expect the encryption to ensure authenticity, that=E2=
=80=99s what the
>
> > signatures are used for.
>
>
>
> This needs to be very clearly spelled out in the text. Lots of people wil=
l not understand this. The wording of section 10.2 is at best ambivalent, w=
ith multiple alternatives presented as acceptable.
>
>
>
> Mike> After the sentence at 10.2 (b) about symmetric encryption, I propos=
e that we add the following sentence to emphasize the point you're raising:=
  "Note however, that if public key encryption is used, no source authentic=
ation is enabled by the encryption, as any party can encrypt content to the=
 public key."

10.2(b)  relies on assumptions about key handling that I don't think
are necessarily true. 10.2(a) is more foolproof. Can everyone just use
that?

>
>
>
> 
>
> >
>
> > I didn't quite get what is meant by "plethora of methods specified in
>
> > the draft to authenticate the blob ... "
>
> > There is a bit of text about authenticating the source (=3Dclient) but
>
> > not much on the blob itself.
>
> > The discussion around the signature and/or encryption is covered in
>
> > RFC7519 (JWT), the format that the request object assumes.
>
> > This is required reading when implementing this spec, so WG thought it
>
> > is not worth repeating here.
>
> > Attacks etc. on the signature and encryption are covered in RFC7515
>
> > and RFC7516 respectively.
>
>
>
> Well, the draft happens to include the following text:
>
>    "The Authorization Server MUST validate the signature of the JSON Web
>
>    Signature [RFC7515] signed Request Object.  The signature MUST be
>
>    validated using the key for that "client_id" and the algorithm
>
>    specified in the "alg" Header Parameter."
>
>
>
> Shouldn't the key be associated with a single algorithm? How do we ensure=
 that the common attack of telling the server to use hmac to verify the sig=
nature doesn't work here?
>
>
>
> Mike> Good point.  This attack is described in Section 2.1 of RFC 8725 an=
d mitigated by the practices in Sections 3.1 and 3.2 of the same.  I propos=
e that we replace the sentence:
>
>     "The signature MUST be validated using the key for that "client_id" a=
nd the algorithm specified in the "alg" Header Parameter."
>
> with:
>
>     "The signature MUST be validated using a key associated with the clie=
nt and the algorithm specified in the "alg" Header Parameter.  If a "kid" H=
eader Parameter is present, the key identified MUST be the key used, and MU=
ST be a key associated with the client.  Algorithm verification MUST be per=
formed, as specified in Sections 3.1 and 3.2 of RFC 8725."

So I think 3.2 of RFC 8725 imposes requirements on the storage of keys
and association with algorithms that have implications for the whole
system. Leaving that to a reference is going to be surprising.

>
>
> > > Key management is ignored. This is a very important issue,
>
> > > especially
>
> >
>
> > A lot of ground is covered by RFC 7515, 7516, 7517, 7518, 7519, 7591,
>
> > and 8414 so this document is not specifically restating them.

The problem with pointing to very generic drafts that don't use ths

>
> >
>
> > >
>
> > > considering the potential problems with the reuse of JWT. I'd like
>
> > > to see a
>
> >
>
> > Are you talking about the reuse of the request object by an adversary
>
> > trying to act as an honest client?
>
> > Even if it happens, the malicious client does not have the proper
>
> > client credential so it cannot redeem the code it obtained with the
>
> > token. It is no different than RFC6749 code grant. Protocols that
>
> > extend it, such as OpenID Connect, have introduced nonce to prevent
>
> > the reuse and used JAR (it is called request object there) to further
>
> > protect tampering and achieve client authentication even in the front
>
> > channel.
>
> >
>
> > > recommendation that keys be separated by intended uses, rather than
>
> > > limiting particular fields in an ad-hoc manner.
>
> >
>
> > Could you kindly elaborate on the "ad-hoc manner" part so that I can
>
> > understand it more fully?
>
>
>
> 10.8, Cross-JWT Confusion discusses avoiding signing certain fields, rath=
er than suggesting good key usage as a solution.
>
>
>
> Mike> I propose to add this new paragraph at the end of Section 10.8 to i=
mplement your suggestion:
>
>     "Finally, another way to prevent cross-JWT confusion is to use a key =
management regime in which keys used to sign Request Objects are identifiab=
ly distinct from those used for other purposes.  Then, if an adversary atte=
mpts to repurpose the Request Object in another context, a key mismatch wil=
l occur, thwarting the attack."

This should be the only way to do it. It's far safer than assuming
symmetric key hygiene (in particular, are you sure your own
encryptions can't come back).

>
>
>
> > > My biggest concern is that these issues are signs that the problem
>
> > > this draft is trying to solve and the mechanisms to solve it haven't
>
> > > been analyzed as thoroughly as they should have been. Without that
>
> > > sort of thorough analysis it's not certain that the mechanisms
>
> > > actually solve the problem and it's not clear what the
>
> > > recommendations to implementers have to be to preserve those properti=
es.
>
> >
>
> > OAuth JAR, as the name "The OAuth 2.0 Authorization Framework: JWT
>
> > Secured Authorization Request (JAR)" suggests, is a framework and not
>
> > a house itself. One such example is FAPI [1] which was formally
>
> > verified [2].
>
>
>
> "It's possible to use this draft security" I don't think should be enough=
 anymore. Rather it should be impossible to use insecurely.
>
>
>
> Mike> The draft describes how to use the mechanism securely.  Yes, if por=
tions of the draft (and those it depends upon) are not followed, insecure u=
sage can result.  That's true of any security draft.  If there are addition=
al specific requirements and/or recommendations needed, we'd be glad to add=
 them.  If so, please identify them.  (Indeed, we're already doing so in re=
sponse to your existing specific feedback.)

Are all possible choices implementors have when complying with this
draft going to end up with secure results? That should mean that there
aren't additional requirements or recommendations needed. What sorts
of analysis informed this draft? The goal should be that any
conforming implementation not be subject to any attack, no matter the
combination of options selected. Pointing to a particular secure
subset of the draft doesn't help justify the elements not in that
subset.


>
>
>
> Mike> As for past JWT problems, the JWT BCP [RFC 8725] was written at the=
 request of the IESG to identify and mitigate them - especially in light of=
 JWTs being used for additional use cases, such as STIR secured telephony a=
nd securing first-responder services.  If you believe that additional gener=
ic JWT issues should be discussed and addressed, we could always revise thi=
s BCP.  But doing so is beyond the scope of this RFC.
>
>
>
> > [1]
>
> > https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md
>
> > [2] https://arxiv.org/abs/1901.11520
>
> >
>
> > >
>
> > > Obviously this draft has had a long and tortured history with
>
> > > multiple reviews,  and what I'm suggesting needs to happen is a lot
>
> > > of work. But it's essential in any security protocol to do this
>
> > > analysis and be clear about what is, and what is not, protected by th=
e protocol.
>
> >
>
> > OAuth JAR is nothing but just another binding to OAuth 2.0. Where
>
> > RFC6749 binds it to form encoding, it provides two additional bindings:
>
> >     1) binding to JWT, and
>
> >     2) binding to the pushed authorization request that is referenced b=
y a URI.
>
> > It is this simple. As such, it would also inherit some of the
>
> > shortcomings in RFC6749. However, it is not this document to address
>
> > them. It should be done by other documents so that the result can be
>
> > encoded using the mechanisms provided in this document.
>
>
>
> This is not a simple matter. JWT has a long and twisted history with some=
 pervasive errors in common libraries, and is a fairly large standard. OAut=
h 2.0 is also large. Ensuring that the mapping has the right properties is =
going to be a mess. If the encoding does not respect the semantics we have =
a serious security issue. If implementors assume the encoding provides prop=
erties it does not, we again have a security issue.
>
>
>
> Mike> See my previous comments on past JWT implementation errors and the =
writing of the JWT BCP [RFC 8725] to address these.

JWT provides certain properties. OAUTH 2.0 assumes certain properties.
Are the properties required by OAUTH 2.0 those provided by this
draft's use of JWT? That's independent of generic problems of JWT but
very specific. By way of analogy if you use HMAC as a signature scheme
you're going to have a bad time, even though HMAC is secure, because
its properties are not those of a signature scheme. That's true no
matter how much you insist your HMAC implementation is correct.

>
>
>
> > It is quite surprising that this fact is not getting appreciated and
>
> > is taking such a long time to complete.
>
> > Maybe I should delete all the explanation text and leave it with just
>
> > the core text. Explanation and justification text for defining
>
> > additional bindings probably are just distractions now as it is now
>
> > appreciated and used all over the world unlike when the project was
>
> > started.
>
>
>
> Mike> I would propose that we make only necessary changes to the draft at=
 this point.  Let's finish this long-overdue specification!
>
>
>
> >
>
> > >
>
> > > Sincerely,
>
> > > Watson Ladd
>
> > >
>
> >
>
> > Thanks again for your detailed comments.
>
> >
>
> > Best wishes,
>
> >
>
> > --
>
> > Nat Sakimura
>
> > NAT.Consulting LLC
>
>
>
> Mike> I now plan to create edits incorporating the proposed resolutions a=
bove for review.
>
>
>
>                                                        Best wishes,
>
>                                                        -- Mike
>
>
>
> --
>
> Astra mortemque praestare gradatim



--
Astra mortemque praestare gradatim




<=
font color=3D"#5856d6" face=3D"Arial" class=3D"">[=E2=80=A6]

Let's get down to use cases then, rather than talking =
in abstracts.

I'm an end user with a =
copy of {The Bat email client} and I want to connect it to {Gmail} + {Yahoo=
} + {My ISP}.  It supports {POP3}, a widely popular open standard.&nbs=
p; I want to be able to authenticate to each of those services without savi=
ng my plaintext passwords on my hard disk where the next {Windows ME} virus=
 will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will th=
en be exfiltrated from my {Paybuddy} account, leaving me destitute.

But, {The Bat} doesn't have a trusted client=
 cert from my isp, because who does - so there's no good protocol for me - =
it's either plaintext auth, or it's some architecture astronaut multi-party=
 nonsense that's massively over specified and doesn't work half the time.&n=
bsp; So I write a plain text password on a post-it note which is lying in t=
he dust under my monitor because the glue has gone bad, and I hope I never =
accidentally click "remember me" when I type it in.

That's been the reality of the end user experience for very =
many years.

NxM means that you can au=
thenticate an arbitrary client against an arbitrary server so long as they =
are both speaking a known public protocol, without needing to build a trust=
 relationship between the client vendor and the server vendor first.

On 15 Feb 2021, at 08:32, Philippe De Ry=
ck <philippe@pragmaticwebsecurity.com> wrote:

[...]

Compared to using a worker for=
 handling RTs, I believe the TMI-BFF only adds a single security benefit: a=
n attacker is no longer able to run a silent flow to obtain a fresh set of =
tokens (since the client is now a confidential client). 
=


But they can just call the bff-token endp=
oint to do the same. If there is a security advantage, IMO it is as a defen=
ce in depth against open redirects, unicode normalisation attacks (ie not v=
alidating the redirect_uri correctly at the AS), etc. 

<=
/div>
=E2=80=94 Neil



ForgeRock values your Privacy
--Apple-Mail-5C230414-B64C-40D7-A7D8-806CC0015B08--


From nobody Mon Feb 15 02:27:02 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9335C3A10E6 for ; Mon, 15 Feb 2021 02:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=DxRGobm1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=czbAUBP7
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsEYZ1qdqLP4 for ; Mon, 15 Feb 2021 02:26:59 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127603A10E5 for ; Mon, 15 Feb 2021 02:26:58 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7236DCC5; Mon, 15 Feb 2021 05:26:57 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 15 Feb 2021 05:26:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=94CPxbDLWFyyyWRqVmmMugBdxCoJMEaQ/kEFXpUqvZU=; b=DxRGobm1FLu5 8X81kU95OQx9EeP063x2t8S9iy3sM8uUP+kDGdGEKgccfbMEXr31ZF0yQx4AZuVT w4SV5uSgwqWubnsulW4Tcz/5viR5weolVrT6pqGo6EGPKH4tlQISnUlPzBizCt10 Ga+Iseu00SxOAMnW71I0D7Tp1NgMrn4YOeL6BKRzNvTQH/BG1zCLVpAHawO+3HLY ijYea59NNdbbhPWZhBOkguFQwnd9wOArHVGnLGND8msYpj5wVEXrRseIv+Hni1p5 LpeTk26Fj+IdU5rmwH5kXsG8jpzPKkEcnMf22CfKQCx/ww6CgE5SZrEhp8M81zwX Pp7+S1cAsA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=94CPxb DLWFyyyWRqVmmMugBdxCoJMEaQ/kEFXpUqvZU=; b=czbAUBP7f/BwdHFKgWSkvo gZKgUoEAKxUqCingxr2DzzBgoxgA8Iy4NhSdNTbLTQkxP6ZB7TbbB/BDUOvCgUgG 2yWbT1ykHEKKmv3Nw6mhCRVIKYviYp7S6/pPhYMNHT5oyy6jhqwj0J3Aa13skRvG jV63YD1K7DJbzAAPZRQZ4vehXmyloSYOHf3SYCP9x7rtsh/wGD9S/RtIVEviNj3o /4iPIFBombkIpkHNnWdhNUmBIpPRngO9Lq1jf8zJckyBNaCiRNzUE5yXjFSIoQvF fc+F7oCFrJkHt6LmWUoDrpKTCZ590qY6+oGy4OPQY5xcWUCeSNtwswomnRkNsZew ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieekgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhlihhp phgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvg gtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhepteelhfeghfevgfffjeefieeu geevffelleegtefgvdehudfhtdehvdethfdvgeeknecuffhomhgrihhnpehprhgrghhmrg htihgtfigvsghsvggtuhhrihhthidrtghomhenucfkphepkedurdduieegrdduvdelrdel heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehphh hilhhiphhpvgesphhrrghgmhgrthhitgifvggsshgvtghurhhithihrdgtohhm
X-ME-Proxy:    
Received: from [192.168.1.10] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 2503E108005F; Mon, 15 Feb 2021 05:26:56 -0500 (EST)
From: Philippe De Ryck 
Message-Id: <2FBBB341-B8FB-4CAA-B1F1-5CC16AB47857@pragmaticwebsecurity.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3064C9BD-7B09-498E-883D-8A8B3257AC07"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 15 Feb 2021 11:26:54 +0100
In-Reply-To: 
Cc: Vittorio Bertocci , oauth@ietf.org
To: Neil Madden 
References: <43B559AA-D888-4E8D-8F82-4226676AC536@pragmaticwebsecurity.com> 
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: 
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2021 10:27:01 -0000

--Apple-Mail=_3064C9BD-7B09-498E-883D-8A8B3257AC07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 15 Feb 2021, at 11:14, Neil Madden  =
wrote:
>=20
>> On 15 Feb 2021, at 08:32, Philippe De Ryck =
 wrote:
>>=20
>> [...]
>>=20
>> Compared to using a worker for handling RTs, I believe the TMI-BFF =
only adds a single security benefit: an attacker is no longer able to =
run a silent flow to obtain a fresh set of tokens (since the client is =
now a confidential client).=20
>=20
> But they can just call the bff-token endpoint to do the same. If there =
is a security advantage, IMO it is as a defence in depth against open =
redirects, unicode normalisation attacks (ie not validating the =
redirect_uri correctly at the AS), etc.=20

A Web Worker and the TMI-BFF both encapsulate the RT and only expose the =
(short-lived) AT.

With the worker-based approach, the client is a public client that =
completes the code exchange without authentication. This allows an =
attacker to run an independent silent flow in an iframe within the =
legitimate application. This flow relies on the existing cookie-based =
session with the AS to obtain an AT and RT, independent of the tokens of =
the client application. A confidential client does not suffer from this =
problem (a stolen code cannot be exchanged without client authN, and =
when done through the BFF, the RT is not exposed).=20

And as you state, there are other benefits as well.

Philipp

=E2=80=94
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/=

--Apple-Mail=_3064C9BD-7B09-498E-883D-8A8B3257AC07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.com> wrote:

On 15 Feb 2021, at =
08:32, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

[...]

Compared to using a worker for handling RTs, I =
believe the TMI-BFF only adds a single security benefit: an attacker is =
no longer able to run a silent flow to obtain a fresh set of tokens =
(since the client is now a confidential =
client). 

But they can just call the bff-token endpoint to do the same. =
If there is a security advantage, IMO it is as a defence in depth =
against open redirects, unicode normalisation attacks (ie not validating =
the redirect_uri correctly at the AS), =
etc. 

A Web Worker and the TMI-BFF both encapsulate the RT and only =
expose the (short-lived) AT.

With the worker-based approach, the =
client is a public client that completes the code exchange without =
authentication. This allows an attacker to run an independent silent =
flow in an iframe within the legitimate application. This flow relies on =
the existing cookie-based session with the AS to obtain an AT and RT, =
independent of the tokens of the client application. A confidential =
client does not suffer from this problem (a stolen code cannot be =
exchanged without client authN, and when done through the BFF, the RT is =
not exposed). 

And as you state, there are other benefits as well.

Philipp

=E2=80=94
Pragmatic Web Security
Security for developers
https://pragmaticwebsecurity.com/
=

--Apple-Mail=_3064C9BD-7B09-498E-883D-8A8B3257AC07--


From nobody Mon Feb 15 02:50:58 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E713A1133 for ; Mon, 15 Feb 2021 02:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrkrv1KIQDzq for ; Mon, 15 Feb 2021 02:50:54 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56E0C3A1137 for ; Mon, 15 Feb 2021 02:50:54 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id x4so8888534wmi.3 for ; Mon, 15 Feb 2021 02:50:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=uzg1Dg+pEpiYyoDgB0gGFEk2ibng8y2luzfIJ5GxG4o=; b=cBLYbR+aNisQosYrLk1bwRoAXxPol2RBEWirk2l4gmiME6WizsBTLRvUW20dN/M1Rv WUtytmg3bOVAc9Dai3kkrF6zYoNRYXRKIkL63/q2jhpg/Zq/K01+MTKP3szrvW3yFey9 B1DN32lBo9pGF6ecclgqOcSKCasjx+iCSJu8A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=uzg1Dg+pEpiYyoDgB0gGFEk2ibng8y2luzfIJ5GxG4o=; b=fFEcq9BrS3Azb+2u0EdhduarDXcOkxAVdtXKv9VA/Cya2ha4oJPkmtcpz7jjljlQhi 2Ok67N/AtCWxk2EYw4UPu6eDNuH0/fU3R3Yk/TO/VG/NHiUjkoDflOy76Mkwu4uw4Gyv C8XgRO0RKWSAnj8Al4gub0DCcqDz8fQI78DHxrI0VGV0lzr/jRWUOJq++DfrJ3qWwLB2 OpSoPyNtQomFu6w5adPUJRq3GvEEe49IyaR35rCCvuRRu7otsT94J+WbyikSbGsjgCOk y1VwxWzM43HTlgmqism/pxqUHpyRRzJUlyqZN0ZbFHVPKynCLpWZXTA4+dNk4K9P87L3 LS1A==
X-Gm-Message-State: AOAM530kkfNTN5bbO6IfZQZVf3FLQw/N0f0+Z1rdWiTift32qQdyIcVQ lznwLAXxxha1dBZ5cCh7WIpVF0aYeQCW+xKB6ZKH8K/bwFEGZv+Ba5e1uSymOthL6xQOqPyz8w= =
X-Google-Smtp-Source: ABdhPJxar/8+ZwRfH4nUdT5ZndT8TvrAqepX4A6ZFTLRBXCZZtoSRi1Sr/i8SuUAhvCtxdxHyf83RA==
X-Received: by 2002:a1c:1dcc:: with SMTP id d195mr14200032wmd.42.1613386252528;  Mon, 15 Feb 2021 02:50:52 -0800 (PST)
Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id j14sm18779049wru.43.2021.02.15.02.50.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Feb 2021 02:50:52 -0800 (PST)
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Feb 2021 10:50:51 +0000
Message-Id: <072DEFFF-134E-4946-9CAD-35EA12DEC802@forgerock.com>
References: <2FBBB341-B8FB-4CAA-B1F1-5CC16AB47857@pragmaticwebsecurity.com>
Cc: Vittorio Bertocci , oauth@ietf.org
In-Reply-To: <2FBBB341-B8FB-4CAA-B1F1-5CC16AB47857@pragmaticwebsecurity.com>
To: Philippe De Ryck 
X-Mailer: iPhone Mail (18C66)
Content-Type: multipart/alternative; boundary=Apple-Mail-27C87F9C-9256-437F-AF8A-37DE54F8B732
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2021 10:50:56 -0000

--Apple-Mail-27C87F9C-9256-437F-AF8A-37DE54F8B732
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



> On 15 Feb 2021, at 10:26, Philippe De Ryck  wrote:
>=20
> =EF=BB=BF
>=20
>>> On 15 Feb 2021, at 11:14, Neil Madden  wrote=
:
>>>=20
>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck  wrote:
>>>>=20
>>> [...]
>>>=20
>>> Compared to using a worker for handling RTs, I believe the TMI-BFF only=
 adds a single security benefit: an attacker is no longer able to run a sil=
ent flow to obtain a fresh set of tokens (since the client is now a confide=
ntial client).=20
>>=20
>> But they can just call the bff-token endpoint to do the same. If there i=
s a security advantage, IMO it is as a defence in depth against open redire=
cts, unicode normalisation attacks (ie not validating the redirect_uri corr=
ectly at the AS), etc.=20
>=20
> A Web Worker and the TMI-BFF both encapsulate the RT and only expose the =
(short-lived) AT.

I don=E2=80=99t think this distinction matters at all from a security point=
 of view. It=E2=80=99s the AT that attackers are after - why bother with a =
RT if I can just call the bff-token endpoint to get a new AT every time?

>=20
> With the worker-based approach, the client is a public client that comple=
tes the code exchange without authentication. This allows an attacker to ru=
n an independent silent flow in an iframe within the legitimate application=
. This flow relies on the existing cookie-based session with the AS to obta=
in an AT and RT, independent of the tokens of the client application. A con=
fidential client does not suffer from this problem (a stolen code cannot be=
 exchanged without client authN, and when done through the BFF, the RT is n=
ot exposed).=20
>=20
> And as you state, there are other benefits as well.
>=20
> Philipp
>=20
> =E2=80=94
> Pragmatic Web Security
> Security for developers
> https://pragmaticwebsecurity.com/

--=20
ForgeRock values your Privacy 

--Apple-Mail-27C87F9C-9256-437F-AF8A-37DE54F8B732
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On 15 Feb 2021, at 10:26, Philippe De Ry=
ck <philippe@pragmaticwebsecurity.com> wrote:

=EF=BB=BF

On=
 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.com> wrote:

On 15 Feb 2021, at 08:32, Philip=
pe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

[...]
Compared to u=
sing a worker for handling RTs, I believe the TMI-BFF only adds a single se=
curity benefit: an attacker is no longer able to run a silent flow to obtai=
n a fresh set of tokens (since the client is now a confidential client).&nb=
sp;

Bu=
t they can just call the bff-token endpoint to do the same. If there is a s=
ecurity advantage, IMO it is as a defence in depth against open redirects, =
unicode normalisation attacks (ie not validating the redirect_uri correctly=
 at the AS), etc. 

=

A Web Worker and the TMI-BFF both encapsulate the RT and on=
ly expose the (short-lived) AT.

I do=
n=E2=80=99t think this distinction matters at all from a security point of =
view. It=E2=80=99s the AT that attackers are after - why bother with a RT i=
f I can just call the bff-token endpoint to get a new AT every time?


With the worker-based approach, the client is a=
 public client that completes the code exchange without authentication. Thi=
s allows an attacker to run an independent silent flow in an iframe within =
the legitimate application. This flow relies on the existing cookie-based s=
ession with the AS to obtain an AT and RT, independent of the tokens of the=
 client application. A confidential client does not suffer from this proble=
m (a stolen code cannot be exchanged without client authN, and when done th=
rough the BFF, the RT is not exposed). 

And as you state, there are other benefits as w=
ell.

Philipp

=E2=80=94
Pragmatic Web Security
Sec=
urity for developers
https://pragmaticwebsecurity.com/



ForgeRock values your Privacy
--Apple-Mail-27C87F9C-9256-437F-AF8A-37DE54F8B732--


From nobody Mon Feb 15 02:54:32 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475913A113B for ; Mon, 15 Feb 2021 02:54:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.188
X-Spam-Level: 
X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXvZc_y5SNwG for ; Mon, 15 Feb 2021 02:54:29 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B52E3A113A for ; Mon, 15 Feb 2021 02:54:25 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id n201so6268381iod.12 for ; Mon, 15 Feb 2021 02:54:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7+X1XX8gVLa91RHry9CTWykogw2qEIJea5e3CLXmA/I=; b=SzIULa2mbsfGp/xjg+HLOirR+PUKt8p74aLTMO9Y8fCuDhrhJkDBSrnfNstN5Q9Kr5 bnsK1JdtEuQNu+OT4fyGhRvGnq9pLxkAjjFhW/+13jUCJWv5mhfu5PqPve83no8ZQiy2 i/guZ+GATwZG9G43EbslTSNL+T0mDVqmrASZTKSRPtfxVUIQJi4nOc+nEHsOStXaqMQm nIO591p4eYvZlwlnq92UGiGSdsgLp8mj8RdE9yfSDWp1dmdT3/cHYfunE/rOuMKL21Mq m+CvNsdKpszjbcQw59NpVEHPCG1zghfEbuhqhY/MhlaBcdomYLGAXRU7AKnMQnL2W88h co6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7+X1XX8gVLa91RHry9CTWykogw2qEIJea5e3CLXmA/I=; b=OEXsbONokFrCCfYp9XMD6VvkQWNofwEdeYBuo0YN0ZiYzTt65eY0t1L6S3vqht6j2p Ehr9Vj9qJFXloS0MiqcZZ54+gq6U87ahzNjtNNA9Yn8FdzLTSe8+ieJhss1ZXfqnVebi 1aM3Hh7m47IxcO145aM4CguZ160vETr7mB6Qkd+UcVMzlsi8G8kKVC385yByctQzWtTu ry+HmrgvlqZJw1s7knglXnDQyDfdyD2tdvRi16/QgxSI7hFXkxj6QYOAoc8ogSw8qPto CPieaOv3eaVGALfY3gpGEKWlXqqUNxd+isUCUhbnu23Rlv668iUvt7oqlsxZ/GfN6DuI iYOQ==
X-Gm-Message-State: AOAM531s5ZntEnevIZ1lY7xByJE+p+HFWUUJ9OrJc9e+/O6uacBB+C+Z x2LhdvMrXlM5D4AFUCFseUMLLZerO/DkFZuw+gDZqz0ntBiHHkI=
X-Google-Smtp-Source: ABdhPJzlQHyqmbEQPS3ALMPCs7h7f5jRmL8WgnPWz9b3ApLyClvxDOfJ6vpWUQAIHm/ZycpJeHvCZIEzCDDxe6s4oZo=
X-Received: by 2002:a02:3541:: with SMTP id y1mr14453584jae.66.1613386464599;  Mon, 15 Feb 2021 02:54:24 -0800 (PST)
MIME-Version: 1.0
References: <2FBBB341-B8FB-4CAA-B1F1-5CC16AB47857@pragmaticwebsecurity.com> <072DEFFF-134E-4946-9CAD-35EA12DEC802@forgerock.com>
In-Reply-To: <072DEFFF-134E-4946-9CAD-35EA12DEC802@forgerock.com>
From: Warren Parad 
Date: Mon, 15 Feb 2021 11:54:13 +0100
Message-ID: 
To: Neil Madden 
Cc: Philippe De Ryck ,  Vittorio Bertocci , oauth 
Content-Type: multipart/alternative; boundary="0000000000001bb73305bb5dcf12"
Archived-At: 
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2021 10:54:31 -0000

--0000000000001bb73305bb5dcf12
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Totally agree.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Mon, Feb 15, 2021 at 11:51 AM Neil Madden 
wrote:

>
>
> On 15 Feb 2021, at 10:26, Philippe De Ryck <
> philippe@pragmaticwebsecurity.com> wrote:
>
> =EF=BB=BF
>
> On 15 Feb 2021, at 11:14, Neil Madden  wrote:
>
> On 15 Feb 2021, at 08:32, Philippe De Ryck <
> philippe@pragmaticwebsecurity.com> wrote:
>
> [...]
>
> *Compared to using a worker for handling RTs, I believe the TMI-BFF only
> adds a single security benefit: an attacker is no longer able to run a
> silent flow to obtain a fresh set of tokens (since the client is now a
> confidential client). *
>
>
> But they can just call the bff-token endpoint to do the same. If there is
> a security advantage, IMO it is as a defence in depth against open
> redirects, unicode normalisation attacks (ie not validating the
> redirect_uri correctly at the AS), etc.
>
>
> A Web Worker and the TMI-BFF both encapsulate the RT and only expose the
> (short-lived) AT.
>
>
> I don=E2=80=99t think this distinction matters at all from a security poi=
nt of
> view. It=E2=80=99s the AT that attackers are after - why bother with a RT=
 if I can
> just call the bff-token endpoint to get a new AT every time?
>
>
> With the worker-based approach, the client is a public client that
> completes the code exchange without authentication. This allows an attack=
er
> to run an independent silent flow in an iframe within the legitimate
> application. This flow relies on the existing cookie-based session with t=
he
> AS to obtain an AT and RT, independent of the tokens of the client
> application. A confidential client does not suffer from this problem (a
> stolen code cannot be exchanged without client authN, and when done throu=
gh
> the BFF, the RT is not exposed).
>
> And as you state, there are other benefits as well.
>
> Philipp
>
> =E2=80=94
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com/
>
>
> ForgeRock values your Privacy 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0000000000001bb73305bb5dcf12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Totally agree.

=

Warren Parad=

Founder, CTO
Secure your user d=
ata with IAM authorization as a service. Implement=C2=A0Authress=
.


On Mon, Feb 15, 2021 at 11:51 AM Neil Madden <neil.madden@forgerock.com> wrote:


On 15 Feb=
 2021, at 10:26, Philippe De Ryck <philippe@pragmaticwebsecurity.com>=
 wrote:

=EF=BB=BF

On 15 Feb 202=
1, at 11:14, Neil Madden <neil.madden@forgerock.com> wrote:

On 15 Feb 2021, a=
t 08:32, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:<=
br>
[...]<=
br>

Compared to using a worker for handling R=
Ts, I believe the TMI-BFF only adds a single security benefit: an attacker =
is no longer able to run a silent flow to obtain a fresh set of tokens (sin=
ce the client is now a confidential client).=C2=A0

But they can just call the bff-token endpoint to do =
the same. If there is a security advantage, IMO it is as a defence in depth=
 against open redirects, unicode normalisation attacks (ie not validating t=
he redirect_uri correctly at the AS), etc.=C2=A0

A Web Worker and the TMI-BFF both encapsulate the RT and=
 only expose the (short-lived) AT.

I=
 don=E2=80=99t think this distinction matters at all from a security point =
of view. It=E2=80=99s the AT that attackers are after - why bother with a R=
T if I can just call the bff-token endpoint to get a new AT every time?


Wi=
th the worker-based approach, the client is a public client that completes =
the code exchange without authentication. This allows an attacker to run an=
 independent silent flow in an iframe within the legitimate application. Th=
is flow relies on the existing cookie-based session with the AS to obtain a=
n AT and RT, independent of the tokens of the client application. A confide=
ntial client does not suffer from this problem (a stolen code cannot be exc=
hanged without client authN, and when done through the BFF, the RT is not e=
xposed).=C2=A0

And as you state, there are other b=
enefits as well.

Philipp

=
=E2=80=94
Pragmatic Web Security
Security for developers
https:=
//pragmaticwebsecurity.com/



ForgeRock values your Privacy__=
_____________________________________________

OAuth mailing list

OAuth@ietf.org

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




--0000000000001bb73305bb5dcf12--


From nobody Mon Feb 15 03:09:47 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489073A1167 for ; Mon, 15 Feb 2021 03:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=gyep3Y3q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wXlrbKVq
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZGj9oD2QDfy for ; Mon, 15 Feb 2021 03:09:44 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9757C3A1166 for ; Mon, 15 Feb 2021 03:09:44 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 177A0307; Mon, 15 Feb 2021 06:09:43 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 15 Feb 2021 06:09:43 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm3; bh=AYpA/BKHgsc0N1/Yyi7bWe2xWiqAo6AvUnsgY90Nqp4=; b=gyep3Y3qo6l5 T5uVU5JITFMD31v4J1rw1+DyO2KPEqRGgFD8OP9ER24IjJShb2viG35SOdXdxbp/ zXsYSyhssBIvrxB2XZulaviX3mKQCHzq8aCC5utCZa7QktVqwY7ljbcn/9Shh4dA JRqglVi4lgUyGI3gr71Pti5uxVfEe8YNUnjvjNhX/wHsuSWUFhRxEG5/yUv4XqF4 Qj20DYOsJwsYD0lAHItA92AtUJLbDxYHta/7WC2VBSJKXp/Nj7ByGEiNEUQT6NRV 7O6n7lp8APlRPdAhU/PnmBiwoMQn0ZpK1gJrXFfxw8wPdNO5cj0NDpvxruNWqKR+ 3KGEDjklAA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AYpA/B KHgsc0N1/Yyi7bWe2xWiqAo6AvUnsgY90Nqp4=; b=wXlrbKVqSjc84gzfDgo7v3 AdgG9XyU4TlF9jrSSSjiIbPtK+VhrpoiQ+Ic76oqEuECDuzO2rz5nKlFB1poj0sQ m3dsph3GFeyIXciEgZ3NtRVhsDEceuCzoikG/KyPpHbMk7VFkkPkQwZHc3wSclKX Huz/52QryUsB7WuuFHaeoo/ErKMsm3z/NuysJhe/e8RwRoYpZKtUK/IwdLDqG45h CHhkGDdme5+xqFiHr+ueckRTrJH+h3lIltLH7de5bKCamdOi9c8Scc4qGLPeWse+ 9NLiMCrGf+wYXO7sskspBFtw3rIsjfa5ZCAKW+kD9jiMDpjAOJs8QCERU5wklqvA ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrieekgddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheprfhhihhlihhp phgvucffvgcutfihtghkuceophhhihhlihhpphgvsehprhgrghhmrghtihgtfigvsghsvg gtuhhrihhthidrtghomheqnecuggftrfgrthhtvghrnhepgeeugeelteeifefhgeffledu gedvudehtdefjeehffdthfettedulefhgefhheejnecuffhomhgrihhnpegurghnihgvlh hfvghtthdruggvnecukfhppeekuddrudeigedruddvledrleehnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpphgvsehprhgrgh hmrghtihgtfigvsghsvggtuhhrihhthidrtghomh
X-ME-Proxy:    
Received: from [192.168.1.23] (d51a4815f.access.telenet.be [81.164.129.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 88BC2240064; Mon, 15 Feb 2021 06:09:41 -0500 (EST)
From: Philippe De Ryck 
Message-Id: <8B710018-3605-483D-B4A8-191A5BBFFEBC@pragmaticwebsecurity.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_861401FD-A88C-4EDF-9995-5BB918AB1EEF"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 15 Feb 2021 12:09:10 +0100
In-Reply-To: <072DEFFF-134E-4946-9CAD-35EA12DEC802@forgerock.com>
Cc: Vittorio Bertocci , oauth@ietf.org
To: Neil Madden 
References: <2FBBB341-B8FB-4CAA-B1F1-5CC16AB47857@pragmaticwebsecurity.com> <072DEFFF-134E-4946-9CAD-35EA12DEC802@forgerock.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: 
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2021 11:09:46 -0000

--Apple-Mail=_861401FD-A88C-4EDF-9995-5BB918AB1EEF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

>=20
> On 15 Feb 2021, at 11:50, Neil Madden  =
wrote:
>=20
>> On 15 Feb 2021, at 10:26, Philippe De Ryck =
 wrote:
>>=20
>>> On 15 Feb 2021, at 11:14, Neil Madden > wrote:
>>>=20
>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck =
> wrote:
>>>>=20
>>>> [...]
>>>>=20
>>>> Compared to using a worker for handling RTs, I believe the TMI-BFF =
only adds a single security benefit: an attacker is no longer able to =
run a silent flow to obtain a fresh set of tokens (since the client is =
now a confidential client).=20
>>>=20
>>> But they can just call the bff-token endpoint to do the same. If =
there is a security advantage, IMO it is as a defence in depth against =
open redirects, unicode normalisation attacks (ie not validating the =
redirect_uri correctly at the AS), etc.=20
>>=20
>> A Web Worker and the TMI-BFF both encapsulate the RT and only expose =
the (short-lived) AT.
>=20
> I don=E2=80=99t think this distinction matters at all from a security =
point of view. It=E2=80=99s the AT that attackers are after - why bother =
with a RT if I can just call the bff-token endpoint to get a new AT =
every time?

Getting an AT from the BFF (or a worker) is an =E2=80=9Conline=E2=80=9D =
attack, which only works as long as the application/malicious code is =
loaded in the browser of the user.=20

Stealing a working refresh token (e.g., with a silent flow) is an =
=E2=80=9Coffline=E2=80=9D attack, which gives long-term access (lifetime =
of the RT), independent of the state of the application in the user=E2=80=99=
s browser.

There is a clear distinction, but whether that matters is a different =
discussion. It depends on how the application used, and how token =
lifetimes are configured. FWIW, the DPoP threat model makes the same =
distinction ("Stolen token (XSS)=E2=80=9D vs =E2=80=9CXSS (Victim is =
online)=E2=80=9D) here: =
https://danielfett.de/2020/05/04/dpop-attacker-model/ =


Philippe
=20


--Apple-Mail=_861401FD-A88C-4EDF-9995-5BB918AB1EEF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On =
15 Feb 2021, at 11:50, Neil Madden <neil.madden@forgerock.com> =
wrote:

On 15 Feb 2021, at =
10:26, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

On 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.com> wrote:

On 15 Feb 2021, at =
08:32, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

[...]

Compared to using a worker for handling RTs, I =
believe the TMI-BFF only adds a single security benefit: an attacker is =
no longer able to run a silent flow to obtain a fresh set of tokens =
(since the client is now a confidential =
client). 

But they can just call the bff-token endpoint to do the same. =
If there is a security advantage, IMO it is as a defence in depth =
against open redirects, unicode normalisation attacks (ie not validating =
the redirect_uri correctly at the AS), =
etc. 

A Web Worker and the TMI-BFF both encapsulate the RT and only =
expose the (short-lived) AT.

I don=E2=80=99t=
 think this distinction matters at all from a security point of view. =
It=E2=80=99s the AT that attackers are after - why bother with a RT if I =
can just call the bff-token endpoint to get a new AT every =
time?

Getting an AT from =
the BFF (or a worker) is an =E2=80=9Conline=E2=80=9D attack, which only =
works as long as the application/malicious code is loaded in the browser =
of the user. 

Stealing a =
working refresh token (e.g., with a silent flow) is an =E2=80=9Coffline=E2=
=80=9D attack, which gives long-term access (lifetime of the RT), =
independent of the state of the application in the user=E2=80=99s =
browser.

There is a clear =
distinction, but whether that matters is a different discussion. It =
depends on how the application used, and how token lifetimes are =
configured. FWIW, the DPoP threat model makes the same distinction =
("Stolen token (XSS)=E2=80=9D vs =E2=80=9CXSS (Victim is online)=E2=80=9D)=
 here: https://danielfett.de/2020/05/04/dpop-attacker-model/
=


Philippe
 

=

--Apple-Mail=_861401FD-A88C-4EDF-9995-5BB918AB1EEF--


From nobody Mon Feb 15 03:15:55 2021
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEE83A117C for ; Mon, 15 Feb 2021 03:15:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level: 
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T45xNFjEYNi8 for ; Mon, 15 Feb 2021 03:15:50 -0800 (PST)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56EA3A117B for ; Mon, 15 Feb 2021 03:15:50 -0800 (PST)
Received: by mail-ej1-x62f.google.com with SMTP id g5so6998678ejt.2 for ; Mon, 15 Feb 2021 03:15:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=YKId1JNopQHqtp+Q1sr3DJtWJWyZ2JC17giu3utL45o=; b=X+LDC4Qhs+FsvWt5rmCUm/UpSnyvzaER5kmpogfIcP7dPv6boDpzo8OB4sfQAZG1Mj Ho9b0V5OSfM8M4kZZr6hHKpNidG8u4O6T1JXPnCQUSGV7+Vw4YSNKfrY3Kvaf2qgG+z/ VZ6RSJn5QgOV7rrVE5XCKRMNHpaW5N+I8YXoo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=YKId1JNopQHqtp+Q1sr3DJtWJWyZ2JC17giu3utL45o=; b=t5AeNWz30WPi5MGKuGDoMsjStJ9pXaqUGquCyFx764npObgZL3hjeQQSZqIQ7YGoyh NOMBDoVDvLvjlh6LQ+VPFt8hDlXLN4zwW/HhgPsLC0xiAHGcfVVGW8Ao5Og38rlRZJCE sV/joSNT0rUuqJ34nA9nx0j7Xc02seLjyt7dcdefKqLW0tNLzHwBA54a52qNs08SmuSY jJdOVe0ggRMnUbYZgDylTyczQ+OJr5V8h4ldbyw7lfyuIef3BIGgnx3HUQp6ukag+yTM GntkLLEo1AHnMUFaFvUKWzuIwILo83NgDpAOSQ6yepqX2r68N6bizDjeWwtZkl6Eaopp JDSA==
X-Gm-Message-State: AOAM532j3wxhqWwaQyIPDa0hG7vU/M74svu/5fXaV8JyqnZt1oRCw4Zp VI6N6aA9AaiqFHR3r8dTlf4KebdZsD3R4XcfO6oqPEeage7ZBmx6QC4Qb0iYh5XPwl6CGFu9/g= =
X-Google-Smtp-Source: ABdhPJydOmWD2e+03YahsgTPuN7VmSNHlBBjW7zvurTOOEvhPTui2WhWn90vDhTsUQ0fmRkXvkMunQ==
X-Received: by 2002:a17:906:e4f:: with SMTP id q15mr14973476eji.216.1613387749012;  Mon, 15 Feb 2021 03:15:49 -0800 (PST)
Received: from [10.0.0.2] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id 35sm9910413edp.85.2021.02.15.03.15.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Feb 2021 03:15:48 -0800 (PST)
From: Neil Madden 
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Feb 2021 11:15:47 +0000
Message-Id: <17812F95-7350-4595-9867-EF9D9452CC07@forgerock.com>
References: <8B710018-3605-483D-B4A8-191A5BBFFEBC@pragmaticwebsecurity.com>
Cc: Vittorio Bertocci , oauth@ietf.org
In-Reply-To: <8B710018-3605-483D-B4A8-191A5BBFFEBC@pragmaticwebsecurity.com>
To: Philippe De Ryck 
X-Mailer: iPhone Mail (18C66)
Content-Type: multipart/alternative; boundary=Apple-Mail-1812512E-1133-4B1D-9DB6-3694DF6716E5
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Feb 2021 11:15:53 -0000

--Apple-Mail-1812512E-1133-4B1D-9DB6-3694DF6716E5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, I=E2=80=99ve argued against this distinction for DPoP too. Since the f=
irst days of HttpOnly attackers learnt to proxy requests through the browse=
r (as you know of course). This is not only to bypass the restrictions but =
it=E2=80=99s also just much better for the attacker because it hides their =
traffic and origin. People are online all the time now, so this is at best =
a mild inconvenience.=20

=E2=80=94 Neil

> On 15 Feb 2021, at 11:09, Philippe De Ryck  wrote:
>=20
> =EF=BB=BF
>>=20
>>> On 15 Feb 2021, at 11:50, Neil Madden  wrote=
:
>>>=20
>>>> On 15 Feb 2021, at 10:26, Philippe De Ryck  wrote:
>>>=20
>>>>> On 15 Feb 2021, at 11:14, Neil Madden  wro=
te:
>>>>>=20
>>>>>> On 15 Feb 2021, at 08:32, Philippe De Ryck  wrote:
>>>>>>=20
>>>>> [...]
>>>>>=20
>>>>> Compared to using a worker for handling RTs, I believe the TMI-BFF on=
ly adds a single security benefit: an attacker is no longer able to run a s=
ilent flow to obtain a fresh set of tokens (since the client is now a confi=
dential client).=20
>>>>=20
>>>> But they can just call the bff-token endpoint to do the same. If there=
 is a security advantage, IMO it is as a defence in depth against open redi=
rects, unicode normalisation attacks (ie not validating the redirect_uri co=
rrectly at the AS), etc.=20
>>>=20
>>> A Web Worker and the TMI-BFF both encapsulate the RT and only expose th=
e (short-lived) AT.
>>=20
>> I don=E2=80=99t think this distinction matters at all from a security po=
int of view. It=E2=80=99s the AT that attackers are after - why bother with=
 a RT if I can just call the bff-token endpoint to get a new AT every time?
>=20
> Getting an AT from the BFF (or a worker) is an =E2=80=9Conline=E2=80=9D a=
ttack, which only works as long as the application/malicious code is loaded=
 in the browser of the user.=20
>=20
> Stealing a working refresh token (e.g., with a silent flow) is an =E2=80=
=9Coffline=E2=80=9D attack, which gives long-term access (lifetime of the R=
T), independent of the state of the application in the user=E2=80=99s brows=
er.
>=20
> There is a clear distinction, but whether that matters is a different dis=
cussion. It depends on how the application used, and how token lifetimes ar=
e configured. FWIW, the DPoP threat model makes the same distinction ("Stol=
en token (XSS)=E2=80=9D vs =E2=80=9CXSS (Victim is online)=E2=80=9D) here: =
https://danielfett.de/2020/05/04/dpop-attacker-model/
>=20
> Philippe
> =20
>=20

--=20
ForgeRock values your Privacy 

--Apple-Mail-1812512E-1133-4B1D-9DB6-3694DF6716E5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, I=E2=80=99ve argu=
ed against this distinction for DPoP too. Since the first days of HttpOnly =
attackers learnt to proxy requests through the browser (as you know of cour=
se). This is not only to bypass the restrictions but it=E2=80=99s also just=
 much better for the attacker because it hides their traffic and origin. Pe=
ople are online all the time now, so this is at best a mild inconvenience.&=
nbsp;

=E2=80=94 Neil
=


On 15 Feb 2021, at 11:09, Ph=
ilippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

=EF=BB=BF

On 15 Feb 2021, at 11:50, Ne=
il Madden <neil.=
madden@forgerock.com> wrote:

On 15 Feb 2021, at 10:26, Philippe D=
e Ryck <=
philippe@pragmaticwebsecurity.com> wrote:

On 15 Feb 2021, at 11:14, Neil Madden <neil.madden@forgerock.com> wrote:<=
/div>

On 15 Feb 2021, at 0=
8:32, Philippe De Ryck <philippe@pragmaticwebsecurity.com> wrote:

[...]

Com=
pared to using a worker for handling RTs, I believe the TMI-BFF only adds a=
 single security benefit: an attacker is no longer able to run a silent flo=
w to obtain a fresh set of tokens (since the client is now a confidential c=
lient). 

But they can just call the bff-token endpoint to do the same. If th=
ere is a security advantage, IMO it is as a defence in depth against open r=
edirects, unicode normalisation attacks (ie not validating the redirect_uri=
 correctly at the AS), etc. 

A Web Worker and the TMI-BFF both encapsulate the=
 RT and only expose the (short-lived) AT.

I don=E2=80=99t =
think this distinction matters at all from a security point of view. It=E2=
=80=99s the AT that attackers are after - why bother with a RT if I can jus=
t call the bff-token endpoint to get a new AT every time?
Getting an AT from the BFF (or a worker) is an =
=E2=80=9Conline=E2=80=9D attack, which only works as long as the applicatio=
n/malicious code is loaded in the browser of the user. 

Stealing a working refresh token (e.g., with a silent=
 flow) is an =E2=80=9Coffline=E2=80=9D attack, which gives long-term access=
 (lifetime of the RT), independent of the state of the application in the u=
ser=E2=80=99s browser.

There is a clear=
 distinction, but whether that matters is a different discussion. It depend=
s on how the application used, and how token lifetimes are configured. FWIW=
, the DPoP threat model makes the same distinction ("Stolen token (XSS)=E2=
=80=9D vs =E2=80=9CXSS (Victim is online)=E2=80=9D) here: https://danielf=
ett.de/2020/05/04/dpop-attacker-model/

<=
div>Philippe