From nobody Mon Mar 2 11:42:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599C3A0FE3 for ; Mon, 2 Mar 2020 11:42:14 -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, 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 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 QKMTEblnc6yj for ; Mon, 2 Mar 2020 11:42:11 -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 84B943A0FE8 for ; Mon, 2 Mar 2020 11:42:10 -0800 (PST) Received: from [192.168.1.5] (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 022Jg5XI027936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 2 Mar 2020 14:42:05 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 2 Mar 2020 14:42:05 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" To: Dick Hardt References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 19:42:15 -0000 --Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Working with that kind of setup, where you=E2=80=99ve got two different = users at the client and the AS, is the driving goal behind CIBA and UMA, = and in some instances, the device flow. All of these have a polling = mechanism that allows an asynchronous update. In XYZ, the client explicitly signals this kind of expectation by not = sending a =E2=80=9Ccallback=E2=80=9D field in its request, indicating = that it doesn=E2=80=99t expect the approving user to get returned = through the front channel. It=E2=80=99s not just about signaling the = client about when to poll next, it=E2=80=99s about signaling the intent = to poll at all. It=E2=80=99s a different security profile that both the AS and the = Client need to know about, since it might not be appropriate for all = different forms of access.=20 XYZ (and to some extent XAuth) also allows the client to present = information about the current user at the client so that the AS can = figure out if it expects the same user or a different user during the = interactive bits by allowing things to be passed in the =E2=80=9Cuser=E2=80= =9D object of the request. It=E2=80=99s not just there as a login hint, = at least in XYZ. There are some details from UMA and CIBA that we can = import, like the user-displayed confirmation codes and the like, that = can help security and usability of the overall protocol. But as is the = case with just about everything in XYZ, I didn=E2=80=99t want to add it = to the spec document until I=E2=80=99d implemented it to make sure that = it made sense to carry that information through to the different = parties. =E2=80=94 Justin > On Feb 28, 2020, at 5:56 PM, Dick Hardt wrote: >=20 > Thinking about this, the fixation attack is against the Client where = the attacker is at the Client, and the victim is at the AS. >=20 > Does the AS need to know the attacker and victim are different? IE, if = the client knows that the User at the Client is the same as the User = that came from the AS, have we prevented the attack? > =E1=90=A7 >=20 > On Tue, Feb 25, 2020 at 7:38 AM Justin Richer > wrote: > That=E2=80=99s good enough for the AS, but is it good enough for the = client? The hash allows the client to make sure that the reference = they=E2=80=99re getting back in the front channel is related to = something they sent out in the first place. We originally had a = =E2=80=9Cstate=E2=80=9D parameter like OAuth 2 for this purpose, but = realized that since the client can push its callback URI we didn=E2=80=99t= need that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80= =9D and =E2=80=9Cc_hash=E2=80=9D have in OIDC, we added this simple hash = parameter that the client can check before it calls the TX endpoint = again. >=20 > =E2=80=94 Justin >=20 >> On Feb 21, 2020, at 8:12 PM, Dick Hardt > wrote: >>=20 >>=20 >> The Client presents the interact_ref to the AS with the transaction = handle. The AS will be able to tell the Client if the interact_ref = belongs to the transaction. >>=20 >> Why is that enough? >> =E1=90=A7 >>=20 >> On Fri, Feb 21, 2020 at 1:51 PM Justin Richer > wrote: >> The hash offers the same kinds of protections to the client that the = OIDC nonce does =E2=80=94 it binds the front channel return to something = you get from the back channel.=20 >>=20 >> In other words, the client can be sure that the return value that = it=E2=80=99s getting is related to the request it made in the first = place, and not another one. Clients using per-request redirect URIs can = also help with this, but this is something that the server can provide = directly. >>=20 >> =E2=80=94 Justin >>=20 >>> On Feb 21, 2020, at 4:14 PM, Dick Hardt > wrote: >>>=20 >>> While I can see the value of the interact_ref (aka interaction_ref) = in the return URI that allows the Client to ensure the user that started = the transaction is the same one that interacted at the AS, I don't = understand why a hash is required. Would you elaborate? >>> =E1=90=A7 >>>=20 >>> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer > wrote: >>> But that=E2=80=99s exactly the point =E2=80=94 it helps in that = case, which is a very common case. For cases where the client doesn=E2=80=99= t expect the user to come back on the same channel, then they don=E2=80=99= t use the callback mechanism. They might use the =E2=80=9Cfinish = message=E2=80=9D URL that Annabelle mentioned in the other thread, or = they might just print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at = the AS, which is common today. >>>=20 >>> XYZ=E2=80=99s interaction structure allows the composition of these = things, under the control of the client. This is exactly why it=E2=80=99s = important to be able to specify how to get to the AS and how to get back = as separate items, so that the client can compose the combination that = makes the most sense for that client. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>> On Feb 21, 2020, at 3:52 PM, Dick Hardt > wrote: >>>>=20 >>>> I got ahead of myself. A completion URI protects the User only if = the User is sent back to the same channel the transaction started so the = Client can confirm it is the same User that started the transaction. >>>>=20 >>>> so this does not help the security: >>>>=20 >>>> "Being able to provide a completion URI even if the user is = starting on a device is a great insight on how to address the threat = above." >>>>=20 >>>> =E1=90=A7 >>>>=20 >>>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt > wrote: >>>> The lightbulb finally clicked on for me. Thanks for your patience. >>>>=20 >>>> The threat you are describing is where the attacker starts a = transaction at the client, and gets the victim to complete it. Correct? >>>>=20 >>>> I still think the Client should be able to signal if it will be = doing a redirect vs showing a QR code (or wants to do both). >>>>=20 >>>> Being able to provide a completion URI even if the user is starting = on a device is a great insight on how to address the threat above.=20 >>>>=20 >>>> I'm going to ponder how to align XAuth more with these features of = XYZ. >>>> =E1=90=A7 >>>>=20 >>>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer > wrote: >>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer > wrote: >>>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we = realized that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we have: >>>>>=20 >>>>> This sentence looks to be missing something. >>>>=20 >>>> Apologies: We realized they both used AS-composed URLs to get the = user to the AS in a web browser for interaction purposes. >>>>=20 >>>>> =20 >>>>>=20 >>>>> - redirect: tells the AS that the client can send the user to an = arbitrary URL (and the AS doesn=E2=80=99t care how the client gets that = info to the user; could be a redirect or an image or send a push = notification to a secondary device, we don=E2=80=99t care as long as the = user shows up in a browser at the AS =E2=80=94 so maybe this field can = be renamed to be more universally accurate) >>>>>=20 >>>>> As stated in this thread, it may be useful for the AS to know if = the URL will be in a QR code, or in a full redirect. >>>>>=20 >>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a = Client has to do, so it needs to know the difference between a popup, = and a full browser redirect. This is targetted at SPAs, where an = additional URL to redirect to is extra work. >>>>> =20 >>>>> - code: tells the AS that the client can present a short code the = user can type (along with a static URL the user can get to, maybe by = typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like the = redirect method) >>>>> - callback: tells the AS that the client can receive the = completion message from a front channel interaction through a redirect. = Note that the client might have gotten to the AS through a redirect = on-device, through a QR-code off device, or through some other magic, = and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s = only concerned with how to get the user :back:. >>>>>=20 >>>>> In a full redirect, the Client wants the AS to send the user back = so that it can continue. >>>>>=20 >>>>> The only parameter in the completion message is the nonce, which = seems superfluous. See below. >>>>> =20 >>>>>=20 >>>>> These three can be combined in different ways depending on what = you want to do at the client. Let=E2=80=99s say you=E2=80=99re doing and = OAuth2 style authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a = plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99= re doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80= =9D to get the long URL. If you=E2=80=99re doing a user code and a QR = code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D= to get the long URL and the short code not he screen at the same time.=20= >>>>>=20 >>>>> On top of that, they can be combined with other methods. Maybe I = can send the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most sense. >>>>>=20 >>>>> Per my question later in this thread, why would the Client not = know what interaction it wants prior to the request? >>>>=20 >>>> What do you mean? The client does know what it wants and that=E2=80=99= s why it=E2=80=99s asking for what it wants. We=E2=80=99re debating = different methods for the client to ask for what it wants. This question = does not make sense to me. >>>>=20 >>>>>=20 >>>>> If the AS is doing CIBA, that is not a decision just for the = Client. Both the AS and the Client need to know they are doing CIBA. = (FWIW: I think this work supersedes CIBA) >>>>=20 >>>> As I=E2=80=99ve stated previously, I believe the interaction = methods here can supersede CIBA. >>>>=20 >>>>>=20 >>>>> Additionally, different interactions have different risk profiles. = Sophisticated ASes will use that signal in the risk assessment, and may = do ask for additional authentication or verification. >>>>> =20 >>>>=20 >>>> Yes, exactly my point. Because different interactions have = different risks, the AS will need to be able to decide which = interactions it=E2=80=99s OK with for a given request. This could vary = based on what=E2=80=99s being requested, or who=E2=80=99s doing the = requesting. >>>>=20 >>>>>=20 >>>>> An interesting difference between XYZ and XAuth=E2=80=99s = approaches is that XYZ keeps the concept of the =E2=80=9Cauthorization = code=E2=80=9D in the callback response (which in turn is based on the = OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an = =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of = nonces generated by the client and the AS in the back channel. This = binds the front channel response to both the back channel request and = the back channel response for a given transaction =E2=80=94 and note = that I=E2=80=99m really open to having a better way to generate and = calculate such a binding, but I think this works. In any event, this = protects the client from session fixation and injection on the return = from the front channel that it=E2=80=99s susceptible to in a pure = polling model, and the hashing approach basically combines the security = parameters of the OAuth 2 authorization code and (to an extent) state, = PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in one element. = This is only applicable if you=E2=80=99re coming back to the client and = you can validate the hash and present the reference parameter. If = you=E2=80=99re doing just plain polling, you don=E2=80=99t have that = protection =E2=80=94 but the client and the AS are aware of that risk, = and there=E2=80=99s an option to prevent it. >>>>>=20 >>>>> XAuth has removed the authorization code concept in its redirect = return, and clients only do polling against the GS API in order to get = tokens. While I obviously think it=E2=80=99s very valuable to remove = things from the front channel, I don=E2=80=99t think this is something = we can remove without opening up attack surfaces that have already been = identified in previous protocols. I would like to understand why XAuth = is not susceptible to the same kinds of attacks, or if it is, what = mitigations there are for them.=20 >>>>>=20 >>>>> Unlike OAuth 2.0, there are no parameters in the front channel = response to the Client. The redirect back to the Client is only needed = to return the interaction back to the Client. >>>>=20 >>>> This argument rings tautologically hollow =E2=80=94 there are no = parameters because you=E2=80=99ve defined that there aren=E2=80=99t any = in XAuth. XYZ does have parameters, to tie the front and back channel = requests together when doing redirect back and forth. >>>>=20 >>>> If you=E2=80=99re not doing a redirect back (ie, not sending a = =E2=80=9Ccallback=E2=80=9D interaction block), then it=E2=80=99s a = polling mechanism like XAuth, the device flow, etc. There are very real = risks to this. >>>>=20 >>>>>=20 >>>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth = 1.0) >>>>>=20 >>>>> In OAuth, the AS gives a code to the User to give to the Client = that the Client then gives to the GS. >>>>>=20 >>>>> In XAuth, the AS gives a "code" to the Client that givers it to = the User to give to the GS. >>>>>=20 >>>>> In XAuth, the "code" is either a user code, or something embedded = in the URI the User is redirected to. >>>>>=20 >>>>> Therefore, there is nothing to protect in the redirect back to the = Client. >>>>>=20 >>>>> If I'm missing an attack, please elaborate how it would happen. >>>>=20 >>>> One form of impersonation is well documented: = https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa7592= 50a0e7 = >>>>=20 >>>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar = request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, = etc, and it=E2=80=99s susceptible to the same kind of issue. >>>>=20 >>>>> =20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle = > wrote: >>>>>>=20 >>>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my = comments here to interaction mode design, setting aside whether or not = we need =E2=80=9Cpopup=E2=80=9D. :D >>>>>> =20 >>>>>> Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for =E2=80=9D? >>>>>> =20 >>>>>> Even if we consider things like QR code data capacity, that=E2=80=99= s really just a URI length limitation, which could apply to non-QR = interaction modes, e.g., if the Client device wants to communicate the = URI over an extremely bandwidth-constrained channel. And it=E2=80=99s = not clear to me how including a URI length limitation in the request = helps. If a GS is capable of generating a shorter URI, why wouldn=E2=80=99= t it always return that? On the client side, it can look at the length = of the URI provided and decide what to do with it (e.g., render a QR = code or display it or do nothing with it). >>>>>> =20 >>>>>> So that really leaves us with two interaction modes that we need: >>>>>> =E2=80=9Curi=E2=80=9D, which returns a full URI that may not be = human friendly; and >>>>>> =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a code = entry page, both of which are human-friendly. >>>>>> =20 >>>>>> Those could be combinable to get both, and even if we don=E2=80=99t= go down the multiple interaction mode route we could add the full URI = to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so. >>>>>> =20 >>>>>> =E2=80=93 >>>>>> Annabelle Backman (she/her) >>>>>> AWS Identity >>>>>> https://aws.amazon.com/identity/ = >>>>>> =20 >>>>>> =20 >>>>>> From: Txauth > on behalf of Dick Hardt = > >>>>>> Date: Tuesday, February 18, 2020 at 6:04 PM >>>>>> To: "txauth@ietf.org " > >>>>>> Subject: [Txauth] Fwd: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>>>>> =20 >>>>>> Added in user code interaction and aligned QR code to be a = superset of user code. >>>>>> Fixed descriptions. >>>>>> =20 >>>>>>=20 >>>>>> ---------- Forwarded message --------- >>>>>> From: > >>>>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>>>> Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt >>>>>> To: Dick Hardt > >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>>>> has been successfully submitted by Dick Hardt and posted to the >>>>>> IETF repository. >>>>>>=20 >>>>>> Name: draft-hardt-xauth-protocol >>>>>> Revision: 03 >>>>>> Title: The XAuth Protocol >>>>>> Document date: 2020-02-18 >>>>>> Group: Individual Submission >>>>>> Pages: 53 >>>>>> URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt = >>>>>> Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = >>>>>> Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 = >>>>>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = >>>>>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 = >>>>>>=20 >>>>>> Abstract: >>>>>> Client software often desires resources or identity claims = that are >>>>>> independent of the client. This protocol allows a user and/or >>>>>> resource owner to delegate resource authorization and/or = release of >>>>>> identity claims to a server. Client software can then request = access >>>>>> to resources and/or identity claims by calling the server. = The >>>>>> server acquires consent and authorization from the user and/or >>>>>> resource owner if required, and then returns to the client = software >>>>>> the authorization and identity claims that were approved. = This >>>>>> protocol can be extended to support alternative = authorizations, >>>>>> claims, interactions, and client authentication mechanisms. >>>>>>=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 >>>>>> =E1=90=A7 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Working with that kind of setup, where you=E2=80=99ve got two = different users at the client and the AS, is the driving goal behind = CIBA and UMA, and in some instances, the device flow. All of these have = a polling mechanism that allows an asynchronous update.
In XYZ, the client explicitly signals = this kind of expectation by not sending a =E2=80=9Ccallback=E2=80=9D = field in its request, indicating that it doesn=E2=80=99t expect the = approving user to get returned through the front channel. It=E2=80=99s = not just about signaling the client about when to poll next, it=E2=80=99s = about signaling the intent to poll at all.

It=E2=80=99s a different security = profile that both the AS and the Client need to know about, since it = might not be appropriate for all different forms of = access. 

XYZ (and to some extent XAuth) also allows the client to = present information about the current user at the client so that the AS = can figure out if it expects the same user or a different user during = the interactive bits by allowing things to be passed in the =E2=80=9Cuser=E2= =80=9D object of the request. It=E2=80=99s not just there as a login = hint, at least in XYZ. There are some details from UMA and CIBA that we = can import, like the user-displayed confirmation codes and the like, = that can help security and usability of the overall protocol. But as is = the case with just about everything in XYZ, I didn=E2=80=99t want to add = it to the spec document until I=E2=80=99d implemented it to make sure = that it made sense to carry that information through to the different = parties.

 =E2=80=94 Justin

On Feb = 28, 2020, at 5:56 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Thinking about this, the fixation = attack is against the Client where the attacker is at the Client, and = the victim is at the AS.

Does the AS need to know the attacker and victim are = different? IE, if the client knows that the User at the Client is the = same as the User that came from the AS, have we prevented the = attack?
3D""=E1=90=A7

On Tue, Feb = 25, 2020 at 7:38 AM Justin Richer <jricher@mit.edu> wrote:
That=E2=80=99s good enough for the AS, but is it = good enough for the client? The hash allows the client to make sure that = the reference they=E2=80=99re getting back in the front channel is = related to something they sent out in the first place. We originally had = a =E2=80=9Cstate=E2=80=9D parameter like OAuth 2 for this purpose, but = realized that since the client can push its callback URI we didn=E2=80=99t= need that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80= =9D and =E2=80=9Cc_hash=E2=80=9D have in OIDC, we added this simple hash = parameter that the client can check before it calls the TX endpoint = again.

 =E2=80=94= Justin

On Feb 21, 2020, at 8:12 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:


The Client presents the interact_ref to = the AS with the transaction handle. The AS will be able to tell the = Client if the interact_ref belongs to the transaction.

Why is that = enough?
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
The hash offers the = same kinds of protections to the client that the OIDC nonce does =E2=80=94= it binds the front channel return to something you get from the back = channel. 

In = other words, the client can be sure that the return value that it=E2=80=99= s getting is related to the request it made in the first place, and not = another one. Clients using per-request redirect URIs can also help with = this, but this is something that the server can provide = directly.

 =E2=80=94 Justin

On Feb = 21, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

While I can see the value of the = interact_ref (aka interaction_ref) in the return URI that allows the = Client to ensure the user that started the transaction is the same one = that interacted at the AS, I don't understand why a hash is required. = Would you elaborate?
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
But that=E2=80=99s = exactly the point =E2=80=94 it helps in that case, which is a very = common case. For cases where the client doesn=E2=80=99t expect the user = to come back on the same channel, then they don=E2=80=99t use the = callback mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D = URL that Annabelle mentioned in the other thread, or they might just = print out =E2=80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is = common today.

XYZ=E2=80= =99s interaction structure allows the composition of these things, under = the control of the client. This is exactly why it=E2=80=99s important to = be able to specify how to get to the AS and how to get back as separate = items, so that the client can compose the combination that makes the = most sense for that client.

 =E2=80=94 Justin


On Feb 21, 2020, at 3:52 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

I got ahead of myself. A = completion URI protects the User only if the User is sent back to the = same channel the transaction started so the Client can confirm it is the = same User that started the transaction.

so this does not help the = security:

"Being= able to provide a completion URI even if the user is starting on a = device is a great insight on how to address the threat above."

3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The = lightbulb finally clicked on for me. Thanks for your patience.

The threat you are = describing is where the attacker starts a transaction at the client, and = gets the victim to complete it. Correct?
I still think the Client should be = able to signal if it will be doing a redirect vs showing a QR code (or = wants to do both).

Being able to provide a completion URI even if the user is = starting on a device is a great insight on how to address the threat = above. 

I'm going to ponder how to align XAuth more with these = features of XYZ.
3D""=E1=90=A7

On Fri, Feb = 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at = 1:54 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Fri, Feb = 21, 2020 at 8:38 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m in = complete agreement with Annabelle. In XYZ we realized = that both the QR Code and Authorization Code, and that the only = difference is how the user gets back to the client. So instead of = inventing a new type of interaction, we split them. In XYZ, we = have:

This= sentence looks to be missing = something.

Apologies: We realized they both used = AS-composed URLs to get the user to the AS in a web browser for = interaction purposes.

 

 - redirect: tells = the AS that the client can send the user to an arbitrary URL (and the AS = doesn=E2=80=99t care how the client gets that info to the user; could be = a redirect or an image or send a push notification to a secondary = device, we don=E2=80=99t care as long as the user shows up in a browser = at the AS =E2=80=94 so maybe this field can be renamed to be more = universally accurate)

As stated in this thread, it may be = useful for the AS to know if the URL will be in a QR code, or in a full = redirect.

In = XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has = to do, so it needs to know the difference between a popup, and a full = browser redirect. This is targetted at SPAs, where an additional URL to = redirect to is extra work.
 
 - code: tells the AS that the client can present a = short code the user can type (along with a static URL the user can get = to, maybe by typing the URL manually, but it=E2=80=99s not = dynamic/arbitrary like the redirect method)
 - callback: tells the AS that the client can receive = the completion message from a front channel interaction through a = redirect. Note that the client might have gotten to the AS through a = redirect on-device, through a QR-code off device, or through some other = magic, and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80= =99s only concerned with how to get the user = :back:.

In a full redirect, the Client wants = the AS to send the user back so that it can continue.

The only parameter in = the completion message is the nonce, which seems superfluous. See = below.
 

These three can be = combined in different ways depending on what you want to do at the = client. Let=E2=80=99s say you=E2=80=99re doing and OAuth2 style = authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re doing a plain = user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. If you=E2=80=99re = doing just a QR code with polling, you use just =E2=80=9Credirect=E2=80=9D= to get the long URL. If you=E2=80=99re doing a user code and a QR code = together, you use =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccode=E2=80=9D = to get the long URL and the short code not he screen at the same = time. 

On = top of that, they can be combined with other methods. Maybe I can send = the user to an arbitrary URL but also display a human-readable = verification code (like CIBA), or send something in a push notification = but also give them a message to type, or I=E2=80=99m getting claims from = an agent but I want them redirected back through the browser. The client = gets to decide what kinds of interaction it can do and how to use these = pieces in ways that make the most = sense.

Per my question later in this thread, = why would the Client not know what interaction it wants prior to the = request?

What do you mean? The client does know = what it wants and that=E2=80=99s why it=E2=80=99s asking for what it = wants. We=E2=80=99re debating different methods for the client to ask = for what it wants. This question does not make sense to me.


If the AS is doing CIBA, that is not a = decision just for the Client. Both the AS and the Client need to know = they are doing CIBA. (FWIW: I think this work supersedes = CIBA)

As I=E2=80=99ve stated previously, I = believe the interaction methods here can supersede CIBA.


Additionally, different interactions = have different risk profiles. Sophisticated ASes will use that signal in = the risk assessment, and may do ask for additional authentication or = verification.
 

Yes, exactly my point. Because = different interactions have different risks, the AS will need to be able = to decide which interactions it=E2=80=99s OK with for a given request. = This could vary based on what=E2=80=99s being requested, or who=E2=80=99s = doing the requesting.


An interesting = difference between XYZ and XAuth=E2=80=99s approaches is that XYZ keeps = the concept of the =E2=80=9Cauthorization code=E2=80=9D in the callback = response (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2= =80=9D field). In XYZ, you get an =E2=80=9Cinteraction_ref=E2=80=9D = which is hashed along with a pair of nonces generated by the client and = the AS in the back channel. This binds the front channel response to = both the back channel request and the back channel response for a given = transaction =E2=80=94 and note that I=E2=80=99m really open to having a = better way to generate and calculate such a binding, but I think this = works. In any event, this protects the client from session fixation and = injection on the return from the front channel that it=E2=80=99s = susceptible to in a pure polling model, and the hashing approach = basically combines the security parameters of the OAuth 2 authorization = code and (to an extent) state, PKCE=E2=80=99s code_challenge, and = OIDC=E2=80=99s nonce in one element. This is only applicable if you=E2=80=99= re coming back to the client and you can validate the hash and present = the reference parameter. If you=E2=80=99re doing just plain polling, you = don=E2=80=99t have that protection =E2=80=94 but the client and the AS = are aware of that risk, and there=E2=80=99s an option to prevent = it.

XAuth has = removed the authorization code concept in its redirect return, and = clients only do polling against the GS API in order to get tokens. While = I obviously think it=E2=80=99s very valuable to remove things from the = front channel, I don=E2=80=99t think this is something we can remove = without opening up attack surfaces that have already been identified in = previous protocols. I would like to understand why XAuth is not = susceptible to the same kinds of attacks, or if it is, what mitigations = there are for them. 

Unlike OAuth 2.0, there = are no parameters in the front channel response to the Client. The = redirect back to the Client is only needed to return the interaction = back to the Client.

This argument rings = tautologically hollow =E2=80=94 there are no parameters because you=E2=80=99= ve defined that there aren=E2=80=99t any in XAuth. XYZ does have = parameters, to tie the front and back channel requests together when = doing redirect back and forth.

If you=E2=80=99re not doing a redirect = back (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), = then it=E2=80=99s a polling mechanism like XAuth, the device flow, etc. = There are very real risks to this.


XAuth (and XYZ) have a different flow than OAuth 2.0 (or = OAuth 1.0)

In = OAuth, the AS gives a code to the User to give to the Client that the = Client then gives to the GS.

In XAuth, the AS gives a "code" to the = Client that givers it to the User to give to the GS.

In XAuth, the "code" is = either a user code, or something embedded in the URI the User is = redirected to.

Therefore, there is nothing to protect in the redirect back = to the Client.

If I'm missing an attack, please elaborate how it would = happen.

One form of impersonation is well = documented: https://hueniverse.com/explaining-the-oauth-session-fixation-at= tack-aa759250a0e7

OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a = similar request initiation step to what we see in XYZ, XAuth, PAR, = FAPI/OBUK, etc, and it=E2=80=99s susceptible to the same kind of = issue.

 

 =E2=80=94 = Justin

On Feb 20, 2020, at 3:21 PM, = Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc.ietf.org> = wrote:

Thanks = for the update, Dick! I=E2=80=99m going to confine my comments here to = interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D
 
Once the GS hands that URI back to the Client, it has zero = control over how the Client uses it. The Client could present any URI = (of a reasonable size) into a QR code, or present it as a clickable = link, or redirect to it, or open it in an external browser, or do any = number of other as-yet-not-invented things with it. Moreover, the Client = may not know yet what it wants to do with it. So what value is there in = distinguishing between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. = =E2=80=9CI want a URI for a QR code=E2=80=9D vs. =E2=80=9CI want a URI = for <some other machine-driven interaction mode>=E2=80=9D?
 
Even if we consider things like QR code data capacity, = that=E2=80=99s really just a URI length limitation, which could apply to = non-QR interaction modes, e.g., if the Client device wants to = communicate the URI over an extremely bandwidth-constrained channel. And = it=E2=80=99s not clear to me how including a URI length limitation in = the request helps. If a GS is capable of generating a shorter URI, why = wouldn=E2=80=99t it always return that? On the client side, it can look = at the length of the URI provided and decide what to do with it (e.g., = render a QR code or display it or do nothing with it).
 
So = that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not = be human friendly; and
  • =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a = code entry page, both of which are human-friendly.
 
Those could be combinable to get both, and even if we don=E2=80= =99t go down the multiple interaction mode route we could add the full = URI to the =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t = hurt anything to do so.
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, February 18, = 2020 at 6:04 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Subject: [Txauth] Fwd: New = Version Notification for draft-hardt-xauth-protocol-03.txt
 
Added in = user code interaction and aligned QR code to be a superset of user = code.
Fixed = descriptions.

 

----------= Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Tue, Feb = 18, 2020 at 6:00 PM
Subject: New Version Notification for = draft-hardt-xauth-protocol-03.txt
To: Dick Hardt <dick.hardt@gmail.com>




A new version of I-D, = draft-hardt-xauth-protocol-03.txt
has been successfully = submitted by Dick Hardt and posted to the
IETF = repository.

Name:      =      draft-hardt-xauth-protocol
Revision:       03
Title:          The XAuth = Protocol
Document date:  2020-02-18
Group:          Individual = Submission
Pages:          53
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -03.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 03

Abstract:
  =  Client software often desires resources or identity claims that = are
   independent of the client.  This = protocol allows a user and/or
   resource owner = to delegate resource authorization and/or release of
  =  identity claims to a server.  Client software can then = request access
   to resources and/or identity = claims by calling the server.  The
  =  server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to = the client software
   the authorization and = identity claims that were approved.  This
  =  protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication = mechanisms.



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

=E1=90=A7
-- 
Txauth mailing = list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth






= --Apple-Mail=_59960BDB-E080-4FAE-859E-D2ED11C405A1-- From nobody Fri Mar 6 08:45:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D223A0AA5 for ; Fri, 6 Mar 2020 08:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 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, MALFORMED_FREEMAIL=1.663, MIME_QP_LONG_LINE=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 vf4CqYVn9ATL for ; Fri, 6 Mar 2020 08:44:58 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450: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 DE3CF3A0AA8 for ; Fri, 6 Mar 2020 08:44:57 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id v11so3122982wrm.9 for ; Fri, 06 Mar 2020 08:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=g/67VyLeYMvCEKDi9DZKyIWP7WrPYcON2j+ukIRIJx4=; b=av+bE6BB70xMoMQn+ZRjwvuqi289lWvFpi2JXhV7+qgbweDkiAP6lggTcb206mr4i8 uGTJGDKqspgRoSLkGbqkhujcYrm2pt/Ps3nv41SzLFZCzR0DQLenI3Jju7xwVvSdJCTR 4YZEV8XvL9BXiL+mb3vJcVXAp1UMFYhkmoebrP2i3m/kPcwPEmyyCWw+emRZShYORi/T NGr4GJhhPMQAT4l24z8YJjisL6cEGFb2Q9k1s0rxgQLyjQB8Rja1C3clTrRe5+zX8lxU fEFrgEhOzUqzj9H1Q2QlWnXNeNCbMBv/QmytVjHza/Zmf48zZoG6vgXwQXciAx67hcCf p69A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=g/67VyLeYMvCEKDi9DZKyIWP7WrPYcON2j+ukIRIJx4=; b=MI+52fBvzK2QR/XZSoVy/Zgi97pVp7aJR+PZ4ndTd75CivuuH/YQVybXrViWRjx/Ds dNs0ihvHloeNBsDdUJeJQS7RBaZx+IiU1cns8eE27C+cnIBJBQqx1wMkePf6n1LFjCFb v0sXzl8LIvW/LuxEgJhLuJOMf922jXcYuZvnVDgPcOO7C76zdz16IMmwVcwmuRpch6iH b2XJffbMCxWCX7TdNiTEml4YVpp5NbvRH9skFWmkToT0awjA+3TgkJmO7mZYYqLqBzbS /09l7kY4xdNkCyukmYeakJ+HMZTQCJU2yzpH1ePasQ5PQ9r0IeqD2klk4XAMswfAnmtR T+Dg== X-Gm-Message-State: ANhLgQ3F6QPcACKdU7r7lrE8fH9Co+YE2js6M9OHLGDdA4h2Almpszbu BRTntwr+UpHK6lpDoZwEYBFx0euf X-Google-Smtp-Source: ADFU+vvV5uuutPZ38DyaLx6/DNS7lym2Edb/nYuoiWri1v4BIriim8V1STzXEW72TYFbRk9lkouysg== X-Received: by 2002:adf:f607:: with SMTP id t7mr4764265wrp.36.1583513095863; Fri, 06 Mar 2020 08:44:55 -0800 (PST) Received: from [10.0.0.144] (bzq-79-178-61-110.red.bezeqint.net. [79.178.61.110]) by smtp.gmail.com with ESMTPSA id t1sm54002688wrs.41.2020.03.06.08.44.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2020 08:44:55 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.22.0.200209 Date: Fri, 06 Mar 2020 18:44:53 +0200 From: Yaron Sheffer To: "txauth@ietf.org" Message-ID: Thread-Topic: Call for charter consensus - TxAuth WG Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 16:45:00 -0000 Hi Everyone, =C2=A0 It appears that momentum is forming around the proposed formation of a TxAu= th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest in proceedin= g with this work.=C2=A0 Please do so by responding to the following questions: =C2=A0 1.=C2=A0 Do you support the charter text provided at the end of this email?=C2=A0 O= r do you have major objections, blocking concerns or feedback (if so please = elaborate)? =C2=A0 2.=C2=A0 Are you willing to author or participate in the development of the dra= fts of this WG? =C2=A0 3.=C2=A0 Are you willing to help review the drafts of this WG? =C2=A0 4.=C2=A0 Are you interested in implementing drafts of this WG? =C2=A0 The call will run for two weeks, until March 21. If you think that the char= ter should be amended In a significant way, please reply on a separate threa= d. =C2=A0 The feedback provided here will help the IESG come to a decision on the for= mation of a new WG. Given the constraints of the chartering process, regardl= ess of the outcome of this consensus call, we will be meeting in Vancouver a= s a BoF. =C2=A0 Thanks, Yaron and Dick =C2=A0 --- Charter Text Follows --- This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authoriz= ing party to delegate access to client software through an authorization ser= ver. It will expand upon the uses cases currently supported by OAuth 2.0 and= OpenID Connect (itself an extension of OAuth 2.0) to support authorizations= scoped as narrowly as a single transaction, provide a clear framework for i= nteraction among all parties involved in the protocol flow, and remove unnec= essary dependence on a browser or user-agent for coordinating interactions.=20 The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will decouple the interact= ion channels, such as the end user=E2=80=99s browser, from the delegation channel,= which happens directly between the client and the authorization server (in = contrast with OAuth 2.0 which is initiated by the client redirecting the use= r=E2=80=99s browser). The client and AS will involve a user to make an authorizati= on decision as necessary through interaction mechanisms indicated by the pro= tocol. This decoupling avoids many of the security concerns and technical ch= allenges of OAuth 2.0 and provides a non-invasive path for supporting future= types of clients and interaction channels. Additionally, the delegation process will allow for: - Fine-grained specification of access - Approval of AS attestation to identity claims - Approval of access to multiple resources and APIs in a single interaction - Separation between the party authorizing access and the party operating t= he client requesting access - A variety of client applications, including Web, mobile, single-page, and= interaction-constrained applications The group will define extension points for this protocol to allow for flexi= bility in areas including: - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation proc= ess (including identity) Additionally, the group will provide mechanisms for management of the proto= col lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Query of token rights by resource servers Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t= o simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol w= here possible. This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily compatible with O= Auth 2.0. Functionality that builds directly on OAuth 2.0 will be developed = in the OAuth Working Group, including functionality back-ported from the pro= tocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic met= hods, such as JOSE and COSE, to the delegation process. This group is not ch= artered to develop new cryptographic methods.=20 The initial work will focus on using HTTP for communication between the cli= ent and the authorization server, taking advantage of optimization features = of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping = to other protocols such as COAP when doing so does not conflict with the pri= mary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol for TLS, detach= ed HTTP signature, and embedded HTTP signatures - Identity and authentication conveyance mechanisms - Guidelines for use of protocol extension points From nobody Fri Mar 6 16:24:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE963A0E45 for ; Fri, 6 Mar 2020 16:24:43 -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_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=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 01fImmR8djxl for ; Fri, 6 Mar 2020 16:24:39 -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 C0DA33A0E41 for ; Fri, 6 Mar 2020 16:24:38 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id d12so4057667lji.4 for ; Fri, 06 Mar 2020 16:24:38 -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=toNM0bIHmHn6ZqTTgXS/GGznOtCiQyySW4G/YOZFDGs=; b=GEswzwX5gwPhBRygMuB7uEdUVZpsP0YQhCNUcDG6hQl0ZzaJ7F0tBLN8fDi53noyNa WfRHtMzNZLAGN6Kay0ar7Pl4+jaERzFp4lEjLARXknani/1rhOjE+NakQL6GQBwfXRGi /7c7EPC4KCTRfq/QiFqhKt7pNqqN3KJkHF2ZsSXzby9ecxqgdQLcyvpY5w8+JrjdExHx j1ozgY9EtopqVw7YZq4tvFyLJ55T/8XoPFY84M/tPImYEgcDgJJQ+VwMwbhQ2bqg1Lr6 RRzz1LfFPF0vnLj1grPr59d+dF1FAXRh5vVupARuqB/Ql97I1qcRlOswEzy2wWoi2Ath 78TA== 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=toNM0bIHmHn6ZqTTgXS/GGznOtCiQyySW4G/YOZFDGs=; b=ssldcGcR/H3kAcdFQkgxFvzCs/KTwkqmTSv9A2ZkbwbM8tgeZ2EvmeePu/MRcXxC6h RHniTJ+CqcGKRKx/Hh5kCIFzYeQPCo8K8DZRqf5+dm62VnN/ZK3RqXWZpS+9Y7Lx2aAp CcIW9xBLJk9HmrcllIvxG3Rxn6ChdpoQf8Rrn852u09GBBFzxw2k41kR5drDUBVZ0inI b++kdGEty2xutJ2etpcYx5GrN3nIJcMRciYEtqYfCK2lBCmWpxMJEuXmf80r2lJd4Z7z 5ul2/eI/NMkYMmWrtrXo9IznN1RgqxMAleq+9JXMs0I5MKk1Tx+H3opWUgtEjaKfqje5 Vw4g== X-Gm-Message-State: ANhLgQ1SMoxVbkbdU4m303vPbe7JY+u/sG5iOpAL5m7KsN4ZXs4UnxGr 0X+tfTd81hVc7VH0nx1cmRKnywlnYDTweGszxkM= X-Google-Smtp-Source: ADFU+vtlAch4O9+WTvF6ZrmeJYxv4VhO7Ujq5jObgtfeuPIbJo1XYCyai7JwAPcgM3g3Cj0RfaDkAd7OXdLkxm7zPFU= X-Received: by 2002:a2e:730e:: with SMTP id o14mr3487209ljc.51.1583540676352; Fri, 06 Mar 2020 16:24:36 -0800 (PST) MIME-Version: 1.0 References: <158207762171.19181.5681341988341123908.idtracker@ietfa.amsl.com> <60B4484A-E05D-4278-899E-A787836D8711@amazon.com> <20FBDF8E-B0B1-4B9B-99DB-EE229B1A97B1@mit.edu> <602299A9-68FB-41C5-810E-D6F44B3E605D@mit.edu> <9ECAC081-3460-4A3B-88B9-4D49D2B84513@mit.edu> <7A91F285-8860-4BA4-875C-E545354F0CB7@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 6 Mar 2020 16:24:09 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000805e2305a038cb82" Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 00:24:43 -0000 --000000000000805e2305a038cb82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your response did not address the question I had. I'm not talking about UMA or CIBA use cases -- I'm looking at requirements for addressing session fixation. To prevent the fixation attack, and assuming the Client can keep secrets, does the AS need to know the User is the same at the Client and the AS? IE: is it sufficient for the Client to verify that the User that came back from the AS, is the same User the Client sent to the AS? wrt. the Client keeping secrets. If the Client cannot keep a secret, an attacker can deduce what a Client needs in a response -- so the Client needs to get something from the AS via the redirect of the User to verify it is the Client User is the same as the AS User. =E1=90=A7 On Mon, Mar 2, 2020 at 11:42 AM Justin Richer wrote: > Working with that kind of setup, where you=E2=80=99ve got two different u= sers at > the client and the AS, is the driving goal behind CIBA and UMA, and in so= me > instances, the device flow. All of these have a polling mechanism that > allows an asynchronous update. > > In XYZ, the client explicitly signals this kind of expectation by not > sending a =E2=80=9Ccallback=E2=80=9D field in its request, indicating tha= t it doesn=E2=80=99t > expect the approving user to get returned through the front channel. It= =E2=80=99s > not just about signaling the client about when to poll next, it=E2=80=99s= about > signaling the intent to poll at all. > > It=E2=80=99s a different security profile that both the AS and the Client= need to > know about, since it might not be appropriate for all different forms of > access. > > XYZ (and to some extent XAuth) also allows the client to present > information about the current user at the client so that the AS can figur= e > out if it expects the same user or a different user during the interactiv= e > bits by allowing things to be passed in the =E2=80=9Cuser=E2=80=9D object= of the request. > It=E2=80=99s not just there as a login hint, at least in XYZ. There are s= ome > details from UMA and CIBA that we can import, like the user-displayed > confirmation codes and the like, that can help security and usability of > the overall protocol. But as is the case with just about everything in XY= Z, > I didn=E2=80=99t want to add it to the spec document until I=E2=80=99d im= plemented it to > make sure that it made sense to carry that information through to the > different parties. > > =E2=80=94 Justin > > On Feb 28, 2020, at 5:56 PM, Dick Hardt wrote: > > Thinking about this, the fixation attack is against the Client where the > attacker is at the Client, and the victim is at the AS. > > Does the AS need to know the attacker and victim are different? IE, if th= e > client knows that the User at the Client is the same as the User that cam= e > from the AS, have we prevented the attack? > =E1=90=A7 > > On Tue, Feb 25, 2020 at 7:38 AM Justin Richer wrote: > >> That=E2=80=99s good enough for the AS, but is it good enough for the cli= ent? The >> hash allows the client to make sure that the reference they=E2=80=99re g= etting back >> in the front channel is related to something they sent out in the first >> place. We originally had a =E2=80=9Cstate=E2=80=9D parameter like OAuth = 2 for this purpose, >> but realized that since the client can push its callback URI we didn=E2= =80=99t need >> that. But to get the kind of functionality that =E2=80=9Cnonce=E2=80=9D = and =E2=80=9Cc_hash=E2=80=9D have >> in OIDC, we added this simple hash parameter that the client can check >> before it calls the TX endpoint again. >> >> =E2=80=94 Justin >> >> On Feb 21, 2020, at 8:12 PM, Dick Hardt wrote: >> >> >> The Client presents the interact_ref to the AS with the transaction >> handle. The AS will be able to tell the Client if the interact_ref belon= gs >> to the transaction. >> >> Why is that enough? >> =E1=90=A7 >> >> On Fri, Feb 21, 2020 at 1:51 PM Justin Richer wrote: >> >>> The hash offers the same kinds of protections to the client that the >>> OIDC nonce does =E2=80=94 it binds the front channel return to somethin= g you get >>> from the back channel. >>> >>> In other words, the client can be sure that the return value that it=E2= =80=99s >>> getting is related to the request it made in the first place, and not >>> another one. Clients using per-request redirect URIs can also help with >>> this, but this is something that the server can provide directly. >>> >>> =E2=80=94 Justin >>> >>> On Feb 21, 2020, at 4:14 PM, Dick Hardt wrote: >>> >>> While I can see the value of the interact_ref (aka interaction_ref) in >>> the return URI that allows the Client to ensure the user that started t= he >>> transaction is the same one that interacted at the AS, I don't understa= nd >>> why a hash is required. Would you elaborate? >>> =E1=90=A7 >>> >>> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer wrote: >>> >>>> But that=E2=80=99s exactly the point =E2=80=94 it helps in that case, = which is a very >>>> common case. For cases where the client doesn=E2=80=99t expect the use= r to come >>>> back on the same channel, then they don=E2=80=99t use the callback mec= hanism. They >>>> might use the =E2=80=9Cfinish message=E2=80=9D URL that Annabelle ment= ioned in the other >>>> thread, or they might just print out =E2=80=9Cyou=E2=80=99re done now!= =E2=80=9D at the AS, which is >>>> common today. >>>> >>>> XYZ=E2=80=99s interaction structure allows the composition of these th= ings, >>>> under the control of the client. This is exactly why it=E2=80=99s impo= rtant to be >>>> able to specify how to get to the AS and how to get back as separate i= tems, >>>> so that the client can compose the combination that makes the most sen= se >>>> for that client. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> On Feb 21, 2020, at 3:52 PM, Dick Hardt wrote: >>>> >>>> I got ahead of myself. A completion URI protects the User only if the >>>> User is sent back to the same channel the transaction started so the C= lient >>>> can confirm it is the same User that started the transaction. >>>> >>>> so this does not help the security: >>>> >>>> "Being able to provide a completion URI even if the user is starting o= n >>>> a device is a great insight on how to address the threat above." >>>> >>>> =E1=90=A7 >>>> >>>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt >>>> wrote: >>>> >>>>> The lightbulb finally clicked on for me. Thanks for your patience. >>>>> >>>>> The threat you are describing is where the attacker starts a >>>>> transaction at the client, and gets the victim to complete it. Correc= t? >>>>> >>>>> I still think the Client should be able to signal if it will be doing >>>>> a redirect vs showing a QR code (or wants to do both). >>>>> >>>>> Being able to provide a completion URI even if the user is starting o= n >>>>> a device is a great insight on how to address the threat above. >>>>> >>>>> I'm going to ponder how to align XAuth more with these features of XY= Z. >>>>> =E1=90=A7 >>>>> >>>>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer >>>>> wrote: >>>>> >>>>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt wrote= : >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer >>>>>> wrote: >>>>>> >>>>>>> I=E2=80=99m in complete agreement with Annabelle. In XYZ we realize= d that >>>>>>> both the QR Code and Authorization Code, and that the only differen= ce is >>>>>>> how the user gets back to the client. So instead of inventing a new >>>>>>> type of interaction, we split them. In XYZ, we have: >>>>>>> >>>>>> >>>>>> This sentence looks to be missing something. >>>>>> >>>>>> >>>>>> Apologies: We realized they both used AS-composed URLs to get the >>>>>> user to the AS in a web browser for interaction purposes. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> - redirect: tells the AS that the client can send the user to an >>>>>>> arbitrary URL (and the AS doesn=E2=80=99t care how the client gets = that info to the >>>>>>> user; could be a redirect or an image or send a push notification t= o a >>>>>>> secondary device, we don=E2=80=99t care as long as the user shows u= p in a browser >>>>>>> at the AS =E2=80=94 so maybe this field can be renamed to be more u= niversally >>>>>>> accurate) >>>>>>> >>>>>> >>>>>> As stated in this thread, it may be useful for the AS to know if the >>>>>> URL will be in a QR code, or in a full redirect. >>>>>> >>>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a >>>>>> Client has to do, so it needs to know the difference between a popup= , and a >>>>>> full browser redirect. This is targetted at SPAs, where an additiona= l URL >>>>>> to redirect to is extra work. >>>>>> >>>>>> >>>>>>> - code: tells the AS that the client can present a short code the >>>>>>> user can type (along with a static URL the user can get to, maybe b= y typing >>>>>>> the URL manually, but it=E2=80=99s not dynamic/arbitrary like the r= edirect method) >>>>>>> - callback: tells the AS that the client can receive the completio= n >>>>>>> message from a front channel interaction through a redirect. Note t= hat the >>>>>>> client might have gotten to the AS through a redirect on-device, th= rough a >>>>>>> QR-code off device, or through some other magic, and this field isn= =E2=80=99t >>>>>>> concerned with that =E2=80=94 it=E2=80=99s only concerned with how = to get the user :back:. >>>>>>> >>>>>> >>>>>> In a full redirect, the Client wants the AS to send the user back so >>>>>> that it can continue. >>>>>> >>>>>> The only parameter in the completion message is the nonce, which >>>>>> seems superfluous. See below. >>>>>> >>>>>> >>>>>>> >>>>>>> These three can be combined in different ways depending on what you >>>>>>> want to do at the client. Let=E2=80=99s say you=E2=80=99re doing an= d OAuth2 style >>>>>>> authorization code, you=E2=80=99d use =E2=80=9Credirect=E2=80=9D an= d =E2=80=9Ccallback=E2=80=9D together. If you=E2=80=99re >>>>>>> doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80=9D. = If you=E2=80=99re doing just a QR code >>>>>>> with polling, you use just =E2=80=9Credirect=E2=80=9D to get the lo= ng URL. If you=E2=80=99re doing >>>>>>> a user code and a QR code together, you use =E2=80=9Credirect=E2=80= =9D and =E2=80=9Ccode=E2=80=9D to get >>>>>>> the long URL and the short code not he screen at the same time. >>>>>>> >>>>>>> On top of that, they can be combined with other methods. Maybe I ca= n >>>>>>> send the user to an arbitrary URL but also display a human-readable >>>>>>> verification code (like CIBA), or send something in a push notifica= tion but >>>>>>> also give them a message to type, or I=E2=80=99m getting claims fro= m an agent but I >>>>>>> want them redirected back through the browser. The client gets to d= ecide >>>>>>> what kinds of interaction it can do and how to use these pieces in = ways >>>>>>> that make the most sense. >>>>>>> >>>>>> >>>>>> Per my question later in this thread, why would the Client not know >>>>>> what interaction it wants prior to the request? >>>>>> >>>>>> >>>>>> What do you mean? The client does know what it wants and that=E2=80= =99s why >>>>>> it=E2=80=99s asking for what it wants. We=E2=80=99re debating differ= ent methods for the >>>>>> client to ask for what it wants. This question does not make sense t= o me. >>>>>> >>>>>> >>>>>> If the AS is doing CIBA, that is not a decision just for the Client. >>>>>> Both the AS and the Client need to know they are doing CIBA. (FWIW: = I think >>>>>> this work supersedes CIBA) >>>>>> >>>>>> >>>>>> As I=E2=80=99ve stated previously, I believe the interaction methods= here can >>>>>> supersede CIBA. >>>>>> >>>>>> >>>>>> Additionally, different interactions have different risk profiles. >>>>>> Sophisticated ASes will use that signal in the risk assessment, and = may do >>>>>> ask for additional authentication or verification. >>>>>> >>>>>> >>>>>> >>>>>> Yes, exactly my point. Because different interactions have different >>>>>> risks, the AS will need to be able to decide which interactions it= =E2=80=99s OK >>>>>> with for a given request. This could vary based on what=E2=80=99s be= ing requested, >>>>>> or who=E2=80=99s doing the requesting. >>>>>> >>>>>> >>>>>>> An interesting difference between XYZ and XAuth=E2=80=99s approache= s is that >>>>>>> XYZ keeps the concept of the =E2=80=9Cauthorization code=E2=80=9D i= n the callback response >>>>>>> (which in turn is based on the OAuth 1 =E2=80=9Coauth_verifier=E2= =80=9D field). In XYZ, you >>>>>>> get an =E2=80=9Cinteraction_ref=E2=80=9D which is hashed along with= a pair of nonces >>>>>>> generated by the client and the AS in the back channel. This binds = the >>>>>>> front channel response to both the back channel request and the bac= k >>>>>>> channel response for a given transaction =E2=80=94 and note that I= =E2=80=99m really open to >>>>>>> having a better way to generate and calculate such a binding, but I= think >>>>>>> this works. In any event, this protects the client from session fix= ation >>>>>>> and injection on the return from the front channel that it=E2=80=99= s susceptible to >>>>>>> in a pure polling model, and the hashing approach basically combine= s the >>>>>>> security parameters of the OAuth 2 authorization code and (to an ex= tent) >>>>>>> state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in o= ne element. This is only >>>>>>> applicable if you=E2=80=99re coming back to the client and you can = validate the >>>>>>> hash and present the reference parameter. If you=E2=80=99re doing j= ust plain >>>>>>> polling, you don=E2=80=99t have that protection =E2=80=94 but the c= lient and the AS are >>>>>>> aware of that risk, and there=E2=80=99s an option to prevent it. >>>>>>> >>>>>>> XAuth has removed the authorization code concept in its redirect >>>>>>> return, and clients only do polling against the GS API in order to = get >>>>>>> tokens. While I obviously think it=E2=80=99s very valuable to remov= e things from >>>>>>> the front channel, I don=E2=80=99t think this is something we can r= emove without >>>>>>> opening up attack surfaces that have already been identified in pre= vious >>>>>>> protocols. I would like to understand why XAuth is not susceptible = to the >>>>>>> same kinds of attacks, or if it is, what mitigations there are for = them. >>>>>>> >>>>>> >>>>>> Unlike OAuth 2.0, there are no parameters in the front channel >>>>>> response to the Client. The redirect back to the Client is only need= ed to >>>>>> return the interaction back to the Client. >>>>>> >>>>>> >>>>>> This argument rings tautologically hollow =E2=80=94 there are no par= ameters >>>>>> because you=E2=80=99ve defined that there aren=E2=80=99t any in XAut= h. XYZ does have >>>>>> parameters, to tie the front and back channel requests together when= doing >>>>>> redirect back and forth. >>>>>> >>>>>> If you=E2=80=99re not doing a redirect back (ie, not sending a =E2= =80=9Ccallback=E2=80=9D >>>>>> interaction block), then it=E2=80=99s a polling mechanism like XAuth= , the device >>>>>> flow, etc. There are very real risks to this. >>>>>> >>>>>> >>>>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0) >>>>>> >>>>>> In OAuth, the AS gives a code to the User to give to the Client that >>>>>> the Client then gives to the GS. >>>>>> >>>>>> In XAuth, the AS gives a "code" to the Client that givers it to the >>>>>> User to give to the GS. >>>>>> >>>>>> In XAuth, the "code" is either a user code, or something embedded in >>>>>> the URI the User is redirected to. >>>>>> >>>>>> Therefore, there is nothing to protect in the redirect back to the >>>>>> Client. >>>>>> >>>>>> If I'm missing an attack, please elaborate how it would happen. >>>>>> >>>>>> >>>>>> One form of impersonation is well documented: >>>>>> https://hueniverse.com/explaining-the-oauth-session-fixation-attack-= aa759250a0e7 >>>>>> >>>>>> OAuth 1.0=E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar req= uest initiation step to >>>>>> what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s sus= ceptible to the >>>>>> same kind of issue. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> =E2=80=94 Justin >>>>>>> >>>>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle < >>>>>>> richanna=3D40amazon.com@dmarc.ietf.org> wrote: >>>>>>> >>>>>>> Thanks for the update, Dick! I=E2=80=99m going to confine my commen= ts here >>>>>>> to interaction mode design, setting aside whether or not we need = =E2=80=9Cpopup=E2=80=9D. :D >>>>>>> >>>>>>> Once the GS hands that URI back to the Client, it has zero control >>>>>>> over how the Client uses it. The Client could present any URI (of a >>>>>>> reasonable size) into a QR code, or present it as a clickable link,= or >>>>>>> redirect to it, or open it in an external browser, or do any number= of >>>>>>> other as-yet-not-invented things with it. Moreover, the Client may = not know >>>>>>> yet what it wants to do with it. So what value is there in distingu= ishing >>>>>>> between =E2=80=9CI want a URI for a redirect=E2=80=9D vs. =E2=80=9C= I want a URI for a QR code=E2=80=9D vs. >>>>>>> =E2=80=9CI want a URI for =E2=80=9D? >>>>>>> >>>>>>> Even if we consider things like QR code data capacity, that=E2=80= =99s really >>>>>>> just a URI length limitation, which could apply to non-QR interacti= on >>>>>>> modes, e.g., if the Client device wants to communicate the URI over= an >>>>>>> extremely bandwidth-constrained channel. And it=E2=80=99s not clear= to me how >>>>>>> including a URI length limitation in the request helps. If a GS is = capable >>>>>>> of generating a shorter URI, why wouldn=E2=80=99t it always return = that? On the >>>>>>> client side, it can look at the length of the URI provided and deci= de what >>>>>>> to do with it (e.g., render a QR code or display it or do nothing w= ith it). >>>>>>> >>>>>>> So that really leaves us with two interaction modes that we need: >>>>>>> >>>>>>> - =E2=80=9Curi=E2=80=9D, which returns a full URI that may not b= e human >>>>>>> friendly; and >>>>>>> - =E2=80=9Ccode=E2=80=9D, which returns a code and URI for a cod= e entry page, >>>>>>> both of which are human-friendly. >>>>>>> >>>>>>> >>>>>>> Those could be combinable to get both, and even if we don=E2=80=99t= go down >>>>>>> the multiple interaction mode route we could add the full URI to th= e =E2=80=9Ccode=E2=80=9D >>>>>>> interaction object. It wouldn=E2=80=99t hurt anything to do so. >>>>>>> >>>>>>> =E2=80=93 >>>>>>> Annabelle Backman (she/her) >>>>>>> AWS Identity >>>>>>> https://aws.amazon.com/identity/ >>>>>>> >>>>>>> >>>>>>> *From: *Txauth on behalf of Dick Hardt < >>>>>>> dick.hardt@gmail.com> >>>>>>> *Date: *Tuesday, February 18, 2020 at 6:04 PM >>>>>>> *To: *"txauth@ietf.org" >>>>>>> *Subject: *[Txauth] Fwd: New Version Notification for >>>>>>> draft-hardt-xauth-protocol-03.txt >>>>>>> >>>>>>> Added in user code interaction and aligned QR code to be a superset >>>>>>> of user code. >>>>>>> Fixed descriptions. >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message --------- >>>>>>> From: >>>>>>> Date: Tue, Feb 18, 2020 at 6:00 PM >>>>>>> Subject: New Version Notification for >>>>>>> draft-hardt-xauth-protocol-03.txt >>>>>>> To: Dick Hardt >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt >>>>>>> has been successfully submitted by Dick Hardt and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Name: draft-hardt-xauth-protocol >>>>>>> Revision: 03 >>>>>>> Title: The XAuth Protocol >>>>>>> Document date: 2020-02-18 >>>>>>> Group: Individual Submission >>>>>>> Pages: 53 >>>>>>> URL: >>>>>>> https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.= txt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 >>>>>>> Htmlized: >>>>>>> https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol >>>>>>> Diff: >>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-03 >>>>>>> >>>>>>> Abstract: >>>>>>> Client software often desires resources or identity claims that >>>>>>> are >>>>>>> independent of the client. This protocol allows a user and/or >>>>>>> resource owner to delegate resource authorization and/or release >>>>>>> of >>>>>>> identity claims to a server. Client software can then request >>>>>>> access >>>>>>> to resources and/or identity claims by calling the server. The >>>>>>> server acquires consent and authorization from the user and/or >>>>>>> resource owner if required, and then returns to the client >>>>>>> software >>>>>>> the authorization and identity claims that were approved. This >>>>>>> protocol can be extended to support alternative authorizations, >>>>>>> claims, interactions, and client authentication mechanisms. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> =E1=90=A7 >>>>>>> -- >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >> > --000000000000805e2305a038cb82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your response did not address the question I had. I'm = not talking about=C2=A0UMA or CIBA use cases -- I'm looking at requirem= ents for addressing session fixation.

To prevent the fix= ation attack, and assuming the Client can keep secrets, does the AS need to= know the User is the same at the Client and the AS?

IE: is it sufficient for the Client to verify that the User that came ba= ck from the AS, is the same User the Client sent to the AS?

<= /div>
wrt. the Client keeping secrets. If the Client cannot keep a secr= et, an attacker can deduce what a Client needs in a response -- so the Clie= nt needs to get something from the AS via the redirect of the User to verif= y it is the Client User is the same as the AS User.





3D""= =E1=90=A7

On Mon, Mar 2, 2020 at 11:42 AM Justin Richer <jricher@mit.edu> wrote:
Working with that kind of setup, where you=E2=80=99ve got two dif= ferent users at the client and the AS, is the driving goal behind CIBA and = UMA, and in some instances, the device flow. All of these have a polling me= chanism that allows an asynchronous update.

In XYZ, the = client explicitly signals this kind of expectation by not sending a =E2=80= =9Ccallback=E2=80=9D field in its request, indicating that it doesn=E2=80= =99t expect the approving user to get returned through the front channel. I= t=E2=80=99s not just about signaling the client about when to poll next, it= =E2=80=99s about signaling the intent to poll at all.

<= div>It=E2=80=99s a different security profile that both the AS and the Clie= nt need to know about, since it might not be appropriate for all different = forms of access.=C2=A0

XYZ (and to some extent XAu= th) also allows the client to present information about the current user at= the client so that the AS can figure out if it expects the same user or a = different user during the interactive bits by allowing things to be passed = in the =E2=80=9Cuser=E2=80=9D object of the request. It=E2=80=99s not just = there as a login hint, at least in XYZ. There are some details from UMA and= CIBA that we can import, like the user-displayed confirmation codes and th= e like, that can help security and usability of the overall protocol. But a= s is the case with just about everything in XYZ, I didn=E2=80=99t want to a= dd it to the spec document until I=E2=80=99d implemented it to make sure th= at it made sense to carry that information through to the different parties= .

=C2=A0=E2=80=94 Justin

On Feb 28, 2020, at 5:56 PM, Dick Hardt <dick.hardt@gmail.com> w= rote:

Thinking about this, the fixation atta= ck is against the Client where the attacker is at the Client, and the victi= m is at the AS.

Does the AS need to know the attacker an= d victim are different? IE, if the client knows that the User at the Client= is the same as the User that came from the AS, have we prevented the attac= k?
3D""=E1=90=A7

On Tue, Feb 25, 2020 at 7:38 A= M Justin Richer <jr= icher@mit.edu> wrote:
That=E2=80=99s good enough for the AS, but is it good eno= ugh for the client? The hash allows the client to make sure that the refere= nce they=E2=80=99re getting back in the front channel is related to somethi= ng they sent out in the first place. We originally had a =E2=80=9Cstate=E2= =80=9D parameter like OAuth 2 for this purpose, but realized that since the= client can push its callback URI we didn=E2=80=99t need that. But to get t= he kind of functionality that =E2=80=9Cnonce=E2=80=9D and =E2=80=9Cc_hash= =E2=80=9D have in OIDC, we added this simple hash parameter that the client= can check before it calls the TX endpoint again.

=C2=A0= =E2=80=94 Justin

On Feb 21, 2020= , at 8:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


The Client presents the interact_ref to the AS with= the transaction handle. The AS will be able to tell the Client if the inte= ract_ref belongs to the transaction.

Why is that e= nough?
<= img alt=3D"" style=3D"width: 0px; max-height: 0px; overflow: hidden;" src= =3D"https://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%= 3D&type=3Dzerocontent&guid=3De8149d62-27cd-484b-8310-c923c4e1e484">= =E1=90=A7

On Fri, Feb 21, 2020 at = 1:51 PM Justin Richer <jricher@mit.edu> wrote:
The hash offers the same kinds of protections to th= e client that the OIDC nonce does =E2=80=94 it binds the front channel retu= rn to something you get from the back channel.=C2=A0

In = other words, the client can be sure that the return value that it=E2=80=99s= getting is related to the request it made in the first place, and not anot= her one. Clients using per-request redirect URIs can also help with this, b= ut this is something that the server can provide directly.

=C2=A0=E2=80=94 Justin

= On Feb 21, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

While I can see the value of the interact_ref (aka inter= action_ref) in the return URI that allows the Client to ensure the user tha= t started the transaction is the same one that interacted at the AS, I don&= #39;t understand why a hash is required. Would you elaborate?
3D""=E1=90=A7

On Fri, Feb 21, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> = wrote:
But = that=E2=80=99s exactly the point =E2=80=94 it helps in that case, which is = a very common case. For cases where the client doesn=E2=80=99t expect the u= ser to come back on the same channel, then they don=E2=80=99t use the callb= ack mechanism. They might use the =E2=80=9Cfinish message=E2=80=9D URL that= Annabelle mentioned in the other thread, or they might just print out =E2= =80=9Cyou=E2=80=99re done now!=E2=80=9D at the AS, which is common today.
XYZ=E2=80=99s interaction structure allows the compositio= n of these things, under the control of the client. This is exactly why it= =E2=80=99s important to be able to specify how to get to the AS and how to = get back as separate items, so that the client can compose the combination = that makes the most sense for that client.

=C2=A0= =E2=80=94 Justin


On F= eb 21, 2020, at 3:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I got ahead of myself. A completion URI protects the User on= ly if the User is sent back to the same channel the transaction started so = the Client can confirm it is the same User that started the transaction.

so this does not help the security:

"Being able to provide a completion URI even if the user is sta= rting on a device is a great insight on how to address the threat above.&qu= ot;

3D""=E1=90=A7

=
On Fri, Fe= b 21, 2020 at 12:40 PM Dick Hardt <dick.hardt@gmail.com> wrote:
The lightbulb fin= ally clicked on for me. Thanks for your patience.

The th= reat you are describing is where the attacker starts a transaction at the c= lient, and gets the victim to complete it. Correct?

= I still think the Client should be able to signal if it will be doing a red= irect vs showing a QR code (or wants to do both).

= Being able to provide a completion URI even if the user is starting on a de= vice is a great insight on how to address the threat above.=C2=A0
<= br>
I'm going to ponder how to align XAuth more with these fe= atures of XYZ.
3D""=E1=90=A7
On Fr= i, Feb 21, 2020 at 11:31 AM Justin Richer <jricher@mit.edu> wrote:
On Feb 21, 2020, at 1:54 PM, Di= ck Hardt <dick= .hardt@gmail.com> wrote:

=


=
On Fri, Feb 21, 2020 at 8:38 AM Justi= n Richer <jricher@m= it.edu> wrote:
I=E2=80=99m in complete agreement with Annabelle. In XYZ we realized that both the QR Code = and Authorization Code, and that the only difference is how the user gets b= ack to the client. So instead of inventing a new type of interaction= , we split them. In XYZ, we have:

This sentence looks to be miss= ing something.

Apologies: We realized they both used AS-composed URLs to get the user t= o the AS in a web browser for interaction purposes.

=C2=A0

=C2=A0- redirect: tells the AS that the client can send the user to an a= rbitrary URL (and the AS doesn=E2=80=99t care how the client gets that info= to the user; could be a redirect or an image or send a push notification t= o a secondary device, we don=E2=80=99t care as long as the user shows up in= a browser at the AS =E2=80=94 so maybe this field can be renamed to be mor= e universally accurate)

As stat= ed in this thread, it may be useful for the AS to know if the URL will be i= n a QR code, or in a full redirect.

In XAuth, the = GS(AS min XYA) closes the popup to minimize what a Client has to do, so it = needs to know the difference between a popup, and a full browser redirect. = This is targetted at SPAs, where an additional URL to redirect to is extra = work.
=C2=A0
=C2=A0- code: tells the AS that the client can present a short= code the user can type (along with a static URL the user can get to, maybe= by typing the URL manually, but it=E2=80=99s not dynamic/arbitrary like th= e redirect method)
=C2=A0- callback: tells the AS that the client c= an receive the completion message from a front channel interaction through = a redirect. Note that the client might have gotten to the AS through a redi= rect on-device, through a QR-code off device, or through some other magic, = and this field isn=E2=80=99t concerned with that =E2=80=94 it=E2=80=99s onl= y concerned with how to get the user :back:.
=

In a full redirect, the Client wants the AS to send the= user back so that it can continue.

The only param= eter in the completion message is the nonce, which seems superfluous. See b= elow.
=C2=A0

These three can be combined in different w= ays depending on what you want to do at the client. Let=E2=80=99s say you= =E2=80=99re doing and OAuth2 style authorization code, you=E2=80=99d use = =E2=80=9Credirect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D together. If you= =E2=80=99re doing a plain user code, you=E2=80=99d use =E2=80=9Ccode=E2=80= =9D. If you=E2=80=99re doing just a QR code with polling, you use just =E2= =80=9Credirect=E2=80=9D to get the long URL. If you=E2=80=99re doing a user= code and a QR code together, you use =E2=80=9Credirect=E2=80=9D and =E2=80= =9Ccode=E2=80=9D to get the long URL and the short code not he screen at th= e same time.=C2=A0

On top of that, they can be com= bined with other methods. Maybe I can send the user to an arbitrary URL but= also display a human-readable verification code (like CIBA), or send somet= hing in a push notification but also give them a message to type, or I=E2= =80=99m getting claims from an agent but I want them redirected back throug= h the browser. The client gets to decide what kinds of interaction it can d= o and how to use these pieces in ways that make the most sense.
=

Per my question later in this thread= , why would the Client not know what interaction it wants prior to the requ= est?

What do you me= an? The client does know what it wants and that=E2=80=99s why it=E2=80=99s = asking for what it wants. We=E2=80=99re debating different methods for the = client to ask for what it wants. This question does not make sense to me.

If the AS is doing CIBA, that is not a decision= just for the Client. Both the AS and the Client need to know they are doin= g CIBA. (FWIW: I think this work supersedes CIBA)

As I=E2=80=99ve stated previously, I believe= the interaction methods here can supersede CIBA.


<= div>Additionally, different interactions have different risk profiles. Soph= isticated ASes will use that signal in the risk assessment, and may do ask = for additional authentication or verification.
=C2=A0
=

Yes, exactly my point. Because= different interactions have different risks, the AS will need to be able t= o decide which interactions it=E2=80=99s OK with for a given request. This = could vary based on what=E2=80=99s being requested, or who=E2=80=99s doing = the requesting.

=

An interesting difference between XYZ and XAu= th=E2=80=99s approaches is that XYZ keeps the concept of the =E2=80=9Cautho= rization code=E2=80=9D in the callback response (which in turn is based on = the OAuth 1 =E2=80=9Coauth_verifier=E2=80=9D field). In XYZ, you get an =E2= =80=9Cinteraction_ref=E2=80=9D which is hashed along with a pair of nonces = generated by the client and the AS in the back channel. This binds the fron= t channel response to both the back channel request and the back channel re= sponse for a given transaction =E2=80=94 and note that I=E2=80=99m really o= pen to having a better way to generate and calculate such a binding, but I = think this works. In any event, this protects the client from session fixat= ion and injection on the return from the front channel that it=E2=80=99s su= sceptible to in a pure polling model, and the hashing approach basically co= mbines the security parameters of the OAuth 2 authorization code and (to an= extent) state, PKCE=E2=80=99s code_challenge, and OIDC=E2=80=99s nonce in = one element. This is only applicable if you=E2=80=99re coming back to the c= lient and you can validate the hash and present the reference parameter. If= you=E2=80=99re doing just plain polling, you don=E2=80=99t have that prote= ction =E2=80=94 but the client and the AS are aware of that risk, and there= =E2=80=99s an option to prevent it.

XAuth has remo= ved the authorization code concept in its redirect return, and clients only= do polling against the GS API in order to get tokens. While I obviously th= ink it=E2=80=99s very valuable to remove things from the front channel, I d= on=E2=80=99t think this is something we can remove without opening up attac= k surfaces that have already been identified in previous protocols. I would= like to understand why XAuth is not susceptible to the same kinds of attac= ks, or if it is, what mitigations there are for them.=C2=A0

Unlike OAuth 2.0, there are no parameter= s in the front channel response to the Client. The redirect back to the Cli= ent is only needed to return the interaction back to the Client.

This argument rings tautologi= cally hollow =E2=80=94 there are no parameters because you=E2=80=99ve defin= ed that there aren=E2=80=99t any in XAuth. XYZ does have parameters, to tie= the front and back channel requests together when doing redirect back and = forth.

If you=E2=80=99re not doing a redirect back= (ie, not sending a =E2=80=9Ccallback=E2=80=9D interaction block), then it= =E2=80=99s a polling mechanism like XAuth, the device flow, etc. There are = very real risks to this.


XAuth (and XYZ) hav= e a different flow than OAuth 2.0 (or OAuth 1.0)

I= n OAuth, the AS gives a code to the User to give to the Client that the Cli= ent then gives to the GS.

In XAuth, the AS gives a= "code" to the Client that givers it to the User to give to the G= S.

In XAuth, the "code" is either a user= code, or something embedded in the URI the User is redirected to.

Therefore, there is nothing to protect in the redirect bac= k to the Client.

If I'm missing an attack, ple= ase elaborate how it would happen.


OAuth 1.0= =E2=80=99s =E2=80=9CRequest Token=E2=80=9D is a similar request initiation = step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it=E2=80=99s su= sceptible to the same kind of issue.

=C2=A0

=C2=A0= =E2=80=94 Justin

On Feb 20, 2020= , at 3:21 PM, Richard Backman, Annabelle <richanna=3D40amazon.com@dmarc= .ietf.org> wrote:

Thank= s for the update, Dick! I=E2=80=99m going to confine my comments here to in= teraction mode design, setting aside whether or not we need =E2=80=9Cpopup= =E2=80=9D. :D
=C2=A0
Once the GS hands that URI back to the Client, it has zero control over= how the Client uses it. The Client could present any URI (of a reasonable = size) into a QR code, or present it as a clickable link, or redirect to it,= or open it in an external browser, or do any number of other as-yet-not-in= vented things with it. Moreover, the Client may not know yet what it wants = to do with it. So what value is there in distinguishing between =E2=80=9CI = want a URI for a redirect=E2=80=9D vs. =E2=80=9CI want a URI for a QR code= =E2=80=9D vs. =E2=80=9CI want a URI for <some other machine-driven inter= action mode>=E2=80=9D?
=C2=A0=
Even if we consider things like QR code data capacity, that= =E2=80=99s really just a URI length limitation, which could apply to non-QR= interaction modes, e.g., if the Client device wants to communicate the URI= over an extremely bandwidth-constrained channel. And it=E2=80=99s not clea= r to me how including a URI length limitation in the request helps. If a GS= is capable of generating a shorter URI, why wouldn=E2=80=99t it always ret= urn that? On the client side, it can look at the length of the URI provided= and decide what to do with it (e.g., render a QR code or display it or do = nothing with it).
=C2=A0
So that really leaves us with two interaction modes that we need:
  • =E2=80=9Curi=E2=80=9D, which returns a full URI that may not b= e human friendly; and
  • =E2=80=9Ccode=E2=80=9D, wh= ich returns a code and URI for a code entry page, both of which are human-f= riendly.
=C2=A0
Those could be combinable to get both, and even if we don=E2=80=99t go d= own the multiple interaction mode route we could add the full URI to the = =E2=80=9Ccode=E2=80=9D interaction object. It wouldn=E2=80=99t hurt anythin= g to do so.
=C2=A0
=E2=80=93
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">Annabelle Backman (she/her)<= u>
AWS Identity=
= =C2=A0
=C2=A0
From:=C2=A0Txauth= <txauth-bo= unces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date:<= span>=C2=A0Tuesday, February 18, 2020 at 6:04 PM
To:= =C2=A0"txauth@ietf.org" <txauth@ietf.org>
Subject:=C2=A0[Txau= th] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt<= /u>
=C2=A0
Added in user code interaction and aligned QR c= ode to be a superset of user code.
= Fixed descriptions.

=C2=A0

---------- Forwarded= message ---------
From: <internet-= drafts@ietf.org>
Date: Tue, Feb 18, 2020 at 6:00 PM
Subject: N= ew Version Notification for draft-hardt-xauth-protocol-03.txt
To: Dick H= ardt <dick.hardt@gmail.com><= u>




A new version o= f I-D, draft-hardt-xauth-protocol-03.txt
has been successfully submitted= by Dick Hardt and posted to the
IETF repository.

Name:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2= =A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The = XAuth Protocol
Document date:=C2=A0 2020-02-18
Group:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 53
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.= txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/dr= aft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.or= g/html/draft-hardt-xauth-protocol-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 = =C2=A0ht= tps://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft= -hardt-xauth-protocol-03

Abstract:
=C2=A0 =C2=A0Client softwa= re often desires resources or identity claims that are
=C2=A0 =C2=A0inde= pendent of the client.=C2=A0 This protocol allows a user and/or
=C2=A0 = =C2=A0resource owner to delegate resource authorization and/or release of=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then = request access
=C2=A0 =C2=A0to resources and/or identity claims by calli= ng the server.=C2=A0 The
=C2=A0 =C2=A0server acquires consent and author= ization from the user and/or
=C2=A0 =C2=A0resource owner if required, an= d then returns to the client software
=C2=A0 =C2=A0the authorization and= identity claims that were approved.=C2=A0 This
=C2=A0 =C2=A0protocol ca= n be extended to support alternative authorizations,
=C2=A0 =C2=A0claims= , interactions, and client authentication mechanisms.




Pl= ease note that it may take a couple of minutes from the time of submission<= br>until the htmlized version and diff are available at=C2=A0<= a href=3D"http://tools.ietf.org/" style=3D"color:blue;text-decoration:under= line" target=3D"_blank">tools.ietf.org.

The IETF Secretariat<= /u>

=E1=90=A7
--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/= listinfo/txauth






--000000000000805e2305a038cb82-- From nobody Sat Mar 7 09:47:55 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E23A16FD for ; Sat, 7 Mar 2020 09:47: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=parecki-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 LfA8oBrOoJrQ for ; Sat, 7 Mar 2020 09:47:46 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 F0A243A16F8 for ; Sat, 7 Mar 2020 09:47:45 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id s24so5241633iog.5 for ; Sat, 07 Mar 2020 09:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3iF6G2JPLYJBp0LYikEKozbGaXubux8Z5spZ3FK5Bfo=; b=ahrDUucxuub3poL7cqMjQDKyDuOmH2TlnueXP6foYtXsB3PAgyaKF6lCUsNnm5gJgp TlIwaI0gRtKgendaYyCi7dqHw33G/hryD/N1HYcenHz5MkE7ZdoomTziWzVpLWM4QavJ IoNJSGgx5da+2Hw1WPQ+wp/0mmyeWMChTZO689gbK2mwEp8fnXorTFT21ViUCgbbvdnV SA9RV9WUfgkX1nJhzHSipokDVcZFvPqTzVsg9AQDCKj49YB8CUbyoX3EA4Rftc1eARHy GTu+ubBqJyqEGY4EqKI33dOmNf93woKIIM9+FZLLNfIWU9ZHx7uF8bJN1McahpBdb259 Q4cg== 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=3iF6G2JPLYJBp0LYikEKozbGaXubux8Z5spZ3FK5Bfo=; b=NSqfv8Bjz0B8L8T1KP/Ns9qI9S7jgiAUdJrokWm5U/nKg/pwLrPVhm0TwdoLXNbZJo Z21Y189Mv6MnFz9YGJeyaPuywbHT0a/5EmWbpm+2WiwQDGDRNr0+lckbS93mqMYw+dJy wjwQLyJH+KXuuT1+KRTvNKetDRbFuzUQ+ChJISGQ4aYx/TjyzM8RRXiCdWsRILOoqIye dCfjszbtGiNDtZflkipsZySHKgt0o1BJz382OwY6nTK2l8MHoXH7i4kroHIcV9IUCqoB WEl2CHdIEgqsBu7y5xd6+9rC0hzkdjJRU+z0+q0g8QxVftn9HmTYiENk/SitX8BLtMBW K/yg== X-Gm-Message-State: ANhLgQ1eL5y/WuHQShnWrnZqX/SMhap0WlUtLM8R2bG/jcSzO8FvJ1vQ zsyizX307H2qEfeH9IjTfjLaM/LRtBM= X-Google-Smtp-Source: ADFU+vuJQZQhDIqC8AMpWPsWAQ/psPE0fX8xML6dIkddTZ67wIs49a7igkFcIIoWriMHJlLI/+6hYQ== X-Received: by 2002:a05:6602:20cf:: with SMTP id 15mr7463605ioz.24.1583603263419; Sat, 07 Mar 2020 09:47:43 -0800 (PST) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com. [209.85.166.169]) by smtp.gmail.com with ESMTPSA id c12sm12777525ile.12.2020.03.07.09.47.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Mar 2020 09:47:42 -0800 (PST) Received: by mail-il1-f169.google.com with SMTP id j69so4996308ila.11 for ; Sat, 07 Mar 2020 09:47:42 -0800 (PST) X-Received: by 2002:a92:5f45:: with SMTP id t66mr8619080ilb.28.1583603262418; Sat, 07 Mar 2020 09:47:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Sat, 7 Mar 2020 09:47:29 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Yaron Sheffer Cc: "txauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 17:47:55 -0000 > 1. Do you support the charter text provided at the end of this email? O= r do you have major objections, blocking concerns or feedback (if so please= elaborate)? Yes > 2. Are you willing to author or participate in the development of the dr= afts of this WG? Yes > 3. Are you willing to help review the drafts of this WG? Yes > 4. Are you interested in implementing drafts of this WG? Yes ---- Aaron Parecki aaronparecki.com @aaronpk On Fri, Mar 6, 2020 at 8:45 AM Yaron Sheffer wrote: > > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a Tx= Auth working group. We=E2=80=99d like to more formally gauge interest in p= roceeding with this work. Please do so by responding to the following ques= tions: > > 1. Do you support the charter text provided at the end of this email? O= r do you have major objections, blocking concerns or feedback (if so please= elaborate)? > > 2. Are you willing to author or participate in the development of the dr= afts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the ch= arter should be amended In a significant way, please reply on a separate th= read. > > The feedback provided here will help the IESG come to a decision on the f= ormation of a new WG. Given the constraints of the chartering process, rega= rdless of the outcome of this consensus call, we will be meeting in Vancouv= er as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for= authorization, identity, and API access. This protocol will allow an autho= rizing party to delegate access to client software through an authorization= server. It will expand upon the uses cases currently supported by OAuth 2.= 0 and OpenID Connect (itself an extension of OAuth 2.0) to support authoriz= ations scoped as narrowly as a single transaction, provide a clear framewor= k for interaction among all parties involved in the protocol flow, and remo= ve unnecessary dependence on a browser or user-agent for coordinating inter= actions. > > The delegation process will be acted upon by multiple parties in the prot= ocol, each performing a specific role. The protocol will decouple the inter= action channels, such as the end user=E2=80=99s browser, from the delegatio= n channel, which happens directly between the client and the authorization = server (in contrast with OAuth 2.0 which is initiated by the client redirec= ting the user=E2=80=99s browser). The client and AS will involve a user to = make an authorization decision as necessary through interaction mechanisms = indicated by the protocol. This decoupling avoids many of the security conc= erns and technical challenges of OAuth 2.0 and provides a non-invasive path= for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating= the client requesting access > - A variety of client applications, including Web, mobile, single-page, a= nd interaction-constrained applications > > The group will define extension points for this protocol to allow for fle= xibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of posses= sion > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces= of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resour= ce requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation pr= ocess (including identity) > > Additionally, the group will provide mechanisms for management of the pro= tocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be b= ackwards-compatible with OAuth 2.0 or OpenID Connect, the group will attemp= t to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc= ol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as su= ch will focus on new technological solutions not necessarily compatible wit= h OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develo= ped in the OAuth Working Group, including functionality back-ported from th= e protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic m= ethods, such as JOSE and COSE, to the delegation process. This group is not= chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the c= lient and the authorization server, taking advantage of optimization featur= es of HTTP2 and HTTP3 where possible, and will strive to enable simple mapp= ing to other protocols such as COAP when doing so does not conflict with th= e primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, deta= ched HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Mar 7 12:27:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2432E3A19D8 for ; Sat, 7 Mar 2020 12:27:34 -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, DKIMWL_WL_HIGH=-0.001, 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=spotify.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 acfC1QXTnwir for ; Sat, 7 Mar 2020 12:27:32 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 D9A333A19D5 for ; Sat, 7 Mar 2020 12:27:31 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id n8so1982665wmc.4 for ; Sat, 07 Mar 2020 12:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spotify.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SjD4O4TONr9vWk+o+b89F/aPmPNFiPDcvyC8UGzzkKc=; b=XrIY1ZpFImjg5VGtraCvn9gke1jAy2ca6GsG6PQBVF0ulK1D6vSYZqpBNRffqn2j9o x+/kyQC+6s5D4ymD3sVVg/f9XufEuaWBmL3AKMGBiLsPOBCP9lmxMmMyF0qcjf9ItkD8 D6QYUEo6xhTNuemFwMHCpTc5yxUoWfyAEHV8M= 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=SjD4O4TONr9vWk+o+b89F/aPmPNFiPDcvyC8UGzzkKc=; b=aFTyt/QvywOKF7VcqtYq8y1q2jXBbivGaR1vuab8w3cmeMaLvLAgWvV+u5vNt9+ta4 g5keEW5a5ChqFFFlw94iv9uRdVsEEzV7wFt38W4p7rYovjeJPi9Xat89JEG8lkqRb0Qu ZNrWP0Kh2NRitVhCCioStwgGbjbOgiG8y4eApbB/P9tpE8skcNn0QKjCvUW1C96tT9dc BftB6A4F3zj/m1hPBBmOwEjhi+Zv5iFn33AWFlL505vrPRpESf8bnAZl5TcjwltPeZFG V+Dzze+Kj+eDTOh0AwcQeoUNa5D1pR7D/+P8iAvxjSf4SM6JJ+45nS5Ml0HsD3l3pij5 Voug== X-Gm-Message-State: ANhLgQ2pi4vI+VF9pCzwd1O4F4ogrMPcVmW1OE+Fn87iOlTADUK24QYs Bqe31BbA3o8nc8khDxIaU0I2yxzjSTn8SE+8EIM6Jw== X-Google-Smtp-Source: ADFU+vs120v1UpcDgImK03Obb/+XN34MakOheCR81om/Y4cikROpaQHpEZDKwLRF58a79NqbtK2xOkM8L2NZ2TO6pec= X-Received: by 2002:a1c:b743:: with SMTP id h64mr11014596wmf.88.1583612849680; Sat, 07 Mar 2020 12:27:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aleksei Petrov Date: Sat, 7 Mar 2020 21:27:17 +0100 Message-ID: To: Yaron Sheffer , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005e09cd05a04999ba" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 20:27:34 -0000 --0000000000005e09cd05a04999ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? Yes > 2. Are you willing to author or participate in the development of the > drafts of this WG? Yes > 3. Are you willing to help review the drafts of this WG? Yes > 4. Are you interested in implementing drafts of this WG? Yes ---- Aleksei Petrov | Senior Software Engineer | User Platform Spotify AB Regeringsgatan 19 111 53 Stockholm On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer wrote: > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005e09cd05a04999ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1.=C2=A0= Do you support the charter text provided at the end of this email?=C2=A0 O= r do you have major objections, blocking concerns or feedback (if so please= elaborate)?

Yes=C2=A0
=C2=A0
2.=C2=A0 Are you willing to au= thor or participate in the development of the drafts of this WG?

Yes=C2=A0
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of= this WG?
=C2=A0
Yes=C2=A0
=C2=A0
4.=C2=A0 Are you interested in = implementing drafts of this WG?
=C2=A0
Yes=C2=A0=

----
Alekse= i Petrov=C2=A0| Senior Software Engineer=C2=A0| User Platform

Spotify AB
Regeringsgatan 19
111 53 Stockholm

<= /div>


On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer <= ;yaronf.ietf@gmail.com> wro= te:
Hi Everyone,=
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu= th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i= n proceeding with this work.=C2=A0 Please do so by responding to the follow= ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?= =C2=A0 Or do you have major objections, blocking concerns or feedback (if s= o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the= drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char= ter should be amended In a significant way, please reply on a separate thre= ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for= mation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver= as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---

This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authori= zing party to delegate access to client software through an authorization s= erver. It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework = for interaction among all parties involved in the protocol flow, and remove= unnecessary dependence on a browser or user-agent for coordinating interac= tions.

The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation = channel, which happens directly between the client and the authorization se= rver (in contrast with OAuth 2.0 which is initiated by the client redirecti= ng the user=E2=80=99s browser). The client and AS will involve a user to ma= ke an authorization decision as necessary through interaction mechanisms in= dicated by the protocol. This decoupling avoids many of the security concer= ns and technical challenges of OAuth 2.0 and provides a non-invasive path f= or supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t= he client requesting access
- A variety of client applications, including Web, mobile, single-page, and= interaction-constrained applications

The group will define extension points for this protocol to allow for flexi= bility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possessi= on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc= ess (including identity)

Additionally, the group will provide mechanisms for management of the proto= col lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt = to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol= where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily compatible with = OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope= d in the OAuth Working Group, including functionality back-ported from the = protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic met= hods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.

The initial work will focus on using HTTP for communication between the cli= ent and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin= g to other protocols such as COAP when doing so does not conflict with the = primary focus.

Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d= etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points


--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000005e09cd05a04999ba-- From nobody Sat Mar 7 16:19:45 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4183A1428 for ; Sat, 7 Mar 2020 06:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_NONE=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 oUSvcJ2A2nBo for ; Sat, 7 Mar 2020 06:30:35 -0800 (PST) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 2CDBF3A1427 for ; Sat, 7 Mar 2020 06:30:35 -0800 (PST) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id AaTJjiWlMJHZdAaTKj33MQ; Sat, 07 Mar 2020 07:30:34 -0700 X-CMAE-Analysis: v=2.3 cv=KYasTjQD c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=Zp0L8TXmEty27ntzuMYA:9 a=QEXdDO2ut3YA:10 a=mh4ueyR6XC0F2eu3eXgA:9 a=yNwISwW-LHsqJXiW:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 X-SECURESERVER-ACCT: vladimir@connect2id.com To: txauth@ietf.org From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <6ec848be-8912-be33-9de2-542aed917107@connect2id.com> Date: Sat, 7 Mar 2020 16:30:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060202000608040802080802" X-CMAE-Envelope: MS4wfICvGHiEZfmEDi8SkOWV3jq03r6N7GkNOMjiFiEmlBz6fGH15yeotfUBrWc8C6eLMkUyEJN/aWqqimsC60kRQMKj8ldD8Jbx9JpO3ZV2B9fWcFpl+y/t 070hThABgzhRWfu9azIKcEhcjWNLA81dNDc9h7JGN0dpAQULM4my6IWi Archived-At: Subject: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 14:30:36 -0000 X-List-Received-Date: Sat, 07 Mar 2020 14:30:36 -0000 This is a cryptographically signed message in MIME format. --------------ms060202000608040802080802 Content-Type: multipart/alternative; boundary="------------CBB21F010F1A6A98E0A4BC36" Content-Language: en-US This is a multi-part message in MIME format. --------------CBB21F010F1A6A98E0A4BC36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is the future, so > 1.=C2=A0 Do you support the charter text provided at the end of this em= ail?=C2=A0 Or do you have major objections, blocking concerns or feedback= (if so please elaborate)? Yes > 2.=C2=A0 Are you willing to author or participate in the development of= the drafts of this WG? Not sure I can be of much help here > 3.=C2=A0 Are you willing to help review the drafts of this WG? Yes > 4.=C2=A0 Are you interested in implementing drafts of this WG? Yes Vladimir --=20 Vladimir Dzhuvinov --------------CBB21F010F1A6A98E0A4BC36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

This is the future, so 

1.=C2=A0 Do you support the charter text =
provided at the end of this email?=C2=A0 Or do you have major objections,=
 blocking concerns or feedback (if so please elaborate)?
Yes
2.=C2=A0 Are you willing to author or par=
ticipate in the development of the drafts of this WG?
Not sure I can be of much help here
3.=C2=A0 Are you willing to help review t=
he drafts of this WG?
Yes
4.=C2=A0 Are you interested in implementi=
ng drafts of this WG?
Yes

Vladimir

--=20
Vladimir Dzhuvinov
--------------CBB21F010F1A6A98E0A4BC36-- --------------ms060202000608040802080802 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMDcxNDMwMzNaMC8G CSqGSIb3DQEJBDEiBCAGufSgATR474mR2IAbi1ILQ0CKHyfodQDcf3bE6nfFsDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBABU235effQiQ7uPANabqzIPWnNmu/y89I00uelXrDnzkJ185 rOXuYTqF+f9XvIDQKIqzAnDi7MaPhHWeOG3z8WRh9C7v0F/00eKG+UM2B3HIm6xlBsxfPhTT 0VvGPw2J34/GgaqJXV5ERxhDO63iNICDHalvTF1XkT4V6oyuVc193fN0fogIw5I1/SkPzSzA A+onwKc/vNAVeO5tIAEoxDDK+zcsByUgdOFISacKqrAU+7t10bOD1qU0pdXezNoUGuUJ3NEl Gupa6/6JZijZyy0fKbq7RPJmc/MCU751S++fGgp2FAiuvq+c68Pg2HS0Ckv60qTy7p3j/yjA MQUrhYcAAAAAAAA= --------------ms060202000608040802080802-- From nobody Sat Mar 7 16:20:22 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F6A3A149E for ; Sat, 7 Mar 2020 07:06: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, 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=amanjeev.com header.b=KM64DFlF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2ngBgfVc 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 XtSARiubgqro for ; Sat, 7 Mar 2020 07:06:52 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908773A14A2 for ; Sat, 7 Mar 2020 07:06:52 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B100F21FE9 for ; Sat, 7 Mar 2020 10:06:51 -0500 (EST) Received: from imap8 ([10.202.2.58]) by compute2.internal (MEProxy); Sat, 07 Mar 2020 10:06:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amanjeev.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=JUW1t kDj70928+UeKvtx4Ix7lxX4ZaJ4qUh7RIP5GBQ=; b=KM64DFlFESl6mT5U5Bx3G yV8tnsv3xVLOfrAmaiCp3EFu1fnSnOJz29VV1VxItvzu0IudmJ4q2E7ir9uJy7/v 04PPohw2J7odg8NbXWrAiGeoP8M+j6VIxTw7spwlqcxvvQZamIE2Y32K4GHw2LeT 5O9aL5AUOZ6dEg55Mb6D7Ps42sDfEmYdTNbJ9D2hUpIhvpPZl7as9kT8NPBeZ34B M5g1hEQW21Q4GRJZRKvFm89NBLTBgndeYtRrgOOWsgoHbLQbOKCy6ZKJQV4D2jXP Tlg/khNjRhCVXIDUR1SMoMYE6aQqux6rPykrvuP4essqBsaAFjufsHV63p7CUTI0 A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=JUW1tkDj70928+UeKvtx4Ix7lxX4ZaJ4qUh7RIP5G BQ=; b=2ngBgfVcUdpTHU5qc0BvBioi1Tz8gzfd/UqA++f395VlHC75NBnMxtx6f EBTl3bJdQfc+k+/7pJ69XYRcFywoe4KPI0Ip05gJvk4JxBT17Pq04qdCoXDRlEki lpLgGRXUuxmaglFK7dYdMzFEUx9V9SK80rystapc2HoMdujQlz5QFzn5XmrZGuMa i+f8MSPCtKyLTn4VCYYEWMFKeWh0JrdIiyhbir2LXJCXBX4xmOSz7mp/I+CKuFJa /j7Fh/uG1Lcm6IL5x2fEAfuGyjTymB5k5UWn6z/38UB1ZX7iCXT21nIODIPOq6Sb iba3QbCqeylBvQXv5dWTuO1IFU55g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddugedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdetmhgrnhhjvggvvhcuufgvthhhihdfuceorghjsegr mhgrnhhjvggvvhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrjhesrghmrghnjhgv vghvrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 01F92520093; Sat, 7 Mar 2020 10:06:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <7cd5726f-cda5-4a2c-adc7-d854e0e81a34@www.fastmail.com> In-Reply-To: References: Date: Sat, 07 Mar 2020 10:06:29 -0500 From: "Amanjeev Sethi" To: txauth@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 15:06:55 -0000 X-List-Received-Date: Sat, 07 Mar 2020 15:06:55 -0000 Hello Everyone, I am relatively new here and in fact only been reading OIDC spec for pas= t 6-8 months. I am still trying to grasp the TxAuth by watching Justin's= talks and posts. I am here to mostly see and hopefully participate in s= ome corners of this spec.=20 > 1. Do you support the charter text provided at the end of this email?= =20 > Or do you have major objections, blocking concerns or feedback (if so=20= > please elaborate)? Yes. > 2. Are you willing to author or participate in the development of the= =20 > drafts of this WG? Yes > 3. Are you willing to help review the drafts of this WG? Yes > 4. Are you interested in implementing drafts of this WG? Yes On Fri, Mar 6, 2020, at 11:44 AM, Yaron Sheffer wrote: > Hi Everyone, > =C2=A0 > It appears that momentum is forming around the proposed formation of a= =20 > TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in=20 > proceeding with this work.=C2=A0 Please do so by responding to the fol= lowing=20 > questions: > =C2=A0 > 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0=20 > Or do you have major objections, blocking concerns or feedback (if so=20= > please elaborate)? > =C2=A0 > 2.=C2=A0 Are you willing to author or participate in the development o= f the=20 > drafts of this WG? > =C2=A0 > 3.=C2=A0 Are you willing to help review the drafts of this WG? > =C2=A0 > 4.=C2=A0 Are you interested in implementing drafts of this WG? > =C2=A0 > The call will run for two weeks, until March 21. If you think that the= =20 > charter should be amended In a significant way, please reply on a=20 > separate thread. > =C2=A0 > The feedback provided here will help the IESG come to a decision on th= e=20 > formation of a new WG. Given the constraints of the chartering process= ,=20 > regardless of the outcome of this consensus call, we will be meeting i= n=20 > Vancouver as a BoF. > =C2=A0 > Thanks, > Yaron and Dick > =C2=A0 > --- Charter Text Follows --- >=20 > This group is chartered to develop a fine-grained delegation protocol=20= > for authorization, identity, and API access. This protocol will allow=20= > an authorizing party to delegate access to client software through an=20= > authorization server. It will expand upon the uses cases currently=20 > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAut= h=20 > 2.0) to support authorizations scoped as narrowly as a single=20 > transaction, provide a clear framework for interaction among all=20 > parties involved in the protocol flow, and remove unnecessary=20 > dependence on a browser or user-agent for coordinating interactions.=20= >=20 > The delegation process will be acted upon by multiple parties in the=20= > protocol, each performing a specific role. The protocol will decouple=20= > the interaction channels, such as the end user=E2=80=99s browser, from= the=20 > delegation channel, which happens directly between the client and the=20= > authorization server (in contrast with OAuth 2.0 which is initiated by= =20 > the client redirecting the user=E2=80=99s browser). The client and AS = will=20 > involve a user to make an authorization decision as necessary through=20= > interaction mechanisms indicated by the protocol. This decoupling=20 > avoids many of the security concerns and technical challenges of OAuth= =20 > 2.0 and provides a non-invasive path for supporting future types of=20= > clients and interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single=20 > interaction > - Separation between the party authorizing access and the party=20 > operating the client requesting access > - A variety of client applications, including Web, mobile, single-page= ,=20 > and interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for=20= > flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of=20 > possession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other=20 > pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding=20 > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation= =20 > process (including identity) >=20 > Additionally, the group will provide mechanisms for management of the=20= > protocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers >=20 > Although the artifacts for this work are not intended or expected to b= e=20 > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will=20= > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the= =20 > new protocol where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as= =20 > such will focus on new technological solutions not necessarily=20 > compatible with OAuth 2.0. Functionality that builds directly on OAuth= =20 > 2.0 will be developed in the OAuth Working Group, including=20 > functionality back-ported from the protocol developed here to OAuth 2.= 0. >=20 > The group is chartered to develop mechanisms for applying cryptographi= c=20 > methods, such as JOSE and COSE, to the delegation process. This group=20= > is not chartered to develop new cryptographic methods.=20 >=20 > The initial work will focus on using HTTP for communication between th= e=20 > client and the authorization server, taking advantage of optimization=20= > features of HTTP2 and HTTP3 where possible, and will strive to enable=20= > simple mapping to other protocols such as COAP when doing so does not=20= > conflict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS,=20= > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > From nobody Sat Mar 7 16:20:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D0F3A14BE for ; Sat, 7 Mar 2020 07:17: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, 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 bngk4J-qi8tz for ; Sat, 7 Mar 2020 07:17:52 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450: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 52C3D3A14C0 for ; Sat, 7 Mar 2020 07:17:52 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id r7so5803006wro.2 for ; Sat, 07 Mar 2020 07:17:52 -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=waF5+PoyVQ3c64NbJEXyoLPPjx38DGv2WNrVEtkhaXk=; b=oLyEC30NoH+VAVs3ZBHGnP6GpCzMGRiEGuRgA21lvIjnBwMlavhdF67o7pPX/MIwrs c+0ikmPYix4rZgAm2R3WstgLOH01U6QAE5x5Cjtx5m7BVVL2x7A1rL8OmPgtKpTpx20U FMXcVKcdkbF6y7TV2TKF/P7E/Q23PGjkxh57GISq0WZ3uc4m+8HhNQzO+Owygt98nP+U bhifiGEObtzkorWToou7XIJwo0FEgzy/SckiVZ6GAfenOClsKGUhxvmojks/mz776+5/ IdR0r/t2xM3jDAd6Fyx43zeeYhZJX+Gp3CLfrfFgcp3LJ5klmZa944c+60EwOJl23pdY K/+A== 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=waF5+PoyVQ3c64NbJEXyoLPPjx38DGv2WNrVEtkhaXk=; b=HkEgk95gVBOcadU8/0Zmmk8RBcraPuApidsbyWGJkArPZ6okMiBIDyOcrzboHoDIuj y7sBxN1o8qJQKx67iQjRjNRKnAnkRqCFSwIMxtrYlSDcDO5KqkNV0IIgFAME4LDOQxXN zuxSgtT+UW7A9CyopmbmC2BZy5gFm08DviYZLdTJyVUCVV+DYf0B643pL1zpB+Kr7crO qWWUf4DyxFbsyLQZT1KQ/oZVH5mOzbq2qhVrIc7PniArUn739yJO8YHzPAElSTDpvHTN wt5/2gEg0OQzfqy7UbwH8Rwg59Wdr3SAl92vHiVxzEwHWpH0h+hsJ3YRhtSpsnu0C3qm qTgw== X-Gm-Message-State: ANhLgQ1/GFajeWsAmDWRFmQX8BKkf+y2qEagX64f1qXZheAYfR+xo7sg nOHu8DhJ6rbHwQ8w0mz+nOWIq+JQeQQ= X-Google-Smtp-Source: ADFU+vsZJ8pzGUN3iyr/mHbBDNb9eR/0O36/AnaD1cfnL7+loHVCMgdDgwTNGt+lFlCXoUnCpXaqXA== X-Received: by 2002:adf:ee02:: with SMTP id y2mr9631555wrn.23.1583594270032; Sat, 07 Mar 2020 07:17:50 -0800 (PST) Received: from ?IPv6:2a01:598:a090:1028:9069:f1b5:ad4a:b3a? ([2a01:598:a090:1028:9069:f1b5:ad4a:b3a]) by smtp.gmail.com with ESMTPSA id v16sm36237296wrp.84.2020.03.07.07.17.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Mar 2020 07:17:48 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 7 Mar 2020 16:17:47 +0100 Message-Id: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net> References: Cc: "txauth@ietf.org" In-Reply-To: To: Yaron Sheffer X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 15:17:54 -0000 X-List-Received-Date: Sat, 07 Mar 2020 15:17:54 -0000 --Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : >=20 > =EF=BB=BFHi Everyone, > =20 > It appears that momentum is forming around the proposed formation of a TxA= uth working group. We=E2=80=99d like to more formally gauge interest in pro= ceeding with this work. Please do so by responding to the following questio= ns: > =20 > 1. Do you support the charter text provided at the end of this email? Or= do you have major objections, blocking concerns or feedback (if so please e= laborate)? I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned the s= cope of the charter is too broad, e.g. identify alone is a huge topic. We need to keep an eye on this aspect in order to make sure, the group is ab= le to work effectively and the specs we will be producing are as simple as p= ossible and foster interoperability. > =20 > 2. Are you willing to author or participate in the development of the dra= fts of this WG? yes > =20 > 3. Are you willing to help review the drafts of this WG? yes > =20 > 4. Are you interested in implementing drafts of this WG? yes best regards, Torsten. > =20 > The call will run for two weeks, until March 21. If you think that the cha= rter should be amended In a significant way, please reply on a separate thre= ad. > =20 > The feedback provided here will help the IESG come to a decision on the fo= rmation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver a= s a BoF. > =20 > Thanks, > Yaron and Dick > =20 > --- Charter Text Follows --- >=20 > This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authoriz= ing party to delegate access to client software through an authorization ser= ver. It will expand upon the uses cases currently supported by OAuth 2.0 and= OpenID Connect (itself an extension of OAuth 2.0) to support authorizations= scoped as narrowly as a single transaction, provide a clear framework for i= nteraction among all parties involved in the protocol flow, and remove unnec= essary dependence on a browser or user-agent for coordinating interactions.=20= >=20 > The delegation process will be acted upon by multiple parties in the proto= col, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation c= hannel, which happens directly between the client and the authorization serv= er (in contrast with OAuth 2.0 which is initiated by the client redirecting t= he user=E2=80=99s browser). The client and AS will involve a user to make an= authorization decision as necessary through interaction mechanisms indicate= d by the protocol. This decoupling avoids many of the security concerns and t= echnical challenges of OAuth 2.0 and provides a non-invasive path for suppor= ting future types of clients and interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interactio= n > - Separation between the party authorizing access and the party operating t= he client requesting access > - A variety of client applications, including Web, mobile, single-page, an= d interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for flex= ibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of possess= ion=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resourc= e requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation pro= cess (including identity) >=20 > Additionally, the group will provide mechanisms for management of the prot= ocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers >=20 > Although the artifacts for this work are not intended or expected to be ba= ckwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t= o simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol w= here possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as suc= h will focus on new technological solutions not necessarily compatible with O= Auth 2.0. Functionality that builds directly on OAuth 2.0 will be developed i= n the OAuth Working Group, including functionality back-ported from the prot= ocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying cryptographic me= thods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.=20 >=20 > The initial work will focus on using HTTP for communication between the cl= ient and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping= to other protocols such as COAP when doing so does not conflict with the pr= imary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, detach= ed HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCi4w 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 /crnd7HTmUfqi0yCylHY62wwggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG 9w0BAQsFADCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdv IFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAw MDAwMDBaFw0yMDAxMzAyMzU5NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+d LiC1cbVCWN1TEV1XemJP68/I91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z 8cqcAe+i1JLbvxt5j47h+5iiZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlV IbYTkOIW2/x7NinUBBSvpO0bxlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1Q PO3AB2xA7hES4EjWFZ7a9HhX5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXc B+JQzLW0sdSVxwIDAQABo4IB5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAw HQYDVR0OBBYEFBnmpsoJu2zUGrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8E AjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAw QAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdv UlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEE fjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2Nz cC5zZWN0aWdvLmNvbTAiBgNVHREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG 9w0BAQsFAAOCAQEAKEl922lsOY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW 0cU8qFc7iXRixKdU361AADG+SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj 2OGZ1V/w3VPJxEyYPpSCFJ0gqUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF 6AQe5fNPhpWAfyVfnTHwQpqm5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlT wTfLDI2pfuxRQLJzoCxIYkxgjlq6XtpvolvwKfJpeg44hus5k11RPDGCA70wggO5AgEBMIGiMIGN MQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRy bzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcyAhBpfEIkHQiWmzF6zDsgdF+DMA0GCWCGSAFlAwQC AQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMDcx NTE3NDdaMC8GCSqGSIb3DQEJBDEiBCC+6UxRKUZfkw4U1qfmHboJ4q4f8l3Cf/PsMdJI1zhTyjCB vQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoT D1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqGSIb3DQEBAQUA BIIBAC7IlpNSuGAlQdXXCTq8EWTc1y0e6mXChWE4ENNWvNmJcuYJILxX0Ido6btScQavi20eqk3y n5NEUISNU2F464NGWo5oLzrAx2ptGPFUQ6qgCo2Gf9TxYCU4zOjahfQypdeb5xzYgTbLqQLyZ0+q WqfXvn7zVMYezeih+vhvRspwzQiEyvUSv3nGcfl6RXgTJ+oHVPsqz/1xcPATdOWxbJPoZFdvPWiB 5YHmRfmHpqcS0mjOXPaIssJZW4LCvx3mxWQI58ff9n9wJF6GLgpMeLPoRKs5jlRbyyJBrYTRYQ29 L2CR1qGWRi/ebr1GfZAahk5ipv4FWWXv37RzkGVNE0MAAAAAAAA= --Apple-Mail-6FAC174B-2571-4630-8CC8-D876050C7BE0-- From nobody Sat Mar 7 16:21:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ABD3A152A for ; Sat, 7 Mar 2020 07:53:26 -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 qGaXlbRHTzgl for ; Sat, 7 Mar 2020 07:53:24 -0800 (PST) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) (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 817703A1528 for ; Sat, 7 Mar 2020 07:53:23 -0800 (PST) Received: by mail-ed1-x544.google.com with SMTP id g19so6363238eds.11 for ; Sat, 07 Mar 2020 07:53: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=eFajJbtPZuz8CfAYWQH59gx1DmPezrorW0aj+arjI7Y=; b=l+tU+3EUOh/Egju/ONNNT29OIh+SVYKk2agEDyNdGtnePXfKZwdEOTJwTLFw3ElsiH La70PIJ+9LJA46EJNMk6yy968OL6TlhojOipgzo+2/SnylcPU219atHXl639z3DIpWxd g5UUD4pqXkFuq69XP/c3YvTuCVRrxBllUj01pR6TWE9BYfnrqw+B1uxH0GuYVwscx881 3Hegt3KPcWRE0bZpB8gA2VUioEVudD27oh0T2OwzI88Il9o7Xxlrat530TOcoTshlQt5 hIRnLWEsdik8F6Plh0+txQlWBG+cm6XNvxfTziPUB5mx6Y9Li22jOkK62PylYEv5iMex 2WYQ== 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=eFajJbtPZuz8CfAYWQH59gx1DmPezrorW0aj+arjI7Y=; b=p28GOTOG6YECozzisN4E8qIhuxSbOupmsLFUPnEjnYJhKnQDi5JnKpWv8RvY7PLQ/z jLGh+vBMzGGCUn46DH8PBiM86u/i0F5TXb26M/6LAir9UWfHJncQL+dSOB99e+9rW1go pdgj+o/iaggN8o//qIqBZ9owBUbhZ0t8+4c0ASWGnR+c/4Fy4wnOUdX1nI23OUWivTuz xcc2mVV2+eLUwRteMe4hLiqzQe8nlVme/feFxc7DBHEFFZxkFhUb0Jk39jYJYDXKANow /qjx6WI4H3ppB5kWZ/y0Zc7duCPWDaEhIP3l+lV6dmNlE3IaK6qzJaGaQ8nS+MMqbVWn Ex5g== X-Gm-Message-State: ANhLgQ3pO4EI0+nPSlzSvnZb/ni27vW7Y6iWmrh0Htr64I2rmIvgRhnD vCLR/qHBwpTEWd/TTzLmcAveXXaB7ZbnMrp3giO4CZ/pL2c= X-Google-Smtp-Source: ADFU+vsVQHd4ruK9Zql2wa8IwNAISMLKu07DYZhD9X5S4GWIjeiiYvYZ9WxtdRdoWabT42dQhQlkIb5dQxa1PhZ7tnU= X-Received: by 2002:a05:6402:b85:: with SMTP id cf5mr8601822edb.27.1583596401840; Sat, 07 Mar 2020 07:53:21 -0800 (PST) MIME-Version: 1.0 References: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net> In-Reply-To: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net> From: David Skaife Date: Sat, 7 Mar 2020 15:53:10 +0000 Message-ID: To: Yaron Sheffer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ffd77605a045c451" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 15:53:26 -0000 X-List-Received-Date: Sat, 07 Mar 2020 15:53:26 -0000 --000000000000ffd77605a045c451 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I'm fairly new to this group (and the OAuth group) but I'm hoping to participate and help here. > 1. Do you support the charter text provided at the end of this email? Or do you have major objections, blocking concerns or feedback (if so please elaborate)? Yes. I share some of the same concerns that Torsten has highlighted, but overall I'm happy with the charter text. I like that it explicitly states that we're aiming to create a *protocol*, not a *framework *(like OAuth 2.0 was). > > 2. Are you willing to author or participate in the development of the drafts of this WG? Yes, I will help as much as my time permits. > > 3. Are you willing to help review the drafts of this WG? Yes. > > 4. Are you interested in implementing drafts of this WG? Yes. Many thanks, David Skaife On Sat, Mar 7, 2020 at 3:17 PM Torsten Lodderstedt wrote: > Hi, > > > Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : > > > > =EF=BB=BFHi Everyone, > > > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > > > 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned th= e scope of the > charter is too broad, e.g. identify alone is a huge topic. > > We need to keep an eye on this aspect in order to make sure, the group is > able to work effectively and the specs we will be producing are as simple > as possible and foster interoperability. > > > > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > yes > > > > > 3. Are you willing to help review the drafts of this WG? > > yes > > > > > 4. Are you interested in implementing drafts of this WG? > > yes > > best regards, > Torsten. > > > > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > > > Thanks, > > Yaron and Dick > > > > --- Charter Text Follows --- > > > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > > > Additionally, the delegation process will allow for: > > > > - Fine-grained specification of access > > - Approval of AS attestation to identity claims > > - Approval of access to multiple resources and APIs in a single > interaction > > - Separation between the party authorizing access and the party > operating the client requesting access > > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > > - Cryptographic agility for keys, message signatures, and proof of > possession > > - User interaction mechanisms including web and non-web methods > > - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > > - Optimized inclusion of additional information through the delegation > process (including identity) > > > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > > > - Discovery of the authorization server > > - Revocation of active tokens > > - Query of token rights by resource servers > > > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > > > Milestones to include: > > - Core delegation protocol > > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > > - Identity and authentication conveyance mechanisms > > - Guidelines for use of protocol extension points > > > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ffd77605a045c451 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm fairly new to this group (and the OAuth= group) but I'm hoping to participate and help here.

=
> 1.=C2=A0 Do= you support the charter text provided at the end of this email?=C2=A0 Or d= o you have major objections, blocking concerns or feedback (if so please el= aborate)?

Yes. I share some of the same concerns that Torsten= has highlighted, but overall I'm happy with the charter text. I like t= hat it explicitly states that we're aiming to create a protocol,= not a framework (like OAuth 2.0 was).

>=C2=A0
> 2.=C2=A0 Are you willing= to author or participate in the development of the drafts of this WG?
<= br>Yes, I will help as much as my time permits.

>=C2=A0
> 3.=C2=A0 Are yo= u willing to help review the drafts of this WG?

Yes.

>=C2=A0
> 4.= =C2=A0 Are you interested in implementing drafts of this WG?=C2=A0= =C2=A0

Yes.


Many thanks,
David Skaife


On Sat, Mar 7= , 2020 at 3:17 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote= :
Hi,

> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>
> =EF=BB=BFHi Everyone,
>=C2=A0
> It appears that momentum is forming around the proposed formation of a= TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge inter= est in proceeding with this work.=C2=A0 Please do so by responding to the f= ollowing questions:
>=C2=A0
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?

I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned the = scope of the charter is too broad, e.g. identify alone is a huge topic.

We need to keep an eye on this aspect in order to make sure, the group is a= ble to work effectively and the specs we will be producing are as simple as= possible and foster interoperability.

>=C2=A0
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?

yes

>=C2=A0
> 3.=C2=A0 Are you willing to help review the drafts of this WG?

yes

>=C2=A0
> 4.=C2=A0 Are you interested in implementing drafts of this WG?

yes

best regards,
Torsten.

>=C2=A0
> The call will run for two weeks, until March 21. If you think that the= charter should be amended In a significant way, please reply on a separate= thread.
>=C2=A0
> The feedback provided here will help the IESG come to a decision on th= e formation of a new WG. Given the constraints of the chartering process, r= egardless of the outcome of this consensus call, we will be meeting in Vanc= ouver as a BoF.
>=C2=A0
> Thanks,
> Yaron and Dick
>=C2=A0
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an au= thorizing party to delegate access to client software through an authorizat= ion server. It will expand upon the uses cases currently supported by OAuth= 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support autho= rizations scoped as narrowly as a single transaction, provide a clear frame= work for interaction among all parties involved in the protocol flow, and r= emove unnecessary dependence on a browser or user-agent for coordinating in= teractions.
>
> The delegation process will be acted upon by multiple parties in the p= rotocol, each performing a specific role. The protocol will decouple the in= teraction channels, such as the end user=E2=80=99s browser, from the delega= tion channel, which happens directly between the client and the authorizati= on server (in contrast with OAuth 2.0 which is initiated by the client redi= recting the user=E2=80=99s browser). The client and AS will involve a user = to make an authorization decision as necessary through interaction mechanis= ms indicated by the protocol. This decoupling avoids many of the security c= oncerns and technical challenges of OAuth 2.0 and provides a non-invasive p= ath for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single intera= ction
> - Separation between the party authorizing access and the party operat= ing the client requesting access
> - A variety of client applications, including Web, mobile, single-page= , and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for = flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of pos= session
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pie= ces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding res= ource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation= process (including identity)
>
> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to b= e backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att= empt to simplify migrating from OAuth 2.0 and OpenID Connect to the new pro= tocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as= such will focus on new technological solutions not necessarily compatible = with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be dev= eloped in the OAuth Working Group, including functionality back-ported from= the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographi= c methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between th= e client and the authorization server, taking advantage of optimization fea= tures of HTTP2 and HTTP3 where possible, and will strive to enable simple m= apping to other protocols such as COAP when doing so does not conflict with= the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, de= tached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth --
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ffd77605a045c451-- From nobody Sat Mar 7 19:17:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB853A0791 for ; Sat, 7 Mar 2020 19:17: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_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=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 SOxezQ0Tr2iE for ; Sat, 7 Mar 2020 19:17:25 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 A91953A078C for ; Sat, 7 Mar 2020 19:17:24 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id j17so348653lfe.7 for ; Sat, 07 Mar 2020 19:17: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=rpB2/WrOYFwSx7l+N0S9w9hdy8PkW0NAKFjts/kcAg0=; b=DwAu4m8WNQomdSK0l3CffMUfiMB1hWw6dnRALj/iy2046fTr7V5JcUx8IIDW3IRYYt zHrbP2jCDTXymBGmOqoStisLpkLzwqBupuR+NXmJiNfXtnR2ZQxrGdnaTeXrjHRY81XH NfDat8sxFLIlE0FAVJHFoOr731bZSyLtbGq7xqFvMDfJiNmnqHCxVKO4nA85KAGqmEqr NiHkTjWP9/Dyp/1OPfKr1sc3zVxd6PSK7yHgFVVg8astlKKpkwQeswGMzqMOWjs6rBHz OEwtz3CW95BYNQl1tU3D7R/ZTQFYek6Qe2DmkW+8y8jriFNiKsqijo5Uhqk32UhRo1Qy BuBg== 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=rpB2/WrOYFwSx7l+N0S9w9hdy8PkW0NAKFjts/kcAg0=; b=IvjsROVEIlEWbdEOV6VRSbVsbQRbHyVgulkS1NQTgmb4aOJ8oat0y4XqQlFnMmPnja eRpPQ92EaUPxC0j7dERKQbFcVo/jAMU/DXd0Dd3aXmWLfxJxT2iaklztjLn7kbmJxuus B//rS7+UMPUSiU2W/fGj5zA8JzLW77ZaADj9QQ0ZimidwYd7Ci5MFBiqzcQfcaQP1Wyo 0RdDBbX8GTVLtYZuUxuHR/0nf4u3uIuWPMY1nDWE1CuRksxYqlY8zbcuX4qQqPdSg3m1 2Z9yJMCBkXakGoa+9XkryRYbEo1D2OIpoK4tmu/ExBw8pu+A0UIW5UgkolevFQY3sW9p yLLQ== X-Gm-Message-State: ANhLgQ3ZkQzWyovN04HzB4jVlnOnuZFIE/p4z2iiu+GPAvQMhf8k5PEX SjIAg5vurOmC4PcqUuwWaRIW8/Qm3ttVeOyenNoz2woHt0s= X-Google-Smtp-Source: ADFU+vvbTAn6QjvZiubjcpPRwlUTtL17h5JYJlTk56Um9+7XWCtj+7rO28LNLgthbuf0+RVT4LMM6DTlyZ+r2mA+LVI= X-Received: by 2002:ac2:4c36:: with SMTP id u22mr5902669lfq.91.1583637442088; Sat, 07 Mar 2020 19:17:22 -0800 (PST) MIME-Version: 1.0 References: <158363691397.25530.3652753138946434165@ietfa.amsl.com> In-Reply-To: <158363691397.25530.3652753138946434165@ietfa.amsl.com> From: Dick Hardt Date: Sat, 7 Mar 2020 19:16:56 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000003053c005a04f5316" Archived-At: Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-05.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 03:17:27 -0000 --0000000000003053c005a04f5316 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please forgive, and point out inconsistencies! If anything is confusing, please let me know. It is likely a mistake on my part! 1. I'm proposing there are only 2 types of interactions defined: a redirect interaction where the Client can redirect to the GS, and the GS back to the Client; or an indirect interaction where the User somehow ge= ts to the GS, and there is no redirect back to the Client. The security characteristics are different, as session fixation can be prevented if t= he GS redirects back to the Client as the Client is able to verify the User= it is interacting with is the same as the User the GS is interacting with. 2. I added a sequence where the Client does a PATCH on the Grant URI with an interaction nonce received from the GS in the redirect back to t= he Client to protect against fixation attacks. 3. The Authorization lifecycle and management is now independent of the Grant. A Client now receives an access token, OR an AuthZ URI. Reading a= nd refreshing an access token are the same thing. A more complete list of changes is below: draft-hardt-xauth-protocol-05 - separated claims from identifiers in request user object - simplified reciprocal grant flow - reduced interactions to redirect and indirect - simplified interaction parameters - added in language for Client to verify interaction completion - added Verify Grant API and Interaction Nonce - replaced Refresh AuthZ with Read AuthZ. Read and refresh are same operation. ---------- Forwarded message --------- From: Date: Sat, Mar 7, 2020 at 7:08 PM Subject: New Version Notification for draft-hardt-xauth-protocol-05.txt To: Dick Hardt A new version of I-D, draft-hardt-xauth-protocol-05.txt has been successfully submitted by Dick Hardt and posted to the IETF repository. Name: draft-hardt-xauth-protocol Revision: 05 Title: The XAuth Protocol Document date: 2020-03-07 Group: Individual Submission Pages: 59 URL: https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt Status: https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol= / Htmlized: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-05 Abstract: Client software often desires resources or identity claims that are independent of the client. This protocol allows a user and/or resource owner to delegate resource authorization and/or release of identity claims to a server. Client software can then request access to resources and/or identity claims by calling the server. The server acquires consent and authorization from the user and/or resource owner if required, and then returns to the client software the authorization and identity claims that were approved. This protocol can be extended to support alternative authorizations, claims, interactions, and client authentication mechanisms. 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 =E1=90=A7 --0000000000003053c005a04f5316 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please forgive, and poin= t out inconsistencies! If anything is confusing, please let me know. It is = likely a mistake on=C2=A0my part!

  1. I'm proposing= there are only 2 types of interactions defined: a redirect interaction whe= re the Client can redirect to the GS, and the GS back to the Client; or an = indirect interaction where the User somehow gets to the GS, and there is no= redirect back to the Client. The security characteristics=C2=A0are differe= nt, as session fixation can be prevented if the GS redirects back to the Cl= ient as the Client is able to verify the User it is interacting with is the= same as the User the GS is interacting with.=C2=A0
  2. = I added a sequence where the Client does a PATCH on the Grant URI with an i= nteraction nonce received=C2=A0from the GS in the redirect back to the Clie= nt to protect against fixation attacks.
  3. The A= uthorization lifecycle and management is now independent of the Grant. A Cl= ient now receives an access token, OR an AuthZ URI. Reading and refreshing = an access token are the same thing.=C2=A0
A more complete list of changes is below:

draft-hardt-xauth-protocol-05

  • separat= ed claims from identifiers in request user object
  • simplified reciprocal grant= flow
  • reduced interactions to redirect and indirect
  • simplified interaction para= meters
  • added in language for Client to verify interaction completion<= /li>
  • added = Verify Grant API and Interaction Nonce
  • replaced Refresh AuthZ with Read AuthZ= . Read and refresh are same operation.

---------- Forwarded message ----= -----
From: <internet-drafts@ietf.org>
Date: Sat, Mar 7, 2020 at= 7:08 PM
Subject: New Version Notification for draft-hardt-xauth-protoco= l-05.txt
To: Dick Hardt <dick= .hardt@gmail.com>



A new version of I-D, draft-hardt-xauth-protocol-05.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The XAuth Protocol
Document date:=C2=A0 2020-03-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 59
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardt-xauth-prot= ocol-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-hardt-xauth-protocol-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 05

Abstract:
=C2=A0 =C2=A0Client software often desires resources or identity claims tha= t are
=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a= nd/or
=C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea= se of
=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re= quest access
=C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2= =A0 The
=C2=A0 =C2=A0server acquires consent and authorization from the user and/or=
=C2=A0 =C2=A0resource owner if required, and then returns to the client sof= tware
=C2=A0 =C2=A0the authorization and identity claims that were approved.=C2= =A0 This
=C2=A0 =C2=A0protocol can be extended to support alternative authorizations= ,
=C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.



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


=E1=90=A7
--0000000000003053c005a04f5316-- From nobody Sun Mar 8 03:23:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2E3A08AB for ; Sun, 8 Mar 2020 03:22:58 -0700 (PDT) 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 0xPEnYLPisbT for ; Sun, 8 Mar 2020 03:22:57 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 95CC13A08AA for ; Sun, 8 Mar 2020 03:22:57 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id q128so6323004iof.9 for ; Sun, 08 Mar 2020 03:22:57 -0700 (PDT) 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=MG02uSB2o0TiWil41hZLB4odLBco//6M6zr7Zn58xtk=; b=Y5C676wAa14MtSiDlU1Kr1+q5tGffP4G0KH7WqQVt1lHcfaB0zV+khBcIDsGfjDQu9 z7ULcfOoxWmeigUh+3jEEzLzXJ1JMlqMo5/TowWcGKVgtDY0HpYYAdh/L+UEj85VQBUf Evr3yjRnWDwJxCmn3E1N3AESMMCMc/Dx4cXTgtCjLkOzaOKLYueCFPkkXRSCy1Hn+oyg qj1SgoxAGy74bPEhl9W9EN9GcsYX1pxrFKO68MxYyyv0/G/+H4VUMAsCiK4igvMvN/HP MWP3AH1gVmnETqYTSipzC7+5wcrMigbnouSKOw1hfwpNbFOZh4tkZfW57CFLtIpw89UQ SeTQ== 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=MG02uSB2o0TiWil41hZLB4odLBco//6M6zr7Zn58xtk=; b=lKHh8XAWgsrId5YEw8JOao82Ugpv7cHwk1HTEIvkG2WaToY2hjvyrbl4eAhnAEpeb9 1ebCRiXtJEFu+SzXnyltTWQNFXmLX/HIQFR740V7BHP04qcq7D45PtXsRDbEoeKJd0Mw 5KCKYWol9ozRZ5SpXegF3SCJuyYl+mbd3E0C2dZld/bHfyq7inHaDyncca6fet0Fc0Wa bJGzSk3p0nVhbYyqrAPEpjdGuLz1BDFkgVn2QOw3BEzqQMb5hm9aXgehzBCY1CAj8qGs FiGp5AoYtq1IWdPljkStXH39VOQMZTw/eRyNoti+W24iNIAmXBi+HAp7X+kPYJmoRll4 iYvQ== X-Gm-Message-State: ANhLgQ26OqCsKpDgeW+kvbsvIojgX4sYAkPKgosgJVxKS6pC0+ITkhRS h0FmWPuahdbfNf8Aso1tqDHQ9COviSkIX3Zz+YIaigeJyqQ= X-Google-Smtp-Source: ADFU+vvdgFrsKWZBVVjjcFsqP6lsKglGA5G3UtyhbkmZqJaiN/6OIWsao7FyqK7UCsCWW2Oqqu4sL4Herjoe8IFEWM4= X-Received: by 2002:a02:c815:: with SMTP id p21mr11001065jao.20.1583662976475; Sun, 08 Mar 2020 03:22:56 -0700 (PDT) MIME-Version: 1.0 From: Vijay IETF Date: Sun, 8 Mar 2020 15:52:45 +0530 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002829fa05a055459a" Archived-At: Subject: [Txauth] Response to Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 10:22:59 -0000 --0000000000002829fa05a055459a Content-Type: text/plain; charset="UTF-8" Hi All, I recently subscribed to the TxAuth WG mailing list after the Call for charter consensus was posted. Therefore I am unable to reply to it directly (as far as my knowledge of Mailman goes) because I don't have it in my inbox. Apologies if this creates a new thread but I have been advised that it is okay to do so. My response to the consensus call is as below. 1. Do you support the charter text provided at the end of this email? Or > do you have major objections, blocking concerns or feedback (if so please > elaborate)? Yes. > 2. Are you willing to author or participate in the development of the > drafts of this WG? Yes > 3. Are you willing to help review the drafts of this WG? Yes > 4. Are you interested in implementing drafts of this WG? Yes --- Brief aside: My interest in this WG arises from my core belief that *consent* should be transactional with an expires header. And that the Internet identity layer (which OIDC claims to be) is fundamentally broken. So when I read the charter it gave me hope and encouraged me to join this list. I think this is a timely initiative and I will be happy to contribute in any manner the WG finds suitable. Thanks and regards! Vijay --0000000000002829fa05a055459a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I recently subscribe= d to the TxAuth WG mailing list after the=C2=A0 Call for charter consensus was posted. Therefore I am unable to reply to it=20 directly (as far as my knowledge of Mailman goes) because I don't have= =20 it in my inbox. Apologies if this creates a new thread but I have been advi= sed that it is okay to do so.

My response to t= he consensus call is as below.

1.=C2=A0 Do you support the charter text provided at the end of this email?=C2=A0 O= r=20 do you have major objections, blocking concerns or feedback (if so=20 please elaborate)?

Yes.
=C2=A0
=
2.=C2=A0 Are you willing = to author or participate in the development of the drafts of this WG?

Yes=C2=A0
=C2=A0
3.=C2=A0 Are you willing to help review the draf= ts of this WG?
=C2=A0
Yes=C2=A0
=C2=A0
<= 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">4.=C2=A0 Are you intereste= d in implementing drafts of this WG?
=C2=A0
Yes =
---

Brief aside:

=
My interest in this WG arises from my core belief that *consent*= should be transactional with an expires header. And that the Internet iden= tity layer (which OIDC claims to be) is fundamentally broken.

So when I read the charter it gave me hope and encouraged = me to join this list. I think this is a timely initiative and I will be hap= py to contribute in any manner the WG finds suitable.

<= div>Thanks and regards!

Vijay

--0000000000002829fa05a055459a-- From nobody Sun Mar 8 12:44:12 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE243A0869 for ; Sun, 8 Mar 2020 12:44:09 -0700 (PDT) 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, 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=sunet.se 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 5XUmw6rLe8Np for ; Sun, 8 Mar 2020 12:44:07 -0700 (PDT) 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 F1D523A0873 for ; Sun, 8 Mar 2020 12:44:06 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id e18so7690906ljn.12 for ; Sun, 08 Mar 2020 12:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=79kPRdCgabLqd45Y0RXubmfu19ECrZ78QOpQeAVEpM4=; b=Uxenxtf68pJrOwGZ1rhhTPQu43DuyGId1E/XWW9rkUfsO9clFzGEzrDeoT12mQElZA rFzVeMdkoC6D9c92HatyPd3Ms6nvs51N9e5P3tQWcbOOBEIWCgbXdfim7rZrntUn9Rmy 5F/8Dn948Bhxhpx9jEeAjVZy4sBjO8RKD+z2wiasMtskhF4LXJA7pPBvxO9Qw9DesIlg AxUoJihIJIO14DEqGo5oz93oYDAxhADotKMxnT/bQmzdEZEdK0KvilDg91uUOlozUcvt b64SjaYcgTGF434nqBvsqlQVJ8r6TEBtoyfp/l6tGrmyoo4ymZd1lb2fap4CPCrLLbwk w+Rg== 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=79kPRdCgabLqd45Y0RXubmfu19ECrZ78QOpQeAVEpM4=; b=n3UDGYGmXs8wTKtpNMmCy3A8Un3Y7HGn1XfKpCAYVpqLDIBKs63K9KyXjYKyi43RCu W+GZq5y+QhUNXogEBS+D55BAni8FWLoBDsx/Kw8kIqlsDpxMhNk8Luvn85eFutiXAAvf Gg2PL0Bd0jkaE6HAqS/G45aknLQQs+XcuXXXHTiFoGpksPQUZ++jS+Uec7dEjSOEvCCs gtf3V3ZjnDa39fTqIv9sLDl44/41bGd53ywZOB6xCM7M73vxwUsquHf2cSWpqmq4+r2R aWFuK/vExRvKHAMYXwcdFrFUXwhrngL2Ggnb8zOVa4nGr7iJc7UFXztLenE2gmJN4ujx SADw== X-Gm-Message-State: ANhLgQ3u5WP3d7hToaXPunMDPCWl6uWAPzGwxEhR31SIq4mVgJ0gyW9x UPAQIr7cbeQSipBfMm5BO8gI/o/0QmY= X-Google-Smtp-Source: ADFU+vsoRD1TFanzcEDV7JyiEVv4bLFkX4broBDcr2cg7hHBE8JLsfF9iVICQdwiPcA5hSAvcRV1ww== X-Received: by 2002:a2e:9b90:: with SMTP id z16mr7931929lji.254.1583696644341; Sun, 08 Mar 2020 12:44:04 -0700 (PDT) Received: from [10.0.0.192] (h-158-174-186-56.NA.cust.bahnhof.se. [158.174.186.56]) by smtp.gmail.com with ESMTPSA id k24sm1371826ljc.25.2020.03.08.12.44.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Mar 2020 12:44:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Leif Johansson Mime-Version: 1.0 (1.0) Date: Sun, 8 Mar 2020 20:44:01 +0100 Message-Id: References: Cc: "txauth@ietf.org" In-Reply-To: To: Yaron Sheffer X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 19:44:10 -0000 Skickat fr=C3=A5n min iPhone > 6 mars 2020 kl. 17:45 skrev Yaron Sheffer : >=20 > =EF=BB=BFHi Everyone, > =20 > It appears that momentum is forming around the proposed formation of a TxA= uth working group. We=E2=80=99d like to more formally gauge interest in pro= ceeding with this work. Please do so by responding to the following questio= ns: > =20 > 1. Do you support the charter text provided at the end of this email? Or= do you have major objections, blocking concerns or feedback (if so please e= laborate)? Yes > =20 > 2. Are you willing to author or participate in the development of the dra= fts of this WG? > =20 Review more than author probably > 3. Are you willing to help review the drafts of this WG? > =20 Yes > 4. Are you interested in implementing drafts of this WG? Yes=20 > =20 > The call will run for two weeks, until March 21. If you think that the cha= rter should be amended In a significant way, please reply on a separate thre= ad. > =20 > The feedback provided here will help the IESG come to a decision on the fo= rmation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver a= s a BoF. > =20 > Thanks, > Yaron and Dick > =20 > --- Charter Text Follows --- >=20 > This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authoriz= ing party to delegate access to client software through an authorization ser= ver. It will expand upon the uses cases currently supported by OAuth 2.0 and= OpenID Connect (itself an extension of OAuth 2.0) to support authorizations= scoped as narrowly as a single transaction, provide a clear framework for i= nteraction among all parties involved in the protocol flow, and remove unnec= essary dependence on a browser or user-agent for coordinating interactions.=20= >=20 > The delegation process will be acted upon by multiple parties in the proto= col, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation c= hannel, which happens directly between the client and the authorization serv= er (in contrast with OAuth 2.0 which is initiated by the client redirecting t= he user=E2=80=99s browser). The client and AS will involve a user to make an= authorization decision as necessary through interaction mechanisms indicate= d by the protocol. This decoupling avoids many of the security concerns and t= echnical challenges of OAuth 2.0 and provides a non-invasive path for suppor= ting future types of clients and interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interactio= n > - Separation between the party authorizing access and the party operating t= he client requesting access > - A variety of client applications, including Web, mobile, single-page, an= d interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for flex= ibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of possess= ion=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resourc= e requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation pro= cess (including identity) >=20 > Additionally, the group will provide mechanisms for management of the prot= ocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers >=20 > Although the artifacts for this work are not intended or expected to be ba= ckwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt t= o simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol w= here possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as suc= h will focus on new technological solutions not necessarily compatible with O= Auth 2.0. Functionality that builds directly on OAuth 2.0 will be developed i= n the OAuth Working Group, including functionality back-ported from the prot= ocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying cryptographic me= thods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.=20 >=20 > The initial work will focus on using HTTP for communication between the cl= ient and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping= to other protocols such as COAP when doing so does not conflict with the pr= imary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, detach= ed HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Mon Mar 9 02:12:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35933A0AD3 for ; Mon, 9 Mar 2020 02:12:09 -0700 (PDT) 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 Os52wsEyj3Sc for ; Mon, 9 Mar 2020 02:12:08 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 55DC43A0B00 for ; Mon, 9 Mar 2020 02:12:08 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id r15so8413428iog.0 for ; Mon, 09 Mar 2020 02:12:08 -0700 (PDT) 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=0ebz20upW8xx3EeTtTr5T6E9i+DGMELukHKsrZ2hYwg=; b=cbQITygCIv67tI0BveTyVfyX42jzblyRb38c+iciJuhm8EN6Fw8nqVQOWgLyzpIkwb Anae92fy0Iyct85IeVlL3lYuFnNXaKCGpIcqpEp/67mop8Tv1Xq2wZtvZfu/LlB7VubE SQgpx92AKkvDBN0f1FYrADG0Tl/csAbN7sG6nJ9bgE5xJ2GOvuCDreCCjeU1tmiikMXD x8cPIJYWog3B0y5FS+Hl8tMhPz1bJi0BxsXwh4Athc1gvWfTbQDdWbC55AOewjJAuC11 NnGVQGsogMk/C8UQgpXI4J9kCzKFVnZFd2BjaEtSEmxbroQEMTD2iQESpLP4vFBfEROH ODYg== 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=0ebz20upW8xx3EeTtTr5T6E9i+DGMELukHKsrZ2hYwg=; b=N+0deXbStb62a9oyH1ADFbAZXfq8s0R0UyhDNTOwctw24+Wu67VpxWlx6bwpCDUExG vcwshTHnmKwBc/ebm/4kAUyHitwB3F+M2Ntoa6EvEuRSWDZviUYQy8FfvsotTi467HBs pYpgwEFEnpe0GDASO+B6c7HoXsmaow0n/zzrNZCVoWeg9pYx3Dp9/6kgeEZrB/b2SlaK RhWNlq0JGLXAjN8etmIb0X6+ftkL64PhKng/oQ4EB8LZHJAeVUWwkg2lwwBBf8cvNGRY Pk6F7KmU9IPff+Zr51xWu8UlubjVJaEIX7tUXq3M3B/SKz/R32Jep4tqJVoNRSfES2Yn IJnQ== X-Gm-Message-State: ANhLgQ2pWn0e6LVhReTG3QbFVYVDBUG5dzHqpFK9JG6KSd9oddiXMb1W UCmaD9OAtFO7NNCOr7bCbDKoEl7jfapWJsJ8wsWj1Yxj X-Google-Smtp-Source: ADFU+vuIF+7BJRo2TJtQFLICGKpnGbVfaDTUcnmPISm5AvndzhcPOaG+KcATq7us3M3i2R8SeegdlMJS0+EfWD5n/AE= X-Received: by 2002:a5d:9ed4:: with SMTP id a20mr12680058ioe.187.1583745127242; Mon, 09 Mar 2020 02:12:07 -0700 (PDT) MIME-Version: 1.0 From: Vijay IETF Date: Mon, 9 Mar 2020 14:41:55 +0530 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b95f8705a06865fd" Archived-At: Subject: [Txauth] XAuth vs AuthZ vs ... X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 09:12:19 -0000 --000000000000b95f8705a06865fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I spent yesterday catching up with the mailing list. That was too much to digest in a day and I am still trying to figure out the boundaries and scope. One thing that is not clear is regarding the multiple proposals in draft form that have been going around. The best disambiguation I could find was: > To disambiguate between different efforts, I=E2=80=99ll refer to Dick=E2= =80=99s draft as XAuth, my own draft as XYZ, and the proposed working group= work here (as in our eventual output) as TxAuth. My question is do these proposals converge, compete or the best one by consensus or otherwise supersedes the other? Apologies if that is a dumb question. A map of efforts/proposals/drafts of this WG would be quite helpful to new comers such as myself. Thx! --- Vijay --000000000000b95f8705a06865fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I spent yesterday catchi= ng up with the mailing list. That was too much to digest in a day and I am = still trying to figure out the boundaries and scope.

One thing that is not clear is regarding the multiple proposals in = draft form that have been going around.

The be= st disambiguation I could find was:
> To disambiguate between different efforts, I=E2=80=99ll refer to Dick=
=E2=80=99s draft as XAuth, my own draft as XYZ, and the proposed working gr=
oup work here (as in our eventual output) as TxAuth.
My qu= estion is do these proposals converge, compete or the best one by consensus= or otherwise supersedes the other?

Apologies if t= hat is a dumb question. A map of efforts/proposals/drafts of this WG would = be quite helpful to new comers such as myself. Thx!

---
Vijay
--000000000000b95f8705a06865fd-- From florianb@spotify.com Mon Mar 9 02:15:24 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9A3A0AEF for ; Mon, 9 Mar 2020 02:15:23 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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=spotify.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 JwyWnG0iXJBf for ; Mon, 9 Mar 2020 02:15:21 -0700 (PDT) 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 C43DE3A0AEB for ; Mon, 9 Mar 2020 02:15:21 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id a14so4846217ilk.6 for ; Mon, 09 Mar 2020 02:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spotify.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N7a2Yv6NBqoYRSWeRfjdEqiKC0n9eTvNWwrEvuhba+E=; b=YuHyzefVkN7cX3snyopcTn8Fei2e7BX4XR7VULSpgYjbgKPkAZK3EQ3de3/THBE8Yg t55SGTGoGegLVSBdo/iZUAeOoLvrr3gg09XDaECs9f/RBBZWdy3RLDmNdb6BAN2uVgmA ePRc9Lui4IhGdVnCiUYbBNrI0qVS2mqEXfknI= 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=N7a2Yv6NBqoYRSWeRfjdEqiKC0n9eTvNWwrEvuhba+E=; b=MxNCactDzAaUanPLiCMv5BlsfZFVJjruoKglyJhMET90oiC/Wt6TSV9azKHZAYVui2 T+15l70jgv7M12O777YhYBS9QYVWUVEjT4Cdqqt8dlwBY1J1EuWjGt70vBvLmpHI9oIk X20JiPL73LCIaTyNBfepRPMr8uW2VNM5CN9jt618rDz9/kXOwwaTbQ+r+GC8fWT+SYJb S5hec1WLkZXUU7qBvDHnpv385CKPRDDjjLUE5ElpjyA32b1BAJ/v9PYWO6sUoYHuLz3V 9gtlU8ANeDh9a1zf+zu9n8/wWBQ7gqBPeHxvgyl1iRyFPcaVy+CYSB71nd1wxjdAFPbl lxtw== X-Gm-Message-State: ANhLgQ3TB9Tb1k3BTNCYoPZhJGXhKxjmOSdrIMbU6gzSbDF0YI4iawR9 6uHH4RgIXJlYJGkCbrFOpKdd3Ox1ICh3pnl8IiCjWg== X-Google-Smtp-Source: ADFU+vslInRsrwrx6m9hygOB+dDCRTAhTV7QZyNbGjs58XZLSkSix5FMPniPo6UO0c0e742WkeoMGhLwEq9G4urAmSg= X-Received: by 2002:a92:86c6:: with SMTP id l67mr14740282ilh.225.1583745320773; Mon, 09 Mar 2020 02:15:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Florian Biesinger Date: Mon, 9 Mar 2020 10:15:09 +0100 Message-ID: To: Yaron Sheffer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000042851205a0687123" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 09:18:35 -0000 --00000000000042851205a0687123 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 4x yes as well. On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffer wrote: > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 /Flo --=20 Florian Biesinger =E2=99=AB | Backend Engineer | florian@spotify.com | +46 = 70 36 72 133 Spotify GmbH c/o Mindspace Krausenstra=C3=9Fe 9 10117 Berlin Get Spotify here! This e-mail (including any attachments) may contain information that is confidential and/or privileged. It is intended only for the recipient(s). If you have reason to believe that you are not the intended recipient of this e-mail, please contact the sender immediately and delete the e-mail from your computer. --00000000000042851205a0687123 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
4x yes as well.

On Fri, Mar 6, 2020 at 5:45 PM Yaron Sheffe= r <yaronf.ietf@gmail.com>= ; wrote:
Hi Ever= yone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu= th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i= n proceeding with this work.=C2=A0 Please do so by responding to the follow= ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?= =C2=A0 Or do you have major objections, blocking concerns or feedback (if s= o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the= drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char= ter should be amended In a significant way, please reply on a separate thre= ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for= mation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver= as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---

This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authori= zing party to delegate access to client software through an authorization s= erver. It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework = for interaction among all parties involved in the protocol flow, and remove= unnecessary dependence on a browser or user-agent for coordinating interac= tions.

The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation = channel, which happens directly between the client and the authorization se= rver (in contrast with OAuth 2.0 which is initiated by the client redirecti= ng the user=E2=80=99s browser). The client and AS will involve a user to ma= ke an authorization decision as necessary through interaction mechanisms in= dicated by the protocol. This decoupling avoids many of the security concer= ns and technical challenges of OAuth 2.0 and provides a non-invasive path f= or supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t= he client requesting access
- A variety of client applications, including Web, mobile, single-page, and= interaction-constrained applications

The group will define extension points for this protocol to allow for flexi= bility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possessi= on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc= ess (including identity)

Additionally, the group will provide mechanisms for management of the proto= col lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt = to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol= where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily compatible with = OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope= d in the OAuth Working Group, including functionality back-ported from the = protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic met= hods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.

The initial work will focus on using HTTP for communication between the cli= ent and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin= g to other protocols such as COAP when doing so does not conflict with the = primary focus.

Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d= etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points


--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
/Flo
--=C2=A0
Florian Biesinger=C2=A0=E2=99=AB=C2=A0| Backend Engineer=C2=A0|=C2=A0florian@spotify.com=C2=A0|=C2=A0+46=C2=A070 36 72 133

Spotify GmbH=C2=A0
c/o Mindspace
Krausenstra=C3=9Fe 9
10117 Berlin

Get Spotify=C2=A0here!


This e-mail (including any attachments) may contai= n information that is=C2=A0confidential and/or privileged. It is intended o= nly for the recipient(s). If=C2=A0you have reason to believe that you are n= ot the intended recipient of this=C2=A0e-mail, please contact the sender im= mediately and delete the e-mail from=C2=A0your computer.
=
--00000000000042851205a0687123-- From nobody Mon Mar 9 03:08:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8593A0BF1 for ; Mon, 9 Mar 2020 03:08:35 -0700 (PDT) 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=swissre.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 XeuaLeHg9e3F for ; Mon, 9 Mar 2020 03:08:33 -0700 (PDT) Received: from esa2.hc1106-67.c3s2.iphmx.com (esa2.hc1106-67.c3s2.iphmx.com [139.138.62.206]) (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 EBBB93A0BF0 for ; Mon, 9 Mar 2020 03:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1583748513; x=1615284513; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hgY5F/xd5KCquo3PvJF6Qk9RwHcpwJ/dTVm3hCLUM8k=; b=XsxFwOrUaAfAyTnOIvgwLd4za5wL/M/28Vc/Wt2y8WhffhHkYkvvfumg xLL5gT1vOq89Rs8UD5XmdyIiFJiqyqlH7l8J5ABpuTGYFJpPCk4+FVaS3 iredlEZz6KbQOZ1K9RH1wiikxufAdV0LFl0oLcU7hVpBXZs3vKUWvNjhB c/857iLDzW2TbVRwf/zVzK6Q+7xUpYzBA+Ng5bHPz9fWoP0YOhm06xOWe G8D6ViyOMcVWwM98++943Ymnb8AKbP8534vnC7rHc3PFVf0DOqnXEqeNn VAoD10hGGJyJWESTT+hd7nTY9SSbSFtHSZPNgLCsCb5Koh79cRLg8jH0c g==; IronPort-SDR: J9uPxhy7OW1XPSN/cMtddzLcJoSWnyZ7a//tuiVNMUspcQGMpt+ZbnsmYuy6AD5BHIASqetV5l 4oBZpqmPTSQkEs+OAEsbgtO/Rdko75jkq6lPVuxGrrEvqhlwH0kzR7C/H8zQ3jl47QcKcEL6Sr 385Du9OGl74ejTmiTx7JsRsRkeh20GH7zBTai+NuFvTgCDSymAVaEv07OWHqLBlCHDQnogWn/I q63tJJDj43pekmQ6a392119T/msCr020S5u8K187mVku0m2Zf6gEiBj3PDVR16tUIFWpgWj0lR jaE= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.102]) by esa2.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 09 Mar 2020 10:08:28 +0000 Received: from CHRP5012.corp.gwpnet.com (10.53.3.187) by edge.swissre.com (193.246.239.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Mar 2020 11:08:27 +0100 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5012.corp.gwpnet.com (10.53.3.187) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Mar 2020 11:08:25 +0100 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.000; Mon, 9 Mar 2020 11:08:25 +0100 From: Lee McGovern To: Yaron Sheffer , "txauth@ietf.org" Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AQHV9PgjakXVRV1C5UOojMVg+gq+B6hACw4g Date: Mon, 9 Mar 2020 10:08:24 +0000 Message-ID: <1f86898ed04543cb89388e56caaf946c@CHRP5009.corp.gwpnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2020-03-09T10:08:23.9242824Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.9] Content-Type: multipart/alternative; boundary="_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_" MIME-Version: 1.0 X-GBS-PROC: 2hIY42bPeOGjeRR/kd6oj+Xv/zaQwqZdYfAi0AttK1Q= Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 10:08:36 -0000 --_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 DQoxLiAgRG8geW91IHN1cHBvcnQgdGhlIGNoYXJ0ZXIgdGV4dCBwcm92aWRlZCBhdCB0aGUgZW5k IG9mIHRoaXMgZW1haWw/ICBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25zLCBibG9ja2lu ZyBjb25jZXJucyBvciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/DQoNClllcw0K DQoyLiAgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhvciBvciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2 ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPw0KDQpZZXMNCg0KMy4gIEFyZSB5b3Ug d2lsbGluZyB0byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQoNClllcw0KDQo0 LiAgQXJlIHlvdSBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyBkcmFmdHMgb2YgdGhpcyBXRz8N Cg0KTm8NCg0KTGVlIE1jR292ZXJuIHwgSUFNIEFyY2hpdGVjdCB8IFZJQ0UgUFJFU0lERU5UIHwg SW5mb3JtYXRpb24gVGVjaG5vbG9neQ0KU3dpc3MgUmUgTWFuYWdlbWVudCBMdGQgfCBNeXRoZW5x dWFpIDUwLzYwLCA4MDIyIFpVUklDSCwgU1dJVFpFUkxBTkQNCkRpcmVjdDogKzQxIDQzIDI4NSA3 MCAxNyBGYXg6ICs0MSA0MyAyODIgNzAgMTcgRS1tYWlsOiBMZWVfTWNHb3Zlcm5Ac3dpc3NyZS5j b208bWFpbHRvOkxlZV9NY0dvdmVybkBzd2lzc3JlLmNvbT4NCg0KT24gRnJpLCBNYXIgNiwgMjAy MCBhdCA1OjQ1IFBNIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSBFdmVyeW9uZSwNCg0KSXQgYXBwZWFy cyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRpb24g b2YgYSBUeEF1dGggd29ya2luZyBncm91cC4gIFdl4oCZZCBsaWtlIHRvIG1vcmUgZm9ybWFsbHkg Z2F1Z2UgaW50ZXJlc3QgaW4gcHJvY2VlZGluZyB3aXRoIHRoaXMgd29yay4gIFBsZWFzZSBkbyBz byBieSByZXNwb25kaW5nIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQoxLiAgRG8geW91 IHN1cHBvcnQgdGhlIGNoYXJ0ZXIgdGV4dCBwcm92aWRlZCBhdCB0aGUgZW5kIG9mIHRoaXMgZW1h aWw/ICBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25zLCBibG9ja2luZyBjb25jZXJucyBv ciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/DQoNCjIuICBBcmUgeW91IHdpbGxp bmcgdG8gYXV0aG9yIG9yIHBhcnRpY2lwYXRlIGluIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJh ZnRzIG9mIHRoaXMgV0c/DQoNCjMuICBBcmUgeW91IHdpbGxpbmcgdG8gaGVscCByZXZpZXcgdGhl IGRyYWZ0cyBvZiB0aGlzIFdHPw0KDQo0LiAgQXJlIHlvdSBpbnRlcmVzdGVkIGluIGltcGxlbWVu dGluZyBkcmFmdHMgb2YgdGhpcyBXRz8NCg0KVGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3byB3ZWVr cywgdW50aWwgTWFyY2ggMjEuIElmIHlvdSB0aGluayB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBi ZSBhbWVuZGVkIEluIGEgc2lnbmlmaWNhbnQgd2F5LCBwbGVhc2UgcmVwbHkgb24gYSBzZXBhcmF0 ZSB0aHJlYWQuDQoNClRoZSBmZWVkYmFjayBwcm92aWRlZCBoZXJlIHdpbGwgaGVscCB0aGUgSUVT RyBjb21lIHRvIGEgZGVjaXNpb24gb24gdGhlIGZvcm1hdGlvbiBvZiBhIG5ldyBXRy4gR2l2ZW4g dGhlIGNvbnN0cmFpbnRzIG9mIHRoZSBjaGFydGVyaW5nIHByb2Nlc3MsIHJlZ2FyZGxlc3Mgb2Yg dGhlIG91dGNvbWUgb2YgdGhpcyBjb25zZW5zdXMgY2FsbCwgd2Ugd2lsbCBiZSBtZWV0aW5nIGlu IFZhbmNvdXZlciBhcyBhIEJvRi4NCg0KVGhhbmtzLA0KWWFyb24gYW5kIERpY2sNCg0KLS0tIENo YXJ0ZXIgVGV4dCBGb2xsb3dzIC0tLQ0KDQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZl bG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24s IGlkZW50aXR5LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1 dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhy b3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNl cyBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5l Y3QgKGl0c2VsZiBhbiBleHRlbnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6 YXRpb25zIHNjb3BlZCBhcyBuYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlk ZSBhIGNsZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52 b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3NhcnkgZGVwZW5k ZW5jZSBvbiBhIGJyb3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0 aW9ucy4NCg0KVGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVs dGlwbGUgcGFydGllcyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmlj IHJvbGUuIFRoZSBwcm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVs cywgc3VjaCBhcyB0aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24g Y2hhbm5lbCwgd2hpY2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2gg aXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dz ZXIpLiBUaGUgY2xpZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0 aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNo YW5pc21zIGluZGljYXRlZCBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGluZyBhdm9pZHMg bWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9m IE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGlu ZyBmdXR1cmUgdHlwZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQoNCkFk ZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCg0KLSBG aW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCi0gQXBwcm92YWwgb2YgQVMgYXR0 ZXN0YXRpb24gdG8gaWRlbnRpdHkgY2xhaW1zDQotIEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0 aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMgaW4gYSBzaW5nbGUgaW50ZXJhY3Rpb24NCi0gU2VwYXJh dGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBv cGVyYXRpbmcgdGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2Vzcw0KLSBBIHZhcmlldHkgb2YgY2xp ZW50IGFwcGxpY2F0aW9ucywgaW5jbHVkaW5nIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5k IGludGVyYWN0aW9uLWNvbnN0cmFpbmVkIGFwcGxpY2F0aW9ucw0KDQpUaGUgZ3JvdXAgd2lsbCBk ZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxl eGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOg0KDQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBm b3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0KLSBV c2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRo b2RzDQotIE1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0 aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlv biBkZWNpc2lvbnMNCi0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3Vy Y2Ugc2VydmVycyBhbmQgYmluZGluZyByZXNvdXJjZSByZXF1ZXN0cyB0byB0b2tlbnMgYW5kIGFz c29jaWF0ZWQgY3J5cHRvZ3JhcGhpYyBrZXlzDQotIE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRk aXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdoIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MgKGluY2x1 ZGluZyBpZGVudGl0eSkNCg0KQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1l Y2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRp bmc6DQoNCi0gRGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcg0KLSBSZXZvY2F0 aW9uIG9mIGFjdGl2ZSB0b2tlbnMNCi0gUXVlcnkgb2YgdG9rZW4gcmlnaHRzIGJ5IHJlc291cmNl IHNlcnZlcnMNCg0KQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3Qg aW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0 aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxsIGF0dGVtcHQgdG8gc2ltcGxp ZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3 IHByb3RvY29sIHdoZXJlIHBvc3NpYmxlLg0KDQpUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQg dG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1 cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBhdGli bGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0bHkgb24g T0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBp bmNsdWRpbmcgZnVuY3Rpb25hbGl0eSBiYWNrLXBvcnRlZCBmcm9tIHRoZSBwcm90b2NvbCBkZXZl bG9wZWQgaGVyZSB0byBPQXV0aCAyLjAuDQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2 ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1Y2gg YXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91cCBp cyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy4NCg0K VGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFAgZm9yIGNvbW11bmljYXRp b24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRha2lu ZyBhZHZhbnRhZ2Ugb2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIG9mIEhUVFAyIGFuZCBIVFRQMyB3 aGVyZSBwb3NzaWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJsZSBzaW1wbGUgbWFwcGluZyB0 byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQIHdoZW4gZG9pbmcgc28gZG9lcyBub3QgY29u ZmxpY3Qgd2l0aCB0aGUgcHJpbWFyeSBmb2N1cy4NCg0KTWlsZXN0b25lcyB0byBpbmNsdWRlOg0K IC0gQ29yZSBkZWxlZ2F0aW9uIHByb3RvY29sDQogLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlz bSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNp Z25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KIC0gSWRlbnRpdHkgYW5kIGF1 dGhlbnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtcw0KIC0gR3VpZGVsaW5lcyBmb3IgdXNl IG9mIHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHMNCg0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlz dA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KCgpUaGlzIGUtbWFpbCwgaW5jbHVkaW5n IGF0dGFjaG1lbnRzLCBpcyBpbnRlbmRlZCBmb3IgdGhlIHBlcnNvbihzKSBvciBjb21wYW55IG5h bWVkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbi4KClVuYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBv ZiB0aGlzIGluZm9ybWF0aW9uIG1heSBiZSB1bmxhd2Z1bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpBbGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUt bWFpbCBtZXNzYWdlcyBhcmUgc3RvcmVkIGluIHRoZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3Nh Z2UgUmVwb3NpdG9yeS4KSWYgeW91IGRvIG5vdCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50 aWFsbHkgcHJpdmF0ZSBlLW1haWxzIGJ5IFN3aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91 IG5vdCB0byB1c2UgdGhlIFN3aXNzIFJlIGUtbWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwg bm9uLWJ1c2luZXNzIHJlbGF0ZWQgY29tbXVuaWNhdGlvbnMuCg== --_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkFyaWFsIFVu aWNvZGUgTVMiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iREUtQ0giIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiZuYnNwOyBEbyB5 b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBl bWFpbD8mbmJzcDsgT3IgZG8geW91IGhhdmUgbWFqb3Igb2JqZWN0aW9ucywgYmxvY2tpbmcgY29u Y2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBsZWFzZSBlbGFib3JhdGUpPzxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuJm5ic3A7IEFy ZSB5b3Ugd2lsbGluZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhlIGRldmVsb3BtZW50 IG9mIHRoZSBkcmFmdHMgb2YgdGhpcyBXRz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiZuYnNwOyBBcmUgeW91IHdpbGxpbmcgdG8g aGVscCByZXZpZXcgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuJm5ic3A7IEFyZSB5b3UgaW50 ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRoaXMgV0c/PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgVW5pY29kZSBNUyZxdW90OyxzZXJpZjtjb2xvcjojNjg2 QUIwIj5MZWUgTWNHb3Zlcm48L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwgVW5pY29kZSBNUyZxdW90OyxzZXJpZjtjb2xvcjoj ODI5QTkwIj4gfCBJQU0gQXJjaGl0ZWN0PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsIFVuaWNvZGUgTVMmcXVvdDssc2VyaWY7 Y29sb3I6IzY4NkFCMCI+DQogfCBWSUNFIFBSRVNJREVOVDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCBVbmljb2RlIE1TJnF1 b3Q7LHNlcmlmO2NvbG9yOiM4MjlBOTAiPiB8IEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8L3NwYW4+ PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwgVW5pY29kZSBNUyZxdW90OyxzZXJpZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM2ODZB QjAiPlN3aXNzIFJlIE1hbmFnZW1lbnQgTHRkPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODI5 QTkwIj4gfCBNeXRoZW5xdWFpIDUwLzYwLCA4MDIyIFpVUklDSCwgU1dJVFpFUkxBTkQ8L3NwYW4+ PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM2ODZBQjAiPkRpcmVjdDogPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojODI5QTkwIj4mIzQzOzQxIDQzIDI4NSA3MCAxNw0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojNjg2QUIwIj5GYXg6IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgyOUE5 MCI+JiM0Mzs0MSA0MyAyODIgNzAgMTcNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzY4NkFC MCI+RS1tYWlsOiA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MjlBOTAiPjxhIGhyZWY9Im1h aWx0bzpMZWVfTWNHb3Zlcm5Ac3dpc3NyZS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojODI5QTkw O3RleHQtZGVjb3JhdGlvbjpub25lIj5MZWVfTWNHb3Zlcm5Ac3dpc3NyZS5jb208L3NwYW4+PC9h Pjwvc3Bhbj48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gRnJpLCBNYXIgNiwgMjAyMCBhdCA1OjQ1IFBNIFlhcm9uIFNoZWZmZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRXZlcnlvbmUsPGJyPg0KJm5ic3A7PGJyPg0KSXQgYXBw ZWFycyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRp b24gb2YgYSBUeEF1dGggd29ya2luZyBncm91cC4mbmJzcDsgV2XigJlkIGxpa2UgdG8gbW9yZSBm b3JtYWxseSBnYXVnZSBpbnRlcmVzdCBpbiBwcm9jZWVkaW5nIHdpdGggdGhpcyB3b3JrLiZuYnNw OyBQbGVhc2UgZG8gc28gYnkgcmVzcG9uZGluZyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczo8 YnI+DQombmJzcDs8YnI+DQoxLiZuYnNwOyBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0 IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8mbmJzcDsgT3IgZG8geW91IGhhdmUg bWFqb3Igb2JqZWN0aW9ucywgYmxvY2tpbmcgY29uY2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBs ZWFzZSBlbGFib3JhdGUpPzxicj4NCiZuYnNwOzxicj4NCjIuJm5ic3A7IEFyZSB5b3Ugd2lsbGlu ZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhlIGRldmVsb3BtZW50IG9mIHRoZSBkcmFm dHMgb2YgdGhpcyBXRz88YnI+DQombmJzcDs8YnI+DQozLiZuYnNwOyBBcmUgeW91IHdpbGxpbmcg dG8gaGVscCByZXZpZXcgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxicj4NCiZuYnNwOzxicj4NCjQu Jm5ic3A7IEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRoaXMg V0c/PGJyPg0KJm5ic3A7PGJyPg0KVGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3byB3ZWVrcywgdW50 aWwgTWFyY2ggMjEuIElmIHlvdSB0aGluayB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBiZSBhbWVu ZGVkIEluIGEgc2lnbmlmaWNhbnQgd2F5LCBwbGVhc2UgcmVwbHkgb24gYSBzZXBhcmF0ZSB0aHJl YWQuPGJyPg0KJm5ic3A7PGJyPg0KVGhlIGZlZWRiYWNrIHByb3ZpZGVkIGhlcmUgd2lsbCBoZWxw IHRoZSBJRVNHIGNvbWUgdG8gYSBkZWNpc2lvbiBvbiB0aGUgZm9ybWF0aW9uIG9mIGEgbmV3IFdH LiBHaXZlbiB0aGUgY29uc3RyYWludHMgb2YgdGhlIGNoYXJ0ZXJpbmcgcHJvY2VzcywgcmVnYXJk bGVzcyBvZiB0aGUgb3V0Y29tZSBvZiB0aGlzIGNvbnNlbnN1cyBjYWxsLCB3ZSB3aWxsIGJlIG1l ZXRpbmcgaW4gVmFuY291dmVyIGFzIGEgQm9GLjxicj4NCiZuYnNwOzxicj4NClRoYW5rcyw8YnI+ DQpZYXJvbiBhbmQgRGljazxicj4NCiZuYnNwOzxicj4NCi0tLSBDaGFydGVyIFRleHQgRm9sbG93 cyAtLS08YnI+DQo8YnI+DQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmlu ZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24sIGlkZW50aXR5 LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5n IHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBh dXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNlcw0KIGNhc2Vz IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCAoaXRz ZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQgYXV0aG9yaXphdGlvbnMg c2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRyYW5zYWN0aW9uLCBwcm92aWRlIGEgY2xl YXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBp biB0aGUgcHJvdG9jb2wgZmxvdywgYW5kDQogcmVtb3ZlIHVubmVjZXNzYXJ5IGRlcGVuZGVuY2Ug b24gYSBicm93c2VyIG9yIHVzZXItYWdlbnQgZm9yIGNvb3JkaW5hdGluZyBpbnRlcmFjdGlvbnMu DQo8YnI+DQo8YnI+DQpUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBi eSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3JtaW5nIGEgc3Bl Y2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uIGNo YW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0aGUgZGVsZWdh dGlvbiBjaGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4NCiB0aGUgY2xpZW50 IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgKGluIGNvbnRyYXN0IHdpdGggT0F1dGggMi4w IHdoaWNoIGlzIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1c2Vy4oCZ cyBicm93c2VyKS4gVGhlIGNsaWVudCBhbmQgQVMgd2lsbCBpbnZvbHZlIGEgdXNlciB0byBtYWtl IGFuIGF1dGhvcml6YXRpb24gZGVjaXNpb24gYXMgbmVjZXNzYXJ5IHRocm91Z2ggaW50ZXJhY3Rp b24gbWVjaGFuaXNtcyBpbmRpY2F0ZWQNCiBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGlu ZyBhdm9pZHMgbWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFs bGVuZ2VzIG9mIE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Ig c3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5l bHMuPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwg YWxsb3cgZm9yOjxicj4NCjxicj4NCi0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgYWNj ZXNzPGJyPg0KLSBBcHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0eSBjbGFpbXM8 YnI+DQotIEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMg aW4gYSBzaW5nbGUgaW50ZXJhY3Rpb248YnI+DQotIFNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcGFy dHkgYXV0aG9yaXppbmcgYWNjZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZSBjbGllbnQg cmVxdWVzdGluZyBhY2Nlc3M8YnI+DQotIEEgdmFyaWV0eSBvZiBjbGllbnQgYXBwbGljYXRpb25z LCBpbmNsdWRpbmcgV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24tY29u c3RyYWluZWQgYXBwbGljYXRpb25zPGJyPg0KPGJyPg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4 dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5 IGluIGFyZWFzIGluY2x1ZGluZzo8YnI+DQo8YnI+DQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBm b3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbiA8YnI+ DQotIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2Vi IG1ldGhvZHM8YnI+DQotIE1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwg b3JnYW5pemF0aW9uLCBhbmQgb3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0 aG9yaXphdGlvbiBkZWNpc2lvbnM8YnI+DQotIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9r ZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMgdG8g dG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5czxicj4NCi0gT3B0aW1pemVk IGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRocm91Z2ggdGhlIGRlbGVnYXRp b24gcHJvY2VzcyAoaW5jbHVkaW5nIGlkZW50aXR5KTxicj4NCjxicj4NCkFkZGl0aW9uYWxseSwg dGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBw cm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjxicj4NCjxicj4NCi0gRGlzY292ZXJ5IG9mIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcjxicj4NCi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5z PGJyPg0KLSBRdWVyeSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVyczxicj4NCjxi cj4NCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVk IG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9y IE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBhdHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3Jh dGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgdG8gdGhlIG5ldyBwcm90b2Nv bCB3aGVyZSBwb3NzaWJsZS48YnI+DQo8YnI+DQpUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQg dG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1 cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBhdGli bGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0bHkgb24g T0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBp bmNsdWRpbmcNCiBmdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRl dmVsb3BlZCBoZXJlIHRvIE9BdXRoIDIuMC48YnI+DQo8YnI+DQpUaGUgZ3JvdXAgaXMgY2hhcnRl cmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcgY3J5cHRvZ3JhcGhpYyBtZXRo b2RzLCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MuIFRo aXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBjcnlwdG9ncmFwaGljIG1l dGhvZHMuDQo8YnI+DQo8YnI+DQpUaGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcg SFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMg b2YgSFRUUDIgYW5kIEhUVFAzIHdoZXJlIHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5h YmxlIHNpbXBsZSBtYXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVANCiB3aGVu IGRvaW5nIHNvIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuPGJyPg0K PGJyPg0KTWlsZXN0b25lcyB0byBpbmNsdWRlOjxicj4NCiZuYnNwOy0gQ29yZSBkZWxlZ2F0aW9u IHByb3RvY29sPGJyPg0KJm5ic3A7LSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5n cyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwg YW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlczxicj4NCiZuYnNwOy0gSWRlbnRpdHkgYW5kIGF1 dGhlbnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtczxicj4NCiZuYnNwOy0gR3VpZGVsaW5l cyBmb3IgdXNlIG9mIHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHM8YnI+DQo8YnI+DQo8YnI+DQot LSA8YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj48ZGl2PlRo aXMgZS1tYWlsLCBpbmNsdWRpbmcgYXR0YWNobWVudHMsIGlzIGludGVuZGVkIGZvciB0aGUgcGVy c29uKHMpIG9yIGNvbXBhbnkgbmFtZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQv b3IgbGVnYWxseSBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLjwvZGl2PlVuYXV0aG9yaXplZCBkaXNj bG9zdXJlLCBjb3B5aW5nIG9yIHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIG1heSBiZSB1bmxhd2Z1 bCBhbmQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj5B bGwgaW5jb21pbmcgYW5kIG91dGdvaW5nIGUtbWFpbCBtZXNzYWdlcyBhcmUgc3RvcmVkIGluIHRo ZSBTd2lzcyBSZSBFbGVjdHJvbmljIE1lc3NhZ2UgUmVwb3NpdG9yeS48YnI+SWYgeW91IGRvIG5v dCB3aXNoIHRoZSByZXRlbnRpb24gb2YgcG90ZW50aWFsbHkgcHJpdmF0ZSBlLW1haWxzIGJ5IFN3 aXNzIFJlLCB3ZSBzdHJvbmdseSBhZHZpc2UgeW91IG5vdCB0byB1c2UgdGhlIFN3aXNzIFJlIGUt bWFpbCBhY2NvdW50IGZvciBhbnkgcHJpdmF0ZSwgbm9uLWJ1c2luZXNzIHJlbGF0ZWQgY29tbXVu aWNhdGlvbnMuPC9ib2R5Pg0KPC9odG1sPg0K --_000_1f86898ed04543cb89388e56caaf946cCHRP5009corpgwpnetcom_-- From nobody Mon Mar 9 20:49:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5920B3A0EC5 for ; Mon, 9 Mar 2020 20:49:44 -0700 (PDT) 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=fusionauth.io 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 vf60uyQAouBE for ; Mon, 9 Mar 2020 20:49:37 -0700 (PDT) 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 487BA3A0ECE for ; Mon, 9 Mar 2020 20:49:27 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id u12so8303251ljo.2 for ; Mon, 09 Mar 2020 20:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fusionauth.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gjkJ9VIeoOLkyqleKI/7w9dCdhnrPMJ+hRx7Fw7n42U=; b=Bt3jRDsN+DDXpvhZkuvBEd9HdK5GJXuzln+h9NvTpxgGD8mEply7oAp942+fuX+MdA Bp6VVAmxMc8LmAzfzhjXopu2bQCnI6UdthstUKXoyh9suNCDLmUPhYml1A4ebpue3x55 emKZVQ4JDUf6A+rpzdP/4cPlKWSasPfN8n5mgKMe2ufBfH21f3mQ4wO0b8DbpE8SLUwt NHl2lMELfoUGq78+SsIsZq8B/JZKaaA0lRF13ngFViUd15qdimrgpn7M52o/A2McjoWJ GnpfQispW8gJ0pDpGj3E2kDZXIaaJZdNnUx1/Yo/XvRw27Pkm7aVUP+HBW6QDU2Rcp63 XSDA== 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=gjkJ9VIeoOLkyqleKI/7w9dCdhnrPMJ+hRx7Fw7n42U=; b=byTu/Y5T69z8Le/JjWT9VL1sNkz/dHOLWgNimEfSJTCpGOXRD5Vgjx4SAYT0Q6YMUb 9jjZAfI1M4ByJu5k5YXLQWyQKxX8n/p/AkpYcIGz523O+mNwqNGKJwRYIsydap+HwhxF yHN1g9cMqNDxSP8J1rxw9kswi/BBmU9LSkHy69L/8qzT2C0uma0kwwgNyPeazokmGvUH ZMgZR834JpHYb5Cmus7bPc0k3R0fqVz4fDaWjha9JVa1q8HtPIq7Gcxaput//d/rZsz4 WGC1YSzBo85cOSBKj+zz4AX2tOP3FmQqa5mOsNYnjSyhV9kWhPvhJTGaUDToD/JtDJsC wbOQ== X-Gm-Message-State: ANhLgQ0dmpR69CpQWYIRfnc2tSfNAkRKODFECNOskaHg2GsGuU1DfEwT j3H3g8x+urXYy6XRQTJ+i6qRV2Rj4aMB6riqR3LXzQ== X-Google-Smtp-Source: ADFU+vtyyFfCrtqYLyWwbaD7qtvH9deGY2NvXoIrO/9eZ0mCRlcUXLPq7hbdNYSC1ysEAu4dJCAzh8uAoNUPvpF2HSo= X-Received: by 2002:a2e:a419:: with SMTP id p25mr1504579ljn.206.1583812159918; Mon, 09 Mar 2020 20:49:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel DeGroff Date: Mon, 9 Mar 2020 21:49:08 -0600 Message-ID: To: Yaron Sheffer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ee8be05a07801f0" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 03:49:45 -0000 --0000000000002ee8be05a07801f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, > 1. Do you support the charter text provided at the end of this email? Or do you have major objections, blocking concerns or feedback (if so please elaborate)? Yes > 2. Are you willing to author or participate in the development of the drafts of this WG? Yes > 3. Are you willing to help review the drafts of this WG? Yes > 4. Are you interested in implementing drafts of this WG? Yes Daniel daniel@fusionauth.io On Fri, Mar 6, 2020 at 9:45 AM Yaron Sheffer wrote: > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000002ee8be05a07801f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

=
> 1.=C2= =A0 Do you support the charter text provided at the end of this email?=C2= =A0 Or do you have major objections, blocking concerns or feedback (if so p= lease elaborate)?

Yes

> 2.=C2=A0 Are you willing to author or participat= e in the development of the drafts of this WG?

Yes

> 3.=C2=A0 Are you wi= lling to help review the drafts of this WG?

Yes

> 4.=C2=A0 Are you inter= ested in implementing drafts of this WG?

Yes

Daniel=C2=A0


On Fri, Mar 6,= 2020 at 9:45 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Hi Everyone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu= th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i= n proceeding with this work.=C2=A0 Please do so by responding to the follow= ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?= =C2=A0 Or do you have major objections, blocking concerns or feedback (if s= o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the= drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char= ter should be amended In a significant way, please reply on a separate thre= ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for= mation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver= as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---

This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authori= zing party to delegate access to client software through an authorization s= erver. It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework = for interaction among all parties involved in the protocol flow, and remove= unnecessary dependence on a browser or user-agent for coordinating interac= tions.

The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation = channel, which happens directly between the client and the authorization se= rver (in contrast with OAuth 2.0 which is initiated by the client redirecti= ng the user=E2=80=99s browser). The client and AS will involve a user to ma= ke an authorization decision as necessary through interaction mechanisms in= dicated by the protocol. This decoupling avoids many of the security concer= ns and technical challenges of OAuth 2.0 and provides a non-invasive path f= or supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t= he client requesting access
- A variety of client applications, including Web, mobile, single-page, and= interaction-constrained applications

The group will define extension points for this protocol to allow for flexi= bility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possessi= on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc= ess (including identity)

Additionally, the group will provide mechanisms for management of the proto= col lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt = to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol= where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily compatible with = OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope= d in the OAuth Working Group, including functionality back-ported from the = protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic met= hods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.

The initial work will focus on using HTTP for communication between the cli= ent and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin= g to other protocols such as COAP when doing so does not conflict with the = primary focus.

Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d= etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points


--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000002ee8be05a07801f0-- From nobody Tue Mar 10 06:47:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB53A0F58 for ; Tue, 10 Mar 2020 06:47:40 -0700 (PDT) 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 SM6AVBp7Tea5 for ; Tue, 10 Mar 2020 06:47:38 -0700 (PDT) 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 E94B23A0F53 for ; Tue, 10 Mar 2020 06:47:37 -0700 (PDT) Received: from [192.168.1.5] (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 02ADlZgC006367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 09:47:35 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 10 Mar 2020 09:47:35 -0400 Cc: "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yaron Sheffer X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 13:47:40 -0000 On Mar 6, 2020, at 11:44 AM, Yaron Sheffer = wrote: >=20 > Hi Everyone, > =20 > It appears that momentum is forming around the proposed formation of a = TxAuth working group. We=E2=80=99d like to more formally gauge interest = in proceeding with this work. Please do so by responding to the = following questions: > =20 > 1. Do you support the charter text provided at the end of this email? = Or do you have major objections, blocking concerns or feedback (if so = please elaborate)? Yes. > =20 > 2. Are you willing to author or participate in the development of the = drafts of this WG? Yes, and I am volunteering to edit. > =20 > 3. Are you willing to help review the drafts of this WG? Yes. > =20 > 4. Are you interested in implementing drafts of this WG? Yes, and I have implemented one of the input drafts. > =20 > The call will run for two weeks, until March 21. If you think that the = charter should be amended In a significant way, please reply on a = separate thread. > =20 > The feedback provided here will help the IESG come to a decision on = the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. > =20 > Thanks, > Yaron and Dick > =20 > --- Charter Text Follows --- >=20 > This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >=20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Separation between the party authorizing access and the party = operating the client requesting access > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation = process (including identity) >=20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.=20 >=20 > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 10 06:58:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B13A133D for ; Tue, 10 Mar 2020 06:58:54 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 Z35mWz5B4oD2 for ; Tue, 10 Mar 2020 06:58:44 -0700 (PDT) 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 518F63A133B for ; Tue, 10 Mar 2020 06:58:30 -0700 (PDT) Received: from [192.168.1.5] (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 02ADwR5d010553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 09:58:28 -0400 From: Justin Richer Message-Id: <476DCE51-67E9-4C25-9B00-2B1D994138A5@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Mar 2020 09:58:27 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <158363691397.25530.3652753138946434165@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-05.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 13:58:55 -0000 --Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The interaction structure mimics the two return styles in XYZ (which are = switched on whether you provide a =E2=80=9Ccallback=E2=80=9D structure = or not) but still doesn=E2=80=99t allow the client to specify different = interaction mechanisms. It seems that now the GS needs to guess what the = client is capable of. To me, one of our greatest opportunities here is = moving away from the assumptions of web-based interaction. I believe we = need to account for this in a way that=E2=80=99s more flexible than a = single-type system.=20 If I have a client app that could get the user to you in a browser or = send you VC=E2=80=99s directly, I should be able to tell you that = upfront and have the AS respond to any and all actions that it can do. =E2=80=94 Justin > On Mar 7, 2020, at 10:16 PM, Dick Hardt wrote: >=20 > Please forgive, and point out inconsistencies! If anything is = confusing, please let me know. It is likely a mistake on my part! > I'm proposing there are only 2 types of interactions defined: a = redirect interaction where the Client can redirect to the GS, and the GS = back to the Client; or an indirect interaction where the User somehow = gets to the GS, and there is no redirect back to the Client. The = security characteristics are different, as session fixation can be = prevented if the GS redirects back to the Client as the Client is able = to verify the User it is interacting with is the same as the User the GS = is interacting with.=20 > I added a sequence where the Client does a PATCH on the Grant URI with = an interaction nonce received from the GS in the redirect back to the = Client to protect against fixation attacks. > The Authorization lifecycle and management is now independent of the = Grant. A Client now receives an access token, OR an AuthZ URI. Reading = and refreshing an access token are the same thing.=20 > A more complete list of changes is below: > draft-hardt-xauth-protocol-05 > separated claims from identifiers in request user object = > simplified reciprocal grant flow = > reduced interactions to redirect and indirect = > simplified interaction parameters = > added in language for Client to verify interaction completion = > added Verify Grant API and Interaction Nonce = > replaced Refresh AuthZ with Read AuthZ.. Read and refresh are same = operation. >=20 > ---------- Forwarded message --------- > From: > > Date: Sat, Mar 7, 2020 at 7:08 PM > Subject: New Version Notification for = draft-hardt-xauth-protocol-05.txt > To: Dick Hardt > >=20 >=20 >=20 > A new version of I-D, draft-hardt-xauth-protocol-05.txt > has been successfully submitted by Dick Hardt and posted to the > IETF repository. >=20 > Name: draft-hardt-xauth-protocol > Revision: 05 > Title: The XAuth Protocol > Document date: 2020-03-07 > Group: Individual Submission > Pages: 59 > URL: = https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt = > Status: = https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ = > Htmlized: = https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-05 = >=20 > Abstract: > Client software often desires resources or identity claims that are > independent of the client. This protocol allows a user and/or > resource owner to delegate resource authorization and/or release of > identity claims to a server. Client software can then request = access > to resources and/or identity claims by calling the server. The > server acquires consent and authorization from the user and/or > resource owner if required, and then returns to the client software > the authorization and identity claims that were approved. This > protocol can be extended to support alternative authorizations, > claims, interactions, and client authentication mechanisms. >=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 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = interaction structure mimics the two return styles in XYZ (which are = switched on whether you provide a =E2=80=9Ccallback=E2=80=9D structure = or not) but still doesn=E2=80=99t allow the client to specify different = interaction mechanisms. It seems that now the GS needs to guess what the = client is capable of. To me, one of our greatest opportunities here is = moving away from the assumptions of web-based interaction. I believe we = need to account for this in a way that=E2=80=99s more flexible than a = single-type system. 

If I have a client app that could get the user to you in a = browser or send you VC=E2=80=99s directly, I should be able to tell you = that upfront and have the AS respond to any and all actions that it can = do.

 =E2=80= =94 Justin

On Mar 7, 2020, at 10:16 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

Please forgive, and point out inconsistencies! If = anything is confusing, please let me know. It is likely a mistake = on my part!

  1. I'm proposing there are only 2 types of interactions defined: = a redirect interaction where the Client can redirect to the GS, and the = GS back to the Client; or an indirect interaction where the User somehow = gets to the GS, and there is no redirect back to the Client. The = security characteristics are different, as session fixation can be = prevented if the GS redirects back to the Client as the Client is able = to verify the User it is interacting with is the same as the User the GS = is interacting with. 
  2. I added a sequence where the Client does a PATCH on = the Grant URI with an interaction nonce received from the GS in the = redirect back to the Client to protect against fixation = attacks.
  3. The Authorization lifecycle and management is now = independent of the Grant. A Client now receives an access token, OR an = AuthZ URI. Reading and refreshing an access token are the same = thing. 
A more complete list of changes is = below:

draft-hardt-xauth-protocol-05

  • separated claims from identifiers in request user object
  • simplified reciprocal grant flow
  • reduced interactions to redirect and indirect
  • simplified interaction parameters
  • added in language for Client to verify interaction = completion
  • added Verify Grant API and Interaction Nonce
  • replaced Refresh AuthZ with Read AuthZ.. Read and = refresh are same operation.

---------- = Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: = Sat, Mar 7, 2020 at 7:08 PM
Subject: New Version = Notification for draft-hardt-xauth-protocol-05.txt
To: = Dick Hardt <dick..hardt@gmail.com>



A new version of I-D, draft-hardt-xauth-protocol-05.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:          =  draft-hardt-xauth-protocol
Revision:       05
Title:          The XAuth Protocol
= Document date:  2020-03-07
Group:          Individual Submission
Pages:          59
URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol= -05.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protoco= l
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-= 05

Abstract:
   Client software often desires resources or identity claims = that are
   independent of the client.  This protocol allows a = user and/or
   resource owner to delegate resource authorization and/or = release of
   identity claims to a server.  Client software can then = request access
   to resources and/or identity claims by calling the = server.  The
   server acquires consent and authorization from the user = and/or
   resource owner if required, and then returns to the client = software
   the authorization and identity claims that were = approved.  This
   protocol can be extended to support alternative = authorizations,
   claims, interactions, and client authentication = mechanisms.




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


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_F3BA0888-8F66-4D29-9F0F-91BC6C176C16-- From nobody Tue Mar 10 07:12:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D2A3A0FDE for ; Tue, 10 Mar 2020 07:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_OTHER_BAD_TLD=1.998, 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 ReJhyEvZ_dqL for ; Tue, 10 Mar 2020 07:12:02 -0700 (PDT) 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 9FFAD3A0865 for ; Tue, 10 Mar 2020 07:12:02 -0700 (PDT) Received: from [192.168.1.5] (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 02AEBx9t015875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 10:12:00 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 10 Mar 2020 10:11:59 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <72806D82-664F-464A-B682-8F2E6F1AF616@mit.edu> References: To: Vijay IETF X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XAuth vs AuthZ vs ... X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:12:04 -0000 Vijay, it=E2=80=99s a great question. So what basically happened is that I have been developing my proposed = draft, XYZ, for over a year. We have implementations in multiple = languages that interop with each other, much of which is available open = source. When I proposed this working group, I put the XYZ spec = (draft-richer-transactional-authorization) up for consideration as the = starting point to the group. It=E2=80=99s been revised a number of times = based on feedback both from reviewers on and off the list as well as = implementers. There are a number of items that are not in the XYZ spec = that we marked as =E2=80=9Cthings to consider=E2=80=9D as it moves = forward =E2=80=94 multiple tokens, management endpoint URLs for tokens, = different key presentation mechanisms, etc. You can see notes of all of = this up on the website I made for the project, https://oauth.xyz/ . Why = aren=E2=80=99t these in the spec text itself? I didn=E2=80=99t want to = add anything in that we didn=E2=80=99t have at least one piece of code = for. The mantra of the IETF is =E2=80=9Crough consensus and running = code=E2=80=9D, and I strongly believe in that. Dick=E2=80=99s proposal, XAuth, is an exercise in a different way to = approach some of the same problems. As far as I am aware, there are no = extant implementations of XAuth. As you saw on the list, it has some = good ideas and there are some disagreements on how it goes about doing = things. Dick=E2=80=99s proposal is now also in consideration for an = input to the working group.=20 There is no =E2=80=9CTXAuth=E2=80=9D draft, yet. When the working group = forms, we will start with one draft, either the XYZ or the XAuth draft = or some combination of the two. It=E2=80=99s clear and expected that = whatever TXAuth turns out isn=E2=80=99t going to exactly be XYZ or = XAuth, and it=E2=80=99s entirely possible that it won=E2=80=99t look = like either. What I would recommend to the working group is to start with one and add = features in from the other as needed. They represent pretty deeply = different worldviews on how things talk and what is represented, and = take a very different philosophy to the =E2=80=9Cease of transition=E2=80=9D= part of the proposed charter.=20 My personal take would be to start with XYZ and add in what I think are = some of the best ideas in XAuth: - Management URLs for access tokens, separate from the transaction - OPTIONS on the tx endpoint for service discovery=20 - A way for the client to request and AS to return long and short URLs = for interaction (but using XYZ=E2=80=99s interaction structure) If the working group is chartered, this is the path that I hope we take, = and I volunteer myself to be the editor for the spec. It=E2=80=99s also = possible that some of these functions will be spun out into separate = documents, but that=E2=80=99s up to the eventual WG to figure out how = best to split things. =E2=80=94 Justin > On Mar 9, 2020, at 5:11 AM, Vijay IETF wrote: >=20 > Hi, >=20 > I spent yesterday catching up with the mailing list. That was too much = to digest in a day and I am still trying to figure out the boundaries = and scope.=20 >=20 > One thing that is not clear is regarding the multiple proposals in = draft form that have been going around. >=20 > The best disambiguation I could find was: > > To disambiguate between different efforts, I=E2=80=99ll refer to = Dick=E2=80=99s draft as XAuth, my own draft as XYZ, and the proposed = working group work here (as in our eventual output) as TxAuth.=20 > My question is do these proposals converge, compete or the best one by = consensus or otherwise supersedes the other? >=20 > Apologies if that is a dumb question. A map of = efforts/proposals/drafts of this WG would be quite helpful to new comers = such as myself. Thx! >=20 > --- > Vijay > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 10 07:13:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57F93A0EC9 for ; Tue, 10 Mar 2020 07:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, 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 KjQa9l9UPJn6 for ; Tue, 10 Mar 2020 07:13:37 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450: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 8B6EB3A0FE3 for ; Tue, 10 Mar 2020 07:13:37 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id a13so16530941edh.3 for ; Tue, 10 Mar 2020 07:13:37 -0700 (PDT) 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=CQtY2w4Mbh+OrSYA5nkUGIdksFy7BCxmHhDszbNTUsQ=; b=ZsnIZ7Ai9wPgMBwdGXm18tVsP03L2ERhzFQ7j53IhUwNpiiTolsUyysWwhKnQkmniu kJAfADLVfyYayyd0XEU/B+z5TGsGeXGxJ6/MRXwJeloFoYeq4CxPmyaWSnDgChaRm96b 6y9I1vlFhAuHxHXEvhYbQWvrQZMFkg+YnKaKhsVl7l/EAeY5k0rn7zOBPJPHqeJtSUmS sAJeaq2jdXFA/KPIPIO/5C4+Z6tkC7cHLQjTk6u4q1fky5SqkEJ7jfaNlboolSY3+SeX +d5U7Mut2PfBWdnC/US6Ikzhpyf42NjS4/PqFPKgHsmAgG0q/fbe27+33k9oauvSUBiy CDQw== 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=CQtY2w4Mbh+OrSYA5nkUGIdksFy7BCxmHhDszbNTUsQ=; b=gxevc+eKgCXysjaATMBIHpRkpTdpTTcJ7zMG9LUge7abwMOZK5qzpkIuxy3yfbpQzb /EM0tbFulA5ztRwXq0uaIYFdu4si4tQ1p0/wjYOXEcBAkhaJOTnXru64eZmi4Uiak7zF ZxlF15n/92jSVLeXwrKBOjP2KO+CXCzl/XtLVot5j0bgPE94Ue1EvbNTfRSacX01jg63 Whw1FLlgdvo/e1Z/nOxobGlv5MRFhKYxNrNECQNf1OqH5kG8x4cVO1Dyv4dLwyAFtqZL DOJJD1FXmHwQ8nLEGAchIj9iDVuvPim8FawYy4UTMtVNXEwQTOZxQNE9bY6HgVH8eheC BBYQ== X-Gm-Message-State: ANhLgQ0SSkAFQ+QqxdiYlCm4lrD4c4wRBZnoXvD9MK5j84exEyrBBHNG P2+p9q+QXpTExQt8G3rz4uZ1JjDkRmKF+caRDvI= X-Google-Smtp-Source: ADFU+vtCuVgZx2yExOyc4IzLvXv2PUwqtTsuG+mAa0zNNwxmvqK6PJdfHuzXE4KwPtc3IiYltouRaQoCRO0UUtjamyQ= X-Received: by 2002:a17:906:a2d3:: with SMTP id by19mr19524135ejb.7.1583849615844; Tue, 10 Mar 2020 07:13:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sudipta Pal Date: Tue, 10 Mar 2020 19:43:23 +0530 Message-ID: To: Yaron Sheffer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000baea8a05a080b978" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:13:40 -0000 --000000000000baea8a05a080b978 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 6 Mar, 2020, 10:15 pm Yaron Sheffer, wrote: > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > Yes. > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > Yes. > > 3. Are you willing to help review the drafts of this WG? > Yes > > 4. Are you interested in implementing drafts of this WG? > > Yes > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000baea8a05a080b978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 6 Mar, 20= 20, 10:15 pm Yaron Sheffer, <yaronf.ietf@gmail.com>= wrote:
Hi Everyone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu= th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i= n proceeding with this work.=C2=A0 Please do so by responding to the follow= ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?= =C2=A0 Or do you have major objections, blocking concerns or feedback (if s= o please elaborate)?

Yes.
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the= drafts of this WG?

Yes.
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?

Yes
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?

Yes

The call will run for two weeks, until March 21. If you think that the char= ter should be amended In a significant way, please reply on a separate thre= ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for= mation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver= as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---

This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authori= zing party to delegate access to client software through an authorization s= erver. It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework = for interaction among all parties involved in the protocol flow, and remove= unnecessary dependence on a browser or user-agent for coordinating interac= tions.

The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation = channel, which happens directly between the client and the authorization se= rver (in contrast with OAuth 2.0 which is initiated by the client redirecti= ng the user=E2=80=99s browser). The client and AS will involve a user to ma= ke an authorization decision as necessary through interaction mechanisms in= dicated by the protocol. This decoupling avoids many of the security concer= ns and technical challenges of OAuth 2.0 and provides a non-invasive path f= or supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t= he client requesting access
- A variety of client applications, including Web, mobile, single-page, and= interaction-constrained applications

The group will define extension points for this protocol to allow for flexi= bility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possessi= on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc= ess (including identity)

Additionally, the group will provide mechanisms for management of the proto= col lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt = to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol= where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily compatible with = OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope= d in the OAuth Working Group, including functionality back-ported from the = protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic met= hods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.

The initial work will focus on using HTTP for communication between the cli= ent and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin= g to other protocols such as COAP when doing so does not conflict with the = primary focus.

Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d= etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points


--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/ma= ilman/listinfo/txauth
--000000000000baea8a05a080b978-- From nobody Tue Mar 10 07:57:21 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD83A10A0 for ; Tue, 10 Mar 2020 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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, PDS_OTHER_BAD_TLD=1.998, 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=amanjeev.com header.b=Og7NlqW4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2IkjxES8 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 QxLfeVZ8ZBHJ for ; Tue, 10 Mar 2020 07:57:17 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3433A1091 for ; Tue, 10 Mar 2020 07:57:17 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 038368DE for ; Tue, 10 Mar 2020 10:57:16 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute2.internal (MEProxy); Tue, 10 Mar 2020 10:57:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amanjeev.com; h= mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=PjQtF4/ZMGuGUWcCWNNHmusBRzkvdiD1AoWL1Z0oKb4=; b=Og7NlqW4 zhOlXasQf190VHgMsS4CfKGDZvXIGPoQalrB2T0PmsKdWnrZ2/kZHKR7EWz2zTd3 Nkg7Rslye0r3UaTtthCVw9VhLEZotnUQCG6T6A4Lmu0O9G9WhjYRvpJs5sPCttFt lud01VOiecP2B7OxoKSdTJ8vSREt3ngHYT/0g1vrNoqPPbAUWytBnWskY1FpuzbN GP56mmQhXR8G6rI6DSE1RceI3Xc70+rRNfHYomxEy9tZkuzOP4zSepO4qNjqSI0M WpVYzak8CYuEDwG+o2N8m0kwQWqGXSjJObALRXR6rkNg2ud9xUx1zxz1WjdeDNSy s90D0Px5BIrgIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=PjQtF4/ZMGuGUWcCWNNHmusBRzkvd iD1AoWL1Z0oKb4=; b=2IkjxES8H3cHOhEXQfhGSPL1THLs0s19CJqNGVlEe9Zih Adv5lItqXCoSTJIc+1q9bY6oYZxIe4fvMwBDPlnpZIg/EHRXqHnpfOUmadkcnfJH NATIjWa9FxaYcWI5Mi5RxYRcaPKzrmH6gj1wFHTCInH7Eq3T/UZ+YLanLsEV2BH8 +5dnSrjjCZy76DlrsiJTB2Gz9GFMiXDPsWKkVnVhrQQWWGhERAXNllqk+uCBjQfL 6d8Tfh7eej0sSDIc0G27RJWs31qtIdBy9hnHp7AQee4N5I8J7ZiRkNOs2xwov9r5 ipT1KA21eWEzKuLkL+pXSGW1z7j66jYyN+bB5296A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvtddgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdlfeehmdenucfjughrpefofg ggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedftehmrghnjhgvvghvucfuvght hhhifdcuoegrjhesrghmrghnjhgvvghvrdgtohhmqeenucffohhmrghinhepohgruhhthh drgiihiienucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegrjhesrghmrghnjhgvvghvrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2C48C520094; Tue, 10 Mar 2020 10:57:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <73c482b5-351a-4fd0-b423-3ff987c3670e@www.fastmail.com> Date: Tue, 10 Mar 2020 10:56:53 -0400 From: "Amanjeev Sethi" To: txauth@ietf.org Content-Type: multipart/alternative; boundary=12dedc3593ab40b888c121dd50ba3a57 Archived-At: Subject: [Txauth] A Request/Response Flow Diagram X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:57:19 -0000 --12dedc3593ab40b888c121dd50ba3a57 Content-Type: text/plain Hello everyone, Is it possible to see or create a rough diagram of the current request/response understanding of TxAuth? I am trying to get the overview and sometimes I find it easier to look at this flow diagram to see the important parts of the protocol. If something like this exists already, could you please point me to that? I was hoping this https://oauth.xyz/interaction/ would host the diagrams. Best, AJ --12dedc3593ab40b888c121dd50ba3a57 Content-Type: text/html
Hello everyone,

Is it possible to see or create a rough diagram of the current request/response understanding of TxAuth?

I am trying to get the overview and sometimes I find it easier to look at this flow diagram to see the important parts of the protocol.

If something like this exists already, could you please point me to that? I was hoping this https://oauth.xyz/interaction/ would host the diagrams.

Best,
AJ
--12dedc3593ab40b888c121dd50ba3a57-- From nobody Tue Mar 10 09:01:55 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE8E3A1575 for ; Tue, 10 Mar 2020 09:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.998, 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 ixRIB3OccJTZ for ; Tue, 10 Mar 2020 09:01:31 -0700 (PDT) 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 2ED1F3A1565 for ; Tue, 10 Mar 2020 09:01:30 -0700 (PDT) Received: from [192.168.1.5] (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 02AG1OaO001042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Mar 2020 12:01:25 -0400 From: Justin Richer Message-Id: <97E201E9-43E2-4112-8C3B-A98F4E48DD10@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_7A195CC8-C971-425A-B79A-5D6FEC4B8FE0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Mar 2020 12:01:24 -0400 In-Reply-To: <73c482b5-351a-4fd0-b423-3ff987c3670e@www.fastmail.com> Cc: txauth@ietf.org To: Amanjeev Sethi References: <73c482b5-351a-4fd0-b423-3ff987c3670e@www.fastmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] A Request/Response Flow Diagram X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 16:01:37 -0000 --Apple-Mail=_7A195CC8-C971-425A-B79A-5D6FEC4B8FE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For XYZ, it depends on the kind of interaction you are doing and how = you=E2=80=99re getting back to things. If you=E2=80=99re doing a full = redirect back and forth, it looks like this: = https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgYnJ= vd3NlciBhcyBiCgANDGNsaWVudCBhcyBjAAsNdHJhbnNhY3Rpb25cbmVuZHBvaQAhBnQAMg1pb= nRlcgATFGkKCmMtPnQ6IHN0YXIAQA9DYWxsYmFjayB1cmwgKEMpXG5DAIEABm5vbmNlIChjbik= Kbm90ZSBvdmVyIGM6IHNob3VsZCAoQykgYmUgdW5pcXVlIHBlcgCBGgw_CnQtPmM6AIEtDCBoY= W5kbGUgKFQxKVxuSQCBIQogVVJMIChJKVxuU2VydmVyAHEIcwBsDXQ6IChJKSBpcwBbFwpjLT5= iOiBnbyB0byAoSSkKYi0-aTogPj4ABwY8AAkFYXV0aGVudGljYXRlIHVzZXIsAA4Fb3JpemUKa= QAsBUxvb2sgdXAAgmUORmluZACBDAUsAIILBSwgKEMpACkHY3JlYXRlAIJvDCByZWYgKFIAEg9= oYXNoOlxuKEgpID0ACAUoY24sIHNuLCAAJAZiOiBHAIE2BkMpXG4gaW5jbHVkZSAoSCksIChSK= SAKYgCCTAU-PgCDHgYAEAgAgw0OdmFsaWRhdAAyBQCDawcAgnYMY29udGludWUgcmVxdWVzdAC= DBwUAQQZ0AIQaBQA3CQCDLAwAGA1jOiBhY2Nlc3MgdG9rZW4gKEEpLCAoVDIpCgo&s=3Dearth= If you=E2=80=99re doing a user code with no callback, it looks like = this: = https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgdXN= lciBhcyB1CgAKDGJyb3cAEgdiAAwNY2xpZW50IGFzIGMAJA10cmFuc2FjdGlvblxuZW5kcG9pA= CEGdABLDQBpBWNvZGUAFw5pCgpjLT50OiBzdGFyAEANCnQtPmM6AFMMIGhhbmRsZSAoVDEpXG5= VAEkIIChVQwAICENvZGUgVVJMIChVQ1UpCmMtPnU6IGNvbW11bmljYXQAJgYsIG1heWIAMwVVK= Qp1LT5iOiBnbyB0bwAvB2ItPmk6ID4-AAcIPAALBWF1dGhlbnQAQQZ1c2VyCnUAIwVlbnQAfQw= KaQA5BUxvb2sgdXAAgUQNAD4Lb3JpemUKaQB2BXNob3cgImNvbXBsZXRlIiBtZXNzYWdlCgpsb= 29wIHBvbGwgd2hpbGUgd2FpdGluZwogICAgAIIvBmNvbnRpbnVlAIIZDShUbikAHwV0AB4GaGV= jawCCOg1zdGF0dXMAGwhjOgBUBSByZXNwb25zZSAoVCBuKzEpCmVuZAoAgn4HYWNjZXNzIHRva= 2VuIChBKQoKCg&s=3Dearth If you=E2=80=99re doing a QR code, it looks like: = https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGljaXBhbnQgdXN= lciBhcyB1CgAKDGJyb3cAEgdiAAwNY2xpZW50IGFzIGMAJA10cmFuc2FjdGlvblxuZW5kcG9pA= CEGdABLDUludGVyABMUaQoKYy0-dDogc3RhcgBCDQp0LT5jOgBVDCBoYW5kbGUgKFQxKVxuAEg= LIEUAcQgoSSkKYy0-dTogY29tbXVuaWNhdGUAEQV1LT5iOiBnbyB0bwAhBWItPmk6ID4-AAcGP= AAJBWF1dGhlbnQALwZ1c2VyCmkAIQVMb29rIHVwAIERDQAoC29yaXplCmkAXAVzaG93ICJjb21= wbGV0ZSIgbWVzc2FnZQoKbG9vcCBwb2xsIHdoaWxlIHdhaXRpbmcKICAgIACBfAZjb250aW51Z= QCBZg0oVG4pAB8FdAAeBmhlY2sAggcNc3RhdHVzABsIYzoAVAUgcmVzcG9uc2UgKFQgbisxKQp= lbmQKAIJLB2FjY2VzcyB0b2tlbiAoQSkKCgo&s=3Dearth I need to clean these up but I would like to put them up on the website = once they=E2=80=99re in good shape. =E2=80=94 Justin > On Mar 10, 2020, at 10:56 AM, Amanjeev Sethi wrote: >=20 > Hello everyone, >=20 > Is it possible to see or create a rough diagram of the current = request/response understanding of TxAuth? >=20 > I am trying to get the overview and sometimes I find it easier to look = at this flow diagram to see the important parts of the protocol. >=20 > If something like this exists already, could you please point me to = that? I was hoping this https://oauth.xyz/interaction/ = would host the diagrams. >=20 > Best, > AJ > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_7A195CC8-C971-425A-B79A-5D6FEC4B8FE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 For = XYZ, it depends on the kind of interaction you are doing and how = you=E2=80=99re getting back to things. If you=E2=80=99re doing a full = redirect back and forth, it looks like this:

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGlj= aXBhbnQgYnJvd3NlciBhcyBiCgANDGNsaWVudCBhcyBjAAsNdHJhbnNhY3Rpb25cbmVuZHBvaQ= AhBnQAMg1pbnRlcgATFGkKCmMtPnQ6IHN0YXIAQA9DYWxsYmFjayB1cmwgKEMpXG5DAIEABm5v= bmNlIChjbikKbm90ZSBvdmVyIGM6IHNob3VsZCAoQykgYmUgdW5pcXVlIHBlcgCBGgw_CnQtPm= M6AIEtDCBoYW5kbGUgKFQxKVxuSQCBIQogVVJMIChJKVxuU2VydmVyAHEIcwBsDXQ6IChJKSBp= cwBbFwpjLT5iOiBnbyB0byAoSSkKYi0-aTogPj4ABwY8AAkFYXV0aGVudGljYXRlIHVzZXIsAA= 4Fb3JpemUKaQAsBUxvb2sgdXAAgmUORmluZACBDAUsAIILBSwgKEMpACkHY3JlYXRlAIJvDCBy= ZWYgKFIAEg9oYXNoOlxuKEgpID0ACAUoY24sIHNuLCAAJAZiOiBHAIE2BkMpXG4gaW5jbHVkZS= AoSCksIChSKSAKYgCCTAU-PgCDHgYAEAgAgw0OdmFsaWRhdAAyBQCDawcAgnYMY29udGludWUg= cmVxdWVzdACDBwUAQQZ0AIQaBQA3CQCDLAwAGA1jOiBhY2Nlc3MgdG9rZW4gKEEpLCAoVDIpCg= o&s=3Dearth

If you=E2=80=99re doing a user code with no callback, it = looks like this:

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGlj= aXBhbnQgdXNlciBhcyB1CgAKDGJyb3cAEgdiAAwNY2xpZW50IGFzIGMAJA10cmFuc2FjdGlvbl= xuZW5kcG9pACEGdABLDQBpBWNvZGUAFw5pCgpjLT50OiBzdGFyAEANCnQtPmM6AFMMIGhhbmRs= ZSAoVDEpXG5VAEkIIChVQwAICENvZGUgVVJMIChVQ1UpCmMtPnU6IGNvbW11bmljYXQAJgYsIG= 1heWIAMwVVKQp1LT5iOiBnbyB0bwAvB2ItPmk6ID4-AAcIPAALBWF1dGhlbnQAQQZ1c2VyCnUA= IwVlbnQAfQwKaQA5BUxvb2sgdXAAgUQNAD4Lb3JpemUKaQB2BXNob3cgImNvbXBsZXRlIiBtZX= NzYWdlCgpsb29wIHBvbGwgd2hpbGUgd2FpdGluZwogICAgAIIvBmNvbnRpbnVlAIIZDShUbikA= HwV0AB4GaGVjawCCOg1zdGF0dXMAGwhjOgBUBSByZXNwb25zZSAoVCBuKzEpCmVuZAoAgn4HYW= NjZXNzIHRva2VuIChBKQoKCg&s=3Dearth

If you=E2=80=99re doing a QR code, it = looks like:

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DcGFydGlj= aXBhbnQgdXNlciBhcyB1CgAKDGJyb3cAEgdiAAwNY2xpZW50IGFzIGMAJA10cmFuc2FjdGlvbl= xuZW5kcG9pACEGdABLDUludGVyABMUaQoKYy0-dDogc3RhcgBCDQp0LT5jOgBVDCBoYW5kbGUg= KFQxKVxuAEgLIEUAcQgoSSkKYy0-dTogY29tbXVuaWNhdGUAEQV1LT5iOiBnbyB0bwAhBWItPm= k6ID4-AAcGPAAJBWF1dGhlbnQALwZ1c2VyCmkAIQVMb29rIHVwAIERDQAoC29yaXplCmkAXAVz= aG93ICJjb21wbGV0ZSIgbWVzc2FnZQoKbG9vcCBwb2xsIHdoaWxlIHdhaXRpbmcKICAgIACBfA= Zjb250aW51ZQCBZg0oVG4pAB8FdAAeBmhlY2sAggcNc3RhdHVzABsIYzoAVAUgcmVzcG9uc2Ug= KFQgbisxKQplbmQKAIJLB2FjY2VzcyB0b2tlbiAoQSkKCgo&s=3Dearth

I need to clean these = up but I would like to put them up on the website once they=E2=80=99re = in good shape.

 =E2=80=94 Justin


On Mar 10, 2020, at 10:56 AM, Amanjeev Sethi <aj@amanjeev.com> = wrote:

Hello = everyone,

Is it = possible to see or create a rough diagram of the current = request/response understanding of TxAuth?

I am trying to get the overview and sometimes I find = it easier to look at this flow diagram to see the important parts of the = protocol.

If = something like this exists already, could you please point me to that? I = was hoping this https://oauth.xyz/interaction/ would host the diagrams.

Best,
AJ
-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_7A195CC8-C971-425A-B79A-5D6FEC4B8FE0-- From nobody Tue Mar 10 09:07:51 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABDE3A157A for ; Tue, 10 Mar 2020 09:07:41 -0700 (PDT) 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 e2inkMugh-zv for ; Tue, 10 Mar 2020 09:07:39 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 2188F3A15BE for ; Tue, 10 Mar 2020 09:07:39 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id d79so13066445ywd.2 for ; Tue, 10 Mar 2020 09:07:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=0b11IY3ukrRMHXAki1En5sqEo1S2dlDZHb+dHshm5YA=; b=MENnOz5UufRDsUMQf2yngBdMFqhBF3bbLKhAW19sNLxldYKjPRUMK9qVUNtRHzqwrL sqYvkpyCD3re7DzmqjQiiu34PIDZb/8ddB0DJhkwP06Pnk3i6ssn8oVkKit9ai0J3qqC HYMC9YKiwMVJYCrPsn8EykFe+GsNXo4YjzDlIqVO7IUSGcd2fuMc+AmD+qPE57Jsumxr bvvcvWgv9UPbGIPLA04k6XAFMXLPlb8okWpmNY9zVooZOrF9bMWmsG+LDGDGvLuBTb2f c1Znob9ISWL7nVTV5+2xy8dTh0eLWVz5C5gPoOyW6cQleU8f5YxhlPMAhZP/76HOM+XQ Wwhg== 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:reply-to :from:date:message-id:subject:to; bh=0b11IY3ukrRMHXAki1En5sqEo1S2dlDZHb+dHshm5YA=; b=PSWd9XYAu/Fv0gGJOPLR3s5vFd2CmVWFIVeFNfsGXBtB7oS2cnys8DpGNO2bHylYpi hQ5WqCTafSXSxMCITVKBZi6G88Q4abRRo6j0hefObuSS6Z4TO6X0nkCxOkBV69F70ZSC WYUiGHZTO1a/l7a1e8GIYfJgwN/DbWbNPtodyZAjnVjNDDoJGzZRLMSjya+iV85vYWOn 1lKo0kRgG8kHg/pF+FY28jawZSNYwaLvfh8QO0NDa0HjpP9o/xEOMMSph5cP1OMRIcgk yMpzqY8/pOvRfgs+ApOCggY2vg2lK00/A7X6fW5x4eC2JNrlDTdiF0T5gdn7IB4q5Kbh oLNg== X-Gm-Message-State: ANhLgQ3S3LCtEIl97M32D1aB2dj4j/Mn5zyHbALd/9g2BgqHFqjJHkRZ Ce9UZDW24ldFlBrxk5M5xMEuadDcnMGJy9+RIQJX3MGUhg== X-Google-Smtp-Source: ADFU+vsc7E6N5Rrv5J2K6+/eNyhL0sxx+KE5o9FiTzRLqvrE3liNA5vhbCUbJxUqJcdDX2ePW6hqV8AHztMaG9AZvXg= X-Received: by 2002:a25:a2cc:: with SMTP id c12mr11338892ybn.70.1583856457000; Tue, 10 Mar 2020 09:07:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: dzagidulin@gmail.com From: Dmitri Zagidulin Date: Tue, 10 Mar 2020 12:07:25 -0400 Message-ID: To: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007eabbe05a082514a" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 16:07:49 -0000 --0000000000007eabbe05a082514a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 1. Do you support the charter text provided at the end of this email? Or do you have major objections, blocking concerns or feedback (if so please elaborate)? Yes. > > 2. Are you willing to author or participate in the development of the drafts of this WG? Yes, and am also volunteering to help edit. > > 3. Are you willing to help review the drafts of this WG? Yes. > > 4. Are you interested in implementing drafts of this WG? Yes, and I have implemented one of the input drafts (client side and server side). On Tue, Mar 10, 2020 at 9:47 AM Justin Richer wrote: > On Mar 6, 2020, at 11:44 AM, Yaron Sheffer wrote: > > > > Hi Everyone, > > > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > > > 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > Yes. > > > > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > Yes, and I am volunteering to edit. > > > > > 3. Are you willing to help review the drafts of this WG? > > Yes. > > > > > 4. Are you interested in implementing drafts of this WG? > > Yes, and I have implemented one of the input drafts. > > > > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > > > Thanks, > > Yaron and Dick > > > > --- Charter Text Follows --- > > > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > > > Additionally, the delegation process will allow for: > > > > - Fine-grained specification of access > > - Approval of AS attestation to identity claims > > - Approval of access to multiple resources and APIs in a single > interaction > > - Separation between the party authorizing access and the party > operating the client requesting access > > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > > - Cryptographic agility for keys, message signatures, and proof of > possession > > - User interaction mechanisms including web and non-web methods > > - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > > - Optimized inclusion of additional information through the delegation > process (including identity) > > > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > > > - Discovery of the authorization server > > - Revocation of active tokens > > - Query of token rights by resource servers > > > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > > > Milestones to include: > > - Core delegation protocol > > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > > - Identity and authentication conveyance mechanisms > > - Guidelines for use of protocol extension points > > > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007eabbe05a082514a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> 1.=C2=A0 Do you support the charter text provided at the = end of this email?=C2=A0 Or do you have major objections, blocking concerns= or feedback (if so please elaborate)?

Yes.

>=C2=A0
> 2.=C2=A0 Are= you willing to author or participate in the development of the drafts of t= his WG?

Yes, and am also volunteering to help edit.

>=C2=A0
> 3.= =C2=A0 Are you willing to help review the drafts of this WG?

= Yes.

>=C2= =A0
> 4.=C2=A0 Are you interested in implementing drafts of this WG?<= br>
Yes, and I have implemented one of the input drafts (client s= ide and server side).

On Tue, Mar 10, 2020 at 9:47 AM Justin Richer <= jricher@mit.edu> wrote:
=
On Mar 6, 2020, at 11:44 = AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>
> Hi Everyone,
>=C2=A0
> It appears that momentum is forming around the proposed formation of a= TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge inter= est in proceeding with this work.=C2=A0 Please do so by responding to the f= ollowing questions:
>=C2=A0
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?

Yes.

>=C2=A0
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?

Yes, and I am volunteering to edit.

>=C2=A0
> 3.=C2=A0 Are you willing to help review the drafts of this WG?

Yes.

>=C2=A0
> 4.=C2=A0 Are you interested in implementing drafts of this WG?

Yes, and I have implemented one of the input drafts.

>=C2=A0
> The call will run for two weeks, until March 21. If you think that the= charter should be amended In a significant way, please reply on a separate= thread.
>=C2=A0
> The feedback provided here will help the IESG come to a decision on th= e formation of a new WG. Given the constraints of the chartering process, r= egardless of the outcome of this consensus call, we will be meeting in Vanc= ouver as a BoF.
>=C2=A0
> Thanks,
> Yaron and Dick
>=C2=A0
> --- Charter Text Follows ---
>
> This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an au= thorizing party to delegate access to client software through an authorizat= ion server. It will expand upon the uses cases currently supported by OAuth= 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support autho= rizations scoped as narrowly as a single transaction, provide a clear frame= work for interaction among all parties involved in the protocol flow, and r= emove unnecessary dependence on a browser or user-agent for coordinating in= teractions.
>
> The delegation process will be acted upon by multiple parties in the p= rotocol, each performing a specific role. The protocol will decouple the in= teraction channels, such as the end user=E2=80=99s browser, from the delega= tion channel, which happens directly between the client and the authorizati= on server (in contrast with OAuth 2.0 which is initiated by the client redi= recting the user=E2=80=99s browser). The client and AS will involve a user = to make an authorization decision as necessary through interaction mechanis= ms indicated by the protocol. This decoupling avoids many of the security c= oncerns and technical challenges of OAuth 2.0 and provides a non-invasive p= ath for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>
> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single intera= ction
> - Separation between the party authorizing access and the party operat= ing the client requesting access
> - A variety of client applications, including Web, mobile, single-page= , and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for = flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of pos= session
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pie= ces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding res= ource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation= process (including identity)
>
> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Query of token rights by resource servers
>
> Although the artifacts for this work are not intended or expected to b= e backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att= empt to simplify migrating from OAuth 2.0 and OpenID Connect to the new pro= tocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as= such will focus on new technological solutions not necessarily compatible = with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be dev= eloped in the OAuth Working Group, including functionality back-ported from= the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographi= c methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods.
>
> The initial work will focus on using HTTP for communication between th= e client and the authorization server, taking advantage of optimization fea= tures of HTTP2 and HTTP3 where possible, and will strive to enable simple m= apping to other protocols such as COAP when doing so does not conflict with= the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, de= tached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007eabbe05a082514a-- From nobody Tue Mar 10 13:14:45 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CE83A0C6C for ; Tue, 10 Mar 2020 13:14:37 -0700 (PDT) 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 FzqZ7ecAWO_7 for ; Tue, 10 Mar 2020 13:14:35 -0700 (PDT) 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 2FCD93A0C59 for ; Tue, 10 Mar 2020 13:14:34 -0700 (PDT) Received: from [192.168.1.5] (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 02AKEWtI004658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Mar 2020 16:14:33 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_1DB1072D-2C3D-49BE-8AA2-B40D5E7FAF93" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <381041C9-6B38-4297-9DE3-57424A8B80C8@mit.edu> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> To: txauth@ietf.org Date: Tue, 10 Mar 2020 16:14:32 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Fwd: [107all] IETF 107 Vancouver In-Person Meeting Cancelled X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 20:14:44 -0000 --Apple-Mail=_1DB1072D-2C3D-49BE-8AA2-B40D5E7FAF93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See below =E2=80=94 the in-person meeting has been cancelled by the = IESG. Hopefully we will still be able to have virtual meetings during = the week. More details forthcoming as they=E2=80=99re available, I=E2=80=99= m sure. =E2=80=94 Justin > Begin forwarded message: >=20 > From: The IESG > Subject: [107all] IETF 107 Vancouver In-Person Meeting Cancelled > Date: March 10, 2020 at 3:10:27 PM EDT > To: "IETF Announcement List" > Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org > Reply-To: iesg@ietf.org >=20 > The IESG and the IRTF Chair have decided to cancel the in-person IETF = 107 Vancouver meeting. This decision is based on input we gathered from = Working Group (WG) and Research Group (RG) chairs about our ability to = hold productive WG and RG sessions at IETF 107. Our assessment of this = feedback is that a majority of sessions would not be viable if we were = to hold the in-person IETF meeting. On this basis, we believe we cannot = hold an effective in-person meeting.=20 >=20 > As a result of this cancellation, the in-person Hackathon, Code = Sprint, all other in-person events planned for the weekend of March = 21-22, the chairs training scheduled for March 20, and all other = in-person sessions during the week are cancelled. >=20 > The IESG is working on an alternative all-virtual agenda for the week = of March 21-27 with a limited schedule adapted to accommodate the time = zones of as many participants as possible. We are also planning to = support an increased volume of virtual interim meetings during the weeks = that follow. We will send another update to the community soon with more = information about these plans. The Hackathon organizers are also = considering plans for virtual Hackathon support. >=20 > We have re-opened Internet-Draft submissions, which had been closed on = March 9 in anticipation of the in-person meeting. Internet-Drafts may be = submitted at . >=20 > A separate announcement from the IETF Executive Director will follow = with details about registration cancellations and refunds. =20 >=20 > These are unusual times given the circumstances created by the spread = of COVID-19. We hope that everyone remains safe and healthy. >=20 > Regards, > The IESG and the IRTF Chair >=20 > --=20 > 107all mailing list > 107all@ietf.org > https://www.ietf.org/mailman/listinfo/107all --Apple-Mail=_1DB1072D-2C3D-49BE-8AA2-B40D5E7FAF93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 See = below =E2=80=94 the in-person meeting has been cancelled by the IESG. = Hopefully we will still be able to have virtual meetings during the = week. More details forthcoming as they=E2=80=99re available, I=E2=80=99m = sure.

 =E2=80=94 = Justin

Begin forwarded message:

From: = The IESG <iesg@ietf.org>
Subject: = [107all] IETF 107 = Vancouver In-Person Meeting Cancelled
Date: = March 10, 2020 at 3:10:27 PM = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org
Reply-To: = iesg@ietf.org

The IESG and the IRTF Chair = have decided to cancel the in-person IETF 107 Vancouver meeting. This = decision is based on input we gathered from Working Group (WG) and = Research Group (RG) chairs about our ability to hold productive WG and = RG sessions at IETF 107. Our assessment of this feedback is that a = majority of sessions would not be viable if we were to hold the = in-person IETF meeting. On this basis, we believe we cannot hold an = effective in-person meeting.

As a result = of this cancellation, the in-person Hackathon, Code Sprint, all other = in-person events planned for the weekend of March 21-22, the chairs = training scheduled for March 20, and all other in-person sessions during = the week are cancelled.

The IESG is working = on an alternative all-virtual agenda for the week of March 21-27 with a = limited schedule adapted to accommodate the time zones of as many = participants as possible. We are also planning to support an increased = volume of virtual interim meetings during the weeks that follow. We will = send another update to the community soon with more information about = these plans. The Hackathon organizers are also considering plans for = virtual Hackathon support.

We have = re-opened Internet-Draft submissions, which had been closed on March 9 = in anticipation of the in-person meeting. Internet-Drafts may be = submitted at <https://datatracker.ietf.org/submit/>.
A separate announcement from the IETF Executive Director = will follow with details about registration cancellations and refunds. =  

These are unusual times given the = circumstances created by the spread of COVID-19.  We hope that = everyone remains safe and healthy.

Regards,
The IESG and the IRTF Chair

--
107all mailing list
107all@ietf.org
https://www.ietf.org/mailman/listinfo/107all

= --Apple-Mail=_1DB1072D-2C3D-49BE-8AA2-B40D5E7FAF93-- From nobody Wed Mar 11 00:38:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8526E3A13FD for ; Wed, 11 Mar 2020 00:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, PDS_OTHER_BAD_TLD=1.998, 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 NRClUGs5DVP6 for ; Wed, 11 Mar 2020 00:38:43 -0700 (PDT) Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (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 B94C03A0A2C for ; Wed, 11 Mar 2020 00:38:43 -0700 (PDT) Received: by mail-il1-x142.google.com with SMTP id g126so1089862ilh.2 for ; Wed, 11 Mar 2020 00:38:43 -0700 (PDT) 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=2AHIRPF24JaFKgkOGNyN08/O8rXHhX4UFOERy8o1etM=; b=PUxNYuef+kgWVqEeR9rUTvrYGQHRaLxObOkA3c6Xb9asxQ5I6EeWcip0Xn2DfEAVct vgA7DODODeU5fz5FdgeeSa6pC8Ry55U6ypCQXdczgH8xcQmAlLOLdW34aHF/BwMAkDUE qv/bQCyzO75sjAgpHJZBMUP3SHCIgHs405TWoIWYHSPol3FkOkfFenqgJSRUCzGZAYAM jNllsb2wDCN2FkV8tvbhQkn06oiuXe/ptvxSouZtJkd/G/CdAUHnpFGj0g5rYMlSa9E2 4qziZum6HOZmurJuZFEGM1Y3ELpqEBcL3FutZYnBRk4ZYRlo1EV2hLoGNnky3DGdyFU1 qW/w== 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=2AHIRPF24JaFKgkOGNyN08/O8rXHhX4UFOERy8o1etM=; b=crXsp+bh6JwOAWDfQRIcNPhXljeJ/7jC7s5tegiRyFjE7AbxOzOxNnAvl9SUD0N4ga vKPPtEmWkLoBxDnmpaLRXbNMQigXLrGyabctlBprGlzJZ25QwEoW4OAANOp2jlSr89yj IRwJcOa3yKXaoQooWMxNEnSWkcLpjo7QGMd9IjScVj6GbfWadgBNT2kJ8oSVdpRzbWNI EKwplGkyqiearSJ87dmWokUHE9m8UqlbfJvnmnKGNsvGQznq/mAvguF3R4pYpLwmhlXF BuwUB8YmTaUoI5tAyWwi7K/2vQBcyac0awaPiFyqULzMmcT7h2Jmm3xGRjOIHDyTqKfz TKnw== X-Gm-Message-State: ANhLgQ1WxP723ZYm/slw+iSkrkRv/BbslElglVZ0bc4mhqbc2OHCAbXy Qn4tswfX9y5e0GLkmGG4zBw/I+yA0T9R/sFQ3fU= X-Google-Smtp-Source: ADFU+vsj28Sn2ssJbK16mOX0Yn8Yn6/zvBYSfkIi3j+hPvE2qV6p9ldgpseT1kdQyHIYIUKNPv+yUzVAb+SallYNWNA= X-Received: by 2002:a92:b606:: with SMTP id s6mr1728506ili.123.1583912322967; Wed, 11 Mar 2020 00:38:42 -0700 (PDT) MIME-Version: 1.0 References: <72806D82-664F-464A-B682-8F2E6F1AF616@mit.edu> In-Reply-To: <72806D82-664F-464A-B682-8F2E6F1AF616@mit.edu> From: Vijay IETF Date: Wed, 11 Mar 2020 13:08:31 +0530 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005dae9f05a08f53c5" Archived-At: Subject: Re: [Txauth] XAuth vs AuthZ vs ... X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 07:38:46 -0000 --0000000000005dae9f05a08f53c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin, Thanks. The fog is lifting :-) Fwiw, I am a strong believer of =E2=80=9Crough consensus and running code= =E2=80=9D as well. --- Vijay On Tue, 10 Mar 2020 at 19:42, Justin Richer wrote: > Vijay, it=E2=80=99s a great question. > > So what basically happened is that I have been developing my proposed > draft, XYZ, for over a year. We have implementations in multiple language= s > that interop with each other, much of which is available open source. Whe= n > I proposed this working group, I put the XYZ spec > (draft-richer-transactional-authorization) up for consideration as the > starting point to the group. It=E2=80=99s been revised a number of times = based on > feedback both from reviewers on and off the list as well as implementers. > There are a number of items that are not in the XYZ spec that we marked a= s > =E2=80=9Cthings to consider=E2=80=9D as it moves forward =E2=80=94 multip= le tokens, management > endpoint URLs for tokens, different key presentation mechanisms, etc. You > can see notes of all of this up on the website I made for the project, > https://oauth.xyz/ . Why aren=E2=80=99t these in the spec text itself? I = didn=E2=80=99t > want to add anything in that we didn=E2=80=99t have at least one piece of= code for. > The mantra of the IETF is =E2=80=9Crough consensus and running code=E2=80= =9D, and I > strongly believe in that. > > Dick=E2=80=99s proposal, XAuth, is an exercise in a different way to appr= oach some > of the same problems. As far as I am aware, there are no extant > implementations of XAuth. As you saw on the list, it has some good ideas > and there are some disagreements on how it goes about doing things. Dick= =E2=80=99s > proposal is now also in consideration for an input to the working group. > > There is no =E2=80=9CTXAuth=E2=80=9D draft, yet. When the working group f= orms, we will > start with one draft, either the XYZ or the XAuth draft or some combinati= on > of the two. It=E2=80=99s clear and expected that whatever TXAuth turns ou= t isn=E2=80=99t > going to exactly be XYZ or XAuth, and it=E2=80=99s entirely possible that= it won=E2=80=99t > look like either. > > What I would recommend to the working group is to start with one and add > features in from the other as needed. They represent pretty deeply > different worldviews on how things talk and what is represented, and take= a > very different philosophy to the =E2=80=9Cease of transition=E2=80=9D par= t of the proposed > charter. > > My personal take would be to start with XYZ and add in what I think are > some of the best ideas in XAuth: > - Management URLs for access tokens, separate from the transaction > - OPTIONS on the tx endpoint for service discovery > - A way for the client to request and AS to return long and short URLs > for interaction (but using XYZ=E2=80=99s interaction structure) > > If the working group is chartered, this is the path that I hope we take, > and I volunteer myself to be the editor for the spec. It=E2=80=99s also p= ossible > that some of these functions will be spun out into separate documents, bu= t > that=E2=80=99s up to the eventual WG to figure out how best to split thin= gs. > > =E2=80=94 Justin > > > On Mar 9, 2020, at 5:11 AM, Vijay IETF wrote: > > > > Hi, > > > > I spent yesterday catching up with the mailing list. That was too much > to digest in a day and I am still trying to figure out the boundaries and > scope. > > > > One thing that is not clear is regarding the multiple proposals in draf= t > form that have been going around. > > > > The best disambiguation I could find was: > > > To disambiguate between different efforts, I=E2=80=99ll refer to Dick= =E2=80=99s draft > as XAuth, my own draft as XYZ, and the proposed working group work here (= as > in our eventual output) as TxAuth. > > My question is do these proposals converge, compete or the best one by > consensus or otherwise supersedes the other? > > > > Apologies if that is a dumb question. A map of efforts/proposals/drafts > of this WG would be quite helpful to new comers such as myself. Thx! > > > > --- > > Vijay > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > --0000000000005dae9f05a08f53c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin,

Thanks. The fog= is lifting :-)

Fwiw, I am a strong believer of = =E2=80=9Crough consensus and running code=E2=80=9D as well.

<= /div>
---
Vijay

On Tue, 10 Mar 2020 at 19:42, Justin= Richer <jricher@mit.edu> wrot= e:
Vijay, it=E2= =80=99s a great question.

So what basically happened is that I have been developing my proposed draft= , XYZ, for over a year. We have implementations in multiple languages that = interop with each other, much of which is available open source. When I pro= posed this working group, I put the XYZ spec (draft-richer-transactional-au= thorization) up for consideration as the starting point to the group. It=E2= =80=99s been revised a number of times based on feedback both from reviewer= s on and off the list as well as implementers. There are a number of items = that are not in the XYZ spec that we marked as =E2=80=9Cthings to consider= =E2=80=9D as it moves forward =E2=80=94 multiple tokens, management endpoin= t URLs for tokens, different key presentation mechanisms, etc. You can see = notes of all of this up on the website I made for the project, https://oauth.xyz/<= /a> . Why aren=E2=80=99t these in the spec text itself? I didn=E2=80=99t wa= nt to add anything in that we didn=E2=80=99t have at least one piece of cod= e for. The mantra of the IETF is =E2=80=9Crough consensus and running code= =E2=80=9D, and I strongly believe in that.

Dick=E2=80=99s proposal, XAuth, is an exercise in a different way to approa= ch some of the same problems. As far as I am aware, there are no extant imp= lementations of XAuth. As you saw on the list, it has some good ideas and t= here are some disagreements on how it goes about doing things. Dick=E2=80= =99s proposal is now also in consideration for an input to the working grou= p.

There is no =E2=80=9CTXAuth=E2=80=9D draft, yet. When the working group for= ms, we will start with one draft, either the XYZ or the XAuth draft or some= combination of the two. It=E2=80=99s clear and expected that whatever TXAu= th turns out isn=E2=80=99t going to exactly be XYZ or XAuth, and it=E2=80= =99s entirely possible that it won=E2=80=99t look like either.

What I would recommend to the working group is to start with one and add fe= atures in from the other as needed. They represent pretty deeply different = worldviews on how things talk and what is represented, and take a very diff= erent philosophy to the =E2=80=9Cease of transition=E2=80=9D part of the pr= oposed charter.

My personal take would be to start with XYZ and add in what I think are som= e of the best ideas in XAuth:
=C2=A0- Management URLs for access tokens, separate from the transaction =C2=A0- OPTIONS on the tx endpoint for service discovery
=C2=A0- A way for the client to request and AS to return long and short URL= s for interaction (but using XYZ=E2=80=99s interaction structure)

If the working group is chartered, this is the path that I hope we take, an= d I volunteer myself to be the editor for the spec. It=E2=80=99s also possi= ble that some of these functions will be spun out into separate documents, = but that=E2=80=99s up to the eventual WG to figure out how best to split th= ings.

=C2=A0=E2=80=94 Justin

> On Mar 9, 2020, at 5:11 AM, Vijay IETF <vijay.ietf@gmail.com> wrote:
>
> Hi,
>
> I spent yesterday catching up with the mailing list. That was too much= to digest in a day and I am still trying to figure out the boundaries and = scope.
>
> One thing that is not clear is regarding the multiple proposals in dra= ft form that have been going around.
>
> The best disambiguation I could find was:
> > To disambiguate between different efforts, I=E2=80=99ll refer to = Dick=E2=80=99s draft as XAuth, my own draft as XYZ, and the proposed workin= g group work here (as in our eventual output) as TxAuth.
> My question is do these proposals converge, compete or the best one by= consensus or otherwise supersedes the other?
>
> Apologies if that is a dumb question. A map of efforts/proposals/draft= s of this WG would be quite helpful to new comers such as myself. Thx!
>
> ---
> Vijay
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--0000000000005dae9f05a08f53c5-- From nobody Wed Mar 11 02:50:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B793A160B for ; Wed, 11 Mar 2020 02:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, PDS_OTHER_BAD_TLD=1.998, 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 Rb5AQyJcIeC0 for ; Wed, 11 Mar 2020 02:50:05 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 F2E393A1623 for ; Wed, 11 Mar 2020 02:50:04 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id f21so1241558otp.12 for ; Wed, 11 Mar 2020 02:50:04 -0700 (PDT) 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=4NGIVc1bLn4RgPX5tg1K4HsLyDOfp/9a7G1kLZUlCTQ=; b=oYQVlxyS3fUJDlqGFmwlqcU2Tw//penf0Hl4NM7ivFuw/5TD1fgWDpn7H3AfarM3Oh lvB4sK7Aop5Upah1dNuVo8IH2fF5IhNYKdZf1MaJ7Sm327+C2/T8twSwY8/jIMr03njG 5jTEYYhtyIvACywVn87iUsh0XnRO0iuHJk3snIN0cbinXGk55iV+/WOcbzmCOAaM1tdp nQWBYvV+mZ1VzpOAStMW1iamFLFtoJkf3mCeWaRN+LxtuJdfGXHoTlHb7Xr1ru75ilZd Zz3y9aGrBczlqNvukvymJID7drGWGlnEeBo1MDMZ/IkQ6/F2ox8oopPlDq2ZYBlqkbmq +qlQ== 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=4NGIVc1bLn4RgPX5tg1K4HsLyDOfp/9a7G1kLZUlCTQ=; b=eNKVHaBa+N4KTQeMmX6cmJItFY6WKsm0kfnelTZ5yVozmaA/WWm9U/d6xdIdso4xI2 WmywayOIKeurXbUWVAxqQWxSArKI1X1fMib5pxyCguxWITET3sUNw80pANRiBmunz2nw +cLfJZc0YkR0G2F6eK5u5dODHgFWRGKSzfjP2lIg7DDaTerRjsBKPocSQ4bivJlpA4YX HfgnycQvytUr9+LfcLhGECjDjVzutXxZ86vLG9t8IBY0QvCIkce0OrHEbmimLrgQoOgZ L3U5GTV9SByEQSRCY3hFb9eOKu/Ur/oghQfuD76ndSjYh4hZWwWfPXW3F2UP8oCsdwRk VAkA== X-Gm-Message-State: ANhLgQ0ax4dtetxuGSIMBeDEtrC2kWIs2NkUTr/3f1qsPXKxpuAbU3gu 4KIKkE9siTTy/VTk6ootTd+7Ve1oKLMBeKqkxo4BGNCMUAk= X-Google-Smtp-Source: ADFU+vtcSOeCtBiddIPCpUsOcQIQdQgK1iQw/0mW013dOnzDuhIGKXTOwT4dfgRLe0ZdqcBkxNJjVKMsdeLAVMPuP/k= X-Received: by 2002:a05:6830:19e2:: with SMTP id t2mr1549951ott.97.1583920203748; Wed, 11 Mar 2020 02:50:03 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Wed, 11 Mar 2020 10:49:52 +0100 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000018dbc505a0912990" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 09:50:15 -0000 --00000000000018dbc505a0912990 Content-Type: text/plain; charset="UTF-8" Hello, Thanks for the work being done. I'm new to IETF (but have worked in the past with other collaborative orgs) so please forgive any unusual habits if any, will try to catch up. > 1. Do you support the charter text provided at the end of this email? Or do you have major objections, blocking concerns or feedback (if so please elaborate)? Yes, with comments. I believe the last part of the charter : "will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus" should be modified, to acknowledge what is really in the scope and what is not. As it is written, I actually don't know very well. Certainly the main goal is HTTP support and that is already a large challenge which needs to be handled with priority. However we need to acknowledge contrained devices are now very common, people want to manage them properly but usually those devices don't speak well over HTTP. From the content available on oauth.xyz, I have the impression that the use case is in the scope. That makes also be a great differentiation compared to OAuth2, and one doesn't have to fight so much with change management as the field is much newer, compared to webapps. In the IoT domain, that would be very useful because implementing delegation at scale is a real/unsolved issue. But as the charter is currently written, it is unclear what "simple mapping" really means and whether that could work out in practice as an after thought. I also have the feeling that saying the mapping to other protocols should not conflict with the primary focus doesn't make it so much clearer on what is exactly expected. Supporting a variety of IoT protocols is obviously out of question. So I suggest we get back to the requirements, and would propose the following: the protocol shall be usable by constrained devices, provided they can discuss over an IP network such as CoAP (see the work on OAuth2 ACE for instance), SCHC (which is also an upcoming IETF RFC) or other future protocols that would allow the interface to match with HTTP behaviour (through an adaptor). For those types of clients, the communication stack (supported and/or prefered) could be declared in a pre-register phase. What would still be out of scope is to design network protocol independance within TXAUTH. For instance, stateful data centric protocols such as MQTT would be out of scope. My team and myself are available to work on this (both on spec and opensource implementation prototype), and make constrained devices a first class citizen, if you agree that's indeed a common need. Of course, I do not intend this to be the priority, but more as a way to take feedback and make sure the protocol's design doesn't forbid such demands, likely to become mainstream. Please let me know what you think. > 2. Are you willing to author or participate in the development of the drafts of this WG? Yes. > 3. Are you willing to help review the drafts of this WG? Yes. > 4. Are you interested in implementing drafts of this WG? Yes, rust implementation (and webassembly bindings). Best regards, Fabien --00000000000018dbc505a0912990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

Thanks for the work being done. I'm new to= IETF (but have worked in the past with other collaborative orgs) so please= forgive any unusual habits if any, will try to catch up.=C2=A0 =C2=A0

> 1.=C2=A0 Do you support the charter text prov= ided at the end of this email?=C2=A0 Or do you have major objections, block= ing concerns or feedback (if so please elaborate)?

Yes, with = comments.

I believe the last part of the chart=
er : "will strive to enable simple mapping to other protocols such as =
COAP when doing so does not conflict with the primary focus" should be=
 modified, to acknowledge what is really in the scope and what is not. As i=
t is written, I actually don't know very well.  
Certain=
ly the main goal is HTTP support and that is already a large challenge whic=
h needs to be handled with priority. 
However we need to ack=
nowledge contrained devices are now very common, people want to manage them=
 properly but usually those devices don't speak well over HTTP. From th=
e content available on oauth.xyz, I have t=
he impression that the use case is in the scope. That makes also be a great=
 differentiation compared to OAuth2, and one doesn't have to fight so m=
uch with change management as the field is much newer, compared to webapps.=
 In the IoT domain, that would be very useful because implementing delegati=
on at scale is a real/unsolved issue. 
But as the charter is=
 currently written, it is unclear what "simple mapping" really me=
ans and whether that could work out in practice as an after thought. I also=
 have the feeling that saying the mapping to other protocols should not con=
flict with the primary focus doesn't make it so much clearer on what is=
 exactly expected.
Supporting a variety of IoT protocols is =
obviously out of question. So I suggest we get back to the requirements, an=
d would propose the following: the protocol shall be usable by constrained =
devices, provided they can discuss over an IP network such as CoAP (see the=
 work on OAuth2 ACE for instance), SCHC (which is also an upcoming IETF RFC=
) or other future protocols that would allow the interface to match with HT=
TP behaviour (through an adaptor). For those types of clients, the communic=
ation stack (supported and/or prefered) could be declared in a pre-register=
 phase. 
What would still be out of scope is to design netwo=
rk protocol independance within TXAUTH. For instance, stateful data centric=
 protocols such as MQTT would be out of scope.
My team and m=
yself are available to work on this (both on spec and opensource implementa=
tion prototype), and make constrained devices a first class citizen, if you=
 agree that's indeed a common need. Of course, I do not intend this to =
be the priority, but more as a way to take feedback and make sure the proto=
col's design doesn't forbid such demands, likely to become mainstre=
am.
Please let me know what you think.

> 2.=C2=A0 Are you willing to author or participate in the = development of the drafts of this WG?

Yes.
=C2=A0
> 3.=C2=A0 Are you willing to help review = the drafts of this WG?

Yes.

> 4.=C2=A0 Are you interested in implementing drafts of this WG= ?

Yes, rust implementation (and webassembly bindings).

Best regards,

Fabien
<= /div> --00000000000018dbc505a0912990-- From nobody Wed Mar 11 04:34:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E833A1789 for ; Wed, 11 Mar 2020 04:34:32 -0700 (PDT) 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=coil.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 K6T1X8lTUx2B for ; Wed, 11 Mar 2020 04:34:30 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450: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 2A8543A1788 for ; Wed, 11 Mar 2020 04:34:30 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id a20so2471319edj.2 for ; Wed, 11 Mar 2020 04:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wVgyp+K69Fo7DMh3hwiVeJujyPOAKEN6PyOsnrB5R14=; b=k7L0T1TaPmTmQLEHxy9wkbs58J+Q/llkzXFz5PwT0tnhz3aBzbsyUTBVs8ffI59he+ yge7Git9YVa+i+H85dftNQKXnUsgFclNHpIPPl9p/5nbH6zJ9IfKyJ0xmRFZdJYkP/Pm eG2tVoqaO1dI1+tHvClFzrlekg8kXsftWpS8mKyVm9tm7wLbi3jUapuJHX1W+WqhRobw fClNXoOhT7NyJjx6ZSb3BfJvXkhZ11WQclp+n5SoZnrHATZzuZwEJr/YDwFOUJJjCvMD bPtmfJC3mGasM2yq0+Is5UxQ8EKrkJmvq+VX2XwWkEYupDH58pP2pXHWXxlrClDdT98F nSYg== 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=wVgyp+K69Fo7DMh3hwiVeJujyPOAKEN6PyOsnrB5R14=; b=s4Ihr9SJmYBYur+2OVTq6VV2YLAReWxhu2ZMHkCdCTxfjqRFpWkO5Co3OfSi14RdGn z5hWlOMHDWuVTz0It1Ag2z7Z6CG3bv/GOvfiaW+nkH37+PFN3CTn/Kg7jRluI0pCOXLy eo6ty7D352+iXEyD/4dyWavEEMBwqCxNZpl1GVqXegTyxAZqVqis4aEIRljS4XAX8Uze l15ZjsMCwbG5N394Otmg/avTQ3F6x1dCGorinO7QtS91OJWEcGvHheHtJaJRlYWB52Pe F65Enw5ko4lvMl7E29X5tb05U3fyiQ69Xt+N2m8XyjlMEr2AOtY4Aqm8mp7OhOB8y5nf vmOg== X-Gm-Message-State: ANhLgQ1SCJY4cQUhzyBrSjmyxXDqsgxWHWC0g1DyhIqJSD6bLEZ9PzuE BA+q6XXr6k6NFZRAYjtAhmR++8J3VS98e9Mc0i5c6zdyJMw= X-Google-Smtp-Source: ADFU+vslpitN1JeYWKygxnYFXKCGCzsYddMe8Tt4G4Zh37kQTom5prs4qbh2ILizF+cSdDzgmyNMdEnL9zgxYOv0x+E= X-Received: by 2002:a17:906:27ca:: with SMTP id k10mr2054436ejc.15.1583926468084; Wed, 11 Mar 2020 04:34:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew De Haast Date: Wed, 11 Mar 2020 13:34:16 +0200 Message-ID: To: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007b1d3e05a0929e62" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 11:34:33 -0000 --0000000000007b1d3e05a0929e62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 1. Do you support the charter text provided at the end of this email? > Yes > 2. Are you willing to author or participate in the development of the > drafts of this WG? > Yes 3. Are you willing to help review the drafts of this WG? > Yes 4. Are you interested in implementing drafts of this WG? > Yes Matt On Fri, Mar 6, 2020 at 6:45 PM Yaron Sheffer wrote: > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000007b1d3e05a0929e62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1.= =C2=A0 Do you support the charter text provided at the end of this email? <= br>

Yes
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the= drafts of this WG?

Yes

=
3.=C2=A0 Are you willing to help review the drafts of this WG?

Yes=C2=A0

4.=C2=A0 Are y= ou interested in implementing drafts of this WG?
=C2= =A0
Yes

Matt

On Fri, Mar 6= , 2020 at 6:45 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Hi Everyone,
=C2=A0
It appears that momentum is forming around the proposed formation of a TxAu= th working group.=C2=A0 We=E2=80=99d like to more formally gauge interest i= n proceeding with this work.=C2=A0 Please do so by responding to the follow= ing questions:
=C2=A0
1.=C2=A0 Do you support the charter text provided at the end of this email?= =C2=A0 Or do you have major objections, blocking concerns or feedback (if s= o please elaborate)?
=C2=A0
2.=C2=A0 Are you willing to author or participate in the development of the= drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in implementing drafts of this WG?
=C2=A0
The call will run for two weeks, until March 21. If you think that the char= ter should be amended In a significant way, please reply on a separate thre= ad.
=C2=A0
The feedback provided here will help the IESG come to a decision on the for= mation of a new WG. Given the constraints of the chartering process, regard= less of the outcome of this consensus call, we will be meeting in Vancouver= as a BoF.
=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows ---

This group is chartered to develop a fine-grained delegation protocol for a= uthorization, identity, and API access. This protocol will allow an authori= zing party to delegate access to client software through an authorization s= erver. It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework = for interaction among all parties involved in the protocol flow, and remove= unnecessary dependence on a browser or user-agent for coordinating interac= tions.

The delegation process will be acted upon by multiple parties in the protoc= ol, each performing a specific role. The protocol will decouple the interac= tion channels, such as the end user=E2=80=99s browser, from the delegation = channel, which happens directly between the client and the authorization se= rver (in contrast with OAuth 2.0 which is initiated by the client redirecti= ng the user=E2=80=99s browser). The client and AS will involve a user to ma= ke an authorization decision as necessary through interaction mechanisms in= dicated by the protocol. This decoupling avoids many of the security concer= ns and technical challenges of OAuth 2.0 and provides a non-invasive path f= or supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t= he client requesting access
- A variety of client applications, including Web, mobile, single-page, and= interaction-constrained applications

The group will define extension points for this protocol to allow for flexi= bility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possessi= on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other pieces o= f information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation proc= ess (including identity)

Additionally, the group will provide mechanisms for management of the proto= col lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt = to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol= where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily compatible with = OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope= d in the OAuth Working Group, including functionality back-ported from the = protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic met= hods, such as JOSE and COSE, to the delegation process. This group is not c= hartered to develop new cryptographic methods.

The initial work will focus on using HTTP for communication between the cli= ent and the authorization server, taking advantage of optimization features= of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin= g to other protocols such as COAP when doing so does not conflict with the = primary focus.

Milestones to include:
=C2=A0- Core delegation protocol
=C2=A0- Key presentation mechanism bindings to the core protocol for TLS, d= etached HTTP signature, and embedded HTTP signatures
=C2=A0- Identity and authentication conveyance mechanisms
=C2=A0- Guidelines for use of protocol extension points


--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000007b1d3e05a0929e62-- From nobody Wed Mar 11 11:53:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAA33A1194 for ; Wed, 11 Mar 2020 11:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.998, RCVD_IN_MSPIKE_H2=-1.463, 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 lB926HWRUW1X for ; Wed, 11 Mar 2020 11:53:11 -0700 (PDT) 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 160023A1182 for ; Wed, 11 Mar 2020 11:53:10 -0700 (PDT) Received: from [192.168.1.5] (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 02BIr82x006173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Mar 2020 14:53:08 -0400 From: Justin Richer Message-Id: <001C0D78-3B44-4E68-A796-FCDC3BB33434@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DE465C6E-8C28-471D-ADBF-40EDFC042F5E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 11 Mar 2020 14:53:07 -0400 In-Reply-To: Cc: txauth@ietf.org To: Fabien Imbault References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 18:53:19 -0000 --Apple-Mail=_DE465C6E-8C28-471D-ADBF-40EDFC042F5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fabian, Thanks for the note about the charter. Hopefully I can explain what we = mean by the current scope language. The intent was to build a protocol that is bound to HTTP and not to = other transport mechanisms. However, the design goal is to build it in = such a way that when we use an HTTP feature, such as a header or verbs = or URL parameters, we=E2=80=99re explicit about what we=E2=80=99re using = and how. Therefore, when someone wants to map this concept and structure = to another protocol stack, they=E2=80=99ll be able to say things like = =E2=80=9CI need the equivalent of an HTTP header for this part of the = protocol=E2=80=9D and use what best applies within their chosen space.=20= What I explicitly wanted to avoid was this group defining something that = was completely abstract with a nominal =E2=80=9Cbinding=E2=80=9D to HTTP = as a transport mechanism. In my experience, this inevitably leads to an = abstraction layer that doesn=E2=80=99t make sense in practice, and = ultimately a confusing set of documents where people are trying to = figure out which document has the details for what they care about. = Especially since the first binding is often the only one that gets = picked up and used by implementors. Abstracting things too early just = leads to disaster, in other words. That=E2=80=99s why I think we=E2=80=99re better of doing something with = an explicit connection to other layers, specifically including HTTP, = JSON, TLS, and even JOSE the like. That way when someone wants to build = TxAuth on top of CORE, CBOR, DTLS, and COSE, they can do the = translations from the original protocol in ways that make the most = sense. For instance, such an implementation would likely want to use = OSCORE/COSE for a key presentation and proofing mechanism. This protocol = set allows you to encapsulate the messages in ways that even HTTP = signatures don=E2=80=99t. But if we build the entire protocol around, = for instance, JOSE objects within an HTTP message, then we lose the = ability to make that kind of translation.=20 I also think it=E2=80=99s probably too much for this group to start with = IoT and alternate transports on its plate, especially because, as you = note, there are many of them and they=E2=80=99re often pretty different = from each other. But we can have these in mind as we are developing = TxAuth, and especially if a specifically interested party such as your = own group is tracking TxAuth and making those translations in real time = as we move the base protocol.=20 Maybe the constrained version of TxAuth will find a home in this WG, = maybe it=E2=80=99ll find a home elsewhere like ACE, or maybe we=E2=80=99ll= have TxAuth-But-For-Tiny-Things as a WG in the future. In all of these = cases, the people working on this are likely going to overlap at least a = little with the people working on TxAuth itself.=20 I hope this clears up the intent behind the wording of the charter! If = there=E2=80=99s a better way to state that, please suggest some succinct = text. Thanks! =E2=80=94 Justin > On Mar 11, 2020, at 5:49 AM, Fabien Imbault = wrote: >=20 > Hello,=20 >=20 > Thanks for the work being done. I'm new to IETF (but have worked in = the past with other collaborative orgs) so please forgive any unusual = habits if any, will try to catch up. =20 >=20 > > 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >=20 > Yes, with comments. >=20 > I believe the last part of the charter : "will strive to enable simple = mapping to other protocols such as COAP when doing so does not conflict = with the primary focus" should be modified, to acknowledge what is = really in the scope and what is not. As it is written, I actually don't = know very well. =20 > Certainly the main goal is HTTP support and that is already a large = challenge which needs to be handled with priority.=20 > However we need to acknowledge contrained devices are now very common, = people want to manage them properly but usually those devices don't = speak well over HTTP. =46rom the content available on oauth.xyz = , I have the impression that the use case is in the = scope. That makes also be a great differentiation compared to OAuth2, = and one doesn't have to fight so much with change management as the = field is much newer, compared to webapps. In the IoT domain, that would = be very useful because implementing delegation at scale is a = real/unsolved issue.=20 > But as the charter is currently written, it is unclear what "simple = mapping" really means and whether that could work out in practice as an = after thought. I also have the feeling that saying the mapping to other = protocols should not conflict with the primary focus doesn't make it so = much clearer on what is exactly expected. > Supporting a variety of IoT protocols is obviously out of question. So = I suggest we get back to the requirements, and would propose the = following: the protocol shall be usable by constrained devices, provided = they can discuss over an IP network such as CoAP (see the work on OAuth2 = ACE for instance), SCHC (which is also an upcoming IETF RFC) or other = future protocols that would allow the interface to match with HTTP = behaviour (through an adaptor). For those types of clients, the = communication stack (supported and/or prefered) could be declared in a = pre-register phase.=20 > What would still be out of scope is to design network protocol = independance within TXAUTH. For instance, stateful data centric = protocols such as MQTT would be out of scope. > My team and myself are available to work on this (both on spec and = opensource implementation prototype), and make constrained devices a = first class citizen, if you agree that's indeed a common need. Of = course, I do not intend this to be the priority, but more as a way to = take feedback and make sure the protocol's design doesn't forbid such = demands, likely to become mainstream. > Please let me know what you think. >=20 > > 2. Are you willing to author or participate in the development of = the drafts of this WG? >=20 > Yes. > =20 > > 3. Are you willing to help review the drafts of this WG? >=20 > Yes. >=20 > > 4. Are you interested in implementing drafts of this WG? >=20 > Yes, rust implementation (and webassembly bindings). >=20 > Best regards, >=20 > Fabien > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_DE465C6E-8C28-471D-ADBF-40EDFC042F5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Fabian,

Thanks for = the note about the charter. Hopefully I can explain what we mean by the = current scope language.

The intent was to build a protocol that is bound to HTTP and = not to other transport mechanisms. However, the design goal is to build = it in such a way that when we use an HTTP feature, such as a header or = verbs or URL parameters, we=E2=80=99re explicit about what we=E2=80=99re = using and how. Therefore, when someone wants to map this concept and = structure to another protocol stack, they=E2=80=99ll be able to say = things like =E2=80=9CI need the equivalent of an HTTP header for this = part of the protocol=E2=80=9D and use what best applies within their = chosen space. 

What I explicitly wanted to avoid was this group defining = something that was completely abstract with a nominal =E2=80=9Cbinding=E2=80= =9D to HTTP as a transport mechanism. In my experience, this inevitably = leads to an abstraction layer that doesn=E2=80=99t make sense in = practice, and ultimately a confusing set of documents where people are = trying to figure out which document has the details for what they care = about. Especially since the first binding is often the only one that = gets picked up and used by implementors. Abstracting things too early = just leads to disaster, in other words.

That=E2=80=99s why I think we=E2=80=99re = better of doing something with an explicit connection to other layers, = specifically including HTTP, JSON, TLS, and even JOSE the like. That way = when someone wants to build TxAuth on top of CORE, CBOR, DTLS, and COSE, = they can do the translations from the original protocol in ways that = make the most sense. For instance, such an implementation would likely = want to use OSCORE/COSE for a key presentation and proofing mechanism. = This protocol set allows you to encapsulate the messages in ways that = even HTTP signatures don=E2=80=99t. But if we build the entire protocol = around, for instance, JOSE objects within an HTTP message, then we lose = the ability to make that kind of translation. 

I also think it=E2=80=99s = probably too much for this group to start with IoT and alternate = transports on its plate, especially because, as you note, there are many = of them and they=E2=80=99re often pretty different from each other. But = we can have these in mind as we are developing TxAuth, and especially if = a specifically interested party such as your own group is tracking = TxAuth and making those translations in real time as we move the base = protocol. 

Maybe the constrained version of TxAuth will find a home in = this WG, maybe it=E2=80=99ll find a home elsewhere like ACE, or maybe = we=E2=80=99ll have TxAuth-But-For-Tiny-Things as a WG in the future. In = all of these cases, the people working on this are likely going to = overlap at least a little with the people working on TxAuth = itself. 

I = hope this clears up the intent behind the wording of the charter! If = there=E2=80=99s a better way to state that, please suggest some succinct = text. Thanks!

 =E2=80=94 Justin

On Mar = 11, 2020, at 5:49 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hello, 

Thanks for the work being done. I'm new to IETF (but have = worked in the past with other collaborative orgs) so please forgive any = unusual habits if any, will try to catch up.  =  

> 1.  Do you support the charter text provided at the = end of this email?  Or do you have major objections, blocking = concerns or feedback (if so please elaborate)?

Yes, with comments.

I believe the last part of the charter : "will strive to =
enable simple mapping to other protocols such as COAP when doing so does =
not conflict with the primary focus" should be modified, to acknowledge =
what is really in the scope and what is not. As it is written, I =
actually don't know very well.  
Certainly the main goal is HTTP support and that is already a =
large challenge which needs to be handled with priority. 
However we need to acknowledge contrained devices are now very =
common, people want to manage them properly but usually those devices =
don't speak well over HTTP. =46rom the content available on oauth.xyz, I have the =
impression that the use case is in the scope. That makes also be a great =
differentiation compared to OAuth2, and one doesn't have to fight so =
much with change management as the field is much newer, compared to =
webapps. In the IoT domain, that would be very useful because =
implementing delegation at scale is a real/unsolved issue. 
But as the charter is currently written, it is unclear what =
"simple mapping" really means and whether that could work out in =
practice as an after thought. I also have the feeling that saying the =
mapping to other protocols should not conflict with the primary focus =
doesn't make it so much clearer on what is exactly expected.
Supporting a variety of IoT protocols is obviously out of =
question. So I suggest we get back to the requirements, and would =
propose the following: the protocol shall be usable by constrained =
devices, provided they can discuss over an IP network such as CoAP (see =
the work on OAuth2 ACE for instance), SCHC (which is also an upcoming =
IETF RFC) or other future protocols that would allow the interface to =
match with HTTP behaviour (through an adaptor). For those types of =
clients, the communication stack (supported and/or prefered) could be =
declared in a pre-register phase. 
What would still be out of scope is to design network protocol =
independance within TXAUTH. For instance, stateful data centric =
protocols such as MQTT would be out of scope.
My team and myself are available to work on this (both on spec =
and opensource implementation prototype), and make constrained devices a =
first class citizen, if you agree that's indeed a common need. Of =
course, I do not intend this to be the priority, but more as a way to =
take feedback and make sure the protocol's design doesn't forbid such =
demands, likely to become mainstream.
Please let me know what you think.

> 2.  Are you willing to author or = participate in the development of the drafts of this WG?

Yes.
 
> 3.  Are you = willing to help review the drafts of this WG?

Yes.

> 4.  Are you interested in = implementing drafts of this WG?

Yes, = rust implementation (and webassembly bindings).

Best regards,

Fabien
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_DE465C6E-8C28-471D-ADBF-40EDFC042F5E-- From nobody Wed Mar 11 12:11:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0EE3A03EF for ; Wed, 11 Mar 2020 12:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, PDS_OTHER_BAD_TLD=1.998, 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 h-m4ArGwsRTq for ; Wed, 11 Mar 2020 12:10:59 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0: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 9B9B03A02BE for ; Wed, 11 Mar 2020 12:10:59 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id j14so3298457otq.3 for ; Wed, 11 Mar 2020 12:10:59 -0700 (PDT) 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=NNqO60AScIwBhzooihJmWFK5YVGwAAC/3YcfU8oaHjY=; b=SEpuBcESiqz5BUFtTRaBMp0Xft562T/CzTSrUOEP932hv4djR8/n53sfpdKAz2mco9 f2odIXxcnyGT3Oq9uqvzi7DngMoym4PqQlpsm+uBJUjDb110hyEzmizpI346EhCVBHnb y4eehq/cpbF5gYjeltTkueZyldfGLjldBQAAWeDL3ulWAXROlNeHlfaiQgQUht2pYg/l UW53ypJ8xe4xTeEx4NO5lB9pR7eq9b8x0drnDTapveoXs1nklc3Qv0MoLeIfZeV0p1zj WsSRclKedht+A004YPK8iPzNHgc+Zhq1d2b3TNN4xT8P6HbtFXC5eTJ6qVEUhtf+WnLu Bcdw== 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=NNqO60AScIwBhzooihJmWFK5YVGwAAC/3YcfU8oaHjY=; b=qwCnXsC4l6UziAfmEwyFsJbmVzpb4boc/37WwlSUpSfLnQ6jGNHIDR6T3RjD/XNNLS AXs4Gyv87NAU8c1UWpjx13zRSDyLb5umNlitVURrMIecXqRLDomXKqQRCnwNwVgx9tWn RoKFr+n4TAeJM2aN8QJyO/6BdHY8InuoqciRvWly09Wg7nH8MHE3dsaNSj8YXnC5k1Js xAVGF7qfYeJOGsOZTuxH3PvJiv2ODCddPVDdP2v79IQbfvGSnLjZz3pUZN/idwkzc0gu dqIQRZS4o8KuJ7//4T2wqv6YgV3FQOwEkxUK+HrcAiO8L2FgFxiQ3YaD+I0ndVfD5q7S 3qNQ== X-Gm-Message-State: ANhLgQ3jNF2vPZa75cFo/qImsqacbwRSFTOCzHax0RRz+71YChq1RufJ 7C+uUGa3NJI0sE3h3Md6UiZxaPQHS7cZriyGuLA= X-Google-Smtp-Source: ADFU+vvs879dcGiRiQm4AysBdsQfvT7GcsdBj03buNBEBkktpCqsdg6xRVH9GAot0s8//s41Eg0K0GffavxDWMHuios= X-Received: by 2002:a05:6830:19e2:: with SMTP id t2mr3331186ott.97.1583953858722; Wed, 11 Mar 2020 12:10:58 -0700 (PDT) MIME-Version: 1.0 References: <001C0D78-3B44-4E68-A796-FCDC3BB33434@mit.edu> In-Reply-To: <001C0D78-3B44-4E68-A796-FCDC3BB33434@mit.edu> From: Fabien Imbault Date: Wed, 11 Mar 2020 20:10:48 +0100 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000016fe3905a098ffdd" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 19:11:02 -0000 --00000000000016fe3905a098ffdd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Thanks, I think your answer makes perfect sense and clarifies better the intent. I'm good with that and certainly agree not to over-engineer. I'm available to help on the current WG, and later on for TxAuth-But-For-Tiny-Things ;-) Cheers. Fabien On Wed, Mar 11, 2020 at 7:53 PM Justin Richer wrote: > Hi Fabian, > > Thanks for the note about the charter. Hopefully I can explain what we > mean by the current scope language. > > The intent was to build a protocol that is bound to HTTP and not to other > transport mechanisms. However, the design goal is to build it in such a w= ay > that when we use an HTTP feature, such as a header or verbs or URL > parameters, we=E2=80=99re explicit about what we=E2=80=99re using and how= . Therefore, when > someone wants to map this concept and structure to another protocol stack= , > they=E2=80=99ll be able to say things like =E2=80=9CI need the equivalent= of an HTTP header > for this part of the protocol=E2=80=9D and use what best applies within t= heir > chosen space. > > What I explicitly wanted to avoid was this group defining something that > was completely abstract with a nominal =E2=80=9Cbinding=E2=80=9D to HTTP = as a transport > mechanism. In my experience, this inevitably leads to an abstraction laye= r > that doesn=E2=80=99t make sense in practice, and ultimately a confusing s= et of > documents where people are trying to figure out which document has the > details for what they care about. Especially since the first binding is > often the only one that gets picked up and used by implementors. > Abstracting things too early just leads to disaster, in other words. > > That=E2=80=99s why I think we=E2=80=99re better of doing something with a= n explicit > connection to other layers, specifically including HTTP, JSON, TLS, and > even JOSE the like. That way when someone wants to build TxAuth on top of > CORE, CBOR, DTLS, and COSE, they can do the translations from the origina= l > protocol in ways that make the most sense. For instance, such an > implementation would likely want to use OSCORE/COSE for a key presentatio= n > and proofing mechanism. This protocol set allows you to encapsulate the > messages in ways that even HTTP signatures don=E2=80=99t. But if we build= the > entire protocol around, for instance, JOSE objects within an HTTP message= , > then we lose the ability to make that kind of translation. > > I also think it=E2=80=99s probably too much for this group to start with = IoT and > alternate transports on its plate, especially because, as you note, there > are many of them and they=E2=80=99re often pretty different from each oth= er. But we > can have these in mind as we are developing TxAuth, and especially if a > specifically interested party such as your own group is tracking TxAuth a= nd > making those translations in real time as we move the base protocol. > > Maybe the constrained version of TxAuth will find a home in this WG, mayb= e > it=E2=80=99ll find a home elsewhere like ACE, or maybe we=E2=80=99ll have > TxAuth-But-For-Tiny-Things as a WG in the future. In all of these cases, > the people working on this are likely going to overlap at least a little > with the people working on TxAuth itself. > > I hope this clears up the intent behind the wording of the charter! If > there=E2=80=99s a better way to state that, please suggest some succinct = text. > Thanks! > > =E2=80=94 Justin > > On Mar 11, 2020, at 5:49 AM, Fabien Imbault > wrote: > > Hello, > > Thanks for the work being done. I'm new to IETF (but have worked in the > past with other collaborative orgs) so please forgive any unusual habits = if > any, will try to catch up. > > > 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > Yes, with comments. > > I believe the last part of the charter : "will strive to enable simple ma= pping to other protocols such as COAP when doing so does not conflict with = the primary focus" should be modified, to acknowledge what is really in the= scope and what is not. As it is written, I actually don't know very well. > > Certainly the main goal is HTTP support and that is already a large chall= enge which needs to be handled with priority. > > However we need to acknowledge contrained devices are now very common, pe= ople want to manage them properly but usually those devices don't speak wel= l over HTTP. From the content available on oauth.xyz, I have the impression= that the use case is in the scope. That makes also be a great differentiat= ion compared to OAuth2, and one doesn't have to fight so much with change m= anagement as the field is much newer, compared to webapps. In the IoT domai= n, that would be very useful because implementing delegation at scale is a = real/unsolved issue. > > But as the charter is currently written, it is unclear what "simple mappi= ng" really means and whether that could work out in practice as an after th= ought. I also have the feeling that saying the mapping to other protocols s= hould not conflict with the primary focus doesn't make it so much clearer o= n what is exactly expected. > > Supporting a variety of IoT protocols is obviously out of question. So I = suggest we get back to the requirements, and would propose the following: t= he protocol shall be usable by constrained devices, provided they can discu= ss over an IP network such as CoAP (see the work on OAuth2 ACE for instance= ), SCHC (which is also an upcoming IETF RFC) or other future protocols that= would allow the interface to match with HTTP behaviour (through an adaptor= ). For those types of clients, the communication stack (supported and/or pr= efered) could be declared in a pre-register phase. > > What would still be out of scope is to design network protocol independan= ce within TXAUTH. For instance, stateful data centric protocols such as MQT= T would be out of scope. > > My team and myself are available to work on this (both on spec and openso= urce implementation prototype), and make constrained devices a first class = citizen, if you agree that's indeed a common need. Of course, I do not inte= nd this to be the priority, but more as a way to take feedback and make sur= e the protocol's design doesn't forbid such demands, likely to become mains= tream. > > Please let me know what you think. > > > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > Yes. > > > 3. Are you willing to help review the drafts of this WG? > > Yes. > > > 4. Are you interested in implementing drafts of this WG? > > Yes, rust implementation (and webassembly bindings). > > Best regards, > > Fabien > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --00000000000016fe3905a098ffdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,=C2=A0

Thanks, I think your a= nswer makes perfect sense and clarifies better the intent. I'm good wit= h that and certainly agree not to over-engineer.=C2=A0
I'm av= ailable to help on the current WG, and later on for TxAuth-But-For-Tiny-Thi= ngs ;-)

Cheers.=C2=A0

Fab= ien

On Wed, Mar 11, 2020 at 7:53 PM Justin Richer <jricher@mit.edu> wrote:
Hi Fabian,

Thanks for the note about the charter. Hopef= ully I can explain what we mean by the current scope language.
The intent was to build a protocol that is bound to HTTP and n= ot to other transport mechanisms. However, the design goal is to build it i= n such a way that when we use an HTTP feature, such as a header or verbs or= URL parameters, we=E2=80=99re explicit about what we=E2=80=99re using and = how. Therefore, when someone wants to map this concept and structure to ano= ther protocol stack, they=E2=80=99ll be able to say things like =E2=80=9CI = need the equivalent of an HTTP header for this part of the protocol=E2=80= =9D and use what best applies within their chosen space.=C2=A0
What I explicitly wanted to avoid was this group defining some= thing that was completely abstract with a nominal =E2=80=9Cbinding=E2=80=9D= to HTTP as a transport mechanism. In my experience, this inevitably leads = to an abstraction layer that doesn=E2=80=99t make sense in practice, and ul= timately a confusing set of documents where people are trying to figure out= which document has the details for what they care about. Especially since = the first binding is often the only one that gets picked up and used by imp= lementors. Abstracting things too early just leads to disaster, in other wo= rds.

That=E2=80=99s why I think we=E2=80=99re bett= er of doing something with an explicit connection to other layers, specific= ally including HTTP, JSON, TLS, and even JOSE the like. That way when someo= ne wants to build TxAuth on top of CORE, CBOR, DTLS, and COSE, they can do = the translations from the original protocol in ways that make the most sens= e. For instance, such an implementation would likely want to use OSCORE/COS= E for a key presentation and proofing mechanism. This protocol set allows y= ou to encapsulate the messages in ways that even HTTP signatures don=E2=80= =99t. But if we build the entire protocol around, for instance, JOSE object= s within an HTTP message, then we lose the ability to make that kind of tra= nslation.=C2=A0

I also think it=E2=80=99s probably= too much for this group to start with IoT and alternate transports on its = plate, especially because, as you note, there are many of them and they=E2= =80=99re often pretty different from each other. But we can have these in m= ind as we are developing TxAuth, and especially if a specifically intereste= d party such as your own group is tracking TxAuth and making those translat= ions in real time as we move the base protocol.=C2=A0

<= div>Maybe the constrained version of TxAuth will find a home in this WG, ma= ybe it=E2=80=99ll find a home elsewhere like ACE, or maybe we=E2=80=99ll ha= ve TxAuth-But-For-Tiny-Things as a WG in the future. In all of these cases,= the people working on this are likely going to overlap at least a little w= ith the people working on TxAuth itself.=C2=A0

I h= ope this clears up the intent behind the wording of the charter! If there= =E2=80=99s a better way to state that, please suggest some succinct text. T= hanks!

=C2=A0=E2=80=94 Justin

On Mar 11, 2020, at 5:49 AM, Fabien Imbault <fabien.imbault@gm= ail.com> wrote:

Hello,=C2=A0

Thanks fo= r the work being done. I'm new to IETF (but have worked in the past wit= h other collaborative orgs) so please forgive any unusual habits if any, wi= ll try to catch up.=C2=A0 =C2=A0

> 1.=C2=A0= Do you support the charter text provided at the end of this email?=C2=A0 O= r do you have major objections, blocking concerns or feedback (if so please= elaborate)?

Yes, with comments.

I believe the last part =
of the charter : "will strive to enable simple mapping to other protoc=
ols such as COAP when doing so does not conflict with the primary focus&quo=
t; should be modified, to acknowledge what is really in the scope and what =
is not. As it is written, I actually don't know very well.  
Certainly the main g=
oal is HTTP support and that is already a large challenge which needs to be=
 handled with priority. 
However we need to acknowledge contrained devices are now ve=
ry common, people want to manage them properly but usually those devices do=
n't speak well over HTTP. From the content available on oauth.xyz, I have the impression that =
the use case is in the scope. That makes also be a great differentiation co=
mpared to OAuth2, and one doesn't have to fight so much with change man=
agement as the field is much newer, compared to webapps. In the IoT domain,=
 that would be very useful because implementing delegation at scale is a re=
al/unsolved issue. 
But as the charter is currently written, it is unclear what "=
;simple mapping" really means and whether that could work out in pract=
ice as an after thought. I also have the feeling that saying the mapping to=
 other protocols should not conflict with the primary focus doesn't mak=
e it so much clearer on what is exactly expected.
Supporting a variety of IoT protoco=
ls is obviously out of question. So I suggest we get back to the requiremen=
ts, and would propose the following: the protocol shall be usable by constr=
ained devices, provided they can discuss over an IP network such as CoAP (s=
ee the work on OAuth2 ACE for instance), SCHC (which is also an upcoming IE=
TF RFC) or other future protocols that would allow the interface to match w=
ith HTTP behaviour (through an adaptor). For those types of clients, the co=
mmunication stack (supported and/or prefered) could be declared in a pre-re=
gister phase. 
What would still be out of scope is to design network protocol indepen=
dance within TXAUTH. For instance, stateful data centric protocols such as =
MQTT would be out of scope.
My team and myself are available to work on this (both on=
 spec and opensource implementation prototype), and make constrained device=
s a first class citizen, if you agree that's indeed a common need. Of c=
ourse, I do not intend this to be the priority, but more as a way to take f=
eedback and make sure the protocol's design doesn't forbid such dem=
ands, likely to become mainstream.
Please let me know what you think.

> 2.=C2=A0 Are you willing to author or participate in= the development of the drafts of this WG?

Yes.
=C2=A0
> 3.=C2=A0 Are you willing to help re= view the drafts of this WG?

Yes.

> 4.=C2=A0 Are you interested in implementing drafts of th= is WG?

Yes, rust implementation (and webassembly bindings).

Best regards,

Fabien
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--00000000000016fe3905a098ffdd-- From nobody Thu Mar 12 07:43:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972443A08B5 for ; Thu, 12 Mar 2020 07:43:43 -0700 (PDT) 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 HcKjRc-HE6ny for ; Thu, 12 Mar 2020 07:43:41 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 4A5153A08AC for ; Thu, 12 Mar 2020 07:43:41 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id f198so6535065qke.11 for ; Thu, 12 Mar 2020 07:43:41 -0700 (PDT) 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=1CRxAVDSaQCWgO1K8DSX6y0zh+4hOsnGCicXvE0wlxU=; b=ImHDF1f+1gI9z9N7mHHwtXOxWoKk9Rgpqt8+XThZYexrdR1Vc2gKKO3LMyd5pOPsz0 bpr5i61MWQV6CjZnX0ihp7DOSq1/i9vn501DTlcYw/hEQm0eJPz5ddp6P0NAmYbhuACx 4DpzS8YyBXRiWfvOUPNf243Fcv1XMmCpCOhggTZnh5dZc7pNSASJV45sBvP211oaYKYs u84VX/F7lDHAHk/dZrJxLSBE+zu6/O6gBULqLWOW/L3YotR0rac3yCbqawtSVAST6zJz 3cPgjvLXTVT17oVKyz/PIFMtTVySJ7f+L1rjGt0ZbpYIeVwE3LkIKRqaqqAToDD2HmN3 rYNA== 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=1CRxAVDSaQCWgO1K8DSX6y0zh+4hOsnGCicXvE0wlxU=; b=eH5r47JoktZgj7Kv+RRJfPDhMeev4hkpxYMODeH/+zy0Ja33JADL6zKWVFRo9FmqHd DiGhFAXhWLPEuqG+Z4GZOuuG/Y6ONqJf96o6RZ3vMFeC9UBmVp1As9qDRxJIRNoo1/LG /lqPSQiotzuRmcyNfZOA1xY/L/ENUnntU9G1TqHNdRObu2oHV6wTHM8lhzZJMU1pCQTH 5C058ChyYKNaR2NtLXc3SWJcZ3Y9w5tfjYTkkeqW5sr7nhVVuL9P2cczyIy1zk+P6w0e a9LtNwvkDKPkGQ2t6lSLFzpoZASx4JLprEWjzVZLLgtbeQtRPB2XrbqTu0qGDGnUKGJd 3ghg== X-Gm-Message-State: ANhLgQ3yLbhvBy2z09Pp8qXwfH1KPUA94zh2qKg0LEvY5mqpLjqgEKig bA7kfNm1QxgI93L3WtFPmL2ysdp9fS50IIZUQVbYP4Qu8MQ= X-Google-Smtp-Source: ADFU+vvo4/dJioiQsYkO7YrwCG25OtKJM1tPE3RcUnofzFJQbonKtzlh1Y/inaOaRJQjWuUPTKn/yz5JnlzSkwjb9WQ= X-Received: by 2002:a25:c052:: with SMTP id c79mr9446347ybf.84.1584024219910; Thu, 12 Mar 2020 07:43:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stephen Moore Date: Thu, 12 Mar 2020 10:43:28 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f185bb05a0a960c1" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 14:43:44 -0000 --000000000000f185bb05a0a960c1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On the 4 questions for the initial Call for charter consensus, I'm a YES. (I joined the mailing list after it went out...) My main interest is in figuring out how to make this work for IoT in a 'home use' setting. (Although that doesn't mean it can't work in larger industrial settings.) -steve https://www.moorelabs.com/ On Thu, Mar 12, 2020 at 10:33 AM Justin Richer wrote: > > > *From: *Yaron Sheffer > *Subject: **[Txauth] Call for charter consensus - TxAuth WG* > *Date: *March 6, 2020 at 11:44:53 AM EST > *To: *"txauth@ietf.org" > > Hi Everyone, > > It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this email? O= r > do you have major objections, blocking concerns or feedback (if so please > elaborate)? > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on the > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000f185bb05a0a960c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the 4 questions for the initial=C2=A0Call for char= ter consensus, I'm a YES.
(I joined the mailing list after it= went out...)

My main interest is in figuring out = how to make this work for IoT in a 'home use' setting. (Although th= at doesn't mean it can't work in larger industrial settings.)
=

-steve

On Thu, Mar 12, 2020 at 10:3= 3 AM Justin Richer <jricher@mit.edu> wrote:


Subject: [= Txauth] Call for charter consensus - TxAuth WG
Date: March 6, 2020 at 11:44:53 AM EST
To: "txauth@ietf.org" <txauth@ietf.org>

Hi Ev= eryone,
=C2=A0
It appears that momentum is forming around the propose= d formation of a TxAuth working group.=C2=A0 We=E2=80=99d like to more form= ally gauge interest in proceeding with this work.=C2=A0 Please do so by res= ponding to the following questions:
=C2=A0
1.=C2=A0 Do you support th= e charter text provided at the end of this email?=C2=A0 Or do you have majo= r objections, blocking concerns or feedback (if so please elaborate)?
= =C2=A0
2.=C2=A0 Are you willing to author or participate in the developm= ent of the drafts of this WG?
=C2=A0
3.=C2=A0 Are you willing to help= review the drafts of this WG?
=C2=A0
4.=C2=A0 Are you interested in = implementing drafts of this WG?
=C2=A0
The call will run for two week= s, until March 21. If you think that the charter should be amended In a sig= nificant way, please reply on a separate thread.
=C2=A0
The feedback = provided here will help the IESG come to a decision on the formation of a n= ew WG. Given the constraints of the chartering process, regardless of the o= utcome of this consensus call, we will be meeting in Vancouver as a BoF.=C2=A0
Thanks,
Yaron and Dick
=C2=A0
--- Charter Text Follows = ---

This group is chartered to develop a fine-grained delegation pro= tocol for authorization, identity, and API access. This protocol will allow= an authorizing party to delegate access to client software through an auth= orization server. It will expand upon the uses cases currently supported by= OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support= authorizations scoped as narrowly as a single transaction, provide a clear= framework for interaction among all parties involved in the protocol flow,= and remove unnecessary dependence on a browser or user-agent for coordinat= ing interactions.

The delegation process will be acted upon by mult= iple parties in the protocol, each performing a specific role. The protocol= will decouple the interaction channels, such as the end user=E2=80=99s bro= wser, from the delegation channel, which happens directly between the clien= t and the authorization server (in contrast with OAuth 2.0 which is initiat= ed by the client redirecting the user=E2=80=99s browser). The client and AS= will involve a user to make an authorization decision as necessary through= interaction mechanisms indicated by the protocol. This decoupling avoids m= any of the security concerns and technical challenges of OAuth 2.0 and prov= ides a non-invasive path for supporting future types of clients and interac= tion channels.

Additionally, the delegation process will allow for:<= br>
- Fine-grained specification of access
- Approval of AS attestati= on to identity claims
- Approval of access to multiple resources and API= s in a single interaction
- Separation between the party authorizing acc= ess and the party operating the client requesting access
- A variety of = client applications, including Web, mobile, single-page, and interaction-co= nstrained applications

The group will define extension points for th= is protocol to allow for flexibility in areas including:

- Cryptogra= phic agility for keys, message signatures, and proof of possession
- Us= er interaction mechanisms including web and non-web methods
- Mechanisms= for conveying user, software, organization, and other pieces of informatio= n used in authorization decisions
- Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated cry= ptographic keys
- Optimized inclusion of additional information through = the delegation process (including identity)

Additionally, the group = will provide mechanisms for management of the protocol lifecycle including:=

- Discovery of the authorization server
- Revocation of active t= okens
- Query of token rights by resource servers

Although the ar= tifacts for this work are not intended or expected to be backwards-compatib= le with OAuth 2.0 or OpenID Connect, the group will attempt to simplify mig= rating from OAuth 2.0 and OpenID Connect to the new protocol where possible= .

This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported = from the protocol developed here to OAuth 2.0.

The group is chartere= d to develop mechanisms for applying cryptographic methods, such as JOSE an= d COSE, to the delegation process. This group is not chartered to develop n= ew cryptographic methods.

The initial work will focus on using HTTP= for communication between the client and the authorization server, taking = advantage of optimization features of HTTP2 and HTTP3 where possible, and w= ill strive to enable simple mapping to other protocols such as COAP when do= ing so does not conflict with the primary focus.

Milestones to inclu= de:
- Core delegation protocol
- Key presentation mechanism binding= s to the core protocol for TLS, detached HTTP signature, and embedded HTTP = signatures
- Identity and authentication conveyance mechanisms
- Gu= idelines for use of protocol extension points


--
Txauth mail= ing list
Txauth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth

--000000000000f185bb05a0a960c1-- From nobody Thu Mar 12 14:44:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A483A0785 for ; Thu, 12 Mar 2020 14:44:16 -0700 (PDT) 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_REMOTE_IMAGE=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=mattr-global.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 Xsndeo1-u62b for ; Thu, 12 Mar 2020 14:44:14 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 B6EB33A0784 for ; Thu, 12 Mar 2020 14:44:14 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id p60so3476066qva.5 for ; Thu, 12 Mar 2020 14:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GpAyJHrW0UlQuuAMHgu0UfBbAS7G6nbQu40VCVSnYHg=; b=tNowaTuIE9EAJGhZXgZ1ZUjJmGg7+H20v0yXZVbcU9WJeK/ZHkdABagmfzGVu70NaR O5FuVryuuKWRmMEJ4IgQsti6ggViRJax2RUpQJcrNdtIuPGb/kg9jeotridT5Tw5PSgg vz/YggzLDJC/cQGgetvFIb7YItZ+tJPIBBbzHIc0OQ7iQOP51i0W1uOyTV+zq2wBgUvB 0oX4N/t5cWA0OmRvGLenwDMKddSLOfXhwVVbT1VhG+OHTr4sc09IWhqFoXqvZ7kzr3sc kppqbYOXoDabQ7LiO1ye5692+lQxVrtF9hrS3k+rqXs4c1FlIhr76B0a43RZ/RbF/Q28 Hx5g== 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=GpAyJHrW0UlQuuAMHgu0UfBbAS7G6nbQu40VCVSnYHg=; b=BhIc1qOzMSLqaf+/0+K62BViU0chIAvzsFLqTUOGvqKJHQEDZyhaocpi5xjp/0ZueX rZKBBcUdJ25H9sAYWjIcsG9+ODFEFVjWCaApiIz0tdxiC7bkjv60M61i+WVN1ejISsNm Q3boYWnLHQ9+bqFkMd6Qn71jw/JkBrSi1wZiCK1hLcOn4aIXhh7W7n6lGX9etnOG3txx z5G3kqFCTlWlvubDVXAYaGJuzlDygelfKVJ2IxDLutAbjLHWVkKaAvm9wPGPBydfwbt5 /yGKNfFh3FWwAvxpv4HDG9KbBqGiUjsJrA4ofsmOcHQaUyEBQFoyv8mgBHSSdRGIIlJv 0D8w== X-Gm-Message-State: ANhLgQ13b95sGKyqnoPFqkD4p7HsBjM4ZYNfbPJHn8Qk8Cn89LqoCS+o tn+jnLMwGGQpE4fpdsp68EMXvxIq0AJaQBo4+P7p+4nRxrWvzhow687ZndaBPpGu4I0bwrWNUfg gqvniQfhlt+VWqLF9K8JUKM8= X-Google-Smtp-Source: ADFU+vsiRwvlVI5RD4L5bGUZr5T3kPfYVzns4CWuQpIzZnBt4IFWrULnogANYzsGpN0o5JIBS+rwcp2j+m2z3dokxhg= X-Received: by 2002:a0c:c389:: with SMTP id o9mr9584940qvi.232.1584049453328; Thu, 12 Mar 2020 14:44:13 -0700 (PDT) MIME-Version: 1.0 From: Tobias Looker Date: Fri, 13 Mar 2020 10:44:02 +1300 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f908b505a0af4097" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 21:44:16 -0000 --000000000000f908b505a0af4097 Content-Type: text/plain; charset="UTF-8" Yes to all questions. Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. -- This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. --000000000000f908b505a0af4097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes to all questions.

Thanks,
=
3D"Mattr=C2= =A0<= /table>
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.= global
<= td width=3D"40">3D"Mattr
3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is confidential. = If you are not the intended recipient, you should not read it - please cont= act me immediately, destroy it, and do not copy or use any part of this com= munication or disclose anything about it. Thank you. Please note that this = communication does not designate an information system for the purposes of = the Electronic Transactions Act 2002.

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--000000000000f908b505a0af4097-- From nobody Thu Mar 12 15:49:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DE13A03EC for ; Thu, 12 Mar 2020 15:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.589 X-Spam-Level: X-Spam-Status: No, score=-9.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 qIWFPPozmn5A for ; Thu, 12 Mar 2020 15:49:50 -0700 (PDT) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 BE1193A0366 for ; Thu, 12 Mar 2020 15:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1584053391; x=1615589391; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=DqSLWs34tgFyHxl32ACyJnKlpCGLX10nTHa8yr+QfwM=; b=mU0/dssk8GkU62MVzUWVdptkNFbx66A8z2RE46BEhGREKfVC7Qe0OVHA IBr7lUEEia0e4ZObsJKZzu08EnzmQoSB8sBW3nalAyqyYBw/BdINXTxmo cF8/cvLgKKpSiqUt1hFumjQlVppTxhPVyMbftOmb7QHrvkyPVg1hW3Cxo c=; IronPort-SDR: NE5S+bvKDf4I1PIa71WpdJvfGHqvGFfXO3ie8U6M1o8b2j+k/B8Vaw2zg7rafGPoFgusej9KXm ifs9DnwyLtow== X-IronPort-AV: E=Sophos; i="5.70,546,1574121600"; d="scan'208,217"; a="32317219" Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 12 Mar 2020 22:49:48 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS id 8AAE6281FE3; Thu, 12 Mar 2020 22:49:47 +0000 (UTC) Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 12 Mar 2020 22:49:46 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 12 Mar 2020 22:49:46 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Thu, 12 Mar 2020 22:49:46 +0000 From: "Richard Backman, Annabelle" To: Tobias Looker , "txauth@ietf.org" Thread-Index: AQHV+LdYc5eICL0wc0+DMURMIApJ6KhFGkYA Date: Thu, 12 Mar 2020 22:49:46 +0000 Message-ID: <00E672E4-C8F9-49E6-A2AC-3A70FF618BF8@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.175] Content-Type: multipart/alternative; boundary="_000_00E672E4C8F949E6A2AC3A70FF618BF8amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 22:49:53 -0000 --_000_00E672E4C8F949E6A2AC3A70FF618BF8amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIHRvIGFsbCBxdWVzdGlvbnMuDQoNCk1hbnkgdGhhbmtzIHRvIEp1c3RpbiBmb3Iga2lja3N0 YXJ0aW5nIHRoaXMgcHJvY2VzcywgYW5kIHRvIGV2ZXJ5b25lIHdobyBoYXMgY29tbWVudGVkIG9y IGNvbnRyaWJ1dGVkIHRvIHRoZSBjaGFydGVyLiBIb3BlZnVsbHkgSeKAmWxsIHNlZSB5b3UgYWxs ICh2aXJ0dWFsbHksIG5vdykgaW4gYSBjb3VwbGUgd2Vla3MhIDpEDQoNCuKAkw0KQW5uYWJlbGxl IEJhY2ttYW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20v aWRlbnRpdHkvDQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIFRvYmlhcyBMb29rZXIgPHRvYmlhcy5sb29rZXJAbWF0dHIuZ2xvYmFsPg0KRGF0 ZTogVGh1cnNkYXksIE1hcmNoIDEyLCAyMDIwIGF0IDI6NDUgUE0NClRvOiAidHhhdXRoQGlldGYu b3JnIiA8dHhhdXRoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtFWFRFUk5BTF1bVHhhdXRoXSBD YWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAtIFR4QXV0aCBXRw0KDQoNCkNBVVRJT046IFRoaXMg ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90 IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBjYW4gY29uZmlybSB0 aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoNCg0KWWVzIHRvIGFsbCBx dWVzdGlvbnMuDQoNClRoYW5rcywNCltNYXR0ciB3ZWJzaXRlXTxodHRwczovL21hdHRyLmdsb2Jh bC8+DQoNCg0KDQpUb2JpYXMgTG9va2VyDQoNCk1hdHRyDQoNCis2NCAoMCkgMjcgMzc4IDA0NjEN CnRvYmlhcy5sb29rZXJAbWF0dHIuZ2xvYmFsPG1haWx0bzp0b2JpYXMubG9va2VyQG1hdHRyLmds b2JhbD4NCg0KW01hdHRyIHdlYnNpdGVdPGh0dHBzOi8vbWF0dHIuZ2xvYmFsLz4NCg0KW01hdHRy IG9uIExpbmtlZEluXTxodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9tYXR0cmdsb2Jh bD4NCg0KW01hdHRyIG9uIFR3aXR0ZXJdPGh0dHBzOi8vdHdpdHRlci5jb20vbWF0dHJnbG9iYWw+ DQoNCltNYXR0ciBvbiBHaXRodWJdPGh0dHBzOi8vZ2l0aHViLmNvbS9tYXR0cmdsb2JhbD4NCg0K DQoNCg0KVGhpcyBjb21tdW5pY2F0aW9uLCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzLCBpcyBj b25maWRlbnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBz aG91bGQgbm90IHJlYWQgaXQgLSBwbGVhc2UgY29udGFjdCBtZSBpbW1lZGlhdGVseSwgZGVzdHJv eSBpdCwgYW5kIGRvIG5vdCBjb3B5IG9yIHVzZSBhbnkgcGFydCBvZiB0aGlzIGNvbW11bmljYXRp b24gb3IgZGlzY2xvc2UgYW55dGhpbmcgYWJvdXQgaXQuIFRoYW5rIHlvdS4gUGxlYXNlIG5vdGUg dGhhdCB0aGlzIGNvbW11bmljYXRpb24gZG9lcyBub3QgZGVzaWduYXRlIGFuIGluZm9ybWF0aW9u IHN5c3RlbSBmb3IgdGhlIHB1cnBvc2VzIG9mIHRoZSBFbGVjdHJvbmljIFRyYW5zYWN0aW9ucyBB Y3QgMjAwMi4NCg0KDQoNClRoaXMgY29tbXVuaWNhdGlvbiwgaW5jbHVkaW5nIGFueSBhdHRhY2ht ZW50cywgaXMgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3Ugc2hvdWxkIG5vdCByZWFkIGl0IC0gcGxlYXNlIGNvbnRhY3QgbWUgaW1tZWRpYXRl bHksIGRlc3Ryb3kgaXQsIGFuZCBkbyBub3QgY29weSBvciB1c2UgYW55IHBhcnQgb2YgdGhpcyBj b21tdW5pY2F0aW9uIG9yIGRpc2Nsb3NlIGFueXRoaW5nIGFib3V0IGl0LiBUaGFuayB5b3UuIFBs ZWFzZSBub3RlIHRoYXQgdGhpcyBjb21tdW5pY2F0aW9uIGRvZXMgbm90IGRlc2lnbmF0ZSBhbiBp bmZvcm1hdGlvbiBzeXN0ZW0gZm9yIHRoZSBwdXJwb3NlcyBvZiB0aGUgRWxlY3Ryb25pYyBUcmFu c2FjdGlvbnMgQWN0IDIwMDIuDQo= --_000_00E672E4C8F949E6A2AC3A70FF618BF8amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3DC1334BBAF0FE4E9679A27FB825F1AA@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAy IDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGltZXM7DQoJcGFub3NlLTE6MiAwIDUgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ZZXMgdG8gYWxsIHF1ZXN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TWFueSB0aGFua3MgdG8gSnVzdGluIGZvciBraWNrc3RhcnRpbmcgdGhpcyBwcm9jZXNzLCBh bmQgdG8gZXZlcnlvbmUgd2hvIGhhcyBjb21tZW50ZWQgb3IgY29udHJpYnV0ZWQgdG8gdGhlIGNo YXJ0ZXIuIEhvcGVmdWxseSBJ4oCZbGwgc2VlIHlvdSBhbGwgKHZpcnR1YWxseSwgbm93KSBpbiBh IGNvdXBsZSB3ZWVrcyEgOkQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5uYWJlbGxlIEJh Y2ttYW4gKHNoZS9oZXIpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5LyI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgVG9iaWFzIExvb2tlciAmbHQ7dG9iaWFzLmxvb2tlckBtYXR0ci5n bG9iYWwmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBNYXJjaCAxMiwgMjAyMCBhdCAy OjQ1IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O3R4 YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtFWFRFUk5BTF1bVHhh dXRoXSBDYWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAtIFR4QXV0aCBXRzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPSIwIiB3aWR0aD0iNjIyIiBzdHlsZT0id2lkdGg6NDY2LjVwdDttYXJnaW4tbGVmdDou NWluO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdo dDoxNS4yNXB0Ij4NCjx0ZCB3aWR0aD0iNjIyIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOjQ2 Ni41cHQ7Ym9yZGVyOnNvbGlkICNFRDdEMzEgMS41cHQ7cGFkZGluZzowaW4gNS40cHQgMGluIDUu NHB0O2hlaWdodDoxNS4yNXB0Ij4NCjxwPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOiNG RkZGOTkiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO2Jh Y2tncm91bmQ6I0ZGRkY5OSI+OiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcw0KIHlvdSBjYW4gY29uZmlybSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50 IGlzIHNhZmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WWVzIHRvIGFsbCBxdWVzdGlvbnMuPGJy IGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iMTI1IiB2YWxp Z249InRvcCIgc3R5bGU9IndpZHRoOjkzLjc1cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90 Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9tYXR0ci5nbG9iYWwvIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj48c3Bh biBzdHlsZT0iY29sb3I6IzBGQURFMTtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MGluIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEyNSIgaGVpZ2h0PSIxMjUiIHN0eWxlPSJ3 aWR0aDoxLjMwMmluO2hlaWdodDoxLjMwMmluIiBpZD0iX3gwMDAwX2kxMDI5IiBzcmM9Imh0dHBz Oi8vbWF0dHIuZ2xvYmFsL2Fzc2V0cy9pbWFnZXMvTWF0dHJMb2dvLnBuZyIgYWx0PSJNYXR0ciB3 ZWJzaXRlIj48L3NwYW4+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSIxNiIgc3R5bGU9IndpZHRoOjEyLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PHRkIHdpZHRoPSIxNTkiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6MTE5LjI1cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiAwaW4iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlRvYmlhcyBMb29r ZXI8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsi Pk1hdHRyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6OS4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+JiM0Mzs2NCAoMCkgMjcgMzc4IDA0 NjE8YnI+DQo8YSBocmVmPSJtYWlsdG86dG9iaWFzLmxvb2tlckBtYXR0ci5nbG9iYWwiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzMzEzMjtib3JkZXI6bm9uZSB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj50b2JpYXMubG9va2VyQG1hdHRyLmdsb2JhbDwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6OS4wcHQgMGluIDBpbiAwaW4iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHdpZHRoPSI0MCIgc3R5bGU9IndpZHRoOjMwLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL21hdHRyLmdsb2JhbC8iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMzMzMxMzI7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjBpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNCIgc3R5bGU9IndpZHRoOi4yNWlu IiBpZD0iX3gwMDAwX2kxMDI4IiBzcmM9Imh0dHBzOi8vbWF0dHIuZ2xvYmFsL2Fzc2V0cy9pbWFn ZXMvd2Vic2l0ZS5wbmciIGFsdD0iTWF0dHIgd2Vic2l0ZSI+PC9zcGFuPjwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iNDAiIHN0eWxlPSJ3aWR0aDoz MC4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu bGlua2VkaW4uY29tL2NvbXBhbnkvbWF0dHJnbG9iYWwiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMzMzMxMzI7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+ PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNCIgc3R5bGU9IndpZHRoOi4yNWluIiBpZD0iX3gwMDAw X2kxMDI3IiBzcmM9Imh0dHBzOi8vbWF0dHIuZ2xvYmFsL2Fzc2V0cy9pbWFnZXMvbGlua2VkaW4u cG5nIiBhbHQ9Ik1hdHRyIG9uIExpbmtlZEluIj48L3NwYW4+PC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI0MCIgc3R5bGU9IndpZHRoOjMwLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29t L21hdHRyZ2xvYmFsIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzMzMTMyO2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgYm9yZGVyPSIwIiB3aWR0 aD0iMjQiIHN0eWxlPSJ3aWR0aDouMjVpbiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwczov L21hdHRyLmdsb2JhbC9hc3NldHMvaW1hZ2VzL3R3aXR0ZXIucG5nIiBhbHQ9Ik1hdHRyIG9uIFR3 aXR0ZXIiPjwvc3Bhbj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 dGQgd2lkdGg9IjQwIiBzdHlsZT0id2lkdGg6MzAuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tYXR0cmdsb2JhbCIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij48c3BhbiBzdHlsZT0iY29sb3I6IzMzMzEzMjtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI0IiBzdHlsZT0id2lkdGg6LjI1 aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYXR0ci5nbG9iYWwvYXNzZXRzL2lt YWdlcy9naXRodWIucG5nIiBhbHQ9Ik1hdHRyIG9uIEdpdGh1YiI+PC9zcGFuPjwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzO2NvbG9yOmJs YWNrIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo2LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojNzY3Njc2Ij5UaGlzIGNvbW11bmlj YXRpb24sIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGNvbmZpZGVudGlhbC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IHNob3VsZCBub3QgcmVhZCBpdCAt IHBsZWFzZSBjb250YWN0IG1lIGltbWVkaWF0ZWx5LCBkZXN0cm95IGl0LCBhbmQgZG8NCiBub3Qg Y29weSBvciB1c2UgYW55IHBhcnQgb2YgdGhpcyBjb21tdW5pY2F0aW9uIG9yIGRpc2Nsb3NlIGFu eXRoaW5nIGFib3V0IGl0LiBUaGFuayB5b3UuIFBsZWFzZSBub3RlIHRoYXQgdGhpcyBjb21tdW5p Y2F0aW9uIGRvZXMgbm90IGRlc2lnbmF0ZSBhbiBpbmZvcm1hdGlvbiBzeXN0ZW0gZm9yIHRoZSBw dXJwb3NlcyBvZiB0aGUgRWxlY3Ryb25pYyBUcmFuc2FjdGlvbnMgQWN0IDIwMDIuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGlzIGNvbW11bmljYXRp b24sIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMsIGlzIGNvbmZpZGVudGlhbC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IHNob3VsZCBub3QgcmVhZCBpdCAtIHBs ZWFzZSBjb250YWN0IG1lIGltbWVkaWF0ZWx5LCBkZXN0cm95IGl0LCBhbmQgZG8gbm90IGNvcHkg b3IgdXNlIGFueSBwYXJ0IG9mIHRoaXMgY29tbXVuaWNhdGlvbiBvciBkaXNjbG9zZSBhbnl0aGlu ZyBhYm91dCBpdC4gVGhhbmsgeW91LiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgY29tbXVuaWNhdGlv biBkb2VzIG5vdCBkZXNpZ25hdGUgYW4gaW5mb3JtYXRpb24gc3lzdGVtIGZvciB0aGUgcHVycG9z ZXMgb2YgdGhlIEVsZWN0cm9uaWMgVHJhbnNhY3Rpb25zIEFjdCAyMDAyLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_00E672E4C8F949E6A2AC3A70FF618BF8amazoncom_-- From nobody Fri Mar 13 09:43:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8A63A0EB7 for ; Fri, 13 Mar 2020 09:43:24 -0700 (PDT) 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 KgwQZlGcVqkv for ; Fri, 13 Mar 2020 09:43:21 -0700 (PDT) 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 52DF13A0EC8 for ; Fri, 13 Mar 2020 09:43:20 -0700 (PDT) Received: from [192.168.1.5] (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 02DGhJEK020798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Mar 2020 12:43:19 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_AA2E395F-E13B-4220-A854-3BDFBA74B31F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158403809452.18288.11892420987391669774@ietfa.amsl.com> To: txauth@ietf.org Date: Fri, 13 Mar 2020 12:43:18 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Fwd: [107all] IETF 107 Virtual Meeting Agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 16:43:24 -0000 --Apple-Mail=_AA2E395F-E13B-4220-A854-3BDFBA74B31F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As you can see below, TXAuth still has a virtual slot in the IETF107 = virtual agenda. It=E2=80=99s at a different day and time than our = meeting originally was, but I hope that everyone can still make it. = =E2=80=9CSee=E2=80=9D you there! =E2=80=94 Justin > Begin forwarded message: >=20 > From: The IESG > Subject: [107all] IETF 107 Virtual Meeting Agenda > Date: March 12, 2020 at 2:34:54 PM EDT > To: "IETF Announcement List" > Cc: ietf@ietf.org, 107all@ietf.org, irtf-announce@ietf.org > Reply-To: iesg@ietf.org >=20 > We have created a virtual IETF 107 agenda because the in-person = meeting was cancelled. This is a detailed email that explains our = choices. Please read it to the end. >=20 > We prioritized the scheduling of BOFs, working groups meeting for the = first time, and dispatch-style working groups. Existing working groups = should know how to progress their work via email and (virtual) interims, = and many of them have a solid basis to do that with participants who = have been collaborating together for a long time. But BOFs and new WGs = do not have that established working mode and usually benefit from = dedicated meeting time for bootstrapping purposes, as well as from a = participant base drawn from all IETF areas. Similarly, dispatch-style = groups are aiming to dispatch new work that otherwise has not seen much = previous discussion.=20 >=20 > The virtual agenda is as follows, with all times listed in UTC: >=20 > Monday, March 23 > 20:00-22:00 TXAUTH > 22:10-00:10 DISPATCH >=20 > Tuesday, March 24 > 20:00-22:00 ADD, RAW > 22:10-00:10 MASQUE >=20 > Wednesday, March 25 > 20:00-21:30 WPACK, DRIP > 21:40-22:40 GENDISPATCH > 22:50-00:30 Plenary >=20 > Thursday, March 26 > 20:00-22:00 PRIVACYPASS > 22:10-00:10 RIPT >=20 > Friday, March 27 > 20:00-22:00 SECDISPATCH > 22:10-00:10 WEBTRANS >=20 > The total meeting block for WG and BOF sessions amounts to: >=20 > Pacific Time 13:00-17:10 (17:30 on Weds) > Eastern Time 16:00-20:10 (20:30 on Weds) > Coordinated Universal Time 20:00-00:10 (00:30 on Weds) > Central European Time 21:00-01:10 (01:30 on Weds) > India Standard Time 01:30-05:40 (06:00 on Weds) > China Standard Time 04:00-08:10 (08:30 on Weds) > Australian Eastern Standard Time 07:00-11:10 (11:30 on Weds) >=20 > We will be using Webex for all of these sessions. We will be posting = training materials and online resources in an FAQ on the IETF web site = next week for those who are unfamiliar with Webex.=20 >=20 > This agenda, with links to the Webex sessions, will appear in the = datatracker shortly. If you plan to attend any of these sessions and you = are not already registered for IETF 107, we encourage you to register as = a remote participant . >=20 > There will not be any other working group meetings, area meetings, or = research group meetings scheduled between March 23 and March 27. HotRFC = is cancelled. We are not providing virtual replacements for side = meetings. The organizers of the Hackathon and the Code Sprint are = working on virtual support for those events and they will communicate = separately about those.=20 >=20 > We are aiming to provide a =E2=80=9Challway=E2=80=9D Webex meeting = where participants can go to test audio and other Webex features and to = find others who are attending IETF 107 virtually. The = hallway@jabber.ietf.org jabber room will also continue to be available. = More information about these will be available on the FAQ page next = week. >=20 > There are many trade-offs involved in scheduling an all-virtual = meeting. We will be pleased if the BOFs on the agenda are able to form = WGs after this. But if not, the virtual BOF will not count as one = attempt against the usual allotment of two attempts to form a WG, given = the unusual circumstances. >=20 > RFC 8713, which specifies the NomCom process, relies heavily on there = being three meetings per year known as the first, second, and third = meetings, respectively. We consider the virtual IETF 107 to be the first = IETF meeting of 2020. We will be seating the new members of the = 2020-2021 IESG, IAB, and IETF LLC Board at the virtual plenary. We are = considering the implications of the cancelled Vancouver meeting for = NomCom volunteer qualification specified in RFC 8713 Section 4.14 and we = will be inviting community discussion about that soon.=20 >=20 > We chose to focus this agenda on the 4.5 hours between 20:00 UTC and = 00:30 UTC. Because we anticipate having relatively few participants for = the scheduled sessions located in the part of the world between Europe = and China, this schedule aims to give the most participants an = opportunity to experience =E2=80=9Cnight time=E2=80=9D -- albeit = abbreviated -- even if they wish to participate in the meeting multiple = days in a row. We consulted with the chairs of the listed sessions when = we were crafting this agenda to check if they thought that many of their = expected participants would be disadvantaged by the slots chosen. They = thought these slots were workable. >=20 > We are preparing for an increased volume of virtual interim meetings = in April and beyond. We will share more information about strategies for = avoiding conflicts and ensuring fairness in scheduling of virtual = interims next week. Until then, we would like to ask chairs to refrain = from scheduling virtual interims. >=20 > We understand that the agenda above is far from ideal. We know that = some people reserved a whole week for IETF work and that week will now = appear empty, and we know that working late into the night, working = overnight, or getting up very early will be unpleasant or infeasible for = some. We understand that when people join meetings from home, other = commitments may interfere. We know there are many in our community with = novel ideas about how to run virtual meetings, and these should be = explored further. With the agenda above, we did the best we could given = the rapidly changing conditions. We do not expect any of the decisions = we made for this meeting to set a precedent for future meetings. >=20 > It was very evident to the IESG in the course of developing this = agenda that we lack consensus-based community recommendations about how = to deal with the inherent difficulties of scheduling virtual meetings = given time zone differences. After IETF 107, we will figure out the best = way to work with those interested in the community on this topic, = perhaps via the manycouches mailing list, GENDISPATCH, a BOF, or other = ways. >=20 > Feel free to send questions and comments to iesg@ietf.org. We may not = be able to respond immediately since we are busier than usual at the = moment as we prepare for the virtual meeting and the seating of the new = IESG members. >=20 > Regards, > The IESG >=20 > --=20 > 107all mailing list > 107all@ietf.org > https://www.ietf.org/mailman/listinfo/107all --Apple-Mail=_AA2E395F-E13B-4220-A854-3BDFBA74B31F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = you can see below, TXAuth still has a virtual slot in the IETF107 = virtual agenda. It=E2=80=99s at a different day and time than our = meeting originally was, but I hope that everyone can still make it. = =E2=80=9CSee=E2=80=9D you there!

 =E2=80=94 Justin

Begin forwarded message:

From: = The IESG <iesg@ietf.org>
Subject: = [107all] IETF 107 = Virtual Meeting Agenda
Date: = March 12, 2020 at 2:34:54 PM = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org, 107all@ietf.org, irtf-announce@ietf.org
Reply-To: = iesg@ietf.org

We have created a virtual = IETF 107 agenda because the in-person meeting was cancelled. This is a = detailed email that explains our choices. Please read it to the end.

We prioritized the scheduling of BOFs, working = groups meeting for the first time, and dispatch-style working groups. = Existing working groups should know how to progress their work via email = and (virtual) interims, and many of them have a solid basis to do that = with participants who have been collaborating together for a long time. = But BOFs and new WGs do not have that established working mode and = usually benefit from dedicated meeting time for bootstrapping purposes, = as well as from a participant base drawn from all IETF areas. Similarly, = dispatch-style groups are aiming to dispatch new work that otherwise has = not seen much previous discussion.

The = virtual agenda is as follows, with all times listed in UTC:

Monday, March 23
20:00-22:00 = TXAUTH
22:10-00:10 DISPATCH

Tuesday, March 24
20:00-22:00 ADD, RAW
22:10-00:10 MASQUE

Wednesday, = March 25
20:00-21:30 WPACK, DRIP
21:40-22:40 = GENDISPATCH
22:50-00:30 Plenary

Thursday, March 26
20:00-22:00 PRIVACYPASS
22:10-00:10 RIPT

Friday, March = 27
20:00-22:00 SECDISPATCH
22:10-00:10 = WEBTRANS

The total meeting block for WG and = BOF sessions amounts to:

Pacific Time =             &n= bsp;     13:00-17:10  (17:30 on Weds)
Eastern Time =             &n= bsp; 16:00-20:10  (20:30 on Weds)
Coordinated = Universal Time        20:00-00:10 =  (00:30 on Weds)
Central European Time =          21:00-01:10 =  (01:30 on Weds)
India Standard Time =            01:30-05= :40  (06:00 on Weds)
China Standard Time =          04:00-08:10 =  (08:30 on Weds)
Australian Eastern Standard Time =       07:00-11:10  (11:30 on Weds)

We will be using Webex for all of these = sessions. We will be posting training materials and online resources in = an FAQ on the IETF web site next week for those who are unfamiliar with = Webex.

This agenda, with links to the = Webex sessions, will appear in the datatracker shortly. If you plan to = attend any of these sessions and you are not already registered for IETF = 107, we encourage you to register as a remote participant <https://www.ietf.org/how/meetings/register/>.

There will not be any other working group = meetings, area meetings, or research group meetings scheduled between = March 23 and March 27. HotRFC is cancelled. We are not providing virtual = replacements for side meetings. The organizers of the Hackathon and the = Code Sprint are working on virtual support for those events and they = will communicate separately about those.

We = are aiming to provide a =E2=80=9Challway=E2=80=9D Webex meeting where = participants can go to test audio and other Webex features and to find = others who are attending IETF 107 virtually. The hallway@jabber.ietf.org jabber room will also continue to = be available. More information about these will be available on the FAQ = page next week.

There are many trade-offs = involved in scheduling an all-virtual meeting. We will be pleased if the = BOFs on the agenda are able to form WGs after this. But if not, the = virtual BOF will not count as one attempt against the usual allotment of = two attempts to form a WG, given the unusual circumstances.

RFC 8713, which specifies the NomCom process, = relies heavily on there being three meetings per year known as the = first, second, and third meetings, respectively. We consider the virtual = IETF 107 to be the first IETF meeting of 2020. We will be seating the = new members of the 2020-2021 IESG, IAB, and IETF LLC Board at the = virtual plenary. We are considering the implications of the cancelled = Vancouver meeting for NomCom volunteer qualification specified in RFC = 8713 Section 4.14 and we will be inviting community discussion about = that soon.

We chose to focus this agenda = on the 4.5 hours between 20:00 UTC and 00:30 UTC. Because we anticipate = having relatively few participants for the scheduled sessions located in = the part of the world between Europe and China, this schedule aims to = give the most participants an opportunity to experience =E2=80=9Cnight = time=E2=80=9D -- albeit abbreviated -- even if they wish to participate = in the meeting multiple days in a row. We consulted with the chairs of = the listed sessions when we were crafting this agenda to check if they = thought that many of their expected participants would be disadvantaged = by the slots chosen. They thought these slots were workable.

We are preparing for an increased volume of = virtual interim meetings in April and beyond. We will share more = information about strategies for avoiding conflicts and ensuring = fairness in scheduling of virtual interims next week. Until then, we = would like to ask chairs to refrain from scheduling virtual interims.

We understand that the agenda above is far = from ideal. We know that some people reserved a whole week for IETF work = and that week will now appear empty, and we know that working late into = the night, working overnight, or getting up very early will be = unpleasant or infeasible for some. We understand that when people join = meetings from home, other commitments may interfere. We know there are = many in our community with novel ideas about how to run virtual = meetings, and these should be explored further. With the agenda above, = we did the best we could given the rapidly changing conditions. We do = not expect any of the decisions we made for this meeting to set a = precedent for future meetings.

It was very = evident to the IESG in the course of developing this agenda that we lack = consensus-based community recommendations about how to deal with the = inherent difficulties of scheduling virtual meetings given time zone = differences. After IETF 107, we will figure out the best way to work = with those interested in the community on this topic, perhaps via the = manycouches mailing list, GENDISPATCH, a BOF, or other ways.

Feel free to send questions and comments to iesg@ietf.org. We may not = be able to respond immediately since we are busier than usual at the = moment as we prepare for the virtual meeting and the seating of the new = IESG members.

Regards,
The = IESG

--
107all mailing = list
107all@ietf.org
https://www.ietf.org/mailman/listinfo/107all

= --Apple-Mail=_AA2E395F-E13B-4220-A854-3BDFBA74B31F-- From nobody Fri Mar 13 13:59:44 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4E3A1003; Fri, 13 Mar 2020 13:59:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158413314888.3136.18382213472704342356@ietfa.amsl.com> Date: Fri, 13 Mar 2020 13:59:08 -0700 Archived-At: Subject: [Txauth] txauth - Requested session has been scheduled for IETF 107 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 20:59:22 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. txauth Session 1 (2:00 requested) Monday, 23 March 2020, Session I 2000-2200 Room Name: Virtual Track 1 size: None --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/txauth.ics Request Information: --------------------------------------------------------- Working Group Name: Transactional Authorization and Delegation Area Name: Security Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: oauth saag secdispatch httpbis uta cose ace acme calext curdle detnet dots emu i2nsf ipsecme kitten lake lamps mile mls rats sacm secevent suit teep tls tokbind trans People who must be present: Yaron Sheffer Roman Danyliw Dick Hardt Resources Requested: Special Requests: They would prefer 2.5 hours according to the wiki. --------------------------------------------------------- From nobody Fri Mar 13 15:13:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6793A1120 for ; Fri, 13 Mar 2020 15:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.998, 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 RFuxL9kscHTl for ; Fri, 13 Mar 2020 15:13:03 -0700 (PDT) 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 344D93A1121 for ; Fri, 13 Mar 2020 15:13:02 -0700 (PDT) Received: from [192.168.1.5] (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 02DMD1xD011447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Mar 2020 18:13:01 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_E40347FB-4924-44C1-AFAD-F70A514D9493" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <6750F9C8-425E-45B1-BCE8-52674F7BCDC5@mit.edu> Date: Fri, 13 Mar 2020 18:13:00 -0400 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2020 22:13:05 -0000 --Apple-Mail=_E40347FB-4924-44C1-AFAD-F70A514D9493 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I took some time to implement an idea that was tossed out on the list = here recently, and that=E2=80=99s how we might support requests and = responses for multiple access tokens. I=E2=80=99ve got a method that I = think works pretty well without getting in the way of the common, simple = case of requesting a single access token. I=E2=80=99ve implemented this = in our Java implementation of XYZ and I=E2=80=99ve updated the = https://oauth.xyz/ website with more details. I=E2=80=99ll update my ID = spec text when I get a chance to reflect this, but I wanted to start = this discussion first. Everything in here is based on the XYZ protocol. Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is an = array of items: resources: [ { actions: ["read", "write", "dolphin"], locations: ["https://server.example.net/", = "https://resource.local/other"], datatypes: ["metadata", "images"] }, { actions: ["foo", "bar", "dolphin"], locations: ["https://resource.other/"], datatypes: ["data", "pictures"] } ] This tells the AS that the client is asking for a single access token = with multiple, perhaps orthogonal sets of access. This is in parallel to = RAR being developed in OAuth 2. However, if we allow the =E2=80=9Cresource= s=E2=80=9D item to be an object instead of an array, we can let the = client signal to the AS that it wants multiple access tokens. The client = picks =E2=80=9Clabels=E2=80=9D for these access tokens, in this case = =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D, and sends a = request like this. resources: { token1: [{ actions: ["read", "write", "dolphin"], locations: ["https://server.example.net/", = "https://resource.local/other"], datatypes: ["metadata", "images"] }], token2: [{ actions: ["foo", "bar", "dolphin"], locations: ["https://resource.other/"], datatypes: ["data", "pictures"] }] } The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this: { access_token: { value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", type: "bearer" } } Or multiple access tokens in a tx response like this: { multiple_access_tokens: { token1: { value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", type: "bearer" }, token2: { value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", type: "bearer" } } } These fields are mutually exclusive, so you either get a single unnamed = token or a set of named tokens. Since the client pics the labels for the = access tokens, it=E2=80=99s clear which part of the request maps to = which part of the response. It=E2=80=99s more complexity for the client = to track, but that complexity is only seen and borne by clients that = need it. Simple clients get to stay simple while letting a complex = problem get solved.=20 A note about the polymorphic JSON that=E2=80=99s in user here, though = it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. For = those unfamiliar with the concept, this is when a given field can have a = value that takes multiple different types: a string, a boolean, an = object, an array, etc. This is pretty simple to deal with in dynamically = typed languages, you just check the type of the resulting object and it = will tell you what you=E2=80=99re dealing with. It=E2=80=99s trickier in = statically typed languages, but I=E2=80=99ve found that pretty much = every platform and library has hooks for custom serialization and = deserialization that will let you dispatch to different types during the = process, so you can still call your top-level parser and toString = methods and things will work as expected. This is one of the reasons = that I did an implementation in Java, to prove that we could do this = kind of thing in a strongly typed language that=E2=80=99s not very = flexible about what goes in objects, and I=E2=80=99ve done it without = resorting to generic collections for the dynamic fields. Previously, = I=E2=80=99ve used this feature in XYZ to allow a single string to stand = in as a reference for an object =E2=80=94 something XYZ calls = =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2. resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfoobar-picture= s=E2=80=9D ] Polymorphic JSON is great for things like this because it means you = don=E2=80=99t have to have multiple fields and normative rules for = mutual exclusivity, like we=E2=80=99d have to have otherwise. The type = switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it. People have been asking for a good way to do multiple access tokens with = OAuth for years, but we=E2=80=99ve never had a good or clean way to pull = it off because of OAuth=E2=80=99s model and the assumptions that it = makes. I think TxAuth gives us the opportunity to solve this in a way = that=E2=80=99s consistent with the rest of the protocol, and do so in a = way that doesn=E2=80=99t make the simple cases we know and love too = complicated for average developers. =E2=80=94 Justin --Apple-Mail=_E40347FB-4924-44C1-AFAD-F70A514D9493 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = took some time to implement an idea that was tossed out on the list here = recently, and that=E2=80=99s how we might support requests and responses = for multiple access tokens. I=E2=80=99ve got a method = that I think works pretty well without getting in the way of the common, = simple case of requesting a single access token. I=E2=80=99ve = implemented this in our Java implementation of XYZ and I=E2=80=99ve = updated the https://oauth.xyz/ website with more details. I=E2=80=99= ll update my ID spec text when I get a chance to reflect this, but I = wanted to start this discussion first. Everything in here is based on = the XYZ protocol.

Normally, the =E2=80=9Cresources=E2=80=9D element of a tx = request is an array of items:

resources: [
= {
            = actions: ["read", "write", "dolphin"],
  =           locations: ["https://server.example.net/", "https://resource.local/other"],
 =           datatypes: ["metadata", = "images"]
        },
= {
            = actions: ["foo", "bar", "dolphin"],
    =         locations: ["https://resource.other/"],
  =           datatypes: ["data", = "pictures"]
        }
]

This tells the AS that the client is asking for a single = access token with multiple, perhaps orthogonal sets of access. This is = in parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this.

resources: = {
    token1: [{
            actions: ["read", = "write", "dolphin"],
        =     locations: ["https://server.example.net/", "https://resource.local/other"],
 =           datatypes: ["metadata", = "images"]
     }],
     token2: [{
  =           actions: ["foo", "bar", = "dolphin"],
          =   locations: ["https://resource.other/"],
  =           datatypes: ["data", = "pictures"]
     }]
}

The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this:

{
      =   access_token: {
        =     value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =           type: "bearer"
        }
}

Or multiple access tokens in a tx response like = this:

{
    multiple_access_tokens: = {
          token1: = {
            value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =           type: "bearer"
          },
          token2: {
            value: = "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
  =           type: "bearer"
          }
    }
}

These fields are = mutually exclusive, so you either get a single unnamed token or a set of = named tokens. Since the client pics the labels for the access tokens, = it=E2=80=99s clear which part of the request maps to which part of the = response. It=E2=80=99s more complexity for the client to track, but that = complexity is only seen and borne by clients that need it. Simple = clients get to stay simple while letting a complex problem get = solved. 

A note about the polymorphic JSON that=E2=80=99s in user = here, though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol = design. For those unfamiliar with the concept, this is when a given = field can have a value that takes multiple different types: a string, a = boolean, an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2.

resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ]

Polymorphic JSON is great for things = like this because it means you don=E2=80=99t have to have multiple = fields and normative rules for mutual exclusivity, like we=E2=80=99d = have to have otherwise. The type switching only works when the base type = is significantly different, though =E2=80=94 that=E2=80=99s why I have = =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tokens=E2=80=9D= above, since both are objects at the top level and you can=E2=80=99t = cleanly switch at the parser level, and you don=E2=80=99t want to have = to dig down into the object to see what to do with it.



People have been asking = for a good way to do multiple access tokens with OAuth for years, but = we=E2=80=99ve never had a good or clean way to pull it off because of = OAuth=E2=80=99s model and the assumptions that it makes. I think TxAuth = gives us the opportunity to solve this in a way that=E2=80=99s = consistent with the rest of the protocol, and do so in a way that = doesn=E2=80=99t make the simple cases we know and love too complicated = for average developers.

 =E2=80=94 Justin

= --Apple-Mail=_E40347FB-4924-44C1-AFAD-F70A514D9493-- From nobody Sat Mar 14 03:16:03 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBC23A11C5 for ; Sat, 14 Mar 2020 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_OTHER_BAD_TLD=1.998, 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=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 9oBvRDATyLjL for ; Sat, 14 Mar 2020 03:15:50 -0700 (PDT) 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 8631D3A11B9 for ; Sat, 14 Mar 2020 03:15:44 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id g62so12825303wme.1 for ; Sat, 14 Mar 2020 03:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:message-id:date :cc:to; bh=usrBIKSQKUqF6OmeOfKQZSoka89gXEH6XX0yU+wsTWU=; b=RjElLWpOUxHRaM6vzLBVz1zIlMEMKBJ/p2BhsWZ2mOp96Y3qJsOn2OAzlGWpCRRChH 1aDeljtZthQmZmC3mQ3axXP68fHgRjILIT+SuIfMojaMHgjB3g13B+epb/uJ7xgLo9Xy rbF9FuGx8voR6etnxc3zj5BbJijNVvCkKvNiz/lrPn74BFAtn6IRFmmJ/Bs6scBzQPnP DvAiOArsnFfnp5pLErz/kZgNBzhKKHdJcudosvfLqMQitpa3g5Vpuz0z3XCwMUHiADqi NKZvRFX7/cjyUUkd3Wp7vcR8/WSt9emvXZpKp0jGi9I2LUQZH2n2hxg95xkot/YkndJN myQA== 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:to; bh=usrBIKSQKUqF6OmeOfKQZSoka89gXEH6XX0yU+wsTWU=; b=fBr4/SGwUL1w0Js7U2C/GIouGgp3+nBjz9BTTCquDsj4nRbpCkH8cEOrxomU02C+Gs 8Zw3OiSTvmiaG7T6e5raPWIZlc7UzjMV/KsmKDJdKDLN8HBiHPbXFmppH1g0XJsv7QqU n0xzL/9lxaReA/ULZsZVS2a3Ji/QiLpzJEUiRdZS9eq/AlODlNig25eA5AEtai0wDYj2 RndP09FXzhBL1cAi11OCn78BAGnkwRPJli6+k/McZSbJSryuCkIg38mcyTrrr1kb31k7 e0gDtxtBvOH4/6BWfRmGZ3cg1uiFFrQbGCa1VKIII6dmweeMgLOHsvgbzaBnWoq0aFzV KM/g== X-Gm-Message-State: ANhLgQ1NOdpECUfEBE0Rdby794pqfRaB7oXIJfM1wblwFmzpqQ/lxJWl mFVcMeobqg2r9EJpcbp3rUrBIQ== X-Google-Smtp-Source: ADFU+vvgo5cWkIRaAiFrVn7tQTQwh63hRKjjn+iSVvw/0PuFyTlyNSQCkwwFdCBTYPc5CxN1a9ZjwA== X-Received: by 2002:a1c:9658:: with SMTP id y85mr6884743wmd.63.1584180936446; Sat, 14 Mar 2020 03:15:36 -0700 (PDT) Received: from ?IPv6:2a01:598:9288:d482:1cb7:ff27:b152:fe5f? ([2a01:598:9288:d482:1cb7:ff27:b152:fe5f]) by smtp.gmail.com with ESMTPSA id s7sm9507900wri.61.2020.03.14.03.15.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Mar 2020 03:15:35 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-459BB24C-9E7E-45E6-8E23-44B500526AAA; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Message-Id: Date: Sat, 14 Mar 2020 11:04:28 +0100 Cc: txauth@ietf.org To: Justin Richer X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 10:16:02 -0000 --Apple-Mail-459BB24C-9E7E-45E6-8E23-44B500526AAA Content-Type: multipart/alternative; boundary=Apple-Mail-839012B8-7307-4152-8DAE-098D1C54C85B Content-Transfer-Encoding: 7bit --Apple-Mail-839012B8-7307-4152-8DAE-098D1C54C85B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =EF=BB=BF Hi Justin, I have always been a fan of multiple access tokens support :-) So thanks you= for bringing this forward. Some questions: Do you assume the client can freely allocated resources to access tokens? Ho= w would that work with audience-restricted/specific access tokens? I think a further element =E2=80=9Etoken=E2=80=9C element within the resourc= e structure could also be used to denote the assignment of a certain resourc= e object to this token. Advantage: no need to change the syntax. What do you= think about this approach? best regards, Torsten. >> Am 13.03.2020 um 23:13 schrieb Justin Richer : > =EF=BB=BFI took some time to implement an idea that was tossed out on the l= ist here recently, and that=E2=80=99s how we might support requests and resp= onses for multiple access tokens. I=E2=80=99ve got a method that I think wor= ks pretty well without getting in the way of the common, simple case of requ= esting a single access token. I=E2=80=99ve implemented this in our Java impl= ementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/ website wi= th more details. I=E2=80=99ll update my ID spec text when I get a chance to r= eflect this, but I wanted to start this discussion first. Everything in here= is based on the XYZ protocol. >=20 > Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is an ar= ray of items: >=20 > resources: [ > { > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/", "https://resource.l= ocal/other"], > datatypes: ["metadata", "images"] > }, > { > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/"], > datatypes: ["data", "pictures"] > } > ] >=20 > This tells the AS that the client is asking for a single access token with= multiple, perhaps orthogonal sets of access. This is in parallel to RAR bei= ng developed in OAuth 2. However, if we allow the =E2=80=9Cresources=E2=80=9D= item to be an object instead of an array, we can let the client signal to t= he AS that it wants multiple access tokens. The client picks =E2=80=9Clabels= =E2=80=9D for these access tokens, in this case =E2=80=9Ctoken1=E2=80=9D and= =E2=80=9Ctoken2=E2=80=9D, and sends a request like this. >=20 > resources: { > token1: [{ > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/", "https://resource.l= ocal/other"], > datatypes: ["metadata", "images"] > }], > token2: [{ > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/"], > datatypes: ["data", "pictures"] > }] > } >=20 > The client could request multiple kinds of access within each sub-object=E2= =80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2= =E2=80=9D fields), but I wanted to keep it simple here. This example is the s= ame total set of resources that the client is asking for in the first case, b= ut here the client=E2=80=99s saying it wants them as two different access to= kens instead of a single one. The AS can tell the difference in the request b= ecause the first type is an array at the top and the second type is an objec= t at the top. So that means that the AS can send back a single access token i= n a tx response like this: >=20 > { > access_token: { > value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > type: "bearer" > } > } >=20 > Or multiple access tokens in a tx response like this: >=20 > { > multiple_access_tokens: { > token1: { > value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > type: "bearer" > }, > token2: { > value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > type: "bearer" > } > } > } >=20 > These fields are mutually exclusive, so you either get a single unnamed to= ken or a set of named tokens. Since the client pics the labels for the acces= s tokens, it=E2=80=99s clear which part of the request maps to which part of= the response. It=E2=80=99s more complexity for the client to track, but tha= t complexity is only seen and borne by clients that need it. Simple clients g= et to stay simple while letting a complex problem get solved.=20 >=20 > A note about the polymorphic JSON that=E2=80=99s in user here, though it=E2= =80=99s already a key part of XYZ=E2=80=99s protocol design. For those unfam= iliar with the concept, this is when a given field can have a value that tak= es multiple different types: a string, a boolean, an object, an array, etc. T= his is pretty simple to deal with in dynamically typed languages, you just c= heck the type of the resulting object and it will tell you what you=E2=80=99= re dealing with. It=E2=80=99s trickier in statically typed languages, but I=E2= =80=99ve found that pretty much every platform and library has hooks for cus= tom serialization and deserialization that will let you dispatch to differen= t types during the process, so you can still call your top-level parser and t= oString methods and things will work as expected. This is one of the reasons= that I did an implementation in Java, to prove that we could do this kind o= f thing in a strongly typed language that=E2=80=99s not very flexible about w= hat goes in objects, and I=E2=80=99ve done it without resorting to generic c= ollections for the dynamic fields. Previously, I=E2=80=99ve used this featur= e in XYZ to allow a single string to stand in as a reference for an object =E2= =80=94 something XYZ calls =E2=80=9Chandles=E2=80=9D. These let you have con= structs akin to a client_id, a scope, a refresh token, and a few other items= without having to create explicit elements for these, since they always sta= nd in for the object they replace there=E2=80=99s no ambiguity. So for thing= s like a resource request, each of these can be replaced by a string using r= esource handles and polymorphic JSON (see note below) to act like a scope in= OAuth2. >=20 > resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfoobar-picture= s=E2=80=9D ] >=20 > Polymorphic JSON is great for things like this because it means you don=E2= =80=99t have to have multiple fields and normative rules for mutual exclusiv= ity, like we=E2=80=99d have to have otherwise. The type switching only works= when the base type is significantly different, though =E2=80=94 that=E2=80=99= s why I have =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tok= ens=E2=80=9D above, since both are objects at the top level and you can=E2=80= =99t cleanly switch at the parser level, and you don=E2=80=99t want to have t= o dig down into the object to see what to do with it. >=20 >=20 >=20 > People have been asking for a good way to do multiple access tokens with O= Auth for years, but we=E2=80=99ve never had a good or clean way to pull it o= ff because of OAuth=E2=80=99s model and the assumptions that it makes. I thi= nk TxAuth gives us the opportunity to solve this in a way that=E2=80=99s con= sistent with the rest of the protocol, and do so in a way that doesn=E2=80=99= t make the simple cases we know and love too complicated for average develop= ers. >=20 > =E2=80=94 Justin >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-839012B8-7307-4152-8DAE-098D1C54C85B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=EF=BB=BF
Hi Ju= stin,

I have always been a f= an of multiple access tokens support :-) So thanks you for bringing this for= ward.

Some questions:
=

Do you assume the client can fre= ely allocated resources to access tokens? How would that work with audience-= restricted/specific access tokens?

I think a further element =E2=80=9Etoken=E2=80=9C element within the r= esource structure could also be used to denote the assignment of a certain r= esource object to this token. Advantage: no need to change the syntax. What d= o you think about this approach?

best regards,
Torsten.
Am 13.03.2020 um 23:13 schrieb Justin Richer <= jricher@mit.edu>:

=EF=BB=BFI took some time to implement an idea that was tossed ou= t on the list here recently, and that=E2=80=99s how we might support request= s and responses for multiple access tokens. I=E2=80=99ve g= ot a method that I think works pretty well without getting in the way of the= common, simple case of requesting a single access token. I=E2=80=99ve imple= mented this in our Java implementation of XYZ and I=E2=80=99ve updated the <= b class=3D"">https://oauth.xyz/ website with more details. I=E2=80=99ll update my ID spec text when I g= et a chance to reflect this, but I wanted to start this discussion first. Ev= erything in here is based on the XYZ protocol.

Normally, the =E2=80=9Cresources=E2=80=9D element of a= tx request is an array of items:

=
resources: [
{
 = ;           actions: ["read", "write", "dolphin"],<= /div>
            locations: ["= https://server.example.ne= t/", "https://resour= ce.local/other"],
         = ;   datatypes: ["metadata", "images"]
   = ;     },
{
      &= nbsp;     actions: ["foo", "bar", "dolphin"],
            locations: ["https://resource.other/"],
            datatypes: ["data", "pictures"]=
        }
]

This t= ells the AS that the client is asking for a single access token with multipl= e, perhaps orthogonal sets of access. This is in parallel to RAR being devel= oped in OAuth 2. However, if we allow the =E2=80=9Cresources=E2=80=9D item t= o be an object instead of an array, we can let the client signal to the AS t= hat it wants multiple access tokens. The client picks =E2=80=9Clabels=E2=80=9D= for these access tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9C= token2=E2=80=9D, and sends a request like this.

resources: {
    token1: [{
      &= nbsp;     actions: ["read", "write", "dolphin"],
            locations: ["https://server.example.net/", "https://resource.local/other"]= ,
            datatypes: [= "metadata", "images"]
     }],
     token2: [{
   = ;         actions: ["foo", "bar", "dolphin"],
            locations: ["https://resource.other/"],
            datatypes: ["data", "p= ictures"]
     }]
}

= The client could request multiple kinds of access within each sub-object=E2=80= =99s array (the value of the =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2= =80=9D fields), but I wanted to keep it simple here. This example is the sam= e total set of resources that the client is asking for in the first case, bu= t here the client=E2=80=99s saying it wants them as two different access tok= ens instead of a single one. The AS can tell the difference in the request b= ecause the first type is an array at the top and the second type is an objec= t at the top. So that means that the AS can send back a single access token i= n a tx response like this:

{
      &n= bsp; access_token: {
         =   value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
            type: "bearer"
        }
}

Or multiple access t= okens in a tx response like this:

=
{
    multiple_access_toke= ns: {
          token1: {
            value: "OS9M2PMHK= UR64TB8N6BW7OZB8CDFONP219RP1LT0",
      &= nbsp;     type: "bearer"
     =     },
          to= ken2: {
            value= : "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
  &n= bsp;         type: "bearer"
  &= nbsp;       }
    }
}

These fields are mutually exclusive, so you either get a single unnam= ed token or a set of named tokens. Since the client pics the labels for the a= ccess tokens, it=E2=80=99s clear which part of the request maps to which par= t of the response. It=E2=80=99s more complexity for the client to track, but= that complexity is only seen and borne by clients that need it. Simple clie= nts get to stay simple while letting a complex problem get solved. 

A note a= bout the polymorphic JSON that=E2=80=99s in user here, though it=E2=80=99= s already a key part of XYZ=E2=80=99s protocol design. For those unfamiliar w= ith the concept, this is when a given field can have a value that takes mult= iple different types: a string, a boolean, an object, an array, etc. This is= pretty simple to deal with in dynamically typed languages, you just check t= he type of the resulting object and it will tell you what you=E2=80=99re dea= ling with. It=E2=80=99s trickier in statically typed languages, but I=E2=80=99= ve found that pretty much every platform and library has hooks for custom se= rialization and deserialization that will let you dispatch to different type= s during the process, so you can still call your top-level parser and toStri= ng methods and things will work as expected. This is one of the reasons that= I did an implementation in Java, to prove that we could do this kind of thi= ng in a strongly typed language that=E2=80=99s not very flexible about what g= oes in objects, and I=E2=80=99ve done it without resorting to generic collec= tions for the dynamic fields. Previously, I=E2=80=99ve used this feature in X= YZ to allow a single string to stand in as a reference for an object =E2=80=94= something XYZ calls =E2=80=9Chandles=E2=80=9D. These let you have construct= s akin to a client_id, a scope, a refresh token, and a few other items witho= ut having to create explicit elements for these, since they always stand in f= or the object they replace there=E2=80=99s no ambiguity. So for things like a= resource request, each of these can be replaced by a string using resource h= andles and polymorphic JSON (see note below) to act like a scope in OAuth2.<= /div>

resources: [ =E2=80=9Cm= etadata-readwrite=E2=80=9D, =E2=80=9Cfoobar-pictures=E2=80=9D ]
=

Polymorphic JSON is gre= at for things like this because it means you don=E2=80=99t have to have mult= iple fields and normative rules for mutual exclusivity, like we=E2=80=99d ha= ve to have otherwise. The type switching only works when the base type is si= gnificantly different, though =E2=80=94 that=E2=80=99s why I have =E2=80=9Ca= ccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, sin= ce both are objects at the top level and you can=E2=80=99t cleanly switch at= the parser level, and you don=E2=80=99t want to have to dig down into the o= bject to see what to do with it.

<= div class=3D"">

People have been asking for a good way to do multiple access to= kens with OAuth for years, but we=E2=80=99ve never had a good or clean way t= o pull it off because of OAuth=E2=80=99s model and the assumptions that it m= akes. I think TxAuth gives us the opportunity to solve this in a way that=E2= =80=99s consistent with the rest of the protocol, and do so in a way that do= esn=E2=80=99t make the simple cases we know and love too complicated for ave= rage developers.

&= nbsp;=E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/li= stinfo/txauth
= --Apple-Mail-839012B8-7307-4152-8DAE-098D1C54C85B-- --Apple-Mail-459BB24C-9E7E-45E6-8E23-44B500526AAA 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzE0MTAwNDI4WjAvBgkqhkiG9w0BCQQxIgQg b2ChJy00T33qmBUIlVyNQJq1iQsARWo9VPvJJOYep2kwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEABHUyRXKIwjQe4Ayy/qB3X2stg5W6wZwrR1k6Aap46EPomvXj3V2w o6+tdIWHafmPP24klrccJhvd6yIhFUlocqyA3JHTcXCUnTon1nawpddQx/y6f2wreRawD9HZN3sc q9ZuI4QBTBB/gMLaRdq9FfxuAngyDUHLhM/id9UBDHVUTO4DiHsdXUHg9iqLcgvcdWYEFermbvm9 52KaAkYw5+IpHTil7Ai2NEoxEnMXCA7lfN/yPWSPxEwzqxY/+HI+3M7ifflnraImPZP+bICv8g/M jpRPIBKk7vEP7RUBiccEAmW+fW2MPBYcChnkacyQ2dQaeid2QiWwqus878+X2gAAAAAAAA== --Apple-Mail-459BB24C-9E7E-45E6-8E23-44B500526AAA-- From nobody Sat Mar 14 06:07:50 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DA13A1231 for ; Sat, 14 Mar 2020 06:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.998, 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 28w0YukKDLnm for ; Sat, 14 Mar 2020 06:07:46 -0700 (PDT) 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 12DFF3A122D for ; Sat, 14 Mar 2020 06:07:45 -0700 (PDT) Received: from [192.168.1.5] (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 02ED7ib7032490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Mar 2020 09:07:44 -0400 From: Justin Richer Message-Id: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E19FF73A-6FB1-4404-8CCA-1CF2992AEAEA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 14 Mar 2020 09:07:43 -0400 In-Reply-To: Cc: txauth@ietf.org To: Torsten Lodderstedt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 13:07:49 -0000 --Apple-Mail=_E19FF73A-6FB1-4404-8CCA-1CF2992AEAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt = wrote: >=20 > =EF=BB=BF > Hi Justin, >=20 > I have always been a fan of multiple access tokens support :-) So = thanks you for bringing this forward. Yes! It=E2=80=99s only taken us another 10 years to get back here again. = :) >=20 > Some questions: >=20 > Do you assume the client can freely allocated resources to access = tokens? How would that work with audience-restricted/specific access = tokens? In the syntax I=E2=80=99m proposing, the client can take any set of = resources and ask for it to go with one token. Basically, each named = element of the resources object in the multi-token request syntax is = exactly the same as a single token request would be, an array of = resource requests. So yes, the client can mix and match as it sees fit, = and the AS can reject a request for combining two different audiences in = the same token. The AS would need to do that anyway for a single token = request, so I don=E2=80=99t see that as a greater burden =E2=80=94 = it=E2=80=99s just that now the client can fulfill the requirements = without making multiple transaction requests.=20 This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to a = client=E2=80=99s simple request, but I actually like that feature. If = the client is capable of dealing with multiple tokens simultaneously, it = can ask for them. The single token case turns into a single unnamed = access token with the same semantics.=20 >=20 > I think a further element =E2=80=9Etoken=E2=80=9C element within the = resource structure could also be used to denote the assignment of a = certain resource object to this token. Advantage: no need to change the = syntax. What do you think about this approach? That=E2=80=99s an interesting idea, and I can see the advantage of a = simpler syntax on the surface =E2=80=A6 but at first shake I see a = couple problems with it. First, this presumes you=E2=80=99d always be = sending a full resource object. If you=E2=80=99re sending a scope string = (or a resource handle in XYZ terms), then you don=E2=80=99t have = anywhere to put the name of the token since it=E2=80=99s no longer an = object. Second, there=E2=80=99s no clear way to combine multiple = resource facets into a single token. And third, you now have to handle a = whole bunch of new error cases: what if some of the resource request = objects have names, and others don=E2=80=99t? What if you use the same = name on multiple resource request objects? If that means you combine = them into a single token, you=E2=80=99re back at the question above = about audience restrictions. And finally, it changes the semantics of = the resource object in a way that a simple client would have to at least = know about, and be able to deal with the AS=E2=80=99s different error = conditions. Your thoughts on these points? I might be missing something obvious with = what you=E2=80=99re suggesting. Thanks for the feedback! =E2=80=94 Justin >=20 > best regards, > Torsten. >=20 >> Am 13.03.2020 um 23:13 schrieb Justin Richer : >>=20 >> =EF=BB=BFI took some time to implement an idea that was tossed out on = the list here recently, and that=E2=80=99s how we might support requests = and responses for multiple access tokens. I=E2=80=99ve got a method that = I think works pretty well without getting in the way of the common, = simple case of requesting a single access token. I=E2=80=99ve = implemented this in our Java implementation of XYZ and I=E2=80=99ve = updated the https://oauth.xyz/ website with more = details. I=E2=80=99ll update my ID spec text when I get a chance to = reflect this, but I wanted to start this discussion first. Everything in = here is based on the XYZ protocol. >>=20 >> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is = an array of items: >>=20 >> resources: [ >> { >> actions: ["read", "write", "dolphin"], >> locations: ["https://server.example.net/ = ", "https://resource.local/other = "], >> datatypes: ["metadata", "images"] >> }, >> { >> actions: ["foo", "bar", "dolphin"], >> locations: ["https://resource.other/ = "], >> datatypes: ["data", "pictures"] >> } >> ] >>=20 >> This tells the AS that the client is asking for a single access token = with multiple, perhaps orthogonal sets of access. This is in parallel to = RAR being developed in OAuth 2. However, if we allow the =E2=80=9Cresource= s=E2=80=9D item to be an object instead of an array, we can let the = client signal to the AS that it wants multiple access tokens. The client = picks =E2=80=9Clabels=E2=80=9D for these access tokens, in this case = =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D, and sends a = request like this. >>=20 >> resources: { >> token1: [{ >> actions: ["read", "write", "dolphin"], >> locations: ["https://server.example.net/ = ", "https://resource.local/other = "], >> datatypes: ["metadata", "images"] >> }], >> token2: [{ >> actions: ["foo", "bar", "dolphin"], >> locations: ["https://resource.other/ = "], >> datatypes: ["data", "pictures"] >> }] >> } >>=20 >> The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this: >>=20 >> { >> access_token: { >> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> type: "bearer" >> } >> } >>=20 >> Or multiple access tokens in a tx response like this: >>=20 >> { >> multiple_access_tokens: { >> token1: { >> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> type: "bearer" >> }, >> token2: { >> value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >> type: "bearer" >> } >> } >> } >>=20 >> These fields are mutually exclusive, so you either get a single = unnamed token or a set of named tokens. Since the client pics the labels = for the access tokens, it=E2=80=99s clear which part of the request maps = to which part of the response. It=E2=80=99s more complexity for the = client to track, but that complexity is only seen and borne by clients = that need it. Simple clients get to stay simple while letting a complex = problem get solved.=20 >>=20 >> A note about the polymorphic JSON that=E2=80=99s in user here, though = it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. For = those unfamiliar with the concept, this is when a given field can have a = value that takes multiple different types: a string, a boolean, an = object, an array, etc. This is pretty simple to deal with in dynamically = typed languages, you just check the type of the resulting object and it = will tell you what you=E2=80=99re dealing with. It=E2=80=99s trickier in = statically typed languages, but I=E2=80=99ve found that pretty much = every platform and library has hooks for custom serialization and = deserialization that will let you dispatch to different types during the = process, so you can still call your top-level parser and toString = methods and things will work as expected. This is one of the reasons = that I did an implementation in Java, to prove that we could do this = kind of thing in a strongly typed language that=E2=80=99s not very = flexible about what goes in objects, and I=E2=80=99ve done it without = resorting to generic collections for the dynamic fields. Previously, = I=E2=80=99ve used this feature in XYZ to allow a single string to stand = in as a reference for an object =E2=80=94 something XYZ calls = =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2. >>=20 >> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ] >>=20 >> Polymorphic JSON is great for things like this because it means you = don=E2=80=99t have to have multiple fields and normative rules for = mutual exclusivity, like we=E2=80=99d have to have otherwise. The type = switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it. >>=20 >>=20 >>=20 >> People have been asking for a good way to do multiple access tokens = with OAuth for years, but we=E2=80=99ve never had a good or clean way to = pull it off because of OAuth=E2=80=99s model and the assumptions that it = makes. I think TxAuth gives us the opportunity to solve this in a way = that=E2=80=99s consistent with the rest of the protocol, and do so in a = way that doesn=E2=80=99t make the simple cases we know and love too = complicated for average developers. >>=20 >> =E2=80=94 Justin >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_E19FF73A-6FB1-4404-8CCA-1CF2992AEAEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=EF=BB=BF
Hi Justin,

I have always been a fan of = multiple access tokens support :-) So thanks you for bringing this = forward.

Yes! It=E2=80=99s only taken us another 10 years = to get back here again. :)


Some questions:

Do you = assume the client can freely allocated resources to access tokens? How = would that work with audience-restricted/specific access = tokens?

In the syntax I=E2=80=99m proposing, the client = can take any set of resources and ask for it to go with one token. = Basically, each named element of the resources object in the multi-token = request syntax is exactly the same as a single token request would be, = an array of resource requests. So yes, the client can mix and match as = it sees fit, and the AS can reject a request for combining two different = audiences in the same token. The AS would need to do that anyway for a = single token request, so I don=E2=80=99t see that as a greater burden = =E2=80=94 it=E2=80=99s just that now the client can fulfill the = requirements without making multiple transaction = requests. 

This syntax = doesn=E2=80=99t allow the AS to assign multiple tokens to a client=E2=80=99= s simple request, but I actually like that feature. If the client is = capable of dealing with multiple tokens simultaneously, it can ask for = them. The single token case turns into a single unnamed access token = with the same semantics. 


I think a further element = =E2=80=9Etoken=E2=80=9C element within the resource structure could also = be used to denote the assignment of a certain resource object to this = token. Advantage: no need to change the syntax. What do you think about = this approach?

That=E2=80=99s an interesting idea, and I can see = the advantage of a simpler syntax on the surface =E2=80=A6 but at first = shake I see a couple problems with it. First, this presumes you=E2=80=99d = always be sending a full resource object. If you=E2=80=99re sending a = scope string (or a resource handle in XYZ terms), then you don=E2=80=99t = have anywhere to put the name of the token since it=E2=80=99s no longer = an object. Second, there=E2=80=99s no clear way to combine multiple = resource facets into a single token. And third, you now have to handle a = whole bunch of new error cases: what if some of the resource request = objects have names, and others don=E2=80=99t? What if you use the same = name on multiple resource request objects? If that means you combine = them into a single token, you=E2=80=99re back at the question above = about audience restrictions. And finally, it changes the semantics of = the resource object in a way that a simple client would have to at least = know about, and be able to deal with the AS=E2=80=99s different error = conditions.

Your thoughts on these = points? I might be missing something obvious with what you=E2=80=99re = suggesting.

Thanks for the = feedback!

 =E2=80=94 = Justin


best regards,
Torsten.

Am 13.03.2020 um 23:13 = schrieb Justin Richer <jricher@mit.edu>:

=EF=BB=BFI took some time to = implement an idea that was tossed out on the list here recently, and = that=E2=80=99s how we might support requests and responses for multiple access tokens. I=E2=80=99ve got a method that I = think works pretty well without getting in the way of the common, simple = case of requesting a single access token. I=E2=80=99ve implemented this = in our Java implementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/ website with more details. I=E2=80=99= ll update my ID spec text when I get a chance to reflect this, but I = wanted to start this discussion first. Everything in here is based on = the XYZ protocol.

Normally, the =E2=80=9Cresources=E2=80=9D element of a tx = request is an array of items:

resources: [
= {
            = actions: ["read", "write", "dolphin"],
  =           locations: ["https://server.example.net/", "https://resource.local/other"],
 =           datatypes: ["metadata", = "images"]
        },
= {
            = actions: ["foo", "bar", "dolphin"],
    =         locations: ["https://resource.other/"],
  =           datatypes: ["data", = "pictures"]
        }
]

This tells the AS that the client is asking for a single = access token with multiple, perhaps orthogonal sets of access. This is = in parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this.

resources: = {
    token1: [{
            actions: ["read", = "write", "dolphin"],
        =     locations: ["https://server.example.net/", "https://resource.local/other"],
 =           datatypes: ["metadata", = "images"]
     }],
     token2: [{
  =           actions: ["foo", "bar", = "dolphin"],
          =   locations: ["https://resource.other/"],
  =           datatypes: ["data", = "pictures"]
     }]
}

The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this:

{
      =   access_token: {
        =     value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =           type: "bearer"
        }
}

Or multiple access tokens in a tx response like = this:

{
    multiple_access_tokens: = {
          token1: = {
            value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =           type: "bearer"
          },
          token2: {
            value: = "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
  =           type: "bearer"
          }
    }
}

These fields are = mutually exclusive, so you either get a single unnamed token or a set of = named tokens. Since the client pics the labels for the access tokens, = it=E2=80=99s clear which part of the request maps to which part of the = response. It=E2=80=99s more complexity for the client to track, but that = complexity is only seen and borne by clients that need it. Simple = clients get to stay simple while letting a complex problem get = solved. 

A note about the polymorphic JSON that=E2=80=99s in user = here, though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol = design. For those unfamiliar with the concept, this is when a given = field can have a value that takes multiple different types: a string, a = boolean, an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2.

resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ]

Polymorphic JSON is great for things = like this because it means you don=E2=80=99t have to have multiple = fields and normative rules for mutual exclusivity, like we=E2=80=99d = have to have otherwise. The type switching only works when the base type = is significantly different, though =E2=80=94 that=E2=80=99s why I have = =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tokens=E2=80=9D= above, since both are objects at the top level and you can=E2=80=99t = cleanly switch at the parser level, and you don=E2=80=99t want to have = to dig down into the object to see what to do with it.



People have been asking = for a good way to do multiple access tokens with OAuth for years, but = we=E2=80=99ve never had a good or clean way to pull it off because of = OAuth=E2=80=99s model and the assumptions that it makes. I think TxAuth = gives us the opportunity to solve this in a way that=E2=80=99s = consistent with the rest of the protocol, and do so in a way that = doesn=E2=80=99t make the simple cases we know and love too complicated = for average developers.

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_E19FF73A-6FB1-4404-8CCA-1CF2992AEAEA-- From nobody Sat Mar 14 09:33:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE613A0484 for ; Sat, 14 Mar 2020 09:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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, PDS_OTHER_BAD_TLD=1.998, 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=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 Xc9eIFi6STpr for ; Sat, 14 Mar 2020 09:32:57 -0700 (PDT) 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 070BB3A046A for ; Sat, 14 Mar 2020 09:32:56 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id a132so13140671wme.1 for ; Sat, 14 Mar 2020 09:32:56 -0700 (PDT) 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=1FifrR2eT8XaB92Vj7W8uwiCy/goZZ9hgm/ZYSQRSJc=; b=isk/AT6B7Yen9++daRt30jH4iRtPMfYVCTYr58WPMvmWBnZs5/VVupdlIegA8SkW05 TykKTKU+wzIPw+fBfZoz1monwtxioYUoR3yVn4wHsj8Tzg+9urpmFP9by2MEHkbTp76X Elbf73F/mQTmme6+eLMq0ToPj6nSu66LvX55HL2VrPJSiZIjBrqdM/NdjHNa/w6alEQo 98XZ22lbRDp4vnGPoHpYy1oF+IvAWePp07s8CpydTxgyeeXogJHXqwzlDgDhyfaqwO3a g95kwXpVWniMsjYm/MdHtcxuEtFMSh8bSyl6JAD4GV2dwGIhtMmyOnSgAh6qyF8hfR7N U8MA== 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=1FifrR2eT8XaB92Vj7W8uwiCy/goZZ9hgm/ZYSQRSJc=; b=iYV5Bo4eDnSkU73CT5EoepZHGwMIHQGedGqo94f25eBBjcCA+mVhpER8RhQ/Yrchcc mDx9aoI9cIFwugQqEMrRL2/BeY1kfmc33/RpaC45L+Z+c79LDKxnLIz2wcv0qSisIQK+ j87N3Of5UWnw/74qGaSq0IP+nqcdTMpLX/zhBo4+Q4gbP16deA7V4v3Ki1eHdigx9nfX JAJ/zCDQbyaOi7gRpCvM2iKPybzdejpZJg8SqAo1DsQlBxVk4vu78ioPS7z643ddyvXX WfFC/ObNAXCZJmJu3+Pkqs8DpBEf9GoteeFDKGwl0+9JJUKVT0bxhR1rWEwL8Hd4IPET 2JPQ== X-Gm-Message-State: ANhLgQ2nbPMEjxmsy9Nl1vHUCBFT1M4YiX2R0bxUvOAKeVQoe+J4yxk/ 4K0zjiBdDmH3PlnEfLtWwrczCQ== X-Google-Smtp-Source: ADFU+vu9qZH9QqAxS3EjhmOExYAQrJwc/bybZE0bx9z7q53aAs0CA2z+VMfCUo9tW6XBkXsog0ldBw== X-Received: by 2002:a7b:c413:: with SMTP id k19mr16456133wmi.184.1584203574902; Sat, 14 Mar 2020 09:32:54 -0700 (PDT) Received: from [192.168.71.111] (p549EE22B.dip0.t-ipconnect.de. [84.158.226.43]) by smtp.gmail.com with ESMTPSA id s7sm46401864wrm.13.2020.03.14.09.32.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Mar 2020 09:32:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> Date: Sat, 14 Mar 2020 17:32:52 +0100 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 16:33:00 -0000 Hi Justin, > On 14. Mar 2020, at 14:07, Justin Richer wrote: >=20 > On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt = wrote: >>=20 >> =EF=BB=BF >> Hi Justin, >>=20 >> I have always been a fan of multiple access tokens support :-) So = thanks you for bringing this forward. >=20 > Yes! It=E2=80=99s only taken us another 10 years to get back here = again. :) >=20 yep. Just an example ;-): = https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/ >>=20 >> Some questions: >>=20 >> Do you assume the client can freely allocated resources to access = tokens? How would that work with audience-restricted/specific access = tokens? >=20 > In the syntax I=E2=80=99m proposing, the client can take any set of = resources and ask for it to go with one token. Basically, each named = element of the resources object in the multi-token request syntax is = exactly the same as a single token request would be, an array of = resource requests. So yes, the client can mix and match as it sees fit, = and the AS can reject a request for combining two different audiences in = the same token. The AS would need to do that anyway for a single token = request, so I don=E2=80=99t see that as a greater burden =E2=80=94 = it=E2=80=99s just that now the client can fulfill the requirements = without making multiple transaction requests.=20 What would be the client=E2=80=99s motivation to split resources to = different access tokens?=20 What information would the client use to allocate the resources to the = appropriate access tokens?=20 In my experience, it is the AS (or the security policy of the = deployment) that determines what can go into a single access token.=20 One policy is to allow everything to go into a single access token. That = might work in a single RS deployment. In a multi RS deployment, one = would either end up with tokens containing the set union of all data = needed by all RSs. Encryptions of those tokens might be complex, I = don=E2=80=99t know whether this is privacy preserving. The other option = is to use token introspection or other callbacks to the AS to obtain the = real data needed for access control per RS, not very performant.=20 Another possible policy is to have access tokens that at most contain = data for a certain resource server. This helps privacy (no implicit data = sharing among resource servers) and security (single audience, = encryption is straightforward, simple token replay prevention). But = someone needs to know the boundaries.=20 If the client knows the boundaries, all it would need to ask the AS for = is to issue access tokens for a set of recipients. This could be done in = parallel to the resources structure.=20 Something like this:=20 { "resources":[ { "actions":[ "read", "write", "dolphin" ], "locations":[ "https://server.example.net/", "https://resource.local/other" ], "datatypes":[ "metadata", "images" ] }, { "actions":[ "read" ], "locations":[ "https://server1.example.net/" ], "datatypes":[ "contacts" ] } ], "tokens":[ "https://server.example.net/", "https://server1.example.net/" ] } The default could be that the AS issues an access token good for all = granted resources.=20 One could also go one step further and let the AS decide what access = tokens it would issue and add metadata about the recipients to the = response.=20 { "access_tokens":[ { "destination":"https://server.example.net/"", "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type":"bearer" }, { "destination":"https://server1.example.net/", "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1", "type":"bearer" } ], "handle":{ "value":"80UPRY5NM33OMUKMKSKU", "type":"bearer" }, "claims":{ "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6", "email":"alice@example.com" } } I personally think this would even better fit the transactional = character of the new protocol. >=20 > This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to = a client=E2=80=99s simple request, but I actually like that feature. If = the client is capable of dealing with multiple tokens simultaneously, it = can ask for them. I think that=E2=80=99s the important aspect! In my opinion, the AS = basically decides whether different tokens are required for different = resources. I therefore think all client must be prepared to use = different tokens to use the privileges granted in a certain transaction = (in the same way OAuth 2 clients must be prepared for refresh tokens = rotation). Whether the client asks for more all or just a specific token = (to start with), is a different question.=20 > The single token case turns into a single unnamed access token with = the same semantics.=20 >=20 >>=20 >> I think a further element =E2=80=9Etoken=E2=80=9C element within the = resource structure could also be used to denote the assignment of a = certain resource object to this token. Advantage: no need to change the = syntax. What do you think about this approach? >=20 > That=E2=80=99s an interesting idea, and I can see the advantage of a = simpler syntax on the surface =E2=80=A6 but at first shake I see a = couple problems with it. First, this presumes you=E2=80=99d always be = sending a full resource object. If you=E2=80=99re sending a scope string = (or a resource handle in XYZ terms), then you don=E2=80=99t have = anywhere to put the name of the token since it=E2=80=99s no longer an = object. That=E2=80=99s certainly true.=20 > Second, there=E2=80=99s no clear way to combine multiple resource = facets into a single token. Why, just use the same label. > And third, you now have to handle a whole bunch of new error cases: = what if some of the resource request objects have names, and others = don=E2=80=99t? What if you use the same name on multiple resource = request objects? If that means you combine them into a single token, = you=E2=80=99re back at the question above about audience restrictions. You need to solve that anyway. I feel my proposal above is more = suitable.=20 > And finally, it changes the semantics of the resource object in a way = that a simple client would have to at least know about, and be able to = deal with the AS=E2=80=99s different error conditions. >=20 > Your thoughts on these points? I might be missing something obvious = with what you=E2=80=99re suggesting. I=E2=80=99m still struggling to understand why a client should ask for a = certain assignment of resources. I think it=E2=80=99s basically the AS = in enforcing a certain security policy. The client (on top of that) = might ask for less powerful access tokens within the boundaries defined = by the AS.=20 >=20 > Thanks for the feedback! Happy to do so. It=E2=80=99s an important topic waiting for an = interoperable solution. I think we need to introduce a clear indication = of boundaries between resource servers (or security domains or whatever = you want to call it) in oder to solve that.=20 best regards, Torsten.=20 >=20 > =E2=80=94 Justin >=20 >>=20 >> best regards, >> Torsten. >>=20 >>> Am 13.03.2020 um 23:13 schrieb Justin Richer : >>>=20 >>> =EF=BB=BFI took some time to implement an idea that was tossed out = on the list here recently, and that=E2=80=99s how we might support = requests and responses for multiple access tokens. I=E2=80=99ve got a = method that I think works pretty well without getting in the way of the = common, simple case of requesting a single access token. I=E2=80=99ve = implemented this in our Java implementation of XYZ and I=E2=80=99ve = updated the https://oauth.xyz/ website with more details. I=E2=80=99ll = update my ID spec text when I get a chance to reflect this, but I wanted = to start this discussion first. Everything in here is based on the XYZ = protocol. >>>=20 >>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is = an array of items: >>>=20 >>> resources: [ >>> { >>> actions: ["read", "write", "dolphin"], >>> locations: ["https://server.example.net/", = "https://resource.local/other"], >>> datatypes: ["metadata", "images"] >>> }, >>> { >>> actions: ["foo", "bar", "dolphin"], >>> locations: ["https://resource.other/"], >>> datatypes: ["data", "pictures"] >>> } >>> ] >>>=20 >>> This tells the AS that the client is asking for a single access = token with multiple, perhaps orthogonal sets of access. This is in = parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this. >>>=20 >>> resources: { >>> token1: [{ >>> actions: ["read", "write", "dolphin"], >>> locations: ["https://server.example.net/", = "https://resource.local/other"], >>> datatypes: ["metadata", "images"] >>> }], >>> token2: [{ >>> actions: ["foo", "bar", "dolphin"], >>> locations: ["https://resource.other/"], >>> datatypes: ["data", "pictures"] >>> }] >>> } >>>=20 >>> The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this: >>>=20 >>> { >>> access_token: { >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>> type: "bearer" >>> } >>> } >>>=20 >>> Or multiple access tokens in a tx response like this: >>>=20 >>> { >>> multiple_access_tokens: { >>> token1: { >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>> type: "bearer" >>> }, >>> token2: { >>> value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >>> type: "bearer" >>> } >>> } >>> } >>>=20 >>> These fields are mutually exclusive, so you either get a single = unnamed token or a set of named tokens. Since the client pics the labels = for the access tokens, it=E2=80=99s clear which part of the request maps = to which part of the response. It=E2=80=99s more complexity for the = client to track, but that complexity is only seen and borne by clients = that need it. Simple clients get to stay simple while letting a complex = problem get solved.=20 >>>=20 >>> A note about the polymorphic JSON that=E2=80=99s in user here, = though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. = For those unfamiliar with the concept, this is when a given field can = have a value that takes multiple different types: a string, a boolean, = an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2. >>>=20 >>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ] >>>=20 >>> Polymorphic JSON is great for things like this because it means you = don=E2=80=99t have to have multiple fields and normative rules for = mutual exclusivity, like we=E2=80=99d have to have otherwise. The type = switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it. >>>=20 >>>=20 >>>=20 >>> People have been asking for a good way to do multiple access tokens = with OAuth for years, but we=E2=80=99ve never had a good or clean way to = pull it off because of OAuth=E2=80=99s model and the assumptions that it = makes. I think TxAuth gives us the opportunity to solve this in a way = that=E2=80=99s consistent with the rest of the protocol, and do so in a = way that doesn=E2=80=99t make the simple cases we know and love too = complicated for average developers. >>>=20 >>> =E2=80=94 Justin >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >=20 From nobody Sat Mar 14 13:15:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735233A0CB2 for ; Sat, 14 Mar 2020 13:15:41 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 B8Jcf9JiV6RV for ; Sat, 14 Mar 2020 13:15:32 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.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 7656D3A0CA3 for ; Sat, 14 Mar 2020 13:15:27 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id DDBtjOeiVcUOqDDBujC853; Sat, 14 Mar 2020 13:15:26 -0700 X-CMAE-Analysis: v=2.3 cv=E/WzWpVl c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=dMtw9-6b0fwnA8krZxEA:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 X-SECURESERVER-ACCT: vladimir@connect2id.com To: txauth@ietf.org References: <6750F9C8-425E-45B1-BCE8-52674F7BCDC5@mit.edu> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Sat, 14 Mar 2020 22:15:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <6750F9C8-425E-45B1-BCE8-52674F7BCDC5@mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080902020500050606050307" X-CMAE-Envelope: MS4wfFkCy5Vfo/y9Xy3pmwNVDPajVeA/BnBTwSV8YEkoa8CZqgDbHlJI8zihAqfh7k6nTvJKQQrSMdOtKQWpH7DLazhgKCC2f3jFy5JIQqL+VzXt7mqbUY5r FC9nO2/zfzJwVQIT3krqqrG+Du+44j8nnVpB2J3Wop7hRY2wkDgxrKLq Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 20:15:42 -0000 This is a cryptographically signed message in MIME format. --------------ms080902020500050606050307 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US +1 for the multiple access tokens. The user experience of apps which need to deal with multiple resources can significantly benefit from this. If the JSON syntax is intuitive and concise that would be really nice. The polymorphic JSON and how can be handled in languages like Java doesn't worry me at all. Vladimir --------------ms080902020500050606050307 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMTQyMDE1MjVaMC8G CSqGSIb3DQEJBDEiBCC8NB3GG29oAGSXCqhdTYwbF+wKpwHPrdRI5oy/h60hujBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAGaBxgSw+EcGhDUCMKdVU/t6/ZRyrtDoC61qlHsWCue1t8pN 1FAk1a9Waye3WU689bP3+Wi4MHDP/aKl7+K3ly7F8k8HV+yM5LAaghFHoHCnJuKZKDj7XBNx bBftDk7FsGJnMnzSPdgZNH2taDMrfBFWK5LNJ7NUXCRsngaPpKkgerIEuS34uxWOfx9Tvj1+ bR/6bwvJlSHStJVqOTyu63MfWOtQ0/slOzye4ovlQAGqgHCU3y5pFdaqiH6FCqQtes/TfAMn Xv4wNEWUJ0WylyN/JYXyTNd17J70J3gJ2otFFSnP4T3xUzvA6s4938M1I5XDoXianaYcxJBz t5d2ZzAAAAAAAAA= --------------ms080902020500050606050307-- From nobody Sat Mar 14 14:56:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0293A0EBD for ; Sat, 14 Mar 2020 14:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, PDS_OTHER_BAD_TLD=1.998, 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 ZC75o5EyPtAC for ; Sat, 14 Mar 2020 14:56:53 -0700 (PDT) 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 558A63A0EBB for ; Sat, 14 Mar 2020 14:56:53 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id i24so13100747eds.1 for ; Sat, 14 Mar 2020 14:56:53 -0700 (PDT) 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=8VHtck/RP1dy0Rc5h+p/LCs+ri+pUSrvuVQKxDBETa4=; b=FgmZIWxENyLQGxV0aoxoel44jHnpGqnPEepy2/01/tKXjKcVAs5208zyDgMPR6/b9G 224g7jdXMRsaFm7s/fcKaYPOnprBaE/hRtRMAv+hwjtqNGgQziLJ/AQtDSUn7HulbcQS 5Nf00ORR69gvZJVP0LkP2uoGIO3u1BrwtpKdMSwd8VgdE4nkijqf0gb+7E3vnkznl2uS VYRiFolXy60d2GI0ok1voI/OQo/dJlZVi+VJApE50851u3C1a+GcyzxWvpzXTOzW4avc 94Z5ra/CSxRWc7xkhKy8TY65rbIBmkmPdnZSFsiagFALabkhmCNYCVZ4TtbAVmb8NJ0n BCAQ== 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=8VHtck/RP1dy0Rc5h+p/LCs+ri+pUSrvuVQKxDBETa4=; b=So6bF9rbKVtoj7NnQz33izzJNMICVU1a4JURp+ePXPstcgiQuGlJMu9TGGvdPv3HZt TKXUHQskn10d1yodT+Ci9Dbxpj18bphmhKQDs+64ABu7jX4KGRtANkwlTq+EMmuJenrM PgJtQSRcVlGps+9pxGUof+1V31DIMfYvBZf+Le8F4nIq3KiC47tWAO8yRL3EUkqPyEoa QI0O6vWB5g7jOTwlR29K3pYjMlQKh6NqaPAOg7xUWZgrwE00lg0yOq2uJH5DBebQ4ngA DjShD+cdvRU4ApVPzdlrM/dfbxfTrGqpkWlkAHOMWCJoRy2HRc+hvTNriOz/pzzterE/ GmIA== X-Gm-Message-State: ANhLgQ1ZtbUlpyFk49nez47qlYsrGC5357JldcEgHVUBTVLBHs3pN8BD ShnQTnWiDcedwRQOvVtV7+g/VocVKwrjwoltKPBTmEsOOo8= X-Google-Smtp-Source: ADFU+vujCVHYo0U/ErwEW7ZXmPp/zE5zLdULt1xQ256oBGUmFbha4nVOQ+E5ZyFvqMYtOjt8eALsGBh7yaRwKoEq00A= X-Received: by 2002:a50:eb01:: with SMTP id y1mr115291edp.82.1584223011512; Sat, 14 Mar 2020 14:56:51 -0700 (PDT) MIME-Version: 1.0 References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> In-Reply-To: <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> From: David Skaife Date: Sat, 14 Mar 2020 21:56:40 +0000 Message-ID: To: Torsten Lodderstedt , Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8a70d05a0d7a98e" Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 21:56:57 -0000 --000000000000d8a70d05a0d7a98e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This is an interesting idea, and one which I think would be a useful addition to the protocol. As you've mentioned, it will be incredibly important to define it in a way that enables the simpler use cases to remain simple, and not be complicated by this additional optional feature. With regards to Torsten's question: "*What would be the client=E2=80=99s mo= tivation to split resources to different access tokens?*" I'm involved in the implementation of Open Banking within the United Kingdom and I can certainly think of scenarios in Open Banking where the client app would be able to provide a better user experience if they could offer the ability to revoke permissions at a fine-grained level, rather than the user having to revoke "all or nothing". For example, if a user has provided a third-party provider with access to their current account balance, account name, and account transactions, at a later point they may want to revoke third-party provider access to their transactions but keep the other permissions active - enabling the client app to split the resources to between different access tokens would provide that ability. Related to the above example, within the context of Open Banking in the UK, we also have the scenario where a user is able to select which of their bank accounts they want to be included within the scope of an authorisation at the point when the user is interacting directly with the Authorization Server (i.e. after the client has already sent the initial back-channel request to the AS containing details of the requested resources, and with this new feature we're discussing here, the details of the access token split) - it would be very desirable (for similar reasons to above example) to have one access token per bank account rather than one access token covering all of their bank accounts, to enable the user to revoke access to each account individually. This might be out of scope of this particular discussion, but within the context of XYZ and within the context of this multiple access token proposal, would there be any way to assign different access tokens to elements of the authorisation that are selected by the user AFTER the initial back-channel request between the client and the AS? One final question from me on this: I'm assuming that it would be optional for Authorization Servers to support multiple access tokens and so what would be the mechanism for the client to determine if the AS supports it, and what would be the response back if a client tries to utilise a feature such as this that the AS doesn't support? Many Thanks, David Skaife On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt wrote: > Hi Justin, > > > On 14. Mar 2020, at 14:07, Justin Richer wrote: > > > > On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> > >> =EF=BB=BF > >> Hi Justin, > >> > >> I have always been a fan of multiple access tokens support :-) So > thanks you for bringing this forward. > > > > Yes! It=E2=80=99s only taken us another 10 years to get back here again= . :) > > > > yep. Just an example ;-): > https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/ > > >> > >> Some questions: > >> > >> Do you assume the client can freely allocated resources to access > tokens? How would that work with audience-restricted/specific access toke= ns? > > > > In the syntax I=E2=80=99m proposing, the client can take any set of res= ources > and ask for it to go with one token. Basically, each named element of the > resources object in the multi-token request syntax is exactly the same as= a > single token request would be, an array of resource requests. So yes, the > client can mix and match as it sees fit, and the AS can reject a request > for combining two different audiences in the same token. The AS would nee= d > to do that anyway for a single token request, so I don=E2=80=99t see that= as a > greater burden =E2=80=94 it=E2=80=99s just that now the client can fulfil= l the requirements > without making multiple transaction requests. > > What would be the client=E2=80=99s motivation to split resources to diffe= rent > access tokens? > What information would the client use to allocate the resources to the > appropriate access tokens? > > In my experience, it is the AS (or the security policy of the deployment) > that determines what can go into a single access token. > > One policy is to allow everything to go into a single access token. That > might work in a single RS deployment. In a multi RS deployment, one would > either end up with tokens containing the set union of all data needed by > all RSs. Encryptions of those tokens might be complex, I don=E2=80=99t kn= ow whether > this is privacy preserving. The other option is to use token introspectio= n > or other callbacks to the AS to obtain the real data needed for access > control per RS, not very performant. > > Another possible policy is to have access tokens that at most contain dat= a > for a certain resource server. This helps privacy (no implicit data shari= ng > among resource servers) and security (single audience, encryption is > straightforward, simple token replay prevention). But someone needs to kn= ow > the boundaries. > > If the client knows the boundaries, all it would need to ask the AS for i= s > to issue access tokens for a set of recipients. This could be done in > parallel to the resources structure. > > Something like this: > > { > "resources":[ > { > "actions":[ > "read", > "write", > "dolphin" > ], > "locations":[ > "https://server.example.net/", > "https://resource.local/other" > ], > "datatypes":[ > "metadata", > "images" > ] > }, > { > "actions":[ > "read" > ], > "locations":[ > "https://server1.example.net/" > ], > "datatypes":[ > "contacts" > ] > } > ], > "tokens":[ > "https://server.example.net/", > "https://server1.example.net/" > ] > } > > The default could be that the AS issues an access token good for all > granted resources. > > One could also go one step further and let the AS decide what access > tokens it would issue and add metadata about the recipients to the > response. > > { > "access_tokens":[ > { > "destination":"https://server.example.net/"", > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type":"bearer" > }, > { > "destination":"https://server1.example.net/", > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1", > "type":"bearer" > } > ], > "handle":{ > "value":"80UPRY5NM33OMUKMKSKU", > "type":"bearer" > }, > "claims":{ > "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6", > "email":"alice@example.com" > } > } > > I personally think this would even better fit the transactional character > of the new protocol. > > > > > This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to a= client=E2=80=99s > simple request, but I actually like that feature. If the client is capabl= e > of dealing with multiple tokens simultaneously, it can ask for them. > > I think that=E2=80=99s the important aspect! In my opinion, the AS basica= lly > decides whether different tokens are required for different resources. I > therefore think all client must be prepared to use different tokens to us= e > the privileges granted in a certain transaction (in the same way OAuth 2 > clients must be prepared for refresh tokens rotation). Whether the client > asks for more all or just a specific token (to start with), is a differen= t > question. > > > The single token case turns into a single unnamed access token with the > same semantics. > > > > >> > >> I think a further element =E2=80=9Etoken=E2=80=9C element within the r= esource structure > could also be used to denote the assignment of a certain resource object = to > this token. Advantage: no need to change the syntax. What do you think > about this approach? > > > > That=E2=80=99s an interesting idea, and I can see the advantage of a si= mpler > syntax on the surface =E2=80=A6 but at first shake I see a couple problem= s with it. > First, this presumes you=E2=80=99d always be sending a full resource obje= ct. If > you=E2=80=99re sending a scope string (or a resource handle in XYZ terms)= , then you > don=E2=80=99t have anywhere to put the name of the token since it=E2=80= =99s no longer an > object. > > That=E2=80=99s certainly true. > > > Second, there=E2=80=99s no clear way to combine multiple resource facet= s into a > single token. > > Why, just use the same label. > > > And third, you now have to handle a whole bunch of new error cases: wha= t > if some of the resource request objects have names, and others don=E2=80= =99t? What > if you use the same name on multiple resource request objects? If that > means you combine them into a single token, you=E2=80=99re back at the qu= estion > above about audience restrictions. > > You need to solve that anyway. I feel my proposal above is more suitable. > > > And finally, it changes the semantics of the resource object in a way > that a simple client would have to at least know about, and be able to de= al > with the AS=E2=80=99s different error conditions. > > > > Your thoughts on these points? I might be missing something obvious wit= h > what you=E2=80=99re suggesting. > > I=E2=80=99m still struggling to understand why a client should ask for a = certain > assignment of resources. I think it=E2=80=99s basically the AS in enforci= ng a > certain security policy. The client (on top of that) might ask for less > powerful access tokens within the boundaries defined by the AS. > > > > > Thanks for the feedback! > > Happy to do so. It=E2=80=99s an important topic waiting for an interopera= ble > solution. I think we need to introduce a clear indication of boundaries > between resource servers (or security domains or whatever you want to cal= l > it) in oder to solve that. > > best regards, > Torsten. > > > > > =E2=80=94 Justin > > > >> > >> best regards, > >> Torsten. > >> > >>> Am 13.03.2020 um 23:13 schrieb Justin Richer : > >>> > >>> =EF=BB=BFI took some time to implement an idea that was tossed out on= the list > here recently, and that=E2=80=99s how we might support requests and respo= nses for > multiple access tokens. I=E2=80=99ve got a method that I think works pret= ty well > without getting in the way of the common, simple case of requesting a > single access token. I=E2=80=99ve implemented this in our Java implementa= tion of > XYZ and I=E2=80=99ve updated the https://oauth.xyz/ website with more det= ails. > I=E2=80=99ll update my ID spec text when I get a chance to reflect this, = but I > wanted to start this discussion first. Everything in here is based on the > XYZ protocol. > >>> > >>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is = an array of items: > >>> > >>> resources: [ > >>> { > >>> actions: ["read", "write", "dolphin"], > >>> locations: ["https://server.example.net/", " > https://resource.local/other"], > >>> datatypes: ["metadata", "images"] > >>> }, > >>> { > >>> actions: ["foo", "bar", "dolphin"], > >>> locations: ["https://resource.other/"], > >>> datatypes: ["data", "pictures"] > >>> } > >>> ] > >>> > >>> This tells the AS that the client is asking for a single access token > with multiple, perhaps orthogonal sets of access. This is in parallel to > RAR being developed in OAuth 2. However, if we allow the =E2=80=9Cresourc= es=E2=80=9D item > to be an object instead of an array, we can let the client signal to the = AS > that it wants multiple access tokens. The client picks =E2=80=9Clabels=E2= =80=9D for these > access tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2= =E2=80=9D, and sends a request like > this. > >>> > >>> resources: { > >>> token1: [{ > >>> actions: ["read", "write", "dolphin"], > >>> locations: ["https://server.example.net/", " > https://resource.local/other"], > >>> datatypes: ["metadata", "images"] > >>> }], > >>> token2: [{ > >>> actions: ["foo", "bar", "dolphin"], > >>> locations: ["https://resource.other/"], > >>> datatypes: ["data", "pictures"] > >>> }] > >>> } > >>> > >>> The client could request multiple kinds of access within each > sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D and= =E2=80=9Ctoken2=E2=80=9D fields), but I > wanted to keep it simple here. This example is the same total set of > resources that the client is asking for in the first case, but here the > client=E2=80=99s saying it wants them as two different access tokens inst= ead of a > single one. The AS can tell the difference in the request because the fir= st > type is an array at the top and the second type is an object at the top. = So > that means that the AS can send back a single access token in a tx respon= se > like this: > >>> > >>> { > >>> access_token: { > >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >>> type: "bearer" > >>> } > >>> } > >>> > >>> Or multiple access tokens in a tx response like this: > >>> > >>> { > >>> multiple_access_tokens: { > >>> token1: { > >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >>> type: "bearer" > >>> }, > >>> token2: { > >>> value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > >>> type: "bearer" > >>> } > >>> } > >>> } > >>> > >>> These fields are mutually exclusive, so you either get a single > unnamed token or a set of named tokens. Since the client pics the labels > for the access tokens, it=E2=80=99s clear which part of the request maps = to which > part of the response. It=E2=80=99s more complexity for the client to trac= k, but > that complexity is only seen and borne by clients that need it. Simple > clients get to stay simple while letting a complex problem get solved. > >>> > >>> A note about the polymorphic JSON that=E2=80=99s in user here, though= it=E2=80=99s > already a key part of XYZ=E2=80=99s protocol design. For those unfamiliar= with the > concept, this is when a given field can have a value that takes multiple > different types: a string, a boolean, an object, an array, etc. This is > pretty simple to deal with in dynamically typed languages, you just check > the type of the resulting object and it will tell you what you=E2=80=99re= dealing > with. It=E2=80=99s trickier in statically typed languages, but I=E2=80=99= ve found that > pretty much every platform and library has hooks for custom serialization > and deserialization that will let you dispatch to different types during > the process, so you can still call your top-level parser and toString > methods and things will work as expected. This is one of the reasons that= I > did an implementation in Java, to prove that we could do this kind of thi= ng > in a strongly typed language that=E2=80=99s not very flexible about what = goes in > objects, and I=E2=80=99ve done it without resorting to generic collection= s for the > dynamic fields. Previously, I=E2=80=99ve used this feature in XYZ to allo= w a single > string to stand in as a reference for an object =E2=80=94 something XYZ c= alls > =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a client= _id, a scope, a > refresh token, and a few other items without having to create explicit > elements for these, since they always stand in for the object they replac= e > there=E2=80=99s no ambiguity. So for things like a resource request, each= of these > can be replaced by a string using resource handles and polymorphic JSON > (see note below) to act like a scope in OAuth2. > >>> > >>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfoobar-pi= ctures=E2=80=9D ] > >>> > >>> Polymorphic JSON is great for things like this because it means you > don=E2=80=99t have to have multiple fields and normative rules for mutual > exclusivity, like we=E2=80=99d have to have otherwise. The type switching= only > works when the base type is significantly different, though =E2=80=94 tha= t=E2=80=99s why I > have =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tokens= =E2=80=9D above, since both are > objects at the top level and you can=E2=80=99t cleanly switch at the pars= er level, > and you don=E2=80=99t want to have to dig down into the object to see wha= t to do > with it. > >>> > >>> > >>> > >>> People have been asking for a good way to do multiple access tokens > with OAuth for years, but we=E2=80=99ve never had a good or clean way to = pull it > off because of OAuth=E2=80=99s model and the assumptions that it makes. I= think > TxAuth gives us the opportunity to solve this in a way that=E2=80=99s con= sistent > with the rest of the protocol, and do so in a way that doesn=E2=80=99t ma= ke the > simple cases we know and love too complicated for average developers. > >>> > >>> =E2=80=94 Justin > >>> > >>> -- > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d8a70d05a0d7a98e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This is an interesting idea, = and one which I think would be a useful addition to the protocol. As you= 9;ve mentioned, it will be incredibly important to define it in a way that = enables the simpler use cases to remain simple, and not be complicated by t= his additional optional feature.

With regards to Torsten= 's question: "What would be the client=E2=80=99s motivation to = split resources to different access tokens?"
I'm involved i= n the implementation of Open Banking within the United Kingdom and I can ce= rtainly think of scenarios in Open Banking where the client app would be ab= le to provide a better user experience if they could offer the ability to r= evoke permissions at a fine-grained level, rather than the user having to r= evoke "all or nothing". For example, if a user has provided a thi= rd-party provider with access to their current account balance, account nam= e, and account transactions, at a later point they may want to revoke third= -party provider access to their transactions but keep the other permissions= active - enabling the client app to split the resources to between differe= nt access tokens would provide that ability.

Related to t= he above example, within the context of Open Banking in the UK, we also hav= e the scenario where a user is able to select which of their bank accounts = they want to be included within the scope of an authorisation at the point = when the user is interacting directly with the Authorization Server (i.e. a= fter the client has already sent the initial back-channel request to the AS= containing details of the requested resources, and with this new feature w= e're discussing here, the details of the access token split) - it would= be very desirable (for similar reasons to above example) to have one acces= s token per bank account rather than one access token covering all of their= bank accounts, to enable the user to revoke access to each account individ= ually. This might be out of scope of this particular discussion, but within= the context of XYZ and within the context of this multiple access token pr= oposal, would there be any way to assign different access tokens to element= s of the authorisation that are selected by the user AFTER the initial back= -channel request between the client and the AS?

One final question f= rom me on this: I'm assuming that it would be optional for Authorizatio= n Servers to support multiple access tokens and so what would be the mechan= ism for the client to determine if the AS supports it, and what would be th= e response back if a client tries to utilise a feature such as this that th= e AS doesn't support?

Many Thanks,
David Skaife
On Sat, = Mar 14, 2020 at 4:33 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org>= wrote:
Hi Justi= n,

> On 14. Mar 2020, at 14:07, Justin Richer <jricher@mit.edu> wrote:
>
> On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt <torsten@lodderstedt.net>= wrote:
>>
>> =EF=BB=BF
>> Hi Justin,
>>
>> I have always been a fan of multiple access tokens support :-) So = thanks you for bringing this forward.
>
> Yes! It=E2=80=99s only taken us another 10 years to get back here agai= n. :)
>

yep. Just an example ;-): ht= tps://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/<= br>
>>
>> Some questions:
>>
>> Do you assume the client can freely allocated resources to access = tokens? How would that work with audience-restricted/specific access tokens= ?
>
> In the syntax I=E2=80=99m proposing, the client can take any set of re= sources and ask for it to go with one token. Basically, each named element = of the resources object in the multi-token request syntax is exactly the sa= me as a single token request would be, an array of resource requests. So ye= s, the client can mix and match as it sees fit, and the AS can reject a req= uest for combining two different audiences in the same token. The AS would = need to do that anyway for a single token request, so I don=E2=80=99t see t= hat as a greater burden =E2=80=94 it=E2=80=99s just that now the client can= fulfill the requirements without making multiple transaction requests.
What would be the client=E2=80=99s motivation to split resources to differe= nt access tokens?
What information would the client use to allocate the resources to the appr= opriate access tokens?

In my experience, it is the AS (or the security policy of the deployment) t= hat determines what can go into a single access token.

One policy is to allow everything to go into a single access token. That mi= ght work in a single RS deployment. In a multi RS deployment, one would eit= her end up with tokens containing the set union of all data needed by all R= Ss. Encryptions of those tokens might be complex, I don=E2=80=99t know whet= her this is privacy preserving. The other option is to use token introspect= ion or other callbacks to the AS to obtain the real data needed for access = control per RS, not very performant.

Another possible policy is to have access tokens that at most contain data = for a certain resource server. This helps privacy (no implicit data sharing= among resource servers) and security (single audience, encryption is strai= ghtforward, simple token replay prevention). But someone needs to know the = boundaries.

If the client knows the boundaries, all it would need to ask the AS for is = to issue access tokens for a set of recipients. This could be done in paral= lel to the resources structure.

Something like this:

{
=C2=A0 =C2=A0"resources":[
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"actions":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "write",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "dolphin"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"locations":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://server.example.ne= t/",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://resource.local/o= ther"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"datatypes":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "metadata",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "images"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"actions":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"locations":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://server1.example.= net/"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"datatypes":[
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contacts"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0],
=C2=A0 =C2=A0"tokens":[
=C2=A0 =C2=A0 =C2=A0 "https://server.example.net/",
=C2=A0 =C2=A0 =C2=A0 "https://server1.example.net/"
=C2=A0 =C2=A0]
}

The default could be that the AS issues an access token good for all grante= d resources.

One could also go one step further and let the AS decide what access tokens= it would issue and add metadata about the recipients to the response.

{
=C2=A0 =C2=A0"access_tokens":[
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"destination":"https://s= erver.example.net/"",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value":"OS9M2PMHKUR64TB8N= 6BW7OZB8CDFONP219RP1LT0",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type":"bearer"
=C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"destination":"https://= server1.example.net/",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value":"OS9M2PMHKUR64TB8N= 6BW7OZB8CDFONP219RP1LT1",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"type":"bearer"
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0],
=C2=A0 =C2=A0"handle":{
=C2=A0 =C2=A0 =C2=A0 "value":"80UPRY5NM33OMUKMKSKU", =C2=A0 =C2=A0 =C2=A0 "type":"bearer"
=C2=A0 =C2=A0},
=C2=A0 =C2=A0"claims":{
=C2=A0 =C2=A0 =C2=A0 "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR= 6",
=C2=A0 =C2=A0 =C2=A0 "email":"alice@example.com"
=C2=A0 =C2=A0}
}

I personally think this would even better fit the transactional character o= f the new protocol.

>
> This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to = a client=E2=80=99s simple request, but I actually like that feature. If the= client is capable of dealing with multiple tokens simultaneously, it can a= sk for them.

I think that=E2=80=99s the important aspect! In my opinion, the AS basicall= y decides whether different tokens are required for different resources. I = therefore think all client must be prepared to use different tokens to use = the privileges granted in a certain transaction (in the same way OAuth 2 cl= ients must be prepared for refresh tokens rotation). Whether the client ask= s for more all or just a specific token (to start with), is a different que= stion.

> The single token case turns into a single unnamed access token with th= e same semantics.

>
>>
>> I think a further element =E2=80=9Etoken=E2=80=9C element within t= he resource structure could also be used to denote the assignment of a cert= ain resource object to this token. Advantage: no need to change the syntax.= What do you think about this approach?
>
> That=E2=80=99s an interesting idea, and I can see the advantage of a s= impler syntax on the surface =E2=80=A6 but at first shake I see a couple pr= oblems with it. First, this presumes you=E2=80=99d always be sending a full= resource object. If you=E2=80=99re sending a scope string (or a resource h= andle in XYZ terms), then you don=E2=80=99t have anywhere to put the name o= f the token since it=E2=80=99s no longer an object.

That=E2=80=99s certainly true.

> Second, there=E2=80=99s no clear way to combine multiple resource face= ts into a single token.

Why, just use the same label.

> And third, you now have to handle a whole bunch of new error cases: wh= at if some of the resource request objects have names, and others don=E2=80= =99t? What if you use the same name on multiple resource request objects? I= f that means you combine them into a single token, you=E2=80=99re back at t= he question above about audience restrictions.

You need to solve that anyway. I feel my proposal above is more suitable. <= br>
> And finally, it changes the semantics of the resource object in a way = that a simple client would have to at least know about, and be able to deal= with the AS=E2=80=99s different error conditions.
>
> Your thoughts on these points? I might be missing something obvious wi= th what you=E2=80=99re suggesting.

I=E2=80=99m still struggling to understand why a client should ask for a ce= rtain assignment of resources. I think it=E2=80=99s basically the AS in enf= orcing a certain security policy. The client (on top of that) might ask for= less powerful access tokens within the boundaries defined by the AS.

>
> Thanks for the feedback!

Happy to do so. It=E2=80=99s an important topic waiting for an interoperabl= e solution. I think we need to introduce a clear indication of boundaries b= etween resource servers (or security domains or whatever you want to call i= t) in oder to solve that.

best regards,
Torsten.

>
>=C2=A0 =E2=80=94 Justin
>
>>
>> best regards,
>> Torsten.
>>
>>> Am 13.03.2020 um 23:13 schrieb Justin Richer <jricher@mit.edu>:
>>>
>>> =EF=BB=BFI took some time to implement an idea that was tossed= out on the list here recently, and that=E2=80=99s how we might support req= uests and responses for multiple access tokens. I=E2=80=99ve got a method t= hat I think works pretty well without getting in the way of the common, sim= ple case of requesting a single access token. I=E2=80=99ve implemented this= in our Java implementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/= website with more details. I=E2=80=99ll update my ID spec text when I = get a chance to reflect this, but I wanted to start this discussion first. = Everything in here is based on the XYZ protocol.
>>>
>>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx requ= est is an array of items:
>>>
>>> resources: [
>>>=C2=A0 =C2=A0 =C2=A0{
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actions: ["= ;read", "write", "dolphin"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0locations: [&qu= ot;https://server.example.net/", "https://resource.local= /other"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datatypes: [&qu= ot;metadata", "images"]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>>>=C2=A0 =C2=A0 =C2=A0{
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actions: ["= ;foo", "bar", "dolphin"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0locations: [&qu= ot;https://resource.other/"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datatypes: [&qu= ot;data", "pictures"]
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>> ]
>>>
>>> This tells the AS that the client is asking for a single acces= s token with multiple, perhaps orthogonal sets of access. This is in parall= el to RAR being developed in OAuth 2. However, if we allow the =E2=80=9Cres= ources=E2=80=9D item to be an object instead of an array, we can let the cl= ient signal to the AS that it wants multiple access tokens. The client pick= s =E2=80=9Clabels=E2=80=9D for these access tokens, in this case =E2=80=9Ct= oken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D, and sends a request like this.=
>>>
>>> resources: {
>>>=C2=A0 =C2=A0 =C2=A0token1: [{
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actions: ["= ;read", "write", "dolphin"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0locations: [&qu= ot;https://server.example.net/", "https://resource.local= /other"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datatypes: [&qu= ot;metadata", "images"]
>>>=C2=A0 =C2=A0 =C2=A0 }],
>>>=C2=A0 =C2=A0 =C2=A0 token2: [{
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actions: ["= ;foo", "bar", "dolphin"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0locations: [&qu= ot;https://resource.other/"],
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datatypes: [&qu= ot;data", "pictures"]
>>>=C2=A0 =C2=A0 =C2=A0 }]
>>> }
>>>
>>> The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D and = =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple here. This= example is the same total set of resources that the client is asking for i= n the first case, but here the client=E2=80=99s saying it wants them as two= different access tokens instead of a single one. The AS can tell the diffe= rence in the request because the first type is an array at the top and the = second type is an object at the top. So that means that the AS can send bac= k a single access token in a tx response like this:
>>>
>>> {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access_token: {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value: "OS= 9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type: "bea= rer"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>> }
>>>
>>> Or multiple access tokens in a tx response like this:
>>>
>>> {
>>>=C2=A0 =C2=A0 =C2=A0multiple_access_tokens: {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token1: {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value: "OS= 9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type: "bea= rer"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token2: {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value: "UF= GLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type: "bea= rer"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>>=C2=A0 =C2=A0 =C2=A0}
>>> }
>>>
>>> These fields are mutually exclusive, so you either get a singl= e unnamed token or a set of named tokens. Since the client pics the labels = for the access tokens, it=E2=80=99s clear which part of the request maps to= which part of the response. It=E2=80=99s more complexity for the client to= track, but that complexity is only seen and borne by clients that need it.= Simple clients get to stay simple while letting a complex problem get solv= ed.
>>>
>>> A note about the polymorphic JSON that=E2=80=99s in user here,= though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. F= or those unfamiliar with the concept, this is when a given field can have a= value that takes multiple different types: a string, a boolean, an object,= an array, etc. This is pretty simple to deal with in dynamically typed lan= guages, you just check the type of the resulting object and it will tell yo= u what you=E2=80=99re dealing with. It=E2=80=99s trickier in statically typ= ed languages, but I=E2=80=99ve found that pretty much every platform and li= brary has hooks for custom serialization and deserialization that will let = you dispatch to different types during the process, so you can still call y= our top-level parser and toString methods and things will work as expected.= This is one of the reasons that I did an implementation in Java, to prove = that we could do this kind of thing in a strongly typed language that=E2=80= =99s not very flexible about what goes in objects, and I=E2=80=99ve done it= without resorting to generic collections for the dynamic fields. Previousl= y, I=E2=80=99ve used this feature in XYZ to allow a single string to stand = in as a reference for an object =E2=80=94 something XYZ calls =E2=80=9Chand= les=E2=80=9D. These let you have constructs akin to a client_id, a scope, a= refresh token, and a few other items without having to create explicit ele= ments for these, since they always stand in for the object they replace the= re=E2=80=99s no ambiguity. So for things like a resource request, each of t= hese can be replaced by a string using resource handles and polymorphic JSO= N (see note below) to act like a scope in OAuth2.
>>>
>>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfo= obar-pictures=E2=80=9D ]
>>>
>>> Polymorphic JSON is great for things like this because it mean= s you don=E2=80=99t have to have multiple fields and normative rules for mu= tual exclusivity, like we=E2=80=99d have to have otherwise. The type switch= ing only works when the base type is significantly different, though =E2=80= =94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cm= ultiple_access_tokens=E2=80=9D above, since both are objects at the top lev= el and you can=E2=80=99t cleanly switch at the parser level, and you don=E2= =80=99t want to have to dig down into the object to see what to do with it.=
>>>
>>>
>>>
>>> People have been asking for a good way to do multiple access t= okens with OAuth for years, but we=E2=80=99ve never had a good or clean way= to pull it off because of OAuth=E2=80=99s model and the assumptions that i= t makes. I think TxAuth gives us the opportunity to solve this in a way tha= t=E2=80=99s consistent with the rest of the protocol, and do so in a way th= at doesn=E2=80=99t make the simple cases we know and love too complicated f= or average developers.
>>>
>>>=C2=A0 =E2=80=94 Justin
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/txa= uth
>

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d8a70d05a0d7a98e-- From nobody Sat Mar 14 15:17:48 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA2F3A0F16 for ; Sat, 14 Mar 2020 15:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_OTHER_BAD_TLD=1.998, 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=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 25NEGq5LcZSE for ; Sat, 14 Mar 2020 15:17:42 -0700 (PDT) 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 D33F83A0F14 for ; Sat, 14 Mar 2020 15:17:41 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id n8so13660669wmc.4 for ; Sat, 14 Mar 2020 15:17:41 -0700 (PDT) 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=CAvHgRnU+gdhrEk5OtqgPYyZKd77l3B1gOUT7sFaGOQ=; b=WjT3Hr3tjEZYkL4vWwmF6d8Ru4216kXLbY/vJu99RbpZdjnNcQKc7ShkEXaQqpn92G HT6vThXbZJoXDljZFCL9TVIDugCY9KdqFAI0ZcOVRSue6lSBgNZYI+h9vrH538oZ+i0g VarA+tt59oc4UgKtlC2eA7gRszbEwik6LXR9N0r3Zwa8zY3VywFaTPVkx4DIsHiTikvp MxbPF3Gna+XPhUtcWWBfOT/Z3XIopBimkDE60q/a6zdq29kxmGBNeQUTEAJqb1fi7GuQ dpxJR4nJg/BmX1rV5T8Gnt8pAQnSbLqeyJDrmfKrmLxNK4kZResxrTHiytTnYHTagB4n 04Gg== 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=CAvHgRnU+gdhrEk5OtqgPYyZKd77l3B1gOUT7sFaGOQ=; b=tPhSO+9J3NbXP3j+OwrEaqI7Ytpsw5Q0+/cHI//Klrz0Tpu5PnhuM/67lfnBVnxh9O 08UoUmSpEYPgt6+jILiHY0ZoPtR2enb9l45Zb5d8FOfKRfZUs0OFX7I/5rPF3XbQ07I3 HFOlIZMd8/uynPRqcGPU2xspBco0d1pY+QTbUqqHjQAs6SnIZpD4k8OhP3QMvdfitlCP 1/52Vf/ZleOJtPEdL1hNQtzdI6Y/Iwccc3Qhb6CpcGMX+EZYwTD9qSpSR18ur64HOfJm eW1Mwtii6OT9ci9TyCcOkCP9IqB52w5XIHmB7tGkW77iPrmYoOXFv/DNZf+3v18stcZm DXDQ== X-Gm-Message-State: ANhLgQ3Pjw263XILW0zs0Yl0NS4b37buPmLVsB8ZzlWfFtOjcnZ3w+l9 U40RavDY+X0WVUjM1yIfUtaEsQ== X-Google-Smtp-Source: ADFU+vsTpyTCSYbz7HK12Gx7st1kYMkFsCAA8K+Tlyr8YfWtFU+dzRBRLOof3vqgANt5jdo8iWJnMQ== X-Received: by 2002:a1c:ab07:: with SMTP id u7mr17348516wme.23.1584224259897; Sat, 14 Mar 2020 15:17:39 -0700 (PDT) Received: from ?IPv6:2003:eb:8f26:25c2:7847:92e:234e:d2ea? (p200300EB8F2625C27847092E234ED2EA.dip0.t-ipconnect.de. [2003:eb:8f26:25c2:7847:92e:234e:d2ea]) by smtp.gmail.com with ESMTPSA id r9sm16044026wma.47.2020.03.14.15.17.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Mar 2020 15:17:39 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-E1549CE4-7B68-44E5-93A4-D03A4ADD6278; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 14 Mar 2020 23:17:37 +0100 Message-Id: References: Cc: Torsten Lodderstedt , Justin Richer , txauth@ietf.org In-Reply-To: To: David Skaife X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2020 22:17:46 -0000 --Apple-Mail-E1549CE4-7B68-44E5-93A4-D03A4ADD6278 Content-Type: multipart/alternative; boundary=Apple-Mail-FBF20ECE-CEEB-48B4-8DC0-E40CD0260B25 Content-Transfer-Encoding: 7bit --Apple-Mail-FBF20ECE-CEEB-48B4-8DC0-E40CD0260B25 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, > Am 14.03.2020 um 22:57 schrieb David Skaife : >=20 > =EF=BB=BF > Hi, >=20 > This is an interesting idea, and one which I think would be a useful addit= ion to the protocol. As you've mentioned, it will be incredibly important to= define it in a way that enables the simpler use cases to remain simple, and= not be complicated by this additional optional feature. >=20 > With regards to Torsten's question: "What would be the client=E2=80=99s mo= tivation to split resources to different access tokens?" > I'm involved in the implementation of Open Banking within the United Kingd= om and I can certainly think of scenarios in Open Banking where the client a= pp would be able to provide a better user experience if they could offer the= ability to revoke permissions at a fine-grained level, rather than the user= having to revoke "all or nothing". For example, if a user has provided a th= ird-party provider with access to their current account balance, account nam= e, and account transactions, at a later point they may want to revoke third-= party provider access to their transactions but keep the other permissions a= ctive - enabling the client app to split the resources to between different a= ccess tokens would provide that ability. I see the use case, but I would solve it differently by revoking the resourc= e object assigned to a certain transaction handle instead of the access toke= n. The token, in my mental model, is just the credential required to execute= certain privileges but not the privilege itself. >=20 > Related to the above example, within the context of Open Banking in the UK= , we also have the scenario where a user is able to select which of their ba= nk accounts they want to be included within the scope of an authorisation at= the point when the user is interacting directly with the Authorization Serv= er (i.e. after the client has already sent the initial back-channel request t= o the AS containing details of the requested resources, and with this new fe= ature we're discussing here, the details of the access token split) - it wou= ld be very desirable (for similar reasons to above example) to have one acce= ss token per bank account rather than one access token covering all of their= bank accounts, to enable the user to revoke access to each account individu= ally. This might be out of scope of this particular discussion, but within t= he context of XYZ and within the context of this multiple access token propo= sal, would there be any way to assign different access tokens to elements of= the authorisation that are selected by the user AFTER the initial back-chan= nel request between the client and the AS? I think this would require a selection over the resources assigned to a cert= ain transaction handle. Here it is getting rather tricky if a single resourc= e object contains all bank accounts. Sending another request to the AS with t= he transaction handle and a subset in the resource parameter that shall be a= ssigned to the access token should do the job. The AS should be able to dete= rmine that the privileges were already granted in this transaction, so no fu= rther user interaction required. > One final question from me on this: I'm assuming that it would be optional= for Authorization Servers to support multiple access tokens and so what wou= ld be the mechanism for the client to determine if the AS supports it, and w= hat would be the response back if a client tries to utilise a feature such a= s this that the AS doesn't support? I think the use cases you described require an assignment of a subset of res= ources to a token, not necessarily multiple access tokens. best regards, Torsten. >=20 > Many Thanks, > David Skaife >=20 >> On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt wrote: >> Hi Justin, >>=20 >> > On 14. Mar 2020, at 14:07, Justin Richer wrote: >> >=20 >> > On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt wrote: >> >>=20 >> >> =EF=BB=BF >> >> Hi Justin, >> >>=20 >> >> I have always been a fan of multiple access tokens support :-) So than= ks you for bringing this forward. >> >=20 >> > Yes! It=E2=80=99s only taken us another 10 years to get back here again= . :) >> >=20 >>=20 >> yep. Just an example ;-): https://mailarchive.ietf.org/arch/msg/oauth/JcK= GhoKy2S_2gAQ2ilMxCPWbgPw/ >>=20 >> >>=20 >> >> Some questions: >> >>=20 >> >> Do you assume the client can freely allocated resources to access toke= ns? How would that work with audience-restricted/specific access tokens? >> >=20 >> > In the syntax I=E2=80=99m proposing, the client can take any set of res= ources and ask for it to go with one token. Basically, each named element of= the resources object in the multi-token request syntax is exactly the same a= s a single token request would be, an array of resource requests. So yes, th= e client can mix and match as it sees fit, and the AS can reject a request f= or combining two different audiences in the same token. The AS would need to= do that anyway for a single token request, so I don=E2=80=99t see that as a= greater burden =E2=80=94 it=E2=80=99s just that now the client can fulfill t= he requirements without making multiple transaction requests.=20 >>=20 >> What would be the client=E2=80=99s motivation to split resources to diffe= rent access tokens?=20 >> What information would the client use to allocate the resources to the ap= propriate access tokens?=20 >>=20 >> In my experience, it is the AS (or the security policy of the deployment)= that determines what can go into a single access token.=20 >>=20 >> One policy is to allow everything to go into a single access token. That m= ight work in a single RS deployment. In a multi RS deployment, one would eit= her end up with tokens containing the set union of all data needed by all RS= s. Encryptions of those tokens might be complex, I don=E2=80=99t know whethe= r this is privacy preserving. The other option is to use token introspection= or other callbacks to the AS to obtain the real data needed for access cont= rol per RS, not very performant.=20 >>=20 >> Another possible policy is to have access tokens that at most contain dat= a for a certain resource server. This helps privacy (no implicit data sharin= g among resource servers) and security (single audience, encryption is strai= ghtforward, simple token replay prevention). But someone needs to know the b= oundaries.=20 >>=20 >> If the client knows the boundaries, all it would need to ask the AS for i= s to issue access tokens for a set of recipients. This could be done in para= llel to the resources structure. >>=20 >> Something like this:=20 >>=20 >> { >> "resources":[ >> { >> "actions":[ >> "read", >> "write", >> "dolphin" >> ], >> "locations":[ >> "https://server.example.net/", >> "https://resource.local/other" >> ], >> "datatypes":[ >> "metadata", >> "images" >> ] >> }, >> { >> "actions":[ >> "read" >> ], >> "locations":[ >> "https://server1.example.net/" >> ], >> "datatypes":[ >> "contacts" >> ] >> } >> ], >> "tokens":[ >> "https://server.example.net/", >> "https://server1.example.net/" >> ] >> } >>=20 >> The default could be that the AS issues an access token good for all gran= ted resources.=20 >>=20 >> One could also go one step further and let the AS decide what access toke= ns it would issue and add metadata about the recipients to the response.=20 >>=20 >> { >> "access_tokens":[ >> { >> "destination":"https://server.example.net/"", >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type":"bearer" >> }, >> { >> "destination":"https://server1.example.net/", >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1", >> "type":"bearer" >> } >> ], >> "handle":{ >> "value":"80UPRY5NM33OMUKMKSKU", >> "type":"bearer" >> }, >> "claims":{ >> "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6", >> "email":"alice@example.com" >> } >> } >>=20 >> I personally think this would even better fit the transactional character= of the new protocol. >>=20 >> >=20 >> > This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to a= client=E2=80=99s simple request, but I actually like that feature. If the c= lient is capable of dealing with multiple tokens simultaneously, it can ask f= or them. >>=20 >> I think that=E2=80=99s the important aspect! In my opinion, the AS basica= lly decides whether different tokens are required for different resources. I= therefore think all client must be prepared to use different tokens to use t= he privileges granted in a certain transaction (in the same way OAuth 2 clie= nts must be prepared for refresh tokens rotation). Whether the client asks f= or more all or just a specific token (to start with), is a different questio= n.=20 >>=20 >> > The single token case turns into a single unnamed access token with the= same semantics.=20 >>=20 >> >=20 >> >>=20 >> >> I think a further element =E2=80=9Etoken=E2=80=9C element within the r= esource structure could also be used to denote the assignment of a certain r= esource object to this token. Advantage: no need to change the syntax. What d= o you think about this approach? >> >=20 >> > That=E2=80=99s an interesting idea, and I can see the advantage of a si= mpler syntax on the surface =E2=80=A6 but at first shake I see a couple prob= lems with it. First, this presumes you=E2=80=99d always be sending a full re= source object. If you=E2=80=99re sending a scope string (or a resource handl= e in XYZ terms), then you don=E2=80=99t have anywhere to put the name of the= token since it=E2=80=99s no longer an object. >>=20 >> That=E2=80=99s certainly true.=20 >>=20 >> > Second, there=E2=80=99s no clear way to combine multiple resource facet= s into a single token. >>=20 >> Why, just use the same label. >>=20 >> > And third, you now have to handle a whole bunch of new error cases: wha= t if some of the resource request objects have names, and others don=E2=80=99= t? What if you use the same name on multiple resource request objects? If th= at means you combine them into a single token, you=E2=80=99re back at the qu= estion above about audience restrictions. >>=20 >> You need to solve that anyway. I feel my proposal above is more suitable.= =20 >>=20 >> > And finally, it changes the semantics of the resource object in a way t= hat a simple client would have to at least know about, and be able to deal w= ith the AS=E2=80=99s different error conditions. >> >=20 >> > Your thoughts on these points? I might be missing something obvious wit= h what you=E2=80=99re suggesting. >>=20 >> I=E2=80=99m still struggling to understand why a client should ask for a c= ertain assignment of resources. I think it=E2=80=99s basically the AS in enf= orcing a certain security policy. The client (on top of that) might ask for l= ess powerful access tokens within the boundaries defined by the AS.=20 >>=20 >> >=20 >> > Thanks for the feedback! >>=20 >> Happy to do so. It=E2=80=99s an important topic waiting for an interopera= ble solution. I think we need to introduce a clear indication of boundaries b= etween resource servers (or security domains or whatever you want to call it= ) in oder to solve that.=20 >>=20 >> best regards, >> Torsten.=20 >>=20 >> >=20 >> > =E2=80=94 Justin >> >=20 >> >>=20 >> >> best regards, >> >> Torsten. >> >>=20 >> >>> Am 13.03.2020 um 23:13 schrieb Justin Richer : >> >>>=20 >> >>> =EF=BB=BFI took some time to implement an idea that was tossed out on= the list here recently, and that=E2=80=99s how we might support requests an= d responses for multiple access tokens. I=E2=80=99ve got a method that I thi= nk works pretty well without getting in the way of the common, simple case o= f requesting a single access token. I=E2=80=99ve implemented this in our Jav= a implementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/ webs= ite with more details. I=E2=80=99ll update my ID spec text when I get a chan= ce to reflect this, but I wanted to start this discussion first. Everything i= n here is based on the XYZ protocol. >> >>>=20 >> >>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is a= n array of items: >> >>>=20 >> >>> resources: [ >> >>> { >> >>> actions: ["read", "write", "dolphin"], >> >>> locations: ["https://server.example.net/", "https://resou= rce.local/other"], >> >>> datatypes: ["metadata", "images"] >> >>> }, >> >>> { >> >>> actions: ["foo", "bar", "dolphin"], >> >>> locations: ["https://resource.other/"], >> >>> datatypes: ["data", "pictures"] >> >>> } >> >>> ] >> >>>=20 >> >>> This tells the AS that the client is asking for a single access token= with multiple, perhaps orthogonal sets of access. This is in parallel to RA= R being developed in OAuth 2. However, if we allow the =E2=80=9Cresources=E2= =80=9D item to be an object instead of an array, we can let the client signa= l to the AS that it wants multiple access tokens. The client picks =E2=80=9C= labels=E2=80=9D for these access tokens, in this case =E2=80=9Ctoken1=E2=80=9D= and =E2=80=9Ctoken2=E2=80=9D, and sends a request like this. >> >>>=20 >> >>> resources: { >> >>> token1: [{ >> >>> actions: ["read", "write", "dolphin"], >> >>> locations: ["https://server.example.net/", "https://resou= rce.local/other"], >> >>> datatypes: ["metadata", "images"] >> >>> }], >> >>> token2: [{ >> >>> actions: ["foo", "bar", "dolphin"], >> >>> locations: ["https://resource.other/"], >> >>> datatypes: ["data", "pictures"] >> >>> }] >> >>> } >> >>>=20 >> >>> The client could request multiple kinds of access within each sub-obj= ect=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D and =E2=80=9C= token2=E2=80=9D fields), but I wanted to keep it simple here. This example i= s the same total set of resources that the client is asking for in the first= case, but here the client=E2=80=99s saying it wants them as two different a= ccess tokens instead of a single one. The AS can tell the difference in the r= equest because the first type is an array at the top and the second type is a= n object at the top. So that means that the AS can send back a single access= token in a tx response like this: >> >>>=20 >> >>> { >> >>> access_token: { >> >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> >>> type: "bearer" >> >>> } >> >>> } >> >>>=20 >> >>> Or multiple access tokens in a tx response like this: >> >>>=20 >> >>> { >> >>> multiple_access_tokens: { >> >>> token1: { >> >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> >>> type: "bearer" >> >>> }, >> >>> token2: { >> >>> value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >> >>> type: "bearer" >> >>> } >> >>> } >> >>> } >> >>>=20 >> >>> These fields are mutually exclusive, so you either get a single unnam= ed token or a set of named tokens. Since the client pics the labels for the a= ccess tokens, it=E2=80=99s clear which part of the request maps to which par= t of the response. It=E2=80=99s more complexity for the client to track, but= that complexity is only seen and borne by clients that need it. Simple clie= nts get to stay simple while letting a complex problem get solved.=20 >> >>>=20 >> >>> A note about the polymorphic JSON that=E2=80=99s in user here, though= it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. For those= unfamiliar with the concept, this is when a given field can have a value th= at takes multiple different types: a string, a boolean, an object, an array,= etc. This is pretty simple to deal with in dynamically typed languages, you= just check the type of the resulting object and it will tell you what you=E2= =80=99re dealing with. It=E2=80=99s trickier in statically typed languages, b= ut I=E2=80=99ve found that pretty much every platform and library has hooks f= or custom serialization and deserialization that will let you dispatch to di= fferent types during the process, so you can still call your top-level parse= r and toString methods and things will work as expected. This is one of the r= easons that I did an implementation in Java, to prove that we could do this k= ind of thing in a strongly typed language that=E2=80=99s not very flexible a= bout what goes in objects, and I=E2=80=99ve done it without resorting to gen= eric collections for the dynamic fields. Previously, I=E2=80=99ve used this f= eature in XYZ to allow a single string to stand in as a reference for an obj= ect =E2=80=94 something XYZ calls =E2=80=9Chandles=E2=80=9D. These let you h= ave constructs akin to a client_id, a scope, a refresh token, and a few othe= r items without having to create explicit elements for these, since they alw= ays stand in for the object they replace there=E2=80=99s no ambiguity. So fo= r things like a resource request, each of these can be replaced by a string u= sing resource handles and polymorphic JSON (see note below) to act like a sc= ope in OAuth2. >> >>>=20 >> >>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfoobar-pi= ctures=E2=80=9D ] >> >>>=20 >> >>> Polymorphic JSON is great for things like this because it means you d= on=E2=80=99t have to have multiple fields and normative rules for mutual exc= lusivity, like we=E2=80=99d have to have otherwise. The type switching only w= orks when the base type is significantly different, though =E2=80=94 that=E2= =80=99s why I have =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_acce= ss_tokens=E2=80=9D above, since both are objects at the top level and you ca= n=E2=80=99t cleanly switch at the parser level, and you don=E2=80=99t want t= o have to dig down into the object to see what to do with it. >> >>>=20 >> >>>=20 >> >>>=20 >> >>> People have been asking for a good way to do multiple access tokens w= ith OAuth for years, but we=E2=80=99ve never had a good or clean way to pull= it off because of OAuth=E2=80=99s model and the assumptions that it makes. I= think TxAuth gives us the opportunity to solve this in a way that=E2=80=99s= consistent with the rest of the protocol, and do so in a way that doesn=E2=80= =99t make the simple cases we know and love too complicated for average deve= lopers. >> >>>=20 >> >>> =E2=80=94 Justin >> >>>=20 >> >>> --=20 >> >>> Txauth mailing list >> >>> Txauth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/txauth >> >=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-FBF20ECE-CEEB-48B4-8DC0-E40CD0260B25 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi David,

Am 14.03.2020 um 22:57 schrieb David Ska= ife <blue.ringed.octopus.guy@gmail.com>:

=EF=BB=BF
Hi,

This is an interesting idea, and one which I think would b= e a useful addition to the protocol. As you've mentioned, it will be incredi= bly important to define it in a way that enables the simpler use cases to re= main simple, and not be complicated by this additional optional feature.
With regards to Torsten's question: "What would be the cl= ient=E2=80=99s motivation to split resources to different access tokens?= "
I'm involved in the implementation of Open Banking within the United Ki= ngdom and I can certainly think of scenarios in Open Banking where the clien= t app would be able to provide a better user experience if they could offer t= he ability to revoke permissions at a fine-grained level, rather than the us= er having to revoke "all or nothing". For example, if a user has provided a t= hird-party provider with access to their current account balance, account na= me, and account transactions, at a later point they may want to revoke third= -party provider access to their transactions but keep the other permissions a= ctive - enabling the client app to split the resources to between different a= ccess tokens would provide that ability.
<= div>
I see the use case, but I would solve it differently by revoki= ng the resource object assigned to a certain transaction handle instead of t= he access token. The token, in my mental model, is just the credential requi= red to execute certain privileges but not the privilege itself.


=
Related to the above example, within the context of Open Banking i= n the UK, we also have the scenario where a user is able to select which of t= heir bank accounts they want to be included within the scope of an authorisa= tion at the point when the user is interacting directly with the Authorizati= on Server (i.e. after the client has already sent the initial back-channel r= equest to the AS containing details of the requested resources, and with thi= s new feature we're discussing here, the details of the access token split) -= it would be very desirable (for similar reasons to above example) to have o= ne access token per bank account rather than one access token covering all o= f their bank accounts, to enable the user to revoke access to each account i= ndividually. This might be out of scope of this particular discussion, but w= ithin the context of XYZ and within the context of this multiple access toke= n proposal, would there be any way to assign different access tokens to elem= ents of the authorisation that are selected by the user AFTER the initial ba= ck-channel request between the client and the AS?

I think this would require a selection over the resou= rces assigned to a certain transaction handle. Here it is getting rather tri= cky if a single resource object contains all bank accounts. Sending another r= equest to the AS with the transaction handle and a subset in the resource pa= rameter that shall be assigned to the access token should do the job. The AS= should be able to determine that the privileges were already granted in thi= s transaction, so no further user interaction required.

=
One fi= nal question from me on this: I'm assuming that it would be optional for Aut= horization Servers to support multiple access tokens and so what would be th= e mechanism for the client to determine if the AS supports it, and what woul= d be the response back if a client tries to utilise a feature such as this t= hat the AS doesn't support?

I think the use cases you described require an assignment of a subset of re= sources to a token, not necessarily multiple access tokens.

best regards,
Torsten.


Many Thanks,
David Skaif= e

On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf= .org> wrote:
jricher@mit.edu> wrote:
>
> On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt <torsten@lodderstedt.net> w= rote:
>>
>> =EF=BB=BF
>> Hi Justin,
>>
>> I have always been a fan of multiple access tokens support :-) So t= hanks you for bringing this forward.
>
> Yes! It=E2=80=99s only taken us another 10 years to get back here again= . :)
>

yep. Just an example ;-): http= s://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/
=
>>
>> Some questions:
>>
>> Do you assume the client can freely allocated resources to access t= okens? How would that work with audience-restricted/specific access tokens?<= br> >
> In the syntax I=E2=80=99m proposing, the client can take any set of res= ources and ask for it to go with one token. Basically, each named element of= the resources object in the multi-token request syntax is exactly the same a= s a single token request would be, an array of resource requests. So yes, th= e client can mix and match as it sees fit, and the AS can reject a request f= or combining two different audiences in the same token. The AS would need to= do that anyway for a single token request, so I don=E2=80=99t see that as a= greater burden =E2=80=94 it=E2=80=99s just that now the client can fulfill t= he requirements without making multiple transaction requests.

What would be the client=E2=80=99s motivation to split resources to differen= t access tokens?
What information would the client use to allocate the resources to the appro= priate access tokens?

In my experience, it is the AS (or the security policy of the deployment) th= at determines what can go into a single access token.

One policy is to allow everything to go into a single access token. That mig= ht work in a single RS deployment. In a multi RS deployment, one would eithe= r end up with tokens containing the set union of all data needed by all RSs.= Encryptions of those tokens might be complex, I don=E2=80=99t know whether t= his is privacy preserving. The other option is to use token introspection or= other callbacks to the AS to obtain the real data needed for access control= per RS, not very performant.

Another possible policy is to have access tokens that at most contain data f= or a certain resource server. This helps privacy (no implicit data sharing a= mong resource servers) and security (single audience, encryption is straight= forward, simple token replay prevention). But someone needs to know the boun= daries.

If the client knows the boundaries, all it would need to ask the AS for is t= o issue access tokens for a set of recipients. This could be done in paralle= l to the resources structure.

Something like this:

{
   "resources":[
      {
         "actions":[
            "read",
            "write",
            "dolphin"
         ],
         "locations":[
            "https://server.example.net/"= ,
            "https://resource.local/other"
         ],
         "datatypes":[
            "metadata",
            "images"
         ]
      },
      {
         "actions":[
            "read"
         ],
         "locations":[
            "https://server1.example.net/"
         ],
         "datatypes":[
            "contacts"
         ]
      }
   ],
   "tokens":[
      "https://server.example.net/",
      "https://server1.example.net/"
   ]
}

The default could be that the AS issues an access token good for all granted= resources.

One could also go one step further and let the AS decide what access tokens i= t would issue and add metadata about the recipients to the response.

{
   "access_tokens":[
      {
         "destination":"https://server.example.net= /"",
         "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP21= 9RP1LT0",
         "type":"bearer"
      },
      {
         "destination":"https://server1.example.n= et/",
         "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP21= 9RP1LT1",
         "type":"bearer"
      }
   ],
   "handle":{
      "value":"80UPRY5NM33OMUKMKSKU",
      "type":"bearer"
   },
   "claims":{
      "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6",
      "email":"alice@example.com"
   }
}

I personally think this would even better fit the transactional character of= the new protocol.

>
> This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to a= client=E2=80=99s simple request, but I actually like that feature. If the c= lient is capable of dealing with multiple tokens simultaneously, it can ask f= or them.

I think that=E2=80=99s the important aspect! In my opinion, the AS basically= decides whether different tokens are required for different resources. I th= erefore think all client must be prepared to use different tokens to use the= privileges granted in a certain transaction (in the same way OAuth 2 client= s must be prepared for refresh tokens rotation). Whether the client asks for= more all or just a specific token (to start with), is a different question.=

> The single token case turns into a single unnamed access token with the= same semantics.

>
>>
>> I think a further element =E2=80=9Etoken=E2=80=9C element within th= e resource structure could also be used to denote the assignment of a certai= n resource object to this token. Advantage: no need to change the syntax. Wh= at do you think about this approach?
>
> That=E2=80=99s an interesting idea, and I can see the advantage of a si= mpler syntax on the surface =E2=80=A6 but at first shake I see a couple prob= lems with it. First, this presumes you=E2=80=99d always be sending a full re= source object. If you=E2=80=99re sending a scope string (or a resource handl= e in XYZ terms), then you don=E2=80=99t have anywhere to put the name of the= token since it=E2=80=99s no longer an object.

That=E2=80=99s certainly true.

> Second, there=E2=80=99s no clear way to combine multiple resource facet= s into a single token.

Why, just use the same label.

> And third, you now have to handle a whole bunch of new error cases: wha= t if some of the resource request objects have names, and others don=E2=80=99= t? What if you use the same name on multiple resource request objects? If th= at means you combine them into a single token, you=E2=80=99re back at the qu= estion above about audience restrictions.

You need to solve that anyway. I feel my proposal above is more suitable.
> And finally, it changes the semantics of the resource object in a way t= hat a simple client would have to at least know about, and be able to deal w= ith the AS=E2=80=99s different error conditions.
>
> Your thoughts on these points? I might be missing something obvious wit= h what you=E2=80=99re suggesting.

I=E2=80=99m still struggling to understand why a client should ask for a cer= tain assignment of resources. I think it=E2=80=99s basically the AS in enfor= cing a certain security policy. The client (on top of that) might ask for le= ss powerful access tokens within the boundaries defined by the AS.

>
> Thanks for the feedback!

Happy to do so. It=E2=80=99s an important topic waiting for an interoperable= solution. I think we need to introduce a clear indication of boundaries bet= ween resource servers (or security domains or whatever you want to call it) i= n oder to solve that.

best regards,
Torsten.

>
>  =E2=80=94 Justin
>
>>
>> best regards,
>> Torsten.
>>
>>> Am 13.03.2020 um 23:13 schrieb Justin Richer <jricher@mit.edu>:
>>>
>>> =EF=BB=BFI took some time to implement an idea that was tossed o= ut on the list here recently, and that=E2=80=99s how we might support reques= ts and responses for multiple access tokens. I=E2=80=99ve got a method that I= think works pretty well without getting in the way of the common, simple ca= se of requesting a single access token. I=E2=80=99ve implemented this in our= Java implementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/ webs= ite with more details. I=E2=80=99ll update my ID spec text when I get a chan= ce to reflect this, but I wanted to start this discussion first. Everything i= n here is based on the XYZ protocol.
>>>
>>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx reque= st is an array of items:
>>>
>>> resources: [
>>>     {
>>>             actions: ["read"= , "write", "dolphin"],
>>>             locations: ["htt= ps://server.example.net/", "https://resource.local/other"],
>>>             datatypes: ["met= adata", "images"]
>>>         },
>>>     {
>>>             actions: ["foo",= "bar", "dolphin"],
>>>             locations: ["https:/= /resource.other/"],
>>>             datatypes: ["dat= a", "pictures"]
>>>         }
>>> ]
>>>
>>> This tells the AS that the client is asking for a single access= token with multiple, perhaps orthogonal sets of access. This is in parallel= to RAR being developed in OAuth 2. However, if we allow the =E2=80=9Cresour= ces=E2=80=9D item to be an object instead of an array, we can let the client= signal to the AS that it wants multiple access tokens. The client picks =E2= =80=9Clabels=E2=80=9D for these access tokens, in this case =E2=80=9Ctoken1=E2= =80=9D and =E2=80=9Ctoken2=E2=80=9D, and sends a request like this.
>>>
>>> resources: {
>>>     token1: [{
>>>             actions: ["read"= , "write", "dolphin"],
>>>             locations: ["htt= ps://server.example.net/", "https://resource.local/other"],
>>>             datatypes: ["met= adata", "images"]
>>>      }],
>>>      token2: [{
>>>             actions: ["foo",= "bar", "dolphin"],
>>>             locations: ["https:/= /resource.other/"],
>>>             datatypes: ["dat= a", "pictures"]
>>>      }]
>>> }
>>>
>>> The client could request multiple kinds of access within each s= ub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D and =E2= =80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple here. This exa= mple is the same total set of resources that the client is asking for in the= first case, but here the client=E2=80=99s saying it wants them as two diffe= rent access tokens instead of a single one. The AS can tell the difference i= n the request because the first type is an array at the top and the second t= ype is an object at the top. So that means that the AS can send back a singl= e access token in a tx response like this:
>>>
>>> {
>>>         access_token: {
>>>             value: "OS9M2PMH= KUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>>>             type: "bearer" >>>         }
>>> }
>>>
>>> Or multiple access tokens in a tx response like this:
>>>
>>> {
>>>     multiple_access_tokens: {
>>>           token1: {
>>>             value: "OS9M2PMH= KUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>>>             type: "bearer" >>>           },
>>>           token2: {
>>>             value: "UFGLO2FD= AFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
>>>             type: "bearer" >>>           }
>>>     }
>>> }
>>>
>>> These fields are mutually exclusive, so you either get a single= unnamed token or a set of named tokens. Since the client pics the labels fo= r the access tokens, it=E2=80=99s clear which part of the request maps to wh= ich part of the response. It=E2=80=99s more complexity for the client to tra= ck, but that complexity is only seen and borne by clients that need it. Simp= le clients get to stay simple while letting a complex problem get solved. >>>
>>> A note about the polymorphic JSON that=E2=80=99s in user here, t= hough it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. For t= hose unfamiliar with the concept, this is when a given field can have a valu= e that takes multiple different types: a string, a boolean, an object, an ar= ray, etc. This is pretty simple to deal with in dynamically typed languages,= you just check the type of the resulting object and it will tell you what y= ou=E2=80=99re dealing with. It=E2=80=99s trickier in statically typed langua= ges, but I=E2=80=99ve found that pretty much every platform and library has h= ooks for custom serialization and deserialization that will let you dispatch= to different types during the process, so you can still call your top-level= parser and toString methods and things will work as expected. This is one o= f the reasons that I did an implementation in Java, to prove that we could d= o this kind of thing in a strongly typed language that=E2=80=99s not very fl= exible about what goes in objects, and I=E2=80=99ve done it without resortin= g to generic collections for the dynamic fields. Previously, I=E2=80=99ve us= ed this feature in XYZ to allow a single string to stand in as a reference f= or an object =E2=80=94 something XYZ calls =E2=80=9Chandles=E2=80=9D. These l= et you have constructs akin to a client_id, a scope, a refresh token, and a f= ew other items without having to create explicit elements for these, since t= hey always stand in for the object they replace there=E2=80=99s no ambiguity= . So for things like a resource request, each of these can be replaced by a s= tring using resource handles and polymorphic JSON (see note below) to act li= ke a scope in OAuth2.
>>>
>>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfoo= bar-pictures=E2=80=9D ]
>>>
>>> Polymorphic JSON is great for things like this because it means= you don=E2=80=99t have to have multiple fields and normative rules for mutu= al exclusivity, like we=E2=80=99d have to have otherwise. The type switching= only works when the base type is significantly different, though =E2=80=94 t= hat=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultipl= e_access_tokens=E2=80=9D above, since both are objects at the top level and y= ou can=E2=80=99t cleanly switch at the parser level, and you don=E2=80=99t w= ant to have to dig down into the object to see what to do with it.
>>>
>>>
>>>
>>> People have been asking for a good way to do multiple access to= kens with OAuth for years, but we=E2=80=99ve never had a good or clean way t= o pull it off because of OAuth=E2=80=99s model and the assumptions that it m= akes. I think TxAuth gives us the opportunity to solve this in a way that=E2= =80=99s consistent with the rest of the protocol, and do so in a way that do= esn=E2=80=99t make the simple cases we know and love too complicated for ave= rage developers.
>>>
>>>  =E2=80=94 Justin
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@iet= f.org
>>> https://www.ietf.org/mailman/listinfo/txauth<= /a>
>

--
Txauth mailing list
Txauth@ietf.org
= https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.or= g
https://www.ietf.org/mailman/listinfo/txauth
= --Apple-Mail-FBF20ECE-CEEB-48B4-8DC0-E40CD0260B25-- --Apple-Mail-E1549CE4-7B68-44E5-93A4-D03A4ADD6278 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzE0MjIxNzM3WjAvBgkqhkiG9w0BCQQxIgQg T1RLZD2LI4niPdQDt1acbvpz6LThK52qVmwKg0bGQdowgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAXVe71R7/mZfY0abGBaqXq/VhbpiWMCqpOHjStYDetDicIYPsriv+ 73BNvEShVX2QaWFJIPVo4yraPgJawrnke7OpN9bFtpV69+to93H5QznNxvDuGn2dlN2Bx6I/QflJ ZypBoC5P9P4esmITX14RWGWSI6fhzOfXWL0quu7IzfhlxkdcIFCJpLP0sXCzLi5/Kj6WcCUKiEaJ yqB7MVV5v5S1RzIfhSAdP3dd58uEfzfgPJb1LUeKbMRU9J1DHvXDR7Y0gJwNpGApexIua72p9LOs 6tQV43gRoVNslCQjIGJNqihxzkF7gchlWH0J3k+Ig7cBCI1I09JQJP7nId4zzgAAAAAAAA== --Apple-Mail-E1549CE4-7B68-44E5-93A4-D03A4ADD6278-- From nobody Sat Mar 14 19:25:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851CB3A0B48 for ; Sat, 14 Mar 2020 19:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_OTHER_BAD_TLD=1.998, 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 KjYOcAPSax2K for ; Sat, 14 Mar 2020 19:25:11 -0700 (PDT) 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 652693A0B47 for ; Sat, 14 Mar 2020 19:25:09 -0700 (PDT) Received: from [192.168.1.5] (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 02F2P6m2008426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Mar 2020 22:25:07 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> Date: Sat, 14 Mar 2020 22:25:06 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 02:25:15 -0000 I=E2=80=99m realizing something with your description below that I think = gets to the differences we=E2=80=99re seeing in the use case driving = this: I think you are looking at the split of access tokens being based on = differences in resource server domains, such that the driver is the = audience restriction from the security domain of the AS/RS side. = However, I=E2=80=99m looking at it from the perspective of the client = calling an API (or set of APIs) with different capabilities. And so in = that case, it=E2=80=99s not just about =E2=80=9Cwhere=E2=80=9D the token = is used, but what it=E2=80=99s used for. In other words, it=E2=80=99s = the Client/RS relationship driving things.=20 Let=E2=80=99s say, for instance, we=E2=80=99ve got a complex client that = wants to have a long-lived read-only access token and a short-lived = read-write token for an API. The client=E2=80=99s going to know about = the API it=E2=80=99s requesting =E2=80=94 even if the client library = doesn=E2=80=99t know, the client software using it will know how the = APIs that it=E2=80=99s been designed to call can be split up. And how = that happens is really up to the API, which is of course defined by the = RS and secured by the AS. So if the AS needs a client to get different = access tokens to call different RS domains, it does exactly what we do = in OAuth 2 today =E2=80=94 it tells the client to get two different = access tokens. Except now, the client can ask for them at the same time. = So you see, it=E2=80=99s about a lot more than the =E2=80=9Cdestination=E2= =80=9D of the token, it=E2=80=99s about the entire desired use of the = token. In other words, the sum total of a =E2=80=9Cresources=E2=80=9D = structure, an array of objects combined together to give a whole = picture. Yes, the AS is still going to apply policy, and if the client is asking = for multiple resource object sets that can=E2=80=99t be combined, for = whatever reason, it can reject that. However, I think it=E2=80=99s a = really bad idea to say that all clients need to be prepared to maybe get = multiple access tokens, and know what to do with them.=20 The thing I don=E2=80=99t like about your proposed syntax(es) is that it = adds complexity that even the clients who never care about multiple = access tokens will need to deal with. I do not want all clients to pay = this cost. I think the vast majority of clients and resource servers are = going to remain single access token like with OAuth2, and this general = case shouldn=E2=80=99t be burdened with even thinking about multiple = access tokens. I think that my proposal lets this happen without the two = getting in the way of each other, which to me is a big win.=20 As an aside: parallel data structures, like the =E2=80=9Ctokens=E2=80=9D = component idea below, are almost always a hack, a symptom of bad syntax = that isn=E2=80=99t extensible in the right way. Considering that it=E2=80=99= s essentially the same data and requirements on the client, I don=E2=80=99= t see what that buys apart from avoiding polymorphic JSON, which I might = add could be avoided by having mutually exclusive data structures of = different types (but, as per my first email, I hope we can avoid that = because it=E2=80=99s brittle).=20 =E2=80=94 Justin > On Mar 14, 2020, at 12:32 PM, Torsten Lodderstedt = wrote: >=20 > Hi Justin, >=20 >> On 14. Mar 2020, at 14:07, Justin Richer wrote: >>=20 >> On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt = wrote: >>>=20 >>> =EF=BB=BF >>> Hi Justin, >>>=20 >>> I have always been a fan of multiple access tokens support :-) So = thanks you for bringing this forward. >>=20 >> Yes! It=E2=80=99s only taken us another 10 years to get back here = again. :) >>=20 >=20 > yep. Just an example ;-): = https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/ >=20 >>>=20 >>> Some questions: >>>=20 >>> Do you assume the client can freely allocated resources to access = tokens? How would that work with audience-restricted/specific access = tokens? >>=20 >> In the syntax I=E2=80=99m proposing, the client can take any set of = resources and ask for it to go with one token. Basically, each named = element of the resources object in the multi-token request syntax is = exactly the same as a single token request would be, an array of = resource requests. So yes, the client can mix and match as it sees fit, = and the AS can reject a request for combining two different audiences in = the same token. The AS would need to do that anyway for a single token = request, so I don=E2=80=99t see that as a greater burden =E2=80=94 = it=E2=80=99s just that now the client can fulfill the requirements = without making multiple transaction requests.=20 >=20 > What would be the client=E2=80=99s motivation to split resources to = different access tokens?=20 > What information would the client use to allocate the resources to the = appropriate access tokens?=20 >=20 > In my experience, it is the AS (or the security policy of the = deployment) that determines what can go into a single access token.=20 >=20 > One policy is to allow everything to go into a single access token. = That might work in a single RS deployment. In a multi RS deployment, one = would either end up with tokens containing the set union of all data = needed by all RSs. Encryptions of those tokens might be complex, I = don=E2=80=99t know whether this is privacy preserving. The other option = is to use token introspection or other callbacks to the AS to obtain the = real data needed for access control per RS, not very performant.=20 >=20 > Another possible policy is to have access tokens that at most contain = data for a certain resource server. This helps privacy (no implicit data = sharing among resource servers) and security (single audience, = encryption is straightforward, simple token replay prevention). But = someone needs to know the boundaries.=20 >=20 > If the client knows the boundaries, all it would need to ask the AS = for is to issue access tokens for a set of recipients. This could be = done in parallel to the resources structure.=20 >=20 > Something like this:=20 >=20 > { > "resources":[ > { > "actions":[ > "read", > "write", > "dolphin" > ], > "locations":[ > "https://server.example.net/", > "https://resource.local/other" > ], > "datatypes":[ > "metadata", > "images" > ] > }, > { > "actions":[ > "read" > ], > "locations":[ > "https://server1.example.net/" > ], > "datatypes":[ > "contacts" > ] > } > ], > "tokens":[ > "https://server.example.net/", > "https://server1.example.net/" > ] > } >=20 > The default could be that the AS issues an access token good for all = granted resources.=20 >=20 > One could also go one step further and let the AS decide what access = tokens it would issue and add metadata about the recipients to the = response.=20 >=20 > { > "access_tokens":[ > { > "destination":"https://server.example.net/"", > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type":"bearer" > }, > { > "destination":"https://server1.example.net/", > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1", > "type":"bearer" > } > ], > "handle":{ > "value":"80UPRY5NM33OMUKMKSKU", > "type":"bearer" > }, > "claims":{ > "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6", > "email":"alice@example.com" > } > } >=20 > I personally think this would even better fit the transactional = character of the new protocol. >=20 >>=20 >> This syntax doesn=E2=80=99t allow the AS to assign multiple tokens to = a client=E2=80=99s simple request, but I actually like that feature. If = the client is capable of dealing with multiple tokens simultaneously, it = can ask for them. >=20 > I think that=E2=80=99s the important aspect! In my opinion, the AS = basically decides whether different tokens are required for different = resources. I therefore think all client must be prepared to use = different tokens to use the privileges granted in a certain transaction = (in the same way OAuth 2 clients must be prepared for refresh tokens = rotation). Whether the client asks for more all or just a specific token = (to start with), is a different question.=20 >=20 >> The single token case turns into a single unnamed access token with = the same semantics.=20 >=20 >>=20 >>>=20 >>> I think a further element =E2=80=9Etoken=E2=80=9C element within the = resource structure could also be used to denote the assignment of a = certain resource object to this token. Advantage: no need to change the = syntax. What do you think about this approach? >>=20 >> That=E2=80=99s an interesting idea, and I can see the advantage of a = simpler syntax on the surface =E2=80=A6 but at first shake I see a = couple problems with it. First, this presumes you=E2=80=99d always be = sending a full resource object. If you=E2=80=99re sending a scope string = (or a resource handle in XYZ terms), then you don=E2=80=99t have = anywhere to put the name of the token since it=E2=80=99s no longer an = object. >=20 > That=E2=80=99s certainly true.=20 >=20 >> Second, there=E2=80=99s no clear way to combine multiple resource = facets into a single token. >=20 > Why, just use the same label. >=20 >> And third, you now have to handle a whole bunch of new error cases: = what if some of the resource request objects have names, and others = don=E2=80=99t? What if you use the same name on multiple resource = request objects? If that means you combine them into a single token, = you=E2=80=99re back at the question above about audience restrictions. >=20 > You need to solve that anyway. I feel my proposal above is more = suitable.=20 >=20 >> And finally, it changes the semantics of the resource object in a way = that a simple client would have to at least know about, and be able to = deal with the AS=E2=80=99s different error conditions. >>=20 >> Your thoughts on these points? I might be missing something obvious = with what you=E2=80=99re suggesting. >=20 > I=E2=80=99m still struggling to understand why a client should ask for = a certain assignment of resources. I think it=E2=80=99s basically the AS = in enforcing a certain security policy. The client (on top of that) = might ask for less powerful access tokens within the boundaries defined = by the AS.=20 >=20 >>=20 >> Thanks for the feedback! >=20 > Happy to do so. It=E2=80=99s an important topic waiting for an = interoperable solution. I think we need to introduce a clear indication = of boundaries between resource servers (or security domains or whatever = you want to call it) in oder to solve that.=20 >=20 > best regards, > Torsten.=20 >=20 >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>> Am 13.03.2020 um 23:13 schrieb Justin Richer : >>>>=20 >>>> =EF=BB=BFI took some time to implement an idea that was tossed out = on the list here recently, and that=E2=80=99s how we might support = requests and responses for multiple access tokens. I=E2=80=99ve got a = method that I think works pretty well without getting in the way of the = common, simple case of requesting a single access token. I=E2=80=99ve = implemented this in our Java implementation of XYZ and I=E2=80=99ve = updated the https://oauth.xyz/ website with more details. I=E2=80=99ll = update my ID spec text when I get a chance to reflect this, but I wanted = to start this discussion first. Everything in here is based on the XYZ = protocol. >>>>=20 >>>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request = is an array of items: >>>>=20 >>>> resources: [ >>>> { >>>> actions: ["read", "write", "dolphin"], >>>> locations: ["https://server.example.net/", = "https://resource.local/other"], >>>> datatypes: ["metadata", "images"] >>>> }, >>>> { >>>> actions: ["foo", "bar", "dolphin"], >>>> locations: ["https://resource.other/"], >>>> datatypes: ["data", "pictures"] >>>> } >>>> ] >>>>=20 >>>> This tells the AS that the client is asking for a single access = token with multiple, perhaps orthogonal sets of access. This is in = parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this. >>>>=20 >>>> resources: { >>>> token1: [{ >>>> actions: ["read", "write", "dolphin"], >>>> locations: ["https://server.example.net/", = "https://resource.local/other"], >>>> datatypes: ["metadata", "images"] >>>> }], >>>> token2: [{ >>>> actions: ["foo", "bar", "dolphin"], >>>> locations: ["https://resource.other/"], >>>> datatypes: ["data", "pictures"] >>>> }] >>>> } >>>>=20 >>>> The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this: >>>>=20 >>>> { >>>> access_token: { >>>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>>> type: "bearer" >>>> } >>>> } >>>>=20 >>>> Or multiple access tokens in a tx response like this: >>>>=20 >>>> { >>>> multiple_access_tokens: { >>>> token1: { >>>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>>> type: "bearer" >>>> }, >>>> token2: { >>>> value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >>>> type: "bearer" >>>> } >>>> } >>>> } >>>>=20 >>>> These fields are mutually exclusive, so you either get a single = unnamed token or a set of named tokens. Since the client pics the labels = for the access tokens, it=E2=80=99s clear which part of the request maps = to which part of the response. It=E2=80=99s more complexity for the = client to track, but that complexity is only seen and borne by clients = that need it. Simple clients get to stay simple while letting a complex = problem get solved.=20 >>>>=20 >>>> A note about the polymorphic JSON that=E2=80=99s in user here, = though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. = For those unfamiliar with the concept, this is when a given field can = have a value that takes multiple different types: a string, a boolean, = an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2. >>>>=20 >>>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ] >>>>=20 >>>> Polymorphic JSON is great for things like this because it means you = don=E2=80=99t have to have multiple fields and normative rules for = mutual exclusivity, like we=E2=80=99d have to have otherwise. The type = switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it. >>>>=20 >>>>=20 >>>>=20 >>>> People have been asking for a good way to do multiple access tokens = with OAuth for years, but we=E2=80=99ve never had a good or clean way to = pull it off because of OAuth=E2=80=99s model and the assumptions that it = makes. I think TxAuth gives us the opportunity to solve this in a way = that=E2=80=99s consistent with the rest of the protocol, and do so in a = way that doesn=E2=80=99t make the simple cases we know and love too = complicated for average developers. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >=20 From nobody Sat Mar 14 19:35:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707CA3A0C5A for ; Sat, 14 Mar 2020 19:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.998, 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 gkOQpgTEFDXu for ; Sat, 14 Mar 2020 19:35:38 -0700 (PDT) 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 774233A0C5F for ; Sat, 14 Mar 2020 19:35:37 -0700 (PDT) Received: from [192.168.1.5] (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 02F2ZWRg011127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Mar 2020 22:35:33 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6007DB68-AB0A-446B-B463-F9F596858707" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 14 Mar 2020 22:35:32 -0400 In-Reply-To: Cc: Torsten Lodderstedt , txauth@ietf.org To: David Skaife References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 02:35:42 -0000 --Apple-Mail=_6007DB68-AB0A-446B-B463-F9F596858707 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, My take on this is that in order for a client to be able to throw out = sub-components of its access by using, say, token revocation, you=E2=80=99= d need to ask for separate tokens from the start. I think the multiple = bank accounts scenario you lay out below is exactly that kind of thing = =E2=80=94 you ask for three different bank accounts from one bank, so = they all have the same RS but different access information. Otherwise, = you=E2=80=99re really just talking about refreshing an existing access = token with fewer rights than it started out as =E2=80=94 at least, if = I=E2=80=99m understating the second scenario below. That=E2=80=99s a bit = weird but in an interesting way: So far in the OAuth world just about = everything is additive, since that=E2=80=99s usually what people care = about in practice. Stepping up AuthZ and only asking for more than = you=E2=80=99ve already gotten the OK for. Refreshes are explicitly = allowed to downscope without prompting the user, and I had that in mind = with the transaction refresh. I think that there=E2=80=99s more we could = do with this, including adoption of the per-access-token management API = idea that=E2=80=99s been floated in the XYZ writeup (not in the spec or = implementation yet, mind you). As for discovery, I think XAuth=E2=80=99s idea of allowing OPTIONS is a = good one, but I would restrict it to being an OPTONS call on the = Transaction Endpoint instead of the matrix in the current proposal. This = way, the client still only has one URL to start things with at the AS. = Right now in XYZ we=E2=80=99ve got the =E2=80=9Ccapabilities=E2=80=9D = array to communicate that kind of information as well, and that could be = a factor too. I=E2=80=99m not sure though because I haven=E2=80=99t = really played with it in implementation yet. As the OAuth 2 mix-up = attack showed us, server discovery can be a little tricky to get right = in a secure way. =E2=80=94 Justin On Mar 14, 2020, at 5:56 PM, David Skaife = wrote: >=20 > Hi, >=20 > This is an interesting idea, and one which I think would be a useful = addition to the protocol. As you've mentioned, it will be incredibly = important to define it in a way that enables the simpler use cases to = remain simple, and not be complicated by this additional optional = feature. >=20 > With regards to Torsten's question: "What would be the client=E2=80=99s = motivation to split resources to different access tokens?" > I'm involved in the implementation of Open Banking within the United = Kingdom and I can certainly think of scenarios in Open Banking where the = client app would be able to provide a better user experience if they = could offer the ability to revoke permissions at a fine-grained level, = rather than the user having to revoke "all or nothing". For example, if = a user has provided a third-party provider with access to their current = account balance, account name, and account transactions, at a later = point they may want to revoke third-party provider access to their = transactions but keep the other permissions active - enabling the client = app to split the resources to between different access tokens would = provide that ability. >=20 > Related to the above example, within the context of Open Banking in = the UK, we also have the scenario where a user is able to select which = of their bank accounts they want to be included within the scope of an = authorisation at the point when the user is interacting directly with = the Authorization Server (i.e. after the client has already sent the = initial back-channel request to the AS containing details of the = requested resources, and with this new feature we're discussing here, = the details of the access token split) - it would be very desirable (for = similar reasons to above example) to have one access token per bank = account rather than one access token covering all of their bank = accounts, to enable the user to revoke access to each account = individually. This might be out of scope of this particular discussion, = but within the context of XYZ and within the context of this multiple = access token proposal, would there be any way to assign different access = tokens to elements of the authorisation that are selected by the user = AFTER the initial back-channel request between the client and the AS? >=20 > One final question from me on this: I'm assuming that it would be = optional for Authorization Servers to support multiple access tokens and = so what would be the mechanism for the client to determine if the AS = supports it, and what would be the response back if a client tries to = utilise a feature such as this that the AS doesn't support? >=20 > Many Thanks, > David Skaife >=20 > On Sat, Mar 14, 2020 at 4:33 PM Torsten Lodderstedt = > wrote: > Hi Justin, >=20 > > On 14. Mar 2020, at 14:07, Justin Richer > wrote: > >=20 > > On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt = > wrote: > >>=20 > >> =EF=BB=BF > >> Hi Justin, > >>=20 > >> I have always been a fan of multiple access tokens support :-) So = thanks you for bringing this forward. > >=20 > > Yes! It=E2=80=99s only taken us another 10 years to get back here = again. :) > >=20 >=20 > yep. Just an example ;-): = https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilMxCPWbgPw/ = = >=20 > >>=20 > >> Some questions: > >>=20 > >> Do you assume the client can freely allocated resources to access = tokens? How would that work with audience-restricted/specific access = tokens? > >=20 > > In the syntax I=E2=80=99m proposing, the client can take any set of = resources and ask for it to go with one token. Basically, each named = element of the resources object in the multi-token request syntax is = exactly the same as a single token request would be, an array of = resource requests. So yes, the client can mix and match as it sees fit, = and the AS can reject a request for combining two different audiences in = the same token. The AS would need to do that anyway for a single token = request, so I don=E2=80=99t see that as a greater burden =E2=80=94 = it=E2=80=99s just that now the client can fulfill the requirements = without making multiple transaction requests.=20 >=20 > What would be the client=E2=80=99s motivation to split resources to = different access tokens?=20 > What information would the client use to allocate the resources to the = appropriate access tokens?=20 >=20 > In my experience, it is the AS (or the security policy of the = deployment) that determines what can go into a single access token.=20 >=20 > One policy is to allow everything to go into a single access token. = That might work in a single RS deployment. In a multi RS deployment, one = would either end up with tokens containing the set union of all data = needed by all RSs. Encryptions of those tokens might be complex, I = don=E2=80=99t know whether this is privacy preserving. The other option = is to use token introspection or other callbacks to the AS to obtain the = real data needed for access control per RS, not very performant.=20 >=20 > Another possible policy is to have access tokens that at most contain = data for a certain resource server. This helps privacy (no implicit data = sharing among resource servers) and security (single audience, = encryption is straightforward, simple token replay prevention). But = someone needs to know the boundaries.=20 >=20 > If the client knows the boundaries, all it would need to ask the AS = for is to issue access tokens for a set of recipients. This could be = done in parallel to the resources structure.=20 >=20 > Something like this:=20 >=20 > { > "resources":[ > { > "actions":[ > "read", > "write", > "dolphin" > ], > "locations":[ > "https://server.example.net/ = ", > "https://resource.local/other = " > ], > "datatypes":[ > "metadata", > "images" > ] > }, > { > "actions":[ > "read" > ], > "locations":[ > "https://server1.example.net/ = " > ], > "datatypes":[ > "contacts" > ] > } > ], > "tokens":[ > "https://server.example.net/ ", > "https://server1.example.net/ " > ] > } >=20 > The default could be that the AS issues an access token good for all = granted resources.=20 >=20 > One could also go one step further and let the AS decide what access = tokens it would issue and add metadata about the recipients to the = response.=20 >=20 > { > "access_tokens":[ > { > "destination":"https://server.example.net/ = "", > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type":"bearer" > }, > { > "destination":"https://server1.example.net/ = ", > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1", > "type":"bearer" > } > ], > "handle":{ > "value":"80UPRY5NM33OMUKMKSKU", > "type":"bearer" > }, > "claims":{ > "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6", > "email":"alice@example.com " > } > } >=20 > I personally think this would even better fit the transactional = character of the new protocol. >=20 > >=20 > > This syntax doesn=E2=80=99t allow the AS to assign multiple tokens = to a client=E2=80=99s simple request, but I actually like that feature. = If the client is capable of dealing with multiple tokens simultaneously, = it can ask for them. >=20 > I think that=E2=80=99s the important aspect! In my opinion, the AS = basically decides whether different tokens are required for different = resources. I therefore think all client must be prepared to use = different tokens to use the privileges granted in a certain transaction = (in the same way OAuth 2 clients must be prepared for refresh tokens = rotation). Whether the client asks for more all or just a specific token = (to start with), is a different question.=20 >=20 > > The single token case turns into a single unnamed access token with = the same semantics.=20 >=20 > >=20 > >>=20 > >> I think a further element =E2=80=9Etoken=E2=80=9C element within = the resource structure could also be used to denote the assignment of a = certain resource object to this token. Advantage: no need to change the = syntax. What do you think about this approach? > >=20 > > That=E2=80=99s an interesting idea, and I can see the advantage of a = simpler syntax on the surface =E2=80=A6 but at first shake I see a = couple problems with it. First, this presumes you=E2=80=99d always be = sending a full resource object. If you=E2=80=99re sending a scope string = (or a resource handle in XYZ terms), then you don=E2=80=99t have = anywhere to put the name of the token since it=E2=80=99s no longer an = object. >=20 > That=E2=80=99s certainly true.=20 >=20 > > Second, there=E2=80=99s no clear way to combine multiple resource = facets into a single token. >=20 > Why, just use the same label. >=20 > > And third, you now have to handle a whole bunch of new error cases: = what if some of the resource request objects have names, and others = don=E2=80=99t? What if you use the same name on multiple resource = request objects? If that means you combine them into a single token, = you=E2=80=99re back at the question above about audience restrictions. >=20 > You need to solve that anyway. I feel my proposal above is more = suitable.=20 >=20 > > And finally, it changes the semantics of the resource object in a = way that a simple client would have to at least know about, and be able = to deal with the AS=E2=80=99s different error conditions. > >=20 > > Your thoughts on these points? I might be missing something obvious = with what you=E2=80=99re suggesting. >=20 > I=E2=80=99m still struggling to understand why a client should ask for = a certain assignment of resources. I think it=E2=80=99s basically the AS = in enforcing a certain security policy. The client (on top of that) = might ask for less powerful access tokens within the boundaries defined = by the AS.=20 >=20 > >=20 > > Thanks for the feedback! >=20 > Happy to do so. It=E2=80=99s an important topic waiting for an = interoperable solution. I think we need to introduce a clear indication = of boundaries between resource servers (or security domains or whatever = you want to call it) in oder to solve that.=20 >=20 > best regards, > Torsten.=20 >=20 > >=20 > > =E2=80=94 Justin > >=20 > >>=20 > >> best regards, > >> Torsten. > >>=20 > >>> Am 13.03.2020 um 23:13 schrieb Justin Richer >: > >>>=20 > >>> =EF=BB=BFI took some time to implement an idea that was tossed out = on the list here recently, and that=E2=80=99s how we might support = requests and responses for multiple access tokens. I=E2=80=99ve got a = method that I think works pretty well without getting in the way of the = common, simple case of requesting a single access token. I=E2=80=99ve = implemented this in our Java implementation of XYZ and I=E2=80=99ve = updated the https://oauth.xyz/ website with more = details. I=E2=80=99ll update my ID spec text when I get a chance to = reflect this, but I wanted to start this discussion first. Everything in = here is based on the XYZ protocol. > >>>=20 > >>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request = is an array of items: > >>>=20 > >>> resources: [ > >>> { > >>> actions: ["read", "write", "dolphin"], > >>> locations: ["https://server.example.net/ = ", "https://resource.local/other = "], > >>> datatypes: ["metadata", "images"] > >>> }, > >>> { > >>> actions: ["foo", "bar", "dolphin"], > >>> locations: ["https://resource.other/ = "], > >>> datatypes: ["data", "pictures"] > >>> } > >>> ] > >>>=20 > >>> This tells the AS that the client is asking for a single access = token with multiple, perhaps orthogonal sets of access. This is in = parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this. > >>>=20 > >>> resources: { > >>> token1: [{ > >>> actions: ["read", "write", "dolphin"], > >>> locations: ["https://server.example.net/ = ", "https://resource.local/other = "], > >>> datatypes: ["metadata", "images"] > >>> }], > >>> token2: [{ > >>> actions: ["foo", "bar", "dolphin"], > >>> locations: ["https://resource.other/ = "], > >>> datatypes: ["data", "pictures"] > >>> }] > >>> } > >>>=20 > >>> The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this: > >>>=20 > >>> { > >>> access_token: { > >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >>> type: "bearer" > >>> } > >>> } > >>>=20 > >>> Or multiple access tokens in a tx response like this: > >>>=20 > >>> { > >>> multiple_access_tokens: { > >>> token1: { > >>> value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >>> type: "bearer" > >>> }, > >>> token2: { > >>> value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > >>> type: "bearer" > >>> } > >>> } > >>> } > >>>=20 > >>> These fields are mutually exclusive, so you either get a single = unnamed token or a set of named tokens. Since the client pics the labels = for the access tokens, it=E2=80=99s clear which part of the request maps = to which part of the response. It=E2=80=99s more complexity for the = client to track, but that complexity is only seen and borne by clients = that need it. Simple clients get to stay simple while letting a complex = problem get solved.=20 > >>>=20 > >>> A note about the polymorphic JSON that=E2=80=99s in user here, = though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. = For those unfamiliar with the concept, this is when a given field can = have a value that takes multiple different types: a string, a boolean, = an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2. > >>>=20 > >>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ] > >>>=20 > >>> Polymorphic JSON is great for things like this because it means = you don=E2=80=99t have to have multiple fields and normative rules for = mutual exclusivity, like we=E2=80=99d have to have otherwise. The type = switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it. > >>>=20 > >>>=20 > >>>=20 > >>> People have been asking for a good way to do multiple access = tokens with OAuth for years, but we=E2=80=99ve never had a good or clean = way to pull it off because of OAuth=E2=80=99s model and the assumptions = that it makes. I think TxAuth gives us the opportunity to solve this in = a way that=E2=80=99s consistent with the rest of the protocol, and do so = in a way that doesn=E2=80=99t make the simple cases we know and love too = complicated for average developers. > >>>=20 > >>> =E2=80=94 Justin > >>>=20 > >>> --=20 > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth = > >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_6007DB68-AB0A-446B-B463-F9F596858707 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi David,

My take on this is that in order for a client to be able to = throw out sub-components of its access by using, say, token revocation, = you=E2=80=99d need to ask for separate tokens from the start. I think = the multiple bank accounts scenario you lay out below is exactly that = kind of thing =E2=80=94 you ask for three different bank accounts from = one bank, so they all have the same RS but different access information. = Otherwise, you=E2=80=99re really just talking about refreshing an = existing access token with fewer rights than it started out as =E2=80=94 = at least, if I=E2=80=99m understating the second scenario below. = That=E2=80=99s a bit weird but in an interesting way: So far in the = OAuth world just about everything is additive, since that=E2=80=99s = usually what people care about in practice. Stepping up AuthZ and only = asking for more than you=E2=80=99ve already gotten the OK for. Refreshes = are explicitly allowed to downscope without prompting the user, and I = had that in mind with the transaction refresh. I think that there=E2=80=99= s more we could do with this, including adoption of the per-access-token = management API idea that=E2=80=99s been floated in the XYZ writeup (not = in the spec or implementation yet, mind you).

As for discovery, I think XAuth=E2=80=99s= idea of allowing OPTIONS is a good one, but I would restrict it to = being an OPTONS call on the Transaction Endpoint instead of the matrix = in the current proposal. This way, the client still only has one URL to = start things with at the AS. Right now in XYZ we=E2=80=99ve got the = =E2=80=9Ccapabilities=E2=80=9D array to communicate that kind of = information as well, and that could be a factor too. I=E2=80=99m not = sure though because I haven=E2=80=99t really played with it in = implementation yet. As the OAuth 2 mix-up attack showed us, server = discovery can be a little tricky to get right in a secure way.

 =E2=80=94 = Justin

On Mar 14, 2020, at = 5:56 PM, David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

This is an interesting idea, and one = which I think would be a useful addition to the protocol. As you've = mentioned, it will be incredibly important to define it in a way that = enables the simpler use cases to remain simple, and not be complicated = by this additional optional feature.

With regards to Torsten's question: "What would be the client=E2=80=99s motivation to split = resources to different access tokens?"
I'm involved in = the implementation of Open Banking within the United Kingdom and I can = certainly think of scenarios in Open Banking where the client app would = be able to provide a better user experience if they could offer the = ability to revoke permissions at a fine-grained level, rather than the = user having to revoke "all or nothing". For example, if a user has = provided a third-party provider with access to their current account = balance, account name, and account transactions, at a later point they = may want to revoke third-party provider access to their transactions but = keep the other permissions active - enabling the client app to split the = resources to between different access tokens would provide that = ability.

Related to = the above example, within the context of Open Banking in the UK, we also = have the scenario where a user is able to select which of their bank = accounts they want to be included within the scope of an authorisation = at the point when the user is interacting directly with the = Authorization Server (i.e. after the client has already sent the initial = back-channel request to the AS containing details of the requested = resources, and with this new feature we're discussing here, the details = of the access token split) - it would be very desirable (for similar = reasons to above example) to have one access token per bank account = rather than one access token covering all of their bank accounts, to = enable the user to revoke access to each account individually. This = might be out of scope of this particular discussion, but within the = context of XYZ and within the context of this multiple access token = proposal, would there be any way to assign different access tokens to = elements of the authorisation that are selected by the user AFTER the = initial back-channel request between the client and the AS?

One final question from me on this: I'm = assuming that it would be optional for Authorization Servers to support = multiple access tokens and so what would be the mechanism for the client = to determine if the AS supports it, and what would be the response back = if a client tries to utilise a feature such as this that the AS doesn't = support?

Many Thanks,
David = Skaife

On Sat, Mar 14, 2020 at 4:33 PM Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:
Hi Justin,

> On 14. Mar 2020, at 14:07, Justin Richer <jricher@mit.edu> wrote:
>
> On Mar 14, 2020, at 6:04 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>
>> =EF=BB=BF
>> Hi Justin,
>>
>> I have always been a fan of multiple access tokens support :-) = So thanks you for bringing this forward.
>
> Yes! It=E2=80=99s only taken us another 10 years to get back here = again. :)
>

yep. Just an example ;-): https://mailarchive.ietf.org/arch/msg/oauth/JcKGhoKy2S_2gAQ2ilM= xCPWbgPw/

>>
>> Some questions:
>>
>> Do you assume the client can freely allocated resources to = access tokens? How would that work with audience-restricted/specific = access tokens?
>
> In the syntax I=E2=80=99m proposing, the client can take any set of = resources and ask for it to go with one token. Basically, each named = element of the resources object in the multi-token request syntax is = exactly the same as a single token request would be, an array of = resource requests. So yes, the client can mix and match as it sees fit, = and the AS can reject a request for combining two different audiences in = the same token. The AS would need to do that anyway for a single token = request, so I don=E2=80=99t see that as a greater burden =E2=80=94 = it=E2=80=99s just that now the client can fulfill the requirements = without making multiple transaction requests.

What would be the client=E2=80=99s motivation to split resources to = different access tokens?
What information would the client use to allocate the resources to the = appropriate access tokens?

In my experience, it is the AS (or the security policy of the = deployment) that determines what can go into a single access token.

One policy is to allow everything to go into a single access token. That = might work in a single RS deployment. In a multi RS deployment, one = would either end up with tokens containing the set union of all data = needed by all RSs. Encryptions of those tokens might be complex, I = don=E2=80=99t know whether this is privacy preserving. The other option = is to use token introspection or other callbacks to the AS to obtain the = real data needed for access control per RS, not very performant.

Another possible policy is to have access tokens that at most contain = data for a certain resource server. This helps privacy (no implicit data = sharing among resource servers) and security (single audience, = encryption is straightforward, simple token replay prevention). But = someone needs to know the boundaries.

If the client knows the boundaries, all it would need to ask the AS for = is to issue access tokens for a set of recipients. This could be done in = parallel to the resources structure.

Something like this:

{
   "resources":[
      {
         "actions":[
            "read",
            "write",
            "dolphin"
         ],
         "locations":[
            "https://server.example.net/",
            "https://resource.local/other"
         ],
         "datatypes":[
            "metadata",
            "images"
         ]
      },
      {
         "actions":[
            "read"
         ],
         "locations":[
            "https://server1.example.net/"
         ],
         "datatypes":[
            "contacts"
         ]
      }
   ],
   "tokens":[
      "https://server.example.net/",
      "https://server1.example.net/"
   ]
}

The default could be that the AS issues an access token good for all = granted resources.

One could also go one step further and let the AS decide what access = tokens it would issue and add metadata about the recipients to the = response.

{
   "access_tokens":[
      {
         "destination":"https://server.example.net/"",
        =  "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
         "type":"bearer"
      },
      {
         "destination":"https://server1.example.net/",
        =  "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT1",
         "type":"bearer"
      }
   ],
   "handle":{
      "value":"80UPRY5NM33OMUKMKSKU",
      "type":"bearer"
   },
   "claims":{
      "subject":"UR64TB8N6BW7OZB8CDFONP-MHKUR6",
      "email":"alice@example.com"
   }
}

I personally think this would even better fit the transactional = character of the new protocol.

>
> This syntax doesn=E2=80=99t allow the AS to assign multiple tokens = to a client=E2=80=99s simple request, but I actually like that feature. = If the client is capable of dealing with multiple tokens simultaneously, = it can ask for them.

I think that=E2=80=99s the important aspect! In my opinion, the AS = basically decides whether different tokens are required for different = resources. I therefore think all client must be prepared to use = different tokens to use the privileges granted in a certain transaction = (in the same way OAuth 2 clients must be prepared for refresh tokens = rotation). Whether the client asks for more all or just a specific token = (to start with), is a different question.

> The single token case turns into a single unnamed access token with = the same semantics.

>
>>
>> I think a further element =E2=80=9Etoken=E2=80=9C element = within the resource structure could also be used to denote the = assignment of a certain resource object to this token. Advantage: no = need to change the syntax. What do you think about this approach?
>
> That=E2=80=99s an interesting idea, and I can see the advantage of = a simpler syntax on the surface =E2=80=A6 but at first shake I see a = couple problems with it. First, this presumes you=E2=80=99d always be = sending a full resource object. If you=E2=80=99re sending a scope string = (or a resource handle in XYZ terms), then you don=E2=80=99t have = anywhere to put the name of the token since it=E2=80=99s no longer an = object.

That=E2=80=99s certainly true.

> Second, there=E2=80=99s no clear way to combine multiple resource = facets into a single token.

Why, just use the same label.

> And third, you now have to handle a whole bunch of new error cases: = what if some of the resource request objects have names, and others = don=E2=80=99t? What if you use the same name on multiple resource = request objects? If that means you combine them into a single token, = you=E2=80=99re back at the question above about audience = restrictions.

You need to solve that anyway. I feel my proposal above is more = suitable.

> And finally, it changes the semantics of the resource object in a = way that a simple client would have to at least know about, and be able = to deal with the AS=E2=80=99s different error conditions.
>
> Your thoughts on these points? I might be missing something obvious = with what you=E2=80=99re suggesting.

I=E2=80=99m still struggling to understand why a client should ask for a = certain assignment of resources. I think it=E2=80=99s basically the AS = in enforcing a certain security policy. The client (on top of that) = might ask for less powerful access tokens within the boundaries defined = by the AS.

>
> Thanks for the feedback!

Happy to do so. It=E2=80=99s an important topic waiting for an = interoperable solution. I think we need to introduce a clear indication = of boundaries between resource servers (or security domains or whatever = you want to call it) in oder to solve that.

best regards,
Torsten.

>
>  =E2=80=94 Justin
>
>>
>> best regards,
>> Torsten.
>>
>>> Am 13.03.2020 um 23:13 schrieb Justin Richer <jricher@mit.edu>:
>>>
>>> =EF=BB=BFI took some time to implement an idea that was = tossed out on the list here recently, and that=E2=80=99s how we might = support requests and responses for multiple access tokens. I=E2=80=99ve = got a method that I think works pretty well without getting in the way = of the common, simple case of requesting a single access token. I=E2=80=99= ve implemented this in our Java implementation of XYZ and I=E2=80=99ve = updated the https://oauth.xyz/ website with more = details. I=E2=80=99ll update my ID spec text when I get a chance to = reflect this, but I wanted to start this discussion first. Everything in = here is based on the XYZ protocol.
>>>
>>> Normally, the =E2=80=9Cresources=E2=80=9D element of a tx = request is an array of items:
>>>
>>> resources: [
>>>     {
>>>             actions: = ["read", "write", "dolphin"],
>>>             locations: = ["https://server.example.net/", "https://resource.local/other"],
>>>             datatypes: = ["metadata", "images"]
>>>         },
>>>     {
>>>             actions: = ["foo", "bar", "dolphin"],
>>>             locations: = ["https://resource.other/"],
>>>             datatypes: = ["data", "pictures"]
>>>         }
>>> ]
>>>
>>> This tells the AS that the client is asking for a single = access token with multiple, perhaps orthogonal sets of access. This is = in parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this.
>>>
>>> resources: {
>>>     token1: [{
>>>             actions: = ["read", "write", "dolphin"],
>>>             locations: = ["https://server.example.net/", "https://resource.local/other"],
>>>             datatypes: = ["metadata", "images"]
>>>      }],
>>>      token2: [{
>>>             actions: = ["foo", "bar", "dolphin"],
>>>             locations: = ["https://resource.other/"],
>>>             datatypes: = ["data", "pictures"]
>>>      }]
>>> }
>>>
>>> The client could request multiple kinds of access within = each sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D= and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this:
>>>
>>> {
>>>         access_token: {
>>>             value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>>>             type: = "bearer"
>>>         }
>>> }
>>>
>>> Or multiple access tokens in a tx response like this:
>>>
>>> {
>>>     multiple_access_tokens: {
>>>           token1: {
>>>             value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>>>             type: = "bearer"
>>>           },
>>>           token2: {
>>>             value: = "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
>>>             type: = "bearer"
>>>           }
>>>     }
>>> }
>>>
>>> These fields are mutually exclusive, so you either get a = single unnamed token or a set of named tokens. Since the client pics the = labels for the access tokens, it=E2=80=99s clear which part of the = request maps to which part of the response. It=E2=80=99s more complexity = for the client to track, but that complexity is only seen and borne by = clients that need it. Simple clients get to stay simple while letting a = complex problem get solved.
>>>
>>> A note about the polymorphic JSON that=E2=80=99s in user = here, though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol = design. For those unfamiliar with the concept, this is when a given = field can have a value that takes multiple different types: a string, a = boolean, an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2.
>>>
>>> resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ]
>>>
>>> Polymorphic JSON is great for things like this because it = means you don=E2=80=99t have to have multiple fields and normative rules = for mutual exclusivity, like we=E2=80=99d have to have otherwise. The = type switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it.
>>>
>>>
>>>
>>> People have been asking for a good way to do multiple = access tokens with OAuth for years, but we=E2=80=99ve never had a good = or clean way to pull it off because of OAuth=E2=80=99s model and the = assumptions that it makes. I think TxAuth gives us the opportunity to = solve this in a way that=E2=80=99s consistent with the rest of the = protocol, and do so in a way that doesn=E2=80=99t make the simple cases = we know and love too complicated for average developers.
>>>
>>>  =E2=80=94 Justin
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
= >

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_6007DB68-AB0A-446B-B463-F9F596858707-- From nobody Sun Mar 15 00:30:21 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2FE3A112F for ; Sun, 15 Mar 2020 00:30:19 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 DMV_mkNDrzrZ for ; Sun, 15 Mar 2020 00:30:18 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.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 A9BA53A112E for ; Sun, 15 Mar 2020 00:30:18 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id DNiyjQVSvcUOqDNizjCIPT; Sun, 15 Mar 2020 00:30:18 -0700 X-CMAE-Analysis: v=2.3 cv=E/WzWpVl c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=dU1ZAqS2czFxQ7Cajb0A:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 X-SECURESERVER-ACCT: vladimir@connect2id.com To: txauth@ietf.org References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <21fc2c0f-5178-1ff7-a8d3-5b53b2c0ab8e@connect2id.com> Date: Sun, 15 Mar 2020 09:30:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030605000808000208070306" X-CMAE-Envelope: MS4wfPQVKBT6T/PyhuRSlHaXBOkaKeVB4UgkGb1Oa6wEdPXf3GvkvuI9eBZvsKb3lmhzR4PkNkLLNxwp+T3QducsqxEy4U/pu1s8bZ849TiX1DKsQDgT+8OP dlXseR2PIWYB/mSHWqSxW36m81tGsxFQFcKvguG0tsyG64W80kD5Wm+t Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 07:30:20 -0000 This is a cryptographically signed message in MIME format. --------------ms030605000808000208070306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 15/03/2020 04:35, Justin Richer wrote: > Refreshes are explicitly allowed to downscope without prompting the > user, and I had that in mind with the transaction refresh. I think > that there=E2=80=99s more we could do with this, including adoption of = the > per-access-token management API idea that=E2=80=99s been floated in the= XYZ > writeup (not in the spec or implementation yet, mind you). Speaking of downscoping refreshes, what we found lacking in OAuth 2.0 is that it works only for scope values and there's no way to reduce the OpenID claims. Vladimir --------------ms030605000808000208070306 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMTUwNzMwMTZaMC8G CSqGSIb3DQEJBDEiBCBWWm9jhotkxNfi/4NcJl/9LW76xLv7gk5rXOLSp+iFsDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAAWQxY58zJm95ITtYqiUqksfWVrAvOSIElj+LcBBeTdVuDzf hsdC2hMIKHe6SeG6UYCSgm4ZGV60Vl460r5VpW7JDY2KCArH8Zc1hw3LzV3MO2YyDU+IS95g iwudLnK+qPZi8hvr/IUPHs9YMebvPPecl2KfmMc797dnC95G9C/5YW7X9VjF5KrqjEpWLYmY zyUMYs1ScvfjMD30ojtXaekvwuU9Dn82jZG5GxTs8amhKhORN85AzsO/gzff04Cve5S0CWdO xJ1WruGfVyX6KWQRjMEq2XZm1s8NuHkJlN8E4NNebFKTqMlAqytj1rm3jKQr7U1lkxUlj69t HerJWtIAAAAAAAA= --------------ms030605000808000208070306-- From nobody Sun Mar 15 05:58:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208103A15CE for ; Sun, 15 Mar 2020 05:58:21 -0700 (PDT) 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 dOikMf-2TOm8 for ; Sun, 15 Mar 2020 05:58:20 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450: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 A74BE3A15CC for ; Sun, 15 Mar 2020 05:58:19 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id w16so1385807wrv.13 for ; Sun, 15 Mar 2020 05:58:19 -0700 (PDT) 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=7n6tOjEaIe3N7NgewIsrVTcU3YosRy/593dt6RJlgvg=; b=GBlj8Aad2HsBqhhvqioEUBuCepiE0dW5VpokTOIuN7ggaDAJhetdsDJVAXcRJjJ67K 5wKYP4e0T2vLAHzaZaesInuZ4Z2Pm07SpVMXSsCQdJ64+ZRYUCuP5ilek6ky3R59arYp LaPGonN/23qN206e1zgDieT7ApIkI9RGPDW1GoENfyZPExlO6rpPaL7j3ZTUPnvKpYbD YxKXo1BYGOtjijIh4BLIK5fRjoqaC0HlqoATcS3v3YicdblT1n+0wPXIMMGE/ROMm2X6 W07HLDkqGEqOuWOkr+D44rdThDVToluWDKJhjp0eLMwqJZFQB3pV0N3T8KIzAwW7PGWY 6mkQ== 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=7n6tOjEaIe3N7NgewIsrVTcU3YosRy/593dt6RJlgvg=; b=R+c8Um/CmgQ34/0a3FmCtJT8Vh/XsX8WY4TRn5Emaxpi9UAikIoJ1spLt6g6VycGcp sEebyCi3ddsdPxtog9IRXqmAXFcSs0cUfz48dqW7tCJvJl6pDlCBehRGkwPuAjL8rOGB gJEl0A4BGAY4npt/lq/BCo4jsd2PI7SkOipiJXsS38M2vst1j2YEWMQAD1SvDZDWmnve hnWzS8tTf24AilgwGYMP+fEwok3DVBSO1iIW1I7iwh4Ko2KRMzgdBgd1yqJ84u1AW+M8 bki8w0D1W3omtZdMuBTT7LyavJh3PoTqAYSUG+yJDSEdqx0rswPek0uxJn6xN5e4Nx8a fJpQ== X-Gm-Message-State: ANhLgQ0o3FbL1ey+vdFAqWzrX37LelS2IFQUA5FMwA9DhDomxwlu0RN9 /qOlGBDnRu9rf+siBw+luqqWD6AqwcU= X-Google-Smtp-Source: ADFU+vs48nRz9F6xv7sNYxcOKzbXAUvgevsAResJJsAYiJZGKpMHLxlb6bzkB8AuDwkO90SX5Gwong== X-Received: by 2002:adf:ed0d:: with SMTP id a13mr29245119wro.167.1584277097643; Sun, 15 Mar 2020 05:58:17 -0700 (PDT) Received: from p200300eb8f2625975d018a55e3e5304e.dip0.t-ipconnect.de (p200300EB8F2625975D018A55E3E5304E.dip0.t-ipconnect.de. [2003:eb:8f26:2597:5d01:8a55:e3e5:304e]) by smtp.gmail.com with ESMTPSA id c72sm24920451wme.35.2020.03.15.05.58.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Mar 2020 05:58:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Sun, 15 Mar 2020 13:58:15 +0100 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 12:58:22 -0000 > On 15. Mar 2020, at 03:25, Justin Richer wrote: >=20 > So if the AS needs a client to get different access tokens to call = different RS domains, it does exactly what we do in OAuth 2 today =E2=80=94= it tells the client to get two different access tokens.=20 How does this work in XYZ? From nobody Sun Mar 15 07:26:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C923A1726 for ; Sun, 15 Mar 2020 07:26:26 -0700 (PDT) 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 jgZapr-3ARNQ for ; Sun, 15 Mar 2020 07:26:25 -0700 (PDT) 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 640573A1724 for ; Sun, 15 Mar 2020 07:26:25 -0700 (PDT) Received: from [192.168.1.5] (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 02FEQNIj022562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Mar 2020 10:26:23 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> Date: Sun, 15 Mar 2020 10:26:23 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2020 14:26:27 -0000 On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt = wrote: >=20 >> On 15. Mar 2020, at 03:25, Justin Richer wrote: >>=20 >> So if the AS needs a client to get different access tokens to call = different RS domains, it does exactly what we do in OAuth 2 today =E2=80=94= it tells the client to get two different access tokens.=20 >=20 > How does this work in XYZ? >=20 Without using the multi-access-token thing I=E2=80=99m proposing in this = thread, the client would just make two separate transaction calls to get = two different tokens. There=E2=80=99s a few ways that shakes out = depending on some of the details. In the OAuth world that amounts to = involving the user twice, and it might be the same in XYZ if you=E2=80=99r= e asking for different things: 1. Client: Start TX-1 (R-1) 2. User: Approve R-1 3. AS: Issue AT-1(R-1) 4. Client: Start TX-2 (R-1) 5. User: approve R-2 6. AS: Issue AT-2(R-2) Unless you=E2=80=99re getting a super refresh token upfront and then = calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can = do that trick too. 1. Client: Start TX-1 (R-1, R-2) 2. User: Approve R-1, R-2 3. AS: Issue AT1 (R-1, R-2) 4. Client: Continue TX-1 (R-2) 5. AS: Issue AT-2 (R-2) But we=E2=80=99ve got another thing we can use in XYZ to help this, the = user handle. This lets a trusted client tell the AS that it believes the = same user is still there and asking the question, so if the access = rights are OK then you don=E2=80=99t need to involve the user again. We = invented this construct with UMA2, where it=E2=80=99s called the = persisted claims token (PCT). 1. Client: Start TX-1 (R-1) 2. User: Approve R-1 3. AS: Issue AT-1 (R-1), user handle U-1 4. Client Start TX-2 (R-2, U-1) 5. AS: Issue AT-2 (R-2) Now: With the multi-token request, we can collapse this all back to a = single transaction with multiple outputs: 1. Client: Start TX-2 (token1: R-1, token2: R-2) 2. User Approve R-1, R-2 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) I haven=E2=80=99t liked any of the multi-access-token solutions to date = because they make things weird for single access token requests. I like = this idea because it=E2=80=99s an optimization for a complex case that = doesn=E2=80=99t change the behavior for the simple case, and in fact = doesn=E2=80=99t even change the expectations for the simple case. To me, = that=E2=80=99s important. =E2=80=94 Justin= From nobody Mon Mar 16 06:50:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3B3A087E for ; Mon, 16 Mar 2020 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 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, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=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 MorRKhrJb3Pk for ; Mon, 16 Mar 2020 06:50:22 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 121FC3A087D for ; Mon, 16 Mar 2020 06:50:21 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id d8so26218236qka.2 for ; Mon, 16 Mar 2020 06:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=LmIehjk+1uOMP6ttSnpQOrAHcEOse1SMnSdqwB2meb4=; b=vT3T+Sd1mLgSjhJ/nt1ZxnywquLSes5UyFJ1pLqoVHNA3so0w+hUiUaxj8oxkKUfy7 FCFxlZhHx4jMPPjSwLywgOYW3RxPHLtsBzolWwd1/j7zNGb0LsHt9BcHyUYWm8xBDFf7 52VIACFWys5PsX6I+jc6jFQpgj9tPgWhx4EwFk7tGp/YdXwTvMuMxW5mSXwd6QgwEEQJ 3I69WyK8KExpZJEVHKfcqr8pAwz+LhWKicBwrhstevALDBAYT1I4nQteAzmw+3mPMIzE W8dYsJByxYrujGk4fnj30pbwrrBvXTEFCjg6o6BmP8Mi2wTGQDgFLA42tKZsEur2GFOT JRcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=LmIehjk+1uOMP6ttSnpQOrAHcEOse1SMnSdqwB2meb4=; b=k3sUYKTI9GrZ/+s93gKp3FG5HV6J9DXaWa1VdxNSB1A25F5inFr/6Qkrubc/61tURq suUDRRcZ05o0m94Y4PYBdiYFZBfzg9cf8I0MVoMM8hl1n8SqwjaOwXhBMwwqb/uf0AWP jT0eFdWZZRYN3d3GLyZRyYQmou1OHbh3zuZBtE8+O9ZXDYt3tFUgCdlshtS+NHnH6I7e KP7qNFqQycngiWsHceImB0rh7iWF2k4uJbQxv/y7vbxrcl0WCEI2WdRazVN2Q2uYrCr0 o/0C1kWInjvbvxishqyAByGAta6rRwaXkzuTX7OLukbo/8sk0fGbnRFlbQMjQXiDxI46 XL9A== X-Gm-Message-State: ANhLgQ3lSDd6fkZi/wIDrM8tr/bpY30Bcof11hWqUu3ryy/qQIBhgHOW l1PLLuvPtF8t8E8U+ADjPsRXRNWi X-Google-Smtp-Source: ADFU+vs18C+cYyhClQ0xY0jOj8jwggMdGX3I1VQwjLoGQpzyzfpFPKkUSX05egOUWiFZ6qDBWmHK1g== X-Received: by 2002:a37:a614:: with SMTP id p20mr26570073qke.114.1584366620231; Mon, 16 Mar 2020 06:50:20 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id m1sm14785762qtm.22.2020.03.16.06.50.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2020 06:50:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Mon, 16 Mar 2020 15:50:17 +0200 From: Yaron Sheffer To: "txauth@ietf.org" Message-ID: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> Thread-Topic: Reminder: Call for charter consensus - TxAuth WG Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 13:50:24 -0000 Here's a quick reminder: if you haven't responded to the call yet, please d= o so soon. Thanks, Yaron =EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" wrote: Hi Everyone, =20 It appears that momentum is forming around the proposed formation of a = TxAuth working group. We=E2=80=99d like to more formally gauge interest in procee= ding with this work. Please do so by responding to the following questions: =20 1. Do you support the charter text provided at the end of this email? = Or do you have major objections, blocking concerns or feedback (if so pleas= e elaborate)? =20 2. Are you willing to author or participate in the development of the = drafts of this WG? =20 3. Are you willing to help review the drafts of this WG? =20 4. Are you interested in implementing drafts of this WG? =20 The call will run for two weeks, until March 21. If you think that the = charter should be amended In a significant way, please reply on a separate t= hread. =20 The feedback provided here will help the IESG come to a decision on the= formation of a new WG. Given the constraints of the chartering process, reg= ardless of the outcome of this consensus call, we will be meeting in Vancouv= er as a BoF. =20 Thanks, Yaron and Dick =20 --- Charter Text Follows --- =20 This group is chartered to develop a fine-grained delegation protocol f= or authorization, identity, and API access. This protocol will allow an auth= orizing party to delegate access to client software through an authorization= server. It will expand upon the uses cases currently supported by OAuth 2.0= and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework f= or interaction among all parties involved in the protocol flow, and remove u= nnecessary dependence on a browser or user-agent for coordinating interactio= ns.=20 =20 The delegation process will be acted upon by multiple parties in the pr= otocol, each performing a specific role. The protocol will decouple the inte= raction channels, such as the end user=E2=80=99s browser, from the delegation chan= nel, which happens directly between the client and the authorization server = (in contrast with OAuth 2.0 which is initiated by the client redirecting the= user=E2=80=99s browser). The client and AS will involve a user to make an authori= zation decision as necessary through interaction mechanisms indicated by the= protocol. This decoupling avoids many of the security concerns and technica= l challenges of OAuth 2.0 and provides a non-invasive path for supporting fu= ture types of clients and interaction channels. =20 Additionally, the delegation process will allow for: =20 - Fine-grained specification of access - Approval of AS attestation to identity claims - Approval of access to multiple resources and APIs in a single interac= tion - Separation between the party authorizing access and the party operati= ng the client requesting access - A variety of client applications, including Web, mobile, single-page,= and interaction-constrained applications =20 The group will define extension points for this protocol to allow for f= lexibility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of poss= ession=20 - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other piec= es of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding reso= urce requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation = process (including identity) =20 Additionally, the group will provide mechanisms for management of the p= rotocol lifecycle including: =20 - Discovery of the authorization server - Revocation of active tokens - Query of token rights by resource servers =20 Although the artifacts for this work are not intended or expected to be= backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attem= pt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc= ol where possible. =20 This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily compatible wi= th OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develo= ped in the OAuth Working Group, including functionality back-ported from the= protocol developed here to OAuth 2.0. =20 The group is chartered to develop mechanisms for applying cryptographic= methods, such as JOSE and COSE, to the delegation process. This group is no= t chartered to develop new cryptographic methods.=20 =20 The initial work will focus on using HTTP for communication between the= client and the authorization server, taking advantage of optimization featu= res of HTTP2 and HTTP3 where possible, and will strive to enable simple mapp= ing to other protocols such as COAP when doing so does not conflict with the= primary focus. =20 Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol for TLS, de= tached HTTP signature, and embedded HTTP signatures - Identity and authentication conveyance mechanisms - Guidelines for use of protocol extension points =20 =20 =20 From nobody Mon Mar 16 08:28:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9603A0A29 for ; Mon, 16 Mar 2020 08:28:54 -0700 (PDT) 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_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=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 LHuXE9La-XyC for ; Mon, 16 Mar 2020 08:28:52 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 39D303A0A28 for ; Mon, 16 Mar 2020 08:28:52 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 19so19107957ljj.7 for ; Mon, 16 Mar 2020 08:28:52 -0700 (PDT) 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=LQOAfH31a0E5SXD2mm0g8JxywUAPRizLsg0fald8YiY=; b=h6ErnGyK9ztioezMgNnu73e5FRDP8KCkAohk9z6qe1tYTDqNwKPK35xexZaSGJzLzi 0/WWfxzgIVGpiYQJECmFn9lKOhEsM3GgG37kqmyBPkpyvTWrENNkvz8YHk5Zc8c2D8Ne IbLyQEb1XmKM5t+ZG1NSFCJPKeBy24sOHs3Xs2r9wWBq4h5n+ieb1e7WRM/y7kFD6bOY Ds6jxw/yeLIN6yHf/qEFxwIeZxQ9UFg4YJIYLSrV4DfmUYnorifYogi2h6skXpl1TMFE 1StHVti63F1DAK6AsPElZ3d6t/yqinZ3hVy8GQalMzz6ikMCfWdDqpTQN/n3Ads7sIZ6 b0xg== 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=LQOAfH31a0E5SXD2mm0g8JxywUAPRizLsg0fald8YiY=; b=q23p4agMAfpABx7TUsOCBTW9HIcimle4dFW8XQZP7JPogDiYHAueJOqKA5euyxgNYh cSJZ9LkkblvjaOhDYJ7vEgMU2r3eu7J9RpCTVwybo+P/zmaYMAy6PHI2o5zUiQAn8HTB 9sEIdo7zE3AayyyprK7s5CLSplCsHrAAPGqwWizQnnWgGmPVYlVqcOkPwZi5yCvxk3TK xiFEpYb1mOQbynMQr8ZS8hljgGK0RjrnbnVPVuSdm1Q9NzLdUXlWUlfMilSjcBN4wF0E lbph9BoeW1Fvde3ismNDGyzNLeFxWfbAaTgFYqeX6EX2IqSi5vrqSoGEvQDJpSq3fche unZA== X-Gm-Message-State: ANhLgQ20lBpjsgRglFmjHMkOEXBYOlxcecGPmBtp0ky2zPAcEkb/dwc/ VNGSh5bp69EwoVt3/3refWsYBCnZLRVO1X2uq56uogwn X-Google-Smtp-Source: ADFU+vvhLTxHulpH0CrJj9uaBdfbW5ozFlbuE9CUBZ3brgKW83Ccxx7JTvl6Lzf1Symas3bk3FXWH6/re4Nw65q4/9g= X-Received: by 2002:a2e:8518:: with SMTP id j24mr16835377lji.138.1584372530117; Mon, 16 Mar 2020 08:28:50 -0700 (PDT) MIME-Version: 1.0 References: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> In-Reply-To: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> From: Dick Hardt Date: Mon, 16 Mar 2020 08:28:24 -0700 Message-ID: To: Yaron Sheffer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d998eb05a0fa7901" Archived-At: Subject: Re: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 15:28:55 -0000 --000000000000d998eb05a0fa7901 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes to all 4 questions. =3D) =E1=90=A7 On Mon, Mar 16, 2020 at 6:50 AM Yaron Sheffer wrote= : > Here's a quick reminder: if you haven't responded to the call yet, please > do so soon. > > Thanks, > Yaron > > =EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" wrote: > > Hi Everyone, > > It appears that momentum is forming around the proposed formation of = a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this > email? Or do you have major objections, blocking concerns or feedback (i= f > so please elaborate)? > > 2. Are you willing to author or participate in the development of th= e > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that th= e > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on > the formation of a new WG. Given the constraints of the chartering proces= s, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single > interaction > - Separation between the party authorizing access and the party > operating the client requesting access > - A variety of client applications, including Web, mobile, > single-page, and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegatio= n > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to > be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and a= s > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying > cryptographic methods, such as JOSE and COSE, to the delegation process. > This group is not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between > the client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d998eb05a0fa7901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes to all 4 questions. =3D)
3D""=E1=90=A7

On Mon, Mar 16, 2020 at 6:50 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Here's a quick reminder: if y= ou haven't responded to the call yet, please do so soon.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

=EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrot= e:

=C2=A0 =C2=A0 Hi Everyone,

=C2=A0 =C2=A0 It appears that momentum is forming around the proposed forma= tion of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally ga= uge interest in proceeding with this work.=C2=A0 Please do so by responding= to the following questions:

=C2=A0 =C2=A0 1.=C2=A0 Do you support the charter text provided at the end = of this email?=C2=A0 Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?

=C2=A0 =C2=A0 2.=C2=A0 Are you willing to author or participate in the deve= lopment of the drafts of this WG?

=C2=A0 =C2=A0 3.=C2=A0 Are you willing to help review the drafts of this WG= ?

=C2=A0 =C2=A0 4.=C2=A0 Are you interested in implementing drafts of this WG= ?

=C2=A0 =C2=A0 The call will run for two weeks, until March 21. If you think= that the charter should be amended In a significant way, please reply on a= separate thread.

=C2=A0 =C2=A0 The feedback provided here will help the IESG come to a decis= ion on the formation of a new WG. Given the constraints of the chartering p= rocess, regardless of the outcome of this consensus call, we will be meetin= g in Vancouver as a BoF.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Yaron and Dick

=C2=A0 =C2=A0 --- Charter Text Follows ---

=C2=A0 =C2=A0 This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will al= low an authorizing party to delegate access to client software through an a= uthorization server. It will expand upon the uses cases currently supported= by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to supp= ort authorizations scoped as narrowly as a single transaction, provide a cl= ear framework for interaction among all parties involved in the protocol fl= ow, and remove unnecessary dependence on a browser or user-agent for coordi= nating interactions.

=C2=A0 =C2=A0 The delegation process will be acted upon by multiple parties= in the protocol, each performing a specific role. The protocol will decoup= le the interaction channels, such as the end user=E2=80=99s browser, from t= he delegation channel, which happens directly between the client and the au= thorization server (in contrast with OAuth 2.0 which is initiated by the cl= ient redirecting the user=E2=80=99s browser). The client and AS will involv= e a user to make an authorization decision as necessary through interaction= mechanisms indicated by the protocol. This decoupling avoids many of the s= ecurity concerns and technical challenges of OAuth 2.0 and provides a non-i= nvasive path for supporting future types of clients and interaction channel= s.

=C2=A0 =C2=A0 Additionally, the delegation process will allow for:

=C2=A0 =C2=A0 - Fine-grained specification of access
=C2=A0 =C2=A0 - Approval of AS attestation to identity claims
=C2=A0 =C2=A0 - Approval of access to multiple resources and APIs in a sing= le interaction
=C2=A0 =C2=A0 - Separation between the party authorizing access and the par= ty operating the client requesting access
=C2=A0 =C2=A0 - A variety of client applications, including Web, mobile, si= ngle-page, and interaction-constrained applications

=C2=A0 =C2=A0 The group will define extension points for this protocol to a= llow for flexibility in areas including:

=C2=A0 =C2=A0 - Cryptographic agility for keys, message signatures, and pro= of of possession
=C2=A0 =C2=A0 - User interaction mechanisms including web and non-web metho= ds
=C2=A0 =C2=A0 - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions
=C2=A0 =C2=A0 - Mechanisms for presenting tokens to resource servers and bi= nding resource requests to tokens and associated cryptographic keys
=C2=A0 =C2=A0 - Optimized inclusion of additional information through the d= elegation process (including identity)

=C2=A0 =C2=A0 Additionally, the group will provide mechanisms for managemen= t of the protocol lifecycle including:

=C2=A0 =C2=A0 - Discovery of the authorization server
=C2=A0 =C2=A0 - Revocation of active tokens
=C2=A0 =C2=A0 - Query of token rights by resource servers

=C2=A0 =C2=A0 Although the artifacts for this work are not intended or expe= cted to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group= will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to th= e new protocol where possible.

=C2=A0 =C2=A0 This group is not chartered to develop extensions to OAuth 2.= 0, and as such will focus on new technological solutions not necessarily co= mpatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 wi= ll be developed in the OAuth Working Group, including functionality back-po= rted from the protocol developed here to OAuth 2.0.

=C2=A0 =C2=A0 The group is chartered to develop mechanisms for applying cry= ptographic methods, such as JOSE and COSE, to the delegation process. This = group is not chartered to develop new cryptographic methods.

=C2=A0 =C2=A0 The initial work will focus on using HTTP for communication b= etween the client and the authorization server, taking advantage of optimiz= ation features of HTTP2 and HTTP3 where possible, and will strive to enable= simple mapping to other protocols such as COAP when doing so does not conf= lict with the primary focus.

=C2=A0 =C2=A0 Milestones to include:
=C2=A0 =C2=A0 =C2=A0- Core delegation protocol
=C2=A0 =C2=A0 =C2=A0- Key presentation mechanism bindings to the core proto= col for TLS, detached HTTP signature, and embedded HTTP signatures
=C2=A0 =C2=A0 =C2=A0- Identity and authentication conveyance mechanisms
=C2=A0 =C2=A0 =C2=A0- Guidelines for use of protocol extension points





--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d998eb05a0fa7901-- From nobody Mon Mar 16 09:17:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8673A0C8B for ; Mon, 16 Mar 2020 09:17:03 -0700 (PDT) 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_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=protonmail.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 2hBjB_5kGKX2 for ; Mon, 16 Mar 2020 09:17:00 -0700 (PDT) Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 3DFF03A0C09 for ; Mon, 16 Mar 2020 09:17:00 -0700 (PDT) Date: Mon, 16 Mar 2020 16:16:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1584375417; bh=w+7j//wDZS+N0hODE/EDuIXvxDheENTms2HZ8ENdtdw=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=tOJquEMoo9NapOMFC0vyBpIZAEScwmoEtMDHB16cqJpVmgtHsSG9/QkgVRU+Qp+x0 cw1kLf9ur4foTY00H8dXXoK1yn6MUwn2NFf5f/K25ZTF/kBbYtVJYozLgk+He0gDrk gl1z9QXW8run0kex/0u6Qbd6CdjKQRYSIcNLXoAM= To: yaronf.ietf@gmail.com, txauth@ietf.org From: Partha Reply-To: Partha Message-ID: <3Izg3tUV4ylbt7esAGXvMoFKbHgOCcBaV9Dn1FWJnpgwqzTQIcOgD2yDl04l8v_KMdMhSYy42KAatunmMV0KFCJd0yGTlZASfyMMbfg7C1k=@protonmail.com> In-Reply-To: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> References: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> Feedback-ID: tK0hZ1Qrq3CaPBM8W5xOlDBKtk3Q1PmRNVxncvkQca-ULzly8hMpago2wjFPrFn2xi7KTzYW2TreFR--GkXExA==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_76fb3a45f5510ea72573dbdc7fa5011e" Archived-At: Subject: Re: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 16:17:03 -0000 This is a multi-part message in MIME format. --b1_76fb3a45f5510ea72573dbdc7fa5011e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 WWVzICEgdG8gYWxsIHRoZSBxdWVzdGlvbnMuCgpUaGFua3MsClBhcnRoYQoKU2VudCBmcm9tIFBy b3Rvbk1haWwgbW9iaWxlCgotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tCk9uIDE2 IE1hciAyMDIwLCA3OjIwIHBtLCBZYXJvbiBTaGVmZmVyIDwgeWFyb25mLmlldGZAZ21haWwuY29t PiB3cm90ZToKSGVyZSdzIGEgcXVpY2sgcmVtaW5kZXI6IGlmIHlvdSBoYXZlbid0IHJlc3BvbmRl ZCB0byB0aGUgY2FsbCB5ZXQsIHBsZWFzZSBkbyBzbyBzb29uLgpUaGFua3MsCllhcm9uCu+7v09u IDMvNi8yMCwgMTg6NDQsICJZYXJvbiBTaGVmZmVyIiA8eWFyb25mLmlldGZAZ21haWwuY29tPiB3 cm90ZToKSGkgRXZlcnlvbmUsCkl0IGFwcGVhcnMgdGhhdCBtb21lbnR1bSBpcyBmb3JtaW5nIGFy b3VuZCB0aGUgcHJvcG9zZWQgZm9ybWF0aW9uIG9mIGEgVHhBdXRoIHdvcmtpbmcgZ3JvdXAuIFdl 4oCZZCBsaWtlIHRvIG1vcmUgZm9ybWFsbHkgZ2F1Z2UgaW50ZXJlc3QgaW4gcHJvY2VlZGluZyB3 aXRoIHRoaXMgd29yay4gUGxlYXNlIGRvIHNvIGJ5IHJlc3BvbmRpbmcgdG8gdGhlIGZvbGxvd2lu ZyBxdWVzdGlvbnM6CjEuIERvIHlvdSBzdXBwb3J0IHRoZSBjaGFydGVyIHRleHQgcHJvdmlkZWQg YXQgdGhlIGVuZCBvZiB0aGlzIGVtYWlsPyBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25z LCBibG9ja2luZyBjb25jZXJucyBvciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/ CjIuIEFyZSB5b3Ugd2lsbGluZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhlIGRldmVs b3BtZW50IG9mIHRoZSBkcmFmdHMgb2YgdGhpcyBXRz8KMy4gQXJlIHlvdSB3aWxsaW5nIHRvIGhl bHAgcmV2aWV3IHRoZSBkcmFmdHMgb2YgdGhpcyBXRz8KNC4gQXJlIHlvdSBpbnRlcmVzdGVkIGlu IGltcGxlbWVudGluZyBkcmFmdHMgb2YgdGhpcyBXRz8KVGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3 byB3ZWVrcywgdW50aWwgTWFyY2ggMjEuIElmIHlvdSB0aGluayB0aGF0IHRoZSBjaGFydGVyIHNo b3VsZCBiZSBhbWVuZGVkIEluIGEgc2lnbmlmaWNhbnQgd2F5LCBwbGVhc2UgcmVwbHkgb24gYSBz ZXBhcmF0ZSB0aHJlYWQuClRoZSBmZWVkYmFjayBwcm92aWRlZCBoZXJlIHdpbGwgaGVscCB0aGUg SUVTRyBjb21lIHRvIGEgZGVjaXNpb24gb24gdGhlIGZvcm1hdGlvbiBvZiBhIG5ldyBXRy4gR2l2 ZW4gdGhlIGNvbnN0cmFpbnRzIG9mIHRoZSBjaGFydGVyaW5nIHByb2Nlc3MsIHJlZ2FyZGxlc3Mg b2YgdGhlIG91dGNvbWUgb2YgdGhpcyBjb25zZW5zdXMgY2FsbCwgd2Ugd2lsbCBiZSBtZWV0aW5n IGluIFZhbmNvdXZlciBhcyBhIEJvRi4KVGhhbmtzLApZYXJvbiBhbmQgRGljawotLS0gQ2hhcnRl ciBUZXh0IEZvbGxvd3MgLS0tClRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBm aW5lLWdyYWluZWQgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgYXV0aG9yaXphdGlvbiwgaWRlbnRp dHksIGFuZCBBUEkgYWNjZXNzLiBUaGlzIHByb3RvY29sIHdpbGwgYWxsb3cgYW4gYXV0aG9yaXpp bmcgcGFydHkgdG8gZGVsZWdhdGUgYWNjZXNzIHRvIGNsaWVudCBzb2Z0d2FyZSB0aHJvdWdoIGFu IGF1dGhvcml6YXRpb24gc2VydmVyLiBJdCB3aWxsIGV4cGFuZCB1cG9uIHRoZSB1c2VzIGNhc2Vz IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCAoaXRz ZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQgYXV0aG9yaXphdGlvbnMg c2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRyYW5zYWN0aW9uLCBwcm92aWRlIGEgY2xl YXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBp biB0aGUgcHJvdG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1bm5lY2Vzc2FyeSBkZXBlbmRlbmNlIG9u IGEgYnJvd3NlciBvciB1c2VyLWFnZW50IGZvciBjb29yZGluYXRpbmcgaW50ZXJhY3Rpb25zLgpU aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0 aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhl IHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uIGNoYW5uZWxzLCBzdWNoIGFz IHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0aGUgZGVsZWdhdGlvbiBjaGFubmVsLCB3 aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9BdXRoIDIuMCB3aGljaCBpcyBpbml0aWF0 ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3NlcikuIFRoZSBj bGllbnQgYW5kIEFTIHdpbGwgaW52b2x2ZSBhIHVzZXIgdG8gbWFrZSBhbiBhdXRob3JpemF0aW9u IGRlY2lzaW9uIGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5k aWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4gVGhpcyBkZWNvdXBsaW5nIGF2b2lkcyBtYW55IG9mIHRo ZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2FsIGNoYWxsZW5nZXMgb2YgT0F1dGggMi4w IGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRoIGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0 eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBjaGFubmVscy4KQWRkaXRpb25hbGx5LCB0 aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOgotIEZpbmUtZ3JhaW5lZCBzcGVj aWZpY2F0aW9uIG9mIGFjY2VzcwotIEFwcHJvdmFsIG9mIEFTIGF0dGVzdGF0aW9uIHRvIGlkZW50 aXR5IGNsYWltcwotIEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMgYW5k IEFQSXMgaW4gYSBzaW5nbGUgaW50ZXJhY3Rpb24KLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBh cnR5IGF1dGhvcml6aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xpZW50 IHJlcXVlc3RpbmcgYWNjZXNzCi0gQSB2YXJpZXR5IG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGlu Y2x1ZGluZyBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBpbnRlcmFjdGlvbi1jb25zdHJh aW5lZCBhcHBsaWNhdGlvbnMKVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMg Zm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1 ZGluZzoKLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJl cywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24KLSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMg aW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzCi0gTWVjaGFuaXNtcyBmb3IgY29udmV5 aW5nIHVzZXIsIHNvZnR3YXJlLCBvcmdhbml6YXRpb24sIGFuZCBvdGhlciBwaWVjZXMgb2YgaW5m b3JtYXRpb24gdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9ucwotIE1lY2hhbmlzbXMgZm9y IHByZXNlbnRpbmcgdG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3Vy Y2UgcmVxdWVzdHMgdG8gdG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5cwot IE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdoIHRo ZSBkZWxlZ2F0aW9uIHByb2Nlc3MgKGluY2x1ZGluZyBpZGVudGl0eSkKQWRkaXRpb25hbGx5LCB0 aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHBy b3RvY29sIGxpZmVjeWNsZSBpbmNsdWRpbmc6Ci0gRGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlcgotIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2VucwotIFF1ZXJ5IG9mIHRva2Vu IHJpZ2h0cyBieSByZXNvdXJjZSBzZXJ2ZXJzCkFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRo aXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21w YXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBh dHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENv bm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJsZS4KVGhpcyBncm91cCBpcyBu b3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAsIGFuZCBhcyBz dWNoIHdpbGwgZm9jdXMgb24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5vdCBuZWNlc3Nh cmlseSBjb21wYXRpYmxlIHdpdGggT0F1dGggMi4wLiBGdW5jdGlvbmFsaXR5IHRoYXQgYnVpbGRz IGRpcmVjdGx5IG9uIE9BdXRoIDIuMCB3aWxsIGJlIGRldmVsb3BlZCBpbiB0aGUgT0F1dGggV29y a2luZyBHcm91cCwgaW5jbHVkaW5nIGZ1bmN0aW9uYWxpdHkgYmFjay1wb3J0ZWQgZnJvbSB0aGUg cHJvdG9jb2wgZGV2ZWxvcGVkIGhlcmUgdG8gT0F1dGggMi4wLgpUaGUgZ3JvdXAgaXMgY2hhcnRl cmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcgY3J5cHRvZ3JhcGhpYyBtZXRo b2RzLCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MuIFRo aXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBjcnlwdG9ncmFwaGljIG1l dGhvZHMuClRoZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1cyBvbiB1c2luZyBIVFRQIGZvciBjb21t dW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBIVFRQMiBhbmQg SFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxsIHN0cml2ZSB0byBlbmFibGUgc2ltcGxlIG1h cHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXMgQ09BUCB3aGVuIGRvaW5nIHNvIGRvZXMg bm90IGNvbmZsaWN0IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuCk1pbGVzdG9uZXMgdG8gaW5jbHVk ZToKLSBDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2wKLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlz bSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNp Z25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcwotIElkZW50aXR5IGFuZCBhdXRo ZW50aWNhdGlvbiBjb252ZXlhbmNlIG1lY2hhbmlzbXMKLSBHdWlkZWxpbmVzIGZvciB1c2Ugb2Yg cHJvdG9jb2wgZXh0ZW5zaW9uIHBvaW50cwoKLS0KVHhhdXRoIG1haWxpbmcgbGlzdApUeGF1dGhA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg= --b1_76fb3a45f5510ea72573dbdc7fa5011e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 WWVzICEgdG8gYWxsIHRoZSBxdWVzdGlvbnMuPGJyPjxicj5UaGFua3MsPGJyPlBhcnRoYTxicj48 YnI+PGJyPlNlbnQgZnJvbSBQcm90b25NYWlsIG1vYmlsZTxicj48YnI+PGJyPjxicj48YnI+LS0t LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLTxicj5PbiAxNiBNYXIgMjAyMCwgNzoyMCBw bSwgWWFyb24gU2hlZmZlciAmbHQ7IHlhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDsgd3JvdGU6PGJy PkhlcmUncyBhIHF1aWNrIHJlbWluZGVyOiBpZiB5b3UgaGF2ZW4ndCByZXNwb25kZWQgdG8gdGhl IGNhbGwgeWV0LCBwbGVhc2UgZG8gc28gc29vbi48YnI+VGhhbmtzLDxicj5ZYXJvbjxicj7vu79P biAzLzYvMjAsIDE4OjQ0LCAiWWFyb24gU2hlZmZlciIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNv bSZndDsgd3JvdGU6PGJyPkhpIEV2ZXJ5b25lLDxicj5JdCBhcHBlYXJzIHRoYXQgbW9tZW50dW0g aXMgZm9ybWluZyBhcm91bmQgdGhlIHByb3Bvc2VkIGZvcm1hdGlvbiBvZiBhIFR4QXV0aCB3b3Jr aW5nIGdyb3VwLiBXZeKAmWQgbGlrZSB0byBtb3JlIGZvcm1hbGx5IGdhdWdlIGludGVyZXN0IGlu IHByb2NlZWRpbmcgd2l0aCB0aGlzIHdvcmsuIFBsZWFzZSBkbyBzbyBieSByZXNwb25kaW5nIHRv IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOjxicj4xLiBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRl ciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8gT3IgZG8geW91IGhhdmUg bWFqb3Igb2JqZWN0aW9ucywgYmxvY2tpbmcgY29uY2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBs ZWFzZSBlbGFib3JhdGUpPzxicj4yLiBBcmUgeW91IHdpbGxpbmcgdG8gYXV0aG9yIG9yIHBhcnRp Y2lwYXRlIGluIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/PGJyPjMu IEFyZSB5b3Ugd2lsbGluZyB0byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/PGJy PjQuIEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRoaXMgV0c/ PGJyPlRoZSBjYWxsIHdpbGwgcnVuIGZvciB0d28gd2Vla3MsIHVudGlsIE1hcmNoIDIxLiBJZiB5 b3UgdGhpbmsgdGhhdCB0aGUgY2hhcnRlciBzaG91bGQgYmUgYW1lbmRlZCBJbiBhIHNpZ25pZmlj YW50IHdheSwgcGxlYXNlIHJlcGx5IG9uIGEgc2VwYXJhdGUgdGhyZWFkLjxicj5UaGUgZmVlZGJh Y2sgcHJvdmlkZWQgaGVyZSB3aWxsIGhlbHAgdGhlIElFU0cgY29tZSB0byBhIGRlY2lzaW9uIG9u IHRoZSBmb3JtYXRpb24gb2YgYSBuZXcgV0cuIEdpdmVuIHRoZSBjb25zdHJhaW50cyBvZiB0aGUg Y2hhcnRlcmluZyBwcm9jZXNzLCByZWdhcmRsZXNzIG9mIHRoZSBvdXRjb21lIG9mIHRoaXMgY29u c2Vuc3VzIGNhbGwsIHdlIHdpbGwgYmUgbWVldGluZyBpbiBWYW5jb3V2ZXIgYXMgYSBCb0YuPGJy PlRoYW5rcyw8YnI+WWFyb24gYW5kIERpY2s8YnI+LS0tIENoYXJ0ZXIgVGV4dCBGb2xsb3dzIC0t LTxicj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRl bGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24sIGlkZW50aXR5LCBhbmQgQVBJIGFj Y2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRl bGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9u IHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNlcyBjYXNlcyBjdXJyZW50bHkgc3Vw cG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgKGl0c2VsZiBhbiBleHRlbnNp b24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25zIHNjb3BlZCBhcyBuYXJy b3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBhIGNsZWFyIGZyYW1ld29yayBm b3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhlIHByb3RvY29s IGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3NhcnkgZGVwZW5kZW5jZSBvbiBhIGJyb3dzZXIgb3Ig dXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0aW9ucy48YnI+VGhlIGRlbGVnYXRp b24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVsdGlwbGUgcGFydGllcyBpbiB0aGUg cHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmljIHJvbGUuIFRoZSBwcm90b2NvbCB3 aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVscywgc3VjaCBhcyB0aGUgZW5kIHVz ZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwgd2hpY2ggaGFwcGVu cyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2ggaXMgaW5pdGlhdGVkIGJ5IHRoZSBj bGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUgY2xpZW50IGFuZCBB UyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBh cyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluZGljYXRlZCBieSB0 aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGluZyBhdm9pZHMgbWFueSBvZiB0aGUgc2VjdXJpdHkg Y29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9mIE9BdXRoIDIuMCBhbmQgcHJvdmlk ZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgb2YgY2xp ZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuPGJyPkFkZGl0aW9uYWxseSwgdGhlIGRlbGVn YXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjo8YnI+LSBGaW5lLWdyYWluZWQgc3BlY2lmaWNh dGlvbiBvZiBhY2Nlc3M8YnI+LSBBcHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0 eSBjbGFpbXM8YnI+LSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFu ZCBBUElzIGluIGEgc2luZ2xlIGludGVyYWN0aW9uPGJyPi0gU2VwYXJhdGlvbiBiZXR3ZWVuIHRo ZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVyYXRpbmcgdGhlIGNs aWVudCByZXF1ZXN0aW5nIGFjY2Vzczxicj4tIEEgdmFyaWV0eSBvZiBjbGllbnQgYXBwbGljYXRp b25zLCBpbmNsdWRpbmcgV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24t Y29uc3RyYWluZWQgYXBwbGljYXRpb25zPGJyPlRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNp b24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBh cmVhcyBpbmNsdWRpbmc6PGJyPi0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNz YWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9uPGJyPi0gVXNlciBpbnRlcmFj dGlvbiBtZWNoYW5pc21zIGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kczxicj4tIE1l Y2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0aW9uLCBhbmQg b3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lv bnM8YnI+LSBNZWNoYW5pc21zIGZvciBwcmVzZW50aW5nIHRva2VucyB0byByZXNvdXJjZSBzZXJ2 ZXJzIGFuZCBiaW5kaW5nIHJlc291cmNlIHJlcXVlc3RzIHRvIHRva2VucyBhbmQgYXNzb2NpYXRl ZCBjcnlwdG9ncmFwaGljIGtleXM8YnI+LSBPcHRpbWl6ZWQgaW5jbHVzaW9uIG9mIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIChpbmNsdWRpbmcg aWRlbnRpdHkpPGJyPkFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5p c21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjxi cj4tIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+LSBSZXZvY2F0aW9u IG9mIGFjdGl2ZSB0b2tlbnM8YnI+LSBRdWVyeSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ug c2VydmVyczxicj5BbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBp bnRlbmRlZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRo IDIuMCBvciBPcGVuSUQgQ29ubmVjdCwgdGhlIGdyb3VwIHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlm eSBtaWdyYXRpbmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRoZSBuZXcg cHJvdG9jb2wgd2hlcmUgcG9zc2libGUuPGJyPlRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIGV4dGVuc2lvbnMgdG8gT0F1dGggMi4wLCBhbmQgYXMgc3VjaCB3aWxsIGZvY3Vz IG9uIG5ldyB0ZWNobm9sb2dpY2FsIHNvbHV0aW9ucyBub3QgbmVjZXNzYXJpbHkgY29tcGF0aWJs ZSB3aXRoIE9BdXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxkcyBkaXJlY3RseSBvbiBP QXV0aCAyLjAgd2lsbCBiZSBkZXZlbG9wZWQgaW4gdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAsIGlu Y2x1ZGluZyBmdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRldmVs b3BlZCBoZXJlIHRvIE9BdXRoIDIuMC48YnI+VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZl bG9wIG1lY2hhbmlzbXMgZm9yIGFwcGx5aW5nIGNyeXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBh cyBKT1NFIGFuZCBDT1NFLCB0byB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlz IG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2RzLjxicj5U aGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlv biBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGFraW5n IGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMgb2YgSFRUUDIgYW5kIEhUVFAzIHdo ZXJlIHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBsZSBtYXBwaW5nIHRv IG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVAgd2hlbiBkb2luZyBzbyBkb2VzIG5vdCBjb25m bGljdCB3aXRoIHRoZSBwcmltYXJ5IGZvY3VzLjxicj5NaWxlc3RvbmVzIHRvIGluY2x1ZGU6PGJy Pi0gQ29yZSBkZWxlZ2F0aW9uIHByb3RvY29sPGJyPi0gS2V5IHByZXNlbnRhdGlvbiBtZWNoYW5p c20gYmluZGluZ3MgdG8gdGhlIGNvcmUgcHJvdG9jb2wgZm9yIFRMUywgZGV0YWNoZWQgSFRUUCBz aWduYXR1cmUsIGFuZCBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZXM8YnI+LSBJZGVudGl0eSBhbmQg YXV0aGVudGljYXRpb24gY29udmV5YW5jZSBtZWNoYW5pc21zPGJyPi0gR3VpZGVsaW5lcyBmb3Ig dXNlIG9mIHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHM8YnI+PGJyPjxicj48YnI+LS08YnI+VHhh dXRoIG1haWxpbmcgbGlzdDxicj5UeGF1dGhAaWV0Zi5vcmc8YnI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4= --b1_76fb3a45f5510ea72573dbdc7fa5011e-- From nobody Mon Mar 16 10:06:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CBC3A0DAD for ; Mon, 16 Mar 2020 10:06:08 -0700 (PDT) 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 4tOLGsEAYBjC for ; Mon, 16 Mar 2020 10:06:06 -0700 (PDT) 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 B6E7E3A0DA1 for ; Mon, 16 Mar 2020 10:06:06 -0700 (PDT) Received: from [192.168.1.5] (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 02GH64Wu029581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 16 Mar 2020 13:06:05 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_AA761F72-EB4D-4094-AAB1-0B9B8B35BAB7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158437831629.23509.1258609755864740692@ietfa.amsl.com> To: txauth@ietf.org Date: Mon, 16 Mar 2020 13:06:04 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Fwd: New Version Notification for draft-richer-transactional-authz-06.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 17:06:18 -0000 --Apple-Mail=_AA761F72-EB4D-4094-AAB1-0B9B8B35BAB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve updated my transactional authz spec with the multiple = resource and multiple access token changes I posted about the other day. =E2=80=94 Justin > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-richer-transactional-authz-06.txt > Date: March 16, 2020 at 1:05:16 PM EDT > To: "Justin Richer" >=20 >=20 > A new version of I-D, draft-richer-transactional-authz-06.txt > has been successfully submitted by Justin Richer and posted to the > IETF repository. >=20 > Name: draft-richer-transactional-authz > Revision: 06 > Title: Transactional Authorization > Document date: 2020-03-16 > Group: Individual Submission > Pages: 34 > URL: = https://www.ietf.org/internet-drafts/draft-richer-transactional-authz-06.t= xt > Status: = https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ > Htmlized: = https://tools.ietf.org/html/draft-richer-transactional-authz-06 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-richer-transactional-authz > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-richer-transactional-authz-06 >=20 > Abstract: > This document defines a mechanism for delegating authorization to a > piece of software, and conveying that delegation to the software. >=20 >=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 --Apple-Mail=_AA761F72-EB4D-4094-AAB1-0B9B8B35BAB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ve updated my transactional authz spec with the = multiple resource and multiple access token changes I posted about the = other day.

 =E2=80= =94 Justin

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-richer-transactional-authz-06.txt
Date: = March 16, 2020 at 1:05:16 PM = EDT
To: = "Justin Richer" <ietf@justin.richer.org>


A new version = of I-D, draft-richer-transactional-authz-06.txt
has been = successfully submitted by Justin Richer and posted to the
IETF repository.

Name: = draft-richer-transactional-authz
Revision: 06
Title:= = Transactional Authorization
Document date: = 2020-03-16
Group: Individual Submission
Pages:= = 34
URL: =            https://www.ietf.org/internet-drafts/draft-richer-transactional= -authz-06.txt
Status: =         https://datatracker.ietf.org/doc/draft-richer-transactional-aut= hz/
Htmlized:       https://tools.ietf.org/html/draft-richer-transactional-authz-06=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richer-transactiona= l-authz
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-richer-transactional-= authz-06

Abstract:
=   This document defines a mechanism for delegating = authorization to a
  piece of software, and = conveying that delegation to the software.





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



= --Apple-Mail=_AA761F72-EB4D-4094-AAB1-0B9B8B35BAB7-- From nobody Mon Mar 16 16:04:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB523A12F3 for ; Mon, 16 Mar 2020 16:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 zvJe0EiXVfb0 for ; Mon, 16 Mar 2020 16:04:53 -0700 (PDT) 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 968643A11FC for ; Mon, 16 Mar 2020 16:04:52 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id o10so20637058ljc.8 for ; Mon, 16 Mar 2020 16:04:52 -0700 (PDT) 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=e3geCzBKpeQMhVYsXRvYRR7N1bIt83KY2UFjEpHFZN4=; b=OTRZ2Znql6rqHJM8v3Z/RyJcQMFwO0m3bwyOFc4oixGfSk7S7LftkEr/bUGtyolyAM 9urGpyPFyfrcaTB+nPPz8h0ogIm6Ss/hQFEmCXkhb4P3WMhKjC9Vbx8KfalwW38soDmq OuZKhylorBF0QMTtx9sbjuZc2l/GQYyfr8ocIEmyVS7HkwiPmQSA3lexUTqMhnTfj6yq tMGQTBr369KL1SQMBAFPZrJ4LaB5rJebNq5Wn9g3ZbERSPicxCPpgpMlw753OTlq+TjU yTOl/RhOA2/si7tfbEdgI8sN/7ngShEoUIE8Su6bbfL/ykW4qfIsv5dnwY+xaf2nqVeg h4jg== 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=e3geCzBKpeQMhVYsXRvYRR7N1bIt83KY2UFjEpHFZN4=; b=ljf6JH/pvuJFP+VRY8clMgZflMaPfF/vPqOxoZrQwbuddHyweHlGsukAyVcRmGHgIz UADo/asqb2yuGrlcEpm4DZv/xFeeHxKZQdDTIR6ekyYAlycC8fuBUzwpy7DBvi2alE+1 vhiq+WShX+FWYcSo0jocUSB0PTIxSRsV+HngOV6XxqYU8SVih5aihKOx30CdOe3pn9VV y0HRwJJVXzFTWDory94SRfSnZY2n6ioDRWJbYdO6tQXPlduSgpWwJd3zuyZYXODuuQko B2QUuZC5B3lhWu7X3+P7E99S3RXC4QeSQnz0rFKz7TxDrdIGS8crwYAFj225uqcJirdl DS9g== X-Gm-Message-State: ANhLgQ2+PMZBH4elG+9Pevk+zecXHheGMKNWigQHnyCOfSsdaBVZGhrm TfjZUWQJ2mGdSzo28oeQYmmXvvyhc7tidHO53OSt0UW+H4A= X-Google-Smtp-Source: ADFU+vs+aU33nGFHzrpoqWOYbW/1nZLViP2y+kArbbojyA8fM7mduiOJVpbKanbXxKLrCKp9RwNle9MPf0mP8ujSI4c= X-Received: by 2002:a2e:9602:: with SMTP id v2mr950521ljh.236.1584399890236; Mon, 16 Mar 2020 16:04:50 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:04:24 -0700 Message-ID: To: txauth@ietf.org Cc: Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000a3c9e105a100d811" Archived-At: Subject: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:04:54 -0000 --000000000000a3c9e105a100d811 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Virtual Meeting: Monday, March 23 20:00 - 22:00 UTC * *Agenda* Chair slides, agenda bashing - 10 min. Charter (link, solicit comments, discuss WG name) - 20 min. XYZ - Justin (with Q&A) - 20 min. XAuth - Dick (with Q&A) - 20 min. Yaron , Dick, Justin - Discussion of differences between protocols - 40 min= . Next steps - 10 min. Additions / suggestions? *Tech* The technology to be used is still TBD. We will update the list when we know. We are expecting it will be the IETF WebEx. (my preference would be Zoom if anyone has an account to have LOTS of people on it =3D) We are planning on using EtherPad for notes, and for queue management. *Scribe* Would someone like to volunteer to be the scribe on EtherPad? We would like to get as much coordination done prior as possible to make the best use of the time. /Dick * Some time math for 20:00 - 22:00 UTC: Pacific Time 13:00-15:00 Eastern Time 16:00-18:00 Coordinated Universal Time 20:00-02:00 Central European Time 21:00-23:00 India Standard Time 01:30-03:30 China Standard Time 04:00-06:00 Australian Eastern Standard Time 07:00-09:00 =E1=90=A7 --000000000000a3c9e105a100d811 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Virtual Meeting:=C2=A0

Monday, March 23=
20:00 - 22:00 UTC *

Agenda
Cha= ir slides, agenda bashing - 10 min.
Charter (link, solicit comments, dis= cuss WG name) - 20 min.
XYZ - Justin (with Q&A) - 20 min.
XAuth -= Dick=C2=A0 (with Q&A) - 20 min.
Yaron , Dick, Justin - Discussion o= f differences between protocols - 40 min.
Next steps - 10 min.
=

Additions / suggestions?

Tech
The technology to be used is still TBD. We wil= l update the list when we know. We are expecting it will be the IETF WebEx.= (my preference would be Zoom if anyone has an account to have LOTS of peop= le on it =3D)

We are planning on using EtherPad fo= r notes, and for queue management.

Scribe
Would someone like to volunteer to be the scribe on EtherPad? We w= ould like to get as much coordination done prior as possible to make the be= st use of the time.

/Dick

* Some time math for 20:00 - 22:00 UTC:

Pacific T= ime=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013:= 00-15:00
Eastern Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A016:00-18:00
Coordinated Universal Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 20:00-02:00
Central European Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21:0= 0-23:00
India Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 01:= 30-03:30
China Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 04:00-06:= 00
Australian Eastern Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A007:00-09:0= 0
=E1=90=A7
--000000000000a3c9e105a100d811-- From nobody Mon Mar 16 16:05:05 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3693A1302 for ; Mon, 16 Mar 2020 16:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 BRk-9RzxhWCL for ; Mon, 16 Mar 2020 16:04:56 -0700 (PDT) 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 206073A11FC for ; Mon, 16 Mar 2020 16:04:55 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id f10so20648156ljn.6 for ; Mon, 16 Mar 2020 16:04:55 -0700 (PDT) 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=BaZkHnulmFPGxWGKYBHQui5wNtjzBRmV7HSdNx4be5E=; b=sDu+nmTJferFBfkIfNVKL1+HQpo6cjVND5GV8uWLMxxcEQ/ddru21WpUIgokOfDEi7 HS3U2BY28k818WHUZ8dsGDNq6Y1vmXO3ev7Y2y9pkzovYMMHV4LyBl4OVCKHQwz/2jpM az9tJpSOMwc+kDWmqKE/umpHk9qYHLpMSOjysqmd+rI+FwNn5GZtEShE8H5iplUe1x7P 4UtCZsfE2J+Yn2Qwvi3sqr3WsBUp+938tG3F7qWtFCYxmeIe89ioLcbiXdPh2PL/oUrk yb46IGGgmoCe9NjWy0/reQVVAibZjPgD47WLC7QnDtAmZw86Q5l5kIBNJ2B5HtJ9x8o2 CZ6w== 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=BaZkHnulmFPGxWGKYBHQui5wNtjzBRmV7HSdNx4be5E=; b=MDOBMv4a/8AbhYxJwykI6tLel/5PAYN/rPxtD5JNGFx70getrvoevrkPeVbc3OkGUI 31At6YqWs/mAuRl1h3gbByLlgUYANQj/MFTDMbdc5vkCqkzSK+S4tg2egXf7TLoLHxVc pyMR+wh+t15tc2pBh0KYTptlsKO07Ezq0qzaqvWyz/XWV8t+QEh+GrMfaBoyjncB6cni ru712D4b7alBLhp79ToW/GtAYnDlHQM437WQ0dZJXbAOfaDU56MCIEutqpL51mbMmHXq F0egtfYtUfTtiTNJyCmqPGMYxViJFLqwGa1zaB0q9XUHIjTnx+fXSB2JWgfluR3uum7H 8cOw== X-Gm-Message-State: ANhLgQ1s3W+fcssO/bMfKiWAiaLEE2wM1aVcbp82lXlgu3k66idI9Zu8 GOZjKPKt86fgu+USanmUyxdCK4bwhUmfXnrfy5Cq7bnRr+k= X-Google-Smtp-Source: ADFU+vu6nocY8mL7VyQSp3PQ9M5l9RG0t1dbZd3XMEa2CkmbTZkOZQJZDdTSoLt7dYo3whPju08lsWonQ/16GAxsXcs= X-Received: by 2002:a2e:1653:: with SMTP id 19mr997799ljw.112.1584399893732; Mon, 16 Mar 2020 16:04:53 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:04:27 -0700 Message-ID: To: txauth@ietf.org Cc: Yaron Sheffer , Justin Richer Content-Type: multipart/alternative; boundary="000000000000d9240605a100d8b2" Archived-At: Subject: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:05:04 -0000 --000000000000d9240605a100d8b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone I prompted a thread around the name of the protocol a while back: https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ As Justin stated "naming is hard" Wearing my marketing hat I want to ensure that the name will be perceived properly in the broader community. A recent example that comes to mind are the privacy related works on the browser storage API. Given that name, one would think that it is local storage. It is actually about browser cookies. Justin discussed his reasons for TxAuth in the thread above (and I'm sure in other places) I chose XAuth in my draft to reflect the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but with an X to reflect all the extra features. =3D) Other suggestions? This will be an agenda item in the BoF -- but the name will NOT be an open discussion item -- we will summarize what has been discussed on the list and perhaps do a poll of options presented unless consensus is obvious from this thread. /Dick =E1=90=A7 --000000000000d9240605a100d8b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone

I prompted a thread = around the name of the protocol a while back:


As Justin stated "naming is har= d"

Wearing my marketing hat I want to ensure = that the name will be perceived=C2=A0properly in the broader community.

A recent example that comes to mind are the privacy r= elated works on the browser storage API. Given that name, one would think t= hat it is local storage. It is actually about browser cookies.
Justin discussed his reasons for TxAuth in the thread above (a= nd I'm sure in other places)

I chose XAuth in = my draft to reflect the eXtensibility goal that we have over OAuth -- and X= Auth is OAuth but with an X to reflect all the extra features. =3D)

Other suggestions?

This will be = an agenda item in the BoF -- but the name will NOT be an open discussion it= em -- we will summarize=C2=A0what has been discussed on the list and perhap= s do a poll of options presented unless consensus is obvious from this thre= ad.

/Dick


=


3D""=E1=90=A7 --000000000000d9240605a100d8b2-- From nobody Mon Mar 16 16:05:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3F83A1301 for ; Mon, 16 Mar 2020 16:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 6G4YI8Oqcj_v for ; Mon, 16 Mar 2020 16:05:02 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 9B57D3A130A for ; Mon, 16 Mar 2020 16:05:01 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id w4so5936201lji.11 for ; Mon, 16 Mar 2020 16:05:01 -0700 (PDT) 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=2a4EMbCa3UDaL5kv9F2UgFFfItl2hs0K6nPtSOmatQs=; b=h/N8OfMZxULJrW/iTuEgyYVYS63HX9lObnjVXH80DPl8Fir9+pEJmLkOVrGmFAfIp1 N3QTwoJU9aSCzHjEsmSVl6+kdBozN7VMbZv45oE6DkvxZEFw0yyp/Mt5AGiwwRFftzdz vZBtVpMHYhbwHHMgdPdTe/glakwPHunaoB94+8KGEP/uN8Xou+rFMLXDZPtA4/iubZlb VpiBidApu6BgNzAcExbpRB6h0kbOU2BxZ4wV0lPCvWGcz1AzRmkeE9r6WP+brrAW49A4 zqyzGEkDRREEkmncwqE/Txg0KMyNjsTM3t8qV37KNPgK3UHHUGEGEaETY2hb6bO3st9f rgSw== 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=2a4EMbCa3UDaL5kv9F2UgFFfItl2hs0K6nPtSOmatQs=; b=qz4gQk6cEUVpLAxeq/ussXSNEiurV1a3dJ4NdlTo1dp6draFpEihZk56z2tvxbq/sr yjwuzzV4foexZWBrQ6HgQezkjXopKtJFa1ClTzeFswO1Kxh1WEQZ85cxbgxRqW1EMT0W iUg09xHpZEhyp9R5Tw2sStM3w/A6LiY7sjm+Ff0wfg8/iisOcfT76BYgtPAdjfQvFGm2 emAW+2xlhzIhPCl7Gzfbb7ctr+PmGBrl7IPWKpTr695V3aY8M3hcf1GNyMF59NElNyH0 oeBYtD++DsMRfX3oOya8KM7E3W8urJ3ODkjNHj5JR4MofvvDY+9EdM1Z4xEDXsP2Qk/H yQyg== X-Gm-Message-State: ANhLgQ2+fj7ZTUKXM+VU/BjN+VJDjplhEDI2QvFrTn2vNfQHcmkbrSwl 1jcV+8tkBE5EUVYhkH8+L2Wj7QXEWuemd7x8iRKmZaw/Qwk= X-Google-Smtp-Source: ADFU+vtM0kqePA4bu0+89A96bKttfK2jZNwOxdLUDaCseNZckFWgolYGOUYLEfa4PNlCh/x7PbjFErxcVcTGzQrBVq4= X-Received: by 2002:a2e:7811:: with SMTP id t17mr931184ljc.150.1584399899381; Mon, 16 Mar 2020 16:04:59 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:04:33 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="0000000000002f531205a100d97a" Archived-At: Subject: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:05:04 -0000 --0000000000002f531205a100d97a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone Justin and I have had some emails back and forth comparing and contrasting XYZ and XAuth. I'm going to post a message for each of the major points, with Justin's rationale and my rationale for our respective design decisions. Feel free to ask clarifying questions in those threads. *Please weigh in with your preference, your rationale, as well as any pros and cons not described.* We would like to get a sense for the group's views on these topics for the virtual BoF in a week. The latest drafts are: XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 Thanks! /Dick =E1=90=A7 --0000000000002f531205a100d97a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone

Justin and I have had som= e emails back and forth comparing and contrasting XYZ and XAuth. I'm go= ing to post a message for each of the major points, with Justin's ratio= nale and my rationale for our respective design decisions.=C2=A0Feel free t= o ask clarifying questions in those threads.

Pl= ease weigh in with your preference, your rationale, as well as any pros and= cons not described.

We would like to ge= t a sense for the group's views on these topics for the virtual BoF in = a week.

The latest drafts are:
/Dick
3D""=E1=90=A7
--0000000000002f531205a100d97a-- From nobody Mon Mar 16 16:05:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A443A1310 for ; Mon, 16 Mar 2020 16:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, 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 Vf4L2Mgp4Z4V for ; Mon, 16 Mar 2020 16:05:08 -0700 (PDT) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 A59593A131E for ; Mon, 16 Mar 2020 16:05:07 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id y2so772176lfe.11 for ; Mon, 16 Mar 2020 16:05:07 -0700 (PDT) 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=N7Feee+3ohTOO7vkzfDBlITp+FRA+KbqdKHIkC4fTSs=; b=ATojXOtaBFRp0eLQYQhCyJBVJ/twfGSFpEZp52X41fgQ39FpY4D8E+kz4pPso2AWzp ZNHz8CIwA+sXl0ltMC9Ht8yWjy3NGIcik1VL8pMCSuiL427Bkvepe9URgfqut3UC6S7t MtX2DS5PK3ZRhprIeUA1ab5PJn/PT7dWLQ3dKbvfKoKGbdA+RxD/EHiKh4Y8rln98Ahm sHyDKtYcTj2it/zIaVEal87YauRNhwz/KGNDhX9L0nYFQKsD0gvWqe/RTLot0PbVCTvd 02F4l+IhJogwKec8GjF6hjAxN9FYcXOP52reD+Ur40GiWjX1keCiQQngB0xRCT5gMBZW N68w== 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=N7Feee+3ohTOO7vkzfDBlITp+FRA+KbqdKHIkC4fTSs=; b=IGWsRl3cHBaOTHq1QcwRqJe7OIe0kU/oig05D4YTrZBL0up8CHSdqA3/CIc4Dif7Yj KLnJfigt/9/Ym3g1TU8xnVg1OfiMgfKKI0XHVE4iDWIyOcNyWYJtYL+aWrwF9SjaRfos Bx/u1DXuc/D7yiZTsDh4nKi1HNuoUaABc48Sca+Ao1yLe/v7tFiMdD0rJjTuu4HsFf7h U27Es/anPNcOQZVDuPF5xlPTEloTmNQ7SQ/IQUlEUQx/BGer6vtVmS2mh6FitRuLqIE5 P3ccx7COS7/l0sOIsdU+N8dA5owSoTYNEH8J7VOgXaqwk2C9xMxdqQtuTvAMHkR7iv4H mZ3w== X-Gm-Message-State: ANhLgQ3QK5LFpPHGnOybHbfPyV+UO2RAv3zNWulKqls6ZhKowdjpMOxp dy3pQpO7XWtRR2ZvuD+23ldbRpdTfr430+7c9kfOVDLh X-Google-Smtp-Source: ADFU+vvbyM0yJ+5shdj4c+GWpjHu/8VNMJ1g96IhC0Iuob8WMVjV9AHqGH2Jbwl8gzZqKKQq1maTTt0o8Bg9pMGgCL0= X-Received: by 2002:a05:6512:3044:: with SMTP id b4mr1049172lfb.10.1584399905460; Mon, 16 Mar 2020 16:05:05 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:04:39 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="0000000000008c14a605a100d9a8" Archived-At: Subject: [Txauth] XYZ vs XAuth: OAuth 2.0 / OIDC compatibility X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:05:18 -0000 --0000000000008c14a605a100d9a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *OAuth 2.0 / OIDC compatibility* XYZ - use key handles to identify Client, or uses public key presented by value (no explicit difference between dynamic and static clients in the protocol) - support for subject, email, phone, ID Token claims - rich resource request, supports OAuth/OIDC style scopes in the same structure through resource handles - access token refresh is done with transaction handle to transaction endpoint (transaction / grant oriented, similar to refresh token) - support for OIDC UserInfo Endpoint through access token for additional claims XYZ Rationale: clean take on existing concepts, allowing us to map things that work well without forcing things that don=E2=80=99t work well into us;= if you have a static client ID and set of scopes, those all have places to fit; if your case doesn=E2=80=99t fit that, you don=E2=80=99t have to force it. No = need for dynamic registration step. XAuth - uses Client ID to identify registered Clients, just as it was used in OAuth 2.0 / OIDC - Dynamic Clients are identified by public key value (same as XYZ) - directly reuses OAuth scopes - allows rich resource requests from RAR - support for all OIDC Claims in an ID Token, or separately - uses a per-access-token refresh token and URL (token / authorization oriented) XAuth Rationale: minimize migration friction for existing deployments. Enable multiple schemas for expressing resources and claims to simplify adoption of existing schemas and creation of new schemas. =E1=90=A7 --0000000000008c14a605a100d9a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OAuth 2.0 / OIDC compatibility

XYZ
- use = key handles to identify Client, or uses public key presented by value (no e= xplicit difference between dynamic and static clients in the protocol)
-= support for subject, email, phone, ID Token claims
- rich resource requ= est, supports OAuth/OIDC style scopes in the same structure through resourc= e handles
- access token refresh is done with transaction handle to tran= saction endpoint (transaction / grant oriented, similar to refresh token)- support for OIDC UserInfo Endpoint through access token for additional = claims

XYZ Rationale: clean take on existing concepts, allowing us t= o map things that work well without forcing things that don=E2=80=99t work = well into us; if you have a static client ID and set of scopes, those all h= ave places to fit; if your case doesn=E2=80=99t fit that, you don=E2=80=99t= have to force it. No need for dynamic registration step.

XAuth
-= uses Client ID to identify registered Clients, just as it was used in OAut= h 2.0 / OIDC
- Dynamic Clients are identified by public key value (same = as XYZ)
- directly reuses OAuth scopes
- allows rich resource request= s from RAR
- support for all OIDC Claims in an ID Token, or separately- uses a per-access-token refresh token and URL (token / authorization or= iented)

XAuth Rationale: minimize migration friction for existing de= ployments. Enable multiple schemas for expressing resources and claims to s= implify adoption of existing schemas and creation of new schemas.=C2=A0
=
3D""==E1=90=A7
--0000000000008c14a605a100d9a8-- From nobody Mon Mar 16 16:06:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972E3A12F8 for ; Mon, 16 Mar 2020 16:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 Be_C16FBP-x4 for ; Mon, 16 Mar 2020 16:05:52 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 ACC213A12F6 for ; Mon, 16 Mar 2020 16:05:51 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id s13so20659141ljm.1 for ; Mon, 16 Mar 2020 16:05:51 -0700 (PDT) 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=bcuQ044dGcmAF1VCh2neeDb6bmefn0rsh0Udg6KrdtA=; b=Uc6ll3ZkJ7aQTrFdQhAWKdqEhUZi+DUQmgWVq5ewtxsSQpig4qY6EuzpZsv43GzIeI PcCB3sPm3Kph3zHxhpO/9IeH/SXfJJspBHjckejtOBCxxsQfPwZ0yXizw712hJeZqNrO tDldbHyVld7koNi4F4GVQ1MVDTSODul2S+1J4H2bBTKvhVxh4iDIRYXOxzgsqwfwlQsV RS+H4s/CnYPbLwnIIhTuJvVgknD2vCBqdkozkHoELzmxcsFMKD9dWzjBZjY/3UmASjR5 vqRgyKHb3RGotKH5jCxwQy33lUWQoNtvf5AbL+O2EhWpC0USyy9CLuoDFTPKTWgxAUNW H9og== 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=bcuQ044dGcmAF1VCh2neeDb6bmefn0rsh0Udg6KrdtA=; b=L/jreNuM6Z82ekO9WHVz9Ys3lTa0Ulhg3muf7LOOXfHdoalMe/Kvu1owEFRP6HO5yd +h2L/uweP7aIwqfQeGVZh9/GUm0bNWVid9RxavTijCmrxD18YkIqghNUb/bCO3fOLRPi dL5A32rcp0A14csfignwCo+XauSdbTBAxklGGWk70t8Zl8IYnjWgci0GOolQkyDHVk97 sA+L0GiWVnpvvFIMPvrl2wxBOxFWebgoTwPc+3tOCh945uSrhSD0gXaZkRbe4AYfcOtb kRt6K+52eAFWXqfcGHNnxoYvtDdLsbLf0sTRwjG8spl+uumKoT4w6qtNvDmnpae/kUVc 1DEA== X-Gm-Message-State: ANhLgQ2V8yi/xLrTv9Fyw0bBmNMCuMGU/FsAeH/In1YYLRf+ibLDFv2W CKpcxvXhEcp1GEzpWPcXPUiBTCdubY8Ha880xieGQtqi X-Google-Smtp-Source: ADFU+vvkqp2FiFbxRk6jmRSqXKHGdHDvMUSEQdUXy42CrugPW1VuAOBtwWzJmwao1kqlT728GxDmZQ/10BUsSZVTVM0= X-Received: by 2002:a2e:8518:: with SMTP id j24mr951562lji.138.1584399949249; Mon, 16 Mar 2020 16:05:49 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:05:23 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="00000000000028436e05a100dc82" Archived-At: Subject: [Txauth] XYZ vs XAuth: Interaction X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:05:58 -0000 --00000000000028436e05a100dc82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Interaction* XYZ - Client expresses all possible interaction capabilities such as redirect, user_code, didcomm as separate fields - AS responds to any interaction capabilities it supports and requires per policy XYZ Rationale: Client knows what user experiences it can support (which might be several options), AS knows what experiences it supports and what kind of interaction (if any) will be needed for a given request. Inline negotiation gets rid of the need for discovery and error recovery steps. Separating how the client gets the user involved and how the client gets updated for the next step allows for innovative and powerful combinations not easily possible with a type-based system XAuth - Client states if it can do a redirect interaction (GS can redirect back to client), or must do an indirect interaction (GS won't be able to redirect back to client) - GS responds with parameters to use, or an error if not supported XAuth Rationale: User interaction can be transferred back to the Client, or it can't. A redirect enables protection from session fixation.[1] Separate URIs for redirect and indirect allow GS to know the security characteristics of request. The Client can present what it can for indirect, and let the User choose which method they prefer. [1] Session fixation. An attacker interacts with a Client and gets a redirect link, and then tricks the victim into clicking the redirect link in the context of the Client. The victim authenticates at the AS and authorizes the access for the Client. The attacker then has access to the victim's resources at the Client. Prevented by ensuring it is the same User at the Client and the AS. =E1=90=A7 --00000000000028436e05a100dc82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interaction

XYZ
- Client expresses all po= ssible interaction capabilities such as redirect, user_code, didcomm as sep= arate fields
- AS responds to any interaction capabilities it supports a= nd requires per policy

XYZ Rationale: Client knows what user experie= nces it can support (which might be several options), AS knows what experie= nces it supports and what kind of interaction (if any) will be needed for a= given request. Inline negotiation gets rid of the need for discovery and e= rror recovery steps. Separating how the client gets the user involved and h= ow the client gets updated for the next step allows for innovative and powe= rful combinations not easily possible with a type-based system

XAuth=
- Client states if it can do a redirect interaction (GS can redirect ba= ck to client), or must do an indirect interaction (GS won't be able to = redirect back to client)
- GS responds with parameters to use, or an err= or if not supported

XAuth Rationale: User interaction can be transfe= rred back to the Client, or it can't. A redirect enables protection fro= m session fixation.[1] Separate URIs for redirect and indirect allow GS to = know the security characteristics of request. The Client can present what i= t can for indirect, and let the User choose which method they prefer.

[1] Session fixation. An attacker interacts with a Client= and gets a redirect link, and then tricks the victim into clicking the red= irect link in the context of the Client. The victim authenticates at the AS= and authorizes the access for the Client. The attacker then has access to = the victim's resources at the Client. Prevented by ensuring it is the s= ame User at the Client and the AS.
3D""=E1=90=A7 --00000000000028436e05a100dc82-- From nobody Mon Mar 16 16:06:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7D3A1300 for ; Mon, 16 Mar 2020 16:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SPF_TEMPERROR=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=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 4dmT1zG4fRPb for ; Mon, 16 Mar 2020 16:05:56 -0700 (PDT) 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 2B47F3A12F7 for ; Mon, 16 Mar 2020 16:05:56 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id f3so5300301lfc.1 for ; Mon, 16 Mar 2020 16:05:56 -0700 (PDT) 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=yADe/tRpPDe44bm10xGNWCLalQSOgr8VMz0+fysyTYs=; b=eoxHv3MlUhBhOG3sM2K1Fk2rWevPXXsMQyFeYhUCsvR1tOtFqvyCnLTGdJXS49yUaL V3cpx8LvtyG8sBIRrSgtcSJSOxTsxX/iAOykuZFk8Wgi0j31OIV8/n0CMYSQ0ZNLo5OQ SIYJyxN1+6XacAJDnvGOcXMQzLfxFF/n+r0Y/pssaExhaquVlOyCY/E/gvQ//aTOTwN6 ZCDna8JE3dczwvalcaXLq9z3mb/91VKrSScrwQQQV+GjnIp7IkTrE+QZobpFHjnN2QRC xz0ZuLAEXJfHRsODJrqPTZGQQL0apxX9/TrIc7Av27Ci/I0iqJc+7SX1DaQOW/dKwCYT t51Q== 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=yADe/tRpPDe44bm10xGNWCLalQSOgr8VMz0+fysyTYs=; b=Oi++Zdzo+Tv20oCofTNQnfU2yiRTLCDNxnnu2+32frTgOyFQwcZW39ChVEEbIs7H23 31LRMkH0LtDNp6dQr6TTuyDjPbZcrLtO3xu/Dtsp5Ysx8fBxRgumbSaRLZ0xBkeWvT0S ZY877OXJSFVVYBzlJ36avD3cJXI8h017A0sIKpIC2lOtrEYagsN7Q6VJoR31MQO+hKxJ zXCZfl6KdQrj6h3INgqRWlbCiMePO0PqUz3iN8IDb0f3hOJtwrW8iNAuAjuNO5hkTaMW FnS42N+dhptPFdkdSr17NnMkh08FNV+zLm1UieBDCGoKLdGNpCUFWwkSJGiFnfq3kYc9 3MGQ== X-Gm-Message-State: ANhLgQ3qannkf2QS8NwEx3wjNRXqaYwtpgnauMYIMV2s4XiS/Tn0GP0A f/CjoDeDW24oyrWYQC+Q+4jdymOqyJjJub2fJWd8MVBqdG0= X-Google-Smtp-Source: ADFU+vuWEAlfA2xEDWozCpIbStT5tPAj6dLZ5QcBDlbbh2Ttj3xBJTXGEUKIo40MNreg2vTwiLtq9gaUVwDm4/WAUeg= X-Received: by 2002:a19:4cc2:: with SMTP id z185mr1017819lfa.0.1584399953968; Mon, 16 Mar 2020 16:05:53 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:05:28 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="00000000000070423905a100dcbd" Archived-At: Subject: [Txauth] XYZ vs XAuth: Data Representation X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:06:07 -0000 --00000000000070423905a100dcbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Data Representation* XYZ - Protocol is centered around a transaction (akin to OAuth =E2=80=9Cgrant= =E2=80=9D) - uses a single URL for interactions around transaction - handles represent the transaction for continuity between requests XYZ Rationale: the OAuth 2 =E2=80=9Cgrant=E2=80=9D is a concept that doesn= =E2=80=99t have clear reification in the OAuth world, the =E2=80=9Ctransaction=E2=80=9D raises it= to that level and allows us to reason on it. Single URI model is simple for clients with a limited set of actions, but multiple URIs could be dispatched from this as in XAuth without breaking the mental model (just like interaction and code URLs are now). XAuth - protocol is RESTful (GET, PATCH, POST, PUT, DELETE, OPTIONS) - GS URI is identifier for GS, and is URI to create Grants - URIs represent Grants and Authorizations with associated access tokens (and any other objects such as Sessions created later) XAuth Rationale URI model provides "identifier" and URL. HTTP verbs are used to manipulate. Easy to determine GS for a Grant or Authorization. Contents of URI are opaque allowing an implementation to easily map to implementation requirements. =E1=90=A7 --00000000000070423905a100dcbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Data Representation

XYZ
- Protocol is cen= tered around a transaction (akin to OAuth =E2=80=9Cgrant=E2=80=9D)
- use= s a single URL for interactions around transaction
- handles represent t= he transaction for continuity between requests

XYZ Rationale: the OA= uth 2 =E2=80=9Cgrant=E2=80=9D is a concept that doesn=E2=80=99t have clear = reification in the OAuth world, the =E2=80=9Ctransaction=E2=80=9D raises it= to that level and allows us to reason on it. Single URI model is simple fo= r clients with a limited set of actions, but multiple URIs could be dispatc= hed from this as in XAuth without breaking the mental model (just like inte= raction and code URLs are now).

XAuth
- protocol is RESTful (GET,= PATCH, POST, PUT, DELETE, OPTIONS)
- GS URI is identifier for GS, and i= s URI to create Grants
- URIs represent Grants and Authorizations with a= ssociated access tokens (and any other objects such as Sessions created lat= er)

XAuth Rationale =C2=A0URI model provides "identifier" = and URL. HTTP verbs are used to manipulate. Easy to determine GS for a Gran= t or Authorization. Contents of URI are opaque allowing an implementation t= o easily map to implementation requirements.
3D""=E1=90=A7
--00000000000070423905a100dcbd-- From nobody Mon Mar 16 16:06:13 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983DF3A1316 for ; Mon, 16 Mar 2020 16:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 OdyYqsOyptnk for ; Mon, 16 Mar 2020 16:06:01 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 B53EC3A1301 for ; Mon, 16 Mar 2020 16:06:00 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id j17so15514028lfe.7 for ; Mon, 16 Mar 2020 16:06:00 -0700 (PDT) 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=gAoLvC6evj2Qq0nJWxZ1Hb89LsuQu1jw3ZXO7XDxlgU=; b=KVA5HqipmTrysAO3Qv7DL2yTAgr9HEYouK1A9cPSmMc/fv2Uo6+lAGxbIyTDbll1vs mYohB3mkELisr4UNzO44L/iYExr+09e7wh3Hi8Mss8X6B1sh8mbdyH3QNEHRkl+1GROQ fr7Mv0ycvICEVZL5zxmgyzGnVIGwXdhcyy/j9X2yAZmhmOpr/zKwulLPhCuu5CscUrTM CPDBIoMvHc0s/MGyTxuPCtXLvDKG3uz72s6qjD/YlCKzOovdiJyq1/oOutk5kZrOQqD5 qWGX3z+67ZlJljHjvV0o4juv3FEodljMMpolr+71qSFHQ4l5SIF3QKwsaFAm7fr/ySQ6 oBug== 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=gAoLvC6evj2Qq0nJWxZ1Hb89LsuQu1jw3ZXO7XDxlgU=; b=LjVhR1JS96xSQSky+D1B6RNl5V7oc0Ri8fesYzd13l2PZLErP/XHqcdmobpHMdpNhN 5qVpWRIoHAR12c0mi4viHBiHpCaStQWrG36gE70KC/KlNt7omaud3wNel3kPYNsGZ69t 20MJqOofsAXV24V71ldB/Yqyufh+byhYyXtBw5FzSkIZybi62cVaHqpXK1g1DS6+GS7F u2RXd08x2tNfKZRELPJ5gAwHTK10TTGLsmctjxkC1YBQBiMeC/S4rmZRvXXDa608UZHk YdJ9BDuKQsliY4vA9/Q8oicFxI9rAnNHXkRJBir4NLXOKco4K4KDOUqpJyUlYprgRY8g ppyA== X-Gm-Message-State: ANhLgQ2lMeEugdiDVClGi0YyWuWIdqSn+VVCLGsTw7DSPhWra6q0c6Yi hVJSUkadjvtpvXhuqKBvKCP1MwlJ+o5RPg6wCuJMvXSe59o= X-Google-Smtp-Source: ADFU+vvIGyrKaZPAZpM2CXgNaBVjnZBDWdi3ZcrPo+CZuPaLGzxtE4Vlpuz03ZoJvQShcRTj/LNtPpURhWZMxSE1rj8= X-Received: by 2002:ac2:41c2:: with SMTP id d2mr1006587lfi.164.1584399958425; Mon, 16 Mar 2020 16:05:58 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:05:32 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="000000000000b444a405a100dc30" Archived-At: Subject: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:06:08 -0000 --000000000000b444a405a100dc30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Discovery* XYZ - Client always starts at the tx endpoint, all other information is dispatched from responses from the endpoint - Clients sends capabilities list in transaction request, AS selects and returns which capabilities are supported XYZ Rationale: client needs a single URL to start talking to an AS, giving developers multiple ways to get information is confusing and can lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s= discovery approach) XAuth - Client sends an OPTIONS call to the GS URI, Grant URI, or Authorization URI XAuth Rationale: Client can make unauthenticated call to GS URI to learn what GS supports, such as authentication mechanisms. Authenticated calls return what a specific Client can do. =E1=90=A7 --000000000000b444a405a100dc30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Discovery

XYZ
=C2=A0- Client always start= s at the tx endpoint, all other information is dispatched from responses fr= om the endpoint
=C2=A0- Clients sends capabilities list in transaction r= equest, AS selects and returns which capabilities are supported

XYZ = Rationale: client needs a single URL to start talking to an AS, giving deve= lopers multiple ways to get information is confusing and can lead to seriou= s errors (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s disco= very approach)

XAuth
=C2=A0- Client sends an OPTIONS call to the = GS URI, Grant URI, or Authorization URI

XAuth Rationale: Client can = make unauthenticated call to GS URI to learn what GS supports, such as auth= entication mechanisms. Authenticated calls return what a specific Client ca= n do.


3D""=E1=90=A7
--000000000000b444a405a100dc30-- From nobody Mon Mar 16 16:06:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF93A1312 for ; Mon, 16 Mar 2020 16:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 EhWa9lQw5TgQ for ; Mon, 16 Mar 2020 16:06:03 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 B49603A1301 for ; Mon, 16 Mar 2020 16:06:02 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id o10so20639559ljc.8 for ; Mon, 16 Mar 2020 16:06:02 -0700 (PDT) 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=wBwujK4Z0bP5x19MdQZA0HDaxfSrWO8VYrw+xcRjILM=; b=XhMu3ZfP+t8WeiVYJdVzqu9ZpCwtgKr7J1AC+8xyEuU0OTDZ28lpBCXCX1l3iuw7KJ C3ee5sq/4HQ3sfGAfYF/qhF0XwvEOs2pYmfI2WBwRNOpEI3r2ZfPBNR8TgyZmpdTH8FI Y5sWskMku7P2s4jtQ3AwGrJETbYCYqGB4v7e8NPxz8lIMIH81N6XIeXCz7FOtkMkI3nJ cWXMTIdkbvvXLemWdTyo/ZQDSy4SVfOerVVIg4bnFlosuEKBu9ikRQUUJEJrjslrb/md VLRSvIzleWWdKX+i/cWWGTj2Cf8Jj5+9PB2CGL2WwV64KjNujINB64HeG7NbuA/CIs2x ii5w== 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=wBwujK4Z0bP5x19MdQZA0HDaxfSrWO8VYrw+xcRjILM=; b=hPzFvW6RdHeWWLz4Ox/IFVEKVHLgA4H5qgSZp86OqplR+zyW4DR+zm8z0eUvvaATj1 LqTIZXZ1Slw6U/aYfSMeffm3QZvZnrgmHJo4LIppPgL3WKk/3rktvvKpGU5LGAZAXux3 h8J7wTFXW8783wh6DP6H/GySsLZjk0N0FwYACT1bJXWe+sW7Lzkcm466znC17Xk+19EY KOF7p5c0hZESDawUEiWOhzHCp4AazgxUguKdlJYqoDlERfIo1sM9Y44wQOp1Rb+nJmFH VUn5wGXsDx896c5YJ+4DkfiuYf9oZ7/2IoHdCEL1IGxXcaR2JdhgUDYdtKr6d4F/ngHY v3Ew== X-Gm-Message-State: ANhLgQ35h6NS3UHVdM6QyeUQSjXE3EoapyS1uWqHKOb0g6pM518s4BDg gWSoVxnaTylvl6vzMeKc9x9ilOVxDvLeu8aKjxti/Nbh350= X-Google-Smtp-Source: ADFU+vsOfNBQjrdV9B33kpdNg52Mtl8hYmYWpWyZMY4DyVqziHKNkS//OnHYhhFe9rEdYnpRgRzeWO295H4BygBB3BA= X-Received: by 2002:a2e:9a0d:: with SMTP id o13mr896869lji.151.1584399960459; Mon, 16 Mar 2020 16:06:00 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 16 Mar 2020 16:05:34 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="000000000000d34ed605a100dc38" Archived-At: Subject: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 23:06:08 -0000 --000000000000d34ed605a100dc38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Client Authentication / Proof of Possession* XYZ - client proves use of bound keys via general-purpose mechanisms, including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS - RS access via bearer token or proof-of-possession through any allowable key binding mechanism XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault" makes too ma= ny assumptions about client=E2=80=99s nature and deployment capabilities. AS s= hould support as many as it can (and possibly have an MTI requirement), client supports whatever method makes the most sense for it. PoP mechanisms for RS should be independent of mechanisms at AS. XAuth - client proves use of bounds keys through an auth mechanism at GS - specifies default mechanism using JOSE for GS and RS proof-of-possession calls - RS access via bearer token just like OAuth 2.0 - extensions can define other mechanisms such as HTTP Sig or MTLS to replace JOSE for either GS and/or RS calls XAuth Rationale: having a Client Authentication mechanism defined and as default removes burden of selecting mechanism for most deployments, and ensures interop. =E1=90=A7 --000000000000d34ed605a100dc38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Client Authentication / Proof of Possession

= XYZ
- client proves use of bound keys via general-purpose mechanisms, in= cluding detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
- RS access vi= a bearer token or proof-of-possession through any allowable key binding mec= hanism

XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault= " makes too many assumptions about client=E2=80=99s nature and deploym= ent capabilities. AS should support as many as it can (and possibly have an= MTI requirement), client supports whatever method makes the most sense for= it. PoP mechanisms for RS should be independent of mechanisms at AS.
XAuth
- client proves use of bounds keys through an auth mechanism at = GS
- specifies default mechanism using JOSE for GS and RS proof-of-posse= ssion calls
- RS access via bearer token just like OAuth 2.0
- extens= ions can define other mechanisms such as HTTP Sig or MTLS to replace JOSE f= or either GS and/or RS calls

XAuth Rationale: having a Client Authen= tication mechanism defined and as default removes burden of selecting mecha= nism for most deployments, and ensures interop.
3D""=E1=90= =A7
--000000000000d34ed605a100dc38-- From nobody Mon Mar 16 18:56:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0933A156C for ; Mon, 16 Mar 2020 18:56:57 -0700 (PDT) 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, 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 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 sxot-iizarVI for ; Mon, 16 Mar 2020 18:56:55 -0700 (PDT) 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 639223A1569 for ; Mon, 16 Mar 2020 18:56:54 -0700 (PDT) Received: from [192.168.1.5] (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 02H1upa4017960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Mar 2020 21:56:52 -0400 From: Justin Richer Message-Id: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B1D00CB2-ED47-49DB-A425-E4483BE60881" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Mar 2020 21:56:51 -0400 In-Reply-To: Cc: txauth@ietf.org, Yaron Sheffer To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 01:56:57 -0000 --Apple-Mail=_B1D00CB2-ED47-49DB-A425-E4483BE60881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, naming things is hard =E2=80=94 but I still believe in the name = TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of = getting an authorization delegated to the client software as a = multi-step, multi-party transaction is, I believe, the key insight = that=E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. = It=E2=80=99s not just about going to the AS first =E2=80=94 we had that = in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I = really think it=E2=80=99s about the transaction at the core.=20 Having come of age in the 1990=E2=80=99s, I have particular dislike for = XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80= =9D, and if you read either of those with a growling yell in your head = then you know exactly what I=E2=80=99m talking about. And to Dick=E2=80=99= s rationale for the name below, I absolutely do NOT see this work as = =E2=80=9COAuth with all the extra features=E2=80=9D. I think that does a = disservice to the kind of change we have an opportunity to make here.=20 =E2=80=94 Justin > On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >=20 > Hello everyone >=20 > I prompted a thread around the name of the protocol a while back: >=20 > = https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ = >=20 > As Justin stated "naming is hard" >=20 > Wearing my marketing hat I want to ensure that the name will be = perceived properly in the broader community. >=20 > A recent example that comes to mind are the privacy related works on = the browser storage API. Given that name, one would think that it is = local storage. It is actually about browser cookies. >=20 > Justin discussed his reasons for TxAuth in the thread above (and I'm = sure in other places) >=20 > I chose XAuth in my draft to reflect the eXtensibility goal that we = have over OAuth -- and XAuth is OAuth but with an X to reflect all the = extra features. =3D) >=20 > Other suggestions? >=20 > This will be an agenda item in the BoF -- but the name will NOT be an = open discussion item -- we will summarize what has been discussed on the = list and perhaps do a poll of options presented unless consensus is = obvious from this thread. >=20 > /Dick >=20 >=20 >=20 >=20 >=20 > =E1=90=A7 --Apple-Mail=_B1D00CB2-ED47-49DB-A425-E4483BE60881 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, = naming things is hard =E2=80=94 but I still believe in the name TxAuth. = We=E2=80=99re moving beyond OAuth, and taking the process of getting an = authorization delegated to the client software as a multi-step, = multi-party transaction is, I believe, the key insight that=E2=80=99s = letting us move beyond OAuth=E2=80=99s limitations here. It=E2=80=99s = not just about going to the AS first =E2=80=94 we had that in OAuth 1 = and we=E2=80=99re patching that into OAuth 2 with PAR. I really think = it=E2=80=99s about the transaction at the core. 

Having come of age in the 1990=E2=80=99s,= I have particular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80= =9D and =E2=80=9CX-CITING=E2=80=9D, and if you read either of those with = a growling yell in your head then you know exactly what I=E2=80=99m = talking about. And to Dick=E2=80=99s rationale for the name below, I = absolutely do NOT see this work as =E2=80=9COAuth with all the extra = features=E2=80=9D. I think that does a disservice to the kind of change = we have an opportunity to make here. 

 =E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello everyone

I prompted a thread = around the name of the protocol a while back:

https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDX= OrTr_s_wc/

As Justin stated "naming is = hard"

Wearing = my marketing hat I want to ensure that the name will be = perceived properly in the broader community.
A recent example that comes to mind = are the privacy related works on the browser storage API. Given that = name, one would think that it is local storage. It is actually about = browser cookies.

Justin discussed his reasons for TxAuth in the thread above = (and I'm sure in other places)

I chose XAuth in my draft to reflect = the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but = with an X to reflect all the extra features. =3D)
Other suggestions?

This will be an agenda = item in the BoF -- but the name will NOT be an open discussion item -- = we will summarize what has been discussed on the list and perhaps = do a poll of options presented unless consensus is obvious from this = thread.

/Dick





3D""=E1=90=A7

= --Apple-Mail=_B1D00CB2-ED47-49DB-A425-E4483BE60881-- From nobody Mon Mar 16 23:13:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F753A18C7 for ; Mon, 16 Mar 2020 23:13:46 -0700 (PDT) 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_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=123-do.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 SP4OYSiw4Uib for ; Mon, 16 Mar 2020 23:13:45 -0700 (PDT) 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 EA4DB3A18C6 for ; Mon, 16 Mar 2020 23:13:44 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id m9so5514209ilq.12 for ; Mon, 16 Mar 2020 23:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=123-do.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bNk94So0cjgVos/UjbHbPOGBDW4+ODvFZUvkKkedLJk=; b=iUAY8HDrfEznx9M2RbcwaS90WQr7JQ+v1OR/kB13xEJ904W9sheeARrOhjGiK9Fq6k MC1Klan5Fo8DijElOAoDqvgpd409MfJ8OoTYSYJk0fbsjwlY9Kyqikk4ugdrSfNbMlpD RjpdKiGkb1cbwiSDJURFDgePe4cGmhZstmWUwwZ//JHGXxFAch6EeDXvYFvN8/CJgmLx V0E+veVLqgoUJNYft9BfP0lb4CZkF9djNoM97jharH0OGwYIYD5FZh5EL2WUW+Sw+WcR 5+gguiUy2bUGgJJ1w4WXPxnIQUgdVCrMZCY1eU5pFbbdlROvUIZTzuZXOabNb5vKghAl ffQA== 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=bNk94So0cjgVos/UjbHbPOGBDW4+ODvFZUvkKkedLJk=; b=mAok7Ti+N0k7twxCxlstJMXueNSXawNI2wX6Y8n9lOIllN0lO7zJxGBQcxSGo7yP4i Zocd1lB/Q+ypWQHNfvXOcckKrnP7bo97EPigdENeRNSJGOqRCFM3uswq8uUkB/ddtBGT PmT+9yenJhYElz3qLOO0CwNqwSbCxHAvQ6A7++ZYeBiu35sv38z1vUe8fL9sLXNV4AD3 eFjg8HIojTQ6r5NuCoXS++Rk+662zIsQ7/OPgim2KbDUnGF5HTXk/BVVNIMck7GkHwLb 43aOeOTwdUlMyHQbB1Z6D3dqIyWlSOT9Q/hpmGZdj5aXdLdGoOQ3xVoIfT1eDgD4jjvj YZtQ== X-Gm-Message-State: ANhLgQ1uIYtkU5P578gVJIBLEVOS/DRFwQWtuKieRgmw9iRIDSwkikCr UymSdIVAqXYh5Lc2E0TCWbV4w5ezIpYglSFi8hQf4LQl X-Google-Smtp-Source: ADFU+vsGqLZLS3JCIhMclvci3dhQz2Xq4ChEb0IQs51SpMg6EDFi9Qc1VK9vLVxMgyoS1aTY8QVGlhA0gNMwImWaBQs= X-Received: by 2002:a92:5cd4:: with SMTP id d81mr3445959ilg.57.1584425623522; Mon, 16 Mar 2020 23:13:43 -0700 (PDT) MIME-Version: 1.0 From: Nigel Hamilton Date: Tue, 17 Mar 2020 06:13:32 +0000 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000076a53b05a106d6c5" Archived-At: Subject: [Txauth] on naming X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 06:13:47 -0000 --00000000000076a53b05a106d6c5 Content-Type: text/plain; charset="UTF-8" The 'auth' in Oauth2 - is a bit confusing for the newcomer. Is that 'auth' referring to authentication or authorisation? I like the brevity of 'tx' and this combined with something else (e.g., keytx, safetx, suretx etc) will help its search engine findability. Nige --00000000000076a53b05a106d6c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The 'auth' in Oauth2 - is a bit con= fusing for the newcomer. Is that 'auth' referring to authentication= or authorisation?=C2=A0

I like the brevity of 'tx&#= 39; and this combined with something else (e.g., keytx, safetx, suretx=C2= =A0etc) will help its search engine findability.

N= ige

--00000000000076a53b05a106d6c5-- From nobody Tue Mar 17 02:22:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A423A1B83 for ; Tue, 17 Mar 2020 02:22:45 -0700 (PDT) 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 YctST_OXTylk for ; Tue, 17 Mar 2020 02:22:44 -0700 (PDT) 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 AB99D3A1B84 for ; Tue, 17 Mar 2020 02:22:43 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id 11so20554477wmo.2 for ; Tue, 17 Mar 2020 02:22:43 -0700 (PDT) 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=Xt1yVC/UEKzx4QD/rT736n7vda+sy20mnkSnzu4+i2g=; b=yrhzF8VzyCezQ2sF8APIhnoKunzIHlUGQ0+earR7b2AXEsw9pVRFz/7gB1Bsf3NTAd sf2kqBMcs+6lNFRP0QRf/D1jBsCuW4KzXc3H0A5VHYqUwY2FniERwfm97txMWZ1Xtgzs Xdv23HTcQd6OXKUifOMf52SL5yMMbz1NagD3J8Xw7rL/MhNy8fia/w+1EYmIPdInRQl5 cXAJ5fPYGnQQvJPPOqDvLkRWkvO3agUGMhFwDTSTDzVSWEdFW2htyDRWWpCQwQH3HbFp Jp3KoNRE+vrV7qSF/YVbPslLOcFL/KU24FyypMdnV7ly6l67pcdFpyaKNA5HEKlJWoti KvYg== 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=Xt1yVC/UEKzx4QD/rT736n7vda+sy20mnkSnzu4+i2g=; b=bjvBmb0tZ+ujxXIZY7BvN9W3lciN4sMpgfSems5faJjAAQOraTKQXSwviSwZWWbvBV oFf84hn4NNtsurJzzicCOq9wLuR6mNYr6jGHOpYBXTF3adQDwGCT7nIIAFxHzaDOPcAV TgBal/8AylZXdyl0dxFXNfLXOO+Z/pDW+GgNdhF2S48lykpAqL5mTvpzozPR8c5QmGOL RIUFpeWeYulhDzWT70qqzJgr1VET8Dpxs+rgFNH+Dr/NAV8KASa3hhb0RWdhP6tGwLST I3O/ZgQN4SDU2bZysy3q43y4NKogJAWy7usuJHorq2faofFVBoyU8seH6xAGR/8NKt4k 31dg== X-Gm-Message-State: ANhLgQ2cel5JS3oSIWEkuDf1flIbYJpL6E6TUtZobiI1xyjVxzUmsCvp ky/wBINJOlh3KCvurSBxKuO+/UIfuQw= X-Google-Smtp-Source: ADFU+vuD3jpMpGXF126kuH0dubcrY4u7YzlRZUviBjU3VUocAOR9678NSkpZiv8muidEiVWIKeH7Xg== X-Received: by 2002:a05:600c:410c:: with SMTP id j12mr4351242wmi.77.1584436961631; Tue, 17 Mar 2020 02:22:41 -0700 (PDT) Received: from p200300eb8f2625ada42231c639d4c620.dip0.t-ipconnect.de (p200300EB8F2625ADA42231C639D4C620.dip0.t-ipconnect.de. [2003:eb:8f26:25ad:a422:31c6:39d4:c620]) by smtp.gmail.com with ESMTPSA id s127sm3146361wmf.28.2020.03.17.02.22.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2020 02:22:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> Date: Tue, 17 Mar 2020 10:22:39 +0100 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 09:22:46 -0000 Hi Justin, thanks for explaining the different options. I=E2=80=99m well aware of = the super refresh token (and remember the discussions back then in = Taipei :-)), I have implemented systems using this and other patterns, = too. The underlying assumption for most of those patterns is that the client = upfront knows the boundaries between RS security domains, which = typically means the solution is bespoken.=20 TXAuth is chartered to develop a protocol and not a framework. What = I=E2=80=99m looking for is interoperable protocol support for use of = RS-specific self-contained access tokens in multi-RS deployments. Why RS-specific self-contained access tokens?=20 This is in my experience the most efficient way to empower = high-volume/high-load services in a very efficient, secure, and privacy = preserving fashion.=20 - Every token contains exactly the data the RS needs to perform access = control decisions locally. No need for further database lookups or AS = callbacks, that=E2=80=99s really fast and keeps cost of the AS function = low. - The token itself can be encrypted to protect this data using a = RS-specific key, one could even use HMACs to protect integrity and = authenticity (fast as well).=20 - The token can have a RS-specific lifetime. - Since every token is restricted to a single RS audience, those tokens = also have a baseline replay detection built-in.=20 I think this pattern makes sense in environments with multiple RSs (e.g. = different products) as well. But since every token is minted to the = specific requirements of a certain RS, the AS must be able to mint = different tokens. That doesn=E2=80=99t work properly without some = support in the protocol. Is there a need for multi access tokens support?=20 Well, you implemented it, I implemented it, and I think a couple of = other implementers did it with OAuth 2 in the past. So there seems to be = some need. Why does the rest use the single token pattern? I think some = deployments will indeed only have a single service, but I bet a lot of = implementers did it because their product does not support anything = else.=20 I have experienced this myself when I designed the architecture of the = yes ecosystem. It is a federation of authorization servers with = associated services where every AS represents a certain bank. Since our = partners shall be able to implement their AS using the product they = like, I needed to go with the least common denominator - single access = token. This has a significant consequences: our tokens are basically = handles, so every service calls back to the AS to obtain its data for = every service request. This degrades performance significantly and, = since those tokens are good for multi audiences, it forces us to = generally use sender constrained tokens, which increases complexity for = clients.=20 I would like to give implementers more options in the TXAuth space. = That=E2=80=99s why I advocate to build-in support f=C3=BCr multiple = access tokens into TXAuth.=20 My proposal is based on the following assumptions: - Token format, content, encryption keys and so on are defined as part = of the interface between AS and RS - The client knows what it wants to do and where - Every party contributes the information it has to the overall process = to make it work simply and effectively for everyone.=20 There is no change/addition needed to the request syntax. All it takes = is your new multi token syntax (+ a small addition) in the response.=20 The client uses the =E2=80=9Cresources" structure to communicate what = (actions, further elements) it wants to do and where (locations). [ { =E2=80=9Cactions": ["read", "write"], "locations": ["https://example.com/resource"], =E2=80=9Cdata": ["foo", "bar"] }, { =E2=80=9Cactions": ["write"], "locations": ["https://other_example.com/resource"], =E2=80=9Cdata": ["foo", "bar"] } ] One deployment might use a single token for all RSs, in this case the = token response remains unchanged:=20 { "access_token":{ "value":"08ur4kahfga09u23rnkjasdf", "type":"bearer" } } If the AS has the need to issue multiple access tokens, it could, for = example, use the =E2=80=9Clocations" elements to determine what tokens = it needs to create. Such an AS then uses the multiple_access_tokens = structure augmented by corresponding "locations=E2=80=9D entries in the = token response:=20 "multiple_access_tokens":{ "token_a":{ "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type":"bearer", "locations":[ "https://example.com/resource" ] }, "token_b":{ "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", "type":"bearer", "locations":[ "https://other_example.com/resource" ] } } Since the client passed the locations values in the request, it is also = able to determine where to use what access token.=20 I think that=E2=80=99s pretty simple, especially from a client = perspective. =20 And If the client wants to split access tokens further apart, e.g. to = obtain tokens with less privileges, it can do so using the request = syntax you defined:=20 resources: { token1: [{ actions: ["read", "write", "dolphin"], locations: ["https://server.example.net/", = "https://resource.local/other"], datatypes: ["metadata", "images"] }], token2: [{ actions: ["foo", "bar", "dolphin"], locations: ["https://resource.other/"], datatypes: ["data", "pictures"] }] } In the simplest case, the AS would return the data as in your proposal. If the client asks for a partitioning of privileges that goes across RS = security domains like this { "resources":{ "token1":[ { "actions":[ "read", "write","dolphin" ], "locations":[ = "https://server.example.net/","https://resource.local/other"], "datatypes":[ "metadata","images"] }, { "actions":["read","write"], "locations":["https://example.com/resource"] } ], "token2":[ { "actions":["foo","bar", "dolphin"], "locations":["https://resource.other/"], "datatypes":["data","pictures"] } ] } } the AS would need to further partition the pre-defined tokens like this: "multiple_access_tokens=E2=80=9D:{ =E2=80=9Ctoken1/a":{ "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type":"bearer", = "locations":["https://server.example.net/","https://resource.local/other"]= }, =E2=80=9Ctoken1/b":{ "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", "type":"bearer", "locations":["https://example.com/resource"] }, =E2=80=9Ctoken2":{ "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", "type":"bearer", "locations":[ "https://other_example.com/resource" ] } } Naming of the tokens is a bit tricky but I think solvable. What do you think? best regards, Torsten. > On 15. Mar 2020, at 15:26, Justin Richer wrote: >=20 > On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt = wrote: >>=20 >>> On 15. Mar 2020, at 03:25, Justin Richer wrote: >>>=20 >>> So if the AS needs a client to get different access tokens to call = different RS domains, it does exactly what we do in OAuth 2 today =E2=80=94= it tells the client to get two different access tokens.=20 >>=20 >> How does this work in XYZ? >>=20 >=20 > Without using the multi-access-token thing I=E2=80=99m proposing in = this thread, the client would just make two separate transaction calls = to get two different tokens. There=E2=80=99s a few ways that shakes out = depending on some of the details. In the OAuth world that amounts to = involving the user twice, and it might be the same in XYZ if you=E2=80=99r= e asking for different things: >=20 > 1. Client: Start TX-1 (R-1) > 2. User: Approve R-1 > 3. AS: Issue AT-1(R-1) > 4. Client: Start TX-2 (R-1) > 5. User: approve R-2 > 6. AS: Issue AT-2(R-2) >=20 > Unless you=E2=80=99re getting a super refresh token upfront and then = calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can = do that trick too. >=20 > 1. Client: Start TX-1 (R-1, R-2) > 2. User: Approve R-1, R-2 > 3. AS: Issue AT1 (R-1, R-2) > 4. Client: Continue TX-1 (R-2) > 5. AS: Issue AT-2 (R-2) >=20 > But we=E2=80=99ve got another thing we can use in XYZ to help this, = the user handle. This lets a trusted client tell the AS that it believes = the same user is still there and asking the question, so if the access = rights are OK then you don=E2=80=99t need to involve the user again. We = invented this construct with UMA2, where it=E2=80=99s called the = persisted claims token (PCT). >=20 > 1. Client: Start TX-1 (R-1) > 2. User: Approve R-1 > 3. AS: Issue AT-1 (R-1), user handle U-1 > 4. Client Start TX-2 (R-2, U-1) > 5. AS: Issue AT-2 (R-2) >=20 > Now: With the multi-token request, we can collapse this all back to a = single transaction with multiple outputs: >=20 > 1. Client: Start TX-2 (token1: R-1, token2: R-2) > 2. User Approve R-1, R-2 > 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) >=20 > I haven=E2=80=99t liked any of the multi-access-token solutions to = date because they make things weird for single access token requests. I = like this idea because it=E2=80=99s an optimization for a complex case = that doesn=E2=80=99t change the behavior for the simple case, and in = fact doesn=E2=80=99t even change the expectations for the simple case. = To me, that=E2=80=99s important. >=20 > =E2=80=94 Justin From nobody Tue Mar 17 02:36:45 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7673D3A1BD4 for ; Tue, 17 Mar 2020 02:36:27 -0700 (PDT) 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_FONT_LOW_CONTRAST=0.001, 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=QIhgohNe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2ne5sJ+g 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 fwid3sqDIUpf for ; Tue, 17 Mar 2020 02:36:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4073A1BD1 for ; Tue, 17 Mar 2020 02:36:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 66BF05C016C for ; Tue, 17 Mar 2020 05:36:24 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 17 Mar 2020 05:36:24 -0400 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:subject:content-type; s=fm2; bh=y57el30 XMYr6zyLKzo5jZ4ybTH38vlzQr4WiufoC330=; b=QIhgohNeFyKeejk1bflAm+Q XqqCHcsWZDrZh7AFSUAk41rxaqgl2k6BbpRvZ8IkplBkQv3fNPfqTBnpGiQaSrAR 2tVEEAWfdS88Ga3bkFHVphqqEXlavY/KRJ0VJhgAMbHf/AUlcNXoC5eCbBokfp/A zkujAOcC11gONpFcMpFDL3uda6hCbZr/WfKVZkpTzFamf0/6kou8fRT1WLEi/J/O Ix5tVBOHhHTaQOzhZHPvgMRcmJrlKVW/KGemQZT8tfI4dndfQUHx6B/H1eChQDzb 4jF4kyY1jf2E50UAhFDHCivLGwoEE7Dnvu/+XUkbsCoTnpQi3QdWp8HfQaL0G8A= = 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=y57el3 0XMYr6zyLKzo5jZ4ybTH38vlzQr4WiufoC330=; b=2ne5sJ+ga2emtPADksIvNM IgT4qiPplV22k551mMW8Ny6swjJGbcUH3dvB8aNul5+vNXAhyF7qBin1+PbuES27 nFwV4+84j8EOdjnaQAwfIVc+pIKGJXhS5T7E9H19RnvGJWuNOj58OIqRZpYD1PpD Sj9emD4kF3AfOp1w9JceOy2lwj5TO1J6Y/LH5G85Z7dfEJgF7FunwSokV7+iGUBa 1ZTa6BSWYcF8dw2feMqOMbLwhDTNHJEettrJxHD3uRvJwgbM8jCGkWqqyPwkx2uK HnyVxuTochPN8okg873idTggFRUl35rFbAUR8vdPfBwSh7qfLj+0b+leqGa8MWxA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefhedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhn ghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F362B180090; Tue, 17 Mar 2020 05:36:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 17 Mar 2020 20:36:38 +1100 From: "Bron Gondwana" To: txauth@ietf.org Content-Type: multipart/alternative; boundary=5521281f08e7407e868898b955e7f38c Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 09:36:43 -0000 --5521281f08e7407e868898b955e7f38c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable It looks like adding large meeting support (1000 people) on to a regular= pro account costs just over $100/month. I don't know if you can just tu= rn it on for the months you want it though. A regular Pro account supports up to 100 people, but I guess we don't kn= ow ahead of time how many people to expect, particularly in this interes= ting time. Bron. On Tue, Mar 17, 2020, at 10:04, Dick Hardt wrote: > Virtual Meeting:=20 >=20 > Monday, March 23 > 20:00 - 22:00 UTC * >=20 > *Agenda* > Chair slides, agenda bashing - 10 min. > Charter (link, solicit comments, discuss WG name) - 20 min. > XYZ - Justin (with Q&A) - 20 min. > XAuth - Dick (with Q&A) - 20 min. > Yaron , Dick, Justin - Discussion of differences between protocols - 4= 0 min. > Next steps - 10 min. >=20 > Additions / suggestions? >=20 > *Tech* > The technology to be used is still TBD. We will update the list when w= e know. We are expecting it will be the IETF WebEx. (my preference would= be Zoom if anyone has an account to have LOTS of people on it =3D) >=20 > We are planning on using EtherPad for notes, and for queue management.= >=20 > *Scribe* > Would someone like to volunteer to be the scribe on EtherPad? We would= like to get as much coordination done prior as possible to make the bes= t use of the time. >=20 > /Dick >=20 > * Some time math for 20:00 - 22:00 UTC: >=20 > Pacific Time 13:00-15:00 > Eastern Time 16:00-18:00 > Coordinated Universal Time 20:00-02:00 > Central European Time 21:00-23:00 > India Standard Time 01:30-03:30 > China Standard Time 04:00-06:00 > Australian Eastern Standard Time 07:00-09:00 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5521281f08e7407e868898b955e7f38c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
It looks like adding large meeting support (1000 people) o= n to a regular pro account costs just over $100/month.  I don't kno= w if you can just turn it on for the months you want it though.

A regular Pro account supports up to 100 people, but I guess we d= on't know ahead of time how many people to expect, particularly in this = interesting time.

<= div style=3D"font-family:Arial;">Bron.

On Tue, Mar 17, 2020, at 10:04, Dick Hardt wrot= e:
Vi= rtual Meeting: 

Monday, March 23
20:00 - 22:00 UTC *

A= genda
Chair slides, agenda bashing - 10 min.
<= /div>
Charter (link, solicit comments, discuss WG name) - 20 min.
XYZ - Justin (with Q&A) - 20 min.
XAuth - = Dick  (with Q&A) - 20 min.
Yaron , Dick, Justin -= Discussion of differences between protocols - 40 min.
Nex= t steps - 10 min.

Additio= ns / suggestions?

Tech
The technology to be used is still TBD. We will update the list when we= know. We are expecting it will be the IETF WebEx. (my preference would = be Zoom if anyone has an account to have LOTS of people on it =3D)

We are planning on using EtherPad for notes, and= for queue management.

Scribe
Would someone like to volunteer to be the scribe on EtherPad? We= would like to get as much coordination done prior as possible to make t= he best use of the time.

/Dick

* Some time math for 20:00 - 22:00 UTC:
<= br>
Pacific Time           =        13:00-15:00
Eastern Time =              16:00-18:00
Coordinated Universal Time        20:00-02:00
=
Central European Time          21:00= -23:00
India Standard Time        &nbs= p;   01:30-03:30
China Standard Time    &nb= sp;     04:00-06:00
Australian Eastern Standard = Time       07:00-09:00
3D""=E1=90=A7
-- 
Txa= uth mailing list
Txauth@ietf.org
https://www= .ietf.org/mailman/listinfo/txauth

<= div style=3D"font-family:Arial;">
= --
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--5521281f08e7407e868898b955e7f38c-- From nobody Tue Mar 17 02:40:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0873A1BB7 for ; Tue, 17 Mar 2020 02:40:50 -0700 (PDT) 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=qawx4H2o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2fcPW5qc 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 MA87L9ghT7Ww for ; Tue, 17 Mar 2020 02:40:48 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758383A1BB5 for ; Tue, 17 Mar 2020 02:40:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AED735C0161 for ; Tue, 17 Mar 2020 05:40:47 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 17 Mar 2020 05:40:47 -0400 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:subject:content-type; s=fm2; bh=MWHXmia 3hdPuSUWgN0pxqe7VqY8caIycpARbTWpR4IM=; b=qawx4H2oSsSnv97Au+aUImT 5PsqTSHQ/WEIZ48WTz8IjDT7aBWDA231BrifvfjeZes71q2rDX1J8qLyYjsOwBd2 bbiaAt2+RNpiOO27ap5XioRKp7rGfiwmweeyAyrKWzwV3uGjLXZV/XmEtIdmYWCv 9EmRo1M8rd8tk28O6+rejt50LBM1q0/9OjzKF1NuRxq45DZtLn6GbDaCwg1l/gCF wDt5QoJAL4wGbV0ru+/ecDFwMicOrBc4V0LK+Gz6Nj79kno6TORzUeSmRxMuAgJn Nr4Cdij52s98/ukR84aZlxQvcKylo4xL/X5TfniYCXe9ewOxgYKoytf+FgLsa3g= = 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=MWHXmi a3hdPuSUWgN0pxqe7VqY8caIycpARbTWpR4IM=; b=2fcPW5qcJVhBOUcPMyc8qC s+bwE8xFaBLINtJ2mcbTAkay/+9BZ4elLtiv/EM+uMdkIRkEx1QGOW3++CkmupOl ebhP+Ot6DsGzdXriY2eK2uqW80YQBp79iTPHsPieO5EK/8sj23AZCQAN7B4uiiuF OPzTUk2EzXcgKpRD0AotQAhUvobRFHc7nleS7/R59v+afroXeYr4I7Gz9lCPfQsB JSEb0mJEulUmn4Kbi3s/76+svOvwp/rk65y0d3Xd5r1Xm824jmz6RV/LNK2oUqYy ZFRSiuRXQaSIIn4yxHrc9LA+0oWqTokb9aTHXCO6xeOXGSSyWBB90pYFmVMgAXpQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefhedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhn ghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 385FB180090; Tue, 17 Mar 2020 05:40:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: In-Reply-To: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> References: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> Date: Tue, 17 Mar 2020 20:40:14 +1100 From: "Bron Gondwana" To: txauth@ietf.org Content-Type: multipart/alternative; boundary=a29c85a51eeb46f8a9c49f6ae9698f3f Archived-At: Subject: Re: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 09:40:51 -0000 --a29c85a51eeb46f8a9c49f6ae9698f3f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes to 1,3 and 4. Don't feel sufficiently qualified to provide major con= tributions for 2 and don't have time to be an author. Bron. On Tue, Mar 17, 2020, at 00:50, Yaron Sheffer wrote: > Here's a quick reminder: if you haven't responded to the call yet, ple= ase do so soon. >=20 > Thanks, > Yaron >=20 > On 3/6/20, 18:44, "Yaron Sheffer" wrote: >=20 > Hi Everyone, >=20 > It appears that momentum is forming around the proposed formation of = a TxAuth working group. We=E2=80=99d like to more formally gauge interes= t in proceeding with this work. Please do so by responding to the follow= ing questions: >=20 > 1. Do you support the charter text provided at the end of this email?= Or do you have major objections, blocking concerns or feedback (if so p= lease elaborate)? >=20 > 2. Are you willing to author or participate in the development of the= drafts of this WG? >=20 > 3. Are you willing to help review the drafts of this WG? >=20 > 4. Are you interested in implementing drafts of this WG? >=20 > The call will run for two weeks, until March 21. If you think that th= e charter should be amended In a significant way, please reply on a sepa= rate thread. >=20 > The feedback provided here will help the IESG come to a decision on t= he formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting = in Vancouver as a BoF. >=20 > Thanks, > Yaron and Dick >=20 > --- Charter Text Follows --- >=20 > This group is chartered to develop a fine-grained delegation protocol= for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an aut= horization server. It will expand upon the uses cases currently supporte= d by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to = support authorizations scoped as narrowly as a single transaction, provi= de a clear framework for interaction among all parties involved in the p= rotocol flow, and remove unnecessary dependence on a browser or user-age= nt for coordinating interactions.=20 >=20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the= delegation channel, which happens directly between the client and the a= uthorization server (in contrast with OAuth 2.0 which is initiated by th= e client redirecting the user=E2=80=99s browser). The client and AS will= involve a user to make an authorization decision as necessary through i= nteraction mechanisms indicated by the protocol. This decoupling avoids = many of the security concerns and technical challenges of OAuth 2.0 and = provides a non-invasive path for supporting future types of clients and = interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single inter= action > - Separation between the party authorizing access and the party opera= ting the client requesting access > - A variety of client applications, including Web, mobile, single-pag= e, and interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for= flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of po= ssession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pi= eces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding re= source requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegatio= n process (including identity) >=20 > Additionally, the group will provide mechanisms for management of the= protocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and a= s such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will= be developed in the OAuth Working Group, including functionality back-p= orted from the protocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying cryptograph= ic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.=20 >=20 > The initial work will focus on using HTTP for communication between t= he client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable s= imple mapping to other protocols such as COAP when doing so does not con= flict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, d= etached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points >=20 >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a29c85a51eeb46f8a9c49f6ae9698f3f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes to 1,3 and 4.  Don't feel sufficiently qualified = to provide major contributions for 2 and don't have time to be an author= .

Bron.

On Tue, Mar 17, 2020, at 00:50, Yaron Sheffer wrote:
<= blockquote type=3D"cite" id=3D"qt">
Her= e's a quick reminder: if you haven't responded to the call yet, please d= o so soon.

Thanks,
Yaron

=EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" <= ;yaronf.ietf@gmail.com> wrote:

    Hi E= veryone,
   &n= bsp; 
   = It appears that momentum is forming around the proposed formation of a = TxAuth working group.  We=E2=80=99d like to more formally gauge int= erest in proceeding with this work.  Please do so by responding to = the following questions:
&nbs= p;    
&n= bsp;   1.  Do you support the charter text provided at th= e end of this email?  Or do you have major objections, blocking con= cerns or feedback (if so please elaborate)?
     
    2.  Are you willing to author o= r participate in the development of the drafts of this WG?
     
    3.  Are you will= ing to help review the drafts of this WG?
     
    4.  Are you interested in impleme= nting drafts of this WG?
&nbs= p;    
&n= bsp;   The call will run for two weeks, until March 21. If you= think that the charter should be amended In a significant way, please r= eply on a separate thread.
&n= bsp;    
=     The feedback provided here will help the IESG come to= a decision on the formation of a new WG. Given the constraints of the c= hartering process, regardless of the outcome of this consensus call, we = will be meeting in Vancouver as a BoF.
     
    Thanks,
    Yaron and Dick
     
    --- Charter Text Follows ---
    
    This group is charter= ed to develop a fine-grained delegation protocol for authorization, iden= tity, and API access. This protocol will allow an authorizing party to d= elegate access to client software through an authorization server. It wi= ll expand upon the uses cases currently supported by OAuth 2.0 and OpenI= D Connect (itself an extension of OAuth 2.0) to support authorizations s= coped as narrowly as a single transaction, provide a clear framework for= interaction among all parties involved in the protocol flow, and remove= unnecessary dependence on a browser or user-agent for coordinating inte= ractions. 
  &= nbsp; 
   = ; The delegation process will be acted upon by multiple parties in the p= rotocol, each performing a specific role. The protocol will decouple the= interaction channels, such as the end user=E2=80=99s browser, from the = delegation channel, which happens directly between the client and the au= thorization server (in contrast with OAuth 2.0 which is initiated by the= client redirecting the user=E2=80=99s browser). The client and AS will = involve a user to make an authorization decision as necessary through in= teraction mechanisms indicated by the protocol. This decoupling avoids m= any of the security concerns and technical challenges of OAuth 2.0 and p= rovides a non-invasive path for supporting future types of clients and i= nteraction channels.
 &n= bsp;  
  =   Additionally, the delegation process will allow for:
    
    - Fine-grained specificati= on of access
  &nbs= p; - Approval of AS attestation to identity claims
    - Approval of access to multiple= resources and APIs in a single interaction
    - Separation between the party authori= zing access and the party operating the client requesting access
    - A variety of cl= ient applications, including Web, mobile, single-page, and interaction-c= onstrained applications
 = ;   
 &nb= sp;  The group will define extension points for this protocol to al= low for flexibility in areas including:
    
    - Cryptographic agility for keys, message sign= atures, and proof of possession 
    - User interaction mechanisms including web = and non-web methods
 &nb= sp;  - Mechanisms for conveying user, software, organization, and o= ther pieces of information used in authorization decisions
    - Mechanisms for presen= ting tokens to resource servers and binding resource requests to tokens = and associated cryptographic keys
    - Optimized inclusion of additional information = through the delegation process (including identity)
    
    Additionally, the group will provide= mechanisms for management of the protocol lifecycle including:
    
    - Discovery of the aut= horization server
  = ;  - Revocation of active tokens
    - Query of token rights by resource servers<= br>
    
<= /div>
    Although the a= rtifacts for this work are not intended or expected to be backwards-comp= atible with OAuth 2.0 or OpenID Connect, the group will attempt to simpl= ify migrating from OAuth 2.0 and OpenID Connect to the new protocol wher= e possible.
   = ; 
    Th= is group is not chartered to develop extensions to OAuth 2.0, and as suc= h will focus on new technological solutions not necessarily compatible w= ith OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be d= eveloped in the OAuth Working Group, including functionality back-ported= from the protocol developed here to OAuth 2.0.
    
    The group is chartered to develop mech= anisms for applying cryptographic methods, such as JOSE and COSE, to the= delegation process. This group is not chartered to develop new cryptogr= aphic methods. 
 &n= bsp;  
  =   The initial work will focus on using HTTP for communication betwe= en the client and the authorization server, taking advantage of optimiza= tion features of HTTP2 and HTTP3 where possible, and will strive to enab= le simple mapping to other protocols such as COAP when doing so does not= conflict with the primary focus.
    
    Milestones to include:
     - Core delegation protocol
     - Key pres= entation mechanism bindings to the core protocol for TLS, detached HTTP = signature, and embedded HTTP signatures
     - Identity and authentication convey= ance mechanisms
  &= nbsp;  - Guidelines for use of protocol extension points
<= div style=3D"font-family:Arial;">    
    
    


-- 
Txauth mailing list
Txauth@ietf.org
https= ://www.ietf.org/mailman/listinfo/txauth


=
--
  Bron Gondwana= , CEO, Fastmail Pty Ltd
  brong@fastmailteam.com
<= /div>


--a29c85a51eeb46f8a9c49f6ae9698f3f-- From nobody Tue Mar 17 02:51:42 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EEE3A1BE1 for ; Tue, 17 Mar 2020 02:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, 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=coil.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 awvdgIrfqeuF for ; Tue, 17 Mar 2020 02:51:38 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 DEEA53A1BE0 for ; Tue, 17 Mar 2020 02:51:37 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id b18so20984660edu.3 for ; Tue, 17 Mar 2020 02:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coil.com; s=g; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=PBQQojVBNMNwn7X2wJ35T4pD6mK+hoqZ+hcAHITVJw4=; b=Za8UthPT2wtGk74KYZJJH0c/lWAgZQZQ8zyxm3AdwY9IKbB96f0Yrv4EqSv628nRxY DiIolln8tPcWwzDbt0kR1rz5JPXXp9iDVguZb8qm4F2MH0td/jjXp906o/2tOEoLuYla I2X35OhCdZaaQujx2JMoMcFvyMmXvWit8Ii55tvD4He/3m9lPNjmIJ0spsIPRssqmdRJ dBC8C/orAj8gTJ5702UZJRFhEh77XEHgbHv+rnftPgWy2LmCWsZdpcR5xO9jA5aRXZQi oCXarGqFHOy6bKZw7wz5HEr5ObzxMDVH1Zs+sZFg7KJTSqz1SU72HBgGITe9i3oEu8RQ nAdw== 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:cc; bh=PBQQojVBNMNwn7X2wJ35T4pD6mK+hoqZ+hcAHITVJw4=; b=iSY43sDFc93YBJZ/RR2wd8M0wSJZiIvMDZsjxbRQaN+6sV2yTAezs3/PAtNST2+IFB r9seXMeorwQZQ6tts+a5zNZtzBnuNWcBNp5GqDAwjhZ+MC400gyPk3EKF9vGm9ybTju/ ejj8T1U3h+GwNshx7RuqgSs/EHkroAqPIE3EzMNy8++1aBBN+sxjPJpcQrHzFiZn4Qk1 pMykKWMCH8shRrZe4GpRWsNqXKDbpt617EpeTFHPn8Anwajw5KPDzqSvWWpKURMXh38E aBjP/RCQqscTHMG+za/outs+TpHTjsZhClicTHqml6PfHWnooHi9Mi/zoGYqtkS7RcLi UXaw== X-Gm-Message-State: ANhLgQ16h+Pkq/At0If3cqHgQbArqLjuALTM1PM1FP5USl5gJRUcXX8M JIfGzrWfEY9TLwfdRytp+PQ9YCvkSRHWzNCCySYMLZ7wRxA= X-Google-Smtp-Source: ADFU+vuaNL9sCJfRXLNJpw9DUVFQEZLLO3xMg7kfekPbHSyvQa/PwO+gRN85oZMILFHS1F268bPt/9qNoiTHY4aVx4Y= X-Received: by 2002:a17:906:5214:: with SMTP id g20mr82650ejm.5.1584438690538; Tue, 17 Mar 2020 02:51:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew De Haast Date: Tue, 17 Mar 2020 11:51:19 +0200 Message-ID: Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000517fc905a109e1ad" Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 09:51:40 -0000 --000000000000517fc905a109e1ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My Zoom account seems to be able to support - You can host meetings with unlimited minutes for up to 300 participants. Can check with my Company if they good with us hosting it on our account. But it should be ok if that's what people want to use. Matt On Tue, Mar 17, 2020 at 11:38 AM Bron Gondwana wrote: > It looks like adding large meeting support (1000 people) on to a regular > pro account costs just over $100/month. I don't know if you can just tur= n > it on for the months you want it though. > > A regular Pro account supports up to 100 people, but I guess we don't kno= w > ahead of time how many people to expect, particularly in this interesting > time. > > Bron. > > On Tue, Mar 17, 2020, at 10:04, Dick Hardt wrote: > > Virtual Meeting: > > Monday, March 23 > 20:00 - 22:00 UTC * > > *Agenda* > Chair slides, agenda bashing - 10 min. > Charter (link, solicit comments, discuss WG name) - 20 min. > XYZ - Justin (with Q&A) - 20 min. > XAuth - Dick (with Q&A) - 20 min. > Yaron , Dick, Justin - Discussion of differences between protocols - 40 > min. > Next steps - 10 min. > > Additions / suggestions? > > *Tech* > The technology to be used is still TBD. We will update the list when we > know. We are expecting it will be the IETF WebEx. (my preference would be > Zoom if anyone has an account to have LOTS of people on it =3D) > > We are planning on using EtherPad for notes, and for queue management. > > *Scribe* > Would someone like to volunteer to be the scribe on EtherPad? We would > like to get as much coordination done prior as possible to make the best > use of the time. > > /Dick > > * Some time math for 20:00 - 22:00 UTC: > > Pacific Time 13:00-15:00 > Eastern Time 16:00-18:00 > Coordinated Universal Time 20:00-02:00 > Central European Time 21:00-23:00 > India Standard Time 01:30-03:30 > China Standard Time 04:00-06:00 > Australian Eastern Standard Time 07:00-09:00 > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www..ietf.org/mailman/listinfo/txauth > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000517fc905a109e1ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My Zoom account seems to be able to support
  • You can host meetings with unlimited minutes for up to 300 particip= ants.
Can check with my Company if they good with us hosting= it on our account. But it should be ok if that's what people want to u= se.

Matt

On Tue, Mar = 17, 2020 at 11:38 AM Bron Gondwana <brong@fastmailteam.com> wrote:
It= looks like adding large meeting support (1000 people) on to a regular pro = account costs just over $100/month.=C2=A0 I don't know if you can just = turn it on for the months you want it though.

A regular Pro accou= nt supports up to 100 people, but I guess we don't know ahead of time h= ow many people to expect, particularly in this interesting time.
<= div style=3D"font-family:Arial">
= Bron.

On Tue, Mar = 17, 2020, at 10:04, Dick Hardt wrote:
Virtual Meeting:= =C2=A0

Monday, March 23
20:= 00 - 22:00 UTC *

Agenda
<= div>
Chair slides, agenda bashing - 10 min.
Charter (link= , solicit comments, discuss WG name) - 20 min.
XYZ - Justin (= with Q&A) - 20 min.
XAuth - Dick=C2=A0 (with Q&A) - 2= 0 min.
Yaron , Dick, Justin - Discussion of differences betwe= en protocols - 40 min.
Next steps - 10 min.

Additions / suggestions?

Tech
The technology to be used is still TBD. = We will update the list when we know. We are expecting it will be the IETF = WebEx. (my preference would be Zoom if anyone has an account to have LOTS o= f people on it =3D)

We are planning on using E= therPad for notes, and for queue management.

<= b>Scribe
Would someone like to volunteer to be the scribe= on EtherPad? We would like to get as much coordination done prior as possi= ble to make the best use of the time.

/Dick

* Some time math for 20:00 - 22:00 UTC:

Pacific Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013:00-15:00
Eastern Time=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016:00-18:00
Coordinated Universal Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 20:00-02:00
Central European Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21:00-23:00=
India Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 01:30-03:30
China Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 04:00-06:00
Australian Eastern Standard Time=C2=A0 =C2= =A0 =C2=A0 =C2=A007:00-09:00
3D""= =E1=90=A7
--=C2=A0
Txauth mailing= list


--
=C2=A0 Bron Gondwana, C= EO, Fastmail Pty Ltd


--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000517fc905a109e1ad-- From nobody Tue Mar 17 03:25:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3293A1C52 for ; Tue, 17 Mar 2020 03:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=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 WD-o5YvP_BR4 for ; Tue, 17 Mar 2020 03:25:25 -0700 (PDT) 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 6C67A3A1C50 for ; Tue, 17 Mar 2020 03:25:25 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id r7so15300832wmg.0 for ; Tue, 17 Mar 2020 03:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=o+cM5N0Pz1gnsp1CM+Z8+qoU7BF9kC4yykXv2crpHH0=; b=TzilY2RQVucqaYll2592En5q3rJEvh2K2uUd7EJfcVfmPMaOBDwPJuPEqzaQGc2/Qe GMbjXBm/CPR57VPJyvh4/BzIie0vXtBW42iBpsfDdRwZSZCWMENk76fvGUNUt7GXm+oE QJg2z1MXkWnjnW3jraU9R8sbztmeIAqWpoJTUcjuyyAWHWKjE3uTi2cKndEVF5e/ce1k d6adYW2VjZyBj5jB42NRxSZhAfJ6wyut1S0FHi3+s0pUg0nSIhDHf5t8PkXR8KGKetDo Xhnduyh1emaRuTQ3PuRZbbTSXUOKZ/a5ShD8AKpCFDW5ZDRvvbWFkfQbuGqWU+MHJVWK 6k7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=o+cM5N0Pz1gnsp1CM+Z8+qoU7BF9kC4yykXv2crpHH0=; b=MynQV8JdSZqu9XUjSeF0qHpPIQtM5nOMVyobob10JRAiJoG7y+QAc6rNl5Lo90BmpA IoUKn4Fi5PAwuNHriCAhjuwHI+gnKB9HVxNz1LqW4lk4VkFULqCk88T7ykOTwJbjlgXT 7x4jR4k3MjtxdYO9xr2jpUxrnIYh9k3OhJy0dziSVJIXNd+ewNAX542KGHaea8g1gWgJ bBLYWeYusn0BBESS7ANKqwUc4WLC1zYd4ionm+NphVpLjQxcIrfCmiy4hzP5FPZLklCy 0PdET7Fw65UW4y90s/gA1m93BtG/khAiPWV1TfzKwHN2lQsO4JmbwWR6Dyi5E0wg2zKl R5VA== X-Gm-Message-State: ANhLgQ301Qr4V5XWzjM2SL0rWLMPAyblqNzEF6e+69YH/M4Owjdhnq90 dLO3ZYV1QGwC2AyLcExAc8TM7aAZ X-Google-Smtp-Source: ADFU+vtcZRdcFYbaeLWIHaxkWE8dveGxeKY20dZFpp7ENJU7AY4YZnO29aKb9ykgr83lJPTdGUYykw== X-Received: by 2002:a1c:9658:: with SMTP id y85mr4609533wmd.63.1584440723665; Tue, 17 Mar 2020 03:25:23 -0700 (PDT) Received: from [10.0.0.144] (bzq-79-178-61-110.red.bezeqint.net. [79.178.61.110]) by smtp.gmail.com with ESMTPSA id y12sm3231325wmi.48.2020.03.17.03.25.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2020 03:25:22 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Tue, 17 Mar 2020 12:25:21 +0200 From: Yaron Sheffer To: Matthew De Haast CC: Message-ID: <8D9DF202-B1A1-4326-9129-666CBBC57DD1@gmail.com> Thread-Topic: [Txauth] TxAuth BoF draft agenda References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3667292722_1631340489" Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 10:25:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3667292722_1631340489 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable The IESG will be running a trial session tomorrow for working group chairs,= with the tool we have used in the past for virtual WG meetings, namely WebE= x (along with Etherpad and Jabber). Let=E2=80=99s see how it goes. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 =20 From: Txauth on behalf of Matthew De Haast Date: Tuesday, March 17, 2020 at 11:51 Cc: Subject: Re: [Txauth] TxAuth BoF draft agenda =20 My Zoom account seems to be able to support=20 You can host meetings with unlimited minutes for up to 300 participants. Can check with my Company if they good with us hosting it on our account. B= ut it should be ok if that's what people want to use. =20 Matt =20 On Tue, Mar 17, 2020 at 11:38 AM Bron Gondwana wro= te: It looks like adding large meeting support (1000 people) on to a regular pr= o account costs just over $100/month. I don't know if you can just turn it = on for the months you want it though. =20 A regular Pro account supports up to 100 people, but I guess we don't know = ahead of time how many people to expect, particularly in this interesting ti= me. =20 Bron. =20 On Tue, Mar 17, 2020, at 10:04, Dick Hardt wrote: Virtual Meeting:=20 =20 Monday, March 23 20:00 - 22:00 UTC * =20 Agenda Chair slides, agenda bashing - 10 min. Charter (link, solicit comments, discuss WG name) - 20 min. XYZ - Justin (with Q&A) - 20 min. XAuth - Dick (with Q&A) - 20 min. Yaron , Dick, Justin - Discussion of differences between protocols - 40 min= . Next steps - 10 min. =20 Additions / suggestions? =20 Tech The technology to be used is still TBD. We will update the list when we kno= w. We are expecting it will be the IETF WebEx. (my preference would be Zoom = if anyone has an account to have LOTS of people on it =3D) =20 We are planning on using EtherPad for notes, and for queue management. =20 Scribe Would someone like to volunteer to be the scribe on EtherPad? We would like= to get as much coordination done prior as possible to make the best use of = the time. =20 /Dick =20 * Some time math for 20:00 - 22:00 UTC: =20 Pacific Time 13:00-15:00 Eastern Time 16:00-18:00 Coordinated Universal Time 20:00-02:00 Central European Time 21:00-23:00 India Standard Time 01:30-03:30 China Standard Time 04:00-06:00 Australian Eastern Standard Time 07:00-09:00 =E1=90=A7 --=20 Txauth mailing list Txauth@ietf.org https://www..ietf.org/mailman/listinfo/txauth =20 =20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com =20 =20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3667292722_1631340489 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The IESG will be running a = trial session tomorrow for working group chairs, with the tool we have used = in the past for virtual WG meetings, namely WebEx (along with Etherpad and J= abber). Let=E2=80=99s see how it goes.

 = ;

Thanks,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 =

 

<= b>From: Txauth <txauth-bounces@ietf.org> on behal= f of Matthew De Haast <matt=3D40coil.com@dmarc.ietf.org>
Date: Tuesday, March 17, 2020 at 11:51
Cc: <txauth@ietf.org>
<= b>Subject: Re: [Txauth] TxAuth BoF draft agenda

 

My Zoom account seems to be able to support

  • You can host meetings with unlimited minutes = for up to 300 participants.

Can check with my Company if they good with us hosting it on our account. = But it should be ok if that's what people want to use.

<= div>

 

Ma= tt

 

On Tue, Mar 17, 2020 at 11:38 AM Bron Gondwana <brong@fastmailteam.com> wrote:<= o:p>

It looks = like adding large meeting support (1000 people) on to a regular pro account = costs just over $100/month.  I don't know if you can just turn it on fo= r the months you want it though.

 

A regular Pro account supports up to 100 people, but I guess we don't kn= ow ahead of time how many people to expect, particularly in this interesting= time.

 

Bron.

 

On Tue, Mar 17= , 2020, at 10:04, Dick Hardt wrote:

Virtual Meeting: 

 

Monday, M= arch 23

20:00 - 22:00 UTC *=

 

Agenda

Chair slides, agenda bashing - 10 min.

=

Charter (link, solicit comments, discuss WG name) - 20 mi= n.

XYZ - Justin (with Q&A) -= 20 min.

XAuth - Dick  (wit= h Q&A) - 20 min.

Yaron , Dic= k, Justin - Discussion of differences between protocols - 40 min.=

Next steps - 10 min.

<= /div>

 

Additions / suggestions?

 

Tech=

The technology to be used is still T= BD. We will update the list when we know. We are expecting it will be the IE= TF WebEx. (my preference would be Zoom if anyone has an account to have LOTS= of people on it =3D)

 <= /o:p>

We are planning on using EtherPad for= notes, and for queue management.

 

Scribe

Would someone like to volunteer to be the= scribe on EtherPad? We would like to get as much coordination done prior as= possible to make the best use of the time.

 

/Dick

 

* Some time math for 20:00 - 22:00 UTC:

 

= Pacific Time                  &= nbsp;13:00-15:00

Eastern Time&nb= sp;              16:00-18:00

Coordinated Universal Time    &nbs= p;   20:00-02:00

Central Eu= ropean Time          21:00-23:00

India Standard Time        &nb= sp;   01:30-03:30

China Sta= ndard Time          04:00-06:00

Australian Eastern Standard Time     = ;  07:00-09:00

= 3D"Image=E1=90=A7

=

-- 

Txauth mailing list

 

 

--

  Bron Gondwana, CEO, Fastmai= l Pty Ltd

 

 

--
Txauth mailing list
<= a href=3D"mailto:Txauth@ietf.org" target=3D"_blank">Txauth@ietf.org
https://ww= w.ietf.org/mailman/listinfo/txauth

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/m= ailman/listinfo/txauth

--B_3667292722_1631340489-- From nobody Tue Mar 17 06:10:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D283A0043 for ; Tue, 17 Mar 2020 06:10:35 -0700 (PDT) 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, 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 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 aoFG2fn2htiL for ; Tue, 17 Mar 2020 06:10:33 -0700 (PDT) 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 A21FA3A0041 for ; Tue, 17 Mar 2020 06:10:33 -0700 (PDT) Received: from [192.168.1.5] (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 02HDAUgu030093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 09:10:31 -0400 From: Justin Richer Message-Id: <8CA9DB9C-017C-4CF8-88F2-08823CD26256@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2B4A4F3A-543D-4565-AE05-E3FC6BE29CBB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Mar 2020 09:10:30 -0400 In-Reply-To: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> Cc: Yaron Sheffer , txauth@ietf.org To: Dick Hardt References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 13:10:36 -0000 --Apple-Mail=_2B4A4F3A-543D-4565-AE05-E3FC6BE29CBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And another thought =E2=80=94 there=E2=80=99s a pretty decent chance = that we=E2=80=99ll end up branding this whole effort OAuth 3 in the = future.=20 The list is named =E2=80=98txauth=E2=80=99. Therefore, calling what = we=E2=80=99re working on anything different from that seems silly and = premature. I say we just stick with TxAuth to match the list and avoid the whole = naming discussion entirely. =E2=80=94 Justin > On Mar 16, 2020, at 9:56 PM, Justin Richer wrote: >=20 > Yes, naming things is hard =E2=80=94 but I still believe in the name = TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of = getting an authorization delegated to the client software as a = multi-step, multi-party transaction is, I believe, the key insight = that=E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. = It=E2=80=99s not just about going to the AS first =E2=80=94 we had that = in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I = really think it=E2=80=99s about the transaction at the core.=20 >=20 > Having come of age in the 1990=E2=80=99s, I have particular dislike = for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2= =80=9D, and if you read either of those with a growling yell in your = head then you know exactly what I=E2=80=99m talking about. And to = Dick=E2=80=99s rationale for the name below, I absolutely do NOT see = this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I = think that does a disservice to the kind of change we have an = opportunity to make here.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 16, 2020, at 7:04 PM, Dick Hardt > wrote: >>=20 >> Hello everyone >>=20 >> I prompted a thread around the name of the protocol a while back: >>=20 >> = https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ = >>=20 >> As Justin stated "naming is hard" >>=20 >> Wearing my marketing hat I want to ensure that the name will be = perceived properly in the broader community. >>=20 >> A recent example that comes to mind are the privacy related works on = the browser storage API. Given that name, one would think that it is = local storage. It is actually about browser cookies. >>=20 >> Justin discussed his reasons for TxAuth in the thread above (and I'm = sure in other places) >>=20 >> I chose XAuth in my draft to reflect the eXtensibility goal that we = have over OAuth -- and XAuth is OAuth but with an X to reflect all the = extra features. =3D) >>=20 >> Other suggestions? >>=20 >> This will be an agenda item in the BoF -- but the name will NOT be an = open discussion item -- we will summarize what has been discussed on the = list and perhaps do a poll of options presented unless consensus is = obvious from this thread. >>=20 >> /Dick >>=20 >>=20 >>=20 >>=20 >>=20 >> =E1=90=A7 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_2B4A4F3A-543D-4565-AE05-E3FC6BE29CBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And = another thought =E2=80=94 there=E2=80=99s a pretty decent chance that = we=E2=80=99ll end up branding this whole effort OAuth 3 in the = future. 

The = list is named =E2=80=98txauth=E2=80=99. Therefore, calling what we=E2=80=99= re working on anything different from that seems silly and = premature.

I = say we just stick with TxAuth to match the list and avoid the whole = naming discussion entirely.

 =E2=80=94 Justin

On Mar = 16, 2020, at 9:56 PM, Justin Richer <jricher@mit.edu> wrote:

Yes, naming things is = hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80=99re = moving beyond OAuth, and taking the process of getting an authorization = delegated to the client software as a multi-step, multi-party = transaction is, I believe, the key insight that=E2=80=99s letting us = move beyond OAuth=E2=80=99s limitations here. It=E2=80=99s not just = about going to the AS first =E2=80=94 we had that in OAuth 1 and we=E2=80=99= re patching that into OAuth 2 with PAR. I really think it=E2=80=99s = about the transaction at the core. 

Having come of age in the 1990=E2=80=99s,= I have particular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80= =9D and =E2=80=9CX-CITING=E2=80=9D, and if you read either of those with = a growling yell in your head then you know exactly what I=E2=80=99m = talking about. And to Dick=E2=80=99s rationale for the name below, I = absolutely do NOT see this work as =E2=80=9COAuth with all the extra = features=E2=80=9D. I think that does a disservice to the kind of change = we have an opportunity to make here. 

 =E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello everyone

I prompted a thread around the name of = the protocol a while back:

https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDX= OrTr_s_wc/

As Justin stated "naming is = hard"

Wearing = my marketing hat I want to ensure that the name will be = perceived properly in the broader community.
A recent example that comes to mind = are the privacy related works on the browser storage API. Given that = name, one would think that it is local storage. It is actually about = browser cookies.

Justin discussed his reasons for TxAuth in the thread above = (and I'm sure in other places)

I chose XAuth in my draft to reflect = the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but = with an X to reflect all the extra features. =3D)
Other suggestions?

This will be an agenda = item in the BoF -- but the name will NOT be an open discussion item -- = we will summarize what has been discussed on the list and perhaps = do a poll of options presented unless consensus is obvious from this = thread.

/Dick





3D""=E1=90=A7

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_2B4A4F3A-543D-4565-AE05-E3FC6BE29CBB-- From nobody Tue Mar 17 06:12:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CA93A010D for ; Tue, 17 Mar 2020 06:12:08 -0700 (PDT) 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 l-oyBkFgHi4k for ; Tue, 17 Mar 2020 06:12:07 -0700 (PDT) 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 4556D3A03EA for ; Tue, 17 Mar 2020 06:12:07 -0700 (PDT) Received: from [192.168.1.5] (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 02HDC4CC030542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 09:12:05 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6533B4FD-29A9-4671-93C0-467841D0633A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Mar 2020 09:12:04 -0400 In-Reply-To: Cc: txauth@ietf.org To: Nigel Hamilton References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] on naming X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 13:12:18 -0000 --Apple-Mail=_6533B4FD-29A9-4671-93C0-467841D0633A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In OAuth 2 it=E2=80=99s for =E2=80=9Cauthorization=E2=80=9D, which is = itself a bit misleading because it=E2=80=99s a delegation protocol at = its heart. What we=E2=80=99re proposing here covers aspects of both = authorization delegation as well as authentication and identity.=20 =E2=80=94 Justin > On Mar 17, 2020, at 2:13 AM, Nigel Hamilton wrote: >=20 >=20 > The 'auth' in Oauth2 - is a bit confusing for the newcomer. Is that = 'auth' referring to authentication or authorisation?=20 >=20 > I like the brevity of 'tx' and this combined with something else = (e.g., keytx, safetx, suretx etc) will help its search engine = findability. >=20 > Nige >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_6533B4FD-29A9-4671-93C0-467841D0633A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = OAuth 2 it=E2=80=99s for =E2=80=9Cauthorization=E2=80=9D, which is = itself a bit misleading because it=E2=80=99s a delegation protocol at its heart. What we=E2=80=99re = proposing here covers aspects of both authorization delegation as well = as authentication and identity. 

 =E2=80=94 Justin

On Mar 17, 2020, at 2:13 AM, Nigel Hamilton <nige@123.do> = wrote:


The 'auth' in Oauth2 - is a bit confusing for the = newcomer. Is that 'auth' referring to authentication or = authorisation? 

I= like the brevity of 'tx' and this combined with something else (e.g., = keytx, safetx, suretx etc) will help its search engine = findability.

Nige

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_6533B4FD-29A9-4671-93C0-467841D0633A-- From nobody Tue Mar 17 09:24:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0871D3A02BB for ; Tue, 17 Mar 2020 09:24:25 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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=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 IrmMEJKuUIec for ; Tue, 17 Mar 2020 09:24:23 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640117.outbound.protection.outlook.com [40.107.64.117]) (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 075203A0829 for ; Tue, 17 Mar 2020 09:24:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CojEzhBuCaYvUbMxYB9oh62DXAP2ZwANMyqK1VA3PeKp6zwqd1fa6rNxnK2nDIebbfq+QRlM1VQFy61LgJ7Y6hRKNtMYzKPfyzBbd96wWnIkLz0nL9yJQsA5k/gWa5a/xDAkS1xS5sEVOx/y4F2qotubx4Bfq2aNbWZ2TswF8oNnr6a+0sx7CzwlQvcHHBH+7kTUyNekIFz7J38BQmC9mGMjbxawWyqRB/gFBnfIogjyFfdANhsXCGEaUtET+C6XqSHe2x3b+yNz3q0Gm71U+JIACdnAVoxvO3DBSfLuvxsjHDZnoLdhhHZNTniNJLa5ZT/jxhhmra30ABwyrRn4sQ== 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=LFM/U2ZGP9rPSnvCLs0ypTjOHHmzydBxRA6aA+1uNa0=; b=imL5U53hrKktdpQHUtEB8ANnzqGJHy39p80AISSbA4PwjNhBoUjeGgpbXvQB80HH26OjhNwc0jMHG2FIRmCeuZsaGWC4huWtHKZANnxMoQQjamnhU6ZgZTHhAj5o9UEHSDQ7oAUlFnKL9q3Bq+2GLuWQBEYCf0Rb+4TQL29LU0LNyltUE4hglbAthSixfMTLqZWIMTXJ/YUOVc5MYwAmPw0h0wj3GEAtWDC3Xpl9MALxrqF54GP7o/k+UodGkGMTZavNxXh98nKj8prRK4EhoAuRMOk4M+MVCfqT4VRtw3dobXqqrDRTN954Hd814i3pDKNXJK/1UsTqeFZlHKKZGw== 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=LFM/U2ZGP9rPSnvCLs0ypTjOHHmzydBxRA6aA+1uNa0=; b=WTa0RlrRvBG/tUrQaqVN13lZYNXak/TqCVic554qBoFZE/XTxOv9tR0w0CB+afDxMoWTkDJ0IOWYao++jcv1q6n1PTfqbmBkcrcUTaYidEf5J6HaEWGKlSfENt5osEmLK43+vLhKfRMrGFytb9KfZMQ5pHL8h+3v7Xj8aq5hpOw= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0712.namprd00.prod.outlook.com (2603:10b6:610:ad::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2871.0; Tue, 17 Mar 2020 16:24:16 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::a56a:2989:f37f:7a7a]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::a56a:2989:f37f:7a7a%3]) with mapi id 15.20.2872.000; Tue, 17 Mar 2020 16:24:16 +0000 From: Mike Jones To: Justin Richer , Dick Hardt CC: Yaron Sheffer , "txauth@ietf.org" Thread-Topic: [Txauth] WG name: TxAuth? XAuth? Something else? Thread-Index: AdX8eH75j5z5QGTpTDekVlY+cheNqQ== Date: Tue, 17 Mar 2020 16:24:16 +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_ActionId=d1793ebb-37b8-4441-a06e-00008ff09252; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-17T16:21:27Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.81.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0dcc3ca8-4d0f-437b-79ed-08d7ca8fa361 x-ms-traffictypediagnostic: CH2PR00MB0712: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(346002)(376002)(39860400002)(396003)(136003)(199004)(9686003)(71200400001)(6506007)(53546011)(66574012)(10290500003)(861006)(8936002)(81166006)(66556008)(52536014)(81156014)(5660300002)(110136005)(66446008)(54906003)(76116006)(7696005)(8676002)(66476007)(66946007)(64756008)(55016002)(86362001)(316002)(186003)(478600001)(33656002)(2906002)(26005)(8990500004)(4326008)(966005)(99710200001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0712; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Rmn+6WoBP7duQRH1K1ZToEG/57QPQILNhIsOE+yxQQOJdjVZ5eboyx+C56Z5OVzUyTpNPqTYerbNSVZ4k9GvX2/x6PbiJFcS3JmuEFE792sAXueqEybICJ42+vYg/Fi97UdCOU+6iUNjhq+qmPlSD0xnwDbinmvGs3isey0O98yYFoCnNkpJSUMGNjQYBuyq9jTrPMoCtx81O7uPrHT2l4szL+bf2Gwxik2y0OldCOz9EHEbGXHLuXWqKNwSGlY47ENHovWdW/C+HjD9X6VEigaWDoBqxo+XCw8lVcKbZtgF5KkCr2mVk8HoJ3LERngxgTrHs2mt7p/Nq/MTlg0rRIvsDrfBtwiFwgNEXo5ltg3PAaFsES/eBTbkAfuZA1b+kXQaOMEfo491UPatUP9wqPcpgYH6eIDRURRXgzP5wWsHy7iJFYGE0KohLmNqmjDpziIbBQqX84Ud9RJzW8X/9t9YPxOdVfd5J0w/i75kxqlTICZ8/+cTtquO6AHA6hhhqTN8bZuAWokieGoWFCrQSc46eJnVNxU9cPITHHPiLMW/M+WIm0cq0EyYUExO/MWgMemgJoTXissPwsLXnHboGw== x-ms-exchange-antispam-messagedata: QdIh2GbEA0wROpzEV2QLkM+zwmSfZpsKGJabGFYJHO31qc2ZmYC1x+TZNuD1zX7+ktOllVl8FTJPm3+gS6YPbidDxUUynuCDGZ3xljhnk9pLxiKOHON/Jpps6RrEBNIsphNGLce1YTRXDDe9ARk3JA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678313B29175587B7CD3E1AF5F60CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0dcc3ca8-4d0f-437b-79ed-08d7ca8fa361 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 16:24:16.5108 (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: o4+IO+aYndRkZUI+KXxpKxkCTRPmSc6zemDkU4Gdub4nSPpSoWAtRZV4n7+Wr8qZghqeyPToKiGzhw6j5jiq6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0712 Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 16:24:42 -0000 --_000_CH2PR00MB0678313B29175587B7CD3E1AF5F60CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhpcyB3b3JrIHdlcmUgaGFwcGVuaW5nIGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBj YWxsaW5nIGl0IE9BdXRoIDMgd291bGQgYmUgYSBkZWNpc2lvbiB0aGF0IGNvdWxkIGJlIHRha2Vu IGJ5IHRoZSB3b3JraW5nIGdyb3VwLiAgQnV0IHVubGVzcyBpdCBtb3ZlcyB0byB0aGUgT0F1dGgg d29ya2luZyBncm91cCwgSSBiZWxpZXZlIHRoYXQgaXQgd291bGQgYmUgdW5yZWFzb25hYmxlIHRv IHVzdXJwIGJyYW5kaW5nIGJlbG9uZ2luZyB0byBhIGRpZmZlcmVudCB3b3JraW5nIGdyb3VwLiAg VHhBdXRoIHNob3VsZCBoYXZlIGl0cyBvd24gZGlzdGluY3QgYnJhbmQgY2hvc2VuIGJ5IGl0cyB0 by1iZS1mb3JtZWQgd29ya2luZyBncm91cC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVHhhdXRoIDx0eGF1 dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IFR1 ZXNkYXksIE1hcmNoIDE3LCAyMDIwIDY6MTEgQU0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0 QGdtYWlsLmNvbT4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+OyB0 eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBXRyBuYW1lOiBUeEF1dGg/IFhB dXRoPyBTb21ldGhpbmcgZWxzZT8NCg0KQW5kIGFub3RoZXIgdGhvdWdodCDigJQgdGhlcmXigJlz IGEgcHJldHR5IGRlY2VudCBjaGFuY2UgdGhhdCB3ZeKAmWxsIGVuZCB1cCBicmFuZGluZyB0aGlz IHdob2xlIGVmZm9ydCBPQXV0aCAzIGluIHRoZSBmdXR1cmUuDQoNClRoZSBsaXN0IGlzIG5hbWVk IOKAmHR4YXV0aOKAmS4gVGhlcmVmb3JlLCBjYWxsaW5nIHdoYXQgd2XigJlyZSB3b3JraW5nIG9u IGFueXRoaW5nIGRpZmZlcmVudCBmcm9tIHRoYXQgc2VlbXMgc2lsbHkgYW5kIHByZW1hdHVyZS4N Cg0KSSBzYXkgd2UganVzdCBzdGljayB3aXRoIFR4QXV0aCB0byBtYXRjaCB0aGUgbGlzdCBhbmQg YXZvaWQgdGhlIHdob2xlIG5hbWluZyBkaXNjdXNzaW9uIGVudGlyZWx5Lg0KDQog4oCUIEp1c3Rp bg0KDQoNCk9uIE1hciAxNiwgMjAyMCwgYXQgOTo1NiBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hl ckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KWWVzLCBuYW1pbmcg dGhpbmdzIGlzIGhhcmQg4oCUIGJ1dCBJIHN0aWxsIGJlbGlldmUgaW4gdGhlIG5hbWUgVHhBdXRo LiBXZeKAmXJlIG1vdmluZyBiZXlvbmQgT0F1dGgsIGFuZCB0YWtpbmcgdGhlIHByb2Nlc3Mgb2Yg Z2V0dGluZyBhbiBhdXRob3JpemF0aW9uIGRlbGVnYXRlZCB0byB0aGUgY2xpZW50IHNvZnR3YXJl IGFzIGEgbXVsdGktc3RlcCwgbXVsdGktcGFydHkgdHJhbnNhY3Rpb24gaXMsIEkgYmVsaWV2ZSwg dGhlIGtleSBpbnNpZ2h0IHRoYXTigJlzIGxldHRpbmcgdXMgbW92ZSBiZXlvbmQgT0F1dGjigJlz IGxpbWl0YXRpb25zIGhlcmUuIEl04oCZcyBub3QganVzdCBhYm91dCBnb2luZyB0byB0aGUgQVMg Zmlyc3Qg4oCUIHdlIGhhZCB0aGF0IGluIE9BdXRoIDEgYW5kIHdl4oCZcmUgcGF0Y2hpbmcgdGhh dCBpbnRvIE9BdXRoIDIgd2l0aCBQQVIuIEkgcmVhbGx5IHRoaW5rIGl04oCZcyBhYm91dCB0aGUg dHJhbnNhY3Rpb24gYXQgdGhlIGNvcmUuDQoNCkhhdmluZyBjb21lIG9mIGFnZSBpbiB0aGUgMTk5 MOKAmXMsIEkgaGF2ZSBwYXJ0aWN1bGFyIGRpc2xpa2UgZm9yIFhBdXRoLiBJdCBzb3VuZHMgdG9v IOKAnFgtVFJFTUXigJ0gYW5kIOKAnFgtQ0lUSU5H4oCdLCBhbmQgaWYgeW91IHJlYWQgZWl0aGVy IG9mIHRob3NlIHdpdGggYSBncm93bGluZyB5ZWxsIGluIHlvdXIgaGVhZCB0aGVuIHlvdSBrbm93 IGV4YWN0bHkgd2hhdCBJ4oCZbSB0YWxraW5nIGFib3V0LiBBbmQgdG8gRGlja+KAmXMgcmF0aW9u YWxlIGZvciB0aGUgbmFtZSBiZWxvdywgSSBhYnNvbHV0ZWx5IGRvIE5PVCBzZWUgdGhpcyB3b3Jr IGFzIOKAnE9BdXRoIHdpdGggYWxsIHRoZSBleHRyYSBmZWF0dXJlc+KAnS4gSSB0aGluayB0aGF0 IGRvZXMgYSBkaXNzZXJ2aWNlIHRvIHRoZSBraW5kIG9mIGNoYW5nZSB3ZSBoYXZlIGFuIG9wcG9y dHVuaXR5IHRvIG1ha2UgaGVyZS4NCg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBNYXIgMTYsIDIwMjAs IGF0IDc6MDQgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZWxsbyBldmVyeW9uZQ0KDQpJIHByb21wdGVk IGEgdGhyZWFkIGFyb3VuZCB0aGUgbmFtZSBvZiB0aGUgcHJvdG9jb2wgYSB3aGlsZSBiYWNrOg0K DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC9aVlFWYkh0NEFE cWVoS3JCRFhPclRyX3Nfd2MvDQoNCkFzIEp1c3RpbiBzdGF0ZWQgIm5hbWluZyBpcyBoYXJkIg0K DQpXZWFyaW5nIG15IG1hcmtldGluZyBoYXQgSSB3YW50IHRvIGVuc3VyZSB0aGF0IHRoZSBuYW1l IHdpbGwgYmUgcGVyY2VpdmVkIHByb3Blcmx5IGluIHRoZSBicm9hZGVyIGNvbW11bml0eS4NCg0K QSByZWNlbnQgZXhhbXBsZSB0aGF0IGNvbWVzIHRvIG1pbmQgYXJlIHRoZSBwcml2YWN5IHJlbGF0 ZWQgd29ya3Mgb24gdGhlIGJyb3dzZXIgc3RvcmFnZSBBUEkuIEdpdmVuIHRoYXQgbmFtZSwgb25l IHdvdWxkIHRoaW5rIHRoYXQgaXQgaXMgbG9jYWwgc3RvcmFnZS4gSXQgaXMgYWN0dWFsbHkgYWJv dXQgYnJvd3NlciBjb29raWVzLg0KDQpKdXN0aW4gZGlzY3Vzc2VkIGhpcyByZWFzb25zIGZvciBU eEF1dGggaW4gdGhlIHRocmVhZCBhYm92ZSAoYW5kIEknbSBzdXJlIGluIG90aGVyIHBsYWNlcykN Cg0KSSBjaG9zZSBYQXV0aCBpbiBteSBkcmFmdCB0byByZWZsZWN0IHRoZSBlWHRlbnNpYmlsaXR5 IGdvYWwgdGhhdCB3ZSBoYXZlIG92ZXIgT0F1dGggLS0gYW5kIFhBdXRoIGlzIE9BdXRoIGJ1dCB3 aXRoIGFuIFggdG8gcmVmbGVjdCBhbGwgdGhlIGV4dHJhIGZlYXR1cmVzLiA9KQ0KDQpPdGhlciBz dWdnZXN0aW9ucz8NCg0KVGhpcyB3aWxsIGJlIGFuIGFnZW5kYSBpdGVtIGluIHRoZSBCb0YgLS0g YnV0IHRoZSBuYW1lIHdpbGwgTk9UIGJlIGFuIG9wZW4gZGlzY3Vzc2lvbiBpdGVtIC0tIHdlIHdp bGwgc3VtbWFyaXplIHdoYXQgaGFzIGJlZW4gZGlzY3Vzc2VkIG9uIHRoZSBsaXN0IGFuZCBwZXJo YXBzIGRvIGEgcG9sbCBvZiBvcHRpb25zIHByZXNlbnRlZCB1bmxlc3MgY29uc2Vuc3VzIGlzIG9i dmlvdXMgZnJvbSB0aGlzIHRocmVhZC4NCg0KL0RpY2sNCg0KDQoNCg0KDQpbaHR0cHM6Ly9tYWls Zm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjA9 JnR5cGU9emVyb2NvbnRlbnQmZ3VpZD1iMjFhMmE2ZC1kN2UzLTQ1ZmEtYjdhOC04NDc2OGExYmQy ZWFd4ZCnDQoNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRv OlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHhhdXRoDQoNCg== --_000_CH2PR00MB0678313B29175587B7CD3E1AF5F60CH2PR00MB0678namp_ 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 MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JZiB0aGlzIHdvcmsgd2Vy ZSBoYXBwZW5pbmcgaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIGNhbGxpbmcgaXQgT0F1dGgg MyB3b3VsZCBiZSBhIGRlY2lzaW9uIHRoYXQgY291bGQgYmUgdGFrZW4gYnkgdGhlIHdvcmtpbmcg Z3JvdXAuJm5ic3A7IEJ1dCB1bmxlc3MgaXQgbW92ZXMgdG8gdGhlIE9BdXRoIHdvcmtpbmcgZ3Jv dXAsIEkgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkDQogYmUgdW5yZWFzb25hYmxlIHRvIHVzdXJwIGJy YW5kaW5nIGJlbG9uZ2luZyB0byBhIGRpZmZlcmVudCB3b3JraW5nIGdyb3VwLiZuYnNwOyBUeEF1 dGggc2hvdWxkIGhhdmUgaXRzIG93biBkaXN0aW5jdCBicmFuZCBjaG9zZW4gYnkgaXRzIHRvLWJl LWZvcm1lZCB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUeGF1dGgg Jmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5KdXN0 aW4gUmljaGVyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDE3LCAyMDIwIDY6MTEg QU08YnI+DQo8Yj5Ubzo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gWWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21haWwuY29t Jmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVHhhdXRoXSBX RyBuYW1lOiBUeEF1dGg/IFhBdXRoPyBTb21ldGhpbmcgZWxzZT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBhbm90aGVyIHRob3VnaHQg4oCUIHRoZXJl4oCZcyBh IHByZXR0eSBkZWNlbnQgY2hhbmNlIHRoYXQgd2XigJlsbCBlbmQgdXAgYnJhbmRpbmcgdGhpcyB3 aG9sZSBlZmZvcnQgT0F1dGggMyBpbiB0aGUgZnV0dXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxpc3QgaXMgbmFtZWQg4oCYdHhhdXRo 4oCZLiBUaGVyZWZvcmUsIGNhbGxpbmcgd2hhdCB3ZeKAmXJlIHdvcmtpbmcgb24gYW55dGhpbmcg ZGlmZmVyZW50IGZyb20gdGhhdCBzZWVtcyBzaWxseSBhbmQgcHJlbWF0dXJlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNheSB3ZSBqdXN0 IHN0aWNrIHdpdGggVHhBdXRoIHRvIG1hdGNoIHRoZSBsaXN0IGFuZCBhdm9pZCB0aGUgd2hvbGUg bmFtaW5nIGRpc2N1c3Npb24gZW50aXJlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAxNiwgMjAyMCwgYXQgOTo1NiBQ TSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJp Y2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ZZXMsIG5hbWluZyB0aGluZ3MgaXMgaGFyZCDigJQgYnV0IEkgc3Rp bGwgYmVsaWV2ZSBpbiB0aGUgbmFtZSBUeEF1dGguIFdl4oCZcmUgbW92aW5nIGJleW9uZCBPQXV0 aCwgYW5kIHRha2luZyB0aGUgcHJvY2VzcyBvZiBnZXR0aW5nIGFuIGF1dGhvcml6YXRpb24gZGVs ZWdhdGVkIHRvIHRoZSBjbGllbnQgc29mdHdhcmUgYXMgYSBtdWx0aS1zdGVwLCBtdWx0aS1wYXJ0 eSB0cmFuc2FjdGlvbiBpcywgSSBiZWxpZXZlLA0KIHRoZSBrZXkgaW5zaWdodCB0aGF04oCZcyBs ZXR0aW5nIHVzIG1vdmUgYmV5b25kIE9BdXRo4oCZcyBsaW1pdGF0aW9ucyBoZXJlLiBJdOKAmXMg bm90IGp1c3QgYWJvdXQgZ29pbmcgdG8gdGhlIEFTIGZpcnN0IOKAlCB3ZSBoYWQgdGhhdCBpbiBP QXV0aCAxIGFuZCB3ZeKAmXJlIHBhdGNoaW5nIHRoYXQgaW50byBPQXV0aCAyIHdpdGggUEFSLiBJ IHJlYWxseSB0aGluayBpdOKAmXMgYWJvdXQgdGhlIHRyYW5zYWN0aW9uIGF0IHRoZSBjb3JlLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5n IGNvbWUgb2YgYWdlIGluIHRoZSAxOTkw4oCZcywgSSBoYXZlIHBhcnRpY3VsYXIgZGlzbGlrZSBm b3IgWEF1dGguIEl0IHNvdW5kcyB0b28g4oCcWC1UUkVNReKAnSBhbmQg4oCcWC1DSVRJTkfigJ0s IGFuZCBpZiB5b3UgcmVhZCBlaXRoZXIgb2YgdGhvc2Ugd2l0aCBhIGdyb3dsaW5nIHllbGwgaW4g eW91ciBoZWFkIHRoZW4geW91IGtub3cgZXhhY3RseSB3aGF0IEnigJltIHRhbGtpbmcgYWJvdXQu IEFuZCB0byBEaWNr4oCZcw0KIHJhdGlvbmFsZSBmb3IgdGhlIG5hbWUgYmVsb3csIEkgYWJzb2x1 dGVseSBkbyBOT1Qgc2VlIHRoaXMgd29yayBhcyDigJxPQXV0aCB3aXRoIGFsbCB0aGUgZXh0cmEg ZmVhdHVyZXPigJ0uIEkgdGhpbmsgdGhhdCBkb2VzIGEgZGlzc2VydmljZSB0byB0aGUga2luZCBv ZiBjaGFuZ2Ugd2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0byBtYWtlIGhlcmUuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KA lCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IE1hciAxNiwgMjAyMCwgYXQgNzowNCBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gZXZl cnlvbmU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcHJv bXB0ZWQgYSB0aHJlYWQgYXJvdW5kIHRoZSBuYW1lIG9mIHRoZSBwcm90b2NvbCBhIHdoaWxlIGJh Y2s6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoL1pW UVZiSHQ0QURxZWhLckJEWE9yVHJfc193Yy8iPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvdHhhdXRoL1pWUVZiSHQ0QURxZWhLckJEWE9yVHJfc193Yy88L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIEp1c3RpbiBz dGF0ZWQgJnF1b3Q7bmFtaW5nIGlzIGhhcmQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VhcmluZyBteSBtYXJrZXRpbmcgaGF0IEkg d2FudCB0byBlbnN1cmUgdGhhdCB0aGUgbmFtZSB3aWxsIGJlIHBlcmNlaXZlZCZuYnNwO3Byb3Bl cmx5IGluIHRoZSBicm9hZGVyIGNvbW11bml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSByZWNlbnQgZXhhbXBsZSB0aGF0IGNvbWVzIHRv IG1pbmQgYXJlIHRoZSBwcml2YWN5IHJlbGF0ZWQgd29ya3Mgb24gdGhlIGJyb3dzZXIgc3RvcmFn ZSBBUEkuIEdpdmVuIHRoYXQgbmFtZSwgb25lIHdvdWxkIHRoaW5rIHRoYXQgaXQgaXMgbG9jYWwg c3RvcmFnZS4gSXQgaXMgYWN0dWFsbHkgYWJvdXQgYnJvd3NlciBjb29raWVzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0aW4gZGlzY3Vz c2VkIGhpcyByZWFzb25zIGZvciBUeEF1dGggaW4gdGhlIHRocmVhZCBhYm92ZSAoYW5kIEknbSBz dXJlIGluIG90aGVyIHBsYWNlcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBjaG9zZSBYQXV0aCBpbiBteSBkcmFmdCB0byByZWZsZWN0IHRo ZSBlWHRlbnNpYmlsaXR5IGdvYWwgdGhhdCB3ZSBoYXZlIG92ZXIgT0F1dGggLS0gYW5kIFhBdXRo IGlzIE9BdXRoIGJ1dCB3aXRoIGFuIFggdG8gcmVmbGVjdCBhbGwgdGhlIGV4dHJhIGZlYXR1cmVz LiA9KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PdGhlciBzdWdnZXN0aW9ucz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3aWxsIGJlIGFuIGFnZW5kYSBpdGVtIGluIHRoZSBCb0Yg LS0gYnV0IHRoZSBuYW1lIHdpbGwgTk9UIGJlIGFuIG9wZW4gZGlzY3Vzc2lvbiBpdGVtIC0tIHdl IHdpbGwgc3VtbWFyaXplJm5ic3A7d2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhlIGxpc3Qg YW5kIHBlcmhhcHMgZG8gYSBwb2xsIG9mIG9wdGlvbnMgcHJlc2VudGVkIHVubGVzcyBjb25zZW5z dXMgaXMgb2J2aW91cyBmcm9tIHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3Jk ZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3Qu Y29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjA9JmFtcDt0eXBlPXplcm9j b250ZW50JmFtcDtndWlkPWIyMWEyYTZkLWQ3ZTMtNDVmYS1iN2E4LTg0NzY4YTFiZDJlYSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS0gPGJyPg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhA aWV0Zi5vcmciPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CH2PR00MB0678313B29175587B7CD3E1AF5F60CH2PR00MB0678namp_-- From nobody Tue Mar 17 10:12:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E83A08CB for ; Tue, 17 Mar 2020 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 BsZp8GTfQpO6 for ; Tue, 17 Mar 2020 10:12:03 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650122.outbound.protection.outlook.com [40.107.65.122]) (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 7BCD73A0824 for ; Tue, 17 Mar 2020 10:12:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qf0jY3ZolmOYdXgY/GlhGcVM1xTnZIC5qqOK9l7ecvTr4WvYFwkr/ls0wts0UyKODFD9NQD0FpqGqbj6VGJOXZUytEZ8VwU9epN9xSdFaBbz3+qDqoWX7CM5riu2vZ64B0A8eO8COu+lErnPyZ5Z2X24rEk6MpqHqieS2HrAu6MgvOrhlcMRgUx/9jlPFaNBygS3U2fBT7xqmSttYKS0RT7+ckET7jcYqD4oJmBJRYVxU9ijLzNXDID3kmOfKpPW3jhy5IXlBL641rW75+SaC+UnYORUtOLo6SJdkg02NebC6R00RWXmbOGc2tsAXeKerTWN3kUM25Dn8OiNE/1IEw== 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=oOVJMSavrjj7F4Qp8NpQ82ASgiz9M+5j5/EHJBDImuc=; b=KyCcBLaGUhLpzzGhMAJPVcTx8dbIdFjv0eJebr0f5zATrxhxJWWZYY0atLCNp3AtbEJdW8ab6CbsWIsVLwPSmXnROnv6TIEUxFnuGnO8jximO6RTids0nUSloUBgqN63mHh7I5Xlajg8R54oUaymQHGPiLDkdSCAwVbF8uiNyfPy2kxJy9kYIv2wDd+1L7OzzgC3wqh9uaNnsII2K0K6tLxGCiW9aJgEuegVJ3KhoGFN/HyBWb58dHF+MRL8qig24+44hOwZ2q3/HO/TNpI2gf2uAowlpryFbg2ikXXBOX674tgoPpkm6Ym4bEVviNV5j3rp6Y9Wcw1bx9OezE3mwg== 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=oOVJMSavrjj7F4Qp8NpQ82ASgiz9M+5j5/EHJBDImuc=; b=XYQ1kCKUNTxW1H4RiJbaUb3FxiJKRNP4RY01/3NX/ZnlGyhWKB7Ct8CQJZHfXm9xpUyQX7sXAyR6X1a5ggx+HW/DpholPx15Qmau7pG9OGGLQrT+b3MSqOqr3UL1Kt1a34/PqBPrC2q7sjFMC6VXXfeC2HnwbnkjPoicXDebtJM= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0762.namprd00.prod.outlook.com (2603:10b6:610:61::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2873.0; Tue, 17 Mar 2020 17:12:01 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::a56a:2989:f37f:7a7a]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::a56a:2989:f37f:7a7a%3]) with mapi id 15.20.2872.000; Tue, 17 Mar 2020 17:12:01 +0000 From: Mike Jones To: Yaron Sheffer , Torsten Lodderstedt CC: "txauth@ietf.org" Thread-Topic: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AQHV89abQy9HJ60g4UeTXV6BVVcAf6g9P3CAgA/VDtA= Date: Tue, 17 Mar 2020 17:12:01 +0000 Message-ID: References: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net> In-Reply-To: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net> 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_ActionId=8071f721-98ce-4dc0-8fbe-0000aa53de5a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-17T17:04:14Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.81.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 787d3b31-05de-4d9c-9408-08d7ca964ee7 x-ms-traffictypediagnostic: CH2PR00MB0762: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(396003)(346002)(376002)(39860400002)(136003)(199004)(110136005)(2906002)(316002)(53546011)(6506007)(966005)(81156014)(8936002)(81166006)(7696005)(55016002)(66446008)(76116006)(64756008)(66476007)(66946007)(66556008)(33656002)(9686003)(478600001)(5660300002)(66574012)(4326008)(186003)(71200400001)(26005)(52536014)(8676002)(10290500003)(86362001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0762; H:CH2PR00MB0678.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aTky1PXS1jYe+TjCT8gUQme+H5XkIi0Eh9PSXb1HFNL5H9eiNBV4MlIL8+ThUpz2Hff0VpOw+Or0gzNrp4iSiGOl7WQMP1eUUYD+uUcbktgQ4tsnuhVp7hTQmAeybbVvaz5SlJnU1R6W+oVOc2wK7wwUCdZQyHE3w6HQDQw3CyreMGdETyPFu3RE00H5++kQ7KxrQau+JPeYYCs37avJKg0jNODqoYGzHG/KYE2gJA1uEALrkSKhuQK7fNy4nUY5+nSPMvc8CJU85zAkstIRI8wQY7aIlOQbsQ/kI6ulDx08G15Zsn33xjPnijOdFBc2iuDSpGaKAUyQMWhqREPa92MHZ7sk2UQamfk9bCiAjK0Ng0i/ewqHA7vMv3E70JUfOpCeCzBkMQZRhm41E0cynY3XSZySDfZK6joI5ec1e3r+YErLGjg9RVVmupJd/LIZJ1mrTsi8WNIKmZyvQxmUDwIbF53c2A4wVwAc0dSy28xXlJGFD8rIz2xpgqr6FBkdOsj4g45q/OuB6Yrjj5mnfg== x-ms-exchange-antispam-messagedata: SE8kOsKPjnn2QROsgxUpupjmwsfXOjbo9loMiwQTXMV+kPlBhZyWiZJWMNPzcDTts225dV+uk/E7UMv//3svQILhI7IBJqABUMswTQsHdhiWi1iyPzadbF2tNKKS/QnuQVwL+j3N6uirM/XuIVDGAQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 787d3b31-05de-4d9c-9408-08d7ca964ee7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 17:12:01.2843 (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: +T231FJ+95ne+v7fnRh3tzehImMCJdRCAAvrMkq+qHt3HFXQAD6y1nS8s24J/0lRSqSQVdiRH+BtZ6cmOryUow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0762 Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 17:12:07 -0000 MS4gIERvIHlvdSBzdXBwb3J0IHRoZSBjaGFydGVyIHRleHQgcHJvdmlkZWQgYXQgdGhlIGVuZCBv ZiB0aGlzIGVtYWlsPyAgT3IgZG8geW91IGhhdmUgbWFqb3Igb2JqZWN0aW9ucywgYmxvY2tpbmcg Y29uY2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBsZWFzZSBlbGFib3JhdGUpPw0KDQpJIHNoYXJl IHRoZSBjb25jZXJucyBhYm91dCBpbmNsdWRpbmcgaWRlbnRpdHkgaW4gdGhlIGNoYXJ0ZXIgdGhh dCB3ZXJlIGV4cHJlc3NlZCBieSBUb3JzdGVuIGFuZCBhZ3JlZWQgd2l0aCBieSBEYXZpZCBTa2Fp ZmUuICBJJ2xsIG5vdGUgdGhhdCBLaW0gQ2FtZXJvbiBwcmV2aW91c2x5IGV4cHJlc3NlZCBjb25j ZXJucyBhYm91dCBpbmNsdWRpbmcgaWRlbnRpdHkgaW4gaGlzIGVhcmxpZXIgY2hhcnRlciBjcml0 aXF1ZSBhdCBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC91TDky T19WazVtMzhEY2FjWFNuc2hYMkNhaEUvLg0KDQpJJ20gZmluZSB3aXRoIHJlZmFjdG9yaW5nIHRo ZSBhdXRob3JpemF0aW9uIHByb3RvY29sLiAgQnV0IGlkZW50aXR5IHNob3VsZCBiZSBkZWNvdXBs ZWQgZnJvbSB0aGUgVHhBdXRoIHdvcmsgdG8gZm9jdXMgaXRzIHNjb3BlIG9uIGFyZWFzIHdoZXJl IGlubm92YXRpb24gaXMgYmVpbmcgcHJvcG9zZWQuICBEaWdpdGFsIGlkZW50aXR5IGNhbiBhbHdh eXMgYmUgYWRkZWQgYXMgYSBsYXllciBpZiBuZWVkZWQsIGp1c3QgYXMgT3BlbklEIENvbm5lY3Qg bGF5ZXJlZCBpZGVudGl0eSBvbnRvIE9BdXRoIDIuMC4NCg0KUGxlYXNlIHJldmlzZSB0aGUgY2hh cnRlciB0byByZW1vdmUgZGlnaXRhbCBpZGVudGl0eSBmcm9tIHRoZSBzY29wZSBvZiB0aGUgd29y ay4NCiANCjIuICBBcmUgeW91IHdpbGxpbmcgdG8gYXV0aG9yIG9yIHBhcnRpY2lwYXRlIGluIHRo ZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQogDQpZZXMNCg0KMy4gIEFy ZSB5b3Ugd2lsbGluZyB0byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQogDQpZ ZXMNCg0KNC4gIEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRo aXMgV0c/DQoNCk5vdCBhdCB0aGlzIHRpbWUuDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgVG9yc3RlbiBMb2RkZXJzdGVkdA0KU2VudDogU2F0dXJkYXksIE1hcmNoIDcs IDIwMjAgNzoxOCBBTQ0KVG86IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4N CkNjOiB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIENh bGwgZm9yIGNoYXJ0ZXIgY29uc2Vuc3VzIC0gVHhBdXRoIFdHDQoNCkhpLA0KDQo+IEFtIDA2LjAz LjIwMjAgdW0gMTc6NDUgc2NocmllYiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5j b20+Og0KPiANCj4g77u/SGkgRXZlcnlvbmUsDQo+ICANCj4gSXQgYXBwZWFycyB0aGF0IG1vbWVu dHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRpb24gb2YgYSBUeEF1dGgg d29ya2luZyBncm91cC4gIFdl4oCZZCBsaWtlIHRvIG1vcmUgZm9ybWFsbHkgZ2F1Z2UgaW50ZXJl c3QgaW4gcHJvY2VlZGluZyB3aXRoIHRoaXMgd29yay4gIFBsZWFzZSBkbyBzbyBieSByZXNwb25k aW5nIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KPiAgDQo+IDEuICBEbyB5b3Ugc3VwcG9y dCB0aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8gIE9y IGRvIHlvdSBoYXZlIG1ham9yIG9iamVjdGlvbnMsIGJsb2NraW5nIGNvbmNlcm5zIG9yIGZlZWRi YWNrIChpZiBzbyBwbGVhc2UgZWxhYm9yYXRlKT8NCg0KSeKAmG0gaW4gYWx0aG91Z2ggSSBoYXZl IHRvIGFkbWl0IEnigJhtIHNsaWdodGx5IGNvbmNlcm5lZCB0aGUgc2NvcGUgb2YgdGhlIGNoYXJ0 ZXIgaXMgdG9vIGJyb2FkLCBlLmcuIGlkZW50aWZ5IGFsb25lIGlzIGEgaHVnZSB0b3BpYy4NCg0K V2UgbmVlZCB0byBrZWVwIGFuIGV5ZSBvbiB0aGlzIGFzcGVjdCBpbiBvcmRlciB0byBtYWtlIHN1 cmUsIHRoZSBncm91cCBpcyBhYmxlIHRvIHdvcmsgZWZmZWN0aXZlbHkgYW5kIHRoZSBzcGVjcyB3 ZSB3aWxsIGJlIHByb2R1Y2luZyBhcmUgYXMgc2ltcGxlIGFzIHBvc3NpYmxlIGFuZCBmb3N0ZXIg aW50ZXJvcGVyYWJpbGl0eS4NCg0KPiAgDQo+IDIuICBBcmUgeW91IHdpbGxpbmcgdG8gYXV0aG9y IG9yIHBhcnRpY2lwYXRlIGluIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJhZnRzIG9mIHRoaXMg V0c/DQoNCnllcw0KDQo+ICANCj4gMy4gIEFyZSB5b3Ugd2lsbGluZyB0byBoZWxwIHJldmlldyB0 aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQoNCnllcw0KDQo+ICANCj4gNC4gIEFyZSB5b3UgaW50ZXJl c3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRoaXMgV0c/DQoNCnllcw0KDQpiZXN0IHJl Z2FyZHMsDQpUb3JzdGVuLg0KDQo+ICANCj4gVGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3byB3ZWVr cywgdW50aWwgTWFyY2ggMjEuIElmIHlvdSB0aGluayB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBi ZSBhbWVuZGVkIEluIGEgc2lnbmlmaWNhbnQgd2F5LCBwbGVhc2UgcmVwbHkgb24gYSBzZXBhcmF0 ZSB0aHJlYWQuDQo+ICANCj4gVGhlIGZlZWRiYWNrIHByb3ZpZGVkIGhlcmUgd2lsbCBoZWxwIHRo ZSBJRVNHIGNvbWUgdG8gYSBkZWNpc2lvbiBvbiB0aGUgZm9ybWF0aW9uIG9mIGEgbmV3IFdHLiBH aXZlbiB0aGUgY29uc3RyYWludHMgb2YgdGhlIGNoYXJ0ZXJpbmcgcHJvY2VzcywgcmVnYXJkbGVz cyBvZiB0aGUgb3V0Y29tZSBvZiB0aGlzIGNvbnNlbnN1cyBjYWxsLCB3ZSB3aWxsIGJlIG1lZXRp bmcgaW4gVmFuY291dmVyIGFzIGEgQm9GLg0KPiAgDQo+IFRoYW5rcywNCj4gWWFyb24gYW5kIERp Y2sNCj4gIA0KPiAtLS0gQ2hhcnRlciBUZXh0IEZvbGxvd3MgLS0tDQo+IA0KPiBUaGlzIGdyb3Vw IGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9j b2wgZm9yIGF1dGhvcml6YXRpb24sIGlkZW50aXR5LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90 b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0 byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2ls bCBleHBhbmQgdXBvbiB0aGUgdXNlcyBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRo IDIuMCBhbmQgT3BlbklEIENvbm5lY3QgKGl0c2VsZiBhbiBleHRlbnNpb24gb2YgT0F1dGggMi4w KSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25zIHNjb3BlZCBhcyBuYXJyb3dseSBhcyBhIHNpbmds ZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBhIGNsZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb24g YW1vbmcgYWxsIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1v dmUgdW5uZWNlc3NhcnkgZGVwZW5kZW5jZSBvbiBhIGJyb3dzZXIgb3IgdXNlci1hZ2VudCBmb3Ig Y29vcmRpbmF0aW5nIGludGVyYWN0aW9ucy4gDQo+IA0KPiBUaGUgZGVsZWdhdGlvbiBwcm9jZXNz IHdpbGwgYmUgYWN0ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwg ZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3Vw bGUgdGhlIGludGVyYWN0aW9uIGNoYW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJv d3NlciwgZnJvbSB0aGUgZGVsZWdhdGlvbiBjaGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5 IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250 cmFzdCB3aXRoIE9BdXRoIDIuMCB3aGljaCBpcyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRp cmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3NlcikuIFRoZSBjbGllbnQgYW5kIEFTIHdpbGwgaW52 b2x2ZSBhIHVzZXIgdG8gbWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGFzIG5lY2Vzc2Fy eSB0aHJvdWdoIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2Nv bC4gVGhpcyBkZWNvdXBsaW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBh bmQgdGVjaG5pY2FsIGNoYWxsZW5nZXMgb2YgT0F1dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1p bnZhc2l2ZSBwYXRoIGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBp bnRlcmFjdGlvbiBjaGFubmVscy4NCj4gDQo+IEFkZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24g cHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCj4gDQo+IC0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRp b24gb2YgYWNjZXNzDQo+IC0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRlbnRpdHkg Y2xhaW1zDQo+IC0gQXBwcm92YWwgb2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBhbmQg QVBJcyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbg0KPiAtIFNlcGFyYXRpb24gYmV0d2VlbiB0aGUg cGFydHkgYXV0aG9yaXppbmcgYWNjZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZSBjbGll bnQgcmVxdWVzdGluZyBhY2Nlc3MNCj4gLSBBIHZhcmlldHkgb2YgY2xpZW50IGFwcGxpY2F0aW9u cywgaW5jbHVkaW5nIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIGludGVyYWN0aW9uLWNv bnN0cmFpbmVkIGFwcGxpY2F0aW9ucw0KPiANCj4gVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVu c2lvbiBwb2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGlu IGFyZWFzIGluY2x1ZGluZzoNCj4gDQo+IC0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlz LCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9uIA0KPiAtIFVzZXIg aW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHMN Cj4gLSBNZWNoYW5pc21zIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlv biwgYW5kIG90aGVyIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24g ZGVjaXNpb25zDQo+IC0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3Vy Y2Ugc2VydmVycyBhbmQgYmluZGluZyByZXNvdXJjZSByZXF1ZXN0cyB0byB0b2tlbnMgYW5kIGFz c29jaWF0ZWQgY3J5cHRvZ3JhcGhpYyBrZXlzDQo+IC0gT3B0aW1pemVkIGluY2x1c2lvbiBvZiBh ZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRocm91Z2ggdGhlIGRlbGVnYXRpb24gcHJvY2VzcyAoaW5j bHVkaW5nIGlkZW50aXR5KQ0KPiANCj4gQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92 aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBp bmNsdWRpbmc6DQo+IA0KPiAtIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIN Cj4gLSBSZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbnMNCj4gLSBRdWVyeSBvZiB0b2tlbiByaWdo dHMgYnkgcmVzb3VyY2Ugc2VydmVycw0KPiANCj4gQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3Ig dGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNv bXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxs IGF0dGVtcHQgdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQg Q29ubmVjdCB0byB0aGUgbmV3IHByb3RvY29sIHdoZXJlIHBvc3NpYmxlLg0KPiANCj4gVGhpcyBn cm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAs IGFuZCBhcyBzdWNoIHdpbGwgZm9jdXMgb24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5v dCBuZWNlc3NhcmlseSBjb21wYXRpYmxlIHdpdGggT0F1dGggMi4wLiBGdW5jdGlvbmFsaXR5IHRo YXQgYnVpbGRzIGRpcmVjdGx5IG9uIE9BdXRoIDIuMCB3aWxsIGJlIGRldmVsb3BlZCBpbiB0aGUg T0F1dGggV29ya2luZyBHcm91cCwgaW5jbHVkaW5nIGZ1bmN0aW9uYWxpdHkgYmFjay1wb3J0ZWQg ZnJvbSB0aGUgcHJvdG9jb2wgZGV2ZWxvcGVkIGhlcmUgdG8gT0F1dGggMi4wLg0KPiANCj4gVGhl IGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGFwcGx5aW5nIGNy eXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBhcyBKT1NFIGFuZCBDT1NFLCB0byB0aGUgZGVsZWdh dGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcg Y3J5cHRvZ3JhcGhpYyBtZXRob2RzLiANCj4gDQo+IFRoZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1 cyBvbiB1c2luZyBIVFRQIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlv biBmZWF0dXJlcyBvZiBIVFRQMiBhbmQgSFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxsIHN0 cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXMg Q09BUCB3aGVuIGRvaW5nIHNvIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggdGhlIHByaW1hcnkgZm9j dXMuDQo+IA0KPiBNaWxlc3RvbmVzIHRvIGluY2x1ZGU6DQo+IC0gQ29yZSBkZWxlZ2F0aW9uIHBy b3RvY29sDQo+IC0gS2V5IHByZXNlbnRhdGlvbiBtZWNoYW5pc20gYmluZGluZ3MgdG8gdGhlIGNv cmUgcHJvdG9jb2wgZm9yIFRMUywgZGV0YWNoZWQgSFRUUCBzaWduYXR1cmUsIGFuZCBlbWJlZGRl ZCBIVFRQIHNpZ25hdHVyZXMNCj4gLSBJZGVudGl0eSBhbmQgYXV0aGVudGljYXRpb24gY29udmV5 YW5jZSBtZWNoYW5pc21zDQo+IC0gR3VpZGVsaW5lcyBmb3IgdXNlIG9mIHByb3RvY29sIGV4dGVu c2lvbiBwb2ludHMNCj4gDQo+IA0KPiAtLSANCj4gVHhhdXRoIG1haWxpbmcgbGlzdA0KPiBUeGF1 dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGgNCg== From nobody Tue Mar 17 14:13:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC043A0762 for ; Tue, 17 Mar 2020 14:13:28 -0700 (PDT) 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, 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 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 Tv0VQYKUDWPB for ; Tue, 17 Mar 2020 14:13:26 -0700 (PDT) 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 772283A0747 for ; Tue, 17 Mar 2020 14:13:26 -0700 (PDT) Received: from [192.168.1.5] (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 02HLDOmY028938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 17:13:24 -0400 From: Justin Richer Message-Id: <1E9C78E5-6D06-4973-B69B-3E7DF46E5B9E@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F9BA250-1137-4F64-8901-778A4B522495" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Mar 2020 17:13:23 -0400 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , "txauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 21:13:29 -0000 --Apple-Mail=_5F9BA250-1137-4F64-8901-778A4B522495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, Yes, I agree, and we decided some time back on this list to not push = calling it OAuth 3. That is not what I=E2=80=99m saying to do and not = what we are discussing. I still think that this is a potential outcome = through coordination with the OAuth working group some day in the = future, but that=E2=80=99s not for us to decide now and it=E2=80=99s not = for us to decide alone.=20 This is exactly why I=E2=80=99m arguing that we should use the branding = of =E2=80=9CTxAuth=E2=80=9D for this work right now.=20 The AD=E2=80=99s and I went back and forth with a bunch of different = names for this list, and I still think we came up with a decent one = here, and we should stick with that. I had originally proposed that we = call the list itself =E2=80=9Cxyz=E2=80=9D, but realized after some = discussion that it would have been pretentious and presumptuous to try = to name a potentially future working group after my own existing = solution.=20 So again I say we just call it TxAuth and not get distracted by the = naming discussion. If you search for =E2=80=9Ctxauth=E2=80=9D on the = web, nearly everything you find points back to this group and this work. = We=E2=80=99ve already got a solid brand under this term, it fits pretty = well, and we should run with it for now. =E2=80=94 Justin > On Mar 17, 2020, at 12:24 PM, Mike Jones = wrote: >=20 > If this work were happening in the OAuth working group, calling it = OAuth 3 would be a decision that could be taken by the working group. = But unless it moves to the OAuth working group, I believe that it would = be unreasonable to usurp branding belonging to a different working = group. TxAuth should have its own distinct brand chosen by its = to-be-formed working group. > =20 > -- Mike > =20 > From: Txauth > On Behalf Of Justin Richer > Sent: Tuesday, March 17, 2020 6:11 AM > To: Dick Hardt > > Cc: Yaron Sheffer >; txauth@ietf.org = > Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? > =20 > And another thought =E2=80=94 there=E2=80=99s a pretty decent chance = that we=E2=80=99ll end up branding this whole effort OAuth 3 in the = future.=20 > =20 > The list is named =E2=80=98txauth=E2=80=99. Therefore, calling what = we=E2=80=99re working on anything different from that seems silly and = premature. > =20 > I say we just stick with TxAuth to match the list and avoid the whole = naming discussion entirely. > =20 > =E2=80=94 Justin >=20 >=20 > On Mar 16, 2020, at 9:56 PM, Justin Richer > wrote: > =20 > Yes, naming things is hard =E2=80=94 but I still believe in the name = TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of = getting an authorization delegated to the client software as a = multi-step, multi-party transaction is, I believe, the key insight = that=E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. = It=E2=80=99s not just about going to the AS first =E2=80=94 we had that = in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I = really think it=E2=80=99s about the transaction at the core.=20 > =20 > Having come of age in the 1990=E2=80=99s, I have particular dislike = for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2= =80=9D, and if you read either of those with a growling yell in your = head then you know exactly what I=E2=80=99m talking about. And to = Dick=E2=80=99s rationale for the name below, I absolutely do NOT see = this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I = think that does a disservice to the kind of change we have an = opportunity to make here.=20 > =20 > =E2=80=94 Justin >=20 >=20 > On Mar 16, 2020, at 7:04 PM, Dick Hardt > wrote: > =20 > Hello everyone > =20 > I prompted a thread around the name of the protocol a while back: > =20 > = https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ = > =20 > As Justin stated "naming is hard" > =20 > Wearing my marketing hat I want to ensure that the name will be = perceived properly in the broader community. > =20 > A recent example that comes to mind are the privacy related works on = the browser storage API. Given that name, one would think that it is = local storage. It is actually about browser cookies. > =20 > Justin discussed his reasons for TxAuth in the thread above (and I'm = sure in other places) > =20 > I chose XAuth in my draft to reflect the eXtensibility goal that we = have over OAuth -- and XAuth is OAuth but with an X to reflect all the = extra features. =3D) > =20 > Other suggestions? > =20 > This will be an agenda item in the BoF -- but the name will NOT be an = open discussion item -- we will summarize what has been discussed on the = list and perhaps do a poll of options presented unless consensus is = obvious from this thread. > =20 > /Dick > =20 > =20 > =20 > =20 > =20 > =E1=90=A7 > =20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_5F9BA250-1137-4F64-8901-778A4B522495 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike,

Yes, = I agree, and we decided some time back on this list to not push calling = it OAuth 3. That is not what I=E2=80=99m saying to do and not what we = are discussing. I still think that this is a potential outcome through = coordination with the OAuth working group some day in the future, but = that=E2=80=99s not for us to decide now and it=E2=80=99s not for us to = decide alone. 

This is exactly why I=E2=80=99m arguing that we should use = the branding of =E2=80=9CTxAuth=E2=80=9D for this work right = now. 

The = AD=E2=80=99s and I went back and forth with a bunch of different names = for this list, and I still think we came up with a decent one here, and = we should stick with that. I had originally proposed that we call the = list itself =E2=80=9Cxyz=E2=80=9D, but realized after some discussion = that it would have been pretentious and presumptuous to try to name a = potentially future working group after my own existing = solution. 

So again I say we just call it TxAuth and not get distracted = by the naming discussion. If you search for =E2=80=9Ctxauth=E2=80=9D on = the web, nearly everything you find points back to this group and this = work. We=E2=80=99ve already got a solid brand under this term, it fits = pretty well, and we should run with it for now.

 =E2=80=94 Justin

On Mar 17, 2020, at 12:24 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

If this work were happening = in the OAuth working group, calling it OAuth 3 would be a decision that = could be taken by the working group.  But unless it moves to the = OAuth working group, I believe that it would be unreasonable to usurp = branding belonging to a different working group.  TxAuth should = have its own distinct brand chosen by its to-be-formed working = group.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Justin = Richer
Sent: Tuesday, March 17, 2020 = 6:11 AM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] WG name: = TxAuth? XAuth? Something else?
 
And another thought =E2=80=94 there=E2=80= =99s a pretty decent chance that we=E2=80=99ll end up branding this = whole effort OAuth 3 in the future. 
 
The list is named =E2=80=98txauth=E2=80=99. Therefore, = calling what we=E2=80=99re working on anything different from that seems = silly and premature.
 
I say we just stick with TxAuth to match the list and avoid = the whole naming discussion entirely.
 
 =E2=80=94 Justin


On Mar 16, 2020, at 9:56 PM, Justin Richer <jricher@mit.edu> wrote:
 
Yes, naming things is hard =E2=80=94 = but I still believe in the name TxAuth. We=E2=80=99re moving beyond = OAuth, and taking the process of getting an authorization delegated to = the client software as a multi-step, multi-party transaction is, I = believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2=80= =99s limitations here. It=E2=80=99s not just about going to the AS first = =E2=80=94 we had that in OAuth 1 and we=E2=80=99re patching that into = OAuth 2 with PAR. I really think it=E2=80=99s about the transaction at = the core. 
 
Having come of age in the 1990=E2=80=99s, I have particular = dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and = =E2=80=9CX-CITING=E2=80=9D, and if you read either of those with a = growling yell in your head then you know exactly what I=E2=80=99m = talking about. And to Dick=E2=80=99s rationale for the name below, I = absolutely do NOT see this work as =E2=80=9COAuth with all the extra = features=E2=80=9D. I think that does a disservice to the kind of change = we have an opportunity to make here. 
 
 =E2=80=94 Justin


On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:
 
Hello everyone
 
I prompted a thread around the name of = the protocol a while back:
 
 
As Justin stated "naming is hard"
 
Wearing my marketing hat I want to = ensure that the name will be perceived properly in the broader = community.
 
A recent example that comes to mind are the privacy related = works on the browser storage API. Given that name, one would think that = it is local storage. It is actually about browser cookies.
 
Justin discussed his reasons for TxAuth = in the thread above (and I'm sure in other places)
 
I chose XAuth in my draft to reflect = the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but = with an X to reflect all the extra features. =3D)
 
Other suggestions?
 
This will be an agenda item in the BoF = -- but the name will NOT be an open discussion item -- we will = summarize what has been discussed on the list and perhaps do a poll = of options presented unless consensus is obvious from this thread.
 
/Dick
 
 
 
 
 
=E1=90=A7
 

= --Apple-Mail=_5F9BA250-1137-4F64-8901-778A4B522495-- From nobody Tue Mar 17 14:20:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1970C3A0797 for ; Tue, 17 Mar 2020 14:20:30 -0700 (PDT) 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=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 Z7k3wptN5Y09 for ; Tue, 17 Mar 2020 14:20:28 -0700 (PDT) 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 3C5C03A0791 for ; Tue, 17 Mar 2020 14:20:28 -0700 (PDT) Received: from [192.168.1.5] (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 02HLKLnh031549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 17:20:21 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 17 Mar 2020 17:20:21 -0400 Cc: Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <36C53882-A83E-4790-A08B-7C9147AF5B64@mit.edu> References: <970D54F0-E407-4578-A93E-F0EE589667F9@lodderstedt.net> To: Mike Jones X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 21:20:31 -0000 While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things. As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.=20 The market has shown us that the most common application of OAuth 2 is = far and away access to identity information along side access to an API. = I think we need to pay attention to that and not make this separate just = because we did it that way before. And some of the proposed innovations, = including getting and sending VC=E2=80=99s, are all about identity. Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. =E2=80=94 Justin > On Mar 17, 2020, at 1:12 PM, Mike Jones = wrote: >=20 > 1. Do you support the charter text provided at the end of this email? = Or do you have major objections, blocking concerns or feedback (if so = please elaborate)? >=20 > I share the concerns about including identity in the charter that were = expressed by Torsten and agreed with by David Skaife. I'll note that = Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.= >=20 > I'm fine with refactoring the authorization protocol. But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed. Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0. >=20 > Please revise the charter to remove digital identity from the scope of = the work. >=20 > 2. Are you willing to author or participate in the development of the = drafts of this WG? >=20 > Yes >=20 > 3. Are you willing to help review the drafts of this WG? >=20 > Yes >=20 > 4. Are you interested in implementing drafts of this WG? >=20 > Not at this time. >=20 > -- Mike >=20 > -----Original Message----- > From: Txauth On Behalf Of Torsten = Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM > To: Yaron Sheffer > Cc: txauth@ietf.org > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth = WG >=20 > Hi, >=20 >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : >>=20 >> =EF=BB=BFHi Everyone, >>=20 >> It appears that momentum is forming around the proposed formation of = a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: >>=20 >> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >=20 > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned = the scope of the charter is too broad, e.g. identify alone is a huge = topic. >=20 > We need to keep an eye on this aspect in order to make sure, the group = is able to work effectively and the specs we will be producing are as = simple as possible and foster interoperability. >=20 >>=20 >> 2. Are you willing to author or participate in the development of = the drafts of this WG? >=20 > yes >=20 >>=20 >> 3. Are you willing to help review the drafts of this WG? >=20 > yes >=20 >>=20 >> 4. Are you interested in implementing drafts of this WG? >=20 > yes >=20 > best regards, > Torsten. >=20 >>=20 >> The call will run for two weeks, until March 21. If you think that = the charter should be amended In a significant way, please reply on a = separate thread. >>=20 >> The feedback provided here will help the IESG come to a decision on = the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. >>=20 >> Thanks, >> Yaron and Dick >>=20 >> --- Charter Text Follows --- >>=20 >> This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >>=20 >> The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >>=20 >> Additionally, the delegation process will allow for: >>=20 >> - Fine-grained specification of access >> - Approval of AS attestation to identity claims >> - Approval of access to multiple resources and APIs in a single = interaction >> - Separation between the party authorizing access and the party = operating the client requesting access >> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys >> - Optimized inclusion of additional information through the = delegation process (including identity) >>=20 >> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >>=20 >> - Discovery of the authorization server >> - Revocation of active tokens >> - Query of token rights by resource servers >>=20 >> Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. >>=20 >> This group is not chartered to develop extensions to OAuth 2.0, and = as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >>=20 >> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.=20 >>=20 >> The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >>=20 >> Milestones to include: >> - Core delegation protocol >> - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures >> - Identity and authentication conveyance mechanisms >> - Guidelines for use of protocol extension points >>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 17 15:05:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588A63A0886 for ; Tue, 17 Mar 2020 15:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 HIyGtKfoYbgE for ; Tue, 17 Mar 2020 15:05:52 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640139.outbound.protection.outlook.com [40.107.64.139]) (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 A55B13A0885 for ; Tue, 17 Mar 2020 15:05:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YSjKdKqEX/SslF/YXTXmn9GzuCZ44tyZ0TXTPETpUccjRBSWcFVBF+XN2YhwXgTrdzxsbSPlouwT25vOukSYpC1FiY/ar8ViPZl4KXnaAPUo4AaOdUQQ/fFulM+sbZ3UIQvAcE4CJ+h8SaurPvxJMLzPq/QjPOU0dPuuUwr13MEATJ9clhtm9Iy6ujbwzAw3r6PBoN1hAf6OvFYc0ZNRP4+bvur2S3bSU8EJc0ixuxTmhw8DFoZ0+XxenDC+Zlcp0swpseAX7TDyWSi4gxgwAjweFzsI+c5ofNuVjdIzd76tnuyOoTrt1jUD6re/gXtMMzpG2wOm/+KFbehzcbD00g== 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=GYzq3kIIKi5DE2lfwhhJ3pRAHpqfcKW54TWi9tr+Z9w=; b=hRRgXzFMCWaqWGsSUCALOpbXzQpyjYRLNk8bg/lVwx42qTMX/k6pLqdVPQhVLdwvkEUEE1w/69jmFfHNTafY1UvxOv/w5EIC2zbQbIycXLEw3qcJabwBFPj2lgKQNmnu5ePQIohadnuKIgfi5GZas+AkTDn6VbaqFDA+RQzsM8qvJYBOQgYCLTOYPISk7+MMvszdsqXQnW5C1S9Qt/vng4cmeS7j3V+Aew507Q8GjRqMDbk9E2e+5JhJ+OjALBDTte12xqaVB6HQSltjEQPSBGVXx+Av+aurU/CbkIkbf+LuDoiGM93//MQQV49sGwMuhY0swxKlqzA+dVRn0LttWw== 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=GYzq3kIIKi5DE2lfwhhJ3pRAHpqfcKW54TWi9tr+Z9w=; b=WvCvYfVCZin7k7+uT+1rCY1da02/koj/CitiGOKa8pM1vdOdbthB0iR+Ue6jrEREQly4TyMrt0Mi8JKHgDJjdIF8pcuMprj4dONkmIp9T+JZIiwCMcS5amzOV6nGEyxmUeU5THEBt33ouKWou/TulXI79lZqyhXFQV2yohoM+qo= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0670.namprd00.prod.outlook.com (2603:10b6:208:1d8::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2871.0; Tue, 17 Mar 2020 22:05:50 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::7cd4:bb5:e70d:f8a2]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::7cd4:bb5:e70d:f8a2%9]) with mapi id 15.20.2873.000; Tue, 17 Mar 2020 22:05:50 +0000 From: Mike Jones To: Justin Richer CC: Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AdX8qDR2vl6CizN9TBeow352Bw//Mg== Date: Tue, 17 Mar 2020 22:05:50 +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_ActionId=cfc55234-bda5-4e77-997c-00009fc31793; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-17T22:00:08Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.81.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b99d6250-562e-4374-908d-08d7cabf5aaa x-ms-traffictypediagnostic: MN2PR00MB0670: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(376002)(396003)(346002)(136003)(39860400002)(366004)(199004)(8936002)(4326008)(66574012)(8990500004)(55016002)(9686003)(966005)(2906002)(6916009)(8676002)(71200400001)(26005)(81156014)(186003)(81166006)(478600001)(10290500003)(53546011)(316002)(33656002)(66556008)(64756008)(66446008)(66476007)(76116006)(54906003)(86362001)(6506007)(5660300002)(66946007)(7696005)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR00MB0670; H:MN2PR00MB0686.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cP2/Q159CqWebc4wF8U0hMZ6OIGIS5xSjnaVHoI+iHj/CEmCOaClQ0ArW0f1sNoKWd0pKkUQUPPzzQqHdb3pGwJ+amShAC6uv4PbsqhcAlxCf7H+39nhFlQDygzUzDpYV13a4FvQ4U4vd/3WxnDtlHbgoHy5YIP15DYswGDlbO0N9ehYuRnXFkdzizH/pIWU7d+c0LTyV7bFoJITBIK3LUnZYuRbmiwzcbW8y8t/GOIJp2FFEns5n3y1vBCYkEEPENa6o/VwaSSxoTL5huq2Se6nBWP8p4T844dy9YFjYIFrM5WpuWWtEcv/SIqFW2roM88LWvz92vqGauBI2aKoYb+1gDiJ9USznmYNHK82AviELe4ZKcCOa56LV3hlzzu0nfdfJEb9lfB2uACs4aV2PhZlYtvkLolv6D15U1rziNWVJbbAGntBrFaomBVV5QDQs4FvJFoGYpJloT9n12e4Q1zWy58aZSYi/YfNTZ2Ps1NQx3OajqUweASaBUlMMy9D3SSVk4FiQm7nKzOLgZRI5w== x-ms-exchange-antispam-messagedata: 6O1AfcK5u50DCCB02j+81snoqLqwYGJmocqaF8XEfZjzbAZ+2DhzrdlQA8Bc4ZfnESlVUnqns9/eExtjEKU5/nT+5BPv2q+x3/DjYHPEWC8Z6AIxTTfPSLMBwZpfmsHqTpHFPGZhqLvrUqh9iCqo8w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b99d6250-562e-4374-908d-08d7cabf5aaa X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2020 22:05:50.3343 (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: Rrw45+J9Lm13xQJ08gnjnfLJjtmFp/CF0DoMqo7BzgKm4Mn1MQpkbMrqnYg9ATrKOK5k7MsCKBTueLvTLhU7pg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0670 Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 22:05:56 -0000 SSBiZWxpZXZlIGl0J3Mgc2lnbmlmaWNhbnQgdGhhdCBmb3VyIHBlb3BsZSBoYXZlIGV4cHJlc3Nl ZCBjb25jZXJucyB3aXRoIGluY2x1ZGluZyBkaWdpdGFsIGlkZW50aXR5IGluIHRoZSBjaGFydGVy ICh0aGUgb25seSBjb25jZXJucyB2b2ljZWQgYXMgZmFyIGFzIEkgY2FuIHRlbGwpLiAgQXQgYSBt aW5pbXVtLCBJIGJlbGlldmUgdGhhdCB0aGF0IHdhcnJhbnRzIG1ha2luZyB0aGUgaW5jbHVzaW9u IG9yIGV4Y2x1c2lvbiBvZiBkaWdpdGFsIGlkZW50aXR5IGEgZGlzY3Vzc2lvbiB0b3BpYyBkdXJp bmcgdGhlIHVwY29taW5nIHZpcnR1YWwgQm9GLCBiZWZvcmUgYWRvcHRpbmcgYW55IGNoYXJ0ZXIu DQoNCkl0IHdvdWxkIGJlIG15IHByb3Bvc2FsIHRvIGluaXRpYWxseSBjaGFydGVyIHdpdGhvdXQg ZGlnaXRhbCBpZGVudGl0eSBhbmQgc2VlIGhvdyBmYXIgd2UgZ2V0IHdpdGggb3VyIGVuZXJnaWVz IGludGVudGlvbmFsbHkgZm9jdXNlZCBpbiB0aGF0IHdheS4gIElmIHRoZSB3b3JraW5nIGdyb3Vw IGRlY2lkZXMgdG8gcmVjaGFydGVyIHRvIGluY2x1ZGUgZGlnaXRhbCBpZGVudGl0eSwgdGhhdCBj YW4gYWx3YXlzIGhhcHBlbiBsYXRlciwgYWZ0ZXIgdGhlIGF1dGhvcml6YXRpb24tZm9jdXNlZCB3 b3JrIGhhcyBtYXR1cmVkLCBhbmQgb25jZSB0aGVyZSdzIGEgY2xlYXIgY2FzZSB0byBhY3R1YWxs eSBkbyBzby4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gDQpTZW50OiBUdWVzZGF5LCBNYXJj aCAxNywgMjAyMCAyOjIwIFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IFRvcnN0 ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjsgdHhhdXRoQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gQ2FsbCBmb3IgY2hhcnRlciBjb25zZW5zdXMgLSBUeEF1 dGggV0cNCg0KV2hpbGUgSSB1bmRlcnN0YW5kIHRoZSBjb25jZXJucyBhcm91bmQgaWRlbnRpdHkg aW4gdGhlIGNoYXJ0ZXIsIGFuZCBJIGhhZCBpbml0aWFsbHkgbm90IGluY2x1ZGVkIGl0LCBJIHdh cyBjb252aW5jZWQgdGhhdCB0aGUga2luZCBvZiBpZGVudGl0eSBwcm90b2NvbCB0aGF0IHdl4oCZ cmUgbG9va2luZyBhdCBoZXJlIGlzIGEgbWlub3IgYWRkaXRpb24gdG8gdGhlIGF1dGhvcml6YXRp b24gYW5kIGRlbGVnYXRpb24gZW5kIG9mIHRoaW5ncy4NCg0KQXMgeW91IGtub3csIG11Y2ggb2Yg d2hhdOKAmXMgaW4gT0lEQyBpcyB0aGVyZSB0byBmaXggcHJvYmxlbXMgd2l0aCBPQXV0aCAyIHdo ZW4gaXTigJlzIHVzZWQgZm9yIGlkZW50aXR5LiBJZiBPQXV0aCAyIGhhZCBzb2x2ZWQgdGhvc2Ug cHJvYmxlbXMgaW50ZXJuYWxseSwgdGhlbiBPSURDIHdvdWxkIGJlIG11Y2gsIG11Y2ggc2ltcGxl ciBhbmQgc21hbGxlci4gV2XigJlyZSBub3cgc3RhcnRpbmcgYXQgYSBiYXNlIHdoZXJlIHRob3Nl IHByb2JsZW1zIGRvbuKAmXQgZXhpc3QsIGJ1dCB3ZSBkb27igJl0IHlldCBrbm93IHdoYXQgb3Ro ZXIgcHJvYmxlbXMgdGhlcmUgbWlnaHQgYmUuIA0KDQpUaGUgbWFya2V0IGhhcyBzaG93biB1cyB0 aGF0IHRoZSBtb3N0IGNvbW1vbiBhcHBsaWNhdGlvbiBvZiBPQXV0aCAyIGlzIGZhciBhbmQgYXdh eSBhY2Nlc3MgdG8gaWRlbnRpdHkgaW5mb3JtYXRpb24gYWxvbmcgc2lkZSBhY2Nlc3MgdG8gYW4g QVBJLiBJIHRoaW5rIHdlIG5lZWQgdG8gcGF5IGF0dGVudGlvbiB0byB0aGF0IGFuZCBub3QgbWFr ZSB0aGlzIHNlcGFyYXRlIGp1c3QgYmVjYXVzZSB3ZSBkaWQgaXQgdGhhdCB3YXkgYmVmb3JlLiBB bmQgc29tZSBvZiB0aGUgcHJvcG9zZWQgaW5ub3ZhdGlvbnMsIGluY2x1ZGluZyBnZXR0aW5nIGFu ZCBzZW5kaW5nIFZD4oCZcywgYXJlIGFsbCBhYm91dCBpZGVudGl0eS4NCg0KRnVydGhlcm1vcmUs IHRoaXMgY2hhcnRlciBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBkb2N1bWVudCBhbmQgc3BlY2lmaWNh dGlvbiBzdHJ1Y3R1cmUgb2YgdGhlIGNvbXBvbmVudHMsIG5vciBkb2VzIGl0IHNwZWNpZnkgdGhl IHB1YmxpY2F0aW9uIG9yZGVyIG9yIHRpbWluZyBvZiBhbnkgZG9jdW1lbnRzLiBJIHBlcnNvbmFs bHkgdGhpbmsgdGhhdCB0aGUgaWRlbnRpdHkgbGF5ZXIgc2hvdWxkIGJlIHNlcGFyYWJsZSB0byBh biBleHRlbnQsIHRvIHRoZSBwb2ludCBvZiBwdWJsaXNoaW5nIHRoYXQgbGF5ZXIgaW4gaXRzIG93 biBzcGVjIGFsb25nc2lkZSB0aGUgY29yZSBhdXRob3JpemF0aW9uIGRlbGVnYXRpb24gc3lzdGVt LiBIb3dldmVyLCB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCBpdCBzaG91bGQgYmUgZGV2ZWxvcGVk IGVsc2V3aGVyZS4NCg0KSWYgdGhlcmUgaXMgYmV0dGVyIGxhbmd1YWdlIHRvIHRpZ2h0ZW4gdGhl IGFzcGVjdHMgb2YgYW4gaWRlbnRpdHkgcHJvdG9jb2wgdGhhdCB3ZSB3aWxsIGV4cGxpY2l0bHkg Y292ZXIsIHRoZW4gSSB3b3VsZCB3ZWxjb21lIHlvdSB0byBzdWdnZXN0IGFuIGFtZW5kZWQgdGV4 dCB0byB0aGUgY2hhcnRlci4gSG93ZXZlciwgSSBiZWxpZXZlIHRoZXJlIGlzIGVub3VnaCBpbnRl cmVzdCB3aXRoaW4gdGhlIGNvbW11bml0eSB0byB3b3JrIG9uIGlkZW50aXR5IGluIHRoZSBjb250 ZXh0IG9mIHRoaXMgcHJvdG9jb2wsIGluY2x1ZGluZyBhIGxhcmdlIG51bWJlciBvZiBwZW9wbGUg YmVpbmcgT0sgd2l0aCBpdCBpbiB0aGUgY2hhcnRlciwgdGhhdCBpdCB3b3VsZCBub3QgYmUgYSBy ZWFzb25hYmxlIHRoaW5nIHRvIHJlbW92ZSBpdC4NCg0KIOKAlCBKdXN0aW4NCg0KPiBPbiBNYXIg MTcsIDIwMjAsIGF0IDE6MTIgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gDQo+IDEuICBEbyB5b3Ugc3VwcG9ydCB0 aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8gIE9yIGRv IHlvdSBoYXZlIG1ham9yIG9iamVjdGlvbnMsIGJsb2NraW5nIGNvbmNlcm5zIG9yIGZlZWRiYWNr IChpZiBzbyBwbGVhc2UgZWxhYm9yYXRlKT8NCj4gDQo+IEkgc2hhcmUgdGhlIGNvbmNlcm5zIGFi b3V0IGluY2x1ZGluZyBpZGVudGl0eSBpbiB0aGUgY2hhcnRlciB0aGF0IHdlcmUgZXhwcmVzc2Vk IGJ5IFRvcnN0ZW4gYW5kIGFncmVlZCB3aXRoIGJ5IERhdmlkIFNrYWlmZS4gIEknbGwgbm90ZSB0 aGF0IEtpbSBDYW1lcm9uIHByZXZpb3VzbHkgZXhwcmVzc2VkIGNvbmNlcm5zIGFib3V0IGluY2x1 ZGluZyBpZGVudGl0eSBpbiBoaXMgZWFybGllciBjaGFydGVyIGNyaXRpcXVlIGF0IGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoL3VMOTJPX1ZrNW0zOERjYWNYU25z aFgyQ2FoRS8uDQo+IA0KPiBJJ20gZmluZSB3aXRoIHJlZmFjdG9yaW5nIHRoZSBhdXRob3JpemF0 aW9uIHByb3RvY29sLiAgQnV0IGlkZW50aXR5IHNob3VsZCBiZSBkZWNvdXBsZWQgZnJvbSB0aGUg VHhBdXRoIHdvcmsgdG8gZm9jdXMgaXRzIHNjb3BlIG9uIGFyZWFzIHdoZXJlIGlubm92YXRpb24g aXMgYmVpbmcgcHJvcG9zZWQuICBEaWdpdGFsIGlkZW50aXR5IGNhbiBhbHdheXMgYmUgYWRkZWQg YXMgYSBsYXllciBpZiBuZWVkZWQsIGp1c3QgYXMgT3BlbklEIENvbm5lY3QgbGF5ZXJlZCBpZGVu dGl0eSBvbnRvIE9BdXRoIDIuMC4NCj4gDQo+IFBsZWFzZSByZXZpc2UgdGhlIGNoYXJ0ZXIgdG8g cmVtb3ZlIGRpZ2l0YWwgaWRlbnRpdHkgZnJvbSB0aGUgc2NvcGUgb2YgdGhlIHdvcmsuDQo+IA0K PiAyLiAgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhvciBvciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2 ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPw0KPiANCj4gWWVzDQo+IA0KPiAzLiAg QXJlIHlvdSB3aWxsaW5nIHRvIGhlbHAgcmV2aWV3IHRoZSBkcmFmdHMgb2YgdGhpcyBXRz8NCj4g DQo+IFllcw0KPiANCj4gNC4gIEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJh ZnRzIG9mIHRoaXMgV0c/DQo+IA0KPiBOb3QgYXQgdGhpcyB0aW1lLg0KPiANCj4gCQkJCS0tIE1p a2UNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFR4YXV0aCA8dHhh dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0DQo+ IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCA3LCAyMDIwIDc6MTggQU0NCj4gVG86IFlhcm9uIFNoZWZm ZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4NCj4gQ2M6IHR4YXV0aEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBbRVhURVJOQUxdIFJlOiBbVHhhdXRoXSBDYWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAt IFR4QXV0aCBXRw0KPiANCj4gSGksDQo+IA0KPj4gQW0gMDYuMDMuMjAyMCB1bSAxNzo0NSBzY2hy aWViIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT46DQo+PiANCj4+IO+7v0hp IEV2ZXJ5b25lLA0KPj4gDQo+PiBJdCBhcHBlYXJzIHRoYXQgbW9tZW50dW0gaXMgZm9ybWluZyBh cm91bmQgdGhlIHByb3Bvc2VkIGZvcm1hdGlvbiBvZiBhIFR4QXV0aCB3b3JraW5nIGdyb3VwLiAg V2XigJlkIGxpa2UgdG8gbW9yZSBmb3JtYWxseSBnYXVnZSBpbnRlcmVzdCBpbiBwcm9jZWVkaW5n IHdpdGggdGhpcyB3b3JrLiAgUGxlYXNlIGRvIHNvIGJ5IHJlc3BvbmRpbmcgdG8gdGhlIGZvbGxv d2luZyBxdWVzdGlvbnM6DQo+PiANCj4+IDEuICBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0 ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8gIE9yIGRvIHlvdSBoYXZlIG1h am9yIG9iamVjdGlvbnMsIGJsb2NraW5nIGNvbmNlcm5zIG9yIGZlZWRiYWNrIChpZiBzbyBwbGVh c2UgZWxhYm9yYXRlKT8NCj4gDQo+IEnigJhtIGluIGFsdGhvdWdoIEkgaGF2ZSB0byBhZG1pdCBJ 4oCYbSBzbGlnaHRseSBjb25jZXJuZWQgdGhlIHNjb3BlIG9mIHRoZSBjaGFydGVyIGlzIHRvbyBi cm9hZCwgZS5nLiBpZGVudGlmeSBhbG9uZSBpcyBhIGh1Z2UgdG9waWMuDQo+IA0KPiBXZSBuZWVk IHRvIGtlZXAgYW4gZXllIG9uIHRoaXMgYXNwZWN0IGluIG9yZGVyIHRvIG1ha2Ugc3VyZSwgdGhl IGdyb3VwIGlzIGFibGUgdG8gd29yayBlZmZlY3RpdmVseSBhbmQgdGhlIHNwZWNzIHdlIHdpbGwg YmUgcHJvZHVjaW5nIGFyZSBhcyBzaW1wbGUgYXMgcG9zc2libGUgYW5kIGZvc3RlciBpbnRlcm9w ZXJhYmlsaXR5Lg0KPiANCj4+IA0KPj4gMi4gIEFyZSB5b3Ugd2lsbGluZyB0byBhdXRob3Igb3Ig cGFydGljaXBhdGUgaW4gdGhlIGRldmVsb3BtZW50IG9mIHRoZSBkcmFmdHMgb2YgdGhpcyBXRz8N Cj4gDQo+IHllcw0KPiANCj4+IA0KPj4gMy4gIEFyZSB5b3Ugd2lsbGluZyB0byBoZWxwIHJldmll dyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQo+IA0KPiB5ZXMNCj4gDQo+PiANCj4+IDQuICBBcmUg eW91IGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIGRyYWZ0cyBvZiB0aGlzIFdHPw0KPiANCj4g eWVzDQo+IA0KPiBiZXN0IHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+IA0KPj4gDQo+PiBUaGUgY2Fs bCB3aWxsIHJ1biBmb3IgdHdvIHdlZWtzLCB1bnRpbCBNYXJjaCAyMS4gSWYgeW91IHRoaW5rIHRo YXQgdGhlIGNoYXJ0ZXIgc2hvdWxkIGJlIGFtZW5kZWQgSW4gYSBzaWduaWZpY2FudCB3YXksIHBs ZWFzZSByZXBseSBvbiBhIHNlcGFyYXRlIHRocmVhZC4NCj4+IA0KPj4gVGhlIGZlZWRiYWNrIHBy b3ZpZGVkIGhlcmUgd2lsbCBoZWxwIHRoZSBJRVNHIGNvbWUgdG8gYSBkZWNpc2lvbiBvbiB0aGUg Zm9ybWF0aW9uIG9mIGEgbmV3IFdHLiBHaXZlbiB0aGUgY29uc3RyYWludHMgb2YgdGhlIGNoYXJ0 ZXJpbmcgcHJvY2VzcywgcmVnYXJkbGVzcyBvZiB0aGUgb3V0Y29tZSBvZiB0aGlzIGNvbnNlbnN1 cyBjYWxsLCB3ZSB3aWxsIGJlIG1lZXRpbmcgaW4gVmFuY291dmVyIGFzIGEgQm9GLg0KPj4gDQo+ PiBUaGFua3MsDQo+PiBZYXJvbiBhbmQgRGljaw0KPj4gDQo+PiAtLS0gQ2hhcnRlciBUZXh0IEZv bGxvd3MgLS0tDQo+PiANCj4+IFRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBm aW5lLWdyYWluZWQgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgYXV0aG9yaXphdGlvbiwgaWRlbnRp dHksIGFuZCBBUEkgYWNjZXNzLiBUaGlzIHByb3RvY29sIHdpbGwgYWxsb3cgYW4gYXV0aG9yaXpp bmcgcGFydHkgdG8gZGVsZWdhdGUgYWNjZXNzIHRvIGNsaWVudCBzb2Z0d2FyZSB0aHJvdWdoIGFu IGF1dGhvcml6YXRpb24gc2VydmVyLiBJdCB3aWxsIGV4cGFuZCB1cG9uIHRoZSB1c2VzIGNhc2Vz IGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCAoaXRz ZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQgYXV0aG9yaXphdGlvbnMg c2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRyYW5zYWN0aW9uLCBwcm92aWRlIGEgY2xl YXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBp biB0aGUgcHJvdG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1bm5lY2Vzc2FyeSBkZXBlbmRlbmNlIG9u IGEgYnJvd3NlciBvciB1c2VyLWFnZW50IGZvciBjb29yZGluYXRpbmcgaW50ZXJhY3Rpb25zLiAN Cj4+IA0KPj4gVGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVs dGlwbGUgcGFydGllcyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmlj IHJvbGUuIFRoZSBwcm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVs cywgc3VjaCBhcyB0aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24g Y2hhbm5lbCwgd2hpY2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2gg aXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dz ZXIpLiBUaGUgY2xpZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0 aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNo YW5pc21zIGluZGljYXRlZCBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGluZyBhdm9pZHMg bWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9m IE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGlu ZyBmdXR1cmUgdHlwZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQo+PiAN Cj4+IEFkZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoN Cj4+IA0KPj4gLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCj4+IC0gQXBw cm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRlbnRpdHkgY2xhaW1zDQo+PiAtIEFwcHJvdmFs IG9mIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMgaW4gYSBzaW5nbGUgaW50 ZXJhY3Rpb24NCj4+IC0gU2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBh Y2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVyYXRpbmcgdGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2Vz cw0KPj4gLSBBIHZhcmlldHkgb2YgY2xpZW50IGFwcGxpY2F0aW9ucywgaW5jbHVkaW5nIFdlYiwg bW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIGludGVyYWN0aW9uLWNvbnN0cmFpbmVkIGFwcGxpY2F0 aW9ucw0KPj4gDQo+PiBUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3Ig dGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5n Og0KPj4gDQo+PiAtIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWdu YXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbiANCj4+IC0gVXNlciBpbnRlcmFjdGlvbiBt ZWNoYW5pc21zIGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcw0KPj4gLSBNZWNoYW5p c21zIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVy IHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zDQo+ PiAtIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcnMg YW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMgdG8gdG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNy eXB0b2dyYXBoaWMga2V5cw0KPj4gLSBPcHRpbWl6ZWQgaW5jbHVzaW9uIG9mIGFkZGl0aW9uYWwg aW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIChpbmNsdWRpbmcgaWRl bnRpdHkpDQo+PiANCj4+IEFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNo YW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5n Og0KPj4gDQo+PiAtIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCj4+IC0g UmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zDQo+PiAtIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0cyBi eSByZXNvdXJjZSBzZXJ2ZXJzDQo+PiANCj4+IEFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9yIHRo aXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21w YXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBh dHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENv bm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJsZS4NCj4+IA0KPj4gVGhpcyBn cm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAs IGFuZCBhcyBzdWNoIHdpbGwgZm9jdXMgb24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5v dCBuZWNlc3NhcmlseSBjb21wYXRpYmxlIHdpdGggT0F1dGggMi4wLiBGdW5jdGlvbmFsaXR5IHRo YXQgYnVpbGRzIGRpcmVjdGx5IG9uIE9BdXRoIDIuMCB3aWxsIGJlIGRldmVsb3BlZCBpbiB0aGUg T0F1dGggV29ya2luZyBHcm91cCwgaW5jbHVkaW5nIGZ1bmN0aW9uYWxpdHkgYmFjay1wb3J0ZWQg ZnJvbSB0aGUgcHJvdG9jb2wgZGV2ZWxvcGVkIGhlcmUgdG8gT0F1dGggMi4wLg0KPj4gDQo+PiBU aGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcg Y3J5cHRvZ3JhcGhpYyBtZXRob2RzLCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxl Z2F0aW9uIHByb2Nlc3MuIFRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5l dyBjcnlwdG9ncmFwaGljIG1ldGhvZHMuIA0KPj4gDQo+PiBUaGUgaW5pdGlhbCB3b3JrIHdpbGwg Zm9jdXMgb24gdXNpbmcgSFRUUCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQg YW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFudGFnZSBvZiBvcHRpbWl6 YXRpb24gZmVhdHVyZXMgb2YgSFRUUDIgYW5kIEhUVFAzIHdoZXJlIHBvc3NpYmxlLCBhbmQgd2ls bCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBsZSBtYXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNo IGFzIENPQVAgd2hlbiBkb2luZyBzbyBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoZSBwcmltYXJ5 IGZvY3VzLg0KPj4gDQo+PiBNaWxlc3RvbmVzIHRvIGluY2x1ZGU6DQo+PiAtIENvcmUgZGVsZWdh dGlvbiBwcm90b2NvbA0KPj4gLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0 byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwgYW5k IGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KPj4gLSBJZGVudGl0eSBhbmQgYXV0aGVudGljYXRp b24gY29udmV5YW5jZSBtZWNoYW5pc21zDQo+PiAtIEd1aWRlbGluZXMgZm9yIHVzZSBvZiBwcm90 b2NvbCBleHRlbnNpb24gcG9pbnRzDQo+PiANCj4+IA0KPj4gLS0gDQo+PiBUeGF1dGggbWFpbGlu ZyBsaXN0DQo+PiBUeGF1dGhAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoDQo+IC0tIA0KPiBUeGF1dGggbWFpbGluZyBsaXN0DQo+IFR4YXV0 aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0 aA0KDQo= From nobody Tue Mar 17 15:32:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530753A091E for ; Tue, 17 Mar 2020 15:31:59 -0700 (PDT) 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=parecki-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 gAyygSfHrC6O for ; Tue, 17 Mar 2020 15:31:56 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 7FC903A091D for ; Tue, 17 Mar 2020 15:31:56 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id q9so2928751iod.4 for ; Tue, 17 Mar 2020 15:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XKOZmPaq96+RgJ/q6DNAGirwRWscJMeTCx0LT9Ac+pc=; b=DyodxZoQZufYlxnfPBz43TTUIqc7LmzUNCqDTQd+iapgQcJmv75DLMftVngniiW90u FExB4DRxGl2X1N3s/ELBFCNEgAv3MZMkxWzIdmRB5R8Bm5dDnruBSq5OFfHUTYdCH7zd SmJa9ZNvxcHoeaDHGQdr0MDPNkhShQSHHyO161xkB1fQdUSFOu5Vtj3pqv8KKCNQVZsb suxuGWkmukT6GxrUNfcNpGgxDN6lpIsqkE8XmtZe9KOpNv6Gv8u0Vp1gpS5he20/VeN9 mAPzp8PmTbr5wlFVT2m+nJutbiN+PCA3PGuSEIA2mT93xONOlrgCugkLboMyFq6oL2JI 9/Xw== 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=XKOZmPaq96+RgJ/q6DNAGirwRWscJMeTCx0LT9Ac+pc=; b=f3Oar1wOHoWVCxSOyS6h7PYKhXlQEhAjukOzy0eIJ/9WuJvCFw5UKYkBkl21VuohtQ zBQVQStflX8OgPB8SBz0v0wBnANTJL4+klFTL4Ql7q65CL7ytoMtEEd0Uf7MAP8m7VhX fhZUDy/SWisoNEEQ23DMd/92EmisbrVRKdcUxu/olA+Qk24cXZkkt5cE70w8fnvFDKFr zZpy7JvIVavm8WCdq2wTmqmrna1+vcP6C7uHxG06TQCCp72zd6d9oCS+9x1j5qaTapHI F1997/0GhDtMFGz8oJ1mU2cmhloB/uY78oAy+1lwj0nVVF/o2/X86a8lgV8SCyNqr85V /F/w== X-Gm-Message-State: ANhLgQ1oEjfd0v/Y3hf65ceHsyOB7bwn81C4Yf7vjefYk8lLhOZLkLYI RdhpZwtSlP3NT16uO6ta1sObciM9ppk= X-Google-Smtp-Source: ADFU+vu/aefs2FA/kUB/pnvlzdmofMR1ziZIOoMfvpQeTBcBJZiRJiJ0coYsyuqQGLIuYXb3bZ5RjQ== X-Received: by 2002:a02:cb8b:: with SMTP id u11mr1522570jap.57.1584484315236; Tue, 17 Mar 2020 15:31:55 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id z72sm1393393iof.52.2020.03.17.15.31.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2020 15:31:54 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id v6so10586165ilq.2 for ; Tue, 17 Mar 2020 15:31:54 -0700 (PDT) X-Received: by 2002:a92:c647:: with SMTP id 7mr1120566ill.28.1584484314198; Tue, 17 Mar 2020 15:31:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Tue, 17 Mar 2020 15:31:43 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Mike Jones Cc: Justin Richer , Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 22:32:00 -0000 Much of the confusion in the marketplace around OAuth and OpenID Connect stems from the fact that they are separate specs developed in separate organizations, when really they are two parts to the same picture. I am strongly against excluding identity from the charter of TxAuth, as I think this is a unique opportunity to bring the two aspects together. The concern expressed by Kim (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE) around OpenID Connect could also be said about OAuth, namely that there will be some amount of confusion around the fact that this spec will cover many of the same use cases as OAuth. I think that's fine, that's just how we move forward and make progress. The other concerns seem vague, e.g. "identity is a huge topic". While that may be true, so is authorization, and that alone is not a good reason to not do it. Perhaps the scope of identity included in TxAuth could be narrowed to specify that it's only about communicating identity information, not about doing things like identity proofing or identity assurance. That might help address some of the other concerns that have been expressed. ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Mar 17, 2020 at 3:06 PM Mike Jones wrote: > > I believe it's significant that four people have expressed concerns with = including digital identity in the charter (the only concerns voiced as far = as I can tell). At a minimum, I believe that that warrants making the incl= usion or exclusion of digital identity a discussion topic during the upcomi= ng virtual BoF, before adopting any charter. > > It would be my proposal to initially charter without digital identity and= see how far we get with our energies intentionally focused in that way. I= f the working group decides to recharter to include digital identity, that = can always happen later, after the authorization-focused work has matured, = and once there's a clear case to actually do so. > > -- Mike > > -----Original Message----- > From: Justin Richer > Sent: Tuesday, March 17, 2020 2:20 PM > To: Mike Jones > Cc: Yaron Sheffer ; Torsten Lodderstedt ; txauth@ietf.org > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > > While I understand the concerns around identity in the charter, and I had= initially not included it, I was convinced that the kind of identity proto= col that we=E2=80=99re looking at here is a minor addition to the authoriza= tion and delegation end of things. > > As you know, much of what=E2=80=99s in OIDC is there to fix problems with= OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those p= roblems internally, then OIDC would be much, much simpler and smaller. We= =E2=80=99re now starting at a base where those problems don=E2=80=99t exist= , but we don=E2=80=99t yet know what other problems there might be. > > The market has shown us that the most common application of OAuth 2 is fa= r and away access to identity information along side access to an API. I th= ink we need to pay attention to that and not make this separate just becaus= e we did it that way before. And some of the proposed innovations, includin= g getting and sending VC=E2=80=99s, are all about identity. > > Furthermore, this charter does not specify the document and specification= structure of the components, nor does it specify the publication order or = timing of any documents. I personally think that the identity layer should = be separable to an extent, to the point of publishing that layer in its own= spec alongside the core authorization delegation system. However, that doe= s not mean that it should be developed elsewhere. > > If there is better language to tighten the aspects of an identity protoco= l that we will explicitly cover, then I would welcome you to suggest an ame= nded text to the charter. However, I believe there is enough interest withi= n the community to work on identity in the context of this protocol, includ= ing a large number of people being OK with it in the charter, that it would= not be a reasonable thing to remove it. > > =E2=80=94 Justin > > > On Mar 17, 2020, at 1:12 PM, Mike Jones wrote: > > > > 1. Do you support the charter text provided at the end of this email? = Or do you have major objections, blocking concerns or feedback (if so plea= se elaborate)? > > > > I share the concerns about including identity in the charter that were = expressed by Torsten and agreed with by David Skaife. I'll note that Kim C= ameron previously expressed concerns about including identity in his earlie= r charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk= 5m38DcacXSnshX2CahE/. > > > > I'm fine with refactoring the authorization protocol. But identity sho= uld be decoupled from the TxAuth work to focus its scope on areas where inn= ovation is being proposed. Digital identity can always be added as a layer= if needed, just as OpenID Connect layered identity onto OAuth 2.0. > > > > Please revise the charter to remove digital identity from the scope of = the work. > > > > 2. Are you willing to author or participate in the development of the = drafts of this WG? > > > > Yes > > > > 3. Are you willing to help review the drafts of this WG? > > > > Yes > > > > 4. Are you interested in implementing drafts of this WG? > > > > Not at this time. > > > > -- Mike > > > > -----Original Message----- > > From: Txauth On Behalf Of Torsten Lodderstedt > > Sent: Saturday, March 7, 2020 7:18 AM > > To: Yaron Sheffer > > Cc: txauth@ietf.org > > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG > > > > Hi, > > > >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : > >> > >> =EF=BB=BFHi Everyone, > >> > >> It appears that momentum is forming around the proposed formation of a= TxAuth working group. We=E2=80=99d like to more formally gauge interest i= n proceeding with this work. Please do so by responding to the following q= uestions: > >> > >> 1. Do you support the charter text provided at the end of this email?= Or do you have major objections, blocking concerns or feedback (if so ple= ase elaborate)? > > > > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned = the scope of the charter is too broad, e.g. identify alone is a huge topic. > > > > We need to keep an eye on this aspect in order to make sure, the group = is able to work effectively and the specs we will be producing are as simpl= e as possible and foster interoperability. > > > >> > >> 2. Are you willing to author or participate in the development of the= drafts of this WG? > > > > yes > > > >> > >> 3. Are you willing to help review the drafts of this WG? > > > > yes > > > >> > >> 4. Are you interested in implementing drafts of this WG? > > > > yes > > > > best regards, > > Torsten. > > > >> > >> The call will run for two weeks, until March 21. If you think that the= charter should be amended In a significant way, please reply on a separate= thread. > >> > >> The feedback provided here will help the IESG come to a decision on th= e formation of a new WG. Given the constraints of the chartering process, r= egardless of the outcome of this consensus call, we will be meeting in Vanc= ouver as a BoF. > >> > >> Thanks, > >> Yaron and Dick > >> > >> --- Charter Text Follows --- > >> > >> This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an au= thorizing party to delegate access to client software through an authorizat= ion server. It will expand upon the uses cases currently supported by OAuth= 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support autho= rizations scoped as narrowly as a single transaction, provide a clear frame= work for interaction among all parties involved in the protocol flow, and r= emove unnecessary dependence on a browser or user-agent for coordinating in= teractions. > >> > >> The delegation process will be acted upon by multiple parties in the p= rotocol, each performing a specific role. The protocol will decouple the in= teraction channels, such as the end user=E2=80=99s browser, from the delega= tion channel, which happens directly between the client and the authorizati= on server (in contrast with OAuth 2.0 which is initiated by the client redi= recting the user=E2=80=99s browser). The client and AS will involve a user = to make an authorization decision as necessary through interaction mechanis= ms indicated by the protocol. This decoupling avoids many of the security c= oncerns and technical challenges of OAuth 2.0 and provides a non-invasive p= ath for supporting future types of clients and interaction channels. > >> > >> Additionally, the delegation process will allow for: > >> > >> - Fine-grained specification of access > >> - Approval of AS attestation to identity claims > >> - Approval of access to multiple resources and APIs in a single intera= ction > >> - Separation between the party authorizing access and the party operat= ing the client requesting access > >> - A variety of client applications, including Web, mobile, single-page= , and interaction-constrained applications > >> > >> The group will define extension points for this protocol to allow for = flexibility in areas including: > >> > >> - Cryptographic agility for keys, message signatures, and proof of pos= session > >> - User interaction mechanisms including web and non-web methods > >> - Mechanisms for conveying user, software, organization, and other pie= ces of information used in authorization decisions > >> - Mechanisms for presenting tokens to resource servers and binding res= ource requests to tokens and associated cryptographic keys > >> - Optimized inclusion of additional information through the delegation= process (including identity) > >> > >> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: > >> > >> - Discovery of the authorization server > >> - Revocation of active tokens > >> - Query of token rights by resource servers > >> > >> Although the artifacts for this work are not intended or expected to b= e backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att= empt to simplify migrating from OAuth 2.0 and OpenID Connect to the new pro= tocol where possible. > >> > >> This group is not chartered to develop extensions to OAuth 2.0, and as= such will focus on new technological solutions not necessarily compatible = with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be dev= eloped in the OAuth Working Group, including functionality back-ported from= the protocol developed here to OAuth 2.0. > >> > >> The group is chartered to develop mechanisms for applying cryptographi= c methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods. > >> > >> The initial work will focus on using HTTP for communication between th= e client and the authorization server, taking advantage of optimization fea= tures of HTTP2 and HTTP3 where possible, and will strive to enable simple m= apping to other protocols such as COAP when doing so does not conflict with= the primary focus. > >> > >> Milestones to include: > >> - Core delegation protocol > >> - Key presentation mechanism bindings to the core protocol for TLS, de= tached HTTP signature, and embedded HTTP signatures > >> - Identity and authentication conveyance mechanisms > >> - Guidelines for use of protocol extension points > >> > >> > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 17 15:47:00 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69133A0939 for ; Tue, 17 Mar 2020 15:46:56 -0700 (PDT) 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=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 sAx5zXKHvWZt for ; Tue, 17 Mar 2020 15:46:55 -0700 (PDT) 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 CA2C83A095E for ; Tue, 17 Mar 2020 15:46:54 -0700 (PDT) Received: from [192.168.1.5] (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 02HMknD9027619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 18:46:50 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 17 Mar 2020 18:46:49 -0400 Cc: Mike Jones , Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Parecki X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 22:46:57 -0000 +1 Thanks, Aaron. I think it really is a very narrow slice of identity that = we want to cover here, and I=E2=80=99d be happy to get more precise = language into the proposed charter before moving forward.=20 =E2=80=94 Justin > On Mar 17, 2020, at 6:31 PM, Aaron Parecki wrote: >=20 > Much of the confusion in the marketplace around OAuth and OpenID > Connect stems from the fact that they are separate specs developed in > separate organizations, when really they are two parts to the same > picture. I am strongly against excluding identity from the charter of > TxAuth, as I think this is a unique opportunity to bring the two > aspects together. >=20 > The concern expressed by Kim > = (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)= > around OpenID Connect could also be said about OAuth, namely that > there will be some amount of confusion around the fact that this spec > will cover many of the same use cases as OAuth. I think that's fine, > that's just how we move forward and make progress. >=20 > The other concerns seem vague, e.g. "identity is a huge topic". While > that may be true, so is authorization, and that alone is not a good > reason to not do it. >=20 > Perhaps the scope of identity included in TxAuth could be narrowed to > specify that it's only about communicating identity information, not > about doing things like identity proofing or identity assurance. That > might help address some of the other concerns that have been > expressed. >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 > On Tue, Mar 17, 2020 at 3:06 PM Mike Jones > wrote: >>=20 >> I believe it's significant that four people have expressed concerns = with including digital identity in the charter (the only concerns voiced = as far as I can tell). At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter. >>=20 >> It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way. If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Justin Richer >> Sent: Tuesday, March 17, 2020 2:20 PM >> To: Mike Jones >> Cc: Yaron Sheffer ; Torsten Lodderstedt = ; txauth@ietf.org >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >>=20 >> While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things. >>=20 >> As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be. >>=20 >> The market has shown us that the most common application of OAuth 2 = is far and away access to identity information along side access to an = API. I think we need to pay attention to that and not make this separate = just because we did it that way before. And some of the proposed = innovations, including getting and sending VC=E2=80=99s, are all about = identity. >>=20 >> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >>=20 >> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 17, 2020, at 1:12 PM, Mike Jones = wrote: >>>=20 >>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >>>=20 >>> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.= >>>=20 >>> I'm fine with refactoring the authorization protocol. But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed. Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0. >>>=20 >>> Please revise the charter to remove digital identity from the scope = of the work. >>>=20 >>> 2. Are you willing to author or participate in the development of = the drafts of this WG? >>>=20 >>> Yes >>>=20 >>> 3. Are you willing to help review the drafts of this WG? >>>=20 >>> Yes >>>=20 >>> 4. Are you interested in implementing drafts of this WG? >>>=20 >>> Not at this time. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Txauth On Behalf Of Torsten = Lodderstedt >>> Sent: Saturday, March 7, 2020 7:18 AM >>> To: Yaron Sheffer >>> Cc: txauth@ietf.org >>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth = WG >>>=20 >>> Hi, >>>=20 >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = : >>>>=20 >>>> =EF=BB=BFHi Everyone, >>>>=20 >>>> It appears that momentum is forming around the proposed formation = of a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: >>>>=20 >>>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >>>=20 >>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. >>>=20 >>> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. >>>=20 >>>>=20 >>>> 2. Are you willing to author or participate in the development of = the drafts of this WG? >>>=20 >>> yes >>>=20 >>>>=20 >>>> 3. Are you willing to help review the drafts of this WG? >>>=20 >>> yes >>>=20 >>>>=20 >>>> 4. Are you interested in implementing drafts of this WG? >>>=20 >>> yes >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>>=20 >>>> The call will run for two weeks, until March 21. If you think that = the charter should be amended In a significant way, please reply on a = separate thread. >>>>=20 >>>> The feedback provided here will help the IESG come to a decision on = the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. >>>>=20 >>>> Thanks, >>>> Yaron and Dick >>>>=20 >>>> --- Charter Text Follows --- >>>>=20 >>>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. >>>>=20 >>>> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >>>>=20 >>>> Additionally, the delegation process will allow for: >>>>=20 >>>> - Fine-grained specification of access >>>> - Approval of AS attestation to identity claims >>>> - Approval of access to multiple resources and APIs in a single = interaction >>>> - Separation between the party authorizing access and the party = operating the client requesting access >>>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>>>=20 >>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>=20 >>>> - Cryptographic agility for keys, message signatures, and proof of = possession >>>> - User interaction mechanisms including web and non-web methods >>>> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions >>>> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys >>>> - Optimized inclusion of additional information through the = delegation process (including identity) >>>>=20 >>>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: >>>>=20 >>>> - Discovery of the authorization server >>>> - Revocation of active tokens >>>> - Query of token rights by resource servers >>>>=20 >>>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. >>>>=20 >>>> This group is not chartered to develop extensions to OAuth 2.0, and = as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >>>>=20 >>>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >>>>=20 >>>> The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >>>>=20 >>>> Milestones to include: >>>> - Core delegation protocol >>>> - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures >>>> - Identity and authentication conveyance mechanisms >>>> - Guidelines for use of protocol extension points >>>>=20 >>>>=20 >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 17 16:20:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AECF3A0A0A for ; Tue, 17 Mar 2020 16:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=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 1nQZ8bV6O947 for ; Tue, 17 Mar 2020 16:20:07 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 B642C3A0A05 for ; Tue, 17 Mar 2020 16:20:07 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id j4so19144220qkc.11 for ; Tue, 17 Mar 2020 16:20:07 -0700 (PDT) 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=okOW8uTKdvu3SXJICSyDiBsv4sBMaQmQHDpx4yh5QkE=; b=BvE8EAbkadQGL+dPzymqfsNgL+I+MIaVRDUfdivBeydbzDVkhRqEpkYqYXnUYLajp/ /Vqle7ic9GCAzy0zJzYN7jOznff8dYilX+G9sSX0XkI9Y2jwHfroV8kP7iwHgaSsn5Q9 onVilmaeaR7Kb4N4Vr3/PK8QiQEbdf8ZGHEnN11A8lxB9HEM2NRU0WTKVlQecDFhXZfq 1bLYHYrGkVOpLJ7DxzzO/oUUoWQsWMIA1WQgyPeohTj/Yo5PN8bQ2Yx9sAcWrT8gDc+1 yaXm+wxuVazQjh35tkGNIswQOBr8MqVkpptdOy52bLZVAWbJfmQp+WjJfYTb3o0Uwxac vIlQ== 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=okOW8uTKdvu3SXJICSyDiBsv4sBMaQmQHDpx4yh5QkE=; b=ScqKVSlWazq0SPZRefQa8wV8WcgPl+sJd3z4WVhruNcGY9G6RrG0O5pVrQvzA7T2Lq swlWqyFkzXxsOg6OQfkKWMNKAvhJAF8T3cF796qq0alktYAOzZlOuxS/LcBs5i4J/vyX NVfq+9WtG/pyzWfAV/Zm3trTCMmWcMVtThn4LF+s0XEpZPYSx0xVzI5g2NMTJu7mqRHp ysAaK0sIKo/EhQ2eZS80IrJqBvvDB7Q+kXCLRlmG+07lkfJtGAFBgQIwt6v/Y6X5MlhJ FBskRNS9CjAaVbQmhw8dIE2u+0H3H1JIUuB8SZo1Y1LDe8XM6mSxmZPkrXj1jQ6NVpKt KUkw== X-Gm-Message-State: ANhLgQ2LhKhWV23hs7LMw+XIuZ2ove0y+49Jg+8G9yhWVb9W7ZqlNGG0 4bTxVpSjbeV5geKZuNpGeqW6q40NdmjHcXZwlp88fWc= X-Google-Smtp-Source: ADFU+vvjDioXwP7qvbw+vMsBI2R/rTLTryR9T2XowJ8k8iSc1aw+7EMM8OlmM2/o9aMD3FFA7I5m9WoTj47ueWm4uWY= X-Received: by 2002:a25:ad88:: with SMTP id z8mr1831214ybi.414.1584487206168; Tue, 17 Mar 2020 16:20:06 -0700 (PDT) MIME-Version: 1.0 References: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> In-Reply-To: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> From: Filip Skokan Date: Wed, 18 Mar 2020 00:19:28 +0100 Message-ID: To: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000132de005a1152d5f" Archived-At: Subject: Re: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 23:20:16 -0000 --000000000000132de005a1152d5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On behalf of myself as an individual 1) =C2=AF\_(=E3=83=84)_/=C2=AF, I have my doubts about the identity portion= , even if limited. I'd be fine with thinking of identity as one of the uses of the extension points only. As far as consumers (developers) are concerned the eventual, or rather, potential, transition from (or coexistance of) OIDC to txauth's identity mechanism must be in some way simple to achieve, as of now - i can't imagine the immediate hassle and software bloat if a website's nascar login page were to mix oauth/oidc with txauth IdPs, so until there's a stable protocol proposal i don't want to be thinking of identity, i'm still questioning the need for a next protocol, let alone one that may derail OIDC's rising adoption 2) no 3) yes 4) not at this point, but once it is stable, clear and there is an interop profile i will Best, *Filip* On Mon, 16 Mar 2020 at 14:50, Yaron Sheffer wrote: > Here's a quick reminder: if you haven't responded to the call yet, please > do so soon. > > Thanks, > Yaron > > =EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" wrote: > > Hi Everyone, > > It appears that momentum is forming around the proposed formation of = a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > > 1. Do you support the charter text provided at the end of this > email? Or do you have major objections, blocking concerns or feedback (i= f > so please elaborate)? > > 2. Are you willing to author or participate in the development of th= e > drafts of this WG? > > 3. Are you willing to help review the drafts of this WG? > > 4. Are you interested in implementing drafts of this WG? > > The call will run for two weeks, until March 21. If you think that th= e > charter should be amended In a significant way, please reply on a separat= e > thread. > > The feedback provided here will help the IESG come to a decision on > the formation of a new WG. Given the constraints of the chartering proces= s, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > > Thanks, > Yaron and Dick > > --- Charter Text Follows --- > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single > interaction > - Separation between the party authorizing access and the party > operating the client requesting access > - A variety of client applications, including Web, mobile, > single-page, and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegatio= n > process (including identity) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Query of token rights by resource servers > > Although the artifacts for this work are not intended or expected to > be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and a= s > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying > cryptographic methods, such as JOSE and COSE, to the delegation process. > This group is not chartered to develop new cryptographic methods. > > The initial work will focus on using HTTP for communication between > the client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000132de005a1152d5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On behalf of myself as an individual

1) =C2=AF\_(=E3=83=84)_/=C2=AF, I have my doubts about the identit= y portion, even if limited. I'd be fine with thinking of identity as on= e of the uses of the extension points only. As far as consumers (developers= ) are concerned the eventual, or rather, potential, transition from (or coe= xistance of) OIDC to txauth's identity mechanism must be in some way si= mple to achieve, as of now - i can't imagine the immediate hassle and s= oftware bloat if a website's nascar login page were to mix oauth/oidc w= ith txauth IdPs, so until there's a stable protocol proposal i don'= t want to be thinking of identity, i'm still questioning the need for a= next protocol, let alone one that may derail OIDC's rising adoption
2) no
3) yes
4) not at this point, but once it = is stable, clear and there is an interop profile i will

Best,
Filip


On Mon, 16 Mar 2020 at 14:50, Yaron= Sheffer <yar= onf.ietf@gmail.com> wrote:
Here's a quick reminder: if you haven't responded= to the call yet, please do so soon.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

=EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrot= e:

=C2=A0 =C2=A0 Hi Everyone,

=C2=A0 =C2=A0 It appears that momentum is forming around the proposed forma= tion of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally ga= uge interest in proceeding with this work.=C2=A0 Please do so by responding= to the following questions:

=C2=A0 =C2=A0 1.=C2=A0 Do you support the charter text provided at the end = of this email?=C2=A0 Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?

=C2=A0 =C2=A0 2.=C2=A0 Are you willing to author or participate in the deve= lopment of the drafts of this WG?

=C2=A0 =C2=A0 3.=C2=A0 Are you willing to help review the drafts of this WG= ?

=C2=A0 =C2=A0 4.=C2=A0 Are you interested in implementing drafts of this WG= ?

=C2=A0 =C2=A0 The call will run for two weeks, until March 21. If you think= that the charter should be amended In a significant way, please reply on a= separate thread.

=C2=A0 =C2=A0 The feedback provided here will help the IESG come to a decis= ion on the formation of a new WG. Given the constraints of the chartering p= rocess, regardless of the outcome of this consensus call, we will be meetin= g in Vancouver as a BoF.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Yaron and Dick

=C2=A0 =C2=A0 --- Charter Text Follows ---

=C2=A0 =C2=A0 This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will al= low an authorizing party to delegate access to client software through an a= uthorization server. It will expand upon the uses cases currently supported= by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to supp= ort authorizations scoped as narrowly as a single transaction, provide a cl= ear framework for interaction among all parties involved in the protocol fl= ow, and remove unnecessary dependence on a browser or user-agent for coordi= nating interactions.

=C2=A0 =C2=A0 The delegation process will be acted upon by multiple parties= in the protocol, each performing a specific role. The protocol will decoup= le the interaction channels, such as the end user=E2=80=99s browser, from t= he delegation channel, which happens directly between the client and the au= thorization server (in contrast with OAuth 2.0 which is initiated by the cl= ient redirecting the user=E2=80=99s browser). The client and AS will involv= e a user to make an authorization decision as necessary through interaction= mechanisms indicated by the protocol. This decoupling avoids many of the s= ecurity concerns and technical challenges of OAuth 2.0 and provides a non-i= nvasive path for supporting future types of clients and interaction channel= s.

=C2=A0 =C2=A0 Additionally, the delegation process will allow for:

=C2=A0 =C2=A0 - Fine-grained specification of access
=C2=A0 =C2=A0 - Approval of AS attestation to identity claims
=C2=A0 =C2=A0 - Approval of access to multiple resources and APIs in a sing= le interaction
=C2=A0 =C2=A0 - Separation between the party authorizing access and the par= ty operating the client requesting access
=C2=A0 =C2=A0 - A variety of client applications, including Web, mobile, si= ngle-page, and interaction-constrained applications

=C2=A0 =C2=A0 The group will define extension points for this protocol to a= llow for flexibility in areas including:

=C2=A0 =C2=A0 - Cryptographic agility for keys, message signatures, and pro= of of possession
=C2=A0 =C2=A0 - User interaction mechanisms including web and non-web metho= ds
=C2=A0 =C2=A0 - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions
=C2=A0 =C2=A0 - Mechanisms for presenting tokens to resource servers and bi= nding resource requests to tokens and associated cryptographic keys
=C2=A0 =C2=A0 - Optimized inclusion of additional information through the d= elegation process (including identity)

=C2=A0 =C2=A0 Additionally, the group will provide mechanisms for managemen= t of the protocol lifecycle including:

=C2=A0 =C2=A0 - Discovery of the authorization server
=C2=A0 =C2=A0 - Revocation of active tokens
=C2=A0 =C2=A0 - Query of token rights by resource servers

=C2=A0 =C2=A0 Although the artifacts for this work are not intended or expe= cted to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group= will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to th= e new protocol where possible.

=C2=A0 =C2=A0 This group is not chartered to develop extensions to OAuth 2.= 0, and as such will focus on new technological solutions not necessarily co= mpatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 wi= ll be developed in the OAuth Working Group, including functionality back-po= rted from the protocol developed here to OAuth 2.0.

=C2=A0 =C2=A0 The group is chartered to develop mechanisms for applying cry= ptographic methods, such as JOSE and COSE, to the delegation process. This = group is not chartered to develop new cryptographic methods.

=C2=A0 =C2=A0 The initial work will focus on using HTTP for communication b= etween the client and the authorization server, taking advantage of optimiz= ation features of HTTP2 and HTTP3 where possible, and will strive to enable= simple mapping to other protocols such as COAP when doing so does not conf= lict with the primary focus.

=C2=A0 =C2=A0 Milestones to include:
=C2=A0 =C2=A0 =C2=A0- Core delegation protocol
=C2=A0 =C2=A0 =C2=A0- Key presentation mechanism bindings to the core proto= col for TLS, detached HTTP signature, and embedded HTTP signatures
=C2=A0 =C2=A0 =C2=A0- Identity and authentication conveyance mechanisms
=C2=A0 =C2=A0 =C2=A0- Guidelines for use of protocol extension points





--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000132de005a1152d5f-- From nobody Wed Mar 18 10:55:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959333A1983 for ; Wed, 18 Mar 2020 10:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] 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 vYcTwhDDVebH for ; Wed, 18 Mar 2020 10:55:16 -0700 (PDT) Received: from mail.babelouest.org (perceval.babelouest.org [IPv6:2001:41d0:8:bc0f::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640D73A1976 for ; Wed, 18 Mar 2020 10:55:15 -0700 (PDT) Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-02-69-159-175-65.dsl.bell.ca [69.159.175.65]) by mail.babelouest.org (Postfix) with ESMTPSA id 01572203DD for ; Wed, 18 Mar 2020 13:55:10 -0400 (EDT) To: txauth@ietf.org References: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> From: Nicolas Mora Autocrypt: addr=nicolas@babelouest.org; keydata= mQINBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX7 6fs+F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU 7Qe1M2Dofmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mz O7dtMY6XQkpvqtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5 JNHsANmgsWCcheEL15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvy g7LL9GsrAaH51ksR1ksDH41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJe qRDF1HfjPFFm3dZ7E0dLR0aPvxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/i cho20wnEVJsVrbNld/0fMvxenrWSmuwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURi SbAyNmfoOII9GBTAFm13XkHWbBysppGQVAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOh o4GYW4d/smGlCbki/bYdSItbtk4rjHAyl+WYM6Jpy1sZXe7SDQARAQABtCVOaWNvbGFzIE1v cmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+iQI3BBMBCAAhBQJZiaq/AhsDBQsJCAcCBhUI CQoLAgQWAgMBAh4BAheAAAoJEP6CE5RAvSK5ZTkP/3PN+SPKLKOcgG/C3ZI9KxM93y4AKZ0z UCBtr2QJDt8viFKq3jPsSo6+Rw1UuY2oDx4wWUXqlsp3NKnvoKWMip6UVVH0XB48iLe4Tiu0 PVqIfHB/MIdE/QSYLFZzX0n4AgTlrho7Hd+S7TZMtf15FKF4/8y5lLVXK86cbZhaOEPcJyb9 taT4IVkU5M22aNfuZAUjexeCsn/em4pjEyREilht8Fo9tND9Nr/w2SOJNAKWZp+JlKR1ok3z sFvEN5rAEsdA9gvQ/5ubs8iXM0KfBHLa0wp/YWRLRrDFoCEqrkZdBetGxJn4G+wNdhb4TTsX HTfb/0Je179uF2jcFawr/DhJb/bKJUB236u2+0e53QufYq8brBqA4aONDCfOVAHVNjazruCK Wli2E2lHvJLVQeFkBP2Mo9IiWO8uNdXpK5QUjcipW5t6fxN1beNzJdZLiHVjjVKskVueoLDY tHt0TzPY75I6Bgy/oRz5e1sP6UjYsZs5+ZUFOw7Zii5kXcPDrhXb1sEd9ZvB4f9XdvxtE91h aUz9EW63XIvsUYsnjqdTznojBVeLVVnZJKp3RlWFw0o0xT90JuOkA5Pw8oL0GpBRA9vaPi1p hs2DCbCRe/U188HkNmhiH1C9dY+J/4h8IvicjIgTI0+27FPFxp6nMlkH4OgjUHZrbvE9E8Sr zonruQINBFmJqr8BEADrI5lstjLaS6IXxH37GWvfPLdjLyTFK5kJqyZkhGNMWHmwmRU3BVrz 0M0Tva/a3Z1B+fXJGzKevQhKMBsrpYhkbKkbMg7vreiWhZjQyy5nvbKA4aMhZ1ckmYWExOk2 QiUpTDoLDBN7VEZG+FV9Hw5ZVeH1k5LnbIxxxIGdzK1mxcCBgJodvzHsp1SZefVIKBKLH+y+ scAZDbnDfSUo/1pPgruogskpg67XrtDP/mZxgf7GB0wlrQrrJt9eBuCD5NXIjtl8KvEIPKTx AlYf/Gu8ZCuu0cwHLl/79WUH6wT35XByAsBMtuG8dHDidj50/XkpP2L6GE52KYTNoQVv5XoA IzpuwXDxcTML0JjE1EKAfRFeyuuiMncX9dgtRdJGMgN/4HYzIiSvWsjYkgVUFrh/ZlENbE6D hy4NLqDEBQb5RMIWrO7VVaAKosRysY72G3Z1FmS2m2dPAlNNLGHESlcLp3nwnNFFneQif4Kf 1ZdFMZJCy8D6n+TbuZmY8eMC624Ot5h18an0yBWFE8E/XU4yQR6savhhinY1Yc4EKjcNiP4c Trphh4cE7XgMitX+0yc1D9s7umuiBdqw9VAsyA20NfLZCMxieiGYcgda1WPA5V7jQc3m8G+C Jyg762Tb3XyPGBPy4TDfghpw1RqYf8wYAi8e74wKHck/uAP6R1lc7wARAQABiQIfBBgBCAAJ BQJZiaq/AhsMAAoJEP6CE5RAvSK5Y4AP/Rb0F2lmB6uDu66BhCYX7Z2hcnt4/LZK1hYb6fRO 3mnW8XClntYOGbKoAGAQDS3PrIx2EJkUr5FiWMpnneQPcwfNuL7VlSqlcFfwN+kkjTcsIjrw 3KMgGNbjjQ83jCUzidyQ4eg18AKKaxb0NrA8UNRTvtK0ozSThxnzLZ20nu/mU9NJhcMVx2Qz IEUiJK5ag3uXli/r52ILle5Wq9LPxjPEsl0oGlqNMGcCZLr20tHXm0XLrSVEenWKL8hjaEud PNdcKMLBWVsp0VIS/di1fsQgwhuJ9C+fwhtqaGsL5DsKDYhrUo1iKi4avX0f8IdzenQSKFso Jf+t+kHIm5/ZdZ8jMN081RznIvz8p8BxWOzbg+BZCCkOIsCxypmU9WgMMJ3hXgRa2OIhQZQ3 AnBc/U843uU/7HVRMhd4efzjNw/v1joDd4KEJEHnS/jT/s9jxEyikOtQW9otJBLgZpoEG+9R FCKPu4TV8RB9kZCHOM5lwSwq7CIwwVltF1pMRokm6X7lyclZ4iCEtfZAM6ZuvN/fh1GbIJxf t+hIWqDPiG9bPtoXZMArUi1zCaSmFdzba/15+P+B3EyaadYiSjVn9WBhe6syxZ8WYo0ehvJE e42BLGcGRcQl+l2Jt57D3FPDYYJEUkl72sGhhKbrg4YBVfCoWuchD0wXvR9ARXtLK5H4 Message-ID: Date: Wed, 18 Mar 2020 13:55:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <474128D8-74AC-463D-BC69-3138A71B7F8B@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 17:55:28 -0000 Hello Le 20-03-16 à 09 h 50, Yaron Sheffer a écrit : > > 1. Do you support the charter text provided at the end of this email? Or do you have major objections, blocking concerns or feedback (if so please elaborate)? > Yes > 2. Are you willing to author or participate in the development of the drafts of this WG? > Yes > 3. Are you willing to help review the drafts of this WG? > Yes > 4. Are you interested in implementing drafts of this WG? > Yes From nobody Wed Mar 18 12:44:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCE03A1AE7 for ; Wed, 18 Mar 2020 12:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 Yj27ZhbtUilc for ; Wed, 18 Mar 2020 12:44:16 -0700 (PDT) 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 5D7F63A1AE9 for ; Wed, 18 Mar 2020 12:44:16 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id z3so14791348edq.11 for ; Wed, 18 Mar 2020 12:44:16 -0700 (PDT) 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=ic6LhbbxDXOkOfWTOOJE4RAFFX/2K9tndP15FXP6bcc=; b=sPAhR4PWN10Wgsthbz+z8qgNG6KDuOMRv2X1XEWD9r10DHKmwKmgSJoi1O4RfMgpWO QsU1eaQWZV+K4+xoO+gbuDaR+UahVz7lweEsaNzbGzPetqym8oeneoYQrN42/9rhXtSC +uF0se6px5n3Wj6NQXV7hHth8xQjTrj8xA3UpZ/8o87jFKW863SuiL4FvEGjeTXezAFl 89aivkQ52z00c1MGof7ft27myHS4O78PVayjqzEk9lMr8JeaYveZLpC6RySg9AYksiFj IDZD+FmC0SJfazOGAh7L4LwbSgUFU737aV54qkoI6do69xNtBk5lYeej5Nl96mHaUpEs eaag== 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=ic6LhbbxDXOkOfWTOOJE4RAFFX/2K9tndP15FXP6bcc=; b=jxH8uxJXHGqeWxy+9eK7vDSrwh6UuPrsh1wLlEyanvvGo7irCHCqM1Bo3JkDSSm8RI GaKwl1UXyFQtu6dXr5YHCkuEkPKzgWRhNRltpYX6pBPAya20wNqcdnSV0mlSzRTWRTXv gabRdS1bI/c+DhB2icOyHAPMVrssNBPzLOM236KnoMJF8vlvPtBsYZbcIp9o6dy3Hrzq P7QdQNvM/rI+0+qfaLPx5jMzezxgn81wbT6PWKvj3W26GRAM3HtRJPx2bMVJdguNzPQh E49Mh/Awpzmlgag3KZWyybtvcrfZFwBUhPbeUIq5hgZVqkMy8CbFIwhMadvEZO/H9Rs+ 96Gw== X-Gm-Message-State: ANhLgQ1uucoGV8UQdjXDU2yTThJYkXOC1DoZU76GFW2Ap8mAooufdkKr HfLhrC7gQCKCvIrQOtHq1m3BDsp4LS/Rr155zXU= X-Google-Smtp-Source: ADFU+vsXfB+jYSLG6WS0b5efkkSLoEwYGomKQOM98axSQ3GVooblkIMpwU84vx6oZGVbesDDwdjHcjVWZaj2epOeIhg= X-Received: by 2002:a05:6402:10d8:: with SMTP id p24mr171962edu.82.1584560654893; Wed, 18 Mar 2020 12:44:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Wed, 18 Mar 2020 19:44:08 +0000 Message-ID: To: Dick Hardt Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000f5c55205a126467b" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 19:44:18 -0000 --000000000000f5c55205a126467b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, My thoughts on these different approaches are: 1. For XYZ, it feels a bit strange and unnecessary to require the client to have to state it's full set of capabilities to the AS. It feels like it should be the other way around - i.e. the client is able to probe what the AS supports. In my view it's more natural for the AS to be "advertising" its capabilities rather than the client. 2. I prefer the XYZ approach of having a single URL that the client knows it needs to interact to start the transaction, vs the more complex approach provided by XAuth. 3. Hopefully there is a middle ground between the two approaches that addresses the two points above. Many thanks, David Skaife On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote: > > *Discovery* > XYZ > - Client always starts at the tx endpoint, all other information is > dispatched from responses from the endpoint > - Clients sends capabilities list in transaction request, AS selects and > returns which capabilities are supported > > XYZ Rationale: client needs a single URL to start talking to an AS, givin= g > developers multiple ways to get information is confusing and can lead to > serious errors (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80= =99s discovery > approach) > > XAuth > - Client sends an OPTIONS call to the GS URI, Grant URI, or Authorizatio= n > URI > > XAuth Rationale: Client can make unauthenticated call to GS URI to learn > what GS supports, such as authentication mechanisms. Authenticated calls > return what a specific Client can do. > > > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f5c55205a126467b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

My thoughts on these different appr= oaches are:

1. For XYZ, it feels a bit strange and unnecessary to re= quire the client to have to state it's full set of capabilities to the = AS. It feels like it should be the other way around - i.e. the client is ab= le to probe what the AS supports. In my view it's more natural for the = AS to be "advertising" its capabilities rather than the client.
2. I prefer the XYZ approach of having a single URL that the client k= nows it needs to interact to start the transaction, vs the more complex app= roach=C2=A0provided by XAuth.

3. Hopefully there is a middle ground = between the two approaches that addresses the two points above.


= Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Har= dt <dick.hardt@gmail.com>= wrote:
Discovery

XYZ
=C2=A0- Client always starts at the= tx endpoint, all other information is dispatched from responses from the e= ndpoint
=C2=A0- Clients sends capabilities list in transaction request, = AS selects and returns which capabilities are supported

XYZ Rational= e: client needs a single URL to start talking to an AS, giving developers m= ultiple ways to get information is confusing and can lead to serious errors= (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s discovery app= roach)

XAuth
=C2=A0- Client sends an OPTIONS call to the GS URI, = Grant URI, or Authorization URI

XAuth Rationale: Client can make una= uthenticated call to GS URI to learn what GS supports, such as authenticati= on mechanisms. Authenticated calls return what a specific Client can do.

=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f5c55205a126467b-- From nobody Wed Mar 18 12:57:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A0A3A1BC6 for ; Wed, 18 Mar 2020 12:57:06 -0700 (PDT) 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_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=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 barEf8trWgAW for ; Wed, 18 Mar 2020 12:57:01 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 DBAAD3A1B6B for ; Wed, 18 Mar 2020 12:56:56 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id c145so40961823qke.12 for ; Wed, 18 Mar 2020 12:56:56 -0700 (PDT) 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=GrPutyjahC+G5Dan117MUtL2/a0naQxdmijyxmg1+Z0=; b=oPahKiqQ59vnbwb05VBH9io4yPJVWPpO//ExJJgpXYJYw2S6ueeUPd33VQxs6/pymA rvNW3fUOBSTYMTGyyNn6HUwNZ6S/YG/n9J7B3yshHbLoY1rSXiRMpbaABGBLfzKSr/E2 9ZXsVooF/YGafs1rxOGZj4bUD87ROaS5Y04O6o3KhYI2I+ROatcHfbIOQZfY+sQJVI3w boC1fr4AYvHMPzTtistO/rm1FbBo6LJZxMVm6Mpruq/4+ffNsdOD9Gmyqez0pjHkGkwJ m5NWZEeax4vVWmPGkIpkI1r/2OKQsU4358RsU7cWfjVUZPFvFSrJTmRAXSqheLwk7bH8 6CaQ== 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=GrPutyjahC+G5Dan117MUtL2/a0naQxdmijyxmg1+Z0=; b=FtM9ZCCfypuSZX48euvGCLfpUjEKj/46erqx1pjdUWbfQtjq0clAkKDsIXgNKMAnJj DC5HNTNqmpvWT+BK2QHrha7QnhZE3tWbsLSbfqnjNgOJGJfyKw37zFHJeUgeg09CUf+n 3oczBDabeytGYk/t8ZWUNy1cFTgE0AOTSS8wY5+1RKP0ILzjODl7xjTb0CX/wVfHZzMs WbUWg00oe96qDQw55ufxvdBykoA0XuXU425FB3LcU6HcKcWNv67N9Gis2SYgq2737gue aWGRaY7OMEXd57TgoKEqSLz+XW78gLP9Gpkvn6dQLruQ5UxIzxWbolcZs/31qGttgVKe fuFg== X-Gm-Message-State: ANhLgQ1rP6XZXBILwP9vo68+gQeemuqlv9HfmqLVyIh/p/yHUMcYXzi+ dxQWMqusKtdkEVqM0LNCBwYTI+4+UoM6S1zvmFUnDBix4/Y= X-Google-Smtp-Source: ADFU+vu1OkAb7W6bg9/acrBg7CMlvmIiqNo3NCtDB2JeXiVlGKCXWbTV5z6qNG2xo7srP1iV69OEKh0goVUqUIoN7Tk= X-Received: by 2002:a25:3a84:: with SMTP id h126mr8799653yba.288.1584561410430; Wed, 18 Mar 2020 12:56:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Stephen Moore Date: Wed, 18 Mar 2020 15:56:36 -0400 Message-ID: To: David Skaife Cc: Dick Hardt , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000fe5b2005a1267312" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 19:57:15 -0000 --000000000000fe5b2005a1267312 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For your thought #1, it seems that it is just who does the filtering. Since I'm looking at this for running on small devices potentially, anything I don't have to process myself is better and I don't mind the AS doing that set math for my client. I think whoever is going to have the larger set (Which I would think would be the AS) should have to do the filtering in my mind because whoever that is will probably be the bigger processor/memory. Furthermore, it does reduce the network traffic since the client doesn't have to probe for that information first. I realize I have a slightly biased viewpoint though. I very much agree on point 2 though. Only having a single URL will simplify configuration and setup. On Wed, Mar 18, 2020 at 3:44 PM David Skaife < blue.ringed.octopus.guy@gmail.com> wrote: > Hi, > > My thoughts on these different approaches are: > > 1. For XYZ, it feels a bit strange and unnecessary to require the client > to have to state it's full set of capabilities to the AS. It feels like i= t > should be the other way around - i.e. the client is able to probe what th= e > AS supports. In my view it's more natural for the AS to be "advertising" > its capabilities rather than the client. > > 2. I prefer the XYZ approach of having a single URL that the client knows > it needs to interact to start the transaction, vs the more complex > approach provided by XAuth. > > 3. Hopefully there is a middle ground between the two approaches that > addresses the two points above. > > > Many thanks, > David Skaife > > On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote: > >> >> *Discovery* >> XYZ >> - Client always starts at the tx endpoint, all other information is >> dispatched from responses from the endpoint >> - Clients sends capabilities list in transaction request, AS selects an= d >> returns which capabilities are supported >> >> XYZ Rationale: client needs a single URL to start talking to an AS, >> giving developers multiple ways to get information is confusing and can >> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OID= C=E2=80=99s >> discovery approach) >> >> XAuth >> - Client sends an OPTIONS call to the GS URI, Grant URI, or >> Authorization URI >> >> XAuth Rationale: Client can make unauthenticated call to GS URI to learn >> what GS supports, such as authentication mechanisms. Authenticated calls >> return what a specific Client can do. >> >> >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fe5b2005a1267312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For your thought #1, it seems that it is just who does the= filtering. Since I'm looking at this for running on small devices pote= ntially, anything I don't have to process myself is better and I don= 9;t mind the AS doing that set math for my client. I think whoever is going= to have the larger set (Which I would think would be the AS) should have t= o do the filtering in my mind because whoever that is will probably be the = bigger processor/memory.=C2=A0

Furthermore, it does redu= ce the network traffic since the client doesn't have to probe for that = information first.

I realize I have a slightly biase= d viewpoint though.

I very much agree on point= 2 though. Only having a single URL will simplify configuration and setup.<= /div>

On Wed, Mar 18, 2020 at 3:44 PM David Skaife <blue.ringed.octopus.guy@gmail.com= > wrote:
Hi,

My thoughts on these different approach= es are:

1. For XYZ, it feels a bit strange and unnecessary to requir= e the client to have to state it's full set of capabilities to the AS. = It feels like it should be the other way around - i.e. the client is able t= o probe what the AS supports. In my view it's more natural for the AS t= o be "advertising" its capabilities rather than the client.
2. I prefer the XYZ approach of having a single URL that the client knows= it needs to interact to start the transaction, vs the more complex approac= h=C2=A0provided by XAuth.

3. Hopefully there is a middle ground betw= een the two approaches that addresses the two points above.


Many= thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt &= lt;dick.hardt@gma= il.com> wrote:
Discovery

XYZ
=C2=A0- Client always= starts at the tx endpoint, all other information is dispatched from respon= ses from the endpoint
=C2=A0- Clients sends capabilities list in transac= tion request, AS selects and returns which capabilities are supported
XYZ Rationale: client needs a single URL to start talking to an AS, givin= g developers multiple ways to get information is confusing and can lead to = serious errors (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s= discovery approach)

XAuth
=C2=A0- Client sends an OPTIONS call t= o the GS URI, Grant URI, or Authorization URI

XAuth Rationale: Clien= t can make unauthenticated call to GS URI to learn what GS supports, such a= s authentication mechanisms. Authenticated calls return what a specific Cli= ent can do.


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000fe5b2005a1267312-- From nobody Wed Mar 18 13:08:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C93A1940 for ; Wed, 18 Mar 2020 13:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=hardjono.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 NHMXsu-6LD4p for ; Wed, 18 Mar 2020 13:08:41 -0700 (PDT) Received: from gateway21.websitewelcome.com (gateway21.websitewelcome.com [192.185.46.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3663A164F for ; Wed, 18 Mar 2020 13:08:41 -0700 (PDT) Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway21.websitewelcome.com (Postfix) with ESMTP id D6470400E5760 for ; Wed, 18 Mar 2020 15:08:40 -0500 (CDT) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id EezYjhVjdEfyqEezYjhpNE; Wed, 18 Mar 2020 15:08:40 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-transfer-encoding:Content-type: Mime-version:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=33rvV1tgX83l0ndmbqkGfuGBKxQAGIqBcLqaxrF+7fA=; b=KU7cXKNL8bjVhTOglEekC8fsFB RcI0mD99KwaKy2UNZat05t2IqMk2ZTSgVD8KAvZMcIcPuqy2FIUoLsM9B5NoqGXSqGaoD+OW7tjmk jLyW69f9IuyBahE0aajC35FNM; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:60993 helo=[10.0.0.194]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1jEezY-000inX-Eh; Wed, 18 Mar 2020 14:08:40 -0600 User-Agent: Microsoft-MacOutlook/10.10.14.200307 Date: Wed, 18 Mar 2020 16:08:37 -0400 From: Thomas Hardjono To: Yaron Sheffer , "txauth@ietf.org" Message-ID: <5351DBFC-F5A8-47E8-A77E-02D5EFEAE4D5@hardjono.net> Thread-Topic: [Txauth] Reminder: Call for charter consensus - TxAuth WG Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5207.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hardjono.net X-BWhitelist: no X-Source-IP: 73.167.220.69 X-Source-L: No X-Exim-ID: 1jEezY-000inX-Eh X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-167-220-69.hsd1.ma.comcast.net ([10.0.0.194]) [73.167.220.69]:60993 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 1 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] Reminder: Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:08:43 -0000 >>> 1. Do you support the charter text provided at the end of this email? = Or do you have major objections, blocking concerns or feedback (if so pleas= e elaborate)? Yes. =20 >>> 2. Are you willing to author or participate in the development of the = drafts of this WG? Yes. =20 >>> 3. Are you willing to help review the drafts of this WG? Yes. =20 >>> 4. Are you interested in implementing drafts of this WG? Yes (depending how mature the specs become). -- thomas -- =EF=BB=BF-----Original Message----- From: Txauth on behalf of Yaron Sheffer Date: Monday, March 16, 2020 at 9:50 AM To: "txauth@ietf.org" Subject: [Txauth] Reminder: Call for charter consensus - TxAuth WG Here's a quick reminder: if you haven't responded to the call yet, please d= o so soon. Thanks, Yaron =EF=BB=BFOn 3/6/20, 18:44, "Yaron Sheffer" wrote: Hi Everyone, =20 It appears that momentum is forming around the proposed formation of a = TxAuth working group. We=E2=80=99d like to more formally gauge interest in procee= ding with this work. Please do so by responding to the following questions: =20 1. Do you support the charter text provided at the end of this email? = Or do you have major objections, blocking concerns or feedback (if so pleas= e elaborate)? =20 2. Are you willing to author or participate in the development of the = drafts of this WG? =20 3. Are you willing to help review the drafts of this WG? =20 4. Are you interested in implementing drafts of this WG? =20 The call will run for two weeks, until March 21. If you think that the = charter should be amended In a significant way, please reply on a separate t= hread. =20 The feedback provided here will help the IESG come to a decision on the= formation of a new WG. Given the constraints of the chartering process, reg= ardless of the outcome of this consensus call, we will be meeting in Vancouv= er as a BoF. =20 Thanks, Yaron and Dick =20 --- Charter Text Follows --- =20 This group is chartered to develop a fine-grained delegation protocol f= or authorization, identity, and API access. This protocol will allow an auth= orizing party to delegate access to client software through an authorization= server. It will expand upon the uses cases currently supported by OAuth 2.0= and OpenID Connect (itself an extension of OAuth 2.0) to support authorizat= ions scoped as narrowly as a single transaction, provide a clear framework f= or interaction among all parties involved in the protocol flow, and remove u= nnecessary dependence on a browser or user-agent for coordinating interactio= ns.=20 =20 The delegation process will be acted upon by multiple parties in the pr= otocol, each performing a specific role. The protocol will decouple the inte= raction channels, such as the end user=E2=80=99s browser, from the delegation chan= nel, which happens directly between the client and the authorization server = (in contrast with OAuth 2.0 which is initiated by the client redirecting the= user=E2=80=99s browser). The client and AS will involve a user to make an authori= zation decision as necessary through interaction mechanisms indicated by the= protocol. This decoupling avoids many of the security concerns and technica= l challenges of OAuth 2.0 and provides a non-invasive path for supporting fu= ture types of clients and interaction channels. =20 Additionally, the delegation process will allow for: =20 - Fine-grained specification of access - Approval of AS attestation to identity claims - Approval of access to multiple resources and APIs in a single interac= tion - Separation between the party authorizing access and the party operati= ng the client requesting access - A variety of client applications, including Web, mobile, single-page,= and interaction-constrained applications =20 The group will define extension points for this protocol to allow for f= lexibility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of poss= ession=20 - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other piec= es of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding reso= urce requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation = process (including identity) =20 Additionally, the group will provide mechanisms for management of the p= rotocol lifecycle including: =20 - Discovery of the authorization server - Revocation of active tokens - Query of token rights by resource servers =20 Although the artifacts for this work are not intended or expected to be= backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attem= pt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc= ol where possible. =20 This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily compatible wi= th OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develo= ped in the OAuth Working Group, including functionality back-ported from the= protocol developed here to OAuth 2.0. =20 The group is chartered to develop mechanisms for applying cryptographic= methods, such as JOSE and COSE, to the delegation process. This group is no= t chartered to develop new cryptographic methods.=20 =20 The initial work will focus on using HTTP for communication between the= client and the authorization server, taking advantage of optimization featu= res of HTTP2 and HTTP3 where possible, and will strive to enable simple mapp= ing to other protocols such as COAP when doing so does not conflict with the= primary focus. =20 Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol for TLS, de= tached HTTP signature, and embedded HTTP signatures - Identity and authentication conveyance mechanisms - Guidelines for use of protocol extension points =20 =20 =20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Wed Mar 18 13:22:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED20F3A0CF0 for ; Wed, 18 Mar 2020 13:22:30 -0700 (PDT) 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, 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 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 dwuJdXypjyYe for ; Wed, 18 Mar 2020 13:22:29 -0700 (PDT) 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 E97CF3A0C56 for ; Wed, 18 Mar 2020 13:22:28 -0700 (PDT) Received: from [192.168.1.5] (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 02IKMQl4008816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 16:22:26 -0400 From: Justin Richer Message-Id: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_CF71C101-4319-4635-8D13-47991A84E2BE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Mar 2020 16:22:25 -0400 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org To: David Skaife References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:22:31 -0000 --Apple-Mail=_CF71C101-4319-4635-8D13-47991A84E2BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OAuth 2 has taught us that wherever possible, you should push the = complexity to the server, not the client. That=E2=80=99s the idea behind = the kind of publication/negotiation here where the client can do = something simple and the AS needs to make the actual comparison and = decision, whatever that is. Clients need to stay simple because, for the = most part, the focus of the client is on calling whatever API and = implementing whatever functionality it is doing, not on the security = layer. The AS is a dedicated security component, so it=E2=80=99s got the = mandate to figure this stuff out. This mindset is one of OAuth 2=E2=80=99s= biggest strengths.=20 So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t = really :used: this feature beyond making sure the protocol can be passed = back and forth, since there=E2=80=99s not a lot of optionality that = really needs to be negotiated here. So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D, = and X. If the client doesn=E2=80=99t know anything at all about the AS, = the client sends: [A, B, C] And the server looks at that, compares with what it can do, and returns: [B] The server doesn=E2=80=99t send D, or X, because the client wouldn=E2=80=99= t have any clue what to do about that. The client can remember that if = it wants to cache that part of the response. So the question is, what if the client knew that only B would be = successful for this server? That=E2=80=99s pretty common because a lot = of clients get written and configured with a static set of capabilities = for a server. And with the negotiation above, the client just needs to = remember after the first call. So in both cases, the client would only = send [B], or leave it off entirely because it doesn=E2=80=99t need to = negotiate, and you=E2=80=99re done.=20 But the thing is, you could do both styles with one simple twist. If you = want to do the discovery portion in a pre-flight request, I think it=E2=80= =99s a good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t = make any sense to me to allow it on any other endpoints, especially = because some of those are going to be user-facing (so the client is not = going to be talking to the URL itself). The client makes this call and = gets back: [B, D, X] And now the client has to put together its possible capabilities from = that list and what it knows it can do. By putting OPTIONS on the = endpoint then we can stick with the same mantra of the client having one = piece of info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80= =94 and learning everything else from that. I think that part is simple = enough to potentially work, and XYZ doesn=E2=80=99t have other endpoints = or aspects that need to be discovered out of band, unlike OAuth 2. =E2=80=94 Justin > On Mar 18, 2020, at 3:44 PM, David Skaife = wrote: >=20 > Hi, >=20 > My thoughts on these different approaches are: >=20 > 1. For XYZ, it feels a bit strange and unnecessary to require the = client to have to state it's full set of capabilities to the AS. It = feels like it should be the other way around - i.e. the client is able = to probe what the AS supports. In my view it's more natural for the AS = to be "advertising" its capabilities rather than the client. >=20 > 2. I prefer the XYZ approach of having a single URL that the client = knows it needs to interact to start the transaction, vs the more complex = approach provided by XAuth. >=20 > 3. Hopefully there is a middle ground between the two approaches that = addresses the two points above. >=20 >=20 > Many thanks, > David Skaife >=20 > On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt > wrote: > Discovery >=20 > XYZ > - Client always starts at the tx endpoint, all other information is = dispatched from responses from the endpoint > - Clients sends capabilities list in transaction request, AS selects = and returns which capabilities are supported >=20 > XYZ Rationale: client needs a single URL to start talking to an AS, = giving developers multiple ways to get information is confusing and can = lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by = OIDC=E2=80=99s discovery approach) >=20 > XAuth > - Client sends an OPTIONS call to the GS URI, Grant URI, or = Authorization URI >=20 > XAuth Rationale: Client can make unauthenticated call to GS URI to = learn what GS supports, such as authentication mechanisms. Authenticated = calls return what a specific Client can do. >=20 >=20 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_CF71C101-4319-4635-8D13-47991A84E2BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OAuth= 2 has taught us that wherever possible, you should push the complexity = to the server, not the client. That=E2=80=99s the idea behind the kind = of publication/negotiation here where the client can do something simple = and the AS needs to make the actual comparison and decision, whatever = that is. Clients need to stay simple because, for the most part, the = focus of the client is on calling whatever API and implementing whatever = functionality it is doing, not on the security layer. The AS is a = dedicated security component, so it=E2=80=99s got the mandate to figure = this stuff out. This mindset is one of OAuth 2=E2=80=99s biggest = strengths. 

So = how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t = really :used: this feature beyond making sure the protocol can be passed = back and forth, since there=E2=80=99s not a lot of optionality that = really needs to be negotiated here.

So let=E2=80=99s say the client can do = A, B, and C. The AS can do B, D, and X. If the client doesn=E2=80=99t = know anything at all about the AS, the client sends:

[A, B, C]

And the server looks at = that, compares with what it can do, and returns:

[B]

The server doesn=E2=80=99t send D, or = X, because the client wouldn=E2=80=99t have any clue what to do about = that. The client can remember that if it wants to cache that part of the = response.

So = the question is, what if the client knew that only B would be successful = for this server? That=E2=80=99s pretty common because a lot of clients = get written and configured with a static set of capabilities for a = server. And with the negotiation above, the client just needs to = remember after the first call. So in both cases, the client would only = send [B], or leave it off entirely because it doesn=E2=80=99t need to = negotiate, and you=E2=80=99re done. 

But the thing is, you could do both = styles with one simple twist. If you want to do the discovery portion in = a pre-flight request, I think it=E2=80=99s a good idea to allow OPTIONS = on the tx endpoint. It doesn=E2=80=99t make any sense to me to allow it = on any other endpoints, especially because some of those are going to be = user-facing (so the client is not going to be talking to the URL = itself). The client makes this call and gets back:

[B, D, X]

And now the client has = to put together its possible capabilities from that list and what it = knows it can do. By putting OPTIONS on the endpoint then we can stick = with the same mantra of the client having one piece of info to get = started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and learning = everything else from that. I think that part is simple enough to = potentially work, and XYZ doesn=E2=80=99t have other endpoints or = aspects that need to be discovered out of band, unlike OAuth = 2.

 =E2=80=94= Justin



On Mar 18, 2020, at 3:44 PM, David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoughts on these different = approaches are:

1. For XYZ, it feels a bit = strange and unnecessary to require the client to have to state it's full = set of capabilities to the AS. It feels like it should be the other way = around - i.e. the client is able to probe what the AS supports. In my = view it's more natural for the AS to be "advertising" its capabilities = rather than the client.

2. I prefer the XYZ = approach of having a single URL that the client knows it needs to = interact to start the transaction, vs the more complex = approach provided by XAuth.

3. = Hopefully there is a middle ground between the two approaches that = addresses the two points above.


Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery

XYZ
 - Client always starts at the tx endpoint, all other = information is dispatched from responses from the endpoint
 - Clients sends capabilities list in transaction = request, AS selects and returns which capabilities are supported

XYZ Rationale: client needs a single URL to = start talking to an AS, giving developers multiple ways to get = information is confusing and can lead to serious errors (see OAuth2=E2=80=99= s mix-up attack caused by OIDC=E2=80=99s discovery approach)

XAuth
 - Client sends an = OPTIONS call to the GS URI, Grant URI, or Authorization URI

XAuth Rationale: Client can make = unauthenticated call to GS URI to learn what GS supports, such as = authentication mechanisms. Authenticated calls return what a specific = Client can do.


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_CF71C101-4319-4635-8D13-47991A84E2BE-- From nobody Wed Mar 18 13:27:50 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D323A1B96 for ; Wed, 18 Mar 2020 13:27:47 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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 WmqtSPfS2RXt for ; Wed, 18 Mar 2020 13:27:39 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650129.outbound.protection.outlook.com [40.107.65.129]) (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 448893A1B97 for ; Wed, 18 Mar 2020 13:27:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UYCmFCb/APb+WYrKF49bqp31dqxJQG59Xt5NGd1oIDbVC0IfhGJ5kLPLBytVLWp4oje4zPo90OLF8NXlcjpDLGGDVs932LFVj7wIM8GLM+D6boNYKLKdpIC2qRKIjLfxhhY/QAAwuGZx48+oIoYsfOX3hbW2CamXX81nATwvAL6oy3VGYKRkGeipfljIj9/pBlbL8oGmbJRcC7qHTKmkQNAtXq3PrbXZFTcWZ9sF4semdr1eA8/ilde9yP6eLcaR/IblsNJyYOlL8so5IH9tnwi9mzxWe7DM82LYh1BmCCmTkucKrwh3byKiaqFpkRdmMQlA4XlvTrm2kjY/LV9RYQ== 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=9oubTnb5H68dn3XhPMKFsZmQ7jJ5gz48Yc4Yey3HDJY=; b=DHHPCIQSNe4ID7J7ZXbyxecsVcxBewFfD4KqVbRELFxGE0e7PVSNEeCXykZxcVx6KiGBPb/0ZeyCYFPvPDYPYZGZWkMWNtdDjz1L8GsxSETkh2knHlVuB+YBRNiTe1EHVUNMC4Mh+agwvKyuVH1O1+8n57U4I72vBxtdr8z+3D0jWKsZCDA+QaC/cDS/KW+yGPBUitOtKWkpQDSiSwmNd8lRq1uHq/8DcZsdqyTacDLVx7uR7h7D4hMasM6CsCfQRUNHiMO6n0sAt6AO+Y9DZcv1309oN/CSgvwXigw9HLoTnntvm6HlPbA7uyz2SfDAQNweUiQmiS4IbvQr9BI/GA== 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=9oubTnb5H68dn3XhPMKFsZmQ7jJ5gz48Yc4Yey3HDJY=; b=Sgd3rAWl1jlzkJXrX2z6Vo8FBx8XTVP/zPVhbqQu1ijRTizE+KafhOricXtfhcvKwBxLTe+8qpmL1sh44FcYJYptRHiew3lLtC7y+OQj0gZDop8SSCNhypEAIxZPlPVhCVzwdIqsr32jFUw19EgOJqk9F5D25t18v0ob2GLceOw= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0737.namprd00.prod.outlook.com (2603:10b6:208:1c1::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2876.0; Wed, 18 Mar 2020 20:27:37 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::3489:6260:95d1:9d3f]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::3489:6260:95d1:9d3f%2]) with mapi id 15.20.2875.000; Wed, 18 Mar 2020 20:27:36 +0000 From: Mike Jones To: Justin Richer , Aaron Parecki CC: Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AdX9Y6GW+kzpYcYiQ6+5iQxhiAzSHA== Date: Wed, 18 Mar 2020 20:27:36 +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_ActionId=f8201b47-79ec-44ef-9862-00002c0b973c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-18T20:01:00Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.81.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8b2e509b-3c84-4462-586e-08d7cb7acc43 x-ms-traffictypediagnostic: BL0PR00MB0737: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(199004)(966005)(10290500003)(186003)(66574012)(498600001)(9686003)(2906002)(33656002)(4326008)(71200400001)(26005)(7696005)(7066003)(30864003)(110136005)(81156014)(81166006)(21615005)(8676002)(54906003)(8936002)(6506007)(66946007)(66476007)(53546011)(66556008)(76116006)(5660300002)(8990500004)(64756008)(66446008)(55016002)(86362001)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0737; H:MN2PR00MB0688.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H9/Y7KxmqyRs7qjhJoGJRgVQWN+Rfitz0uvY4ifWCOJFx4rbDOw4GMpcWqOaYEL5o1uuzXkCGCSvlP3WPEJ1XwrP1XyBgW/HYceYGglkYEosJ/jHnHUpXCcEF9w8jNJ2jIjwGr+4h8dwSPXDjnouUbKz84tw7Kxa+CeMdCx55o1yXYcKnqD7OkN90K2OlK8FGu9gHyXyF/ElKnm6BUy7V2RuPWwP5AwB2OssoBaMePDp37mMZakdK1wLEP0PkyQaykavUSjeuuFfMFMwh8bZQ8IWFdFkuV1TOKvQqX5p5i/DiqzlsAdAamlYVXnhRNrfRB/zTXeeDQH86Oy5JpGMd2/H/dZpxN4q6F1YJI8muwCVD1OD4HdZR8gWC4BYyY50uvk2aNl3bPS7MvvivJ9COmGn7oxBLHmU/0fxCLNvw8VaXAsWFXnvPmh8ZNNvEEg9/xMaKKT8IdMAUNfie/SXUo9r9K0IxLq9iV5/Ts2/qMSRVPb0N1aYua9riKPGuUpqH472kH2sdEzxmdBVLpgoqQ== x-ms-exchange-antispam-messagedata: QL1T3b40pk6JaQuFtGXkipGPPR8oV/+sVhdRW1ho9ehu4Fa5oC2oFcYVQfPU7u7EwAfFt5UulGE3ALruQzJK0/h/mQEWhMXX9C0sYUZw/p+VQpA0gzgBvPctFWENmC7QNGSDQVYHw7BZoyIpSgBB8A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688E4B36EB514D68C0F79EEF5F70MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b2e509b-3c84-4462-586e-08d7cb7acc43 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 20:27:36.8453 (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: J8UPiccxcwlLelOYMNw/YqKMfbx2REcK5JTGtXuMinaux5UvjgWqScZ6Hk379m8/b1qg2GabhjBYscS978NOxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0737 Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:27:48 -0000 --_000_MN2PR00MB0688E4B36EB514D68C0F79EEF5F70MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHV0dGluZyBhIGxpdHRsZSBtb3JlIG1lYXQgb24gdGhlICJpZGVudGl0eSBpcyBhIGh1Z2UgdG9w aWMiIGNvbW1lbnQsIGxldCBtZSBtYWtlIGEgZmV3IG9ic2VydmF0aW9ucyBhYm91dCBPcGVuSUQg Q29ubmVjdCBhbmQgT0F1dGggMi4wLiAgTW9zdCBvZiBPcGVuSUQgQ29ubmVjdCBDb3JlPGh0dHBz Oi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFfMC5odG1sPiBjcmVhdGVz IG5ldyBpZGVudGl0eS1zcGVjaWZpYyBmdW5jdGlvbmFsaXR5IHN1Y2ggYXMgSUQgVG9rZW5zLCB0 aGUgVXNlckluZm8gRW5kcG9pbnQsIENsYWltcyAoaW5jbHVkaW5nIGFnZ3JlZ2F0ZWQgYW5kIGRp c3RyaWJ1dGVkIGNsYWltcyksIGF1dGhlbnRpY2F0ZWQgc2Vzc2lvbnMsIGlzc3VlcnMsIGtleSBt YW5hZ2VtZW50IGFuZCBrZXkgcm9sbG92ZXIsIHNlbGYtaXNzdWVkIGlkZW50aXR5IHByb3ZpZGVy cywgZXRjLiAgWWVzLCBTZWN0aW9uIDMgKEF1dGhlbnRpY2F0aW9uKTxodHRwczovL29wZW5pZC5u ZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRtbCNBdXRoZW50aWNhdGlvbj4gZGVz Y3JpYmVzIGhvdyB0byB0dXJuIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpbnRvIGFuIGF1dGhl bnRpY2F0aW9uIHJlcXVlc3Qg4oCTIHdoaWNoIGlzIHRoZSBjb3JlIG9mIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiBPcGVuSUQgQ29ubmVjdCBhbmQgT0F1dGggMi4wIOKAkyBhbmQgU2VjdGlvbiA5 IChDbGllbnQgQXV0aGVudGljYXRpb24pPGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt Y29ubmVjdC1jb3JlLTFfMC5odG1sI0NsaWVudEF1dGhlbnRpY2F0aW9uPiAgaXMgYWxzbyBhYm91 dCB0aGUgT0F1dGgvQ29ubmVjdCBpbnRlcmZhY2UuICBCdXQgbW9zdCBvZiBpdCBpcyBub3QgYWJv dXQgT0F1dGggb3IgYXV0aG9yaXphdGlvbi4NCg0KDQoNClRoYXTigJlzIGV2ZW4gbW9yZSB0cnVl IHdoZW4geW91IGNvbnNpZGVyIHRoYXQgb3RoZXIgT3BlbklEIENvbm5lY3Qgc3BlY3MgYXJlIGlt cG9ydGFudCBpbiBtYW55IGRlcGxveW1lbnRzLCBzdWNoIGFzIERpc2NvdmVyeTxodHRwOi8vb3Bl bmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWw+LCBGcm9udC1D aGFubmVsIExvZ291dDxodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZnJv bnRjaGFubmVsLTFfMC5odG1sPiwgSWRlbnRpdHkgQXNzdXJhbmNlPGh0dHBzOi8vb3BlbmlkLm5l dC9zcGVjcy9vcGVuaWQtY29ubmVjdC00LWlkZW50aXR5LWFzc3VyYW5jZS0xXzAuaHRtbD4sIGV0 Yy4gIFRoZXJl4oCZcyBhIGxvdCBtb3JlIHRvIGlkZW50aXR5IHRoYW4ganVzdCBsb2dnaW5nIGlu IGFuZCByZXR1cm5pbmcgY2xhaW1zIGFib3V0IHRoZSBlbmQtdXNlci4NCg0KDQoNClRoZXJlZm9y ZSwgaWYgaWRlbnRpdHkgaXMgaW4gc2NvcGUgYXQgYWxsLCBJIGFncmVlIHRoYXQgaXQgc2hvdWxk IGJlIGEgbmFycm93LCB3ZWxsLWRlZmluZWQgc2xpY2Ug4oCTIGZvciBpbnN0YW5jZSBtYXliZSBh IG1lY2hhbmlzbSBkZWZpbmluZyB3aGF0IHN5bnRheCB5b3UgdXNlIHRvIGluZGljYXRlIHRoYXQg YSBUeEF1dGggYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIGFsc28gYW4gYXV0aGVudGljYXRpb24g KGxvZ2luKSByZXF1ZXN0IOKAkyB3aGljaCBpcyB3aGF0IHRoZSDigJxvcGVuaWTigJ0gc2NvcGUg ZG9lcy4gIEJ1dCBpZGVudGl0eSBpcyBodWdlIHRvcGljLiAgSSBiZWxpZXZlIHRoYXQgd2Ugc2hv dWxkIGVuYWJsZSBhcyBtdWNoIHJldXNlIG9mIGV4aXN0aW5nIGlkZW50aXR5IG1lY2hhbmlzbXMg YXMgcG9zc2libGUsIHdoaWxlIHN0aWxsIHJld29ya2luZyB0aGUgcHJvdG9jb2wgZmxvd3MuICBU aGluZ3MgbGlrZSBzZXNzaW9uIG1hbmFnZW1lbnQgKGluY2x1ZGluZyBzZXNzaW9uIHJlbmV3YWwg YW5kIGxvZ291dCksIGlkZW50aXR5IGFzc3VyYW5jZSwgYW5kIGNsYWltcyBhYm91dCB0aGUgZW5k LXVzZXIgYW5kIGFib3V0IHRoZSBhdXRoZW50aWNhdGlvbiBwZXJmb3JtZWQgc2hvdWxkIGJlIGV4 cGxpY2l0bHkgb3V0IG9mIHNjb3BlLCB0byBrZWVwIHVzIGZyb20gdHJ5aW5nIHRvIHJlaW52ZW50 IGFsbCB0aGUgd2hlZWxzLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpTZW50OiBUdWVz ZGF5LCBNYXJjaCAxNywgMjAyMCAzOjQ3IFBNDQpUbzogQWFyb24gUGFyZWNraSA8YWFyb25AcGFy ZWNraS5jb20+DQpDYzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsg WWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPjsgVG9yc3RlbiBMb2RkZXJzdGVk dCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbVHhhdXRoXSBDYWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAtIFR4QXV0aCBXRw0KDQoNCg0K KzENCg0KDQoNClRoYW5rcywgQWFyb24uIEkgdGhpbmsgaXQgcmVhbGx5IGlzIGEgdmVyeSBuYXJy b3cgc2xpY2Ugb2YgaWRlbnRpdHkgdGhhdCB3ZSB3YW50IHRvIGNvdmVyIGhlcmUsIGFuZCBJ4oCZ ZCBiZSBoYXBweSB0byBnZXQgbW9yZSBwcmVjaXNlIGxhbmd1YWdlIGludG8gdGhlIHByb3Bvc2Vk IGNoYXJ0ZXIgYmVmb3JlIG1vdmluZyBmb3J3YXJkLg0KDQoNCg0K4oCUIEp1c3Rpbg0KDQoNCg0K PiBPbiBNYXIgMTcsIDIwMjAsIGF0IDY6MzEgUE0sIEFhcm9uIFBhcmVja2kgPGFhcm9uQHBhcmVj a2kuY29tPG1haWx0bzphYXJvbkBwYXJlY2tpLmNvbT4+IHdyb3RlOg0KDQo+DQoNCj4gTXVjaCBv ZiB0aGUgY29uZnVzaW9uIGluIHRoZSBtYXJrZXRwbGFjZSBhcm91bmQgT0F1dGggYW5kIE9wZW5J RA0KDQo+IENvbm5lY3Qgc3RlbXMgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIHNlcGFyYXRl IHNwZWNzIGRldmVsb3BlZCBpbg0KDQo+IHNlcGFyYXRlIG9yZ2FuaXphdGlvbnMsIHdoZW4gcmVh bGx5IHRoZXkgYXJlIHR3byBwYXJ0cyB0byB0aGUgc2FtZQ0KDQo+IHBpY3R1cmUuIEkgYW0gc3Ry b25nbHkgYWdhaW5zdCBleGNsdWRpbmcgaWRlbnRpdHkgZnJvbSB0aGUgY2hhcnRlciBvZg0KDQo+ IFR4QXV0aCwgYXMgSSB0aGluayB0aGlzIGlzIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIGJyaW5n IHRoZSB0d28NCg0KPiBhc3BlY3RzIHRvZ2V0aGVyLg0KDQo+DQoNCj4gVGhlIGNvbmNlcm4gZXhw cmVzc2VkIGJ5IEtpbQ0KDQo+IChodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3R4YXV0aC91TDkyT19WazVtMzhEY2FjWFNuc2hYMkMNCg0KPiBhaEUpIGFyb3VuZCBPcGVuSUQg Q29ubmVjdCBjb3VsZCBhbHNvIGJlIHNhaWQgYWJvdXQgT0F1dGgsIG5hbWVseSB0aGF0DQoNCj4g dGhlcmUgd2lsbCBiZSBzb21lIGFtb3VudCBvZiBjb25mdXNpb24gYXJvdW5kIHRoZSBmYWN0IHRo YXQgdGhpcyBzcGVjDQoNCj4gd2lsbCBjb3ZlciBtYW55IG9mIHRoZSBzYW1lIHVzZSBjYXNlcyBh cyBPQXV0aC4gSSB0aGluayB0aGF0J3MgZmluZSwNCg0KPiB0aGF0J3MganVzdCBob3cgd2UgbW92 ZSBmb3J3YXJkIGFuZCBtYWtlIHByb2dyZXNzLg0KDQo+DQoNCj4gVGhlIG90aGVyIGNvbmNlcm5z IHNlZW0gdmFndWUsIGUuZy4gImlkZW50aXR5IGlzIGEgaHVnZSB0b3BpYyIuIFdoaWxlDQoNCj4g dGhhdCBtYXkgYmUgdHJ1ZSwgc28gaXMgYXV0aG9yaXphdGlvbiwgYW5kIHRoYXQgYWxvbmUgaXMg bm90IGEgZ29vZA0KDQo+IHJlYXNvbiB0byBub3QgZG8gaXQuDQoNCj4NCg0KPiBQZXJoYXBzIHRo ZSBzY29wZSBvZiBpZGVudGl0eSBpbmNsdWRlZCBpbiBUeEF1dGggY291bGQgYmUgbmFycm93ZWQg dG8NCg0KPiBzcGVjaWZ5IHRoYXQgaXQncyBvbmx5IGFib3V0IGNvbW11bmljYXRpbmcgaWRlbnRp dHkgaW5mb3JtYXRpb24sIG5vdA0KDQo+IGFib3V0IGRvaW5nIHRoaW5ncyBsaWtlIGlkZW50aXR5 IHByb29maW5nIG9yIGlkZW50aXR5IGFzc3VyYW5jZS4gVGhhdA0KDQo+IG1pZ2h0IGhlbHAgYWRk cmVzcyBzb21lIG9mIHRoZSBvdGhlciBjb25jZXJucyB0aGF0IGhhdmUgYmVlbg0KDQo+IGV4cHJl c3NlZC4NCg0KPg0KDQo+IC0tLS0NCg0KPiBBYXJvbiBQYXJlY2tpDQoNCj4gYWFyb25wYXJlY2tp LmNvbQ0KDQo+IEBhYXJvbnBrDQoNCj4NCg0KPiBPbiBUdWUsIE1hciAxNywgMjAyMCBhdCAzOjA2 IFBNIE1pa2UgSm9uZXMNCg0KPiA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu b3JnPj4gd3JvdGU6DQoNCj4+DQoNCj4+IEkgYmVsaWV2ZSBpdCdzIHNpZ25pZmljYW50IHRoYXQg Zm91ciBwZW9wbGUgaGF2ZSBleHByZXNzZWQgY29uY2VybnMgd2l0aCBpbmNsdWRpbmcgZGlnaXRh bCBpZGVudGl0eSBpbiB0aGUgY2hhcnRlciAodGhlIG9ubHkgY29uY2VybnMgdm9pY2VkIGFzIGZh ciBhcyBJIGNhbiB0ZWxsKS4gIEF0IGEgbWluaW11bSwgSSBiZWxpZXZlIHRoYXQgdGhhdCB3YXJy YW50cyBtYWtpbmcgdGhlIGluY2x1c2lvbiBvciBleGNsdXNpb24gb2YgZGlnaXRhbCBpZGVudGl0 eSBhIGRpc2N1c3Npb24gdG9waWMgZHVyaW5nIHRoZSB1cGNvbWluZyB2aXJ0dWFsIEJvRiwgYmVm b3JlIGFkb3B0aW5nIGFueSBjaGFydGVyLg0KDQo+Pg0KDQo+PiBJdCB3b3VsZCBiZSBteSBwcm9w b3NhbCB0byBpbml0aWFsbHkgY2hhcnRlciB3aXRob3V0IGRpZ2l0YWwgaWRlbnRpdHkgYW5kIHNl ZSBob3cgZmFyIHdlIGdldCB3aXRoIG91ciBlbmVyZ2llcyBpbnRlbnRpb25hbGx5IGZvY3VzZWQg aW4gdGhhdCB3YXkuICBJZiB0aGUgd29ya2luZyBncm91cCBkZWNpZGVzIHRvIHJlY2hhcnRlciB0 byBpbmNsdWRlIGRpZ2l0YWwgaWRlbnRpdHksIHRoYXQgY2FuIGFsd2F5cyBoYXBwZW4gbGF0ZXIs IGFmdGVyIHRoZSBhdXRob3JpemF0aW9uLWZvY3VzZWQgd29yayBoYXMgbWF0dXJlZCwgYW5kIG9u Y2UgdGhlcmUncyBhIGNsZWFyIGNhc2UgdG8gYWN0dWFsbHkgZG8gc28uDQoNCj4+DQoNCj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCj4+DQoNCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4NCg0KPj4gU2VudDogVHVlc2RheSwgTWFyY2gg MTcsIDIwMjAgMjoyMCBQTQ0KDQo+PiBUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KDQo+PiBDYzog WWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBn bWFpbC5jb20+PjsgVG9yc3RlbiBMb2RkZXJzdGVkdA0KDQo+PiA8dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj47IHR4YXV0aEBpZXRmLm9yZzxt YWlsdG86dHhhdXRoQGlldGYub3JnPg0KDQo+PiBTdWJqZWN0OiBSZTogW1R4YXV0aF0gQ2FsbCBm b3IgY2hhcnRlciBjb25zZW5zdXMgLSBUeEF1dGggV0cNCg0KPj4NCg0KPj4gV2hpbGUgSSB1bmRl cnN0YW5kIHRoZSBjb25jZXJucyBhcm91bmQgaWRlbnRpdHkgaW4gdGhlIGNoYXJ0ZXIsIGFuZCBJ IGhhZCBpbml0aWFsbHkgbm90IGluY2x1ZGVkIGl0LCBJIHdhcyBjb252aW5jZWQgdGhhdCB0aGUg a2luZCBvZiBpZGVudGl0eSBwcm90b2NvbCB0aGF0IHdl4oCZcmUgbG9va2luZyBhdCBoZXJlIGlz IGEgbWlub3IgYWRkaXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24gYW5kIGRlbGVnYXRpb24gZW5k IG9mIHRoaW5ncy4NCg0KPj4NCg0KPj4gQXMgeW91IGtub3csIG11Y2ggb2Ygd2hhdOKAmXMgaW4g T0lEQyBpcyB0aGVyZSB0byBmaXggcHJvYmxlbXMgd2l0aCBPQXV0aCAyIHdoZW4gaXTigJlzIHVz ZWQgZm9yIGlkZW50aXR5LiBJZiBPQXV0aCAyIGhhZCBzb2x2ZWQgdGhvc2UgcHJvYmxlbXMgaW50 ZXJuYWxseSwgdGhlbiBPSURDIHdvdWxkIGJlIG11Y2gsIG11Y2ggc2ltcGxlciBhbmQgc21hbGxl ci4gV2XigJlyZSBub3cgc3RhcnRpbmcgYXQgYSBiYXNlIHdoZXJlIHRob3NlIHByb2JsZW1zIGRv buKAmXQgZXhpc3QsIGJ1dCB3ZSBkb27igJl0IHlldCBrbm93IHdoYXQgb3RoZXIgcHJvYmxlbXMg dGhlcmUgbWlnaHQgYmUuDQoNCj4+DQoNCj4+IFRoZSBtYXJrZXQgaGFzIHNob3duIHVzIHRoYXQg dGhlIG1vc3QgY29tbW9uIGFwcGxpY2F0aW9uIG9mIE9BdXRoIDIgaXMgZmFyIGFuZCBhd2F5IGFj Y2VzcyB0byBpZGVudGl0eSBpbmZvcm1hdGlvbiBhbG9uZyBzaWRlIGFjY2VzcyB0byBhbiBBUEku IEkgdGhpbmsgd2UgbmVlZCB0byBwYXkgYXR0ZW50aW9uIHRvIHRoYXQgYW5kIG5vdCBtYWtlIHRo aXMgc2VwYXJhdGUganVzdCBiZWNhdXNlIHdlIGRpZCBpdCB0aGF0IHdheSBiZWZvcmUuIEFuZCBz b21lIG9mIHRoZSBwcm9wb3NlZCBpbm5vdmF0aW9ucywgaW5jbHVkaW5nIGdldHRpbmcgYW5kIHNl bmRpbmcgVkPigJlzLCBhcmUgYWxsIGFib3V0IGlkZW50aXR5Lg0KDQo+Pg0KDQo+PiBGdXJ0aGVy bW9yZSwgdGhpcyBjaGFydGVyIGRvZXMgbm90IHNwZWNpZnkgdGhlIGRvY3VtZW50IGFuZCBzcGVj aWZpY2F0aW9uIHN0cnVjdHVyZSBvZiB0aGUgY29tcG9uZW50cywgbm9yIGRvZXMgaXQgc3BlY2lm eSB0aGUgcHVibGljYXRpb24gb3JkZXIgb3IgdGltaW5nIG9mIGFueSBkb2N1bWVudHMuIEkgcGVy c29uYWxseSB0aGluayB0aGF0IHRoZSBpZGVudGl0eSBsYXllciBzaG91bGQgYmUgc2VwYXJhYmxl IHRvIGFuIGV4dGVudCwgdG8gdGhlIHBvaW50IG9mIHB1Ymxpc2hpbmcgdGhhdCBsYXllciBpbiBp dHMgb3duIHNwZWMgYWxvbmdzaWRlIHRoZSBjb3JlIGF1dGhvcml6YXRpb24gZGVsZWdhdGlvbiBz eXN0ZW0uIEhvd2V2ZXIsIHRoYXQgZG9lcyBub3QgbWVhbiB0aGF0IGl0IHNob3VsZCBiZSBkZXZl bG9wZWQgZWxzZXdoZXJlLg0KDQo+Pg0KDQo+PiBJZiB0aGVyZSBpcyBiZXR0ZXIgbGFuZ3VhZ2Ug dG8gdGlnaHRlbiB0aGUgYXNwZWN0cyBvZiBhbiBpZGVudGl0eSBwcm90b2NvbCB0aGF0IHdlIHdp bGwgZXhwbGljaXRseSBjb3ZlciwgdGhlbiBJIHdvdWxkIHdlbGNvbWUgeW91IHRvIHN1Z2dlc3Qg YW4gYW1lbmRlZCB0ZXh0IHRvIHRoZSBjaGFydGVyLiBIb3dldmVyLCBJIGJlbGlldmUgdGhlcmUg aXMgZW5vdWdoIGludGVyZXN0IHdpdGhpbiB0aGUgY29tbXVuaXR5IHRvIHdvcmsgb24gaWRlbnRp dHkgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBwcm90b2NvbCwgaW5jbHVkaW5nIGEgbGFyZ2UgbnVt YmVyIG9mIHBlb3BsZSBiZWluZyBPSyB3aXRoIGl0IGluIHRoZSBjaGFydGVyLCB0aGF0IGl0IHdv dWxkIG5vdCBiZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8gcmVtb3ZlIGl0Lg0KDQo+Pg0KDQo+PiDi gJQgSnVzdGluDQoNCj4+DQoNCj4+PiBPbiBNYXIgMTcsIDIwMjAsIGF0IDE6MTIgUE0sIE1pa2Ug Sm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzpNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K DQo+Pj4NCg0KPj4+IDEuICBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVk IGF0IHRoZSBlbmQgb2YgdGhpcyBlbWFpbD8gIE9yIGRvIHlvdSBoYXZlIG1ham9yIG9iamVjdGlv bnMsIGJsb2NraW5nIGNvbmNlcm5zIG9yIGZlZWRiYWNrIChpZiBzbyBwbGVhc2UgZWxhYm9yYXRl KT8NCg0KPj4+DQoNCj4+PiBJIHNoYXJlIHRoZSBjb25jZXJucyBhYm91dCBpbmNsdWRpbmcgaWRl bnRpdHkgaW4gdGhlIGNoYXJ0ZXIgdGhhdCB3ZXJlIGV4cHJlc3NlZCBieSBUb3JzdGVuIGFuZCBh Z3JlZWQgd2l0aCBieSBEYXZpZCBTa2FpZmUuICBJJ2xsIG5vdGUgdGhhdCBLaW0gQ2FtZXJvbiBw cmV2aW91c2x5IGV4cHJlc3NlZCBjb25jZXJucyBhYm91dCBpbmNsdWRpbmcgaWRlbnRpdHkgaW4g aGlzIGVhcmxpZXIgY2hhcnRlciBjcml0aXF1ZSBhdCBodHRwczovL21haWxhcmNoaXZlLmlldGYu b3JnL2FyY2gvbXNnL3R4YXV0aC91TDkyT19WazVtMzhEY2FjWFNuc2hYMkNhaEUvLg0KDQo+Pj4N Cg0KPj4+IEknbSBmaW5lIHdpdGggcmVmYWN0b3JpbmcgdGhlIGF1dGhvcml6YXRpb24gcHJvdG9j b2wuICBCdXQgaWRlbnRpdHkgc2hvdWxkIGJlIGRlY291cGxlZCBmcm9tIHRoZSBUeEF1dGggd29y ayB0byBmb2N1cyBpdHMgc2NvcGUgb24gYXJlYXMgd2hlcmUgaW5ub3ZhdGlvbiBpcyBiZWluZyBw cm9wb3NlZC4gIERpZ2l0YWwgaWRlbnRpdHkgY2FuIGFsd2F5cyBiZSBhZGRlZCBhcyBhIGxheWVy IGlmIG5lZWRlZCwganVzdCBhcyBPcGVuSUQgQ29ubmVjdCBsYXllcmVkIGlkZW50aXR5IG9udG8g T0F1dGggMi4wLg0KDQo+Pj4NCg0KPj4+IFBsZWFzZSByZXZpc2UgdGhlIGNoYXJ0ZXIgdG8gcmVt b3ZlIGRpZ2l0YWwgaWRlbnRpdHkgZnJvbSB0aGUgc2NvcGUgb2YgdGhlIHdvcmsuDQoNCj4+Pg0K DQo+Pj4gMi4gIEFyZSB5b3Ugd2lsbGluZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhl IGRldmVsb3BtZW50IG9mIHRoZSBkcmFmdHMgb2YgdGhpcyBXRz8NCg0KPj4+DQoNCj4+PiBZZXMN Cg0KPj4+DQoNCj4+PiAzLiAgQXJlIHlvdSB3aWxsaW5nIHRvIGhlbHAgcmV2aWV3IHRoZSBkcmFm dHMgb2YgdGhpcyBXRz8NCg0KPj4+DQoNCj4+PiBZZXMNCg0KPj4+DQoNCj4+PiA0LiAgQXJlIHlv dSBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyBkcmFmdHMgb2YgdGhpcyBXRz8NCg0KPj4+DQoN Cj4+PiBOb3QgYXQgdGhpcyB0aW1lLg0KDQo+Pj4NCg0KPj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQo+Pj4NCg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQoNCj4+PiBGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0eGF1 dGgtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBUb3JzdGVuDQoNCj4+PiBMb2RkZXJz dGVkdA0KDQo+Pj4gU2VudDogU2F0dXJkYXksIE1hcmNoIDcsIDIwMjAgNzoxOCBBTQ0KDQo+Pj4g VG86IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmll dGZAZ21haWwuY29tPj4NCg0KPj4+IENjOiB0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBp ZXRmLm9yZz4NCg0KPj4+IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIENhbGwgZm9y IGNoYXJ0ZXIgY29uc2Vuc3VzIC0gVHhBdXRoDQoNCj4+PiBXRw0KDQo+Pj4NCg0KPj4+IEhpLA0K DQo+Pj4NCg0KPj4+PiBBbSAwNi4wMy4yMDIwIHVtIDE3OjQ1IHNjaHJpZWIgWWFyb24gU2hlZmZl ciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjoN Cg0KPj4+Pg0KDQo+Pj4+IO+7v0hpIEV2ZXJ5b25lLA0KDQo+Pj4+DQoNCj4+Pj4gSXQgYXBwZWFy cyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRpb24g b2YgYSBUeEF1dGggd29ya2luZyBncm91cC4gIFdl4oCZZCBsaWtlIHRvIG1vcmUgZm9ybWFsbHkg Z2F1Z2UgaW50ZXJlc3QgaW4gcHJvY2VlZGluZyB3aXRoIHRoaXMgd29yay4gIFBsZWFzZSBkbyBz byBieSByZXNwb25kaW5nIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQo+Pj4+DQoNCj4+ Pj4gMS4gIERvIHlvdSBzdXBwb3J0IHRoZSBjaGFydGVyIHRleHQgcHJvdmlkZWQgYXQgdGhlIGVu ZCBvZiB0aGlzIGVtYWlsPyAgT3IgZG8geW91IGhhdmUgbWFqb3Igb2JqZWN0aW9ucywgYmxvY2tp bmcgY29uY2VybnMgb3IgZmVlZGJhY2sgKGlmIHNvIHBsZWFzZSBlbGFib3JhdGUpPw0KDQo+Pj4N Cg0KPj4+IEnigJhtIGluIGFsdGhvdWdoIEkgaGF2ZSB0byBhZG1pdCBJ4oCYbSBzbGlnaHRseSBj b25jZXJuZWQgdGhlIHNjb3BlIG9mIHRoZSBjaGFydGVyIGlzIHRvbyBicm9hZCwgZS5nLiBpZGVu dGlmeSBhbG9uZSBpcyBhIGh1Z2UgdG9waWMuDQoNCj4+Pg0KDQo+Pj4gV2UgbmVlZCB0byBrZWVw IGFuIGV5ZSBvbiB0aGlzIGFzcGVjdCBpbiBvcmRlciB0byBtYWtlIHN1cmUsIHRoZSBncm91cCBp cyBhYmxlIHRvIHdvcmsgZWZmZWN0aXZlbHkgYW5kIHRoZSBzcGVjcyB3ZSB3aWxsIGJlIHByb2R1 Y2luZyBhcmUgYXMgc2ltcGxlIGFzIHBvc3NpYmxlIGFuZCBmb3N0ZXIgaW50ZXJvcGVyYWJpbGl0 eS4NCg0KPj4+DQoNCj4+Pj4NCg0KPj4+PiAyLiAgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhvciBv ciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlzIFdH Pw0KDQo+Pj4NCg0KPj4+IHllcw0KDQo+Pj4NCg0KPj4+Pg0KDQo+Pj4+IDMuICBBcmUgeW91IHdp bGxpbmcgdG8gaGVscCByZXZpZXcgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPw0KDQo+Pj4NCg0KPj4+ IHllcw0KDQo+Pj4NCg0KPj4+Pg0KDQo+Pj4+IDQuICBBcmUgeW91IGludGVyZXN0ZWQgaW4gaW1w bGVtZW50aW5nIGRyYWZ0cyBvZiB0aGlzIFdHPw0KDQo+Pj4NCg0KPj4+IHllcw0KDQo+Pj4NCg0K Pj4+IGJlc3QgcmVnYXJkcywNCg0KPj4+IFRvcnN0ZW4uDQoNCj4+Pg0KDQo+Pj4+DQoNCj4+Pj4g VGhlIGNhbGwgd2lsbCBydW4gZm9yIHR3byB3ZWVrcywgdW50aWwgTWFyY2ggMjEuIElmIHlvdSB0 aGluayB0aGF0IHRoZSBjaGFydGVyIHNob3VsZCBiZSBhbWVuZGVkIEluIGEgc2lnbmlmaWNhbnQg d2F5LCBwbGVhc2UgcmVwbHkgb24gYSBzZXBhcmF0ZSB0aHJlYWQuDQoNCj4+Pj4NCg0KPj4+PiBU aGUgZmVlZGJhY2sgcHJvdmlkZWQgaGVyZSB3aWxsIGhlbHAgdGhlIElFU0cgY29tZSB0byBhIGRl Y2lzaW9uIG9uIHRoZSBmb3JtYXRpb24gb2YgYSBuZXcgV0cuIEdpdmVuIHRoZSBjb25zdHJhaW50 cyBvZiB0aGUgY2hhcnRlcmluZyBwcm9jZXNzLCByZWdhcmRsZXNzIG9mIHRoZSBvdXRjb21lIG9m IHRoaXMgY29uc2Vuc3VzIGNhbGwsIHdlIHdpbGwgYmUgbWVldGluZyBpbiBWYW5jb3V2ZXIgYXMg YSBCb0YuDQoNCj4+Pj4NCg0KPj4+PiBUaGFua3MsDQoNCj4+Pj4gWWFyb24gYW5kIERpY2sNCg0K Pj4+Pg0KDQo+Pj4+IC0tLSBDaGFydGVyIFRleHQgRm9sbG93cyAtLS0NCg0KPj4+Pg0KDQo+Pj4+ IFRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBmaW5lLWdyYWluZWQgZGVsZWdh dGlvbiBwcm90b2NvbCBmb3IgYXV0aG9yaXphdGlvbiwgaWRlbnRpdHksIGFuZCBBUEkgYWNjZXNz LiBUaGlzIHByb3RvY29sIHdpbGwgYWxsb3cgYW4gYXV0aG9yaXppbmcgcGFydHkgdG8gZGVsZWdh dGUgYWNjZXNzIHRvIGNsaWVudCBzb2Z0d2FyZSB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2Vy dmVyLiBJdCB3aWxsIGV4cGFuZCB1cG9uIHRoZSB1c2VzIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0 ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCAoaXRzZWxmIGFuIGV4dGVuc2lvbiBv ZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQgYXV0aG9yaXphdGlvbnMgc2NvcGVkIGFzIG5hcnJvd2x5 IGFzIGEgc2luZ2xlIHRyYW5zYWN0aW9uLCBwcm92aWRlIGEgY2xlYXIgZnJhbWV3b3JrIGZvciBp bnRlcmFjdGlvbiBhbW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBpbiB0aGUgcHJvdG9jb2wgZmxv dywgYW5kIHJlbW92ZSB1bm5lY2Vzc2FyeSBkZXBlbmRlbmNlIG9uIGEgYnJvd3NlciBvciB1c2Vy LWFnZW50IGZvciBjb29yZGluYXRpbmcgaW50ZXJhY3Rpb25zLg0KDQo+Pj4+DQoNCj4+Pj4gVGhl IGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVsdGlwbGUgcGFydGll cyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmljIHJvbGUuIFRoZSBw cm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVscywgc3VjaCBhcyB0 aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwgd2hp Y2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2ggaXMgaW5pdGlhdGVk IGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUgY2xp ZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlvbiBk ZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluZGlj YXRlZCBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGluZyBhdm9pZHMgbWFueSBvZiB0aGUg c2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9mIE9BdXRoIDIuMCBh bmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlw ZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQoNCj4+Pj4NCg0KPj4+PiBB ZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxvdyBmb3I6DQoNCj4+ Pj4NCg0KPj4+PiAtIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIGFjY2Vzcw0KDQo+Pj4+ IC0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRlbnRpdHkgY2xhaW1zDQoNCj4+Pj4g LSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBBUElzIGluIGEg c2luZ2xlDQoNCj4+Pj4gaW50ZXJhY3Rpb24NCg0KPj4+PiAtIFNlcGFyYXRpb24gYmV0d2VlbiB0 aGUgcGFydHkgYXV0aG9yaXppbmcgYWNjZXNzIGFuZCB0aGUgcGFydHkNCg0KPj4+PiBvcGVyYXRp bmcgdGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2Vzcw0KDQo+Pj4+IC0gQSB2YXJpZXR5IG9mIGNs aWVudCBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyBXZWIsIG1vYmlsZSwNCg0KPj4+PiBzaW5nbGUt cGFnZSwgYW5kIGludGVyYWN0aW9uLWNvbnN0cmFpbmVkIGFwcGxpY2F0aW9ucw0KDQo+Pj4+DQoN Cj4+Pj4gVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJv dG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzoNCg0KPj4+ Pg0KDQo+Pj4+IC0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25h dHVyZXMsIGFuZCBwcm9vZiBvZg0KDQo+Pj4+IHBvc3Nlc3Npb24NCg0KPj4+PiAtIFVzZXIgaW50 ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHMNCg0K Pj4+PiAtIE1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0 aW9uLCBhbmQgb3RoZXINCg0KPj4+PiBwaWVjZXMgb2YgaW5mb3JtYXRpb24gdXNlZCBpbiBhdXRo b3JpemF0aW9uIGRlY2lzaW9ucw0KDQo+Pj4+IC0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0 b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVycyBhbmQgYmluZGluZw0KDQo+Pj4+IHJlc291cmNlIHJl cXVlc3RzIHRvIHRva2VucyBhbmQgYXNzb2NpYXRlZCBjcnlwdG9ncmFwaGljIGtleXMNCg0KPj4+ PiAtIE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdo IHRoZQ0KDQo+Pj4+IGRlbGVnYXRpb24gcHJvY2VzcyAoaW5jbHVkaW5nIGlkZW50aXR5KQ0KDQo+ Pj4+DQoNCj4+Pj4gQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1lY2hhbmlz bXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRpbmc6DQoN Cj4+Pj4NCg0KPj4+PiAtIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCg0K Pj4+PiAtIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2Vucw0KDQo+Pj4+IC0gUXVlcnkgb2YgdG9r ZW4gcmlnaHRzIGJ5IHJlc291cmNlIHNlcnZlcnMNCg0KPj4+Pg0KDQo+Pj4+IEFsdGhvdWdoIHRo ZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRv IGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0 LCB0aGUgZ3JvdXAgd2lsbCBhdHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRo IDIuMCBhbmQgT3BlbklEIENvbm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJs ZS4NCg0KPj4+Pg0KDQo+Pj4+IFRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9w IGV4dGVuc2lvbnMgdG8gT0F1dGggMi4wLCBhbmQgYXMgc3VjaCB3aWxsIGZvY3VzIG9uIG5ldyB0 ZWNobm9sb2dpY2FsIHNvbHV0aW9ucyBub3QgbmVjZXNzYXJpbHkgY29tcGF0aWJsZSB3aXRoIE9B dXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxkcyBkaXJlY3RseSBvbiBPQXV0aCAyLjAg d2lsbCBiZSBkZXZlbG9wZWQgaW4gdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAsIGluY2x1ZGluZyBm dW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRldmVsb3BlZCBoZXJl IHRvIE9BdXRoIDIuMC4NCg0KPj4+Pg0KDQo+Pj4+IFRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8g ZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1 Y2ggYXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91 cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy4N Cg0KPj4+Pg0KDQo+Pj4+IFRoZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1cyBvbiB1c2luZyBIVFRQ IGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBI VFRQMiBhbmQgSFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxsIHN0cml2ZSB0byBlbmFibGUg c2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXMgQ09BUCB3aGVuIGRvaW5n IHNvIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuDQoNCj4+Pj4NCg0K Pj4+PiBNaWxlc3RvbmVzIHRvIGluY2x1ZGU6DQoNCj4+Pj4gLSBDb3JlIGRlbGVnYXRpb24gcHJv dG9jb2wNCg0KPj4+PiAtIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmdzIHRvIHRo ZSBjb3JlIHByb3RvY29sIGZvciBUTFMsDQoNCj4+Pj4gZGV0YWNoZWQgSFRUUCBzaWduYXR1cmUs IGFuZCBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZXMNCg0KPj4+PiAtIElkZW50aXR5IGFuZCBhdXRo ZW50aWNhdGlvbiBjb252ZXlhbmNlIG1lY2hhbmlzbXMNCg0KPj4+PiAtIEd1aWRlbGluZXMgZm9y IHVzZSBvZiBwcm90b2NvbCBleHRlbnNpb24gcG9pbnRzDQoNCj4+Pj4NCg0KPj4+Pg0KDQo+Pj4+ IC0tDQoNCj4+Pj4gVHhhdXRoIG1haWxpbmcgbGlzdA0KDQo+Pj4+IFR4YXV0aEBpZXRmLm9yZzxt YWlsdG86VHhhdXRoQGlldGYub3JnPg0KDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoDQoNCj4+PiAtLQ0KDQo+Pj4gVHhhdXRoIG1haWxpbmcgbGlzdA0K DQo+Pj4gVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQoNCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQo+Pg0KDQo+PiAtLQ0K DQo+PiBUeGF1dGggbWFpbGluZyBsaXN0DQoNCj4+IFR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhh dXRoQGlldGYub3JnPg0KDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aA0KDQoNCg== --_000_MN2PR00MB0688E4B36EB514D68C0F79EEF5F70MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlB1dHRpbmcgYSBsaXR0bGUgbW9yZSBtZWF0IG9uIHRoZSAmcXVvdDtpZGVudGl0 eSBpcyBhIGh1Z2UgdG9waWMmcXVvdDsgY29tbWVudCwgbGV0IG1lIG1ha2UgYSBmZXcgb2JzZXJ2 YXRpb25zIGFib3V0IE9wZW5JRCBDb25uZWN0IGFuZCBPQXV0aCAyLjAuJm5ic3A7IE1vc3Qgb2YN CjxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1jb3JlLTFf MC5odG1sIj5PcGVuSUQgQ29ubmVjdCBDb3JlPC9hPiBjcmVhdGVzIG5ldyBpZGVudGl0eS1zcGVj aWZpYyBmdW5jdGlvbmFsaXR5IHN1Y2ggYXMgSUQgVG9rZW5zLCB0aGUgVXNlckluZm8gRW5kcG9p bnQsIENsYWltcyAoaW5jbHVkaW5nIGFnZ3JlZ2F0ZWQgYW5kIGRpc3RyaWJ1dGVkIGNsYWltcyks IGF1dGhlbnRpY2F0ZWQgc2Vzc2lvbnMsIGlzc3VlcnMsDQoga2V5IG1hbmFnZW1lbnQgYW5kIGtl eSByb2xsb3Zlciwgc2VsZi1pc3N1ZWQgaWRlbnRpdHkgcHJvdmlkZXJzLCBldGMuJm5ic3A7IFll cywgPGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWNvcmUt MV8wLmh0bWwjQXV0aGVudGljYXRpb24iPg0KU2VjdGlvbiAzIChBdXRoZW50aWNhdGlvbik8L2E+ IGRlc2NyaWJlcyBob3cgdG8gdHVybiBhbiBhdXRob3JpemF0aW9uIHJlcXVlc3QgaW50byBhbiBh dXRoZW50aWNhdGlvbiByZXF1ZXN0IOKAkyB3aGljaCBpcyB0aGUgY29yZSBvZiB0aGUgcmVsYXRp b25zaGlwIGJldHdlZW4gT3BlbklEIENvbm5lY3QgYW5kIE9BdXRoIDIuMCDigJMgYW5kDQo8YSBo cmVmPSJodHRwczovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtY29yZS0xXzAuaHRt bCNDbGllbnRBdXRoZW50aWNhdGlvbiI+DQpTZWN0aW9uIDkgKENsaWVudCBBdXRoZW50aWNhdGlv bik8L2E+ICZuYnNwO2lzIGFsc28gYWJvdXQgdGhlIE9BdXRoL0Nvbm5lY3QgaW50ZXJmYWNlLiZu YnNwOyBCdXQgbW9zdCBvZiBpdCBpcyBub3QgYWJvdXQgT0F1dGggb3IgYXV0aG9yaXphdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhdOKAmXMgZXZlbiBtb3JlIHRydWUgd2hl biB5b3UgY29uc2lkZXIgdGhhdCBvdGhlciBPcGVuSUQgQ29ubmVjdCBzcGVjcyBhcmUgaW1wb3J0 YW50IGluIG1hbnkgZGVwbG95bWVudHMsIHN1Y2ggYXMNCjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQu bmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWRpc2NvdmVyeS0xXzAuaHRtbCI+RGlzY292ZXJ5PC9h PiwNCjxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1mcm9u dGNoYW5uZWwtMV8wLmh0bWwiPkZyb250LUNoYW5uZWwgTG9nb3V0PC9hPiwNCjxhIGhyZWY9Imh0 dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC00LWlkZW50aXR5LWFzc3VyYW5j ZS0xXzAuaHRtbCI+SWRlbnRpdHkgQXNzdXJhbmNlPC9hPiwgZXRjLiZuYnNwOyBUaGVyZeKAmXMg YSBsb3QgbW9yZSB0byBpZGVudGl0eSB0aGFuIGp1c3QgbG9nZ2luZyBpbiBhbmQgcmV0dXJuaW5n IGNsYWltcyBhYm91dCB0aGUgZW5kLXVzZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlRoZXJlZm9yZSwgaWYgaWRlbnRpdHkgaXMgaW4gc2NvcGUgYXQgYWxsLCBJIGFncmVlIHRoYXQg aXQgc2hvdWxkIGJlIGEgbmFycm93LCB3ZWxsLWRlZmluZWQgc2xpY2Ug4oCTIGZvciBpbnN0YW5j ZSBtYXliZSBhIG1lY2hhbmlzbSBkZWZpbmluZyB3aGF0IHN5bnRheCB5b3UgdXNlIHRvIGluZGlj YXRlIHRoYXQgYSBUeEF1dGggYXV0aG9yaXphdGlvbiByZXF1ZXN0IGlzIGFsc28gYW4gYXV0aGVu dGljYXRpb24NCiAobG9naW4pIHJlcXVlc3Qg4oCTIHdoaWNoIGlzIHdoYXQgdGhlIOKAnG9wZW5p ZOKAnSBzY29wZSBkb2VzLiZuYnNwOyBCdXQgaWRlbnRpdHkgaXMgaHVnZSB0b3BpYy4mbmJzcDsg SSBiZWxpZXZlIHRoYXQgd2Ugc2hvdWxkIGVuYWJsZSBhcyBtdWNoIHJldXNlIG9mIGV4aXN0aW5n IGlkZW50aXR5IG1lY2hhbmlzbXMgYXMgcG9zc2libGUsIHdoaWxlIHN0aWxsIHJld29ya2luZyB0 aGUgcHJvdG9jb2wgZmxvd3MuJm5ic3A7IFRoaW5ncyBsaWtlIHNlc3Npb24gbWFuYWdlbWVudCAo aW5jbHVkaW5nDQogc2Vzc2lvbiByZW5ld2FsIGFuZCBsb2dvdXQpLCBpZGVudGl0eSBhc3N1cmFu Y2UsIGFuZCBjbGFpbXMgYWJvdXQgdGhlIGVuZC11c2VyIGFuZCBhYm91dCB0aGUgYXV0aGVudGlj YXRpb24gcGVyZm9ybWVkIHNob3VsZCBiZSBleHBsaWNpdGx5IG91dCBvZiBzY29wZSwgdG8ga2Vl cCB1cyBmcm9tIHRyeWluZyB0byByZWludmVudCBhbGwgdGhlIHdoZWVscy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7 IDxicj4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE3LCAyMDIwIDM6NDcgUE08YnI+DQpUbzogQWFy b24gUGFyZWNraSAmbHQ7YWFyb25AcGFyZWNraS5jb20mZ3Q7PGJyPg0KQ2M6IE1pa2UgSm9uZXMg Jmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs7IFlhcm9uIFNoZWZmZXIgJmx0O3lh cm9uZi5pZXRmQGdtYWlsLmNvbSZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5A bG9kZGVyc3RlZHQubmV0Jmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KU3ViamVjdDogUmU6IFtU eGF1dGhdIENhbGwgZm9yIGNoYXJ0ZXIgY29uc2Vuc3VzIC0gVHhBdXRoIFdHPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mIzQzOzE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzLCBBYXJv bi4gSSB0aGluayBpdCByZWFsbHkgaXMgYSB2ZXJ5IG5hcnJvdyBzbGljZSBvZiBpZGVudGl0eSB0 aGF0IHdlIHdhbnQgdG8gY292ZXIgaGVyZSwgYW5kIEnigJlkIGJlIGhhcHB5IHRvIGdldCBtb3Jl IHByZWNpc2UgbGFuZ3VhZ2UgaW50byB0aGUgcHJvcG9zZWQgY2hhcnRlciBiZWZvcmUgbW92aW5n IGZvcndhcmQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+4oCUIEp1c3RpbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IE9uIE1hciAxNywgMjAyMCwgYXQgNjozMSBQ TSwgQWFyb24gUGFyZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFhcm9uQHBhcmVja2kuY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+YWFyb25A cGFyZWNraS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBNdWNoIG9mIHRoZSBjb25mdXNpb24gaW4gdGhlIG1hcmtldHBsYWNlIGFyb3Vu ZCBPQXV0aCBhbmQgT3BlbklEDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgQ29ubmVjdCBzdGVtcyBmcm9tIHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgc2VwYXJh dGUgc3BlY3MgZGV2ZWxvcGVkIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgc2VwYXJhdGUgb3JnYW5pemF0aW9ucywgd2hlbiByZWFsbHkgdGhleSBhcmUg dHdvIHBhcnRzIHRvIHRoZSBzYW1lDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgcGljdHVyZS4gSSBhbSBzdHJvbmdseSBhZ2FpbnN0IGV4Y2x1ZGluZyBpZGVu dGl0eSBmcm9tIHRoZSBjaGFydGVyIG9mDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgVHhBdXRoLCBhcyBJIHRoaW5rIHRoaXMgaXMgYSB1bmlxdWUgb3Bwb3J0 dW5pdHkgdG8gYnJpbmcgdGhlIHR3bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGFzcGVjdHMgdG9nZXRoZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBUaGUgY29uY2VybiBleHByZXNzZWQgYnkgS2ltPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICg8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3R4YXV0aC91TDkyT19WazVtMzhEY2FjWFNuc2hYMkMiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC91TDkyT19WazVtMzhEY2FjWFNuc2hYMkM8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBh aEUpIGFyb3VuZCBPcGVuSUQgQ29ubmVjdCBjb3VsZCBhbHNvIGJlIHNhaWQgYWJvdXQgT0F1dGgs IG5hbWVseSB0aGF0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgdGhlcmUgd2lsbCBiZSBzb21lIGFtb3VudCBvZiBjb25mdXNpb24gYXJvdW5kIHRoZSBmYWN0 IHRoYXQgdGhpcyBzcGVjDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgd2lsbCBjb3ZlciBtYW55IG9mIHRoZSBzYW1lIHVzZSBjYXNlcyBhcyBPQXV0aC4gSSB0 aGluayB0aGF0J3MgZmluZSwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyB0aGF0J3MganVzdCBob3cgd2UgbW92ZSBmb3J3YXJkIGFuZCBtYWtlIHByb2dyZXNz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVGhlIG90aGVyIGNvbmNlcm5zIHNl ZW0gdmFndWUsIGUuZy4gJnF1b3Q7aWRlbnRpdHkgaXMgYSBodWdlIHRvcGljJnF1b3Q7LiBXaGls ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoYXQgbWF5 IGJlIHRydWUsIHNvIGlzIGF1dGhvcml6YXRpb24sIGFuZCB0aGF0IGFsb25lIGlzIG5vdCBhIGdv b2QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyByZWFzb24g dG8gbm90IGRvIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgUGVyaGFwcyB0 aGUgc2NvcGUgb2YgaWRlbnRpdHkgaW5jbHVkZWQgaW4gVHhBdXRoIGNvdWxkIGJlIG5hcnJvd2Vk IHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc3BlY2lm eSB0aGF0IGl0J3Mgb25seSBhYm91dCBjb21tdW5pY2F0aW5nIGlkZW50aXR5IGluZm9ybWF0aW9u LCBub3QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBhYm91 dCBkb2luZyB0aGluZ3MgbGlrZSBpZGVudGl0eSBwcm9vZmluZyBvciBpZGVudGl0eSBhc3N1cmFu Y2UuIFRoYXQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBt aWdodCBoZWxwIGFkZHJlc3Mgc29tZSBvZiB0aGUgb3RoZXIgY29uY2VybnMgdGhhdCBoYXZlIGJl ZW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBleHByZXNz ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAtLS0tPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEFhcm9uIFBhcmVja2k8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYWFyb25wYXJlY2tpLmNvbTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBAYWFyb25wazxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgT24gVHVlLCBNYXIgMTcsIDIwMjAgYXQgMzowNiBQTSBN aWtlIEpvbmVzIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IEkg YmVsaWV2ZSBpdCdzIHNpZ25pZmljYW50IHRoYXQgZm91ciBwZW9wbGUgaGF2ZSBleHByZXNzZWQg Y29uY2VybnMgd2l0aCBpbmNsdWRpbmcgZGlnaXRhbCBpZGVudGl0eSBpbiB0aGUgY2hhcnRlciAo dGhlIG9ubHkgY29uY2VybnMgdm9pY2VkIGFzIGZhciBhcyBJIGNhbiB0ZWxsKS4mbmJzcDsgQXQg YSBtaW5pbXVtLCBJIGJlbGlldmUgdGhhdCB0aGF0IHdhcnJhbnRzIG1ha2luZyB0aGUgaW5jbHVz aW9uIG9yDQogZXhjbHVzaW9uIG9mIGRpZ2l0YWwgaWRlbnRpdHkgYSBkaXNjdXNzaW9uIHRvcGlj IGR1cmluZyB0aGUgdXBjb21pbmcgdmlydHVhbCBCb0YsIGJlZm9yZSBhZG9wdGluZyBhbnkgY2hh cnRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgSXQgd291bGQg YmUgbXkgcHJvcG9zYWwgdG8gaW5pdGlhbGx5IGNoYXJ0ZXIgd2l0aG91dCBkaWdpdGFsIGlkZW50 aXR5IGFuZCBzZWUgaG93IGZhciB3ZSBnZXQgd2l0aCBvdXIgZW5lcmdpZXMgaW50ZW50aW9uYWxs eSBmb2N1c2VkIGluIHRoYXQgd2F5LiZuYnNwOyBJZiB0aGUgd29ya2luZyBncm91cCBkZWNpZGVz IHRvIHJlY2hhcnRlciB0byBpbmNsdWRlIGRpZ2l0YWwgaWRlbnRpdHksIHRoYXQgY2FuIGFsd2F5 cw0KIGhhcHBlbiBsYXRlciwgYWZ0ZXIgdGhlIGF1dGhvcml6YXRpb24tZm9jdXNlZCB3b3JrIGhh cyBtYXR1cmVkLCBhbmQgb25jZSB0aGVyZSdzIGEgY2xlYXIgY2FzZSB0byBhY3R1YWxseSBkbyBz by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsgRnJvbTogSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0LmVkdSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPmpyaWNoZXJAbWl0LmVkdTwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgU2VudDogVHVlc2RheSwgTWFyY2ggMTcs IDIwMjAgMjoyMCBQTTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsgVG86IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IENjOiBZYXJvbiBTaGVm ZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+eWFyb25mLmlldGZAZ21h aWwuY29tPC9zcGFuPjwvYT4mZ3Q7OyBUb3JzdGVuIExvZGRlcnN0ZWR0DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvc3Bhbj48L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj50eGF1dGhAaWV0Zi5vcmc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgU3ViamVj dDogUmU6IFtUeGF1dGhdIENhbGwgZm9yIGNoYXJ0ZXIgY29uc2Vuc3VzIC0gVHhBdXRoIFdHPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IFdoaWxlIEkgdW5kZXJzdGFu ZCB0aGUgY29uY2VybnMgYXJvdW5kIGlkZW50aXR5IGluIHRoZSBjaGFydGVyLCBhbmQgSSBoYWQg aW5pdGlhbGx5IG5vdCBpbmNsdWRlZCBpdCwgSSB3YXMgY29udmluY2VkIHRoYXQgdGhlIGtpbmQg b2YgaWRlbnRpdHkgcHJvdG9jb2wgdGhhdCB3ZeKAmXJlIGxvb2tpbmcgYXQgaGVyZSBpcyBhIG1p bm9yIGFkZGl0aW9uIHRvIHRoZSBhdXRob3JpemF0aW9uIGFuZCBkZWxlZ2F0aW9uDQogZW5kIG9m IHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgQXMgeW91 IGtub3csIG11Y2ggb2Ygd2hhdOKAmXMgaW4gT0lEQyBpcyB0aGVyZSB0byBmaXggcHJvYmxlbXMg d2l0aCBPQXV0aCAyIHdoZW4gaXTigJlzIHVzZWQgZm9yIGlkZW50aXR5LiBJZiBPQXV0aCAyIGhh ZCBzb2x2ZWQgdGhvc2UgcHJvYmxlbXMgaW50ZXJuYWxseSwgdGhlbiBPSURDIHdvdWxkIGJlIG11 Y2gsIG11Y2ggc2ltcGxlciBhbmQgc21hbGxlci4gV2XigJlyZSBub3cgc3RhcnRpbmcgYXQgYSBi YXNlDQogd2hlcmUgdGhvc2UgcHJvYmxlbXMgZG9u4oCZdCBleGlzdCwgYnV0IHdlIGRvbuKAmXQg eWV0IGtub3cgd2hhdCBvdGhlciBwcm9ibGVtcyB0aGVyZSBtaWdodCBiZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgVGhlIG1hcmtldCBoYXMgc2hvd24gdXMgdGhh dCB0aGUgbW9zdCBjb21tb24gYXBwbGljYXRpb24gb2YgT0F1dGggMiBpcyBmYXIgYW5kIGF3YXkg YWNjZXNzIHRvIGlkZW50aXR5IGluZm9ybWF0aW9uIGFsb25nIHNpZGUgYWNjZXNzIHRvIGFuIEFQ SS4gSSB0aGluayB3ZSBuZWVkIHRvIHBheSBhdHRlbnRpb24gdG8gdGhhdCBhbmQgbm90IG1ha2Ug dGhpcyBzZXBhcmF0ZSBqdXN0IGJlY2F1c2Ugd2UgZGlkDQogaXQgdGhhdCB3YXkgYmVmb3JlLiBB bmQgc29tZSBvZiB0aGUgcHJvcG9zZWQgaW5ub3ZhdGlvbnMsIGluY2x1ZGluZyBnZXR0aW5nIGFu ZCBzZW5kaW5nIFZD4oCZcywgYXJlIGFsbCBhYm91dCBpZGVudGl0eS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgRnVydGhlcm1vcmUsIHRoaXMgY2hhcnRlciBkb2Vz IG5vdCBzcGVjaWZ5IHRoZSBkb2N1bWVudCBhbmQgc3BlY2lmaWNhdGlvbiBzdHJ1Y3R1cmUgb2Yg dGhlIGNvbXBvbmVudHMsIG5vciBkb2VzIGl0IHNwZWNpZnkgdGhlIHB1YmxpY2F0aW9uIG9yZGVy IG9yIHRpbWluZyBvZiBhbnkgZG9jdW1lbnRzLiBJIHBlcnNvbmFsbHkgdGhpbmsgdGhhdCB0aGUg aWRlbnRpdHkgbGF5ZXIgc2hvdWxkIGJlIHNlcGFyYWJsZQ0KIHRvIGFuIGV4dGVudCwgdG8gdGhl IHBvaW50IG9mIHB1Ymxpc2hpbmcgdGhhdCBsYXllciBpbiBpdHMgb3duIHNwZWMgYWxvbmdzaWRl IHRoZSBjb3JlIGF1dGhvcml6YXRpb24gZGVsZWdhdGlvbiBzeXN0ZW0uIEhvd2V2ZXIsIHRoYXQg ZG9lcyBub3QgbWVhbiB0aGF0IGl0IHNob3VsZCBiZSBkZXZlbG9wZWQgZWxzZXdoZXJlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBJZiB0aGVyZSBpcyBiZXR0ZXIg bGFuZ3VhZ2UgdG8gdGlnaHRlbiB0aGUgYXNwZWN0cyBvZiBhbiBpZGVudGl0eSBwcm90b2NvbCB0 aGF0IHdlIHdpbGwgZXhwbGljaXRseSBjb3ZlciwgdGhlbiBJIHdvdWxkIHdlbGNvbWUgeW91IHRv IHN1Z2dlc3QgYW4gYW1lbmRlZCB0ZXh0IHRvIHRoZSBjaGFydGVyLiBIb3dldmVyLCBJIGJlbGll dmUgdGhlcmUgaXMgZW5vdWdoIGludGVyZXN0IHdpdGhpbiB0aGUgY29tbXVuaXR5DQogdG8gd29y ayBvbiBpZGVudGl0eSBpbiB0aGUgY29udGV4dCBvZiB0aGlzIHByb3RvY29sLCBpbmNsdWRpbmcg YSBsYXJnZSBudW1iZXIgb2YgcGVvcGxlIGJlaW5nIE9LIHdpdGggaXQgaW4gdGhlIGNoYXJ0ZXIs IHRoYXQgaXQgd291bGQgbm90IGJlIGEgcmVhc29uYWJsZSB0aGluZyB0byByZW1vdmUgaXQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IOKAlCBKdXN0aW48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IE9uIE1hciAxNywgMjAyMCwg YXQgMToxMiBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXM9 NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgMS4mbmJzcDsgRG8geW91IHN1cHBvcnQgdGhl IGNoYXJ0ZXIgdGV4dCBwcm92aWRlZCBhdCB0aGUgZW5kIG9mIHRoaXMgZW1haWw/Jm5ic3A7IE9y IGRvIHlvdSBoYXZlIG1ham9yIG9iamVjdGlvbnMsIGJsb2NraW5nIGNvbmNlcm5zIG9yIGZlZWRi YWNrIChpZiBzbyBwbGVhc2UgZWxhYm9yYXRlKT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBJIHNoYXJlIHRoZSBjb25jZXJucyBhYm91dCBpbmNsdWRp bmcgaWRlbnRpdHkgaW4gdGhlIGNoYXJ0ZXIgdGhhdCB3ZXJlIGV4cHJlc3NlZCBieSBUb3JzdGVu IGFuZCBhZ3JlZWQgd2l0aCBieSBEYXZpZCBTa2FpZmUuJm5ic3A7IEknbGwgbm90ZSB0aGF0IEtp bSBDYW1lcm9uIHByZXZpb3VzbHkgZXhwcmVzc2VkIGNvbmNlcm5zIGFib3V0IGluY2x1ZGluZyBp ZGVudGl0eSBpbiBoaXMgZWFybGllciBjaGFydGVyDQogY3JpdGlxdWUgYXQgPGEgaHJlZj0iaHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90eGF1dGgvdUw5Mk9fVms1bTM4RGNh Y1hTbnNoWDJDYWhFLyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90eGF1dGgv dUw5Mk9fVms1bTM4RGNhY1hTbnNoWDJDYWhFLzwvc3Bhbj48L2E+LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IEknbSBmaW5lIHdpdGggcmVmYWN0b3Jp bmcgdGhlIGF1dGhvcml6YXRpb24gcHJvdG9jb2wuJm5ic3A7IEJ1dCBpZGVudGl0eSBzaG91bGQg YmUgZGVjb3VwbGVkIGZyb20gdGhlIFR4QXV0aCB3b3JrIHRvIGZvY3VzIGl0cyBzY29wZSBvbiBh cmVhcyB3aGVyZSBpbm5vdmF0aW9uIGlzIGJlaW5nIHByb3Bvc2VkLiZuYnNwOyBEaWdpdGFsIGlk ZW50aXR5IGNhbiBhbHdheXMgYmUgYWRkZWQgYXMgYSBsYXllciBpZiBuZWVkZWQsDQoganVzdCBh cyBPcGVuSUQgQ29ubmVjdCBsYXllcmVkIGlkZW50aXR5IG9udG8gT0F1dGggMi4wLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IFBsZWFzZSByZXZpc2Ug dGhlIGNoYXJ0ZXIgdG8gcmVtb3ZlIGRpZ2l0YWwgaWRlbnRpdHkgZnJvbSB0aGUgc2NvcGUgb2Yg dGhlIHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsgMi4mbmJzcDsgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhvciBvciBwYXJ0aWNpcGF0ZSBpbiB0 aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IFllczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDMuJm5ic3A7IEFyZSB5b3Ugd2lsbGluZyB0 byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgWWVzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgNC4mbmJzcDsgQXJlIHlvdSBpbnRlcmVzdGVkIGlu IGltcGxlbWVudGluZyBkcmFmdHMgb2YgdGhpcyBXRz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBOb3QgYXQgdGhpcyB0aW1lLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7IEZyb206IFR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDsgT24gQmVoYWxmIE9mIFRv cnN0ZW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7IExvZGRlcnN0ZWR0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsgU2VudDogU2F0dXJkYXksIE1hcmNoIDcsIDIwMjAgNzoxOCBBTTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IFRvOiBZYXJvbiBT aGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+eWFyb25mLmlldGZA Z21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj50eGF1 dGhAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIENhbGwg Zm9yIGNoYXJ0ZXIgY29uc2Vuc3VzIC0gVHhBdXRoDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyBXRzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IEhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyBBbSAwNi4wMy4yMDIwIHVtIDE3OjQ1IHNjaHJpZWIg WWFyb24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnlhcm9u Zi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IO+7v0hpIEV2ZXJ5b25lLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgSXQgYXBw ZWFycyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRp b24gb2YgYSBUeEF1dGggd29ya2luZyBncm91cC4mbmJzcDsgV2XigJlkIGxpa2UgdG8gbW9yZSBm b3JtYWxseSBnYXVnZSBpbnRlcmVzdCBpbiBwcm9jZWVkaW5nIHdpdGggdGhpcyB3b3JrLiZuYnNw OyBQbGVhc2UgZG8gc28gYnkgcmVzcG9uZGluZyB0byB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 IDEuJm5ic3A7IERvIHlvdSBzdXBwb3J0IHRoZSBjaGFydGVyIHRleHQgcHJvdmlkZWQgYXQgdGhl IGVuZCBvZiB0aGlzIGVtYWlsPyZuYnNwOyBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25z LCBibG9ja2luZyBjb25jZXJucyBvciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgSeKAmG0g aW4gYWx0aG91Z2ggSSBoYXZlIHRvIGFkbWl0IEnigJhtIHNsaWdodGx5IGNvbmNlcm5lZCB0aGUg c2NvcGUgb2YgdGhlIGNoYXJ0ZXIgaXMgdG9vIGJyb2FkLCBlLmcuIGlkZW50aWZ5IGFsb25lIGlz IGEgaHVnZSB0b3BpYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyBXZSBuZWVkIHRvIGtlZXAgYW4gZXllIG9uIHRoaXMgYXNwZWN0IGluIG9yZGVyIHRv IG1ha2Ugc3VyZSwgdGhlIGdyb3VwIGlzIGFibGUgdG8gd29yayBlZmZlY3RpdmVseSBhbmQgdGhl IHNwZWNzIHdlIHdpbGwgYmUgcHJvZHVjaW5nIGFyZSBhcyBzaW1wbGUgYXMgcG9zc2libGUgYW5k IGZvc3RlciBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgMi4mbmJzcDsgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhv ciBvciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlz IFdHPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IHll czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg My4mbmJzcDsgQXJlIHlvdSB3aWxsaW5nIHRvIGhlbHAgcmV2aWV3IHRoZSBkcmFmdHMgb2YgdGhp cyBXRz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyB5 ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7 IDQuJm5ic3A7IEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRzIG9mIHRo aXMgV0c/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsg eWVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsgYmVz dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7IFRvcnN0ZW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGUgY2FsbCB3aWxsIHJ1biBmb3IgdHdvIHdlZWtzLCB1bnRpbCBNYXJj aCAyMS4gSWYgeW91IHRoaW5rIHRoYXQgdGhlIGNoYXJ0ZXIgc2hvdWxkIGJlIGFtZW5kZWQgSW4g YSBzaWduaWZpY2FudCB3YXksIHBsZWFzZSByZXBseSBvbiBhIHNlcGFyYXRlIHRocmVhZC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IFRo ZSBmZWVkYmFjayBwcm92aWRlZCBoZXJlIHdpbGwgaGVscCB0aGUgSUVTRyBjb21lIHRvIGEgZGVj aXNpb24gb24gdGhlIGZvcm1hdGlvbiBvZiBhIG5ldyBXRy4gR2l2ZW4gdGhlIGNvbnN0cmFpbnRz IG9mIHRoZSBjaGFydGVyaW5nIHByb2Nlc3MsIHJlZ2FyZGxlc3Mgb2YgdGhlIG91dGNvbWUgb2Yg dGhpcyBjb25zZW5zdXMgY2FsbCwgd2Ugd2lsbCBiZSBtZWV0aW5nIGluIFZhbmNvdXZlciBhcw0K IGEgQm9GLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsm Z3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyZndDsmZ3Q7Jmd0OyBZYXJvbiBhbmQgRGljazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLS0tIENoYXJ0ZXIgVGV4dCBGb2xsb3dz IC0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsgVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5lZCBk ZWxlZ2F0aW9uIHByb3RvY29sIGZvciBhdXRob3JpemF0aW9uLCBpZGVudGl0eSwgYW5kIEFQSSBh Y2Nlc3MuIFRoaXMgcHJvdG9jb2wgd2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0byBk ZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIuDQogSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNlcyBjYXNlcyBjdXJyZW50bHkg c3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgKGl0c2VsZiBhbiBleHRl bnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25zIHNjb3BlZCBhcyBu YXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBhIGNsZWFyIGZyYW1ld29y ayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52b2x2ZWQNCiBpbiB0aGUgcHJv dG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1bm5lY2Vzc2FyeSBkZXBlbmRlbmNlIG9uIGEgYnJvd3Nl ciBvciB1c2VyLWFnZW50IGZvciBjb29yZGluYXRpbmcgaW50ZXJhY3Rpb25zLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgVGhlIGRlbGVn YXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVsdGlwbGUgcGFydGllcyBpbiB0 aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmljIHJvbGUuIFRoZSBwcm90b2Nv bCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVscywgc3VjaCBhcyB0aGUgZW5k IHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwgd2hpY2gNCiBo YXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9BdXRoIDIuMCB3aGljaCBpcyBpbml0aWF0ZWQgYnkg dGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3NlcikuIFRoZSBjbGllbnQg YW5kIEFTIHdpbGwgaW52b2x2ZSBhIHVzZXIgdG8gbWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lz aW9uIGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGludGVyYWN0aW9uDQogbWVjaGFuaXNtcyBpbmRpY2F0 ZWQgYnkgdGhlIHByb3RvY29sLiBUaGlzIGRlY291cGxpbmcgYXZvaWRzIG1hbnkgb2YgdGhlIHNl Y3VyaXR5IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwgY2hhbGxlbmdlcyBvZiBPQXV0aCAyLjAgYW5k IHByb3ZpZGVzIGEgbm9uLWludmFzaXZlIHBhdGggZm9yIHN1cHBvcnRpbmcgZnV0dXJlIHR5cGVz IG9mIGNsaWVudHMgYW5kIGludGVyYWN0aW9uIGNoYW5uZWxzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgQWRkaXRpb25hbGx5LCB0aGUg ZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBGaW5lLWdyYWluZWQgc3BlY2lm aWNhdGlvbiBvZiBhY2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsgLSBBcHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGl0 eSBjbGFpbXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7 Jmd0OyZndDsgLSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBB UElzIGluIGEgc2luZ2xlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsmZ3Q7Jmd0OyZndDsgaW50ZXJhY3Rpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBh cnR5IGF1dGhvcml6aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgb3BlcmF0aW5nIHRoZSBjbGll bnQgcmVxdWVzdGluZyBhY2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBBIHZhcmlldHkgb2YgY2xpZW50IGFwcGxpY2F0aW9ucywg aW5jbHVkaW5nIFdlYiwgbW9iaWxlLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IHNpbmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24tY29u c3RyYWluZWQgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBv aW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMg aW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsm Z3Q7Jmd0OyZndDsgLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2ln bmF0dXJlcywgYW5kIHByb29mIG9mDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgcG9zc2Vzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyAtIFVzZXIgaW50ZXJhY3Rpb24gbWVj aGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHM8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBNZWNoYW5pc21zIGZv ciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgcGll Y2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBNZWNo YW5pc21zIGZvciBwcmVzZW50aW5nIHRva2VucyB0byByZXNvdXJjZSBzZXJ2ZXJzIGFuZCBiaW5k aW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsgcmVzb3VyY2UgcmVxdWVzdHMgdG8gdG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dy YXBoaWMga2V5czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZn dDsmZ3Q7Jmd0OyAtIE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlv biB0aHJvdWdoIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7Jmd0OyZndDsmZ3Q7IGRlbGVnYXRpb24gcHJvY2VzcyAoaW5jbHVkaW5nIGlkZW50aXR5KTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg QWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFn ZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRpbmc6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyAtIERpc2NvdmVyeSBv ZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBSZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbnM8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg LSBRdWVyeSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVyczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgQWx0aG91Z2ggdGhl IGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8g YmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3Qs IHRoZSBncm91cCB3aWxsIGF0dGVtcHQgdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGgg Mi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3IHByb3RvY29sIHdoZXJlDQogcG9zc2li bGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyBUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBleHRlbnNpb25zIHRv IE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBz b2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0 aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0bHkgb24gT0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxv cGVkIGluDQogdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAsIGluY2x1ZGluZyBmdW5jdGlvbmFsaXR5 IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRldmVsb3BlZCBoZXJlIHRvIE9BdXRoIDIu MC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsm Z3Q7IFRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBs eWluZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1Y2ggYXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhl IGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVs b3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1 cyBvbiB1c2luZyBIVFRQIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlv biBmZWF0dXJlcyBvZiBIVFRQMiBhbmQgSFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxsIHN0 cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8NCiBvdGhlciBwcm90b2NvbHMgc3VjaCBh cyBDT0FQIHdoZW4gZG9pbmcgc28gZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgcHJpbWFyeSBm b2N1cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0 OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZn dDsmZ3Q7IE1pbGVzdG9uZXMgdG8gaW5jbHVkZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsgLSBDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2w8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg LSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2Nv bCBmb3IgVExTLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 Jmd0OyZndDsmZ3Q7IGRldGFjaGVkIEhUVFAgc2lnbmF0dXJlLCBhbmQgZW1iZWRkZWQgSFRUUCBz aWduYXR1cmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0 OyZndDsmZ3Q7IC0gSWRlbnRpdHkgYW5kIGF1dGhlbnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFu aXNtczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7 Jmd0OyAtIEd1aWRlbGluZXMgZm9yIHVzZSBvZiBwcm90b2NvbCBleHRlbnNpb24gcG9pbnRzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyZndDsmZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZndDsg LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyZn dDsgVHhhdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+VHhhdXRo QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90eGF1dGgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhh dXRoPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsmZ3Q7Jmd0OyAtLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsmZ3Q7IFR4YXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+VHhh dXRoQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyAt LTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZndDsgVHhhdXRo IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlR4YXV0aEBpZXRmLm9yZzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCI+DQo8c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR00MB0688E4B36EB514D68C0F79EEF5F70MN2PR00MB0688namp_-- From nobody Wed Mar 18 13:53:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C31F3A1C11 for ; Wed, 18 Mar 2020 13:53:14 -0700 (PDT) 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_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=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 3X-P1C-CgR4H for ; Wed, 18 Mar 2020 13:53:12 -0700 (PDT) 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 265DD3A1C10 for ; Wed, 18 Mar 2020 13:53:12 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id a20so32684291edj.2 for ; Wed, 18 Mar 2020 13:53:12 -0700 (PDT) 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=PHER79IC5lluJaRFGG+e34DwrFjeNbMvMqTVpRwI+TM=; b=ErH34wgwYMrJGTzS8zFPZiN17Lkh/eqfP3Ww6MbIH5Nj9t+3gMQ/bCm3PLkmK3pJgY Fbr6cEdmxxgKZ3xVTbxoqsi+ZQmWRHYfwm0ni2Rf6qTOLpn8EzigjMif6mplQUklJxhG 28+H6e+SkeHNc3NkqVfF+8HdbPN17LivOLy1sLiX1QLh+v6flJDuQc/fsCQDkDGiHjgJ xwoZ/TVdJDetH1/z5LJ7fuA9gz90s+2XZBgXpMi4jxNnU59uCUt4vxTC/+p+V+AFRKOi pRoLKSYmdouOAN74722/GMGrImnqsrX1hHCWtIZnPIXBvGe0j0paWDqcCuHSorsZuKGY QmZA== 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=PHER79IC5lluJaRFGG+e34DwrFjeNbMvMqTVpRwI+TM=; b=N7YhU+3z7bJ/Z+M49J6cQmvMWzaMuaRYBNCnF+0wcIju5YSJbna72+c/ygaiy623aC Fe06CvfSALHF40wezDRk9IdwUrGSkxJTmTIgkxigBjHn9oV2Vrcu09XXkJ5j1qNYBC3k jrlp0ccb69M07LmZm5jLOSTgR8iAgjRL1GkfbiurwFoorWhgM7fsy8zo/3FdIas1SI2A sB0ofVYP7/q5E8vuUKd+iPaP5RAJeMTch5HrRfnYpMn3p+lO1SHRMmjXQAeX6TG7X0nq CxMgMOILPM/E/BOukg60buSzjpMEsL4DpYyrbSBxxAxNS+ExOHmLYRthZ27L4Mn8of8g 3hHQ== X-Gm-Message-State: ANhLgQ0cby93iZX63tbCNKgMcpR7obsGhoFE4ua1m2Lnq8Xmk2rqlpuQ wCDMTqc7MIDRQtZ3kI3jMnfyA+zxLLOCa0cietU= X-Google-Smtp-Source: ADFU+vt2wt5qRukZTpx6rCt2lhq4IL/K+E6NhH57d+P/YFg3bAY/HUOcNFpfvWgg7nTvFp9Vn0Q97GTZL4bxNEsODFk= X-Received: by 2002:a17:906:f24e:: with SMTP id gy14mr105765ejb.165.1584564790625; Wed, 18 Mar 2020 13:53:10 -0700 (PDT) MIME-Version: 1.0 References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> In-Reply-To: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> From: David Skaife Date: Wed, 18 Mar 2020 20:53:04 +0000 Message-ID: To: Justin Richer Cc: Dick Hardt , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007807a505a1273d1e" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:53:15 -0000 --0000000000007807a505a1273d1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Stephen and Justin for your responses. I certainly accept some of the points you've raised here. One thing I'd like to add though is that the examples you've provided only show the happy-path scenario (from a client's perspective) - where the AS conveniently supports only one of the capabilities provided by the client. What about if we consider the following scenario: - Client can do A, B, C and D. The AS can do A, B, C, D and E. - The client sends [A, B, C, D]. - Does the AS now send back [A, B, C, D], and then force the client to make a decision (i.e. complexity on the client)? Or instead, does the AS make a decision itself and then only send one result back? If the latter, then how would the AS make this decision, and could this potentially result in an undesirable outcome from a client's perspective? As you've mentioned, in reality the client would likely "remember" the capabilities that the AS supports. So if the AS were instead probed by the client to retrieve the list of its capabilities, this additional complexity needed on the client side would not be something that is present in every interaction - as the client would simply need to pass it's preferred (supported) method on each interaction, rather than having to keep probing and filtering on each request. Additionally, this concept of the client remembering what the AS supports would negate the argument about there being an increase in network traffic raised by Stephen. I don't think it's as clear-cut as you've presented in your responses, but I do accept that there are merits to trying to push complexity to the server. Many thanks, David Skaife On Wed, Mar 18, 2020 at 8:22 PM Justin Richer wrote: > OAuth 2 has taught us that wherever possible, you should push the > complexity to the server, not the client. That=E2=80=99s the idea behind = the kind > of publication/negotiation here where the client can do something simple > and the AS needs to make the actual comparison and decision, whatever tha= t > is. Clients need to stay simple because, for the most part, the focus of > the client is on calling whatever API and implementing whatever > functionality it is doing, not on the security layer. The AS is a dedicat= ed > security component, so it=E2=80=99s got the mandate to figure this stuff = out. This > mindset is one of OAuth 2=E2=80=99s biggest strengths. > > So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t r= eally :used: this > feature beyond making sure the protocol can be passed back and forth, sin= ce > there=E2=80=99s not a lot of optionality that really needs to be negotiat= ed here. > > So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D, a= nd X. If > the client doesn=E2=80=99t know anything at all about the AS, the client = sends: > > [A, B, C] > > And the server looks at that, compares with what it can do, and returns: > > [B] > > The server doesn=E2=80=99t send D, or X, because the client wouldn=E2=80= =99t have any clue > what to do about that. The client can remember that if it wants to cache > that part of the response. > > So the question is, what if the client knew that only B would be > successful for this server? That=E2=80=99s pretty common because a lot of= clients > get written and configured with a static set of capabilities for a server= . > And with the negotiation above, the client just needs to remember after t= he > first call. So in both cases, the client would only send [B], or leave it > off entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80= =99re done. > > But the thing is, you could do both styles with one simple twist. If you > want to do the discovery portion in a pre-flight request, I think it=E2= =80=99s a > good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t make an= y sense to > me to allow it on any other endpoints, especially because some of those a= re > going to be user-facing (so the client is not going to be talking to the > URL itself). The client makes this call and gets back: > > [B, D, X] > > And now the client has to put together its possible capabilities from tha= t > list and what it knows it can do. By putting OPTIONS on the endpoint then > we can stick with the same mantra of the client having one piece of info = to > get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and learnin= g everything else from > that. I think that part is simple enough to potentially work, and XYZ > doesn=E2=80=99t have other endpoints or aspects that need to be discovere= d out of > band, unlike OAuth 2. > > =E2=80=94 Justin > > > > On Mar 18, 2020, at 3:44 PM, David Skaife < > blue.ringed.octopus.guy@gmail.com> wrote: > > Hi, > > My thoughts on these different approaches are: > > 1. For XYZ, it feels a bit strange and unnecessary to require the client > to have to state it's full set of capabilities to the AS. It feels like i= t > should be the other way around - i.e. the client is able to probe what th= e > AS supports. In my view it's more natural for the AS to be "advertising" > its capabilities rather than the client. > > 2. I prefer the XYZ approach of having a single URL that the client knows > it needs to interact to start the transaction, vs the more complex > approach provided by XAuth. > > 3. Hopefully there is a middle ground between the two approaches that > addresses the two points above. > > > Many thanks, > David Skaife > > On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote: > >> >> *Discovery* >> XYZ >> - Client always starts at the tx endpoint, all other information is >> dispatched from responses from the endpoint >> - Clients sends capabilities list in transaction request, AS selects an= d >> returns which capabilities are supported >> >> XYZ Rationale: client needs a single URL to start talking to an AS, >> giving developers multiple ways to get information is confusing and can >> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OID= C=E2=80=99s >> discovery approach) >> >> XAuth >> - Client sends an OPTIONS call to the GS URI, Grant URI, or >> Authorization URI >> >> XAuth Rationale: Client can make unauthenticated call to GS URI to learn >> what GS supports, such as authentication mechanisms. Authenticated calls >> return what a specific Client can do. >> >> >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --0000000000007807a505a1273d1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Stephen and Justin for your responses.

I cer= tainly accept some of the points you've raised here. One thing I'd = like to add though is that the examples you've provided only show the h= appy-path scenario (from a client's perspective) - where the AS conveni= ently supports only one of the capabilities provided by the client. What ab= out if we consider the following scenario:

- Client can do A, B, C a= nd D. The AS can do A, B, C, D and E.
- The client sends [A, B, C, D].- Does the AS now send back [A, B, C, D], and then force the client to ma= ke a decision (i.e. complexity on the client)? Or instead, does the AS make= a decision=C2=A0itself and then only send one result back? If the latter, = then how would the AS make this decision, and could this potentially result= in an undesirable outcome from a client's perspective?

As you&#= 39;ve mentioned, in reality the client would likely "remember" th= e capabilities=C2=A0that the AS supports. So if the AS were instead probed = by the client to retrieve the list of its capabilities, this additional com= plexity needed on the client side would not be something that is present in= every interaction - as the client would simply need to pass it's prefe= rred (supported) method on each interaction, rather than having to keep pro= bing and filtering on each request. Additionally, this concept of the clien= t remembering what the AS supports would negate the argument about there be= ing an increase in network traffic raised by Stephen.

I don't th= ink it's as clear-cut as you've presented in your responses, but I = do accept that there are merits to trying to push complexity to the server.=


Many thanks,
David Skaife

On Wed, Mar 18, 2020 at 8:22 PM Jus= tin Richer <jricher@mit.edu> w= rote:
OAuth 2 has taught us that wherever possibl= e, you should push the complexity to the server, not the client. That=E2=80= =99s the idea behind the kind of publication/negotiation here where the cli= ent can do something simple and the AS needs to make the actual comparison = and decision, whatever that is. Clients need to stay simple because, for th= e most part, the focus of the client is on calling whatever API and impleme= nting whatever functionality it is doing, not on the security layer. The AS= is a dedicated security component, so it=E2=80=99s got the mandate to figu= re this stuff out. This mindset is one of OAuth 2=E2=80=99s biggest strengt= hs.=C2=A0

So how would this work in XYZ? I=E2=80=99ll sa= y that we haven=E2=80=99t really :used: this feature beyond making sure the= protocol can be passed back and forth, since there=E2=80=99s not a lot of = optionality that really needs to be negotiated here.

So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D, an= d X. If the client doesn=E2=80=99t know anything at all about the AS, the c= lient sends:

[A, B, C]

An= d the server looks at that, compares with what it can do, and returns:

[B]

The server doesn=E2=80=99= t send D, or X, because the client wouldn=E2=80=99t have any clue what to d= o about that. The client can remember that if it wants to cache that part o= f the response.

So the question is, what if the cl= ient knew that only B would be successful for this server? That=E2=80=99s p= retty common because a lot of clients get written and configured with a sta= tic set of capabilities for a server. And with the negotiation above, the c= lient just needs to remember after the first call. So in both cases, the cl= ient would only send [B], or leave it off entirely because it doesn=E2=80= =99t need to negotiate, and you=E2=80=99re done.=C2=A0

=
But the thing is, you could do both styles with one simple twist. If y= ou want to do the discovery portion in a pre-flight request, I think it=E2= =80=99s a good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t= make any sense to me to allow it on any other endpoints, especially becaus= e some of those are going to be user-facing (so the client is not going to = be talking to the URL itself). The client makes this call and gets back:

[B, D, X]

And now the clien= t has to put together its possible capabilities from that list and what it = knows it can do. By putting OPTIONS on the endpoint then we can stick with = the same mantra of the client having one piece of info to get started =E2= =80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and learning everything else= from that. I think that part is simple enough to potentially work, and XYZ= doesn=E2=80=99t have other endpoints or aspects that need to be discovered= out of band, unlike OAuth 2.

=C2=A0=E2=80=94 Just= in



On = Mar 18, 2020, at 3:44 PM, David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoug= hts on these different approaches are:

1. For XYZ, it feels a bit st= range and unnecessary to require the client to have to state it's full = set of capabilities to the AS. It feels like it should be the other way aro= und - i.e. the client is able to probe what the AS supports. In my view it&= #39;s more natural for the AS to be "advertising" its capabilitie= s rather than the client.

2. I prefer the XYZ approach of having a s= ingle URL that the client knows it needs to interact to start the transacti= on, vs the more complex approach=C2=A0provided by XAuth.

3. Hopefull= y there is a middle ground between the two approaches that addresses the tw= o points above.


Many thanks,
David Skaife

On Mon, Mar 16= , 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery
<= br>XYZ
=C2=A0- Client always starts at the tx endpoint, all other inform= ation is dispatched from responses from the endpoint
=C2=A0- Clients sen= ds capabilities list in transaction request, AS selects and returns which c= apabilities are supported

XYZ Rationale: client needs a single URL t= o start talking to an AS, giving developers multiple ways to get informatio= n is confusing and can lead to serious errors (see OAuth2=E2=80=99s mix-up = attack caused by OIDC=E2=80=99s discovery approach)

XAuth
=C2=A0-= Client sends an OPTIONS call to the GS URI, Grant URI, or Authorization UR= I

XAuth Rationale: Client can make unauthenticated call to GS URI to= learn what GS supports, such as authentication mechanisms. Authenticated c= alls return what a specific Client can do.


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--0000000000007807a505a1273d1e-- From nobody Wed Mar 18 14:05:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B711E3A1C33 for ; Wed, 18 Mar 2020 14:05:00 -0700 (PDT) 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, 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 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 MDSSWlL-FjOT for ; Wed, 18 Mar 2020 14:04:58 -0700 (PDT) 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 E99FB3A1C34 for ; Wed, 18 Mar 2020 14:04:57 -0700 (PDT) Received: from [192.168.1.5] (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 02IL4riR025090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 17:04:54 -0400 From: Justin Richer Message-Id: <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_65B35968-1634-4854-AE94-BEEE8A104628" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Mar 2020 17:04:53 -0400 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org To: David Skaife References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:05:01 -0000 --Apple-Mail=_65B35968-1634-4854-AE94-BEEE8A104628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wasn=E2=80=99t showing just the happy path, but I think my example = might have been too simple. Also, I think we've got a different model = for what=E2=80=99s in the capabilities. It=E2=80=99s not about a set of = mutually exclusive options that the client has to choose from. > Thanks Stephen and Justin for your responses. >=20 > I certainly accept some of the points you've raised here. One thing = I'd like to add though is that the examples you've provided only show = the happy-path scenario (from a client's perspective) - where the AS = conveniently supports only one of the capabilities provided by the = client. What about if we consider the following scenario: >=20 > - Client can do A, B, C and D. The AS can do A, B, C, D and E. > - The client sends [A, B, C, D]. > - Does the AS now send back [A, B, C, D] Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset of = the client=E2=80=99s capabilities.=20 > , and then force the client to make a decision (i.e. complexity on the = client)? Or instead, does the AS make a decision itself and then only = send one result back? If the latter, then how would the AS make this = decision, and could this potentially result in an undesirable outcome = from a client's perspective? The client is already declaring that it can do all of those, and so it = needs to figure out which of those it=E2=80=99s going to use and how = they work together. My intent wasn=E2=80=99t to say that the client = could only do one of those at a time, but rather that these were = different things that the client could support that were optional at the = AS, and the AS is telling the client which bits that it knows about and = can handle. Maybe this is a list of extensions, maybe it=E2=80=99s a = list of optional features, but it=E2=80=99s on top of the =E2=80=9Ccore=E2= =80=9D portions of the protocol.=20 I=E2=80=99ll also say that this is completely separate from the = discussion on how to handle interaction =E2=80=94 I think the = information patterns on that (which are in a different thread) are much = clearer.=20 >=20 > As you've mentioned, in reality the client would likely "remember" the = capabilities that the AS supports. So if the AS were instead probed by = the client to retrieve the list of its capabilities, this additional = complexity needed on the client side would not be something that is = present in every interaction - as the client would simply need to pass = it's preferred (supported) method on each interaction, rather than = having to keep probing and filtering on each request. Additionally, this = concept of the client remembering what the AS supports would negate the = argument about there being an increase in network traffic raised by = Stephen. The reality is that most clients aren=E2=80=99t really going to discover = and declare things, especially if the client can start the whole = protocol with just one bit of information. XYZ originally started with = zero discovery, because all of the important parts are revealed during = the protocol.=20 >=20 > I don't think it's as clear-cut as you've presented in your responses, = but I do accept that there are merits to trying to push complexity to = the server. >=20 I agree that it=E2=80=99s not that clear cut yet =E2=80=94 but that=E2=80=99= s largely because there aren=E2=80=99t a lot of concrete things that = would go in this =E2=80=9Cdiscovery=E2=80=9D document yet. At least with = XYZ, we deliberately minimized what the client would need to know going = in, for both simplicity and security. When you make the core protocol = such that you don=E2=80=99t need a lot of extra bits in order for things = to function, then you aren=E2=80=99t creating problems that you need = solutions for. Thanks for raising the discussion! >=20 > Many thanks, > David Skaife >=20 > On Wed, Mar 18, 2020 at 8:22 PM Justin Richer > wrote: > OAuth 2 has taught us that wherever possible, you should push the = complexity to the server, not the client. That=E2=80=99s the idea behind = the kind of publication/negotiation here where the client can do = something simple and the AS needs to make the actual comparison and = decision, whatever that is. Clients need to stay simple because, for the = most part, the focus of the client is on calling whatever API and = implementing whatever functionality it is doing, not on the security = layer. The AS is a dedicated security component, so it=E2=80=99s got the = mandate to figure this stuff out. This mindset is one of OAuth 2=E2=80=99s= biggest strengths.=20 >=20 > So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t = really :used: this feature beyond making sure the protocol can be passed = back and forth, since there=E2=80=99s not a lot of optionality that = really needs to be negotiated here. >=20 > So let=E2=80=99s say the client can do A, B, and C. The AS can do B, = D, and X. If the client doesn=E2=80=99t know anything at all about the = AS, the client sends: >=20 > [A, B, C] >=20 > And the server looks at that, compares with what it can do, and = returns: >=20 > [B] >=20 > The server doesn=E2=80=99t send D, or X, because the client wouldn=E2=80= =99t have any clue what to do about that. The client can remember that = if it wants to cache that part of the response. >=20 > So the question is, what if the client knew that only B would be = successful for this server? That=E2=80=99s pretty common because a lot = of clients get written and configured with a static set of capabilities = for a server. And with the negotiation above, the client just needs to = remember after the first call. So in both cases, the client would only = send [B], or leave it off entirely because it doesn=E2=80=99t need to = negotiate, and you=E2=80=99re done.=20 >=20 > But the thing is, you could do both styles with one simple twist. If = you want to do the discovery portion in a pre-flight request, I think = it=E2=80=99s a good idea to allow OPTIONS on the tx endpoint. It = doesn=E2=80=99t make any sense to me to allow it on any other endpoints, = especially because some of those are going to be user-facing (so the = client is not going to be talking to the URL itself). The client makes = this call and gets back: >=20 > [B, D, X] >=20 > And now the client has to put together its possible capabilities from = that list and what it knows it can do. By putting OPTIONS on the = endpoint then we can stick with the same mantra of the client having one = piece of info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80= =94 and learning everything else from that. I think that part is simple = enough to potentially work, and XYZ doesn=E2=80=99t have other endpoints = or aspects that need to be discovered out of band, unlike OAuth 2. >=20 > =E2=80=94 Justin >=20 >=20 >=20 >> On Mar 18, 2020, at 3:44 PM, David Skaife = > wrote: >>=20 >> Hi, >>=20 >> My thoughts on these different approaches are: >>=20 >> 1. For XYZ, it feels a bit strange and unnecessary to require the = client to have to state it's full set of capabilities to the AS. It = feels like it should be the other way around - i.e. the client is able = to probe what the AS supports. In my view it's more natural for the AS = to be "advertising" its capabilities rather than the client. >>=20 >> 2. I prefer the XYZ approach of having a single URL that the client = knows it needs to interact to start the transaction, vs the more complex = approach provided by XAuth. >>=20 >> 3. Hopefully there is a middle ground between the two approaches that = addresses the two points above. >>=20 >>=20 >> Many thanks, >> David Skaife >>=20 >> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt > wrote: >> Discovery >>=20 >> XYZ >> - Client always starts at the tx endpoint, all other information is = dispatched from responses from the endpoint >> - Clients sends capabilities list in transaction request, AS selects = and returns which capabilities are supported >>=20 >> XYZ Rationale: client needs a single URL to start talking to an AS, = giving developers multiple ways to get information is confusing and can = lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by = OIDC=E2=80=99s discovery approach) >>=20 >> XAuth >> - Client sends an OPTIONS call to the GS URI, Grant URI, or = Authorization URI >>=20 >> XAuth Rationale: Client can make unauthenticated call to GS URI to = learn what GS supports, such as authentication mechanisms. Authenticated = calls return what a specific Client can do. >>=20 >>=20 >> =E1=90=A7 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_65B35968-1634-4854-AE94-BEEE8A104628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = wasn=E2=80=99t showing just the happy path, but I think my example might = have been too simple. Also, I think we've got a different model for = what=E2=80=99s in the capabilities. It=E2=80=99s not about a set of = mutually exclusive options that the client has to choose from.

Thanks Stephen and Justin for your responses.

I certainly accept = some of the points you've raised here. One thing I'd like to add though = is that the examples you've provided only show the happy-path scenario = (from a client's perspective) - where the AS conveniently supports only = one of the capabilities provided by the client. What about if we = consider the following scenario:

- Client = can do A, B, C and D. The AS can do A, B, C, D and E.
- = The client sends [A, B, C, D].
- Does the AS now send back = [A, B, C, D]

Yes, = the AS sends back [A, B, C, D] because that=E2=80=99s the subset of the = client=E2=80=99s capabilities. 

, = and then force the client to make a decision (i.e. complexity on the = client)? Or instead, does the AS make a decision itself and then = only send one result back? If the latter, then how would the AS make = this decision, and could this potentially result in an undesirable = outcome from a client's perspective?

The = client is already declaring that it can do all of those, and so it needs = to figure out which of those it=E2=80=99s going to use and how they work = together. My intent wasn=E2=80=99t to say that the client could only do = one of those at a time, but rather that these were different things that = the client could support that were optional at the AS, and the AS is = telling the client which bits that it knows about and can handle. Maybe = this is a list of extensions, maybe it=E2=80=99s a list of optional = features, but it=E2=80=99s on top of the =E2=80=9Ccore=E2=80=9D portions = of the protocol. 

I=E2=80=99ll = also say that this is completely separate from the discussion on how to = handle interaction =E2=80=94 I think the information patterns on that = (which are in a different thread) are much clearer. 


As you've mentioned, in reality = the client would likely "remember" the capabilities that the AS = supports. So if the AS were instead probed by the client to retrieve the = list of its capabilities, this additional complexity needed on the = client side would not be something that is present in every interaction = - as the client would simply need to pass it's preferred (supported) = method on each interaction, rather than having to keep probing and = filtering on each request. Additionally, this concept of the client = remembering what the AS supports would negate the argument about there = being an increase in network traffic raised by Stephen.

The = reality is that most clients aren=E2=80=99t really going to discover and = declare things, especially if the client can start the whole protocol = with just one bit of information. XYZ originally started with zero = discovery, because all of the important parts are revealed during the = protocol. 


I = don't think it's as clear-cut as you've presented in your responses, but = I do accept that there are merits to trying to push complexity to the = server.


I agree that it=E2=80=99s not that clear cut yet = =E2=80=94 but that=E2=80=99s largely because there aren=E2=80=99t a lot = of concrete things that would go in this =E2=80=9Cdiscovery=E2=80=9D = document yet. At least with XYZ, we deliberately minimized what the = client would need to know going in, for both simplicity and security. = When you make the core protocol such that you don=E2=80=99t need a lot = of extra bits in order for things to function, then you aren=E2=80=99t = creating problems that you need solutions for.

Thanks for raising the discussion!


Many thanks,
David = Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer = <jricher@mit.edu> = wrote:
OAuth 2 has taught us that wherever possible, = you should push the complexity to the server, not the client. That=E2=80=99= s the idea behind the kind of publication/negotiation here where the = client can do something simple and the AS needs to make the actual = comparison and decision, whatever that is. Clients need to stay simple = because, for the most part, the focus of the client is on calling = whatever API and implementing whatever functionality it is doing, not on = the security layer. The AS is a dedicated security component, so it=E2=80=99= s got the mandate to figure this stuff out. This mindset is one of OAuth = 2=E2=80=99s biggest strengths. 

So how would this work in XYZ? I=E2=80=99= ll say that we haven=E2=80=99t really :used: this feature beyond making = sure the protocol can be passed back and forth, since there=E2=80=99s = not a lot of optionality that really needs to be negotiated here.

So = let=E2=80=99s say the client can do A, B, and C. The AS can do B, D, and = X. If the client doesn=E2=80=99t know anything at all about the AS, the = client sends:

[A, B, C]

And the server looks at that, compares with what it can do, = and returns:

[B]

The server doesn=E2=80=99t send D, or X, because the client = wouldn=E2=80=99t have any clue what to do about that. The client can = remember that if it wants to cache that part of the response.

So the question is, what = if the client knew that only B would be successful for this server? = That=E2=80=99s pretty common because a lot of clients get written and = configured with a static set of capabilities for a server. And with the = negotiation above, the client just needs to remember after the first = call. So in both cases, the client would only send [B], or leave it off = entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80=99re = done. 

But = the thing is, you could do both styles with one simple twist. If you = want to do the discovery portion in a pre-flight request, I think it=E2=80= =99s a good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t = make any sense to me to allow it on any other endpoints, especially = because some of those are going to be user-facing (so the client is not = going to be talking to the URL itself). The client makes this call and = gets back:

[B, = D, X]

And now = the client has to put together its possible capabilities from that list = and what it knows it can do. By putting OPTIONS on the endpoint then we = can stick with the same mantra of the client having one piece of info to = get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and = learning everything else from that. I think that part is simple enough = to potentially work, and XYZ doesn=E2=80=99t have other endpoints or = aspects that need to be discovered out of band, unlike OAuth = 2.

 =E2=80=94= Justin



On Mar 18, 2020, at 3:44 PM, David Skaife = <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoughts on these = different approaches are:

1. For XYZ, it = feels a bit strange and unnecessary to require the client to have to = state it's full set of capabilities to the AS. It feels like it should = be the other way around - i.e. the client is able to probe what the AS = supports. In my view it's more natural for the AS to be "advertising" = its capabilities rather than the client.

2. = I prefer the XYZ approach of having a single URL that the client knows = it needs to interact to start the transaction, vs the more complex = approach provided by XAuth.

3. = Hopefully there is a middle ground between the two approaches that = addresses the two points above.


Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery

XYZ
 - Client always starts at the tx endpoint, all other = information is dispatched from responses from the endpoint
 - Clients sends capabilities list in transaction = request, AS selects and returns which capabilities are supported

XYZ Rationale: client needs a single URL to = start talking to an AS, giving developers multiple ways to get = information is confusing and can lead to serious errors (see OAuth2=E2=80=99= s mix-up attack caused by OIDC=E2=80=99s discovery approach)

XAuth
 - Client sends an = OPTIONS call to the GS URI, Grant URI, or Authorization URI

XAuth Rationale: Client can make = unauthenticated call to GS URI to learn what GS supports, such as = authentication mechanisms. Authenticated calls return what a specific = Client can do.


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


= --Apple-Mail=_65B35968-1634-4854-AE94-BEEE8A104628-- From nobody Wed Mar 18 14:10:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB083A1C53 for ; Wed, 18 Mar 2020 14:10:42 -0700 (PDT) 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_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=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 HVKzIWBjup2u for ; Wed, 18 Mar 2020 14:10:39 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 9D90B3A1C4E for ; Wed, 18 Mar 2020 14:10:39 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id e11so41350889qkg.9 for ; Wed, 18 Mar 2020 14:10:39 -0700 (PDT) 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=YqT0fYki3Scp51rPMXm7dNROeE3j4B3eAzhpp0Xx4O4=; b=ozOajzGOhMlPt6BDIvbK5fJ2KP3w8M81JV5cPFUJpouOIjjY+5eARORmJXTzTdLVXH OfnaYS5SZUVmvPM2J9Cj6N5qC77Zw5yF9Fdv3E/R4cYJHKhVACCNaBA1OgCXzxa/nam0 GSiCs4EYdn/6V77w34Mjzw+6aXv2RVqRDU6DxDam8c/ALfcwAooFV1EZmGW1YV3yDKib uAzns39uQSN2K7xIqq5DxmTzAZsn6abL3hKk0F7JHN4/QZ+wRZgukW20t+272fYco8fx 4SlGw84fnxTonV5wFFUdJXUrHN911Fn39xsX8bZJ4zm+vj8nVvaEFfqh7gL+NeXXWCXf nX3w== 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=YqT0fYki3Scp51rPMXm7dNROeE3j4B3eAzhpp0Xx4O4=; b=Zq7t7hPv0Z9G8yhLzQpL4mYSUaT1gZIOYXnJrlWRZmIRv3/ejaZbtU3ZCueyAufSZZ kHqXW0gycPTDAZdp2ONDR3wJarIE5me/Lyd02RTkhB3ezV7mavz4habTaPGZJIHl4bZj YtLFIohPZVgzcaNok3ueeKY+tVAXJ9W9BHB6pUbDQkKFywnir2IkhkvLYDCbTax5wEnI V2sQu3kXSR42VPtpJAjUTGtbL6J5gXNW5V9+MnZhchlGQvFFezvStmsD4ffi1kV4WlFL 3KkHQcbQ2ZXk/LfYKu1SeEgzefeVko5WnpIShEIx5X2+Mtu3gtzMfa8aMZ3n4qpRyXIw WhpQ== X-Gm-Message-State: ANhLgQ2+87PBHeFcsCovNgftN0s9kaXVJx87UsXehLKKGtdeIBoOw7BO 6gYutZN6QHkGUO2L5VGDD3ABP4wZfM7QazStg74= X-Google-Smtp-Source: ADFU+vvz79jHhkP4qryybMrbxPqeWlCWlMWM3kahB0SKoFZBJZfJ5r7b4jhn/ONwqpC3l7SUD9u3oecMtx8lihw53fw= X-Received: by 2002:a25:34c2:: with SMTP id b185mr9881194yba.57.1584565838548; Wed, 18 Mar 2020 14:10:38 -0700 (PDT) MIME-Version: 1.0 References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> In-Reply-To: From: Stephen Moore Date: Wed, 18 Mar 2020 17:10:25 -0400 Message-ID: To: David Skaife Cc: Justin Richer , txauth@ietf.org, Dick Hardt Content-Type: multipart/alternative; boundary="000000000000ee12ab05a1277b7b" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:10:42 -0000 --000000000000ee12ab05a1277b7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think I'd be happy in either case, I have a feeling though, in like 99% of the case it'll pick the first one. So a question there is, does order matter? If you enforce order, I'd say the client sends what it can do in order of preference, and the AS responds in kind. (As in the AS could switch the order to what it wants, or just leaves the order as the client sent it. That way the client picks the first one and runs with it. As for the remembering bit... again on a dead small micro that can speak wifi, you can't count on it remembering anything... space is at a premium too. Caching is a client side option... not a requirement as I see it. -steve On Wed, Mar 18, 2020 at 4:53 PM David Skaife < blue.ringed.octopus.guy@gmail.com> wrote: > Thanks Stephen and Justin for your responses. > > I certainly accept some of the points you've raised here. One thing I'd > like to add though is that the examples you've provided only show the > happy-path scenario (from a client's perspective) - where the AS > conveniently supports only one of the capabilities provided by the client= . > What about if we consider the following scenario: > > - Client can do A, B, C and D. The AS can do A, B, C, D and E. > - The client sends [A, B, C, D]. > - Does the AS now send back [A, B, C, D], and then force the client to > make a decision (i.e. complexity on the client)? Or instead, does the AS > make a decision itself and then only send one result back? If the latter, > then how would the AS make this decision, and could this potentially resu= lt > in an undesirable outcome from a client's perspective? > > As you've mentioned, in reality the client would likely "remember" the > capabilities that the AS supports. So if the AS were instead probed by th= e > client to retrieve the list of its capabilities, this additional complexi= ty > needed on the client side would not be something that is present in every > interaction - as the client would simply need to pass it's preferred > (supported) method on each interaction, rather than having to keep probin= g > and filtering on each request. Additionally, this concept of the client > remembering what the AS supports would negate the argument about there > being an increase in network traffic raised by Stephen. > > I don't think it's as clear-cut as you've presented in your responses, bu= t > I do accept that there are merits to trying to push complexity to the > server. > > > Many thanks, > David Skaife > > On Wed, Mar 18, 2020 at 8:22 PM Justin Richer wrote: > >> OAuth 2 has taught us that wherever possible, you should push the >> complexity to the server, not the client. That=E2=80=99s the idea behind= the kind >> of publication/negotiation here where the client can do something simple >> and the AS needs to make the actual comparison and decision, whatever th= at >> is. Clients need to stay simple because, for the most part, the focus of >> the client is on calling whatever API and implementing whatever >> functionality it is doing, not on the security layer. The AS is a dedica= ted >> security component, so it=E2=80=99s got the mandate to figure this stuff= out. This >> mindset is one of OAuth 2=E2=80=99s biggest strengths. >> >> So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t = really :used: >> this feature beyond making sure the protocol can be passed back and fort= h, >> since there=E2=80=99s not a lot of optionality that really needs to be n= egotiated >> here. >> >> So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D, = and X. If >> the client doesn=E2=80=99t know anything at all about the AS, the client= sends: >> >> [A, B, C] >> >> And the server looks at that, compares with what it can do, and returns: >> >> [B] >> >> The server doesn=E2=80=99t send D, or X, because the client wouldn=E2=80= =99t have any >> clue what to do about that. The client can remember that if it wants to >> cache that part of the response. >> >> So the question is, what if the client knew that only B would be >> successful for this server? That=E2=80=99s pretty common because a lot o= f clients >> get written and configured with a static set of capabilities for a serve= r. >> And with the negotiation above, the client just needs to remember after = the >> first call. So in both cases, the client would only send [B], or leave i= t >> off entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80= =99re done. >> >> But the thing is, you could do both styles with one simple twist. If you >> want to do the discovery portion in a pre-flight request, I think it=E2= =80=99s a >> good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t make a= ny sense to >> me to allow it on any other endpoints, especially because some of those = are >> going to be user-facing (so the client is not going to be talking to the >> URL itself). The client makes this call and gets back: >> >> [B, D, X] >> >> And now the client has to put together its possible capabilities from >> that list and what it knows it can do. By putting OPTIONS on the endpoin= t >> then we can stick with the same mantra of the client having one piece of >> info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 an= d learning everything else >> from that. I think that part is simple enough to potentially work, and X= YZ >> doesn=E2=80=99t have other endpoints or aspects that need to be discover= ed out of >> band, unlike OAuth 2. >> >> =E2=80=94 Justin >> >> >> >> On Mar 18, 2020, at 3:44 PM, David Skaife < >> blue.ringed.octopus.guy@gmail.com> wrote: >> >> Hi, >> >> My thoughts on these different approaches are: >> >> 1. For XYZ, it feels a bit strange and unnecessary to require the client >> to have to state it's full set of capabilities to the AS. It feels like = it >> should be the other way around - i.e. the client is able to probe what t= he >> AS supports. In my view it's more natural for the AS to be "advertising" >> its capabilities rather than the client. >> >> 2. I prefer the XYZ approach of having a single URL that the client know= s >> it needs to interact to start the transaction, vs the more complex >> approach provided by XAuth. >> >> 3. Hopefully there is a middle ground between the two approaches that >> addresses the two points above. >> >> >> Many thanks, >> David Skaife >> >> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote= : >> >>> >>> *Discovery* >>> XYZ >>> - Client always starts at the tx endpoint, all other information is >>> dispatched from responses from the endpoint >>> - Clients sends capabilities list in transaction request, AS selects >>> and returns which capabilities are supported >>> >>> XYZ Rationale: client needs a single URL to start talking to an AS, >>> giving developers multiple ways to get information is confusing and can >>> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OI= DC=E2=80=99s >>> discovery approach) >>> >>> XAuth >>> - Client sends an OPTIONS call to the GS URI, Grant URI, or >>> Authorization URI >>> >>> XAuth Rationale: Client can make unauthenticated call to GS URI to lear= n >>> what GS supports, such as authentication mechanisms. Authenticated call= s >>> return what a specific Client can do. >>> >>> >>> =E1=90=A7 >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ee12ab05a1277b7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I'd be happy in either case,=C2=A0
I have = a feeling though, in like 99% of the case it'll pick the first one. So = a question there is, does order matter? If you enforce order, I'd say t= he client sends what it can do in order of preference, and the AS responds = in kind. (As in the AS could switch the order to what it wants, or just lea= ves the order as the client sent it. That way the client picks the first on= e and runs with it.=C2=A0

As for the remembering b= it... again on a dead small micro that can speak wifi, you can't count = on it remembering anything... space is at a premium too. Caching is a clien= t side option... not a requirement as I see it.
-steve

On We= d, Mar 18, 2020 at 4:53 PM David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:
<= /div>
Tha= nks Stephen and Justin for your responses.

I certainly accept some o= f the points you've raised here. One thing I'd like to add though i= s that the examples you've provided only show the happy-path scenario (= from a client's perspective) - where the AS conveniently supports only = one of the capabilities provided by the client. What about if we consider t= he following scenario:

- Client can do A, B, C and D. The AS can do = A, B, C, D and E.
- The client sends [A, B, C, D].
- Does the AS now = send back [A, B, C, D], and then force the client to make a decision (i.e. = complexity on the client)? Or instead, does the AS make a decision=C2=A0its= elf and then only send one result back? If the latter, then how would the A= S make this decision, and could this potentially result in an undesirable o= utcome from a client's perspective?

As you've mentioned, in = reality the client would likely "remember" the capabilities=C2=A0= that the AS supports. So if the AS were instead probed by the client to ret= rieve the list of its capabilities, this additional complexity needed on th= e client side would not be something that is present in every interaction -= as the client would simply need to pass it's preferred (supported) met= hod on each interaction, rather than having to keep probing and filtering o= n each request. Additionally, this concept of the client remembering what t= he AS supports would negate the argument about there being an increase in n= etwork traffic raised by Stephen.

I don't think it's as clea= r-cut as you've presented in your responses, but I do accept that there= are merits to trying to push complexity to the server.


Many tha= nks,
David Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer <jricher@mit.edu> wro= te:
OAuth 2= has taught us that wherever possible, you should push the complexity to th= e server, not the client. That=E2=80=99s the idea behind the kind of public= ation/negotiation here where the client can do something simple and the AS = needs to make the actual comparison and decision, whatever that is. Clients= need to stay simple because, for the most part, the focus of the client is= on calling whatever API and implementing whatever functionality it is doin= g, not on the security layer. The AS is a dedicated security component, so = it=E2=80=99s got the mandate to figure this stuff out. This mindset is one = of OAuth 2=E2=80=99s biggest strengths.=C2=A0

So how wou= ld this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t really :used:= this feature beyond making sure the protocol can be passed back and forth,= since there=E2=80=99s not a lot of optionality that really needs to be neg= otiated here.

So let=E2=80=99s say the client can do= A, B, and C. The AS can do B, D, and X. If the client doesn=E2=80=99t know= anything at all about the AS, the client sends:

[= A, B, C]

And the server looks at that, compares wi= th what it can do, and returns:

[B]

=
The server doesn=E2=80=99t send D, or X, because the client woul= dn=E2=80=99t have any clue what to do about that. The client can remember t= hat if it wants to cache that part of the response.

So the question is, what if the client knew that only B would be successf= ul for this server? That=E2=80=99s pretty common because a lot of clients g= et written and configured with a static set of capabilities for a server. A= nd with the negotiation above, the client just needs to remember after the = first call. So in both cases, the client would only send [B], or leave it o= ff entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80=99r= e done.=C2=A0

But the thing is, you could do both = styles with one simple twist. If you want to do the discovery portion in a = pre-flight request, I think it=E2=80=99s a good idea to allow OPTIONS on th= e tx endpoint. It doesn=E2=80=99t make any sense to me to allow it on any o= ther endpoints, especially because some of those are going to be user-facin= g (so the client is not going to be talking to the URL itself). The client = makes this call and gets back:

[B, D, X]

And now the client has to put together its possible capabil= ities from that list and what it knows it can do. By putting OPTIONS on the= endpoint then we can stick with the same mantra of the client having one p= iece of info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80= =94 and learning everything else from that. I think that part is simple eno= ugh to potentially work, and XYZ doesn=E2=80=99t have other endpoints or as= pects that need to be discovered out of band, unlike OAuth 2.
=C2=A0=E2=80=94 Justin



On Mar 18, 2020, at 3:44 PM, David Skaife <= blue= .ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoughts on these different approaches are:
<= br>1. For XYZ, it feels a bit strange and unnecessary to require the client= to have to state it's full set of capabilities to the AS. It feels lik= e it should be the other way around - i.e. the client is able to probe what= the AS supports. In my view it's more natural for the AS to be "a= dvertising" its capabilities rather than the client.

2. I prefe= r the XYZ approach of having a single URL that the client knows it needs to= interact to start the transaction, vs the more complex approach=C2=A0provi= ded by XAuth.

3. Hopefully there is a middle ground between the two = approaches that addresses the two points above.


Many thanks,
= David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com= > wrote:
Discovery

XYZ
=C2=A0- Client always starts at= the tx endpoint, all other information is dispatched from responses from t= he endpoint
=C2=A0- Clients sends capabilities list in transaction reque= st, AS selects and returns which capabilities are supported

XYZ Rati= onale: client needs a single URL to start talking to an AS, giving develope= rs multiple ways to get information is confusing and can lead to serious er= rors (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s discovery= approach)

XAuth
=C2=A0- Client sends an OPTIONS call to the GS U= RI, Grant URI, or Authorization URI

XAuth Rationale: Client can make= unauthenticated call to GS URI to learn what GS supports, such as authenti= cation mechanisms. Authenticated calls return what a specific Client can do= .


= 3D""= =E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ee12ab05a1277b7b-- From nobody Wed Mar 18 14:18:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152D03A1C74 for ; Wed, 18 Mar 2020 14:18:39 -0700 (PDT) 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, 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 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 QyPi-zfm9PBx for ; Wed, 18 Mar 2020 14:18:36 -0700 (PDT) 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 994923A1C81 for ; Wed, 18 Mar 2020 14:18:35 -0700 (PDT) Received: from [192.168.1.5] (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 02ILIW2Y030084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Mar 2020 17:18:33 -0400 From: Justin Richer Message-Id: <30E67E8A-CD0F-40CD-92C5-12D23E6FB1FA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_DC80E9F7-52AD-4AC4-8F70-BC8CBE508E5F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Mar 2020 17:18:32 -0400 In-Reply-To: <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> Cc: txauth@ietf.org, Dick Hardt To: David Skaife References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:18:39 -0000 --Apple-Mail=_DC80E9F7-52AD-4AC4-8F70-BC8CBE508E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking with someone on another channel, let me explain it this way. This isn=E2=80=99t like =E2=80=9CI will send this to you in JSON or = CBOR, which do you want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can = take a signed ID token=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. So = there isn=E2=80=99t an order or a preference or an exclusivity. If you = can do either of them, or both of them, you just do them. Doing the OPTIONS call would let the client fetch from the server all of = that at once, if it wanted too. Allowing it inline lets the client do = all of that without making a second network call or remembering = anything. But it always has the option to do so. =E2=80=94 Justin > On Mar 18, 2020, at 5:04 PM, Justin Richer wrote: >=20 > I wasn=E2=80=99t showing just the happy path, but I think my example = might have been too simple. Also, I think we've got a different model = for what=E2=80=99s in the capabilities. It=E2=80=99s not about a set of = mutually exclusive options that the client has to choose from. >=20 >> Thanks Stephen and Justin for your responses. >>=20 >> I certainly accept some of the points you've raised here. One thing = I'd like to add though is that the examples you've provided only show = the happy-path scenario (from a client's perspective) - where the AS = conveniently supports only one of the capabilities provided by the = client. What about if we consider the following scenario: >>=20 >> - Client can do A, B, C and D. The AS can do A, B, C, D and E. >> - The client sends [A, B, C, D]. >> - Does the AS now send back [A, B, C, D] >=20 > Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset = of the client=E2=80=99s capabilities.=20 >=20 >> , and then force the client to make a decision (i.e. complexity on = the client)? Or instead, does the AS make a decision itself and then = only send one result back? If the latter, then how would the AS make = this decision, and could this potentially result in an undesirable = outcome from a client's perspective? >=20 > The client is already declaring that it can do all of those, and so it = needs to figure out which of those it=E2=80=99s going to use and how = they work together. My intent wasn=E2=80=99t to say that the client = could only do one of those at a time, but rather that these were = different things that the client could support that were optional at the = AS, and the AS is telling the client which bits that it knows about and = can handle. Maybe this is a list of extensions, maybe it=E2=80=99s a = list of optional features, but it=E2=80=99s on top of the =E2=80=9Ccore=E2= =80=9D portions of the protocol.=20 >=20 > I=E2=80=99ll also say that this is completely separate from the = discussion on how to handle interaction =E2=80=94 I think the = information patterns on that (which are in a different thread) are much = clearer.=20 >=20 >>=20 >> As you've mentioned, in reality the client would likely "remember" = the capabilities that the AS supports. So if the AS were instead probed = by the client to retrieve the list of its capabilities, this additional = complexity needed on the client side would not be something that is = present in every interaction - as the client would simply need to pass = it's preferred (supported) method on each interaction, rather than = having to keep probing and filtering on each request. Additionally, this = concept of the client remembering what the AS supports would negate the = argument about there being an increase in network traffic raised by = Stephen. >=20 > The reality is that most clients aren=E2=80=99t really going to = discover and declare things, especially if the client can start the = whole protocol with just one bit of information. XYZ originally started = with zero discovery, because all of the important parts are revealed = during the protocol.=20 >=20 >>=20 >> I don't think it's as clear-cut as you've presented in your = responses, but I do accept that there are merits to trying to push = complexity to the server. >>=20 >=20 > I agree that it=E2=80=99s not that clear cut yet =E2=80=94 but = that=E2=80=99s largely because there aren=E2=80=99t a lot of concrete = things that would go in this =E2=80=9Cdiscovery=E2=80=9D document yet. = At least with XYZ, we deliberately minimized what the client would need = to know going in, for both simplicity and security. When you make the = core protocol such that you don=E2=80=99t need a lot of extra bits in = order for things to function, then you aren=E2=80=99t creating problems = that you need solutions for. >=20 > Thanks for raising the discussion! >=20 >>=20 >> Many thanks, >> David Skaife >>=20 >> On Wed, Mar 18, 2020 at 8:22 PM Justin Richer > wrote: >> OAuth 2 has taught us that wherever possible, you should push the = complexity to the server, not the client. That=E2=80=99s the idea behind = the kind of publication/negotiation here where the client can do = something simple and the AS needs to make the actual comparison and = decision, whatever that is. Clients need to stay simple because, for the = most part, the focus of the client is on calling whatever API and = implementing whatever functionality it is doing, not on the security = layer. The AS is a dedicated security component, so it=E2=80=99s got the = mandate to figure this stuff out. This mindset is one of OAuth 2=E2=80=99s= biggest strengths.=20 >>=20 >> So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t= really :used: this feature beyond making sure the protocol can be = passed back and forth, since there=E2=80=99s not a lot of optionality = that really needs to be negotiated here. >>=20 >> So let=E2=80=99s say the client can do A, B, and C. The AS can do B, = D, and X. If the client doesn=E2=80=99t know anything at all about the = AS, the client sends: >>=20 >> [A, B, C] >>=20 >> And the server looks at that, compares with what it can do, and = returns: >>=20 >> [B] >>=20 >> The server doesn=E2=80=99t send D, or X, because the client = wouldn=E2=80=99t have any clue what to do about that. The client can = remember that if it wants to cache that part of the response. >>=20 >> So the question is, what if the client knew that only B would be = successful for this server? That=E2=80=99s pretty common because a lot = of clients get written and configured with a static set of capabilities = for a server. And with the negotiation above, the client just needs to = remember after the first call. So in both cases, the client would only = send [B], or leave it off entirely because it doesn=E2=80=99t need to = negotiate, and you=E2=80=99re done.=20 >>=20 >> But the thing is, you could do both styles with one simple twist. If = you want to do the discovery portion in a pre-flight request, I think = it=E2=80=99s a good idea to allow OPTIONS on the tx endpoint. It = doesn=E2=80=99t make any sense to me to allow it on any other endpoints, = especially because some of those are going to be user-facing (so the = client is not going to be talking to the URL itself). The client makes = this call and gets back: >>=20 >> [B, D, X] >>=20 >> And now the client has to put together its possible capabilities from = that list and what it knows it can do. By putting OPTIONS on the = endpoint then we can stick with the same mantra of the client having one = piece of info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80= =94 and learning everything else from that. I think that part is simple = enough to potentially work, and XYZ doesn=E2=80=99t have other endpoints = or aspects that need to be discovered out of band, unlike OAuth 2. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>=20 >>> On Mar 18, 2020, at 3:44 PM, David Skaife = > wrote: >>>=20 >>> Hi, >>>=20 >>> My thoughts on these different approaches are: >>>=20 >>> 1. For XYZ, it feels a bit strange and unnecessary to require the = client to have to state it's full set of capabilities to the AS. It = feels like it should be the other way around - i.e. the client is able = to probe what the AS supports. In my view it's more natural for the AS = to be "advertising" its capabilities rather than the client. >>>=20 >>> 2. I prefer the XYZ approach of having a single URL that the client = knows it needs to interact to start the transaction, vs the more complex = approach provided by XAuth. >>>=20 >>> 3. Hopefully there is a middle ground between the two approaches = that addresses the two points above. >>>=20 >>>=20 >>> Many thanks, >>> David Skaife >>>=20 >>> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt > wrote: >>> Discovery >>>=20 >>> XYZ >>> - Client always starts at the tx endpoint, all other information is = dispatched from responses from the endpoint >>> - Clients sends capabilities list in transaction request, AS = selects and returns which capabilities are supported >>>=20 >>> XYZ Rationale: client needs a single URL to start talking to an AS, = giving developers multiple ways to get information is confusing and can = lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by = OIDC=E2=80=99s discovery approach) >>>=20 >>> XAuth >>> - Client sends an OPTIONS call to the GS URI, Grant URI, or = Authorization URI >>>=20 >>> XAuth Rationale: Client can make unauthenticated call to GS URI to = learn what GS supports, such as authentication mechanisms. Authenticated = calls return what a specific Client can do. >>>=20 >>>=20 >>> =E1=90=A7 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_DC80E9F7-52AD-4AC4-8F70-BC8CBE508E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Speaking with someone on another channel, let me explain it = this way.

This = isn=E2=80=99t like =E2=80=9CI will send this to you in JSON or CBOR, = which do you want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can take a = signed ID token=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. So there = isn=E2=80=99t an order or a preference or an exclusivity. If you can do = either of them, or both of them, you just do them.

Doing the OPTIONS call = would let the client fetch from the server all of that at once, if it = wanted too. Allowing it inline lets the client do all of that without = making a second network call or remembering anything. But it always has = the option to do so.

 =E2=80=94 Justin

On Mar = 18, 2020, at 5:04 PM, Justin Richer <jricher@mit.edu> wrote:

I wasn=E2=80=99t showing just = the happy path, but I think my example might have been too simple. Also, = I think we've got a different model for what=E2=80=99s in the = capabilities. It=E2=80=99s not about a set of mutually exclusive options = that the client has to choose from.

Thanks = Stephen and Justin for your responses.

I certainly accept some of the = points you've raised here. One thing I'd like to add though is that the = examples you've provided only show the happy-path scenario (from a = client's perspective) - where the AS conveniently supports only one of = the capabilities provided by the client. What about if we consider the = following scenario:

- Client can do A, B, C = and D. The AS can do A, B, C, D and E.
- The client sends = [A, B, C, D].
- Does the AS now send back [A, B, C, = D]

Yes, the AS sends back [A, B, C, D] because that=E2=80=99s = the subset of the client=E2=80=99s capabilities. 

, and then force the client to make a decision = (i.e. complexity on the client)? Or instead, does the AS make a = decision itself and then only send one result back? If the latter, = then how would the AS make this decision, and could this potentially = result in an undesirable outcome from a client's perspective?

The client is already declaring that it = can do all of those, and so it needs to figure out which of those it=E2=80= =99s going to use and how they work together. My intent wasn=E2=80=99t = to say that the client could only do one of those at a time, but rather = that these were different things that the client could support that were = optional at the AS, and the AS is telling the client which bits that it = knows about and can handle. Maybe this is a list of extensions, maybe = it=E2=80=99s a list of optional features, but it=E2=80=99s on top of the = =E2=80=9Ccore=E2=80=9D portions of the protocol. 

I=E2=80=99ll also say = that this is completely separate from the discussion on how to handle = interaction =E2=80=94 I think the information patterns on that (which = are in a different thread) are much clearer. 


As you've mentioned, in reality = the client would likely "remember" the capabilities that the AS = supports. So if the AS were instead probed by the client to retrieve the = list of its capabilities, this additional complexity needed on the = client side would not be something that is present in every interaction = - as the client would simply need to pass it's preferred (supported) = method on each interaction, rather than having to keep probing and = filtering on each request. Additionally, this concept of the client = remembering what the AS supports would negate the argument about there = being an increase in network traffic raised by Stephen.

The reality is that most clients = aren=E2=80=99t really going to discover and declare things, especially = if the client can start the whole protocol with just one bit of = information. XYZ originally started with zero discovery, because all of = the important parts are revealed during the protocol. 


I don't think it's as clear-cut as = you've presented in your responses, but I do accept that there are = merits to trying to push complexity to the server.


I agree that it=E2=80=99s not that = clear cut yet =E2=80=94 but that=E2=80=99s largely because there = aren=E2=80=99t a lot of concrete things that would go in this = =E2=80=9Cdiscovery=E2=80=9D document yet. At least with XYZ, we = deliberately minimized what the client would need to know going in, for = both simplicity and security. When you make the core protocol such that = you don=E2=80=99t need a lot of extra bits in order for things to = function, then you aren=E2=80=99t creating problems that you need = solutions for.

Thanks for raising the discussion!


Many thanks,
David = Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer = <jricher@mit.edu> = wrote:
OAuth 2 has taught us that wherever possible, you should = push the complexity to the server, not the client. That=E2=80=99s the = idea behind the kind of publication/negotiation here where the client = can do something simple and the AS needs to make the actual comparison = and decision, whatever that is. Clients need to stay simple because, for = the most part, the focus of the client is on calling whatever API and = implementing whatever functionality it is doing, not on the security = layer. The AS is a dedicated security component, so it=E2=80=99s got the = mandate to figure this stuff out. This mindset is one of OAuth 2=E2=80=99s= biggest strengths. 

So how would this work in XYZ? I=E2=80=99ll say that we = haven=E2=80=99t really :used: this feature beyond making sure the = protocol can be passed back and forth, since there=E2=80=99s not a lot = of optionality that really needs to be negotiated here.

So let=E2=80=99s say = the client can do A, B, and C. The AS can do B, D, and X. If the client = doesn=E2=80=99t know anything at all about the AS, the client = sends:

[A, B, = C]

And the = server looks at that, compares with what it can do, and = returns:

[B]

The server doesn=E2=80=99t send D, or X, because the client = wouldn=E2=80=99t have any clue what to do about that. The client can = remember that if it wants to cache that part of the response.

So the question is, what = if the client knew that only B would be successful for this server? = That=E2=80=99s pretty common because a lot of clients get written and = configured with a static set of capabilities for a server. And with the = negotiation above, the client just needs to remember after the first = call. So in both cases, the client would only send [B], or leave it off = entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80=99re = done. 

But = the thing is, you could do both styles with one simple twist. If you = want to do the discovery portion in a pre-flight request, I think it=E2=80= =99s a good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t = make any sense to me to allow it on any other endpoints, especially = because some of those are going to be user-facing (so the client is not = going to be talking to the URL itself). The client makes this call and = gets back:

[B, = D, X]

And now = the client has to put together its possible capabilities from that list = and what it knows it can do. By putting OPTIONS on the endpoint then we = can stick with the same mantra of the client having one piece of info to = get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and = learning everything else from that. I think that part is simple enough = to potentially work, and XYZ doesn=E2=80=99t have other endpoints or = aspects that need to be discovered out of band, unlike OAuth = 2.

 =E2=80=94= Justin



On Mar 18, 2020, at 3:44 PM, David Skaife = <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoughts on these = different approaches are:

1. For XYZ, it = feels a bit strange and unnecessary to require the client to have to = state it's full set of capabilities to the AS. It feels like it should = be the other way around - i.e. the client is able to probe what the AS = supports. In my view it's more natural for the AS to be "advertising" = its capabilities rather than the client.

2. = I prefer the XYZ approach of having a single URL that the client knows = it needs to interact to start the transaction, vs the more complex = approach provided by XAuth.

3. = Hopefully there is a middle ground between the two approaches that = addresses the two points above.


Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery

XYZ
 - Client always starts at the tx = endpoint, all other information is dispatched from responses from the = endpoint
 - Clients sends capabilities list in = transaction request, AS selects and returns which capabilities are = supported

XYZ Rationale: client needs a = single URL to start talking to an AS, giving developers multiple ways to = get information is confusing and can lead to serious errors (see = OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s discovery = approach)

XAuth
 - = Client sends an OPTIONS call to the GS URI, Grant URI, or Authorization = URI

XAuth Rationale: Client can make = unauthenticated call to GS URI to learn what GS supports, such as = authentication mechanisms. Authenticated calls return what a specific = Client can do.


3D""=E1=90=A7
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

<= br class=3D"" 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;">-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_DC80E9F7-52AD-4AC4-8F70-BC8CBE508E5F-- From nobody Wed Mar 18 14:24:27 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431A53A1C88 for ; Wed, 18 Mar 2020 14:24:25 -0700 (PDT) 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_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=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 5H-11f4lTPHS for ; Wed, 18 Mar 2020 14:24:22 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 05A023A1C8D for ; Wed, 18 Mar 2020 14:24:17 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id j2so28584414qkl.7 for ; Wed, 18 Mar 2020 14:24:16 -0700 (PDT) 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=lYlZc0Cpz5FuOEqYCLX3nyPXjiGv/3QDlHBwlY0ryYM=; b=LLzx+iXz1weEso686uq8kbk+Gmv1BBDTV46Hlzm4h9WqD7YwqMdtjGt9V7FOaKBBWZ IPzAqhqEF3m48o6erddZul1KTYD3aaWxnNZcwwtOByz/2wUb5r+M8wiF2vvdG/NwEJny h8l2yDB5PFRbr6LAEUohC3BXugflPYx4nXU8p0MrCndffs5hfmsZ++8b8J12eqE7DcFP SW1ZSG503wfGKA3S1KwZNkIZyGGAqovNDUc6DFMDHxfmAgATC6hBkf4HjDH6HHG2AYVz wxcWWh//BZ4LPSSr0ucyI6FkS6XMBb6ikxZJWm6b9LkUrIi9g61fRxmeCllNrbMPV6Ci I3nw== 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=lYlZc0Cpz5FuOEqYCLX3nyPXjiGv/3QDlHBwlY0ryYM=; b=Kt/9P+Zvfnq2aHfhYcuW7VkmwcTrwlWkdZrZ0AeIJ/s3Fy9KDr+2r7w5+z2NXL+YOu WNfoATf+igrRNxZ4q9WosNpx9aVOsGxFWG4ml3d+lz6gM3diQ4pDMw6sU9q+wLr0VvN2 oI28nWSWW6nad+TKz6nL9XPtmkL/PzSgB0sTQLe2nwmNn80IQyaMitzOlkkV05WvLGg2 yKoMOZd/cA1YUH0NI4A5+sp4rwN3aPJRb/8S2cdAqi0yjFEn1c50ODPBI/9UkhFKEVvY lYfGOWQnQWcMNNB3ThfF8dypWq/21ZK1nBCxDkLBEk5Y9EPZsuSLh9lXBpDc86VENwQ6 v9VA== X-Gm-Message-State: ANhLgQ3lXxgpxbINd4KWusaK9VRiwnmyIGBbzUK6+FvKyJ184h9Jgy00 46aIYesEXeIYw9WUJ3o6k8HfcqfF9fJcIx/cWfI= X-Google-Smtp-Source: ADFU+vsfl0Aljix+xOuTdnHogGUiPSHupsTfCuSAd1U6tAFFiosutn+iLemKWUsUFnC4Vf7Y8ybi5ik/ZCkUh3VmUpk= X-Received: by 2002:a25:ba93:: with SMTP id s19mr10039319ybg.100.1584566656024; Wed, 18 Mar 2020 14:24:16 -0700 (PDT) MIME-Version: 1.0 References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> <30E67E8A-CD0F-40CD-92C5-12D23E6FB1FA@mit.edu> In-Reply-To: <30E67E8A-CD0F-40CD-92C5-12D23E6FB1FA@mit.edu> From: Stephen Moore Date: Wed, 18 Mar 2020 17:24:02 -0400 Message-ID: To: Justin Richer Cc: David Skaife , txauth@ietf.org, Dick Hardt Content-Type: multipart/alternative; boundary="000000000000a7c6f605a127acba" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:24:25 -0000 --000000000000a7c6f605a127acba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That makes more sense to me now. Thanks Justin! I also like that particular solution, rather basically relying on caching or re-discovery before the transaction begins since, I think, that allows for more flexible client 'requirements'. -steve On Wed, Mar 18, 2020 at 5:18 PM Justin Richer wrote: > Speaking with someone on another channel, let me explain it this way. > > This isn=E2=80=99t like =E2=80=9CI will send this to you in JSON or CBOR,= which do you > want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can take a signed ID tok= en=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. > So there isn=E2=80=99t an order or a preference or an exclusivity. If you= can do > either of them, or both of them, you just do them. > > Doing the OPTIONS call would let the client fetch from the server all of > that at once, if it wanted too. Allowing it inline lets the client do all > of that without making a second network call or remembering anything. But > it always has the option to do so. > > =E2=80=94 Justin > > On Mar 18, 2020, at 5:04 PM, Justin Richer wrote: > > I wasn=E2=80=99t showing just the happy path, but I think my example migh= t have > been too simple. Also, I think we've got a different model for what=E2=80= =99s in > the capabilities. It=E2=80=99s not about a set of mutually exclusive opti= ons that > the client has to choose from. > > Thanks Stephen and Justin for your responses. > > I certainly accept some of the points you've raised here. One thing I'd > like to add though is that the examples you've provided only show the > happy-path scenario (from a client's perspective) - where the AS > conveniently supports only one of the capabilities provided by the client= . > What about if we consider the following scenario: > > - Client can do A, B, C and D. The AS can do A, B, C, D and E. > - The client sends [A, B, C, D]. > - Does the AS now send back [A, B, C, D] > > > Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset of = the > client=E2=80=99s capabilities. > > , and then force the client to make a decision (i.e. complexity on the > client)? Or instead, does the AS make a decision itself and then only sen= d > one result back? If the latter, then how would the AS make this decision, > and could this potentially result in an undesirable outcome from a client= 's > perspective? > > > The client is already declaring that it can do all of those, and so it > needs to figure out which of those it=E2=80=99s going to use and how they= work > together. My intent wasn=E2=80=99t to say that the client could only do o= ne of > those at a time, but rather that these were different things that the > client could support that were optional at the AS, and the AS is telling > the client which bits that it knows about and can handle. Maybe this is a > list of extensions, maybe it=E2=80=99s a list of optional features, but i= t=E2=80=99s on top > of the =E2=80=9Ccore=E2=80=9D portions of the protocol. > > I=E2=80=99ll also say that this is completely separate from the discussio= n on how > to handle interaction =E2=80=94 I think the information patterns on that = (which are > in a different thread) are much clearer. > > > As you've mentioned, in reality the client would likely "remember" the > capabilities that the AS supports. So if the AS were instead probed by th= e > client to retrieve the list of its capabilities, this additional complexi= ty > needed on the client side would not be something that is present in every > interaction - as the client would simply need to pass it's preferred > (supported) method on each interaction, rather than having to keep probin= g > and filtering on each request. Additionally, this concept of the client > remembering what the AS supports would negate the argument about there > being an increase in network traffic raised by Stephen. > > > The reality is that most clients aren=E2=80=99t really going to discover = and > declare things, especially if the client can start the whole protocol wit= h > just one bit of information. XYZ originally started with zero discovery, > because all of the important parts are revealed during the protocol. > > > I don't think it's as clear-cut as you've presented in your responses, bu= t > I do accept that there are merits to trying to push complexity to the > server. > > > I agree that it=E2=80=99s not that clear cut yet =E2=80=94 but that=E2=80= =99s largely because > there aren=E2=80=99t a lot of concrete things that would go in this =E2= =80=9Cdiscovery=E2=80=9D > document yet. At least with XYZ, we deliberately minimized what the clien= t > would need to know going in, for both simplicity and security. When you > make the core protocol such that you don=E2=80=99t need a lot of extra bi= ts in > order for things to function, then you aren=E2=80=99t creating problems t= hat you > need solutions for. > > Thanks for raising the discussion! > > > Many thanks, > David Skaife > > On Wed, Mar 18, 2020 at 8:22 PM Justin Richer wrote: > >> OAuth 2 has taught us that wherever possible, you should push the >> complexity to the server, not the client. That=E2=80=99s the idea behind= the kind >> of publication/negotiation here where the client can do something simple >> and the AS needs to make the actual comparison and decision, whatever th= at >> is. Clients need to stay simple because, for the most part, the focus of >> the client is on calling whatever API and implementing whatever >> functionality it is doing, not on the security layer. The AS is a dedica= ted >> security component, so it=E2=80=99s got the mandate to figure this stuff= out. This >> mindset is one of OAuth 2=E2=80=99s biggest strengths. >> >> So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t = really :used: >> this feature beyond making sure the protocol can be passed back and fort= h, >> since there=E2=80=99s not a lot of optionality that really needs to be n= egotiated >> here. >> >> So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D, = and X. If >> the client doesn=E2=80=99t know anything at all about the AS, the client= sends: >> >> [A, B, C] >> >> And the server looks at that, compares with what it can do, and returns: >> >> [B] >> >> The server doesn=E2=80=99t send D, or X, because the client wouldn=E2=80= =99t have any >> clue what to do about that. The client can remember that if it wants to >> cache that part of the response. >> >> So the question is, what if the client knew that only B would be >> successful for this server? That=E2=80=99s pretty common because a lot o= f clients >> get written and configured with a static set of capabilities for a serve= r. >> And with the negotiation above, the client just needs to remember after = the >> first call. So in both cases, the client would only send [B], or leave i= t >> off entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80= =99re done. >> >> But the thing is, you could do both styles with one simple twist. If you >> want to do the discovery portion in a pre-flight request, I think it=E2= =80=99s a >> good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t make a= ny sense to >> me to allow it on any other endpoints, especially because some of those = are >> going to be user-facing (so the client is not going to be talking to the >> URL itself). The client makes this call and gets back: >> >> [B, D, X] >> >> And now the client has to put together its possible capabilities from >> that list and what it knows it can do. By putting OPTIONS on the endpoin= t >> then we can stick with the same mantra of the client having one piece of >> info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 an= d learning everything else >> from that. I think that part is simple enough to potentially work, and X= YZ >> doesn=E2=80=99t have other endpoints or aspects that need to be discover= ed out of >> band, unlike OAuth 2. >> >> =E2=80=94 Justin >> >> >> >> On Mar 18, 2020, at 3:44 PM, David Skaife < >> blue.ringed.octopus.guy@gmail.com> wrote: >> >> Hi, >> >> My thoughts on these different approaches are: >> >> 1. For XYZ, it feels a bit strange and unnecessary to require the client >> to have to state it's full set of capabilities to the AS. It feels like = it >> should be the other way around - i.e. the client is able to probe what t= he >> AS supports. In my view it's more natural for the AS to be "advertising" >> its capabilities rather than the client. >> >> 2. I prefer the XYZ approach of having a single URL that the client know= s >> it needs to interact to start the transaction, vs the more complex >> approach provided by XAuth. >> >> 3. Hopefully there is a middle ground between the two approaches that >> addresses the two points above. >> >> >> Many thanks, >> David Skaife >> >> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote= : >> >>> >>> *Discovery* >>> XYZ >>> - Client always starts at the tx endpoint, all other information is >>> dispatched from responses from the endpoint >>> - Clients sends capabilities list in transaction request, AS selects >>> and returns which capabilities are supported >>> >>> XYZ Rationale: client needs a single URL to start talking to an AS, >>> giving developers multiple ways to get information is confusing and can >>> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OI= DC=E2=80=99s >>> discovery approach) >>> >>> XAuth >>> - Client sends an OPTIONS call to the GS URI, Grant URI, or >>> Authorization URI >>> >>> XAuth Rationale: Client can make unauthenticated call to GS URI to lear= n >>> what GS supports, such as authentication mechanisms. Authenticated call= s >>> return what a specific Client can do. >>> >>> >>> =E1=90=A7 >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a7c6f605a127acba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That makes more sense to me now. Thanks Justin!
I also= like that particular solution, rather basically relying on caching or re-d= iscovery before the transaction begins since, I think, that allows for more= flexible client 'requirements'.
-steve

On Wed, Mar = 18, 2020 at 5:18 PM Justin Richer <jr= icher@mit.edu> wrote:
Speaking with someon= e on another channel, let me explain it this way.

This i= sn=E2=80=99t like =E2=80=9CI will send this to you in JSON or CBOR, which d= o you want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can take a signed ID= token=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. So there isn=E2=80=99= t an order or a preference or an exclusivity. If you can do either of them,= or both of them, you just do them.

Doing the OPTI= ONS call would let the client fetch from the server all of that at once, if= it wanted too. Allowing it inline lets the client do all of that without m= aking a second network call or remembering anything. But it always has the = option to do so.

=C2=A0=E2=80=94 Justin
On Mar 18, 2020, at 5:04 PM, Justin Richer= <jricher@mit.edu> wrote:

I wasn=E2=80=99t showing just the happy path, but I think my example might= have been too simple. Also, I think we've got a different model for wh= at=E2=80=99s in the capabilities. It=E2=80=99s not about a set of mutually = exclusive options that the client has to choose from.

Thanks Stephen= and Justin for your responses.

I certainly = accept some of the points you've raised here. One thing I'd like to= add though is that the examples you've provided only show the happy-pa= th scenario (from a client's perspective) - where the AS conveniently s= upports only one of the capabilities provided by the client. What about if = we consider the following scenario:

- Client can do A, B, C and D. T= he AS can do A, B, C, D and E.
- The client sends [A, B, C, D].
- Doe= s the AS now send back [A, B, C, D]

=
Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset = of the client=E2=80=99s capabilities.=C2=A0

, and then force the client to make a decision (i= .e. complexity on the client)? Or instead, does the AS make a decision=C2= =A0itself and then only send one result back? If the latter, then how would= the AS make this decision, and could this potentially result in an undesir= able outcome from a client's perspective?
<= div>
The client is already declaring that it can do all of th= ose, and so it needs to figure out which of those it=E2=80=99s going to use= and how they work together. My intent wasn=E2=80=99t to say that the clien= t could only do one of those at a time, but rather that these were differen= t things that the client could support that were optional at the AS, and th= e AS is telling the client which bits that it knows about and can handle. M= aybe this is a list of extensions, maybe it=E2=80=99s a list of optional fe= atures, but it=E2=80=99s on top of the =E2=80=9Ccore=E2=80=9D portions of t= he protocol.=C2=A0

I=E2=80=99ll also say that this= is completely separate from the discussion on how to handle interaction = =E2=80=94 I think the information patterns on that (which are in a differen= t thread) are much clearer.=C2=A0

<= div dir=3D"ltr">
As you've mentioned, in reality the client would li= kely "remember" the capabilities=C2=A0that the AS supports. So if= the AS were instead probed by the client to retrieve the list of its capab= ilities, this additional complexity needed on the client side would not be = something that is present in every interaction - as the client would simply= need to pass it's preferred (supported) method on each interaction, ra= ther than having to keep probing and filtering on each request. Additionall= y, this concept of the client remembering what the AS supports would negate= the argument about there being an increase in network traffic raised by St= ephen.



I don't think it's as clea= r-cut as you've presented in your responses, but I do accept that there= are merits to trying to push complexity to the server.

=




Many= thanks,
David Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:
OAu= th 2 has taught us that wherever possible, you should push the complexity t= o the server, not the client. That=E2=80=99s the idea behind the kind of pu= blication/negotiation here where the client can do something simple and the= AS needs to make the actual comparison and decision, whatever that is. Cli= ents need to stay simple because, for the most part, the focus of the clien= t is on calling whatever API and implementing whatever functionality it is = doing, not on the security layer. The AS is a dedicated security component,= so it=E2=80=99s got the mandate to figure this stuff out. This mindset is = one of OAuth 2=E2=80=99s biggest strengths.=C2=A0

So how= would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t really :u= sed: this feature beyond making sure the protocol can be passed back and fo= rth, since there=E2=80=99s not a lot of optionality that really needs to be= negotiated here.

So let=E2=80=99s say the client ca= n do A, B, and C. The AS can do B, D, and X. If the client doesn=E2=80=99t = know anything at all about the AS, the client sends:

[A, B, C]

And the server looks at that, compare= s with what it can do, and returns:

[B]
=
The server doesn=E2=80=99t send D, or X, because the client = wouldn=E2=80=99t have any clue what to do about that. The client can rememb= er that if it wants to cache that part of the response.

So the question is, what if the client knew that only B would be succ= essful for this server? That=E2=80=99s pretty common because a lot of clien= ts get written and configured with a static set of capabilities for a serve= r. And with the negotiation above, the client just needs to remember after = the first call. So in both cases, the client would only send [B], or leave = it off entirely because it doesn=E2=80=99t need to negotiate, and you=E2=80= =99re done.=C2=A0

But the thing is, you could do b= oth styles with one simple twist. If you want to do the discovery portion i= n a pre-flight request, I think it=E2=80=99s a good idea to allow OPTIONS o= n the tx endpoint. It doesn=E2=80=99t make any sense to me to allow it on a= ny other endpoints, especially because some of those are going to be user-f= acing (so the client is not going to be talking to the URL itself). The cli= ent makes this call and gets back:

[B, D, X]
=

And now the client has to put together its possible cap= abilities from that list and what it knows it can do. By putting OPTIONS on= the endpoint then we can stick with the same mantra of the client having o= ne piece of info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2= =80=94 and learning everything else from that. I think that part is simple = enough to potentially work, and XYZ doesn=E2=80=99t have other endpoints or= aspects that need to be discovered out of band, unlike OAuth 2.
=
=C2=A0=E2=80=94 Justin


On Mar 18, 2020, at 3:44 PM, David Skaife &= lt;b= lue.ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoughts on these different approaches are:
1. For XYZ, it feels a bit strange and unnecessary to require the cli= ent to have to state it's full set of capabilities to the AS. It feels = like it should be the other way around - i.e. the client is able to probe w= hat the AS supports. In my view it's more natural for the AS to be &quo= t;advertising" its capabilities rather than the client.

2. I pr= efer the XYZ approach of having a single URL that the client knows it needs= to interact to start the transaction, vs the more complex approach=C2=A0pr= ovided by XAuth.

3. Hopefully there is a middle ground between the t= wo approaches that addresses the two points above.


Many thanks,<= br>David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery

XYZ
=C2=A0- Client always starts a= t the tx endpoint, all other information is dispatched from responses from = the endpoint
=C2=A0- Clients sends capabilities list in transaction requ= est, AS selects and returns which capabilities are supported

XYZ Rat= ionale: client needs a single URL to start talking to an AS, giving develop= ers multiple ways to get information is confusing and can lead to serious e= rrors (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s discover= y approach)

XAuth
=C2=A0- Client sends an OPTIONS call to the GS = URI, Grant URI, or Authorization URI

XAuth Rationale: Client can mak= e unauthenticated call to GS URI to learn what GS supports, such as authent= ication mechanisms. Authenticated calls return what a specific Client can d= o.


--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mail= man/listinfo/txauth

=

--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/= mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a7c6f605a127acba-- From nobody Wed Mar 18 15:04:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC63A1D18 for ; Wed, 18 Mar 2020 15:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 LE1UHzWVmF4N for ; Wed, 18 Mar 2020 15:03:58 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650119.outbound.protection.outlook.com [40.107.65.119]) (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 18D043A1D11 for ; Wed, 18 Mar 2020 15:03:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dMH0/4knvCXtp8Tm6L+6MebpdROiLXkgx8CIqj4RhkMqaeC49aAhMs7dmGDC9kXl9X/h2EtX7FNqBl8sdE1YfbSe1s/LXAEObEYadWJhXvp2kXDytyD3JiMiknCD421t/67haDcROewWcaGZ5xXuRnC3bJwc5MDtouy0bBXl7E4yi9L3fUaR6rLfbV6IApPM9UHW3/8DLqQ/HP8HVuMg7APDgmqGT97sZmmdURsKzs9kmYmEj2s449Q3PdHfCpPo6ScFvgvkPGVtKXMwvMSGq1glmOAtDdNOGm9YDtFZKBUX2aNWqKhXD/OxOg4SnP/8Qzj22ROHwLSEtXnPjbdMcA== 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=2rFYM6rljjkUybziPfpvaZlzpZNeEu6picj+uOpEHdA=; b=KPFTq38yzTh32nP1cyZkZ38iKkd7RN+kdFLxd+ASEAB4euXR4iYBjvgIuyMUxS1i6NkZY9+RcYigrXTnd8UHYun32dtnQG4sWneuxt9TznaRUuID7MEiaY+2+ernot8rFdz9r7Oz2fuGJCsVmVImYeyZ+6ceUeJaz4ufyoG8emefLaRal2NG/fmx+ehS8YxVmvI0Hy/6rHIW8jSLmdh+pNzq0UQED38jBVDc95F1JxoeitjELmDE3PRCAFC8pDyDdJjT6mYOmMhHjpfRf91U/+eSlQwYVTh12pYQqwpm7/19B7K1W+h/NN2+ofiTgyZc5BlXnakfzRAzcv1TqYyhZg== 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=2rFYM6rljjkUybziPfpvaZlzpZNeEu6picj+uOpEHdA=; b=XqEkpAmPkK+bxU2RogzsZM9TAeX64dznRnlgAyzuybolxEXQaoqF5jP4QuFnwW7f0ytzQvzAqakC+7188FU6Wb0xYSQ3atmEZECFFQSy9ojwy+PWudah5GjUCGB8BZNojqDBprJi3ZFR0O+wyBbsI/g23608G80DMdDxk/dkU48= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by MN2PR00MB0719.namprd00.prod.outlook.com (2603:10b6:208:1d3::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2877.0; Wed, 18 Mar 2020 22:03:47 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::3489:6260:95d1:9d3f]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::3489:6260:95d1:9d3f%2]) with mapi id 15.20.2875.000; Wed, 18 Mar 2020 22:03:47 +0000 From: Mike Jones To: Torsten Lodderstedt , Justin Richer CC: "txauth@ietf.org" Thread-Topic: [EXTERNAL] Re: [Txauth] Multiple Access Tokens in XYZ Thread-Index: AQHV+emXM7bTeFNvkEOCWHfLD2Lc86hID0WAgAA5UQCAAKV4AIAAsOaAgAAYoICAAs/NgIACZZqQ Date: Wed, 18 Mar 2020 22:03:47 +0000 Message-ID: References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> In-Reply-To: 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_ActionId=dccb66fb-bcac-441e-bb17-0000662e900f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-18T21:58:50Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.81.134] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 76210c8f-6d43-4b8d-c231-08d7cb883be3 x-ms-traffictypediagnostic: MN2PR00MB0719: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: =?utf-8?B?U0ZWOk5TUE07U0ZTOigxMDAwOTAwMSkoNjAwOTAwMSkoNDI4MDAxKSgzNzc0?= =?utf-8?B?NTQwMDMpKDc2MTA0MDAzKSg1MTQ0NDAwMykoNTE3MDQwMDUpKDUyNjA0MDA1?= =?utf-8?B?KSgyNDQ1NDAwMikoMTM0NjQwMDMpKDE5OTAwMikoMTg5MDAyKSgyMDc3NjAw?= =?utf-8?B?MykoNjkyMjYwMDEpKDYzNjk2MDAyKSg3NDg3NjAwMSkoNzQ3MDYwMDEpKDU0?= =?utf-8?B?NjA2MDA2KSgzMzY1NjAwMSkoNzcwOTYwMDEpKDc2Nzg2MDAxKSg3Njc5NjAw?= =?utf-8?B?MSkoODE1NDIwMDEpKDU0MzU2MDAxKSg5MzEzNjAwMSkoOTI1NjYwMDEpKDQ2?= =?utf-8?B?MTAyMDAxKSg1NjE5NDQwMDIpKDY0NzA2MDAxKSg3NjU3NjAwMSkoODEzNDIw?= =?utf-8?B?MDEpKDkyNzI2MDAxKSgxNTk3NTQ0NTAwNikoNzc5ODIwMDEpKDU5NzY2MDAx?= =?utf-8?B?KSg1NjgxNjAwNSkoODAwMjIwMDEpKDY2MDY2MDAxKSg3NjQ4MjAwMSkoNzQz?= =?utf-8?B?MTYwMDEpKDkwMTQ2MDAxKSg2NTgxNjAwMSkoMjE3MTAwMSkoODc5MzYwMDEp?= =?utf-8?B?KDU2Nzc2MDAxKSg1NDMxNjAwMikoNzQzNjYwMDEpKDQ0Mzc2MDA1KSg4NzI2?= =?utf-8?B?NjAwMSkoNTQyMDYwMDcpKDI2NTYwMDIpKDQzOTYwMDEpKDQ3OTc2MDAxKSg1?= =?utf-8?B?MDk4NjAwMSkoOTU2NjYwMDMpKDQ5ODY2MDAxKSg0NzczNjAwMSkoNTE4NTYw?= =?utf-8?B?MDEpKDg1MzA2MDAyKSg3OTEwMjAwMSkoODU4NTIwMDMpKDgzMDcyMDAyKSgy?= =?utf-8?B?MTA1NjAwMSkoOTczMzYwMDEpKDk0OTQ2MDAxKSg5MzUxNjAwMikoOTU0MTYw?= =?utf-8?B?MDEpKDk0MzE2MDAyKSg4NjM2MjAwMSkoOTcxODYwMDEpKDgwOTc2MDAxKSg1?= =?utf-8?B?NTE5MzQwMDIpKDgxNjg2MDAxKSg4MzMyMjAwMSkoMTk1ODA0MDUwMDEpKDgx?= =?utf-8?B?ODE2MDAxKSg4NjYxMjAwMSkoMzE5NjYwMDgpKDc0NjYyMDAxKSgxOTU4MDM5?= =?utf-8?B?NTAwMykoNTM4MDYwMDEpKDc0NTAyMDAxKSg0NzQ0NjAwMik7RElSOk9VVDtT?= =?utf-8?B?RlA6MTEwMTtTQ0w6MTtTUlZSOk1OMlBSMDBNQjA3MTk7SDpNTjJQUjAwTUIw?= =?utf-8?B?Njg4Lm5hbXByZDAwLnByb2Qub3V0bG9vay5jb207RlBSOjtTUEY6Tm9uZTtM?= =?utf-8?Q?ANG:en;PTR:InfoNoRecords;A:1;MX:1;?= received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cDmRCMqjIjtG5RXAfxZk8jrndUKJAyuB9QY+9hJQMNwmzNVgq9M3Moi6zQx3CVko3kEQpnjJQNLSj6XaTKdT/1mbzkFsHLuW3JhSJsWdTLMbCxKeWIm9mw2Rz829eskV9BXOb5nmORV4IAkrsFRzuP9AOW6y83xij6+UO9AfAYG+vuKj30cJnO6TC7kzRlL11utHbCVsSSpsdfby9fLk/aD/06+SnLsD6Ym8//6cRW98tJ29sYlz45DDCKZjjZUbu+uUkkPhShKeJZFxj0h+7b/IBMQ22HQqrqCDOQseD4pCTT8+QG3dpqHqoW57cM6Y2eUFpWOozpdeLuM/SSeRIiNzc+kHJHEDEEE9B0OPJJCjgaTIWRCy9g5kBP81/ss3sdKcF8YfTv8Y4NWwq2Jn6NERsu8mRQPMrt3iX39dtNHnlJXZVFCJiCMuGA2rERoCSNnW3+UF+3wnbhD3NFH/rqqgdOC9rQqFcSiBjUYHQCUH+jLfsJAmP9cco4bMTuEu3nRNBjZvg5S+oGu5Q2XlEGpVowKX8y0WR28OG/Bb5F5w4GgyM9iEWrRIMnJ1UU467LvjMPtDR6KRAbbIlUcXavP8K0mWMVgGHHHMLUB8pFt7fky+ThbgGg203oI5z9y4bm1/Tlnv0BtZRMdkf5UZhe3gO02s98Ah4Qp83/QdXJB/wddbWMSjjd2FbOLimDGVLJtqi+dSd85gpqlQD2OX0Q== x-ms-exchange-antispam-messagedata: dC7tPRPnAOifaekBC04OTYFGXjVXODcJyfG4b2v98kk/yZTUbNTn7q9Kwk8UItLHEPijbUjiD7Bnn8OhsftdJcNlnpY2brynNfeliQR1dF4ke8f474Czht/WfmvHNbvV5stCxkGPom+6r/u4XeleeA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76210c8f-6d43-4b8d-c231-08d7cb883be3 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2020 22:03:47.6091 (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: WBRkdeuYS1wuZGcAkQsUoTI87reElcL2QHJbIwP2q+DG0J5c1I3YhE7LJd5hkpCTLW8tSW5HZ4xT8GKt+/Vqtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0719 Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 22:04:01 -0000 SSBhZ3JlZSB3aXRoIG1hbnkgb2YgVG9yc3RlbidzIHBvaW50cyBiZWxvdyAtIHBhcnRpY3VsYXJs eSB0aGUgbmVlZCBmb3Igc3VwcG9ydGluZyBhY2Nlc3MgdG9rZW5zIHRoYXQgYXJlIGF1ZGllbmNl ZCB0byBhIHBhcnRpY3VsYXIgcmVzb3VyY2UuICBUaGF0J3Mgb25lIG9mIHRoZSBrZXlzIHRvIHBy ZXZlbnRpbmcgdG9rZW4gcmVwbGF5LiAgVGhpcyBuZWVkIGNhbWUgdXAgd2hlbiB3ZSB0aG91Z2h0 IHRoYXQgVG9rZW4gQmluZGluZyB3YXMgaW1taW5lbnQgYW5kIGl0IGlzIGxpa2V3aXNlIHByb2Jh Ymx5IG5lZWRlZCBmb3Igb3RoZXIga2luZHMgb2YgUG9QIGFjY2VzcyB0b2tlbnMuDQoNCkFub3Ro ZXIgZXhhbXBsZSB3aXRoIG11bHRpcGxlIHJlc291cmNlczogIElmIHlvdSdyZSBsb2dnaW5nIGlu IGFuZCBnZXR0aW5nIGFuIGFjY2VzcyB0b2tlbiBmb3IgYSBVc2VySW5mbyBlbmRwb2ludCwgeW91 IG1heSBhbHNvIHdhbnQgYW4gYWNjZXNzIHRva2VuIGZvciBhbm90aGVyIHJlc291cmNlLCB0aGF0 IG1heSBiZSBvcGVyYXRlZCBieSBhIGRpZmZlcmVudCBwYXJ0eS4gIFRob3NlIHdpbGwgaGF2ZSBk aWZmZXJlbnQgYXVkaWVuY2VzIGFuZCBkaWZmZXJlbnQgUG9QIGJpbmRpbmdzLg0KDQpGaW5hbGx5 LCBJIGFncmVlIHdpdGggVG9yc3RlbidzIHBvaW50IHRoYXQgdGhlIGFjY2VzcyB0b2tlbnMgc2hv dWxkIGJlIHNlbGYtY29udGFpbmVkIHdpdGggZXZlcnl0aGluZyB0aGF0IHRoZSByZXNvdXJjZSBu ZWVkcy4gIEZvciBpbnN0YW5jZSwgbm8gdG9rZW4gaW50cm9zcGVjdGlvbiBzaG91bGQgYmUgcmVx dWlyZWQgKG9yIGV2ZW4gbmVlZGVkLCBpbiBtb3N0IGNhc2VzKS4NCg0KCQkJCS0tIE1pa2UNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0DQpTZW50OiBUdWVzZGF5 LCBNYXJjaCAxNywgMjAyMCAyOjIzIEFNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQu ZWR1Pg0KQ2M6IHR4YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW1R4YXV0 aF0gTXVsdGlwbGUgQWNjZXNzIFRva2VucyBpbiBYWVoNCg0KSGkgSnVzdGluLA0KDQp0aGFua3Mg Zm9yIGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVudCBvcHRpb25zLiBJ4oCZbSB3ZWxsIGF3YXJlIG9m IHRoZSBzdXBlciByZWZyZXNoIHRva2VuIChhbmQgcmVtZW1iZXIgdGhlIGRpc2N1c3Npb25zIGJh Y2sgdGhlbiBpbiBUYWlwZWkgOi0pKSwgSSBoYXZlIGltcGxlbWVudGVkIHN5c3RlbXMgdXNpbmcg dGhpcyBhbmQgb3RoZXIgcGF0dGVybnMsIHRvby4NCg0KVGhlIHVuZGVybHlpbmcgYXNzdW1wdGlv biBmb3IgbW9zdCBvZiB0aG9zZSBwYXR0ZXJucyBpcyB0aGF0IHRoZSBjbGllbnQgdXBmcm9udCBr bm93cyB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIFJTIHNlY3VyaXR5IGRvbWFpbnMsIHdoaWNoIHR5 cGljYWxseSBtZWFucyB0aGUgc29sdXRpb24gaXMgYmVzcG9rZW4uIA0KDQpUWEF1dGggaXMgY2hh cnRlcmVkIHRvIGRldmVsb3AgYSBwcm90b2NvbCBhbmQgbm90IGEgZnJhbWV3b3JrLiBXaGF0IEni gJltIGxvb2tpbmcgZm9yIGlzIGludGVyb3BlcmFibGUgcHJvdG9jb2wgc3VwcG9ydCBmb3IgdXNl IG9mIFJTLXNwZWNpZmljIHNlbGYtY29udGFpbmVkIGFjY2VzcyB0b2tlbnMgaW4gbXVsdGktUlMg ZGVwbG95bWVudHMuDQoNCldoeSBSUy1zcGVjaWZpYyBzZWxmLWNvbnRhaW5lZCBhY2Nlc3MgdG9r ZW5zPyANClRoaXMgaXMgaW4gbXkgZXhwZXJpZW5jZSB0aGUgbW9zdCBlZmZpY2llbnQgd2F5IHRv IGVtcG93ZXIgaGlnaC12b2x1bWUvaGlnaC1sb2FkIHNlcnZpY2VzIGluIGEgdmVyeSBlZmZpY2ll bnQsIHNlY3VyZSwgYW5kIHByaXZhY3kgcHJlc2VydmluZyBmYXNoaW9uLiANCg0KLSBFdmVyeSB0 b2tlbiBjb250YWlucyBleGFjdGx5IHRoZSBkYXRhIHRoZSBSUyBuZWVkcyB0byBwZXJmb3JtIGFj Y2VzcyBjb250cm9sIGRlY2lzaW9ucyBsb2NhbGx5LiBObyBuZWVkIGZvciBmdXJ0aGVyIGRhdGFi YXNlIGxvb2t1cHMgb3IgQVMgY2FsbGJhY2tzLCB0aGF04oCZcyByZWFsbHkgZmFzdCBhbmQga2Vl cHMgY29zdCBvZiB0aGUgQVMgZnVuY3Rpb24gbG93Lg0KLSBUaGUgdG9rZW4gaXRzZWxmIGNhbiBi ZSBlbmNyeXB0ZWQgdG8gcHJvdGVjdCB0aGlzIGRhdGEgdXNpbmcgYSBSUy1zcGVjaWZpYyBrZXks IG9uZSBjb3VsZCBldmVuIHVzZSBITUFDcyB0byBwcm90ZWN0IGludGVncml0eSBhbmQgYXV0aGVu dGljaXR5IChmYXN0IGFzIHdlbGwpLiANCi0gVGhlIHRva2VuIGNhbiBoYXZlIGEgUlMtc3BlY2lm aWMgbGlmZXRpbWUuDQotIFNpbmNlIGV2ZXJ5IHRva2VuIGlzIHJlc3RyaWN0ZWQgdG8gYSBzaW5n bGUgUlMgYXVkaWVuY2UsIHRob3NlIHRva2VucyBhbHNvIGhhdmUgYSBiYXNlbGluZSByZXBsYXkg ZGV0ZWN0aW9uIGJ1aWx0LWluLiANCg0KSSB0aGluayB0aGlzIHBhdHRlcm4gbWFrZXMgc2Vuc2Ug aW4gZW52aXJvbm1lbnRzIHdpdGggbXVsdGlwbGUgUlNzIChlLmcuIGRpZmZlcmVudCBwcm9kdWN0 cykgYXMgd2VsbC4gQnV0IHNpbmNlIGV2ZXJ5IHRva2VuIGlzIG1pbnRlZCB0byB0aGUgc3BlY2lm aWMgcmVxdWlyZW1lbnRzIG9mIGEgY2VydGFpbiBSUywgdGhlIEFTIG11c3QgYmUgYWJsZSB0byBt aW50IGRpZmZlcmVudCB0b2tlbnMuIFRoYXQgZG9lc27igJl0IHdvcmsgcHJvcGVybHkgd2l0aG91 dCBzb21lIHN1cHBvcnQgaW4gdGhlIHByb3RvY29sLg0KDQpJcyB0aGVyZSBhIG5lZWQgZm9yIG11 bHRpIGFjY2VzcyB0b2tlbnMgc3VwcG9ydD8gDQpXZWxsLCB5b3UgaW1wbGVtZW50ZWQgaXQsIEkg aW1wbGVtZW50ZWQgaXQsIGFuZCBJIHRoaW5rIGEgY291cGxlIG9mIG90aGVyIGltcGxlbWVudGVy cyBkaWQgaXQgd2l0aCBPQXV0aCAyIGluIHRoZSBwYXN0LiBTbyB0aGVyZSBzZWVtcyB0byBiZSBz b21lIG5lZWQuIFdoeSBkb2VzIHRoZSByZXN0IHVzZSB0aGUgc2luZ2xlIHRva2VuIHBhdHRlcm4/ IEkgdGhpbmsgc29tZSBkZXBsb3ltZW50cyB3aWxsIGluZGVlZCBvbmx5IGhhdmUgYSBzaW5nbGUg c2VydmljZSwgYnV0IEkgYmV0IGEgbG90IG9mIGltcGxlbWVudGVycyBkaWQgaXQgYmVjYXVzZSB0 aGVpciBwcm9kdWN0IGRvZXMgbm90IHN1cHBvcnQgYW55dGhpbmcgZWxzZS4gDQoNCkkgaGF2ZSBl eHBlcmllbmNlZCB0aGlzIG15c2VsZiB3aGVuIEkgZGVzaWduZWQgdGhlIGFyY2hpdGVjdHVyZSBv ZiB0aGUgeWVzIGVjb3N5c3RlbS4gSXQgaXMgYSBmZWRlcmF0aW9uIG9mIGF1dGhvcml6YXRpb24g c2VydmVycyB3aXRoIGFzc29jaWF0ZWQgc2VydmljZXMgd2hlcmUgZXZlcnkgQVMgcmVwcmVzZW50 cyBhIGNlcnRhaW4gYmFuay4gU2luY2Ugb3VyIHBhcnRuZXJzIHNoYWxsIGJlIGFibGUgdG8gaW1w bGVtZW50IHRoZWlyIEFTIHVzaW5nIHRoZSBwcm9kdWN0IHRoZXkgbGlrZSwgSSBuZWVkZWQgdG8g Z28gd2l0aCB0aGUgbGVhc3QgY29tbW9uIGRlbm9taW5hdG9yIC0gc2luZ2xlIGFjY2VzcyB0b2tl bi4gVGhpcyBoYXMgYSBzaWduaWZpY2FudCBjb25zZXF1ZW5jZXM6IG91ciB0b2tlbnMgYXJlIGJh c2ljYWxseSBoYW5kbGVzLCBzbyBldmVyeSBzZXJ2aWNlIGNhbGxzIGJhY2sgdG8gdGhlIEFTIHRv IG9idGFpbiBpdHMgZGF0YSBmb3IgZXZlcnkgc2VydmljZSByZXF1ZXN0LiBUaGlzIGRlZ3JhZGVz IHBlcmZvcm1hbmNlIHNpZ25pZmljYW50bHkgYW5kLCBzaW5jZSB0aG9zZSB0b2tlbnMgYXJlIGdv b2QgZm9yIG11bHRpIGF1ZGllbmNlcywgaXQgZm9yY2VzIHVzIHRvIGdlbmVyYWxseSB1c2Ugc2Vu ZGVyIGNvbnN0cmFpbmVkIHRva2Vucywgd2hpY2ggaW5jcmVhc2VzIGNvbXBsZXhpdHkgZm9yIGNs aWVudHMuIA0KDQpJIHdvdWxkIGxpa2UgdG8gZ2l2ZSBpbXBsZW1lbnRlcnMgbW9yZSBvcHRpb25z IGluIHRoZSBUWEF1dGggc3BhY2UuIFRoYXTigJlzIHdoeSBJIGFkdm9jYXRlIHRvIGJ1aWxkLWlu IHN1cHBvcnQgZsO8ciBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIGludG8gVFhBdXRoLiANCg0KTXkg cHJvcG9zYWwgaXMgYmFzZWQgb24gdGhlIGZvbGxvd2luZyBhc3N1bXB0aW9uczoNCi0gVG9rZW4g Zm9ybWF0LCBjb250ZW50LCBlbmNyeXB0aW9uIGtleXMgYW5kIHNvIG9uIGFyZSBkZWZpbmVkIGFz IHBhcnQgb2YgdGhlIGludGVyZmFjZSBiZXR3ZWVuIEFTIGFuZCBSUw0KLSBUaGUgY2xpZW50IGtu b3dzIHdoYXQgaXQgd2FudHMgdG8gZG8gYW5kIHdoZXJlDQotIEV2ZXJ5IHBhcnR5IGNvbnRyaWJ1 dGVzIHRoZSBpbmZvcm1hdGlvbiBpdCBoYXMgdG8gdGhlIG92ZXJhbGwgcHJvY2VzcyB0byBtYWtl IGl0IHdvcmsgc2ltcGx5IGFuZCBlZmZlY3RpdmVseSBmb3IgZXZlcnlvbmUuIA0KDQpUaGVyZSBp cyBubyBjaGFuZ2UvYWRkaXRpb24gbmVlZGVkIHRvIHRoZSByZXF1ZXN0IHN5bnRheC4gQWxsIGl0 IHRha2VzIGlzIHlvdXIgbmV3IG11bHRpIHRva2VuIHN5bnRheCAoKyBhIHNtYWxsIGFkZGl0aW9u KSBpbiB0aGUgcmVzcG9uc2UuIA0KDQpUaGUgY2xpZW50IHVzZXMgdGhlIOKAnHJlc291cmNlcyIg c3RydWN0dXJlIHRvIGNvbW11bmljYXRlIHdoYXQgKGFjdGlvbnMsIGZ1cnRoZXIgZWxlbWVudHMp IGl0IHdhbnRzIHRvIGRvIGFuZCB3aGVyZSAobG9jYXRpb25zKS4NCg0KWw0KICAgIHsNCiAgICAg IOKAnGFjdGlvbnMiOiBbInJlYWQiLCAid3JpdGUiXSwNCiAgICAgICJsb2NhdGlvbnMiOiBbImh0 dHBzOi8vZXhhbXBsZS5jb20vcmVzb3VyY2UiXSwNCiAgICAgIOKAnGRhdGEiOiBbImZvbyIsICJi YXIiXQ0KICAgIH0sDQogICAgew0KICAgICAg4oCcYWN0aW9ucyI6IFsid3JpdGUiXSwNCiAgICAg ICJsb2NhdGlvbnMiOiBbImh0dHBzOi8vb3RoZXJfZXhhbXBsZS5jb20vcmVzb3VyY2UiXSwNCiAg ICAgIOKAnGRhdGEiOiBbImZvbyIsICJiYXIiXQ0KICAgIH0NCl0NCg0KT25lIGRlcGxveW1lbnQg bWlnaHQgdXNlIGEgc2luZ2xlIHRva2VuIGZvciBhbGwgUlNzLCBpbiB0aGlzIGNhc2UgdGhlIHRv a2VuIHJlc3BvbnNlIHJlbWFpbnMgdW5jaGFuZ2VkOiANCg0Kew0KICJhY2Nlc3NfdG9rZW4iOnsN CiAgICJ2YWx1ZSI6IjA4dXI0a2FoZmdhMDl1MjNybmtqYXNkZiIsDQogICAidHlwZSI6ImJlYXJl ciINCiB9DQp9DQoNCklmIHRoZSBBUyBoYXMgdGhlIG5lZWQgdG8gaXNzdWUgbXVsdGlwbGUgYWNj ZXNzIHRva2VucywgaXQgY291bGQsIGZvciBleGFtcGxlLCB1c2UgdGhlIOKAnGxvY2F0aW9ucyIg ZWxlbWVudHMgdG8gZGV0ZXJtaW5lIHdoYXQgdG9rZW5zIGl0IG5lZWRzIHRvIGNyZWF0ZS4gU3Vj aCBhbiBBUyB0aGVuIHVzZXMgdGhlIG11bHRpcGxlX2FjY2Vzc190b2tlbnMgc3RydWN0dXJlIGF1 Z21lbnRlZCBieSBjb3JyZXNwb25kaW5nICJsb2NhdGlvbnPigJ0gZW50cmllcyBpbiB0aGUgdG9r ZW4gcmVzcG9uc2U6IA0KDQoibXVsdGlwbGVfYWNjZXNzX3Rva2VucyI6ew0KICAgInRva2VuX2Ei OnsNCiAgICAgInZhbHVlIjoiT1M5TTJQTUhLVVI2NFRCOE42Qlc3T1pCOENERk9OUDIxOVJQMUxU MCIsDQogICAgICJ0eXBlIjoiYmVhcmVyIiwNCiAgICAgImxvY2F0aW9ucyI6Ww0KICAgICAgICJo dHRwczovL2V4YW1wbGUuY29tL3Jlc291cmNlIg0KICAgICBdDQogICB9LA0KICAgInRva2VuX2Ii OnsNCiAgICAgInZhbHVlIjoiVUZHTE8yRkRBRkc3VkdaWlBKM0laRU1OMjFFVlU3MUZIQ0FSUDRK MSIsDQogICAgICJ0eXBlIjoiYmVhcmVyIiwNCiAgICAgImxvY2F0aW9ucyI6Ww0KICAgICAgICJo dHRwczovL290aGVyX2V4YW1wbGUuY29tL3Jlc291cmNlIg0KICAgICBdDQogICB9DQogfQ0KDQpT aW5jZSB0aGUgY2xpZW50IHBhc3NlZCB0aGUgbG9jYXRpb25zIHZhbHVlcyBpbiB0aGUgcmVxdWVz dCwgaXQgaXMgYWxzbyBhYmxlIHRvIGRldGVybWluZSB3aGVyZSB0byB1c2Ugd2hhdCBhY2Nlc3Mg dG9rZW4uIA0KDQpJIHRoaW5rIHRoYXTigJlzIHByZXR0eSBzaW1wbGUsIGVzcGVjaWFsbHkgZnJv bSBhIGNsaWVudCBwZXJzcGVjdGl2ZS4gIA0KDQpBbmQgSWYgdGhlIGNsaWVudCB3YW50cyB0byBz cGxpdCBhY2Nlc3MgdG9rZW5zIGZ1cnRoZXIgYXBhcnQsIGUuZy4gdG8gb2J0YWluIHRva2VucyB3 aXRoIGxlc3MgcHJpdmlsZWdlcywgaXQgY2FuIGRvIHNvIHVzaW5nIHRoZSByZXF1ZXN0IHN5bnRh eCB5b3UgZGVmaW5lZDogDQoNCnJlc291cmNlczogew0KICAgdG9rZW4xOiBbew0KICAgICAgICAg ICBhY3Rpb25zOiBbInJlYWQiLCAid3JpdGUiLCAiZG9scGhpbiJdLA0KICAgICAgICAgICBsb2Nh dGlvbnM6IFsiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvIiwgImh0dHBzOi8vcmVzb3VyY2Uu bG9jYWwvb3RoZXIiXSwNCiAgICAgICAgICAgZGF0YXR5cGVzOiBbIm1ldGFkYXRhIiwgImltYWdl cyJdDQogICAgfV0sDQogICAgdG9rZW4yOiBbew0KICAgICAgICAgICBhY3Rpb25zOiBbImZvbyIs ICJiYXIiLCAiZG9scGhpbiJdLA0KICAgICAgICAgICBsb2NhdGlvbnM6IFsiaHR0cHM6Ly9yZXNv dXJjZS5vdGhlci8iXSwNCiAgICAgICAgICAgZGF0YXR5cGVzOiBbImRhdGEiLCAicGljdHVyZXMi XQ0KICAgIH1dDQp9DQoNCkluIHRoZSBzaW1wbGVzdCBjYXNlLCB0aGUgQVMgd291bGQgcmV0dXJu IHRoZSBkYXRhIGFzIGluIHlvdXIgcHJvcG9zYWwuDQoNCklmIHRoZSBjbGllbnQgYXNrcyBmb3Ig YSBwYXJ0aXRpb25pbmcgb2YgcHJpdmlsZWdlcyB0aGF0IGdvZXMgYWNyb3NzIFJTIHNlY3VyaXR5 IGRvbWFpbnMgbGlrZSB0aGlzDQoNCnsNCiAicmVzb3VyY2VzIjp7DQogICAidG9rZW4xIjpbDQog ICAgIHsNCiAgICAgICAiYWN0aW9ucyI6WyAicmVhZCIsICJ3cml0ZSIsImRvbHBoaW4iIF0sDQog ICAgICAgImxvY2F0aW9ucyI6WyAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvIiwiaHR0cHM6 Ly9yZXNvdXJjZS5sb2NhbC9vdGhlciJdLA0KICAgICAgICJkYXRhdHlwZXMiOlsgIm1ldGFkYXRh IiwiaW1hZ2VzIl0NCiAgICAgfSwNCiAgICAgew0KICAgICAgICJhY3Rpb25zIjpbInJlYWQiLCJ3 cml0ZSJdLA0KICAgICAgICJsb2NhdGlvbnMiOlsiaHR0cHM6Ly9leGFtcGxlLmNvbS9yZXNvdXJj ZSJdDQogICAgIH0NCiAgIF0sDQogICAidG9rZW4yIjpbDQogICAgIHsNCiAgICAgICAiYWN0aW9u cyI6WyJmb28iLCJiYXIiLCAiZG9scGhpbiJdLA0KICAgICAgICJsb2NhdGlvbnMiOlsiaHR0cHM6 Ly9yZXNvdXJjZS5vdGhlci8iXSwNCiAgICAgICAiZGF0YXR5cGVzIjpbImRhdGEiLCJwaWN0dXJl cyJdDQogICAgIH0NCiAgIF0NCiB9DQp9DQoNCnRoZSBBUyB3b3VsZCBuZWVkIHRvIGZ1cnRoZXIg cGFydGl0aW9uIHRoZSBwcmUtZGVmaW5lZCB0b2tlbnMgbGlrZSB0aGlzOg0KDQoibXVsdGlwbGVf YWNjZXNzX3Rva2Vuc+KAnTp7DQogICDigJx0b2tlbjEvYSI6ew0KICAgICAidmFsdWUiOiJPUzlN MlBNSEtVUjY0VEI4TjZCVzdPWkI4Q0RGT05QMjE5UlAxTFQwIiwNCiAgICAgInR5cGUiOiJiZWFy ZXIiLA0KICAgICAibG9jYXRpb25zIjpbImh0dHBzOi8vc2VydmVyLmV4YW1wbGUubmV0LyIsImh0 dHBzOi8vcmVzb3VyY2UubG9jYWwvb3RoZXIiXQ0KICAgfSwNCiAgIOKAnHRva2VuMS9iIjp7DQog ICAgICJ2YWx1ZSI6Ik9TOU0yUE1IS1VSNjRUQjhONkJXN09aQjhDREZPTlAyMTlSUDFMVDAiLA0K ICAgICAidHlwZSI6ImJlYXJlciIsDQogICAgICJsb2NhdGlvbnMiOlsiaHR0cHM6Ly9leGFtcGxl LmNvbS9yZXNvdXJjZSJdDQogICB9LA0KICAg4oCcdG9rZW4yIjp7DQogICAgICJ2YWx1ZSI6IlVG R0xPMkZEQUZHN1ZHWlpQSjNJWkVNTjIxRVZVNzFGSENBUlA0SjEiLA0KICAgICAidHlwZSI6ImJl YXJlciIsDQogICAgICJsb2NhdGlvbnMiOlsNCiAgICAgICAiaHR0cHM6Ly9vdGhlcl9leGFtcGxl LmNvbS9yZXNvdXJjZSINCiAgICAgXQ0KICAgfQ0KIH0NCg0KTmFtaW5nIG9mIHRoZSB0b2tlbnMg aXMgYSBiaXQgdHJpY2t5IGJ1dCBJIHRoaW5rIHNvbHZhYmxlLg0KDQpXaGF0IGRvIHlvdSB0aGlu az8NCg0KYmVzdCByZWdhcmRzLA0KVG9yc3Rlbi4NCg0KPiBPbiAxNS4gTWFyIDIwMjAsIGF0IDE1 OjI2LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KPiANCj4gT24gTWFy IDE1LCAyMDIwLCBhdCA4OjU4IEFNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldD4gd3JvdGU6DQo+PiANCj4+PiBPbiAxNS4gTWFyIDIwMjAsIGF0IDAzOjI1LCBK dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KPj4+IA0KPj4+IFNvIGlmIHRo ZSBBUyBuZWVkcyBhIGNsaWVudCB0byBnZXQgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMgdG8gY2Fs bCBkaWZmZXJlbnQgUlMgZG9tYWlucywgaXQgZG9lcyBleGFjdGx5IHdoYXQgd2UgZG8gaW4gT0F1 dGggMiB0b2RheSDigJQgaXQgdGVsbHMgdGhlIGNsaWVudCB0byBnZXQgdHdvIGRpZmZlcmVudCBh Y2Nlc3MgdG9rZW5zLiANCj4+IA0KPj4gSG93IGRvZXMgdGhpcyB3b3JrIGluIFhZWj8NCj4+IA0K PiANCj4gV2l0aG91dCB1c2luZyB0aGUgbXVsdGktYWNjZXNzLXRva2VuIHRoaW5nIEnigJltIHBy b3Bvc2luZyBpbiB0aGlzIHRocmVhZCwgdGhlIGNsaWVudCB3b3VsZCBqdXN0IG1ha2UgdHdvIHNl cGFyYXRlIHRyYW5zYWN0aW9uIGNhbGxzIHRvIGdldCB0d28gZGlmZmVyZW50IHRva2Vucy4gVGhl cmXigJlzIGEgZmV3IHdheXMgdGhhdCBzaGFrZXMgb3V0IGRlcGVuZGluZyBvbiBzb21lIG9mIHRo ZSBkZXRhaWxzLiBJbiB0aGUgT0F1dGggd29ybGQgdGhhdCBhbW91bnRzIHRvIGludm9sdmluZyB0 aGUgdXNlciB0d2ljZSwgYW5kIGl0IG1pZ2h0IGJlIHRoZSBzYW1lIGluIFhZWiBpZiB5b3XigJly ZSBhc2tpbmcgZm9yIGRpZmZlcmVudCB0aGluZ3M6DQo+IA0KPiAxLiBDbGllbnQ6IFN0YXJ0IFRY LTEgKFItMSkNCj4gMi4gVXNlcjogQXBwcm92ZSBSLTENCj4gMy4gQVM6IElzc3VlIEFULTEoUi0x KQ0KPiA0LiBDbGllbnQ6IFN0YXJ0IFRYLTIgKFItMSkNCj4gNS4gVXNlcjogYXBwcm92ZSBSLTIN Cj4gNi4gQVM6IElzc3VlIEFULTIoUi0yKQ0KPiANCj4gVW5sZXNzIHlvdeKAmXJlIGdldHRpbmcg YSBzdXBlciByZWZyZXNoIHRva2VuIHVwZnJvbnQgYW5kIHRoZW4gY2FsbGluZyBmb3IgdHdvIGRv d25ncmFkZWQgYWNjZXNzIHRva2VucyBsYXRlciDigJQgd2hpY2ggZG9lcyB3b3JrLCBhbmQgSeKA mXZlIGJ1aWx0IG91dCBzeXN0ZW1zIHRoYXQgZG8gZXhhY3RseSB0aGF0LiBYWVogY2FuIGRvIHRo YXQgdHJpY2sgdG9vLg0KPiANCj4gMS4gQ2xpZW50OiBTdGFydCBUWC0xIChSLTEsIFItMikNCj4g Mi4gVXNlcjogQXBwcm92ZSBSLTEsIFItMg0KPiAzLiBBUzogSXNzdWUgQVQxIChSLTEsIFItMikN Cj4gNC4gQ2xpZW50OiBDb250aW51ZSBUWC0xIChSLTIpDQo+IDUuIEFTOiBJc3N1ZSBBVC0yIChS LTIpDQo+IA0KPiBCdXQgd2XigJl2ZSBnb3QgYW5vdGhlciB0aGluZyB3ZSBjYW4gdXNlIGluIFhZ WiB0byBoZWxwIHRoaXMsIHRoZSB1c2VyIGhhbmRsZS4gVGhpcyBsZXRzIGEgdHJ1c3RlZCBjbGll bnQgdGVsbCB0aGUgQVMgdGhhdCBpdCBiZWxpZXZlcyB0aGUgc2FtZSB1c2VyIGlzIHN0aWxsIHRo ZXJlIGFuZCBhc2tpbmcgdGhlIHF1ZXN0aW9uLCBzbyBpZiB0aGUgYWNjZXNzIHJpZ2h0cyBhcmUg T0sgdGhlbiB5b3UgZG9u4oCZdCBuZWVkIHRvIGludm9sdmUgdGhlIHVzZXIgYWdhaW4uIFdlIGlu dmVudGVkIHRoaXMgY29uc3RydWN0IHdpdGggVU1BMiwgd2hlcmUgaXTigJlzIGNhbGxlZCB0aGUg cGVyc2lzdGVkIGNsYWltcyB0b2tlbiAoUENUKS4NCj4gDQo+IDEuIENsaWVudDogU3RhcnQgVFgt MSAoUi0xKQ0KPiAyLiBVc2VyOiBBcHByb3ZlIFItMQ0KPiAzLiBBUzogSXNzdWUgQVQtMSAoUi0x KSwgdXNlciBoYW5kbGUgVS0xIDQuIENsaWVudCBTdGFydCBUWC0yIChSLTIsIA0KPiBVLTEpIDUu IEFTOiBJc3N1ZSBBVC0yIChSLTIpDQo+IA0KPiBOb3c6IFdpdGggdGhlIG11bHRpLXRva2VuIHJl cXVlc3QsIHdlIGNhbiBjb2xsYXBzZSB0aGlzIGFsbCBiYWNrIHRvIGEgc2luZ2xlIHRyYW5zYWN0 aW9uIHdpdGggbXVsdGlwbGUgb3V0cHV0czoNCj4gDQo+IDEuIENsaWVudDogU3RhcnQgVFgtMiAo dG9rZW4xOiBSLTEsIHRva2VuMjogUi0yKSAyLiBVc2VyIEFwcHJvdmUgUi0xLCANCj4gUi0yIDMu IEFTOiBJc3N1ZSBBVC0xICh0b2tlbjE6IFItMSksIEFULTIgKHRva2VuMjogUi0yKQ0KPiANCj4g SSBoYXZlbuKAmXQgbGlrZWQgYW55IG9mIHRoZSBtdWx0aS1hY2Nlc3MtdG9rZW4gc29sdXRpb25z IHRvIGRhdGUgYmVjYXVzZSB0aGV5IG1ha2UgdGhpbmdzIHdlaXJkIGZvciBzaW5nbGUgYWNjZXNz IHRva2VuIHJlcXVlc3RzLiBJIGxpa2UgdGhpcyBpZGVhIGJlY2F1c2UgaXTigJlzIGFuIG9wdGlt aXphdGlvbiBmb3IgYSBjb21wbGV4IGNhc2UgdGhhdCBkb2VzbuKAmXQgY2hhbmdlIHRoZSBiZWhh dmlvciBmb3IgdGhlIHNpbXBsZSBjYXNlLCBhbmQgaW4gZmFjdCBkb2VzbuKAmXQgZXZlbiBjaGFu Z2UgdGhlIGV4cGVjdGF0aW9ucyBmb3IgdGhlIHNpbXBsZSBjYXNlLiBUbyBtZSwgdGhhdOKAmXMg aW1wb3J0YW50Lg0KPiANCj4g4oCUIEp1c3Rpbg0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0K VHhhdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4 YXV0aA0K From nobody Wed Mar 18 15:12:22 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6905F3A1D27 for ; Wed, 18 Mar 2020 15:12:20 -0700 (PDT) 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_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=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 MnCdCD4Ga5B4 for ; Wed, 18 Mar 2020 15:12:17 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450: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 7FAC93A1C8A for ; Wed, 18 Mar 2020 15:12:17 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id a20so120595edj.2 for ; Wed, 18 Mar 2020 15:12:17 -0700 (PDT) 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=Qb5hDgxmkAepRg61L7GOT7TAzIevxICLX8s+5WBuK7Q=; b=QJar0iwBN8SyznEjx0T+WgnbPVI63ZRfj578/YBtfInhfI9EF7IvullLF0ApI50Xyt DAkag3sFS7fBcxtbgkHa0Ac4wCZQCsPru4+7hVu1/RsJg8RQ/krOHdxO4brzn/8D3wsN wldJsptBSblVRMXXNDEy32j6KjhYIevEwaEeGIeyMrZQ9W89U3TumF4KRxAWzXgCc4g3 n2QB6l+VeHnK9baHaImm5fqCvxOiuJZ8XOGJXKCfMYBD3brZPL/NfdnOZ76zIRJ7OjLK LhIe03HwySnlIfycS+TAsICCSYiuSy5UMGe3dbmXj0FfMzENRTegSc7KKNQzyLNscaY3 +B+w== 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=Qb5hDgxmkAepRg61L7GOT7TAzIevxICLX8s+5WBuK7Q=; b=NyEnznxt/U9HQupt8+6HuFo6DBE5cD3/Bue/718BObEY+p6oJGoFBN0xYBnL1gm7Iw UV/08wjYj/XUCSHiDhyoNEILp/O+X8zWEGqN8vTVXYFOol12gA6bt5n6HeNVj8C4Lktx /xNZQC5xX6hG54AoARknIXPWHDaeGkCWZCHONt6SZu9Zz2lOxrMin/7SlLrXB/QZqio5 4wrKO4fW5hY5MtSqxE0RqxQ5OsIoRY1XIafHB5IRowox+uALdDw7dp/UX9lDnFgCU8ws s/jGdynlrT/0oSEl7IVQMAxL76Nfs3XSU4UAF9LtkqWcyzz3Jxqrqq9MW695589n6ERw 25xA== X-Gm-Message-State: ANhLgQ2hQHix5RU/8h+8Mke6mRiVaaBc4wvAQcr5/cSabiSQqA1jtZSa i36j5VS+zwSyxavoWQGL3NXNVHtTidgsI3901+g= X-Google-Smtp-Source: ADFU+vuf+toHPmuuJH0ggDtram8SZ2EZ1FbPenoPqirkuxJfVbQMCNcvRnAZT43Ff5uifxY+NJQwdwUDZJG2ZCEjWGY= X-Received: by 2002:aa7:cf01:: with SMTP id a1mr6415806edy.282.1584569535873; Wed, 18 Mar 2020 15:12:15 -0700 (PDT) MIME-Version: 1.0 References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> <30E67E8A-CD0F-40CD-92C5-12D23E6FB1FA@mit.edu> In-Reply-To: From: David Skaife Date: Wed, 18 Mar 2020 22:12:04 +0000 Message-ID: To: Stephen Moore Cc: Justin Richer , txauth@ietf.org, Dick Hardt Content-Type: multipart/alternative; boundary="0000000000004ec61905a1285841" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 22:12:21 -0000 --0000000000004ec61905a1285841 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for explaining further Justin - that makes more sense now. I think the confusion was that the topic here is simply "Discovery" and also the XAuth rationale section in the original email says "Client can make unauthenticated call to GS URI to learn what GS supports, *such as authentication mechanisms*" - which sounds like an example where the options would potentially be mutually exclusive. So certainly in my mind I was focusing on the mutually exclusive scenarios, which I now appreciate isn't what you intended for the XYZ capabilities feature. Was a useful discussion, thanks. David Skaife On Wed, Mar 18, 2020 at 9:24 PM Stephen Moore wrote: > That makes more sense to me now. Thanks Justin! > I also like that particular solution, rather basically relying on caching > or re-discovery before the transaction begins since, I think, that allows > for more flexible client 'requirements'. > -steve > > On Wed, Mar 18, 2020 at 5:18 PM Justin Richer wrote: > >> Speaking with someone on another channel, let me explain it this way. >> >> This isn=E2=80=99t like =E2=80=9CI will send this to you in JSON or CBOR= , which do you >> want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can take a signed ID to= ken=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. >> So there isn=E2=80=99t an order or a preference or an exclusivity. If yo= u can do >> either of them, or both of them, you just do them. >> >> Doing the OPTIONS call would let the client fetch from the server all of >> that at once, if it wanted too. Allowing it inline lets the client do al= l >> of that without making a second network call or remembering anything. Bu= t >> it always has the option to do so. >> >> =E2=80=94 Justin >> >> On Mar 18, 2020, at 5:04 PM, Justin Richer wrote: >> >> I wasn=E2=80=99t showing just the happy path, but I think my example mig= ht have >> been too simple. Also, I think we've got a different model for what=E2= =80=99s in >> the capabilities. It=E2=80=99s not about a set of mutually exclusive opt= ions that >> the client has to choose from. >> >> Thanks Stephen and Justin for your responses. >> >> I certainly accept some of the points you've raised here. One thing I'd >> like to add though is that the examples you've provided only show the >> happy-path scenario (from a client's perspective) - where the AS >> conveniently supports only one of the capabilities provided by the clien= t. >> What about if we consider the following scenario: >> >> - Client can do A, B, C and D. The AS can do A, B, C, D and E. >> - The client sends [A, B, C, D]. >> - Does the AS now send back [A, B, C, D] >> >> >> Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset of= the >> client=E2=80=99s capabilities. >> >> , and then force the client to make a decision (i.e. complexity on the >> client)? Or instead, does the AS make a decision itself and then only se= nd >> one result back? If the latter, then how would the AS make this decision= , >> and could this potentially result in an undesirable outcome from a clien= t's >> perspective? >> >> >> The client is already declaring that it can do all of those, and so it >> needs to figure out which of those it=E2=80=99s going to use and how the= y work >> together. My intent wasn=E2=80=99t to say that the client could only do = one of >> those at a time, but rather that these were different things that the >> client could support that were optional at the AS, and the AS is telling >> the client which bits that it knows about and can handle. Maybe this is = a >> list of extensions, maybe it=E2=80=99s a list of optional features, but = it=E2=80=99s on top >> of the =E2=80=9Ccore=E2=80=9D portions of the protocol. >> >> I=E2=80=99ll also say that this is completely separate from the discussi= on on how >> to handle interaction =E2=80=94 I think the information patterns on that= (which are >> in a different thread) are much clearer. >> >> >> As you've mentioned, in reality the client would likely "remember" the >> capabilities that the AS supports. So if the AS were instead probed by t= he >> client to retrieve the list of its capabilities, this additional complex= ity >> needed on the client side would not be something that is present in ever= y >> interaction - as the client would simply need to pass it's preferred >> (supported) method on each interaction, rather than having to keep probi= ng >> and filtering on each request. Additionally, this concept of the client >> remembering what the AS supports would negate the argument about there >> being an increase in network traffic raised by Stephen. >> >> >> The reality is that most clients aren=E2=80=99t really going to discover= and >> declare things, especially if the client can start the whole protocol wi= th >> just one bit of information. XYZ originally started with zero discovery, >> because all of the important parts are revealed during the protocol. >> >> >> I don't think it's as clear-cut as you've presented in your responses, >> but I do accept that there are merits to trying to push complexity to th= e >> server. >> >> >> I agree that it=E2=80=99s not that clear cut yet =E2=80=94 but that=E2= =80=99s largely because >> there aren=E2=80=99t a lot of concrete things that would go in this =E2= =80=9Cdiscovery=E2=80=9D >> document yet. At least with XYZ, we deliberately minimized what the clie= nt >> would need to know going in, for both simplicity and security. When you >> make the core protocol such that you don=E2=80=99t need a lot of extra b= its in >> order for things to function, then you aren=E2=80=99t creating problems = that you >> need solutions for. >> >> Thanks for raising the discussion! >> >> >> Many thanks, >> David Skaife >> >> On Wed, Mar 18, 2020 at 8:22 PM Justin Richer wrote: >> >>> OAuth 2 has taught us that wherever possible, you should push the >>> complexity to the server, not the client. That=E2=80=99s the idea behin= d the kind >>> of publication/negotiation here where the client can do something simpl= e >>> and the AS needs to make the actual comparison and decision, whatever t= hat >>> is. Clients need to stay simple because, for the most part, the focus o= f >>> the client is on calling whatever API and implementing whatever >>> functionality it is doing, not on the security layer. The AS is a dedic= ated >>> security component, so it=E2=80=99s got the mandate to figure this stuf= f out. This >>> mindset is one of OAuth 2=E2=80=99s biggest strengths. >>> >>> So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t= really :used: >>> this feature beyond making sure the protocol can be passed back and for= th, >>> since there=E2=80=99s not a lot of optionality that really needs to be = negotiated >>> here. >>> >>> So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D,= and X. >>> If the client doesn=E2=80=99t know anything at all about the AS, the cl= ient sends: >>> >>> [A, B, C] >>> >>> And the server looks at that, compares with what it can do, and returns= : >>> >>> [B] >>> >>> The server doesn=E2=80=99t send D, or X, because the client wouldn=E2= =80=99t have any >>> clue what to do about that. The client can remember that if it wants to >>> cache that part of the response. >>> >>> So the question is, what if the client knew that only B would be >>> successful for this server? That=E2=80=99s pretty common because a lot = of clients >>> get written and configured with a static set of capabilities for a serv= er. >>> And with the negotiation above, the client just needs to remember after= the >>> first call. So in both cases, the client would only send [B], or leave = it >>> off entirely because it doesn=E2=80=99t need to negotiate, and you=E2= =80=99re done. >>> >>> But the thing is, you could do both styles with one simple twist. If yo= u >>> want to do the discovery portion in a pre-flight request, I think it=E2= =80=99s a >>> good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t make = any sense to >>> me to allow it on any other endpoints, especially because some of those= are >>> going to be user-facing (so the client is not going to be talking to th= e >>> URL itself). The client makes this call and gets back: >>> >>> [B, D, X] >>> >>> And now the client has to put together its possible capabilities from >>> that list and what it knows it can do. By putting OPTIONS on the endpoi= nt >>> then we can stick with the same mantra of the client having one piece o= f >>> info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 a= nd learning everything else >>> from that. I think that part is simple enough to potentially work, and = XYZ >>> doesn=E2=80=99t have other endpoints or aspects that need to be discove= red out of >>> band, unlike OAuth 2. >>> >>> =E2=80=94 Justin >>> >>> >>> >>> On Mar 18, 2020, at 3:44 PM, David Skaife < >>> blue.ringed.octopus.guy@gmail.com> wrote: >>> >>> Hi, >>> >>> My thoughts on these different approaches are: >>> >>> 1. For XYZ, it feels a bit strange and unnecessary to require the clien= t >>> to have to state it's full set of capabilities to the AS. It feels like= it >>> should be the other way around - i.e. the client is able to probe what = the >>> AS supports. In my view it's more natural for the AS to be "advertising= " >>> its capabilities rather than the client. >>> >>> 2. I prefer the XYZ approach of having a single URL that the client >>> knows it needs to interact to start the transaction, vs the more comple= x >>> approach provided by XAuth. >>> >>> 3. Hopefully there is a middle ground between the two approaches that >>> addresses the two points above. >>> >>> >>> Many thanks, >>> David Skaife >>> >>> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt >>> wrote: >>> >>>> >>>> *Discovery* >>>> XYZ >>>> - Client always starts at the tx endpoint, all other information is >>>> dispatched from responses from the endpoint >>>> - Clients sends capabilities list in transaction request, AS selects >>>> and returns which capabilities are supported >>>> >>>> XYZ Rationale: client needs a single URL to start talking to an AS, >>>> giving developers multiple ways to get information is confusing and ca= n >>>> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by O= IDC=E2=80=99s >>>> discovery approach) >>>> >>>> XAuth >>>> - Client sends an OPTIONS call to the GS URI, Grant URI, or >>>> Authorization URI >>>> >>>> XAuth Rationale: Client can make unauthenticated call to GS URI to >>>> learn what GS supports, such as authentication mechanisms. Authenticat= ed >>>> calls return what a specific Client can do. >>>> >>>> >>>> =E1=90=A7 >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --0000000000004ec61905a1285841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks=C2=A0for explaining further Justin - that makes mor= e sense now.

I think the confusion was that the topic here is = simply "Discovery" and also the XAuth rationale section in the or= iginal email says "Client can make unauthenticated call to GS URI to l= earn what GS supports, such as authentication mechanisms" - whi= ch sounds like an example where the options would potentially be mutually e= xclusive. So certainly in my mind I was focusing on the mutually=C2=A0exclu= sive scenarios, which I now appreciate isn't what you intended for the = XYZ capabilities feature.

Was a useful discussion, thanks.

<= /div>
David Skaife

On Wed, Mar 18, 2020 at 9:24 PM Ste= phen Moore <srmoore@gmail.com&g= t; wrote:
That makes more sense to me now. Thanks Justin!
I also like = that particular solution, rather basically relying on caching or re-discove= ry before the transaction begins since, I think, that allows for more flexi= ble client 'requirements'.
-steve

On Wed, Mar 18, 20= 20 at 5:18 PM Justin Richer <jricher@mit.edu> wrote:
Speaking with someone on another channel, l= et me explain it this way.

This isn=E2=80=99t like =E2= =80=9CI will send this to you in JSON or CBOR, which do you want?=E2=80=9D = It=E2=80=99s more like =E2=80=9CI can take a signed ID token=E2=80=9D and = =E2=80=9CI speak French=E2=80=9D. So there isn=E2=80=99t an order or a pref= erence or an exclusivity. If you can do either of them, or both of them, yo= u just do them.

Doing the OPTIONS call would let t= he client fetch from the server all of that at once, if it wanted too. Allo= wing it inline lets the client do all of that without making a second netwo= rk call or remembering anything. But it always has the option to do so.

=C2=A0=E2=80=94 Justin

On Mar 18, 2020, at 5:04 PM, Justin Richer <jricher@mit.edu> wrote:
I wasn=E2=80=99t = showing just the happy path, but I think my example might have been too sim= ple. Also, I think we've got a different model for what=E2=80=99s in th= e capabilities. It=E2=80=99s not about a set of mutually exclusive options = that the client has to choose from.

Thanks Stephen and Justin for yo= ur responses.

I certainly accept some of the= points you've raised here. One thing I'd like to add though is tha= t the examples you've provided only show the happy-path scenario (from = a client's perspective) - where the AS conveniently supports only one o= f the capabilities provided by the client. What about if we consider the fo= llowing scenario:

- Client can do A, B, C and D. The AS can do A, B,= C, D and E.
- The client sends [A, B, C, D].
- Does the AS now send = back [A, B, C, D]

Yes, the AS s= ends back [A, B, C, D] because that=E2=80=99s the subset of the client=E2= =80=99s capabilities.=C2=A0

, and then force the client to make a decision (i.e. complexity o= n the client)? Or instead, does the AS make a decision=C2=A0itself and then= only send one result back? If the latter, then how would the AS make this = decision, and could this potentially result in an undesirable outcome from = a client's perspective?

The client is already declaring that it can do all of those, and so it nee= ds to figure out which of those it=E2=80=99s going to use and how they work= together. My intent wasn=E2=80=99t to say that the client could only do on= e of those at a time, but rather that these were different things that the = client could support that were optional at the AS, and the AS is telling th= e client which bits that it knows about and can handle. Maybe this is a lis= t of extensions, maybe it=E2=80=99s a list of optional features, but it=E2= =80=99s on top of the =E2=80=9Ccore=E2=80=9D portions of the protocol.=C2= =A0

I=E2=80=99ll also say that this is completely = separate from the discussion on how to handle interaction =E2=80=94 I think= the information patterns on that (which are in a different thread) are muc= h clearer.=C2=A0

<= br>As you've mentioned, in reality the client would likely "rememb= er" the capabilities=C2=A0that the AS supports. So if the AS were inst= ead probed by the client to retrieve the list of its capabilities, this add= itional complexity needed on the client side would not be something that is= present in every interaction - as the client would simply need to pass it&= #39;s preferred (supported) method on each interaction, rather than having = to keep probing and filtering on each request. Additionally, this concept o= f the client remembering what the AS supports would negate the argument abo= ut there being an increase in network traffic raised by Stephen.
<= /div>

The reality is that most clients aren= =E2=80=99t really going to discover and declare things, especially if the c= lient can start the whole protocol with just one bit of information. XYZ or= iginally started with zero discovery, because all of the important parts ar= e revealed during the protocol.=C2=A0


I don't think it's as clear-cut as you'= ve presented in your responses, but I do accept that there are merits to tr= ying to push complexity to the server.


I agree that it=E2=80=99s not that clear cut yet =E2=80=94 = but that=E2=80=99s largely because there aren=E2=80=99t a lot of concrete t= hings that would go in this =E2=80=9Cdiscovery=E2=80=9D document yet. At le= ast with XYZ, we deliberately minimized what the client would need to know = going in, for both simplicity and security. When you make the core protocol= such that you don=E2=80=99t need a lot of extra bits in order for things t= o function, then you aren=E2=80=99t creating problems that you need solutio= ns for.

Thanks for raising the discussion!

Many thanks,
David= Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer <jricher@mit.edu> wrote:
=
OAuth 2 has taught u= s that wherever possible, you should push the complexity to the server, not= the client. That=E2=80=99s the idea behind the kind of publication/negotia= tion here where the client can do something simple and the AS needs to make= the actual comparison and decision, whatever that is. Clients need to stay= simple because, for the most part, the focus of the client is on calling w= hatever API and implementing whatever functionality it is doing, not on the= security layer. The AS is a dedicated security component, so it=E2=80=99s = got the mandate to figure this stuff out. This mindset is one of OAuth 2=E2= =80=99s biggest strengths.=C2=A0

So how would this work = in XYZ? I=E2=80=99ll say that we haven=E2=80=99t really :used: this feature= beyond making sure the protocol can be passed back and forth, since there= =E2=80=99s not a lot of optionality that really needs to be negotiated here= .

So let=E2=80=99s say the client can do A, B, and C= . The AS can do B, D, and X. If the client doesn=E2=80=99t know anything at= all about the AS, the client sends:

[A, B, C]

And the server looks at that, compares with what it c= an do, and returns:

[B]

T= he server doesn=E2=80=99t send D, or X, because the client wouldn=E2=80=99t= have any clue what to do about that. The client can remember that if it wa= nts to cache that part of the response.

So the que= stion is, what if the client knew that only B would be successful for this = server? That=E2=80=99s pretty common because a lot of clients get written a= nd configured with a static set of capabilities for a server. And with the = negotiation above, the client just needs to remember after the first call. = So in both cases, the client would only send [B], or leave it off entirely = because it doesn=E2=80=99t need to negotiate, and you=E2=80=99re done.=C2= =A0

But the thing is, you could do both styles wit= h one simple twist. If you want to do the discovery portion in a pre-flight= request, I think it=E2=80=99s a good idea to allow OPTIONS on the tx endpo= int. It doesn=E2=80=99t make any sense to me to allow it on any other endpo= ints, especially because some of those are going to be user-facing (so the = client is not going to be talking to the URL itself). The client makes this= call and gets back:

[B, D, X]

And now the client has to put together its possible capabilities from= that list and what it knows it can do. By putting OPTIONS on the endpoint = then we can stick with the same mantra of the client having one piece of in= fo to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and lea= rning everything else from that. I think that part is simple enough to pote= ntially work, and XYZ doesn=E2=80=99t have other endpoints or aspects that = need to be discovered out of band, unlike OAuth 2.

=C2=A0=E2=80=94 Justin



On Mar 18, 2020, at 3:44 PM, David Skaife <blue.ringed.oct= opus.guy@gmail.com> wrote:

Hi,
My thoughts on these different approaches are:

1. For X= YZ, it feels a bit strange and unnecessary to require the client to have to= state it's full set of capabilities to the AS. It feels like it should= be the other way around - i.e. the client is able to probe what the AS sup= ports. In my view it's more natural for the AS to be "advertising&= quot; its capabilities rather than the client.

2. I prefer the XYZ a= pproach of having a single URL that the client knows it needs to interact t= o start the transaction, vs the more complex approach=C2=A0provided by XAut= h.

3. Hopefully there is a middle ground between the two approaches = that addresses the two points above.


Many thanks,
David Skaif= e

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
= Discovery

XYZ
=C2=A0- Client always starts at the tx endpo= int, all other information is dispatched from responses from the endpoint=C2=A0- Clients sends capabilities list in transaction request, AS select= s and returns which capabilities are supported

XYZ Rationale: client= needs a single URL to start talking to an AS, giving developers multiple w= ays to get information is confusing and can lead to serious errors (see OAu= th2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s discovery approach)
XAuth
=C2=A0- Client sends an OPTIONS call to the GS URI, Grant URI= , or Authorization URI

XAuth Rationale: Client can make unauthentica= ted call to GS URI to learn what GS supports, such as authentication mechan= isms. Authenticated calls return what a specific Client can do.


=
3D""==E1=90=A7
--=C2=A0
Txauth = mailing list
Txauth= @ietf.org
https://www.ietf.org/mailman/listinfo/t= xauth


--=C2=A0
Txauth mailin= g list
Txauth@ietf.org
https://www.ietf.org/mailman/list= info/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000004ec61905a1285841-- From nobody Wed Mar 18 15:44:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648523A1DAB for ; Wed, 18 Mar 2020 15:44:57 -0700 (PDT) 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=unavailable 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 REfwbxkPSREq for ; Wed, 18 Mar 2020 15:44:54 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 2DF0D3A1DA7 for ; Wed, 18 Mar 2020 15:44:49 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id v6so170054edw.8 for ; Wed, 18 Mar 2020 15:44:48 -0700 (PDT) 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=IwE+IPSkVdvQ5UGjwmEoSmKk5iLTFpO/CJfeW+oPj3w=; b=P8L93uRH2faKEvEjVly8Ktqq0avBMMKpGiBz+Gs4bZ87dliYyWqO3r6DZ2rg5QaXnQ DbWN9owwtpio3jrJ6IRD8Csiixqlh1mG3LKDaLbtOuVCuuRBxPdJQLwmE94avgdEEJFR tJkwedTcYHvqNz+H5Fp14D6fWdGurzQMwVd9Si6LgxeUl2zy2eQjEtajUjK0N4iMRDWy O5Fr/4Jp6+OFaRBbnJ9wpiq0gpJry51zmAiSg2xnBKeQh2tp2KvksUen3Bo7tnTupUZP 2iGGjfPNv8tU07MA3z1EqWJXXnhZ9StMikp3J3uYy83fgA5YyhJ7wm374gLLgLxwWkNp n8cQ== 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=IwE+IPSkVdvQ5UGjwmEoSmKk5iLTFpO/CJfeW+oPj3w=; b=shjBis4Z4UdZrEDO26iZVc2GbdW/2LhZazTwZv7Te7Fr6B7S9onSyOkOTR2FOs/137 4FUCVUjuhB12Z4bOF9C2nP2wqaCjUTYCY1oExRzpsiZNoKBELAwpjuvXPsFwUAyINpc0 D56NIZMx735IqoDSIp3Idbv0H+CnylfKZ2WzrbtNRMLDQCB8F60iRflixqqh2s1oNtrL GR4cgNSQ8odEXLzzsRyPItjFIc+8oZAY/c9fh9ubkdmNx2m4K3WZSIrRVSIL8QX/m1WQ lEwqZy99PDyzsGeKzo6WLUSX7paIZc5a4hLTeNdvTeVllmY8hv/8Jj4TNDcMoMGYH+x3 OVLg== X-Gm-Message-State: ANhLgQ2u8EeJb3s46Ser38ssmfY9q3gv9JMQFefzDRzWfDscUKJPyCAS iSjDthhhghdGZss9fqzxVVtTU5gjBYix+dVcVKAN7YNE X-Google-Smtp-Source: ADFU+vs+kX/SobIti787IaXYP3fVyd1nTiBq5ZBDgQSXuvB3PWDP47GVBA1X2Jsb1tihqX508qV5LrvowgcvFM4n4pQ= X-Received: by 2002:a17:907:6f1:: with SMTP id yh17mr539255ejb.20.1584571487322; Wed, 18 Mar 2020 15:44:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Wed, 18 Mar 2020 22:44:35 +0000 Message-ID: To: Justin Richer Cc: Aaron Parecki , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009f89ea05a128cc0f" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 22:44:58 -0000 --0000000000009f89ea05a128cc0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, As one of the four people who expressed a slight concern about including identity within the TxAuth charter, I'd like to say that I would definitely be supportive of the proposal to explicitly state which elements of identity are included - to narrow the scope. I accept that removing identity completely doesn't seem to have general support amongst the group. The root cause of my concern is that, by including the full scope of identity and the full set of use cases that OpenID Connect supports today, I envisage that resulting in the WG having such a broad scope that we would spend years on end thrashing through it and then no protocol ever actually getting agreed/standardised. Many thanks, David Skaife On Tue, Mar 17, 2020 at 10:47 PM Justin Richer wrote: > +1 > > Thanks, Aaron. I think it really is a very narrow slice of identity that > we want to cover here, and I=E2=80=99d be happy to get more precise langu= age into > the proposed charter before moving forward. > > =E2=80=94 Justin > > > On Mar 17, 2020, at 6:31 PM, Aaron Parecki wrote: > > > > Much of the confusion in the marketplace around OAuth and OpenID > > Connect stems from the fact that they are separate specs developed in > > separate organizations, when really they are two parts to the same > > picture. I am strongly against excluding identity from the charter of > > TxAuth, as I think this is a unique opportunity to bring the two > > aspects together. > > > > The concern expressed by Kim > > ( > https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE) > > around OpenID Connect could also be said about OAuth, namely that > > there will be some amount of confusion around the fact that this spec > > will cover many of the same use cases as OAuth. I think that's fine, > > that's just how we move forward and make progress. > > > > The other concerns seem vague, e.g. "identity is a huge topic". While > > that may be true, so is authorization, and that alone is not a good > > reason to not do it. > > > > Perhaps the scope of identity included in TxAuth could be narrowed to > > specify that it's only about communicating identity information, not > > about doing things like identity proofing or identity assurance. That > > might help address some of the other concerns that have been > > expressed. > > > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > > > > On Tue, Mar 17, 2020 at 3:06 PM Mike Jones > > wrote: > >> > >> I believe it's significant that four people have expressed concerns > with including digital identity in the charter (the only concerns voiced = as > far as I can tell). At a minimum, I believe that that warrants making th= e > inclusion or exclusion of digital identity a discussion topic during the > upcoming virtual BoF, before adopting any charter. > >> > >> It would be my proposal to initially charter without digital identity > and see how far we get with our energies intentionally focused in that > way. If the working group decides to recharter to include digital > identity, that can always happen later, after the authorization-focused > work has matured, and once there's a clear case to actually do so. > >> > >> -- Mike > >> > >> -----Original Message----- > >> From: Justin Richer > >> Sent: Tuesday, March 17, 2020 2:20 PM > >> To: Mike Jones > >> Cc: Yaron Sheffer ; Torsten Lodderstedt < > torsten@lodderstedt.net>; txauth@ietf.org > >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > >> > >> While I understand the concerns around identity in the charter, and I > had initially not included it, I was convinced that the kind of identity > protocol that we=E2=80=99re looking at here is a minor addition to the > authorization and delegation end of things. > >> > >> As you know, much of what=E2=80=99s in OIDC is there to fix problems w= ith OAuth > 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those proble= ms > internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now > starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know > what other problems there might be. > >> > >> The market has shown us that the most common application of OAuth 2 is > far and away access to identity information along side access to an API. = I > think we need to pay attention to that and not make this separate just > because we did it that way before. And some of the proposed innovations, > including getting and sending VC=E2=80=99s, are all about identity. > >> > >> Furthermore, this charter does not specify the document and > specification structure of the components, nor does it specify the > publication order or timing of any documents. I personally think that the > identity layer should be separable to an extent, to the point of publishi= ng > that layer in its own spec alongside the core authorization delegation > system. However, that does not mean that it should be developed elsewhere= . > >> > >> If there is better language to tighten the aspects of an identity > protocol that we will explicitly cover, then I would welcome you to sugge= st > an amended text to the charter. However, I believe there is enough intere= st > within the community to work on identity in the context of this protocol, > including a large number of people being OK with it in the charter, that = it > would not be a reasonable thing to remove it. > >> > >> =E2=80=94 Justin > >> > >>> On Mar 17, 2020, at 1:12 PM, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >>> > >>> 1. Do you support the charter text provided at the end of this > email? Or do you have major objections, blocking concerns or feedback (i= f > so please elaborate)? > >>> > >>> I share the concerns about including identity in the charter that wer= e > expressed by Torsten and agreed with by David Skaife. I'll note that Kim > Cameron previously expressed concerns about including identity in his > earlier charter critique at > https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/= . > >>> > >>> I'm fine with refactoring the authorization protocol. But identity > should be decoupled from the TxAuth work to focus its scope on areas wher= e > innovation is being proposed. Digital identity can always be added as a > layer if needed, just as OpenID Connect layered identity onto OAuth 2.0. > >>> > >>> Please revise the charter to remove digital identity from the scope o= f > the work. > >>> > >>> 2. Are you willing to author or participate in the development of th= e > drafts of this WG? > >>> > >>> Yes > >>> > >>> 3. Are you willing to help review the drafts of this WG? > >>> > >>> Yes > >>> > >>> 4. Are you interested in implementing drafts of this WG? > >>> > >>> Not at this time. > >>> > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: Txauth On Behalf Of Torsten > Lodderstedt > >>> Sent: Saturday, March 7, 2020 7:18 AM > >>> To: Yaron Sheffer > >>> Cc: txauth@ietf.org > >>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth = WG > >>> > >>> Hi, > >>> > >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = : > >>>> > >>>> =EF=BB=BFHi Everyone, > >>>> > >>>> It appears that momentum is forming around the proposed formation of > a TxAuth working group. We=E2=80=99d like to more formally gauge interes= t in > proceeding with this work. Please do so by responding to the following > questions: > >>>> > >>>> 1. Do you support the charter text provided at the end of this > email? Or do you have major objections, blocking concerns or feedback (i= f > so please elaborate)? > >>> > >>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerne= d the scope of > the charter is too broad, e.g. identify alone is a huge topic. > >>> > >>> We need to keep an eye on this aspect in order to make sure, the grou= p > is able to work effectively and the specs we will be producing are as > simple as possible and foster interoperability. > >>> > >>>> > >>>> 2. Are you willing to author or participate in the development of > the drafts of this WG? > >>> > >>> yes > >>> > >>>> > >>>> 3. Are you willing to help review the drafts of this WG? > >>> > >>> yes > >>> > >>>> > >>>> 4. Are you interested in implementing drafts of this WG? > >>> > >>> yes > >>> > >>> best regards, > >>> Torsten. > >>> > >>>> > >>>> The call will run for two weeks, until March 21. If you think that > the charter should be amended In a significant way, please reply on a > separate thread. > >>>> > >>>> The feedback provided here will help the IESG come to a decision on > the formation of a new WG. Given the constraints of the chartering proces= s, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > >>>> > >>>> Thanks, > >>>> Yaron and Dick > >>>> > >>>> --- Charter Text Follows --- > >>>> > >>>> This group is chartered to develop a fine-grained delegation protoco= l > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > >>>> > >>>> The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > >>>> > >>>> Additionally, the delegation process will allow for: > >>>> > >>>> - Fine-grained specification of access > >>>> - Approval of AS attestation to identity claims > >>>> - Approval of access to multiple resources and APIs in a single > interaction > >>>> - Separation between the party authorizing access and the party > operating the client requesting access > >>>> - A variety of client applications, including Web, mobile, > single-page, and interaction-constrained applications > >>>> > >>>> The group will define extension points for this protocol to allow fo= r > flexibility in areas including: > >>>> > >>>> - Cryptographic agility for keys, message signatures, and proof of > possession > >>>> - User interaction mechanisms including web and non-web methods > >>>> - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > >>>> - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > >>>> - Optimized inclusion of additional information through the > delegation process (including identity) > >>>> > >>>> Additionally, the group will provide mechanisms for management of th= e > protocol lifecycle including: > >>>> > >>>> - Discovery of the authorization server > >>>> - Revocation of active tokens > >>>> - Query of token rights by resource servers > >>>> > >>>> Although the artifacts for this work are not intended or expected to > be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > >>>> > >>>> This group is not chartered to develop extensions to OAuth 2.0, and > as such will focus on new technological solutions not necessarily > compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.= 0 > will be developed in the OAuth Working Group, including functionality > back-ported from the protocol developed here to OAuth 2.0. > >>>> > >>>> The group is chartered to develop mechanisms for applying > cryptographic methods, such as JOSE and COSE, to the delegation process. > This group is not chartered to develop new cryptographic methods. > >>>> > >>>> The initial work will focus on using HTTP for communication between > the client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > >>>> > >>>> Milestones to include: > >>>> - Core delegation protocol > >>>> - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > >>>> - Identity and authentication conveyance mechanisms > >>>> - Guidelines for use of protocol extension points > >>>> > >>>> > >>>> -- > >>>> Txauth mailing list > >>>> Txauth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/txauth > >>> -- > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth > >> > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000009f89ea05a128cc0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As one of the=C2=A0four people who = expressed a slight concern about including identity within the TxAuth chart= er, I'd like to say that I would definitely be supportive of the propos= al to explicitly state which elements of identity are included - to narrow = the scope. I accept that removing identity completely doesn't seem to h= ave general support amongst the group. The root cause of my concern is that= , by including the full scope of identity and the full set of use cases tha= t OpenID Connect supports today, I envisage that resulting in the WG having= such a broad scope that we would spend years on end thrashing through it a= nd then no protocol ever actually getting agreed/standardised.


<= /div>
Many thanks,
David Skaife

On Tue, Mar 17, 2020 at = 10:47 PM Justin Richer <jricher@mit.e= du> wrote:
aaron@parecki.com> wrote:
>
> Much of the confusion in the marketplace around OAuth and OpenID
> Connect stems from the fact that they are separate specs developed in<= br> > separate organizations, when really they are two parts to the same
> picture. I am strongly against excluding identity from the charter of<= br> > TxAuth, as I think this is a unique opportunity to bring the two
> aspects together.
>
> The concern expressed by Kim
> (https://mailarchive.ie= tf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)
> around OpenID Connect could also be said about OAuth, namely that
> there will be some amount of confusion around the fact that this spec<= br> > will cover many of the same use cases as OAuth. I think that's fin= e,
> that's just how we move forward and make progress.
>
> The other concerns seem vague, e.g. "identity is a huge topic&quo= t;. While
> that may be true, so is authorization, and that alone is not a good > reason to not do it.
>
> Perhaps the scope of identity included in TxAuth could be narrowed to<= br> > specify that it's only about communicating identity information, n= ot
> about doing things like identity proofing or identity assurance. That<= br> > might help address some of the other concerns that have been
> expressed.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
> On Tue, Mar 17, 2020 at 3:06 PM Mike Jones
> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> I believe it's significant that four people have expressed con= cerns with including digital identity in the charter (the only concerns voi= ced as far as I can tell).=C2=A0 At a minimum, I believe that that warrants= making the inclusion or exclusion of digital identity a discussion topic d= uring the upcoming virtual BoF, before adopting any charter.
>>
>> It would be my proposal to initially charter without digital ident= ity and see how far we get with our energies intentionally focused in that = way.=C2=A0 If the working group decides to recharter to include digital ide= ntity, that can always happen later, after the authorization-focused work h= as matured, and once there's a clear case to actually do so.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>>
>> -----Original Message-----
>> From: Justin Richer <jricher@mit.edu>
>> Sent: Tuesday, March 17, 2020 2:20 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt= .net>; txauth@i= etf.org
>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
>>
>> While I understand the concerns around identity in the charter, an= d I had initially not included it, I was convinced that the kind of identit= y protocol that we=E2=80=99re looking at here is a minor addition to the au= thorization and delegation end of things.
>>
>> As you know, much of what=E2=80=99s in OIDC is there to fix proble= ms with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and smalle= r. We=E2=80=99re now starting at a base where those problems don=E2=80=99t = exist, but we don=E2=80=99t yet know what other problems there might be. >>
>> The market has shown us that the most common application of OAuth = 2 is far and away access to identity information along side access to an AP= I. I think we need to pay attention to that and not make this separate just= because we did it that way before. And some of the proposed innovations, i= ncluding getting and sending VC=E2=80=99s, are all about identity.
>>
>> Furthermore, this charter does not specify the document and specif= ication structure of the components, nor does it specify the publication or= der or timing of any documents. I personally think that the identity layer = should be separable to an extent, to the point of publishing that layer in = its own spec alongside the core authorization delegation system. However, t= hat does not mean that it should be developed elsewhere.
>>
>> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to suggest= an amended text to the charter. However, I believe there is enough interes= t within the community to work on identity in the context of this protocol,= including a large number of people being OK with it in the charter, that i= t would not be a reasonable thing to remove it.
>>
>> =E2=80=94 Justin
>>
>>> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microso= ft.com@dmarc.ietf.org> wrote:
>>>
>>> 1.=C2=A0 Do you support the charter text provided at the end o= f this email?=C2=A0 Or do you have major objections, blocking concerns or f= eedback (if so please elaborate)?
>>>
>>> I share the concerns about including identity in the charter t= hat were expressed by Torsten and agreed with by David Skaife.=C2=A0 I'= ll note that Kim Cameron previously expressed concerns about including iden= tity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacX= SnshX2CahE/.
>>>
>>> I'm fine with refactoring the authorization protocol.=C2= =A0 But identity should be decoupled from the TxAuth work to focus its scop= e on areas where innovation is being proposed.=C2=A0 Digital identity can a= lways be added as a layer if needed, just as OpenID Connect layered identit= y onto OAuth 2.0.
>>>
>>> Please revise the charter to remove digital identity from the = scope of the work.
>>>
>>> 2.=C2=A0 Are you willing to author or participate in the devel= opment of the drafts of this WG?
>>>
>>> Yes
>>>
>>> 3.=C2=A0 Are you willing to help review the drafts of this WG?=
>>>
>>> Yes
>>>
>>> 4.=C2=A0 Are you interested in implementing drafts of this WG?=
>>>
>>> Not at this time.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>>>
>>> -----Original Message-----
>>> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodder= stedt
>>> Sent: Saturday, March 7, 2020 7:18 AM
>>> To: Yaron Sheffer <yaronf.ietf@gmail.com>
>>> Cc: txaut= h@ietf.org
>>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG
>>>
>>> Hi,
>>>
>>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>>>
>>>> =EF=BB=BFHi Everyone,
>>>>
>>>> It appears that momentum is forming around the proposed fo= rmation of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally= gauge interest in proceeding with this work.=C2=A0 Please do so by respond= ing to the following questions:
>>>>
>>>> 1.=C2=A0 Do you support the charter text provided at the e= nd of this email?=C2=A0 Or do you have major objections, blocking concerns = or feedback (if so please elaborate)?
>>>
>>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly c= oncerned the scope of the charter is too broad, e.g. identify alone is a hu= ge topic.
>>>
>>> We need to keep an eye on this aspect in order to make sure, t= he group is able to work effectively and the specs we will be producing are= as simple as possible and foster interoperability.
>>>
>>>>
>>>> 2.=C2=A0 Are you willing to author or participate in the d= evelopment of the drafts of this WG?
>>>
>>> yes
>>>
>>>>
>>>> 3.=C2=A0 Are you willing to help review the drafts of this= WG?
>>>
>>> yes
>>>
>>>>
>>>> 4.=C2=A0 Are you interested in implementing drafts of this= WG?
>>>
>>> yes
>>>
>>> best regards,
>>> Torsten.
>>>
>>>>
>>>> The call will run for two weeks, until March 21. If you th= ink that the charter should be amended In a significant way, please reply o= n a separate thread.
>>>>
>>>> The feedback provided here will help the IESG come to a de= cision on the formation of a new WG. Given the constraints of the charterin= g process, regardless of the outcome of this consensus call, we will be mee= ting in Vancouver as a BoF.
>>>>
>>>> Thanks,
>>>> Yaron and Dick
>>>>
>>>> --- Charter Text Follows ---
>>>>
>>>> This group is chartered to develop a fine-grained delegati= on protocol for authorization, identity, and API access. This protocol will= allow an authorizing party to delegate access to client software through a= n authorization server. It will expand upon the uses cases currently suppor= ted by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to s= upport authorizations scoped as narrowly as a single transaction, provide a= clear framework for interaction among all parties involved in the protocol= flow, and remove unnecessary dependence on a browser or user-agent for coo= rdinating interactions.
>>>>
>>>> The delegation process will be acted upon by multiple part= ies in the protocol, each performing a specific role. The protocol will dec= ouple the interaction channels, such as the end user=E2=80=99s browser, fro= m the delegation channel, which happens directly between the client and the= authorization server (in contrast with OAuth 2.0 which is initiated by the= client redirecting the user=E2=80=99s browser). The client and AS will inv= olve a user to make an authorization decision as necessary through interact= ion mechanisms indicated by the protocol. This decoupling avoids many of th= e security concerns and technical challenges of OAuth 2.0 and provides a no= n-invasive path for supporting future types of clients and interaction chan= nels.
>>>>
>>>> Additionally, the delegation process will allow for:
>>>>
>>>> - Fine-grained specification of access
>>>> - Approval of AS attestation to identity claims
>>>> - Approval of access to multiple resources and APIs in a s= ingle interaction
>>>> - Separation between the party authorizing access and the = party operating the client requesting access
>>>> - A variety of client applications, including Web, mobile,= single-page, and interaction-constrained applications
>>>>
>>>> The group will define extension points for this protocol t= o allow for flexibility in areas including:
>>>>
>>>> - Cryptographic agility for keys, message signatures, and = proof of possession
>>>> - User interaction mechanisms including web and non-web me= thods
>>>> - Mechanisms for conveying user, software, organization, a= nd other pieces of information used in authorization decisions
>>>> - Mechanisms for presenting tokens to resource servers and= binding resource requests to tokens and associated cryptographic keys
>>>> - Optimized inclusion of additional information through th= e delegation process (including identity)
>>>>
>>>> Additionally, the group will provide mechanisms for manage= ment of the protocol lifecycle including:
>>>>
>>>> - Discovery of the authorization server
>>>> - Revocation of active tokens
>>>> - Query of token rights by resource servers
>>>>
>>>> Although the artifacts for this work are not intended or e= xpected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the gr= oup will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to= the new protocol where possible.
>>>>
>>>> This group is not chartered to develop extensions to OAuth= 2.0, and as such will focus on new technological solutions not necessarily= compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0= will be developed in the OAuth Working Group, including functionality back= -ported from the protocol developed here to OAuth 2.0.
>>>>
>>>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. Th= is group is not chartered to develop new cryptographic methods.
>>>>
>>>> The initial work will focus on using HTTP for communicatio= n between the client and the authorization server, taking advantage of opti= mization features of HTTP2 and HTTP3 where possible, and will strive to ena= ble simple mapping to other protocols such as COAP when doing so does not c= onflict with the primary focus.
>>>>
>>>> Milestones to include:
>>>> - Core delegation protocol
>>>> - Key presentation mechanism bindings to the core protocol= for TLS, detached HTTP signature, and embedded HTTP signatures
>>>> - Identity and authentication conveyance mechanisms
>>>> - Guidelines for use of protocol extension points
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txaut= h@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/t= xauth
>>> --
>>> Txauth mailing list
>>> Txauth@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/txa= uth
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000009f89ea05a128cc0f-- From nobody Thu Mar 19 05:36:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7033A289F for ; Thu, 19 Mar 2020 05:36:17 -0700 (PDT) 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, 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 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 YMiVIWs9wpLS for ; Thu, 19 Mar 2020 05:36:14 -0700 (PDT) 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 24E623A289D for ; Thu, 19 Mar 2020 05:36:13 -0700 (PDT) Received: from [192.168.1.5] (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 02JCaAKt013681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 08:36:11 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_24D45571-3554-4FFC-A033-638B7B187ACB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Mar 2020 08:36:10 -0400 In-Reply-To: Cc: Steve Moore , txauth@ietf.org, Dick Hardt To: David Skaife References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> <30E67E8A-CD0F-40CD-92C5-12D23E6FB1FA@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 12:36:17 -0000 --Apple-Mail=_24D45571-3554-4FFC-A033-638B7B187ACB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think one of the reasons that we=E2=80=99re failing on really nailing = down this discussion is that we don=E2=80=99t have concrete examples or = implementations of what we mean by =E2=80=9Cdiscovery=E2=80=9D. Even in = the XYZ implementations, we aren=E2=80=99t :using: the capabilities = component in a dynamic way.=20 I think what=E2=80=99s going to drive discovery is whatever information = needs to be discovered. I=E2=80=99ve tried to design XYZ such that this = kind of information is minimized, and I believe that=E2=80=99s a = valuable design principle that we should carry in to TxAuth. =E2=80=94 Justin > On Mar 18, 2020, at 6:12 PM, David Skaife = wrote: >=20 > Thanks for explaining further Justin - that makes more sense now. >=20 > I think the confusion was that the topic here is simply "Discovery" = and also the XAuth rationale section in the original email says "Client = can make unauthenticated call to GS URI to learn what GS supports, such = as authentication mechanisms" - which sounds like an example where the = options would potentially be mutually exclusive. So certainly in my mind = I was focusing on the mutually exclusive scenarios, which I now = appreciate isn't what you intended for the XYZ capabilities feature. >=20 > Was a useful discussion, thanks. >=20 > David Skaife >=20 > On Wed, Mar 18, 2020 at 9:24 PM Stephen Moore > wrote: > That makes more sense to me now. Thanks Justin! > I also like that particular solution, rather basically relying on = caching or re-discovery before the transaction begins since, I think, = that allows for more flexible client 'requirements'. > -steve >=20 > On Wed, Mar 18, 2020 at 5:18 PM Justin Richer > wrote: > Speaking with someone on another channel, let me explain it this way. >=20 > This isn=E2=80=99t like =E2=80=9CI will send this to you in JSON or = CBOR, which do you want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can = take a signed ID token=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. So = there isn=E2=80=99t an order or a preference or an exclusivity. If you = can do either of them, or both of them, you just do them. >=20 > Doing the OPTIONS call would let the client fetch from the server all = of that at once, if it wanted too. Allowing it inline lets the client do = all of that without making a second network call or remembering = anything. But it always has the option to do so. >=20 > =E2=80=94 Justin >=20 >> On Mar 18, 2020, at 5:04 PM, Justin Richer > wrote: >>=20 >> I wasn=E2=80=99t showing just the happy path, but I think my example = might have been too simple. Also, I think we've got a different model = for what=E2=80=99s in the capabilities. It=E2=80=99s not about a set of = mutually exclusive options that the client has to choose from. >>=20 >>> Thanks Stephen and Justin for your responses. >>>=20 >>> I certainly accept some of the points you've raised here. One thing = I'd like to add though is that the examples you've provided only show = the happy-path scenario (from a client's perspective) - where the AS = conveniently supports only one of the capabilities provided by the = client. What about if we consider the following scenario: >>>=20 >>> - Client can do A, B, C and D. The AS can do A, B, C, D and E. >>> - The client sends [A, B, C, D]. >>> - Does the AS now send back [A, B, C, D] >>=20 >> Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset = of the client=E2=80=99s capabilities.=20 >>=20 >>> , and then force the client to make a decision (i.e. complexity on = the client)? Or instead, does the AS make a decision itself and then = only send one result back? If the latter, then how would the AS make = this decision, and could this potentially result in an undesirable = outcome from a client's perspective? >>=20 >> The client is already declaring that it can do all of those, and so = it needs to figure out which of those it=E2=80=99s going to use and how = they work together. My intent wasn=E2=80=99t to say that the client = could only do one of those at a time, but rather that these were = different things that the client could support that were optional at the = AS, and the AS is telling the client which bits that it knows about and = can handle. Maybe this is a list of extensions, maybe it=E2=80=99s a = list of optional features, but it=E2=80=99s on top of the =E2=80=9Ccore=E2= =80=9D portions of the protocol.=20 >>=20 >> I=E2=80=99ll also say that this is completely separate from the = discussion on how to handle interaction =E2=80=94 I think the = information patterns on that (which are in a different thread) are much = clearer.=20 >>=20 >>>=20 >>> As you've mentioned, in reality the client would likely "remember" = the capabilities that the AS supports. So if the AS were instead probed = by the client to retrieve the list of its capabilities, this additional = complexity needed on the client side would not be something that is = present in every interaction - as the client would simply need to pass = it's preferred (supported) method on each interaction, rather than = having to keep probing and filtering on each request. Additionally, this = concept of the client remembering what the AS supports would negate the = argument about there being an increase in network traffic raised by = Stephen. >>=20 >> The reality is that most clients aren=E2=80=99t really going to = discover and declare things, especially if the client can start the = whole protocol with just one bit of information. XYZ originally started = with zero discovery, because all of the important parts are revealed = during the protocol.=20 >>=20 >>>=20 >>> I don't think it's as clear-cut as you've presented in your = responses, but I do accept that there are merits to trying to push = complexity to the server. >>>=20 >>=20 >> I agree that it=E2=80=99s not that clear cut yet =E2=80=94 but = that=E2=80=99s largely because there aren=E2=80=99t a lot of concrete = things that would go in this =E2=80=9Cdiscovery=E2=80=9D document yet. = At least with XYZ, we deliberately minimized what the client would need = to know going in, for both simplicity and security. When you make the = core protocol such that you don=E2=80=99t need a lot of extra bits in = order for things to function, then you aren=E2=80=99t creating problems = that you need solutions for. >>=20 >> Thanks for raising the discussion! >>=20 >>>=20 >>> Many thanks, >>> David Skaife >>>=20 >>> On Wed, Mar 18, 2020 at 8:22 PM Justin Richer > wrote: >>> OAuth 2 has taught us that wherever possible, you should push the = complexity to the server, not the client. That=E2=80=99s the idea behind = the kind of publication/negotiation here where the client can do = something simple and the AS needs to make the actual comparison and = decision, whatever that is. Clients need to stay simple because, for the = most part, the focus of the client is on calling whatever API and = implementing whatever functionality it is doing, not on the security = layer. The AS is a dedicated security component, so it=E2=80=99s got the = mandate to figure this stuff out. This mindset is one of OAuth 2=E2=80=99s= biggest strengths.=20 >>>=20 >>> So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99= t really :used: this feature beyond making sure the protocol can be = passed back and forth, since there=E2=80=99s not a lot of optionality = that really needs to be negotiated here. >>>=20 >>> So let=E2=80=99s say the client can do A, B, and C. The AS can do B, = D, and X. If the client doesn=E2=80=99t know anything at all about the = AS, the client sends: >>>=20 >>> [A, B, C] >>>=20 >>> And the server looks at that, compares with what it can do, and = returns: >>>=20 >>> [B] >>>=20 >>> The server doesn=E2=80=99t send D, or X, because the client = wouldn=E2=80=99t have any clue what to do about that. The client can = remember that if it wants to cache that part of the response. >>>=20 >>> So the question is, what if the client knew that only B would be = successful for this server? That=E2=80=99s pretty common because a lot = of clients get written and configured with a static set of capabilities = for a server. And with the negotiation above, the client just needs to = remember after the first call. So in both cases, the client would only = send [B], or leave it off entirely because it doesn=E2=80=99t need to = negotiate, and you=E2=80=99re done.=20 >>>=20 >>> But the thing is, you could do both styles with one simple twist. If = you want to do the discovery portion in a pre-flight request, I think = it=E2=80=99s a good idea to allow OPTIONS on the tx endpoint. It = doesn=E2=80=99t make any sense to me to allow it on any other endpoints, = especially because some of those are going to be user-facing (so the = client is not going to be talking to the URL itself). The client makes = this call and gets back: >>>=20 >>> [B, D, X] >>>=20 >>> And now the client has to put together its possible capabilities = from that list and what it knows it can do. By putting OPTIONS on the = endpoint then we can stick with the same mantra of the client having one = piece of info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80= =94 and learning everything else from that. I think that part is simple = enough to potentially work, and XYZ doesn=E2=80=99t have other endpoints = or aspects that need to be discovered out of band, unlike OAuth 2. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>>=20 >>>> On Mar 18, 2020, at 3:44 PM, David Skaife = > wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> My thoughts on these different approaches are: >>>>=20 >>>> 1. For XYZ, it feels a bit strange and unnecessary to require the = client to have to state it's full set of capabilities to the AS. It = feels like it should be the other way around - i.e. the client is able = to probe what the AS supports. In my view it's more natural for the AS = to be "advertising" its capabilities rather than the client. >>>>=20 >>>> 2. I prefer the XYZ approach of having a single URL that the client = knows it needs to interact to start the transaction, vs the more complex = approach provided by XAuth. >>>>=20 >>>> 3. Hopefully there is a middle ground between the two approaches = that addresses the two points above. >>>>=20 >>>>=20 >>>> Many thanks, >>>> David Skaife >>>>=20 >>>> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt > wrote: >>>> Discovery >>>>=20 >>>> XYZ >>>> - Client always starts at the tx endpoint, all other information = is dispatched from responses from the endpoint >>>> - Clients sends capabilities list in transaction request, AS = selects and returns which capabilities are supported >>>>=20 >>>> XYZ Rationale: client needs a single URL to start talking to an AS, = giving developers multiple ways to get information is confusing and can = lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by = OIDC=E2=80=99s discovery approach) >>>>=20 >>>> XAuth >>>> - Client sends an OPTIONS call to the GS URI, Grant URI, or = Authorization URI >>>>=20 >>>> XAuth Rationale: Client can make unauthenticated call to GS URI to = learn what GS supports, such as authentication mechanisms. Authenticated = calls return what a specific Client can do. >>>>=20 >>>>=20 >>>> =E1=90=A7 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_24D45571-3554-4FFC-A033-638B7B187ACB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think one of the reasons that we=E2=80=99re failing on really nailing = down this discussion is that we don=E2=80=99t have concrete examples or = implementations of what we mean by =E2=80=9Cdiscovery=E2=80=9D. Even in = the XYZ implementations, we aren=E2=80=99t :using: the capabilities = component in a dynamic way. 

I think what=E2=80=99s going to drive discovery is whatever = information needs to be discovered. I=E2=80=99ve tried to design XYZ = such that this kind of information is minimized, and I believe that=E2=80=99= s a valuable design principle that we should carry in to = TxAuth.

 =E2=80=94 Justin

On Mar = 18, 2020, at 6:12 PM, David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:

Thanks for explaining = further Justin - that makes more sense now.

I think the confusion was that the topic here = is simply "Discovery" and also the XAuth rationale section in the = original email says "Client can make unauthenticated call to GS URI to = learn what GS supports, such as authentication = mechanisms" - which sounds like an example where the options would = potentially be mutually exclusive. So certainly in my mind I was = focusing on the mutually exclusive scenarios, which I now = appreciate isn't what you intended for the XYZ capabilities feature.

Was a useful discussion, thanks.

David = Skaife

On Wed, Mar = 18, 2020 at 9:24 PM Stephen Moore <srmoore@gmail.com> wrote:
That = makes more sense to me now. Thanks Justin!
I also like = that particular solution, rather basically relying on caching or = re-discovery before the transaction begins since, I think, that allows = for more flexible client 'requirements'.
-steve

On Wed, Mar = 18, 2020 at 5:18 PM Justin Richer <jricher@mit.edu> wrote:
Speaking with someone = on another channel, let me explain it this way.

This isn=E2=80=99t like =E2=80=9CI will = send this to you in JSON or CBOR, which do you want?=E2=80=9D It=E2=80=99s= more like =E2=80=9CI can take a signed ID token=E2=80=9D and =E2=80=9CI = speak French=E2=80=9D. So there isn=E2=80=99t an order or a preference = or an exclusivity. If you can do either of them, or both of them, you = just do them.

Doing the OPTIONS call would let the client fetch from the = server all of that at once, if it wanted too. Allowing it inline lets = the client do all of that without making a second network call or = remembering anything. But it always has the option to do so.

 =E2=80=94 = Justin

On Mar 18, 2020, at 5:04 PM, = Justin Richer <jricher@mit.edu> wrote:

I wasn=E2=80=99t = showing just the happy path, but I think my example might have been too = simple. Also, I think we've got a different model for what=E2=80=99s in = the capabilities. It=E2=80=99s not about a set of mutually exclusive = options that the client has to choose from.

Thanks Stephen and Justin for your = responses.

I certainly accept some of the points you've raised here. One = thing I'd like to add though is that the examples you've provided only = show the happy-path scenario (from a client's perspective) - where the = AS conveniently supports only one of the capabilities provided by the = client. What about if we consider the following scenario:

- Client can do A, B, C and D. The AS can do = A, B, C, D and E.
- The client sends [A, B, C, D].
- Does the AS now send back [A, B, C, = D]

Yes, the AS sends back [A, B, C, D] because that=E2=80=99s = the subset of the client=E2=80=99s capabilities. 

, and then force the client to make a decision = (i.e. complexity on the client)? Or instead, does the AS make a = decision itself and then only send one result back? If the latter, = then how would the AS make this decision, and could this potentially = result in an undesirable outcome from a client's perspective?

The client is already declaring that it = can do all of those, and so it needs to figure out which of those it=E2=80= =99s going to use and how they work together. My intent wasn=E2=80=99t = to say that the client could only do one of those at a time, but rather = that these were different things that the client could support that were = optional at the AS, and the AS is telling the client which bits that it = knows about and can handle. Maybe this is a list of extensions, maybe = it=E2=80=99s a list of optional features, but it=E2=80=99s on top of the = =E2=80=9Ccore=E2=80=9D portions of the protocol. 

I=E2=80=99ll also say = that this is completely separate from the discussion on how to handle = interaction =E2=80=94 I think the information patterns on that (which = are in a different thread) are much clearer. 


As you've mentioned, in reality = the client would likely "remember" the capabilities that the AS = supports. So if the AS were instead probed by the client to retrieve the = list of its capabilities, this additional complexity needed on the = client side would not be something that is present in every interaction = - as the client would simply need to pass it's preferred (supported) = method on each interaction, rather than having to keep probing and = filtering on each request. Additionally, this concept of the client = remembering what the AS supports would negate the argument about there = being an increase in network traffic raised by Stephen.

The reality is that most clients = aren=E2=80=99t really going to discover and declare things, especially = if the client can start the whole protocol with just one bit of = information. XYZ originally started with zero discovery, because all of = the important parts are revealed during the protocol. 


I don't think it's as clear-cut as = you've presented in your responses, but I do accept that there are = merits to trying to push complexity to the server.


I agree that it=E2=80=99s not that = clear cut yet =E2=80=94 but that=E2=80=99s largely because there = aren=E2=80=99t a lot of concrete things that would go in this = =E2=80=9Cdiscovery=E2=80=9D document yet. At least with XYZ, we = deliberately minimized what the client would need to know going in, for = both simplicity and security. When you make the core protocol such that = you don=E2=80=99t need a lot of extra bits in order for things to = function, then you aren=E2=80=99t creating problems that you need = solutions for.

Thanks for raising the discussion!


Many thanks,
David = Skaife

On Wed, Mar 18, 2020 at 8:22 PM Justin Richer = <jricher@mit.edu> wrote:
OAuth 2 has = taught us that wherever possible, you should push the complexity to the = server, not the client. That=E2=80=99s the idea behind the kind of = publication/negotiation here where the client can do something simple = and the AS needs to make the actual comparison and decision, whatever = that is. Clients need to stay simple because, for the most part, the = focus of the client is on calling whatever API and implementing whatever = functionality it is doing, not on the security layer. The AS is a = dedicated security component, so it=E2=80=99s got the mandate to figure = this stuff out. This mindset is one of OAuth 2=E2=80=99s biggest = strengths. 

So = how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99t = really :used: this feature beyond making sure the protocol can be passed = back and forth, since there=E2=80=99s not a lot of optionality that = really needs to be negotiated here.

So let=E2=80=99s say the client can do = A, B, and C. The AS can do B, D, and X. If the client doesn=E2=80=99t = know anything at all about the AS, the client sends:

[A, B, C]

And the server looks at = that, compares with what it can do, and returns:

[B]

The server doesn=E2=80=99t send D, or = X, because the client wouldn=E2=80=99t have any clue what to do about = that. The client can remember that if it wants to cache that part of the = response.

So = the question is, what if the client knew that only B would be successful = for this server? That=E2=80=99s pretty common because a lot of clients = get written and configured with a static set of capabilities for a = server. And with the negotiation above, the client just needs to = remember after the first call. So in both cases, the client would only = send [B], or leave it off entirely because it doesn=E2=80=99t need to = negotiate, and you=E2=80=99re done. 

But the thing is, you could do both = styles with one simple twist. If you want to do the discovery portion in = a pre-flight request, I think it=E2=80=99s a good idea to allow OPTIONS = on the tx endpoint. It doesn=E2=80=99t make any sense to me to allow it = on any other endpoints, especially because some of those are going to be = user-facing (so the client is not going to be talking to the URL = itself). The client makes this call and gets back:

[B, D, X]

And now the client has = to put together its possible capabilities from that list and what it = knows it can do. By putting OPTIONS on the endpoint then we can stick = with the same mantra of the client having one piece of info to get = started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and learning = everything else from that. I think that part is simple enough to = potentially work, and XYZ doesn=E2=80=99t have other endpoints or = aspects that need to be discovered out of band, unlike OAuth = 2.

 =E2=80=94= Justin



On Mar 18, 2020, at 3:44 PM, David Skaife = <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

My thoughts on these = different approaches are:

1. For XYZ, it = feels a bit strange and unnecessary to require the client to have to = state it's full set of capabilities to the AS. It feels like it should = be the other way around - i.e. the client is able to probe what the AS = supports. In my view it's more natural for the AS to be "advertising" = its capabilities rather than the client.

2. = I prefer the XYZ approach of having a single URL that the client knows = it needs to interact to start the transaction, vs the more complex = approach provided by XAuth.

3. = Hopefully there is a middle ground between the two approaches that = addresses the two points above.


Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery

XYZ
 - Client always starts at the tx endpoint, all other = information is dispatched from responses from the endpoint
 - Clients sends capabilities list in transaction = request, AS selects and returns which capabilities are supported

XYZ Rationale: client needs a single URL to = start talking to an AS, giving developers multiple ways to get = information is confusing and can lead to serious errors (see OAuth2=E2=80=99= s mix-up attack caused by OIDC=E2=80=99s discovery approach)

XAuth
 - Client sends an = OPTIONS call to the GS URI, Grant URI, or Authorization URI

XAuth Rationale: Client can make = unauthenticated call to GS URI to learn what GS supports, such as = authentication mechanisms. Authenticated calls return what a specific = Client can do.


3D""=E1=90=A7
-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

<= br = style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-varia= nt-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;t= ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;tex= t-decoration:none" class=3D"">-- 
Txauth mailing = list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_24D45571-3554-4FFC-A033-638B7B187ACB-- From nobody Thu Mar 19 06:37:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA3D3A29DB for ; Thu, 19 Mar 2020 06:37:44 -0700 (PDT) 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 6r1jojX-_c-k for ; Thu, 19 Mar 2020 06:37:40 -0700 (PDT) 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 DE1B23A29CC for ; Thu, 19 Mar 2020 06:37:39 -0700 (PDT) Received: from [192.168.1.5] (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 02JDbb2r001301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 09:37:37 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Thu, 19 Mar 2020 09:37:36 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 13:37:52 -0000 I see what you=E2=80=99re going for here. I think the key point comes = down to this: > - The client knows what it wants to do and where That=E2=80=99s knowledge is exactly why I would argue that the client = would have to explicitly request multiple access tokens in order to get = them.=20 I=E2=80=99m worried about requiring all clients to be prepared to accept = multiple access tokens. In a lot of big cloud deployments, it=E2=80=99s = absolutely based on location. But that=E2=80=99s not the only dispatch = for security domains. A client would need to know, ultimately, what a = token is for and where to use it. And we=E2=80=99d also need to deal = with cases that allow for subdomains, paths, query parameters, and other = variability of an API=E2=80=99s URLs. After all, I=E2=80=99m probably = going to send that same token to a bunch of different URLs in order to = do a bunch of different things, even if they=E2=80=99re all within the = same =E2=80=9CRS=E2=80=9D or =E2=80=9Cdomain=E2=80=9D or whatever. Which = brings us to an underlying problem =E2=80=94 I don=E2=80=99t think = there=E2=80=99s a good way to reference the identity of an RS. Solid is = attempting to do that using WebID=E2=80=99s as service identifiers, and = while that=E2=80=99s interesting, it=E2=80=99s deeply tied to their = system where everything knows what a WebID is and what to do with it. I = think it=E2=80=99s a bad idea to depend on that kind of thing for a = general purpose system.=20 I=E2=80=99m hesitant to have clients depend on being told that = information. I think if we go down that route we=E2=80=99re going to = have to also tell clients things like =E2=80=9Cthis is only good for GET = requests=E2=80=9D and =E2=80=9Cthis is good for subdomains on this = location=E2=80=9D and =E2=80=9Cthis can be used for anything except this = one exception=E2=80=9D. And it doesn=E2=80=99t fit well when you=E2=80=99r= e trying to mix two different APIs that have really different = structures. Things like GraphQL and REST lead to pretty different URL = designs, and TxAuth should be usable for all of that. It feels like too = much automated configuration of a client instead of the client just = =E2=80=9Cdoing something=E2=80=9D, which I think is going to be the = common case. In other words, I do think that the client software is = going to be bespoke for the API that it=E2=80=99s calling. However, the = security library that speaks the TxAuth piece doesn=E2=80=99t have to = be, and the protocol itself doesn=E2=80=99t need to be. But the = protocols should allow the client software to express to the security = layer what it knows about the API. And speaking of common cases, I think it=E2=80=99s actually much more = rare to have multiple security domains covered by an AS in a way that = would need multiple encryptions or targets. I think many of us see it = because we work with large enterprise-scale systems with multiple = domains that we want to manage all at once. In my experience, it=E2=80=99s= much more common to have a client talk to one AS to get one token for = one RS. One of my goals with this is to not make it complicated for = simple clients, and I think having to be prepared to get multiple access = tokens is too complex for simple clients. I might be wrong, but it=E2=80=99= s based on my experience across a lot of different kinds of APIs. The = idea of splitting up tokens like below feels REALLY complex, especially = when I asked for a single one. I get why you want to do it, it makes = sense for the AS to be able to do something like that, but from a = client=E2=80=99s perspective it=E2=80=99s a lot more complicated without = a clear idea of what the identity of an RS is. I think solving that = problem is a HUGE issue that we should put firmly out of scope. The thing is, though, you=E2=80=99re absolutely right that there=E2=80=99s= a need for this kind of multiple tokens. So in my view, the lift of = having a client know about the domains that it=E2=80=99s calling is a = lot less than the client having to potentially deal with more tokens = than it asked for, and knowing how to correctly dispatch those. Also the = semantics of what the =E2=80=9Cresources=E2=80=9D object represents = changes, since I could potentially be getting two tokens back that do = parts of the one thing that I asked for, and the client now needs to = know which to use for what. If the client has to name the splits itself, = that implies the client knows what each =E2=80=9Cresources=E2=80=9D = sub-object represents and knows how to apply that to its =E2=80=9Ccall = the API=E2=80=9D code. The security layer doesn=E2=80=99t know or care, = but the code that knows how to manipulate the API and its data knows and = cares. As for the token content =E2=80=94 that=E2=80=99s solidly an = implementation decision and orthogonal to this discussion. You can do = all of this multi access token stuff with introspection and = reference-based tokens. Access tokens themselves need to stay opaque to = the client and to the protocol at large. I don=E2=80=99t believe = that=E2=80=99s up for debate. Thanks so much for pushing this conversation, and now I=E2=80=99m more = convinced than ever that handling multiple tokens in the response is = something we need to figure out within this group.=20 =E2=80=94 Justin > On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt = wrote: >=20 > Hi Justin, >=20 > thanks for explaining the different options. I=E2=80=99m well aware of = the super refresh token (and remember the discussions back then in = Taipei :-)), I have implemented systems using this and other patterns, = too. >=20 > The underlying assumption for most of those patterns is that the = client upfront knows the boundaries between RS security domains, which = typically means the solution is bespoken.=20 >=20 > TXAuth is chartered to develop a protocol and not a framework. What = I=E2=80=99m looking for is interoperable protocol support for use of = RS-specific self-contained access tokens in multi-RS deployments. >=20 > Why RS-specific self-contained access tokens?=20 > This is in my experience the most efficient way to empower = high-volume/high-load services in a very efficient, secure, and privacy = preserving fashion.=20 >=20 > - Every token contains exactly the data the RS needs to perform access = control decisions locally. No need for further database lookups or AS = callbacks, that=E2=80=99s really fast and keeps cost of the AS function = low. > - The token itself can be encrypted to protect this data using a = RS-specific key, one could even use HMACs to protect integrity and = authenticity (fast as well).=20 > - The token can have a RS-specific lifetime. > - Since every token is restricted to a single RS audience, those = tokens also have a baseline replay detection built-in.=20 >=20 > I think this pattern makes sense in environments with multiple RSs = (e.g. different products) as well. But since every token is minted to = the specific requirements of a certain RS, the AS must be able to mint = different tokens. That doesn=E2=80=99t work properly without some = support in the protocol. >=20 > Is there a need for multi access tokens support?=20 > Well, you implemented it, I implemented it, and I think a couple of = other implementers did it with OAuth 2 in the past. So there seems to be = some need. Why does the rest use the single token pattern? I think some = deployments will indeed only have a single service, but I bet a lot of = implementers did it because their product does not support anything = else.=20 >=20 > I have experienced this myself when I designed the architecture of the = yes ecosystem. It is a federation of authorization servers with = associated services where every AS represents a certain bank. Since our = partners shall be able to implement their AS using the product they = like, I needed to go with the least common denominator - single access = token. This has a significant consequences: our tokens are basically = handles, so every service calls back to the AS to obtain its data for = every service request. This degrades performance significantly and, = since those tokens are good for multi audiences, it forces us to = generally use sender constrained tokens, which increases complexity for = clients.=20 >=20 > I would like to give implementers more options in the TXAuth space. = That=E2=80=99s why I advocate to build-in support f=C3=BCr multiple = access tokens into TXAuth.=20 >=20 > My proposal is based on the following assumptions: > - Token format, content, encryption keys and so on are defined as part = of the interface between AS and RS > - The client knows what it wants to do and where > - Every party contributes the information it has to the overall = process to make it work simply and effectively for everyone.=20 >=20 > There is no change/addition needed to the request syntax. All it takes = is your new multi token syntax (+ a small addition) in the response.=20 >=20 > The client uses the =E2=80=9Cresources" structure to communicate what = (actions, further elements) it wants to do and where (locations). >=20 > [ > { > =E2=80=9Cactions": ["read", "write"], > "locations": ["https://example.com/resource"], > =E2=80=9Cdata": ["foo", "bar"] > }, > { > =E2=80=9Cactions": ["write"], > "locations": ["https://other_example.com/resource"], > =E2=80=9Cdata": ["foo", "bar"] > } > ] >=20 > One deployment might use a single token for all RSs, in this case the = token response remains unchanged:=20 >=20 > { > "access_token":{ > "value":"08ur4kahfga09u23rnkjasdf", > "type":"bearer" > } > } >=20 > If the AS has the need to issue multiple access tokens, it could, for = example, use the =E2=80=9Clocations" elements to determine what tokens = it needs to create. Such an AS then uses the multiple_access_tokens = structure augmented by corresponding "locations=E2=80=9D entries in the = token response:=20 >=20 > "multiple_access_tokens":{ > "token_a":{ > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type":"bearer", > "locations":[ > "https://example.com/resource" > ] > }, > "token_b":{ > "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > "type":"bearer", > "locations":[ > "https://other_example.com/resource" > ] > } > } >=20 > Since the client passed the locations values in the request, it is = also able to determine where to use what access token.=20 >=20 > I think that=E2=80=99s pretty simple, especially from a client = perspective. =20 >=20 > And If the client wants to split access tokens further apart, e.g. to = obtain tokens with less privileges, it can do so using the request = syntax you defined:=20 >=20 > resources: { > token1: [{ > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/", = "https://resource.local/other"], > datatypes: ["metadata", "images"] > }], > token2: [{ > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/"], > datatypes: ["data", "pictures"] > }] > } >=20 > In the simplest case, the AS would return the data as in your = proposal. >=20 > If the client asks for a partitioning of privileges that goes across = RS security domains like this >=20 > { > "resources":{ > "token1":[ > { > "actions":[ "read", "write","dolphin" ], > "locations":[ = "https://server.example.net/","https://resource.local/other"], > "datatypes":[ "metadata","images"] > }, > { > "actions":["read","write"], > "locations":["https://example.com/resource"] > } > ], > "token2":[ > { > "actions":["foo","bar", "dolphin"], > "locations":["https://resource.other/"], > "datatypes":["data","pictures"] > } > ] > } > } >=20 > the AS would need to further partition the pre-defined tokens like = this: >=20 > "multiple_access_tokens=E2=80=9D:{ > =E2=80=9Ctoken1/a":{ > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type":"bearer", > = "locations":["https://server.example.net/","https://resource.local/other"]= > }, > =E2=80=9Ctoken1/b":{ > "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > "type":"bearer", > "locations":["https://example.com/resource"] > }, > =E2=80=9Ctoken2":{ > "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > "type":"bearer", > "locations":[ > "https://other_example.com/resource" > ] > } > } >=20 > Naming of the tokens is a bit tricky but I think solvable. >=20 > What do you think? >=20 > best regards, > Torsten. >=20 >> On 15. Mar 2020, at 15:26, Justin Richer wrote: >>=20 >> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt = wrote: >>>=20 >>>> On 15. Mar 2020, at 03:25, Justin Richer wrote: >>>>=20 >>>> So if the AS needs a client to get different access tokens to call = different RS domains, it does exactly what we do in OAuth 2 today =E2=80=94= it tells the client to get two different access tokens.=20 >>>=20 >>> How does this work in XYZ? >>>=20 >>=20 >> Without using the multi-access-token thing I=E2=80=99m proposing in = this thread, the client would just make two separate transaction calls = to get two different tokens. There=E2=80=99s a few ways that shakes out = depending on some of the details. In the OAuth world that amounts to = involving the user twice, and it might be the same in XYZ if you=E2=80=99r= e asking for different things: >>=20 >> 1. Client: Start TX-1 (R-1) >> 2. User: Approve R-1 >> 3. AS: Issue AT-1(R-1) >> 4. Client: Start TX-2 (R-1) >> 5. User: approve R-2 >> 6. AS: Issue AT-2(R-2) >>=20 >> Unless you=E2=80=99re getting a super refresh token upfront and then = calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can = do that trick too. >>=20 >> 1. Client: Start TX-1 (R-1, R-2) >> 2. User: Approve R-1, R-2 >> 3. AS: Issue AT1 (R-1, R-2) >> 4. Client: Continue TX-1 (R-2) >> 5. AS: Issue AT-2 (R-2) >>=20 >> But we=E2=80=99ve got another thing we can use in XYZ to help this, = the user handle. This lets a trusted client tell the AS that it believes = the same user is still there and asking the question, so if the access = rights are OK then you don=E2=80=99t need to involve the user again. We = invented this construct with UMA2, where it=E2=80=99s called the = persisted claims token (PCT). >>=20 >> 1. Client: Start TX-1 (R-1) >> 2. User: Approve R-1 >> 3. AS: Issue AT-1 (R-1), user handle U-1 >> 4. Client Start TX-2 (R-2, U-1) >> 5. AS: Issue AT-2 (R-2) >>=20 >> Now: With the multi-token request, we can collapse this all back to a = single transaction with multiple outputs: >>=20 >> 1. Client: Start TX-2 (token1: R-1, token2: R-2) >> 2. User Approve R-1, R-2 >> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) >>=20 >> I haven=E2=80=99t liked any of the multi-access-token solutions to = date because they make things weird for single access token requests. I = like this idea because it=E2=80=99s an optimization for a complex case = that doesn=E2=80=99t change the behavior for the simple case, and in = fact doesn=E2=80=99t even change the expectations for the simple case. = To me, that=E2=80=99s important. >>=20 >> =E2=80=94 Justin >=20 From nobody Thu Mar 19 06:44:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED073A294E for ; Thu, 19 Mar 2020 06:44:07 -0700 (PDT) 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=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 apbsXF2vS_k3 for ; Thu, 19 Mar 2020 06:44:03 -0700 (PDT) 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 E27973A15C2 for ; Thu, 19 Mar 2020 06:44:02 -0700 (PDT) Received: from [192.168.1.5] (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 02JDhpWW003486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 09:43:52 -0400 From: Justin Richer Message-Id: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F0CB642C-C506-434D-9DB6-97892A63B897" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Mar 2020 09:43:51 -0400 In-Reply-To: Cc: Aaron Parecki , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" To: David Skaife References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 13:44:08 -0000 --Apple-Mail=_F0CB642C-C506-434D-9DB6-97892A63B897 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 David, I agree about the potential for exploding the scope to derail us. My = goal for identity within TxAuth=E2=80=99s =E2=80=9Ccore=E2=80=9D = consists of: - A way to ask for a small set of simple, well-defined user claims in = the auth request. So things like =E2=80=9Csubject=E2=80=9D and =E2=80=9Cem= ail address=E2=80=9D and =E2=80=9Cusername=E2=80=9D, for instance. This = should be extensible by a clear registry. (And no, we shouldn=E2=80=99t = reuse the OIDC one as it=E2=80=99s tied to the assumptions of OIDC too = much already.) - A way for the AS to send the client signed assertions. I don=E2=80=99t = actually think we should be defining our own assertion format here in = this group, but we should have slots for things like ID Tokens and SAML = assertions and Verifiable Credentials documents. This set should be = extensible by a registry as well. - A way for the client to present assertions about the user that the AS = can verify, and again we shouldn=E2=80=99t be defining these formats = ourselves, there are plenty to re-use. And =E2=80=A6 that=E2=80=99s pretty much it, at least to get us started. = This is far from =E2=80=9Call of identity=E2=80=9D. With XYZ, you can = already use it out-of-the-box to do these things as well as a handful of = other identity bits =E2=80=94 like for example passing the OIDC scopes = (as resource handles) and getting back an access token that you can use = to call a UserInfo Endpoint. All of that exists already though, and it = maps cleanly because it=E2=80=99s been defined under OAuth 2 and those = concepts map to XYZ. =E2=80=94 Justin > On Mar 18, 2020, at 6:44 PM, David Skaife = wrote: >=20 > Hi, >=20 > As one of the four people who expressed a slight concern about = including identity within the TxAuth charter, I'd like to say that I = would definitely be supportive of the proposal to explicitly state which = elements of identity are included - to narrow the scope. I accept that = removing identity completely doesn't seem to have general support = amongst the group. The root cause of my concern is that, by including = the full scope of identity and the full set of use cases that OpenID = Connect supports today, I envisage that resulting in the WG having such = a broad scope that we would spend years on end thrashing through it and = then no protocol ever actually getting agreed/standardised. >=20 >=20 > Many thanks, > David Skaife >=20 > On Tue, Mar 17, 2020 at 10:47 PM Justin Richer > wrote: > +1 >=20 > Thanks, Aaron. I think it really is a very narrow slice of identity = that we want to cover here, and I=E2=80=99d be happy to get more precise = language into the proposed charter before moving forward.=20 >=20 > =E2=80=94 Justin >=20 > > On Mar 17, 2020, at 6:31 PM, Aaron Parecki > wrote: > >=20 > > Much of the confusion in the marketplace around OAuth and OpenID > > Connect stems from the fact that they are separate specs developed = in > > separate organizations, when really they are two parts to the same > > picture. I am strongly against excluding identity from the charter = of > > TxAuth, as I think this is a unique opportunity to bring the two > > aspects together. > >=20 > > The concern expressed by Kim > > = (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE = = ) > > around OpenID Connect could also be said about OAuth, namely that > > there will be some amount of confusion around the fact that this = spec > > will cover many of the same use cases as OAuth. I think that's fine, > > that's just how we move forward and make progress. > >=20 > > The other concerns seem vague, e.g. "identity is a huge topic". = While > > that may be true, so is authorization, and that alone is not a good > > reason to not do it. > >=20 > > Perhaps the scope of identity included in TxAuth could be narrowed = to > > specify that it's only about communicating identity information, not > > about doing things like identity proofing or identity assurance. = That > > might help address some of the other concerns that have been > > expressed. > >=20 > > ---- > > Aaron Parecki > > aaronparecki.com > > @aaronpk > >=20 > > On Tue, Mar 17, 2020 at 3:06 PM Mike Jones > > > wrote: > >>=20 > >> I believe it's significant that four people have expressed concerns = with including digital identity in the charter (the only concerns voiced = as far as I can tell). At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter. > >>=20 > >> It would be my proposal to initially charter without digital = identity and see how far we get with our energies intentionally focused = in that way. If the working group decides to recharter to include = digital identity, that can always happen later, after the = authorization-focused work has matured, and once there's a clear case to = actually do so. > >>=20 > >> -- Mike > >>=20 > >> -----Original Message----- > >> From: Justin Richer > > >> Sent: Tuesday, March 17, 2020 2:20 PM > >> To: Mike Jones > > >> Cc: Yaron Sheffer >; Torsten Lodderstedt = >; = txauth@ietf.org > >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > >>=20 > >> While I understand the concerns around identity in the charter, and = I had initially not included it, I was convinced that the kind of = identity protocol that we=E2=80=99re looking at here is a minor addition = to the authorization and delegation end of things. > >>=20 > >> As you know, much of what=E2=80=99s in OIDC is there to fix = problems with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 = had solved those problems internally, then OIDC would be much, much = simpler and smaller. We=E2=80=99re now starting at a base where those = problems don=E2=80=99t exist, but we don=E2=80=99t yet know what other = problems there might be. > >>=20 > >> The market has shown us that the most common application of OAuth 2 = is far and away access to identity information along side access to an = API. I think we need to pay attention to that and not make this separate = just because we did it that way before. And some of the proposed = innovations, including getting and sending VC=E2=80=99s, are all about = identity. > >>=20 > >> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. > >>=20 > >> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. > >>=20 > >> =E2=80=94 Justin > >>=20 > >>> On Mar 17, 2020, at 1:12 PM, Mike Jones = > wrote: > >>>=20 > >>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? > >>>=20 > >>> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/ = . > >>>=20 > >>> I'm fine with refactoring the authorization protocol. But = identity should be decoupled from the TxAuth work to focus its scope on = areas where innovation is being proposed. Digital identity can always = be added as a layer if needed, just as OpenID Connect layered identity = onto OAuth 2.0. > >>>=20 > >>> Please revise the charter to remove digital identity from the = scope of the work. > >>>=20 > >>> 2. Are you willing to author or participate in the development of = the drafts of this WG? > >>>=20 > >>> Yes > >>>=20 > >>> 3. Are you willing to help review the drafts of this WG? > >>>=20 > >>> Yes > >>>=20 > >>> 4. Are you interested in implementing drafts of this WG? > >>>=20 > >>> Not at this time. > >>>=20 > >>> -- Mike > >>>=20 > >>> -----Original Message----- > >>> From: Txauth > On Behalf Of Torsten Lodderstedt > >>> Sent: Saturday, March 7, 2020 7:18 AM > >>> To: Yaron Sheffer > > >>> Cc: txauth@ietf.org > >>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG > >>>=20 > >>> Hi, > >>>=20 > >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = >: > >>>>=20 > >>>> =EF=BB=BFHi Everyone, > >>>>=20 > >>>> It appears that momentum is forming around the proposed formation = of a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: > >>>>=20 > >>>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? > >>>=20 > >>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. > >>>=20 > >>> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. > >>>=20 > >>>>=20 > >>>> 2. Are you willing to author or participate in the development = of the drafts of this WG? > >>>=20 > >>> yes > >>>=20 > >>>>=20 > >>>> 3. Are you willing to help review the drafts of this WG? > >>>=20 > >>> yes > >>>=20 > >>>>=20 > >>>> 4. Are you interested in implementing drafts of this WG? > >>>=20 > >>> yes > >>>=20 > >>> best regards, > >>> Torsten. > >>>=20 > >>>>=20 > >>>> The call will run for two weeks, until March 21. If you think = that the charter should be amended In a significant way, please reply on = a separate thread. > >>>>=20 > >>>> The feedback provided here will help the IESG come to a decision = on the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. > >>>>=20 > >>>> Thanks, > >>>> Yaron and Dick > >>>>=20 > >>>> --- Charter Text Follows --- > >>>>=20 > >>>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. > >>>>=20 > >>>> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. > >>>>=20 > >>>> Additionally, the delegation process will allow for: > >>>>=20 > >>>> - Fine-grained specification of access > >>>> - Approval of AS attestation to identity claims > >>>> - Approval of access to multiple resources and APIs in a single = interaction > >>>> - Separation between the party authorizing access and the party = operating the client requesting access > >>>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications > >>>>=20 > >>>> The group will define extension points for this protocol to allow = for flexibility in areas including: > >>>>=20 > >>>> - Cryptographic agility for keys, message signatures, and proof = of possession > >>>> - User interaction mechanisms including web and non-web methods > >>>> - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions > >>>> - Mechanisms for presenting tokens to resource servers and = binding resource requests to tokens and associated cryptographic keys > >>>> - Optimized inclusion of additional information through the = delegation process (including identity) > >>>>=20 > >>>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: > >>>>=20 > >>>> - Discovery of the authorization server > >>>> - Revocation of active tokens > >>>> - Query of token rights by resource servers > >>>>=20 > >>>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. > >>>>=20 > >>>> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. > >>>>=20 > >>>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. > >>>>=20 > >>>> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. > >>>>=20 > >>>> Milestones to include: > >>>> - Core delegation protocol > >>>> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures > >>>> - Identity and authentication conveyance mechanisms > >>>> - Guidelines for use of protocol extension points > >>>>=20 > >>>>=20 > >>>> -- > >>>> Txauth mailing list > >>>> Txauth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/txauth = > >>> -- > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth = > >>=20 > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_F0CB642C-C506-434D-9DB6-97892A63B897 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 David,

I = agree about the potential for exploding the scope to derail us. My goal = for identity within TxAuth=E2=80=99s =E2=80=9Ccore=E2=80=9D consists = of:

 - A = way to ask for a small set of simple, well-defined user claims in the = auth request. So things like =E2=80=9Csubject=E2=80=9D and =E2=80=9Cemail = address=E2=80=9D and =E2=80=9Cusername=E2=80=9D, for instance. This = should be extensible by a clear registry. (And no, we shouldn=E2=80=99t = reuse the OIDC one as it=E2=80=99s tied to the assumptions of OIDC too = much already.)
 - A way for the AS to send the = client signed assertions. I don=E2=80=99t actually think we should be = defining our own assertion format here in this group, but we should have = slots for things like ID Tokens and SAML assertions and Verifiable = Credentials documents. This set should be extensible by a registry as = well.
 - A way for the client to present = assertions about the user that the AS can verify, and again we = shouldn=E2=80=99t be defining these formats ourselves, there are plenty = to re-use.

And = =E2=80=A6 that=E2=80=99s pretty much it, at least to get us started. = This is far from =E2=80=9Call of identity=E2=80=9D. With XYZ, you can = already use it out-of-the-box to do these things as well as a handful of = other identity bits =E2=80=94 like for example passing the OIDC scopes = (as resource handles) and getting back an access token that you can use = to call a UserInfo Endpoint. All of that exists already though, and it = maps cleanly because it=E2=80=99s been defined under OAuth 2 and those = concepts map to XYZ.

 =E2=80=94 Justin

On Mar = 18, 2020, at 6:44 PM, David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

As one of the four people who = expressed a slight concern about including identity within the TxAuth = charter, I'd like to say that I would definitely be supportive of the = proposal to explicitly state which elements of identity are included - = to narrow the scope. I accept that removing identity completely doesn't = seem to have general support amongst the group. The root cause of my = concern is that, by including the full scope of identity and the full = set of use cases that OpenID Connect supports today, I envisage that = resulting in the WG having such a broad scope that we would spend years = on end thrashing through it and then no protocol ever actually getting = agreed/standardised.


Many thanks,
David = Skaife

On Tue, Mar 17, 2020 at 10:47 PM Justin = Richer <jricher@mit.edu> wrote:
+1

Thanks, Aaron. I think it really is a very narrow slice of identity that = we want to cover here, and I=E2=80=99d be happy to get more precise = language into the proposed charter before moving forward.

 =E2=80=94 Justin

> On Mar 17, 2020, at 6:31 PM, Aaron Parecki <aaron@parecki.com> wrote:
>
> Much of the confusion in the marketplace around OAuth and OpenID
> Connect stems from the fact that they are separate specs developed = in
> separate organizations, when really they are two parts to the = same
> picture. I am strongly against excluding identity from the charter = of
> TxAuth, as I think this is a unique opportunity to bring the two
> aspects together.
>
> The concern expressed by Kim
> (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXS= nshX2CahE)
> around OpenID Connect could also be said about OAuth, namely = that
> there will be some amount of confusion around the fact that this = spec
> will cover many of the same use cases as OAuth. I think that's = fine,
> that's just how we move forward and make progress.
>
> The other concerns seem vague, e.g. "identity is a huge topic". = While
> that may be true, so is authorization, and that alone is not a = good
> reason to not do it.
>
> Perhaps the scope of identity included in TxAuth could be narrowed = to
> specify that it's only about communicating identity information, = not
> about doing things like identity proofing or identity assurance. = That
> might help address some of the other concerns that have been
> expressed.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
> On Tue, Mar 17, 2020 at 3:06 PM Mike Jones
> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:
>>
>> I believe it's significant that four people have expressed = concerns with including digital identity in the charter (the only = concerns voiced as far as I can tell).  At a minimum, I believe = that that warrants making the inclusion or exclusion of digital identity = a discussion topic during the upcoming virtual BoF, before adopting any = charter.
>>
>> It would be my proposal to initially charter without digital = identity and see how far we get with our energies intentionally focused = in that way.  If the working group decides to recharter to include = digital identity, that can always happen later, after the = authorization-focused work has matured, and once there's a clear case to = actually do so.
>>
>>                  =               -- Mike
>>
>> -----Original Message-----
>> From: Justin Richer <jricher@mit.edu>
>> Sent: Tuesday, March 17, 2020 2:20 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten = Lodderstedt <torsten@lodderstedt.net>; txauth@ietf.org
>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
>>
>> While I understand the concerns around identity in the charter, = and I had initially not included it, I was convinced that the kind of = identity protocol that we=E2=80=99re looking at here is a minor addition = to the authorization and delegation end of things.
>>
>> As you know, much of what=E2=80=99s in OIDC is there to fix = problems with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 = had solved those problems internally, then OIDC would be much, much = simpler and smaller. We=E2=80=99re now starting at a base where those = problems don=E2=80=99t exist, but we don=E2=80=99t yet know what other = problems there might be.
>>
>> The market has shown us that the most common application of = OAuth 2 is far and away access to identity information along side access = to an API. I think we need to pay attention to that and not make this = separate just because we did it that way before. And some of the = proposed innovations, including getting and sending VC=E2=80=99s, are = all about identity.
>>
>> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere.
>>
>> If there is better language to tighten the aspects of an = identity protocol that we will explicitly cover, then I would welcome = you to suggest an amended text to the charter. However, I believe there = is enough interest within the community to work on identity in the = context of this protocol, including a large number of people being OK = with it in the charter, that it would not be a reasonable thing to = remove it.
>>
>> =E2=80=94 Justin
>>
>>> On Mar 17, 2020, at 1:12 PM, Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:
>>>
>>> 1.  Do you support the charter text provided at the = end of this email?  Or do you have major objections, blocking = concerns or feedback (if so please elaborate)?
>>>
>>> I share the concerns about including identity in the = charter that were expressed by Torsten and agreed with by David = Skaife.  I'll note that Kim Cameron previously expressed concerns = about including identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXS= nshX2CahE/.
>>>
>>> I'm fine with refactoring the authorization protocol.  = But identity should be decoupled from the TxAuth work to focus its scope = on areas where innovation is being proposed.  Digital identity can = always be added as a layer if needed, just as OpenID Connect layered = identity onto OAuth 2.0.
>>>
>>> Please revise the charter to remove digital identity from = the scope of the work.
>>>
>>> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>>>
>>> Yes
>>>
>>> 3.  Are you willing to help review the drafts of this = WG?
>>>
>>> Yes
>>>
>>> 4.  Are you interested in implementing drafts of this = WG?
>>>
>>> Not at this time.
>>>
>>>                =               -- Mike
>>>
>>> -----Original Message-----
>>> From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Torsten Lodderstedt
>>> Sent: Saturday, March 7, 2020 7:18 AM
>>> To: Yaron Sheffer <yaronf.ietf@gmail.com>
>>> Cc: txauth@ietf.org
>>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus = - TxAuth WG
>>>
>>> Hi,
>>>
>>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>>>
>>>> =EF=BB=BFHi Everyone,
>>>>
>>>> It appears that momentum is forming around the proposed = formation of a TxAuth working group.  We=E2=80=99d like to more = formally gauge interest in proceeding with this work.  Please do so = by responding to the following questions:
>>>>
>>>> 1.  Do you support the charter text provided at = the end of this email?  Or do you have major objections, blocking = concerns or feedback (if so please elaborate)?
>>>
>>> I=E2=80=98m in although I have to admit I=E2=80=98m = slightly concerned the scope of the charter is too broad, e.g. identify = alone is a huge topic.
>>>
>>> We need to keep an eye on this aspect in order to make = sure, the group is able to work effectively and the specs we will be = producing are as simple as possible and foster interoperability.
>>>
>>>>
>>>> 2.  Are you willing to author or participate in = the development of the drafts of this WG?
>>>
>>> yes
>>>
>>>>
>>>> 3.  Are you willing to help review the drafts of = this WG?
>>>
>>> yes
>>>
>>>>
>>>> 4.  Are you interested in implementing drafts of = this WG?
>>>
>>> yes
>>>
>>> best regards,
>>> Torsten.
>>>
>>>>
>>>> The call will run for two weeks, until March 21. If you = think that the charter should be amended In a significant way, please = reply on a separate thread.
>>>>
>>>> The feedback provided here will help the IESG come to a = decision on the formation of a new WG. Given the constraints of the = chartering process, regardless of the outcome of this consensus call, we = will be meeting in Vancouver as a BoF.
>>>>
>>>> Thanks,
>>>> Yaron and Dick
>>>>
>>>> --- Charter Text Follows ---
>>>>
>>>> This group is chartered to develop a fine-grained = delegation protocol for authorization, identity, and API access. This = protocol will allow an authorizing party to delegate access to client = software through an authorization server. It will expand upon the uses = cases currently supported by OAuth 2.0 and OpenID Connect (itself an = extension of OAuth 2.0) to support authorizations scoped as narrowly as = a single transaction, provide a clear framework for interaction among = all parties involved in the protocol flow, and remove unnecessary = dependence on a browser or user-agent for coordinating interactions.
>>>>
>>>> The delegation process will be acted upon by multiple = parties in the protocol, each performing a specific role. The protocol = will decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.
>>>>
>>>> Additionally, the delegation process will allow for:
>>>>
>>>> - Fine-grained specification of access
>>>> - Approval of AS attestation to identity claims
>>>> - Approval of access to multiple resources and APIs in = a single interaction
>>>> - Separation between the party authorizing access and = the party operating the client requesting access
>>>> - A variety of client applications, including Web, = mobile, single-page, and interaction-constrained applications
>>>>
>>>> The group will define extension points for this = protocol to allow for flexibility in areas including:
>>>>
>>>> - Cryptographic agility for keys, message signatures, = and proof of possession
>>>> - User interaction mechanisms including web and non-web = methods
>>>> - Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
>>>> - Mechanisms for presenting tokens to resource servers = and binding resource requests to tokens and associated cryptographic = keys
>>>> - Optimized inclusion of additional information through = the delegation process (including identity)
>>>>
>>>> Additionally, the group will provide mechanisms for = management of the protocol lifecycle including:
>>>>
>>>> - Discovery of the authorization server
>>>> - Revocation of active tokens
>>>> - Query of token rights by resource servers
>>>>
>>>> Although the artifacts for this work are not intended = or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.
>>>>
>>>> This group is not chartered to develop extensions to = OAuth 2.0, and as such will focus on new technological solutions not = necessarily compatible with OAuth 2.0. Functionality that builds = directly on OAuth 2.0 will be developed in the OAuth Working Group, = including functionality back-ported from the protocol developed here to = OAuth 2.0.
>>>>
>>>> The group is chartered to develop mechanisms for = applying cryptographic methods, such as JOSE and COSE, to the delegation = process. This group is not chartered to develop new cryptographic = methods.
>>>>
>>>> The initial work will focus on using HTTP for = communication between the client and the authorization server, taking = advantage of optimization features of HTTP2 and HTTP3 where possible, = and will strive to enable simple mapping to other protocols such as COAP = when doing so does not conflict with the primary focus.
>>>>
>>>> Milestones to include:
>>>> - Core delegation protocol
>>>> - Key presentation mechanism bindings to the core = protocol for TLS, detached HTTP signature, and embedded HTTP = signatures
>>>> - Identity and authentication conveyance mechanisms
>>>> - Guidelines for use of protocol extension points
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
= >>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
= >>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_F0CB642C-C506-434D-9DB6-97892A63B897-- From nobody Thu Mar 19 08:03:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7933A0043 for ; Thu, 19 Mar 2020 08:02:59 -0700 (PDT) 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 zc9oTtyK2H4L for ; Thu, 19 Mar 2020 08:02:56 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 65DE43A0033 for ; Thu, 19 Mar 2020 08:02:56 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id c187so2802343wme.1 for ; Thu, 19 Mar 2020 08:02:56 -0700 (PDT) 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=WoVv7W7aOAZhDlCz5ZTQiQGjUclUATJcvr3NxDRD1kM=; b=Ppjkxe3qa9VqcOFxGDHlI5JIEDpNsi9ffQFYgrzTE/jQdkhFbZS/P6zDGHzCU6s2VL OMgNrAJNVbe/1IsmYmjXjfRuZ8Y86tqacCqU4nHsDr//XUStKK39FG+yaw5wosmxoMML PDpHegoyqkBpped4v02O2/EupmgZTLizZfEMgictQdTGGbe4gchah1XpSm2zXoHmSKLn C/zeXYzXCDoCYUXxG6mzzg013fC7D2LQxRRxPrIKMp2LZZ738WnMfz3Qs5vQXGVsqemt kHCD/u7ihxiGDaWtnUajOyB235ke1/GFMBzhCw1CWbxhjk//7NUEhmO4vYr76huP3/G5 0Ljw== 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=WoVv7W7aOAZhDlCz5ZTQiQGjUclUATJcvr3NxDRD1kM=; b=VQZtznVTlYsTlOoRihofVQqklsNMNENTkhfv2eXAH1ne/L8tiKTkoiEDZmCsT0ryJo 1MX7VM5C3eBNe42X4oxHcscc2SB4itxia4595J66WbvSJe3UjCh16S+hhTqE6YuTrJcX Ll7GOEUxDN4SnoPG0SrAUfcQYuKj5ks1ZX0ou9O5hflg2dgv+Odz8HodwBQGWp4K0TQg 0IHGsQunBeZJ2GNI8FsKZYIb1QrTpzDXO05zq5JzNJMECCqSFHyDUTk9+1X4yLi1xhcB xiKzMKL14+wqZ20viYwNFQn5GVK7d9UFNXSbEPKZxPidjnQlsNYrSwhdEAENzSGoihmw hu7g== X-Gm-Message-State: ANhLgQ0RqVXYW1oyjxTXNaxxLh956yM0erJQrG2nX9pGqvG+x+QxHx80 ogj5inbJ/EoEOl+8KNtIOheZvw== X-Google-Smtp-Source: ADFU+vskcQEPVw8cQzynIkZWBn2kt7O0u5Pc1EJqTGjFhp9TXpzi2hgdlyd6TFcJ0A1tdqSp5YkQHg== X-Received: by 2002:a1c:5402:: with SMTP id i2mr4224607wmb.169.1584630174565; Thu, 19 Mar 2020 08:02:54 -0700 (PDT) Received: from p200300eb8f2625b4c1842dc11ab64701.dip0.t-ipconnect.de (p200300EB8F2625B4C1842DC11AB64701.dip0.t-ipconnect.de. [2003:eb:8f26:25b4:c184:2dc1:1ab6:4701]) by smtp.gmail.com with ESMTPSA id u25sm3480885wml.17.2020.03.19.08.02.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2020 08:02:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> Date: Thu, 19 Mar 2020 16:02:52 +0100 Cc: David Skaife , Aaron Parecki , Yaron Sheffer , Mike Jones , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 15:03:00 -0000 Hi, > On 19. Mar 2020, at 14:43, Justin Richer wrote: >=20 > David, >=20 > I agree about the potential for exploding the scope to derail us. My = goal for identity within TxAuth=E2=80=99s =E2=80=9Ccore=E2=80=9D = consists of: >=20 > - A way to ask for a small set of simple, well-defined user claims in = the auth request. So things like =E2=80=9Csubject=E2=80=9D and =E2=80=9Cem= ail address=E2=80=9D and =E2=80=9Cusername=E2=80=9D, for instance. This = should be extensible by a clear registry. (And no, we shouldn=E2=80=99t = reuse the OIDC one as it=E2=80=99s tied to the assumptions of OIDC too = much already.) I don=E2=80=99t see a need to define concrete claims in the TXAuth = context. I don=E2=80=99t even see a need to define a mechanism to attest = identity claims as part of TXAuth as this can easily be done in an = extension.=20 We should stay focused at the problem at hand, authorisation and = delegation is hard enough to solve properly and in an interoperable = manner. I would rather spend the time to bring API authorization to a = new level, e.g. by truly supporting audience restricted/RS-specific = access tokens and the ability to automatically test conformance with the = protocol.=20 I also see a conceptual issue with incorporating identity attestation = between AS and RS in TXAuth: I bet implementers will expose identity = data to clients even in cases where there is no real need, just because = it is there and part of the protocol. I think data minimisation and = privacy by design works differently. =46rom the security perspective, = one should consider the trust models for authorization and identity = attestation are different. In the first case, it is the AS protecting = the user and the RSs from bad actors. In identity, the AS(IDP) protects = the client(RP) from bad users. Mixing those two will make the security = threat analysis even harder. I see identity topics though, namely the way identity data are being = conveyed between AS and RS. This is no man's land today but a key aspect = for vendor support and interop between ASs and RSs.=20 > - A way for the AS to send the client signed assertions. I don=E2=80=99= t actually think we should be defining our own assertion format here in = this group, but we should have slots for things like ID Tokens and SAML = assertions and Verifiable Credentials documents. This set should be = extensible by a registry as well. Why does this need to be in scope for TXAuth? I totally get the need for = supporting this between AS and RS. > - A way for the client to present assertions about the user that the = AS can verify, and again we shouldn=E2=80=99t be defining these formats = ourselves, there are plenty to re-use. That=E2=80=99s a use case I would support since it would allow the = client to bootstrap a conversation with the AS using identity data = attested somewhere else or in another transaction.=20 >=20 > And =E2=80=A6 that=E2=80=99s pretty much it, at least to get us = started. This is far from =E2=80=9Call of identity=E2=80=9D. With XYZ, = you can already use it out-of-the-box to do these things as well as a = handful of other identity bits =E2=80=94 like for example passing the = OIDC scopes (as resource handles) and getting back an access token that = you can use to call a UserInfo Endpoint. All of that exists already = though, and it maps cleanly because it=E2=80=99s been defined under = OAuth 2 and those concepts map to XYZ. best regards, Torsten.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 18, 2020, at 6:44 PM, David Skaife = wrote: >>=20 >> Hi, >>=20 >> As one of the four people who expressed a slight concern about = including identity within the TxAuth charter, I'd like to say that I = would definitely be supportive of the proposal to explicitly state which = elements of identity are included - to narrow the scope. I accept that = removing identity completely doesn't seem to have general support = amongst the group. The root cause of my concern is that, by including = the full scope of identity and the full set of use cases that OpenID = Connect supports today, I envisage that resulting in the WG having such = a broad scope that we would spend years on end thrashing through it and = then no protocol ever actually getting agreed/standardised. >>=20 >>=20 >> Many thanks, >> David Skaife >>=20 >> On Tue, Mar 17, 2020 at 10:47 PM Justin Richer = wrote: >> +1 >>=20 >> Thanks, Aaron. I think it really is a very narrow slice of identity = that we want to cover here, and I=E2=80=99d be happy to get more precise = language into the proposed charter before moving forward.=20 >>=20 >> =E2=80=94 Justin >>=20 >> > On Mar 17, 2020, at 6:31 PM, Aaron Parecki = wrote: >> >=20 >> > Much of the confusion in the marketplace around OAuth and OpenID >> > Connect stems from the fact that they are separate specs developed = in >> > separate organizations, when really they are two parts to the same >> > picture. I am strongly against excluding identity from the charter = of >> > TxAuth, as I think this is a unique opportunity to bring the two >> > aspects together. >> >=20 >> > The concern expressed by Kim >> > = (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)= >> > around OpenID Connect could also be said about OAuth, namely that >> > there will be some amount of confusion around the fact that this = spec >> > will cover many of the same use cases as OAuth. I think that's = fine, >> > that's just how we move forward and make progress. >> >=20 >> > The other concerns seem vague, e.g. "identity is a huge topic". = While >> > that may be true, so is authorization, and that alone is not a good >> > reason to not do it. >> >=20 >> > Perhaps the scope of identity included in TxAuth could be narrowed = to >> > specify that it's only about communicating identity information, = not >> > about doing things like identity proofing or identity assurance. = That >> > might help address some of the other concerns that have been >> > expressed. >> >=20 >> > ---- >> > Aaron Parecki >> > aaronparecki.com >> > @aaronpk >> >=20 >> > On Tue, Mar 17, 2020 at 3:06 PM Mike Jones >> > wrote: >> >>=20 >> >> I believe it's significant that four people have expressed = concerns with including digital identity in the charter (the only = concerns voiced as far as I can tell). At a minimum, I believe that = that warrants making the inclusion or exclusion of digital identity a = discussion topic during the upcoming virtual BoF, before adopting any = charter. >> >>=20 >> >> It would be my proposal to initially charter without digital = identity and see how far we get with our energies intentionally focused = in that way. If the working group decides to recharter to include = digital identity, that can always happen later, after the = authorization-focused work has matured, and once there's a clear case to = actually do so. >> >>=20 >> >> -- Mike >> >>=20 >> >> -----Original Message----- >> >> From: Justin Richer >> >> Sent: Tuesday, March 17, 2020 2:20 PM >> >> To: Mike Jones >> >> Cc: Yaron Sheffer ; Torsten Lodderstedt = ; txauth@ietf.org >> >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >> >>=20 >> >> While I understand the concerns around identity in the charter, = and I had initially not included it, I was convinced that the kind of = identity protocol that we=E2=80=99re looking at here is a minor addition = to the authorization and delegation end of things. >> >>=20 >> >> As you know, much of what=E2=80=99s in OIDC is there to fix = problems with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 = had solved those problems internally, then OIDC would be much, much = simpler and smaller. We=E2=80=99re now starting at a base where those = problems don=E2=80=99t exist, but we don=E2=80=99t yet know what other = problems there might be. >> >>=20 >> >> The market has shown us that the most common application of OAuth = 2 is far and away access to identity information along side access to an = API. I think we need to pay attention to that and not make this separate = just because we did it that way before. And some of the proposed = innovations, including getting and sending VC=E2=80=99s, are all about = identity. >> >>=20 >> >> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >> >>=20 >> >> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >> >>=20 >> >> =E2=80=94 Justin >> >>=20 >> >>> On Mar 17, 2020, at 1:12 PM, Mike Jones = wrote: >> >>>=20 >> >>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >> >>>=20 >> >>> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.= >> >>>=20 >> >>> I'm fine with refactoring the authorization protocol. But = identity should be decoupled from the TxAuth work to focus its scope on = areas where innovation is being proposed. Digital identity can always = be added as a layer if needed, just as OpenID Connect layered identity = onto OAuth 2.0. >> >>>=20 >> >>> Please revise the charter to remove digital identity from the = scope of the work. >> >>>=20 >> >>> 2. Are you willing to author or participate in the development = of the drafts of this WG? >> >>>=20 >> >>> Yes >> >>>=20 >> >>> 3. Are you willing to help review the drafts of this WG? >> >>>=20 >> >>> Yes >> >>>=20 >> >>> 4. Are you interested in implementing drafts of this WG? >> >>>=20 >> >>> Not at this time. >> >>>=20 >> >>> -- Mike >> >>>=20 >> >>> -----Original Message----- >> >>> From: Txauth On Behalf Of Torsten = Lodderstedt >> >>> Sent: Saturday, March 7, 2020 7:18 AM >> >>> To: Yaron Sheffer >> >>> Cc: txauth@ietf.org >> >>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG >> >>>=20 >> >>> Hi, >> >>>=20 >> >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = : >> >>>>=20 >> >>>> =EF=BB=BFHi Everyone, >> >>>>=20 >> >>>> It appears that momentum is forming around the proposed = formation of a TxAuth working group. We=E2=80=99d like to more formally = gauge interest in proceeding with this work. Please do so by responding = to the following questions: >> >>>>=20 >> >>>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >> >>>=20 >> >>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. >> >>>=20 >> >>> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. >> >>>=20 >> >>>>=20 >> >>>> 2. Are you willing to author or participate in the development = of the drafts of this WG? >> >>>=20 >> >>> yes >> >>>=20 >> >>>>=20 >> >>>> 3. Are you willing to help review the drafts of this WG? >> >>>=20 >> >>> yes >> >>>=20 >> >>>>=20 >> >>>> 4. Are you interested in implementing drafts of this WG? >> >>>=20 >> >>> yes >> >>>=20 >> >>> best regards, >> >>> Torsten. >> >>>=20 >> >>>>=20 >> >>>> The call will run for two weeks, until March 21. If you think = that the charter should be amended In a significant way, please reply on = a separate thread. >> >>>>=20 >> >>>> The feedback provided here will help the IESG come to a decision = on the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. >> >>>>=20 >> >>>> Thanks, >> >>>> Yaron and Dick >> >>>>=20 >> >>>> --- Charter Text Follows --- >> >>>>=20 >> >>>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. >> >>>>=20 >> >>>> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >> >>>>=20 >> >>>> Additionally, the delegation process will allow for: >> >>>>=20 >> >>>> - Fine-grained specification of access >> >>>> - Approval of AS attestation to identity claims >> >>>> - Approval of access to multiple resources and APIs in a single = interaction >> >>>> - Separation between the party authorizing access and the party = operating the client requesting access >> >>>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >> >>>>=20 >> >>>> The group will define extension points for this protocol to = allow for flexibility in areas including: >> >>>>=20 >> >>>> - Cryptographic agility for keys, message signatures, and proof = of possession >> >>>> - User interaction mechanisms including web and non-web methods >> >>>> - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions >> >>>> - Mechanisms for presenting tokens to resource servers and = binding resource requests to tokens and associated cryptographic keys >> >>>> - Optimized inclusion of additional information through the = delegation process (including identity) >> >>>>=20 >> >>>> Additionally, the group will provide mechanisms for management = of the protocol lifecycle including: >> >>>>=20 >> >>>> - Discovery of the authorization server >> >>>> - Revocation of active tokens >> >>>> - Query of token rights by resource servers >> >>>>=20 >> >>>> Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible. >> >>>>=20 >> >>>> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >> >>>>=20 >> >>>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >> >>>>=20 >> >>>> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >> >>>>=20 >> >>>> Milestones to include: >> >>>> - Core delegation protocol >> >>>> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures >> >>>> - Identity and authentication conveyance mechanisms >> >>>> - Guidelines for use of protocol extension points >> >>>>=20 >> >>>>=20 >> >>>> -- >> >>>> Txauth mailing list >> >>>> Txauth@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/txauth >> >>> -- >> >>> Txauth mailing list >> >>> Txauth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/txauth >> >>=20 >> >> -- >> >> Txauth mailing list >> >> Txauth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 From nobody Thu Mar 19 08:28:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677603A0766 for ; Thu, 19 Mar 2020 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 oGJGu6XFRyy9 for ; Thu, 19 Mar 2020 08:28:26 -0700 (PDT) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (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 EA4F43A0764 for ; Thu, 19 Mar 2020 08:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1584631706; x=1616167706; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=QczYyvCjzrTIYB/922FZcRp6N3mE2eSy8aNuy+kr8R4=; b=L2VZekuWMdsS8TU/lOs7JvPHMU/3gt88EfnUrCMzbWmfetLBCjiJw3Ox utsjIw/jHo8xzVsTv5jJUZVDikRpLWRx7cCPQeURhP1FK+7vZhinIeQrd 6tcmQgT/G/TSEgwgAzelgxNsurAAwK6RgLmFC98yGppFDeMBkOvcnNx1z w=; IronPort-SDR: CYLo3EC9C58ME2C3eMSvrdHiR3fndQ8Q62SOiRM35jblJx85kAaCqGAyewKb4Ew6SjlifulSve CKG9uFdZyL1w== X-IronPort-AV: E=Sophos; i="5.70,572,1574121600"; d="scan'208,217"; a="32149536" Thread-Topic: [Txauth] TxAuth BoF draft agenda Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 19 Mar 2020 15:28:24 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-4e7c8266.us-west-2.amazon.com (Postfix) with ESMTPS id DB6C7A1BC8; Thu, 19 Mar 2020 15:28:23 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 19 Mar 2020 15:28:23 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Mar 2020 15:28:23 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Thu, 19 Mar 2020 15:28:23 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , "txauth@ietf.org" CC: Yaron Sheffer Thread-Index: AQHV++egOmBjVJ/UJ0G9o0gxziMpAqhPmOWA Date: Thu, 19 Mar 2020 15:28:23 +0000 Message-ID: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.150] Content-Type: multipart/alternative; boundary="_000_563D324D8F5F4747AA8EF5C78AF0C81Damazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 15:28:28 -0000 --_000_563D324D8F5F4747AA8EF5C78AF0C81Damazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBleHBlY3QgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBhcm91bmQgd2hldGhlci90byB3aGF0IGV4dGVu dCBpdCBzaG91bGQgaW5jbHVkZSDigJxpZGVudGl0eeKAnSBhbmQgd2l0aG91dCBzb21lIHN0cnVj dHVyZSB0aGF0IGNvdWxkIGVhc2lseSBjb25zdW1lIHRoZSB3aG9sZSBtZWV0aW5nLiBTaG91bGQg d2UgdGltZWJveCB0aGF0IGRpc2N1c3Npb24sIGFuZC9vciBnZXQgc29tZSB2b2x1bnRlZXJzIHRv IHN1bW1hcml6ZSB0aGUgdmFyaW91cyBwb3NpdGlvbnM/DQoNCuKAkw0KQW5uYWJlbGxlIEJhY2tt YW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRp dHkvDQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBNYXJj aCAxNiwgMjAyMCBhdCA0OjA3IFBNDQpUbzogInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBpZXRm Lm9yZz4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0 OiBbRVhURVJOQUxdW1R4YXV0aF0gVHhBdXRoIEJvRiBkcmFmdCBhZ2VuZGENCg0KDQpDQVVUSU9O OiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24u IERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgY2FuIGNv bmZpcm0gdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQoNClZpcnR1 YWwgTWVldGluZzoNCg0KTW9uZGF5LCBNYXJjaCAyMw0KMjA6MDAgLSAyMjowMCBVVEMgKg0KDQpB Z2VuZGENCkNoYWlyIHNsaWRlcywgYWdlbmRhIGJhc2hpbmcgLSAxMCBtaW4uDQpDaGFydGVyIChs aW5rLCBzb2xpY2l0IGNvbW1lbnRzLCBkaXNjdXNzIFdHIG5hbWUpIC0gMjAgbWluLg0KWFlaIC0g SnVzdGluICh3aXRoIFEmQSkgLSAyMCBtaW4uDQpYQXV0aCAtIERpY2sgICh3aXRoIFEmQSkgLSAy MCBtaW4uDQpZYXJvbiAsIERpY2ssIEp1c3RpbiAtIERpc2N1c3Npb24gb2YgZGlmZmVyZW5jZXMg YmV0d2VlbiBwcm90b2NvbHMgLSA0MCBtaW4uDQpOZXh0IHN0ZXBzIC0gMTAgbWluLg0KDQpBZGRp dGlvbnMgLyBzdWdnZXN0aW9ucz8NCg0KVGVjaA0KVGhlIHRlY2hub2xvZ3kgdG8gYmUgdXNlZCBp cyBzdGlsbCBUQkQuIFdlIHdpbGwgdXBkYXRlIHRoZSBsaXN0IHdoZW4gd2Uga25vdy4gV2UgYXJl IGV4cGVjdGluZyBpdCB3aWxsIGJlIHRoZSBJRVRGIFdlYkV4LiAobXkgcHJlZmVyZW5jZSB3b3Vs ZCBiZSBab29tIGlmIGFueW9uZSBoYXMgYW4gYWNjb3VudCB0byBoYXZlIExPVFMgb2YgcGVvcGxl IG9uIGl0ID0pDQoNCldlIGFyZSBwbGFubmluZyBvbiB1c2luZyBFdGhlclBhZCBmb3Igbm90ZXMs IGFuZCBmb3IgcXVldWUgbWFuYWdlbWVudC4NCg0KU2NyaWJlDQpXb3VsZCBzb21lb25lIGxpa2Ug dG8gdm9sdW50ZWVyIHRvIGJlIHRoZSBzY3JpYmUgb24gRXRoZXJQYWQ/IFdlIHdvdWxkIGxpa2Ug dG8gZ2V0IGFzIG11Y2ggY29vcmRpbmF0aW9uIGRvbmUgcHJpb3IgYXMgcG9zc2libGUgdG8gbWFr ZSB0aGUgYmVzdCB1c2Ugb2YgdGhlIHRpbWUuDQoNCi9EaWNrDQoNCiogU29tZSB0aW1lIG1hdGgg Zm9yIDIwOjAwIC0gMjI6MDAgVVRDOg0KDQpQYWNpZmljIFRpbWUgICAgICAgICAgICAgICAgICAg MTM6MDAtMTU6MDANCkVhc3Rlcm4gVGltZSAgICAgICAgICAgICAgIDE2OjAwLTE4OjAwDQpDb29y ZGluYXRlZCBVbml2ZXJzYWwgVGltZSAgICAgICAgMjA6MDAtMDI6MDANCkNlbnRyYWwgRXVyb3Bl YW4gVGltZSAgICAgICAgICAyMTowMC0yMzowMA0KSW5kaWEgU3RhbmRhcmQgVGltZSAgICAgICAg ICAgIDAxOjMwLTAzOjMwDQpDaGluYSBTdGFuZGFyZCBUaW1lICAgICAgICAgIDA0OjAwLTA2OjAw DQpBdXN0cmFsaWFuIEVhc3Rlcm4gU3RhbmRhcmQgVGltZSAgICAgICAwNzowMC0wOTowMA0KW2h0 dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJX RnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD03N2ExMGIwNy00NjYyLTQzYTQtOWNj ZC04ZGZhZDljM2I5ODdd4ZCnDQo= --_000_563D324D8F5F4747AA8EF5C78AF0C81Damazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <33F6FFF4712DD247B6AE143CE5D221F8@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkdhZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIg NCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYz QzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGV4cGVjdCBhIGxvdCBvZiBkaXNjdXNzaW9uIGFyb3VuZCB3aGV0aGVy L3RvIHdoYXQgZXh0ZW50IGl0IHNob3VsZCBpbmNsdWRlIOKAnGlkZW50aXR54oCdIGFuZCB3aXRo b3V0IHNvbWUgc3RydWN0dXJlIHRoYXQgY291bGQgZWFzaWx5IGNvbnN1bWUgdGhlIHdob2xlIG1l ZXRpbmcuIFNob3VsZCB3ZSB0aW1lYm94IHRoYXQgZGlzY3Vzc2lvbiwgYW5kL29yIGdldCBzb21l IHZvbHVudGVlcnMgdG8gc3VtbWFyaXplIHRoZQ0KIHZhcmlvdXMgcG9zaXRpb25zPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKA kzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8v YXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+aHR0 cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToN Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlR4 YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhh cmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5 LCBNYXJjaCAxNiwgMjAyMCBhdCA0OjA3IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDt0eGF1dGhA aWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPllh cm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+W0VYVEVSTkFMXVtUeGF1dGhdIFR4QXV0aCBCb0YgZHJhZnQgYWdlbmRhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIg Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI2MjIiIHN0eWxlPSJ3aWR0aDo0NjYuNXB0O21hcmdpbi1s ZWZ0Oi41aW47Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0i aGVpZ2h0OjE1LjI1cHQiPg0KPHRkIHdpZHRoPSI2MjIiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lk dGg6NDY2LjVwdDtib3JkZXI6c29saWQgI0VEN0QzMSAxLjVwdDtwYWRkaW5nOjBpbiA1LjRwdCAw aW4gNS40cHQ7aGVpZ2h0OjE1LjI1cHQiPg0KPHA+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO2JhY2tncm91 bmQ6I0ZGRkY5OSI+Q0FVVElPTjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2s7YmFja2dyb3VuZDojRkZGRjk5Ij46IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNp ZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNo bWVudHMgdW5sZXNzDQogeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNv bnRlbnQgaXMgc2FmZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJv ZHk+DQo8L3RhYmxlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5WaXJ0dWFsIE1lZXRpbmc6Jm5i c3A7IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Nb25kYXksIE1hcmNo IDIzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MjA6MDAgLSAyMjowMCBVVEMgKiA8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+QWdlbmRhPC9iPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5DaGFp ciBzbGlkZXMsIGFnZW5kYSBiYXNoaW5nIC0gMTAgbWluLjxicj4NCkNoYXJ0ZXIgKGxpbmssIHNv bGljaXQgY29tbWVudHMsIGRpc2N1c3MgV0cgbmFtZSkgLSAyMCBtaW4uPGJyPg0KWFlaIC0gSnVz dGluICh3aXRoIFEmYW1wO0EpIC0gMjAgbWluLjxicj4NClhBdXRoIC0gRGljayZuYnNwOyAod2l0 aCBRJmFtcDtBKSAtIDIwIG1pbi48YnI+DQpZYXJvbiAsIERpY2ssIEp1c3RpbiAtIERpc2N1c3Np b24gb2YgZGlmZmVyZW5jZXMgYmV0d2VlbiBwcm90b2NvbHMgLSA0MCBtaW4uPGJyPg0KTmV4dCBz dGVwcyAtIDEwIG1pbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWRkaXRpb25zIC8gc3VnZ2VzdGlvbnM/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+VGVjaDwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5UaGUgdGVjaG5vbG9neSB0byBiZSB1c2VkIGlzIHN0aWxsIFRCRC4gV2Ugd2ls bCB1cGRhdGUgdGhlIGxpc3Qgd2hlbiB3ZSBrbm93LiBXZSBhcmUgZXhwZWN0aW5nIGl0IHdpbGwg YmUgdGhlIElFVEYgV2ViRXguIChteSBwcmVmZXJlbmNlIHdvdWxkIGJlIFpvb20gaWYgYW55b25l IGhhcyBhbiBhY2NvdW50IHRvIGhhdmUgTE9UUyBvZiBwZW9wbGUgb24gaXQgPSk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5XZSBhcmUgcGxhbm5pbmcgb24g dXNpbmcgRXRoZXJQYWQgZm9yIG5vdGVzLCBhbmQgZm9yIHF1ZXVlIG1hbmFnZW1lbnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+U2NyaWJlPC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPldvdWxkIHNvbWVvbmUgbGlrZSB0byB2b2x1bnRlZXIgdG8gYmUg dGhlIHNjcmliZSBvbiBFdGhlclBhZD8gV2Ugd291bGQgbGlrZSB0byBnZXQgYXMgbXVjaCBjb29y ZGluYXRpb24gZG9uZSBwcmlvciBhcyBwb3NzaWJsZSB0byBtYWtlIHRoZSBiZXN0IHVzZSBvZiB0 aGUgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4v RGljazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiogU29t ZSB0aW1lIG1hdGggZm9yIDIwOjAwIC0gMjI6MDAgVVRDOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlBhY2lmaWMgVGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEzOjAwLTE1 OjAwPGJyPg0KRWFzdGVybiBUaW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzE2OjAwLTE4OjAwPGJyPg0KQ29vcmRpbmF0ZWQgVW5pdmVyc2Fs IFRpbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjA6MDAtMDI6MDA8YnI+DQpDZW50cmFs IEV1cm9wZWFuIFRpbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIxOjAwLTIz OjAwPGJyPg0KSW5kaWEgU3RhbmRhcmQgVGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDAxOjMwLTAzOjMwPGJyPg0KQ2hpbmEgU3RhbmRhcmQgVGltZSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMDQ6MDAtMDY6MDA8YnI+DQpBdXN0cmFsaWFuIEVh c3Rlcm4gU3RhbmRhcmQgVGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzA3OjAwLTA5OjAw PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAwMF9p MTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGph eTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD03 N2ExMGIwNy00NjYyLTQzYTQtOWNjZC04ZGZhZDljM2I5ODciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_563D324D8F5F4747AA8EF5C78AF0C81Damazoncom_-- From nobody Thu Mar 19 09:30:31 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9234E3A08DD for ; Thu, 19 Mar 2020 09:30:29 -0700 (PDT) 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=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 QuVF62g7XyZC for ; Thu, 19 Mar 2020 09:30:27 -0700 (PDT) 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 535323A08DB for ; Thu, 19 Mar 2020 09:30:27 -0700 (PDT) Received: from [192.168.1.5] (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 02JGULOE002293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 12:30:22 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> Date: Thu, 19 Mar 2020 12:30:21 -0400 Cc: David Skaife , Aaron Parecki , Yaron Sheffer , Mike Jones , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 16:30:30 -0000 It looks like we=E2=80=99re on different sides of this entirely =E2=80=94 = I don=E2=80=99t see communication about identity between the AS and RS = as in scope at all. I do see communication about the identity between AS = and Client (RP) as in scope. You are absolutely correct that they solve = very different problems and protect different parts of the ecosystem.=20 I also agree that they can, and likely should, be layered on top of each = other. You should be able to do the authorization delegation piece = without touching identity at all, for sure. But the fact remains that = most developers today see OAuth 2 through the OIDC lens. Most people = think that OAuth2 is an identity protocol because that=E2=80=99s how = they use it. We need to pay attention to that landscape, and to me that = says pretty clearly that we should be paying attention to identity from = the start. It=E2=80=99s going to be one of the first applications that = people want this for, and we=E2=80=99d be doing the world a disservice = to dismiss it entirely. I think it=E2=80=99s a red herring saying that we=E2=80=99ll never = finish a core protocol if we have identity topics in scope. Saying = it=E2=80=99s in scope for the group does not mean that we solve the = problem in a single document or at the same time as the core. It=E2=80=99s= up to the chairs to direct the group to split documents, to prioritize = efforts, and to work on things in a reasonable fashion.=20 If I got to pick on my own today, I=E2=80=99d split things up like: - TxAuth delegation protocol, includes tx calls, interaction (redirect, = callback, user code, poll/wait), resources (single and multiple), = handles - TxAuth identity protocol, includes sending claims to AS, requesting = claims from AS, receiving claims from AS, receiving assertions from AS, = probably session management and other stuff - TxAuth token lifecycle management, includes introspection, = revocation, token-level refresh And probably extensions for things like additional key proofing = mechanisms (like self-contained JOSE objects), additional interaction = mechanisms (didcomm queries, CHAPI, etc), and maybe discovery belongs in = its own spec, maybe it=E2=80=99s in the core, I don=E2=80=99t know. I might not have drawn the lines between these documents right, and = those lines might shift over time. Working on UMA2, I learned that = sometimes you need to recombine and refactor your specifications in = order for them to make sense in the world. Both UMA1 and UMA2 have two = documents, but what=E2=80=99s considered =E2=80=9Ccore=E2=80=9D and = what=E2=80=99s considered the =E2=80=9Cextension=E2=80=9D are pretty = different in both. I would not be surprised if we go through those kinds = of exercises here. This is work that=E2=80=99s going to take a long time, and it=E2=80=99s = not all going to be done at the same time. But pushing a topic out of = scope just because we might not do it immediately is, I think, doing = this group and this problem space a disservice.=20 =E2=80=94 Justin > On Mar 19, 2020, at 11:02 AM, Torsten Lodderstedt = wrote: >=20 > Hi, >=20 >> On 19. Mar 2020, at 14:43, Justin Richer wrote: >>=20 >> David, >>=20 >> I agree about the potential for exploding the scope to derail us. My = goal for identity within TxAuth=E2=80=99s =E2=80=9Ccore=E2=80=9D = consists of: >>=20 >> - A way to ask for a small set of simple, well-defined user claims in = the auth request. So things like =E2=80=9Csubject=E2=80=9D and =E2=80=9Cem= ail address=E2=80=9D and =E2=80=9Cusername=E2=80=9D, for instance. This = should be extensible by a clear registry. (And no, we shouldn=E2=80=99t = reuse the OIDC one as it=E2=80=99s tied to the assumptions of OIDC too = much already.) >=20 > I don=E2=80=99t see a need to define concrete claims in the TXAuth = context. I don=E2=80=99t even see a need to define a mechanism to attest = identity claims as part of TXAuth as this can easily be done in an = extension.=20 >=20 > We should stay focused at the problem at hand, authorisation and = delegation is hard enough to solve properly and in an interoperable = manner. I would rather spend the time to bring API authorization to a = new level, e.g. by truly supporting audience restricted/RS-specific = access tokens and the ability to automatically test conformance with the = protocol.=20 >=20 > I also see a conceptual issue with incorporating identity attestation = between AS and RS in TXAuth: I bet implementers will expose identity = data to clients even in cases where there is no real need, just because = it is there and part of the protocol. I think data minimisation and = privacy by design works differently. =46rom the security perspective, = one should consider the trust models for authorization and identity = attestation are different. In the first case, it is the AS protecting = the user and the RSs from bad actors. In identity, the AS(IDP) protects = the client(RP) from bad users. Mixing those two will make the security = threat analysis even harder. >=20 > I see identity topics though, namely the way identity data are being = conveyed between AS and RS. This is no man's land today but a key aspect = for vendor support and interop between ASs and RSs.=20 >=20 >> - A way for the AS to send the client signed assertions. I don=E2=80=99= t actually think we should be defining our own assertion format here in = this group, but we should have slots for things like ID Tokens and SAML = assertions and Verifiable Credentials documents. This set should be = extensible by a registry as well. >=20 > Why does this need to be in scope for TXAuth? I totally get the need = for supporting this between AS and RS. >=20 >> - A way for the client to present assertions about the user that the = AS can verify, and again we shouldn=E2=80=99t be defining these formats = ourselves, there are plenty to re-use. >=20 > That=E2=80=99s a use case I would support since it would allow the = client to bootstrap a conversation with the AS using identity data = attested somewhere else or in another transaction.=20 >=20 >>=20 >> And =E2=80=A6 that=E2=80=99s pretty much it, at least to get us = started. This is far from =E2=80=9Call of identity=E2=80=9D. With XYZ, = you can already use it out-of-the-box to do these things as well as a = handful of other identity bits =E2=80=94 like for example passing the = OIDC scopes (as resource handles) and getting back an access token that = you can use to call a UserInfo Endpoint. All of that exists already = though, and it maps cleanly because it=E2=80=99s been defined under = OAuth 2 and those concepts map to XYZ. >=20 > best regards, > Torsten.=20 >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 18, 2020, at 6:44 PM, David Skaife = wrote: >>>=20 >>> Hi, >>>=20 >>> As one of the four people who expressed a slight concern about = including identity within the TxAuth charter, I'd like to say that I = would definitely be supportive of the proposal to explicitly state which = elements of identity are included - to narrow the scope. I accept that = removing identity completely doesn't seem to have general support = amongst the group. The root cause of my concern is that, by including = the full scope of identity and the full set of use cases that OpenID = Connect supports today, I envisage that resulting in the WG having such = a broad scope that we would spend years on end thrashing through it and = then no protocol ever actually getting agreed/standardised. >>>=20 >>>=20 >>> Many thanks, >>> David Skaife >>>=20 >>> On Tue, Mar 17, 2020 at 10:47 PM Justin Richer = wrote: >>> +1 >>>=20 >>> Thanks, Aaron. I think it really is a very narrow slice of identity = that we want to cover here, and I=E2=80=99d be happy to get more precise = language into the proposed charter before moving forward.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 17, 2020, at 6:31 PM, Aaron Parecki = wrote: >>>>=20 >>>> Much of the confusion in the marketplace around OAuth and OpenID >>>> Connect stems from the fact that they are separate specs developed = in >>>> separate organizations, when really they are two parts to the same >>>> picture. I am strongly against excluding identity from the charter = of >>>> TxAuth, as I think this is a unique opportunity to bring the two >>>> aspects together. >>>>=20 >>>> The concern expressed by Kim >>>> = (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)= >>>> around OpenID Connect could also be said about OAuth, namely that >>>> there will be some amount of confusion around the fact that this = spec >>>> will cover many of the same use cases as OAuth. I think that's = fine, >>>> that's just how we move forward and make progress. >>>>=20 >>>> The other concerns seem vague, e.g. "identity is a huge topic". = While >>>> that may be true, so is authorization, and that alone is not a good >>>> reason to not do it. >>>>=20 >>>> Perhaps the scope of identity included in TxAuth could be narrowed = to >>>> specify that it's only about communicating identity information, = not >>>> about doing things like identity proofing or identity assurance. = That >>>> might help address some of the other concerns that have been >>>> expressed. >>>>=20 >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>>=20 >>>> On Tue, Mar 17, 2020 at 3:06 PM Mike Jones >>>> wrote: >>>>>=20 >>>>> I believe it's significant that four people have expressed = concerns with including digital identity in the charter (the only = concerns voiced as far as I can tell). At a minimum, I believe that = that warrants making the inclusion or exclusion of digital identity a = discussion topic during the upcoming virtual BoF, before adopting any = charter. >>>>>=20 >>>>> It would be my proposal to initially charter without digital = identity and see how far we get with our energies intentionally focused = in that way. If the working group decides to recharter to include = digital identity, that can always happen later, after the = authorization-focused work has matured, and once there's a clear case to = actually do so. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: Justin Richer >>>>> Sent: Tuesday, March 17, 2020 2:20 PM >>>>> To: Mike Jones >>>>> Cc: Yaron Sheffer ; Torsten Lodderstedt = ; txauth@ietf.org >>>>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >>>>>=20 >>>>> While I understand the concerns around identity in the charter, = and I had initially not included it, I was convinced that the kind of = identity protocol that we=E2=80=99re looking at here is a minor addition = to the authorization and delegation end of things. >>>>>=20 >>>>> As you know, much of what=E2=80=99s in OIDC is there to fix = problems with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 = had solved those problems internally, then OIDC would be much, much = simpler and smaller. We=E2=80=99re now starting at a base where those = problems don=E2=80=99t exist, but we don=E2=80=99t yet know what other = problems there might be. >>>>>=20 >>>>> The market has shown us that the most common application of OAuth = 2 is far and away access to identity information along side access to an = API. I think we need to pay attention to that and not make this separate = just because we did it that way before. And some of the proposed = innovations, including getting and sending VC=E2=80=99s, are all about = identity. >>>>>=20 >>>>> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >>>>>=20 >>>>> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Mar 17, 2020, at 1:12 PM, Mike Jones = wrote: >>>>>>=20 >>>>>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >>>>>>=20 >>>>>> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.= >>>>>>=20 >>>>>> I'm fine with refactoring the authorization protocol. But = identity should be decoupled from the TxAuth work to focus its scope on = areas where innovation is being proposed. Digital identity can always = be added as a layer if needed, just as OpenID Connect layered identity = onto OAuth 2.0. >>>>>>=20 >>>>>> Please revise the charter to remove digital identity from the = scope of the work. >>>>>>=20 >>>>>> 2. Are you willing to author or participate in the development = of the drafts of this WG? >>>>>>=20 >>>>>> Yes >>>>>>=20 >>>>>> 3. Are you willing to help review the drafts of this WG? >>>>>>=20 >>>>>> Yes >>>>>>=20 >>>>>> 4. Are you interested in implementing drafts of this WG? >>>>>>=20 >>>>>> Not at this time. >>>>>>=20 >>>>>> -- Mike >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Txauth On Behalf Of Torsten = Lodderstedt >>>>>> Sent: Saturday, March 7, 2020 7:18 AM >>>>>> To: Yaron Sheffer >>>>>> Cc: txauth@ietf.org >>>>>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = : >>>>>>>=20 >>>>>>> =EF=BB=BFHi Everyone, >>>>>>>=20 >>>>>>> It appears that momentum is forming around the proposed = formation of a TxAuth working group. We=E2=80=99d like to more formally = gauge interest in proceeding with this work. Please do so by responding = to the following questions: >>>>>>>=20 >>>>>>> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >>>>>>=20 >>>>>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. >>>>>>=20 >>>>>> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. >>>>>>=20 >>>>>>>=20 >>>>>>> 2. Are you willing to author or participate in the development = of the drafts of this WG? >>>>>>=20 >>>>>> yes >>>>>>=20 >>>>>>>=20 >>>>>>> 3. Are you willing to help review the drafts of this WG? >>>>>>=20 >>>>>> yes >>>>>>=20 >>>>>>>=20 >>>>>>> 4. Are you interested in implementing drafts of this WG? >>>>>>=20 >>>>>> yes >>>>>>=20 >>>>>> best regards, >>>>>> Torsten. >>>>>>=20 >>>>>>>=20 >>>>>>> The call will run for two weeks, until March 21. If you think = that the charter should be amended In a significant way, please reply on = a separate thread. >>>>>>>=20 >>>>>>> The feedback provided here will help the IESG come to a decision = on the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Yaron and Dick >>>>>>>=20 >>>>>>> --- Charter Text Follows --- >>>>>>>=20 >>>>>>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. >>>>>>>=20 >>>>>>> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >>>>>>>=20 >>>>>>> Additionally, the delegation process will allow for: >>>>>>>=20 >>>>>>> - Fine-grained specification of access >>>>>>> - Approval of AS attestation to identity claims >>>>>>> - Approval of access to multiple resources and APIs in a single = interaction >>>>>>> - Separation between the party authorizing access and the party = operating the client requesting access >>>>>>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>>>>>>=20 >>>>>>> The group will define extension points for this protocol to = allow for flexibility in areas including: >>>>>>>=20 >>>>>>> - Cryptographic agility for keys, message signatures, and proof = of possession >>>>>>> - User interaction mechanisms including web and non-web methods >>>>>>> - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions >>>>>>> - Mechanisms for presenting tokens to resource servers and = binding resource requests to tokens and associated cryptographic keys >>>>>>> - Optimized inclusion of additional information through the = delegation process (including identity) >>>>>>>=20 >>>>>>> Additionally, the group will provide mechanisms for management = of the protocol lifecycle including: >>>>>>>=20 >>>>>>> - Discovery of the authorization server >>>>>>> - Revocation of active tokens >>>>>>> - Query of token rights by resource servers >>>>>>>=20 >>>>>>> Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible. >>>>>>>=20 >>>>>>> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >>>>>>>=20 >>>>>>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >>>>>>>=20 >>>>>>> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >>>>>>>=20 >>>>>>> Milestones to include: >>>>>>> - Core delegation protocol >>>>>>> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures >>>>>>> - Identity and authentication conveyance mechanisms >>>>>>> - Guidelines for use of protocol extension points >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>=20 >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >=20 From nobody Thu Mar 19 09:33:25 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88613A092E for ; Thu, 19 Mar 2020 09:33:14 -0700 (PDT) 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 IBY-Sp1PfLYI for ; Thu, 19 Mar 2020 09:33:13 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 092F23A0909 for ; Thu, 19 Mar 2020 09:33:12 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id o12so3361388wrh.11 for ; Thu, 19 Mar 2020 09:33:12 -0700 (PDT) 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=wR/CTszjuMFv0tqWFi7VLS8uzZXSldm8fsUIzgD/6aU=; b=gtM/YNTyesBykJrf3hRscJYwkYqwIFa0k32qOh92JOjGaf+wJ5Ohc6/SzrC1KneTwC aTnfptDmJlTA0YeRNI0CF0zTUW6o6nR3wCnPI3n4Rm6ydiOL9f7IVhZQ2cICBqrWGCBg vvl8bSpNn+t8xobEzYzYXW1ofdvu5QuDbHuUHzVW/tiXJ5WR8Nk4MgoO0PmKYmhIWTLk B4K6WnQS+zw1+kcojRYpE0iyvrQlJvbK/jeKd/hFsD/rolBX10bw6TcmfX9HAja7GHKT pdbBGA2RCzeONPPJgLkwFWjZAWm0nt4NtbfGYU9AZ4ASVQOWzeiNA/lkNOxt7YuWJZtv NzUA== 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=wR/CTszjuMFv0tqWFi7VLS8uzZXSldm8fsUIzgD/6aU=; b=mQ1P/Rv62QdwknRk1dH/2WtlTQ1LdqAf/QdOXbvzSEsjDq+6E47e8JSVLO/CnAa+kn lpV29WeyzBW6bzHlOhyDpciRgEleW4aRxAmFD+dbj3Oxha6ZutZNbt1rVU7h75e8f/0E upotmRegVeaIZP0b5wPjnz1DO4S4JixvQPUQD573h1jh8G36u+zJyjw1sZvxbbNK7b0o VjTQDthijCiDnt45p/cd9SzqM7QlPoPjjZEUYkAqJ9dAHznZQm1jWDFl15U9f3kcd7Dh /Bg0KdoNGWH2yI4gAAPCwplNOS/hi2gnJgU+6faUocIlIEUa4ithxMXfKFh2HMvgXzjv Jauw== X-Gm-Message-State: ANhLgQ0bWACD+G7xX+z4X3y8O6/JhNAU4sWdsQeAFqxmk/BGDghnVGj7 X9Na5EhuZfiZGaWBkq9LHilaMA== X-Google-Smtp-Source: ADFU+vsmsjL8gFZhRRWBo9KaRKYDJbvIzmIqxm9S6/LG+189uT0PJJBQwTSUGU+fjwol3+sRwCkkQQ== X-Received: by 2002:adf:9796:: with SMTP id s22mr5141455wrb.31.1584635591257; Thu, 19 Mar 2020 09:33:11 -0700 (PDT) Received: from p200300eb8f2625b4c1842dc11ab64701.dip0.t-ipconnect.de (p200300EB8F2625B4C1842DC11AB64701.dip0.t-ipconnect.de. [2003:eb:8f26:25b4:c184:2dc1:1ab6:4701]) by smtp.gmail.com with ESMTPSA id t126sm4060832wmb.27.2020.03.19.09.33.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2020 09:33:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> Date: Thu, 19 Mar 2020 17:33:09 +0100 Cc: David Skaife , Aaron Parecki , Yaron Sheffer , Mike Jones , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 16:33:24 -0000 Hi Justin, > On 19. Mar 2020, at 17:30, Justin Richer wrote: >=20 > It looks like we=E2=80=99re on different sides of this entirely =E2=80=94= I don=E2=80=99t see communication about identity between the AS and RS = as in scope at all.=20 I described why I see it in scope. May I ask you to state why you = don=E2=80=99t agree? best regards, Torsten.=20 From nobody Thu Mar 19 09:47:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190CE3A090C for ; Thu, 19 Mar 2020 09:47:13 -0700 (PDT) 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=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 CkrFqxGKwzbV for ; Thu, 19 Mar 2020 09:47:12 -0700 (PDT) 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 C48253A0906 for ; Thu, 19 Mar 2020 09:47:11 -0700 (PDT) Received: from [192.168.1.5] (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 02JGl6Oe008921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 12:47:07 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> Date: Thu, 19 Mar 2020 12:47:06 -0400 Cc: David Skaife , Aaron Parecki , Yaron Sheffer , Mike Jones , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 16:47:14 -0000 On Mar 19, 2020, at 12:33 PM, Torsten Lodderstedt = wrote: >=20 > Hi Justin, >=20 >> On 19. Mar 2020, at 17:30, Justin Richer wrote: >>=20 >> It looks like we=E2=80=99re on different sides of this entirely =E2=80=94= I don=E2=80=99t see communication about identity between the AS and RS = as in scope at all.=20 >=20 > I described why I see it in scope. May I ask you to state why you = don=E2=80=99t agree? Well, it=E2=80=99s in scope as much as describing any other aspect of = what the token is for and what it represents is in scope. That is = alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 But here=E2=80=99s the thing: none of that has an impact on the core = protocol. That is entirely up to the AS and the RS to agree on, and the = client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. This does raise the question of what our bar of interoperability is = going to be with TxAuth: do we expect independent AS and RS = implementations to talk to each other? That=E2=80=99s not something = OAuth 2 was ever concerned with, though obviously JWT and introspection = are both from the OAuth2 WG and solve that problem. =E2=80=94 Justin= From nobody Thu Mar 19 10:11:48 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CFD3A09C5 for ; Thu, 19 Mar 2020 10:11:46 -0700 (PDT) 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=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 dfHw8d1vOelA for ; Thu, 19 Mar 2020 10:11:44 -0700 (PDT) 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 4835D3A09C6 for ; Thu, 19 Mar 2020 10:11:44 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id h9so4054874wrc.8 for ; Thu, 19 Mar 2020 10:11:43 -0700 (PDT) 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=yM0navR+To/yIo6Kf60qVqFol9j+c8waECS3ZitRLjM=; b=UYOmifalvT+RkndCQOkG+0NSS20RWIaNc69MY1Z0IsLXzBJQZDTQKpQKiZxwXnWrYq tegmfZuGfZYZuFljQ25l8RfuPVP9HJdMigU2Rd75mMvdcraQai/X6AFSAWxowZKGdrv6 vuGyKzotvC23PEHK/BtEZmmRbZPowiR8oyCOeqJKJv8cx649IKfjvOnn+jaYfAPlVg9G AFKthwvRm2nytVI5f5ggYqPbPIMH7igsF9JmU6giZCwR6ygIVIl9LKpGSvk1vcv5tyW6 81E+nNhPhC9OSEMY3OfQuWoAF9nN/VIicS7OLKhdYNGqLUDS55aQupXuK6mTXd6uk6x2 DflQ== 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=yM0navR+To/yIo6Kf60qVqFol9j+c8waECS3ZitRLjM=; b=PztrOJz+StGOVEwj7IHmNY8mPHG2Ti2/4WHyEeppbQthuXggSXT/O0dsmD9QM3Tr56 rKPCdkvyiWQdbpBFmMyJwX27hb2CklfBeNA29L+ZEzATeVVy2HeYhXXTFk2I0SSumZsa //U7ywI8LgHvgVrencnk86ZmhK4dFd9gpeasWua2bmUM1QdbusP0qMA9lfvHdl1x3Vp9 PyTWcADo+82bsQX3N7nXfpBiKfDcZxupORmDjDL+W1RUue48PCVGD0n+XT4o4yjYj2d0 Wn8T+KJF4I0Zoqo7JgtfNaBTOi+2kH9qkd3TRGALzmt/uAcTMaykWaQ8qQsHw/FSpZVT fkAA== X-Gm-Message-State: ANhLgQ3pZq8jVpxhzU1IgKFWPIldWKJsnwwDlbapZRIfcPi9PKplleAB wXzivZiavQf8C0eBCHhA/vnWpQ== X-Google-Smtp-Source: ADFU+vvxkPd8R09hGV0QkzDif8bt+48XG9ZQQGAilM35hBgclDhLmZJ2Cd5lFEJk/S+XmKbzDMJI5g== X-Received: by 2002:adf:a313:: with SMTP id c19mr5377632wrb.411.1584637902360; Thu, 19 Mar 2020 10:11:42 -0700 (PDT) Received: from p200300eb8f2625b4c1842dc11ab64701.dip0.t-ipconnect.de (p200300EB8F2625B4C1842DC11AB64701.dip0.t-ipconnect.de. [2003:eb:8f26:25b4:c184:2dc1:1ab6:4701]) by smtp.gmail.com with ESMTPSA id h81sm4444437wme.42.2020.03.19.10.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2020 10:11:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Thu, 19 Mar 2020 18:11:37 +0100 Cc: David Skaife , Aaron Parecki , Yaron Sheffer , Mike Jones , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 17:11:47 -0000 > On 19. Mar 2020, at 17:47, Justin Richer wrote: >=20 > On Mar 19, 2020, at 12:33 PM, Torsten Lodderstedt = wrote: >>=20 >> Hi Justin, >>=20 >>> On 19. Mar 2020, at 17:30, Justin Richer wrote: >>>=20 >>> It looks like we=E2=80=99re on different sides of this entirely =E2=80= =94 I don=E2=80=99t see communication about identity between the AS and = RS as in scope at all.=20 >>=20 >> I described why I see it in scope. May I ask you to state why you = don=E2=80=99t agree? >=20 > Well, it=E2=80=99s in scope as much as describing any other aspect of = what the token is for and what it represents is in scope. That is = alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >=20 > But here=E2=80=99s the thing: none of that has an impact on the core = protocol. That is entirely up to the AS and the RS to agree on, and the = client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. >=20 > This does raise the question of what our bar of interoperability is = going to be with TxAuth: do we expect independent AS and RS = implementations to talk to each other? That=E2=80=99s not something = OAuth 2 was ever concerned with, though obviously JWT and introspection = are both from the OAuth2 WG and solve that problem. There are two aspects to it: interoperability and vendor support.=20 Interoperability between AS and RS is important if deployments want to = combine pre-packaged TXAuth and API implementations. I think that makes = a lot of sense and should be included in the charter. Vendors support: vendor support when it comes to "what can go into an = access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= I also think it is a good exercise for the group to think the whole = process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not = to provide clients with access tokens. The purpose is to enable API = request processing in a secure manner. What it really takes to achieve = that goal is not obvious if the work always stops at the =E2=80=9Cyou = have your access token, good luck=E2=80=9D stage.=20 >=20 > =E2=80=94 Justin From nobody Thu Mar 19 10:35:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E162E3A0BD1 for ; Thu, 19 Mar 2020 10:35:13 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 quawNlRwR6Zi for ; Thu, 19 Mar 2020 10:35:12 -0700 (PDT) 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 374AA3A0BB2 for ; Thu, 19 Mar 2020 10:35:11 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Ez4YjBguscbP9Ez4YjRepL; Thu, 19 Mar 2020 10:35:11 -0700 X-CMAE-Analysis: v=2.3 cv=NcGYKFL4 c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=LZs3M66Qduh0QFinj3oA:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 X-SECURESERVER-ACCT: vladimir@connect2id.com To: txauth@ietf.org References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Thu, 19 Mar 2020 19:35:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050302090608090704080401" X-CMAE-Envelope: MS4wfFOBqfnLkFS56ahJfpSrovJ2a0uuZAnR7NjCnaaF8Em575w0AK3eRKc3DzIbsVKtITWiuMipL0LPHpWJDtyDrVK+KBB/zne4m4Vd0C6zI87qyIurkS0+ 2rvOEw0nV0ovKAz+7ca5cLnNEkLSrJaXjPeTr5fBvJqB6TQ7bpP1iuEu Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 17:35:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050302090608090704080401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 19/03/2020 19:11, Torsten Lodderstedt wrote: > On 19. Mar 2020, at 17:47, Justin Richer wrote: >> Well, it=E2=80=99s in scope as much as describing any other aspect of = what the token is for and what it represents is in scope. That is alongsi= de things like the intended audience of the token, the access rights for = the token, the presentation keys the token is bound to, etc. It could be = information in the token text itself (like a JWT), it could be introspect= ed from the AS, it could be referenced in some other way. So if we can de= fine identity aspects in that, then we=E2=80=99re fine in covering it the= re.=20 >> >> But here=E2=80=99s the thing: none of that has an impact on the core p= rotocol. That is entirely up to the AS and the RS to agree on, and the cl= ient never sees or has any influence on it. That portion of the protocol = is completely opaque to the client. Therefore, it doesn=E2=80=99t really = affect the authorization and delegation portions of the client talking to= the AS and the client talking to the RS. >> >> This does raise the question of what our bar of interoperability is go= ing to be with TxAuth: do we expect independent AS and RS implementations= to talk to each other? That=E2=80=99s not something OAuth 2 was ever con= cerned with, though obviously JWT and introspection are both from the OAu= th2 WG and solve that problem. > There are two aspects to it: interoperability and vendor support.=20 > > Interoperability between AS and RS is important if deployments want to = combine pre-packaged TXAuth and API implementations. I think that makes a= lot of sense and should be included in the charter. +1 The current OAuth 2.0 status quo of the largely unspecified relationship between AS and RS is also making the life of web & sec framework maintainers difficult. We witnessing this with people integrating the OAuth SDK into frameworks. Vittorio's recent work to put together a minimal interoperable JWT profile for access tokens is helpful, but it has come after the fact. And there is not agreement on things like authorising access to claims. Integrating apps (RSs) with TxAuth should be straightforward and simple. This can have a enormous effect on adoption. > Vendors support: vendor support when it comes to "what can go into an a= ccess token" and "what can be conveyed in a token introspection response=E2= =80=9D greatly deviates in my observation. This also means implementation= use vendors specific features restricting their ability to use other sol= utions. TXAuth should aim at improving the situation. =20 +1 > I also think it is a good exercise for the group to think the whole pro= cess "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not to = provide clients with access tokens. The purpose is to enable API request = processing in a secure manner. What it really takes to achieve that goal = is not obvious if the work always stops at the =E2=80=9Cyou have your acc= ess token, good luck=E2=80=9D stage.=20 +1 Vladimir --------------ms050302090608090704080401 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMTkxNzM1MDlaMC8G CSqGSIb3DQEJBDEiBCC/ddwisrMcLHfStHhu2iYqoaL4OUdeHV0mAbDPBkd3lDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAHLWVXBCe8MDF91ksW7x/BZWT0WBRcuSd9ZOndN8I7N/wX9h FHAAHBDih79mKkyk3p2CweJGNMiy9WnrRQRfqQDZgyAahA0GqZNpEtuUiIG4BkIKIM/G/xtQ RTbDsWgLz3aK1VxwJLr25JGxhjO4u6cxkwP89uH84lE9pejIYb1z/YZ+9dZoLG5/pqM7hEBt WZLwNvmBYTiBjtDzcGXqRW6N9m+Ugfn65owcswfIwzDiAptf2vUIaRSeVmeVzzvionSG6D10 +UMDthM/rXtqOvBlPzEFDfRGnViT1BtZaNRe823u4y67736DExj/Y+cLQbDnpJoq+a2loMQ7 g9hUj9wAAAAAAAA= --------------ms050302090608090704080401-- From nobody Thu Mar 19 11:00:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3473A0C52 for ; Thu, 19 Mar 2020 11:00:29 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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=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 rOxjTNE-pE3v for ; Thu, 19 Mar 2020 11:00:26 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640133.outbound.protection.outlook.com [40.107.64.133]) (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 563BD3A0C4E for ; Thu, 19 Mar 2020 11:00:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GMQ/vALzx9jLlp1dxR8Gaw/uFIQV5qX2vBCjd/si0FxKtZ/6SZBUziNCrijKI6aGQGYyzgzZcvJS3oBQX8DuKHLbovAwwaSHcKPt0zdQ1kSMg0fRWUWeH+Mmrf1mG0cML3ExMX0bpaxmgRsZaMYhKkdBibErm4mbUAcnUapmIknjpqdxeG38vegpdUeBCg+K6dOOUl3LRcpxpDs7MWrjzDWsiZabEyOnpMzs0J5D62awhwdXPfq4j5xfojlHhIdKWQy2zxX51OL0Ru3M4KAdtInT/edvlv9d7JzmCTshhScLVHJ+2QK5bpgJ7WAk5+/Kj0zDFvigHKiBv1OsBvnU/A== 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=F6MCs4NuiWqr/FqajbZRgrqvLC4IZ9drILps5kfIwQI=; b=jO+e2wT4slgohhdTyYwVVQG9zHgQg51G4pMzhmjvnqZa3TgZjODkNf63ReEe4EAH5n+PvJygZcBJWBnDwUqpUEWW8bUr9sfuGKK7L8LGkY3r4f+cXJk7uKZcMlrawy/Pq3jiok+Xr7zx7o58oTpCX90UK4mIa7sBdNOR3oqYTSJkq/bnaqy/ebSDgw6pIhyzE5i4Qj132Aqo7QnfieNFleOLvAPiUWA/lUtYht6L80zRsH5mnB8AOKXn4cpnqazrWuULlpzBBUvuHFVsSpfLed9qn++hLBoIVcqvtoftz+i2EX+W67673RDQ9UpPk8aE1mpD3FBxFQ5FA8ZW4WQAUQ== 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=F6MCs4NuiWqr/FqajbZRgrqvLC4IZ9drILps5kfIwQI=; b=FIBmhtlf+D1z9vNcflhUfM0u6qILAzuMjRNyM26tRJLmHCCfVXTYaYSMgxH+HZn7Eg5KsaUFV+/9QuGAo3GPS8uXmN+Vr0Bwyg4RqjLXpnPbHPwdNxpsboRDaBMsX3qxezMNJrktO/FyMCVXrozoqdOB41bxGvY7OSQEwJGdluI= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM6PR00MB0601.namprd00.prod.outlook.com (2603:10b6:5:161::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2871.0; Thu, 19 Mar 2020 18:00:24 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1%9]) with mapi id 15.20.2877.000; Thu, 19 Mar 2020 18:00:23 +0000 From: Mike Jones To: "Richard Backman, Annabelle" , Dick Hardt , "txauth@ietf.org" CC: Yaron Sheffer Thread-Topic: [Txauth] TxAuth BoF draft agenda Thread-Index: AQHV/gMQGpEsChArWUOg+WdJ77msfqhQMVCw Date: Thu, 19 Mar 2020 18:00:23 +0000 Message-ID: References: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> In-Reply-To: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> 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_ActionId=1365b598-9a16-4f34-9e49-0000d8180442; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-19T17:49:00Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f1890dab-66f9-45c4-3f54-08d7cc2f65cf x-ms-traffictypediagnostic: DM6PR00MB0601: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(346002)(136003)(39860400002)(376002)(396003)(366004)(199004)(6506007)(71200400001)(52536014)(316002)(9686003)(55016002)(86362001)(33656002)(5660300002)(2906002)(966005)(66476007)(10290500003)(186003)(66946007)(110136005)(76116006)(66556008)(66446008)(478600001)(64756008)(76236002)(26005)(4326008)(81166006)(81156014)(8676002)(7696005)(53546011)(8936002)(8990500004)(99710200001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0601; H:DM6PR00MB0682.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sy+iYym+OHIwkJqZz7F6LMZFwt+2JS8Q9/wCEAoTotI6Oa9WVEe2VPU8rJPGWWOBPTO54Gwqc2fFwMEyCOlGZcB6Cqd3Mhk9zdoWG+yAXxzQ4d8papORFjQUWN7KNoNiGYLqeWwaoimN2EOQ1wlRJEN+68dFS25Ax7783xsxpmLRa9v9xS7ApSuJlFn8uCSK5Pl4VyHHXQ9V1rZ13FwOsoW+KkjYjWC2D8EtV+VGWvEOAA6p7gf2Ys+Ib8m/3McOrm/vUfN8IscD767hXw1O5+cVbeNy3Md+1G0Vyggew+xm/zgh1ipGInsBznm4VxDScZaJRp5yDJBtqGDkxFtwtKCU1HckeS9rI/VZrzvrSi08mBpgJKoW9hccEz53/w/a0SYiRgRL4ShLQu/e45lD5w8PDt9YScLiwf3g7+qMubZowStbiywCsa59UVW/DdR3s1WUXlN0RKZt/6vPGixhds8/ie/BR+zfDpOdZF8yeObBpwSRoNFwn1FQHikfwhfYpVJ2zxR26+O6GnZDQ8SPmDDqbdWgMqc/UmTGsvWoJE4LDnp62AuNhAZryNBgB/IgASq3rcuighsfRq7UD49qBA== x-ms-exchange-antispam-messagedata: yn2jiU4VHbO6qgDp9EXXGcm39+tC+NUO8NGvHKgzVtp6dc1Aa5XUCQZaX5+7so8/d5a1RFrPLfXt1MECyvRU5l9949refFikcap1tYPmbEC7Xc8ZVljvTsyMSxFd2kQalGLvV5h2m1gXlYM0DNV3RA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB068274582CAD2AE6F8F44CDAF5F40DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f1890dab-66f9-45c4-3f54-08d7cc2f65cf X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2020 18:00:23.8440 (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: 1hTSw+Rvpfm9Nw7we8OSil1v3ke1e9WK9VbcpN/uP9l6U25Rh6/J1Th2h3GzwEuvsfLJVIF0eOIRwq84hzWKbw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0601 Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:00:31 -0000 --_000_DM6PR00MB068274582CAD2AE6F8F44CDAF5F40DM6PR00MB0682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2l2ZW4gdGhhdCBmb3VyIHBlb3BsZSBoYXZlIHJhaXNlZCBxdWVzdGlvbnMgYWJvdXQgdGhlIGlk ZW50aXR5IGFzcGVjdCBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlciwgSSB3b3VsZCByZXF1ZXN0IHRo YXQgdGhlIGNoYWlycyBhbGxvY2F0ZSBhdCBsZWFzdCAyMCBtaW51dGVzIHRvIGRpc2N1c3Npb24g b2Ygd2hldGhlciBpZGVudGl0eSBzaG91bGQgYmUgaW4gb3Igb3V0IG9mIHNjb3BlLCBhbmQgaWYg aW4gc2NvcGUsIHdoYXQgYXNwZWN0cyBvZiBpZGVudGl0eSBzaG91bGQgYmUgaW4gYW5kIG91dCBv ZiBzY29wZS4gIFRoaXMgc2hvdWxkIGhhdmUgaXRzIG93biB0aW1lIHNsb3QsIHJhdGhlciB0aGFu IGluY2x1ZGluZyBpdCBpbiB0aGUgMjAgbWludXRlcyBvZiBjaGFydGVyIGFuZCBuYW1pbmcgZGlz Y3Vzc2lvbnMgY3VycmVudGx5IGFsbG9jYXRlZCwgYXMgaXTigJlzIGEgZm91bmRhdGlvbmFsIGRl Y2lzaW9uIHRvIHNjb3BpbmcgdGhlIHdvcmssIGFuZCBpcyBsaWtlbHkgdG8gbmVlZCBhdCBsZWFz dCAyMCBtaW51dGVzIG9uIGl0cyBvd24uDQoNClRvcnN0ZW7igJlzIGFuZCBWbGFkaW1pcuKAmXMg ZmVlZGJhY2sgYWJvdXQgaW50ZXJvcGVyYWJpbGl0eSBhbW9uZyBhdXRob3JpemF0aW9uIHNlcnZl cnMgYW5kIHJlc291cmNlIHNlcnZlcnMgc2hvdWxkIGFsc28gYmUgZXhwbGljaXRseSBpbmNsdWRl ZCBzb21ld2hlcmUgaW4gdGhlIGNoYXJ0ZXIgZGlzY3Vzc2lvbnMuDQoNCklmIHdl4oCZcmUgc2hv cnQgb24gdGltZSwgSeKAmWQgcmF0aGVyIHdlIGZpcnN0IGdldCBhZ3JlZW1lbnQgb24gdGhlIGNo YXJ0ZXIgYW5kIHNjb3BlIHRoYW4gZGlzY3VzcyB0aGUgZW5naW5lZXJpbmcgbWVyaXRzIGFuZCB0 cmFkZW9mZnMgYW1vbmcgcGFydGljdWxhciBwcm9wb3NlZCBzdGFydGluZyBwb2ludCBkcmFmdHMu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGFua3MsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUNClNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAxOSwgMjAyMCA4OjI4IEFNDQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJk dEBnbWFpbC5jb20+OyB0eGF1dGhAaWV0Zi5vcmcNCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYu aWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbVHhhdXRoXSBUeEF1dGgg Qm9GIGRyYWZ0IGFnZW5kYQ0KDQpJIGV4cGVjdCBhIGxvdCBvZiBkaXNjdXNzaW9uIGFyb3VuZCB3 aGV0aGVyL3RvIHdoYXQgZXh0ZW50IGl0IHNob3VsZCBpbmNsdWRlIOKAnGlkZW50aXR54oCdIGFu ZCB3aXRob3V0IHNvbWUgc3RydWN0dXJlIHRoYXQgY291bGQgZWFzaWx5IGNvbnN1bWUgdGhlIHdo b2xlIG1lZXRpbmcuIFNob3VsZCB3ZSB0aW1lYm94IHRoYXQgZGlzY3Vzc2lvbiwgYW5kL29yIGdl dCBzb21lIHZvbHVudGVlcnMgdG8gc3VtbWFyaXplIHRoZSB2YXJpb3VzIHBvc2l0aW9ucz8NCg0K 4oCTDQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0eQ0KaHR0cHM6Ly9h d3MuYW1hem9uLmNvbS9pZGVudGl0eS8NCg0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBE aWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20+Pg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAxNiwgMjAyMCBhdCA0OjA3IFBNDQpUbzogInR4YXV0 aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRmLm9yZzxtYWls dG86dHhhdXRoQGlldGYub3JnPj4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFp bC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBbRVhURVJOQUxd W1R4YXV0aF0gVHhBdXRoIEJvRiBkcmFmdCBhZ2VuZGENCg0KVmlydHVhbCBNZWV0aW5nOg0KDQpN b25kYXksIE1hcmNoIDIzDQoyMDowMCAtIDIyOjAwIFVUQyAqDQoNCkFnZW5kYQ0KQ2hhaXIgc2xp ZGVzLCBhZ2VuZGEgYmFzaGluZyAtIDEwIG1pbi4NCkNoYXJ0ZXIgKGxpbmssIHNvbGljaXQgY29t bWVudHMsIGRpc2N1c3MgV0cgbmFtZSkgLSAyMCBtaW4uDQpYWVogLSBKdXN0aW4gKHdpdGggUSZB KSAtIDIwIG1pbi4NClhBdXRoIC0gRGljayAgKHdpdGggUSZBKSAtIDIwIG1pbi4NCllhcm9uICwg RGljaywgSnVzdGluIC0gRGlzY3Vzc2lvbiBvZiBkaWZmZXJlbmNlcyBiZXR3ZWVuIHByb3RvY29s cyAtIDQwIG1pbi4NCk5leHQgc3RlcHMgLSAxMCBtaW4uDQoNCkFkZGl0aW9ucyAvIHN1Z2dlc3Rp b25zPw0KDQpUZWNoDQpUaGUgdGVjaG5vbG9neSB0byBiZSB1c2VkIGlzIHN0aWxsIFRCRC4gV2Ug d2lsbCB1cGRhdGUgdGhlIGxpc3Qgd2hlbiB3ZSBrbm93LiBXZSBhcmUgZXhwZWN0aW5nIGl0IHdp bGwgYmUgdGhlIElFVEYgV2ViRXguIChteSBwcmVmZXJlbmNlIHdvdWxkIGJlIFpvb20gaWYgYW55 b25lIGhhcyBhbiBhY2NvdW50IHRvIGhhdmUgTE9UUyBvZiBwZW9wbGUgb24gaXQgPSkNCg0KV2Ug YXJlIHBsYW5uaW5nIG9uIHVzaW5nIEV0aGVyUGFkIGZvciBub3RlcywgYW5kIGZvciBxdWV1ZSBt YW5hZ2VtZW50Lg0KDQpTY3JpYmUNCldvdWxkIHNvbWVvbmUgbGlrZSB0byB2b2x1bnRlZXIgdG8g YmUgdGhlIHNjcmliZSBvbiBFdGhlclBhZD8gV2Ugd291bGQgbGlrZSB0byBnZXQgYXMgbXVjaCBj b29yZGluYXRpb24gZG9uZSBwcmlvciBhcyBwb3NzaWJsZSB0byBtYWtlIHRoZSBiZXN0IHVzZSBv ZiB0aGUgdGltZS4NCg0KL0RpY2sNCg0KKiBTb21lIHRpbWUgbWF0aCBmb3IgMjA6MDAgLSAyMjow MCBVVEM6DQoNClBhY2lmaWMgVGltZSAgICAgICAgICAgICAgICAgICAxMzowMC0xNTowMA0KRWFz dGVybiBUaW1lICAgICAgICAgICAgICAgMTY6MDAtMTg6MDANCkNvb3JkaW5hdGVkIFVuaXZlcnNh bCBUaW1lICAgICAgICAyMDowMC0wMjowMA0KQ2VudHJhbCBFdXJvcGVhbiBUaW1lICAgICAgICAg IDIxOjAwLTIzOjAwDQpJbmRpYSBTdGFuZGFyZCBUaW1lICAgICAgICAgICAgMDE6MzAtMDM6MzAN CkNoaW5hIFN0YW5kYXJkIFRpbWUgICAgICAgICAgMDQ6MDAtMDY6MDANCkF1c3RyYWxpYW4gRWFz dGVybiBTdGFuZGFyZCBUaW1lICAgICAgIDA3OjAwLTA5OjAwDQrhkKcNCg== --_000_DM6PR00MB068274582CAD2AE6F8F44CDAF5F40DM6PR00MB0682namp_ 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 MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIw NjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+R2l2ZW4gdGhh dCBmb3VyIHBlb3BsZSBoYXZlIHJhaXNlZCBxdWVzdGlvbnMgYWJvdXQgdGhlIGlkZW50aXR5IGFz cGVjdCBvZiB0aGUgcHJvcG9zZWQgY2hhcnRlciwgSSB3b3VsZCByZXF1ZXN0IHRoYXQgdGhlIGNo YWlycyBhbGxvY2F0ZSBhdCBsZWFzdCAyMCBtaW51dGVzIHRvIGRpc2N1c3Npb24gb2Ygd2hldGhl ciBpZGVudGl0eSBzaG91bGQgYmUgaW4gb3Igb3V0DQogb2Ygc2NvcGUsIGFuZCBpZiBpbiBzY29w ZSwgd2hhdCBhc3BlY3RzIG9mIGlkZW50aXR5IHNob3VsZCBiZSBpbiBhbmQgb3V0IG9mIHNjb3Bl LiZuYnNwOyBUaGlzIHNob3VsZCBoYXZlIGl0cyBvd24gdGltZSBzbG90LCByYXRoZXIgdGhhbiBp bmNsdWRpbmcgaXQgaW4gdGhlIDIwIG1pbnV0ZXMgb2YgY2hhcnRlciBhbmQgbmFtaW5nIGRpc2N1 c3Npb25zIGN1cnJlbnRseSBhbGxvY2F0ZWQsIGFzIGl04oCZcyBhIGZvdW5kYXRpb25hbCBkZWNp c2lvbiB0byBzY29waW5nDQogdGhlIHdvcmssIGFuZCBpcyBsaWtlbHkgdG8gbmVlZCBhdCBsZWFz dCAyMCBtaW51dGVzIG9uIGl0cyBvd24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj5Ub3JzdGVu4oCZcyBhbmQgVmxhZGltaXLigJlzIGZlZWRiYWNrIGFib3V0IGludGVyb3Bl cmFiaWxpdHkgYW1vbmcgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFuZCByZXNvdXJjZSBzZXJ2ZXJz IHNob3VsZCBhbHNvIGJlIGV4cGxpY2l0bHkgaW5jbHVkZWQgc29tZXdoZXJlIGluIHRoZSBjaGFy dGVyIGRpc2N1c3Npb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SWYg d2XigJlyZSBzaG9ydCBvbiB0aW1lLCBJ4oCZZCByYXRoZXIgd2UgZmlyc3QgZ2V0IGFncmVlbWVu dCBvbiB0aGUgY2hhcnRlciBhbmQgc2NvcGUgdGhhbiBkaXNjdXNzIHRoZSBlbmdpbmVlcmluZyBt ZXJpdHMgYW5kIHRyYWRlb2ZmcyBhbW9uZyBwYXJ0aWN1bGFyIHByb3Bvc2VkIHN0YXJ0aW5nIHBv aW50IGRyYWZ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3Ms PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVHhhdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9y ZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGU8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDE5LCAyMDIwIDg6MjggQU08YnI+DQo8Yj5U bzo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OzsgdHhhdXRoQGll dGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFp bC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIFR4 QXV0aCBCb0YgZHJhZnQgYWdlbmRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGV4cGVjdCBhIGxvdCBvZiBkaXNjdXNzaW9uIGFyb3VuZCB3aGV0aGVyL3RvIHdoYXQg ZXh0ZW50IGl0IHNob3VsZCBpbmNsdWRlIOKAnGlkZW50aXR54oCdIGFuZCB3aXRob3V0IHNvbWUg c3RydWN0dXJlIHRoYXQgY291bGQgZWFzaWx5IGNvbnN1bWUgdGhlIHdob2xlIG1lZXRpbmcuIFNo b3VsZCB3ZSB0aW1lYm94IHRoYXQgZGlzY3Vzc2lvbiwgYW5kL29yIGdldCBzb21lIHZvbHVudGVl cnMgdG8gc3VtbWFyaXplIHRoZQ0KIHZhcmlvdXMgcG9zaXRpb25zPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vYXdzLmFtYXpv bi5jb20vaWRlbnRpdHkvIj5odHRwczovL2F3cy5hbWF6b24uY29tL2lkZW50aXR5LzwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5UeGF1dGggJmx0OzxhIGhyZWY9Im1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRm Lm9yZyI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBI YXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0 QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgTWFyY2ggMTYsIDIw MjAgYXQgNDowNyBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnR4YXV0 aEBpZXRmLm9yZyI+dHhhdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnR4YXV0aEBpZXRmLm9yZyI+dHhhdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i Pllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20i Pnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltFWFRF Uk5BTF1bVHhhdXRoXSBUeEF1dGggQm9GIGRyYWZ0IGFnZW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VmlydHVhbCBNZWV0aW5n OiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+TW9uZGF5LCBN YXJjaCAyMzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjIwOjAwIC0gMjI6MDAgVVRDICogPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPkFnZW5kYTwvYj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Q2hhaXIgc2xpZGVzLCBhZ2VuZGEgYmFzaGluZyAtIDEwIG1pbi48YnI+DQpDaGFydGVyIChsaW5r LCBzb2xpY2l0IGNvbW1lbnRzLCBkaXNjdXNzIFdHIG5hbWUpIC0gMjAgbWluLjxicj4NClhZWiAt IEp1c3RpbiAod2l0aCBRJmFtcDtBKSAtIDIwIG1pbi48YnI+DQpYQXV0aCAtIERpY2smbmJzcDsg KHdpdGggUSZhbXA7QSkgLSAyMCBtaW4uPGJyPg0KWWFyb24gLCBEaWNrLCBKdXN0aW4gLSBEaXNj dXNzaW9uIG9mIGRpZmZlcmVuY2VzIGJldHdlZW4gcHJvdG9jb2xzIC0gNDAgbWluLjxicj4NCk5l eHQgc3RlcHMgLSAxMCBtaW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFkZGl0aW9ucyAvIHN1Z2dlc3Rpb25zPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPlRlY2g8L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlIHRlY2hub2xvZ3kgdG8gYmUgdXNlZCBpcyBzdGlsbCBUQkQuIFdl IHdpbGwgdXBkYXRlIHRoZSBsaXN0IHdoZW4gd2Uga25vdy4gV2UgYXJlIGV4cGVjdGluZyBpdCB3 aWxsIGJlIHRoZSBJRVRGIFdlYkV4LiAobXkgcHJlZmVyZW5jZSB3b3VsZCBiZSBab29tIGlmIGFu eW9uZSBoYXMgYW4gYWNjb3VudCB0byBoYXZlIExPVFMgb2YgcGVvcGxlIG9uIGl0ID0pPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V2UgYXJlIHBsYW5uaW5n IG9uIHVzaW5nIEV0aGVyUGFkIGZvciBub3RlcywgYW5kIGZvciBxdWV1ZSBtYW5hZ2VtZW50Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPlNjcmliZTwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Xb3VsZCBzb21lb25lIGxpa2UgdG8gdm9sdW50ZWVyIHRv IGJlIHRoZSBzY3JpYmUgb24gRXRoZXJQYWQ/IFdlIHdvdWxkIGxpa2UgdG8gZ2V0IGFzIG11Y2gg Y29vcmRpbmF0aW9uIGRvbmUgcHJpb3IgYXMgcG9zc2libGUgdG8gbWFrZSB0aGUgYmVzdCB1c2Ug b2YgdGhlIHRpbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+L0RpY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4q IFNvbWUgdGltZSBtYXRoIGZvciAyMDowMCAtIDIyOjAwIFVUQzo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5QYWNpZmljIFRpbWUmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxMzow MC0xNTowMDxicj4NCkVhc3Rlcm4gVGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxNjowMC0xODowMDxicj4NCkNvb3JkaW5hdGVkIFVuaXZl cnNhbCBUaW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwOjAwLTAyOjAwPGJyPg0KQ2Vu dHJhbCBFdXJvcGVhbiBUaW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyMTow MC0yMzowMDxicj4NCkluZGlhIFN0YW5kYXJkIFRpbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAwMTozMC0wMzozMDxicj4NCkNoaW5hIFN0YW5kYXJkIFRpbWUmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDA0OjAwLTA2OjAwPGJyPg0KQXVzdHJhbGlh biBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswNzowMC0w OTowMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIx IiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEzOGluO2hlaWdodDouMDEzOGluIiBpZD0iX3gw MDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1h WkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwPSZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3Vp ZD03N2ExMGIwNy00NjYyLTQzYTQtOWNjZC04ZGZhZDljM2I5ODciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM6PR00MB068274582CAD2AE6F8F44CDAF5F40DM6PR00MB0682namp_-- From nobody Thu Mar 19 11:09:05 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2949C3A0CB4 for ; Thu, 19 Mar 2020 11:08:57 -0700 (PDT) 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 PJURMys4FdAU for ; Thu, 19 Mar 2020 11:08:52 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 1BEA43A0CC1 for ; Thu, 19 Mar 2020 11:08:52 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id s1so4318793wrv.5 for ; Thu, 19 Mar 2020 11:08:51 -0700 (PDT) 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=ikv7DK0vVhd6erm873KVQpwAl/UfijAB2FOqEb7ZxUo=; b=qGs2nIQOYWfgBMGK0k3uI1YP7TxRj68aX51ax330cjOyf78QxyNjprOjOahwmEMZwY nFVBcebk2TtPfcT6igK6LeowV5tuYH+lgLLs0DDY0CqwLWxpk6MeTRjMjSCFaoU/uOOX rE+lTkYV3Be+zjqN/bf31RH3WKepa54VF2kBkXWa6qHIHUgaQ6OoBgVsA8NLUQoWl6q4 xK23iQsktotR4l1eEQz23oTbt6rNdiEd2jWn3zZdDoGxIw604vhuQtSgGXPFGka6X7Xs 1oLn3l/fXLkXXrtIRTrqihuq+35XALZFa9xdomdUtcJPDN52UXLbtNUqBI8XqX8r+KV+ YwJg== 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=ikv7DK0vVhd6erm873KVQpwAl/UfijAB2FOqEb7ZxUo=; b=jcTZkErrPX/DT+MkWpR0fgyLKQisDbJ47L9PCRz3Cq5N8KvAgIjvOpOv9nDK/AgJ37 vt6znokavSrNppNd2O+OQX73l+4CmdZcmWfe/fNShCrbcDVZs3JWY8RhJe4cMqMjXPIT rqX7RP6H4RibtHfXAXn9upTLwvmwxY0uJ5cBKLaGCg6RKFnqMfMDIS9Olthf+NSjtykZ +gPGxlu/EZUAgU3ocFZfLrjcB+xM5JSqbCfajrYZWQL/gYHRmc0UBLWwsV4xlVG7b0qS 0tq3FrczfbQl817m2LjrLl0ivLeGUlt6f86df2zpOlFdFHbrEWQvEnyIXRojJ1W7bf2W thyw== X-Gm-Message-State: ANhLgQ3tFuuY11FpmQrno2a0g4bxm1qXsyx3Ll6xOAIEAdB12Yls2Z4p J72uHTu5orA5RJMsjD+DGRNRX4iRAQY= X-Google-Smtp-Source: ADFU+vt5IpckP9IicZue50tJ+NmxRX5W3zriXUwDhzfb+ajPA2mF3wj8D8p639k7hQlo/DWJn4B9ug== X-Received: by 2002:adf:f00f:: with SMTP id j15mr5746790wro.413.1584641329688; Thu, 19 Mar 2020 11:08:49 -0700 (PDT) Received: from p200300eb8f2625b4c1842dc11ab64701.dip0.t-ipconnect.de (p200300EB8F2625B4C1842DC11AB64701.dip0.t-ipconnect.de. [2003:eb:8f26:25b4:c184:2dc1:1ab6:4701]) by smtp.gmail.com with ESMTPSA id o16sm4743478wrs.44.2020.03.19.11.08.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2020 11:08:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Thu, 19 Mar 2020 19:08:47 +0100 Cc: Vladimir Dzhuvinov Content-Transfer-Encoding: quoted-printable Message-Id: <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> To: txauth@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:09:04 -0000 Hi all, I suggest to add the following requirement to the charter: =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I want = to make sure we try to build a protocol that serves the needs of a broad = set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 And here is my explanation:=20 OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 And there are even more examples today for multi API environments that = would benefit from that feature:=20 =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. Since we are preparing to define a completely new protocol for API = access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get = it right and simple, but if we just stick to the =E2=80=9Ca single = access token is enough=E2=80=9D mantra, we miss the chance to give = implementers a broader range of design choices out of the box and we = won=E2=80=99t success in achieving true interoperability. Here are more advantages we can gain by supporting such a feature:=20 =E2=80=A2 Privacy: =E2=80=A2 A single access token can be used to track = user across services. =E2=80=A2 RS-specific access tokens cannot. =E2=80=A2 RS-specific access tokens can also be = encrypted to protect data confidentiality in transit. =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. What do you think? best regards, Torsten.=20 > On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >=20 >=20 > On 19/03/2020 19:11, Torsten Lodderstedt wrote: >> On 19. Mar 2020, at 17:47, Justin Richer wrote: >>> Well, it=E2=80=99s in scope as much as describing any other aspect = of what the token is for and what it represents is in scope. That is = alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>=20 >>> But here=E2=80=99s the thing: none of that has an impact on the core = protocol. That is entirely up to the AS and the RS to agree on, and the = client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. >>>=20 >>> This does raise the question of what our bar of interoperability is = going to be with TxAuth: do we expect independent AS and RS = implementations to talk to each other? That=E2=80=99s not something = OAuth 2 was ever concerned with, though obviously JWT and introspection = are both from the OAuth2 WG and solve that problem. >> There are two aspects to it: interoperability and vendor support.=20 >>=20 >> Interoperability between AS and RS is important if deployments want = to combine pre-packaged TXAuth and API implementations. I think that = makes a lot of sense and should be included in the charter. >=20 > +1 >=20 > The current OAuth 2.0 status quo of the largely unspecified = relationship > between AS and RS is also making the life of web & sec framework > maintainers difficult. We witnessing this with people integrating the > OAuth SDK into frameworks. Vittorio's recent work to put together a > minimal interoperable JWT profile for access tokens is helpful, but it > has come after the fact. And there is not agreement on things like > authorising access to claims. >=20 > Integrating apps (RSs) with TxAuth should be straightforward and = simple. >=20 > This can have a enormous effect on adoption. >=20 >=20 >> Vendors support: vendor support when it comes to "what can go into an = access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >=20 > +1 >=20 >=20 >> I also think it is a good exercise for the group to think the whole = process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not = to provide clients with access tokens. The purpose is to enable API = request processing in a secure manner. What it really takes to achieve = that goal is not obvious if the work always stops at the =E2=80=9Cyou = have your access token, good luck=E2=80=9D stage.=20 >=20 > +1 >=20 > Vladimir >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Mar 19 11:28:27 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50213A0CC7 for ; Thu, 19 Mar 2020 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 sSVl3Oa75TCM for ; Thu, 19 Mar 2020 11:28:20 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640125.outbound.protection.outlook.com [40.107.64.125]) (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 9935B3A0CC4 for ; Thu, 19 Mar 2020 11:28:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AUH9DtGzxw6QV/iH8rUGQCEWwTkacXgzYqeWEE3mX6P+CWuXKu3VpzmbW1gDOa8i0GkDfe3I50S5OFHyFoAdhFTIP/pvHbX5Y/vjWT4q3UCKPDPjetrxBLCYG9pOQgp4ba2eEsj8qWOQ93hdqrZ3JLIGASCRlqjaUdxbZfjIqu1dxG18RVGOh74etWJjBS22T/aQF90CideUiNHLXyHnWy+dslhQWXwUAJihOuFzDARZ5PyOd6nBoFpPOR+Jsy9LBSxejf0agt6KUPbO1syIFMR+lBnfS9MzirsN2EaGFCtTY1AewNh+helCwAseNuGYLsUDA/AxMadKDioIpdRQyg== 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=n4QoFE1AeQKSzMItRfzZaHdVpuoKbJSQPgnIUzkWwU0=; b=Rxb/je0NwuwbGMCrvfmKYqv5K/5EHSmcGrPqQezvSLagRmTtLyLXEh1mM7zoGhDhYAVTpc+dNV/LGO19IyLGIXJJQ4Tut8pEdGScmZmJQjZWqqNl7tyMiTn6nmaIWH+4OOS8cv218mixqqHYRdnHmtbRoT/lXJlZC+q36eu2Sw3a6hOmU5YFmS+dDZqMbuYmnIOI2VVSIogu7p9i4o+DkxiaEIJboCrVkOo0LH1EWpi2ZggiMwqXtaPP9uTs10i03ijAq+oAYNoUZEEmIG3opB9AbhviP9KPfNu1QbHoAJp/eMrWXGTh+2s3ssgP+cqznkgmpTeyRBvN4Gv5hE+jsg== 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=n4QoFE1AeQKSzMItRfzZaHdVpuoKbJSQPgnIUzkWwU0=; b=FaIfVcastCuLG/JoSPrPoHZDSNB7tRzt8PQ0nWrjo1JgcKvC03I4KcsmS9FgbDrhJrO3PH8f8yA3886PklYjBBMu7VcrnpuHxTfJ79UQqN3BjmYGaWBhf2prvJ8emBtbjtWcUe6ROGkSjs8j7cyJ+HhAfn34/R2/56208jbpiw0= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM6PR00MB0816.namprd00.prod.outlook.com (2603:10b6:5:208::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2877.0; Thu, 19 Mar 2020 18:28:18 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1%9]) with mapi id 15.20.2877.000; Thu, 19 Mar 2020 18:28:18 +0000 From: Mike Jones To: Torsten Lodderstedt , "txauth@ietf.org" CC: Vladimir Dzhuvinov Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AdX+HCaFHXmvC7lDQRSXgxyQomJj5Q== Date: Thu, 19 Mar 2020 18:28:18 +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_ActionId=c44f6e9f-3fa6-450f-9d2b-00000d84d85f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-19T18:27:34Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 90c97a2c-ac0f-464c-21a7-08d7cc334bfb x-ms-traffictypediagnostic: DM6PR00MB0816: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(396003)(346002)(376002)(136003)(39860400002)(366004)(199004)(7696005)(316002)(52536014)(5660300002)(2906002)(8936002)(8990500004)(81156014)(81166006)(8676002)(86362001)(33656002)(71200400001)(9686003)(966005)(186003)(66446008)(66476007)(64756008)(26005)(10290500003)(76116006)(110136005)(55016002)(66556008)(6506007)(53546011)(4326008)(478600001)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0816; H:DM6PR00MB0682.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q+fqXrxH9yN1HJO4R8znrkQdQBsxrR11XDlI/v1hSqReBsD2OZiu5DaplqTFjJmGyLPcXagBGEmlcrvheUmYij83acWcYkNhQVbzHKriZhnM3i6xMbCqjlpqQoLTFcKfiOQfPT62acYmyuih3yQHgvpC4lRLgEuqqYN5/z69oMsSad0t+xoznXsoulQ0CApeytsoAnacjJELPmUSxb/45MZZBwbLD1um5QX+1EIge898kNaC69E7EUMRHedAF+0Nkr5El2f2IceNlcRkNwJIVlI6BhgdXdC+s9kiJ7babM08JL06upapLDLFnUS+taRlsKe6abCEII5L1rcAODx4hVw4Sn/zncf7plivhwxMG0k6T5RnxAux9oxHwh6eVHfnsQhtAXfJthyyPFDnLGdflbiNjxhLvuow7ma5PlI+EezzIQ08HtBZc1JiNsLJ5CoImKeIJaKTHqqArJmeHjxbkxvVkyFyNfW/wd72b7uzMaIZ21fe1rppiyyt/gYkeiFAxk8UtBr2lkyTNMej8fxcfQ== x-ms-exchange-antispam-messagedata: nkZb1UWLc7t4xpF3To3gcxH9cGGohKpyMgW9tCblGFtHP76zBe+lOnC3bUvor4rL/CKzhHoLmHyPe5E2BOKIsWLSe7uNiYhFgY/ICGtz6b4aCOLPfcR7EWDCjvP28MIChFLMsDpaoG2dcaxJQx20xA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90c97a2c-ac0f-464c-21a7-08d7cc334bfb X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2020 18:28:18.4898 (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: PvGa3ICAw5DVeIx9oFnUa37szJfknT4Fw1MKzgJE9RsRn5UZLZ3xWP31cPGJ20hn5p7U004VNPwWZ2BO+NknZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0816 Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:28:24 -0000 SSBzdXBwb3J0IGFkZGluZyB0aGlzIHJlcXVpcmVtZW50IHRvIHRoZSBjaGFydGVyLg0KDQoJCQkJ LS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVHhhdXRoIDx0eGF1 dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNl bnQ6IFRodXJzZGF5LCBNYXJjaCAxOSwgMjAyMCAxMTowOSBBTQ0KVG86IHR4YXV0aEBpZXRmLm9y Zw0KQ2M6IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+DQpTdWJq ZWN0OiBSZTogW1R4YXV0aF0gQ2FsbCBmb3IgY2hhcnRlciBjb25zZW5zdXMgLSBUeEF1dGggV0cN Cg0KSGkgYWxsLA0KDQpJIHN1Z2dlc3QgdG8gYWRkIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQg dG8gdGhlIGNoYXJ0ZXI6DQoJ4oCiIFN1cHBvcnQgZm9yIFJTLXNwZWNpZmljIGFjY2VzcyB0b2tl bnMgaW4gTXVsdGktUlMgZGVwbG95bWVudHMgDQoNCkkgZG9u4oCZdCBtaW5kIEhPVyB0aGlzIHJl cXVpcmVtZW50IGlzIHN1cHBvcnRlZCBpbiBUWEF1dGguIEkgd2FudCB0byBtYWtlIHN1cmUgd2Ug dHJ5IHRvIGJ1aWxkIGEgcHJvdG9jb2wgdGhhdCBzZXJ2ZXMgdGhlIG5lZWRzIG9mIGEgYnJvYWQg c2V0IG9mIGRlcGxveW1lbnRzLiBNeSBjb25jZXJuIGlzIG90aGVyd2lzZSBUWEF1dGggd2lsbCBi ZSBub3QgaW5ub3ZhdGl2ZSBlbm91Z2ggdG8gZ2FpbiB0cmFjdGlvbiBpbiB0aGUgbWFya2V0IHJh cGlkbHkuIFNwZWFraW5nIGZvciBteXNlbGYsIEkgcmVhbGlzZWQgaW4gdGhlIGxhc3QgY291cGxl IG9mIGRheXMsIG1vc3RseSBpbiBjb252ZXJzYXRpb25zIHdpdGggSnVzdGluLCB0aGF0IHRoZSBy ZXN1bHQgb2YgdGhpcyB3b3JraW5nIGdyb3VwIGFzIGVudmlzaW9uZWQgbm93IGlzIG5vdCBvZiBw YXJ0aWN1bGFyIGludGVyZXN0IHRvIHVzICh5ZXMuY29tKSBiZWNhdXNlIGl0IGRvZXMgbm90IHNv bHZlIG91ciByZWFsIHByb2JsZW1zLiANCg0KQW5kIGhlcmUgaXMgbXkgZXhwbGFuYXRpb246IA0K DQpPQXV0aCB0cmFkaXRpb25hbGx5IGhhcyB0aGUgcGhpbG9zb3BoeSBvZiBhIHNpbmdsZSBhY2Nl c3MgdG9rZW4uIFRoYXTigJlzIGZpbmUgZm9yIHNpbmdsZSBzZXJ2aWNlIGRlcGxveW1lbnRzLCBi dXQgaXQgaGFkIHJlYWNoZWQgaXRzIGxpbWl0cyBhbHJlYWR5IGJlZm9yZSBSRkM2NzQ5IHdhcyBw dWJsaXNoZWQuIFRoZXJlIGFyZSBhIHJlYWwgaW1wbGVtZW50YXRpb25zIG91dCB0aGVyZSBmb3Jj aW5nIGNsaWVudHMgdG8gdXNlIGRpZmZlcmVudCBhY2Nlc3MgdG9rZW5zIGZvciBkaWZmZXJlbnQg c2VydmljZXMsIHR5cGljYWxseSBmb3IgcHJpdmFjeSBhbmQgc2VjdXJpdHkgcmVhc29ucy4gVGhl cmUgaXMgYWxzbyBhbiDigJxhbmNpZW50IiB0ZWNobm9sb2d5IGNhbGxlZCBLZXJiZXJvcyB0aGF0 IHVzZXMgZXhhY3RseSB0aGlzIHBhdHRlcm4gYW5kIGlzIHdlbGwga25vd24gZm9yIHNlY3VyaXR5 LCBwZXJmb3JtYW5jZSwgYW5kIHNjYWxhYmlsaXR5LiANCg0KQW5kIHRoZXJlIGFyZSBldmVuIG1v cmUgZXhhbXBsZXMgdG9kYXkgZm9yIG11bHRpIEFQSSBlbnZpcm9ubWVudHMgdGhhdCB3b3VsZCBi ZW5lZml0IGZyb20gdGhhdCBmZWF0dXJlOiANCgnigKIgT3BlbiBiYW5raW5nOiBtb3N0IGJhbmtz IEkgd29ya2VkIHdpdGggaGF2ZSBtdWx0aXBsZSBBUElzLCBzZWdyZWdhdGlvbiBiZXR3ZWVuIEFQ SXMgaXMgdG9kYXkgYWNoaWV2ZWQgYnkgbWFpbnRhaW5pbmcgZGlmZmVyZW50IGdyYW50cywgYmFz aWNhbGx5IHJlc3VsdGluZyBpbiB0aGUgZmFjdCB0aGF0IHRoZSB1c2VycyBjYW5ub3QgY29uc2Vu dCB0byBkaWZmZXJlbnQgc2VydmljZXMgYXQgb25jZS4gV2hhdCBhIHRlcnJpYmxlIFVYIQ0KCeKA oiBFdmVyeW9uZSBpcyBkb2luZyBtaWNybyBzZXJ2aWNlcyB0b2RheS4gSGF2ZSB5b3UgZXZlcnkg dGhvdWdodCBhYm91dCB0aGUgY291cGxpbmcgY2F1c2VkIGJ5IGEgc2luZ2xlIHRva2VuIGFjcm9z cyBtaWNybyBzZXJ2aWNlcz8gVGhpcyByZW1pbmRzIG1lIG9mIGhvdyBlYXN5IGl0IGlzIHRvIHRl c3Qgc2VydmljZXMgaW5kZXBlbmRlbnRseSB1c2luZyBzZWxmLWNvbnRhaW5lZCBSUy1zcGVjaWZp YyB0b2tlbnMuDQoJ4oCiIElvVCAtIGV2ZXJ5IGRldmljZSBpbiBhIGhvdXNlaG9sZCBpcyBhIHBv dGVudGlhbCBSUyAoaW4gbXkgb3BpbmlvbikuIENvbnZleWluZyBhbGwgbmVjZXNzYXJ5IGRhdGEg aW4gYW4gYWNjZXNzIHRva2VuIG5lZWRlZCB0byBtZWV0IGFjY2VzcyBjb250cm9sIGRlY2lzaW9u cyBsb2NhbGx5IHdvdWxkIGJlIGEgaHVnZSBiZW5lZml0IGluIHRlcm1zIG9mIHBlcmZvcm1hbmNl IGFuZCBkZWNvdXBsaW5nLiBVc2luZyBzeW1tZXRyaWMgY3J5cHRvZ3JhcGh5IGZvciB0b2tlbiBp bnRlZ3JpdHksIGF1dGhlbnRpY2l0eSBhbmQgY29uZmlkZW50aWFsaXR5IHdvdWxkIHJlc3VsdCBp biBsb3dlciBjb21wdXRlIHJlcXVpcmVtZW50cy4NCg0KU2luY2Ugd2UgYXJlIHByZXBhcmluZyB0 byBkZWZpbmUgYSBjb21wbGV0ZWx5IG5ldyBwcm90b2NvbCBmb3IgQVBJIGFjY2VzcyBhdXRob3Jp emF0aW9uIGFuZCBkZWxlZ2F0aW9uLCBJIHRoaW5rIHRoaXMgbmV3IHByb3RvY29sIHNob3VsZCBz dXBwb3J0IHRoaXMga2luZCBvZiBzY2VuYXJpb3MuIEl0IHdpbGwgcmVxdWlyZSBzaWduaWZpY2Fu dCB3b3JrIHRvIGdldCBpdCByaWdodCBhbmQgc2ltcGxlLCBidXQgaWYgd2UganVzdCBzdGljayB0 byB0aGUg4oCcYSBzaW5nbGUgYWNjZXNzIHRva2VuIGlzIGVub3VnaOKAnSBtYW50cmEsIHdlIG1p c3MgdGhlIGNoYW5jZSB0byBnaXZlIGltcGxlbWVudGVycyBhIGJyb2FkZXIgcmFuZ2Ugb2YgZGVz aWduIGNob2ljZXMgb3V0IG9mIHRoZSBib3ggYW5kIHdlIHdvbuKAmXQgc3VjY2VzcyBpbiBhY2hp ZXZpbmcgdHJ1ZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpIZXJlIGFyZSBtb3JlIGFkdmFudGFnZXMg d2UgY2FuIGdhaW4gYnkgc3VwcG9ydGluZyBzdWNoIGEgZmVhdHVyZTogDQoJ4oCiIFByaXZhY3k6 DQoJCeKAoiBBIHNpbmdsZSBhY2Nlc3MgdG9rZW4gY2FuIGJlIHVzZWQgdG8gdHJhY2sgdXNlciBh Y3Jvc3Mgc2VydmljZXMuDQoJCeKAoiBSUy1zcGVjaWZpYyBhY2Nlc3MgdG9rZW5zIGNhbm5vdC4N CgkJ4oCiIFJTLXNwZWNpZmljIGFjY2VzcyB0b2tlbnMgY2FuIGFsc28gYmUgZW5jcnlwdGVkIHRv IHByb3RlY3QgZGF0YSBjb25maWRlbnRpYWxpdHkgaW4gdHJhbnNpdC4NCgnigKIgU2VjdXJpdHk6 IFJTLXNwZWNpZmljIGFjY2VzcyB0b2tlbnMgaGF2ZSBhIGJhc2VsaW5lIHJlcGxheSBkZXRlY3Rp b24uDQoJ4oCiIFBlcmZvcm1hbmNlOiBSUy1zcGVjaWZpYyBhY2Nlc3MgdG9rZW5zIGFsbG93IHRo ZSBBUyB0byBjb252ZXkgYWxsIGRhdGEgcmVxdWlyZWQgdG8gYXV0aG9yaXplIGFuIEFQSSBjYWxs IGluIGEgdG9rZW4gKGUuZy4gYSBKV1QpIGFuZCB0byBSUyB0byBtZWV0IHRoZSBhY2Nlc3MgY29u dHJvbCBkZWNpc2lvbiBiYXNlZCBvbiB0aGF0IGRhdGEuIFRoaXMgaXMgYSBodWdlIGFkdmFudGFn ZSBpbiB0ZXJtcyBvZiBwZXJmb3JtYW5jZSwgc2NhbGFiaWxpdHkgYW5kIGNvc3Qgc2luY2UgdGhl cmUgaXMgbm8gbmVlZCBmb3IgVG9rZW4gSW50cm9zcGVjdGlvbiBvciBvdGhlciBraW5kcyBvZiBh Y2Nlc3MgdG8gYW5vdGhlciBzZXJ2aWNlcyBvciBkYXRhYmFzZS4NCg0KV2hhdCBkbyB5b3UgdGhp bms/DQoNCmJlc3QgcmVnYXJkcywNClRvcnN0ZW4uIA0KDQo+IE9uIDE5LiBNYXIgMjAyMCwgYXQg MTg6MzUsIFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+IHdyb3Rl Og0KPiANCj4gDQo+IE9uIDE5LzAzLzIwMjAgMTk6MTEsIFRvcnN0ZW4gTG9kZGVyc3RlZHQgd3Jv dGU6DQo+PiBPbiAxOS4gTWFyIDIwMjAsIGF0IDE3OjQ3LCBKdXN0aW4gUmljaGVyIDxqcmljaGVy QG1pdC5lZHU+IHdyb3RlOg0KPj4+IFdlbGwsIGl04oCZcyBpbiBzY29wZSBhcyBtdWNoIGFzIGRl c2NyaWJpbmcgYW55IG90aGVyIGFzcGVjdCBvZiB3aGF0IHRoZSB0b2tlbiBpcyBmb3IgYW5kIHdo YXQgaXQgcmVwcmVzZW50cyBpcyBpbiBzY29wZS4gVGhhdCBpcyBhbG9uZ3NpZGUgdGhpbmdzIGxp a2UgdGhlIGludGVuZGVkIGF1ZGllbmNlIG9mIHRoZSB0b2tlbiwgdGhlIGFjY2VzcyByaWdodHMg Zm9yIHRoZSB0b2tlbiwgdGhlIHByZXNlbnRhdGlvbiBrZXlzIHRoZSB0b2tlbiBpcyBib3VuZCB0 bywgZXRjLiBJdCBjb3VsZCBiZSBpbmZvcm1hdGlvbiBpbiB0aGUgdG9rZW4gdGV4dCBpdHNlbGYg KGxpa2UgYSBKV1QpLCBpdCBjb3VsZCBiZSBpbnRyb3NwZWN0ZWQgZnJvbSB0aGUgQVMsIGl0IGNv dWxkIGJlIHJlZmVyZW5jZWQgaW4gc29tZSBvdGhlciB3YXkuIFNvIGlmIHdlIGNhbiBkZWZpbmUg aWRlbnRpdHkgYXNwZWN0cyBpbiB0aGF0LCB0aGVuIHdl4oCZcmUgZmluZSBpbiBjb3ZlcmluZyBp dCB0aGVyZS4gDQo+Pj4gDQo+Pj4gQnV0IGhlcmXigJlzIHRoZSB0aGluZzogbm9uZSBvZiB0aGF0 IGhhcyBhbiBpbXBhY3Qgb24gdGhlIGNvcmUgcHJvdG9jb2wuIFRoYXQgaXMgZW50aXJlbHkgdXAg dG8gdGhlIEFTIGFuZCB0aGUgUlMgdG8gYWdyZWUgb24sIGFuZCB0aGUgY2xpZW50IG5ldmVyIHNl ZXMgb3IgaGFzIGFueSBpbmZsdWVuY2Ugb24gaXQuIFRoYXQgcG9ydGlvbiBvZiB0aGUgcHJvdG9j b2wgaXMgY29tcGxldGVseSBvcGFxdWUgdG8gdGhlIGNsaWVudC4gVGhlcmVmb3JlLCBpdCBkb2Vz buKAmXQgcmVhbGx5IGFmZmVjdCB0aGUgYXV0aG9yaXphdGlvbiBhbmQgZGVsZWdhdGlvbiBwb3J0 aW9ucyBvZiB0aGUgY2xpZW50IHRhbGtpbmcgdG8gdGhlIEFTIGFuZCB0aGUgY2xpZW50IHRhbGtp bmcgdG8gdGhlIFJTLg0KPj4+IA0KPj4+IFRoaXMgZG9lcyByYWlzZSB0aGUgcXVlc3Rpb24gb2Yg d2hhdCBvdXIgYmFyIG9mIGludGVyb3BlcmFiaWxpdHkgaXMgZ29pbmcgdG8gYmUgd2l0aCBUeEF1 dGg6IGRvIHdlIGV4cGVjdCBpbmRlcGVuZGVudCBBUyBhbmQgUlMgaW1wbGVtZW50YXRpb25zIHRv IHRhbGsgdG8gZWFjaCBvdGhlcj8gVGhhdOKAmXMgbm90IHNvbWV0aGluZyBPQXV0aCAyIHdhcyBl dmVyIGNvbmNlcm5lZCB3aXRoLCB0aG91Z2ggb2J2aW91c2x5IEpXVCBhbmQgaW50cm9zcGVjdGlv biBhcmUgYm90aCBmcm9tIHRoZSBPQXV0aDIgV0cgYW5kIHNvbHZlIHRoYXQgcHJvYmxlbS4NCj4+ IFRoZXJlIGFyZSB0d28gYXNwZWN0cyB0byBpdDogaW50ZXJvcGVyYWJpbGl0eSBhbmQgdmVuZG9y IHN1cHBvcnQuIA0KPj4gDQo+PiBJbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gQVMgYW5kIFJTIGlz IGltcG9ydGFudCBpZiBkZXBsb3ltZW50cyB3YW50IHRvIGNvbWJpbmUgcHJlLXBhY2thZ2VkIFRY QXV0aCBhbmQgQVBJIGltcGxlbWVudGF0aW9ucy4gSSB0aGluayB0aGF0IG1ha2VzIGEgbG90IG9m IHNlbnNlIGFuZCBzaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGNoYXJ0ZXIuDQo+IA0KPiArMQ0K PiANCj4gVGhlIGN1cnJlbnQgT0F1dGggMi4wIHN0YXR1cyBxdW8gb2YgdGhlIGxhcmdlbHkgdW5z cGVjaWZpZWQgDQo+IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEFTIGFuZCBSUyBpcyBhbHNvIG1ha2lu ZyB0aGUgbGlmZSBvZiB3ZWIgJiBzZWMgDQo+IGZyYW1ld29yayBtYWludGFpbmVycyBkaWZmaWN1 bHQuIFdlIHdpdG5lc3NpbmcgdGhpcyB3aXRoIHBlb3BsZSANCj4gaW50ZWdyYXRpbmcgdGhlIE9B dXRoIFNESyBpbnRvIGZyYW1ld29ya3MuIFZpdHRvcmlvJ3MgcmVjZW50IHdvcmsgdG8gDQo+IHB1 dCB0b2dldGhlciBhIG1pbmltYWwgaW50ZXJvcGVyYWJsZSBKV1QgcHJvZmlsZSBmb3IgYWNjZXNz IHRva2VucyBpcyANCj4gaGVscGZ1bCwgYnV0IGl0IGhhcyBjb21lIGFmdGVyIHRoZSBmYWN0LiBB bmQgdGhlcmUgaXMgbm90IGFncmVlbWVudCBvbiANCj4gdGhpbmdzIGxpa2UgYXV0aG9yaXNpbmcg YWNjZXNzIHRvIGNsYWltcy4NCj4gDQo+IEludGVncmF0aW5nIGFwcHMgKFJTcykgd2l0aCBUeEF1 dGggc2hvdWxkIGJlIHN0cmFpZ2h0Zm9yd2FyZCBhbmQgc2ltcGxlLg0KPiANCj4gVGhpcyBjYW4g aGF2ZSBhIGVub3Jtb3VzIGVmZmVjdCBvbiBhZG9wdGlvbi4NCj4gDQo+IA0KPj4gVmVuZG9ycyBz dXBwb3J0OiB2ZW5kb3Igc3VwcG9ydCB3aGVuIGl0IGNvbWVzIHRvICJ3aGF0IGNhbiBnbyBpbnRv IGFuIGFjY2VzcyB0b2tlbiIgYW5kICJ3aGF0IGNhbiBiZSBjb252ZXllZCBpbiBhIHRva2VuIGlu dHJvc3BlY3Rpb24gcmVzcG9uc2XigJ0gZ3JlYXRseSBkZXZpYXRlcyBpbiBteSBvYnNlcnZhdGlv bi4gVGhpcyBhbHNvIG1lYW5zIGltcGxlbWVudGF0aW9uIHVzZSB2ZW5kb3JzIHNwZWNpZmljIGZl YXR1cmVzIHJlc3RyaWN0aW5nIHRoZWlyIGFiaWxpdHkgdG8gdXNlIG90aGVyIHNvbHV0aW9ucy4g VFhBdXRoIHNob3VsZCBhaW0gYXQgaW1wcm92aW5nIHRoZSBzaXR1YXRpb24uICANCj4gDQo+ICsx DQo+IA0KPiANCj4+IEkgYWxzbyB0aGluayBpdCBpcyBhIGdvb2QgZXhlcmNpc2UgZm9yIHRoZSBn cm91cCB0byB0aGluayB0aGUgd2hvbGUgcHJvY2VzcyAiZnJvbSB0aGUgZW5k4oCdLiBUaGUgcHVy cG9zZSBvZiBUWEF1dGggKGFuZCBPQXV0aCkgaXMgbm90IHRvIHByb3ZpZGUgY2xpZW50cyB3aXRo IGFjY2VzcyB0b2tlbnMuIFRoZSBwdXJwb3NlIGlzIHRvIGVuYWJsZSBBUEkgcmVxdWVzdCBwcm9j ZXNzaW5nIGluIGEgc2VjdXJlIG1hbm5lci4gV2hhdCBpdCByZWFsbHkgdGFrZXMgdG8gYWNoaWV2 ZSB0aGF0IGdvYWwgaXMgbm90IG9idmlvdXMgaWYgdGhlIHdvcmsgYWx3YXlzIHN0b3BzIGF0IHRo ZSDigJx5b3UgaGF2ZSB5b3VyIGFjY2VzcyB0b2tlbiwgZ29vZCBsdWNr4oCdIHN0YWdlLiANCj4g DQo+ICsxDQo+IA0KPiBWbGFkaW1pcg0KPiANCj4gDQo+IC0tDQo+IFR4YXV0aCBtYWlsaW5nIGxp c3QNCj4gVHhhdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoDQoNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo= From nobody Thu Mar 19 11:35:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8593A0D06 for ; Thu, 19 Mar 2020 11:35:50 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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=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 PSW_Nv2STkgt for ; Thu, 19 Mar 2020 11:35:46 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640102.outbound.protection.outlook.com [40.107.64.102]) (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 1B4273A0D04 for ; Thu, 19 Mar 2020 11:35:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TUwCzq3yBzUTVYbI2LOtyawm/67Fonp2W2x+i7hxx7QNsZnhfmIu8TmPjjuWEzhgI+s/g6q/QRRfBb2LdLFgw9X9fqHhaVkfeiqgN+HLuw5Jj/ZipIeqo61SL7XZlhCdqPS+O0K6HYrGGst25k79JwyQdMNut4bp007hArvQHrL08ZmfjBu7Wi2ZteF3VXL6FqgANtcQOnrAx7Nx08Y1T5mn1h7xITcPqz1wJH+mTJeM4LvmRPpxciBfNteAhjweSrzNoFOefD3k6jkePByyRoBSXVHkBv5wApFqfpx4fkcfP5JmrAo2I8Dacrx5UsIAK27enhCyR4hIu/gCculbhg== 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=Dc38Uw3vCfTVNhXn+yRYlAXfSNBaGweXGFoC/XKELqI=; b=lcdJOJ5JwJmOBEbGyi+SSeCtUNzyqydoeBu38v0Ae6gP/szof2vN8nR1pheME6YG7wdG9n6m+udztP49Uqkns89sVvz5eK87+e8e/8yqG2aWskfhPz/B1ynXv24wooyhFfmGoNlllK5SE8J1ZrYM7/QU8rygTAMzAS8qG/MHcm8lv6IDxGHnjjPZ6Fl6I1WwWqiwJ93RK+gFrCpkNOQhdqAsYvJ1tSlRN29b3nSSDDIKmzRLGGeQzFDYeV7Un3Z7b4SFOdi3XT/3zyAnvldwE2Re6S/KMnq0E5SlhvtlM7hxAbIl+3jPjuq4s6jQs7oNermB6A7KVy/N5PNkKGl18g== 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=Dc38Uw3vCfTVNhXn+yRYlAXfSNBaGweXGFoC/XKELqI=; b=KQCb5Vbr1G+59S5rTj+dELBPptQ3Mlvd53rmiGQacRIUqqnTAg9jRmJnbgvSB7BuIpvYruPRMk9HEn74n2vyv9vZstBu/0Plj35FGKXFeUzwwpziKAffKjmCqLMCWBOLfAEjSRkCRVtqZwedXq9lH2CnPmQbJ47EB8k8vWkQcLs= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM6PR00MB0800.namprd00.prod.outlook.com (2603:10b6:5:1b9::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2877.0; Thu, 19 Mar 2020 18:35:43 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1%9]) with mapi id 15.20.2877.000; Thu, 19 Mar 2020 18:35:43 +0000 From: Mike Jones To: "Richard Backman, Annabelle" , Dick Hardt , "txauth@ietf.org" , "panva.ip@gmail.com" CC: Yaron Sheffer Thread-Topic: [Txauth] TxAuth BoF draft agenda Thread-Index: AQHV/gMQGpEsChArWUOg+WdJ77msfqhQMVCwgAAM4oA= Date: Thu, 19 Mar 2020 18:35:43 +0000 Message-ID: References: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> In-Reply-To: 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_ActionId=1365b598-9a16-4f34-9e49-0000d8180442; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-19T17:49:00Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ce2e2b74-8d5a-4013-4f4e-08d7cc34555b x-ms-traffictypediagnostic: DM6PR00MB0800: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(199004)(7696005)(52536014)(5660300002)(2940100002)(2906002)(8936002)(8990500004)(81156014)(81166006)(8676002)(86362001)(33656002)(71200400001)(9686003)(966005)(76236002)(186003)(66446008)(66476007)(64756008)(26005)(10290500003)(498600001)(76116006)(110136005)(55016002)(66556008)(6506007)(53546011)(4326008)(66946007)(99710200001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0800; H:DM6PR00MB0682.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 86hkhAc8Pl4gFk4lUzWigEdoddM8BuJQ2pHLoRQeTCiDbhQdKEuG6dfukQvO2YNsNzzEnDnDgmkJFH9WxpNfPYuWsGb8fWpaTsqZlHYdEvQl1qCWuhOslQClpeEl3BSrsdAUElo0qBb1yE9syMxLymgvOxr3vuLdsihWOCA7rstxucXtQpX4U4SW/oN+9V5K1kNG12g5mfjq2cyMHG0mkuYMKnS3KHa7cIads6SebbHFYYVM4txoA/OnQA0MDnppGN8HtDn/9TV7btItgrCHnOuXzf1qZ+RAQspGFJqvJDyCEJfBXzJAKbDzNeBvdhAojkFrgsjDdjs/YCCHpd0K7jMtmhou7N/x8HewnnbRW+isSxt3TSgDHc4G1poarZkf/UlVqt+TjgoywLVcFAruQ4aLUR+h9lpyFowfrWU1hi8JSvtqPK88u6tWFIAY8CLIoW+LflhoKjYpiBTCjSNPyM1vWTKLDoNO9tnlHYPAWUncEicfIeKWFPJZVH/MPvbgo2xlQKg/3qr70rtyKSvZMqf4FmbywKhOCo9xIdnOqQWoPCfQ1jOtQrmJk1yPs1ppby6cXXsvp7CPGeOCPhLrDA== x-ms-exchange-antispam-messagedata: ZZdiEUBj6ztf5aY1SqItUOgNUZ7pzf9lP6J5/2lnEDVMcP6nemojAmQ2cSwY5yzdudaXwqgeCGypPe6F8E6IY8NMaiyoZ6+ShNffCTJeVhCJ+u4oE6L4XvXCgNVaFWFhS84cvywECMAqvW0Ebx362g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06828533979EECA9F27B01B5F5F40DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce2e2b74-8d5a-4013-4f4e-08d7cc34555b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2020 18:35:43.7512 (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: Vfa9p/wGv66JZTisfsAeOYBPgQi5968httTV/NxBatnOkBib2hLGOO16eoypHYR1e0RHHBd5I6nF7PCKLFg1GQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0800 Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:35:52 -0000 --_000_DM6PR00MB06828533979EECA9F27B01B5F5F40DM6PR00MB0682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIGl04oCZcyBmaXZlLiAgSSBtaXNzZWQgc2VlaW5nIEZpbGlw4oCZcyBjb21tZW50 cy4NCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE5LCAyMDIwIDEx OjAwIEFNDQpUbzogUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgPHJpY2hhbm5hPTQwYW1hem9u LmNvbUBkbWFyYy5pZXRmLm9yZz47IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPjsg dHhhdXRoQGlldGYub3JnDQpDYzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29t Pg0KU3ViamVjdDogUkU6IFtUeGF1dGhdIFR4QXV0aCBCb0YgZHJhZnQgYWdlbmRhDQoNCkdpdmVu IHRoYXQgZm91ciBwZW9wbGUgaGF2ZSByYWlzZWQgcXVlc3Rpb25zIGFib3V0IHRoZSBpZGVudGl0 eSBhc3BlY3Qgb2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIsIEkgd291bGQgcmVxdWVzdCB0aGF0IHRo ZSBjaGFpcnMgYWxsb2NhdGUgYXQgbGVhc3QgMjAgbWludXRlcyB0byBkaXNjdXNzaW9uIG9mIHdo ZXRoZXIgaWRlbnRpdHkgc2hvdWxkIGJlIGluIG9yIG91dCBvZiBzY29wZSwgYW5kIGlmIGluIHNj b3BlLCB3aGF0IGFzcGVjdHMgb2YgaWRlbnRpdHkgc2hvdWxkIGJlIGluIGFuZCBvdXQgb2Ygc2Nv cGUuICBUaGlzIHNob3VsZCBoYXZlIGl0cyBvd24gdGltZSBzbG90LCByYXRoZXIgdGhhbiBpbmNs dWRpbmcgaXQgaW4gdGhlIDIwIG1pbnV0ZXMgb2YgY2hhcnRlciBhbmQgbmFtaW5nIGRpc2N1c3Np b25zIGN1cnJlbnRseSBhbGxvY2F0ZWQsIGFzIGl04oCZcyBhIGZvdW5kYXRpb25hbCBkZWNpc2lv biB0byBzY29waW5nIHRoZSB3b3JrLCBhbmQgaXMgbGlrZWx5IHRvIG5lZWQgYXQgbGVhc3QgMjAg bWludXRlcyBvbiBpdHMgb3duLg0KDQpUb3JzdGVu4oCZcyBhbmQgVmxhZGltaXLigJlzIGZlZWRi YWNrIGFib3V0IGludGVyb3BlcmFiaWxpdHkgYW1vbmcgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGFu ZCByZXNvdXJjZSBzZXJ2ZXJzIHNob3VsZCBhbHNvIGJlIGV4cGxpY2l0bHkgaW5jbHVkZWQgc29t ZXdoZXJlIGluIHRoZSBjaGFydGVyIGRpc2N1c3Npb25zLg0KDQpJZiB3ZeKAmXJlIHNob3J0IG9u IHRpbWUsIEnigJlkIHJhdGhlciB3ZSBmaXJzdCBnZXQgYWdyZWVtZW50IG9uIHRoZSBjaGFydGVy IGFuZCBzY29wZSB0aGFuIGRpc2N1c3MgdGhlIGVuZ2luZWVyaW5nIG1lcml0cyBhbmQgdHJhZGVv ZmZzIGFtb25nIHBhcnRpY3VsYXIgcHJvcG9zZWQgc3RhcnRpbmcgcG9pbnQgZHJhZnRzLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhhbmtzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgUmljaGFyZCBC YWNrbWFuLCBBbm5hYmVsbGUNClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOSwgMjAyMCA4OjI4IEFN DQpUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tPj47IHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPg0KQ2M6 IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIFR4QXV0aCBCb0Yg ZHJhZnQgYWdlbmRhDQoNCkkgZXhwZWN0IGEgbG90IG9mIGRpc2N1c3Npb24gYXJvdW5kIHdoZXRo ZXIvdG8gd2hhdCBleHRlbnQgaXQgc2hvdWxkIGluY2x1ZGUg4oCcaWRlbnRpdHnigJ0gYW5kIHdp dGhvdXQgc29tZSBzdHJ1Y3R1cmUgdGhhdCBjb3VsZCBlYXNpbHkgY29uc3VtZSB0aGUgd2hvbGUg bWVldGluZy4gU2hvdWxkIHdlIHRpbWVib3ggdGhhdCBkaXNjdXNzaW9uLCBhbmQvb3IgZ2V0IHNv bWUgdm9sdW50ZWVycyB0byBzdW1tYXJpemUgdGhlIHZhcmlvdXMgcG9zaXRpb25zPw0KDQrigJMN CkFubmFiZWxsZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQpodHRwczovL2F3cy5h bWF6b24uY29tL2lkZW50aXR5Lw0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sg SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+ DQpEYXRlOiBNb25kYXksIE1hcmNoIDE2LCAyMDIwIGF0IDQ6MDcgUE0NClRvOiAidHhhdXRoQGll dGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+IiA8dHhhdXRoQGlldGYub3JnPG1haWx0bzp0 eGF1dGhAaWV0Zi5vcmc+Pg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNv bTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4NClN1YmplY3Q6IFtFWFRFUk5BTF1bVHhh dXRoXSBUeEF1dGggQm9GIGRyYWZ0IGFnZW5kYQ0KDQpWaXJ0dWFsIE1lZXRpbmc6DQoNCk1vbmRh eSwgTWFyY2ggMjMNCjIwOjAwIC0gMjI6MDAgVVRDICoNCg0KQWdlbmRhDQpDaGFpciBzbGlkZXMs IGFnZW5kYSBiYXNoaW5nIC0gMTAgbWluLg0KQ2hhcnRlciAobGluaywgc29saWNpdCBjb21tZW50 cywgZGlzY3VzcyBXRyBuYW1lKSAtIDIwIG1pbi4NClhZWiAtIEp1c3RpbiAod2l0aCBRJkEpIC0g MjAgbWluLg0KWEF1dGggLSBEaWNrICAod2l0aCBRJkEpIC0gMjAgbWluLg0KWWFyb24gLCBEaWNr LCBKdXN0aW4gLSBEaXNjdXNzaW9uIG9mIGRpZmZlcmVuY2VzIGJldHdlZW4gcHJvdG9jb2xzIC0g NDAgbWluLg0KTmV4dCBzdGVwcyAtIDEwIG1pbi4NCg0KQWRkaXRpb25zIC8gc3VnZ2VzdGlvbnM/ DQoNClRlY2gNClRoZSB0ZWNobm9sb2d5IHRvIGJlIHVzZWQgaXMgc3RpbGwgVEJELiBXZSB3aWxs IHVwZGF0ZSB0aGUgbGlzdCB3aGVuIHdlIGtub3cuIFdlIGFyZSBleHBlY3RpbmcgaXQgd2lsbCBi ZSB0aGUgSUVURiBXZWJFeC4gKG15IHByZWZlcmVuY2Ugd291bGQgYmUgWm9vbSBpZiBhbnlvbmUg aGFzIGFuIGFjY291bnQgdG8gaGF2ZSBMT1RTIG9mIHBlb3BsZSBvbiBpdCA9KQ0KDQpXZSBhcmUg cGxhbm5pbmcgb24gdXNpbmcgRXRoZXJQYWQgZm9yIG5vdGVzLCBhbmQgZm9yIHF1ZXVlIG1hbmFn ZW1lbnQuDQoNClNjcmliZQ0KV291bGQgc29tZW9uZSBsaWtlIHRvIHZvbHVudGVlciB0byBiZSB0 aGUgc2NyaWJlIG9uIEV0aGVyUGFkPyBXZSB3b3VsZCBsaWtlIHRvIGdldCBhcyBtdWNoIGNvb3Jk aW5hdGlvbiBkb25lIHByaW9yIGFzIHBvc3NpYmxlIHRvIG1ha2UgdGhlIGJlc3QgdXNlIG9mIHRo ZSB0aW1lLg0KDQovRGljaw0KDQoqIFNvbWUgdGltZSBtYXRoIGZvciAyMDowMCAtIDIyOjAwIFVU QzoNCg0KUGFjaWZpYyBUaW1lICAgICAgICAgICAgICAgICAgIDEzOjAwLTE1OjAwDQpFYXN0ZXJu IFRpbWUgICAgICAgICAgICAgICAxNjowMC0xODowMA0KQ29vcmRpbmF0ZWQgVW5pdmVyc2FsIFRp bWUgICAgICAgIDIwOjAwLTAyOjAwDQpDZW50cmFsIEV1cm9wZWFuIFRpbWUgICAgICAgICAgMjE6 MDAtMjM6MDANCkluZGlhIFN0YW5kYXJkIFRpbWUgICAgICAgICAgICAwMTozMC0wMzozMA0KQ2hp bmEgU3RhbmRhcmQgVGltZSAgICAgICAgICAwNDowMC0wNjowMA0KQXVzdHJhbGlhbiBFYXN0ZXJu IFN0YW5kYXJkIFRpbWUgICAgICAgMDc6MDAtMDk6MDANCuGQpw0K --_000_DM6PR00MB06828533979EECA9F27B01B5F5F40DM6PR00MB0682namp_ 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 MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIw NjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QWN0dWFsbHks IGl04oCZcyBmaXZlLiZuYnNwOyBJIG1pc3NlZCBzZWVpbmcgRmlsaXDigJlzIGNvbW1lbnRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1p a2UgSm9uZXMgPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxOSwgMjAyMCAxMTow MCBBTTxicj4NCjxiPlRvOjwvYj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hh bm5hPTQwYW1hem9uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IERpY2sgSGFyZHQgJmx0O2RpY2su aGFyZHRAZ21haWwuY29tJmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBZYXJv biBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbVHhhdXRoXSBUeEF1dGggQm9GIGRyYWZ0IGFnZW5kYTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkdpdmVu IHRoYXQgZm91ciBwZW9wbGUgaGF2ZSByYWlzZWQgcXVlc3Rpb25zIGFib3V0IHRoZSBpZGVudGl0 eSBhc3BlY3Qgb2YgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIsIEkgd291bGQgcmVxdWVzdCB0aGF0IHRo ZSBjaGFpcnMgYWxsb2NhdGUgYXQgbGVhc3QgMjAgbWludXRlcyB0byBkaXNjdXNzaW9uIG9mIHdo ZXRoZXIgaWRlbnRpdHkgc2hvdWxkIGJlIGluIG9yIG91dA0KIG9mIHNjb3BlLCBhbmQgaWYgaW4g c2NvcGUsIHdoYXQgYXNwZWN0cyBvZiBpZGVudGl0eSBzaG91bGQgYmUgaW4gYW5kIG91dCBvZiBz Y29wZS4mbmJzcDsgVGhpcyBzaG91bGQgaGF2ZSBpdHMgb3duIHRpbWUgc2xvdCwgcmF0aGVyIHRo YW4gaW5jbHVkaW5nIGl0IGluIHRoZSAyMCBtaW51dGVzIG9mIGNoYXJ0ZXIgYW5kIG5hbWluZyBk aXNjdXNzaW9ucyBjdXJyZW50bHkgYWxsb2NhdGVkLCBhcyBpdOKAmXMgYSBmb3VuZGF0aW9uYWwg ZGVjaXNpb24gdG8gc2NvcGluZw0KIHRoZSB3b3JrLCBhbmQgaXMgbGlrZWx5IHRvIG5lZWQgYXQg bGVhc3QgMjAgbWludXRlcyBvbiBpdHMgb3duLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+VG9yc3RlbuKAmXMgYW5kIFZsYWRpbWly4oCZcyBmZWVkYmFjayBhYm91dCBpbnRl cm9wZXJhYmlsaXR5IGFtb25nIGF1dGhvcml6YXRpb24gc2VydmVycyBhbmQgcmVzb3VyY2Ugc2Vy dmVycyBzaG91bGQgYWxzbyBiZSBleHBsaWNpdGx5IGluY2x1ZGVkIHNvbWV3aGVyZSBpbiB0aGUg Y2hhcnRlciBkaXNjdXNzaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PklmIHdl4oCZcmUgc2hvcnQgb24gdGltZSwgSeKAmWQgcmF0aGVyIHdlIGZpcnN0IGdldCBhZ3Jl ZW1lbnQgb24gdGhlIGNoYXJ0ZXIgYW5kIHNjb3BlIHRoYW4gZGlzY3VzcyB0aGUgZW5naW5lZXJp bmcgbWVyaXRzIGFuZCB0cmFkZW9mZnMgYW1vbmcgcGFydGljdWxhciBwcm9wb3NlZCBzdGFydGlu ZyBwb2ludCBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4 YXV0aC1ib3VuY2VzQGlldGYub3JnIj50eGF1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxOSwgMjAyMCA4OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBE aWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPmRpY2su aGFyZHRAZ21haWwuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3Jn Ij50eGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiBZYXJvbiBTaGVmZmVyICZsdDs8 YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj55YXJvbmYuaWV0ZkBnbWFpbC5j b208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbVHhhdXRoXSBU eEF1dGggQm9GIGRyYWZ0IGFnZW5kYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBleHBlY3QgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBhcm91bmQgd2hldGhlci90byB3aGF0 IGV4dGVudCBpdCBzaG91bGQgaW5jbHVkZSDigJxpZGVudGl0eeKAnSBhbmQgd2l0aG91dCBzb21l IHN0cnVjdHVyZSB0aGF0IGNvdWxkIGVhc2lseSBjb25zdW1lIHRoZSB3aG9sZSBtZWV0aW5nLiBT aG91bGQgd2UgdGltZWJveCB0aGF0IGRpc2N1c3Npb24sIGFuZC9vciBnZXQgc29tZSB2b2x1bnRl ZXJzIHRvIHN1bW1hcml6ZSB0aGUNCiB2YXJpb3VzIHBvc2l0aW9ucz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igJM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+QW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PkFXUyBJZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczovL2F3cy5hbWF6 b24uY29tL2lkZW50aXR5LyI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS88L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+VHhhdXRoICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmciPnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIERpY2sg SGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJk dEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDE2LCAy MDIwIGF0IDQ6MDcgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzp0eGF1 dGhAaWV0Zi5vcmciPnR4YXV0aEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzp0eGF1dGhAaWV0Zi5vcmciPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj5ZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t Ij55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bRVhU RVJOQUxdW1R4YXV0aF0gVHhBdXRoIEJvRiBkcmFmdCBhZ2VuZGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlZpcnR1YWwgTWVldGlu ZzombmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk1vbmRheSwg TWFyY2ggMjM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yMDowMCAtIDIyOjAwIFVUQyAqIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj5BZ2VuZGE8L2I+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkNoYWlyIHNsaWRlcywgYWdlbmRhIGJhc2hpbmcgLSAxMCBtaW4uPGJyPg0KQ2hhcnRlciAobGlu aywgc29saWNpdCBjb21tZW50cywgZGlzY3VzcyBXRyBuYW1lKSAtIDIwIG1pbi48YnI+DQpYWVog LSBKdXN0aW4gKHdpdGggUSZhbXA7QSkgLSAyMCBtaW4uPGJyPg0KWEF1dGggLSBEaWNrJm5ic3A7 ICh3aXRoIFEmYW1wO0EpIC0gMjAgbWluLjxicj4NCllhcm9uICwgRGljaywgSnVzdGluIC0gRGlz Y3Vzc2lvbiBvZiBkaWZmZXJlbmNlcyBiZXR3ZWVuIHByb3RvY29scyAtIDQwIG1pbi48YnI+DQpO ZXh0IHN0ZXBzIC0gMTAgbWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BZGRpdGlvbnMgLyBzdWdnZXN0aW9ucz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj5UZWNoPC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPlRoZSB0ZWNobm9sb2d5IHRvIGJlIHVzZWQgaXMgc3RpbGwgVEJELiBX ZSB3aWxsIHVwZGF0ZSB0aGUgbGlzdCB3aGVuIHdlIGtub3cuIFdlIGFyZSBleHBlY3RpbmcgaXQg d2lsbCBiZSB0aGUgSUVURiBXZWJFeC4gKG15IHByZWZlcmVuY2Ugd291bGQgYmUgWm9vbSBpZiBh bnlvbmUgaGFzIGFuIGFjY291bnQgdG8gaGF2ZSBMT1RTIG9mIHBlb3BsZSBvbiBpdCA9KTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldlIGFyZSBwbGFubmlu ZyBvbiB1c2luZyBFdGhlclBhZCBmb3Igbm90ZXMsIGFuZCBmb3IgcXVldWUgbWFuYWdlbWVudC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj5TY3JpYmU8 L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+V291bGQgc29tZW9uZSBsaWtlIHRvIHZvbHVudGVlciB0 byBiZSB0aGUgc2NyaWJlIG9uIEV0aGVyUGFkPyBXZSB3b3VsZCBsaWtlIHRvIGdldCBhcyBtdWNo IGNvb3JkaW5hdGlvbiBkb25lIHByaW9yIGFzIHBvc3NpYmxlIHRvIG1ha2UgdGhlIGJlc3QgdXNl IG9mIHRoZSB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ KiBTb21lIHRpbWUgbWF0aCBmb3IgMjA6MDAgLSAyMjowMCBVVEM6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+UGFjaWZpYyBUaW1lJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTM6 MDAtMTU6MDA8YnI+DQpFYXN0ZXJuIFRpbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MTY6MDAtMTg6MDA8YnI+DQpDb29yZGluYXRlZCBVbml2 ZXJzYWwgVGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyMDowMC0wMjowMDxicj4NCkNl bnRyYWwgRXVyb3BlYW4gVGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjE6 MDAtMjM6MDA8YnI+DQpJbmRpYSBTdGFuZGFyZCBUaW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgMDE6MzAtMDM6MzA8YnI+DQpDaGluYSBTdGFuZGFyZCBUaW1lJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwNDowMC0wNjowMDxicj4NCkF1c3RyYWxp YW4gRWFzdGVybiBTdGFuZGFyZCBUaW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDc6MDAt MDk6MDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0i MSIgaGVpZ2h0PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94 MDAwMF9pMTAyNSIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9 YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMD0mYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1 aWQ9NzdhMTBiMDctNDY2Mi00M2E0LTljY2QtOGRmYWQ5YzNiOTg3Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB06828533979EECA9F27B01B5F5F40DM6PR00MB0682namp_-- From nobody Thu Mar 19 12:11:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2792A3A0D8A for ; Thu, 19 Mar 2020 12:11:55 -0700 (PDT) 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, 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 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 CEHXeygNDWhs for ; Thu, 19 Mar 2020 12:11:53 -0700 (PDT) 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 3441E3A0D89 for ; Thu, 19 Mar 2020 12:11:53 -0700 (PDT) Received: from [192.168.1.5] (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 02JJBm8c031999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 15:11:49 -0400 From: Justin Richer Message-Id: <30E029DE-4083-4B65-A97B-EE4F5BF4B7E2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_45A47FD3-78EF-4593-8DAD-8C9A48E4A520" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Mar 2020 15:11:48 -0400 In-Reply-To: Cc: "Richard Backman, Annabelle" , Dick Hardt , "txauth@ietf.org" , Yaron Sheffer To: Mike Jones References: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 19:11:55 -0000 --Apple-Mail=_45A47FD3-78EF-4593-8DAD-8C9A48E4A520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to adding both of these discussions to the agenda. =E2=80=94 Justin > On Mar 19, 2020, at 2:00 PM, Mike Jones = wrote: >=20 > Given that four people have raised questions about the identity aspect = of the proposed charter, I would request that the chairs allocate at = least 20 minutes to discussion of whether identity should be in or out = of scope, and if in scope, what aspects of identity should be in and out = of scope. This should have its own time slot, rather than including it = in the 20 minutes of charter and naming discussions currently allocated, = as it=E2=80=99s a foundational decision to scoping the work, and is = likely to need at least 20 minutes on its own. > =20 > Torsten=E2=80=99s and Vladimir=E2=80=99s feedback about = interoperability among authorization servers and resource servers should = also be explicitly included somewhere in the charter discussions. > =20 > If we=E2=80=99re short on time, I=E2=80=99d rather we first get = agreement on the charter and scope than discuss the engineering merits = and tradeoffs among particular proposed starting point drafts. > =20 > Thanks, > -- Mike > =20 > From: Txauth > On Behalf Of Richard Backman, = Annabelle > Sent: Thursday, March 19, 2020 8:28 AM > To: Dick Hardt >; = txauth@ietf.org > Cc: Yaron Sheffer > > Subject: [EXTERNAL] Re: [Txauth] TxAuth BoF draft agenda > =20 > I expect a lot of discussion around whether/to what extent it should = include =E2=80=9Cidentity=E2=80=9D and without some structure that could = easily consume the whole meeting. Should we timebox that discussion, = and/or get some volunteers to summarize the various positions? > =20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth > on behalf of Dick Hardt = > > Date: Monday, March 16, 2020 at 4:07 PM > To: "txauth@ietf.org " > > Cc: Yaron Sheffer > > Subject: [EXTERNAL][Txauth] TxAuth BoF draft agenda > =20 > Virtual Meeting: =20 > =20 > Monday, March 23 > 20:00 - 22:00 UTC *=20 > =20 > Agenda > Chair slides, agenda bashing - 10 min. > Charter (link, solicit comments, discuss WG name) - 20 min. > XYZ - Justin (with Q&A) - 20 min. > XAuth - Dick (with Q&A) - 20 min. > Yaron , Dick, Justin - Discussion of differences between protocols - = 40 min. > Next steps - 10 min. > =20 > Additions / suggestions? > =20 > Tech > The technology to be used is still TBD. We will update the list when = we know. We are expecting it will be the IETF WebEx. (my preference = would be Zoom if anyone has an account to have LOTS of people on it =3D) > =20 > We are planning on using EtherPad for notes, and for queue management. > =20 > Scribe > Would someone like to volunteer to be the scribe on EtherPad? We would = like to get as much coordination done prior as possible to make the best = use of the time. > =20 > /Dick > =20 > * Some time math for 20:00 - 22:00 UTC: > =20 > Pacific Time 13:00-15:00 > Eastern Time 16:00-18:00 > Coordinated Universal Time 20:00-02:00 > Central European Time 21:00-23:00 > India Standard Time 01:30-03:30 > China Standard Time 04:00-06:00 > Australian Eastern Standard Time 07:00-09:00 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_45A47FD3-78EF-4593-8DAD-8C9A48E4A520 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = to adding both of these discussions to the agenda.

 =E2=80=94 Justin

On Mar 19, 2020, at 2:00 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

Given that four people have = raised questions about the identity aspect of the proposed charter, I = would request that the chairs allocate at least 20 minutes to discussion = of whether identity should be in or out of scope, and if in scope, what = aspects of identity should be in and out of scope.  This should = have its own time slot, rather than including it in the 20 minutes of = charter and naming discussions currently allocated, as it=E2=80=99s a = foundational decision to scoping the work, and is likely to need at = least 20 minutes on its own.
 
Torsten=E2=80= =99s and Vladimir=E2=80=99s feedback about interoperability among = authorization servers and resource servers should also be explicitly = included somewhere in the charter discussions.
 
If we=E2=80=99= re short on time, I=E2=80=99d rather we first get agreement on the = charter and scope than discuss the engineering merits and tradeoffs = among particular proposed starting point drafts.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Thanks,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Richard = Backman, Annabelle
Sent: Thursday, March 19, 2020 = 8:28 AM
To: Dick Hardt <dick.hardt@gmail.com>; txauth@ietf.org
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>
Subject: [EXTERNAL] Re: [Txauth] = TxAuth BoF draft agenda
 
I expect a lot of discussion around = whether/to what extent it should include =E2=80=9Cidentity=E2=80=9D and = without some structure that could easily consume the whole meeting. = Should we timebox that discussion, and/or get some volunteers to = summarize the various positions?
 
=E2=80=93
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/
 
 
From: Txauth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Monday, March 16, 2020 = at 4:07 PM
To: "txauth@ietf.org" <txauth@ietf.org>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>
Subject: [EXTERNAL][Txauth] = TxAuth BoF draft agenda
 
Virtual Meeting:  
 
Monday, March 23
20:00 - 22:00 UTC * 
 
Agenda
Chair slides, agenda bashing - 10 min.
Charter = (link, solicit comments, discuss WG name) - 20 min.
XYZ - = Justin (with Q&A) - 20 min.
XAuth - Dick  (with = Q&A) - 20 min.
Yaron , Dick, Justin - Discussion of = differences between protocols - 40 min.
Next steps - 10 = min.
 
Additions / suggestions?
 
Tech
The technology to be used is still TBD. We will update the = list when we know. We are expecting it will be the IETF WebEx. (my = preference would be Zoom if anyone has an account to have LOTS of people = on it =3D)
 
We are planning on using EtherPad for notes, and = for queue management.
 
Scribe
Would someone like to volunteer to be the scribe on EtherPad? = We would like to get as much coordination done prior as possible to make = the best use of the time.
 
/Dick
 
* Some time math for 20:00 - 22:00 UTC:
 
Pacific Time        =            13:00-15:00
Eastern= Time              =  16:00-18:00
Coordinated Universal Time    =     20:00-02:00
Central European Time  =         21:00-23:00
India Standard = Time            01:30-03:30
China Standard Time          = 04:00-06:00
Australian Eastern Standard Time    =    07:00-09:00
=E1=90=A7
-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_45A47FD3-78EF-4593-8DAD-8C9A48E4A520-- From nobody Thu Mar 19 13:07:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259F3A0E7C for ; Thu, 19 Mar 2020 13:07:31 -0700 (PDT) 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=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 19ud7J0LSXl3 for ; Thu, 19 Mar 2020 13:07:25 -0700 (PDT) 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 6D6423A0E6C for ; Thu, 19 Mar 2020 13:07:25 -0700 (PDT) Received: from [192.168.1.5] (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 02JK7DOu020024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 16:07:14 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> Date: Thu, 19 Mar 2020 16:07:13 -0400 Cc: txauth@ietf.org, Vladimir Dzhuvinov Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 20:07:31 -0000 I think this is already in scope in the ways that I=E2=80=99ve = described, with the caveat that identifying "the RS" is really, really = hard to do. What if instead it=E2=80=99s: - Support for directed, audience-restricted access tokens in multi-RS = deployments Would that work? To me the difference is that it=E2=80=99s getting away = from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more towards = the notion of getting a token directed to a specific set of actions = and/or locations. =E2=80=94 Justin > On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: >=20 > Hi all, >=20 > I suggest to add the following requirement to the charter: > =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >=20 > I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I = want to make sure we try to build a protocol that serves the needs of a = broad set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 >=20 > And here is my explanation:=20 >=20 > OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 >=20 > And there are even more examples today for multi API environments that = would benefit from that feature:=20 > =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! > =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. > =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. >=20 > Since we are preparing to define a completely new protocol for API = access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get = it right and simple, but if we just stick to the =E2=80=9Ca single = access token is enough=E2=80=9D mantra, we miss the chance to give = implementers a broader range of design choices out of the box and we = won=E2=80=99t success in achieving true interoperability. >=20 > Here are more advantages we can gain by supporting such a feature:=20 > =E2=80=A2 Privacy: > =E2=80=A2 A single access token can be used to track = user across services. > =E2=80=A2 RS-specific access tokens cannot. > =E2=80=A2 RS-specific access tokens can also be = encrypted to protect data confidentiality in transit. > =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. > =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >=20 > What do you think? >=20 > best regards, > Torsten.=20 >=20 >> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>=20 >>=20 >> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>> On 19. Mar 2020, at 17:47, Justin Richer wrote: >>>> Well, it=E2=80=99s in scope as much as describing any other aspect = of what the token is for and what it represents is in scope. That is = alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>=20 >>>> But here=E2=80=99s the thing: none of that has an impact on the = core protocol. That is entirely up to the AS and the RS to agree on, and = the client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. >>>>=20 >>>> This does raise the question of what our bar of interoperability is = going to be with TxAuth: do we expect independent AS and RS = implementations to talk to each other? That=E2=80=99s not something = OAuth 2 was ever concerned with, though obviously JWT and introspection = are both from the OAuth2 WG and solve that problem. >>> There are two aspects to it: interoperability and vendor support.=20 >>>=20 >>> Interoperability between AS and RS is important if deployments want = to combine pre-packaged TXAuth and API implementations. I think that = makes a lot of sense and should be included in the charter. >>=20 >> +1 >>=20 >> The current OAuth 2.0 status quo of the largely unspecified = relationship >> between AS and RS is also making the life of web & sec framework >> maintainers difficult. We witnessing this with people integrating the >> OAuth SDK into frameworks. Vittorio's recent work to put together a >> minimal interoperable JWT profile for access tokens is helpful, but = it >> has come after the fact. And there is not agreement on things like >> authorising access to claims. >>=20 >> Integrating apps (RSs) with TxAuth should be straightforward and = simple. >>=20 >> This can have a enormous effect on adoption. >>=20 >>=20 >>> Vendors support: vendor support when it comes to "what can go into = an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>=20 >> +1 >>=20 >>=20 >>> I also think it is a good exercise for the group to think the whole = process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not = to provide clients with access tokens. The purpose is to enable API = request processing in a secure manner. What it really takes to achieve = that goal is not obvious if the work always stops at the =E2=80=9Cyou = have your access token, good luck=E2=80=9D stage.=20 >>=20 >> +1 >>=20 >> Vladimir >>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Mar 19 13:41:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023383A0F16 for ; Thu, 19 Mar 2020 13:41:13 -0700 (PDT) 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, MIME_QP_LONG_LINE=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=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 zhs73YYQz-6j for ; Thu, 19 Mar 2020 13:41:08 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450: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 9F0D63A0F14 for ; Thu, 19 Mar 2020 13:41:07 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id f3so4894067wrw.7 for ; Thu, 19 Mar 2020 13:41:07 -0700 (PDT) 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=3htf08HEW2A2znyQpEZ1phNaxtKMNiSdWaZDS+XlQCI=; b=nnVnAxkHoFvtlWC9fFVLcTVFW7GJt8COs6XluG33pMWrBKSdZsKF8r++QkusqlDM3v NYztICUKQQXGIOmaWbHDOWvpRrBa3B+iec2zTnjDqfRqOYUOmdL2Ui2hJWDP6DzEBAQk SV2+WmuAsXv+7QOPDdU/xgTRl8gF0em0wkXPY90kU40kJ5dgpwqrEigmZetb5X5eDW5q kz3BPpyCvmhKpVF5JH4QuRjWZt01MBXX+mGlCgZ4IJaRqBX/0hocziT+NxDp8axpeNxJ hbPx7ASRnIGxrO9uKCLzNkXA4ekAzmckap6iCy28e5evNdOsn8cnPDK7nR9MDwiQiLmI H77A== 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=3htf08HEW2A2znyQpEZ1phNaxtKMNiSdWaZDS+XlQCI=; b=Dw1nsGeCsYoyzSyZzve0+N9vdZExUNWpBW8Ju4qJMIamxg8cRNFMy+xYksAjngK6im 9aDUZZmnTL8G/JND+QhAJoLjZd5epUOVENPz/Lije8Kr+XO+pbVqu0BG4gw6AKW2m7Z3 Fux5YqR0ur/ws6+/4JwgpoDTDZDe2s+EYF+PZN4mCDvKElKySHeUdvoxASfRehhHyXO3 djXQdJcnuboFQe2gOjh63JO+8irdr8aXtVBLhSrLCZd00elW2rBfxycw9pI5YyNBEIo3 uokMacF8qFxRi7b7PBtXCDnlJk4nfLrxKcAF9SAtWqJ8d4wh7UurEe3JQI8DskRaErq6 B6+Q== X-Gm-Message-State: ANhLgQ3ZS06LqM3JiwS5xRL1ssrM0hq2hIPkSFLrEJjcZYhIpYfAZZwb FQ6h0B3zsJD4EQzmK29hvMm39A== X-Google-Smtp-Source: ADFU+vsm1CpKsK1Law3Sf4RqM2XoW6+hxjeYIkoNtLlVe0LLY46LjeddO46up5vm+zm8HQAZpYUrZQ== X-Received: by 2002:a5d:464e:: with SMTP id j14mr6485900wrs.339.1584650465646; Thu, 19 Mar 2020 13:41:05 -0700 (PDT) Received: from [192.168.71.106] (p549EE22B.dip0.t-ipconnect.de. [84.158.226.43]) by smtp.gmail.com with ESMTPSA id q11sm5039989wrp.53.2020.03.19.13.41.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Mar 2020 13:41:04 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-34DC094A-20ED-40F5-AF96-DB13D5A6EE57; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Thu, 19 Mar 2020 21:41:02 +0100 Message-Id: References: Cc: Torsten Lodderstedt , txauth@ietf.org, Vladimir Dzhuvinov In-Reply-To: To: Justin Richer X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 20:41:13 -0000 --Apple-Mail-34DC094A-20ED-40F5-AF96-DB13D5A6EE57 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 19.03.2020 um 21:07 schrieb Justin Richer : >=20 > =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99ve de= scribed, Given our recent discussion, I don=E2=80=99t see how it is already in scope=20= > with the caveat that identifying "the RS" is really, really hard to do. I don=E2=80=99t think it=E2=80=99s difficult to use URLs to identify at leas= t =E2=80=9Edestinations=E2=80=9C, it works for cookies as well.=20 > What if instead it=E2=80=99s: >=20 > - Support for directed, audience-restricted access tokens in multi-RS depl= oyments >=20 > Would that work? To me the difference is that it=E2=80=99s getting away fr= om a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more towards the no= tion of getting a token directed to a specific set of actions and/or locatio= ns. wfm, as long it is clear the AS/RS determines the boundaries. best regards, Torsten. >=20 > =E2=80=94 Justin >=20 >> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt wrote: >>=20 >> Hi all, >>=20 >> I suggest to add the following requirement to the charter: >> =E2=80=A2 Support for RS-specific access tokens in Multi-RS deployment= s=20 >>=20 >> I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I want t= o make sure we try to build a protocol that serves the needs of a broad set o= f deployments. My concern is otherwise TXAuth will be not innovative enough t= o gain traction in the market rapidly. Speaking for myself, I realised in th= e last couple of days, mostly in conversations with Justin, that the result o= f this working group as envisioned now is not of particular interest to us (= yes.com) because it does not solve our real problems.=20 >>=20 >> And here is my explanation:=20 >>=20 >> OAuth traditionally has the philosophy of a single access token. That=E2=80= =99s fine for single service deployments, but it had reached its limits alre= ady before RFC6749 was published. There are a real implementations out there= forcing clients to use different access tokens for different services, typi= cally for privacy and security reasons. There is also an =E2=80=9Cancient" t= echnology called Kerberos that uses exactly this pattern and is well known f= or security, performance, and scalability.=20 >>=20 >> And there are even more examples today for multi API environments that wo= uld benefit from that feature:=20 >> =E2=80=A2 Open banking: most banks I worked with have multiple APIs, s= egregation between APIs is today achieved by maintaining different grants, b= asically resulting in the fact that the users cannot consent to different se= rvices at once. What a terrible UX! >> =E2=80=A2 Everyone is doing micro services today. Have you every thoug= ht about the coupling caused by a single token across micro services? This r= eminds me of how easy it is to test services independently using self-contai= ned RS-specific tokens. >> =E2=80=A2 IoT - every device in a household is a potential RS (in my o= pinion). Conveying all necessary data in an access token needed to meet acce= ss control decisions locally would be a huge benefit in terms of performance= and decoupling. Using symmetric cryptography for token integrity, authentic= ity and confidentiality would result in lower compute requirements. >>=20 >> Since we are preparing to define a completely new protocol for API access= authorization and delegation, I think this new protocol should support this= kind of scenarios. It will require significant work to get it right and sim= ple, but if we just stick to the =E2=80=9Ca single access token is enough=E2= =80=9D mantra, we miss the chance to give implementers a broader range of de= sign choices out of the box and we won=E2=80=99t success in achieving true i= nteroperability. >>=20 >> Here are more advantages we can gain by supporting such a feature:=20 >> =E2=80=A2 Privacy: >> =E2=80=A2 A single access token can be used to track user across s= ervices. >> =E2=80=A2 RS-specific access tokens cannot. >> =E2=80=A2 RS-specific access tokens can also be encrypted to prote= ct data confidentiality in transit. >> =E2=80=A2 Security: RS-specific access tokens have a baseline replay d= etection. >> =E2=80=A2 Performance: RS-specific access tokens allow the AS to conve= y all data required to authorize an API call in a token (e.g. a JWT) and to R= S to meet the access control decision based on that data. This is a huge adv= antage in terms of performance, scalability and cost since there is no need f= or Token Introspection or other kinds of access to another services or datab= ase. >>=20 >> What do you think? >>=20 >> best regards, >> Torsten.=20 >>=20 >>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>>=20 >>>=20 >>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>>> On 19. Mar 2020, at 17:47, Justin Richer wrote: >>>>> Well, it=E2=80=99s in scope as much as describing any other aspect of w= hat the token is for and what it represents is in scope. That is alongside t= hings like the intended audience of the token, the access rights for the tok= en, the presentation keys the token is bound to, etc. It could be informatio= n in the token text itself (like a JWT), it could be introspected from the A= S, it could be referenced in some other way. So if we can define identity as= pects in that, then we=E2=80=99re fine in covering it there.=20 >>>>>=20 >>>>> But here=E2=80=99s the thing: none of that has an impact on the core p= rotocol. That is entirely up to the AS and the RS to agree on, and the clien= t never sees or has any influence on it. That portion of the protocol is com= pletely opaque to the client. Therefore, it doesn=E2=80=99t really affect th= e authorization and delegation portions of the client talking to the AS and t= he client talking to the RS. >>>>>=20 >>>>> This does raise the question of what our bar of interoperability is go= ing to be with TxAuth: do we expect independent AS and RS implementations to= talk to each other? That=E2=80=99s not something OAuth 2 was ever concerned= with, though obviously JWT and introspection are both from the OAuth2 WG an= d solve that problem. >>>> There are two aspects to it: interoperability and vendor support.=20 >>>>=20 >>>> Interoperability between AS and RS is important if deployments want to c= ombine pre-packaged TXAuth and API implementations. I think that makes a lot= of sense and should be included in the charter. >>>=20 >>> +1 >>>=20 >>> The current OAuth 2.0 status quo of the largely unspecified relationship= >>> between AS and RS is also making the life of web & sec framework >>> maintainers difficult. We witnessing this with people integrating the >>> OAuth SDK into frameworks. Vittorio's recent work to put together a >>> minimal interoperable JWT profile for access tokens is helpful, but it >>> has come after the fact. And there is not agreement on things like >>> authorising access to claims. >>>=20 >>> Integrating apps (RSs) with TxAuth should be straightforward and simple.= >>>=20 >>> This can have a enormous effect on adoption. >>>=20 >>>=20 >>>> Vendors support: vendor support when it comes to "what can go into an a= ccess token" and "what can be conveyed in a token introspection response=E2=80= =9D greatly deviates in my observation. This also means implementation use v= endors specific features restricting their ability to use other solutions. T= XAuth should aim at improving the situation. =20 >>>=20 >>> +1 >>>=20 >>>=20 >>>> I also think it is a good exercise for the group to think the whole pro= cess "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not to pro= vide clients with access tokens. The purpose is to enable API request proces= sing in a secure manner. What it really takes to achieve that goal is not ob= vious if the work always stops at the =E2=80=9Cyou have your access token, g= ood luck=E2=80=9D stage.=20 >>>=20 >>> +1 >>>=20 >>> Vladimir >>>=20 >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-34DC094A-20ED-40F5-AF96-DB13D5A6EE57 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzE5MjA0MTAyWjAvBgkqhkiG9w0BCQQxIgQg ihltLMWDEhd2/rYHKn+gLHGejVEcZQHtjhca63WKRt8wgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAGiggvqF40Y0nOcgHV4rvV85ApfBKw+7mvUkutPLR2QwYnm9eYCrF NgRaZizc+fAHTASsfR2+Ylrt3R/RQmvZjQj0YP55YZlFQIijHkfFEvAjlRgU7/wfGDJfnszlB9AU Ekv59j9lVEhnzOrqrUxrDkC9BcjwtLbHTS0JqZMva6YU+FIuZDAYIJJDBoe8fqkv2oTr88pQfEqM euCl71ZG0gZHqMHqV8llvIdPIsivY/WKS8aqo3M4q2Wp1zRoisX9hNplim9PDTD5nCxq4FrRuwlR +aXk7KChfRbgO1x38XL/wuU1qj9MMfkxd/ckE+ODOcEATL+9CH0C/umxb6CNXQAAAAAAAA== --Apple-Mail-34DC094A-20ED-40F5-AF96-DB13D5A6EE57-- From nobody Thu Mar 19 13:48:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBBA3A0F34 for ; Thu, 19 Mar 2020 13:48:00 -0700 (PDT) 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=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 BHE0D2oJyolZ for ; Thu, 19 Mar 2020 13:47:56 -0700 (PDT) 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 C523C3A0F36 for ; Thu, 19 Mar 2020 13:47:55 -0700 (PDT) Received: from [192.168.1.5] (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 02JKlnDk002137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 16:47:50 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Thu, 19 Mar 2020 16:47:49 -0400 Cc: Torsten Lodderstedt , txauth@ietf.org, Vladimir Dzhuvinov Content-Transfer-Encoding: quoted-printable Message-Id: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> References: To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 20:48:01 -0000 On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = wrote: >=20 >> Am 19.03.2020 um 21:07 schrieb Justin Richer : >>=20 >> =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99ve= described, >=20 > Given our recent discussion, I don=E2=80=99t see how it is already in = scope=20 What I mean is that a client can already ask for separate tokens and use = the =E2=80=9Cresources=E2=80=9D block to describe which resource servers = it wants. However, right now, it=E2=80=99s up to the client to determine = what the split is =E2=80=94 either by asking for separate tokens in = either the single-token format (with multiple requests) or multi-token = format (with a single request).=20 >=20 >> with the caveat that identifying "the RS" is really, really hard to = do. >=20 > I don=E2=80=99t think it=E2=80=99s difficult to use URLs to identify = at least =E2=80=9Edestinations=E2=80=9C, it works for cookies as well.=20= I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99m = trying to push back against optimizing for that one kind of identity. = And cookies have all kinds of rules for paths and domains and origins = that protect them, so if that=E2=80=99s the model we=E2=80=99re arguing = for we need to at least consider all of that. We also need to consider = that cookies fail in a lot of ways! :) >=20 >> What if instead it=E2=80=99s: >>=20 >> - Support for directed, audience-restricted access tokens in multi-RS = deployments >>=20 >> Would that work? To me the difference is that it=E2=80=99s getting = away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more = towards the notion of getting a token directed to a specific set of = actions and/or locations. >=20 > wfm, as long it is clear the AS/RS determines the boundaries. Ultimately they always do, and they=E2=80=99ll always need to deal with = the situation where a client asks for rights that cross boundaries. The = question is what to do in those situations, and I think there=E2=80=99s = a lot more discussion we need to have on that front! Do we allow the AS = to split a token request, do we have errors for this, do we have a = client indicate that it can receive split tokens =E2=80=A6 etc. I think = it=E2=80=99s an interesting area, but complex and not nearly as = clean-cut as your own use case and deployment might let it be. =E2=80=94 Justin >=20 > best regards, > Torsten. >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: >>>=20 >>> Hi all, >>>=20 >>> I suggest to add the following requirement to the charter: >>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >>>=20 >>> I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I = want to make sure we try to build a protocol that serves the needs of a = broad set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 >>>=20 >>> And here is my explanation:=20 >>>=20 >>> OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 >>>=20 >>> And there are even more examples today for multi API environments = that would benefit from that feature:=20 >>> =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! >>> =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. >>> =E2=80=A2 IoT - every device in a household is a potential RS (in = my opinion). Conveying all necessary data in an access token needed to = meet access control decisions locally would be a huge benefit in terms = of performance and decoupling. Using symmetric cryptography for token = integrity, authenticity and confidentiality would result in lower = compute requirements. >>>=20 >>> Since we are preparing to define a completely new protocol for API = access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get = it right and simple, but if we just stick to the =E2=80=9Ca single = access token is enough=E2=80=9D mantra, we miss the chance to give = implementers a broader range of design choices out of the box and we = won=E2=80=99t success in achieving true interoperability. >>>=20 >>> Here are more advantages we can gain by supporting such a feature:=20= >>> =E2=80=A2 Privacy: >>> =E2=80=A2 A single access token can be used to track user = across services. >>> =E2=80=A2 RS-specific access tokens cannot. >>> =E2=80=A2 RS-specific access tokens can also be encrypted to = protect data confidentiality in transit. >>> =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. >>> =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >>>=20 >>> What do you think? >>>=20 >>> best regards, >>> Torsten.=20 >>>=20 >>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>>>=20 >>>>=20 >>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>>>> On 19. Mar 2020, at 17:47, Justin Richer wrote: >>>>>> Well, it=E2=80=99s in scope as much as describing any other = aspect of what the token is for and what it represents is in scope. That = is alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>>>=20 >>>>>> But here=E2=80=99s the thing: none of that has an impact on the = core protocol. That is entirely up to the AS and the RS to agree on, and = the client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. >>>>>>=20 >>>>>> This does raise the question of what our bar of interoperability = is going to be with TxAuth: do we expect independent AS and RS = implementations to talk to each other? That=E2=80=99s not something = OAuth 2 was ever concerned with, though obviously JWT and introspection = are both from the OAuth2 WG and solve that problem. >>>>> There are two aspects to it: interoperability and vendor support.=20= >>>>>=20 >>>>> Interoperability between AS and RS is important if deployments = want to combine pre-packaged TXAuth and API implementations. I think = that makes a lot of sense and should be included in the charter. >>>>=20 >>>> +1 >>>>=20 >>>> The current OAuth 2.0 status quo of the largely unspecified = relationship >>>> between AS and RS is also making the life of web & sec framework >>>> maintainers difficult. We witnessing this with people integrating = the >>>> OAuth SDK into frameworks. Vittorio's recent work to put together a >>>> minimal interoperable JWT profile for access tokens is helpful, but = it >>>> has come after the fact. And there is not agreement on things like >>>> authorising access to claims. >>>>=20 >>>> Integrating apps (RSs) with TxAuth should be straightforward and = simple. >>>>=20 >>>> This can have a enormous effect on adoption. >>>>=20 >>>>=20 >>>>> Vendors support: vendor support when it comes to "what can go into = an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>>>=20 >>>> +1 >>>>=20 >>>>=20 >>>>> I also think it is a good exercise for the group to think the = whole process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) = is not to provide clients with access tokens. The purpose is to enable = API request processing in a secure manner. What it really takes to = achieve that goal is not obvious if the work always stops at the =E2=80=9C= you have your access token, good luck=E2=80=9D stage.=20 >>>>=20 >>>> +1 >>>>=20 >>>> Vladimir >>>>=20 >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Mar 19 15:22:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C73A10EC for ; Thu, 19 Mar 2020 15:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, 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=mattr-global.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 HIg8OWhs65B8 for ; Thu, 19 Mar 2020 15:22:54 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 119023A1090 for ; Thu, 19 Mar 2020 15:22:52 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id z13so1990563qvw.3 for ; Thu, 19 Mar 2020 15:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=kuldQM7/qt9bQc2KfeH2/Fnw4BRlyMSU0/4NCrcyUC4=; b=dLYgx2CNxON++b88K+KVUKSK5sVWpABFj308p4Ew9PUF8XPeFiAylgUmeAZ78cdD1p vdeUSojt+73GsC6scFxdyrXcqCpnlboFWxv/OzwjAv0w2pmcXzJ8QE3LxLHHGq088y8W 9V4mdeoo9t15p+mUSbiZFxCFZfdxN7A9dIhDUgeADJK84JNV+dupvtiEG9yMf2ksUbyH IAzJUQ1mxMft4ZFU+r4zfcvRs3Qktcscz+UHqqfoDcJvjn/RUHVhap5uVVyRHjEm9uGO uPPxjSYEjgAA54Jhder/KgCrdiK4KEgTVl6Wll4JRYWYKCcMbJB/DT3jBaMa5ssn8isF Js9w== 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=kuldQM7/qt9bQc2KfeH2/Fnw4BRlyMSU0/4NCrcyUC4=; b=O+aXPaWJPZ3p+Zz4g8KxSJz7pNe6azp5xw15nakJ1XOwrpoSCW0Nqj3OIcMTKAyHxz EttUN6yZj7rDb3Aw/NChsGIa2nUBNpV5zkZCcdRMRUnm6LOs5c9ohQzMKWxq0j2gwmTq QgW9DGCMSs6Aj5x+ntA+suhVxst6/X6/aFF7gvfwA9pMPKeu7pswaO72fg2CPbOLHrEh SWnZ8NeEX/CdNUgQ06guAsySNLnWZq4mPTFefc9zjPJ/Pu3HFhD8D9DU9dijyI9JsrNo pgkHvkzbD4bWDcwG9VuRcJ8k/lHdK0zg1A72VduSUkFVFcWqMLVAOqJJaPyTMu4fTH93 QzaA== X-Gm-Message-State: ANhLgQ1JKUjUaKU2KpFmag7pNX9BpqjEMzkSRVMTIBUHmyEdsv/bWqut 4C9/Q+6zTP5gx2liq2bbM4MDPifDY5GHNglOuasGv+sdA9rgXjhSCCBc9cACPPVMZeDSwjv/Wjk BntQyIJGSY9xx6qe3pq7DXZPMmw== X-Google-Smtp-Source: ADFU+vueB0x6VtNprzT7poGOWglwfPAjIyIajijbQ+xR429zMz4QPQKwf9hPI7vmpOEk7cXDyV4YUTfI1uWBmMFOApQ= X-Received: by 2002:a0c:9e41:: with SMTP id z1mr5300224qve.130.1584656565957; Thu, 19 Mar 2020 15:22:45 -0700 (PDT) MIME-Version: 1.0 From: Tobias Looker Date: Fri, 20 Mar 2020 11:22:35 +1300 Message-ID: To: txauth@ietf.org Content-Type: multipart/related; boundary="000000000000b5007905a13c9b21" Archived-At: Subject: [Txauth] Client bound user assertions X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 22:22:56 -0000 --000000000000b5007905a13c9b21 Content-Type: multipart/alternative; boundary="000000000000b5007705a13c9b20" --000000000000b5007705a13c9b20 Content-Type: text/plain; charset="UTF-8" Hi, I'm unsure of the best way to articulate this idea on this forum, but see my below explanation for an attempt. I'm also aware that it as a discussion topic is dependent on how "identity" fits into TxAuth in general. With OpenID connect today the format of the user assertions we get are often bound to the client (or a small audience) mainly by the issuer using the audience field in the id_token to communicate who it is for (e.g this is for client x) which gives all parties a way to determine whether they are the intended audience of the assertion. However, this does not enable a client to authenticate as the intended audience of the user assertion to other parties. If a client was instead able to authenticate as the rightful audience of a user assertion then they would be able to onward disclose the user assertion to a relying party, such that the relying party would be able to authenticate both the original issuer of the assertion and the client now presenting the assertion. See below for a simple example. Here the client obtains a user assertion from the OP or Authorization server that is suitably bound to the client in an authenticatable way. [image: Screen Shot 2020-03-12 at 10.05.15 AM.png] The relying party now makes a request to the client who is in possession of the assertion from the authorization server and the client can respond, presenting the assertion. In this flow, with regards to OIDC, the client is essentially taking a similar role to that of a self issued openid connect provider. [image: Screen Shot 2020-03-12 at 10.05.20 AM.png] How this could be realized in TxnAuth? If the client strongly authenticates at the start of an authorization transaction e.g by signing the original authorization request with either an ephemeral or static key, the resulting assertion could be bound to this key enabling the client to authenticate as the rightful audience of the assertion to other relying parties. Similar to how DPOP for access_tokens works. Why is this interesting and what use cases does it enable? Being able to obtain user assertions that can be bound to the client such that the client can onward disclose them enables new opportunities around how users can manage different sources of their identity information through a single client. This can help to eliminate things like the nascar problem and presentations to relying parties that require aggregating assertions from multiple authorization servers. Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. -- This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. --000000000000b5007705a13c9b20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'm unsure of the be= st way to articulate this idea on this forum, but see my below explanation = for an attempt. I'm also aware that it as a discussion topic is depende= nt on how "identity" fits into TxAuth in general.=C2=A0

With OpenID connect today the format of the user assertions= we get are often bound to the client (or a small audience) mainly by the i= ssuer using the audience field in the id_token to communicate who=C2=A0it i= s for (e.g this is for client x) which gives all parties a way to determine= whether they are the intended audience of the assertion. However, this doe= s not enable a client to authenticate as the intended audience of the user = assertion to other parties. If a client was instead able to authenticate as= the rightful audience of a user assertion then they would be able to onwar= d disclose the user assertion to a relying party, such that the relying par= ty would be able to authenticate both the original issuer of the assertion = and the client now presenting the assertion.

See b= elow for a simple example.

Here the client obtains= a user assertion from the OP or Authorization server that is suitably boun= d to the client in an authenticatable way.

3D"Screen

= The relying party now makes a request to the client who is in possession of= the assertion from the authorization server and the client can respond, pr= esenting the assertion.=C2=A0In this flow, with regards to OIDC, the client= is essentially taking a similar role to that of a self issued openid conne= ct provider.

3D"=
=C2=A0
How this could be realiz= ed in TxnAuth?=C2=A0

If the client strongly authen= ticates at the start of an authorization transaction e.g by signing the ori= ginal authorization request with either an ephemeral or static key, the res= ulting assertion could be bound to this key enabling the client to authenti= cate as the rightful audience of the assertion to other relying parties. Si= milar to how DPOP for access_tokens works.

Why is = this interesting and what use cases does it enable?

Being able to obtain user assertions that can be bound to the client such= that the client can onward disclose them enables new opportunities around = how users can manage different sources of their identity information throug= h a single client. This can help to eliminate things like the nascar proble= m and presentations to relying parties that require aggregating assertions = from multiple authorization servers.

Thanks,
=
<= table width=3D"auto" cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style= =3D"color:rgb(0,0,0);font-family:Times;font-size:medium;border:0px">
3D"Mattr= =C2=A0
Tobias Looker
<= /td>
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr=3D"Matt=3D"Mattr3D"Mattr

This communication, including any attachm= ents, is confidential. If you are not the intended recipient, you should no= t read it - please contact me immediately, destroy it, and do not copy or u= se any part of this communication or disclose anything about it. Thank you.= Please note that this communication does not designate an information syst= em for the purposes of the Electronic Transactions Act 2002.

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--000000000000b5007705a13c9b20-- --000000000000b5007905a13c9b21 Content-Type: image/png; name="Screen Shot 2020-03-12 at 10.05.15 AM.png" Content-Disposition: inline; filename="Screen Shot 2020-03-12 at 10.05.15 AM.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_k7ntxqmx2 iVBORw0KGgoAAAANSUhEUgAAAv4AAAG5CAYAAAD20DDwAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV lgdUk1kWx9/3fekktECkE3qT3gJICT0UQTqISkgCCSWGhCBiR8QRsKEiAuqIDUTBsQAyqIgotkGx gH1AREUdBws2VPYDljCze3b37D3n5f3OzX333fvOd8/5A0D+xhaJMmBFADKF2eKIAG96XHwCHf8U QAABROAIDNgciYgZHh4CUJva/24fe9Bo1G5Zjuf69///qylxeRIOAFA4yslcCScT5RPoesIRibMB QMpRv8GibNE4t6KsIkYLRPnGOKdO8tNxTp7kzxMxURE+AGDIABDIbLY4FQCyGuqn53BS0TxkBso2 Qq5AiDIfZQ8On81FuQblmZmZC8f5NsqmyX/Jk/q3nMmynGx2qowne5kwgq9AIspgL/4/n+N/W2aG dOoOYzDegDgwAt1J6JvdTV8YLGNh8uywKRZwJ+InmC8NjJ5ijsQnYYq5bN9g2dmM2SFTnCLwZ8ny ZLOippgn8YucYvHCCNldKWIf5hSzxdP3StOjZX4+jyXLn8ePip3iHEHM7CmWpEcGT8f4yPxiaYSs fp4wwHv6Xn9Z75mSv/QrYMnOZvOjAmW9s6fr5wmZ0zklcbLauDxfv+mYaFm8KNtbdpcoI1wWz8sI kPklOZGys9noBzl9Nlz2hmnsoPApBnbAAZ03G4C+RjYvN3u8AZ+FosViQSo/m85EJ4tHZwk5VjPp djZ2NgCMz+nkZ/CeNjF/EO3KtC83GQD3dADgwGlfXBwADaYAqMdN+4w1AaCiM9e0niMV50z6MOM/ WLQqBaAC1IEOMACmwBKtzwm4AS/gB4JAGIgC8WA+4AA+yARisAgsBatAISgGm8A2UAF2g72gBhwB x0ATaAXnwEVwFdwAd8AD0AcGwSswDD6CUQiC8BAFokLqkC5kBFlAdhAD8oD8oBAoAoqHkqBUSAhJ oaXQaqgYKoUqoD1QLfQLdAo6B12GuqF7UD80BL2DvsIITIZVYG3YGLaGGTATDoaj4HlwKpwF58EF 8Aa4HK6GD8ON8Dn4KnwH7oNfwSMIQOQQGqKHWCIMxAcJQxKQFESMLEeKkDKkGqlHWpBO5BbSh7xG vmBwGCqGjrHEuGECMdEYDiYLsxxTgqnA1GAaMR2YW5h+zDDmB5aC1cJaYF2xLGwcNhW7CFuILcMe wJ7EXsDewQ5iP+JwOBrOBOeMC8TF49JwS3AluJ24Blwbrhs3gBvB4/HqeAu8Oz4Mz8Zn4wvxO/CH 8WfxN/GD+M8EOYIuwY7gT0ggCAn5hDLCIcIZwk3Cc8IoUZFoRHQlhhG5xMXEjcR9xBbideIgcZSk RDIhuZOiSGmkVaRyUj3pAukh6b2cnJy+nIvcHDmB3Eq5crmjcpfk+uW+kJXJ5mQfciJZSt5APkhu I98jv6dQKMYUL0oCJZuygVJLOU95TPksT5W3kmfJc+VXyFfKN8rflH+jQFQwUmAqzFfIUyhTOK5w XeG1IlHRWNFHka24XLFS8ZRir+KIElXJVilMKVOpROmQ0mWlF8p4ZWNlP2WucoHyXuXzygNUhGpA 9aFyqKup+6gXqIMqOBUTFZZKmkqxyhGVLpVhVWVVB9UY1VzVStXTqn00hGZMY9EyaBtpx2g9tK8z tGcwZ/BmrJtRP+PmjE9qmmpeajy1IrUGtTtqX9Xp6n7q6eqb1ZvUH2lgNMw15mgs0tilcUHjtaaK ppsmR7NI85jmfS1Yy1wrQmuJ1l6ta1oj2jraAdoi7R3a57Vf69B0vHTSdLbqnNEZ0qXqeugKdLfq ntV9SVelM+kZ9HJ6B31YT0svUE+qt0evS29U30Q/Wj9fv0H/kQHJgGGQYrDVoN1g2FDXMNRwqWGd 4X0johHDiG+03ajT6JOxiXGs8VrjJuMXJmomLJM8kzqTh6YUU0/TLNNq09tmODOGWbrZTrMb5rC5 oznfvNL8ugVs4WQhsNhp0T0TO9NlpnBm9cxeS7Il0zLHss6y34pmFWKVb9Vk9cba0DrBerN1p/UP G0ebDJt9Ng9slW2DbPNtW2zf2Znbcewq7W7bU+z97VfYN9u/dbBw4DnscrjrSHUMdVzr2O743cnZ SexU7zTkbOic5Fzl3MtQYYQzShiXXLAu3i4rXFpdvrg6uWa7HnP9083SLd3tkNuLWSazeLP2zRpw 13dnu+9x7/OgeyR5/OzR56nnyfas9nziZeDF9Trg9ZxpxkxjHma+8bbxFnuf9P7k4+qzzKfNF/EN 8C3y7fJT9ov2q/B77K/vn+pf5z8c4BiwJKAtEBsYHLg5sJelzeKwalnDQc5By4I6gsnBkcEVwU9C zEPEIS2hcGhQ6JbQh7ONZgtnN4WBMFbYlrBH4SbhWeG/zsHNCZ9TOedZhG3E0ojOSGrkgshDkR+j vKM2Rj2INo2WRrfHKMQkxtTGfIr1jS2N7YuzjlsWdzVeI14Q35yAT4hJOJAwMtdv7ra5g4mOiYWJ PfNM5uXOuzxfY37G/NMLFBawFxxPwibFJh1K+sYOY1ezR5JZyVXJwxwfznbOK64Xdyt3iOfOK+U9 T3FPKU15keqeuiV1iO/JL+O/FvgIKgRv0wLTdqd9Sg9LP5g+lhGb0ZBJyEzKPCVUFqYLOxbqLMxd 2C2yEBWK+rJcs7ZlDYuDxQckkGSepDlbBRVE16Sm0jXS/hyPnMqcz4tiFh3PVcoV5l5bbL543eLn ef55+5dglnCWtC/VW7pqaf8y5rI9y6HlycvbVxisKFgxuDJgZc0q0qr0Vb/l2+SX5n9YHbu6pUC7 YGXBwJqANXWF8oXiwt61bmt3/4T5SfBT1zr7dTvW/SjiFl0ptikuK/5Wwim5st52ffn6sQ0pG7o2 Om3ctQm3SbipZ7Pn5ppSpdK80oEtoVsat9K3Fm39sG3BtstlDmW7t5O2S7f3lYeUN+8w3LFpx7cK fsWdSu/KhiqtqnVVn3Zyd97c5bWrfrf27uLdX38W/Hx3T8Cexmrj6rK9uL05e5/ti9nXuZ+xv/aA xoHiA98PCg/21UTUdNQ619Ye0jq0sQ6uk9YNHU48fOOI75Hmesv6PQ20huKj4Kj06Mtfkn7pORZ8 rP0443j9CaMTVSepJ4saocbFjcNN/Ka+5vjm7lNBp9pb3FpO/mr168FWvdbK06qnN54hnSk4M3Y2 7+xIm6jt9bnUcwPtC9ofnI87f7tjTkfXheALly76Xzzfyew8e8n9Uutl18unrjCuNF11utp4zfHa yd8cfzvZ5dTVeN35evMNlxst3bO6z9z0vHnulu+ti7dZt6/emX2nuye6525vYm/fXe7dF/cy7r29 n3N/9MHKh9iHRY8UH5U91npc/bvZ7w19Tn2n+337rz2JfPJggDPw6qnk6bfBgmeUZ2XPdZ/XvrB7 0TrkP3Tj5dyXg69Er0ZfF/6h9EfVG9M3J/70+vPacNzw4Fvx27F3Je/V3x/84PChfSR85PHHzI+j n4o+q3+u+cL40vk19uvz0UXf8N/Kv5t9b/kR/OPhWObYmIgtZk9IAQRdcEoKAO8OAkCJR7UCqrtJ cyd19IRBk9p/gsB/4kmtPWFOAOxvAyB6JQCB6F6J7sboruwFwLgUivICsL29bP3TJCn2dpO5yKii xH4eG3uvDQC+BYDv4rGx0Z1jY9/3ocXeA6Ata1K/T0iYAQAM0aRQbBfJKRf8i/0D0d0MkN0RdPQA AAGdaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjc2 NjwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj40 NDE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KsQmUcwAAQABJREFUeAHsnQm4HUWZv+smN/tyb3bWJBBCIOw7 SJAAIoJRUEBwVLbRUXQWdEZhHEdgnkfFGZ0ZRwXRPw6MGyiCQERQloSwKIZNQiBsSQiB7Lk3+37/ 9aukDn36dPfps91zTt+3nufe7q71q7fqdH9dXfVVS5d1JsZ1dnaatra2mNBk74ULF5px48YlR4oJ raTcZkwLq5iOEOENqwgoMV6wigET4Q2rCCgxXrCKARPhDasIKDFesIoBE+ENqwgoMV6wKgTTq9AL HwhAAAIQgAAEIAABCEAgawRQ/LPWotQHAhCAAAQgAAEIQAACEQRQ/COg4AUBCEAAAhCAAAQgAIGs EUDxz1qLUh8IQAACEIAABCAAAQhEEEDxj4CCFwQgAAEIQAACEIAABLJGAMU/ay1KfSAAAQhAAAIQ gAAEIBBBAMU/AgpeEIAABCAAAQhAAAIQyBoBFP+stSj1gQAEIAABCEAAAhCAQAQBFP8IKHhBAAIQ gAAEIAABCEAgawRQ/LPWotQHAhCAAAQgAAEIQAACEQRQ/COg4AUBCEAAAhCAAAQgAIGsEWjp6Ojo qkWlbL6mvb29FllnLk9YpW9SWMEqPYH0MelXsEpPIH1M+hWs0hNIH5N+Bav0BApjtra1tRX67vLp 7Ow0SeGxCW2AOma5aSsptxnTwiqpJ+WHwSqfR9IVrJLo5IfBKp9H0hWskujkh8Eqn0fSFayS6OSH wSqfR9IVrArpMNWnkAk+EIAABCAAAQhAAAIQyBwBFP/MNSkVggAEIAABCEAAAhCAQCEBFP9CJvhA AAIQgAAEIAABCEAgcwRQ/DPXpFQIAhCAAAQgAAEIQAAChQRQ/AuZ4AMBCEAAAhCAAAQgAIHMEUDx z1yTUiEIQAACEIAABCAAAQgUEkDxL2SCDwQgAAEIQAACEIAABDJHAMU/c01KhSAAAQhAAAIQgAAE IFBIAMW/kAk+EIAABCAAAQhAAAIQyBwBFP/MNSkVggAEIAABCEAAAhCAQCEBFP9CJvhAAAIQgAAE IAABCEAgcwRQ/DPXpFQIAhCAAAQgAAEIQAAChQRQ/AuZ4AMBCEAAAhCAAAQgAIHMEWjp6OjoqkWt bL6mvb29FllnLk9YpW9SWMEqPYH0MelXsEpPIH1M+hWs0hNIH5N+Bav0BApjtra1tRX67vLp7Ow0 SeGxCW2AOma5aSsptxnTwiqpJ+WHwSqfR9IVrJLo5IfBKp9H0hWskujkh8Eqn0fSFayS6OSHwSqf R9IVrArpMNWnkAk+EIAABCAAAQhAAAIQyByBhlH8t2/fbq699lr31x2UZ8yY0a3ldUedKGMngQUL Fri2VRsXc6XELZYX4Y1HoFnad/HixQ13P9L9+Oabby5o1D/84Q9O1t/85jcuLC5eQcIID38fVjsV c48++mjq33WxvBotvBH6aTXa8Y033mg0tMgDAQiECNRM8f/Vr35lPv3pT5uTTjrJTfnZf//9zXnn nWf++Z//2UTd5Ldt29btN3Xd6BrJPfvss+bUU081n//8551YeujqWv649ARKeYiWEje9BMRsFALd 1b6V/nb/9Kc/ufvfCSec0CjonDxhxV/3pr/5m79xYd/5znecrNVQGKOeCWEQKP5hItW9rkY7ovhX t03IDQK1INBai0wvuOACI8V/0KBB5tBDDzWXXnqp0Q1BD8df//rX5vvf/775n//5H3PJJZfkipfi 39WVfp2xHkh//dd/bfSloFz34IMPmpaWlnKTVz3d4Ycfbh5++GHz7ne/2+Wth6GuNUcNVxqBUvpS KXFLk4LY3Ung+eefd7+dHTt25IrVb0q/83322SfnV4uTSn+7Tz75pBk/frw57rjjaiFeWXmKW9BA g+5D//3f/2323HNPI9Y+LByv1MJK+f2VErdUOeodvzvrNnz4cHPHHXeYqVOn5qrdne2YK5QTCECg 2wlUXfHXqMEvf/lLc/7555tvfetbZu+9984p17qx3XrrreaKK64wl112mdFXgHe9612u0lL8S3Ev vPBCSS8K4byDN7xwWKNd+wdso8mFPBBoJAJSRsPKk347p5xySt3ETPvb1Yi/RvvLNYhQiwqGuflR +fe+971m2LBhuSLD8XIBnDQkAbXj6tWrC2Tz7SgDGTgIQCC7BKqq+D/xxBPuE/Bpp51m/uM//sOM HTs2j5xG1z/60Y+6h8aZZ57ppgL98Y9/dF8Gtm7dmov7yiuvmNmzZxuNgm3YsMHsu+++5utf/7oL 14P93/7t38zcuXPdtZ+uc/XVV+fSa97o/fff7+KMGDHCjBs3zr2ITJ48OS/OzJkz3bXSKt9vfvOb pl+/fkbXP/3pT83TTz9tXn/9dXPggQeaf/qnfzLKK43T1w6N1L/00ktO9iOPPNKVP2rUqDTJc3G8 0qDRRDnVSzJLvltuucX96QXr8ssvd+G6oetLip8apBHED37wg+acc85x4cX+Kb3yPfnkk93oozjL T+7iiy92f+7C/tMXHI0YKa7kVFxx/q//+i8fxWgO8COPPJKTR/X4+7//+5zSoPDnnnvO5StZw05f dRYuXOjq68P0xUif/P1XkLPPPtul96x8PH8UCzFRPfRyqa9Eqksxp/zF4q677nJR9fVKU9XSpFWC qH7py4wKe/HFF90L85IlS1ydxfX00083EyZM8MlyR6X38Q444ABzxBFHmI985COu7/pIiqM6fPnL Xza//e1vzf/93/+5tgr+TnxcfwzWWaxGjhxpPF8fxx/FU3z8b0jy6i/8Qp02nvJVfrfffrtZv369 K8aXHWxb/xtQO/i2veiiixwzjVjKBfn68sOy+bqq/ylO3759je5J//AP/+Dy8P+CfVD9VRyVVv1V fdn/Nn18f/Qyx4X7eDrOmTPHSPH/93//96B33rlG2qWQxbWf6qzfX/Arqu+/klcuiWfwniKeyieY p+eufNRXg2HBc4XLeb7+9yMeaoMPfehDsS83KkO/VaVVfMmR5t6l9qvkvid5VbbaVnn5+1TwnhTs B6qv+v1//ud/5to/SgbJH/WlSf1WZemoeqofxbkojr4dg2mC8qku3/72t93vKNxPFc//Zv3vV78l xfPtqDbyLm35Pj5HCECgCQhYhTfW2R99bFhUwGc/+1nN1em66aabuuyNMCpKzs8qYC7u3Xff7fze fvttd20Vh64TTzyxy958u+zDqGu//fZz/nb6kItnP+N32QeI+7MvErlzn/EnPvGJLvlbJb9L8tgH h7vu1atXnkxWMXf+11xzTS5fpbOjHl2f+tSnXJjKt4qzK99+gvdFRB7Fyr6wdJ111lkureqh9FYx d9fHH398ZDp5BlkpjWSTmz9/vsvDXdh/CpOM//u//+uO9kHfddVVV7ngZ555psuOwjlZ7YOhy97M uxSu+Haqlc8i7xhuX89EaZWXOCsvOwpZkM/06dOdn1WUcuUqnXf24eHCDzvsMCeL8lI+ynfWrFku mq+H8gg7OyKVS+/DVA/VR3mKhWTTtfJUfO9UD/VDH+7rYb8+ufj2i5OP6lgrrvLzTtztAztXluQ7 +OCD3bVVsn20xKPaX/nKhTnLX+He2alvXXb6hONzxhlndNk51F32QezKs2tifDR3tMqEy1fp/Z8Y TJkypcsqZLm4qo/KsUqAy0fnvq/nIgVOxE91U17iduWVVzrOug7X2bebZBQb/Xl5xdbXt1i8QPGu j6ostZHyU5vpWm2rvu2d6iV/f1Sfsi+bLv7QoUNdnZVWf3K+Tyu+d8H2VTyVZ1/uXb7huipc5Ymd 6ig28hNPyaa8fH1VhsqTk3+wTOcZ8U9pf/SjH7n87EBHRIydXpJRctx55525OL5c+SlMceSCbel/ fzoqjuqncJ9WMspfDHXUPcPLrWvVVU5t6eutvqpzX14wnuIGy1c85efLt1M/FSXnFCaWvn6KL8b+ nqNyvdO9TnGVxru09z1fX58ueAzeV1S2v2/6spVWcqme6geek2/rJBl0/w8631aqn8rSn/qV7p3h uv3lL38puA95jnH9VO1oXybcc0gyB/up5BBn1U/+yktx/O/Lt6NnFWxHySnuceUrTHnquVCuCz4H S83Dy1xqOsVvxrSwSt/SsCpktVMzKfR3PqX+ILyyY0eD85TZqOyvv/56d6P48Y9/7IIXLVrkrpWH bvBS8OV0tCOtLkxKjPfzN2KF+7h2ipGLp5uQ91N8vYjopvSlL33Jpdc/3bTl55Uhxde1FH+lt2sH cnH10qEwa80i5xc+ESu78M3Fu+222/KC7eiZ87/nnnvy/P1F2o7pb656UNivEa6Ovo2kqEpG+Xun OumGLX/VN+x8Wu/vmSi+Hnqe4apVq9wNX/7+IaEbvK79Q8vHVV5KqzA9zLy/jpJN/nbBty/SPeCV R9jpAaa4yktO5erajoLn8pS/HXVz/r4d5Resh/qXl0Gc9eBSPvOtYhaMK7be6WVRcYJp9RD0/CVb Med/C4oX5qy8Fe6dzqUIPPTQQ97LyWy/FHUdc8wxXXZam/O3X6GcXHZ6XNe6detycb/3ve85f730 eudlVfsr3DPw4eGj5y2ecpJZabxCElQ49duTvOoX3imu72v2K43zLhZPTOWC/cX7KT/xECv9Jr3z 9VKfCbaP4mvAQPF1rj853xeUzju9lIbbd77tD76uwfZVHRRX/cbXV3n7fqe44fb15aQ5Ku0nP/nJ rqOPPjoxuu//ktE7X66XW3WQ029BMkvJ8xx0FC/5637k0wZ5+nuKy8T+U1zV3zvlEc5XYeF4vj2V d7B8X5b/TSut91N/Cpb/+uuvuz6mlyvvohT/tPc9X1+flz96VmrPoKxewRVTpQ32g6CcykcyePl9 vuor/vegPuhdVFxfV3EUD+/e//73O7bhfu6ZRfVT/S5UtmRWfXw/9S9pytun1+/L11n+vh09q/A9 QXEU3/e34D3B54niL0rpnOecLnZ+rLQ6Q36qnVeVlNuMaWFV2AuqqviPHj26y87bd6UUg62Rft1o 7OdtF183WF3379+/y5q2y5PUP0iCyp1uxBqhCDopDX/+85+77FSQoLe7WSlvjcZ75xUCn6duaIqj P/vZ3UdzR69Yffe7383zD17oB7Fs2bIu+9neKRvBMF+WXfMQ9M6dF2PlI/qba/AmrnKjlAKfRg8B 1Uk367AL/4i9nHrohZ1/CEgGOa/464EXdv4hqTYNO/8w9GH+IeKvfXx98ZHcXhHUUQ8q/7XAx9NR 8VSmd74eQT+Fqb6+Hv6h6eP6eqkc5Rdm4FlptEyyFXOlKP76zahMvbgGnfqkr7/81X8Vz06PC0Zz 5/qipLBXX33VXfu+opeYNE78xdeX5+sb5qO8xEajij5uMH/J7NMWi+fT+f7iFRbvr6P6uurly/L1 Uj8KO6/4B/3D8queyi/cN/Qb9L+VYPt62YJKjvIP5uPrGyw37fny5cu7NAr+d3/3d0WTqO+Ju3e+ XPkF+6uUv6jfpdL5NvFpPc+o+0MUJ/kFv5gpz3A8sQn2JcWRC7eF/JLK9/cGpZMLK/6l3Pd8fV1G gX9iF8VK8ks2laG0vh/4+4bPwtcpeE/2Yb4/+bAkeX0/V5ly6u/iGmxXF7DrX/g+5OXzL1XB+obb xzP3XH2+Pp5PW047ovh7msWPnnPxmIUx0uoMhSkLB6Ki4sT5VSJzvdLCqrA1qzrH32Zv7x3pnFXa 8yL6xb1WgXFz/oOBfm7+m2++GfQuOLc3cTNx4kSzadMmI1vTjz/+eF6cjRs35l1HXWgx8rHHHpsX 5MtfuXJlnn/4QnP49ffyyy+bX/ziF+6oOJ7L2rVrw0nKug7Pe9WcTjkx9fM3nUfgn+38gavk03D+ im2VIZfI/njzEnv/oKfmTdsHlrEKSNDbnSu+5v1KHoVrLrHmmmr+tBZ9yylM81/tgz9nOURtq8Vn jz32mKujwsOyuMSBf1b5DlztPPXyxqVVvnL2U3oeS8071zx/OwKZW7OwM8fK///gBz9wZltlDUt9 XL8BLfRUewZ/J1r7ojD1Y9/mvnTF13oZ++Usb13ApEmTfJTEo9pCf2Kv9tMaGa130XXYqX9oPrDW rliFxc0dV1q5oLxp46nPKr2d2uDmJYuzd36hodol2J6+HX28tEdfn2BePq3aVv3W9wHvr2M4vq9v ME4551rLpHrbr5FFk+v3IXOa+q3436jO1ZetMpdLrzqKT9S9wI44u/bVGp1DDjkklyZcv1xAGSdi oz/Job7k+6pnH5Wlr08wzDOOS+fzLfe+5+8hVmkOFuvOda/Rn5zvgzoP9zsvg/pOFG+l8f3J33N8 vRTmnfh786jy82nC9yEfP+4+VO929PJxhAAEGpdAVRX/gw46yN3kiynowiEFRU4LCOW84u8uQv+U r5xPEwrOu5RCohuondNv7Jxf92dHdPLiJF2EFyQnxQ2HrVixwvzLv/yLsXN2jf1y4RaxSWHVXy2d f6Bo4ZaU6CinRbJyelBpb4Cgk9IQVByCYeFz/0AK+wevJY8UqCTnH+Z6UNnRKye3V/ylzMgFlQHl +eEPf9jJrzCZia0l1ziW/iVOMlTLScFQeXoh+sd//EeXrV5gtdhU+2Cce+65zk/KmpT/cPspME6u AQMGuLTF/qldv/CFL+T42tFz07t378iXK/uVzGUnmaWI6k9tofb66le/mlu8XSxeUAFSf/CKVlDW uHqFFbBgmqRz3+/i4sT1qTj/uHzS+tsvlO4eFR5siEovvlGKv+LqBVpOv285tWcSz7DiH2wLl0EF /8J9yf9W/X0qKuskvnFt5vOL+62qHH/fiyrTp48KK9VPzx39JTnfNlFx4uofV7e430Ut29Gbma4m tygW+EEAArUl0Kua2fuRcY22F3NPPfWUi5JG8befw13cwYMHJ2b7jW98w1mV+dznPmf0sJAibudP 5h6GiYl3Bdq502miRcbRQ/mHP/yh+du//Vs3cvnWW285y0KSqzuclHftaxD+s9MvHAfJoAeDlDP9 aZRRx6gRrzh5ww+WchWwYD5SaKQs+Ae8Xl70MhBU/MXWfpp2Co6+vNjP5u5afmGX9IANx4271kh2 kKP9bO+uxVJ/1Xb6uiErSfPmzXO20mXNRy+wssrjnV5g7SLjPLm8jF6uckf89FIllrIGojztehR3 bac2+OLzjlLq7VQAo9+xXUPjXsTsNAP3chaMmDae+oPK9ZyL1StOUQqWHXUe7HdR4d3tpxF/fa3R i14xJ9n1W/WWcjQSrd+KnfaUewn29VM8zzB49P3ELgYvVlzZ4XqBDPYl/1uN60vFCip2j0lz34sq o5zfSpws+g0EOftz/Uai7lFR8kT5he9DPl/fjlFpquUXvieoHvortx2rJRf5QAAClRGoquL/gQ98 wEnz85//PFEqTSPQjVKb1cj0p1zSiL9s9ssVG4335Uqh1SYzfqqEpoekdd6UYNr4Pp6dk+lMgGpj FJmW82XruGbNGh+tJkf/MNJITLDc8LkKl2IgZUx/2kVZx/AD0CvgQWH9KI9XLHyYFPawk9Ie99k7 Ku/gSL/ClWdQ6Vf+XpnXQ16fuX3dNJUgznmZg+FR5QfDvUIpGXwZUcdgmqTz8Ncv/zUjLo0UQJn3 034X2uNC08Z+//vfu+jq//rqFSWP94vLN8lfnKSgSFnUC5bPS8ekEVOFayqCNuiTQiAFVEqezK0G XVw836bqL2qXYLnh82B+1TiP6wfqt5KnO5wGNPTilGa038ujkX21l9jJTKucH+3Xuf996qUgzDB4 rbi1cuoL+uJXSl+Kuo94+fxv0l/7Yyn3PZ8mfFRbR/VxMVZfCPeTsJyet/II8g2fq9zwfTYoi/8t eD9f52rdh3y+aY/l3hPS5k88CECgfgRag/MXo8QoFh5Mo5GrCy+80CktX/va15wt/2C4zqUU2IVs zvu6664zst+vMnSjkZONaN3s/E1dfv7rgOYUe3n8i4K/VrylS5fq4Ebbg/6aby+n0Xzv7xX8zZs3 Oz//6VTz8H0cl8j+C8f1/sGjXdjrLmUPPJxe9ZSzi5YLwlyA/RdO4/2DR8kqJ3mC8cVFzi5ALPjc rE/62p/gM5/5TN6cXpfA/gvm4+sp5VTpglOkvPKpTdeCadQOwWvlqykqmreuFzFrmcIX5eIpb03B ksLo00mR10i2Roy1PkNOG7z5cF1rpMu7oP+//uu/Ou+gHJ6TeGj0MVgP/zXqPe95j8vf19n3A82B 1joPPfS1IVTwZVPlagRe02CC9fJyBY/ae0IPc9mW10uMl1mb28l5eRX+wAMPmN13373AnrdeirVO RUqF0tvFvW6/BL1Y6gtB0Gl/AmsZxu01oHUmnoGvVzBu+Ny/mHqZfLj6gF4M5Xw+8hMD7ccRZqA9 BfxotNgVi+f7sV5wVMcbbrjB/NVf/VWOlcqVn5Qo9V85Xy+tZ1AfinLBdgu3r9KofaP6uB84kDy+ vcREzl+HyysWHo4fvLYLSN09QVMZ4/IPxte5n+alfqS20G9JU3qC6dVP7r33XvdiEB7ZD/ZfpfE8 fVuEywv3CR8eLE9+4XgakQ7G0bnvS7pX+jBfvr526QUy6OSn+um35OMr3PfFUu97wTx8OWprPR/0 XAqueRAn3cO0n4v6uW/nMKejjjrKZaV7l150gk7to692ejFT3n4fGNUrHFd+cr5uSfchxQu2o669 fME6Bs+D7eOZh+sSzCfunqA8fTt6WZXO56nzYLm6LsWRNj0tWMEqjkDRvmEV3lhnlfHYsLgAu2mV syluBeqSTfIvfvGLzva0rCHIBrms9ijMTn/Jy8IqOM7fPsScDX47t9GFWyXHWe+RWcOg+/jHP+78 7WZZXbKDLiebycrbTldw5kRlPtPedLvsBldde+21V5e98bq4ViHrsqNSLq69ibm09kHlrocMGeKu g/9k4UH5+rjBMH9uN1Tqsg9wF+/GG2903rLSYl+Gun7yk584f+VhFRmfJHe0o0q586QTO9rt8pHs 3vk28mFWsemySo2zRqGjrq3i22VHdH2S3NGn9R6eiR0Fc+nESZYo7OZBrlw7iuejOksXqo8dJc75 +ROVpTKtQt+ldlQeykuyKI3djM1HzR3VPxRmR9AiLVl4Cx/a/0H5qW7qK/KXvHaEzLWprGF4FpJB Zfr2lk38sMy+zkrjnX0Iu3hBlnZ01ZWn9GELLz5d8Ki2V1z7FcxZQJK1Dfswd78J+dvRv1x0qzy4 vizTezLdKctQOrcKb5dVerrs1CYX1y7qdfWRv/qiOEt+nStP2f/3zjNI6rM+ro5iqDzU1spT/VT1 9/moXcRdzret8paf5FA7qw0UZpX4VPG8pR6l93nal+Rcf1H+qqssnnjn5dEx7LT3gOpgvyC5Nlf+ qov8gvHVFvILtq/uGeqvkkPyeKf+rbhRTv4KD/+OouJG+VnlzXGXNbBSnPq82kPlB9n4PNQmnqfa RfXRb8CbMRULL7POlY84hZ2vX9BffuIbdOF4uk/Iz/clyRDuS5Ip+FtV/5N8/p4j2/rKQ3X1LmzV R/5e/mBbRt33fH19Xv4oOYKsVL7/Pfn7ndL6cqI4qQ0kq+5HXn4vg31xcfx9eb4/+boqns49M5Xj nTffG6yb8lc5Ki94H/L5evmC9VVchXundPLTPUj5iYGcj+fThu8JUe3o7wmeD1Z9HMpU/zznVJFD kdLqDKFk7rKScpsxLawKe0H0E21XvHIbWUq0bFNrUxzdTPTw1p8erDK5F7Zzr+LsDq8urp2f36WH v5QkbbqldFKepQwFnW6YujEpXPHk7KhwbiMg+cu8qPKTkylNbeolf93sdIOUbF4x8oq/wsMujeIv VpLRbmfvylA+2ujG38jtzr9ddhqQCwvnn7Zj+purv7krn2AbKVwPMZXt//RAkd3pKBdMq3DPRPno Yebz0FEPjmA+SusfFFF5K67SBPOQbLJJHS5X6aUEKD/9STELO5nGU34K93l6pUfxfb1VB89JCnxU PZSXd8E6ez8dldb3L1+eruWf1tmvFnnyqh/bOfzOL6j4S/GTMqX+4svSUS8NerENOruTdZddQ5IX Vy+cvh/7uJ5B2N+Hh49qr2B9xVMvY3JesZFMcuInc5pBWXWu9lE+vn2LxXOZ7foX1V/0IqF6BJ2v V9hfcbThkerg+4jaNq591Q99n/H18PIHy/N9Lujnz1WOwn19vX/aox2977LzqNNGz8XzipvK94pX LnDXSRRPsdELpZyX2fMUp7Dz9Qv6y6+Y4q+ydd/xXIPt6F/OFKYyffn6XYmlT6Nygkq/ZIhS/OWv PMJtGb7v+foqfthJXrHxZeuo/u3vE0rr5YzipPyiZFB9NGAQdMpT/qqfL0/X/hmjfLxTuWnvQz5P /zIdrG9UO/r4ksGX6eP5tGEuase4e4LyUHoUf996xY+ec/GYhTHS6gyFKd/57UeFFfOrROZ6pYVV YavWRPFXMYItZVqNrR0ptUmJrvUX53yY0uhcO+Haz6WxabSJkZ0G5PL2eSqtypZ/cJMjhYfL9+X5 tLpphv18WJy/Dw92ar0A2OlKXfZTqg92x3D5PrCUjhmWI1iu8lO4bth6kOghE47vy9QxnFYPNd28 /YNAaZWPb7twWoUn5a8wpVUeksnHDZfr81W4j+P9gkeF2Tn9Lr9wvHDaYLjOJYPvk8E8dR6MGwyT v5c/Lm0wftS5vgTZ6Txdstfuy/HHcHxfnvaRsFPOXHASK/Ux2e2Py2/+rpG8cDlx1758tZVXIHxc hYXLUf8S13AfCcscF8/n7Y/KX5zD+flwfwzL4f1VrsIkv8r0Li6+j6vytD9EVDz5Rfkrbx8Wrq8v N+moF0D93uI29UtKqzCVHW6jcBrF8f1XR117F5Q56O/DdZR/OEzX4ftVXDxfdjAP30ZBP3+uo+8r 3i8oj08b9PPnip903wvW16cJHpU+Sl7F8WmjZArn4WVQXP2FWSm+/H1Zqq+uvb872fUvWG5U/GBc 5eHzkb9Pq/NwmPdTnvrzzscLp1Uc1SuYv88j6KfzYFqfb9pjFKu0aSsptxnTwiptz9ipi6aPnR+z GftGGplbraJXM2dHE9z8ajtNJ1UZiu+dzvfbbz9/GXmUvW8/zzMYwY7eRC7QC+av+FHXYT+fb5y/ Dw8evfnRoJ/OS8kjnNZfF8tD4fbTsI9e0VF52c/KsXmkkcV+uTH6S+PS5GdH9pwFmXB+4bTBa52r Hpr3FvT3eUT5KUz+Xv64tD6PuOOYMWNypl19nDTl+bhxR+VhRzXjgp1/XDlxiRTft1V4jmBUXlqb kdQ/fDlp46kMO6pYNM8oWXxZCgv3/7j4wbh+cabPxx/j0io8KcynjztqrUx4vUxc3Ch/lV2sfIX7 /huVh/eLyyfKvxS/uLLDefhrHYv1FR/Xy+6P8g+3uw9Lc1T6OHl9+riyg+FpZIgrKy7/uPi+XB3j 0saF+TyL5REVz6cJlxm+9vE4QgACjUWgqlZ9GqtqSAMBCEAAAhCAAAQgAAEIeAIo/p4ERwhAAAIQ gAAEIAABCGSYQE2n+mSYWyarJhOqdr5zbrpHJitJpSAAAQhAAAIQgEAPJYDi30MbPqraaeZXR6XD DwIQgAAEIAABCECg8Qkw1afx2wgJIQABCEAAAhCAAAQgUDEBFP+KEZIBBCAAAQhAAAIQgAAEGp8A in/jtxESQgACEIAABCAAAQhAoGICKP4VIyQDCEAAAhCAAAQgAAEIND4BFP/GbyMkhAAEIAABCEAA AhCAQMUEUPwrRkgGEIAABCAAAQhAAAIQaHwCLR0dHV21ENPma2QeElecAKyKM/IxYOVJFD/Cqjgj HwNWnkTxI6yKM/IxYOVJFD/CqjgjHwNWnkTxI6wKGbW2tbUV+u7y6ezsNEnhsQltgGCXm7aScpsx LaySelJ+GKzyeSRdwSqJTn4YrPJ5JF3BKolOfhis8nkkXcEqiU5+GKzyeSRdwaqQDlN9CpngAwEI QAACEIAABCAAgcwRQPHPXJNSIQhAAAIQgAAEIAABCBQSQPEvZIIPBCAAAQhAAAIQgAAEMkegNXM1 okIQgAAEIFAxge3bt5vNmzcbHeVaW1tNv379Ks6XDCAAAQhAoH4EUPzrx56SIQABCDQUgY0bN5pF ixaZpUuXGhlK0PW2bducjH369DEDBw50LwItLS1mjz32cC8DDVUBhIEABCAAgUQCKP6JeAiEAAQg kG0CUuxXr15tXnnlFfPyyy/nFP9169aZHTt2mK6uLvfXq1cvo79BgwaZl156yYwbN85MmjTJjB8/ 3gwZMsSFZZsUtYMABCDQ/ARQ/Ju/DakBBCAAgbIILF++3MybN8+88MILZu7cuU7pL5bRmjVrzNtv v21mz55t9ttvPzN58mT3N3HiRDN48OBiyQmHAAQgAIE6EkDxryN8ioYABCBQDwIaydcI/yOPPGLm zJnjFPktW7aUJMrWrVvdyP/ChQvdS8ORRx5ppkyZYsaMGVNSPkSGAAQgAIHuI4Di332sKQkCEIBA 3Qloao+m9DzwwAPmxRdfNBs2bChbJk0DUnpN/dFXgBUrVphp06a5+f9aB4CDAAQgAIHGIoDi31jt gTQQgAAEakZAVnqeffZZc8899zilX4p7NZzy0Q6ZM2fONPoScMYZZ7hpQCj/1aBLHhCAAASqRwA7 /tVjSU4QgAAEGpaApvf85S9/Mb/5zW+qqvQHK7xp0yYza9Ysc9dddxlNAcJBAAIQgEBjEUDxb6z2 QBoIQAACNSHw5ptvupH+V1991VnpqUkhNlON+D/11FPmvvvucyZBa1UO+UIAAhCAQOkEUPxLZ0YK CEAAAk1FQDb5f/vb37qRfr8hVy0roClFf/zjH93iYb8PQC3LI28IQAACEEhHoGXBggXVmeSZrjxi QQACEIBANxKQoq/pN/fff7/RVJzudCNHjjTnn3++2X///buzWMqCAAQgAIEYAq3ahCXOaZSora0t LjjRX/M7k/JOSlxJuc2YFlZJvSE/DFb5PJKuYJVEJz8sy6xee+018/TTT3e70i/CK1eudGUfd9xx ZujQoW7qT7nPFO7t+X026QpWSXTyw2CVzyPpClZJdPLDGpkVU33y24orCEAAApkhINv8mnKzZMmS utRJ1n60OZj+qmVBqC4VoVAIQAACGSGA4p+RhqQaEIAABMIEVq9e7XbY1YLbejnZ+dfLx8aNG+sl AuVCAAIQgMAuAij+dAUIQAACGSUg852LFy+ua+1kRnTu3Ll1++pQ18pTOAQgAIEGI4Di32ANgjgQ gAAEqkFAo/zaUKsRrOqsWrXKPPPMM9WoFnlAAAIQgEAFBFD8K4BHUghAAAKNSkAj/VrY2whO8/sf e+yxhngJaQQeyAABCECgXgRQ/OtFnnIhAAEI1JDAs88+a2RPv1HcokWLzNKlSxtFHOSAAAQg0CMJ oPj3yGan0hCAQJYJaF69LOk0ktN+AvPmzWskkZAFAhCAQI8jgOLf45qcCkMAAlknsH79+oYcXW+U qUdZb3/qBwEIQCCOAIp/HBn8IQABCDQpgY6Ojrps2FUMl/YT0NcIHAQgAAEI1IcAin99uFMqBCAA gZoRWLt2ramn7f64ismm/6ZNm+KC8YcABCAAgRoTQPGvMWCyhwAEINDdBLRZlubUN5qTTGzk1Wit gjwQgEBPIoDi35Nam7pCAAI9gsCWLVuMTGg2mpNMkg0HAQhAAAL1IYDiXx/ulAoBCECgpgQaVfFn jn9Nm53MIQABCCQSaLGLwGoyLKTFZe3t7YmFE7iTAKzS9wRYwSo9gfQxs9avZMP/Rz/6kdGc+kZy I0eONF/84hfN6NGjG0msmsmStX5VM1A2Y1ilpwsrWKUnUBizta2trdB3l09nZ6dJCo9NaAPUMctN W0m5zZgWVkk9KT8MVvk8kq5glUQnPyxrrIYNG2ZaW1vzK9kAV7169TKjRo0q69nAvT19A8IKVnEE mrFvVCJz1u7tce3q/dOwYqqPp8URAhCAQEYIDBo0qCEV/759+5qBAwdmhDLVgAAEINB8BFD8m6/N kBgCEIBAIgF9be3Tp09inHoEavpnI8pVDxaUCQEIQKAeBFD860GdMiEAAQjUkMDQoUPNkCFDalhC eVnvsccepqWlpbzEpIIABCAAgYoJoPhXjJAMIAABCDQWAU2pGTt2bGMJZaXZd999G04mBIIABCDQ kwig+Pek1qauEIBAjyFw8MEHN1RdNcUHxb+hmgRhIACBHkgAxb8HNjpVhgAEsk/goIMOMhr5bxS3 1157mREjRjSKOMgBAQhAoEcSQPHvkc1OpSEAgawTkM38/fbbr2GqedRRRxmZ88RBAAIQgED9CHAX rh97SoYABCBQMwJaRDtlypSGULZlwvPQQw+tWV3JGAIQgAAE0hFA8U/HiVgQgAAEmo6ApvsMHz68 7nJrobEs+uAgAAEIQKC+BFD868uf0iEAAQjUjIDm1B9wwAF1NaHZu3dvM3nyZDN48OCa1ZOMIQAB CEAgHQEU/3SciAUBCECg6Qj079/fHH744UbHejkp/IcddlhDLTSuFwvKhQAEIFBvAij+9W4ByocA BCBQIwJaTHvIIYeYPffcs0YlFM920qRJmPEsjokYEIAABLqFAIp/t2CmEAhAAAL1ISDrPlOnTjWy o9/dbtCgQeY973mP0REHAQhAAAL1J9DS0dHRVQsxbL6mvb29FllnLk9YpW9SWMEqPYH0MbPUr7Zt 22a2bNliZEnHuzVr1pgf/ehHZs6cOd6r5kdZFTrxxBPNxz/+cdOvXz9X3vbt283atWvN0KFDG8La UK0hZKlfwarWBNLnT7+CVXoChTFb29raCn13+XR2dpqk8NiENkAds9y0lZTbjGlhldST8sNglc8j 6QpWSXTyw7LAauvWrWbp0qXmz3/+sxt0efe73220sFZO9+IPfOADZvHixWb16tX5la/R1ZgxY8z7 3/9+M3r06FwJr732mnn44Yfd1B+tPdDgUFrb/tzbcxiLnsCqKKJcBFjlUBQ9gVVRRLkIjcyqNScl JxCAAAQg0JQEli9fbl544QXz7LPPmtmzZ5tx48a5uf2a5uOdTHsed9xx5oEHHjD6KlBLpx2DNdo/ fvz4XDFdXV3upeT3v/+928F34cKF5ogjjnBWh+q5+DgnICcQgAAEegAB5vj3gEamihCAQDYJSJnW KPpdd91l7rzzTvPYY4+ZDRs2mPnz55snn3wyr9IDBgwwp512WrcstJUJUX1x8FN8JIgU/VmzZrmX Dn2Z0AvAr3/9a3fU6BgOAhCAAARqTwDFv/aMKQECEIBA1Qloao/m7N9+++3moYceMosWLTKaQy+3 adMmp1C/9dZbuXI1514j8GeffbYbcc8FVPlkt912M+ecc06eJaH169eb3/3ud2bJkiW50jZv3mxe fPFF99Jy9913m7ffftvoRQYHAQhAAAK1I4DiXzu25AwBCECgJgS0ePeZZ55xI+aa2iNFP+zeeOMN c99995l169blgjTn/5hjjnGWdoLTgHIRKjzRfH7N6z/00ENzc/f1MqIpSH/6058KFPsdO3a4NQd6 Kbjnnnvcl4oKRSA5BCAAAQgkEEDxT4BDEAQgAIFGI6CR/kcffdTce++9bl6/H+WPklNTf55++unc lwDFaW1tNVOmTDFnnHGGs64Tla4cP1nqUZ6a4hNcsKsFxeEXkHD+enHRNCBNV3r11VfDwVxDAAIQ gECVCKD4Vwkk2UAAAhCoNQEp/U899ZSbHqM580lKv2TR3Pn777/fvPnmm3miya6+5vtrdH748OFG 04DKdUo7bNgwM23aNHPqqaeaIUOG5LKStSRN45k3b57R6H6S03QgrUuQ8q9pS0z7SaJFGAQgAIHy CKD4l8eNVBCAAAS6nYAs92ghb1iRjxNEyvbLL7/sptGE5/vLlOaZZ55pPvjBD5r999/ffQmIyyfO X18PJk6c6PJQXkETzitXrnQvHfo6kdaKkH+x0dcMpcdBAAIQgEB1CWDOs7o8yQ0CEIBATQhoFFyj 55oKU8pouL4KPP74487CjpR82df3bvDgweb00083u+++u/uSoK8JaRVujfIfddRR5uijjzYHH3xw 3oZhWlcgs6H62qD1CKU4xX/iiSfcbr8XXHBBXXYcLkVe4kIAAhBoJgIo/s3UWsgKAQj0SAKasjN9 +nRnxafY9J4oQJpD/8gjj7hRfW3k1adPn1w0mfmUPX1Z/Nl3333N3Llz3cuFylRZfoqOpvRohF8m OmWuU8q+0o0YMSL3tUAvJNolWKY6pfiXa6ZTeSj93nvv7dYj+I3IckJzAgEIQAACZRFA8S8LG4kg AAEIdA8BTZORRRyN2qedMhMlmebQz5gxwwUdeeSRRht6SZGX03HUqFHO2s8hhxziFH+Z3pQCLrOb Uv6l8GsBrxbuHn/88WaPPfbI7QysPBRHXyUkp0b6lbYSp/Sy9LPnnnuaCRMmVJIVaSEAAQhAYBcB FH+6AgQgAIEGJiAF/MEHH3Qbc1Uq5tq1a11espmvFwFN1QlusiWlXtN+9Ldx40YXR/PupdRrN96B Awca7RKskfig0wuJrAdJ6dcxaEI0GK/Uc71IaI8CvWTgIAABCECgcgIo/pUzJAcIQAACNSGgqTZS +rUTbynz+pOE0c6+squvufx6AZDyr0239AIQtO6jKUD6C7sVK1bkvPQ1QC8CUva1iFd7B5Q6pz+X WcSJXjpk6UfrCBj1jwCEFwQgAIESCaD4lwiM6BCAAAS6i4B2tp05c2ZFU3yiZNUIvV4mli5dal5/ /XVz4IEHujn+mu4jaz/BrwDh9Br9X716tVP4FyxY4NYEaDMxfU2ohVu1apXbB+Ciiy7KsxpUi7LI EwIQgEDWCbRYO8s12SNd9pv1AMEVJwCr4ox8DFh5EsWPsCrOyMdoRFaaanPLLbe4+f1ezlocNb1H 92pZ+9HIvxbr6k/z+TW1xy8E1ui+lHuZEtU0IZkH1RcDfTkoZ8FxKXWRDB/72MfMySefXEqyusdt xH5VdygxAsAqBkyEN6wioMR4waoQTGvQ7nI4WBYZksLD8YPXgl1u2krKbca0sAr2nORzWCXzCYbC Kkgj+bwRWWnajGzw19ppBF+j6hrF1+i/lGwp/bp/y9ynrjXNSIq/FtwuW7bMaAqOX/Rba/mUv8rT LsTacVgbjpXq6vVcaMR+VYwdrIoReiccVu+wKHYGq2KE3gmvNSum+rzDmjMIQAACDUFA8+Rnz55d sWWcUirjlXsp9FqcG9zwq5R8ahV38eLFblrRiSeemLcWoVblkS8EIACBLBJg594stip1ggAEmpqA Rnz+8pe/1HwKTTNB0tQnrSXQngQ4CEAAAhAojwCKf3ncSAUBCECgZgReeeWVhhtxr1llU2asLxLa XEzTknAQgAAEIFAeART/8riRCgIQgEBNCGjO/axZs9y89poU0MSZynToCy+80MQ1QHQIQAAC9SWA 4l9f/pQOAQhAII+A7OTPmTMnz4+LnQT8S5GOOAhAAAIQKJ0Ain/pzEgBAQhAoGYEpPTLXCYumoCm QWk3YxwEIAABCJROAMW/dGakgAAEIFATArKHrwWsuHgCsngEo3g+hEAAAhBIIoDin0SHMAhAAALd SEB28hcuXNiNJTZnUc899xwWj5qz6ZAaAhCoMwEU/zo3AMVDAAIQ8ASWLl3qbOj7a47RBGTTXyZP cRCAAAQgUBoBFP/SeBEbAhCAQM0IvP3229ipT0F3w4YNzPNPwYkoEIAABMIEUPzDRLiGAAQgUAcC slMvc5Waw45LJqBNvPR1BAcBCEAAAqURQPEvjRexIQABCNSEwNatW83KlSsNpiqL4xUrvSTpZQkH AQhAAALpCaD4p2dFTAhAAAI1IyBldvXq1TXLP0sZ6+VIO/iKGQ4CEIAABNITaOno6KjJkInN17S3 t6eXpAfHhFX6xocVrNITSB+zEfqVFqt+5zvfMfPnz08veA+OecQRR5hPfvKTZuDAgQ1LoRH6VcPC CQkGqxCQhEtYJcAJBcEqBMRetra1tRX67vLRgygpPDahDRDsctNWUm4zpoVVUk/KD4NVPo+kK1gl 0ckPawRWGr3W3HVcOgJa4DtgwIBUz5l6PRcaoV+lo/lOLFi9w6LYGayKEXonHFbvsCh2VmtWTPUp 1gKEQwACEOgGAtu2bWPH3hI4r1271ogZDgIQgAAE0hNA8U/PipgQgAAEakZAu/Yy4p8er0b8UfzT 8yImBCAAARFA8acfQAACEGgAAlL8WayaviH0koQFpPS8iAkBCEBABFD86QcQgAAEGoCARq8xT5m+ IbTfgV6WcBCAAAQgkJ4Ain96VsSEAAQgUDMCKLGlodVoP8xKY0ZsCEAAAij+9AEIQAACEGhKAkz1 acpmQ2gIQKCOBFD86wifoiEAAQh4An369PGnHFMS6NWLR1hKVESDAAQg4Ahw16QjQAACEGgAAq2t rUZ/uHQEpPT37t07XWRiQQACEICAI4DiT0eAAAQg0AAEpPQPGTKkASRpDhEGDx5s+ErSHG2FlBCA QOMQQPFvnLZAEghAoAcTGDhwoJkwYYJpaWnpwRTSVV2MxErMcBCAAAQgkJ4Ain96VsSEAAQgUDMC UmJPPfVUs//++6P8J1CW0j9x4kRz2mmnofgncCIIAhCAQBQBJpRGUcEPAhCAQDcT0FSfww8/3PTr 18/MmTPHLF261Kxbt87IXn2U9RqZsix3jnslaSVP3759y6JTbrmazy+Ff9iwYWbMmDHmoIMOMpMn T2ZNRFmtQCIIQKAnE0Dx78mtT90hAIGGItC/f39zxBFHOKV22bJliYr/+vXrzaBBg8qSv5K0kmv0 6NHdWq4Uf71w7Lbbbq5svRzhIAABCECgdAItCxYs6Co9GSkgAAEIQAACEIAABCAAgWYi0GK3iI9V /Ds7O01bW1tZ9Vm4cKEZN25cWWkrKbcZ08IqfTeBFaziCFTy26dfxVEt9IdVIZM4H1jFkSn0h1Uh kzgfWMWRKfSHVSETFvcWMsEHAhCAAAQgAAEIQAACmSOA4p+5JqVCEIAABCAAAQhAAAIQKCSA4l/I BB8IQAACEIAABCAAAQhkjgCKf+aalApBAAIQgAAEIAABCECgkACKfyETfCAAAQhAAAIQgAAEIJA5 Aij+mWtSKgQBCEAAAhCAAAQgAIFCAij+hUzwgQAEIAABCEAAAhCAQOYIoPhnrkmpEAQgAAEIQAAC EIAABAoJoPgXMsEHAhCAAAQgAAEIQAACmSOA4p+5JqVCEIAABCAAAQhAAAIQKCSA4l/IBB8IQAAC EIAABCAAAQhkjgCKf+aalApBAAIQgAAEIAABCECgkACKfyETfCAAAQhAAAIQgAAEIJA5Ai0dHR1d taiVzde0t7fXIuvM5Qmr9E0KK1ilJ5A+Jv0KVukJpI9Jv4JVegLpY9KvYJWeQGHM1ra2tkLfXT6d nZ0mKTw2oQ1Qxyw3bSXlNmNaWCX1pPwwWOXzSLqCVRKd/DBY5fNIuoJVEp38MFjl80i6glUSnfww WOXzSLqCVSEdpvoUMsEHAhCAAAQgAAEIQAACmSPQmrkaUSEIQAACPYTAtddeG1vTk08+2UydOjU2 PCqgq6vLtLa2mk2bNpk+ffpERcEPAhCAAASamAAj/k3ceIgOAQj0bAIzZswwUtaj/sols2PHDrNl y5Zyk5MOAhCAAAQamAAj/g3cOIgGAQhAoBgBjeonjezPnDnTaPT/ueeeM3fddZf56le/mpflAw88 YF544QUzbNgw84lPfMKFSfEfNGhQXjy9ZMjts88+7qh/3s+X/8QTT5gFCxaYl19+2Vx44YVm0qRJ ubgqZ+7cuaZfv35m3333NaeffroLC+ahLxhXX311Lg0nEIAABCBQXQKM+FeXJ7lBAAIQaCgCp5xy ilP2v/CFL5innnrK9O7d28yZM8fJeO+995ozzjjDzJ4927z++uvmox/9qPPfvHlzZB1OPfXUPH8p 7XqxkFP+55xzjrn//vvNq6++aiZPnuxeKBQmhf69732vefvtt82SJUtcmcFpSjofOXKkkTw4CEAA AhCoHQFG/GvHlpwhAAEI1JyAFG+vfAcL8yPnmga02267mQcffNAFX3rppebnP/+5OfHEE82vfvUr 8/Wvf91ceeWVLuy73/2uue2222Kn+iivOPf4448bpf/IRz7iokyYMMEsWrTIHHTQQa6cW2+91Sn8 svYmeRTXy6gE119/vTn//PPjsscfAhCAAASqQADFvwoQyQICEIBAvQgkKeNepqBCPW7cuNxLwKxZ s8xZZ53lo5l3v/vd7rycOf5f+9rX3Kj+woUL3RSfL33pS2bgwIFu9H/lypXmxRdfNM8++6yb6qNC 9FLw5ptvuvI0Rejhhx925/yDAAQgAIHaEUDxrx1bcoYABCBQcwLF5vhLgPB8fS+Upt0MHTrUX5qx Y8e683IU/9NOO829UNxxxx3mhz/8odm2bZtbAyClXwuGgwuQVcjnP/95p/zrPG5qkcJwEIAABCBQ PQIo/tVjSU4QgAAEGpKANrHR6HvYHXbYYeaNN97IefspQ0mK/7p163LxNb1HU4a8C76EaIrPNddc Y7797W+bZcuWuSk/mucf3tjRL+71eXCEAAQgAIHaEUDxrx1bcoYABCDQLQTilGdvbUc7mu+xxx4F spx99tlG1namTJniRuR/8YtfuDhRir/yOu6449wCXCn1WpD7rne9K5fnSSedZD7zmc+YadOmOcs+ AwYMMEcffbQZPny4m7v/k5/8xFkOmjhxorn55pvNH//4R3P77bfn0nMCAQhAAAK1J4DiX3vGlAAB CECgZgQ0qh7l/Oi7THlK8Y9yX/ziF91iXCnwZ555ptH10qVLYxf3XnHFFW7xr0x6XnzxxXlZ/vKX vzRXXXWV+cpXvuI2AZMFoM997nMuzg033GC+/OUvm8suu8xs3LjRHHHEEebGG2/MTUGSjDgIQAAC EKg9ART/2jOmBAhAAAI1IZBmQWz4a4BeFDS/Xq6lpcVZ3AkKF44fDJNt/hNOOMFogXDY7b777uaW W24Je7vrESNGOEVfLyDhqT56QUkqMzJDPCEAAQhAoCwCvcpKRSIIQAACEIAABCAAAQhAoKkItNhF X121kFiLydrb22uRdebyhFX6JoUVrNITSB+TfgWr9ATSx6RfwSo9gfQx6VewSk+gMGZr+LNrMErU Z9lgeNK5OmZS3klpKym3GdPCKqk35IfBKp9H0hWskujkh8Eqn0fSFayS6OSHwSqfR9IVrJLo5IfB Kp9H0hWsCukw1aeQCT4QgAAEIAABCEAAAhDIHAEU/8w1KRWCAAQgAAEIQAACEIBAIQEU/0Im+EAA AhCAAAQgAAEIQCBzBFD8M9ekVAgCEIAABCAAAQhAAAKFBFD8C5ngAwEIQAACEIAABCAAgcwRQPHP XJNSIQhAAAIQgAAEIAABCBQSQPEvZIIPBCAAAQhAAAIQgAAEMkcAxT9zTUqFIAABCEAAAhCAAAQg UEgAxb+QCT4QgAAEIAABCEAAAhDIHAEU/8w1KRWCAAQgAAEIQAACEIBAIQEU/0Im+EAAAhCAAAQg AAEIQCBzBFD8M9ekVAgCEIAABCAAAQhAAAKFBFD8C5ngAwEIQAACEIAABCAAgcwRaOno6OiqRa1s vqa9vb0WWWcuT1ilb1JYwSo9gfQx6VewSk8gfUz6FazSE0gfk34Fq/QECmO2trW1Ffru8uns7DRJ 4bEJbYA6ZrlpKym3GdPCKqkn5YfBKp9H0hWskujkh8Eqn0fw6uabb3aXl1xyiTvCymFI9Q9WqTDR r9JjghWsEgmk0YGZ6pOIkEAIQAACPZvALbfcYvSHgwAEIACB5ieA4t/8bUgNIAABCEAAAhCAAAQg UJQAin9RRESAAAQgAAEIQAACEIBA8xNA8W/+NqQGEIAABCAAAQhAAAIQKEoAxb8oIiJAAAIQgAAE ICMjYIYAAEAASURBVAABCECg+Qmg+Dd/G1IDCEAAAhCAAAQgAAEIFCWA4l8UEREgAAEIQAACEIAA BCDQ/ARQ/Ju/DakBBCAAAQhAAAIQgAAEihJA8S+KiAgQgAAEIAABCEAAAhBofgIo/s3fhtQAAhCA AAQgAAEIQAACRQmg+BdFRAQIQAACEIAABCAAAQg0PwEU/+ZvQ2oAAQhAAAIQgAAEIACBogRQ/Isi IgIEIAABCEAAAhCAAASan0BLR0dHVy2qYfM17e3ttcg6c3nCKn2TwgpW6Qmkj0m/imc1bdo0Fzh9 +nR3hFU8q3AIrMJE4q9hFc8mHAKrMJH4a1gVsmlta2sr9N3l09nZaZLCYxPaAMEuN20l5TZjWlgl 9aT8MFjl80i6glUSnfwwWOXzCF61tra6S38/h1WQTvI5rJL5BENhFaSRfA6rZD7BUFgFaew8Z6pP IRN8IAABCEAAAhCAAAQgkDkCKP6Za1IqBAEIQAACEIAABCAAgUICKP6FTPCBAAQgAAEIQAACEIBA 5gig+GeuSakQBCAAAQhAAAIQgAAECgmg+BcywQcCEIAABCAAAQhAAAKZI4Din7kmpUIQgAAEIAAB CEAAAhAoJIDiX8gEHwhAAAIQgAAEIAABCGSOAIp/5pqUCkEAAhCAAAQgAAEIQKCQAIp/IRN8IAAB CEAAAhCAAAQgkDkCKP6Za1IqBAEIQAACEIAABCAAgUICKP6FTPCBAAQgAAEIQAACEIBA5gig+Geu SakQBCAAAQhAAAIQgAAECgmg+BcywQcCEIAABCAAAQhAAAKZI9CyYMGCrszVigpBAAIQgEBVCFx4 4YUun1tvvbUq+ZEJBCAAAQjUj0DruHHjYkvv7Ow0bW1tseFJAQsXLjRJeSelraTcZkwLq6TekB8G q3weSVewSqKTHwarfB7Bq/79+7tLfz+HVZBO8jmskvkEQ2EVpJF8DqtkPsFQWAVp7Dxnqk8hE3wg AAEIQKBCAtdee63RHw4CEIAABBqHAIp/47QFkkAAAhBoegKPP/64OeGEE8wzzzxjurqYSdr0DUoF IACBTBFozVRtqAwEIAABCNSVwFe+8hVzwQUXmI6OjrrKQeEQgAAEIFBIgBH/Qib4QAACEIBAmQS+ 9a1vmSuuuKLM1CSDAAQgAIFaEkDxryVd8oYABCDQwwgceeSRrsYtLS09rOZUFwIQgEDjE0Dxb/w2 QkIIQAACEIAABCAAAQhUTADFv2KEZAABCEAAAlEEGPWPooIfBCAAgfoRQPGvH3tKhgAEIJBpAlj1 yXTzUjkIQKAJCWDVpwkbDZEhAAEINCqBGTNm5Inmr6dOnWoeffRRM3v2bHP11VfnxeECAhCAAAS6 hwCKf/dwphQIQAACPYKA37TLj/bPnDnT1VuKv9zDDz+M4u9I8A8CEIBA9xNA8e9+5pQIAQhAILME HnrooYK6+bn+U6ZMMWeddVZBOB4QgAAEINA9BFD8u4czpUAAAhDoEQS8kh9X2WLhcenwhwAEIACB ygmwuLdyhuQAAQhAAAIQgAAEIACBhifQYrdV76qFlNquvb29vRZZZy5PWKVvUljBKj2B9DHpV/Gs pk2b5gKnT5/ujrCKZxUOgVWYSPw1rOLZhENgFSYSfw2rQjatbW1thb67fDo7O01SeGxCGyDY5aat pNxmTAurpJ6UHwarfB5JV7BKopMfBqt8HsGr1tadM0L9/RxWQTrJ57BK5hMMhVWQRvI5rJL5BENh FaSx85ypPoVM8IEABCAAAQhAAAIQgEDmCKD4Z65JqRAEIAABCEAAAhCAAAQKCaD4FzLBBwIQgAAE IAABCEAAApkjgOKfuSalQhCAAAQgAAEIQAACECgkgOJfyAQfCEAAAhCAAAQgAAEIZI4Ain/mmpQK QQACEIAABCAAAQhAoJAAin8hE3wgAAEIQAACEIAABCCQOQIo/plrUioEAQhAAAIQgAAEIACBQgIo /oVM8IEABCAAAQhAAAIQgEDmCKD4Z65JqRAEIAABCEAAAhCAAAQKCaD4FzLBBwIQgAAEIAABCEAA ApkjgOKfuSalQhCAAAQgAAEIQAACECgkgOJfyAQfCEAAAhCAAAQgAAEIZI5AS0dHR1ctamXzNe3t 7bXIOnN5wip9k8IKVukJpI9Jv4pnNW3aNBc4ffp0d4RVPKtwCKzCROKvYRXPJhwCqzCR+GtYFbJp bWtrK/Td5dPZ2WmSwmMT2gDBLjdtJeU2Y1pYJfWk/DBY5fNIuoJVEp38MFjl8whetba2ukt/P4dV kE7yOayS+QRDYRWkkXwOq2Q+wVBYBWnsPGeqTyETfCAAAQhAAAIQgAAEIJA5Aij+mWtSKgQBCEAA AhCAAAQgAIFCAju/4Rb64wMBCEAAAj2QwIwZM8y1116bq/mCBQuM/k455RTnt2nTJvPpT3/aXHLJ Jbk4nEAAAhCAQHMQQPFvjnZCSghAAALdQmDq1Kk5JT9YoF4IvPvGN77hTzlCAAIVEtiyZYtZunSp WbFihdmwYYPZtm2b6eqKt7uiuPPnzy+r1PXr15tBgwZlJm1LS4vp06ePq9PIkSPN6NGj3XVZFewh iVD8e0hDU00IQAACaQlI+Q8q+sF0xx9/vFE4DgIQqIyAlPuVK1eaJ5980syePdu8+uqrTvnXV7Uk xV/h/fv3L6twvVT4BfulZtCIaXv16uVYSOmfNGmSOeaYY9yfjBHopQBXSADFv5AJPhCAAAR6NIGL L744UfHv0XCoPASqRGDVqlXmtttuM3fccYd57bXXzOrVq92I//bt2xMV/yoVn4lspNzrRWbAgAFm +PDh5pFHHjHnn3++Oe+888q2LJkJMAmVQPFPgEMQBCAAgZ5IQPP3L7300siqa8Qfly0C9957r9E+ DUOGDDHHHnusOffcc7NVwQasjZT7e+65x1x//fVO6d+8eXMDStn4IunLyNatW93fmjVrzJIlS8yy Zcuc0v/hD3+48StQBwmx6lMH6BQJAQhAoNEJjB8/vkBE+aH4F2Bpao8LLrjA/OxnPzOnnnqqGTFi hPnUpz5lUEJr36RvvfWWufHGG828efPgXUXcmgb1/PPPmxtuuMG9AFQx68xkheKfmaakIhCAAASq R+Dqq68uyAxLPgVImtpj7ty55uGHH3Yj/Joa8aUvfckceeSR5nvf+15T16sZhH/ooYfMM888YzTy j6suAa1FeOKJJ8zMmTOrm3FGckPxz0hDUg0IQAAC1SQQpeSffPLJ1SyCvOpMYPLkyW5UNDglQkrT hAkT6ixZ9ou/7777GOmvYTNv3LjR3HXXXTUsoXmzRvFv3rZDcghAAAI1JRCc7qNzrPnUFHfdM3/l lVdMZ2enOeecc+ouS9YFePbZZ7NexbrXT6P+uEICLO4tZIIPBCAAAQhYAlL0b775Zsci6gsAkLJD QCYlr7zySpT+bmrS5cuXx5ak353+opwWswY32AvHacS0kvGaa64Ji5r6+qqrroo1Xyqzw3Gmh7WO AldIAMW/kAk+EIAABCBgCcisp1f8meaT3S5x++23m8suu8z87ne/MwcffHB2K9pANdOUqjgn5T1q jY3ip1H865FW94e4ciV3pYq/7PJHOfGIU/y1MRqukECrPusluWLhpH2HAKzeYVHsDFbFCL0TDqt3 WBQ7g1UxQu+Ep2F1xBFHmLFjx7pEOvdp/PGd3NKfkbaxWGketL7mLFq0yAwePNgJRxt1TxvFlSLL NHFtIEU3ydUrrSxBxcmcJG/asLi801igikubpuwspm2Ne4sSEFU4KTwJWkdHR9lpKym3GdPCKqkn 5YfBKp9H0hWskujkh8Eqn0fwSmYeNb/fPwtgFaSTfN4MrPRF58EHHzQvv/yyq8z69evdC4BGnTWS KssoSSO5QQKVPH+bgVWwrjqvpL7hvILX2pXX/96C/jovpvjXK22/fv1iZQ7XoZzrOB4qt5iLS1ss XSXt28hpmepTrOUJhwAEINCDCegTvhR/XPYIPP3002bHjh15c8Y1BaVPnz5Gir+czH2mVfxdAv5B AAINTQDFv6GbB+EgAAEIpCOgkcBio4E+J8WTwpfGXXTRRS6aj19K2nD+4bQtLS1Gf7j6EJDN/vD8 6OBIpR/1r490lAoBCNSCAIp/LaiSJwQgAIFuILBu3XqzZk2nkc3qbdvTKfISS1vc91kWb1UkSfQN G9abzVu2JkWJDYsqt7V3bzNg4AAzdOhQM3jQoNi0BECgEQloqpTWSOAg0CwEUPybpaWQEwIQgMAu Aho537Bhg9mwcZNT/Ddv3pJ6BL8aEDfacqvlevXqZTRPd5PNs2vUSDu/fIj9ClCt3MkHArUlINOa l156qRlvp8PpBYBpUdXn/eijj5pBMYMCCxcurH6BGc8RxT/jDUz1IACB7BHYvn27Wb26w6yzCzGT zAI2Q801hch9sbBzy/VCM3DgQNO7d+9mEB0ZIZAjsGDBAmeyUmYreQnIYanKyXXXXWdaW6PVVXHH lUYgmmRpeRAbAhCAAAS6iYAUZZnsW7N2rdELQFbmyGsa0GprDW63TbuZAQP6G30JwEGgGQlEvQRo Twy9EOBKJ6ARf1z1CKD4V48lOUEAAhCoOQEp/hvsnP5SFsaWErfaFeiy8iZbHn+nxJ1122A++9nL zRtvvPFOgD3Tl424Ub+8iBEX9UqrFzSZVyzH1UvmepXbrKyKjTjHvQSU0ydIA4FqEEDxrwZF8oAA BCDQjQSkIKd1UvqlfA4fNsz06dsnbbKqxNu8abMbxdcmO5rGk8aVUrc0+REHAo1GoNjLQqPJizzZ IpBJxX/ZsmVmwfz5Zq39FL5jR7qHjZpV1ioGDizPqkQlaZcvX2Zenrdz85RSu1cl5Zaa1uoPbv7t 3nuPNUOGDilVVOJDAAJ1INDWNtTsvttuZqBdHNdLP+JudFLida9YsmSpXYS8JnXJN910U8HoftDM ZOqMdkWsV1otPBw3blyp4rr49ZK5XuU2K6vDDz/cJCnymt6jRb/aD0PmUXEQqDeBTCn+W7ZsMQ8/ 9JB5/rnnzKuvvOp21Stl9GibnS8r03LluErSbrZy9+vbt5xirQm/7pNZOsMgu6X7PuP3MZMPPth8 4IMfMEPb2sqSm0QQgEDtCfS1I/yD7W9WpjLrtWBW5a5bu86st1aIttvpOjgIZJ2AV/aZ15/1lm7O +mVG8dfCsF/eepv52U9/Yua/9vrORW+mxT7s0i8Q06fochfKVZJWLyflLmSrpNxS0+6wfLSY8Kk/ zzZjZs0yq1euNB+/5GLT3t7enL0fqSGQcQK9evU2fVr71E3pF17Ny9efvjZszzhvqtczCUjR158U fY3q6xwHgUYlkBnF/4E/PGBu+P73zZK33zaTDjzQHHvssWbkiBGmVwmKfyWLiypJ22HN8rUPK095 rqTcUtNq1tSazk7zF/tF5cknnzQ3//h/zcAhg81F9mZX7qK7Rv1hIBcEskBAL+pbt211L+z1GvHX YlH9lfL1NQvsqUPPICC7/ZrKU6rr06eP20gvKl14N+VgHA3YJbl6pZ05c6bRngaN5LQ/CK6QQCYU /+XLl5sf/+j/mbcWLzYHTD7QXPGFz5tjjzsubyTa/1jCI/p6GLVYLi29ermpQW2BqSsurCXdlvKV zItsprmN2jRIiv/3v/s985gd9f/lrbea4+xL1kGHHFLYu/CBAATqSkBfQt3uvna90yBrH7+lJf0X 0MoF73ILetesWev2G9BLCA4CWSNQjtIvBnvuuWfs2gAp70kKfBLDZkybVJ9Kwvbaa69Kkmc2basU 1iRXLLwR0s565BHz0otzjaaiXPDRjzqlXwq+ZJfyvn7dOmfzuo/93Nxmp6X4t0BtGqOFwJp3OmrU KLsIbahLowdUh7UnvaZzjRlsR7T1MtC3b/E5+M3AKtxe5ch84OTJ5rJP/rWd8vNn8+aiRea+3/3O 7DV2bDjrxOtyyvUZktaTKH6EVXFGPkazsNL9SfeutE712mzNSuqrYr++3TcCZtV+u9/AZncvlVWf NE4DNKqbFgJHfaFoljYK1hWZgzSSz3sSqxNOOCFW8U+mRGhaAsccc4yL2pP6lSpcrL6twRHuMEwl TgoPxw9eS3EuN22p5WpOv0a2NE/+lFNPzY306yHytp368+ADD5g5z89x8ij8yKOPMnYoyjxiP03N sn960BxmV+afceaZ7i389ddeM7+5806zaOEbZs+99jTvee97zaGHHZY4naVUmevFKlhuJTIfZBf3 7mnfpmU96fXX55fU1pWU2539qlqsKqlvJWlhFWzB5PNmYqVpM1vs/S6t031wk1W8Nchhv22mTVaV eCpbf2mdBmwGDBjgFiOHpw9W8luoV9pm6le+jWDlSRQ/VsJq2rRp5u677zbr7e7buOoT0A7g559/ vsu4u3TRYC0q6Ru1TpuJqT6CpJF9PSiCC02l0P/x8SfcNCBNp5GpzqVvLzGjRo9ypj5/9pOfmtl2 rrpeGrRgVWnPsj/G39xxp/nJ/91i3Nx766dRq912393ssccewXbt0ed6yRph11C89upO60k9GgaV h0CDE5DyvX17egW8wauDeBBoegLHH3+8M/H5hz/8IXauf9NXsk4V0PqJKVOmuL9Svo7WSdxuL7Y7 J3zWrHLbrdIvF/40vHHDRjNnzhz3OU0PvvXr15lnnn7arQV45eVXjEb2pfTLLbbrA555+hmjT9KP PfaYU/rlrxGbF2wey91omXxwnkAva6ZPXPXShYMABCAAAQhAIB2BYXZDvcsvv9xoHwB95cJVh4BY HmZnaHz2s581I0eOrE6mGcslEyP+cW3S2qfVNXxbe5vp7Og0egscvdsYZ9d69BhjxowZY1bYhcGa Mzvcjl6PHbu3+2ogU1wvvvCCmwKkTrSb3fxGtrBxEIAABJqBgL7IhQ0ZNIrcDBY0SksgRz0J6Dc6 1Zr+XL16tbntttvM3LlzzapVq+xGohucFSz9TnDFCeg+p9kemtozfPhwc8ABB5gLLrjAnGqndYsx rpBAphX/QXanynedeKKZ//prZt68eWaIVd5PP+MMM36ffexU1xbz/g98wPnJrOXBhx1qTrI762lr +w+d+2Gr9G8wb731llX6dzenv+8MpvkU9h18IACBBiKw8wHY2z0A+9pFvG6X3u6d0l+chtVl9IVW my16Bad4ImJAIJsENKB49tlnu7WFMpH90ksvGVkplE6S9CW9VFPcQXpaIxRePxMMTzpvxLRS7qW3 yUDLpEmTnCn3o48+2gwZMiSpKj06LNOKvzr3pAMmmYsvvdQsstZnBg4Y6K41uq/O8sFzzjYHHXSQ fQhtNuPsy4A+C+mrwNF2Jbh+kEuXLrXz2EeaiftPNAPs2yQOAhCAQKMS0FRHLWIbu/feznJZo474 y/qa5t2+8cYb1nrPWvfFtVGZIhcEak1Au2qfdNJJbqRaSr8W+2oKctKIv3QTzVgoxyl/DYqW4xox rXQ56Xqqk5T/0aNHl/1iUw6TZkyTOcVfb8Jh05v77Luvs0DTW7tY2i3svWk5zbE7/Mgj3A9MCr9M yOmBpAfmJPu5SOnkrwdqsQUiUeWm7RBKWyz/uLwqLTfMKq6csP+mjckjEuH4XEMAArUloGmJe1gj BBr9amSnLxHaU2B3O4Vy6xa7zwBWTRq5uZCtGwhIz5DxkLQGRJpp7x+Pr9aWanw5HIsTyJTir7n6 d//mrrIXykj5LneRTSVpV61aaeemjSjeWhExKim3krTr7N4ILHiOaBC8IFAnAr3tyJffo6ROIpRU rGSVgQAcBCAAAQh0H4GMKf47zM033VT2gg7NqSt3MUglaSuZN1dJuZWk1TxdLUrCQQACDULAzudv 1Ok90YQabQFCtJT4QgACEMgSgUwp/nqMDB46pMCsZ9oG0xeDsEnQ7kirhW7lTrmpl8za7Xjt2rVp 8RAPAhCAAAQgAAEIQKDOBDKl+Etp/+SnPuWsWpTDVVYmZBKqHFdJWi3o0aKUclwl5VaSdo1V+m/5 8c1m3ksvliM2aSAAAQhAAAIQgAAEuplAphT/Xr17manWdmuzbc/8ht1VeOy4cWU1fb0WzKxYscKt pyhLaBJBAAIQgAAEIAABCHQ7gUwp/qKnKTPlTpupV9o+TSizWDXXfOJu/21RIAQgAAEIQCCRgNba adrs888/b15++WWjQTVZ60sy59nR0WHa29sT840LVN7lWv5qxLTSQ2SUxdvxP/jgg505dvSTuB5g TOYU//iqEgIBCEAAAhCAAAQag4Ds9WvTrjvuuMPMmjXLvPLKK07xl8W9JMW/MaRvDClkkMVv4KVd e0+2G7Gee+65ZsKECWWv2WyMmtVOipYFCxY0/b7Q3/6Pb5nfTZ/uTMP9/qEHa0eLnHMEZInoi1/4 R/PMU0+ZI446yvzX/3wnF8YJBCBQOwIaIdxoR+20+ZXOvWtvbzP7T5zYNJvXbLR7gbz2+utu/xRf Bz3Eh1oDDQPsXgTlWljzeXGEQCMTkGKvEf4f/OAH5sEHH8z7HTSy3I0um/Znet/73mc+/elPm3F2 CjUj/4Ut1iowca6S+ePducGEtmZW4+pPn7+abY5/d7IKtnUl7avPkf5zoY5J/ShYps4rKbcZWVVS 30rSwirc8+Kvm4mVXrpXrFxppwesi69Qk4ZI2R9hd1YfMXx4wQtMJb+FeqVtpn7luwysPInix0pY LV682Ey3A5b33ntvblPR4iUSoxgBmRm/++67zb52A9Yvf/nLRsZTStFPgvlX0r6NnLZXsJKcQwAC EIAABCAAAQjUloDm9N96660o/TXAvN7uBn7LLbe4aVQ1yL7ps0Txb/ompAIQgAAEIAABCDQTAY30 azQaVxsCb775pvntb39bm8ybPFcU/yZvQMSHAAQgAAEIQKC5CDzyyCPNJXATSnv//fc3odS1Fxmr PrVnTAkQgAAEIAABCEAgR+B1u7A9zo0fP97oL8ppUfDMmTOjgpxfI6aVYDNmzHDylfNvypQpBWt+ fD7WQI3RX5R78UU2GI3iguIfRQU/CEAAAhCAAAQgUCMC69bFL86fOnWqufjiiyNLluJ/qt2oNM41 YlrJWonif9VVV5lBgwZFVllz+W+++ebIMC2wxRUSQPEvZIIPBCAAAQhAAAIQqBmBJDv9GrWXAh/l ktIpfr3SynJOnMxR9SjFTyP+cdYak14otm/fXkoxPSZurx5TUyoKAQhAAAIQgAAEIACBHkwAxb8H Nz5VhwAEIAABCEAAAhDoOQRQ/HtOW1NTCEAAAhCAAAQgAIEeTADFvwc3PlWHAAQgAAEIQAACEOg5 BFD8e05bU1MIQAACEIAABCAAgR5MAKs+PbjxqToEIAABCEAAAhBoZALXXXed6d+/f6SISXsaRCbA 06D40wkgAAEIQAACEIAABBqSgBR/XPUItBbb4KBYeJIo3ZV2y5YtTgxv37a7yg3XvaeVu23bNodA x1LrXmr8IGvSBmkkn8MqmU8wtFlYyTb1xo0bg6Jn5lz3cNVtzZo1pnfv3gX1apY2CgqOzEEayec9 jVUcjU2bNsU+U72e02hpN2/eHCtznKzd5d/T+lWx+rbGbYqgBlHipPCkRuvo6Cg7banl9u3b14nS 0tLijuXKXGq5wfpXkrY7WVVL5hUrVuS20G5tbS2prXsaq0rqW0naZuxXldS3krTNxEov2lu2bg3+ lDNzrnv4gAEDzNChQ3P3F1+5Stq3XmmbqV/Vm3NPY+V5Rx01rSVOjymm+Ncrbb9+/WJljqpjd/rF sSwmQ73uG7Uul8W9xVqecAhAAAIQgAAEIAABCGSAAIp/BhqRKkAAAhCAAAQgAAEIQKAYART/YoQI hwAEIAABCEAAAhCAQAYIYNUnA41IFSAAAQhAAAIQaB4CvXr1Mjt27IgUeMGCBWbGjBmRYcXm+Ncr 7cKFC2NljqxIN3hGGQjohmIbvggU/4ZvIgSEAAQgAAEIQCBLBNrb282qVasiqySlXwp8lCum+Ddi 2qh6dIffsGHDuqOYpisDxb/pmgyBIQABCEAAAhBoZgIHHnigeeyxxyKrIKU/TvGPTBDwbMa0AfGr ejp58uSq5peVzJjjn5WWpB4QgAAEIAABCDQFgfe+973GmyBvCoGbUMgzzzyzCaWuvcgo/rVnTAkQ gAAEIAABCEAgR+D00083++yzT+6ak+oSGDdunDnrrLOqm2lGckPxz0hDUg0IQAACEIAABJqDwL77 7msuu+wyt1ldc0jcPFIOGTLEXHrppWbixInNI3Q3Ssoc/26ETVEQgAAEIACBRiNw7733munTp5ut dkfoD33oQ4yUdkMDaYfdj33sY2bJkiXmV7/6lVm6dGk3lJr9IkaNGmXOO+88c9FFFxkxxhUSQPEv ZIIPBCAAAQhAoEcQuOCCC0xra6tT+F955RVz4YUXmptuusmcf/75PaL+9azk3nvvba644gozduxY 8/DDD5sXX3zRLF++3GzcuDHW1Gc95W3EsmUWdcCAAUYK/wEHHGCmTp1qzj33XMeUNRTRLYbiH80F XwhAAAIQgECmCcydO9cpnD/4wQ/Mhz/8YVfXBx980I1Ao/jXvullZ15Tfi6//HJz8sknG7WHV/yT zHZ2dHQYmQMtx23atKnskfBGTCvFXyP7o0ePdor/QQcdZAYNGsTC6YTOgeKfAIcgCEAAAhCAQFYJ yNzhsmXL8qqn+dFHHnlknh8XtSOgUenBgwebY4891v2lKUmbZWnxajmus7PTtLW1lZPUNGPasiqa 8UStasgkVyy8EdJu2bLFieHfkJtB5jC3ZpR527Ztrho6lip/qfGDvEgbpJF8DqtkPsHQZmG1fft2 NxUgKHtWznUP1zSHNWvWmKhdN5uljYLt0QwyP/roo+bOO+80ixcvdkqhrKGUK3e56cSMtMGek3wO q2Q+wVBYBWkY05r05idYSeH5WeVf6VNUuWlLLbdv376ucD+fq7vKDda4VJmDabuTVbDcSmResWKF mxeq/DQ/tBTmlZTbjKwqqW8laWEV7O3J583ESi/aW+wizCw63cM1X3fo0KG5+4uvZyW/hXqlbZZ+ pakRffr0cdMjduzYUfI9vRpt1CysfF11pF8FaSSfwyqZTzC01qww5xmkzTkEIAABCECghxHQgsgb brjByLrPoYceaj71qU/1MAJUFwI9hwCKf89pa2oKAQhAAAIQyBG49tprjTaSCjp9cXnrrbeCXpxD AAIZIoDin6HGpCoQgAAEIACBtARks18mJDXaL2syM2fONA899JC5+uqrXRYzZswwejnAQQAC2SGA VZ/stCU1gQAEejKBLmO8gYOejIG6pyegaT0//OEPnaJ/zTXXuLn92vjokksuyWUi+/L+RSDnyUlV CchAiTbw0tq5DRs2GK3jSfotK+78+fPLkmH9+vXO3GU5iRsxrdYFaX2K1qmMHDnSmfXUNS6eAIp/ PBtCIAABCDQNge07thvZ2W6Wh96mTRuNLBTh6ktAFnz0550WFnqnuf8a9cfVhoCU+5UrV5onn3zS zJ4927z66qtO+dfvOEnxr8Sevl4qZJCjHNeIab0dfyn9kyZNMsccc4z7k8ERb/ClnLpmOU15rZ9l ItQNAhCAQBMS2Lx5i1lhlYgWu6FNXzvipQdiIzpZjZGsK1etMt4Uc6VyLliwwCmowZHqSvMkPQRq TWCV/Q3cdttt5o477jCvvfaaWb16tRvx1wtxkuJfa7maKX8p93qR0dqU4cOHm0ceecTtOn3eeeeV ZG2wmepcqawo/pUSJD0EIACBBiAgJXr58hVuFH3gwIGmd6/eDSBVvgh2NpKTT1MGZL5RI4jlOq/s a176zTff7LJB8S+XJum6m4CU+3vuucdcf/31TunfvHlzd4uQifL0grTVmjfWn/b/WLJkiduUTiP+ fjfqTFS0ipXIhOJvX/h2OtsBcN1IwOPONUA3lk1REIBAAQEp0suWLS/wz4qHV/ZvueUWpqBkpVF7 aD1kOenGG2808+bNY8pbFfuApkE9//zzbsH6lClTqphzdrLKhOLfr19/N5dLD71qfTrOThPXriYb Nqy30wpaTL9+/WpXCDlDAAI9moBX9m+66SajHWZxEMgCAVlPeuaZZ1D6a9CY0gWfeOIJZ6Xq+OOP r0EJzZ1lJhT/cePGuTle+lQ276V5ZtSoUc3dKk0gvRYkLV78ptGuyXvvvXcTSIyIEIBAqQQ0f7a3 XSugj3uam99d844XLlxoZs2aZUod2T/llFMiqyhFoB4LGlmEGdkckZ49jZXmpDO9J7IrVMVz48aN 5q677jIo/oU4M6H4H3f8caZ9+DCjeaM/++lPzX77TTC77b57YW3xqQqBtWvXmtt/+Suzws4nHj1m tDnppJOqki+ZQAACjUGgf//+pm3oUDNkyJCclaAtW7eYzs41Zu3aNW5xbq0llfKPg0BWCTz77LNZ rVrD1Euj/rhCAplQ/Cfst585225E8v9u/KF56MEHzLD2NnOs/bwzcuQo07t3essW9bJRK5u8by1e XNg6KXy6U2aN+MnU23NPP2tuv+2XbrT/pJNPNsced2wKSYkCAQg0A4FBdmGwrGMMGzbMWsrob++h OxcJb7OLEQfaUcp+9iufrJFstHNpa+X0FVe24/WnqT4a+X/ggQeKTvWRzfkop/uWFvuV4ypJq5cX 1aUcV0m5zZi2p7FKMrsrM6r6i3L66pa0qVojplU9tE9Eue6qq64yGoyIcjOsuVn9RTl2oI6iYkwm FH99wv34xz9hVthFbfdOn+5Gox9/7HG3mYN/aEVXP9+Xz8H5PMJXO6yd8A77AF34+gLTq7W3mWo/ q19y6aWmrb09HJVrCECgCQnofjnMfj0dNWpkwYO21YbpC4Di7OiyJjmXLnPTf2pdzfHjx7sXgCuu uMKZO/TTf+Ie9rWWh/whUA0C0jfinJT3uE3T0ij+9Uh7sh0EjCtX9axU8Y97cRePuHsBaz6je1ir RgaSXLHwRkk7aPAg84mLLzLtVgl98k9/MoveeMOssvPQm8HpIdqrJf2XiXrWSbbB950wwRx17NHm fWeeafYeO9Z9BShVpmbpV8F6IXOQRvI5rJL5BENLZSUzgJq/WgunEf62oW0FSn+wLM1Nbrej56tX d7gNw4JhlZ7rIa66ySxf1KCNvkLoBUB/b9h7/M9//vPcUWUnsUwKKyY3aYsReiccVu+wKPdM6x3i OOo3kuTqlVbrFeJkTpI3bVhc3mnWScSlTVN2FtO2xr1FCYgqnBSeBE02mstNW265h9jtx9vbh5kT rQmn+fNfd/LvsA/JtE4dqFwLNZWkLbe+qlcl5ZaetsUMsfN+97KLeSfYdRQTJ05MizYvXiX1rUe/ kvCVyFyvtLDK63aJF83ESiOFW6zN6lq4wYMG5+b0x+WvBb9a1D940KCqK/7KWy8WQ+19JrwYN/w7 OuSQQ8w3vvENJ+bXvvY1Nx0o7pkTThtXtyj/StI2U7/yda+kvpWk7WmsPO+oo1tjEzM1rZjiX6+0 0p3ifn9RdSzVLy7vNDpbXNpiMlTSnxs5bSam+gQbb2jbUHPyKVPNiSdNcTvgaV56WqdRJj1wynGV pF20aFHZlnEqKbfUtC2mxQwcNNApBurUOAhAIFsEetspfL2sid5izln7sXEbxfnpQI0iD3JAAAIQ aFQCmVP8PWiNFpWqxOthVu6bYSVppURrilI5rpJyK0lbjqykgQAEGpvAtq3bUs3b37FDu2XGz1Fu 7FoiHQQgAIGeS6A5Jpb33Pah5hCAAAS6jcC6devcJohJ0wkUtmXLZvdFtdsEoyAIQAACEKgKgcyO +FeFDplAAAIQaEACWmRfC+cXBva183VlujPKbdiwwXR0dNZs8yHVTV8jcRCAAAREQDt2D7JriqIc +31EUUn2Q/FP5kMoBCAAgYYiIMW4v1XMdZSFn2q67XZN1CprrafF5j3cWtDRwjm/yHarXVC8adNm Z8N/tTXekPRVoFyZfN1Q/MslSDoIZI/Addddl7sPhWu3wO7zgSuNAIp/abyIDQEIQKCuBKQcD7Sb bEn5l/GCaiv/Mqe5zO6JoqPMdvbrt3PjnE2bNhop/GvXrjNJNsjLhaPNFvWVQVZ9VEccBCAAARHQ iD+uegRQ/KvHkpwgAAEIdAsB2bgfMWKEMXavkvV26o1eALTgtjSn+NZWV8SsGpn61d+KFbXaC8UX 2uWUfI3w62Vmr732jLTfX1q9iA0BCEAAAnEEUPzjyOAPAQhAoEEJ7FSU7UZa7fuaFVb5X7z4LTvv fnVJ0naZLqn9dlrPTiXcT93RWLum+sg5P70Z2HcEjcKrXL1k9LJHecu19OptunQe2FhIJkFbTC/n 1dKy84VkVzY2rY1vveTby4a1t7eZ0aNGm2HD2t1oP9N8RBUHAQhAoDYEUPxrw5VcIQABCNSUgBRk bdaz25gx5q233jZzX5prNm3cnLrMneq4lO8Wp4TvTOh9pbjvVM59hk7Pd9q7jbNL6VeYYvpUkXHz PHem8F7aKfikKSea0aNHuTm8KP2eDEcIQAACtSGA4l8bruQKAQhAoOYENAqvXXT1AqAR9jVr19a8 zGoW0L/fGNPPyt+nT59qZkteEIAABCAQQ4AVVDFg8IYABCDQLARk6m6YtcLTbE4yx5npa7a6IC8E IACBZiDAiH8ztBIyQgACEEggMMzu/H3AAZOsBZ6+CbHeCZJpznJH2WXHXwtxy3Hhcifsu6+R7DgI 9DQC+v3p9xDlZsyYEeXt/PxanLgI9Uo7c+ZMc+2118aJVRd/mSPGFRJA8S9kgg8EIACBpiIwcuQI c+KI4827jj8uldxr1qwxQ4cOTRU3HOmNN94wY8eODXunug6Xqzn9zOtPhY5IGSOw5557mjgb9FLe kxT4JBTNmDapPpWE7bXXXpUkz2zalo6OjvC6rKpU1uZrrTUwkpMGJqzSUNoZB1awSk8gfUz6FazS E0gfk34FqzgCl19+ufnFL34RF4x/FQhceOGFRpt/oYvmw2xtsxu0xLnOzk6TFB6XTv664ZWbtpJy mzEtrJJ6Un4YrPJ5JF3BKolOfhis8nkkXcEqiU5+GKzyeSRd9TRW06ZNM3fffbdZv359EhbCyiSg 6Yjnn3++S40umg+Rxb35PLiCAAQgAAEIQAACNSVw/PHHm5NPPrnstTY1Fa7JM9f6iSlTpri/Jq9K TcRH8a8JVjKFAAQgAAEIQAAC0QRk0UrTfQ4//HC3cV10LHxLJTBgwABz2GGHmc9+9rNm5MiRpSbv EfFZ3NsjmplKQgACEIAABCDQKAS0B8fUqVPN6tWrzW233Wbmzp1rVq1aZWQ1a9u2bTt3zW4UYRtY DhkHaG1tdZbGhg8fbq2bHWAuuOACc+qpp7rdxhtY9LqJhuJfN/QUDAEIQAACEIBATyUwePBgc/bZ ZxtZ+HnyySfNSy+9ZJYvX242bdpkduzYEYtF4dq0rxynlwopymmdZFqyZEle9N12280p2HmeRS5K LTeYXVJavUCJxahRo8ykSZPMsccea44++mgzZMiQYBacBwikb/1AIk4hAAEIQAACEIAABCojILO6 J510klOkpfRrsa/s+yfZ61+6dKkZM2ZMWQUr/1I2zbvvvvvMN7/5zbyyrrzySjdFKc+zyEWp5Qaz S0orxV8vMqqTlP/Ro0eX9GITLKennKP495SWpp4QgAAEIAABCDQcAS1G3WOPPdxfGuEWLlxoxo0b lyZqQZxSLR9qOpKmIvk9B8aPH2+uuOKKgnyLeZRabjC/StIG8+F8JwEW99IT/n97ZwKt1fT+8R2t ZRm7yJBi/f0QkSmRMqyFUIaQEiFRpiJj5jEyhcxFGUslIbMylzlDFFYyrGUoylBYpsW6//PZel77 fc95zz33vt3p7fus9d5zzp7O3p9z7j7P3vvZe4uACIiACIiACIiACCQSQPk3QfGXNG4CUvwb9/NT 7kVABERABERABESg1giw7KjJxRdfbKc6NlICUvwb6YNTtkVABERABERABESgtgn07dvX32KDDTZw Ye9/bd9X6dcOASn+tcNVqYqACIiACIiACIhAWRBA+UfxlzR+Aprc2/ifoUogAiIgAiIgAiIgArVG AHOfHj161Fr6SrjuCEjxrzvWupMIiIAIiIAIiIAINDoC9Pizuo6k8ROQqU/jf4YqgQiIgAiIgAiI gAiIgAhUSaBJtDZrZZWhaiHA77//7u644w6/SUXSmrA33nijv+txxx3nVlxxxcw5YKmpCRMmuB13 3NG99NJL7sILL3Rrrrmmu+CCC/wwla1FmznBIgHHjh3rd9m7/PLLYyEs73jYJhzrr7++22OPPVxF RUUsfJLD//73Pzd+/HjXoUOHJG/v9sYbb7jevXu7zz//vGiYmnjcdtttfjOMlVZayR/ZAQ+erDUs EQERWLoEbrjhBv//xf9YKLgjSfVjGI7zDTfc0Nd7SfUF6VBXUC8uDaHu+/jjj93QoUOLJjd37lz3 ySef+B0/27Zt6zbZZBO3xhpr+PBhfsLzoonJQwREQAREYKkRaJq2CUQpmyZk2WDir7/+cpMmTXLD hw/PKxD3HTdunFfUN9tsszy/qi4ef/xxxzbYlOuLL75wO+20k0/r5JNPdi+88ELqphfVKS8ftj33 3DOXXhj3vffec+HyV+SZco4ePdrdeeedrmPHjnnFSGLFdt3szJf2fCjf5MmTU8Pk3ajgIsxz6DVs 2DDHkl3slsdvwYIFrk+fPq5fv35u1KhRPmixuGE64fmxxx7rjjjiCM+lunHDdJJYhf5p56XctzHG Fau0tyHfrz5ZzZw50x1wwAGx/+NmzZq5l19+OeZuOQ/fSToYitUXpMOW9mFdEsa19LIeqd+6deuW l14Yt1evXl7p33LLLX2e2Pzn4YcfdhMnTnR77bWXC/NDOmlphemm5ZkOnaOPPtq9+OKLYZTceVrc XKAiJ6XErc/3Cs41kVLKW0pcscr+tMRKrIoRyPI/WK82/sccc4y79dZb3axZsxwfCZOPPvrIsSU1 /sjzzz/ve7VRhjfaaCPXuXNn785HEUHJHjJkiLvooosc2zc3adLEfzDxYwRg2rRp7pBDDsn1vuOO PPHEE+6dd97xvWVbb721D4u7pfvDDz+42bNn+3RxN/n55599D9p5551nTrEjS16Fy16Rt3333dfR MDHF/7fffnNPPvmke/31132P33777efoZTehHIxaIGFa8+bN8x9W/CkvEoYj/3PmzHGMloTy2GOP OT7a++yzj9t+++3dK6+84vMUhuEcJYL7hY2Xbbfd1isnNAps1IKP7IwZM9zmm2/utttuO9eiRQuf lOWFC/LSs2dPX8bDDz/c55PGBCxCsThhOUN/nYvAsk6AUVLqiw8//NBtscUWbpdddvFKdBIXOgQ+ /fRTt/HGG8e8qXceffRR3zHSpk0bt//++/tRVf7vqSsR/m+5Llyzm7qPOuSKK66IpYsDSj/p08my +uqr58Lccsstvh7goxSK1V/mRtynnnrKffbZZ75eplFAowV59dVX/Qgk9Q/lO+2009xqq62Wyyth rO4O6y7cJSIgAiIgAv8S+FdrrCca7dq18+Yvd911V14OxowZ493xv/TSS72i/8033/hhY3rZcUP4 MF1yySXelIcPIoJCibv1/Hz99df+HLdQqcRE5uyzz86F3W233dyUKVN8Gnzsvv32W3fGGWfk0vEe S/6gqGO607p169A59ZwPHB9heumRhQsX+g/3gw8+6PNw0003+WvcQ3n77bdjQ/30umNORJn4aJvs vvvujp71kSNH+t/yyy/vzLTp/vvvdwceeKBXBq677jrvH8a1NIodaSgglh69a9dcc42j54FGTatW rdwHH3zgw/DxRZE/8sgj/ZHnhbKCW8uWLX3P3PTp031Y+0Pemzat13aoZUVHEWgQBGjYm8yfP9/t vPPOOfNIzCT33ntv9/3331uQ3JG64fzzz3fUfe+//37OnRNG70jnkUce8fUHYbm2dKgjFy1a5O69 9968eHZB3bfeeusVrfvopKHDIVT6iXvSSSdZEnlH6gTqcIS80ZhhZIBGDnljxNbyRt2OiRF1HB02 9GhTr1EPkg5uU6dO9dc+Qf0RAREQARGIEah3TYtefX6huQ/mMHfffbfPLIoxHwJ6jRF6lVGSw54o FF3z94GiP3xM+PHx5Gg9QfjTS/3000/7Hm96zhDMULCpZ2QAoUcJ2/nw4+s9oj/YyybZ0pp/0pHG DSMMI0aM8N6UC5tXyobyTEOCUQ/cBwwYkEsC5Xnw4MF+PoGZPd1+++3O7H/56JlwTs888TlnngDl /r9o1IO5DvTSnXPOOT445Q3jWhp2DP1+/PFHr3DQcNlmm238B5pGD8zp6ScsygAjCFtttZVPAlOo Z555xvdMMlJDOWlcYetLryA9gHzkEcygaFiggEhEYFkkwP9pWEcVMkDRRzFGuTWhEc3/VVhf4EfH AOFRmhEa/CbUL82bN3f33HOPV5ypR7HBx/2EE07wwa699lrf425xwiN1H3VAkqCUM0q6ww47JHkn uoX1DPUA87EoE0LeyCt5O/HEE70bDY+33nrLn7PKyHPPPZf7VlAvps078JH0RwREQASWcQL1rvjT 807vMSYw9EBzRHBnqJoPCaY/1suP31dffeV7szjnQ2C9+1xnEXrBUDL50PBDUGrprTJByU5S+vF/ 88033cCBAy1o4pGJvKFgnnT99de7Ll26eGd6qMgD5TKbLBRpPu4mfBSx20X5ZxSEj9q7777rVlhh Bd9AIY1CsQYQeUfhtxEGjphJmWBuRG9ZMaGxQc8feeNHjz7KOrL22mu7QYMGeUX/tdde80P73Csc rcAcyRpVhRxR/FH6acBRPnoXed4SEVhWCYQKcBIDTPfMRND8UbBRxEPFnwY3o2tM9jWhgWAmNjQu qHeuvvpqX48QhjoD00qTyy67zE5jR+o+q2MKPemlRxhprImEdaLFp14O6xVMf0yoc8LGEnO7JCIg AiIgAukE6l3xJ3vYajIBDMWflSfsQ4bST29x4UeR8Cj/yJ9//umPxf6gJCNhGqTLdehGmCw9zijQ fIQLV+Agfig0Isy0CAWXEQ2bm0C4X3/91ZcNpTgpL2Fa9M7zsaXX/r777suNSoRh7Hyttday09gR e1gTRhjSBFt+E3brQ3kwltjv8gwOO+wwb3/Lx9n8LE6hsm/uHBnZwAaXnj3KRsONUR6JCCyrBKgr rL4wBmFnB41w7PFD4X+ycEWvn376yQexFXS4CP/vf/nlF/fPP//E6pzw/zU8D+9ndR+jiklidQr1 Iz311RXLW3j/rl275tXTjAgUk5VXXrmYl9xFQAREQASWEGgQiv/xxx/vzVJQjlnNx+xSMQuhB5ye 46RepqQe78InaxPDQnfMVOjVwkSInmwT6xWz66QjIwwo/WkfoMJ49I5jWsQ9sYtHKBMT6VB6q5qh z0oYfEhRlOGDHWtNhPuYYJZTlRQqIhaeXjZW+WEOhMnNN9+c94EubFRZODti3kUc5j7wbBlFkIiA CCQToL5gcmsomCzuuuuuoVNulI0GAZPukS+//DIXhnSYX4ONf+GqL1X9z1rdV2i/b4nT6dC/f3/f OWFmRuaH2R8dF2kLImByZHWixavOUYp/dWgprAiIwLJKoF4n9xp0hqU7derkbTk52rJz9FqhFGLm wpA2iiu9YPQCsTJMFknaAwBFmo8UvcwMI9PQ4KOTZvpi96qJfT9x6fWnF/3ZZ5/1STFRjYYL9qsI H3XyYHMbvGPwB0WZsAzvF7OxDYLHTo866ihvysQEXBoO1riKBczgQEMGpZ1hf8wKMN2BMxMQmQ9Q KPTgoSwQ1spPw4E8UCabV1EYT9ciIAL/EqC+QPG2+gITRWzdWQksFJRfFH7CMSmWBv7ff/+dC2L1 Dqv6INQ7NL4t3VzAhJMsdR/ziJhfgPkmc5ow+aPOps6gnmASfzGxvJn5JXljtNFs+ovFw529RuCD hOY/3kF/REAEREAEcgQahOJPbjAd4ePDMRQmwzKh99BDD3Xt27f3HyrbYIpwhcu2FfY0WY8/vVkW lo8jHyeUUCbAsoY2DQyWm6xK+LhUd2IvaTJ6wSoVfBgxX6I3HeUZW1tsVRn16NGjh/9gEh7/sAcO xZ8PKWFCCc2TiFNMmMxHeqeccoo3q2Jfg2KSlg5xGO1g5AJmzAUgT+SPDXto4CQJ92P+BnMCTIjz xx9/+IacuekoAiIQJ8D/JP9bV111lZ97xOR+JrNanWZHYjIplh59lih+6KGH8v6/mGBPPcR8Ixrk rMCDeSX/ywjphPWOd1zyJ0vdR4cKIwx02jDCyVwp6llGB88888wwudi5lfHKK6/M5Y263iYLF9bt YQIsMnDwwQf71eBCd52LgAiIgAgUEIgq+aIS2ZUW9avKI1r2saogRf1LuW9txo0U9kp+SVLKfbOw ilYFqoxGRiqjkY6822e9bzS6UMnPJBpZqIwaDXZZ7WPW+yYlbHGjBk9ltIJIUpCibllYFYts9y3m n+beGOOKVdoTzfdrTKysDir1nbR08kkkX4V1X12wSspbqeVNLlnVrqXcty5YJZWglDzXV1yxSnqS yW5ilcwlyVWs4lSWK2gH6DKFAD1k4cSzlKBLzYtJzPSWs1Y+owPhBl/VuQlzCehRw9yIoXB64Fgt qD6EXsju3bv7JTzDeQL1kRfdUwQaG4GlVQdVJ526rvuqk7fG9vyUXxEQARGoTwINYnJvfQJo6Pdm B0tMa0aPHu037Klpfk8//XS/HCD2stj9sjum7QtQ0zRrGo9lWrHn7devX02TUDwREAEREAEREAER EIFqEpDiX01gdR2cXnp+pQpL+rHTJz+TLKsYWdileWTH5MIVRZZm+kpLBERABERABERABEQgTkCm PnEmchEBERABERABERABERCBsiPQhIk8tVGqKF1XUVFRG0mXXZpilf2RipVYZSeQPaTeK7HKTiB7 SL1X9cuKeXEIo8wNWVhanOWuWW0rSVgpa/z48W6fffbxG2DW9L3CxHaXXXZx55xzTtJtquXG6lss uctqg0tLaiNNY8UGgSxJzIpnLAe/zjrruK222spvIrq08t9o0onP9/3PJQL230U1zzSTOjswsRKr YgT0P1iMTNxdrOJMirmIVTEycXexijMp5tLQWEVmspXR8rbFsuvdS8nz0oob7bNTee+99xbNJ/7R /kaVHJGsOsN7771XGS3R6+Pwh/NIUc9dV/ckLG+0k3cl6WeVMK7FYfUunlG0+Ih3KpZmUlxLo6qj sYoaO3RyV0ZLp/v7RUvHV0bLrOeYJqVTyn0bclzZ+DeaJpoyKgIiIAIiIAIiUFMCbAL6zjvvOHa2 3nHHHV24Dw69wZHi6fejYd+gTTfd1N/GNoSLlObE699//909+eSTvse+TZs2bv/99/cbWhLY4s6a NctvbsnqfIXy888/+57oYrtaRwqkY8M9eqrZh4M9PEzwYyNMyxvukaLrvbG4IB5z+chHGIbNQ3Fj M1D2MQoFd/zxI45ZbsycOdPvzzF58mS/ySr7D5ngVzhnkHl8ttkoeXrggQf8vj3cz9y5Fz/KEKZn 6VI+/NkslPmJYRlwZ68S7s05fsXmQ0ZKvYsaVn4fpXPPPdcnT1ie1XXXXedHLWwzREYweEfYWHaj jTZytn8I9zCBD/FZIIWRAxMLQ15+++03v4cJIzm8F926dXO2r5SFY0NVNj1l75W6FNn41yVt3UsE REAEREAERKDOCaB4olzed999jmWy2V167NixPh9sHIpiNmXKFMeqcyhqKGwICh6Kownnl1xyib9k d2waDxMnTvRh2ByP64ULF3p/wv3www9+07wwDUuLIxvjrb/++q5169ahc+7cFG3ygULJZpyh4B4K DQPCoDSzjPdPP/3kjxZm3Lhx3p/8sKGnlQX/bbfd1g0fPtyXJdohLNc6AAAL4ElEQVTrxzc0SAc5 9dRTvYkQ/ijy3MM2XEX55l72O/DAA/2O3cSjwYKiT6OLe4aNFxRo3KKRg1ia5Jv8kI9oZMArx7bz N3Eo90EHHeTgwzXn5ClJWB54r732cpT9o48+ygUhLyj6pvT37t3bm4WRHmWhYfD000/78FyTXzZ6 feGFF7xZ1qhRo3JpEQdGb7/9tvvuu+9cly5dYu8F7wvhOnfu7N+LYhue5hKtpRP1+NcSWCUrAiIg AiIgAiLQMAjQu0rPqim6KGa//vqr++abb3yP8q233prbwZqe3q+//tptscUWqZlH6WSXahR/hPTb tm3rHnzwQTdgwADvRo8yu9oX25uCkYYOHTr4sEl/aEygUCJ9+/b1CjVKLmJKub9Y8sd66GnkoByj rFqZCYLiaQoyYUgffxoMKNso4SYo7JSR+yLMNUDJR8I0zR930iZdFHaEcuOGks0oAH70vlMmeA0Z MsSnb3n1kaI/5Iuw3J/RBFYmhDVpRSZPPhj5oyGCwIJ0w7x4jyV/uBfKf6dOnfxoT8eOHX1jATt/ hKXOn3nmGTd9+vTcc+/Tp49/ll27dvVheI5Tp051m2++uW9AkuYFF1zg/RgtYuSCncppZLIMu70X jPTYe3HCCSf4ESHmc8ydO9fHres/UvzrmrjuJwIiIAIiIAIiUKcEhg4d6pVQFFHMeFD8Irt5r1Re dtllbs899/S9zvidddZZmTbLZE8cevgvvfTSXFl69uzpTU9M8UfZLKb0EwkzloEDB+bihyco2SiU 9KAjKLUozDQWyDs979UVJveaoFibIk9adh/z59r8cQvjWpjwSKOBUQB6x60BQhqYtjDReoUVVnDc pyqhcUKDhcZCKJj2MHKAwDQ0U7L7heHDc0x3UNzpwX/uuee8kk/jhZGfu+66y9EwxKxn0qRJ/kfc li1b+lECS2f+/Ple6eea58zz4PmQ9oQJE/x18+bNfd4xJQvfi0MOOcQtWLDAJ7Xyyiv7983Srevj cnV9Q91PBERABERABERABOqawOzZs/0t6SWmN58eYmSPPfbw5huYALGbPH6mYPoARf4wYoAZCoqq /QiKqVAWQWmcM2eO74FOCk8vPL3dq6++eq7RwjUjCjWVDTbYIDEqCnmS8hwq6uGciMJEKAsc6ek3 G37C0FBBQabHHlMlGiz1JTQWWBmJ3nZMrMwsimeNSZY9QzuSz2OOOSaX3bABt+KKK7r+/fv73n3C jxgxwjFCgBR7Lywh4sKjvkQ9/vVFXvcVAREQAREQARGoMwIo9Pww0aCXnR5f6+XG1IQfShxmGfiZ uQoTNU1ee+01O/UK/rRp03wPd86xGicon/QMYxZSKGa6Qu85+TKhBx7bd/zpsS8UesrD8IX+SZNw CYOyHvbu48Z1qMQXxiUMgolQ9+7dHSYtxhN3WGLH/vDDD+dMfTDdqUpQsGmEFJoycf+abP6JORFc aDCFrGkE0PjDzj9a4cddfvnlbuTIka5Vq1Y+i1Xdj0ngzJPA9Ic8G3feMZ6tTeINywuTlVZaya26 6qqhc52eL1end9PNREAEREAEREAERKCOCaDo9+rVy/fk08NLr+v222/vc3H66ae7+++/3/euY/KB X/v27b0f9uSY4zBhF/vyGTNm5HLOSjMolDbJk3XtaTRYgyEXsMhJmn0/96J33JRJSwJFnBEF/FH8 UYTpuUZQqsMeetxQXlGgTYlmhaFQTLGnV55VgCgPwpFr3E0K45o7/EjH5iKYO0fyZ3kiTRoTKMSW H8KE51wjKNQo5cRBKC/phPnxHhn+9OvXz5vZcKQRglA28vvHH384zHAwycJMh4YK7wf5xAxo8ODB Re+AKRKjSNj0h+ZaNCgwA7ORGc7D92KVVVaR4l+UqjxEQAREQAREQAREoEQCTN5dd911vV14u3bt /KReW5WGjaOYtIny2qNHD4e/KXIof/Ror7322u7dd9/1CqllBdOXMWPGeKWUHt/jjjvOxydOFqFX uNjEXhRPRh2SBAUWfwSlnx895CjJxKFBgKAk08PMNUoz5QtNfYhjYTkyukB8ysKRa/MvjIs7bqSP mQ8/Gin2QykmHRRtlHbuiyJPo4gVlJigjP+gQYO8gk0YS5O8Ex+THPJBXFZjCucOYDYUmiaFcYkf Crb6TLSlwcT9WrRo4Zf2pOFHumuttZZDGcdO/+OPP/blYuSCsg0bNixMKu+c/GPuM2/evNxkbgKw +hDv1FVXXeXLGO0d4OcE8F4Qh4ZlTUYu8m5ewkWTqGD/rVNVkFBVwxwFwfMuaTHV1JarlPs2xrhi lffqpF6IVSqePE+xysOReiFWqXjyPMUqD0fqhVil4snzbOisUJVQ2kIJ9Y0k/zBs4Tm93Ch/hWkW hku6buiskvIcskryT3MrJW59s6ruewGHUsqbJa5MfdLeNvmJgAiIgAiIgAgs8wSqUtCr8i8ESPjq xilMQ9cNn0BDfMZS/Bv+e6McioAIiIAIiIAIiIAIiEDJBKT4l4xQCYiACIiACIiACIiACIhAwycg xb/hPyPlUAREQAREQAREQAREQARKJtAkmmBSdHJvKakzcSWccV1KWuUeV6yyP2GxEqvsBLKH1Hsl VtkJZA+p90qsshPIHlLvlVhlJxAP2TRtSaEss4PjSf7rwouZlnaxeLiXct/GGFes0t6GfD+xyueR diVWaXTy/cQqn0falVil0cn3E6t8HmlXYpVGJ99PrPJ5pF2JVZyOTH3iTOQiAiIgAiIgAiIgAiIg AmVHQIp/2T1SFUgEREAEREAEREAEREAE4gSk+MeZyEUEREAEREAEREAEREAEyo6AFP+ye6QqkAiI gAiIgAiIgAiIgAjECUjxjzORiwiIgAiIgAiIgAiIgAiUHQEp/mX3SFUgERABERABERABERABEYgT kOIfZyIXERABERABERABERABESg7AlL8y+6RqkAiIAIiIAIiIAIiIAIiECcgxT/ORC4iIAIiIAIi IAIiIAIiUHYEpPiX3SNVgURABERABERABERABEQgTkCKf5yJXERABERABERABERABESg7AhI8S+7 R6oCiYAIiIAIiIAIiIAIiECcgBT/OBO5iIAIiIAIiIAIiIAIiEDZEWiyaNGiytooVZSuq6ioqI2k yy5Nscr+SMVKrLITyB5S75VYZSeQPaTeK7HKTiB7SL1XYpWdQDxk02bNmsVdl7gsXrzYpfkXjRh5 8GLWNG4p922MccUq7U3K9xOrfB5pV2KVRiffT6zyeaRdiVUanXw/scrnkXYlVml08v3EKp9H2pVY xenI1CfORC4iIAIiIAIiIAIiIAIiUHYEpPiX3SNVgURABERABERABERABEQgTkCKf5yJXERABERA BERABERABESg7AhI8S+7R6oCiYAIiIAIiIAIiIAIiECcgBT/OBO5iIAIiIAIiIAIiIAIiEDZEZDi X3aPVAUSAREQAREQAREQAREQgTgBKf5xJnIRAREQAREQAREQAREQgbIjIMW/7B6pCiQCIiACIiAC IiACIiACcQJS/ONM5CICIiACIiACIiACIiACZUdAin/ZPVIVSAREQAREQAREQAREQATiBKT4x5nI RQREQAREQAREQAREQATKjoAU/7J7pCqQCIiACIiACIiACIiACMQJSPGPM5GLCIiACIiACIiACIiA CJQdgSaLFi2qrI1SRem6ioqK2ki67NIUq+yPVKzEKjuB7CH1XolVdgLZQ+q9EqvsBLKH1HslVtkJ xEM2bdasWdx1icvixYtdmn/RiJEHL2ZN45Zy38YYV6zS3qR8P7HK55F2JVZpdPL9xCqfR9qVWKXR yfcTq3weaVdilUYn30+s8nmkXYlVnI5MfeJM5CICIiACIiACIiACIiACZUdAin/ZPVIVSAREQARE QAREQAREQATiBKT4x5nIRQREQAREQAREQAREQATKjoAU/7J7pCqQCIiACIiACIiACIiACMQJSPGP M5GLCIiACIiACIiACIiACJQdASn+ZfdIVSAREAEREAEREAEREAERiBOQ4h9nIhcREAEREAEREAER EAERKDsC/w9HOugTkx3aXQAAAABJRU5ErkJggg== --000000000000b5007905a13c9b21 Content-Type: image/png; name="Screen Shot 2020-03-12 at 10.05.20 AM.png" Content-Disposition: inline; filename="Screen Shot 2020-03-12 at 10.05.20 AM.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_k7ntxqms1 iVBORw0KGgoAAAANSUhEUgAAAwMAAAGvCAYAAAAHYwmfAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV lgdUk1kWx9/3fekktECkE3qT3gJICT0UQTqISkgCCSWGhCBiR8QRsKEiAuqIDUTBsQAyqIgotkGx gH1AREUdBws2VPYDljCze3b37D3n5f3OzX333fvOd8/5A0D+xhaJMmBFADKF2eKIAG96XHwCHf8U QAABROAIDNgciYgZHh4CUJva/24fe9Bo1G5Zjuf69///qylxeRIOAFA4yslcCScT5RPoesIRibMB QMpRv8GibNE4t6KsIkYLRPnGOKdO8tNxTp7kzxMxURE+AGDIABDIbLY4FQCyGuqn53BS0TxkBso2 Qq5AiDIfZQ8On81FuQblmZmZC8f5NsqmyX/Jk/q3nMmynGx2qowne5kwgq9AIspgL/4/n+N/W2aG dOoOYzDegDgwAt1J6JvdTV8YLGNh8uywKRZwJ+InmC8NjJ5ijsQnYYq5bN9g2dmM2SFTnCLwZ8ny ZLOippgn8YucYvHCCNldKWIf5hSzxdP3StOjZX4+jyXLn8ePip3iHEHM7CmWpEcGT8f4yPxiaYSs fp4wwHv6Xn9Z75mSv/QrYMnOZvOjAmW9s6fr5wmZ0zklcbLauDxfv+mYaFm8KNtbdpcoI1wWz8sI kPklOZGys9noBzl9Nlz2hmnsoPApBnbAAZ03G4C+RjYvN3u8AZ+FosViQSo/m85EJ4tHZwk5VjPp djZ2NgCMz+nkZ/CeNjF/EO3KtC83GQD3dADgwGlfXBwADaYAqMdN+4w1AaCiM9e0niMV50z6MOM/ WLQqBaAC1IEOMACmwBKtzwm4AS/gB4JAGIgC8WA+4AA+yARisAgsBatAISgGm8A2UAF2g72gBhwB x0ATaAXnwEVwFdwAd8AD0AcGwSswDD6CUQiC8BAFokLqkC5kBFlAdhAD8oD8oBAoAoqHkqBUSAhJ oaXQaqgYKoUqoD1QLfQLdAo6B12GuqF7UD80BL2DvsIITIZVYG3YGLaGGTATDoaj4HlwKpwF58EF 8Aa4HK6GD8ON8Dn4KnwH7oNfwSMIQOQQGqKHWCIMxAcJQxKQFESMLEeKkDKkGqlHWpBO5BbSh7xG vmBwGCqGjrHEuGECMdEYDiYLsxxTgqnA1GAaMR2YW5h+zDDmB5aC1cJaYF2xLGwcNhW7CFuILcMe wJ7EXsDewQ5iP+JwOBrOBOeMC8TF49JwS3AluJ24Blwbrhs3gBvB4/HqeAu8Oz4Mz8Zn4wvxO/CH 8WfxN/GD+M8EOYIuwY7gT0ggCAn5hDLCIcIZwk3Cc8IoUZFoRHQlhhG5xMXEjcR9xBbideIgcZSk RDIhuZOiSGmkVaRyUj3pAukh6b2cnJy+nIvcHDmB3Eq5crmjcpfk+uW+kJXJ5mQfciJZSt5APkhu I98jv6dQKMYUL0oCJZuygVJLOU95TPksT5W3kmfJc+VXyFfKN8rflH+jQFQwUmAqzFfIUyhTOK5w XeG1IlHRWNFHka24XLFS8ZRir+KIElXJVilMKVOpROmQ0mWlF8p4ZWNlP2WucoHyXuXzygNUhGpA 9aFyqKup+6gXqIMqOBUTFZZKmkqxyhGVLpVhVWVVB9UY1VzVStXTqn00hGZMY9EyaBtpx2g9tK8z tGcwZ/BmrJtRP+PmjE9qmmpeajy1IrUGtTtqX9Xp6n7q6eqb1ZvUH2lgNMw15mgs0tilcUHjtaaK ppsmR7NI85jmfS1Yy1wrQmuJ1l6ta1oj2jraAdoi7R3a57Vf69B0vHTSdLbqnNEZ0qXqeugKdLfq ntV9SVelM+kZ9HJ6B31YT0svUE+qt0evS29U30Q/Wj9fv0H/kQHJgGGQYrDVoN1g2FDXMNRwqWGd 4X0johHDiG+03ajT6JOxiXGs8VrjJuMXJmomLJM8kzqTh6YUU0/TLNNq09tmODOGWbrZTrMb5rC5 oznfvNL8ugVs4WQhsNhp0T0TO9NlpnBm9cxeS7Il0zLHss6y34pmFWKVb9Vk9cba0DrBerN1p/UP G0ebDJt9Ng9slW2DbPNtW2zf2Znbcewq7W7bU+z97VfYN9u/dbBw4DnscrjrSHUMdVzr2O743cnZ SexU7zTkbOic5Fzl3MtQYYQzShiXXLAu3i4rXFpdvrg6uWa7HnP9083SLd3tkNuLWSazeLP2zRpw 13dnu+9x7/OgeyR5/OzR56nnyfas9nziZeDF9Trg9ZxpxkxjHma+8bbxFnuf9P7k4+qzzKfNF/EN 8C3y7fJT9ov2q/B77K/vn+pf5z8c4BiwJKAtEBsYHLg5sJelzeKwalnDQc5By4I6gsnBkcEVwU9C zEPEIS2hcGhQ6JbQh7ONZgtnN4WBMFbYlrBH4SbhWeG/zsHNCZ9TOedZhG3E0ojOSGrkgshDkR+j vKM2Rj2INo2WRrfHKMQkxtTGfIr1jS2N7YuzjlsWdzVeI14Q35yAT4hJOJAwMtdv7ra5g4mOiYWJ PfNM5uXOuzxfY37G/NMLFBawFxxPwibFJh1K+sYOY1ezR5JZyVXJwxwfznbOK64Xdyt3iOfOK+U9 T3FPKU15keqeuiV1iO/JL+O/FvgIKgRv0wLTdqd9Sg9LP5g+lhGb0ZBJyEzKPCVUFqYLOxbqLMxd 2C2yEBWK+rJcs7ZlDYuDxQckkGSepDlbBRVE16Sm0jXS/hyPnMqcz4tiFh3PVcoV5l5bbL543eLn ef55+5dglnCWtC/VW7pqaf8y5rI9y6HlycvbVxisKFgxuDJgZc0q0qr0Vb/l2+SX5n9YHbu6pUC7 YGXBwJqANXWF8oXiwt61bmt3/4T5SfBT1zr7dTvW/SjiFl0ptikuK/5Wwim5st52ffn6sQ0pG7o2 Om3ctQm3SbipZ7Pn5ppSpdK80oEtoVsat9K3Fm39sG3BtstlDmW7t5O2S7f3lYeUN+8w3LFpx7cK fsWdSu/KhiqtqnVVn3Zyd97c5bWrfrf27uLdX38W/Hx3T8Cexmrj6rK9uL05e5/ti9nXuZ+xv/aA xoHiA98PCg/21UTUdNQ619Ye0jq0sQ6uk9YNHU48fOOI75Hmesv6PQ20huKj4Kj06Mtfkn7pORZ8 rP0443j9CaMTVSepJ4saocbFjcNN/Ka+5vjm7lNBp9pb3FpO/mr168FWvdbK06qnN54hnSk4M3Y2 7+xIm6jt9bnUcwPtC9ofnI87f7tjTkfXheALly76Xzzfyew8e8n9Uutl18unrjCuNF11utp4zfHa yd8cfzvZ5dTVeN35evMNlxst3bO6z9z0vHnulu+ti7dZt6/emX2nuye6525vYm/fXe7dF/cy7r29 n3N/9MHKh9iHRY8UH5U91npc/bvZ7w19Tn2n+337rz2JfPJggDPw6qnk6bfBgmeUZ2XPdZ/XvrB7 0TrkP3Tj5dyXg69Er0ZfF/6h9EfVG9M3J/70+vPacNzw4Fvx27F3Je/V3x/84PChfSR85PHHzI+j n4o+q3+u+cL40vk19uvz0UXf8N/Kv5t9b/kR/OPhWObYmIgtZk9IAQRdcEoKAO8OAkCJR7UCqrtJ cyd19IRBk9p/gsB/4kmtPWFOAOxvAyB6JQCB6F6J7sboruwFwLgUivICsL29bP3TJCn2dpO5yKii xH4eG3uvDQC+BYDv4rGx0Z1jY9/3ocXeA6Ata1K/T0iYAQAM0aRQbBfJKRf8i/0D0d0MkN0RdPQA AAGdaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjc3 MTwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj40 MzE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KsuiogAAAQABJREFUeAHsnQm8XVV97/83uZmHezOQMGQChCDz jDXBBCgog6IISFtlsH19Ra3Svj6t9vMKtLZq24+1tiKIA9TKLIpEUAQhzDIIaAhTIAkhgYQM92ae 79u/FdbNPvvsfc4+87C/C2723mv911r/9V3rnLP+e00dfYGzAq63t9e6uroKSCQHLV682KZOnZos UCCkknxbMS6sCjSGSBCsIkAKPMKqAJxIEKwiQAo8wqoAnEgQrCJACjzCqgCcSBCsIkAKPMKqAJx3 ggYUF0ECAhCAAAQgAAEIQAACEGhHAhgD7VirlAkCEIAABCAAAQhAAAIpCGAMpICECAQgAAEIQAAC EIAABNqRAMZAO9YqZYIABCAAAQhAAAIQgEAKAhgDKSAhAgEIQAACEIAABCAAgXYkgDHQjrVKmSAA AQhAAAIQgAAEIJCCAMZACkiIQAACEIAABCAAAQhAoB0JYAy0Y61SJghAAAIQgAAEIAABCKQggDGQ AhIiEIAABCAAAQhAAAIQaEcCGAPtWKuUCQIQgAAEIAABCEAAAikIYAykgIQIBCAAAQhAAAIQgAAE 2pEAxkA71iplggAEIAABCEAAAhCAQAoCGAMpICECAQhAAAIQgAAEIACBdiTQsWjRor52LBhlggAE IAABCEAAAhCAAAQKE+joC1whkd7eXuvq6iokkhi2ePFimzp1amJ4oYBK8m3FuLAq1Bpyw2CVy6PQ E6wK0ckNg1Uuj0JPsCpEJzcMVrk8Cj3BqhCd3DBY5fIo9ASrQnR2hTFNqDgjJCAAAQhAAAIQgAAE INCWBDAG2rJaKRQEIAABCEAAAhCAAASKE8AYKM4ICQhAAAIQgAAEIAABCLQlAYyBtqxWCgUBCEAA AhCAAAQgAIHiBDAGijNCAgIQgAAEIAABCEAAAm1JAGOgLauVQkEAAhCAAAQgAAEIQKA4AYyB4oyQ gAAEIAABCEAAAhCAQFsSwBhoy2qlUBCAAAQgAAEIQAACEChOAGOgOCMkIAABCEAAAhCAAAQg0JYE MAbaslopFAQgAAEIQAACEIAABIoTwBgozggJCEAAAhCAAAQgAAEItCUBjIG2rFYKBQEIQAACEIAA BCAAgeIEMAaKM0ICAhCAAAQgAAEIQAACbUmgo6enp69WJQvStu7u7lol31bpwip9dcIKVukJpJek XcEqPYH0krQrWKUnkF6SdgWr9ASKS3Z2dXUVlOrt7bViMkkJqLGWG7eSfFsxLqySWlG+P6zymST5 wCqJTL4/rPKZJPnAKolMvj+s8pkk+cAqiUy+P6zymST5wCqJzG5/pgntZsEdBCAAAQhAAAIQgAAE MkUAYyBT1U1ha0Fg0aJFduWVV9oDDzxQi+RLSnPp0qVOF+nTLE66XHfddXnq3HHHHU7Xn/70py4s SS4vYoyH2Cv+66+/HhOa6+Vlm6G+cjWr/KkZ2mI16lHlwEEAAhCAQH0IVN0Y0A/sySef7P7+6I/+ yN7//vebrp/+9Kft7//+723u3Ln1KRm5QKBOBNRxueKKK6wZOpe/+c1vnC5/8Ad/UKfSF89GbKLG wGWXXWYf/vCHna7f+MY3XCJxcsVT3yUh9oqf1hiQbDPUV9rypZVrhrZYjXrEGEhb48hBAAIQqJxA Z+VJ5Kdw//3326xZs2znzp22ZcsWe/PNN93fs88+a1/+8pft2GOPtSeeeCI/Yhv4fOYzn7E99tjD Lr/88jYoDUWIElAbPuqoo6yvb/e6+yOPPNLU5qdNmxYVr/uzPlf77ruvnXDCCXXPOylDsQlvJKD5 m//xH/9hU6dONfH0YVG5pPTwbx4CY8aMsZ/85Cc2e/bsfqWox34U3EAAAhBoCQI1MQZUcv04XHzx xe4H35NYt26dfe9737O//uu/tgsuuMBuuukmH9Q21+eff94ZQm1TIAqSQ0Cd16hTZzbcGYqG1/NZ IwMaFSh34X4tdI2y8W99NTLgDQHl6+W0AQCu+QmoHmXYRZ2vx6g/zxCAAAQg0JwEamYMdHR0mP/z RR89erT91V/9lf3oRz+ym2++2b761a+6t6kartf0Ib1Nv+uuu+zf/u3fbPv27fbggw/6qG4+sOZD L1iwwHW2Dz/8cPvIRz7SH+5vXnzxRfvv//5vW7NmjS1evNhOP/109/eud73Li/RfNbdVab766qv2 vve9z5SmpjiFnWTkNNKxdetW+93vfmePPvqoTZgwwXW6LrroIhcuOY2CeGPAxys2QnDrrbfar3/9 a/eG9OCDD7ZjjjnGzjvvPDe64BIu8I+G4+XENOp8mL8q/IUXXrBbbrnFjdKIjX601XFU2aNO8d56 6y3H8KCDDrKjjz7azj//fBsyZEi/qOpPz5oC9vOf/9yuv/56l2ahMqvzILnbbrvNOjs7XWdQnULP sT/x4EadDcn66RzSV/WgN99hlyQn+ai78cYb7Ze//GV/J8bnHe6U+vYondT511ts3b/88sv22GOP uSTD9evzl27hPH1ZlYba7fjx41345z73uRy1NIVG9SFumj+vMiuuRhokGy1vTuTQw7x580zGwL/8 y7+EfHNvNSVHne2kOlK59MZehrx30kd6+Y5fIWZKV/Lf/e537U//9E9dOuE0PVul/dxzz7nPtc/P y4U/156hX1fgDS/VR7jOvK66Kg/VmeJKRrLSuZh74403THy8wSf+Z599dqq4Pm3lrfKrTWjESPWn dLwL17XKK/l//Md/tJkzZzoRxZPuYR2kf7hd+bQk853vfMd9rlXOaLvycrrGcdQUzr/4i78Ii7np XL4thjn6tqgyyenzq/Ymp/Lq+1t6Ss7XY7gNhfPXd7s+C74duUT4BwIQgAAEGkcgmO5Q0AVf4gXD o4HBELHmT/QFnYK+4IctGuyeFSYZycrpGhgOfY888oi7Kiz4cXRh+if4kXH+wQ9in/6CaRru+bTT TusLOmj9ct/61rf69tlnn77grWhf8CPeF3Sq+yZPntw3YMCAvqCD1C8Xl2bQCXdpBsZATppBp9j5 S8fhw4e7/D/+8Y/3jRo1yvkHP+4uXcmdeOKJrlxeT/kluVdeeaUvMFT65YM51E5flT2Y4pEULcdf +Ug+ro7kr3DvxGbvvffuCwyyvqAT0Pfnf/7nfcEPt4sf1fMTn/hEv16+LEpvxowZfYFB4ZPs+9u/ /VsnF3Qa3FUy0bT6hYObwEDrCzoTTvaMM85wbeSII45wz/IPux/84AfOP+go9gWdHPene+XxyU9+ sl+0kJzihV3QOclJM+i8u+egI9X3zDPP9Iv69umvak///u//7sqve+mguPqTU9uQn+S9W7hwYT9f yV166aV9SWVVuI+vMqrtej/pFhigPtmC12uvvdalE0wV6peLfgbFRHkFUzv6ZfyN/BTmuQWdwv76 ku76HIbLoPr0zrMSJ6Whz53noWeVR0715cumsure5+flfHsOtxfJKb1w/i7Bd/5RmOKLs09HHH19 KV/vvKyu3qn+9dlQXMVTWX17U7sp5qSzb1/SUWn4+OG8fdm9DpKZM2eOS146qL7T6ODrSjorL5+f 9Fb8cNnCbVG6iXcSR6+f6tF/j3o/6aa05PQZ9OVTWpLxnyHP3wkG/4TrUXrqeyMpf89Fn6k459tG XFgxv0bFjX4Gi+kZDm+Uzo3KF1bh2i98D6vCfMKhsArTiL+3eO/dvqV+KYQ7RkkVoE7o2LFj+zPx cf71X//V/Yjt2LGjb/Xq1S7861//uvtxU8feu2C6UZ86z/rRCd6Ke2/X+dWP45133tnvp7SCt9qu gx28tXf+wchEXpqSC0Yk8tJU51b5BKMGffeHfqCC0QHnf+aZZ/bnpXyjP8T9gZEb6S3Z4E29C/Gs fIciXIZI1P7HUowByerHPVwGJaQf5fe85z19ns3//M//OL3e+9739m3YsKE/LxkT0leGkHfeGPjQ hz7Up/BizncUdQ23K9+BCXdQ1bmQvuEOp9JXZ0J6eP+0cuqQKV6wmD1HTfGQf9hw8h0StdNwR046 Kz/Jh51PI9wBC956Ojkf35fXl1UMvPNpqi58uRTmeX3lK1/xogWvf/Znf9YXrMfJkfHtynuqwyb9 pUfUed18h8/Xr++se3nPMpyGZ6YOovLw5VUc5acyhp38wrwU5uV8XJ9PVM7n5dkqrvfT5993SuWv sqgdqSPrnZfV1TtvGIfjKsy3t+jnxsfzV88qXK8K851ezzRc1z4vX17pIF29v+KrPcTp4GUfeugh iTnnyxpl6+OHeSlCnM5eP9VjXFv0bUHtynOMsvH1uEur3e3Ys/Hl9e0t/LlPStOn5eP651KujYob /Qy2gs6wSl9LsIJVEoFGtY1y8h0QfHHXzc2fP98NSwdfjm7qTjTjxx9/3ILOtwVv8t2fpuVo2D74 IXfTW7z8yJEj3dD6XnvtZZr24Z3SDTr1tnnzZu/l0nnqqafc9A5Nw5G74YYb8tJUnv/n//wft7hZ 4VF34IEHWtBh7PfW9BotFH766af7/TQtKq374he/6KYUKY2wC34g3eNLL70U9q74ftmyZW56yNtv v52Tlob3NfUlzEYCwQ+3BSMh/bKf+tSnLDAaLDAW3LSq/oDgRuwUXsxpWkDQcbDA4MkR9c9+aoQC g8bsppnlCAYPmi6ielabkCskF3xA++U0PUNOU5vCTnUadHDcdA2lFXZBRy5P13B40r30k55Bxyov vt85R1Mrok5t35dLYX5qS/DmOCqa97xt2za3KL/YLkKa5hF09Ezbekad/FTmoKPpgvQ5CDqn7jMY llV9SS4uDfH0U0nCccq5V1pqL9p5KOzkLyfOURcY5zn5qyziqLrVtJc4p3antD760Y/mxJWsbzf+ Ghdfft/+9rcdq6iuqu+gg+vyD8cVwzAn6SYdov5qDz5vP1XK66tyHXbYYf3JqqyKH3Yqt6/XaFhg DLi2kKYt+nKFP6PhfArdl/K5L5QOYRCAAAQgUBsCnbVJ1tw8eK0LUCdl/fr1FrxldlflF7xddvNi o3lPnz49x0sdWG0VqB/NuB/yc845x4I30rZq1SobN26c+9G95JJL7G/+5m/cmgHNv9dc92gnPZii 4+Zhx6V5/PHHm4wHn6ZXSPNro+6QQw6J1SsqF/csI0B/mjcvg0a7wKjj5Z0WW1fTXXPNNXbSSSe5 ef/BaIvr2Md1HMVGnf6NGzfmlU3yMtiWLFli+++/f7960XrrD4jcqLOiP3V6ZBg++eSTTkLPUacO hOYeq/7UWQ/ebrq45crJ6FHemuccvEHNScYvWFVHx3c0JRDurOVEKPLgyxNOy0dR504d6bhOVVRe +qZ1qhetZ/n85z9fNIo6dlpnos6lOMvpXh1HdVy98589sYs6rWPQnH+VNaxntAzReKU8K139KQ/l 5T+vek5yMgaizuuXFM+nq++JuLIqvaS4ClNdqg3J+Is68YhjEm1bXgftzpOkg28z3mj15Qrnqby0 5sA7H0c7YEXT1Xey8vMyPo6ucTqHw0u5l576E0PVo9bsaK2RnnEQgAAEINB4AjUzBrQQVwvR9HZf b6P1Y6C3WFqMeuqpp8aWfPDgwTn+2pJUTj9W6sgmORkNMgb05mvt2rUWTLGxYE68E3/3u9/tFhpr oVwwj9n5qZOj0YM0afo84xYg+7ByritXrrQvfelLFszztqFDh1qwBsGVIfxmuJx0k+Lox11vANXp 025OcgcccICdcsopFkzz6R+pERsZBIXYRPMYNmxY1Cv2WfWovH3Hxy9c9p2bcCS9JZfTW1F1XPUn Nuq8amGq3m7LFZLTuRZqd96p83HWWWf5x/6rRhDiXLTDFicT51esk5NUx0n+cXlE/WQMBFNkTMZs MSeGccaA4vm3x76Okj57npnKGmYcvi+mR7HwaHvRAn8ximsvPq1CDJPqxaenRbE//vGPfVI5V32X JTkfPym8FH8ZwPor5HzdxMkklV+fo7gRAF+P0bRqWY/B2iMbOHBgwXqM6sMzBCAAAQjUjkDNjAGp rI6a77SVUwRNB5JTR1Y77qRxn/3sZ92uFitWrLC7777b/f3zP/+z6U37N7/5TZeE3sDrzfbvf//7 vCT1hi/8hj5PoEoeejurXZX+8i//0umlzoZY6Ye+lI54KepceOGFpj/tbOPZXH311S5P7bokp7Jr p6Q4NqXkFSerkRy9ldfIhEZwPGeVWcZj1Kn96E21OoX6U2cmmPfsRlH8TiaKkySnOL/97W/7k1UH J5iP3Z9vf8A7N9ERpKSOVTRe9LmaHalo2knPfktRGXjFnPTTW2w/zUedWbHV6Isvsy+D5DRVJ8lF mSXJleMvw1F5q734aSpKJ6m9FMujmHGnEShNjyvVlfMWPUkXbb3sDbJS9SgkH1e2en3XhT/3qkef b7n1WKichEEAAhCAQOkEBpQepX4xgt1v+jNTp6PQX7/gOzfqFMkw0FaaGpL+z//8TzdlScFTpkwx bSNYKL1adnKCxdHOEAgWUfcbKF5/jWyU6jQyEnZ+bnHYL3yvUQ4ZIZrGpcOptB3rPffc40TERtOA qu3U4ZQhoM6l3kqH2Rd66yo5TXGQ8aCOoTqs2r5VHYmwi5NTx9/LydDSm+FwvtH7cHrVuE96E63p GpUYyVHdNPImYyDNqICPqw6n6kR8fHsJd0K9MaCOW5RT+NmnV4ur6ltTqkppL4WMWG/oRHX1HXO9 MAiXLXofjRd+1qhjXDsWY9V3tC3IUA07z1tpRPMNPytOIePDt3efti+z8gunE7338tW+lvu5r7Ye pAcBCEAAAskEOvVjX8ylkfFpaB6qnPbcl0sT18fR1J2wvObTa0qDOivBtqN26KGHujT9P9r3XtM+ 9KfpNpp6o2lBwbZ3OekoDXV8tRZAC2W1p7fmq2tubbgDpHQ1BUUnJGuvf+2F7cshHcO6SVb7ZctF /RUn6ucE3/lH03DkNC0qLKf7YOcYF6bzD8JhzjPyz3777ec6c1pvEDacVFY56ac07rvvPrv33ntN C65lIIVdsD2r60iqEyLZYMtP+4d/+AdnpPjFzF7eszn33HNzzkEoVl7F90aO10l+yk9/erMv59PR VCVNoQp2/rHoHHBNM9MbbdWHOn5p5JRHsDuS66xpUewf//Efu/z8P1r8qc6R33Pd17mm3sgQCTtf 58pbhpOcb79ef8VR51DtVmXxIyDSQ+cxyEkfPcv5NP2z84z8UyhMo2YybrWGJU4uzs+PxMhYlo6a YqQRqbCs2oLO/ZDOfh98r5a4a7qHrx/PLPw5CacVrnefhufln3WNstAp5uF0dO/bi0b/fJjPX/oG 24uGk7Tbb7/dlU+fF8l7WZ+/1qXIySD26fkExOZrX/uaaxvhxbo+3F/FR2t/Hn744ZxFveKk0Tct vNf8fF++MCelofVNchr5kvETdtJBaejzIB00JVJO5ZJsWGf5yfmyaW2H2qIMknCbdULBPzojJFyP Xr9wml5W13A9eo7RsoTl4j73CleZfD16XeVfKE2FyyXptiu08L/ELcwnHAqrMI3C97AqzCccCqsw jcL3dWUVzBkt6II3OwXDo4HB2zxNwO4LpncknjNQKI4P8/n6LTyDjnlfMM3HBQc/+C595RMMqzu/ YNqIyzeYWtQX7ODRF3S4++TntyYNOkp9waJYJ6t92xVXf5IN3qz3SW/pLD/twe9d8IPl/BQedcEb Ohfm/YNDutxZBMrrF7/4RZ+2So1zmzZt6pOM8goW9joRbc2pLT5/+MMfOn+FBZ3UuOj9ftqWVHI6 r0D6aevA4A2jO0dA/tLPO52jID/x0DaiYTbBSEFfsGDaiUq3oDPrZMUjeJvv0o5j47cmFKM0Lngb 7tIVc+2tHsxjdnn5tKW731Yx6ED3BZ0nd26B/KSH5IM3ne6MB7/tYSE5hXk5xdez4it/pRm8RXXp B4ZA/173KofXR9ewU5v0YcF0Bxdf6Yu92IblVRfyE8vAKOjTFpDSX2WSHtLHu2C0xMn65/BVaeh8 h0Iu6HD2BZ2+vqBznCcWvJHO8/Me2tpRzJVHMI3Ee/dfg0P/nK7SWbpLZzELDgXLK6/nIhZy/vOr e6WvMoad/MK8FOblfNxgVMD5qb6Ublx7kU6qA59/0PF1+klP1XEwouTSUFm987Lh/L2fry/FVb3p OVpfPp3wNVgYm8PKty2VSeXwzufjOcnfl1d1IPnAKHOcC+ng20zwIsTJSlfVi2cWLltgILh0w2WT fv5clPDWnj7dsH5ed18/ela78mcd6HtG6aku5MJyeg5/7pWuvteki2cR/tx7v7j8lZZnpftSXaPi FvoMFitDo3RuVL6wKtYidofDajeLYnewKkYo+N4uJlLql4K+xPVjoC/1tBUQjuP1Ceerzrv2yg4W qrq0lb46t74j7ePoADIdOiTDQTL+L3iT3b+PvpfVj7f2x1fn0MsFowZu720vo2spxoB09j9mSjPc GQ+nqXt1yHVoms974sSJLq7Cgt2Q3DkMCivmdPiPT0PXYMcfd2ia7sP5B1NJ3NkMOngsLC9DQsZV 2Mkg+MxnPuMOcPOyMl6inf5SjYFg/r7rGKjzrT+x93uP+46Q/OV0zoTq3Mv6qzorwZvqfnULySm/ sNOzOtY+LV2lg+os7HwdRv1Vv+rw+M6N4qvtxrVfpff973/fdRDD+Un/qF6+AxbWwd+LfzFjIHjL 3/exj33MR8m5FvoM+s6c8lDHM+pUXukq/cJlUPllVIadZyYWcuHPr9JXGmEnvyhfL+fjKm91bn3e 4bry+fk68M86JyOsr9IMGwLSwcvqGnZqg+r4+/x0Vf7R+grH8feeldiE46sN+zNTJOvz9pzk58vr w6M6qDxRHZSm/FU+n5+eg1Ei5xctmwyCqG4ynOQfdj5Nb0SHw3z9yM+3Ky8vHXyeYTnJSvdw3ipf 0uc+jo/S8C7MyvulvTYqrmeVVs+wXKN0blS+sArXfuF7WBXmEw6FVZhG/L3reQVf3olOwxTBl3di eDQgyKbfS0PBwY9A/3PSTThO8KPixOLy1RCy9sTX0LemaHjZaLrLly93Q8kaotbUAM3NL+SCjlD/ NALFCZc3Tjeflg/zenidVW5NWZo0aZJbjOvl467aYlND71rXkHaLzmg6WhAc/Hi7svopBFGZ8HPw wXA7PGnKlPIOlzcsp3ttV6mF3OIYdb68Uf9Cz2Km/DWtRVMrPDvFifKUn8rl51cHbxBNf3HtKk4u nLbSkgt+5Fw+StOnFycnXaL+vrwK8/E19UMuTt77S1bTvgKDyuUZTTeu3C7Rd9JVvkFH2HvlXAMD 2PyakcD4ywnTg6Z/FfoMFso7XF7Vmf7SMvNxpUNcHnG8vFz4Myg/n7fKF2bn5b2fnhVXU55Uz+Ie jSN95CTr4+3y2cVK3yuKp/haSyDuUTkvH7768hbS18tH8/Zxw+FeB1+ncTooHU390TbIYV2j6YfT 9SwlrzSj7Upx5ZLy82G+XUleacrpe1kuLg0vJ66SC+cblddzXP5KO8pKfmldo+J6Vmn1DMs1SudG 5QurcO0XvodVYT7hUFiFacTfV303oaQv8fjsd/mmjaMOs/9xLJSetuoM3rQXEskJC4asc57DD4V0 SwpTh8LPJw+nFXfvD/tSYy3X6byCUrY+9R065acv/UJO2zlW04mZOgMy0KL8os/KV53tNLsrpZVT HuqIFEszThfPQWHRNpMk72VlTCUZXUlxlZ/CCoXrMDz9lesKpe3TlIzqTH+FXFJacf6l+CXlHU3D P+tarD142Wh55B+t26hMoWfFT9LXx0vKOxyeRgelI0Mv+hlNSl/+Yd3iPvtJcaVbXJhP0+ueRi6a bzTd6HM4be4hAAEIQKD6BJp6N6HqF5cUIQABCEAAAhCAAAQgAAFPAGPAk+AKAQhAAAIQgAAEIACB jBHAGMhYhVNcCEAAAhCAAAQgAAEIeAIYA54EVwhAAAIQgAAEIAABCGSMAMZAxiqc4kIAAhCAAAQg AAEIQMATwBjwJLhCAAIQgAAEIAABCEAgYwQwBjJW4RQXAhCAAAQgAAEIQAACngDGgCfBFQIQgAAE IAABCEAAAhkjgDGQsQqnuBCAAAQgAAEIQAACEPAEMAY8Ca4QgAAEIAABCEAAAhDIGIGOnp6evlqV OUjburu7a5V8W6ULq/TVCStYpSeQXpJ2Bav0BNJL0q5glZ5AeknaFazSEygu2dnV1VVQqre314rJ JCWgxlpu3ErybcW4sEpqRfn+sMpnkuQDqyQy+f6wymeS5AOrJDL5/rDKZ5LkA6skMvn+sMpnkuQD qyQyu/2ZJrSbBXcQgAAEIAABCEAAAhDIFAGMgUxVN4WFAAQgAAEIQAACEIDAbgIYA7tZcAcBCEAA AhCAAAQgAIFMEejMVGkpLAQgAIEME9ixY4dt2bLFdF2/fr0NHjzYhgwZYgMG8F4ow82CokMAAhkn gDGQ8QZA8SEAgfYmsGnTJluyZIktX77ctLmCnrdv326bN2+2UaNG2fDhw23s2LG29957u7/OTn4W 2rtFUDoIQAACuQT41s/lwRMEIACBliegzv6aNWvslVdesZdffrnfGNBowM6dO62vr89dBw4c6EYF xowZ4wyBqVOn2vTp023atGnOUGDEoOWbAgWAAAQgUJQAxkBRRAhAAAIQaB0Cb7/9tr300kv2/PPP 2/z5850hUEz7tWvX2uLFi+2pp56yd73rXXbwwQe7vwMOOMBGjhxZLDrhEIAABCDQwgQwBlq48lAd AhCAgCegN/6vvvqqPfjggzZv3jx78803bevWrT441XXbtm324osvOsNAhsTRRx9tM2fOtIkTJ6aK jxAEIAABCLQeAYyB1qszNIYABCCQQ0DTgtSJv+OOO+yFF16wjRs35oSX8qApRIqv9GRQrFy50s46 6yw3jaijo6OUpJCFAAQgAIEWIIAx0AKVhIoQgAAEkghod6Bnn33W7r77bvv973/v1gMkyZbiL6NA J3fOnTvXNGLw/ve/300hwiAohSKyEIAABJqfAPvJNX8doSEEIACBWAKaGvS73/3OfvrTn1bVEAhn pl2HHnroITfqoHUFOAhAAAIQaC8CGAPtVZ+UBgIQyBCBZcuW2Z133mkLFiyo2ohAHD6NDDz99NP2 i1/8wm1PGieDHwQgAAEItCYBjIHWrDe0hgAEMk5AZwbce++9bo2ADhGrtdN0pMcff9wtUK5HfrUu D+lDAAIQgMAuAh3BnNC+WsHQfNPu7u5aJd9W6cIqfXXCClbpCaSXbKV2pQXD9913n5u6o0PE6um0 s9A555xjxx9/fD2zbdm8WqldNRoyrNLXAKxglZ5AccnOrq6uglJ6+1RMJikBNdZy41aSbyvGhVVS K8r3h1U+kyQfWCWRyfdvJVbaQvSRRx5xpwnnl6S2PitWrLCHH37YTjjhBBs9enTJmbXi93MlOrdS u/KVWUl5K4kLK18Dxa+wKs7IS8DKk0i+Mk0omQ0hEIAABJqOgM4O0HSdt956qyG6aZchGSM61Ez3 OAhAAAIQaG0CGAOtXX9oDwEIZIzAmjVr3EnBWtTbKKepSTJI6j1FqVHlJV8IQAAC7UwAY6Cda5ey QQACbUdAW4kuXbq0oeXSiIBOKG7U6ERDC0/mEIAABNqMAMZAm1UoxYEABNqXgEYDdAiYFhA32q1e vdqeeeaZRqtB/hCAAAQgUCEBjIEKARIdAhCAQL0IaERA8/WbwWl0QIuYm8EwaQYe6AABCECgVQlg DLRqzaE3BCCQOQLPPvusab//ZnFLliwxHXyGgwAEIACB1iWAMdC6dYfmEIBAhgjs3LnT7eDTTEXW 4WNaO4CDAAQgAIHWJYAx0Lp1h+YQgECGCGzYsMGWL1/edCV++eWXm04nFIIABCAAgfQEMAbSs0IS AhCAQMMI6OCczZs3Nyz/pIy1jkGjFjgIQAACEGhNAhgDrVlvaA0BCGSMwLp166yRZwsk4daIRTMa KUn64g8BCEAAArkEMAZyefAEAQhAoCkJ6IAvzdFvNiedOHys2WoFfSAAAQikJ4AxkJ4VkhCAAAQa RmDr1q2m7TybzUkn6YaDAAQgAIHWJIAx0Jr1htYQgEAGCTSjMaD1AqwZyGBjpMgQgEDbEOhYtGhR 871qahu8FAQCEIBAdQjMmzfPbrjhhqabkjN27Fj71Kc+ZePGjatOQUkFAhCAAATqSqBz6tSpBTPs 7e21rq6ugjJJgYsXL7Zi6SfFrSTfVowLq6SWkO8Pq3wmST6wSiKT79/srPS9NmjQoKYzBgYPHmz7 7befdXd350ON8WnF7+dKdG72dhVTRVZJeSuJC6u42oj3g1U8lzhfWMVRyfVjmlAuD54gAAEINCWB ESNGWGdnZ9PpNmTIEBs+fHjT6YVCEIAABCCQjgDGQDpOSEEAAhBoKAGN0GpkoNncmDFjmlKvZuOE PhCAAASalQDGQLPWDHpBAAIQCBEYPXq0jRo1KuTTHLeTJ0+2jo6O5lAGLSAAAQhAoGQCGAMlIyMC BCAAgfoT0Nz8KVOm1D/jIjkecMABRSQIhgAEIACBZiaAMdDMtYNuEIAABEIEDj300NBT4281bQlj oPH1gAYQgAAEKiGAMVAJPeJCAAIQqCOBQw45xDRC0Cxu0qRJNn78+GZRBz0gAAEIQKAMAhgDZUAj CgQgAIFGEFDH+13velcjso7N85hjjrGBAwfGhuEJAQhAAAKtQQBjoDXqCS0hAAEIuIW6M2fOtAED Gv/Vre1EDz/8cGoFAhCAAARanEDjf1FaHCDqQwACEKgnAU0V0qm/jXZazLz33ns3Wg3yhwAEIACB CglgDFQIkOgQgAAE6klg3LhxdtBBBzV0O09NDTr44INt5MiR9Sw6eUEAAhCAQA0IYAzUACpJQgAC EKgVgaFDh9qRRx5pujbKaYrQEUcc0VSLmRvFgnwhAAEItDoBjIFWr0H0hwAEMkVA6wUOO+ww22ef fRpW7mnTptl+++3XsPzJGAIQgAAEqkcAY6B6LEkJAhCAQF0IaFeh2bNnm/b5r7cbMWKEnXDCCaYr DgIQgAAEWp9AR09PT1+tihGkbd3d3bVKvq3ShVX66oQVrNITSC/ZzO1q+/bttnXrVtP0HO/Wrl1r 1157rc2bN8971fza0dFhM2bMsA9+8IM2YcIEl9+OHTts3bp1Nnr06KbY5ajmEErMoJnbVYlFqbk4 rNIjhhWs0hMoLtnZ1dVVUKq3t9eKySQloMZabtxK8m3FuLBKakX5/rDKZ5LkA6skMvn+zchq27Zt tnz5cnvyySfdi5X3ve99/fv667v1lFNOsaVLl9qaNWvyC1QDn4kTJ9qZZ57p1gr47/YVK1bYr371 KzdtSGsZ9AKo0Nanrfj9XInOzdiuijWNSspbSVxYFauZ3eGw2s2i2B2sihEy6ywuggQEIAABCNSb wNtvv23PP/+8Pfvss/bUU0/Z1KlT3VqB8Im/06dPd1N27r33XtPoQS2dTj7WqIDWC7z11lsuq76+ Pnv00UftnnvuMe1ytHjxYjvqqKPcbkeNXOBcSw6kDQEIQKDdCLBmoN1qlPJAAAItTUAd7FdffdXu uOMO+8lPfmKPPPKIbdy40RYuXGhPPPFETtnU4dboQD0W82o7U41MDBkypF8Hdf7vu+8+Z4hoBENG wY9//GN31RtiHAQgAAEIND8BjIHmryM0hAAEMkJA04K0BuC2226zX//617ZkyRLTnHy5zZs3u072 smXL+mloDr/e1J999tm2xx579PtX+2bPPfe0D3/4wzk7GG3YsMHuvvtue/PNN/uz27Jli73wwgvO kPnZz37mwmTc4CAAAQhAoHkJYAw0b92gGQQgkCECWiCsN/96s65pQer8R93rr79uv/jFL2z9+vX9 QToA7LjjjrMzzjjDwlOI+gUqvNFCYa0TOPzww/vXAshA0fSl3/zmN7Zz586cHPSsNQwyFO688043 opEjwAMEIAABCDQVAYyBpqoOlIEABLJIQCMCDz/8sJsWpHUCfjQgjoWmDf32t7/Nkens7LSTTjrJ 3v/+97tdfeLileOnHYKUpqYHhRcFa9Fw1CiJpi9j5qGHHnJlWrBgQTSYZwhAAAIQaBICGANNUhGo AQEIZJOADIGnn37aTa3RuoBChoAIaS7+L3/5S3vjjTdygI0aNcqtH9Bb/LFjx5qmEJXrFHfMmDF2 1lln2cknn2xK2zvtzPHAAw/YSy+9lDcq4GX8VVOJNNqhtQ+a8sSUIU+GKwQgAIHmIYAx0Dx1gSYQ gEAGCahTrcXC6tyn6SxrGs7LL7/spuD4XX2ETR14bet5+umn24c+9CE78MADTSMGpTrFOeCAA1wa SstvIap0Vq1a5QyRZ555JvXuRd7Yueuuu1z8UvVBHgIQgAAEakug9F+K2upD6hCAAAQyQ0Bvy/WW X9No0hgCHoxGD7SlpzcAtP+/dyNHjrRTTz3V9tprLzfioFEHdeLTOI0GHHPMMXbsscfaoYcemnPI mdYpaAtT6asOfilO6yEee+wxd2rxBz7wgVKiIgsBCEAAAjUmgDFQY8AkDwEIQCCOgKb7zJkzx+2+ U2xqUFx8zclXB1unEutE4PDi4WHDhrn9/rXTkLYdnT9/vjM4lKfy0uiCjA+tA9BIwIgRI+xd73qX MwB0ToDODPCjCpLTacfaNlTGQLlbhioNxVfap512Wv/haXFlww8CEIAABOpHAGOgfqzJCQIQgIAj oAPCtBOP3u6XYwh4jDp/QPP35bTIVweT+U68rtpu9A//8A/dYWUafdC0InXKtQWojAmtBdAiYclp atDee++d00mX0aDRC+mpEQHFrcR5o0J57b///hWta6hED+JCAAIQgMBuAhgDu1lwBwEIQKAuBNQp 12Fd6sxX6tatW+fS0onFM2fOdNN8wgeD6e2/pgzpb9OmTaZFvZrmo465FhprZEF/0QXHMli0a5EM AV3D25lWovPSpUvdGQoyPJQvDgIQgAAEGksAY6Cx/MkdAhDIGAGNBMgQ0M5BpawTKIRJRoXOJtAp wDoETPP+dVCYjIJwJ1/Th/Qnp454eHGwT1+jBjIsZABou1OdbaA5/9VyMjK0w5DWJRx99NHVSpZ0 IAABCECgTAIYA2WCIxoEIACBcgjohN65c+em3o0nbR7qZMvAkEHw2muv2bvf/W7TmgFNAdIuQ+HR gmiamg6ktQAyAhYtWuTWGGjHII061MKtXr3anVOgdQqapoSDAAQgAIHGEegI9oyu2Vnx2o9aP0K4 4gRgVZyRl4CVJ1H8CqvijLxEPVhpms7111/v1gv4fGtx1dQgffdqlyGNEGjRrv7U8daIwKBBg1y2 GgVQh1+7Da1cudKWLVvmRhb0XMlahjRlkg5/8id/YrNmzUoj3rIy9WhXLQsnojisIkAKPMKqAJxI EKwiQGIeO+OGicNyeltUTCYsH75XBZQbt5J8WzEurMItp/A9rArzCYfCKkyj8H09WGnKjc4IqLXT m369fV+zZo0bJVDHW4aAvo+19aieNfVHclo7oM6/FhTLOJBfPZzWLWgRtdY5aO1CGsd3expKu2Rg BaskAq3YNirRuR7f7XGsK9G53nGZJhRXg/hBAAIQqDIBdb41r7/SHXlKUUtrEtTB158WAOvNfzM5 GUfa9nTGjBk5axuaSUd0gQAEINDuBDiBuN1rmPJBAAJNQUBven73u9/VfPpNUxQ2pRKaNqW1CRqV wEEAAhCAQGMIYAw0hju5QgACGSPwyiuvNN2b+UZXgaYkaWRAU5pwEIAABCDQGAIYA43hTq4QgECG CKjT+9BDD7n9/TNU7FRF1Q5Gzz//fCpZhCAAAQhAoPoEMAaqz5QUIQABCOQQ0E498+bNy/HjYRcB byjVa+Ey3CEAAQhAIJcAxkAuD54gAAEIVJ2ADAGd/IuLJ6ApVDqVGQcBCEAAAvUngDFQf+bkCAEI ZIiA9uvXIllcMgHttASjZD6EQAACEKglAYyBWtIlbQhAIPMEtJXo4sWLM8+hGIDnnnuOnZaKQSIc AhCAQA0IYAzUACpJQgACEPAEli9f7vb4989c4wksXbrUtP0qDgIQgAAE6ksAY6C+vMkNAhDIGIE3 33yTffRT1PnGjRtZN5CCEyIQgAAEqk0AY6DaREkPAhCAwDsEdAKwts7UnHhcYQI6eEyjKDgIQAAC EKgvAYyB+vImNwhAIEMEtm3bZqtWrTK2zSxe6WIlw0kGFA4CEIAABOpHAGOgfqzJCQIQyBgBdXDX rFmTsVKXV1wZTDqJWMxwEIAABCBQPwIdPT09NXsNE6Rt3d3d9StNC+cEq/SVBytYpSeQXrIW7UoL Yv/jP/7DFi5cmF6RDEseddRR9md/9mc2fPjwtqFQi3bVNnAiBYFVBEiBR1gVgBMJglUESMxjZ1dX V4z3bi/9mBWT2S2de6cKKDduJfm2YlxY5badQk+wKkQnNwxWuTwKPdWCld5yay48Lh0BLSIeNmxY 4u8G3+3pOEoKVrBKItCKbaMSnWvx3Z7ENuxfic71jss0oXDNcQ8BCECgigS2b9/OycMl8Fy3bp2J GQ4CEIAABOpHAGOgfqzJCQIQyBgBnT7MyED6StfIAMZAel5IQgACEKgGAYyBalAkDQhAAAIxBGQM sCA2BkyClwwndl5KgIM3BCAAgRoRwBioEViShQAEIKC33GyVmb4d6DwGGVA4CEAAAhCoHwGMgfqx JicIQCBjBOjYllbhGhWAWWnMkIYABCBQKQGMgUoJEh8CEIAABKpGgGlCVUNJQhCAAARSEcAYSIUJ IQhAAAKlExg0aFDpkTIcQ1OqBgzgZynDTYCiQwACDSDAt24DoJMlBCCQDQKdnZ2mP1w6AgMHDjT9 4SAAAQhAoH4EMAbqx5qcIACBjBGQITBq1KiMlbr84o4cOdIYTSmfHzEhAAEIlEMAY6AcasSBAAQg kILA8OHDbf/997eOjo4U0tkWESOxEjMcBCAAAQjUjwDGQP1YkxMEIJAxAurYnnzyyXbggQdiEBSo exkCBxxwgJ1yyikYAwU4EQQBCECgFgSYzFoLqqQJAQhAICCgaUJHHnmkDRkyxObNm2fLly+39evX m/bT97vmaCvNcufJNyqu9B88eHBZdex11kJhTQnSNKqJEyfaIYccYgcffDBrLMqiSiQIQAAC5RPA GCifHTEhAAEIFCUwdOhQO+qoo1xHd8WKFXnGwIYNG2zEiBFF04kTaFRclWPChAlxKhX18zqHjQGl JYMJBwEIQAAC9SfQ0dPT01erbIO0rbu7u1bJt1W6sEpfnbCCVXoC6SVpV7BKTyC9JO0KVukJpJek XcEqPYHikp1dXV0FpXp7e62YTFICaqzlxq0k31aMC6ukVpTvD6t8Jkk+sEoik+8Pq3wmST6wSiKT 7w+rfCZJPrBKIpPvD6t8Jkk+sEois9ufBcS7WXAHAQhAAAIQgAAEIACBTBHAGMhUdVNYCEAAAhCA AAQgAAEI7CaAMbCbBXcQgAAEIAABCEAAAhDIFAGMgUxVN4WFAAQgAAEIQAACEIDAbgIYA7tZcAcB CEAAAhCAAAQgAIFMEcAYyFR1U1gIQAACEIAABCAAAQjsJoAxsJsFdxCAAAQgAAEIQAACEMgUAYyB TFU3hYUABCAAAQhAAAIQgMBuAhgDu1lwBwEIQAACEIAABCAAgUwRwBjIVHVTWAhAAAIQgAAEIAAB COwmgDGwmwV3EIAABCAAAQhAAAIQyBQBjIFMVTeFhQAEIAABCEAAAhCAwG4CGAO7WXAHAQhAAAIQ gAAEIACBTBHoWLRoUV+mSkxhIQABCEAAAhCAAAQgAAFHoKMvcIVY9Pb2WldXVyGRxLDFixfb1KlT E8MLBVSSbyvGhVWh1pAbBqtcHoWeYFWITm4YrHJ5FHqCVSE6uWGwyuVR6AlWhejkhsEql0ehJ1gV orMrjGlCxRkhAQEIQAACEIAABCAAgbYk0NmWpaJQEIAABFqUwJVXXpmo+axZs2z27NmJ4XEBGvwd OHCgbdmyxQYNGhQngh8EIAABCGSYACMDGa58ig4BCDQfgQceeMDUgY/7K1dbpbV169ZyoxMPAhCA AATamAAjA21cuRQNAhBoTQJ6+19oBGDu3LmmUYJ58+bZfffdZ3//93+fU9B7773Xnn/+eRszZox9 4hOfcGEyBkaMGJEjJ8NDLpxX1O+xxx6zYKMJe/nll+2CCy6w6dOnuzj6R/ksXLjQdu7cafvtt5+d euqpLiychkY6Lr/88v443EAAAhCAQHMRYGSgueoDbSAAAQgUJaDO+//7f//PvvjFL9rTTz9tAwYM sOeee87Fu+uuu+y0006zp556yl577TXXgVeApgnFuZNOOinHWx15GRtyf/VXf2Vnn322/fKXv7QF CxbYu9/9bmdkKEydfHX+ly5dam+99ZbLMzzFSffjxo0z6YODAAQgAIHmJcDIQPPWDZpBAAIZJaDO uO+QhxGE37Dvtddeduedd7rd3i655BK77rrr7N///d/t1ltvta985Sv2hS98wUX9z//8T7vlllvK miakUYFvfetbdt5557m09t9/f1uyZIkzCpSP0vVh0ueb3/xmzijA1Vdf3R8eLgf3EIAABCDQPAQw BpqnLtAEAhCAgCOgOf7FnO+ES05bOHvj4aGHHrIzzjijP/r73vc+d1/OmoF/+qd/cm//NU1I04M+ //nP2/Dhw11eq1atsvnz57sRAp+ZDIU33njDPcqQuP/++30QVwhAAAIQaFICGANNWjGoBQEIZJeA pgHpr5DT/P9t27bliWjKzujRo/v9p0yZ4u7LMQZOOeUUtybhJz/5iV177bW2fft218Hv6elx6wSi RoumFckgkEualuQC+QcCEIAABJqGAMZA01QFikAAAhBIT0Ad8uiCYMU+4ogj7PXXX+9PyI8YFDIG 1q5d229APProozZjxoz++FpToD91/A899FA3EvC5z33OVqxYYYccckjsNCC/gLg/EW4gAAEIQKBp CWAMNG3VoBgEIJBlAkkdaj9ioJPW44wBLfjVLj8zZ850Hfgbb7zRYYwzBpTWCSecYLfddpt98pOf dB399773vf3YNcXof//v/21nnXWW21Fo2LBhdswxx1h3d7czAn74wx/a5MmTTesFtGbhN7/5jVuz 0J8ANxCAAAQg0PQEMAaavopQEAIQyBqB8K484bL7Q8d0lTGw9957h4Pd/f/9v//Xzj//fPd2//TT Tzc9L1++PHEB8WWXXWZz5syxL3/5y3bhhRfmpHfTTTe5HYu0c1FnZ6cbIfj0pz9tixcvtquuusr+ 7u/+zv7oj/7INmzYYEceeaRpwbA3UKQjDgIQgAAEmp8AxkDz1xEaQgACGSKgRbfRufi++B0dHe5W MrqXQSB3xRVXuKv+kb92+lEaUfl+odCNzg7QX1jeB8vYuP766/v18ekpfPz48XbNNdfEhmnEgcXD niJXCEAAAs1NAGOguesH7SAAgQwSCHe644pfLFxxwjLh+7j0ovJRmULxk8KS/KNp8wwBCEAAAo0l 0BEsQiu+h12ZOmqBm+aW4ooTgFVxRl4CVp5E8SusijPyErDyJIpfYVWckZeAlSdR/Aqr4oy8BKw8 ieJXWBVn1NnV1VVQSsPQxWSSElAFlBu3knxbMS6sklpRvj+s8pkk+cAqiUy+P6zymST5wCqJTL4/ rPKZJPnAKolMvj+s8pkk+cAqicxu/wG7b7mDAAQgAAEIQAACEIAABLJEAGMgS7VNWSEAAQhAAAIQ gAAEIBAigDEQgsEtBCAAAQhAAAIQgAAEskQAYyBLtU1ZIQABCEAAAhCAAAQgECKAMRCCwS0EIAAB CEAAAhCAAASyRABjIEu1TVkhAAEIQAACEIAABCAQIoAxEILBLQQgAAEIQAACEIAABLJEAGMgS7VN WSEAAQhAAAIQgAAEIBAigDEQgsEtBCAAAQhAAAIQgAAEskQAYyBLtU1ZIQABCEAAAhCAAAQgECKA MRCCwS0EIAABCEAAAhCAAASyRABjIEu1TVkhAAEIQAACEIAABCAQIoAxEILBLQQgAAEIQAACEIAA BLJEoKOnp6evVgUO0rbu7u5aJd9W6cIqfXXCClbpCaSXpF3BKj2B9JK0K1ilJ5BeknYFq/QEikt2 dnV1FZTq7e21YjJJCaixlhu3knxbMS6sklpRvj+s8pkk+cAqiUy+f5ZYLVq0yMaMGVP293OWWKml VPKbAqv8z1qSD6ySyOT7wyqfSZIPrJLI7PZnmtBuFtxBAAIQyAQBGQM33HBDJspKISEAAQhAoDAB jIHCfAiFAAQg0HYErrzySnv44YfbrlwUCAIQgAAESieAMVA6M2JAAAIQaFkCGhV44IEHGBlo2RpE cQhAAALVJYAxUF2epAYBCECgqQnIGPDuuuuu87dcIQABCEAgowQwBjJa8RQbAhDIJgFNEfJu7ty5 /pYrBCAAAQhklADGQEYrnmJDAALZI+CnCPmSMzLgSXCFAAQgkF0CGAPZrXtKDgEIZIxAeIqQL7rW D+AgAAEIQCC7BDAGslv3lBwCEMgYgeuvvz6vxHF+eUJ4QAACEIBA2xLAGGjbqqVgEIAABHYT0KhA 3LSgOL/dsbiDAAQgAIF2J4Ax0O41TPkgAAEIBATipgh5MEwV8iS4QgACEMgeAYyB7NU5JYYABDJI oNDOQUwVymCDoMgQgAAE3iGAMUBTgAAEIJABAoXe/jNVKAMNgCJCAAIQSCCAMZAABm8IQAAC7UJA hkAhY0DlLBbeLiwoBwQgAAEI5BLo6Onp6cv1qt5TkLZ1d3dXL8E2TglW6SsXVrBKTyC9ZDu3q9df f90efvjhfhhf/epXbcqUKfbHf/zH/X56njlzZv9zoZt2ZlWo3OWEwSo9NVjBKj2B9JK0q+KsOru6 ugpK9fb2WjGZpARUAeXGrSTfVowLq6RWlO8Pq3wmST6wSiKT79/OrA477DDTn3e33HKLbd++3S69 9FLvVdK1nVnFgajkNwVWcUTj/WAVzyXOF1ZxVOL9YBXPJezLNKEwDe4hAAEIQAACEIAABCCQIQIY AxmqbIoKAQhAAAIQgAAEIACBMAGMgTAN7iEAAQhAAAIQgAAEIJAhAhgDGapsigoBCEAAAhCAAAQg AIEwAYyBMA3uIQABCEAAAhCAAAQgkCECGAMZqmyKCgEIQAACEIAABCAAgTABjIEwDe4hAAEIQAAC EIAABCCQIQIYAxmqbIoKAQhAAAIQgAAEIACBMAGMgTAN7iEAAQhAAAIQgAAEIJAhAhgDGapsigoB CEAAAhCAAAQgAIEwAYyBMA3uIQABCEAAAhCAAAQgkCECGAMZqmyKCgEIQAACEIAABCAAgTABjIEw De4hAAEIQAACEIAABCCQIQIdPT09fbUqb5C2dXd31yr5tkoXVumrE1awSk8gvWSW2tVZZ53lwMyZ Myc9oJBklliFil3WLazSY4MVrNITSC9JuyrOqrOrq6ugVG9vrxWTSUpAFVBu3ErybcW4sEpqRfn+ sMpnkuQDqyQy+f5ZYtXZ2Wnbt28v+/s5S6zUUir5TYFV/mctyQdWSWTy/WGVzyTJB1ZJZHb7d+6+ 5Q4CEIAABCAQT+Cuu+4yjSSMGjXKDjnkELvwwgvjBfGFAAQgAIGWIsCagZaqLpSFAAQgUH8CH/vY x+xHP/qRnXzyyTZu3Dj73Oc+Z1u2bKm/IuQIAQhAAAJVJ4AxUHWkJAgBCECgfQjMnz/f7r//fvvo Rz9q5557rn3+85+3ww8/3P7rv/6rfQpJSSAAAQhkmADThDJc+RQdAhCAQDECBx98sK1YsSJHbMeO Hbb//vvn+PEAAQhAAAKtSYCRgdasN7SGAAQg0BACr7zyiq1du9Y+/OEPNyR/MoUABCAAgeoSwBio Lk9SgwAEINC2BJ544gn78z//czvjjDPatowUDAIQgEDWCDBNKGs1TnkhAAEIlEHgtttus09+8pN2 90jU5uQAAEAASURBVN1326RJk8pIgSgQgAAEINCMBDAGmrFW0AkCEIBAExGQIXD++ee7/fa1teji xYubSDtUgQAEIACBSghgDFRCj7gQgAAEMkDgqquusvvuu8+eeuopV9rly5fbwoULbfbs2fbAAw/Y 3Llz7fLLL88ACYoIAQhAoP0IYAy0X51SIghAAAJVI/Db3/7Wdu7caVdeeWV/mps3b7Zhw4Y5Y0Ce 2noUY6AfDzcQgAAEWooAxkBLVRfKQgACEKgvgaOPPtq9/Q/nqmlCU6dOdV5+dCAczj0EIAABCLQO AXYTap26QlMIQAACEIAABCAAAQhUlQDGQFVxkhgEIAABCEAAAhCAAARah0DHokWL+lpHXTSFAAQg AIFKCVxwwQUuiZtuuqnSpIgPAQhAAAItTqDTz/tMKkdvb691dXUlBRf0D88rLSgYE1hJvq0YF1Yx jSDBC1YJYGK8YRUDJcErS6yGDh1q27dv75/3n4Ak0TtLrAShkt8UWCU2o7wAWOUhSfSAVSKavABY 5SHJ82CaUB4SPCAAAQhAAAIQgAAEIJANAhgD2ahnSgkBCEAAAhCAAAQgAIE8AhgDeUjwgAAEIAAB CEAAAhCAQDYIYAxko54pJQQgAAEIQAACEIAABPIIYAzkIcEDAhCAAAQgAAEIQAAC2SCAMZCNeqaU EIAABCAAAQhAAAIQyCOAMZCHBA8IQAACEIAABCAAAQhkgwDGQDbqmVJCAAIQgAAEIAABCEAgjwDG QB4SPCAAAQhAAAIQgAAEIJANAhgD2ahnSgkBCEAAAhCAAAQgAIE8AhgDeUjwgAAEIAABCEAAAhCA QDYIYAxko54pJQQgAAEIQAACEIAABPIIYAzkIcEDAhCAAAQgAAEIQAAC2SDQ0dPT01erogZpW3d3 d62Sb6t0YZW+OmEFq/QE0ktmqV2dddZZDsycOXPSAwpJZolVqNhl3cIqPTZYwSo9gfSStKvirDq7 uroKSvX29loxmaQEVAHlxq0k31aMC6ukVpTvD6t8Jkk+sEoik++fJVadnZ22ffv2sr+fs8RKLaWS 3xRY5X/WknxglUQm3x9W+UySfGCVRGa3P9OEdrPgDgIQgAAEIAABCEAAApkigDGQqeqmsBCAAAQg AAEIQAACENhNAGNgNwvuIAABCEAAAhCAAAQgkCkCnZkqLYWFAAQgAAEIQAACNSawdetWW758ua1c udI2btzo1uj09eXu17JhwwYbMWJEWZoo7YULF5YVt5J86xG3o6PDBg0a5NiMHz/eJkyYUFY5iZSe AMZAelZIQgACEIAABCAAgUQC6vCvWrXKnnjiCXvqqadswYIFziDYvHmzRY0BLeLXYv5ynNIbOnRo OVGdYVJuvpXonDbugAEDXNlkCEyfPt2OO+44O/DAA2306NEmQwFXfQLltcLq60GKEIAABCAAAQhA oKUJrF692m6++Wa7/fbb7dVXX7U1a9a4kYEdO3bkGQMtXdAaKq8Ov4yVYcOG2dixY+3BBx+0M888 0y688MKyd0CrobptkTTGQFtUI4WAAAQgAAEIQKCRBNThv/POO+2qq65yhsCWLVsaqU7L5q0RlG3b trm/tWvX2ltvvWVvvvmm7bXXXnbOOeeYRg5w1SUA0eryJDUIQAACEIAABDJI4I033rBrrrnGXnrp JcMQqF4D0JSo+fPn27e//W1bsWJF9RImpX4CGAP9KLiBAAQgAAEIQAAC5RG455577JlnnjGNEOCq S0DrDR577DGbO3dudRMmNUcAY4CGAAEIQAACEIAABCokMGfOHEYEKmRYKPqmTZvsjjvuKCRCWJkE MAbKBEc0CEAAAhCAAAQg4Ak8/fTT/pZrjQhodABXfQIsIK4+U1KEAAQgAAEIQCBjBLT3f5KbPXu2 6S/s/PagWjB75ZVXhoNy7uPi9vT0WHd3t9uhqNS4leTr40rBK664IkfPUh4KxX3ggQdMf3Fu2bJl cd74VUgAY6BCgESHAAQgAAEIQAACmtee5NShv/zyy3OCe3t73VaZaYyBaNzFixfb1KlTUxkD0bhp 8501a1aizipIoQ59TkFjHqI6hUXEI8kY0GFuuOoT6FSjKObSyCSlQdwkMvn+sMpnkuQDq3wyX/va 15znF77whZxAWOXgKPiQFVa+05KV8vpKp7yeRPErrIoz8hJpWOmNepyc/NT5LeQaFVc7IiXpXEjf NGFx6fp4xXZiKhTXpxG9lhPHp5GFuJ1dXV2+vLFXQSgmExsx8NQwVrlxK8m3FePCKqkV5fvDKpfJ o48+an/9139te+65px155JE5nzlY5bIq9JQlVjrQRwZBud/PWWKlNlPJbwqsCn3qcsPamZVOC45+ 3ny7KmYMxMX1rMqJmzbfIUOGJOqcW3OlP0VZhFNQvoVcobhx8TyruLBifp5VMbm48FaKyzShuBrE DwItRODv/u7v7IILLnDGdwupjaoQgAAEIAABCDQBAYyBJqgEVIBAJQS+/vWv21FHHVXR/M1K8idu 7QjorV+hN38K27lzZ8kKfO9737P169eXFVeZFcq3o6PD9IeDAAQgAIHWIIAx0Br1hJYQSCQgQ0BO HbBCHcfEBAhoKgLr12+wtWt7TXtqb9+hjn7yfOJt27bZoDJP5BwwcKC9smBBWWXfuHGjbUlcyNdh nUHaw4YPs9GjR9vIESPKyoNIEIAABCBQHwIYA/XhTC4QgAAEChKQIbdu3Xp7e+VKZwxs2bK17Df3 BTOqUuCmTZsTUxowYIBp3u/mQKZvj/E2cuSowFhNFCcAAhDIGIGk3YKEQTsl4epLAGOgvrzJDQI1 JcD0jJrirWniO3bssOXBW/41a9a4xb01zazGiWvqkhvZCBYpy8gZNny4Gy2ocbYkDwEItAiBQmcj LFq0qEVK0T5qYgy0T11SEggwTahF24A6z9o+sB0MgXAVaBrTmmBXuT0372kDhg01jRjgIAABCBQa GYBO/QlgDNSfOTlCoKoEol+q/lmH3Dz++ON23XXX5R0cU1UFSKxiAjIGNgZrBEpx4YW69ZqCE7zk d05v+9OuT9lVto02ZOgQwxQopYaRhQAEIFAfAhgD9eFMLhCoGYHoKZAyBtRRlDEgd//992MMOBLN /Y86zWmd6ld7j48dM8YGDR6UNlpV5LZs3uLe9utgoFIMgkC4KvmTCAQgAAEIVJdAyxgDK4K5tIsW LgwW2K0LFtUV/lHZuHGDDR9e3g4WjYr79tsr7OWXXi6rdivReVPAavwee9jkyVNs0uRJbAlYVg00 NpIfCYjT4j3veY997GMfiwvCr0YENBf28ssvr1Hqu5LVoTt7BYfMjRgxvO6fWRkto0ePsjffWh4s dF5b03KSOAQgAAEI1J5A0xsDW4Pt69TZ+U1wyuqCVxa4kyCLvUHbHizE09Z25bhGxdU2fUMGDy5H 5WD7wfLLq0WLXd1dtu+0fe3Y44+3U/7wFBtd5FTqspQkEgQyQkAjNfrTyIz+qm0YDA5GAkaOHOE6 5APL/J6rtCqUr3Y+2hBsMbojWCSMgwAEIACB1iXQ1MaAFp/dctPNdtONN9iCl18xdVyD42xs4MDC M081dF3uriqNiisDp9zFdZXovCNgtTPg+vSTT9kjjzxqS5cssY9ffJF1d3e3bqtGcwg0AQG9xNCf DINp06bZxRdfXBXDYMCAgTaoc1DwPVjeC49qoOns7DT9DQimK+2oRoKkAQEIQAACDSPQ1MbAvb+6 1779rW/ZW2++adPf/W47PnhzPX7cOBtQxBjQrhyaT1uOa1TcnjU91j2mvA54JTpvDPYB3xrM/f3d c8/Zk088Ydd9/wc2fNRIu/Cii9yPfTkMiQMBCOQS0FZ5Mgr0V6lhoJci27Zvcy9HGmUQbA9GA7YF f8VGaXMp8ASB9iYwaNAg00vMOKcXA1Hnf7uLrb2Ji9sT7NKll3blxE2b79y5cy26BaiPGy1LvZ51 fgmu+gSa1hhYGRy88/1rv2vLli61Qw471D572WV2/Akn5Lyx9h+C6CiAtufrDqa6dAzIH0HQj5fk o3E82t7eXtN83HJcJXF1yMbUqVPLydZNnapEZ32ByRj4zrevtgeCxaa33HSTe+N3/Q9/WFAfdQj0 drAcV0ncSr6MKsm3FePCKn3rrBerqGFwwQUX2D/+4z+mVlSdDXdKcbB+akSwf39HR/73XOrEShbc tYvQ2rXrbMOGDc4gKTkJIkCgTQlMnjzZXnvttdjSqUMf16mPFY54tmLcSBGq9jhp0qSqpUVCuwl0 qgNbzKWRSUqj3LjPPfusvfjCfNsZTGM59/zznSGgDrzSU4d+w/r1tjb4MRwUdEa7AuvYW4s66MYv Nt4jWBg7avRop5repsmSXtu71kYGb77VeR48eHCs2uXqrMRaMa46F+8++GD7RDA96PHHHrM3gqlC r7zySqqDj9RBLtcRNz05WLUnK/9m/e6777ZDDzus6Fs+T0HfM1uCEVCNJg4ZXL83ZYEpEJyHsMV9 l2o3oTROL230vazFxn4koxW/J9E5TW3vkskqqxOCF5ZJxkB6ekgWInDccceV1c/KapssxDIc1lns jbIAFpMJJxi+V+e73LgvzH/BDbdpHv3ZH/5w/4iAfljeDKYN3XfvvTbv9/Nc+iedfLIdfewxpq3r HgyGte771a/cG6sjjjzSzgt2Uhk1apS99uqr9tOf/MSWLH7d9pm0j/3haafZ4Ucckfdmu5LyVhK3 ElaV5BuO+wfvfW/AZpLbtUnTlh566KFwdebdh+PmBRbxqCRuI0dRym3PlZS3kriwKtIQQ8HVYpU0 6qisNEVIf1pYfFEwFU/3qt8RI0bYylWrEkcsQ2q6W30Pbg4643rxYdYRDa7ps/LWX1onHsOGDQsW PI9237eVtOdWjNsM3+1p68rLNYpzq7M6P3hx+bOf/cyNmnmWXKtHYHgwEnreeeeV3K9s9XZVKsFy Pr/lzfEoVbMy5PUWSW/NNA1lTLCXtnd6w/T4o4+5KUT68dYWosvffMv2mLCH23b0Rz/8H3sqmPuu t91aFLv33vvY7JNPsp/e/hP74X9fb25ufjCSoLdbe+61VxC+t08681e9tRsXrMl4dcGuXZsyDwQA EKgCAXX49afOvxYRV8upQ75jR/pOebXyJR0IQCCewIwZM2zWrFn2q+CFZNLagfiY+BYjoL7gzJkz 3V8xWcJLJ9C0xoAfPvfDyr5omzZusnnz5pnm3cpt2LDenvntb93agreCfa81AuA/hEuD9QZPPfmk /cGM9wY75TziDAHFkZX4fJDG28FbNYwBEdntBgQGgToZnv/uEO4gAIG0BNT519t/dQyqaQCkzR85 CECg/gT0Mu3SSy+1t99+2/VT9PISVzkBjSwedNBB9qlPfcrGjx9feYKkkEegaY2BPE3f8egc1Oka g/bG7+3pNS1+nbDnxGDf7ZE2YaLZxIkTbWXwQdQagbHBB3PatKludEE/zi88/7ybu6qGtWdwYI/i 4CAAAQhUk8APfvCDmhgAmjJZaApSNctQalq8QCiVGPLtSECf0dnBSwBtYnLzzTfb/PnzbfXq1bYx OI9D675KmV7XjnzSlknfcxoJ0LSgsWPHOkPggx/8oJ0cTAkXY1z1CbScMaC5te8NhuIWvvaqvfTS SzYq6NCf+v7327R99w2mznbYmUGDGRZsK6oP3qFHHG4nnXKK22b0Ix89JzAENtqyZcsCQ2AvO/UD 72dUoPrtiRQhkHkC1RwJ2PWjOND9KA4OFgprX/86LxEoXp/BTKUdwZROHRDpOz3FIyEBgfYkoJeM Z599tu2zzz72RDBl+cUXX3QjBdqtLDrirn5KuTvy1Wv3s2gtVaJz2rjq8Gt7eG0CM336dLet/IEH HujWf0b14bk6BFrOGNAHZ/pB0+2iSy6xJcGuN8OHDXfPGgVQA/rQh8+2acEowKBgBGFqYCBMCrb6 0g/qscEKdH1Ily9fHsyLH28HHHiADQusThwEIACBZiWgaZJdXd02ZfIkt2Oavsua0WnXN02JeP31 14Ndg9ax5WgzVhI61Y2AFsufeOKJ7o22pgxpG15NX46ODMhfLzjLcerLaCZEOa6SfOsRV3059fXE RgbBhAkTWJRdTkWXEKcljIG4eXf77ref2/lmoE7jHDzI/DZ3Wmx8WDAioB2ENIVI1rOcfkSnB3PO FE/++pGNS1fySVuOFuNaadw4fYrlqfBK8/Xl1ZdV9M1FmvyRgQAEakNAUxr33mvPsg9RrI1W+alq xEJnHuwVTL/ctjU4ByHo5OAgkGUC6mdoTWKhdYnl7PrimVZr9zOfXtprJTpXEjetfsiVR6DpjQHN /f/xrbeVVDp1qvUjWo5rVNzVq1cFc+PGlaNy/zqIciKHyyvWWlSNgwAEmoPAwOANmT9DpTk0KqyF dNUmBDgIQAACEGgdAi1gDOy0a666qiSiertd7iKTRsVNO5cuDkS1dNYmhauCvc5xEIBAkxDQEoEm nRoUT6g5pzHF64ovBCAAAQiIQNMbA/ppGdW16xThtFWmN9zRLUmbPa4W3/npOml19XJVK28w71fD eDgIQAACEIAABCAAgWwQaHpjQJ36T3/mMyXVhna00JZU5bhGxdUiIy2UKcdVS+ftgRH17f+6yl56 8YVy1CAOBCAAAQhAAAIQgECLEWh6Y2DAwAFu69BSuFaySKVRcV8PTlOeMnVqKcXsl62WzlpAfNMN N/anyw0EIAABCEAAAhCAQHsTaHpjQPhLnT4j+VLj+GpuVNxBTaCz5ia31vxkX2tcIQABCEAAAs1B QOv41q1bZ7///e/t5ZdftpUrV7pd/6Jbi2onQO2nX47r6emx7u7ucqI6XcrNtxKd08ZVP0SbwPhz Bg499NC8bVnLKjiREgm0hDGQqD0BEIAABCAAAQhAoEkIaIRdB43dfvvt9tBDD9krr7zijAHt3Bc1 BppE5aZTI3zo2EHBlvCzZs2y0047zY488siy14M2XSGbTKHONAtG08gklauSuEpTH55y0ignji9D VuPqS0y7GsnpmoZDGhnPNXolbpRI8jOsktlEQ1qR1dq1a90Wwe3YWVCZ1BFSGf3GDq1YR+gc/aQl P2eVldr6Cy+8YN/4xjfsl7/8Zarf0GSK2Q3RyIrWQuosBf09+eST9tJLL9nnPvc52zc4TLacGQxZ bZNpW1FnV1dXQVkBLCaTlICGscqN69NUpZeaRiU6NypuJayqpbOMAX80uq7FuFcrX1/Xaa/NwCqt rl4OVp5E8WsWWenE0q3B56+cH7niRBsr4Yf8VUZ9rzSqfhuVL99X6dtfq7PS1KAbb7zR7rjjjv6D UNOXHskkAqtXr7Zbb73VJk2aZF/60pdK3iCm1dtVEpck/3K+6wYkJYY/BCAAAQhAAAIQgEA6As8+ +6zddNNNGALpcJUkpZGC66+/3k3BKikiwqkIYAykwoQQBCAAAQhAAAIQSCbws5/9zLRNOK42BN54 4w37+c9/XpvEM54qxkDGGwDFhwAEIAABCECgcgK//vWvK0+EFAoS0FoMXPUJsJtQ9ZmSIgQgAAEI QAACGSOwYMGCxBJPmzbN9Bd22qhD62i08Hju3LnhoJz7uLh+m85y4laSr48rBR944IEcPUt5mD17 dqL4okWLTH9xTgu0cdUngDFQfaakCAEIQAACEIBAxghoAXGSU+f3oosuygnesGGDjRgxwhkDJ598 ck5Y+CEu7vLly23ixIllxa0kXx9X+lViDFx++eXhIubca23Addddl+PnH7Q4Fld9AhgD1WdKihCA AAQgAAEIZIyA3tInOb3dj74N97u+FIqn9OLiasvNqVOnOmMgKc+kuGnzVfpJOhfKM01YNN1wnEJG xo4dO8Ki3FeJAGsGqgSSZCAAAQhAAAIQgAAEINBqBDAGWq3G0BcCEIAABCAAAQhAAAJVIoAxUCWQ JAMBCEAAAhCAAAQgAIFWI4Ax0Go1hr4QgAAEIAABCEAAAhCoEgGMgSqBJBkIQAACEIAABCAAAQi0 GgF2E2q1GkNfCEAAAhCAAAQg0MIErrzyykTtC525kBiJgIoIYAxUhI/IEIAABCAAAQhAAAKlELji iitKEUe2xgQ6tVdtMdfT01NMJDE8Tfpxkbds2eL2z9X+u+WkUYnOjYpbTjk9u2rorJMFdaqhnK5p 9KlGvr4MpVzT6JaUXqN0blS+sEpqCfn+jWK1evVq2xR85nbu3JmvVIv7qEyrVq2yjcEBSwMG7JqZ 2qjPQqPybVS7alR5K8m3XVmJSVzZ5F/snIGkuEqv3Lhp8tV5BEk6N/JrKU6nYvqUE8enKVblulaJ 26lDJQo5fzhFIZmkMMEvln5S3CFDhlhHR4f7KzWNSnRuVNxKWFVL523bttnQoUNdlehajHu18k1q A0n+zcAqSbckf1glkcn3zyIrnUK6Mugwr1+/oe0MAhkA48aNs3Fjx1pnZ6c1qn4blS/fV/mf8SSf dmbV3d2d95vq22SxDn1cXM+qnLhp8+3q6krUOakO6+FfrG8S1cGzivqnefas0shGZVopLguIo7XH MwQgAAEIQAACEIAABDJCAGMgIxVNMSEAAQhAAAIQgAAEIBAlgDEQJcIzBCAAAQhAAAIQgAAEMkKA 3YQyUtEUEwIQgAAEIACB2hEYOHCg7dixIzaDRYsW2QMPPJATtiFYVK/1QsXm/cfFXb58uS1cuLCs uGnz1Vz7JJ1zClLHBzHGVZ8AxkD1mZIiBCAAAQhAAAIZI6CFvto5K86pU61OfdhpBz8tqi9mDMTF 1Y5/2uijnLiV5OvjhstRz/sxY8bUM7vM5IUxkJmqpqAQgAAEIAABCNSKwKGHHmpJB2bJEIgaA2n1 aMW4actWqtzBBx9cahTkUxBgzUAKSIhAAAIQgAAEIACBQgTOOOMMtx16IRnCKiNw+umnV5YAsWMJ YAzEYsETAhCAAAQgAAEIpCegjuq+++6bPgKSJRHQ+QIyuHDVJ4AxUH2mpAgBCEAAAhCAQMYIHHDA AfbJT37SRo8enbGS1764I0eOtEsuucTEGFd9AhgD1WdKihCAAAQgAAEIZIyAFvT+yZ/8iV144YU2 ceLEjJW+dsXdY4897GMf+5jjKsa46hNgAXH1mZIiBOpO4K677rI5c+bYtm3b7OMf/7jNmjWr7jqQ IQQgAIGsE5g8ebJddtllNmXKFLv//vvthRdesLfffts2bdpkO3fuzDqeVOUfMGCADRs2zGQEHHTQ QTZ79mw77bTTHNOOjo5UaSBUGgGMgdJ4IQ2BpiOgNybanu4jH/mIvfLKK/ahD33Ivvvd79p5553X dLqiEAQgAIF2JqB98Pfbbz+79NJL3UuZ+fPn9xsD0W1A/fag5fDo6ekxbWVajqsk33rElTGgEYAJ EyY4Y+CQQw4xbWnKGQPl1Ha6OBgD6TghBYGmJKAfGr19uvrqq+2cc85xOmpru1tvvRVjoClrDKUg AIF2J6C315rjfvzxx7u/pPL29vZaV1dXUnBBfx0IpgW15bhK8m1k3HLKSpx0BDpVscVcGpmkNCqJ qzRlSZeTRjlxfBmyGldTTGR9y+mahkMaGc81eiVulEjycxKrffbZx40GKKaX0fCq9mL2z/6anHpy CHGT2URDKmG1du1aN40g+uYwmkcrPqtMmiKhMvo3e5WwIm76VgArWCURoG0kkcn3zwKrzmJWqSAU k8lHt8tHw1jlxvVpysIuNY1KdG5U3EpYVUtnGQOabiKnazHu1crX13XaazOwSqurl6s1K51Qecst t9iSJUvc0PFFF13k6g9WvgaKXxvJSruPbA0+f+04H1ZlkoGqMup7pdafhaSablS+jWxXxb7DYbWL QKPaRiX50q6SWm++P6zymUR92E0oSoRnCLQoAb2B3bFjh1ukpjexOAhAAAIQgAAEIFCMAMZAMUKE Q6AFCGi3hW9/+9umXYWOOuoo+1//63+1gNaoCAEIQAACEIBAowlgDDS6BsgfAhUQuPLKK+3UU0/N SWH48OG2bNmyHD8eIAABCEAAAhCAQBwBdhOKo4IfBFqEgLYTvfbaa92owLnnnmvaXeiee+6xyy+/ 3JXg8ccft+uuu67/uUWKhZqeQN+uTRT8I1cIQKA1CGzdutWWL19uK1eutI0bN7pNOaIbBGzYsMFG jBhRVoGU9sKFC8uKW0m+9YirdUaDBg1ybMaPH++2GC2roERKTQBjIDUqBCHQfAQOP/xw+853vuM6 +1dccYVboKkpQhdffHG/stp61BsH/Z7ctASBHTt3mPb11g9jK7jNmze5dSutoCs6QqAWBNThX7Vq lT3xxBP21FNP2YIFC5xBoM9x1BjQrn1+045Sdalkv/9K8q1HXH/OgAyB6dOn23HHHWcHHnig24Sg HTdZKLXuayGPMVALqqQJgToSOOOMM0x/ce4973mPO8Y9Lgy/5iewZctWWxl0LDqCQ3gGBwaBfiSb 0elkVem6avVq0xtRHASySmB18Bm4+eab7fbbb7dXX33V1qxZ40YGtLlD1BjIKqNi5VaHX0aSdiEb O3asPfjgg3bmmWfahRdeWHSXw2JpEx5PAGMgngu+ZRBYtGiR6U+LWXEQgEDlBNSxfvvtle5tu9aC DBwwsPJEq5xCMJPJ6afpA9rCT28OcRDIIgF1+O+880676qqrnCGwZcuWLGKouMwymrTVuf50Pslb b71lb775pu21117ucM1mfSlSccEbmEDzGwNBo8DVkYDHHVjmaZw6/9dff71pn3v9aXoKxkAacshA IB0Bda5XrHg7nTBSEIBAwwi88cYbds0119hLL73EdLkq1oKmRGk9nHbMmzlzpu25555VTJ2kRKBp jYEhQ4a4A3j0Q6i3Y4MHD6bG6kBg48YNwZSEDhP/JOcNgHvvvdcefvjhJDH8IQABCEAAApkhoM0b nnnmGQyBGtS4+oKPPfaYzZ07l6mvNeDbtMbA5MmT3ZwxDbPNf36+HXnUkTUoPkmGCWjXg6VL33CG l/iHnTcA/AhAOIx7CECgdQhoPu7AAQNMg4Ca68885tapOzRtbgJz5swJ1s4wNahWtaTDNO+44w6M gRoAblpj4JjjjrXusWNM81C///3v25e+9EXbM5gvhqsNgXXr1tkNP/yRrQzmJ0+YOMFOPPFE8waA tqbUfRonY+Gkk04qKiorn10UimJyArBKx0lSrcpqv/32s6/9y7+kL2gZkkOHDrWu0aNt1KhR/bsT bd221Xp719q6dWvdAuAykiUKBCDwDoGnn34aFjUmoNEBXPUJNK0xsO+++9rZwR7q373mO3bPL+62 kcOH2fHBzijjx+9hAwcW3lGjHvvgxlVFJflqz+BlS5fGJVvUr5J8ZQSoA/Xcb5+122691Y0KnDhr lh1/wvG2JlgMKJfWECiqKAIQgEAsgcWLF8f6V8tzRLD4WLtyjBkzJtihY2jwHbprIfL2YMHj8GDH jiHBNEztgrIpmJuLgwAEyiOg3/Ekp7V00fV0fntQjc7pAMkkFxdXi/W7u7vdyF6pcSvJ18eVrtrO ulxXKG6hGQgcqFku8cLxmtYY0Fvjj3/8E7YyWDh3989/brfdcqs9+sijgTEwvv+HLKlolbwdbFTc 8AcsqVxJ/pXorPUY6zest8WvLbKBgzptdvBW/+JLLrGu4EtGf9qfXn8yCLRQuNgogb60fvCDHySp 2u/f29tb9hZh6jhNnTq1P61SbirJtxXjwip962gkKx08pC1Ea+HU8R8TjLLuscd40+hA2HUGYRop kMzOvmB70OUr3NShsAz3EIBAOgL6LU5y+m2Mnvfif1PSGAPRuP77qpy4afOdFbwYjObr46qchTr0 SRy8fzRd76+ryiSDIM6xdXEclcr9OlWxxVwamaQ0Kok7YuQI+8RFFzrr94nf/MaWvP66ra7RD2aS /vXy1w/xgI7CIx610kXbdO23//52zPHH2gdOP90mT5kSTB3IbRd6o3jZZZe5v9eDerjhhhvcn+7D Th/UaNxwePg+rVw4jr8nridR/Aqr4oy8RKNYafs8zYfVj2C1nUYCukZ35RkC4Xy0n3d3V1ewJ3qP O+QsHFbpvcqksqmMfkSiUZzJN31twqq6rPTCL46p/Ip97hsVV+sfknROTydeMi5dL1ls3UWhuD6N 6LWcOD6NLMTt7Ap+AAo5QSgmkxRfw1jlxvX5HhacsDplylSbEWwntXDha65h7gyGtgs5NaRCu+E0 Y1xf3kK6JYVVVt6tNn6PPWxSsGD4qGCR9sQUW3Yddthh9pWvfMX+9m//1h2oEh4x0K5Paeq8kvJW o10lsSzkX4nOjYoLq0I1mhvWSFajg7n8W4M9tWtxuubIESP71wjklnj3k/LVZ3dkMEKhjkc1ndKW saEyasS3UZ+FRuXbyHaV5rs4rq5hFUcl3i8tK7dmJ9Lf8nGLGQNxcX27Kidu2nzVj4q2IR83nkZ6 32i64ZjF+m+F4obT8feelX8u5VpJeVspbtNOEwpXVld3l806abbNOHGmO8lPO2AUcnoDpR+eclyj 4i5ZssSiO/ik1b8SndetXRcszN6zaGchSZdp06blTCVifUESKfwh0BgCAzsHBicXdxTN3O0yFMji IAABCEAgWwRawhjwVaK3Smk6+fpRK9Vy9Hk0Kq4sSC0GKsdVqvOgQYPKyTYvjgwD/eEgAIHmIbB9 2/ZU6wB27tSpn8lznpunRGgCAQhAAALVJNCYSerVLAFpQQACEIBAIoH169e7gxsLTSdQ2NatW9zI a2JCBEAAAhCAQFsSaKmRgbasAQoFAQhAICCghfy1cH7x4eBg/q+2EY1zGzdutJ6e3podmKSyaQQT BwEIQEAEknYLUph2SsLVlwDGQH15kxsEIACBPALqLA8NOuu1MAh2BGusVge7BHUEeYwNdgXT4jx/ 4N+2YNHy5s1b3BkDOlek0OhBntIpPXzZMAZSAkMMAhkgUOhsBNYe1r8BYAzUnzk5QgACEMghoA7z 8OBgsBEjhtuOYLc0/VXTaWvPFcGZLbpqC9EhQ3adN7B58yZ3uOC6devd4YPVzFNp6YBIjUZoN6Fa GDrV1pf0IACB+hAoNDJQHw3IJUwAYyBMg3sIQAACDSKgPfj33mtv277tddsQTNvRrmla1FuaS5bX dCH9rVxZm8PNzPw0oD7X8ddIgAycSZP26T9foLSyIA0BCEAAAvUggDFQD8rkAQEIQKAIAXWeR48e Zfvvv587jXjp0mXBPP41RWLlBvdZX9AlD/57ZytRP+1HqxE0TUjO+Wn+fmA36G39ruk7wUPwv5/W 3zFgoPWpbx86BE3bk3bYAOe1c+cO99Zf8rvi7/KXKTKgoy/YGa3LJuwxwcaM6XajArtklDsOAhCA AASajQDGQLPVCPpAAAKZJaBOsw4Y2nPiRFu27E2b/+J827xpS2oe6oy79/P+n1Bnvr+nH0rNiYWe +2+9VdDv8U667zzn5iPPICV5Bm7Y8CF2YnBI5IQJe7i1CRgCu7jwLwQgAIFmJYAx0Kw1g14QgEAm CehtvU4DllGgN/Fr161rKQ5Dh060IYH+1Tq/pKUKj7IQgAAEWpBAbfaya0EQqAwBCECgmQiMGDEi mGYzpplUSqWLdJbuOAhAAAIQaA0CjAy0Rj2hJQQgkDECY4ITyQ86aHqw88/gxJJra9By38BXElfn EmhxcJzbf7/9TLrjIJA1Avos6nMV5+J2z9GCfo0A+rU9cfHkFxe3J9gKuDv4nJUTN22+c+fOtegW oD5ukq619tfWyLjqE8AYqD5TUoQABCBQMYHx48fZjHHvsfe+54TEtNauXRssOh6dGF4ooJK4r7/+ uk2ZMiU2ea0RYJ1ALBo825zA5MmT7bXXXostpTr0cZ36WOGIZyvGjRShao+TJk2qWloktJtAR2Bd vrPsa7dnte685Vqt9No5HVilr11YwSo9gfSStCtYpSeQXpJ2lR1Wl156qd14443pC4xkyQQuuOAC u/rqq0uKx2ewOK7OruAAmkKut7fXiskkxVcFlBu3knxbMS6sklpRvj+s8pkk+cAqiUy+P6zymST5 wCqJTL4/rPKZJPm0Oqvzzz/ffvazn9mGDRuSioh/BQQ0NfG8884ruV/Z6u2qVGTl9IFZQFwqZeQh AAEIQAACEIBAhMCMGTNs1qxZZa/jiSTHY4hAZ2enzQy2LNYfrvoEMAaqz5QUIQABCEAAAhDIGIFx 48aZpgodeeSR7rC9jBW/ZsUdNmyYHXbYYfapT33Kxo8fX7N8spwwC4izXPuUHQIQgAAEIACBqhDQ GSGzZ8+2NWvW2M0332zz58+31atXm3bf2r59e9Gdf6qiRBskog0INBKgaUFjx44NdlU7yD74wQ/a ySef7E5Nb4MiNl0RMAaarkpQCAIQgAAEIACBViQwcuRIO/vss22fffaxJ554wl588UV7++23TVty 7ty5M6dIMhDU6S3HVbLFp4yUFStW5GS75557uk53jmfMQyU6p40ro0pbru6xxx42ffp0O/744+3A Aw+0UaNGxWiEVzUIlNcKq5EzaUAAAhCAAAQgAIE2I6Dtfk888UTXuZYhoAXFOn8geiaA/Ms9oG/5 8uU2ceLEssjdcccd9o1vfCMn7he+8AU3vSnHM+ahEp3TxpUxICNJbGQQTJgwgUXZMXVRTS+MgWrS JC0IQAACEIAABDJPQAeQ7b333u4vCUY5u774tBYvXmxTp071jyVdjzrqKPvpT39qixYtcvGmTZtm l112Wao0KtG5kriplEOobAIsIC4bHREhAAEIQAACEIBA6xHQ2gbvZAzgsk0AYyDb9U/pIQABCEAA AhDIGAFtgerd5Zdf7m+5ZpQAxkBGK55iQwACEIAABCCQTQIXX3yxK7hGBcKjBNmkQakxBmgDEIAA BCAAAQhAIGMEZBAwRShjlZ5QXBYQJ4DBGwIQgAAEIAABCLQrAU0Vuuiii9q1eJSrBAIYAyXAQhQC EIAABCAAAQi0AwE/VagdykIZKiPANKHK+BEbAhCAAAQgAAEIQAACLUugo6enp69a2m/atMm++c1v uuR0gEWQtnV3d/cn/7Wvfc3df/azn7Vhw4b1+xe7URpz5syxmTNn2q9+9Sv7m7/5G3cQxZe//GX7 wAc+4PIplkaa8O9973v2/PPP29e//vU8ca+7AvzBIdrjV/mPGTMmTz7OQ3Iqx4wZM/KCPauHH37Y Hbut48yr6VQmHeCh0xH1p5P8xHPw4MHVzKYuaXlWdcmsxTOBVfoKrCYrfV/oc67PWNj57xF9PxZz hb4vvvrVr5q+K/R9Ug1X6LvPp6+TVPW3bNky23///e3YY4+1cePGueCwPuF7HzfL12q2q3bnCKv0 NQwrWKUnUFyys6urq6BUKYdEKK21a9fabbfdZv/8z//sOunh9L///e/bueeeazr2upgL5/vrX//a Ojo6TGn9//bOBdiq6Y/jWzJiGOYv0UTjXVGhhDKZ6cXoQUWiPEYlPTxKkyFpEJMR4zUVMh6lUCMj k9IUyjuK0mR6MZOIJoYJk1f9z2fpd+66+6x9zr733LqO8/3N3Hv2Xq+91mfvvfb6rfVba61evTpq 27ZtNHPmzOiGG26I8POvQbp+3ELX8f1XrVrl0o6nR5gPPvgg8pfiwu25556LHnnkkYhykadC10WJ oEEeSp8XG3f8Fy9eHAzDNUNS6LrEufvuu6M777wzQmFjR0Skd+/e0ZVXXhlNmzbNnVf131VXXRUN HDgwh0uadNLkOSkdY5Xkn8+9mOuWYlyxyvc0VParSVbUF+edd17Oe4zyvWTJkkruSc9Vvvpi//33 dzt0UoJQfVK5ZOEz/7rUfR07dkxMq2/fvtG6deuiFi1auF1Ply5dGuE2a9asqE+fPpHlh7xQ7lDZ LRf+dc0t9MuGSNdcc0301ltvZb3Txs1G8A5qK25NPldecQoe1lZ5i7muWBW8rdkAYpVFUfBArAoi imp8zsCAAQOiSZMmRZ9//nnEltwmnLN9Nv4IDd4vv/wy2rlzp+tl6ty5s3PnQ4mcdtpprgE7bty4 iK2pEfNj9jsfo0svvTTbS+8CZP7RU/b++++7bcBPPfXUiD/E4v7www9OoSBdX1BiPvzwQ6dg+O7+ Mctv+UtwsTZv165do9dee80pA4T97bffonnz5kVr1qyJmjVrFnXv3j068MADs8mg1Lz99tvu3E8L Nl999ZVTeiywH478r127Nho8eLB5u9+5c+e6fPfq1Stq06aNS9tP1w+Mu6/QtGrVKrrwwgvdaI6N 4PDh/fjjj6OTTz45at26ddSwYUOXhOWFE/JCA+CTTz5x99P84tdNcvfzpGMRKGcCKOevvvqqe/dP OeWUqFu3bomjpuwYumHDhuiEE07IQUa98/rrr7uRTeqdHj16uHRQKKgrEd5bzuNrilvdN2bMmJx0 caDRT/p0vNgoKLufUu9RD8TF6mtzt7xt3LgxOvbYY10dZAqM1cvUP5Rv5MiR7rtheSUNC+PXXZa2 fkVABERABIon8E8ru/h0sinQwOzUqZPrLc86Zg4YhsYd/7vuuiui8f/NN99E3333XdSlSxfnRng+ VvRg89GgUY3QyMTdeog2b97sjnHzG6D9+vWLGH63sB06dMgOo/MB5FqjRo3KpuMS3/2Pnryjjz46 +KH1w/nHNOz5MNOIR7Zt2+bMAmbPnu3ywKgBZgLWE29xaUTfdNNNdup+X3jhBTfKQN7JtwnHgwYN iqZMmRI9/vjjTjGyLcRnzJgRXXTRRU6peuCBB5y/H9fSSPplmB+x9FCu7r///ogP/R133BE1atQo oscQ4YNM4/6KK65wv9yjL774wh0TjgbDO++848LaP/JSt25dO9WvCJQ9AeoMky1btrj64dlnn3X1 xZNPPunOqUfiQl1y++23R9R9K1eurOS9detWF49eeuoPq3csHepIesYYyQyJ1X0nnXRSyNt13NAJ YYqABbr++uvtsNIv9QT1A0Le2rdv70YQUHzI2/nnn+/qSvzJG/XItddeGy1fvtyNTFCvUQ7SwW3h woXunPASERABERCBmiewR1pq9P7zN2LEiGyOacw+88wz7pzGsg0v40DvM3MN/B6rhx56KGfJKz4w /PFB5dd6jEiD3uz58+c7O9qjjjrKfVRouGICQ+88Qs8ToxH+B9l5ZP4xKnDWWWfZaapfzIMYiaBs COljQ0vZEMrTvHnziPIOGzbMufEP05zRo0c7+9umTZs6d8yeHnvssWwY/wAFyuKjJFHuYzKjI2PH jo2wzx0yZEi2vH68+DEfWJMff/wxeuKJJ6LjjjvOjcLw0WY0gB5FRgQQ7gt2yS1btnTn69evdx9m wpEW5aLBf+KJJ7oykX8+/AimYmeeeaZrpDgH/ROBMiPAe+rXUfHi0/jnvfNNHemQoP6w993iTJ06 NSK8zTfq2bOnebn3sH79+sF6h7oBobOAnvmQ5Kv7aKgzmsq7nFb8eoZ6IF4nck7dMXToUJckysiy ZcvcMaubLFq0KPutoI669957015a4URABERABKpBYI8oA/TQY+tJpY5NOcPJCO4Mc/NxwYyGEQKT r7/+2vV6cc7HgYZ1VYTeMnrh+fj8/vvvzoaVXnv/Y0zDO6QIcJ2PPvooGj58eN5LYlPrCyMaTMxl EjFCw5k8+OViGJ0PvgkfyiOOOMI1nqdPn+4+dCtWrHATeemZpzcsLv5QPEqAjUTQo09j3oR5C/Sq JQkTr+khxKaTPxoejAQgDRo0cAoKozGYWTG0z7X8UQ0mDqIIhAQFB9MuzJ0oH72Q3G+JCJQrAb9R HGKA2R/vrC+c0zj3lQGUcBY2oCPAhNE43mGEOi5U7/AumowfP94Oc37z1X305iP77rtvTrw0DtRn 8bxRZ/n1CqaKJtQ5fp3NYgcSERABERCBPUtgjygDZBnbT3rNUQZefPFFd447igDzBOIfSsKjECA0 5vMJk9UQPw3S5dz/I0waO1Ma13yYzz77bKIkCj14DGsjjGQwemFzHXD79ddfXdmSFA7CmDBqQSMf cxx/9ML8/d/DDz/cP6107M/LoHGfT+gdNGncuLEzA9qxY4dzomwoCygk9erVc+ZPxtni5CsXczNg Ta8mZcOkC9MwiQiUKwHqCqsvjIHfUYBijn2/L7zD9Mb7YiuL/e9//8s6++/99u3bo7///juno8N/ X/3jbCKZg0J1n9Up1I+MPlRVQnmjE8Wvu21FolDaLKggEQEREAER2LME9pgycN1117lea3qAMIHB PAfBpISecibL+T3eVsxQz7j52S+N1bhg70rvF3b1LJtpE9Ti4ULnjESgCPBRst62UDjfjeVRMUvi mta7zsgDk/VsboMfPn7Mahs2tA+fJHveeLz4Ofb9psQwMlFI4o0TUwbojWNugt8jidmP/9H2j0PX wTSMOEwg5N4y2iARAREIE6AOfO+99yp5UheZKZB5EA6hDrWRuU2bNpm3q0uZr4NCH5dC76xf98Xj ck5HBPUCHRbxfC1YsMB1ZuQz48FMMl4nUsemrZ+lDITuitxEQAREoGYJVFIG6F2PCytN/PXXX5Wc 8/XkWECGtOktZnIc9qb0ZFn6THql1xg3TEpYTYOhcUx88gnxbdiaY/KGcIydOz1nNEaZ7IYJTf/+ /d2EYUyWQmL5QQHho2Vppi0vowMoIfR08ccQP9dnLgFlZPidCcs0sM1kxvJMfmg8YzsLH/vI+/m0 sJZP/P7880/HADcm7aKQkPdffvklZ2KhnxbHpOenZW6Ul958RjkwrcIEgaVI2QuCSY7ML4gLPY18 0LH1ZaIiSgYroTAShHKDsmTXSvO8kL6Fj1+ruueh9GCQ9v7GrwuHeNx4GM5rurxpJ2GHykuvctzU Im3+SrG8xdzfEKti7m/ofcP8jneYe8X8GkbrMIm8+uqrXf1H43zChAmVLkuDmPqBDgPeL8yGLB3u EelgrsicLExu2AsAt5deeskt5VwpMe+EuH7d53lVOmSZaBT7P/74I7r44ovdIhAPP/ywW+CBupaO DUwLrVzU0XZsZbS8UScSZ86cOQXnITDaAQ9YkX67du1cHRZ/B//tz3MlmHlOQu9vMc9zKb6/oXfw 335/i6mfi7m/IVahxystv9DzF0qvtspbis9zMfd3b5e3kjJAgzIumL7El4pL+3DRO0ylz6QwP20m /06cONF92Phw0JBnopj1AsVNe+ycNPggkR+O+SAy6dfS5qPFahUsbUqvO0pAkiJAOS0eHygaspxX pbyMcnA9rstKSazBjRkAH0o+2igKLD3KB5q06cEnzyYoA0wCtonV5k7DGoENcSyfuPGBhAFubGDE PAdWUOJa7LvAyhshIU3S89MinJWX9c+5L9wrbP+N2+TJk51JVMjM4PLLL3cNgtNPP91tQER6KCjY N/v5Tvu8xPNGesVIKD0rr59u2vyF4vrp2HHa9EL5szT8X1v21XcLHYfS43mLu6fNXymWN5TntOUN sQpxTpte6H3j3eUd5p7QWcI7h7kh7x0978wjsvrOfskDixEQFoWAusrmR1Fe3lf8UQioU1AcMM2k /mVkgHRCIwTE9eu+UFlxY3NFRiKo1xgJxYypSZMmrqODEWATK1eojJY36kyObUKyX0ZLx37pmLjg ggtc/cnqazAr5v6G4tq1/N+09zf+XvlpVOc4lF4oz2nzF4obylfa9EL5C6Wn+ipEpaK94fuG7lHa +1HT9dXeuL/FlDcU12dpx2n5qbxG7J/ffTIfiewSM5icxAWbT8xufOHjkEbozaGXuZCE0gsNJYfy F0qbyijNMDTpWfGtsVtMedkQLc4qlD8rL0oAH1fiYU5l7hanUHn5kCMs1Ud5GYWhsZBkphRKr6bL SyOFXk6WCjSJlwv3Yu4v8UNp4u7L3iivfz07DuWtmPJW5Xm2PNgvy/fG38FQ/iy8/1vV59mPW1vl LeZ5rs36ilFSq4N8jv5xmueZ+oxJuGmEvV+orwpdN/S8kJe4eyh/fj7IG9cq5nku5v7W1vMMgzgr n4sdh/iVYnmLub+qr9I9KzwztVlfpW1f2bNtv7X1PFenvrI8F/M811Z5q/P9rWsF5jekUe23336V Ng/zwxc6Zl3qUJqF4iX5p02LHqo0EkqvmPJipuRP7EvKAxOlmWeAeQC9ZP6mZH6cUP58/88++8yZ FGDSc+6557qeOnrvkiSUXk2VFxMvRoHY+OzWW29NykJe91D+QhHSDmeG0qup8obyVVW3UP5CaRTz PNN7lPY68WunfZ7j8ZLO0+ajmPIWc39rs74q1CCHaYhfMeUlvTT1VdL9jLuH8hcPw3lt3d/aep5V X4WegvDzrPoqzCrkWpv1VSg/cbdQfVBMfVVb72+51FeVlIG4bTE3FxAh9/iND53TyK1u3FB6adNC K0ojofSKKS9mTqE043lh0zFelKeeesr16sf97bxQWjS6GWZngh6Th9mBNN9eCaH0aqq8aN7Mk8A8 qroSyl8orbQf11B6NVXeUL6q6hbKXyiNYp7nYt7BtM9zKM8ht71R3mLubzGsSrG85XZ/a6u8qq9C b0cU/FYW8w7W1v0tpn5WfRV+NkKu5XZ/93Z5KykDoRsgt5ongP2+zQsoJnV69TARwj4/zbBdMdcq FNffMK5QWPmLgAiIgAiIgAiIgAj8OwjU+XdkQ7kQAREQAREQAREQAREQARHY2wT2ySzBmZ1AvLcv ruuJgAiIgAiIgAiIQFoCNi9uxIgRaaPUSrjnn3/erbyVtA/H5s2bo5dfftktSx5aWjxNppmUz6p+ WAfUBA9WNmNhElYjqynZE2la3lgRCLNrNrhlvgn7orAvC5unSqpIIPMw5ZXMLpl5/fN5omhUV4q5 binGFav0T4pYiVUSgWLefT1XSVRz3cUql0mSi1glkcl1T8MqY2K7K2OWmhO5mHd/T8TNrKq3K7O6 X04+zQH/zA7fuzLLCptTqt8VK1bsggGsdu7c6Y4zKwimimuBksqb2ZF816effmrBgr9JcS1wPE9+ moXiWhqh31DczLxJOrN3ZZY43gWDkSNH7sosX7wLtr6kea788P5x6Lq+f77jUoqrOQNVVJ4UXARE QAREQARE4N9BgMUrli9fHq1Zs8bNxWN5axM2M800RqN169ZFl112mdsfA78lS5a4ILbPBTuBM2HT ztkjZN68eW7PnGbNmkU9evRwm3D6cVmal42h2AMjLmw2xbXHjBkT93LnbBg2d+5ct7M3+xDRe84S lkimAek2ELW84JZpzPLjwhCPScv04Ddu3Ni5848NBCkX+46wmIcvuOOPH+na6mWsSMhSxGz8yvK3 HJvgF58czdxENpRFyBPxyC/XI22Ea/G3cuXKSuk5z8w/wuNP+hmlJsvc4rL/Cn6EIa+ECUmmEe6W Umefp9tuu80FISz36sEHH3SjBd27d3fuixcvjljF0TbD5RoI1zCBD/GbNm3qNsM1d//ZYPSBhVrY S4nngntXr149F9TSWrVqlXsuSm0eZR0rsH5FQAREQAREQAREoFQIsMs2Ddhp06ZF7FHAZpmY5yCZ XmLXWHvjjTeiDRs2uMYbjTiERh+NSROO2dQPYc8fFIpZs2a5MGwsyjnuCOFYIQp3Pw3nufsfO2dn ev3dZqC+ux1b45t0WRacPYJMSLNDhw526n4xjSIMSgT7CKGEcA2E8OwvhD/HKCdsfmp+bAqKsoEf ext17NjRNfI5x7SIP/xp3JMG3BAa5FzL/nr27JlN95VXXnGNfxQt0iG/Zr5Foxq3zAhDTpooAuSH fBCGBjP5QTjnvvTq1cstu845x+QpJCg07H4+c+ZMpwhaGPKC2ZApAv369Yvuu+8+lz5l4Xrz5893 wTknv/3794/efPNNt9T71KlTLSkXB0UDU6Tvv/8++Fxs27bNhevcubN7Lh599NFs/FI60MhAKd0t 5VUEREAEREAERMARoBeWBiUNdHqx2YgLO3J6gek5nzRpktuJm8AHtOfbAAAJu0lEQVTHH398hJ0+ NuX5ZPbs2RFr2qMMIKTfvHnzCPdhw4Y5N3qeGW2gQRrvPScAowJJy3zTyEWRoNFOfHYfZ68gs/mn wRwXRg0IS882DWZ6oS28hbVG8zEZ5YgGKfnmOqRHwxzh2jTGGfUYMmSIc2NkhYY/AkcT8mVC2qRL Ix4hL7ihICD4oZCQJ65LeYhPXmlsm0yZMsWFZY8lhPzAmrQypj3OjREGlBOEvJOunxfnsfsf10Ih aNeunZs30bZtW6dAtGzZ0oVYtmxZtGDBggilsUuXLs5t0KBB7l6yuznCfVy4cKHbuR2lkjTHjh3r /FB2GAEib6RRv3797HMxbty47HMBywMOOMApE+vXr3dxS+2flIFSu2PKrwiIgAiIgAiIQMTkXBqm /NET36lTp+xuz+PHj3cNQHq8mzRpEt1yyy2JG3z6KGm80mNvvev49enTxzXATRmgAco1kwRFZPjw 4UFvGt7kyRrSNDTpjee6NJ7xq6r4JkWY+1jj3r8OaZJnrksD14Rr5hMUCfJHLzpKCcoPaaCQGKM0 eabhj8kNPei+YLKDQoKQP9/EyUyn/PD+McoRjXl6+hctWuQa/ig0jBA9/fTTEcriOeec40x7UBQR nhP8TLZs2eIUAc65zygeKAGkzURqRhZQArg/pGVlJjwTlbdu3cqhMzMzhcM5lNi/OiWWX2VXBERA BERABERABByB1atXu9/Jkye7Xn96khEUA0w/GCUYNWqU87NGpwuQ8G/79u1RZhKs67WmAcsfgo14 GqEhuXbtWtdTHQpvvfXsIExjt06dOtke8FD4Qm40oI/J9MyHhEZ6qEG9adMmF5y4viIRT4OywJER AZsTQBhGAGg0M4eA+CggtSWUoWvXrq5XHtMpM6niXmPOZffP7iW/AwYMyGaX+Cb07jNywCgA4RjJ YLUmhBGn0HPhx63JHd0t3b31q5GBvUVa1xEBERABERABEahRApj98EcDlQm79AybyQm93vzRsMPU Bz8zdWEyqAk9+SaEW7p0qesJN7eq/NIgZanPww47LCcaNv+YotDLTr7oZadBTe9769atnXlMvGFP 3umVjs8j8BOPmxbZJqQ04G2UwMJz3qJFCzt1ikj2xDsgr717944wh7FRDLzJD2ZIc+bMybqb2Y8X PeeQRjf5iufVGOREKOCAKRJcMN/yWaMYoBAybyCzslB0zz33OLMf7kkaYaI5Jlws90qeGSVCeMbe fffdiMnIcYEJu2cffPDBca+SOa9TMjlVRkVABERABERABERgNwFMcfr27evMTBgBoGe3TZs2zvfm m2+OZsyY4RrcmIvgd8YZZzg/lAUUACYFY6+eWa4zy7Rbt26ukWkTSTFtQUEwJSIbMOEg33wBGqn0 oqMI+EKjHTt38oIyQKPZJuTS0I6b4dCAZsUiGtY0RFm5x4QGrPXiU04mK9NoRlBCWI0I0xckHtc5 7v4HP9KJz03Am/xZnkgbBQOzIb+h7x9butjWw8DyQ3lJh1GGqsrAgQOdiQ6/KCYIZSW/O3bscCY8 mHNh4sO9s7kRPC+jR49OvBxKF6NNjA74pl4oGeQb5QNBMfCfi4MOOkjKQCJVeYiACIiACIiACIjA HiDABOEjjzzS2ZmzKg8rCtlqOBMmTHATQ2nQXnLJJVGrVq2yjTtsyun5btCggVMEhg4dms0dDfXp 06e7hjkN68GDB7v4xEkjjAwkTR6m0cwE1bhwHRqxNOo5ZgItygAmPjSyGdEwUxwa+Jir0GNNA5fy mR/pEueY3WZD2L1jKkV80qU3nXOWJOU8Hpd4uKEkYCLEHzzsj4Yy8Wh805DnWjTuaWyzzCar/+B/ 4403Ort9wlia5K19+/bOnIf8ENdGSThGMDmyY879uJz70qhRIzeZF/MtrtewYcOIZUZRBkmXDcho oGP3v3HjRlcuRjgo28SJE/2kKh2Tf0yFvv322+yEcQKwChH3hJWJCJPZ28DNMeC54Bxl00ZkKiVY Iif7ZMD8YxCXkOHqDuGQHA+q/5AmXCLoXMx1SzGuWAUfg6CjWAWxBB3FKogl6ChWQSxBR7EKYgk6 ilUQS9Bxb7Oi+UNDLqnNYP7BzO529ONac4o004gfN014P8zeZmXXLibPtRW3plmleS7gVVvlrc51 69oN1q8IiIAIiIAIiIAIlAuBQo32Qv5xTlUNH4+v89Ig8F+8z5ozUBrPnnIpAiIgAiIgAiIgAiIg AjVOQMpAjSNVgiIgAiIgAiIgAiIgAiJQGgSkDJTGfVIuRUAEREAEREAEREAERKDGCeyTWf4p7wTi Yq7I0lL+zPBi0vqvxxWr9HdYrMQqPYH0IfVciVV6AulD6rkSq/QE0ofUcyVW6QkUDlm30FJI1ZmV bJflYS2UvoWN/xZz3VKMK1bxJyD5XKyS2cR9xCpOJPlcrJLZxH3EKk4k+VysktnEfcQqTiT5XKyS 2cR9xCpOJPdcZkK5TOQiAiIgAiIgAiIgAiIgAmVBQMpAWdxmFVIEREAEREAEREAEREAEcglIGchl IhcREAEREAEREAEREAERKAsCUgbK4jarkCIgAiIgAiIgAiIgAiKQS0DKQC4TuYiACIiACIiACIiA CIhAWRCQMlAWt1mFFAEREAEREAEREAEREIFcAlIGcpnIRQREQAREQAREQAREQATKgoCUgbK4zSqk CIiACIiACIiACIiACOQSkDKQy0QuIiACIiACIiACIiACIlAWBKQMlMVtViFFQAREQAREQAREQARE IJeAlIFcJnIRAREQAREQAREQAREQgbIgIGWgLG6zCikCIiACIiACIiACIiACuQSkDOQykYsIiIAI iIAIiIAIiIAIlAWBfX766adde6qkmbSjQw89dE8l/59KV6zS306xEqv0BNKH1HMlVukJpA+p50qs 0hNIH1LPlVilJ1A4ZN1DDjkkb6iff/45KhQmKQEe1urGLea6pRhXrJKeolx3scplkuQiVklkct3F KpdJkotYJZHJdRerXCZJLmKVRCbXXaxymSS5iFUSmQp3mQlVsNCRCIiACIiACIiACIiACJQVASkD ZXW7VVgREAEREAEREAEREAERqCAgZaCChY5EQAREQAREQAREQAREoKwISBkoq9utwoqACIiACIiA CIiACIhABQEpAxUsdCQCIiACIiACIiACIiACZUVAykBZ3W4VVgREQAREQAREQAREQAQqCEgZqGCh IxEQAREQAREQAREQAREoKwJSBsrqdquwIiACIiACIiACIiACIlBBQMpABQsdiYAIiIAIiIAIiIAI iEBZEZAyUFa3W4UVAREQAREQAREQAREQgQoC/werEY5fD3OeXwAAAABJRU5ErkJggg== --000000000000b5007905a13c9b21-- From nobody Thu Mar 19 15:46:22 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B442B3A1181 for ; Thu, 19 Mar 2020 15:46:20 -0700 (PDT) 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 lk2SgWm_6M8o for ; Thu, 19 Mar 2020 15:46:12 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 641303A1179 for ; Thu, 19 Mar 2020 15:45:57 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id ca19so4736674edb.13 for ; Thu, 19 Mar 2020 15:45:57 -0700 (PDT) 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=w+OLoLuAp6U9YEAPZf0vdjIy3//d7BvjswqzTH8boYE=; b=MrnyKn1+KzWEId12uDrVxS5sqvteMxXH5+gihhqAsTw5FvLlOdvlA2aXAvYM6L1hra Y8if7qH6liTgP5+CcyEtrgQBotJ9DvmOKv0asPqyVRLarfvmFgz3aRaNxzzEzD157DlZ I0qy1k9oggRCL/TZraSlWQSdqHm5tHVymB0Vn4dl/JnNuKxMibuh1pZP1cCbcd+9r6d0 /wQbuQr0IOJYFdzYWiSTHx1AHWWItIX8Gr0O/DgBSyADXsC34v6GdJKkJD6HBoJ+omyf 7CFGqwj4HFHiJOoS4/P0YlRC+1cm3vGt7HUhn8GcFTOdIvJh/vn22USZiBE/R4OlS9Mc 1tgA== 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=w+OLoLuAp6U9YEAPZf0vdjIy3//d7BvjswqzTH8boYE=; b=cb+3Dcoz8+gBd+MjtfG/LwYG3sWk5mOpc3VvR19hduuOsqg8/2k4Utcg8Uh3KK31fO aCxLAjqo1YKvAOiqQlKgPx8pDOI77++RUY8aIQsSO8yHkddbtqWkUeX+88nH1toUdrMD hWNbzEy3xWBmGjWNq+Rn6q36mKFe9nKj2D38L8kEHI/If+43Ml7DNX5p3ocEz6Qa8U8J z3eF/MzRfIP76XYB3De2HRsFU+l4T1diaIZmricD2MeCyyaTo4OxX1daaPVtuYb/FI9q dkrDWeSn/eFRNJvVCYYdGUrU81m6ExB+e4yWTpokGCIQCfZt8zniBQzlXLyY9jGoKTwX g4TQ== X-Gm-Message-State: ANhLgQ0xlvrWvSIFbhvDPiakh88Hkl9hWHoBEafmwyVr36SNaxoc0rOO 4InpS0rFxRAc+2kT70A29bCGAaDAVbwm3xnjTXk= X-Google-Smtp-Source: ADFU+vtu0k4lmKPudOTIo/981bscjdRopmI/RtymSGpa2h9QlAJoqok2FdZg3t3OywFhw1LrGEqrI7HCAEqOjxVlG6A= X-Received: by 2002:a17:906:507:: with SMTP id j7mr5584180eja.277.1584657950467; Thu, 19 Mar 2020 15:45:50 -0700 (PDT) MIME-Version: 1.0 References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> In-Reply-To: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> From: David Skaife Date: Thu, 19 Mar 2020 22:45:40 +0000 Message-ID: To: Justin Richer Cc: Aaron Parecki , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003a68ef05a13cee4e" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 22:46:21 -0000 --0000000000003a68ef05a13cee4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Back to the topic of identity, I'm much happier including this subset of identity that you've listed below. My original point is that the current charter wording suggests to me that the *entire *scope of OIDC (and *all *o= f the use cases that OIDC supports today) are in scope to be re-worked as part of this WG - at least that's how I interpret the current charter wording. That seems to be quite different to the view you've presented below, which, as I've said, I'm happier with as it's a much more specific and narrower slice of the broad topic of identity (and the broad scope of OIDC). Many thanks, David Skaife On Thu, Mar 19, 2020 at 1:43 PM Justin Richer wrote: > David, > > I agree about the potential for exploding the scope to derail us. My goal > for identity within TxAuth=E2=80=99s =E2=80=9Ccore=E2=80=9D consists of: > > - A way to ask for a small set of simple, well-defined user claims in th= e > auth request. So things like =E2=80=9Csubject=E2=80=9D and =E2=80=9Cemail= address=E2=80=9D and =E2=80=9Cusername=E2=80=9D, > for instance. This should be extensible by a clear registry. (And no, we > shouldn=E2=80=99t reuse the OIDC one as it=E2=80=99s tied to the assumpti= ons of OIDC too > much already.) > - A way for the AS to send the client signed assertions. I don=E2=80=99t= actually > think we should be defining our own assertion format here in this group, > but we should have slots for things like ID Tokens and SAML assertions an= d > Verifiable Credentials documents. This set should be extensible by a > registry as well. > - A way for the client to present assertions about the user that the AS > can verify, and again we shouldn=E2=80=99t be defining these formats ours= elves, > there are plenty to re-use. > > And =E2=80=A6 that=E2=80=99s pretty much it, at least to get us started. = This is far from > =E2=80=9Call of identity=E2=80=9D. With XYZ, you can already use it out-o= f-the-box to do > these things as well as a handful of other identity bits =E2=80=94 like f= or example > passing the OIDC scopes (as resource handles) and getting back an access > token that you can use to call a UserInfo Endpoint. All of that exists > already though, and it maps cleanly because it=E2=80=99s been defined und= er OAuth 2 > and those concepts map to XYZ. > > =E2=80=94 Justin > > On Mar 18, 2020, at 6:44 PM, David Skaife < > blue.ringed.octopus.guy@gmail.com> wrote: > > Hi, > > As one of the four people who expressed a slight concern about including > identity within the TxAuth charter, I'd like to say that I would definite= ly > be supportive of the proposal to explicitly state which elements of > identity are included - to narrow the scope. I accept that removing > identity completely doesn't seem to have general support amongst the grou= p. > The root cause of my concern is that, by including the full scope of > identity and the full set of use cases that OpenID Connect supports today= , > I envisage that resulting in the WG having such a broad scope that we wou= ld > spend years on end thrashing through it and then no protocol ever actuall= y > getting agreed/standardised. > > > Many thanks, > David Skaife > > On Tue, Mar 17, 2020 at 10:47 PM Justin Richer wrote: > >> +1 >> >> Thanks, Aaron. I think it really is a very narrow slice of identity that >> we want to cover here, and I=E2=80=99d be happy to get more precise lang= uage into >> the proposed charter before moving forward. >> >> =E2=80=94 Justin >> >> > On Mar 17, 2020, at 6:31 PM, Aaron Parecki wrote: >> > >> > Much of the confusion in the marketplace around OAuth and OpenID >> > Connect stems from the fact that they are separate specs developed in >> > separate organizations, when really they are two parts to the same >> > picture. I am strongly against excluding identity from the charter of >> > TxAuth, as I think this is a unique opportunity to bring the two >> > aspects together. >> > >> > The concern expressed by Kim >> > ( >> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE= ) >> > around OpenID Connect could also be said about OAuth, namely that >> > there will be some amount of confusion around the fact that this spec >> > will cover many of the same use cases as OAuth. I think that's fine, >> > that's just how we move forward and make progress. >> > >> > The other concerns seem vague, e.g. "identity is a huge topic". While >> > that may be true, so is authorization, and that alone is not a good >> > reason to not do it. >> > >> > Perhaps the scope of identity included in TxAuth could be narrowed to >> > specify that it's only about communicating identity information, not >> > about doing things like identity proofing or identity assurance. That >> > might help address some of the other concerns that have been >> > expressed. >> > >> > ---- >> > Aaron Parecki >> > aaronparecki.com >> > @aaronpk >> > >> > On Tue, Mar 17, 2020 at 3:06 PM Mike Jones >> > wrote: >> >> >> >> I believe it's significant that four people have expressed concerns >> with including digital identity in the charter (the only concerns voiced= as >> far as I can tell). At a minimum, I believe that that warrants making t= he >> inclusion or exclusion of digital identity a discussion topic during the >> upcoming virtual BoF, before adopting any charter. >> >> >> >> It would be my proposal to initially charter without digital identity >> and see how far we get with our energies intentionally focused in that >> way. If the working group decides to recharter to include digital >> identity, that can always happen later, after the authorization-focused >> work has matured, and once there's a clear case to actually do so. >> >> >> >> -- Mike >> >> >> >> -----Original Message----- >> >> From: Justin Richer >> >> Sent: Tuesday, March 17, 2020 2:20 PM >> >> To: Mike Jones >> >> Cc: Yaron Sheffer ; Torsten Lodderstedt < >> torsten@lodderstedt.net>; txauth@ietf.org >> >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >> >> >> >> While I understand the concerns around identity in the charter, and I >> had initially not included it, I was convinced that the kind of identity >> protocol that we=E2=80=99re looking at here is a minor addition to the >> authorization and delegation end of things. >> >> >> >> As you know, much of what=E2=80=99s in OIDC is there to fix problems = with >> OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those= problems >> internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now >> starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know >> what other problems there might be. >> >> >> >> The market has shown us that the most common application of OAuth 2 i= s >> far and away access to identity information along side access to an API.= I >> think we need to pay attention to that and not make this separate just >> because we did it that way before. And some of the proposed innovations, >> including getting and sending VC=E2=80=99s, are all about identity. >> >> >> >> Furthermore, this charter does not specify the document and >> specification structure of the components, nor does it specify the >> publication order or timing of any documents. I personally think that th= e >> identity layer should be separable to an extent, to the point of publish= ing >> that layer in its own spec alongside the core authorization delegation >> system. However, that does not mean that it should be developed elsewher= e. >> >> >> >> If there is better language to tighten the aspects of an identity >> protocol that we will explicitly cover, then I would welcome you to sugg= est >> an amended text to the charter. However, I believe there is enough inter= est >> within the community to work on identity in the context of this protocol= , >> including a large number of people being OK with it in the charter, that= it >> would not be a reasonable thing to remove it. >> >> >> >> =E2=80=94 Justin >> >> >> >>> On Mar 17, 2020, at 1:12 PM, Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> >>> >> >>> 1. Do you support the charter text provided at the end of this >> email? Or do you have major objections, blocking concerns or feedback (= if >> so please elaborate)? >> >>> >> >>> I share the concerns about including identity in the charter that >> were expressed by Torsten and agreed with by David Skaife. I'll note th= at >> Kim Cameron previously expressed concerns about including identity in hi= s >> earlier charter critique at >> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE= / >> . >> >>> >> >>> I'm fine with refactoring the authorization protocol. But identity >> should be decoupled from the TxAuth work to focus its scope on areas whe= re >> innovation is being proposed. Digital identity can always be added as a >> layer if needed, just as OpenID Connect layered identity onto OAuth 2.0. >> >>> >> >>> Please revise the charter to remove digital identity from the scope >> of the work. >> >>> >> >>> 2. Are you willing to author or participate in the development of >> the drafts of this WG? >> >>> >> >>> Yes >> >>> >> >>> 3. Are you willing to help review the drafts of this WG? >> >>> >> >>> Yes >> >>> >> >>> 4. Are you interested in implementing drafts of this WG? >> >>> >> >>> Not at this time. >> >>> >> >>> -- Mike >> >>> >> >>> -----Original Message----- >> >>> From: Txauth On Behalf Of Torsten >> Lodderstedt >> >>> Sent: Saturday, March 7, 2020 7:18 AM >> >>> To: Yaron Sheffer >> >>> Cc: txauth@ietf.org >> >>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth >> WG >> >>> >> >>> Hi, >> >>> >> >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer > >: >> >>>> >> >>>> =EF=BB=BFHi Everyone, >> >>>> >> >>>> It appears that momentum is forming around the proposed formation o= f >> a TxAuth working group. We=E2=80=99d like to more formally gauge intere= st in >> proceeding with this work. Please do so by responding to the following >> questions: >> >>>> >> >>>> 1. Do you support the charter text provided at the end of this >> email? Or do you have major objections, blocking concerns or feedback (= if >> so please elaborate)? >> >>> >> >>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concern= ed the scope of >> the charter is too broad, e.g. identify alone is a huge topic. >> >>> >> >>> We need to keep an eye on this aspect in order to make sure, the >> group is able to work effectively and the specs we will be producing are= as >> simple as possible and foster interoperability. >> >>> >> >>>> >> >>>> 2. Are you willing to author or participate in the development of >> the drafts of this WG? >> >>> >> >>> yes >> >>> >> >>>> >> >>>> 3. Are you willing to help review the drafts of this WG? >> >>> >> >>> yes >> >>> >> >>>> >> >>>> 4. Are you interested in implementing drafts of this WG? >> >>> >> >>> yes >> >>> >> >>> best regards, >> >>> Torsten. >> >>> >> >>>> >> >>>> The call will run for two weeks, until March 21. If you think that >> the charter should be amended In a significant way, please reply on a >> separate thread. >> >>>> >> >>>> The feedback provided here will help the IESG come to a decision on >> the formation of a new WG. Given the constraints of the chartering proce= ss, >> regardless of the outcome of this consensus call, we will be meeting in >> Vancouver as a BoF. >> >>>> >> >>>> Thanks, >> >>>> Yaron and Dick >> >>>> >> >>>> --- Charter Text Follows --- >> >>>> >> >>>> This group is chartered to develop a fine-grained delegation >> protocol for authorization, identity, and API access. This protocol will >> allow an authorizing party to delegate access to client software through= an >> authorization server. It will expand upon the uses cases currently >> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth >> 2.0) to support authorizations scoped as narrowly as a single transactio= n, >> provide a clear framework for interaction among all parties involved in = the >> protocol flow, and remove unnecessary dependence on a browser or user-ag= ent >> for coordinating interactions. >> >>>> >> >>>> The delegation process will be acted upon by multiple parties in th= e >> protocol, each performing a specific role. The protocol will decouple th= e >> interaction channels, such as the end user=E2=80=99s browser, from the d= elegation >> channel, which happens directly between the client and the authorization >> server (in contrast with OAuth 2.0 which is initiated by the client >> redirecting the user=E2=80=99s browser). The client and AS will involve = a user to >> make an authorization decision as necessary through interaction mechanis= ms >> indicated by the protocol. This decoupling avoids many of the security >> concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve >> path for supporting future types of clients and interaction channels. >> >>>> >> >>>> Additionally, the delegation process will allow for: >> >>>> >> >>>> - Fine-grained specification of access >> >>>> - Approval of AS attestation to identity claims >> >>>> - Approval of access to multiple resources and APIs in a single >> interaction >> >>>> - Separation between the party authorizing access and the party >> operating the client requesting access >> >>>> - A variety of client applications, including Web, mobile, >> single-page, and interaction-constrained applications >> >>>> >> >>>> The group will define extension points for this protocol to allow >> for flexibility in areas including: >> >>>> >> >>>> - Cryptographic agility for keys, message signatures, and proof of >> possession >> >>>> - User interaction mechanisms including web and non-web methods >> >>>> - Mechanisms for conveying user, software, organization, and other >> pieces of information used in authorization decisions >> >>>> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >> >>>> - Optimized inclusion of additional information through the >> delegation process (including identity) >> >>>> >> >>>> Additionally, the group will provide mechanisms for management of >> the protocol lifecycle including: >> >>>> >> >>>> - Discovery of the authorization server >> >>>> - Revocation of active tokens >> >>>> - Query of token rights by resource servers >> >>>> >> >>>> Although the artifacts for this work are not intended or expected t= o >> be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will >> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the n= ew >> protocol where possible. >> >>>> >> >>>> This group is not chartered to develop extensions to OAuth 2.0, and >> as such will focus on new technological solutions not necessarily >> compatible with OAuth 2.0. Functionality that builds directly on OAuth 2= .0 >> will be developed in the OAuth Working Group, including functionality >> back-ported from the protocol developed here to OAuth 2.0. >> >>>> >> >>>> The group is chartered to develop mechanisms for applying >> cryptographic methods, such as JOSE and COSE, to the delegation process. >> This group is not chartered to develop new cryptographic methods. >> >>>> >> >>>> The initial work will focus on using HTTP for communication between >> the client and the authorization server, taking advantage of optimizatio= n >> features of HTTP2 and HTTP3 where possible, and will strive to enable >> simple mapping to other protocols such as COAP when doing so does not >> conflict with the primary focus. >> >>>> >> >>>> Milestones to include: >> >>>> - Core delegation protocol >> >>>> - Key presentation mechanism bindings to the core protocol for TLS, >> detached HTTP signature, and embedded HTTP signatures >> >>>> - Identity and authentication conveyance mechanisms >> >>>> - Guidelines for use of protocol extension points >> >>>> >> >>>> >> >>>> -- >> >>>> Txauth mailing list >> >>>> Txauth@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/txauth >> >>> -- >> >>> Txauth mailing list >> >>> Txauth@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> >> Txauth mailing list >> >> Txauth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --0000000000003a68ef05a13cee4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

Back to the topic= of identity, I'm much happier including this subset of identity that y= ou've listed below. My original point is that the current charter wordi= ng suggests to me that the entire scope of OIDC (and all of t= he use cases that OIDC supports=C2=A0today) are in scope to be re-worked as= part of this WG - at least that's how I interpret the current charter = wording. That seems to be quite different to the view you've presented = below, which, as I've said, I'm happier with as it's a much mor= e specific and narrower slice of the broad topic of identity (and the broad= scope of OIDC).


Many thanks,
David Skaife<= /div>


On Thu, Mar 19, 2020 at 1:43 PM Justin Richer <jricher@mit.edu> wrote:
David,

I agree about the potential for explodi= ng the scope to derail us. My goal for identity within TxAuth=E2=80=99s =E2= =80=9Ccore=E2=80=9D consists of:

=C2=A0- A way to = ask for a small set of simple, well-defined user claims in the auth request= . So things like =E2=80=9Csubject=E2=80=9D and =E2=80=9Cemail address=E2=80= =9D and =E2=80=9Cusername=E2=80=9D, for instance. This should be extensible= by a clear registry. (And no, we shouldn=E2=80=99t reuse the OIDC one as i= t=E2=80=99s tied to the assumptions of OIDC too much already.)
= =C2=A0- A way for the AS to send the client signed assertions. I don=E2=80= =99t actually think we should be defining our own assertion format here in = this group, but we should have slots for things like ID Tokens and SAML ass= ertions and Verifiable Credentials documents. This set should be extensible= by a registry as well.
=C2=A0- A way for the client to present a= ssertions about the user that the AS can verify, and again we shouldn=E2=80= =99t be defining these formats ourselves, there are plenty to re-use.
=

And =E2=80=A6 that=E2=80=99s pretty much it, at least t= o get us started. This is far from =E2=80=9Call of identity=E2=80=9D. With = XYZ, you can already use it out-of-the-box to do these things as well as a = handful of other identity bits =E2=80=94 like for example passing the OIDC = scopes (as resource handles) and getting back an access token that you can = use to call a UserInfo Endpoint. All of that exists already though, and it = maps cleanly because it=E2=80=99s been defined under OAuth 2 and those conc= epts map to XYZ.

=C2=A0=E2=80=94 Justin
On Mar 18, 2020, at 6:44 PM, David Skaife = <= blue.ringed.octopus.guy@gmail.com> wrote:

Hi,

As one of the=C2=A0four people who expressed a = slight concern about including identity within the TxAuth charter, I'd = like to say that I would definitely be supportive of the proposal to explic= itly state which elements of identity are included - to narrow the scope. I= accept that removing identity completely doesn't seem to have general = support amongst the group. The root cause of my concern is that, by includi= ng the full scope of identity and the full set of use cases that OpenID Con= nect supports today, I envisage that resulting in the WG having such a broa= d scope that we would spend years on end thrashing through it and then no p= rotocol ever actually getting agreed/standardised.


Ma= ny thanks,
David Skaife

On Tue, Mar 17, 2020 at 10:47 PM Jus= tin Richer <jricher= @mit.edu> wrote:
+1

Thanks, Aaron. I think it really is a very narrow slice of identity that we= want to cover here, and I=E2=80=99d be happy to get more precise language = into the proposed charter before moving forward.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 6:31 PM, Aaron Parecki <aaron@parecki.com> wrote:
>
> Much of the confusion in the marketplace around OAuth and OpenID
> Connect stems from the fact that they are separate specs developed in<= br> > separate organizations, when really they are two parts to the same
> picture. I am strongly against excluding identity from the charter of<= br> > TxAuth, as I think this is a unique opportunity to bring the two
> aspects together.
>
> The concern expressed by Kim
> (https://mailarchive.ie= tf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)
> around OpenID Connect could also be said about OAuth, namely that
> there will be some amount of confusion around the fact that this spec<= br> > will cover many of the same use cases as OAuth. I think that's fin= e,
> that's just how we move forward and make progress.
>
> The other concerns seem vague, e.g. "identity is a huge topic&quo= t;. While
> that may be true, so is authorization, and that alone is not a good > reason to not do it.
>
> Perhaps the scope of identity included in TxAuth could be narrowed to<= br> > specify that it's only about communicating identity information, n= ot
> about doing things like identity proofing or identity assurance. That<= br> > might help address some of the other concerns that have been
> expressed.
>
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
> On Tue, Mar 17, 2020 at 3:06 PM Mike Jones
> <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> I believe it's significant that four people have expressed con= cerns with including digital identity in the charter (the only concerns voi= ced as far as I can tell).=C2=A0 At a minimum, I believe that that warrants= making the inclusion or exclusion of digital identity a discussion topic d= uring the upcoming virtual BoF, before adopting any charter.
>>
>> It would be my proposal to initially charter without digital ident= ity and see how far we get with our energies intentionally focused in that = way.=C2=A0 If the working group decides to recharter to include digital ide= ntity, that can always happen later, after the authorization-focused work h= as matured, and once there's a clear case to actually do so.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>>
>> -----Original Message-----
>> From: Justin Richer <jricher@mit.edu>
>> Sent: Tuesday, March 17, 2020 2:20 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt= .net>; txauth@i= etf.org
>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
>>
>> While I understand the concerns around identity in the charter, an= d I had initially not included it, I was convinced that the kind of identit= y protocol that we=E2=80=99re looking at here is a minor addition to the au= thorization and delegation end of things.
>>
>> As you know, much of what=E2=80=99s in OIDC is there to fix proble= ms with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and smalle= r. We=E2=80=99re now starting at a base where those problems don=E2=80=99t = exist, but we don=E2=80=99t yet know what other problems there might be. >>
>> The market has shown us that the most common application of OAuth = 2 is far and away access to identity information along side access to an AP= I. I think we need to pay attention to that and not make this separate just= because we did it that way before. And some of the proposed innovations, i= ncluding getting and sending VC=E2=80=99s, are all about identity.
>>
>> Furthermore, this charter does not specify the document and specif= ication structure of the components, nor does it specify the publication or= der or timing of any documents. I personally think that the identity layer = should be separable to an extent, to the point of publishing that layer in = its own spec alongside the core authorization delegation system. However, t= hat does not mean that it should be developed elsewhere.
>>
>> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to suggest= an amended text to the charter. However, I believe there is enough interes= t within the community to work on identity in the context of this protocol,= including a large number of people being OK with it in the charter, that i= t would not be a reasonable thing to remove it.
>>
>> =E2=80=94 Justin
>>
>>> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microso= ft.com@dmarc.ietf.org> wrote:
>>>
>>> 1.=C2=A0 Do you support the charter text provided at the end o= f this email?=C2=A0 Or do you have major objections, blocking concerns or f= eedback (if so please elaborate)?
>>>
>>> I share the concerns about including identity in the charter t= hat were expressed by Torsten and agreed with by David Skaife.=C2=A0 I'= ll note that Kim Cameron previously expressed concerns about including iden= tity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacX= SnshX2CahE/.
>>>
>>> I'm fine with refactoring the authorization protocol.=C2= =A0 But identity should be decoupled from the TxAuth work to focus its scop= e on areas where innovation is being proposed.=C2=A0 Digital identity can a= lways be added as a layer if needed, just as OpenID Connect layered identit= y onto OAuth 2.0.
>>>
>>> Please revise the charter to remove digital identity from the = scope of the work.
>>>
>>> 2.=C2=A0 Are you willing to author or participate in the devel= opment of the drafts of this WG?
>>>
>>> Yes
>>>
>>> 3.=C2=A0 Are you willing to help review the drafts of this WG?=
>>>
>>> Yes
>>>
>>> 4.=C2=A0 Are you interested in implementing drafts of this WG?=
>>>
>>> Not at this time.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike
>>>
>>> -----Original Message-----
>>> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodder= stedt
>>> Sent: Saturday, March 7, 2020 7:18 AM
>>> To: Yaron Sheffer <yaronf.ietf@gmail.com>
>>> Cc: txaut= h@ietf.org
>>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG
>>>
>>> Hi,
>>>
>>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>>>
>>>> =EF=BB=BFHi Everyone,
>>>>
>>>> It appears that momentum is forming around the proposed fo= rmation of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally= gauge interest in proceeding with this work.=C2=A0 Please do so by respond= ing to the following questions:
>>>>
>>>> 1.=C2=A0 Do you support the charter text provided at the e= nd of this email?=C2=A0 Or do you have major objections, blocking concerns = or feedback (if so please elaborate)?
>>>
>>> I=E2=80=98m in although I have to admit I=E2=80=98m slightly c= oncerned the scope of the charter is too broad, e.g. identify alone is a hu= ge topic.
>>>
>>> We need to keep an eye on this aspect in order to make sure, t= he group is able to work effectively and the specs we will be producing are= as simple as possible and foster interoperability.
>>>
>>>>
>>>> 2.=C2=A0 Are you willing to author or participate in the d= evelopment of the drafts of this WG?
>>>
>>> yes
>>>
>>>>
>>>> 3.=C2=A0 Are you willing to help review the drafts of this= WG?
>>>
>>> yes
>>>
>>>>
>>>> 4.=C2=A0 Are you interested in implementing drafts of this= WG?
>>>
>>> yes
>>>
>>> best regards,
>>> Torsten.
>>>
>>>>
>>>> The call will run for two weeks, until March 21. If you th= ink that the charter should be amended In a significant way, please reply o= n a separate thread.
>>>>
>>>> The feedback provided here will help the IESG come to a de= cision on the formation of a new WG. Given the constraints of the charterin= g process, regardless of the outcome of this consensus call, we will be mee= ting in Vancouver as a BoF.
>>>>
>>>> Thanks,
>>>> Yaron and Dick
>>>>
>>>> --- Charter Text Follows ---
>>>>
>>>> This group is chartered to develop a fine-grained delegati= on protocol for authorization, identity, and API access. This protocol will= allow an authorizing party to delegate access to client software through a= n authorization server. It will expand upon the uses cases currently suppor= ted by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to s= upport authorizations scoped as narrowly as a single transaction, provide a= clear framework for interaction among all parties involved in the protocol= flow, and remove unnecessary dependence on a browser or user-agent for coo= rdinating interactions.
>>>>
>>>> The delegation process will be acted upon by multiple part= ies in the protocol, each performing a specific role. The protocol will dec= ouple the interaction channels, such as the end user=E2=80=99s browser, fro= m the delegation channel, which happens directly between the client and the= authorization server (in contrast with OAuth 2.0 which is initiated by the= client redirecting the user=E2=80=99s browser). The client and AS will inv= olve a user to make an authorization decision as necessary through interact= ion mechanisms indicated by the protocol. This decoupling avoids many of th= e security concerns and technical challenges of OAuth 2.0 and provides a no= n-invasive path for supporting future types of clients and interaction chan= nels.
>>>>
>>>> Additionally, the delegation process will allow for:
>>>>
>>>> - Fine-grained specification of access
>>>> - Approval of AS attestation to identity claims
>>>> - Approval of access to multiple resources and APIs in a s= ingle interaction
>>>> - Separation between the party authorizing access and the = party operating the client requesting access
>>>> - A variety of client applications, including Web, mobile,= single-page, and interaction-constrained applications
>>>>
>>>> The group will define extension points for this protocol t= o allow for flexibility in areas including:
>>>>
>>>> - Cryptographic agility for keys, message signatures, and = proof of possession
>>>> - User interaction mechanisms including web and non-web me= thods
>>>> - Mechanisms for conveying user, software, organization, a= nd other pieces of information used in authorization decisions
>>>> - Mechanisms for presenting tokens to resource servers and= binding resource requests to tokens and associated cryptographic keys
>>>> - Optimized inclusion of additional information through th= e delegation process (including identity)
>>>>
>>>> Additionally, the group will provide mechanisms for manage= ment of the protocol lifecycle including:
>>>>
>>>> - Discovery of the authorization server
>>>> - Revocation of active tokens
>>>> - Query of token rights by resource servers
>>>>
>>>> Although the artifacts for this work are not intended or e= xpected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the gr= oup will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to= the new protocol where possible.
>>>>
>>>> This group is not chartered to develop extensions to OAuth= 2.0, and as such will focus on new technological solutions not necessarily= compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0= will be developed in the OAuth Working Group, including functionality back= -ported from the protocol developed here to OAuth 2.0.
>>>>
>>>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. Th= is group is not chartered to develop new cryptographic methods.
>>>>
>>>> The initial work will focus on using HTTP for communicatio= n between the client and the authorization server, taking advantage of opti= mization features of HTTP2 and HTTP3 where possible, and will strive to ena= ble simple mapping to other protocols such as COAP when doing so does not c= onflict with the primary focus.
>>>>
>>>> Milestones to include:
>>>> - Core delegation protocol
>>>> - Key presentation mechanism bindings to the core protocol= for TLS, detached HTTP signature, and embedded HTTP signatures
>>>> - Identity and authentication conveyance mechanisms
>>>> - Guidelines for use of protocol extension points
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txaut= h@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/t= xauth
>>> --
>>> Txauth mailing list
>>> Txauth@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/txa= uth
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--0000000000003a68ef05a13cee4e-- From nobody Thu Mar 19 17:11:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB28A3A12C0 for ; Thu, 19 Mar 2020 17:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=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 4srj4Et78om2 for ; Thu, 19 Mar 2020 17:11:32 -0700 (PDT) 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 3F16F3A12ED for ; Thu, 19 Mar 2020 17:11:26 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id u15so4296079lji.10 for ; Thu, 19 Mar 2020 17:11:26 -0700 (PDT) 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=AkV//3JCWX7r3rXI4HLEZe7s7tW0YD88bz4uE/Vkshg=; b=UUfAeIy9Kx1xESzs/CVV9EWbY6aXRt79v59/JpDVt4q4j6+/VLhn5BTszno2e7r+K/ t/peSb+/w5oPcNmmdNzTkcqej7AvQ1BPVD3mN5yC26LFrE0NMCNy8jAv6fzu4IP8rQnZ svAyYqiBd1uEvoDpzUd8GNzsv85bxkuGD+CysJhG1sD6v7GgH79f+reEf8XoSRVaW6zY /U9NNnwobkbmV/mMOlZCH8gtyXDZSS/VPyKmEtMTPnJgzpAjBUSMu2Z+dyhZxceIsxpT NsP9EAijtYIheLrl6/49MQ9Vya7j8eJI2UqiOkkywLMuPTVi7Q/OoqSbGWyRnQCaaKWl ei7g== 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=AkV//3JCWX7r3rXI4HLEZe7s7tW0YD88bz4uE/Vkshg=; b=e+DtOB7Rc1Orr/BXbx+iwcgxP6/ZlIy2k3IGy127ErSgKlViat2fwitDtQL85+PWot NQOav7kLefIuWFQf1U3NkxINXz9upb6JHeh7dqwaONv+DKDYIoejvp3AUm09yc2Vl66V tE58qC1etr2wwhAue0O1u+qD18tFN0xDEIocO0kfPuKQPemHiD97RuQfZlfHs4RcCFao xl2ABzWPBdAWnEUln0wQDe97A9myVAhV4FJEavVs0KEvvW1Dd1+uS9g7zLeCFDYAStiC J5eDGwAX5JJLmM1cBiUvcEgsECv28VBL2IeRW1hIsQbHHki7ZhAYCySJwDvaJnkEcIC9 MHSw== X-Gm-Message-State: ANhLgQ3UF2nxNXcnLZe3JIrNtFM0UDBKLohholvXHM91/cY1ZoRqiCjz dT8vW6zC5f7fsvCe8NT9YiMwPoVkx1e+XYouk2eq/qrv2SA= X-Google-Smtp-Source: ADFU+vsqR0QDSrvZHM2n6wlQMeyZ1B5hqfekcWIpFhk3s7iyRXjQF+HSfXXXh9NTx73O3n3RGtZIlhJvQxsB5Iz6pL4= X-Received: by 2002:a2e:9d84:: with SMTP id c4mr3729686ljj.51.1584663074816; Thu, 19 Mar 2020 17:11:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 19 Mar 2020 17:10:48 -0700 Message-ID: To: txauth@ietf.org Cc: Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000a9c66905a13e1fca" Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 00:11:39 -0000 --000000000000a9c66905a13e1fca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We are still looking for an EtherPad scribe to take meeting minutes. WebEx will be used for audio and presentation visuals. The WebEx chat feature will be used for queue management. Jabber will be used for back channel chats. EtherPad will be used for the blue sheets, and for meeting minutes. More details here: https://www.ietf.org/how/meetings/107/session-presenter-guide/ =E1=90=A7 On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt wrote: > Virtual Meeting: > > Monday, March 23 > 20:00 - 22:00 UTC * > > *Agenda* > Chair slides, agenda bashing - 10 min. > Charter (link, solicit comments, discuss WG name) - 20 min. > XYZ - Justin (with Q&A) - 20 min. > XAuth - Dick (with Q&A) - 20 min. > Yaron , Dick, Justin - Discussion of differences between protocols - 40 > min. > Next steps - 10 min. > > Additions / suggestions? > > *Tech* > The technology to be used is still TBD. We will update the list when we > know. We are expecting it will be the IETF WebEx. (my preference would be > Zoom if anyone has an account to have LOTS of people on it =3D) > > We are planning on using EtherPad for notes, and for queue management. > > *Scribe* > Would someone like to volunteer to be the scribe on EtherPad? We would > like to get as much coordination done prior as possible to make the best > use of the time. > > /Dick > > * Some time math for 20:00 - 22:00 UTC: > > Pacific Time 13:00-15:00 > Eastern Time 16:00-18:00 > Coordinated Universal Time 20:00-02:00 > Central European Time 21:00-23:00 > India Standard Time 01:30-03:30 > China Standard Time 04:00-06:00 > Australian Eastern Standard Time 07:00-09:00 > =E1=90=A7 > --000000000000a9c66905a13e1fca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are still looking for an EtherPad scribe to take meetin= g minutes.

WebEx will be used for audio and presentation= visuals. The WebEx chat feature will be used for queue management.

Jabber will be used for back channel chats.

EtherPad will be used for the blue sheets, and for meeting= minutes.

More details here:

<= div>https://www.ietf.org/how/meetings/107/session-presenter-guide/
<= /div>

3D""=E1=90=A7

On Mon, Mar 16, 20= 20 at 4:04 PM Dick Hardt <dick.h= ardt@gmail.com> wrote:
Virtual Meeting:=C2=A0

Mo= nday, March 23
20:00 - 22:00 UTC *

Agenda
Chair slides, agenda bashing - 10 min.
Charter (link, solicit= comments, discuss WG name) - 20 min.
XYZ - Justin (with Q&A) - 20 m= in.
XAuth - Dick=C2=A0 (with Q&A) - 20 min.
Yaron , Dick, Justin = - Discussion of differences between protocols - 40 min.
Next steps - 10 = min.

Additions / suggestions?

Tech
The technology to be used is sti= ll TBD. We will update the list when we know. We are expecting it will be t= he IETF WebEx. (my preference would be Zoom if anyone has an account to hav= e LOTS of people on it =3D)

We are planning on usi= ng EtherPad for notes, and for queue management.

<= b>Scribe
Would someone like to volunteer to be the scribe on = EtherPad? We would like to get as much coordination done prior as possible = to make the best use of the time.

/Dick
=
* Some time math for 20:00 - 22:00 UTC:

=
Pacific Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A013:00-15:00
Eastern Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A016:00-18:00
Coordinated Universal Time=C2=A0 =C2=A0 = =C2=A0 =C2=A0 20:00-02:00
Central European Time=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 21:00-23:00
India Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 01:30-03:30
China Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 04:00-06:00
Australian Eastern Standard Time=C2=A0 =C2=A0 =C2=A0= =C2=A007:00-09:00
3D""=E1=90=A7
--000000000000a9c66905a13e1fca-- From nobody Thu Mar 19 17:58:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95033A13AF for ; Thu, 19 Mar 2020 17:58:23 -0700 (PDT) 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 Bc68ZOvY5aGV for ; Thu, 19 Mar 2020 17:58:15 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 E0EBE3A13AC for ; Thu, 19 Mar 2020 17:58:09 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id w1so4668627ljh.5 for ; Thu, 19 Mar 2020 17:58:09 -0700 (PDT) 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=1ZpBvGEfBxBtaCD4IugxFqybC0NSGcAa80YOtpJQ4Bw=; b=tE2Rp13o7A1YGAwsTThosN5GQVTvHbADZ20iHAxH4k27bcPedvoKnmzijvVdgmjc/i y2iVhJk4Pq23VmlOr2aKSmgcw8ym0jkbpGcYdGcGakviSmAKGAZox3AjZm9bZ5feG8g2 c6foRe25/lg1I+PfYbYvpxqawWsCT7DQekrADbIbsbPUDuB7eFXrGZrLaLfyoGQpRcT0 X+3BUfkVWNir3aowI2f4fIOL9uaX4Xv1TJXcSvXbiM/3tAQIu7apRap6XBxXI3KDttRG HFHbjFp3kfxG9/tT7XfcE3/gy3jZRAIKYhbbIAQiA8x8ICj2psn9FeKuQiQG2iwYSb3O C8Tg== 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=1ZpBvGEfBxBtaCD4IugxFqybC0NSGcAa80YOtpJQ4Bw=; b=dHPlhtCKd6Ij7j20wbzW6XF14zBepOZQonzfM9C7Qx5L9rUbC0xP3qVXgRcl2kYzZV 0mbozXGPRTpD2YCl0/DHwnOcifXn6Nem9Rg2Piig1VHin/vptUMqjuRvrXJiubDHq/zs 1EDWcptZtlGe0G0t7H8O+x+mlvkr71eNRBxP4HEG5Vq1ZsQm3XAlgdrYwl1F0Df6fDG1 wIPNbEUMJVwYYySGVzXKWAHLuo7AAa9PEsWxzyJwXBWhtIAjSaWvJORDjf9SW1Vy4OGp cGEEB6cK7O9DFixBZp477jXCJdFE3sgruIgVqxJhAF3rfH8vx+eVdb/sEX/R3JyUmxyB fNcg== X-Gm-Message-State: ANhLgQ3i4tmHD7sypphNoCOPWBh2C7HRUgdO1LbjrrnTZRG/CDgqSSvc GN+vglpr4kC1NTUdCj/ZcPfvzSWniBTn4DN6VZI= X-Google-Smtp-Source: ADFU+vuj+vrKCFdsAOBczd5Yr3Yhku3OZpOxGqHfQnnzF88zWctFpXE43ppyiRqyqIwZPxdNT2/csgJ1ebBWZsNBQn0= X-Received: by 2002:a2e:7811:: with SMTP id t17mr3755271ljc.150.1584665887616; Thu, 19 Mar 2020 17:58:07 -0700 (PDT) MIME-Version: 1.0 References: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> In-Reply-To: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> From: Dick Hardt Date: Thu, 19 Mar 2020 17:57:40 -0700 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , txauth@ietf.org, Torsten Lodderstedt , Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary="00000000000051b61005a13ec797" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 00:58:24 -0000 --00000000000051b61005a13ec797 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rereading the charter I would consider the proposed charter change: - Support for directed, audience-restricted access tokens in multi-RS deployments To be covered by the two highlighted lines below: Additionally, the delegation process will allow for: - Fine-grained specification of access - Approval of AS attestation to identity claims - Approval of access to multiple resources and APIs in a single interaction - Separation between the party authorizing access and the party operating the client requesting access - A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications Torsten: Does the scope of fine-grained access combined with approval of ac= cess to multiple resources cover your requirements? Note that we are not stating how we do it, just what is in scope. /Dick On Thu, Mar 19, 2020 at 1:48 PM Justin Richer wrote: > On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt > wrote: > > > >> Am 19.03.2020 um 21:07 schrieb Justin Richer : > >> > >> =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99v= e described, > > > > Given our recent discussion, I don=E2=80=99t see how it is already in s= cope > > What I mean is that a client can already ask for separate tokens and use > the =E2=80=9Cresources=E2=80=9D block to describe which resource servers = it wants. However, > right now, it=E2=80=99s up to the client to determine what the split is = =E2=80=94 either by > asking for separate tokens in either the single-token format (with multip= le > requests) or multi-token format (with a single request). > > > > >> with the caveat that identifying "the RS" is really, really hard to do= . > > > > I don=E2=80=99t think it=E2=80=99s difficult to use URLs to identify at= least > =E2=80=9Edestinations=E2=80=9C, it works for cookies as well. > > I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99m tr= ying to push back > against optimizing for that one kind of identity. And cookies have all > kinds of rules for paths and domains and origins that protect them, so if > that=E2=80=99s the model we=E2=80=99re arguing for we need to at least co= nsider all of > that. We also need to consider that cookies fail in a lot of ways! :) > > > > >> What if instead it=E2=80=99s: > >> > >> - Support for directed, audience-restricted access tokens in multi-RS > deployments > >> > >> Would that work? To me the difference is that it=E2=80=99s getting awa= y from a > fixed notion of what an =E2=80=9CRS=E2=80=9D is and more towards the noti= on of getting a > token directed to a specific set of actions and/or locations. > > > > wfm, as long it is clear the AS/RS determines the boundaries. > > Ultimately they always do, and they=E2=80=99ll always need to deal with t= he > situation where a client asks for rights that cross boundaries. The > question is what to do in those situations, and I think there=E2=80=99s a= lot more > discussion we need to have on that front! Do we allow the AS to split a > token request, do we have errors for this, do we have a client indicate > that it can receive split tokens =E2=80=A6 etc. I think it=E2=80=99s an i= nteresting area, > but complex and not nearly as clean-cut as your own use case and deployme= nt > might let it be. > > =E2=80=94 Justin > > > > > best regards, > > Torsten. > > > >> > >> =E2=80=94 Justin > >> > >>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt 40lodderstedt.net@dmarc.ietf.org> wrote: > >>> > >>> Hi all, > >>> > >>> I suggest to add the following requirement to the charter: > >>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS deploym= ents > >>> > >>> I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I w= ant to > make sure we try to build a protocol that serves the needs of a broad set > of deployments. My concern is otherwise TXAuth will be not innovative > enough to gain traction in the market rapidly. Speaking for myself, I > realised in the last couple of days, mostly in conversations with Justin, > that the result of this working group as envisioned now is not of > particular interest to us (yes.com) because it does not solve our real > problems. > >>> > >>> And here is my explanation: > >>> > >>> OAuth traditionally has the philosophy of a single access token. > That=E2=80=99s fine for single service deployments, but it had reached it= s limits > already before RFC6749 was published. There are a real implementations ou= t > there forcing clients to use different access tokens for different > services, typically for privacy and security reasons. There is also an > =E2=80=9Cancient" technology called Kerberos that uses exactly this patte= rn and is > well known for security, performance, and scalability. > >>> > >>> And there are even more examples today for multi API environments tha= t > would benefit from that feature: > >>> =E2=80=A2 Open banking: most banks I worked with have multiple APIs= , > segregation between APIs is today achieved by maintaining different grant= s, > basically resulting in the fact that the users cannot consent to differen= t > services at once. What a terrible UX! > >>> =E2=80=A2 Everyone is doing micro services today. Have you every th= ought > about the coupling caused by a single token across micro services? This > reminds me of how easy it is to test services independently using > self-contained RS-specific tokens. > >>> =E2=80=A2 IoT - every device in a household is a potential RS (in m= y > opinion). Conveying all necessary data in an access token needed to meet > access control decisions locally would be a huge benefit in terms of > performance and decoupling. Using symmetric cryptography for token > integrity, authenticity and confidentiality would result in lower compute > requirements. > >>> > >>> Since we are preparing to define a completely new protocol for API > access authorization and delegation, I think this new protocol should > support this kind of scenarios. It will require significant work to get i= t > right and simple, but if we just stick to the =E2=80=9Ca single access to= ken is > enough=E2=80=9D mantra, we miss the chance to give implementers a broader= range of > design choices out of the box and we won=E2=80=99t success in achieving t= rue > interoperability. > >>> > >>> Here are more advantages we can gain by supporting such a feature: > >>> =E2=80=A2 Privacy: > >>> =E2=80=A2 A single access token can be used to track user acros= s > services. > >>> =E2=80=A2 RS-specific access tokens cannot. > >>> =E2=80=A2 RS-specific access tokens can also be encrypted to pr= otect > data confidentiality in transit. > >>> =E2=80=A2 Security: RS-specific access tokens have a baseline repla= y > detection. > >>> =E2=80=A2 Performance: RS-specific access tokens allow the AS to co= nvey all > data required to authorize an API call in a token (e.g. a JWT) and to RS = to > meet the access control decision based on that data. This is a huge > advantage in terms of performance, scalability and cost since there is no > need for Token Introspection or other kinds of access to another services > or database. > >>> > >>> What do you think? > >>> > >>> best regards, > >>> Torsten. > >>> > >>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >>>> > >>>> > >>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: > >>>>> On 19. Mar 2020, at 17:47, Justin Richer wrote: > >>>>>> Well, it=E2=80=99s in scope as much as describing any other aspect= of what > the token is for and what it represents is in scope. That is alongside > things like the intended audience of the token, the access rights for the > token, the presentation keys the token is bound to, etc. It could be > information in the token text itself (like a JWT), it could be introspect= ed > from the AS, it could be referenced in some other way. So if we can defin= e > identity aspects in that, then we=E2=80=99re fine in covering it there. > >>>>>> > >>>>>> But here=E2=80=99s the thing: none of that has an impact on the co= re > protocol. That is entirely up to the AS and the RS to agree on, and the > client never sees or has any influence on it. That portion of the protoco= l > is completely opaque to the client. Therefore, it doesn=E2=80=99t really = affect the > authorization and delegation portions of the client talking to the AS and > the client talking to the RS. > >>>>>> > >>>>>> This does raise the question of what our bar of interoperability i= s > going to be with TxAuth: do we expect independent AS and RS implementatio= ns > to talk to each other? That=E2=80=99s not something OAuth 2 was ever conc= erned > with, though obviously JWT and introspection are both from the OAuth2 WG > and solve that problem. > >>>>> There are two aspects to it: interoperability and vendor support. > >>>>> > >>>>> Interoperability between AS and RS is important if deployments want > to combine pre-packaged TXAuth and API implementations. I think that make= s > a lot of sense and should be included in the charter. > >>>> > >>>> +1 > >>>> > >>>> The current OAuth 2.0 status quo of the largely unspecified > relationship > >>>> between AS and RS is also making the life of web & sec framework > >>>> maintainers difficult. We witnessing this with people integrating th= e > >>>> OAuth SDK into frameworks. Vittorio's recent work to put together a > >>>> minimal interoperable JWT profile for access tokens is helpful, but = it > >>>> has come after the fact. And there is not agreement on things like > >>>> authorising access to claims. > >>>> > >>>> Integrating apps (RSs) with TxAuth should be straightforward and > simple. > >>>> > >>>> This can have a enormous effect on adoption. > >>>> > >>>> > >>>>> Vendors support: vendor support when it comes to "what can go into > an access token" and "what can be conveyed in a token introspection > response=E2=80=9D greatly deviates in my observation. This also means > implementation use vendors specific features restricting their ability to > use other solutions. TXAuth should aim at improving the situation. > >>>> > >>>> +1 > >>>> > >>>> > >>>>> I also think it is a good exercise for the group to think the whole > process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not = to provide > clients with access tokens. The purpose is to enable API request processi= ng > in a secure manner. What it really takes to achieve that goal is not > obvious if the work always stops at the =E2=80=9Cyou have your access tok= en, good > luck=E2=80=9D stage. > >>>> > >>>> +1 > >>>> > >>>> Vladimir > >>>> > >>>> > >>>> -- > >>>> Txauth mailing list > >>>> Txauth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/txauth > >>> > >>> -- > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth > >> > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000051b61005a13ec797 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rereading the charter I would=C2=A0consider the proposed c= harter change:

=C2=A0- Support for directed, audience-restricted ac= cess tokens in multi-RS deployments

<= div>To be covered by the two highlighted lines below:

Addi= tionally, the delegation process will allow for:

<= /div>
- Fine= -grained specification of access
- Approval of = AS attestation to identity claims
- Approval of access to multiple resources and = APIs in a single interaction
- Separation betwe= en the party authorizing access and the party operating the client requesti= ng access
- A variety of client applications, includin= g Web, mobile, single-page, and interaction-constrained applications
<= /div>

Torsten: Does the scope of fine-grained access combined w= ith approval of access to m= ultiple=C2=A0resources cover your requirements?

Note that we are not stating how we do it, just what is in= scope.

/Dick

On Thu, Mar 19, 2020 at 1:48 PM= Justin Richer <jricher@mit.edu&g= t; wrote:
On Mar= 19, 2020, at 4:41 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>
>> Am 19.03.2020 um 21:07 schrieb Justin Richer <jricher@mit.edu>:
>>
>> =EF=BB=BFI think this is already in scope in the ways that I=E2=80= =99ve described,
>
> Given our recent discussion, I don=E2=80=99t see how it is already in = scope

What I mean is that a client can already ask for separate tokens and use th= e =E2=80=9Cresources=E2=80=9D block to describe which resource servers it w= ants. However, right now, it=E2=80=99s up to the client to determine what t= he split is =E2=80=94 either by asking for separate tokens in either the si= ngle-token format (with multiple requests) or multi-token format (with a si= ngle request).

>
>> with the caveat that identifying "the RS" is really, rea= lly hard to do.
>
> I don=E2=80=99t think it=E2=80=99s difficult to use URLs to identify a= t least =E2=80=9Edestinations=E2=80=9C, it works for cookies as well.

I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99m tryi= ng to push back against optimizing for that one kind of identity. And cooki= es have all kinds of rules for paths and domains and origins that protect t= hem, so if that=E2=80=99s the model we=E2=80=99re arguing for we need to at= least consider all of that. We also need to consider that cookies fail in = a lot of ways! :)

>
>> What if instead it=E2=80=99s:
>>
>> - Support for directed, audience-restricted access tokens in multi= -RS deployments
>>
>> Would that work? To me the difference is that it=E2=80=99s getting= away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more towar= ds the notion of getting a token directed to a specific set of actions and/= or locations.
>
> wfm, as long it is clear the AS/RS determines the boundaries.

Ultimately they always do, and they=E2=80=99ll always need to deal with the= situation where a client asks for rights that cross boundaries. The questi= on is what to do in those situations, and I think there=E2=80=99s a lot mor= e discussion we need to have on that front! Do we allow the AS to split a t= oken request, do we have errors for this, do we have a client indicate that= it can receive split tokens =E2=80=A6 etc. I think it=E2=80=99s an interes= ting area, but complex and not nearly as clean-cut as your own use case and= deployment might let it be.

=C2=A0=E2=80=94 Justin

>
> best regards,
> Torsten.
>
>>
>> =E2=80=94 Justin
>>
>>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt <torsten= =3D40= lodderstedt.net@dmarc.ietf.org> wrote:
>>>
>>> Hi all,
>>>
>>> I suggest to add the following requirement to the charter:
>>>=C2=A0 =C2=A0=E2=80=A2 Support for RS-specific access tokens in= Multi-RS deployments
>>>
>>> I don=E2=80=99t mind HOW this requirement is supported in TXAu= th. I want to make sure we try to build a protocol that serves the needs of= a broad set of deployments. My concern is otherwise TXAuth will be not inn= ovative enough to gain traction in the market rapidly. Speaking for myself,= I realised in the last couple of days, mostly in conversations with Justin= , that the result of this working group as envisioned now is not of particu= lar interest to us (yes.com) because it does not solve our real problems.
>>>
>>> And here is my explanation:
>>>
>>> OAuth traditionally has the philosophy of a single access toke= n. That=E2=80=99s fine for single service deployments, but it had reached i= ts limits already before RFC6749 was published. There are a real implementa= tions out there forcing clients to use different access tokens for differen= t services, typically for privacy and security reasons. There is also an = =E2=80=9Cancient" technology called Kerberos that uses exactly this pa= ttern and is well known for security, performance, and scalability.
>>>
>>> And there are even more examples today for multi API environme= nts that would benefit from that feature:
>>>=C2=A0 =C2=A0=E2=80=A2 Open banking: most banks I worked with h= ave multiple APIs, segregation between APIs is today achieved by maintainin= g different grants, basically resulting in the fact that the users cannot c= onsent to different services at once. What a terrible UX!
>>>=C2=A0 =C2=A0=E2=80=A2 Everyone is doing micro services today. = Have you every thought about the coupling caused by a single token across m= icro services? This reminds me of how easy it is to test services independe= ntly using self-contained RS-specific tokens.
>>>=C2=A0 =C2=A0=E2=80=A2 IoT - every device in a household is a p= otential RS (in my opinion). Conveying all necessary data in an access toke= n needed to meet access control decisions locally would be a huge benefit i= n terms of performance and decoupling. Using symmetric cryptography for tok= en integrity, authenticity and confidentiality would result in lower comput= e requirements.
>>>
>>> Since we are preparing to define a completely new protocol for= API access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get it = right and simple, but if we just stick to the =E2=80=9Ca single access toke= n is enough=E2=80=9D mantra, we miss the chance to give implementers a broa= der range of design choices out of the box and we won=E2=80=99t success in = achieving true interoperability.
>>>
>>> Here are more advantages we can gain by supporting such a feat= ure:
>>>=C2=A0 =C2=A0=E2=80=A2 Privacy:
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 A single access token can = be used to track user across services.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RS-specific access tokens = cannot.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RS-specific access tokens = can also be encrypted to protect data confidentiality in transit.
>>>=C2=A0 =C2=A0=E2=80=A2 Security: RS-specific access tokens have= a baseline replay detection.
>>>=C2=A0 =C2=A0=E2=80=A2 Performance: RS-specific access tokens a= llow the AS to convey all data required to authorize an API call in a token= (e.g. a JWT) and to RS to meet the access control decision based on that d= ata. This is a huge advantage in terms of performance, scalability and cost= since there is no need for Token Introspection or other kinds of access to= another services or database.
>>>
>>> What do you think?
>>>
>>> best regards,
>>> Torsten.
>>>
>>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov <vladimir@connect2i= d.com> wrote:
>>>>
>>>>
>>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote:
>>>>> On 19. Mar 2020, at 17:47, Justin Richer <jricher@mit.edu> wrote= :
>>>>>> Well, it=E2=80=99s in scope as much as describing = any other aspect of what the token is for and what it represents is in scop= e. That is alongside things like the intended audience of the token, the ac= cess rights for the token, the presentation keys the token is bound to, etc= . It could be information in the token text itself (like a JWT), it could b= e introspected from the AS, it could be referenced in some other way. So if= we can define identity aspects in that, then we=E2=80=99re fine in coverin= g it there.
>>>>>>
>>>>>> But here=E2=80=99s the thing: none of that has an = impact on the core protocol. That is entirely up to the AS and the RS to ag= ree on, and the client never sees or has any influence on it. That portion = of the protocol is completely opaque to the client. Therefore, it doesn=E2= =80=99t really affect the authorization and delegation portions of the clie= nt talking to the AS and the client talking to the RS.
>>>>>>
>>>>>> This does raise the question of what our bar of in= teroperability is going to be with TxAuth: do we expect independent AS and = RS implementations to talk to each other? That=E2=80=99s not something OAut= h 2 was ever concerned with, though obviously JWT and introspection are bot= h from the OAuth2 WG and solve that problem.
>>>>> There are two aspects to it: interoperability and vend= or support.
>>>>>
>>>>> Interoperability between AS and RS is important if dep= loyments want to combine pre-packaged TXAuth and API implementations. I thi= nk that makes a lot of sense and should be included in the charter.
>>>>
>>>> +1
>>>>
>>>> The current OAuth 2.0 status quo of the largely unspecifie= d relationship
>>>> between AS and RS is also making the life of web & sec= framework
>>>> maintainers difficult. We witnessing this with people inte= grating the
>>>> OAuth SDK into frameworks. Vittorio's recent work to p= ut together a
>>>> minimal interoperable JWT profile for access tokens is hel= pful, but it
>>>> has come after the fact. And there is not agreement on thi= ngs like
>>>> authorising access to claims.
>>>>
>>>> Integrating apps (RSs) with TxAuth should be straightforwa= rd and simple.
>>>>
>>>> This can have a enormous effect on adoption.
>>>>
>>>>
>>>>> Vendors support: vendor support when it comes to "= ;what can go into an access token" and "what can be conveyed in a= token introspection response=E2=80=9D greatly deviates in my observation. = This also means implementation use vendors specific features restricting th= eir ability to use other solutions. TXAuth should aim at improving the situ= ation.=C2=A0
>>>>
>>>> +1
>>>>
>>>>
>>>>> I also think it is a good exercise for the group to th= ink the whole process "from the end=E2=80=9D. The purpose of TXAuth (a= nd OAuth) is not to provide clients with access tokens. The purpose is to e= nable API request processing in a secure manner. What it really takes to ac= hieve that goal is not obvious if the work always stops at the =E2=80=9Cyou= have your access token, good luck=E2=80=9D stage.
>>>>
>>>> +1
>>>>
>>>> Vladimir
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txaut= h@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/t= xauth
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/txa= uth
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000051b61005a13ec797-- From nobody Thu Mar 19 23:20:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DE53A160E for ; Thu, 19 Mar 2020 23:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=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 agtxQruujhZx for ; Thu, 19 Mar 2020 23:20:20 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 1BDA33A151C for ; Thu, 19 Mar 2020 23:20:13 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id h9so6008865wrc.8 for ; Thu, 19 Mar 2020 23:20:13 -0700 (PDT) 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=hwMeXoItugJF6wAqcwreoeBBxiWcuEumIi9doSfN67s=; b=RbVHSQnXuFP5vdwiGiB+ReHfqY9sMSjqF0uvjdr1PtncGB5yaG4T87lP/v9lcpr7gL T9v+pNPxOKJ2DC+gyaPPGWV+gudph/XCM9kRkucKGa1zkcHwBYESDTKe36vGDXaw6hYe kq+jmzEG7qUuvCEmzMj6wmiNz9ZA7wiCLUqWKyQae3ifyu4d4AsKx2f0k6bytg1R08mZ 3gSusPv6iWiGcqjcpDBLbAhHHW8FD/e/7TddKJG05Mk014YtWM91a0DOrClJscDDt5eZ jJbkFCJQ6XknQ7FuV/5ni5DyM7XnrV4FDxvBpaXQ3QWpzAIviJR7UM2gXOlE9RVrjBKU dIRQ== 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=hwMeXoItugJF6wAqcwreoeBBxiWcuEumIi9doSfN67s=; b=D5Mlmwn0dXXBgA9gRVNq9TPphwr1xdHU/VrjfCv2uwgtS55uBna3UB6J6jLQW+P9RD mGfJROlA2Ih4vpv7vmEQ+Z4si0X8u+/0y6H9LAqZqCx7swHrrxRthn0qeKUzRTIHmwHT cudYj6yIx4cgeaUEGoivcs43uVynG3RMm2vIDguJkmgjw/ccsklGaqEbovtMiVLLWugw unuYliSu8zzDmYy5tFKbLh4nfXseW0l/L/+WBz0vY0UmynGEKmU4oeUzO30VYNlBB3RE KxCgVVs0dNAKCPq1WpPiOH1Dt1s4l1kNbFDI2JhFJGYg5FtM8YB15ESkaj5JQ+UQLv2h WUfw== X-Gm-Message-State: ANhLgQ2fKYLiBMTxxAms6I/bzONinB/Hm5v37gLbjQf4tpboFMrPZRxN z0xeN2rVJ6nVtMKvL1sF5ryv6UCZ+2TWO8kAtAo= X-Google-Smtp-Source: ADFU+vuqMXImwEhPP5lw1BGsXsd5hwxAu3neEbHqKZPt7L6cTStCAi96Gdj16KmYibF4wg+7xbghJAaG1SSlelvlQ64= X-Received: by 2002:a5d:4c87:: with SMTP id z7mr9358773wrs.39.1584685210806; Thu, 19 Mar 2020 23:20:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Fri, 20 Mar 2020 15:19:56 +0900 Message-ID: To: Mike Jones Cc: Justin Richer , Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000123fe105a143477c" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 06:20:34 -0000 --000000000000123fe105a143477c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I thought I should keep my mouth shut as anything I say may be deemed biased as my other hat is the chairman of OIDF, but here is my 2c. As Torsten indicated, there is much to be desired to standardize the AS - RS communication patterns. You may say that the charter includes it, but I cannot read it out of the charter just like Torsten could not. As a new protocol, it would be good to include it. In this respect, I am not sure if we should start off from OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel that we should architect is more fully. Not mentioning AS - RS relationship to me feels like an indication of this failure. For that matter, I feel that the first output of the group should be an architecture document that takes the concerns from all the relevant stakeholders/actors in. We should also be cognizant of the access control models like ABAC. For that, decoupling of identity (=3D set of claims) assertion and authorizatio= n is a necessity. We could optimize it but the base case should take care of it. (In this respect, I am feeling that OIDC has perhaps over-optimized.) So, I feel that at least as the first step, TxAuth should concentre on the Access Control. If I were to go one step further, it should be modelled so that it can consume various identity assertions (authenticated identity in ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates (such as in eIDAS and Japanese National ID scheme) etc. We are not going to get to a unified identity world anytime soon. Cheers, Nat Sakimura On Wed, Mar 18, 2020 at 7:06 AM Mike Jones wrote: > I believe it's significant that four people have expressed concerns with > including digital identity in the charter (the only concerns voiced as fa= r > as I can tell). At a minimum, I believe that that warrants making the > inclusion or exclusion of digital identity a discussion topic during the > upcoming virtual BoF, before adopting any charter. > > It would be my proposal to initially charter without digital identity and > see how far we get with our energies intentionally focused in that way. = If > the working group decides to recharter to include digital identity, that > can always happen later, after the authorization-focused work has matured= , > and once there's a clear case to actually do so. > > -- Mike > > -----Original Message----- > From: Justin Richer > Sent: Tuesday, March 17, 2020 2:20 PM > To: Mike Jones > Cc: Yaron Sheffer ; Torsten Lodderstedt < > torsten@lodderstedt.net>; txauth@ietf.org > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > > While I understand the concerns around identity in the charter, and I had > initially not included it, I was convinced that the kind of identity > protocol that we=E2=80=99re looking at here is a minor addition to the > authorization and delegation end of things. > > As you know, much of what=E2=80=99s in OIDC is there to fix problems with= OAuth 2 > when it=E2=80=99s used for identity. If OAuth 2 had solved those problems > internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now > starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know > what other problems there might be. > > The market has shown us that the most common application of OAuth 2 is fa= r > and away access to identity information along side access to an API. I > think we need to pay attention to that and not make this separate just > because we did it that way before. And some of the proposed innovations, > including getting and sending VC=E2=80=99s, are all about identity. > > Furthermore, this charter does not specify the document and specification > structure of the components, nor does it specify the publication order or > timing of any documents. I personally think that the identity layer shoul= d > be separable to an extent, to the point of publishing that layer in its o= wn > spec alongside the core authorization delegation system. However, that do= es > not mean that it should be developed elsewhere. > > If there is better language to tighten the aspects of an identity protoco= l > that we will explicitly cover, then I would welcome you to suggest an > amended text to the charter. However, I believe there is enough interest > within the community to work on identity in the context of this protocol, > including a large number of people being OK with it in the charter, that = it > would not be a reasonable thing to remove it. > > =E2=80=94 Justin > > > On Mar 17, 2020, at 1:12 PM, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > > > 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > > > I share the concerns about including identity in the charter that were > expressed by Torsten and agreed with by David Skaife. I'll note that Kim > Cameron previously expressed concerns about including identity in his > earlier charter critique at > https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/= . > > > > I'm fine with refactoring the authorization protocol. But identity > should be decoupled from the TxAuth work to focus its scope on areas wher= e > innovation is being proposed. Digital identity can always be added as a > layer if needed, just as OpenID Connect layered identity onto OAuth 2.0. > > > > Please revise the charter to remove digital identity from the scope of > the work. > > > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > > > Yes > > > > 3. Are you willing to help review the drafts of this WG? > > > > Yes > > > > 4. Are you interested in implementing drafts of this WG? > > > > Not at this time. > > > > -- Mike > > > > -----Original Message----- > > From: Txauth On Behalf Of Torsten Lodderstedt > > Sent: Saturday, March 7, 2020 7:18 AM > > To: Yaron Sheffer > > Cc: txauth@ietf.org > > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG > > > > Hi, > > > >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : > >> > >> =EF=BB=BFHi Everyone, > >> > >> It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > >> > >> 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > > > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned = the scope of the > charter is too broad, e.g. identify alone is a huge topic. > > > > We need to keep an eye on this aspect in order to make sure, the group > is able to work effectively and the specs we will be producing are as > simple as possible and foster interoperability. > > > >> > >> 2. Are you willing to author or participate in the development of the > drafts of this WG? > > > > yes > > > >> > >> 3. Are you willing to help review the drafts of this WG? > > > > yes > > > >> > >> 4. Are you interested in implementing drafts of this WG? > > > > yes > > > > best regards, > > Torsten. > > > >> > >> The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > >> > >> The feedback provided here will help the IESG come to a decision on th= e > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > >> > >> Thanks, > >> Yaron and Dick > >> > >> --- Charter Text Follows --- > >> > >> This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > >> > >> The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > >> > >> Additionally, the delegation process will allow for: > >> > >> - Fine-grained specification of access > >> - Approval of AS attestation to identity claims > >> - Approval of access to multiple resources and APIs in a single > interaction > >> - Separation between the party authorizing access and the party > operating the client requesting access > >> - A variety of client applications, including Web, mobile, single-page= , > and interaction-constrained applications > >> > >> The group will define extension points for this protocol to allow for > flexibility in areas including: > >> > >> - Cryptographic agility for keys, message signatures, and proof of > possession > >> - User interaction mechanisms including web and non-web methods > >> - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > >> - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > >> - Optimized inclusion of additional information through the delegation > process (including identity) > >> > >> Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > >> > >> - Discovery of the authorization server > >> - Revocation of active tokens > >> - Query of token rights by resource servers > >> > >> Although the artifacts for this work are not intended or expected to b= e > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > >> > >> This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > >> > >> The group is chartered to develop mechanisms for applying cryptographi= c > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > >> > >> The initial work will focus on using HTTP for communication between th= e > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > >> > >> Milestones to include: > >> - Core delegation protocol > >> - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > >> - Identity and authentication conveyance mechanisms > >> - Guidelines for use of protocol extension points > >> > >> > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --000000000000123fe105a143477c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought I should keep my mouth=C2=A0shut as anything I s= ay may be deemed biased as my other hat is the chairman of OIDF, but here i= s my 2c.=C2=A0

As Torsten indicated, there is much to be= desired to standardize the AS - RS communication patterns. You may say tha= t the charter includes it, but I cannot read it out of the charter just lik= e Torsten could not. As a new protocol, it would be good to include it.=C2= =A0

In this respect, I am not sure if we should st= art off from OAuth 2.0 and OIDC model. If we are creating a new protocol, I= feel that we should architect is more fully. Not mentioning AS - RS relati= onship to me feels like an indication of this failure. For that matter, I f= eel that the first output of the group should be an architecture document t= hat takes the concerns from all the relevant stakeholders/actors in.=C2=A0<= /div>

We should also be cognizant of the access=C2=A0con= trol models like ABAC. For that, decoupling of identity (=3D set of claims)= assertion and authorization is a necessity. We could optimize it but the b= ase case should take care of it. (In this respect, I am feeling that OIDC h= as perhaps over-optimized.) So, I feel that at least as the first step, TxA= uth should concentre on the Access Control. If I were to go one step furthe= r, it should be modelled so that it can consume various identity assertions= (authenticated identity in ISO/IEC 24760 speak) including ID Token, SAML A= ssertion, DID Verifiable Credentials, X.509 certificates (such as in eIDAS = and Japanese National ID scheme)=C2=A0 etc. We are not going to get to a un= ified identity world anytime soon.=C2=A0

Cheers,= =C2=A0

Nat Sakimura


=
On Wed, Ma= r 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
I believe it'= s significant that four people have expressed concerns with including digit= al identity in the charter (the only concerns voiced as far as I can tell).= =C2=A0 At a minimum, I believe that that warrants making the inclusion or e= xclusion of digital identity a discussion topic during the upcoming virtual= BoF, before adopting any charter.

It would be my proposal to initially charter without digital identity and s= ee how far we get with our energies intentionally focused in that way.=C2= =A0 If the working group decides to recharter to include digital identity, = that can always happen later, after the authorization-focused work has matu= red, and once there's a clear case to actually do so.

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

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net&= gt;; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had i= nitially not included it, I was convinced that the kind of identity protoco= l that we=E2=80=99re looking at here is a minor addition to the authorizati= on and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems with O= Auth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now starting at a base where those problems don=E2=80=99t exist, b= ut we don=E2=80=99t yet know what other problems there might be.

The market has shown us that the most common application of OAuth 2 is far = and away access to identity information along side access to an API. I thin= k we need to pay attention to that and not make this separate just because = we did it that way before. And some of the proposed innovations, including = getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and specification s= tructure of the components, nor does it specify the publication order or ti= ming of any documents. I personally think that the identity layer should be= separable to an extent, to the point of publishing that layer in its own s= pec alongside the core authorization delegation system. However, that does = not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol = that we will explicitly cover, then I would welcome you to suggest an amend= ed text to the charter. However, I believe there is enough interest within = the community to work on identity in the context of this protocol, includin= g a large number of people being OK with it in the charter, that it would n= ot be a reasonable thing to remove it.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
>
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?
>
> I share the concerns about including identity in the charter that were= expressed by Torsten and agreed with by David Skaife.=C2=A0 I'll note = that Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Ca= hE/.
>
> I'm fine with refactoring the authorization protocol.=C2=A0 But id= entity should be decoupled from the TxAuth work to focus its scope on areas= where innovation is being proposed.=C2=A0 Digital identity can always be a= dded as a layer if needed, just as OpenID Connect layered identity onto OAu= th 2.0.
>
> Please revise the charter to remove digital identity from the scope of= the work.
>
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?
>
> Yes
>
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.o= rg
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>: >>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed formation = of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in proceeding with this work.=C2=A0 Please do so by responding to t= he following questions:
>>
>> 1.=C2=A0 Do you support the charter text provided at the end of th= is email?=C2=A0 Or do you have major objections, blocking concerns or feedb= ack (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the charter is too broad, e.g. identify alone is a huge topic= .
>
> We need to keep an eye on this aspect in order to make sure, the group= is able to work effectively and the specs we will be producing are as simp= le as possible and foster interoperability.
>
>>
>> 2.=C2=A0 Are you willing to author or participate in the developme= nt of the drafts of this WG?
>
> yes
>
>>
>> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> yes
>
>>
>> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think that= the charter should be amended In a significant way, please reply on a sepa= rate thread.
>>
>> The feedback provided here will help the IESG come to a decision o= n the formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation proto= col for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an author= ization server. It will expand upon the uses cases currently supported by O= Auth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support a= uthorizations scoped as narrowly as a single transaction, provide a clear f= ramework for interaction among all parties involved in the protocol flow, a= nd remove unnecessary dependence on a browser or user-agent for coordinatin= g interactions.
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the de= legation channel, which happens directly between the client and the authori= zation server (in contrast with OAuth 2.0 which is initiated by the client = redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mech= anisms indicated by the protocol. This decoupling avoids many of the securi= ty concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve path for supporting future types of clients and interaction channels. >>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single in= teraction
>> - Separation between the party authorizing access and the party op= erating the client requesting access
>> - A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof of= possession
>> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other= pieces of information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding= resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the delega= tion process (including identity)
>>
>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new= protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported = from the protocol developed here to OAuth 2.0.
>>
>> The group is chartered to develop mechanisms for applying cryptogr= aphic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication betwee= n the client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable simp= le mapping to other protocols such as COAP when doing so does not conflict = with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for TLS= , detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--000000000000123fe105a143477c-- From nobody Fri Mar 20 00:48:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950163A167A for ; Fri, 20 Mar 2020 00:48:14 -0700 (PDT) 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 AAiB7_zrCVu8 for ; Fri, 20 Mar 2020 00:48:05 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 0A5523A1101 for ; Fri, 20 Mar 2020 00:47:54 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id m25so3423240vsa.7 for ; Fri, 20 Mar 2020 00:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=09kqINZbNgaJ08f1ylme8IxsTsiLQ9eM83h3/Iwxtpg=; b=WtQB3c7DQouaUdwt0GkTwj343TWfXe925afx93VCB6iPV9dwfqTw9CjVMGuJNiTXo7 OwjlLxKznyDy8fITBol6D/KAwnrR54Mk8IG73CAlN6Svk++PD2J8nf4FMcVtlXM9nRNG 6BvqNJEoUbubpV7wdVGqo6twspylAM2rBirgQkBjaB0JE/drvJa6VY0T0Yz/kJk8ntPF WKW9MSNd7l5e/r9USSdYZJZTmCexJuItZ0U+898VqNqY9LxMCLoBCZtEFaScS5vVOCP6 tc2rCa0juRp+EAMfcjQ6aNE1q2U5v0kB+r2wiQKI8XDiMZMDXP2p0ZOI/x6IGkQx78nq 3C3Q== 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:reply-to :from:date:message-id:subject:to:cc; bh=09kqINZbNgaJ08f1ylme8IxsTsiLQ9eM83h3/Iwxtpg=; b=Jx0bn/HIuu7xuTvdKfdNqKvT+zqXoHhhl+ckHZ5YIRc8EJEeVQc04cnNn15aWIZ+cD mgP+wkDIjhxfRprzOBNZQTymqHBnOLuYXWZXwP8FuUCwLDj1qB0d0zx/wlOV2leboO3a Td8M5s4H9WhjvJEDWT61iGOGGzbYOCazItotRP34hCBRa3H2iodEEodnM87v5JfNNRjn erX3rykYupd1ySVOwrp1Jbb6L5gvDuSA98frCn9wRZtBN7ftIZT6Nqd6zIZ/UZnfSviR +t4oyhiHcIkRGQ27irGx4nJYYCTiYzabqMbehqr7uUBAja412BhRWzqv28yyAuD5y6uJ Vq5g== X-Gm-Message-State: ANhLgQ3H8mtpNLq6j5V0w7dOMivxak0OOy33g4yuprCv/gmVU0VQ1UwG +3XM3s2yCaycTnGZHIt9jyN6ksr9cbz2ge9/PP23yA== X-Google-Smtp-Source: ADFU+vtkriXjLLYs6t96RlsgpdxUeWhwG7rnnWCA+LM7wFsKw9rc+hxjg1mXEgzup1Kgt7z7P5E3lL5IvUnMcZ+BRRs= X-Received: by 2002:a05:6102:2086:: with SMTP id h6mr4226794vsr.134.1584690472702; Fri, 20 Mar 2020 00:47:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Fri, 20 Mar 2020 00:47:41 -0700 Message-ID: To: Nat Sakimura Cc: Mike Jones , Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" , Justin Richer Content-Type: multipart/alternative; boundary="000000000000b4700a05a14480a9" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 07:48:15 -0000 --000000000000b4700a05a14480a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like the direction this is going. Besides agreeing with the proposed layering and with the importance of fleshing out the RS-AS discourse and access control, which probably doesn't come as a surprise given my interest in the JWT AT profile; I feel that focusing on this aspect, rather that areas like identity which already have a known, viable solution, will make it easier to "market" TxAuth to the non initiated. A lot of the improvements being proposed these days are better ways of implementing what to the untrained eye might look like the same scenarios being tackled by existing protocols- and given that most of the non identity experts use SDKs, they might just not see much difference. Given better guidance on the access control aspect would provide a valueprop that would be easy to see to the non expert, too. On Thu, Mar 19, 2020 at 11:21 PM Nat Sakimura wrote: > I thought I should keep my mouth shut as anything I say may be deemed > biased as my other hat is the chairman of OIDF, but here is my 2c. > > As Torsten indicated, there is much to be desired to standardize the AS - > RS communication patterns. You may say that the charter includes it, but = I > cannot read it out of the charter just like Torsten could not. As a new > protocol, it would be good to include it. > > In this respect, I am not sure if we should start off from OAuth 2.0 and > OIDC model. If we are creating a new protocol, I feel that we should > architect is more fully. Not mentioning AS - RS relationship to me feels > like an indication of this failure. For that matter, I feel that the firs= t > output of the group should be an architecture document that takes the > concerns from all the relevant stakeholders/actors in. > > We should also be cognizant of the access control models like ABAC. For > that, decoupling of identity (=3D set of claims) assertion and authorizat= ion > is a necessity. We could optimize it but the base case should take care o= f > it. (In this respect, I am feeling that OIDC has perhaps over-optimized.) > So, I feel that at least as the first step, TxAuth should concentre on th= e > Access Control. If I were to go one step further, it should be modelled s= o > that it can consume various identity assertions (authenticated identity i= n > ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable > Credentials, X.509 certificates (such as in eIDAS and Japanese National I= D > scheme) etc. We are not going to get to a unified identity world anytime > soon. > > Cheers, > > Nat Sakimura > > > On Wed, Mar 18, 2020 at 7:06 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >> I believe it's significant that four people have expressed concerns with >> including digital identity in the charter (the only concerns voiced as f= ar >> as I can tell). At a minimum, I believe that that warrants making the >> inclusion or exclusion of digital identity a discussion topic during the >> upcoming virtual BoF, before adopting any charter. >> >> It would be my proposal to initially charter without digital identity an= d >> see how far we get with our energies intentionally focused in that way. = If >> the working group decides to recharter to include digital identity, that >> can always happen later, after the authorization-focused work has mature= d, >> and once there's a clear case to actually do so. >> >> -- Mike >> >> -----Original Message----- >> From: Justin Richer >> Sent: Tuesday, March 17, 2020 2:20 PM >> To: Mike Jones >> Cc: Yaron Sheffer ; Torsten Lodderstedt < >> torsten@lodderstedt.net>; txauth@ietf.org >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >> >> While I understand the concerns around identity in the charter, and I ha= d >> initially not included it, I was convinced that the kind of identity >> protocol that we=E2=80=99re looking at here is a minor addition to the >> authorization and delegation end of things. >> >> As you know, much of what=E2=80=99s in OIDC is there to fix problems wit= h OAuth 2 >> when it=E2=80=99s used for identity. If OAuth 2 had solved those problem= s >> internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now >> starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know >> what other problems there might be. >> >> The market has shown us that the most common application of OAuth 2 is >> far and away access to identity information along side access to an API.= I >> think we need to pay attention to that and not make this separate just >> because we did it that way before. And some of the proposed innovations, >> including getting and sending VC=E2=80=99s, are all about identity. >> >> Furthermore, this charter does not specify the document and specificatio= n >> structure of the components, nor does it specify the publication order o= r >> timing of any documents. I personally think that the identity layer shou= ld >> be separable to an extent, to the point of publishing that layer in its = own >> spec alongside the core authorization delegation system. However, that d= oes >> not mean that it should be developed elsewhere. >> >> If there is better language to tighten the aspects of an identity >> protocol that we will explicitly cover, then I would welcome you to sugg= est >> an amended text to the charter. However, I believe there is enough inter= est >> within the community to work on identity in the context of this protocol= , >> including a large number of people being OK with it in the charter, that= it >> would not be a reasonable thing to remove it. >> >> =E2=80=94 Justin >> >> > On Mar 17, 2020, at 1:12 PM, Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> > >> > 1. Do you support the charter text provided at the end of this email? >> Or do you have major objections, blocking concerns or feedback (if so >> please elaborate)? >> > >> > I share the concerns about including identity in the charter that were >> expressed by Torsten and agreed with by David Skaife. I'll note that Ki= m >> Cameron previously expressed concerns about including identity in his >> earlier charter critique at >> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE= / >> . >> > >> > I'm fine with refactoring the authorization protocol. But identity >> should be decoupled from the TxAuth work to focus its scope on areas whe= re >> innovation is being proposed. Digital identity can always be added as a >> layer if needed, just as OpenID Connect layered identity onto OAuth 2.0. >> > >> > Please revise the charter to remove digital identity from the scope of >> the work. >> > >> > 2. Are you willing to author or participate in the development of the >> drafts of this WG? >> > >> > Yes >> > >> > 3. Are you willing to help review the drafts of this WG? >> > >> > Yes >> > >> > 4. Are you interested in implementing drafts of this WG? >> > >> > Not at this time. >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: Txauth On Behalf Of Torsten Loddersted= t >> > Sent: Saturday, March 7, 2020 7:18 AM >> > To: Yaron Sheffer >> > Cc: txauth@ietf.org >> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G >> > >> > Hi, >> > >> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : >> >> >> >> =EF=BB=BFHi Everyone, >> >> >> >> It appears that momentum is forming around the proposed formation of = a >> TxAuth working group. We=E2=80=99d like to more formally gauge interest= in >> proceeding with this work. Please do so by responding to the following >> questions: >> >> >> >> 1. Do you support the charter text provided at the end of this >> email? Or do you have major objections, blocking concerns or feedback (= if >> so please elaborate)? >> > >> > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the >> charter is too broad, e.g. identify alone is a huge topic.. >> > >> > We need to keep an eye on this aspect in order to make sure, the group >> is able to work effectively and the specs we will be producing are as >> simple as possible and foster interoperability. >> > >> >> >> >> 2. Are you willing to author or participate in the development of th= e >> drafts of this WG? >> > >> > yes >> > >> >> >> >> 3. Are you willing to help review the drafts of this WG? >> > >> > yes >> > >> >> >> >> 4. Are you interested in implementing drafts of this WG? >> > >> > yes >> > >> > best regards, >> > Torsten. >> > >> >> >> >> The call will run for two weeks, until March 21. If you think that th= e >> charter should be amended In a significant way, please reply on a separa= te >> thread. >> >> >> >> The feedback provided here will help the IESG come to a decision on >> the formation of a new WG. Given the constraints of the chartering proce= ss, >> regardless of the outcome of this consensus call, we will be meeting in >> Vancouver as a BoF. >> >> >> >> Thanks, >> >> Yaron and Dick >> >> >> >> --- Charter Text Follows --- >> >> >> >> This group is chartered to develop a fine-grained delegation protocol >> for authorization, identity, and API access. This protocol will allow an >> authorizing party to delegate access to client software through an >> authorization server. It will expand upon the uses cases currently >> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth >> 2.0) to support authorizations scoped as narrowly as a single transactio= n, >> provide a clear framework for interaction among all parties involved in = the >> protocol flow, and remove unnecessary dependence on a browser or user-ag= ent >> for coordinating interactions. >> >> >> >> The delegation process will be acted upon by multiple parties in the >> protocol, each performing a specific role. The protocol will decouple th= e >> interaction channels, such as the end user=E2=80=99s browser, from the d= elegation >> channel, which happens directly between the client and the authorization >> server (in contrast with OAuth 2.0 which is initiated by the client >> redirecting the user=E2=80=99s browser). The client and AS will involve = a user to >> make an authorization decision as necessary through interaction mechanis= ms >> indicated by the protocol. This decoupling avoids many of the security >> concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve >> path for supporting future types of clients and interaction channels. >> >> >> >> Additionally, the delegation process will allow for: >> >> >> >> - Fine-grained specification of access >> >> - Approval of AS attestation to identity claims >> >> - Approval of access to multiple resources and APIs in a single >> interaction >> >> - Separation between the party authorizing access and the party >> operating the client requesting access >> >> - A variety of client applications, including Web, mobile, >> single-page, and interaction-constrained applications >> >> >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> >> - User interaction mechanisms including web and non-web methods >> >> - Mechanisms for conveying user, software, organization, and other >> pieces of information used in authorization decisions >> >> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >> >> - Optimized inclusion of additional information through the delegatio= n >> process (including identity) >> >> >> >> Additionally, the group will provide mechanisms for management of the >> protocol lifecycle including: >> >> >> >> - Discovery of the authorization server >> >> - Revocation of active tokens >> >> - Query of token rights by resource servers >> >> >> >> Although the artifacts for this work are not intended or expected to >> be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will >> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the n= ew >> protocol where possible. >> >> >> >> This group is not chartered to develop extensions to OAuth 2.0, and a= s >> such will focus on new technological solutions not necessarily compatibl= e >> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be >> developed in the OAuth Working Group, including functionality back-porte= d >> from the protocol developed here to OAuth 2.0. >> >> >> >> The group is chartered to develop mechanisms for applying >> cryptographic methods, such as JOSE and COSE, to the delegation process. >> This group is not chartered to develop new cryptographic methods. >> >> >> >> The initial work will focus on using HTTP for communication between >> the client and the authorization server, taking advantage of optimizatio= n >> features of HTTP2 and HTTP3 where possible, and will strive to enable >> simple mapping to other protocols such as COAP when doing so does not >> conflict with the primary focus. >> >> >> >> Milestones to include: >> >> - Core delegation protocol >> >> - Key presentation mechanism bindings to the core protocol for TLS, >> detached HTTP signature, and embedded HTTP signatures >> >> - Identity and authentication conveyance mechanisms >> >> - Guidelines for use of protocol extension points >> >> >> >> >> >> -- >> >> Txauth mailing list >> >> Txauth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >> > -- >> > Txauth mailing list >> > Txauth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b4700a05a14480a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the direction this is going. Besides agreeing with = the proposed layering and with the importance of fleshing out the RS-AS dis= course and access control, which probably doesn't come as a surprise gi= ven my interest in the JWT AT profile; I feel that focusing on this aspect,= rather that areas like identity which=C2=A0already=C2=A0have a known, viab= le solution, will make it easier to "market" TxAuth to the non in= itiated. A lot of the improvements being proposed these days are better way= s of implementing what to the untrained eye might look like the same scenar= ios being tackled=C2=A0by existing=C2=A0protocols- and given that most of t= he non identity experts use SDKs, they might just not see much difference. = Given better guidance on the access control aspect would provide a valuepro= p that would be easy to see to the non expert, too.

On Thu, M= ar 19, 2020 at 11:21 PM Nat Sakimura <sakimura@gmail.com> wrote:
I thought I should keep my mouth=C2= =A0shut as anything I say may be deemed biased as my other hat is the chair= man of OIDF, but here is my 2c.=C2=A0

As Torsten indicat= ed, there is much to be desired to standardize the AS - RS communication pa= tterns. You may say that the charter includes it, but I cannot read it out = of the charter just like Torsten could not. As a new protocol, it would be = good to include it.=C2=A0

In this respect, I am no= t sure if we should start off from OAuth 2.0 and OIDC model. If we are crea= ting a new protocol, I feel that we should architect is more fully. Not men= tioning AS - RS relationship to me feels like an indication of this failure= . For that matter, I feel that the first output of the group should be an a= rchitecture document that takes the concerns from all the relevant stakehol= ders/actors in.=C2=A0

We should also be cognizant = of the access=C2=A0control models like ABAC. For that, decoupling of identi= ty (=3D set of claims) assertion and authorization is a necessity. We could= optimize it but the base case should take care of it. (In this respect, I = am feeling that OIDC has perhaps over-optimized.) So, I feel that at least = as the first step, TxAuth should concentre on the Access Control. If I were= to go one step further, it should be modelled so that it can consume vario= us identity assertions (authenticated identity in ISO/IEC 24760 speak) incl= uding ID Token, SAML Assertion, DID Verifiable Credentials, X.509 certifica= tes (such as in eIDAS and Japanese National ID scheme)=C2=A0 etc. We are no= t going to get to a unified identity world anytime soon.=C2=A0
Cheers,=C2=A0

Nat Sakimura
=

On Wed, Mar 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microso= ft.com@dmarc.ietf.org> wrote:
I believe it's significant that four people have e= xpressed concerns with including digital identity in the charter (the only = concerns voiced as far as I can tell).=C2=A0 At a minimum, I believe that t= hat warrants making the inclusion or exclusion of digital identity a discus= sion topic during the upcoming virtual BoF, before adopting any charter.
It would be my proposal to initially charter without digital identity and s= ee how far we get with our energies intentionally focused in that way.=C2= =A0 If the working group decides to recharter to include digital identity, = that can always happen later, after the authorization-focused work has matu= red, and once there's a clear case to actually do so.

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

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net&= gt;; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had i= nitially not included it, I was convinced that the kind of identity protoco= l that we=E2=80=99re looking at here is a minor addition to the authorizati= on and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems with O= Auth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now starting at a base where those problems don=E2=80=99t exist, b= ut we don=E2=80=99t yet know what other problems there might be.

The market has shown us that the most common application of OAuth 2 is far = and away access to identity information along side access to an API. I thin= k we need to pay attention to that and not make this separate just because = we did it that way before. And some of the proposed innovations, including = getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and specification s= tructure of the components, nor does it specify the publication order or ti= ming of any documents. I personally think that the identity layer should be= separable to an extent, to the point of publishing that layer in its own s= pec alongside the core authorization delegation system. However, that does = not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol = that we will explicitly cover, then I would welcome you to suggest an amend= ed text to the charter. However, I believe there is enough interest within = the community to work on identity in the context of this protocol, includin= g a large number of people being OK with it in the charter, that it would n= ot be a reasonable thing to remove it.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
>
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?
>
> I share the concerns about including identity in the charter that were= expressed by Torsten and agreed with by David Skaife.=C2=A0 I'll note = that Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Ca= hE/.
>
> I'm fine with refactoring the authorization protocol.=C2=A0 But id= entity should be decoupled from the TxAuth work to focus its scope on areas= where innovation is being proposed.=C2=A0 Digital identity can always be a= dded as a layer if needed, just as OpenID Connect layered identity onto OAu= th 2.0.
>
> Please revise the charter to remove digital identity from the scope of= the work.
>
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?
>
> Yes
>
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.o= rg
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>: >>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed formation = of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in proceeding with this work.=C2=A0 Please do so by responding to t= he following questions:
>>
>> 1.=C2=A0 Do you support the charter text provided at the end of th= is email?=C2=A0 Or do you have major objections, blocking concerns or feedb= ack (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the charter is too broad, e.g. identify alone is a huge topic= ..
>
> We need to keep an eye on this aspect in order to make sure, the group= is able to work effectively and the specs we will be producing are as simp= le as possible and foster interoperability.
>
>>
>> 2.=C2=A0 Are you willing to author or participate in the developme= nt of the drafts of this WG?
>
> yes
>
>>
>> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> yes
>
>>
>> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think that= the charter should be amended In a significant way, please reply on a sepa= rate thread.
>>
>> The feedback provided here will help the IESG come to a decision o= n the formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation proto= col for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an author= ization server. It will expand upon the uses cases currently supported by O= Auth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support a= uthorizations scoped as narrowly as a single transaction, provide a clear f= ramework for interaction among all parties involved in the protocol flow, a= nd remove unnecessary dependence on a browser or user-agent for coordinatin= g interactions.
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the de= legation channel, which happens directly between the client and the authori= zation server (in contrast with OAuth 2.0 which is initiated by the client = redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mech= anisms indicated by the protocol. This decoupling avoids many of the securi= ty concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve path for supporting future types of clients and interaction channels. >>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single in= teraction
>> - Separation between the party authorizing access and the party op= erating the client requesting access
>> - A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof of= possession
>> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other= pieces of information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding= resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the delega= tion process (including identity)
>>
>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new= protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported = from the protocol developed here to OAuth 2.0.
>>
>> The group is chartered to develop mechanisms for applying cryptogr= aphic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication betwee= n the client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable simp= le mapping to other protocols such as COAP when doing so does not conflict = with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for TLS= , detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat= _en
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000b4700a05a14480a9-- From nobody Fri Mar 20 04:52:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EE43A08A8 for ; Fri, 20 Mar 2020 04:52:24 -0700 (PDT) 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 tmSLgQ6IKinb for ; Fri, 20 Mar 2020 04:52:23 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 B41E13A089C for ; Fri, 20 Mar 2020 04:52:21 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id c19so5620502ioo.6 for ; Fri, 20 Mar 2020 04:52:21 -0700 (PDT) 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=nwNzf4roM6Ym1VgRwJkPsDz/j98E6c4FNkeFQEXRkxU=; b=NdavTfSOhnlMM2LSnnGd4WoQmJKhQQCRLemgCdQaWEM/4tuU+88C5yodMZ4iBR6Ua7 KBs+KgvTzT+wdUnrD3xQMmPQLl94QCYjUZTsmI1N4hMa2yXBHIvO0Bx1JmuUy5Zz+7I9 6cMCXR7Li6Xswb3onwYbTV1DXBbzT3PvbUEDgqeV4AA7DdW/Tzgwywdrq8iA5iCWPWMl xUZGYPGHDQ4DdMRTmRR1uDBFM4hd1+CwAmC4b/ACd6jpCKOMrYs7/eLyurww+4XvKS2o bDskeYOI28Zbe0FStIEgJ5toGgVJUDEi6tUw76iSCG9N6Su+Unm5hJTWrG0DE3HFsJ/R /7hA== 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=nwNzf4roM6Ym1VgRwJkPsDz/j98E6c4FNkeFQEXRkxU=; b=LuwSWw1oMjwUkQbv9Y6/fHGnbrnnv3xw4+Fucr1mPKJhCpAJI1JDigdYcMVEaGLgtX on5P8pEDtJtaCff7Y8LAgw4kcaKmXt4bGH5nWhdOsXu5TRSfCKHwuYjuONzt/hiekNPP Y7f4ijJxb+hJsjFADyy9kPlLTIk2s6+aShJgMBD4skSUQbvu/ocjkXQdXVrPfXdB9wLY yn8IK1CH1lWcbLABoNPhJOeXpqGmtP9hSiaMluTU6c8BaKzqaYJvrkp+bqJml5WO/xL3 chEvdr3xXSHNjmGgavYSU2rG1Bm8T6hEuGtCd4ObC27njEmrZYXPc4QOZENQb97BQNaD eeEQ== X-Gm-Message-State: ANhLgQ0kGbm1RIvYXKivhHE1Xcu4xfP6UDjkriXKKwSki+HSCKJo0mxu vADdrnxEPl0ZoKKDFs9vs52qXPNfHRy3QSFCyV7WPg== X-Google-Smtp-Source: ADFU+vtcxjVoVppwB1Z/t0MMYC7cS8+6cG06DhEh4/33ABPAUzJruKwhFz3rhFr6s7Drydw53ZWr52MwTvHfl0EnOUE= X-Received: by 2002:a6b:156:: with SMTP id 83mr7018984iob.187.1584705141051; Fri, 20 Mar 2020 04:52:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay IETF Date: Fri, 20 Mar 2020 17:22:09 +0530 Message-ID: To: Aaron Parecki Cc: Mike Jones , Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" , Justin Richer Content-Type: multipart/alternative; boundary="00000000000001947a05a147eb27" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 11:52:26 -0000 --00000000000001947a05a147eb27 Content-Type: text/plain; charset="UTF-8" On Wed, 18 Mar 2020 at 04:02, Aaron Parecki wrote: > Much of the confusion in the marketplace around OAuth and OpenID > Connect stems from the fact that they are separate specs developed in > separate organizations, when really they are two parts to the same > picture. I am strongly against excluding identity from the charter of > TxAuth, as I think this is a unique opportunity to bring the two > aspects together. > +1 --- Vijay --00000000000001947a05a147eb27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, 18 Mar 2020 at 04:02, Aaron Parecki <aaron@parecki.com> wrote:
Much of the confusion in the marketplace = around OAuth and OpenID
Connect stems from the fact that they are separate specs developed in
separate organizations, when really they are two parts to the same
picture. I am strongly against excluding identity from the charter of
TxAuth, as I think this is a unique opportunity to bring the two
aspects together.

+1

---
Vijay
--00000000000001947a05a147eb27-- From nobody Fri Mar 20 06:39:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9F3A0984 for ; Fri, 20 Mar 2020 06:39:16 -0700 (PDT) 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=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 HBdXMisvqVAy for ; Fri, 20 Mar 2020 06:39:11 -0700 (PDT) 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 67A873A098C for ; Fri, 20 Mar 2020 06:39:10 -0700 (PDT) Received: from [192.168.1.5] (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 02KDd54Z013358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 09:39:06 -0400 From: Justin Richer Message-Id: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_AA779CEF-D7BA-4A3F-AD41-FFA34BA90B44" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Mar 2020 09:39:05 -0400 In-Reply-To: Cc: Mike Jones , Yaron Sheffer , Torsten Lodderstedt , "txauth@ietf.org" To: Nat Sakimura References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 13:39:17 -0000 --Apple-Mail=_AA779CEF-D7BA-4A3F-AD41-FFA34BA90B44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with a lot of that argument. Let me see if I can more clearly = restate what I was trying to say earlier in this thread: the = relationships between the different parties are separable and depend on = the kind of deployments and use cases that are being addressed by = people. So in an OAuth/OIDC-style world, we=E2=80=99ve got three = components (ignoring people), and three relationships between them: C<->AS C<->RS AS<->RS For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, = =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow to interpret a = token=E2=80=9D. For authentication, it=E2=80=99s additionally =E2=80=9Chow= do I get the authentication info=E2=80=9D, =E2=80=9Chow do I ask for a = profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80=9D= . I still believe this is a good separation of concerns. The client = doesn=E2=80=99t need to know what=E2=80=99s in the access token, or if = it=E2=80=99s a reference or self-contained, or really concern itself at = all with what the RS does with it. Are there overlaps? Certainly =E2=80=94= the client needs to know how to ask for a token that the RS will accept = for what the client is going to do, and to do that the client needs to = be able to describe what it wants to do in a way that the AS can = interpret and map to a set of rights that the RS will eventually = interpret.=20 I believe the proposed charter already covers this split with the = following items: - Fine-grained specification of access - Approval of access to multiple resources and APIs in a single = interaction - Separation between the party authorizing access and the party = operating the client requesting access - Revocation of active tokens - Query of token rights by resource servers It=E2=80=99s the combination of the rich request and the lifecycle = management that puts the AS and RS in scope. I think things like = declaring a single token format are absolutely out =E2=80=94 if you want = to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just fine. = However, something that I think is in scope is defining a structure for = what a token represents. And I think that if we can do that in this WG = in a general way, then that=E2=80=99s useful. Because then that = structure can be represented by mapping to a token format or an = introspection response or a database entry. I think Nat=E2=80=99s = comments on ABAC are important: we are going to need a place to put = those attributes. Whether they=E2=80=99re communicated to the RS through = the token itself or through some other channel is, I strongly believe, a = matter of deployment choice. So, what can the charter say to make this more clear? All that said, I=E2=80=99m against having an architecture document as a = working group output. In my experience, when a WG puts its effort into a = formal architecture doc as a deliverable, there is a lot of conjectural = energy that goes into what might be a good idea, and then not all of it = works out when you try to hammer the details of making that architecture = into a real engineered thing.You end up baking in assumptions and = abstractions that don=E2=80=99t make sense anymore, and then trying to = engineer solutions around those when they don=E2=80=99t fit right. If = the architecture can=E2=80=99t change in light of new information, which = is the case with an RFC, then it becomes a shackle instead of a = scaffold. But a malleable document that the group can use as a guide = while engineering the actual parts =E2=80=94 yes, that makes sense. The = architecture can be refactored and changed as decisions are made and = things come into focus. I feel the same about use case documents as = formal artifacts.=20 Thanks, Nat. =E2=80=94 Justin > On Mar 20, 2020, at 2:19 AM, Nat Sakimura wrote: >=20 > I thought I should keep my mouth shut as anything I say may be deemed = biased as my other hat is the chairman of OIDF, but here is my 2c.=20 >=20 > As Torsten indicated, there is much to be desired to standardize the = AS - RS communication patterns. You may say that the charter includes = it, but I cannot read it out of the charter just like Torsten could not. = As a new protocol, it would be good to include it.=20 >=20 > In this respect, I am not sure if we should start off from OAuth 2.0 = and OIDC model. If we are creating a new protocol, I feel that we should = architect is more fully. Not mentioning AS - RS relationship to me feels = like an indication of this failure. For that matter, I feel that the = first output of the group should be an architecture document that takes = the concerns from all the relevant stakeholders/actors in.=20 >=20 > We should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme) etc. We are not = going to get to a unified identity world anytime soon.=20 >=20 > Cheers,=20 >=20 > Nat Sakimura >=20 >=20 > On Wed, Mar 18, 2020 at 7:06 AM Mike Jones = > wrote: > I believe it's significant that four people have expressed concerns = with including digital identity in the charter (the only concerns voiced = as far as I can tell). At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter. >=20 > It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way. If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so. >=20 > -- Mike >=20 > -----Original Message----- > From: Justin Richer >=20 > Sent: Tuesday, March 17, 2020 2:20 PM > To: Mike Jones > > Cc: Yaron Sheffer >; Torsten Lodderstedt = >; = txauth@ietf.org > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >=20 > While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things. >=20 > As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.=20 >=20 > The market has shown us that the most common application of OAuth 2 is = far and away access to identity information along side access to an API. = I think we need to pay attention to that and not make this separate just = because we did it that way before. And some of the proposed innovations, = including getting and sending VC=E2=80=99s, are all about identity. >=20 > Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >=20 > If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >=20 > =E2=80=94 Justin >=20 > > On Mar 17, 2020, at 1:12 PM, Mike Jones = > wrote: > >=20 > > 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? > >=20 > > I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/ = . > >=20 > > I'm fine with refactoring the authorization protocol. But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed. Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0. > >=20 > > Please revise the charter to remove digital identity from the scope = of the work. > >=20 > > 2. Are you willing to author or participate in the development of = the drafts of this WG? > >=20 > > Yes > >=20 > > 3. Are you willing to help review the drafts of this WG? > >=20 > > Yes > >=20 > > 4. Are you interested in implementing drafts of this WG? > >=20 > > Not at this time. > >=20 > > -- Mike > >=20 > > -----Original Message----- > > From: Txauth > On Behalf Of Torsten Lodderstedt > > Sent: Saturday, March 7, 2020 7:18 AM > > To: Yaron Sheffer > > > Cc: txauth@ietf.org > > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth = WG > >=20 > > Hi, > >=20 > >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer >: > >>=20 > >> =EF=BB=BFHi Everyone, > >>=20 > >> It appears that momentum is forming around the proposed formation = of a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: > >>=20 > >> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? > >=20 > > I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. > >=20 > > We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. > >=20 > >>=20 > >> 2. Are you willing to author or participate in the development of = the drafts of this WG? > >=20 > > yes > >=20 > >>=20 > >> 3. Are you willing to help review the drafts of this WG? > >=20 > > yes > >=20 > >>=20 > >> 4. Are you interested in implementing drafts of this WG? > >=20 > > yes > >=20 > > best regards, > > Torsten. > >=20 > >>=20 > >> The call will run for two weeks, until March 21. If you think that = the charter should be amended In a significant way, please reply on a = separate thread. > >>=20 > >> The feedback provided here will help the IESG come to a decision on = the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. > >>=20 > >> Thanks, > >> Yaron and Dick > >>=20 > >> --- Charter Text Follows --- > >>=20 > >> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 > >>=20 > >> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. > >>=20 > >> Additionally, the delegation process will allow for: > >>=20 > >> - Fine-grained specification of access > >> - Approval of AS attestation to identity claims > >> - Approval of access to multiple resources and APIs in a single = interaction > >> - Separation between the party authorizing access and the party = operating the client requesting access > >> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications > >>=20 > >> The group will define extension points for this protocol to allow = for flexibility in areas including: > >>=20 > >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 > >> - User interaction mechanisms including web and non-web methods > >> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > >> - Optimized inclusion of additional information through the = delegation process (including identity) > >>=20 > >> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: > >>=20 > >> - Discovery of the authorization server > >> - Revocation of active tokens > >> - Query of token rights by resource servers > >>=20 > >> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. > >>=20 > >> This group is not chartered to develop extensions to OAuth 2.0, and = as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. > >>=20 > >> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.=20 > >>=20 > >> The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. > >>=20 > >> Milestones to include: > >> - Core delegation protocol > >> - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures > >> - Identity and authentication conveyance mechanisms > >> - Guidelines for use of protocol extension points > >>=20 > >>=20 > >> --=20 > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_AA779CEF-D7BA-4A3F-AD41-FFA34BA90B44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with a lot of that argument. Let me see if I can more clearly = restate what I was trying to say earlier in this thread: the = relationships between the different parties are separable and depend on = the kind of deployments and use cases that are being addressed by = people. So in an OAuth/OIDC-style world, we=E2=80=99ve got three = components (ignoring people), and three relationships between them:

C<->AS

C<->RS

AS<->RS

For authorization, these = map to =E2=80=9Chow to get a token=E2=80=9D, =E2=80=9Chow to use a = token=E2=80=9D, and =E2=80=9Chow to interpret a token=E2=80=9D. For = authentication, it=E2=80=99s additionally =E2=80=9Chow do I get the = authentication info=E2=80=9D, =E2=80=9Chow do I ask for a profile=E2=80=9D= , and =E2=80=9Chow do I know whose profile this is=E2=80=9D. I still = believe this is a good separation of concerns. The client doesn=E2=80=99t = need to know what=E2=80=99s in the access token, or if it=E2=80=99s a = reference or self-contained, or really concern itself at all with what = the RS does with it. Are there overlaps? Certainly =E2=80=94 the client = needs to know how to ask for a token that the RS will accept for what = the client is going to do, and to do that the client needs to be able to = describe what it wants to do in a way that the AS can interpret and map = to a set of rights that the RS will eventually = interpret. 

I believe the proposed charter already covers this split with = the following items:

- Fine-grained specification of access
- = Approval of access to multiple resources and APIs in a single = interaction
- Separation between the party authorizing = access and the party operating the client requesting access
- Revocation of active = tokens
- Query of token rights by resource servers

It=E2=80=99s the combination of the rich request and the = lifecycle management that puts the AS and RS in scope. I think things = like declaring a single token format are absolutely out =E2=80=94 if you = want to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just = fine. However, something that I think is in scope is defining a = structure for what a token represents. And I think that if we can do = that in this WG in a general way, then that=E2=80=99s useful. Because = then that structure can be represented by mapping to a token format or = an introspection response or a database entry. I think Nat=E2=80=99s = comments on ABAC are important: we are going to need a place to put = those attributes. Whether they=E2=80=99re communicated to the RS through = the token itself or through some other channel is, I strongly believe, a = matter of deployment choice.

So, what can the charter say to make = this more clear?

All that said, I=E2=80=99m against having an architecture = document as a working group output. In my experience, when a WG puts its = effort into a formal architecture doc as a = deliverable, there is a lot of conjectural energy that goes into = what might be a good idea, and then not all of it works out when you try = to hammer the details of making that architecture into a real engineered = thing.You end up baking in assumptions and abstractions that don=E2=80=99t= make sense anymore, and then trying to engineer solutions around those = when they don=E2=80=99t fit right. If the architecture can=E2=80=99t = change in light of new information, which is the case with an RFC, then = it becomes a shackle instead of a scaffold. But a malleable document = that the group can use as a guide while engineering the actual parts =E2=80= =94 yes, that makes sense. The architecture can be refactored and = changed as decisions are made and things come into focus. I feel the = same about use case documents as formal artifacts. 

Thanks, = Nat.
 =E2=80=94 Justin

On Mar 20, 2020, at 2:19 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

I thought I should keep my = mouth shut as anything I say may be deemed biased as my other hat = is the chairman of OIDF, but here is my 2c. 

As Torsten indicated, there is much to = be desired to standardize the AS - RS communication patterns. You may = say that the charter includes it, but I cannot read it out of the = charter just like Torsten could not. As a new protocol, it would be good = to include it. 

In this respect, I am not sure if we should start off from = OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel that = we should architect is more fully. Not mentioning AS - RS relationship = to me feels like an indication of this failure. For that matter, I feel = that the first output of the group should be an architecture document = that takes the concerns from all the relevant stakeholders/actors = in. 

We = should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme)  etc. We are not = going to get to a unified identity world anytime soon. 

Cheers, 

Nat Sakimura


On Wed, Mar = 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
I = believe it's significant that four people have expressed concerns with = including digital identity in the charter (the only concerns voiced as = far as I can tell).  At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter.

It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way.  If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so.

                    =             -- Mike

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten = Lodderstedt <torsten@lodderstedt.net>; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.

The market has shown us that the most common application of OAuth 2 is = far and away access to identity information along side access to an API. = I think we need to pay attention to that and not make this separate just = because we did it that way before. And some of the proposed innovations, = including getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere.

If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it.

 =E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>
> 1.  Do you support the charter text provided at the end of = this email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
>
> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife.  I'll = note that Kim Cameron previously expressed concerns about including = identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXS= nshX2CahE/.
>
> I'm fine with refactoring the authorization protocol.  But = identity should be decoupled from the TxAuth work to focus its scope on = areas where innovation is being proposed.  Digital identity can = always be added as a layer if needed, just as OpenID Connect layered = identity onto OAuth 2.0.
>
> Please revise the charter to remove digital identity from the scope = of the work.
>
> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>
> Yes
>
> 3.  Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.  Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>                  =              -- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Torsten Lodderstedt
> Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.org
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed = formation of a TxAuth working group.  We=E2=80=99d like to more = formally gauge interest in proceeding with this work.  Please do so = by responding to the following questions:
>>
>> 1.  Do you support the charter text provided at the end of = this email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic.
>
> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability.
>
>>
>> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>
> yes
>
>>
>> 3.  Are you willing to help review the drafts of this = WG?
>
> yes
>
>>
>> 4.  Are you interested in implementing drafts of this = WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think = that the charter should be amended In a significant way, please reply on = a separate thread.
>>
>> The feedback provided here will help the IESG come to a = decision on the formation of a new WG. Given the constraints of the = chartering process, regardless of the outcome of this consensus call, we = will be meeting in Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.
>>
>> The delegation process will be acted upon by multiple parties = in the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.
>>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single = interaction
>> - Separation between the party authorizing access and the party = operating the client requesting access
>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to = allow for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof = of possession
>> - User interaction mechanisms including web and non-web = methods
>> - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions
= >> - Mechanisms for presenting tokens to resource servers and = binding resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the = delegation process (including identity)
>>
>> Additionally, the group will provide mechanisms for management = of the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth = 2.0.
>>
>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
= > --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


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

= --Apple-Mail=_AA779CEF-D7BA-4A3F-AD41-FFA34BA90B44-- From nobody Fri Mar 20 07:59:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7803A09EA for ; Fri, 20 Mar 2020 07:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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 ZEBM11dzGvD7 for ; Fri, 20 Mar 2020 07:58:31 -0700 (PDT) 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 666DE3A09F0 for ; Fri, 20 Mar 2020 07:58:18 -0700 (PDT) Received: from [192.168.1.5] (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 02KEwG6E008266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 10:58:17 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> Date: Fri, 20 Mar 2020 10:58:16 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 14:59:06 -0000 So fundamentally, I don=E2=80=99t want the AS to allowed to split tokens = when the client isn=E2=80=99t expecting it. Would a simple feature flag = to allow that behavior at the AS be enough to switch both cases?=20 So let=E2=80=99s say we just do the simple thing and make it a boolean = top-level flag. If the client sends =E2=80=9Csplit_tokens: true=E2=80=9D = then the AS always returns the =E2=80=9Cmultiple_access_tokens=E2=80=9D = structure and it comes up with whatever names it makes sense for the = resulting tokens. The client can do either the single or multiple token = request style. The client needs to be able to figure out from the token = responses how to put which token in which place, and I think we can do = some things with the guts of the =E2=80=9Cresources=E2=80=9D request = object, like using =E2=80=9Clocations=E2=80=9D and maybe other fields. = If the client doesn=E2=80=99t send =E2=80=9Csplit_tokens: true=E2=80=9D = then the AS sends a single token for a single token request, and = multiple tokens for a multiple token request, exactly mapped to what the = client requested in each resources block. If the client asks for = resources that cross domains in a way that AS can=E2=80=99t support, it = returns an error. The syntax needs work, but it would at least allow both modes of = operation. And it collapses nicely into the single-token use case, which = is one of my goals here. I don=E2=80=99t want a client to ask for 1 = token and get 2 or ask for 2 tokens and get 3, unless it=E2=80=99s fully = prepared for that. Would something like that fly for you? =E2=80=94 Justin > On Mar 19, 2020, at 9:37 AM, Justin Richer wrote: >=20 > I see what you=E2=80=99re going for here. I think the key point comes = down to this: >=20 >> - The client knows what it wants to do and where >=20 > That=E2=80=99s knowledge is exactly why I would argue that the client = would have to explicitly request multiple access tokens in order to get = them.=20 >=20 > I=E2=80=99m worried about requiring all clients to be prepared to = accept multiple access tokens. In a lot of big cloud deployments, it=E2=80= =99s absolutely based on location. But that=E2=80=99s not the only = dispatch for security domains. A client would need to know, ultimately, = what a token is for and where to use it. And we=E2=80=99d also need to = deal with cases that allow for subdomains, paths, query parameters, and = other variability of an API=E2=80=99s URLs. After all, I=E2=80=99m = probably going to send that same token to a bunch of different URLs in = order to do a bunch of different things, even if they=E2=80=99re all = within the same =E2=80=9CRS=E2=80=9D or =E2=80=9Cdomain=E2=80=9D or = whatever. Which brings us to an underlying problem =E2=80=94 I don=E2=80=99= t think there=E2=80=99s a good way to reference the identity of an RS. = Solid is attempting to do that using WebID=E2=80=99s as service = identifiers, and while that=E2=80=99s interesting, it=E2=80=99s deeply = tied to their system where everything knows what a WebID is and what to = do with it. I think it=E2=80=99s a bad idea to depend on that kind of = thing for a general purpose system.=20 >=20 > I=E2=80=99m hesitant to have clients depend on being told that = information. I think if we go down that route we=E2=80=99re going to = have to also tell clients things like =E2=80=9Cthis is only good for GET = requests=E2=80=9D and =E2=80=9Cthis is good for subdomains on this = location=E2=80=9D and =E2=80=9Cthis can be used for anything except this = one exception=E2=80=9D. And it doesn=E2=80=99t fit well when you=E2=80=99r= e trying to mix two different APIs that have really different = structures. Things like GraphQL and REST lead to pretty different URL = designs, and TxAuth should be usable for all of that. It feels like too = much automated configuration of a client instead of the client just = =E2=80=9Cdoing something=E2=80=9D, which I think is going to be the = common case. In other words, I do think that the client software is = going to be bespoke for the API that it=E2=80=99s calling. However, the = security library that speaks the TxAuth piece doesn=E2=80=99t have to = be, and the protocol itself doesn=E2=80=99t need to be. But the = protocols should allow the client software to express to the security = layer what it knows about the API. >=20 > And speaking of common cases, I think it=E2=80=99s actually much more = rare to have multiple security domains covered by an AS in a way that = would need multiple encryptions or targets. I think many of us see it = because we work with large enterprise-scale systems with multiple = domains that we want to manage all at once. In my experience, it=E2=80=99s= much more common to have a client talk to one AS to get one token for = one RS. One of my goals with this is to not make it complicated for = simple clients, and I think having to be prepared to get multiple access = tokens is too complex for simple clients. I might be wrong, but it=E2=80=99= s based on my experience across a lot of different kinds of APIs. The = idea of splitting up tokens like below feels REALLY complex, especially = when I asked for a single one. I get why you want to do it, it makes = sense for the AS to be able to do something like that, but from a = client=E2=80=99s perspective it=E2=80=99s a lot more complicated without = a clear idea of what the identity of an RS is. I think solving that = problem is a HUGE issue that we should put firmly out of scope. >=20 > The thing is, though, you=E2=80=99re absolutely right that there=E2=80=99= s a need for this kind of multiple tokens. So in my view, the lift of = having a client know about the domains that it=E2=80=99s calling is a = lot less than the client having to potentially deal with more tokens = than it asked for, and knowing how to correctly dispatch those. Also the = semantics of what the =E2=80=9Cresources=E2=80=9D object represents = changes, since I could potentially be getting two tokens back that do = parts of the one thing that I asked for, and the client now needs to = know which to use for what. If the client has to name the splits itself, = that implies the client knows what each =E2=80=9Cresources=E2=80=9D = sub-object represents and knows how to apply that to its =E2=80=9Ccall = the API=E2=80=9D code. The security layer doesn=E2=80=99t know or care, = but the code that knows how to manipulate the API and its data knows and = cares. >=20 > As for the token content =E2=80=94 that=E2=80=99s solidly an = implementation decision and orthogonal to this discussion. You can do = all of this multi access token stuff with introspection and = reference-based tokens. Access tokens themselves need to stay opaque to = the client and to the protocol at large. I don=E2=80=99t believe = that=E2=80=99s up for debate. >=20 > Thanks so much for pushing this conversation, and now I=E2=80=99m more = convinced than ever that handling multiple tokens in the response is = something we need to figure out within this group.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt = wrote: >>=20 >> Hi Justin, >>=20 >> thanks for explaining the different options. I=E2=80=99m well aware = of the super refresh token (and remember the discussions back then in = Taipei :-)), I have implemented systems using this and other patterns, = too. >>=20 >> The underlying assumption for most of those patterns is that the = client upfront knows the boundaries between RS security domains, which = typically means the solution is bespoken.=20 >>=20 >> TXAuth is chartered to develop a protocol and not a framework. What = I=E2=80=99m looking for is interoperable protocol support for use of = RS-specific self-contained access tokens in multi-RS deployments. >>=20 >> Why RS-specific self-contained access tokens?=20 >> This is in my experience the most efficient way to empower = high-volume/high-load services in a very efficient, secure, and privacy = preserving fashion.=20 >>=20 >> - Every token contains exactly the data the RS needs to perform = access control decisions locally. No need for further database lookups = or AS callbacks, that=E2=80=99s really fast and keeps cost of the AS = function low. >> - The token itself can be encrypted to protect this data using a = RS-specific key, one could even use HMACs to protect integrity and = authenticity (fast as well).=20 >> - The token can have a RS-specific lifetime. >> - Since every token is restricted to a single RS audience, those = tokens also have a baseline replay detection built-in.=20 >>=20 >> I think this pattern makes sense in environments with multiple RSs = (e.g. different products) as well. But since every token is minted to = the specific requirements of a certain RS, the AS must be able to mint = different tokens. That doesn=E2=80=99t work properly without some = support in the protocol. >>=20 >> Is there a need for multi access tokens support?=20 >> Well, you implemented it, I implemented it, and I think a couple of = other implementers did it with OAuth 2 in the past. So there seems to be = some need. Why does the rest use the single token pattern? I think some = deployments will indeed only have a single service, but I bet a lot of = implementers did it because their product does not support anything = else.=20 >>=20 >> I have experienced this myself when I designed the architecture of = the yes ecosystem. It is a federation of authorization servers with = associated services where every AS represents a certain bank. Since our = partners shall be able to implement their AS using the product they = like, I needed to go with the least common denominator - single access = token. This has a significant consequences: our tokens are basically = handles, so every service calls back to the AS to obtain its data for = every service request. This degrades performance significantly and, = since those tokens are good for multi audiences, it forces us to = generally use sender constrained tokens, which increases complexity for = clients.=20 >>=20 >> I would like to give implementers more options in the TXAuth space. = That=E2=80=99s why I advocate to build-in support f=C3=BCr multiple = access tokens into TXAuth.=20 >>=20 >> My proposal is based on the following assumptions: >> - Token format, content, encryption keys and so on are defined as = part of the interface between AS and RS >> - The client knows what it wants to do and where >> - Every party contributes the information it has to the overall = process to make it work simply and effectively for everyone.=20 >>=20 >> There is no change/addition needed to the request syntax. All it = takes is your new multi token syntax (+ a small addition) in the = response.=20 >>=20 >> The client uses the =E2=80=9Cresources" structure to communicate what = (actions, further elements) it wants to do and where (locations). >>=20 >> [ >> { >> =E2=80=9Cactions": ["read", "write"], >> "locations": ["https://example.com/resource"], >> =E2=80=9Cdata": ["foo", "bar"] >> }, >> { >> =E2=80=9Cactions": ["write"], >> "locations": ["https://other_example.com/resource"], >> =E2=80=9Cdata": ["foo", "bar"] >> } >> ] >>=20 >> One deployment might use a single token for all RSs, in this case the = token response remains unchanged:=20 >>=20 >> { >> "access_token":{ >> "value":"08ur4kahfga09u23rnkjasdf", >> "type":"bearer" >> } >> } >>=20 >> If the AS has the need to issue multiple access tokens, it could, for = example, use the =E2=80=9Clocations" elements to determine what tokens = it needs to create. Such an AS then uses the multiple_access_tokens = structure augmented by corresponding "locations=E2=80=9D entries in the = token response:=20 >>=20 >> "multiple_access_tokens":{ >> "token_a":{ >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type":"bearer", >> "locations":[ >> "https://example.com/resource" >> ] >> }, >> "token_b":{ >> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >> "type":"bearer", >> "locations":[ >> "https://other_example.com/resource" >> ] >> } >> } >>=20 >> Since the client passed the locations values in the request, it is = also able to determine where to use what access token.=20 >>=20 >> I think that=E2=80=99s pretty simple, especially from a client = perspective. =20 >>=20 >> And If the client wants to split access tokens further apart, e.g. to = obtain tokens with less privileges, it can do so using the request = syntax you defined:=20 >>=20 >> resources: { >> token1: [{ >> actions: ["read", "write", "dolphin"], >> locations: ["https://server.example.net/", = "https://resource.local/other"], >> datatypes: ["metadata", "images"] >> }], >> token2: [{ >> actions: ["foo", "bar", "dolphin"], >> locations: ["https://resource.other/"], >> datatypes: ["data", "pictures"] >> }] >> } >>=20 >> In the simplest case, the AS would return the data as in your = proposal. >>=20 >> If the client asks for a partitioning of privileges that goes across = RS security domains like this >>=20 >> { >> "resources":{ >> "token1":[ >> { >> "actions":[ "read", "write","dolphin" ], >> "locations":[ = "https://server.example.net/","https://resource.local/other"], >> "datatypes":[ "metadata","images"] >> }, >> { >> "actions":["read","write"], >> "locations":["https://example.com/resource"] >> } >> ], >> "token2":[ >> { >> "actions":["foo","bar", "dolphin"], >> "locations":["https://resource.other/"], >> "datatypes":["data","pictures"] >> } >> ] >> } >> } >>=20 >> the AS would need to further partition the pre-defined tokens like = this: >>=20 >> "multiple_access_tokens=E2=80=9D:{ >> =E2=80=9Ctoken1/a":{ >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type":"bearer", >> = "locations":["https://server.example.net/","https://resource.local/other"]= >> }, >> =E2=80=9Ctoken1/b":{ >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> "type":"bearer", >> "locations":["https://example.com/resource"] >> }, >> =E2=80=9Ctoken2":{ >> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >> "type":"bearer", >> "locations":[ >> "https://other_example.com/resource" >> ] >> } >> } >>=20 >> Naming of the tokens is a bit tricky but I think solvable. >>=20 >> What do you think? >>=20 >> best regards, >> Torsten. >>=20 >>> On 15. Mar 2020, at 15:26, Justin Richer wrote: >>>=20 >>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt = wrote: >>>>=20 >>>>> On 15. Mar 2020, at 03:25, Justin Richer wrote: >>>>>=20 >>>>> So if the AS needs a client to get different access tokens to call = different RS domains, it does exactly what we do in OAuth 2 today =E2=80=94= it tells the client to get two different access tokens.=20 >>>>=20 >>>> How does this work in XYZ? >>>>=20 >>>=20 >>> Without using the multi-access-token thing I=E2=80=99m proposing in = this thread, the client would just make two separate transaction calls = to get two different tokens. There=E2=80=99s a few ways that shakes out = depending on some of the details. In the OAuth world that amounts to = involving the user twice, and it might be the same in XYZ if you=E2=80=99r= e asking for different things: >>>=20 >>> 1. Client: Start TX-1 (R-1) >>> 2. User: Approve R-1 >>> 3. AS: Issue AT-1(R-1) >>> 4. Client: Start TX-2 (R-1) >>> 5. User: approve R-2 >>> 6. AS: Issue AT-2(R-2) >>>=20 >>> Unless you=E2=80=99re getting a super refresh token upfront and then = calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can = do that trick too. >>>=20 >>> 1. Client: Start TX-1 (R-1, R-2) >>> 2. User: Approve R-1, R-2 >>> 3. AS: Issue AT1 (R-1, R-2) >>> 4. Client: Continue TX-1 (R-2) >>> 5. AS: Issue AT-2 (R-2) >>>=20 >>> But we=E2=80=99ve got another thing we can use in XYZ to help this, = the user handle. This lets a trusted client tell the AS that it believes = the same user is still there and asking the question, so if the access = rights are OK then you don=E2=80=99t need to involve the user again. We = invented this construct with UMA2, where it=E2=80=99s called the = persisted claims token (PCT). >>>=20 >>> 1. Client: Start TX-1 (R-1) >>> 2. User: Approve R-1 >>> 3. AS: Issue AT-1 (R-1), user handle U-1 >>> 4. Client Start TX-2 (R-2, U-1) >>> 5. AS: Issue AT-2 (R-2) >>>=20 >>> Now: With the multi-token request, we can collapse this all back to = a single transaction with multiple outputs: >>>=20 >>> 1. Client: Start TX-2 (token1: R-1, token2: R-2) >>> 2. User Approve R-1, R-2 >>> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) >>>=20 >>> I haven=E2=80=99t liked any of the multi-access-token solutions to = date because they make things weird for single access token requests. I = like this idea because it=E2=80=99s an optimization for a complex case = that doesn=E2=80=99t change the behavior for the simple case, and in = fact doesn=E2=80=99t even change the expectations for the simple case. = To me, that=E2=80=99s important. >>>=20 >>> =E2=80=94 Justin >>=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Fri Mar 20 10:16:58 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7057D3A0C97; Fri, 20 Mar 2020 10:16:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Agenda To: X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158472461624.13412.5637890496784591161@ietfa.amsl.com> Date: Fri, 20 Mar 2020 10:16:56 -0700 Archived-At: Subject: [Txauth] Virtual IETF 107 Meeting WebEx Invitation: TXAUTH X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:16:57 -0000 TXAUTH Session at IETF 107 Monday, March 23, 2020 20:00-22:00 (UTC) Join meeting: Meeting number (access code): 314 345 860 Meeting password: 7CxgVpFNB27 IETF 107 Agenda: From nobody Fri Mar 20 10:24:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F03A0D39 for ; Fri, 20 Mar 2020 10:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 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, MALFORMED_FREEMAIL=1.713, MISSING_HEADERS=1.021, 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 J_QSpmWSl8ev for ; Fri, 20 Mar 2020 10:24:53 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 51C813A0D30 for ; Fri, 20 Mar 2020 10:24:53 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id i1so4473542lfo.1 for ; Fri, 20 Mar 2020 10:24:52 -0700 (PDT) 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:cc; bh=u12cuUkz+o/xx1+qFY1qzuJNuUgdt30/aCPpQTVcX+g=; b=mEEOzEaWv2DZtSD7619PIf6JSTk2+qfbuLqCcoKChugbYD/iBfuETQVmpN0Ke0kLta Xo1yiAZUvCbyXEDnlkEE6dyymbdSsB9eZeBPpIGKXcY6EJYxyXu7SkKwG5RnJTBaJf7o FfA4PycptFpaiol3eRgP1cYpsgc1SH8lLUkLP05zYBU7fYlOUXnvyzDYgGMdvcIoBKWK qDhSZylD9URcMcoDuMl9+hseGpV3TDVbfK8Ha1CL3U6+vQVC5du0xsmLexYILlmBBbfm BR4rIudoRyGji+6O0aS6l0dQFwq6P6ti5FV6aaI2RYiXoFWsoZNKwIJIar3vIuB59KeV 17tw== 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:cc; bh=u12cuUkz+o/xx1+qFY1qzuJNuUgdt30/aCPpQTVcX+g=; b=KLo/gdjw9VM8JWxUtPNvmo0ARHm05XQBuINNKEpkYLTxdR/S1E0ps9YlJRVFsEHd1X OG4wfJ3fFgmBSH8imQQtc4J87Z/IwtYXX9r4Y+cz60xr7xD7EKI2D3CLc6YV6ahwGpgb SGuhQURbHMnNupIkDLnI4Tg1rTTWcgFfxMFQ62I1bpBO4sGSFaeqHg7n3bXsexMBTycc kJPuVZz1gDX/2076YqXrcOQXpJnqfFwJyABLyYbvTBshoCkiIw6X4EQy90t6kXGEYQ4F 1iEYh+xI7wkcM1Qat4lpITtGwlofDxTuDslTqWJYlSw5WfJ6vBXxO9yQHuQQtERuxKOr WqKQ== X-Gm-Message-State: ANhLgQ0DUNsf2C7SvkqDtoRTcf+i+alLvX4GENKWAsHXVeifHMdHzuUv cuwWTaRSRAlaevUcOaNXz3ri96FyVfR1xQgcFukwexGk X-Google-Smtp-Source: ADFU+vtMQBIT1xn11hV4s223/mfMmlqnv5HHzukzh3foVhAov0D4E+MwPFKQfs0+FDX5iFv2yq/IAm2drglYvUVoUiQ= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr441338lfm.91.1584725090167; Fri, 20 Mar 2020 10:24:50 -0700 (PDT) MIME-Version: 1.0 References: <158472461624.13412.5637890496784591161@ietfa.amsl.com> In-Reply-To: <158472461624.13412.5637890496784591161@ietfa.amsl.com> From: Dick Hardt Date: Fri, 20 Mar 2020 10:24:24 -0700 Message-ID: Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000010eeab05a14c906f" Archived-At: Subject: Re: [Txauth] Virtual IETF 107 Meeting WebEx Invitation: TXAUTH X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:24:56 -0000 --00000000000010eeab05a14c906f Content-Type: text/plain; charset="UTF-8" We are the first session listed in the agenda. Note the agenda line item has icons on the right with links for the the Jabber room, EtherPad for Blue pad, and WebEx link. On Fri, Mar 20, 2020 at 10:17 AM IETF Agenda wrote: > TXAUTH Session at IETF 107 > > Monday, March 23, 2020 > 20:00-22:00 (UTC) > > Join meeting: < > https://ietf.webex.com/ietf/j.php?MTID=m2d064bb1ddce5360cac8c5459998d232> > > Meeting number (access code): 314 345 860 > Meeting password: 7CxgVpFNB27 > > IETF 107 Agenda: > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000010eeab05a14c906f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are the first session listed in the agenda.=C2=A0
<= br>
Note the agenda line item has icons on the right with links f= or the the Jabber room, EtherPad for Blue pad, and WebEx link.


On Fri, Mar 20, 2020 at 10:17 AM IETF Agenda <agenda@ietf.org> wrote:
TXAUTH Session at IETF 107

Monday, March 23, 2020
20:00-22:00 (UTC)

Join meeting: <https://= ietf.webex.com/ietf/j.php?MTID=3Dm2d064bb1ddce5360cac8c5459998d232><= br>
Meeting number (access code): 314 345 860
Meeting password: 7CxgVpFNB27

IETF 107 Agenda: <https://datatracker.ietf.org/mee= ting/107/agenda>

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000010eeab05a14c906f-- From nobody Fri Mar 20 11:04:49 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB96B3A0D7B for ; Fri, 20 Mar 2020 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=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 4gnmmYvpzim5 for ; Fri, 20 Mar 2020 11:04:33 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 A15C63A0D76 for ; Fri, 20 Mar 2020 11:04:30 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id v16so372969ljk.13 for ; Fri, 20 Mar 2020 11:04:30 -0700 (PDT) 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=C1HsyseHK+V2afEiOYYur+vbdRSBRo2WNZPcs/n1HQ0=; b=L98Prj+DVyXosJjYneGBJs6vzrwZzWWeS+j18VQwIBreaG3+ZSJ1v/72TwQMWIHyOl 3H+i1NLX3wE7zTl5Wj3r+Cj4L7Pydw+KoaRsp6Ndm5JS5DTcwMKNbTMv5zkoY9ETOVyW EaF2/79L/R9jYqCTHhWuqPHRQ5VjtXP/ZbIEThpMQymdSbQSeHi0bg+OJgz1ESX4CKdg N8YTbuT6sl/7LS/BmLRM5L2onyhVgTbLZ1c8eLKY5iRe3UId6/GUChsniNL1jPPGmztn vAm0rcngYojZbozVIFIrtl34LxTTRW3L4wSdKVfiY4kqLzZtY/WWTfBAlFpVF3tHFVpx a7rw== 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=C1HsyseHK+V2afEiOYYur+vbdRSBRo2WNZPcs/n1HQ0=; b=Fqz7zDxlCGx01mpTZUCsYaqNt9KulPX0Q2ZoUfgQknqRJxQY/FZ1AJTGtbk7Rd0oh4 OJB9nsgY7djIVoEa2bOLBA2A4hG+k9ZyYYRVq7kgZM75xR13fTqCRooNeot0luJTLpv5 /tbAEgnr8aCdTIZSbK5APwhKWeeLeWCaF+USAV0OBxigkpfM6K69j4r3IVIQLCQ1pZ1H Uv+CHVr8Zusp5ujmOclkKvOknfHQqqC/8RrGdkdQaOoME3PwJMa1NIZAiMyYvBc+vpcS +BsqrN0PKdWZ1PYIgN1NECx5pAyAh38hVxKEZnhaYk2yXTiUYQkEbyI37yAUDbsHBrYP Sk3A== X-Gm-Message-State: ANhLgQ28Kaf1LS58awmKuu+h3XXNcemqj5ZflR25jNp98VTVyCUxAthP 9lGHeG0LPubNCm3RpwVDyHwqmuqgflXAM8oRBdE= X-Google-Smtp-Source: ADFU+vtVadQdfEhZEuxdpjblvsyUpBm7cP4En0iCcEKLu3YjYmdKIEzMyLhfi0/X9EOO6B+2G7N6lysduVWuLmQHXHM= X-Received: by 2002:a2e:9d84:: with SMTP id c4mr6280022ljj.51.1584727462246; Fri, 20 Mar 2020 11:04:22 -0700 (PDT) MIME-Version: 1.0 References: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> In-Reply-To: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 11:03:55 -0700 Message-ID: To: Justin Richer Cc: Nat Sakimura , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000073fb5e05a14d1d35" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 18:04:45 -0000 --00000000000073fb5e05a14d1d35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nat: thanks for chiming in. Useful insights as always! Vittorio: I'll reinterpret your statement about "marketing" the work, to be that we should solve real problems that people don't have solutions for today. *AS<->RS relationship* TL;DR: I think the charter misses the mark in the AS<->RS relationship being in scope and we should expand it. In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast to OAuth 1.0, but the interactions / communication between the AS and the RS were out of scope, as the uses cases at the time had the AS and RS operated by the same entity. New use cases have a weaker coupling between the AS and RS, and to enable interop, extensions have been written for Token Introspection, and JWT Profile for OAuth 2.0 Access Tokens . The TxAuth charter includes introspection: - Query of token rights by resource servers -- but does not include the common design pattern where the RS can directly interpret the token. Here is proposed updated text to the line above to be broader in scope than just a query: - communication of token attributes between the authorization server and resource server *Architecture and Use Case documents* TL;DR: Yes to use case doc, no to architecture doc. I agree with Justin that an architecture document is unlikely to prove useful long term. I disagree with him on the use cases. I don't think the use cases need to be exhaustive, but example use cases helps everyone understand everyone else's primary use cases. If your use case is not similar to others, then you should write it up and the WG can decide if it is in scope or not. If it is, it gets added to the use case document. I would consider this a living document while working on the core protocol. It would NOT be a use case document that scopes the WG work. The charter does that. It would be a companion document to the core protocol. I strongly think a use case document resolves many of the miscommunications that happen where people are talking past each other, because they don't understand each other's use case. *Reusing Existing Technology* TL;DR: we should be reusing existing specifications where ever possible. Reading between the lines, I think the concern around identity may be that the TxAuth charter implies that the WG is going to create yet-another-identity-representation and ignore all the previous efforts. I think creating yet-another-identity-representation to solve use cases that are already solved with existing representations would be misguided effort. My own interest in TxAuth is being able to use one protocol to request and receive any existing and future identity representation. One of my motivations for writing the XAuth document was to show how different representations could be requested and received, as this was missing in XYZ. If a use case requires a new representation, then perhaps TxAuth may be a place for that work to happen, but I think it is more likely to happen in other forums. It is not clear to me how, or if, reusing existing technology fits into the charter, but I do strongly think it should be a tenet of the WG. On a related note, I also strongly think that the existing OAuth 2.0 scopes should be easily used in requests and responses. XAuth shows an example of how that can be done. /Dick On Fri, Mar 20, 2020 at 6:39 AM Justin Richer wrote: > I agree with a lot of that argument. Let me see if I can more clearly > restate what I was trying to say earlier in this thread: the relationship= s > between the different parties are separable and depend on the kind of > deployments and use cases that are being addressed by people. So in an > OAuth/OIDC-style world, we=E2=80=99ve got three components (ignoring peop= le), and > three relationships between them: > > C<->AS > > C<->RS > > AS<->RS > > For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, =E2= =80=9Chow to use a > token=E2=80=9D, and =E2=80=9Chow to interpret a token=E2=80=9D. For authe= ntication, it=E2=80=99s > additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, =E2= =80=9Chow do I ask for a > profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80= =9D. I still believe this > is a good separation of concerns. The client doesn=E2=80=99t need to know= what=E2=80=99s in > the access token, or if it=E2=80=99s a reference or self-contained, or re= ally > concern itself at all with what the RS does with it. Are there overlaps? > Certainly =E2=80=94 the client needs to know how to ask for a token that = the RS > will accept for what the client is going to do, and to do that the client > needs to be able to describe what it wants to do in a way that the AS can > interpret and map to a set of rights that the RS will eventually interpre= t. > > I believe the proposed charter already covers this split with the > following items: > > - Fine-grained specification of access > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > - Revocation of active tokens > - Query of token rights by resource servers > > It=E2=80=99s the combination of the rich request and the lifecycle manage= ment that > puts the AS and RS in scope. I think things like declaring a single token > format are absolutely out =E2=80=94 if you want to use JWT, or CWT, or UU= ID=E2=80=99s, > that=E2=80=99s all just fine. However, something that I think is in scope= is > defining a structure for what a token represents. And I think that if we > can do that in this WG in a general way, then that=E2=80=99s useful. Beca= use then > that structure can be represented by mapping to a token format or an > introspection response or a database entry. I think Nat=E2=80=99s comment= s on ABAC > are important: we are going to need a place to put those attributes. > Whether they=E2=80=99re communicated to the RS through the token itself o= r through > some other channel is, I strongly believe, a matter of deployment choice. > > So, what can the charter say to make this more clear? > > All that said, I=E2=80=99m against having an architecture document as a w= orking > group output. In my experience, when a WG puts its effort into a formal > architecture doc *as a deliverable*, there is a lot of conjectural energy > that goes into what might be a good idea, and then not all of it works ou= t > when you try to hammer the details of making that architecture into a rea= l > engineered thing.You end up baking in assumptions and abstractions that > don=E2=80=99t make sense anymore, and then trying to engineer solutions a= round > those when they don=E2=80=99t fit right. If the architecture can=E2=80=99= t change in light > of new information, which is the case with an RFC, then it becomes a > shackle instead of a scaffold. But a malleable document that the group ca= n > use as a guide while engineering the actual parts =E2=80=94 yes, that mak= es sense. > The architecture can be refactored and changed as decisions are made and > things come into focus. I feel the same about use case documents as forma= l > artifacts. > > Thanks, Nat. > =E2=80=94 Justin > > On Mar 20, 2020, at 2:19 AM, Nat Sakimura wrote: > > I thought I should keep my mouth shut as anything I say may be deemed > biased as my other hat is the chairman of OIDF, but here is my 2c. > > As Torsten indicated, there is much to be desired to standardize the AS - > RS communication patterns. You may say that the charter includes it, but = I > cannot read it out of the charter just like Torsten could not. As a new > protocol, it would be good to include it. > > In this respect, I am not sure if we should start off from OAuth 2.0 and > OIDC model. If we are creating a new protocol, I feel that we should > architect is more fully. Not mentioning AS - RS relationship to me feels > like an indication of this failure. For that matter, I feel that the firs= t > output of the group should be an architecture document that takes the > concerns from all the relevant stakeholders/actors in. > > We should also be cognizant of the access control models like ABAC. For > that, decoupling of identity (=3D set of claims) assertion and authorizat= ion > is a necessity. We could optimize it but the base case should take care o= f > it. (In this respect, I am feeling that OIDC has perhaps over-optimized.) > So, I feel that at least as the first step, TxAuth should concentre on th= e > Access Control. If I were to go one step further, it should be modelled s= o > that it can consume various identity assertions (authenticated identity i= n > ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable > Credentials, X.509 certificates (such as in eIDAS and Japanese National I= D > scheme) etc. We are not going to get to a unified identity world anytime > soon. > > Cheers, > > Nat Sakimura > > > On Wed, Mar 18, 2020 at 7:06 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >> I believe it's significant that four people have expressed concerns with >> including digital identity in the charter (the only concerns voiced as f= ar >> as I can tell). At a minimum, I believe that that warrants making the >> inclusion or exclusion of digital identity a discussion topic during the >> upcoming virtual BoF, before adopting any charter. >> >> It would be my proposal to initially charter without digital identity an= d >> see how far we get with our energies intentionally focused in that way. = If >> the working group decides to recharter to include digital identity, that >> can always happen later, after the authorization-focused work has mature= d, >> and once there's a clear case to actually do so. >> >> -- Mike >> >> -----Original Message----- >> From: Justin Richer >> Sent: Tuesday, March 17, 2020 2:20 PM >> To: Mike Jones >> Cc: Yaron Sheffer ; Torsten Lodderstedt < >> torsten@lodderstedt.net>; txauth@ietf.org >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >> >> While I understand the concerns around identity in the charter, and I ha= d >> initially not included it, I was convinced that the kind of identity >> protocol that we=E2=80=99re looking at here is a minor addition to the >> authorization and delegation end of things. >> >> As you know, much of what=E2=80=99s in OIDC is there to fix problems wit= h OAuth 2 >> when it=E2=80=99s used for identity. If OAuth 2 had solved those problem= s >> internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now >> starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know >> what other problems there might be. >> >> The market has shown us that the most common application of OAuth 2 is >> far and away access to identity information along side access to an API.= I >> think we need to pay attention to that and not make this separate just >> because we did it that way before. And some of the proposed innovations, >> including getting and sending VC=E2=80=99s, are all about identity. >> >> Furthermore, this charter does not specify the document and specificatio= n >> structure of the components, nor does it specify the publication order o= r >> timing of any documents. I personally think that the identity layer shou= ld >> be separable to an extent, to the point of publishing that layer in its = own >> spec alongside the core authorization delegation system. However, that d= oes >> not mean that it should be developed elsewhere. >> >> If there is better language to tighten the aspects of an identity >> protocol that we will explicitly cover, then I would welcome you to sugg= est >> an amended text to the charter. However, I believe there is enough inter= est >> within the community to work on identity in the context of this protocol= , >> including a large number of people being OK with it in the charter, that= it >> would not be a reasonable thing to remove it. >> >> =E2=80=94 Justin >> >> > On Mar 17, 2020, at 1:12 PM, Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> > >> > 1. Do you support the charter text provided at the end of this email? >> Or do you have major objections, blocking concerns or feedback (if so >> please elaborate)? >> > >> > I share the concerns about including identity in the charter that were >> expressed by Torsten and agreed with by David Skaife. I'll note that Ki= m >> Cameron previously expressed concerns about including identity in his >> earlier charter critique at >> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE= / >> . >> > >> > I'm fine with refactoring the authorization protocol. But identity >> should be decoupled from the TxAuth work to focus its scope on areas whe= re >> innovation is being proposed. Digital identity can always be added as a >> layer if needed, just as OpenID Connect layered identity onto OAuth 2.0. >> > >> > Please revise the charter to remove digital identity from the scope of >> the work. >> > >> > 2. Are you willing to author or participate in the development of the >> drafts of this WG? >> > >> > Yes >> > >> > 3. Are you willing to help review the drafts of this WG? >> > >> > Yes >> > >> > 4. Are you interested in implementing drafts of this WG? >> > >> > Not at this time. >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: Txauth On Behalf Of Torsten Loddersted= t >> > Sent: Saturday, March 7, 2020 7:18 AM >> > To: Yaron Sheffer >> > Cc: txauth@ietf.org >> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G >> > >> > Hi, >> > >> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : >> >> >> >> =EF=BB=BFHi Everyone, >> >> >> >> It appears that momentum is forming around the proposed formation of = a >> TxAuth working group. We=E2=80=99d like to more formally gauge interest= in >> proceeding with this work. Please do so by responding to the following >> questions: >> >> >> >> 1. Do you support the charter text provided at the end of this >> email? Or do you have major objections, blocking concerns or feedback (= if >> so please elaborate)? >> > >> > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the >> charter is too broad, e.g. identify alone is a huge topic. >> > >> > We need to keep an eye on this aspect in order to make sure, the group >> is able to work effectively and the specs we will be producing are as >> simple as possible and foster interoperability. >> > >> >> >> >> 2. Are you willing to author or participate in the development of th= e >> drafts of this WG? >> > >> > yes >> > >> >> >> >> 3. Are you willing to help review the drafts of this WG? >> > >> > yes >> > >> >> >> >> 4. Are you interested in implementing drafts of this WG? >> > >> > yes >> > >> > best regards, >> > Torsten. >> > >> >> >> >> The call will run for two weeks, until March 21. If you think that th= e >> charter should be amended In a significant way, please reply on a separa= te >> thread. >> >> >> >> The feedback provided here will help the IESG come to a decision on >> the formation of a new WG. Given the constraints of the chartering proce= ss, >> regardless of the outcome of this consensus call, we will be meeting in >> Vancouver as a BoF. >> >> >> >> Thanks, >> >> Yaron and Dick >> >> >> >> --- Charter Text Follows --- >> >> >> >> This group is chartered to develop a fine-grained delegation protocol >> for authorization, identity, and API access. This protocol will allow an >> authorizing party to delegate access to client software through an >> authorization server. It will expand upon the uses cases currently >> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth >> 2.0) to support authorizations scoped as narrowly as a single transactio= n, >> provide a clear framework for interaction among all parties involved in = the >> protocol flow, and remove unnecessary dependence on a browser or user-ag= ent >> for coordinating interactions. >> >> >> >> The delegation process will be acted upon by multiple parties in the >> protocol, each performing a specific role. The protocol will decouple th= e >> interaction channels, such as the end user=E2=80=99s browser, from the d= elegation >> channel, which happens directly between the client and the authorization >> server (in contrast with OAuth 2.0 which is initiated by the client >> redirecting the user=E2=80=99s browser). The client and AS will involve = a user to >> make an authorization decision as necessary through interaction mechanis= ms >> indicated by the protocol. This decoupling avoids many of the security >> concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve >> path for supporting future types of clients and interaction channels. >> >> >> >> Additionally, the delegation process will allow for: >> >> >> >> - Fine-grained specification of access >> >> - Approval of AS attestation to identity claims >> >> - Approval of access to multiple resources and APIs in a single >> interaction >> >> - Separation between the party authorizing access and the party >> operating the client requesting access >> >> - A variety of client applications, including Web, mobile, >> single-page, and interaction-constrained applications >> >> >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> >> - User interaction mechanisms including web and non-web methods >> >> - Mechanisms for conveying user, software, organization, and other >> pieces of information used in authorization decisions >> >> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >> >> - Optimized inclusion of additional information through the delegatio= n >> process (including identity) >> >> >> >> Additionally, the group will provide mechanisms for management of the >> protocol lifecycle including: >> >> >> >> - Discovery of the authorization server >> >> - Revocation of active tokens >> >> - Query of token rights by resource servers >> >> >> >> Although the artifacts for this work are not intended or expected to >> be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will >> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the n= ew >> protocol where possible. >> >> >> >> This group is not chartered to develop extensions to OAuth 2.0, and a= s >> such will focus on new technological solutions not necessarily compatibl= e >> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be >> developed in the OAuth Working Group, including functionality back-porte= d >> from the protocol developed here to OAuth 2.0. >> >> >> >> The group is chartered to develop mechanisms for applying >> cryptographic methods, such as JOSE and COSE, to the delegation process. >> This group is not chartered to develop new cryptographic methods. >> >> >> >> The initial work will focus on using HTTP for communication between >> the client and the authorization server, taking advantage of optimizatio= n >> features of HTTP2 and HTTP3 where possible, and will strive to enable >> simple mapping to other protocols such as COAP when doing so does not >> conflict with the primary focus. >> >> >> >> Milestones to include: >> >> - Core delegation protocol >> >> - Key presentation mechanism bindings to the core protocol for TLS, >> detached HTTP signature, and embedded HTTP signatures >> >> - Identity and authentication conveyance mechanisms >> >> - Guidelines for use of protocol extension points >> >> >> >> >> >> -- >> >> Txauth mailing list >> >> Txauth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth >> > -- >> > Txauth mailing list >> > Txauth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000073fb5e05a14d1d35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nat: thanks for chiming in. Useful=C2=A0insights as a= lways!

Vittorio: I'll reinterpret your sta= tement about "marketing" the work, to be that we should solve rea= l problems that people don't have solutions for today.=C2=A0
=
AS<->RS relationship

TL;DR: I think the charter misses the mark in the AS<->RS relationsh= ip being in scope and we should expand it.

In OAuth 2.0 (RFC67= 49)l, the AS and RS were separate roles in contrast to OAuth 1.0, but the i= nteractions / communication between the AS and the RS were out of scope, as= the uses cases at the time had the AS and RS operated by the same entity. = New use cases have a weaker coupling between the AS and RS, and to enable i= nterop, extensions have been written for Token Introspection, and JWT Profi= le for OAuth 2.0 Access Tokens .=C2=A0

The TxAuth = charter includes introspection:
=C2=A0
- Query of token= rights by resource servers=C2=A0

-- but does not include the common design pattern where the RS can = directly interpret the token.

Here is proposed upd= ated=C2=A0text to the line above to be broader in scope than just a query:<= /div>

- communication=C2=A0of token attributes=C2=A0betw= een the authorization server and resource server


Architecture and Use Cas= e documents

TL;DR: Yes to use case doc, no to = architecture doc.

I agree with Justin that an arch= itecture=C2=A0document is unlikely to prove useful long term. I disagree wi= th him on the use cases. I don't think the use cases need to be exhaust= ive, but example use cases helps everyone understand everyone else's pr= imary use cases. If your use case is not similar to others, then you should= write it up and the WG can decide if it is in scope or not. If it is, it g= ets added to the use case document. I would consider this a living document= while working on the core protocol. It would NOT be a use case document th= at scopes the WG work. The charter does that. It would be a companion docum= ent to the core protocol. I strongly think a use case document resolves man= y of the miscommunications that happen where people are talking past each o= ther, because they don't understand each other's use case.

Reusing Existing Technology
<= b>
TL;DR: we should be reusing existing specifications wh= ere ever possible.

Reading between the lines, I th= ink the concern around identity may be that the TxAuth charter implies that= the WG is going to create yet-another-identity-representation and ignore a= ll the previous efforts. I think creating=C2=A0yet-another-identity-represe= ntation to solve use cases that are already solved with existing representa= tions would be misguided effort. My own interest in TxAuth is being able to= use one protocol to request and receive any existing and future identity r= epresentation. One of my motivations for writing the XAuth document was to = show how different representations could be requested and received, as this= was missing in XYZ.=C2=A0 If a use case requires a new representation, the= n perhaps TxAuth may be a place for that work to happen, but I think it is = more likely to happen in other forums.

It is not c= lear to me how, or if, reusing existing technology fits into the charter, b= ut I do strongly think it should be a tenet of the WG.

<= /div>
On a related note, I also strongly think that the existing OAuth = 2.0 scopes should be easily used in requests and responses. XAuth shows an = example of how that can be done.

/Dick=C2=A0
=




On Fri, Mar 20, 20= 20 at 6:39 AM Justin Richer <jricher@= mit.edu> wrote:
I agree with a lot of that= argument. Let me see if I can more clearly restate what I was trying to sa= y earlier in this thread: the relationships between the different parties a= re separable and depend on the kind of deployments and use cases that are b= eing addressed by people. So in an OAuth/OIDC-style world, we=E2=80=99ve go= t three components (ignoring people), and three relationships between them:=

C<->AS

C<->RS

AS<->RS

For authorizati= on, these map to =E2=80=9Chow to get a token=E2=80=9D, =E2=80=9Chow to use = a token=E2=80=9D, and =E2=80=9Chow to interpret a token=E2=80=9D. For authe= ntication, it=E2=80=99s additionally =E2=80=9Chow do I get the authenticati= on info=E2=80=9D, =E2=80=9Chow do I ask for a profile=E2=80=9D, and =E2=80= =9Chow do I know whose profile this is=E2=80=9D. I still believe this is a = good separation of concerns. The client doesn=E2=80=99t need to know what= =E2=80=99s in the access token, or if it=E2=80=99s a reference or self-cont= ained, or really concern itself at all with what the RS does with it. Are t= here overlaps? Certainly =E2=80=94 the client needs to know how to ask for = a token that the RS will accept for what the client is going to do, and to = do that the client needs to be able to describe what it wants to do in a wa= y that the AS can interpret and map to a set of rights that the RS will eve= ntually interpret.=C2=A0

I believe the proposed ch= arter already covers this split with the following items:

- Fine-grained specification of access
- Approval of access to m= ultiple resources and APIs in a single interaction
- Separation between = the party authorizing access and the party operating the client requesting = access
- Revocation of active tokens
- Query of token right= s by resource servers

It=E2=80=99s the combina= tion of the rich request and the lifecycle management that puts the AS and = RS in scope. I think things like declaring a single token format are absolu= tely out =E2=80=94 if you want to use JWT, or CWT, or UUID=E2=80=99s, that= =E2=80=99s all just fine. However, something that I think is in scope is de= fining a structure for what a token represents. And I think that if we can = do that in this WG in a general way, then that=E2=80=99s useful. Because th= en that structure can be represented by mapping to a token format or an int= rospection response or a database entry. I think Nat=E2=80=99s comments on = ABAC are important: we are going to need a place to put those attributes. W= hether they=E2=80=99re communicated to the RS through the token itself or t= hrough some other channel is, I strongly believe, a matter of deployment ch= oice.

So, what can the charter say to make this mo= re clear?

All that said, I=E2=80=99m against havin= g an architecture document as a working group output. In my experience, whe= n a WG puts its effort into a formal architecture doc as a deliverable, there is a lot of conjectural energy that goes into what might be a goo= d idea, and then not all of it works out when you try to hammer the details= of making that architecture into a real engineered thing.You end up baking= in assumptions and abstractions that don=E2=80=99t make sense anymore, and= then trying to engineer solutions around those when they don=E2=80=99t fit= right. If the architecture can=E2=80=99t change in light of new informatio= n, which is the case with an RFC, then it becomes a shackle instead of a sc= affold. But a malleable document that the group can use as a guide while en= gineering the actual parts =E2=80=94 yes, that makes sense. The architectur= e can be refactored and changed as decisions are made and things come into = focus. I feel the same about use case documents as formal artifacts.=C2=A0<= /div>

Thanks, Nat.
=C2=A0=E2=80=94 Justin=

On Mar 20, 2020, at 2:19 A= M, Nat Sakimura <sakimura@gmail.com> wrote:

I thought= I should keep my mouth=C2=A0shut as anything I say may be deemed biased as= my other hat is the chairman of OIDF, but here is my 2c.=C2=A0

As Torsten indicated, there is much to be desired to standardize th= e AS - RS communication patterns. You may say that the charter includes it,= but I cannot read it out of the charter just like Torsten could not. As a = new protocol, it would be good to include it.=C2=A0

In this respect, I am not sure if we should start off from OAuth 2.0 and = OIDC model. If we are creating a new protocol, I feel that we should archit= ect is more fully. Not mentioning AS - RS relationship to me feels like an = indication of this failure. For that matter, I feel that the first output o= f the group should be an architecture document that takes the concerns from= all the relevant stakeholders/actors in.=C2=A0

We= should also be cognizant of the access=C2=A0control models like ABAC. For = that, decoupling of identity (=3D set of claims) assertion and authorizatio= n is a necessity. We could optimize it but the base case should take care o= f it. (In this respect, I am feeling that OIDC has perhaps over-optimized.)= So, I feel that at least as the first step, TxAuth should concentre on the= Access Control. If I were to go one step further, it should be modelled so= that it can consume various identity assertions (authenticated identity in= ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable Cr= edentials, X.509 certificates (such as in eIDAS and Japanese National ID sc= heme)=C2=A0 etc. We are not going to get to a unified identity world anytim= e soon.=C2=A0

Cheers,=C2=A0

Nat Sakimura


On Wed, Mar 18, 2020 at 7:06 AM Mike Jo= nes <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
I believe it's significa= nt that four people have expressed concerns with including digital identity= in the charter (the only concerns voiced as far as I can tell).=C2=A0 At a= minimum, I believe that that warrants making the inclusion or exclusion of= digital identity a discussion topic during the upcoming virtual BoF, befor= e adopting any charter.

It would be my proposal to initially charter without digital identity and s= ee how far we get with our energies intentionally focused in that way.=C2= =A0 If the working group decides to recharter to include digital identity, = that can always happen later, after the authorization-focused work has matu= red, and once there's a clear case to actually do so.

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

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net&= gt;; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had i= nitially not included it, I was convinced that the kind of identity protoco= l that we=E2=80=99re looking at here is a minor addition to the authorizati= on and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems with O= Auth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now starting at a base where those problems don=E2=80=99t exist, b= ut we don=E2=80=99t yet know what other problems there might be.

The market has shown us that the most common application of OAuth 2 is far = and away access to identity information along side access to an API. I thin= k we need to pay attention to that and not make this separate just because = we did it that way before. And some of the proposed innovations, including = getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and specification s= tructure of the components, nor does it specify the publication order or ti= ming of any documents. I personally think that the identity layer should be= separable to an extent, to the point of publishing that layer in its own s= pec alongside the core authorization delegation system. However, that does = not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol = that we will explicitly cover, then I would welcome you to suggest an amend= ed text to the charter. However, I believe there is enough interest within = the community to work on identity in the context of this protocol, includin= g a large number of people being OK with it in the charter, that it would n= ot be a reasonable thing to remove it.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
>
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?
>
> I share the concerns about including identity in the charter that were= expressed by Torsten and agreed with by David Skaife.=C2=A0 I'll note = that Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Ca= hE/.
>
> I'm fine with refactoring the authorization protocol.=C2=A0 But id= entity should be decoupled from the TxAuth work to focus its scope on areas= where innovation is being proposed.=C2=A0 Digital identity can always be a= dded as a layer if needed, just as OpenID Connect layered identity onto OAu= th 2.0.
>
> Please revise the charter to remove digital identity from the scope of= the work.
>
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?
>
> Yes
>
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.o= rg
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>: >>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed formation = of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in proceeding with this work.=C2=A0 Please do so by responding to t= he following questions:
>>
>> 1.=C2=A0 Do you support the charter text provided at the end of th= is email?=C2=A0 Or do you have major objections, blocking concerns or feedb= ack (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the charter is too broad, e.g. identify alone is a huge topic= .
>
> We need to keep an eye on this aspect in order to make sure, the group= is able to work effectively and the specs we will be producing are as simp= le as possible and foster interoperability.
>
>>
>> 2.=C2=A0 Are you willing to author or participate in the developme= nt of the drafts of this WG?
>
> yes
>
>>
>> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> yes
>
>>
>> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think that= the charter should be amended In a significant way, please reply on a sepa= rate thread.
>>
>> The feedback provided here will help the IESG come to a decision o= n the formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation proto= col for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an author= ization server. It will expand upon the uses cases currently supported by O= Auth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support a= uthorizations scoped as narrowly as a single transaction, provide a clear f= ramework for interaction among all parties involved in the protocol flow, a= nd remove unnecessary dependence on a browser or user-agent for coordinatin= g interactions.
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the de= legation channel, which happens directly between the client and the authori= zation server (in contrast with OAuth 2.0 which is initiated by the client = redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mech= anisms indicated by the protocol. This decoupling avoids many of the securi= ty concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve path for supporting future types of clients and interaction channels. >>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single in= teraction
>> - Separation between the party authorizing access and the party op= erating the client requesting access
>> - A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof of= possession
>> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other= pieces of information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding= resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the delega= tion process (including identity)
>>
>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new= protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported = from the protocol developed here to OAuth 2.0.
>>
>> The group is chartered to develop mechanisms for applying cryptogr= aphic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication betwee= n the client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable simp= le mapping to other protocols such as COAP when doing so does not conflict = with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for TLS= , detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


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

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000073fb5e05a14d1d35-- From nobody Fri Mar 20 11:36:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FA63A0BF3 for ; Fri, 20 Mar 2020 11:36:52 -0700 (PDT) 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 sQkNEFxOftcH for ; Fri, 20 Mar 2020 11:36:48 -0700 (PDT) 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 75BF93A0DB4 for ; Fri, 20 Mar 2020 11:36:47 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id c20so5378160lfb.0 for ; Fri, 20 Mar 2020 11:36:47 -0700 (PDT) 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=0KgQROAwp7xPUqLJgqJN+YYijiIfKeaDJOA8Mx6N/XI=; b=Pz19aig1oUWQcDNAOCWOxE7fTDxQtOfg9FN/C8yGceKDjJUS+7EBHYG75qkH+Nr2dw dsM57potMgxEkLMXKlWP9Y+nS6H5q2sJH5FPmeQFHIl9sXOvwKCNAmLLtqLU9tbRzSVY caIZn4IKXzEsCpQD5YoXHzVj+gVV+JEBweIORU3yLgIzIYgcSrC0DGCuyP4j9wmbvM4r Y/q3ND4nFc78d4oUEYQzcHQakK5FRwu8NAfFfP4m6WHziq+ItlQxzn/dQf6/RU5OSimg xkm9oW2FFrYIZyWnHPvAUlHw2tyXIyOnWzboc6EMDYx/8sbmqwj/S1IW+wxxVxLjOAPe 9NKQ== 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=0KgQROAwp7xPUqLJgqJN+YYijiIfKeaDJOA8Mx6N/XI=; b=b54oVauhQferhhjGd4hD5q5HwnAXCy9dE+8oZxuBGiQAjSa7IBwox5mGGQmLptlrjX IldNbAS4/5WtlyhF8xquAIKsYUHwHxs7x0ulJ5dlUMtsnYyxG/yy2Q1gOQLglw/bn6it 0cjt7gtdxnH3iK55hsAxtKEwnTQSay4dfL4blGr9zWOoV7C8MQB/XLvv7qn8YY1htzmU yGGV+Nk5LhFmKwDFWdKFduZbe/Q51kVl8Z9U5cR6k3HrVghzYYUkiR9z0cw2zdzLO3NY uGxlWRrUPpaZGFlQVhE8pWLVkXCbRUaE1eP2v5LEQopaDf4NmyBpWnOIH7HKfmGE6xXp 8nmg== X-Gm-Message-State: ANhLgQ3qNXQVf6HxaITEf1hnjWnyFmGZgRI2HZAs9+LN7Hx4HWH7daMA qTYprdydlOc8llDO6Q/qzqh6AkjK6P4F9cAFILs= X-Google-Smtp-Source: ADFU+vszfJQhs84j//jya0nM6wayYkaWDVS49m4aeaKiATazgCot5Pnmz6NjdQZGHaNkIn0awKdw+4DPomUuAmM5KYc= X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr6256057lfe.23.1584729405265; Fri, 20 Mar 2020 11:36:45 -0700 (PDT) MIME-Version: 1.0 References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> In-Reply-To: <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 11:36:18 -0700 Message-ID: To: Justin Richer Cc: Torsten Lodderstedt , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000441c5e05a14d91ae" Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 18:36:53 -0000 --000000000000441c5e05a14d91ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Justin that the Client unexpectedly getting split access tokens is undesirable. I agree with Mike and Torsten that tokens should be self contained, and able to be independent between resources. I would add that they should be as fine grained as practical, which is part of the charter. Rather then the client thinking it is getting multiple access tokens, how about thinking of the client getting access to multiple resources? The AS provides an access token for each resource. The access tokens may all be the same, all be different, or a mix. The Client does not need to know which ones are the same or different ahead of time, but it does know which one it will use for accessing which resource. I don't think there is a need for a "split_tokens" flag. That sounds overly complicated. On Fri, Mar 20, 2020 at 7:59 AM Justin Richer wrote: > So fundamentally, I don=E2=80=99t want the AS to allowed to split tokens = when the > client isn=E2=80=99t expecting it. Would a simple feature flag to allow t= hat > behavior at the AS be enough to switch both cases? > > So let=E2=80=99s say we just do the simple thing and make it a boolean t= op-level > flag. If the client sends =E2=80=9Csplit_tokens: true=E2=80=9D then the A= S always returns > the =E2=80=9Cmultiple_access_tokens=E2=80=9D structure and it comes up wi= th whatever names > it makes sense for the resulting tokens. The client can do either the > single or multiple token request style. The client needs to be able to > figure out from the token responses how to put which token in which place= , > and I think we can do some things with the guts of the =E2=80=9Cresources= =E2=80=9D request > object, like using =E2=80=9Clocations=E2=80=9D and maybe other fields. If= the client > doesn=E2=80=99t send =E2=80=9Csplit_tokens: true=E2=80=9D then the AS sen= ds a single token for a > single token request, and multiple tokens for a multiple token request, > exactly mapped to what the client requested in each resources block. If t= he > client asks for resources that cross domains in a way that AS can=E2=80= =99t > support, it returns an error. > > The syntax needs work, but it would at least allow both modes of > operation. And it collapses nicely into the single-token use case, which = is > one of my goals here. I don=E2=80=99t want a client to ask for 1 token an= d get 2 or > ask for 2 tokens and get 3, unless it=E2=80=99s fully prepared for that. > > Would something like that fly for you? > > =E2=80=94 Justin > > > On Mar 19, 2020, at 9:37 AM, Justin Richer wrote: > > > > I see what you=E2=80=99re going for here. I think the key point comes d= own to > this: > > > >> - The client knows what it wants to do and where > > > > That=E2=80=99s knowledge is exactly why I would argue that the client w= ould have > to explicitly request multiple access tokens in order to get them. > > > > I=E2=80=99m worried about requiring all clients to be prepared to accep= t > multiple access tokens. In a lot of big cloud deployments, it=E2=80=99s a= bsolutely > based on location. But that=E2=80=99s not the only dispatch for security = domains. A > client would need to know, ultimately, what a token is for and where to u= se > it. And we=E2=80=99d also need to deal with cases that allow for subdomai= ns, paths, > query parameters, and other variability of an API=E2=80=99s URLs. After a= ll, I=E2=80=99m > probably going to send that same token to a bunch of different URLs in > order to do a bunch of different things, even if they=E2=80=99re all with= in the > same =E2=80=9CRS=E2=80=9D or =E2=80=9Cdomain=E2=80=9D or whatever. Which = brings us to an underlying problem > =E2=80=94 I don=E2=80=99t think there=E2=80=99s a good way to reference t= he identity of an RS. > Solid is attempting to do that using WebID=E2=80=99s as service identifie= rs, and > while that=E2=80=99s interesting, it=E2=80=99s deeply tied to their syste= m where everything > knows what a WebID is and what to do with it. I think it=E2=80=99s a bad = idea to > depend on that kind of thing for a general purpose system. > > > > I=E2=80=99m hesitant to have clients depend on being told that informat= ion. I > think if we go down that route we=E2=80=99re going to have to also tell c= lients > things like =E2=80=9Cthis is only good for GET requests=E2=80=9D and =E2= =80=9Cthis is good for > subdomains on this location=E2=80=9D and =E2=80=9Cthis can be used for an= ything except this > one exception=E2=80=9D. And it doesn=E2=80=99t fit well when you=E2=80=99= re trying to mix two > different APIs that have really different structures. Things like GraphQL > and REST lead to pretty different URL designs, and TxAuth should be usabl= e > for all of that. It feels like too much automated configuration of a clie= nt > instead of the client just =E2=80=9Cdoing something=E2=80=9D, which I thi= nk is going to be > the common case. In other words, I do think that the client software is > going to be bespoke for the API that it=E2=80=99s calling. However, the s= ecurity > library that speaks the TxAuth piece doesn=E2=80=99t have to be, and the = protocol > itself doesn=E2=80=99t need to be. But the protocols should allow the cli= ent > software to express to the security layer what it knows about the API. > > > > And speaking of common cases, I think it=E2=80=99s actually much more r= are to > have multiple security domains covered by an AS in a way that would need > multiple encryptions or targets. I think many of us see it because we wor= k > with large enterprise-scale systems with multiple domains that we want to > manage all at once. In my experience, it=E2=80=99s much more common to ha= ve a > client talk to one AS to get one token for one RS. One of my goals with > this is to not make it complicated for simple clients, and I think having > to be prepared to get multiple access tokens is too complex for simple > clients. I might be wrong, but it=E2=80=99s based on my experience across= a lot of > different kinds of APIs. The idea of splitting up tokens like below feels > REALLY complex, especially when I asked for a single one. I get why you > want to do it, it makes sense for the AS to be able to do something like > that, but from a client=E2=80=99s perspective it=E2=80=99s a lot more com= plicated without a > clear idea of what the identity of an RS is. I think solving that problem > is a HUGE issue that we should put firmly out of scope. > > > > The thing is, though, you=E2=80=99re absolutely right that there=E2=80= =99s a need for > this kind of multiple tokens. So in my view, the lift of having a client > know about the domains that it=E2=80=99s calling is a lot less than the c= lient > having to potentially deal with more tokens than it asked for, and knowin= g > how to correctly dispatch those. Also the semantics of what the =E2=80=9C= resources=E2=80=9D > object represents changes, since I could potentially be getting two token= s > back that do parts of the one thing that I asked for, and the client now > needs to know which to use for what. If the client has to name the splits > itself, that implies the client knows what each =E2=80=9Cresources=E2=80= =9D sub-object > represents and knows how to apply that to its =E2=80=9Ccall the API=E2=80= =9D code. The > security layer doesn=E2=80=99t know or care, but the code that knows how = to > manipulate the API and its data knows and cares. > > > > As for the token content =E2=80=94 that=E2=80=99s solidly an implementa= tion decision and > orthogonal to this discussion. You can do all of this multi access token > stuff with introspection and reference-based tokens. Access tokens > themselves need to stay opaque to the client and to the protocol at large= . > I don=E2=80=99t believe that=E2=80=99s up for debate. > > > > Thanks so much for pushing this conversation, and now I=E2=80=99m more = convinced > than ever that handling multiple tokens in the response is something we > need to figure out within this group. > > > > =E2=80=94 Justin > > > >> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> > >> Hi Justin, > >> > >> thanks for explaining the different options. I=E2=80=99m well aware of= the > super refresh token (and remember the discussions back then in Taipei :-)= ), > I have implemented systems using this and other patterns, too. > >> > >> The underlying assumption for most of those patterns is that the clien= t > upfront knows the boundaries between RS security domains, which typically > means the solution is bespoken. > >> > >> TXAuth is chartered to develop a protocol and not a framework. What I= =E2=80=99m > looking for is interoperable protocol support for use of RS-specific > self-contained access tokens in multi-RS deployments. > >> > >> Why RS-specific self-contained access tokens? > >> This is in my experience the most efficient way to empower > high-volume/high-load services in a very efficient, secure, and privacy > preserving fashion. > >> > >> - Every token contains exactly the data the RS needs to perform access > control decisions locally. No need for further database lookups or AS > callbacks, that=E2=80=99s really fast and keeps cost of the AS function l= ow. > >> - The token itself can be encrypted to protect this data using a > RS-specific key, one could even use HMACs to protect integrity and > authenticity (fast as well). > >> - The token can have a RS-specific lifetime. > >> - Since every token is restricted to a single RS audience, those token= s > also have a baseline replay detection built-in. > >> > >> I think this pattern makes sense in environments with multiple RSs > (e.g. different products) as well. But since every token is minted to the > specific requirements of a certain RS, the AS must be able to mint > different tokens. That doesn=E2=80=99t work properly without some support= in the > protocol. > >> > >> Is there a need for multi access tokens support? > >> Well, you implemented it, I implemented it, and I think a couple of > other implementers did it with OAuth 2 in the past. So there seems to be > some need. Why does the rest use the single token pattern? I think some > deployments will indeed only have a single service, but I bet a lot of > implementers did it because their product does not support anything else. > >> > >> I have experienced this myself when I designed the architecture of the > yes ecosystem. It is a federation of authorization servers with associate= d > services where every AS represents a certain bank. Since our partners sha= ll > be able to implement their AS using the product they like, I needed to go > with the least common denominator - single access token. This has a > significant consequences: our tokens are basically handles, so every > service calls back to the AS to obtain its data for every service request= . > This degrades performance significantly and, since those tokens are good > for multi audiences, it forces us to generally use sender constrained > tokens, which increases complexity for clients. > >> > >> I would like to give implementers more options in the TXAuth space. > That=E2=80=99s why I advocate to build-in support f=C3=BCr multiple acces= s tokens into > TXAuth. > >> > >> My proposal is based on the following assumptions: > >> - Token format, content, encryption keys and so on are defined as part > of the interface between AS and RS > >> - The client knows what it wants to do and where > >> - Every party contributes the information it has to the overall proces= s > to make it work simply and effectively for everyone. > >> > >> There is no change/addition needed to the request syntax. All it takes > is your new multi token syntax (+ a small addition) in the response. > >> > >> The client uses the =E2=80=9Cresources" structure to communicate what = (actions, > further elements) it wants to do and where (locations). > >> > >> [ > >> { > >> =E2=80=9Cactions": ["read", "write"], > >> "locations": ["https://example.com/resource"], > >> =E2=80=9Cdata": ["foo", "bar"] > >> }, > >> { > >> =E2=80=9Cactions": ["write"], > >> "locations": ["https://other_example.com/resource"], > >> =E2=80=9Cdata": ["foo", "bar"] > >> } > >> ] > >> > >> One deployment might use a single token for all RSs, in this case the > token response remains unchanged: > >> > >> { > >> "access_token":{ > >> "value":"08ur4kahfga09u23rnkjasdf", > >> "type":"bearer" > >> } > >> } > >> > >> If the AS has the need to issue multiple access tokens, it could, for > example, use the =E2=80=9Clocations" elements to determine what tokens it= needs to > create. Such an AS then uses the multiple_access_tokens structure augment= ed > by corresponding "locations=E2=80=9D entries in the token response: > >> > >> "multiple_access_tokens":{ > >> "token_a":{ > >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >> "type":"bearer", > >> "locations":[ > >> "https://example.com/resource" > >> ] > >> }, > >> "token_b":{ > >> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > >> "type":"bearer", > >> "locations":[ > >> "https://other_example.com/resource" > >> ] > >> } > >> } > >> > >> Since the client passed the locations values in the request, it is als= o > able to determine where to use what access token. > >> > >> I think that=E2=80=99s pretty simple, especially from a client perspec= tive. > >> > >> And If the client wants to split access tokens further apart, e.g. to > obtain tokens with less privileges, it can do so using the request syntax > you defined: > >> > >> resources: { > >> token1: [{ > >> actions: ["read", "write", "dolphin"], > >> locations: ["https://server.example.net/", " > https://resource.local/other"], > >> datatypes: ["metadata", "images"] > >> }], > >> token2: [{ > >> actions: ["foo", "bar", "dolphin"], > >> locations: ["https://resource.other/"], > >> datatypes: ["data", "pictures"] > >> }] > >> } > >> > >> In the simplest case, the AS would return the data as in your proposal= . > >> > >> If the client asks for a partitioning of privileges that goes across R= S > security domains like this > >> > >> { > >> "resources":{ > >> "token1":[ > >> { > >> "actions":[ "read", "write","dolphin" ], > >> "locations":[ "https://server.example.net/"," > https://resource.local/other"], > >> "datatypes":[ "metadata","images"] > >> }, > >> { > >> "actions":["read","write"], > >> "locations":["https://example.com/resource"] > >> } > >> ], > >> "token2":[ > >> { > >> "actions":["foo","bar", "dolphin"], > >> "locations":["https://resource.other/"], > >> "datatypes":["data","pictures"] > >> } > >> ] > >> } > >> } > >> > >> the AS would need to further partition the pre-defined tokens like thi= s: > >> > >> "multiple_access_tokens=E2=80=9D:{ > >> =E2=80=9Ctoken1/a":{ > >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >> "type":"bearer", > >> "locations":["https://server.example.net/"," > https://resource.local/other"] > >> }, > >> =E2=80=9Ctoken1/b":{ > >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > >> "type":"bearer", > >> "locations":["https://example.com/resource"] > >> }, > >> =E2=80=9Ctoken2":{ > >> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > >> "type":"bearer", > >> "locations":[ > >> "https://other_example.com/resource" > >> ] > >> } > >> } > >> > >> Naming of the tokens is a bit tricky but I think solvable. > >> > >> What do you think? > >> > >> best regards, > >> Torsten. > >> > >>> On 15. Mar 2020, at 15:26, Justin Richer wrote: > >>> > >>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>> > >>>>> On 15. Mar 2020, at 03:25, Justin Richer wrote: > >>>>> > >>>>> So if the AS needs a client to get different access tokens to call > different RS domains, it does exactly what we do in OAuth 2 today =E2=80= =94 it > tells the client to get two different access tokens. > >>>> > >>>> How does this work in XYZ? > >>>> > >>> > >>> Without using the multi-access-token thing I=E2=80=99m proposing in t= his > thread, the client would just make two separate transaction calls to get > two different tokens. There=E2=80=99s a few ways that shakes out dependin= g on some > of the details. In the OAuth world that amounts to involving the user > twice, and it might be the same in XYZ if you=E2=80=99re asking for diffe= rent > things: > >>> > >>> 1. Client: Start TX-1 (R-1) > >>> 2. User: Approve R-1 > >>> 3. AS: Issue AT-1(R-1) > >>> 4. Client: Start TX-2 (R-1) > >>> 5. User: approve R-2 > >>> 6. AS: Issue AT-2(R-2) > >>> > >>> Unless you=E2=80=99re getting a super refresh token upfront and then = calling > for two downgraded access tokens later =E2=80=94 which does work, and I= =E2=80=99ve built > out systems that do exactly that. XYZ can do that trick too. > >>> > >>> 1. Client: Start TX-1 (R-1, R-2) > >>> 2. User: Approve R-1, R-2 > >>> 3. AS: Issue AT1 (R-1, R-2) > >>> 4. Client: Continue TX-1 (R-2) > >>> 5. AS: Issue AT-2 (R-2) > >>> > >>> But we=E2=80=99ve got another thing we can use in XYZ to help this, t= he user > handle. This lets a trusted client tell the AS that it believes the same > user is still there and asking the question, so if the access rights are = OK > then you don=E2=80=99t need to involve the user again. We invented this c= onstruct > with UMA2, where it=E2=80=99s called the persisted claims token (PCT). > >>> > >>> 1. Client: Start TX-1 (R-1) > >>> 2. User: Approve R-1 > >>> 3. AS: Issue AT-1 (R-1), user handle U-1 > >>> 4. Client Start TX-2 (R-2, U-1) > >>> 5. AS: Issue AT-2 (R-2) > >>> > >>> Now: With the multi-token request, we can collapse this all back to a > single transaction with multiple outputs: > >>> > >>> 1. Client: Start TX-2 (token1: R-1, token2: R-2) > >>> 2. User Approve R-1, R-2 > >>> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) > >>> > >>> I haven=E2=80=99t liked any of the multi-access-token solutions to da= te > because they make things weird for single access token requests. I like > this idea because it=E2=80=99s an optimization for a complex case that do= esn=E2=80=99t > change the behavior for the simple case, and in fact doesn=E2=80=99t even= change > the expectations for the simple case. To me, that=E2=80=99s important. > >>> > >>> =E2=80=94 Justin > >> > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000441c5e05a14d91ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Justin that the Client unexpectedly getting s= plit access tokens is undesirable.

I agree with Mike and= Torsten that tokens should be self contained, and able to be independent b= etween resources. I would add that they should be as fine grained as practi= cal, which is part of the charter.

Rather then the= client thinking=C2=A0it is getting multiple access tokens, how about think= ing of the client getting access to multiple resources?

The AS provides an access token for each resource. The access tokens = may all be the same, all be different, or a mix.

T= he Client does not need to know which ones are the same or different ahead = of time, but it does know which one it will use for accessing which resourc= e.

I don't think there is a need for a "s= plit_tokens" flag. That sounds overly complicated.






On Fri, Mar 20= , 2020 at 7:59 AM Justin Richer <jric= her@mit.edu> wrote:
So fundamentally, I don=E2=80=99t want the AS to allowed to spli= t tokens when the client isn=E2=80=99t expecting it. Would a simple feature= flag to allow that behavior at the AS be enough to switch both cases?

So let=E2=80=99s say we=C2=A0 just do the simple thing and make it a boolea= n top-level flag. If the client sends =E2=80=9Csplit_tokens: true=E2=80=9D = then the AS always returns the =E2=80=9Cmultiple_access_tokens=E2=80=9D str= ucture and it comes up with whatever names it makes sense for the resulting= tokens. The client can do either the single or multiple token request styl= e. The client needs to be able to figure out from the token responses how t= o put which token in which place, and I think we can do some things with th= e guts of the =E2=80=9Cresources=E2=80=9D request object, like using =E2=80= =9Clocations=E2=80=9D and maybe other fields. If the client doesn=E2=80=99t= send =E2=80=9Csplit_tokens: true=E2=80=9D then the AS sends a single token= for a single token request, and multiple tokens for a multiple token reque= st, exactly mapped to what the client requested in each resources block. If= the client asks for resources that cross domains in a way that AS can=E2= =80=99t support, it returns an error.

The syntax needs work, but it would at least allow both modes of operation.= And it collapses nicely into the single-token use case, which is one of my= goals here. I don=E2=80=99t want a client to ask for 1 token and get 2 or = ask for 2 tokens and get 3, unless it=E2=80=99s fully prepared for that.
Would something like that fly for you?

=C2=A0=E2=80=94 Justin

> On Mar 19, 2020, at 9:37 AM, Justin Richer <jricher@mit.edu> wrote:
>
> I see what you=E2=80=99re going for here. I think the key point comes = down to this:
>
>> - The client knows what it wants to do and where
>
> That=E2=80=99s knowledge is exactly why I would argue that the client = would have to explicitly request multiple access tokens in order to get the= m.
>
> I=E2=80=99m worried about requiring all clients to be prepared to acce= pt multiple access tokens. In a lot of big cloud deployments, it=E2=80=99s = absolutely based on location. But that=E2=80=99s not the only dispatch for = security domains. A client would need to know, ultimately, what a token is = for and where to use it. And we=E2=80=99d also need to deal with cases that= allow for subdomains, paths, query parameters, and other variability of an= API=E2=80=99s URLs. After all, I=E2=80=99m probably going to send that sam= e token to a bunch of different URLs in order to do a bunch of different th= ings, even if they=E2=80=99re all within the same =E2=80=9CRS=E2=80=9D or = =E2=80=9Cdomain=E2=80=9D or whatever. Which brings us to an underlying prob= lem =E2=80=94 I don=E2=80=99t think there=E2=80=99s a good way to reference= the identity of an RS. Solid is attempting to do that using WebID=E2=80=99= s as service identifiers, and while that=E2=80=99s interesting, it=E2=80=99= s deeply tied to their system where everything knows what a WebID is and wh= at to do with it. I think it=E2=80=99s a bad idea to depend on that kind of= thing for a general purpose system.
>
> I=E2=80=99m hesitant to have clients depend on being told that informa= tion. I think if we go down that route we=E2=80=99re going to have to also = tell clients things like =E2=80=9Cthis is only good for GET requests=E2=80= =9D and =E2=80=9Cthis is good for subdomains on this location=E2=80=9D and = =E2=80=9Cthis can be used for anything except this one exception=E2=80=9D. = And it doesn=E2=80=99t fit well when you=E2=80=99re trying to mix two diffe= rent APIs that have really different structures. Things like GraphQL and RE= ST lead to pretty different URL designs, and TxAuth should be usable for al= l of that. It feels like too much automated configuration of a client inste= ad of the client just =E2=80=9Cdoing something=E2=80=9D, which I think is g= oing to be the common case. In other words, I do think that the client soft= ware is going to be bespoke for the API that it=E2=80=99s calling. However,= the security library that speaks the TxAuth piece doesn=E2=80=99t have to = be, and the protocol itself doesn=E2=80=99t need to be. But the protocols s= hould allow the client software to express to the security layer what it kn= ows about the API.
>
> And speaking of common cases, I think it=E2=80=99s actually much more = rare to have multiple security domains covered by an AS in a way that would= need multiple encryptions or targets. I think many of us see it because we= work with large enterprise-scale systems with multiple domains that we wan= t to manage all at once. In my experience, it=E2=80=99s much more common to= have a client talk to one AS to get one token for one RS. One of my goals = with this is to not make it complicated for simple clients, and I think hav= ing to be prepared to get multiple access tokens is too complex for simple = clients. I might be wrong, but it=E2=80=99s based on my experience across a= lot of different kinds of APIs. The idea of splitting up tokens like below= feels REALLY complex, especially when I asked for a single one. I get why = you want to do it, it makes sense for the AS to be able to do something lik= e that, but from a client=E2=80=99s perspective it=E2=80=99s a lot more com= plicated without a clear idea of what the identity of an RS is. I think sol= ving that problem is a HUGE issue that we should put firmly out of scope. >
> The thing is, though, you=E2=80=99re absolutely right that there=E2=80= =99s a need for this kind of multiple tokens. So in my view, the lift of ha= ving a client know about the domains that it=E2=80=99s calling is a lot les= s than the client having to potentially deal with more tokens than it asked= for, and knowing how to correctly dispatch those. Also the semantics of wh= at the =E2=80=9Cresources=E2=80=9D object represents changes, since I could= potentially be getting two tokens back that do parts of the one thing that= I asked for, and the client now needs to know which to use for what. If th= e client has to name the splits itself, that implies the client knows what = each =E2=80=9Cresources=E2=80=9D sub-object represents and knows how to app= ly that to its =E2=80=9Ccall the API=E2=80=9D code. The security layer does= n=E2=80=99t know or care, but the code that knows how to manipulate the API= and its data knows and cares.
>
> As for the token content =E2=80=94 that=E2=80=99s solidly an implement= ation decision and orthogonal to this discussion. You can do all of this mu= lti access token stuff with introspection and reference-based tokens. Acces= s tokens themselves need to stay opaque to the client and to the protocol a= t large. I don=E2=80=99t believe that=E2=80=99s up for debate.
>
> Thanks so much for pushing this conversation, and now I=E2=80=99m more= convinced than ever that handling multiple tokens in the response is somet= hing we need to figure out within this group.
>
> =E2=80=94 Justin
>
>> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
>>
>> Hi Justin,
>>
>> thanks for explaining the different options. I=E2=80=99m well awar= e of the super refresh token (and remember the discussions back then in Tai= pei :-)), I have implemented systems using this and other patterns, too. >>
>> The underlying assumption for most of those patterns is that the c= lient upfront knows the boundaries between RS security domains, which typic= ally means the solution is bespoken.
>>
>> TXAuth is chartered to develop a protocol and not a framework. Wha= t I=E2=80=99m looking for is interoperable protocol support for use of RS-s= pecific self-contained access tokens in multi-RS deployments.
>>
>> Why RS-specific self-contained access tokens?
>> This is in my experience the most efficient way to empower high-vo= lume/high-load services in a very efficient, secure, and privacy preserving= fashion.
>>
>> - Every token contains exactly the data the RS needs to perform ac= cess control decisions locally. No need for further database lookups or AS = callbacks, that=E2=80=99s really fast and keeps cost of the AS function low= .
>> - The token itself can be encrypted to protect this data using a R= S-specific key, one could even use HMACs to protect integrity and authentic= ity (fast as well).
>> - The token can have a RS-specific lifetime.
>> - Since every token is restricted to a single RS audience, those t= okens also have a baseline replay detection built-in.
>>
>> I think this pattern makes sense in environments with multiple RSs= (e.g. different products) as well. But since every token is minted to the = specific requirements of a certain RS, the AS must be able to mint differen= t tokens. That doesn=E2=80=99t work properly without some support in the pr= otocol.
>>
>> Is there a need for multi access tokens support?
>> Well, you implemented it, I implemented it, and I think a couple o= f other implementers did it with OAuth 2 in the past. So there seems to be = some need. Why does the rest use the single token pattern? I think some dep= loyments will indeed only have a single service, but I bet a lot of impleme= nters did it because their product does not support anything else.
>>
>> I have experienced this myself when I designed the architecture of= the yes ecosystem. It is a federation of authorization servers with associ= ated services where every AS represents a certain bank. Since our partners = shall be able to implement their AS using the product they like, I needed t= o go with the least common denominator - single access token. This has a si= gnificant consequences: our tokens are basically handles, so every service = calls back to the AS to obtain its data for every service request. This deg= rades performance significantly and, since those tokens are good for multi = audiences, it forces us to generally use sender constrained tokens, which i= ncreases complexity for clients.
>>
>> I would like to give implementers more options in the TXAuth space= . That=E2=80=99s why I advocate to build-in support f=C3=BCr multiple acces= s tokens into TXAuth.
>>
>> My proposal is based on the following assumptions:
>> - Token format, content, encryption keys and so on are defined as = part of the interface between AS and RS
>> - The client knows what it wants to do and where
>> - Every party contributes the information it has to the overall pr= ocess to make it work simply and effectively for everyone.
>>
>> There is no change/addition needed to the request syntax. All it t= akes is your new multi token syntax (+ a small addition) in the response. <= br> >>
>> The client uses the =E2=80=9Cresources" structure to communic= ate what (actions, further elements) it wants to do and where (locations).<= br> >>
>> [
>>=C2=A0 =C2=A0{
>>=C2=A0 =C2=A0 =C2=A0=E2=80=9Cactions": ["read", &quo= t;write"],
>>=C2=A0 =C2=A0 =C2=A0"locations": ["https://exampl= e.com/resource"],
>>=C2=A0 =C2=A0 =C2=A0=E2=80=9Cdata": ["foo", "ba= r"]
>>=C2=A0 =C2=A0},
>>=C2=A0 =C2=A0{
>>=C2=A0 =C2=A0 =C2=A0=E2=80=9Cactions": ["write"], >>=C2=A0 =C2=A0 =C2=A0"locations": ["https://= other_example.com/resource"],
>>=C2=A0 =C2=A0 =C2=A0=E2=80=9Cdata": ["foo", "ba= r"]
>>=C2=A0 =C2=A0}
>> ]
>>
>> One deployment might use a single token for all RSs, in this case = the token response remains unchanged:
>>
>> {
>> "access_token":{
>>=C2=A0 "value":"08ur4kahfga09u23rnkjasdf",
>>=C2=A0 "type":"bearer"
>> }
>> }
>>
>> If the AS has the need to issue multiple access tokens, it could, = for example, use the =E2=80=9Clocations" elements to determine what to= kens it needs to create. Such an AS then uses the multiple_access_tokens st= ructure augmented by corresponding "locations=E2=80=9D entries in the = token response:
>>
>> "multiple_access_tokens":{
>>=C2=A0 "token_a":{
>>=C2=A0 =C2=A0 "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFO= NP219RP1LT0",
>>=C2=A0 =C2=A0 "type":"bearer",
>>=C2=A0 =C2=A0 "locations":[
>>=C2=A0 =C2=A0 =C2=A0 "https://example.com/resource"= ;
>>=C2=A0 =C2=A0 ]
>>=C2=A0 },
>>=C2=A0 "token_b":{
>>=C2=A0 =C2=A0 "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU= 71FHCARP4J1",
>>=C2=A0 =C2=A0 "type":"bearer",
>>=C2=A0 =C2=A0 "locations":[
>>=C2=A0 =C2=A0 =C2=A0 "https://other_example.com/resou= rce"
>>=C2=A0 =C2=A0 ]
>>=C2=A0 }
>> }
>>
>> Since the client passed the locations values in the request, it is= also able to determine where to use what access token.
>>
>> I think that=E2=80=99s pretty simple, especially from a client per= spective.=C2=A0
>>
>> And If the client wants to split access tokens further apart, e.g.= to obtain tokens with less privileges, it can do so using the request synt= ax you defined:
>>
>> resources: {
>>=C2=A0 token1: [{
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actions: ["read", &quo= t;write", "dolphin"],
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 locations: ["https://serv= er.example.net/", "https://resource.local/other"]= ,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datatypes: ["metadata"= , "images"]
>>=C2=A0 =C2=A0}],
>>=C2=A0 =C2=A0token2: [{
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actions: ["foo", "= ;bar", "dolphin"],
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 locations: ["https://resource= .other/"],
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datatypes: ["data", &q= uot;pictures"]
>>=C2=A0 =C2=A0}]
>> }
>>
>> In the simplest case, the AS would return the data as in your prop= osal.
>>
>> If the client asks for a partitioning of privileges that goes acro= ss RS security domains like this
>>
>> {
>> "resources":{
>>=C2=A0 "token1":[
>>=C2=A0 =C2=A0 {
>>=C2=A0 =C2=A0 =C2=A0 "actions":[ "read", "= write","dolphin" ],
>>=C2=A0 =C2=A0 =C2=A0 "locations":[ "https://server= .example.net/","https://resource.local/other"],<= br> >>=C2=A0 =C2=A0 =C2=A0 "datatypes":[ "metadata",&= quot;images"]
>>=C2=A0 =C2=A0 },
>>=C2=A0 =C2=A0 {
>>=C2=A0 =C2=A0 =C2=A0 "actions":["read","wr= ite"],
>>=C2=A0 =C2=A0 =C2=A0 "locations":["https://exampl= e.com/resource"]
>>=C2=A0 =C2=A0 }
>>=C2=A0 ],
>>=C2=A0 "token2":[
>>=C2=A0 =C2=A0 {
>>=C2=A0 =C2=A0 =C2=A0 "actions":["foo","bar= ", "dolphin"],
>>=C2=A0 =C2=A0 =C2=A0 "locations":["https://resource.ot= her/"],
>>=C2=A0 =C2=A0 =C2=A0 "datatypes":["data","= pictures"]
>>=C2=A0 =C2=A0 }
>>=C2=A0 ]
>> }
>> }
>>
>> the AS would need to further partition the pre-defined tokens like= this:
>>
>> "multiple_access_tokens=E2=80=9D:{
>>=C2=A0 =E2=80=9Ctoken1/a":{
>>=C2=A0 =C2=A0 "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFO= NP219RP1LT0",
>>=C2=A0 =C2=A0 "type":"bearer",
>>=C2=A0 =C2=A0 "locations":["https://server.example= .net/","https://resource.local/other"]
>>=C2=A0 },
>>=C2=A0 =E2=80=9Ctoken1/b":{
>>=C2=A0 =C2=A0 "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFO= NP219RP1LT0",
>>=C2=A0 =C2=A0 "type":"bearer",
>>=C2=A0 =C2=A0 "locations":["https://example.com/r= esource"]
>>=C2=A0 },
>>=C2=A0 =E2=80=9Ctoken2":{
>>=C2=A0 =C2=A0 "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU= 71FHCARP4J1",
>>=C2=A0 =C2=A0 "type":"bearer",
>>=C2=A0 =C2=A0 "locations":[
>>=C2=A0 =C2=A0 =C2=A0 "https://other_example.com/resou= rce"
>>=C2=A0 =C2=A0 ]
>>=C2=A0 }
>> }
>>
>> Naming of the tokens is a bit tricky but I think solvable.
>>
>> What do you think?
>>
>> best regards,
>> Torsten.
>>
>>> On 15. Mar 2020, at 15:26, Justin Richer <jricher@mit.edu> wrote:
>>>
>>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt <torsten@lodderstedt.n= et> wrote:
>>>>
>>>>> On 15. Mar 2020, at 03:25, Justin Richer <jricher@mit.edu> wrote= :
>>>>>
>>>>> So if the AS needs a client to get different access to= kens to call different RS domains, it does exactly what we do in OAuth 2 to= day =E2=80=94 it tells the client to get two different access tokens.
>>>>
>>>> How does this work in XYZ?
>>>>
>>>
>>> Without using the multi-access-token thing I=E2=80=99m proposi= ng in this thread, the client would just make two separate transaction call= s to get two different tokens. There=E2=80=99s a few ways that shakes out d= epending on some of the details. In the OAuth world that amounts to involvi= ng the user twice, and it might be the same in XYZ if you=E2=80=99re asking= for different things:
>>>
>>> 1. Client: Start TX-1 (R-1)
>>> 2. User: Approve R-1
>>> 3. AS: Issue AT-1(R-1)
>>> 4. Client: Start TX-2 (R-1)
>>> 5. User: approve R-2
>>> 6. AS: Issue AT-2(R-2)
>>>
>>> Unless you=E2=80=99re getting a super refresh token upfront an= d then calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can do t= hat trick too.
>>>
>>> 1. Client: Start TX-1 (R-1, R-2)
>>> 2. User: Approve R-1, R-2
>>> 3. AS: Issue AT1 (R-1, R-2)
>>> 4. Client: Continue TX-1 (R-2)
>>> 5. AS: Issue AT-2 (R-2)
>>>
>>> But we=E2=80=99ve got another thing we can use in XYZ to help = this, the user handle. This lets a trusted client tell the AS that it belie= ves the same user is still there and asking the question, so if the access = rights are OK then you don=E2=80=99t need to involve the user again. We inv= ented this construct with UMA2, where it=E2=80=99s called the persisted cla= ims token (PCT).
>>>
>>> 1. Client: Start TX-1 (R-1)
>>> 2. User: Approve R-1
>>> 3. AS: Issue AT-1 (R-1), user handle U-1
>>> 4. Client Start TX-2 (R-2, U-1)
>>> 5. AS: Issue AT-2 (R-2)
>>>
>>> Now: With the multi-token request, we can collapse this all ba= ck to a single transaction with multiple outputs:
>>>
>>> 1. Client: Start TX-2 (token1: R-1, token2: R-2)
>>> 2. User Approve R-1, R-2
>>> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2)
>>>
>>> I haven=E2=80=99t liked any of the multi-access-token solution= s to date because they make things weird for single access token requests. = I like this idea because it=E2=80=99s an optimization for a complex case th= at doesn=E2=80=99t change the behavior for the simple case, and in fact doe= sn=E2=80=99t even change the expectations for the simple case. To me, that= =E2=80=99s important.
>>>
>>> =E2=80=94 Justin
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000441c5e05a14d91ae-- From nobody Fri Mar 20 11:46:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157E13A0D5C for ; Fri, 20 Mar 2020 11:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, PDS_OTHER_BAD_TLD=1.998, 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 aBdNJ0lZ2tFB for ; Fri, 20 Mar 2020 11:45:51 -0700 (PDT) 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 CB2FD3A0D84 for ; Fri, 20 Mar 2020 11:45:50 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id s1so5380973lfd.3 for ; Fri, 20 Mar 2020 11:45:50 -0700 (PDT) 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=VxpY+edCV5F+g86xb2GLOCLOfGp7uPwvdUNcJ1aB76U=; b=k5Wu75Y/fvv5toI+PSqkEaPqrgbmBq5HXVrPN07WzLpFtaMnjX4BRxwmY+kwQGcwnP GTe1zVjhvCggJj9H5AJj3MPL4nyRireSUuDGE+w+YssUvTc0fTslRrDfcilsvmQvtrHu wcHpJlJu178qy8turluhlui5AuO8O8s6qUhu6uoVmxAJE/pXQki7OO1N5/qdXoOW9NVp 7B5kfvzXtGYD1jA4HcfS9ps7xt13s4FfFk1uWj1q2GYUGTGDEY/rRFtPVn9tsjWHMSUa zPaI4+tJitj60dUJBId0VF3gD56EaAeBy678/B+Bm7q8e07M6UzWPn015wRny2/HSoyX FlOQ== 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=VxpY+edCV5F+g86xb2GLOCLOfGp7uPwvdUNcJ1aB76U=; b=WTVXpdZMWLynpTBB76y2WGqUo7LTdfQyicxLcvWJTBabwfrJ7f+1PaqJL8Rra/MPVP zHDELGL7kvzc48A4BNNt384IqwMwRyzGYe88qPmV18xYuTr1DmFxcnxZ3uF1CPwS4FaE Vrzuo1eb3KWcLHxTHAcjvPFoj3wB1hOqb42/MQ2E6Tsbk6JujQSVNIAdsLVoKFoVvmUd +3sUOyV+9xG6mJxi6DE3HMVgPbitkGWERm426PeNwXNA/FbIIVI/Dl6lfdRWsemTNvIw 9HkjMW2eKXO1JM2OkQEfEQ/3bx7Hb1nmpQcdWyIdBN4mhGA9vpspUwRdfZ9YYWh2v3x3 O4qA== X-Gm-Message-State: ANhLgQ3ZIb1XTkjLS9QpnbcORULRUdX6xAJcZBhStzSWUBxJisEEpAXt DLK7uDMAVXbMYPbEf8S+1o5F67nfq/uEtKHj68DYi9cY X-Google-Smtp-Source: ADFU+vs5l+oJXKm1I52IUOl/Z7iOU+5xviExVzDGeYmSAzRas3tq7Jc60eg3TH4tE8FhBDFDg8/UidPwwvAwc7dukCE= X-Received: by 2002:a19:4cc2:: with SMTP id z185mr6238914lfa.0.1584729948903; Fri, 20 Mar 2020 11:45:48 -0700 (PDT) MIME-Version: 1.0 References: <6750F9C8-425E-45B1-BCE8-52674F7BCDC5@mit.edu> In-Reply-To: <6750F9C8-425E-45B1-BCE8-52674F7BCDC5@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 11:45:22 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ab5d8a05a14db13d" Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 18:46:04 -0000 --000000000000ab5d8a05a14db13d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin: How are each of the access tokens refreshed in the multiple access token scenario? On Fri, Mar 13, 2020 at 3:13 PM Justin Richer wrote: > I took some time to implement an idea that was tossed out on the list her= e > recently, and that=E2=80=99s how we might support requests and responses = for *multiple > access tokens*. I=E2=80=99ve got a method that I think works pretty well = without > getting in the way of the common, simple case of requesting a single acce= ss > token. I=E2=80=99ve implemented this in our Java implementation of XYZ an= d I=E2=80=99ve > updated the *https://oauth.xyz/ * website with more > details. I=E2=80=99ll update my ID spec text when I get a chance to refle= ct this, > but I wanted to start this discussion first. Everything in here is based = on > the XYZ protocol. > > Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is an a= rray of items: > > resources: [ > { > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/", " > https://resource.local/other"], > datatypes: ["metadata", "images"] > }, > { > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/"], > datatypes: ["data", "pictures"] > } > ] > > > This tells the AS that the client is asking for a single access token wit= h > multiple, perhaps orthogonal sets of access. This is in parallel to RAR > being developed in OAuth 2. However, if we allow the =E2=80=9Cresources= =E2=80=9D item to be > an object instead of an array, we can let the client signal to the AS tha= t > it wants multiple access tokens. The client picks =E2=80=9Clabels=E2=80= =9D for these access > tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80= =9D, and sends a request like this. > > resources: { > token1: [{ > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/", " > https://resource.local/other"], > datatypes: ["metadata", "images"] > }], > token2: [{ > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/"], > datatypes: ["data", "pictures"] > }] > } > > > The client could request multiple kinds of access within each sub-object= =E2=80=99s > array (the value of the =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2= =80=9D fields), but I wanted to keep > it simple here. This example is the same total set of resources that the > client is asking for in the first case, but here the client=E2=80=99s say= ing it > wants them as two different access tokens instead of a single one. The AS > can tell the difference in the request because the first type is an array > at the top and the second type is an object at the top. So that means tha= t > the AS can send back a single access token in a tx response like this: > > { > access_token: { > value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > type: "bearer" > } > } > > > Or multiple access tokens in a tx response like this: > > { > multiple_access_tokens: { > token1: { > value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > type: "bearer" > }, > token2: { > value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > type: "bearer" > } > } > } > > > These fields are mutually exclusive, so you either get a single unnamed > token or a set of named tokens. Since the client pics the labels for the > access tokens, it=E2=80=99s clear which part of the request maps to which= part of > the response. It=E2=80=99s more complexity for the client to track, but t= hat > complexity is only seen and borne by clients that need it. Simple clients > get to stay simple while letting a complex problem get solved. > > *A note about the polymorphic JSON *that=E2=80=99s in user here, though i= t=E2=80=99s > already a key part of XYZ=E2=80=99s protocol design. For those unfamiliar= with the > concept, this is when a given field can have a value that takes multiple > different types: a string, a boolean, an object, an array, etc. This is > pretty simple to deal with in dynamically typed languages, you just check > the type of the resulting object and it will tell you what you=E2=80=99re= dealing > with. It=E2=80=99s trickier in statically typed languages, but I=E2=80=99= ve found that > pretty much every platform and library has hooks for custom serialization > and deserialization that will let you dispatch to different types during > the process, so you can still call your top-level parser and toString > methods and things will work as expected. This is one of the reasons that= I > did an implementation in Java, to prove that we could do this kind of thi= ng > in a strongly typed language that=E2=80=99s not very flexible about what = goes in > objects, and I=E2=80=99ve done it without resorting to generic collection= s for the > dynamic fields. Previously, I=E2=80=99ve used this feature in XYZ to allo= w a single > string to stand in as a reference for an object =E2=80=94 something XYZ c= alls > =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a client= _id, a scope, a > refresh token, and a few other items without having to create explicit > elements for these, since they always stand in for the object they replac= e > there=E2=80=99s no ambiguity. So for things like a resource request, each= of these > can be replaced by a string using resource handles and polymorphic JSON > (see note below) to act like a scope in OAuth2. > > resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, =E2=80=9Cfoobar-pictur= es=E2=80=9D ] > > > Polymorphic JSON is great for things like this because it means you don= =E2=80=99t > have to have multiple fields and normative rules for mutual exclusivity, > like we=E2=80=99d have to have otherwise. The type switching only works w= hen the > base type is significantly different, though =E2=80=94 that=E2=80=99s why= I have > =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tokens=E2=80= =9D above, since both are objects > at the top level and you can=E2=80=99t cleanly switch at the parser level= , and you > don=E2=80=99t want to have to dig down into the object to see what to do = with it. > > > > People have been asking for a good way to do multiple access tokens with > OAuth for years, but we=E2=80=99ve never had a good or clean way to pull = it off > because of OAuth=E2=80=99s model and the assumptions that it makes. I thi= nk TxAuth > gives us the opportunity to solve this in a way that=E2=80=99s consistent= with the > rest of the protocol, and do so in a way that doesn=E2=80=99t make the si= mple cases > we know and love too complicated for average developers. > > =E2=80=94 Justin > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ab5d8a05a14db13d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin: How are each of the access tokens refreshed in the= multiple=C2=A0access token scenario?=C2=A0

On Fri, Mar 13, 2020 at 3:13 PM = Justin Richer <jric= her@mit.edu> wrote:
I took some time to implement an idea that was tossed out o= n the list here recently, and that=E2=80=99s how we might support requests = and responses for multiple access tokens. I=E2=80=99ve got a method = that I think works pretty well without getting in the way of the common, si= mple case of requesting a single access token. I=E2=80=99ve implemented thi= s in our Java implementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/ websit= e with more details. I=E2=80=99ll update my ID spec text when I get a chanc= e to reflect this, but I wanted to start this discussion first. Everything = in here is based on the XYZ protocol.

Normally, the =E2= =80=9Cresources=E2=80=9D element of a tx request is an array of items:

resources: [
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actions: [&q= uot;read", "write", "dolphin"],
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 locations: ["https://server.example.net/", = "https://re= source.local/other"],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 datatypes: ["metadata", "images"]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 },
= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actions: [&qu= ot;foo", "bar", "dolphin"],
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 locations: ["https://resource.other/"],
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datatypes: ["data", &qu= ot;pictures"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
]

This tells the AS that the client is aski= ng for a single access token with multiple, perhaps orthogonal sets of acce= ss. This is in parallel to RAR being developed in OAuth 2. However, if we a= llow the =E2=80=9Cresources=E2=80=9D item to be an object instead of an arr= ay, we can let the client signal to the AS that it wants multiple access to= kens. The client picks =E2=80=9Clabels=E2=80=9D for these access tokens, in= this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D, and sends= a request like this.

resources: {
=C2= =A0 =C2=A0 token1: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a= ctions: ["read", "write", "dolphin"],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 locations: ["https://server.example.net/", "= https://resource.local/other"],
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 datatypes: ["metadata", "images"]
=C2=A0 =C2=A0 =C2=A0}],
=C2=A0 =C2=A0 =C2=A0token2: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actions: ["foo",= "bar", "dolphin"],
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 locations: ["https://resource.other/"],
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 datatypes: ["data", "pictures&qu= ot;]
=C2=A0 =C2=A0 =C2=A0}]
}
<= div>
The client could request multiple kinds of access within= each sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D= and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple here.= This example is the same total set of resources that the client is asking = for in the first case, but here the client=E2=80=99s saying it wants them a= s two different access tokens instead of a single one. The AS can tell the = difference in the request because the first type is an array at the top and= the second type is an object at the top. So that means that the AS can sen= d back a single access token in a tx response like this:

{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 access_token: {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value: "OS9M2PMHKUR64TB8N6BW= 7OZB8CDFONP219RP1LT0",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 type: "bearer"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}

Or multiple access tok= ens in a tx response like this:

{
=C2=A0 =C2= =A0 multiple_access_tokens: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = token1: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value: "= OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 type: "bearer"
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 token2= : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value: "UFGLO2= FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 type: "bearer"
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
}

These fields are mutually exclusive, so you either get= a single unnamed token or a set of named tokens. Since the client pics the= labels for the access tokens, it=E2=80=99s clear which part of the request= maps to which part of the response. It=E2=80=99s more complexity for the c= lient to track, but that complexity is only seen and borne by clients that = need it. Simple clients get to stay simple while letting a complex problem = get solved.=C2=A0

A note about the polymorphic = JSON that=E2=80=99s in user here, though it=E2=80=99s already a key par= t of XYZ=E2=80=99s protocol design. For those unfamiliar with the concept, = this is when a given field can have a value that takes multiple different t= ypes: a string, a boolean, an object, an array, etc. This is pretty simple = to deal with in dynamically typed languages, you just check the type of the= resulting object and it will tell you what you=E2=80=99re dealing with. It= =E2=80=99s trickier in statically typed languages, but I=E2=80=99ve found t= hat pretty much every platform and library has hooks for custom serializati= on and deserialization that will let you dispatch to different types during= the process, so you can still call your top-level parser and toString meth= ods and things will work as expected. This is one of the reasons that I did= an implementation in Java, to prove that we could do this kind of thing in= a strongly typed language that=E2=80=99s not very flexible about what goes= in objects, and I=E2=80=99ve done it without resorting to generic collecti= ons for the dynamic fields. Previously, I=E2=80=99ve used this feature in X= YZ to allow a single string to stand in as a reference for an object =E2=80= =94 something XYZ calls =E2=80=9Chandles=E2=80=9D. These let you have const= ructs akin to a client_id, a scope, a refresh token, and a few other items = without having to create explicit elements for these, since they always sta= nd in for the object they replace there=E2=80=99s no ambiguity. So for thin= gs like a resource request, each of these can be replaced by a string using= resource handles and polymorphic JSON (see note below) to act like a scope= in OAuth2.

resources: [ =E2=80=9Cmetadata-readwrite=E2=80= =9D, =E2=80=9Cfoobar-pictures=E2=80=9D ]

Po= lymorphic JSON is great for things like this because it means you don=E2=80= =99t have to have multiple fields and normative rules for mutual exclusivit= y, like we=E2=80=99d have to have otherwise. The type switching only works = when the base type is significantly different, though =E2=80=94 that=E2=80= =99s why I have =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access= _tokens=E2=80=9D above, since both are objects at the top level and you can= =E2=80=99t cleanly switch at the parser level, and you don=E2=80=99t want t= o have to dig down into the object to see what to do with it.


People have been asking for a goo= d way to do multiple access tokens with OAuth for years, but we=E2=80=99ve = never had a good or clean way to pull it off because of OAuth=E2=80=99s mod= el and the assumptions that it makes. I think TxAuth gives us the opportuni= ty to solve this in a way that=E2=80=99s consistent with the rest of the pr= otocol, and do so in a way that doesn=E2=80=99t make the simple cases we kn= ow and love too complicated for average developers.

=C2=A0=E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ab5d8a05a14db13d-- From nobody Fri Mar 20 11:47:48 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1E3A09FA for ; Fri, 20 Mar 2020 11:47:31 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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, 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 JeSQSobmWvS5 for ; Fri, 20 Mar 2020 11:47:25 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640137.outbound.protection.outlook.com [40.107.64.137]) (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 752613A0DBE for ; Fri, 20 Mar 2020 11:47:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A4nPJWB+UPfUwodrXM+qnJuIZWLanER32+uAyba8vp4GLIDl7E9VuW+eJjvCvRjtXJ4bX8C0/YxMMEJ6VQgsJq2aUnuet3Ck7r7BsTk3FBMfbntSrfXFX7SKop0Ib4SUt0p4z3UA+kwp37ATu7iOm66n/ifCVv4BTs2nHuJ3MXNx2DnJu8ID3CsEmwZeMbNJIbbFR42hHP2v9u8kk7lrJcq4EXlw1jl7E05/8LcL0AiCrb2X0rdf1mLUlj0fbEkwVU0vHVGcFbI4pEwGwF1NK2AescedXidKZXD7uOw2GVmgcKPMYz8daNvykwZUh22zhpfNeIqiKWGJ9XbUrXtGaw== 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=/h3CGd4J9czXn0gR1ofrNiLxLO0MQde9eXOA1DMyb9M=; b=KoWKoX3Q/JivSOueckFAkAWsHxuCxa5OPlV5V9qs0yBw/ivuscbfbifGJHRP0C+Dnv6GITlJOMCL7+mugrvFFfy7DkGs+eJdY06JhZwOXTc6eoseweePBtHCImSxlT5SXIuthcnphZa0zMEqPcQKfMwNwM3LEfkZ2dwFMMLOb2nEA9N4nqnPKKKn9sTaZl3EcRmAVVmE2oFqZjFYbzLQdg0ab6Gq1l22rwPHdu3Y8/fvPtlr23fcFDQDVsTU06O6/PScp6k8jrCnm2K+Qq+rS8+nRMXNoE+U98OqmUQCBxsiILEYUSTkP1+Fx5Jyf02n8IPArHlbLF9Wj+zzq6sajw== 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=/h3CGd4J9czXn0gR1ofrNiLxLO0MQde9eXOA1DMyb9M=; b=KNPBY/gU4cJx46vTriq63IochzaJP5IzSUNiZN6AuHnDgvG+j/j0mHSj0Bndo+fOZuFtbamYex0YcdeMdFT94k2vyoAHdFF+CikpceCcZJphAGS+GdGlUsPFQiv4VYe05H7V4JEvBP/H/EJu4L8BaGOIhc/lNQTWjTXyTxwnygk= Received: from DM6PR00MB0682.namprd00.prod.outlook.com (2603:10b6:5:213::24) by DM6PR00MB0860.namprd00.prod.outlook.com (2603:10b6:5:21c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2876.0; Fri, 20 Mar 2020 18:47:22 +0000 Received: from DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1]) by DM6PR00MB0682.namprd00.prod.outlook.com ([fe80::dd11:a6cf:2334:5de1%9]) with mapi id 15.20.2880.000; Fri, 20 Mar 2020 18:47:22 +0000 From: Mike Jones To: Dick Hardt , Justin Richer CC: Yaron Sheffer , Torsten Lodderstedt , Nat Sakimura , "txauth@ietf.org" Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AdX+5/vuKMPjDtsgRce4O+0x+SlF/Q== Date: Fri, 20 Mar 2020 18:47:22 +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_ActionId=100ea457-4acb-41d8-87fa-0000b3b03873; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-20T18:37:43Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [173.160.167.177] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 064685d4-2689-4d95-c742-08d7ccff2014 x-ms-traffictypediagnostic: DM6PR00MB0860: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(199004)(54906003)(66946007)(10290500003)(9686003)(76116006)(26005)(2906002)(66476007)(33656002)(110136005)(52536014)(186003)(966005)(498600001)(4326008)(66446008)(64756008)(66556008)(55016002)(8990500004)(81156014)(81166006)(8676002)(6506007)(66574012)(5660300002)(53546011)(71200400001)(8936002)(30864003)(7696005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR00MB0860; H:DM6PR00MB0682.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mCtfbDccdcGS8dh7SabJx2oiqz/yyxYjfbLVq17e7n4jujilaxInvXt1XH59h1ZnAHru6Q/Alj1yXVJEbTTP1/7iIrUaUIVX804IaMBIH0b/u/XV+pkm6u7zPLENDy3opAQ9DDe7K7vgPeMMpnRoMmNKIg51IlTwvVmRBL3jjSTOWj0yC3sAm8PMuPWqNrYAhA3vWTXcCif1yG2bI5N46ANZUMhw65S1Dssyllr8Jo50+MSnesBkKrf19OK+GiFGxDIgj9J4+M1LW6Zo/CYYvDJTPJpHz2zzUoI4hbdIyAry3rYWWEfssV1OZ7uIyMcUN8LZWVUiDGBNM18iJcxS/IRT7YyR6kftF46Y1cH1e0eM6sEBPO+PKV0N3hOok60vUIAkYtkyzb7JsKfVEfgPDky1KtnhC+2kXOnaTXvkCWZdClw0RWaKtdeXWLVJbbfweqfV5q1svZjZWH1wJkuRmU6Umdv3LsXswm4czfsBdjv11KT/5+jV5A35sojWPgVkHWzjC4fnlhVJaE3vR+5neA== x-ms-exchange-antispam-messagedata: Uibps7h+zzUmixvCD1Nm8OIo1o/6Db35EkSbuniPsb+NQeNIvnjq1k47IjtTyCmle62pP9CaxukjMJJOFWGn/z57Cyfke3es5VsD78yKv0mgEQb9cvq+4+6skA45xMNvgL16xwKNZBl7Zh1LXyhUqg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB0682ADE62F89284C8AA5F8B6F5F50DM6PR00MB0682namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 064685d4-2689-4d95-c742-08d7ccff2014 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 18:47:22.1929 (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: RSwrDB9Nqn3FXoC0RYWebC09mKdbiJ/p48v/Wp5nFPDN9CAt1AyhodFpmAQYRaxJqSu3y7xbwKUN0mxCa3XlAg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0860 Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 18:47:45 -0000 --_000_DM6PR00MB0682ADE62F89284C8AA5F8B6F5F50DM6PR00MB0682namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIG1hbnkgb2YgdGhlIHBvaW50cyB0aGF0IERpY2sgbWFrZXMgYmVsb3cg4oCT IGVzcGVjaWFsbHkgdGhhdCB3ZSBzaG91bGQgYmUgcmV1c2luZyBleGlzdGluZyB0ZWNobm9sb2dp ZXMgd2hlcmUgYXBwbGljYWJsZSBhbmQgb25seSBpbnZlbnRpbmcgd2hlbiBkb2luZyBzbyBjcmVh dGVzIHVuaXF1ZSBuZXcgdmFsdWUuDQoNClJldXNpbmcgRXhpc3RpbmcgVGVjaG5vbG9neTogVG8g dGhlIHNwZWNpZmljIHBvaW50IGFib3V0IHJldXNpbmcgZXhpc3RpbmcgaWRlbnRpdHkgcmVwcmVz ZW50YXRpb25zLCBJIHdvdWxkIHJlcXVlc3QgdGhhdCB0aGlzIHBvaW50IGJlIGFkZGVkIHRvIHRo ZSBjaGFydGVyOg0KDQogICogICBUaGUgd29ya2luZyBncm91cCB3aWxsIG5vdCBjcmVhdGUgbmV3 IGlkZW50aXR5IHJlcHJlc2VudGF0aW9uczsgaXQgbWF5IGVuYWJsZSB0aGUgdXNlIG9mIGV4aXN0 aW5nIGlkZW50aXR5IHJlcHJlc2VudGF0aW9ucyBvciBuZXcgaWRlbnRpdHkgcmVwcmVzZW50YXRp b25zIGNyZWF0ZWQgYnkgb3RoZXJzLg0KDQpBUzwtPlJTIHJlbGF0aW9uc2hpcDogSSBiZWxpZXZl IHRoYXQgaW50cm9zcGVjdGlvbiBpcyB1bm5lY2Vzc2FyeSBmb3IgbWFueSB1c2UgY2FzZXMsIGFu ZCBpbmRlZWQsIHJlcXVpcmluZyBpdCB3b3VsZCBiZSBhIHJlZ3Jlc3Npb24gcmVsYXRpdmUgdG8g T0F1dGggMi4wLiAgVGhlcmVmb3JlLCBJIHN1cHBvcnQgRGlja+KAmXMgcHJvcG9zZWQgbW9kaWZp Y2F0aW9uOg0KDQogICogICBjb21tdW5pY2F0aW9uIG9mIHRva2VuIGF0dHJpYnV0ZXMgYmV0d2Vl biB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlcg0KDQpPQXV0aCAy LjAgc2NvcGVzOiAgSSBhZ3JlZSB0aGF0IHRoZSBleGlzdGluZyBPQXV0aCAyLjAgc2NvcGVzIHNo b3VsZCBiZSBlYXNpbHkgdXNlZCBpbiByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGlj ayBIYXJkdA0KU2VudDogRnJpZGF5LCBNYXJjaCAyMCwgMjAyMCAxMTowNCBBTQ0KVG86IEp1c3Rp biBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb20+OyBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dD47IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPjsgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+OyB0eGF1dGhAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBDYWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAtIFR4QXV0 aCBXRw0KDQpOYXQ6IHRoYW5rcyBmb3IgY2hpbWluZyBpbi4gVXNlZnVsIGluc2lnaHRzIGFzIGFs d2F5cyENCg0KVml0dG9yaW86IEknbGwgcmVpbnRlcnByZXQgeW91ciBzdGF0ZW1lbnQgYWJvdXQg Im1hcmtldGluZyIgdGhlIHdvcmssIHRvIGJlIHRoYXQgd2Ugc2hvdWxkIHNvbHZlIHJlYWwgcHJv YmxlbXMgdGhhdCBwZW9wbGUgZG9uJ3QgaGF2ZSBzb2x1dGlvbnMgZm9yIHRvZGF5Lg0KDQpBUzwt PlJTIHJlbGF0aW9uc2hpcA0KDQpUTDtEUjogSSB0aGluayB0aGUgY2hhcnRlciBtaXNzZXMgdGhl IG1hcmsgaW4gdGhlIEFTPC0+UlMgcmVsYXRpb25zaGlwIGJlaW5nIGluIHNjb3BlIGFuZCB3ZSBz aG91bGQgZXhwYW5kIGl0Lg0KDQpJbiBPQXV0aCAyLjAgKFJGQzY3NDkpbCwgdGhlIEFTIGFuZCBS UyB3ZXJlIHNlcGFyYXRlIHJvbGVzIGluIGNvbnRyYXN0IHRvIE9BdXRoIDEuMCwgYnV0IHRoZSBp bnRlcmFjdGlvbnMgLyBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIEFTIGFuZCB0aGUgUlMgd2Vy ZSBvdXQgb2Ygc2NvcGUsIGFzIHRoZSB1c2VzIGNhc2VzIGF0IHRoZSB0aW1lIGhhZCB0aGUgQVMg YW5kIFJTIG9wZXJhdGVkIGJ5IHRoZSBzYW1lIGVudGl0eS4gTmV3IHVzZSBjYXNlcyBoYXZlIGEg d2Vha2VyIGNvdXBsaW5nIGJldHdlZW4gdGhlIEFTIGFuZCBSUywgYW5kIHRvIGVuYWJsZSBpbnRl cm9wLCBleHRlbnNpb25zIGhhdmUgYmVlbiB3cml0dGVuIGZvciBUb2tlbiBJbnRyb3NwZWN0aW9u LCBhbmQgSldUIFByb2ZpbGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIC4NCg0KVGhlIFR4 QXV0aCBjaGFydGVyIGluY2x1ZGVzIGludHJvc3BlY3Rpb246DQoNCi0gUXVlcnkgb2YgdG9rZW4g cmlnaHRzIGJ5IHJlc291cmNlIHNlcnZlcnMNCg0KLS0gYnV0IGRvZXMgbm90IGluY2x1ZGUgdGhl IGNvbW1vbiBkZXNpZ24gcGF0dGVybiB3aGVyZSB0aGUgUlMgY2FuIGRpcmVjdGx5IGludGVycHJl dCB0aGUgdG9rZW4uDQoNCkhlcmUgaXMgcHJvcG9zZWQgdXBkYXRlZCB0ZXh0IHRvIHRoZSBsaW5l IGFib3ZlIHRvIGJlIGJyb2FkZXIgaW4gc2NvcGUgdGhhbiBqdXN0IGEgcXVlcnk6DQoNCi0gY29t bXVuaWNhdGlvbiBvZiB0b2tlbiBhdHRyaWJ1dGVzIGJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXINCg0KDQpBcmNoaXRlY3R1cmUgYW5kIFVzZSBDYXNl IGRvY3VtZW50cw0KDQpUTDtEUjogWWVzIHRvIHVzZSBjYXNlIGRvYywgbm8gdG8gYXJjaGl0ZWN0 dXJlIGRvYy4NCg0KSSBhZ3JlZSB3aXRoIEp1c3RpbiB0aGF0IGFuIGFyY2hpdGVjdHVyZSBkb2N1 bWVudCBpcyB1bmxpa2VseSB0byBwcm92ZSB1c2VmdWwgbG9uZyB0ZXJtLiBJIGRpc2FncmVlIHdp dGggaGltIG9uIHRoZSB1c2UgY2FzZXMuIEkgZG9uJ3QgdGhpbmsgdGhlIHVzZSBjYXNlcyBuZWVk IHRvIGJlIGV4aGF1c3RpdmUsIGJ1dCBleGFtcGxlIHVzZSBjYXNlcyBoZWxwcyBldmVyeW9uZSB1 bmRlcnN0YW5kIGV2ZXJ5b25lIGVsc2UncyBwcmltYXJ5IHVzZSBjYXNlcy4gSWYgeW91ciB1c2Ug Y2FzZSBpcyBub3Qgc2ltaWxhciB0byBvdGhlcnMsIHRoZW4geW91IHNob3VsZCB3cml0ZSBpdCB1 cCBhbmQgdGhlIFdHIGNhbiBkZWNpZGUgaWYgaXQgaXMgaW4gc2NvcGUgb3Igbm90LiBJZiBpdCBp cywgaXQgZ2V0cyBhZGRlZCB0byB0aGUgdXNlIGNhc2UgZG9jdW1lbnQuIEkgd291bGQgY29uc2lk ZXIgdGhpcyBhIGxpdmluZyBkb2N1bWVudCB3aGlsZSB3b3JraW5nIG9uIHRoZSBjb3JlIHByb3Rv Y29sLiBJdCB3b3VsZCBOT1QgYmUgYSB1c2UgY2FzZSBkb2N1bWVudCB0aGF0IHNjb3BlcyB0aGUg V0cgd29yay4gVGhlIGNoYXJ0ZXIgZG9lcyB0aGF0LiBJdCB3b3VsZCBiZSBhIGNvbXBhbmlvbiBk b2N1bWVudCB0byB0aGUgY29yZSBwcm90b2NvbC4gSSBzdHJvbmdseSB0aGluayBhIHVzZSBjYXNl IGRvY3VtZW50IHJlc29sdmVzIG1hbnkgb2YgdGhlIG1pc2NvbW11bmljYXRpb25zIHRoYXQgaGFw cGVuIHdoZXJlIHBlb3BsZSBhcmUgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIsIGJlY2F1c2UgdGhl eSBkb24ndCB1bmRlcnN0YW5kIGVhY2ggb3RoZXIncyB1c2UgY2FzZS4NCg0KUmV1c2luZyBFeGlz dGluZyBUZWNobm9sb2d5DQoNClRMO0RSOiB3ZSBzaG91bGQgYmUgcmV1c2luZyBleGlzdGluZyBz cGVjaWZpY2F0aW9ucyB3aGVyZSBldmVyIHBvc3NpYmxlLg0KDQpSZWFkaW5nIGJldHdlZW4gdGhl IGxpbmVzLCBJIHRoaW5rIHRoZSBjb25jZXJuIGFyb3VuZCBpZGVudGl0eSBtYXkgYmUgdGhhdCB0 aGUgVHhBdXRoIGNoYXJ0ZXIgaW1wbGllcyB0aGF0IHRoZSBXRyBpcyBnb2luZyB0byBjcmVhdGUg eWV0LWFub3RoZXItaWRlbnRpdHktcmVwcmVzZW50YXRpb24gYW5kIGlnbm9yZSBhbGwgdGhlIHBy ZXZpb3VzIGVmZm9ydHMuIEkgdGhpbmsgY3JlYXRpbmcgeWV0LWFub3RoZXItaWRlbnRpdHktcmVw cmVzZW50YXRpb24gdG8gc29sdmUgdXNlIGNhc2VzIHRoYXQgYXJlIGFscmVhZHkgc29sdmVkIHdp dGggZXhpc3RpbmcgcmVwcmVzZW50YXRpb25zIHdvdWxkIGJlIG1pc2d1aWRlZCBlZmZvcnQuIE15 IG93biBpbnRlcmVzdCBpbiBUeEF1dGggaXMgYmVpbmcgYWJsZSB0byB1c2Ugb25lIHByb3RvY29s IHRvIHJlcXVlc3QgYW5kIHJlY2VpdmUgYW55IGV4aXN0aW5nIGFuZCBmdXR1cmUgaWRlbnRpdHkg cmVwcmVzZW50YXRpb24uIE9uZSBvZiBteSBtb3RpdmF0aW9ucyBmb3Igd3JpdGluZyB0aGUgWEF1 dGggZG9jdW1lbnQgd2FzIHRvIHNob3cgaG93IGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgY291 bGQgYmUgcmVxdWVzdGVkIGFuZCByZWNlaXZlZCwgYXMgdGhpcyB3YXMgbWlzc2luZyBpbiBYWVou ICBJZiBhIHVzZSBjYXNlIHJlcXVpcmVzIGEgbmV3IHJlcHJlc2VudGF0aW9uLCB0aGVuIHBlcmhh cHMgVHhBdXRoIG1heSBiZSBhIHBsYWNlIGZvciB0aGF0IHdvcmsgdG8gaGFwcGVuLCBidXQgSSB0 aGluayBpdCBpcyBtb3JlIGxpa2VseSB0byBoYXBwZW4gaW4gb3RoZXIgZm9ydW1zLg0KDQpJdCBp cyBub3QgY2xlYXIgdG8gbWUgaG93LCBvciBpZiwgcmV1c2luZyBleGlzdGluZyB0ZWNobm9sb2d5 IGZpdHMgaW50byB0aGUgY2hhcnRlciwgYnV0IEkgZG8gc3Ryb25nbHkgdGhpbmsgaXQgc2hvdWxk IGJlIGEgdGVuZXQgb2YgdGhlIFdHLg0KDQpPbiBhIHJlbGF0ZWQgbm90ZSwgSSBhbHNvIHN0cm9u Z2x5IHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5nIE9BdXRoIDIuMCBzY29wZXMgc2hvdWxkIGJlIGVh c2lseSB1c2VkIGluIHJlcXVlc3RzIGFuZCByZXNwb25zZXMuIFhBdXRoIHNob3dzIGFuIGV4YW1w bGUgb2YgaG93IHRoYXQgY2FuIGJlIGRvbmUuDQoNCi9EaWNrDQoNCg0KDQoNCk9uIEZyaSwgTWFy IDIwLCAyMDIwIGF0IDY6MzkgQU0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0 bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkkgYWdyZWUgd2l0aCBhIGxvdCBvZiB0aGF0IGFy Z3VtZW50LiBMZXQgbWUgc2VlIGlmIEkgY2FuIG1vcmUgY2xlYXJseSByZXN0YXRlIHdoYXQgSSB3 YXMgdHJ5aW5nIHRvIHNheSBlYXJsaWVyIGluIHRoaXMgdGhyZWFkOiB0aGUgcmVsYXRpb25zaGlw cyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgcGFydGllcyBhcmUgc2VwYXJhYmxlIGFuZCBkZXBlbmQg b24gdGhlIGtpbmQgb2YgZGVwbG95bWVudHMgYW5kIHVzZSBjYXNlcyB0aGF0IGFyZSBiZWluZyBh ZGRyZXNzZWQgYnkgcGVvcGxlLiBTbyBpbiBhbiBPQXV0aC9PSURDLXN0eWxlIHdvcmxkLCB3ZeKA mXZlIGdvdCB0aHJlZSBjb21wb25lbnRzIChpZ25vcmluZyBwZW9wbGUpLCBhbmQgdGhyZWUgcmVs YXRpb25zaGlwcyBiZXR3ZWVuIHRoZW06DQoNCkM8LT5BUw0KDQpDPC0+UlMNCg0KQVM8LT5SUw0K DQpGb3IgYXV0aG9yaXphdGlvbiwgdGhlc2UgbWFwIHRvIOKAnGhvdyB0byBnZXQgYSB0b2tlbuKA nSwg4oCcaG93IHRvIHVzZSBhIHRva2Vu4oCdLCBhbmQg4oCcaG93IHRvIGludGVycHJldCBhIHRv a2Vu4oCdLiBGb3IgYXV0aGVudGljYXRpb24sIGl04oCZcyBhZGRpdGlvbmFsbHkg4oCcaG93IGRv IEkgZ2V0IHRoZSBhdXRoZW50aWNhdGlvbiBpbmZv4oCdLCDigJxob3cgZG8gSSBhc2sgZm9yIGEg cHJvZmlsZeKAnSwgYW5kIOKAnGhvdyBkbyBJIGtub3cgd2hvc2UgcHJvZmlsZSB0aGlzIGlz4oCd LiBJIHN0aWxsIGJlbGlldmUgdGhpcyBpcyBhIGdvb2Qgc2VwYXJhdGlvbiBvZiBjb25jZXJucy4g VGhlIGNsaWVudCBkb2VzbuKAmXQgbmVlZCB0byBrbm93IHdoYXTigJlzIGluIHRoZSBhY2Nlc3Mg dG9rZW4sIG9yIGlmIGl04oCZcyBhIHJlZmVyZW5jZSBvciBzZWxmLWNvbnRhaW5lZCwgb3IgcmVh bGx5IGNvbmNlcm4gaXRzZWxmIGF0IGFsbCB3aXRoIHdoYXQgdGhlIFJTIGRvZXMgd2l0aCBpdC4g QXJlIHRoZXJlIG92ZXJsYXBzPyBDZXJ0YWlubHkg4oCUIHRoZSBjbGllbnQgbmVlZHMgdG8ga25v dyBob3cgdG8gYXNrIGZvciBhIHRva2VuIHRoYXQgdGhlIFJTIHdpbGwgYWNjZXB0IGZvciB3aGF0 IHRoZSBjbGllbnQgaXMgZ29pbmcgdG8gZG8sIGFuZCB0byBkbyB0aGF0IHRoZSBjbGllbnQgbmVl ZHMgdG8gYmUgYWJsZSB0byBkZXNjcmliZSB3aGF0IGl0IHdhbnRzIHRvIGRvIGluIGEgd2F5IHRo YXQgdGhlIEFTIGNhbiBpbnRlcnByZXQgYW5kIG1hcCB0byBhIHNldCBvZiByaWdodHMgdGhhdCB0 aGUgUlMgd2lsbCBldmVudHVhbGx5IGludGVycHJldC4NCg0KSSBiZWxpZXZlIHRoZSBwcm9wb3Nl ZCBjaGFydGVyIGFscmVhZHkgY292ZXJzIHRoaXMgc3BsaXQgd2l0aCB0aGUgZm9sbG93aW5nIGl0 ZW1zOg0KDQotIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIGFjY2Vzcw0KLSBBcHByb3Zh bCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBBUElzIGluIGEgc2luZ2xlIGlu dGVyYWN0aW9uDQotIFNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcGFydHkgYXV0aG9yaXppbmcgYWNj ZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZSBjbGllbnQgcmVxdWVzdGluZyBhY2Nlc3MN Ci0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zDQotIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0cyBi eSByZXNvdXJjZSBzZXJ2ZXJzDQoNCkl04oCZcyB0aGUgY29tYmluYXRpb24gb2YgdGhlIHJpY2gg cmVxdWVzdCBhbmQgdGhlIGxpZmVjeWNsZSBtYW5hZ2VtZW50IHRoYXQgcHV0cyB0aGUgQVMgYW5k IFJTIGluIHNjb3BlLiBJIHRoaW5rIHRoaW5ncyBsaWtlIGRlY2xhcmluZyBhIHNpbmdsZSB0b2tl biBmb3JtYXQgYXJlIGFic29sdXRlbHkgb3V0IOKAlCBpZiB5b3Ugd2FudCB0byB1c2UgSldULCBv ciBDV1QsIG9yIFVVSUTigJlzLCB0aGF04oCZcyBhbGwganVzdCBmaW5lLiBIb3dldmVyLCBzb21l dGhpbmcgdGhhdCBJIHRoaW5rIGlzIGluIHNjb3BlIGlzIGRlZmluaW5nIGEgc3RydWN0dXJlIGZv ciB3aGF0IGEgdG9rZW4gcmVwcmVzZW50cy4gQW5kIEkgdGhpbmsgdGhhdCBpZiB3ZSBjYW4gZG8g dGhhdCBpbiB0aGlzIFdHIGluIGEgZ2VuZXJhbCB3YXksIHRoZW4gdGhhdOKAmXMgdXNlZnVsLiBC ZWNhdXNlIHRoZW4gdGhhdCBzdHJ1Y3R1cmUgY2FuIGJlIHJlcHJlc2VudGVkIGJ5IG1hcHBpbmcg dG8gYSB0b2tlbiBmb3JtYXQgb3IgYW4gaW50cm9zcGVjdGlvbiByZXNwb25zZSBvciBhIGRhdGFi YXNlIGVudHJ5LiBJIHRoaW5rIE5hdOKAmXMgY29tbWVudHMgb24gQUJBQyBhcmUgaW1wb3J0YW50 OiB3ZSBhcmUgZ29pbmcgdG8gbmVlZCBhIHBsYWNlIHRvIHB1dCB0aG9zZSBhdHRyaWJ1dGVzLiBX aGV0aGVyIHRoZXnigJlyZSBjb21tdW5pY2F0ZWQgdG8gdGhlIFJTIHRocm91Z2ggdGhlIHRva2Vu IGl0c2VsZiBvciB0aHJvdWdoIHNvbWUgb3RoZXIgY2hhbm5lbCBpcywgSSBzdHJvbmdseSBiZWxp ZXZlLCBhIG1hdHRlciBvZiBkZXBsb3ltZW50IGNob2ljZS4NCg0KU28sIHdoYXQgY2FuIHRoZSBj aGFydGVyIHNheSB0byBtYWtlIHRoaXMgbW9yZSBjbGVhcj8NCg0KQWxsIHRoYXQgc2FpZCwgSeKA mW0gYWdhaW5zdCBoYXZpbmcgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGFzIGEgd29ya2luZyBn cm91cCBvdXRwdXQuIEluIG15IGV4cGVyaWVuY2UsIHdoZW4gYSBXRyBwdXRzIGl0cyBlZmZvcnQg aW50byBhIGZvcm1hbCBhcmNoaXRlY3R1cmUgZG9jIGFzIGEgZGVsaXZlcmFibGUsIHRoZXJlIGlz IGEgbG90IG9mIGNvbmplY3R1cmFsIGVuZXJneSB0aGF0IGdvZXMgaW50byB3aGF0IG1pZ2h0IGJl IGEgZ29vZCBpZGVhLCBhbmQgdGhlbiBub3QgYWxsIG9mIGl0IHdvcmtzIG91dCB3aGVuIHlvdSB0 cnkgdG8gaGFtbWVyIHRoZSBkZXRhaWxzIG9mIG1ha2luZyB0aGF0IGFyY2hpdGVjdHVyZSBpbnRv IGEgcmVhbCBlbmdpbmVlcmVkIHRoaW5nLllvdSBlbmQgdXAgYmFraW5nIGluIGFzc3VtcHRpb25z IGFuZCBhYnN0cmFjdGlvbnMgdGhhdCBkb27igJl0IG1ha2Ugc2Vuc2UgYW55bW9yZSwgYW5kIHRo ZW4gdHJ5aW5nIHRvIGVuZ2luZWVyIHNvbHV0aW9ucyBhcm91bmQgdGhvc2Ugd2hlbiB0aGV5IGRv buKAmXQgZml0IHJpZ2h0LiBJZiB0aGUgYXJjaGl0ZWN0dXJlIGNhbuKAmXQgY2hhbmdlIGluIGxp Z2h0IG9mIG5ldyBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgdGhlIGNhc2Ugd2l0aCBhbiBSRkMsIHRo ZW4gaXQgYmVjb21lcyBhIHNoYWNrbGUgaW5zdGVhZCBvZiBhIHNjYWZmb2xkLiBCdXQgYSBtYWxs ZWFibGUgZG9jdW1lbnQgdGhhdCB0aGUgZ3JvdXAgY2FuIHVzZSBhcyBhIGd1aWRlIHdoaWxlIGVu Z2luZWVyaW5nIHRoZSBhY3R1YWwgcGFydHMg4oCUIHllcywgdGhhdCBtYWtlcyBzZW5zZS4gVGhl IGFyY2hpdGVjdHVyZSBjYW4gYmUgcmVmYWN0b3JlZCBhbmQgY2hhbmdlZCBhcyBkZWNpc2lvbnMg YXJlIG1hZGUgYW5kIHRoaW5ncyBjb21lIGludG8gZm9jdXMuIEkgZmVlbCB0aGUgc2FtZSBhYm91 dCB1c2UgY2FzZSBkb2N1bWVudHMgYXMgZm9ybWFsIGFydGlmYWN0cy4NCg0KVGhhbmtzLCBOYXQu DQog4oCUIEp1c3Rpbg0KDQoNCk9uIE1hciAyMCwgMjAyMCwgYXQgMjoxOSBBTSwgTmF0IFNha2lt dXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3Rl Og0KDQpJIHRob3VnaHQgSSBzaG91bGQga2VlcCBteSBtb3V0aCBzaHV0IGFzIGFueXRoaW5nIEkg c2F5IG1heSBiZSBkZWVtZWQgYmlhc2VkIGFzIG15IG90aGVyIGhhdCBpcyB0aGUgY2hhaXJtYW4g b2YgT0lERiwgYnV0IGhlcmUgaXMgbXkgMmMuDQoNCkFzIFRvcnN0ZW4gaW5kaWNhdGVkLCB0aGVy ZSBpcyBtdWNoIHRvIGJlIGRlc2lyZWQgdG8gc3RhbmRhcmRpemUgdGhlIEFTIC0gUlMgY29tbXVu aWNhdGlvbiBwYXR0ZXJucy4gWW91IG1heSBzYXkgdGhhdCB0aGUgY2hhcnRlciBpbmNsdWRlcyBp dCwgYnV0IEkgY2Fubm90IHJlYWQgaXQgb3V0IG9mIHRoZSBjaGFydGVyIGp1c3QgbGlrZSBUb3Jz dGVuIGNvdWxkIG5vdC4gQXMgYSBuZXcgcHJvdG9jb2wsIGl0IHdvdWxkIGJlIGdvb2QgdG8gaW5j bHVkZSBpdC4NCg0KSW4gdGhpcyByZXNwZWN0LCBJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBz dGFydCBvZmYgZnJvbSBPQXV0aCAyLjAgYW5kIE9JREMgbW9kZWwuIElmIHdlIGFyZSBjcmVhdGlu ZyBhIG5ldyBwcm90b2NvbCwgSSBmZWVsIHRoYXQgd2Ugc2hvdWxkIGFyY2hpdGVjdCBpcyBtb3Jl IGZ1bGx5LiBOb3QgbWVudGlvbmluZyBBUyAtIFJTIHJlbGF0aW9uc2hpcCB0byBtZSBmZWVscyBs aWtlIGFuIGluZGljYXRpb24gb2YgdGhpcyBmYWlsdXJlLiBGb3IgdGhhdCBtYXR0ZXIsIEkgZmVl bCB0aGF0IHRoZSBmaXJzdCBvdXRwdXQgb2YgdGhlIGdyb3VwIHNob3VsZCBiZSBhbiBhcmNoaXRl Y3R1cmUgZG9jdW1lbnQgdGhhdCB0YWtlcyB0aGUgY29uY2VybnMgZnJvbSBhbGwgdGhlIHJlbGV2 YW50IHN0YWtlaG9sZGVycy9hY3RvcnMgaW4uDQoNCldlIHNob3VsZCBhbHNvIGJlIGNvZ25pemFu dCBvZiB0aGUgYWNjZXNzIGNvbnRyb2wgbW9kZWxzIGxpa2UgQUJBQy4gRm9yIHRoYXQsIGRlY291 cGxpbmcgb2YgaWRlbnRpdHkgKD0gc2V0IG9mIGNsYWltcykgYXNzZXJ0aW9uIGFuZCBhdXRob3Jp emF0aW9uIGlzIGEgbmVjZXNzaXR5LiBXZSBjb3VsZCBvcHRpbWl6ZSBpdCBidXQgdGhlIGJhc2Ug Y2FzZSBzaG91bGQgdGFrZSBjYXJlIG9mIGl0LiAoSW4gdGhpcyByZXNwZWN0LCBJIGFtIGZlZWxp bmcgdGhhdCBPSURDIGhhcyBwZXJoYXBzIG92ZXItb3B0aW1pemVkLikgU28sIEkgZmVlbCB0aGF0 IGF0IGxlYXN0IGFzIHRoZSBmaXJzdCBzdGVwLCBUeEF1dGggc2hvdWxkIGNvbmNlbnRyZSBvbiB0 aGUgQWNjZXNzIENvbnRyb2wuIElmIEkgd2VyZSB0byBnbyBvbmUgc3RlcCBmdXJ0aGVyLCBpdCBz aG91bGQgYmUgbW9kZWxsZWQgc28gdGhhdCBpdCBjYW4gY29uc3VtZSB2YXJpb3VzIGlkZW50aXR5 IGFzc2VydGlvbnMgKGF1dGhlbnRpY2F0ZWQgaWRlbnRpdHkgaW4gSVNPL0lFQyAyNDc2MCBzcGVh aykgaW5jbHVkaW5nIElEIFRva2VuLCBTQU1MIEFzc2VydGlvbiwgRElEIFZlcmlmaWFibGUgQ3Jl ZGVudGlhbHMsIFguNTA5IGNlcnRpZmljYXRlcyAoc3VjaCBhcyBpbiBlSURBUyBhbmQgSmFwYW5l c2UgTmF0aW9uYWwgSUQgc2NoZW1lKSAgZXRjLiBXZSBhcmUgbm90IGdvaW5nIHRvIGdldCB0byBh IHVuaWZpZWQgaWRlbnRpdHkgd29ybGQgYW55dGltZSBzb29uLg0KDQpDaGVlcnMsDQoNCk5hdCBT YWtpbXVyYQ0KDQoNCk9uIFdlZCwgTWFyIDE4LCAyMDIwIGF0IDc6MDYgQU0gTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSSBiZWxpZXZlIGl0J3Mgc2lnbmlm aWNhbnQgdGhhdCBmb3VyIHBlb3BsZSBoYXZlIGV4cHJlc3NlZCBjb25jZXJucyB3aXRoIGluY2x1 ZGluZyBkaWdpdGFsIGlkZW50aXR5IGluIHRoZSBjaGFydGVyICh0aGUgb25seSBjb25jZXJucyB2 b2ljZWQgYXMgZmFyIGFzIEkgY2FuIHRlbGwpLiAgQXQgYSBtaW5pbXVtLCBJIGJlbGlldmUgdGhh dCB0aGF0IHdhcnJhbnRzIG1ha2luZyB0aGUgaW5jbHVzaW9uIG9yIGV4Y2x1c2lvbiBvZiBkaWdp dGFsIGlkZW50aXR5IGEgZGlzY3Vzc2lvbiB0b3BpYyBkdXJpbmcgdGhlIHVwY29taW5nIHZpcnR1 YWwgQm9GLCBiZWZvcmUgYWRvcHRpbmcgYW55IGNoYXJ0ZXIuDQoNCkl0IHdvdWxkIGJlIG15IHBy b3Bvc2FsIHRvIGluaXRpYWxseSBjaGFydGVyIHdpdGhvdXQgZGlnaXRhbCBpZGVudGl0eSBhbmQg c2VlIGhvdyBmYXIgd2UgZ2V0IHdpdGggb3VyIGVuZXJnaWVzIGludGVudGlvbmFsbHkgZm9jdXNl ZCBpbiB0aGF0IHdheS4gIElmIHRoZSB3b3JraW5nIGdyb3VwIGRlY2lkZXMgdG8gcmVjaGFydGVy IHRvIGluY2x1ZGUgZGlnaXRhbCBpZGVudGl0eSwgdGhhdCBjYW4gYWx3YXlzIGhhcHBlbiBsYXRl ciwgYWZ0ZXIgdGhlIGF1dGhvcml6YXRpb24tZm9jdXNlZCB3b3JrIGhhcyBtYXR1cmVkLCBhbmQg b25jZSB0aGVyZSdzIGEgY2xlYXIgY2FzZSB0byBhY3R1YWxseSBkbyBzby4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJA bWl0LmVkdT4+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxNywgMjAyMCAyOjIwIFBNDQpUbzogTWlr ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNv bTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj47IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+OyB0 eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVHhh dXRoXSBDYWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAtIFR4QXV0aCBXRw0KDQpXaGlsZSBJIHVu ZGVyc3RhbmQgdGhlIGNvbmNlcm5zIGFyb3VuZCBpZGVudGl0eSBpbiB0aGUgY2hhcnRlciwgYW5k IEkgaGFkIGluaXRpYWxseSBub3QgaW5jbHVkZWQgaXQsIEkgd2FzIGNvbnZpbmNlZCB0aGF0IHRo ZSBraW5kIG9mIGlkZW50aXR5IHByb3RvY29sIHRoYXQgd2XigJlyZSBsb29raW5nIGF0IGhlcmUg aXMgYSBtaW5vciBhZGRpdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbiBhbmQgZGVsZWdhdGlvbiBl bmQgb2YgdGhpbmdzLg0KDQpBcyB5b3Uga25vdywgbXVjaCBvZiB3aGF04oCZcyBpbiBPSURDIGlz IHRoZXJlIHRvIGZpeCBwcm9ibGVtcyB3aXRoIE9BdXRoIDIgd2hlbiBpdOKAmXMgdXNlZCBmb3Ig aWRlbnRpdHkuIElmIE9BdXRoIDIgaGFkIHNvbHZlZCB0aG9zZSBwcm9ibGVtcyBpbnRlcm5hbGx5 LCB0aGVuIE9JREMgd291bGQgYmUgbXVjaCwgbXVjaCBzaW1wbGVyIGFuZCBzbWFsbGVyLiBXZeKA mXJlIG5vdyBzdGFydGluZyBhdCBhIGJhc2Ugd2hlcmUgdGhvc2UgcHJvYmxlbXMgZG9u4oCZdCBl eGlzdCwgYnV0IHdlIGRvbuKAmXQgeWV0IGtub3cgd2hhdCBvdGhlciBwcm9ibGVtcyB0aGVyZSBt aWdodCBiZS4NCg0KVGhlIG1hcmtldCBoYXMgc2hvd24gdXMgdGhhdCB0aGUgbW9zdCBjb21tb24g YXBwbGljYXRpb24gb2YgT0F1dGggMiBpcyBmYXIgYW5kIGF3YXkgYWNjZXNzIHRvIGlkZW50aXR5 IGluZm9ybWF0aW9uIGFsb25nIHNpZGUgYWNjZXNzIHRvIGFuIEFQSS4gSSB0aGluayB3ZSBuZWVk IHRvIHBheSBhdHRlbnRpb24gdG8gdGhhdCBhbmQgbm90IG1ha2UgdGhpcyBzZXBhcmF0ZSBqdXN0 IGJlY2F1c2Ugd2UgZGlkIGl0IHRoYXQgd2F5IGJlZm9yZS4gQW5kIHNvbWUgb2YgdGhlIHByb3Bv c2VkIGlubm92YXRpb25zLCBpbmNsdWRpbmcgZ2V0dGluZyBhbmQgc2VuZGluZyBWQ+KAmXMsIGFy ZSBhbGwgYWJvdXQgaWRlbnRpdHkuDQoNCkZ1cnRoZXJtb3JlLCB0aGlzIGNoYXJ0ZXIgZG9lcyBu b3Qgc3BlY2lmeSB0aGUgZG9jdW1lbnQgYW5kIHNwZWNpZmljYXRpb24gc3RydWN0dXJlIG9mIHRo ZSBjb21wb25lbnRzLCBub3IgZG9lcyBpdCBzcGVjaWZ5IHRoZSBwdWJsaWNhdGlvbiBvcmRlciBv ciB0aW1pbmcgb2YgYW55IGRvY3VtZW50cy4gSSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgdGhlIGlk ZW50aXR5IGxheWVyIHNob3VsZCBiZSBzZXBhcmFibGUgdG8gYW4gZXh0ZW50LCB0byB0aGUgcG9p bnQgb2YgcHVibGlzaGluZyB0aGF0IGxheWVyIGluIGl0cyBvd24gc3BlYyBhbG9uZ3NpZGUgdGhl IGNvcmUgYXV0aG9yaXphdGlvbiBkZWxlZ2F0aW9uIHN5c3RlbS4gSG93ZXZlciwgdGhhdCBkb2Vz IG5vdCBtZWFuIHRoYXQgaXQgc2hvdWxkIGJlIGRldmVsb3BlZCBlbHNld2hlcmUuDQoNCklmIHRo ZXJlIGlzIGJldHRlciBsYW5ndWFnZSB0byB0aWdodGVuIHRoZSBhc3BlY3RzIG9mIGFuIGlkZW50 aXR5IHByb3RvY29sIHRoYXQgd2Ugd2lsbCBleHBsaWNpdGx5IGNvdmVyLCB0aGVuIEkgd291bGQg d2VsY29tZSB5b3UgdG8gc3VnZ2VzdCBhbiBhbWVuZGVkIHRleHQgdG8gdGhlIGNoYXJ0ZXIuIEhv d2V2ZXIsIEkgYmVsaWV2ZSB0aGVyZSBpcyBlbm91Z2ggaW50ZXJlc3Qgd2l0aGluIHRoZSBjb21t dW5pdHkgdG8gd29yayBvbiBpZGVudGl0eSBpbiB0aGUgY29udGV4dCBvZiB0aGlzIHByb3RvY29s LCBpbmNsdWRpbmcgYSBsYXJnZSBudW1iZXIgb2YgcGVvcGxlIGJlaW5nIE9LIHdpdGggaXQgaW4g dGhlIGNoYXJ0ZXIsIHRoYXQgaXQgd291bGQgbm90IGJlIGEgcmVhc29uYWJsZSB0aGluZyB0byBy ZW1vdmUgaXQuDQoNCiDigJQgSnVzdGluDQoNCj4gT24gTWFyIDE3LCAyMDIwLCBhdCAxOjEyIFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y ZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+DQo+IDEu ICBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2Yg dGhpcyBlbWFpbD8gIE9yIGRvIHlvdSBoYXZlIG1ham9yIG9iamVjdGlvbnMsIGJsb2NraW5nIGNv bmNlcm5zIG9yIGZlZWRiYWNrIChpZiBzbyBwbGVhc2UgZWxhYm9yYXRlKT8NCj4NCj4gSSBzaGFy ZSB0aGUgY29uY2VybnMgYWJvdXQgaW5jbHVkaW5nIGlkZW50aXR5IGluIHRoZSBjaGFydGVyIHRo YXQgd2VyZSBleHByZXNzZWQgYnkgVG9yc3RlbiBhbmQgYWdyZWVkIHdpdGggYnkgRGF2aWQgU2th aWZlLiAgSSdsbCBub3RlIHRoYXQgS2ltIENhbWVyb24gcHJldmlvdXNseSBleHByZXNzZWQgY29u Y2VybnMgYWJvdXQgaW5jbHVkaW5nIGlkZW50aXR5IGluIGhpcyBlYXJsaWVyIGNoYXJ0ZXIgY3Jp dGlxdWUgYXQgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90eGF1dGgvdUw5 Mk9fVms1bTM4RGNhY1hTbnNoWDJDYWhFLy4NCj4NCj4gSSdtIGZpbmUgd2l0aCByZWZhY3Rvcmlu ZyB0aGUgYXV0aG9yaXphdGlvbiBwcm90b2NvbC4gIEJ1dCBpZGVudGl0eSBzaG91bGQgYmUgZGVj b3VwbGVkIGZyb20gdGhlIFR4QXV0aCB3b3JrIHRvIGZvY3VzIGl0cyBzY29wZSBvbiBhcmVhcyB3 aGVyZSBpbm5vdmF0aW9uIGlzIGJlaW5nIHByb3Bvc2VkLiAgRGlnaXRhbCBpZGVudGl0eSBjYW4g YWx3YXlzIGJlIGFkZGVkIGFzIGEgbGF5ZXIgaWYgbmVlZGVkLCBqdXN0IGFzIE9wZW5JRCBDb25u ZWN0IGxheWVyZWQgaWRlbnRpdHkgb250byBPQXV0aCAyLjAuDQo+DQo+IFBsZWFzZSByZXZpc2Ug dGhlIGNoYXJ0ZXIgdG8gcmVtb3ZlIGRpZ2l0YWwgaWRlbnRpdHkgZnJvbSB0aGUgc2NvcGUgb2Yg dGhlIHdvcmsuDQo+DQo+IDIuICBBcmUgeW91IHdpbGxpbmcgdG8gYXV0aG9yIG9yIHBhcnRpY2lw YXRlIGluIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQo+DQo+IFll cw0KPg0KPiAzLiAgQXJlIHlvdSB3aWxsaW5nIHRvIGhlbHAgcmV2aWV3IHRoZSBkcmFmdHMgb2Yg dGhpcyBXRz8NCj4NCj4gWWVzDQo+DQo+IDQuICBBcmUgeW91IGludGVyZXN0ZWQgaW4gaW1wbGVt ZW50aW5nIGRyYWZ0cyBvZiB0aGlzIFdHPw0KPg0KPiBOb3QgYXQgdGhpcyB0aW1lLg0KPg0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+DQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVy c3RlZHQNCj4gU2VudDogU2F0dXJkYXksIE1hcmNoIDcsIDIwMjAgNzoxOCBBTQ0KPiBUbzogWWFy b24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFp bC5jb20+Pg0KPiBDYzogdHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+DQo+ IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIENhbGwgZm9yIGNoYXJ0ZXIgY29uc2Vu c3VzIC0gVHhBdXRoIFdHDQo+DQo+IEhpLA0KPg0KPj4gQW0gMDYuMDMuMjAyMCB1bSAxNzo0NSBz Y2hyaWViIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25m LmlldGZAZ21haWwuY29tPj46DQo+Pg0KPj4g77u/SGkgRXZlcnlvbmUsDQo+Pg0KPj4gSXQgYXBw ZWFycyB0aGF0IG1vbWVudHVtIGlzIGZvcm1pbmcgYXJvdW5kIHRoZSBwcm9wb3NlZCBmb3JtYXRp b24gb2YgYSBUeEF1dGggd29ya2luZyBncm91cC4gIFdl4oCZZCBsaWtlIHRvIG1vcmUgZm9ybWFs bHkgZ2F1Z2UgaW50ZXJlc3QgaW4gcHJvY2VlZGluZyB3aXRoIHRoaXMgd29yay4gIFBsZWFzZSBk byBzbyBieSByZXNwb25kaW5nIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KPj4NCj4+IDEu ICBEbyB5b3Ugc3VwcG9ydCB0aGUgY2hhcnRlciB0ZXh0IHByb3ZpZGVkIGF0IHRoZSBlbmQgb2Yg dGhpcyBlbWFpbD8gIE9yIGRvIHlvdSBoYXZlIG1ham9yIG9iamVjdGlvbnMsIGJsb2NraW5nIGNv bmNlcm5zIG9yIGZlZWRiYWNrIChpZiBzbyBwbGVhc2UgZWxhYm9yYXRlKT8NCj4NCj4gSeKAmG0g aW4gYWx0aG91Z2ggSSBoYXZlIHRvIGFkbWl0IEnigJhtIHNsaWdodGx5IGNvbmNlcm5lZCB0aGUg c2NvcGUgb2YgdGhlIGNoYXJ0ZXIgaXMgdG9vIGJyb2FkLCBlLmcuIGlkZW50aWZ5IGFsb25lIGlz IGEgaHVnZSB0b3BpYy4uDQo+DQo+IFdlIG5lZWQgdG8ga2VlcCBhbiBleWUgb24gdGhpcyBhc3Bl Y3QgaW4gb3JkZXIgdG8gbWFrZSBzdXJlLCB0aGUgZ3JvdXAgaXMgYWJsZSB0byB3b3JrIGVmZmVj dGl2ZWx5IGFuZCB0aGUgc3BlY3Mgd2Ugd2lsbCBiZSBwcm9kdWNpbmcgYXJlIGFzIHNpbXBsZSBh cyBwb3NzaWJsZSBhbmQgZm9zdGVyIGludGVyb3BlcmFiaWxpdHkuDQo+DQo+Pg0KPj4gMi4gIEFy ZSB5b3Ugd2lsbGluZyB0byBhdXRob3Igb3IgcGFydGljaXBhdGUgaW4gdGhlIGRldmVsb3BtZW50 IG9mIHRoZSBkcmFmdHMgb2YgdGhpcyBXRz8NCj4NCj4geWVzDQo+DQo+Pg0KPj4gMy4gIEFyZSB5 b3Ugd2lsbGluZyB0byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/DQo+DQo+IHll cw0KPg0KPj4NCj4+IDQuICBBcmUgeW91IGludGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIGRyYWZ0 cyBvZiB0aGlzIFdHPw0KPg0KPiB5ZXMNCj4NCj4gYmVzdCByZWdhcmRzLA0KPiBUb3JzdGVuLg0K Pg0KPj4NCj4+IFRoZSBjYWxsIHdpbGwgcnVuIGZvciB0d28gd2Vla3MsIHVudGlsIE1hcmNoIDIx LiBJZiB5b3UgdGhpbmsgdGhhdCB0aGUgY2hhcnRlciBzaG91bGQgYmUgYW1lbmRlZCBJbiBhIHNp Z25pZmljYW50IHdheSwgcGxlYXNlIHJlcGx5IG9uIGEgc2VwYXJhdGUgdGhyZWFkLg0KPj4NCj4+ IFRoZSBmZWVkYmFjayBwcm92aWRlZCBoZXJlIHdpbGwgaGVscCB0aGUgSUVTRyBjb21lIHRvIGEg ZGVjaXNpb24gb24gdGhlIGZvcm1hdGlvbiBvZiBhIG5ldyBXRy4gR2l2ZW4gdGhlIGNvbnN0cmFp bnRzIG9mIHRoZSBjaGFydGVyaW5nIHByb2Nlc3MsIHJlZ2FyZGxlc3Mgb2YgdGhlIG91dGNvbWUg b2YgdGhpcyBjb25zZW5zdXMgY2FsbCwgd2Ugd2lsbCBiZSBtZWV0aW5nIGluIFZhbmNvdXZlciBh cyBhIEJvRi4NCj4+DQo+PiBUaGFua3MsDQo+PiBZYXJvbiBhbmQgRGljaw0KPj4NCj4+IC0tLSBD aGFydGVyIFRleHQgRm9sbG93cyAtLS0NCj4+DQo+PiBUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6 YXRpb24sIGlkZW50aXR5LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93 IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdh cmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0 aGUgdXNlcyBjYXNlcyBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklE IENvbm5lY3QgKGl0c2VsZiBhbiBleHRlbnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1 dGhvcml6YXRpb25zIHNjb3BlZCBhcyBuYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwg cHJvdmlkZSBhIGNsZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRp ZXMgaW52b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3Nhcnkg ZGVwZW5kZW5jZSBvbiBhIGJyb3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGlu dGVyYWN0aW9ucy4NCj4+DQo+PiBUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQg dXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCwgZWFjaCBwZXJmb3JtaW5n IGEgc3BlY2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0 aW9uIGNoYW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQgdXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0aGUg ZGVsZWdhdGlvbiBjaGFubmVsLCB3aGljaCBoYXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNs aWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250cmFzdCB3aXRoIE9BdXRo IDIuMCB3aGljaCBpcyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNl cuKAmXMgYnJvd3NlcikuIFRoZSBjbGllbnQgYW5kIEFTIHdpbGwgaW52b2x2ZSBhIHVzZXIgdG8g bWFrZSBhbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGludGVy YWN0aW9uIG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4gVGhpcyBkZWNvdXBs aW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2FsIGNo YWxsZW5nZXMgb2YgT0F1dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRoIGZv ciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBjaGFu bmVscy4NCj4+DQo+PiBBZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBh bGxvdyBmb3I6DQo+Pg0KPj4gLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MN Cj4+IC0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRlbnRpdHkgY2xhaW1zDQo+PiAt IEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMgaW4gYSBz aW5nbGUgaW50ZXJhY3Rpb24NCj4+IC0gU2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRo b3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVyYXRpbmcgdGhlIGNsaWVudCByZXF1ZXN0 aW5nIGFjY2Vzcw0KPj4gLSBBIHZhcmlldHkgb2YgY2xpZW50IGFwcGxpY2F0aW9ucywgaW5jbHVk aW5nIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIGludGVyYWN0aW9uLWNvbnN0cmFpbmVk IGFwcGxpY2F0aW9ucw0KPj4NCj4+IFRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9p bnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBp bmNsdWRpbmc6DQo+Pg0KPj4gLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3Nh Z2Ugc2lnbmF0dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24NCj4+IC0gVXNlciBpbnRlcmFj dGlvbiBtZWNoYW5pc21zIGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcw0KPj4gLSBN ZWNoYW5pc21zIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5k IG90aGVyIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNp b25zDQo+PiAtIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9rZW5zIHRvIHJlc291cmNlIHNl cnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMgdG8gdG9rZW5zIGFuZCBhc3NvY2lh dGVkIGNyeXB0b2dyYXBoaWMga2V5cw0KPj4gLSBPcHRpbWl6ZWQgaW5jbHVzaW9uIG9mIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIChpbmNsdWRp bmcgaWRlbnRpdHkpDQo+Pg0KPj4gQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRl IG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNsZSBpbmNs dWRpbmc6DQo+Pg0KPj4gLSBEaXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQo+ PiAtIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2Vucw0KPj4gLSBRdWVyeSBvZiB0b2tlbiByaWdo dHMgYnkgcmVzb3VyY2Ugc2VydmVycw0KPj4NCj4+IEFsdGhvdWdoIHRoZSBhcnRpZmFjdHMgZm9y IHRoaXMgd29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1j b21wYXRpYmxlIHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2ls bCBhdHRlbXB0IHRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklE IENvbm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJsZS4NCj4+DQo+PiBUaGlz IGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIu MCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMg bm90IG5lY2Vzc2FyaWx5IGNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkg dGhhdCBidWlsZHMgZGlyZWN0bHkgb24gT0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRo ZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBpbmNsdWRpbmcgZnVuY3Rpb25hbGl0eSBiYWNrLXBvcnRl ZCBmcm9tIHRoZSBwcm90b2NvbCBkZXZlbG9wZWQgaGVyZSB0byBPQXV0aCAyLjAuDQo+Pg0KPj4g VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGFwcGx5aW5n IGNyeXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBhcyBKT1NFIGFuZCBDT1NFLCB0byB0aGUgZGVs ZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBu ZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2RzLg0KPj4NCj4+IFRoZSBpbml0aWFsIHdvcmsgd2lsbCBm b2N1cyBvbiB1c2luZyBIVFRQIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXph dGlvbiBmZWF0dXJlcyBvZiBIVFRQMiBhbmQgSFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxs IHN0cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2gg YXMgQ09BUCB3aGVuIGRvaW5nIHNvIGRvZXMgbm90IGNvbmZsaWN0IHdpdGggdGhlIHByaW1hcnkg Zm9jdXMuDQo+Pg0KPj4gTWlsZXN0b25lcyB0byBpbmNsdWRlOg0KPj4gLSBDb3JlIGRlbGVnYXRp b24gcHJvdG9jb2wNCj4+IC0gS2V5IHByZXNlbnRhdGlvbiBtZWNoYW5pc20gYmluZGluZ3MgdG8g dGhlIGNvcmUgcHJvdG9jb2wgZm9yIFRMUywgZGV0YWNoZWQgSFRUUCBzaWduYXR1cmUsIGFuZCBl bWJlZGRlZCBIVFRQIHNpZ25hdHVyZXMNCj4+IC0gSWRlbnRpdHkgYW5kIGF1dGhlbnRpY2F0aW9u IGNvbnZleWFuY2UgbWVjaGFuaXNtcw0KPj4gLSBHdWlkZWxpbmVzIGZvciB1c2Ugb2YgcHJvdG9j b2wgZXh0ZW5zaW9uIHBvaW50cw0KPj4NCj4+DQo+PiAtLQ0KPj4gVHhhdXRoIG1haWxpbmcgbGlz dA0KPj4gVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KPiAtLQ0KPiBUeGF1dGggbWFp bGluZyBsaXN0DQo+IFR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQotLQ0KVHhhdXRo IG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQoNCi0tDQpOYXQg U2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0dHA6Ly9uYXQu c2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0 aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg== --_000_DM6PR00MB0682ADE62F89284C8AA5F8B6F5F50DM6PR00MB0682namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI4ODk2Nzg1NzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAyOTE0MDY2MiA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 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+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgYWdyZWUgd2l0aCBtYW55IG9mIHRoZSBwb2lu dHMgdGhhdCBEaWNrIG1ha2VzIGJlbG93IOKAkyBlc3BlY2lhbGx5IHRoYXQgd2Ugc2hvdWxkIGJl IHJldXNpbmcgZXhpc3RpbmcgdGVjaG5vbG9naWVzIHdoZXJlIGFwcGxpY2FibGUgYW5kIG9ubHkg aW52ZW50aW5nIHdoZW4gZG9pbmcgc28gY3JlYXRlcyB1bmlxdWUgbmV3IHZhbHVlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5SZXVzaW5nIEV4aXN0aW5nIFRlY2hub2xvZ3k6IDwvYj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+VG8gdGhlIHNwZWNpZmljIHBvaW50IGFib3V0IHJldXNpbmcgZXhpc3RpbmcgaWRl bnRpdHkgcmVwcmVzZW50YXRpb25zLCBJIHdvdWxkIHJlcXVlc3QgdGhhdCB0aGlzIHBvaW50IGJl IGFkZGVkIHRvIHRoZSBjaGFydGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0iY29sb3I6IzAwMjA2MDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3QgY3JlYXRlIG5ldyBpZGVudGl0eSBy ZXByZXNlbnRhdGlvbnM7IGl0IG1heSBlbmFibGUgdGhlIHVzZSBvZiBleGlzdGluZyBpZGVudGl0 eSByZXByZXNlbnRhdGlvbnMgb3IgbmV3IGlkZW50aXR5IHJlcHJlc2VudGF0aW9ucyBjcmVhdGVk IGJ5IG90aGVycy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5BUyZsdDstJmd0O1JTIHJlbGF0aW9uc2hpcDo8L2I+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiBJIGJlbGlldmUgdGhhdCBpbnRyb3NwZWN0aW9uIGlz IHVubmVjZXNzYXJ5IGZvciBtYW55IHVzZSBjYXNlcywgYW5kIGluZGVlZCwgcmVxdWlyaW5nIGl0 IHdvdWxkIGJlIGEgcmVncmVzc2lvbiByZWxhdGl2ZSB0byBPQXV0aCAyLjAuJm5ic3A7IFRoZXJl Zm9yZSwgSSBzdXBwb3J0IERpY2vigJlzIHByb3Bvc2VkIG1vZGlmaWNhdGlvbjo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCmNvbW11bmljYXRpb24gb2YgdG9rZW4g YXR0cmlidXRlcyBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ug c2VydmVyPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+T0F1dGggMi4wIHNjb3BlczogPC9iPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj4mbmJzcDtJIGFncmVlIHRoYXQNCjwvc3Bhbj50aGUgZXhpc3RpbmcgT0F1dGgg Mi4wIHNjb3BlcyBzaG91bGQgYmUgZWFzaWx5IHVzZWQgaW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNl cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC0tIE1pa2U8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUeGF1dGggJmx0O3R4YXV0aC1i b3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5EaWNrIEhhcmR0PGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgTWFyY2ggMjAsIDIwMjAgMTE6MDQgQU08YnI+DQo8Yj5Ubzo8 L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+ IFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDs7IFRvcnN0ZW4gTG9k ZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OzsgTmF0IFNha2ltdXJhICZs dDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7OyBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzPTQw bWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IHR4YXV0aEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1R4YXV0aF0gQ2FsbCBmb3IgY2hhcnRlciBjb25zZW5zdXMgLSBU eEF1dGggV0c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5h dDogdGhhbmtzIGZvciBjaGltaW5nIGluLiBVc2VmdWwmbmJzcDtpbnNpZ2h0cyBhcyBhbHdheXMh PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZp dHRvcmlvOiBJJ2xsIHJlaW50ZXJwcmV0IHlvdXIgc3RhdGVtZW50IGFib3V0ICZxdW90O21hcmtl dGluZyZxdW90OyB0aGUgd29yaywgdG8gYmUgdGhhdCB3ZSBzaG91bGQgc29sdmUgcmVhbCBwcm9i bGVtcyB0aGF0IHBlb3BsZSBkb24ndCBoYXZlIHNvbHV0aW9ucyBmb3IgdG9kYXkuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkFT Jmx0Oy0mZ3Q7UlMgcmVsYXRpb25zaGlwPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRMO0RSOiBJIHRoaW5rIHRoZSBjaGFydGVyIG1pc3NlcyB0aGUg bWFyayBpbiB0aGUgQVMmbHQ7LSZndDtSUyByZWxhdGlvbnNoaXAgYmVpbmcgaW4gc2NvcGUgYW5k IHdlIHNob3VsZCBleHBhbmQgaXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gT0F1dGggMi4wIChSRkM2NzQ5KWwsIHRoZSBBUyBhbmQgUlMgd2VyZSBzZXBhcmF0ZSBy b2xlcyBpbiBjb250cmFzdCB0byBPQXV0aCAxLjAsIGJ1dCB0aGUgaW50ZXJhY3Rpb25zIC8gY29t bXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBBUyBhbmQgdGhlIFJTIHdlcmUgb3V0IG9mIHNjb3BlLCBh cyB0aGUgdXNlcyBjYXNlcyBhdCB0aGUgdGltZSBoYWQgdGhlIEFTIGFuZCBSUyBvcGVyYXRlZCBi eSB0aGUgc2FtZQ0KIGVudGl0eS4gTmV3IHVzZSBjYXNlcyBoYXZlIGEgd2Vha2VyIGNvdXBsaW5n IGJldHdlZW4gdGhlIEFTIGFuZCBSUywgYW5kIHRvIGVuYWJsZSBpbnRlcm9wLCBleHRlbnNpb25z IGhhdmUgYmVlbiB3cml0dGVuIGZvciBUb2tlbiBJbnRyb3NwZWN0aW9uLCBhbmQgSldUIFByb2Zp bGUgZm9yIE9BdXRoIDIuMCBBY2Nlc3MgVG9rZW5zIC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFR4QXV0aCBjaGFydGVyIGlu Y2x1ZGVzIGludHJvc3BlY3Rpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFF1ZXJ5IG9mIHRva2VuIHJpZ2h0 cyBieSByZXNvdXJjZSBzZXJ2ZXJzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t IGJ1dCBkb2VzIG5vdCBpbmNsdWRlIHRoZSBjb21tb24gZGVzaWduIHBhdHRlcm4gd2hlcmUgdGhl IFJTIGNhbiBkaXJlY3RseSBpbnRlcnByZXQgdGhlIHRva2VuLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIHByb3Bvc2VkIHVwZGF0 ZWQmbmJzcDt0ZXh0IHRvIHRoZSBsaW5lIGFib3ZlIHRvIGJlIGJyb2FkZXIgaW4gc2NvcGUgdGhh biBqdXN0IGEgcXVlcnk6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGNvbW11bmljYXRpb24mbmJzcDtvZiB0b2tl biBhdHRyaWJ1dGVzJm5ic3A7YmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJl c291cmNlIHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+QXJjaGl0ZWN0dXJlIGFuZCBVc2UgQ2FzZSBkb2N1bWVudHM8L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRMO0RSOiBZZXMgdG8gdXNl IGNhc2UgZG9jLCBubyB0byBhcmNoaXRlY3R1cmUgZG9jLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggSnVzdGluIHRoYXQg YW4gYXJjaGl0ZWN0dXJlJm5ic3A7ZG9jdW1lbnQgaXMgdW5saWtlbHkgdG8gcHJvdmUgdXNlZnVs IGxvbmcgdGVybS4gSSBkaXNhZ3JlZSB3aXRoIGhpbSBvbiB0aGUgdXNlIGNhc2VzLiBJIGRvbid0 IHRoaW5rIHRoZSB1c2UgY2FzZXMgbmVlZCB0byBiZSBleGhhdXN0aXZlLCBidXQgZXhhbXBsZSB1 c2UgY2FzZXMgaGVscHMgZXZlcnlvbmUgdW5kZXJzdGFuZCBldmVyeW9uZSBlbHNlJ3MNCiBwcmlt YXJ5IHVzZSBjYXNlcy4gSWYgeW91ciB1c2UgY2FzZSBpcyBub3Qgc2ltaWxhciB0byBvdGhlcnMs IHRoZW4geW91IHNob3VsZCB3cml0ZSBpdCB1cCBhbmQgdGhlIFdHIGNhbiBkZWNpZGUgaWYgaXQg aXMgaW4gc2NvcGUgb3Igbm90LiBJZiBpdCBpcywgaXQgZ2V0cyBhZGRlZCB0byB0aGUgdXNlIGNh c2UgZG9jdW1lbnQuIEkgd291bGQgY29uc2lkZXIgdGhpcyBhIGxpdmluZyBkb2N1bWVudCB3aGls ZSB3b3JraW5nIG9uIHRoZSBjb3JlIHByb3RvY29sLg0KIEl0IHdvdWxkIE5PVCBiZSBhIHVzZSBj YXNlIGRvY3VtZW50IHRoYXQgc2NvcGVzIHRoZSBXRyB3b3JrLiBUaGUgY2hhcnRlciBkb2VzIHRo YXQuIEl0IHdvdWxkIGJlIGEgY29tcGFuaW9uIGRvY3VtZW50IHRvIHRoZSBjb3JlIHByb3RvY29s LiBJIHN0cm9uZ2x5IHRoaW5rIGEgdXNlIGNhc2UgZG9jdW1lbnQgcmVzb2x2ZXMgbWFueSBvZiB0 aGUgbWlzY29tbXVuaWNhdGlvbnMgdGhhdCBoYXBwZW4gd2hlcmUgcGVvcGxlIGFyZSB0YWxraW5n IHBhc3QNCiBlYWNoIG90aGVyLCBiZWNhdXNlIHRoZXkgZG9uJ3QgdW5kZXJzdGFuZCBlYWNoIG90 aGVyJ3MgdXNlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5SZXVzaW5nIEV4aXN0aW5nIFRlY2hub2xv Z3k8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRMO0RSOiB3ZSBzaG91bGQgYmUgcmV1c2luZyBleGlzdGluZyBzcGVjaWZpY2F0aW9ucyB3 aGVyZSBldmVyIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWFkaW5nIGJldHdlZW4gdGhlIGxpbmVzLCBJIHRoaW5rIHRoZSBj b25jZXJuIGFyb3VuZCBpZGVudGl0eSBtYXkgYmUgdGhhdCB0aGUgVHhBdXRoIGNoYXJ0ZXIgaW1w bGllcyB0aGF0IHRoZSBXRyBpcyBnb2luZyB0byBjcmVhdGUgeWV0LWFub3RoZXItaWRlbnRpdHkt cmVwcmVzZW50YXRpb24gYW5kIGlnbm9yZSBhbGwgdGhlIHByZXZpb3VzIGVmZm9ydHMuIEkgdGhp bmsgY3JlYXRpbmcmbmJzcDt5ZXQtYW5vdGhlci1pZGVudGl0eS1yZXByZXNlbnRhdGlvbg0KIHRv IHNvbHZlIHVzZSBjYXNlcyB0aGF0IGFyZSBhbHJlYWR5IHNvbHZlZCB3aXRoIGV4aXN0aW5nIHJl cHJlc2VudGF0aW9ucyB3b3VsZCBiZSBtaXNndWlkZWQgZWZmb3J0LiBNeSBvd24gaW50ZXJlc3Qg aW4gVHhBdXRoIGlzIGJlaW5nIGFibGUgdG8gdXNlIG9uZSBwcm90b2NvbCB0byByZXF1ZXN0IGFu ZCByZWNlaXZlIGFueSBleGlzdGluZyBhbmQgZnV0dXJlIGlkZW50aXR5IHJlcHJlc2VudGF0aW9u LiBPbmUgb2YgbXkgbW90aXZhdGlvbnMgZm9yDQogd3JpdGluZyB0aGUgWEF1dGggZG9jdW1lbnQg d2FzIHRvIHNob3cgaG93IGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgY291bGQgYmUgcmVxdWVz dGVkIGFuZCByZWNlaXZlZCwgYXMgdGhpcyB3YXMgbWlzc2luZyBpbiBYWVouJm5ic3A7IElmIGEg dXNlIGNhc2UgcmVxdWlyZXMgYSBuZXcgcmVwcmVzZW50YXRpb24sIHRoZW4gcGVyaGFwcyBUeEF1 dGggbWF5IGJlIGEgcGxhY2UgZm9yIHRoYXQgd29yayB0byBoYXBwZW4sIGJ1dCBJIHRoaW5rIGl0 IGlzIG1vcmUNCiBsaWtlbHkgdG8gaGFwcGVuIGluIG90aGVyIGZvcnVtcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgbm90IGNsZWFy IHRvIG1lIGhvdywgb3IgaWYsIHJldXNpbmcgZXhpc3RpbmcgdGVjaG5vbG9neSBmaXRzIGludG8g dGhlIGNoYXJ0ZXIsIGJ1dCBJIGRvIHN0cm9uZ2x5IHRoaW5rIGl0IHNob3VsZCBiZSBhIHRlbmV0 IG9mIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIGEgcmVsYXRlZCBub3RlLCBJIGFsc28gc3Ryb25nbHkgdGhpbmsg dGhhdCB0aGUgZXhpc3RpbmcgT0F1dGggMi4wIHNjb3BlcyBzaG91bGQgYmUgZWFzaWx5IHVzZWQg aW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4gWEF1dGggc2hvd3MgYW4gZXhhbXBsZSBvZiBob3cg dGhhdCBjYW4gYmUgZG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+L0RpY2smbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFy IDIwLCAyMDIwIGF0IDY6MzkgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBh Z3JlZSB3aXRoIGEgbG90IG9mIHRoYXQgYXJndW1lbnQuIExldCBtZSBzZWUgaWYgSSBjYW4gbW9y ZSBjbGVhcmx5IHJlc3RhdGUgd2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5IGVhcmxpZXIgaW4gdGhp cyB0aHJlYWQ6IHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gdGhlIGRpZmZlcmVudCBwYXJ0aWVz IGFyZSBzZXBhcmFibGUgYW5kIGRlcGVuZCBvbiB0aGUga2luZCBvZiBkZXBsb3ltZW50cyBhbmQg dXNlIGNhc2VzDQogdGhhdCBhcmUgYmVpbmcgYWRkcmVzc2VkIGJ5IHBlb3BsZS4gU28gaW4gYW4g T0F1dGgvT0lEQy1zdHlsZSB3b3JsZCwgd2XigJl2ZSBnb3QgdGhyZWUgY29tcG9uZW50cyAoaWdu b3JpbmcgcGVvcGxlKSwgYW5kIHRocmVlIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiB0aGVtOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QyZsdDstJmd0O0FTPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMmbHQ7 LSZndDtSUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BUyZsdDstJmd0O1JTPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciBhdXRob3JpemF0aW9uLCB0aGVzZSBtYXAgdG8g4oCcaG93IHRv IGdldCBhIHRva2Vu4oCdLCDigJxob3cgdG8gdXNlIGEgdG9rZW7igJ0sIGFuZCDigJxob3cgdG8g aW50ZXJwcmV0IGEgdG9rZW7igJ0uIEZvciBhdXRoZW50aWNhdGlvbiwgaXTigJlzIGFkZGl0aW9u YWxseSDigJxob3cgZG8gSSBnZXQgdGhlIGF1dGhlbnRpY2F0aW9uIGluZm/igJ0sIOKAnGhvdyBk byBJIGFzayBmb3IgYSBwcm9maWxl4oCdLCBhbmQg4oCcaG93IGRvIEkga25vdyB3aG9zZQ0KIHBy b2ZpbGUgdGhpcyBpc+KAnS4gSSBzdGlsbCBiZWxpZXZlIHRoaXMgaXMgYSBnb29kIHNlcGFyYXRp b24gb2YgY29uY2VybnMuIFRoZSBjbGllbnQgZG9lc27igJl0IG5lZWQgdG8ga25vdyB3aGF04oCZ cyBpbiB0aGUgYWNjZXNzIHRva2VuLCBvciBpZiBpdOKAmXMgYSByZWZlcmVuY2Ugb3Igc2VsZi1j b250YWluZWQsIG9yIHJlYWxseSBjb25jZXJuIGl0c2VsZiBhdCBhbGwgd2l0aCB3aGF0IHRoZSBS UyBkb2VzIHdpdGggaXQuIEFyZSB0aGVyZSBvdmVybGFwcz8NCiBDZXJ0YWlubHkg4oCUIHRoZSBj bGllbnQgbmVlZHMgdG8ga25vdyBob3cgdG8gYXNrIGZvciBhIHRva2VuIHRoYXQgdGhlIFJTIHdp bGwgYWNjZXB0IGZvciB3aGF0IHRoZSBjbGllbnQgaXMgZ29pbmcgdG8gZG8sIGFuZCB0byBkbyB0 aGF0IHRoZSBjbGllbnQgbmVlZHMgdG8gYmUgYWJsZSB0byBkZXNjcmliZSB3aGF0IGl0IHdhbnRz IHRvIGRvIGluIGEgd2F5IHRoYXQgdGhlIEFTIGNhbiBpbnRlcnByZXQgYW5kIG1hcCB0byBhIHNl dCBvZiByaWdodHMNCiB0aGF0IHRoZSBSUyB3aWxsIGV2ZW50dWFsbHkgaW50ZXJwcmV0LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGJlbGlldmUgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYWxyZWFkeSBjb3ZlcnMgdGhpcyBzcGxpdCB3 aXRoIHRoZSBmb2xsb3dpbmcgaXRlbXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgYWNj ZXNzPGJyPg0KLSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBB UElzIGluIGEgc2luZ2xlIGludGVyYWN0aW9uPGJyPg0KLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhl IHBhcnR5IGF1dGhvcml6aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xp ZW50IHJlcXVlc3RpbmcgYWNjZXNzPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zPGJyPg0KLSBRdWVy eSBvZiB0b2tlbiByaWdodHMgYnkgcmVzb3VyY2Ugc2VydmVyczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKAmXMgdGhlIGNvbWJpbmF0aW9u IG9mIHRoZSByaWNoIHJlcXVlc3QgYW5kIHRoZSBsaWZlY3ljbGUgbWFuYWdlbWVudCB0aGF0IHB1 dHMgdGhlIEFTIGFuZCBSUyBpbiBzY29wZS4gSSB0aGluayB0aGluZ3MgbGlrZSBkZWNsYXJpbmcg YSBzaW5nbGUgdG9rZW4gZm9ybWF0IGFyZSBhYnNvbHV0ZWx5IG91dCDigJQgaWYgeW91IHdhbnQg dG8gdXNlIEpXVCwgb3IgQ1dULCBvciBVVUlE4oCZcywgdGhhdOKAmXMgYWxsIGp1c3QNCiBmaW5l LiBIb3dldmVyLCBzb21ldGhpbmcgdGhhdCBJIHRoaW5rIGlzIGluIHNjb3BlIGlzIGRlZmluaW5n IGEgc3RydWN0dXJlIGZvciB3aGF0IGEgdG9rZW4gcmVwcmVzZW50cy4gQW5kIEkgdGhpbmsgdGhh dCBpZiB3ZSBjYW4gZG8gdGhhdCBpbiB0aGlzIFdHIGluIGEgZ2VuZXJhbCB3YXksIHRoZW4gdGhh dOKAmXMgdXNlZnVsLiBCZWNhdXNlIHRoZW4gdGhhdCBzdHJ1Y3R1cmUgY2FuIGJlIHJlcHJlc2Vu dGVkIGJ5IG1hcHBpbmcgdG8gYSB0b2tlbg0KIGZvcm1hdCBvciBhbiBpbnRyb3NwZWN0aW9uIHJl c3BvbnNlIG9yIGEgZGF0YWJhc2UgZW50cnkuIEkgdGhpbmsgTmF04oCZcyBjb21tZW50cyBvbiBB QkFDIGFyZSBpbXBvcnRhbnQ6IHdlIGFyZSBnb2luZyB0byBuZWVkIGEgcGxhY2UgdG8gcHV0IHRo b3NlIGF0dHJpYnV0ZXMuIFdoZXRoZXIgdGhleeKAmXJlIGNvbW11bmljYXRlZCB0byB0aGUgUlMg dGhyb3VnaCB0aGUgdG9rZW4gaXRzZWxmIG9yIHRocm91Z2ggc29tZSBvdGhlciBjaGFubmVsIGlz LCBJDQogc3Ryb25nbHkgYmVsaWV2ZSwgYSBtYXR0ZXIgb2YgZGVwbG95bWVudCBjaG9pY2UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB3 aGF0IGNhbiB0aGUgY2hhcnRlciBzYXkgdG8gbWFrZSB0aGlzIG1vcmUgY2xlYXI/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCB0aGF0IHNh aWQsIEnigJltIGFnYWluc3QgaGF2aW5nIGFuIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBhcyBhIHdv cmtpbmcgZ3JvdXAgb3V0cHV0LiBJbiBteSBleHBlcmllbmNlLCB3aGVuIGEgV0cgcHV0cyBpdHMg ZWZmb3J0IGludG8gYSBmb3JtYWwgYXJjaGl0ZWN0dXJlIGRvYw0KPGk+YXMgYSBkZWxpdmVyYWJs ZTwvaT4sIHRoZXJlIGlzIGEgbG90IG9mIGNvbmplY3R1cmFsIGVuZXJneSB0aGF0IGdvZXMgaW50 byB3aGF0IG1pZ2h0IGJlIGEgZ29vZCBpZGVhLCBhbmQgdGhlbiBub3QgYWxsIG9mIGl0IHdvcmtz IG91dCB3aGVuIHlvdSB0cnkgdG8gaGFtbWVyIHRoZSBkZXRhaWxzIG9mIG1ha2luZyB0aGF0IGFy Y2hpdGVjdHVyZSBpbnRvIGEgcmVhbCBlbmdpbmVlcmVkIHRoaW5nLllvdSBlbmQgdXAgYmFraW5n IGluIGFzc3VtcHRpb25zDQogYW5kIGFic3RyYWN0aW9ucyB0aGF0IGRvbuKAmXQgbWFrZSBzZW5z ZSBhbnltb3JlLCBhbmQgdGhlbiB0cnlpbmcgdG8gZW5naW5lZXIgc29sdXRpb25zIGFyb3VuZCB0 aG9zZSB3aGVuIHRoZXkgZG9u4oCZdCBmaXQgcmlnaHQuIElmIHRoZSBhcmNoaXRlY3R1cmUgY2Fu 4oCZdCBjaGFuZ2UgaW4gbGlnaHQgb2YgbmV3IGluZm9ybWF0aW9uLCB3aGljaCBpcyB0aGUgY2Fz ZSB3aXRoIGFuIFJGQywgdGhlbiBpdCBiZWNvbWVzIGEgc2hhY2tsZSBpbnN0ZWFkIG9mDQogYSBz Y2FmZm9sZC4gQnV0IGEgbWFsbGVhYmxlIGRvY3VtZW50IHRoYXQgdGhlIGdyb3VwIGNhbiB1c2Ug YXMgYSBndWlkZSB3aGlsZSBlbmdpbmVlcmluZyB0aGUgYWN0dWFsIHBhcnRzIOKAlCB5ZXMsIHRo YXQgbWFrZXMgc2Vuc2UuIFRoZSBhcmNoaXRlY3R1cmUgY2FuIGJlIHJlZmFjdG9yZWQgYW5kIGNo YW5nZWQgYXMgZGVjaXNpb25zIGFyZSBtYWRlIGFuZCB0aGluZ3MgY29tZSBpbnRvIGZvY3VzLiBJ IGZlZWwgdGhlIHNhbWUgYWJvdXQgdXNlIGNhc2UNCiBkb2N1bWVudHMgYXMgZm9ybWFsIGFydGlm YWN0cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgTmF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyMCwgMjAyMCwgYXQg MjoxOSBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRob3VnaHQgSSBz aG91bGQga2VlcCBteSBtb3V0aCZuYnNwO3NodXQgYXMgYW55dGhpbmcgSSBzYXkgbWF5IGJlIGRl ZW1lZCBiaWFzZWQgYXMgbXkgb3RoZXIgaGF0IGlzIHRoZSBjaGFpcm1hbiBvZiBPSURGLCBidXQg aGVyZSBpcyBteSAyYy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFzIFRvcnN0ZW4gaW5kaWNhdGVkLCB0aGVyZSBpcyBtdWNoIHRvIGJlIGRlc2ly ZWQgdG8gc3RhbmRhcmRpemUgdGhlIEFTIC0gUlMgY29tbXVuaWNhdGlvbiBwYXR0ZXJucy4gWW91 IG1heSBzYXkgdGhhdCB0aGUgY2hhcnRlciBpbmNsdWRlcyBpdCwgYnV0IEkgY2Fubm90IHJlYWQg aXQgb3V0IG9mIHRoZSBjaGFydGVyIGp1c3QgbGlrZSBUb3JzdGVuIGNvdWxkIG5vdC4gQXMgYSBu ZXcgcHJvdG9jb2wsIGl0IHdvdWxkDQogYmUgZ29vZCB0byBpbmNsdWRlIGl0LiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGlz IHJlc3BlY3QsIEkgYW0gbm90IHN1cmUgaWYgd2Ugc2hvdWxkIHN0YXJ0IG9mZiBmcm9tIE9BdXRo IDIuMCBhbmQgT0lEQyBtb2RlbC4gSWYgd2UgYXJlIGNyZWF0aW5nIGEgbmV3IHByb3RvY29sLCBJ IGZlZWwgdGhhdCB3ZSBzaG91bGQgYXJjaGl0ZWN0IGlzIG1vcmUgZnVsbHkuIE5vdCBtZW50aW9u aW5nIEFTIC0gUlMgcmVsYXRpb25zaGlwIHRvIG1lIGZlZWxzIGxpa2UgYW4gaW5kaWNhdGlvbiBv Zg0KIHRoaXMgZmFpbHVyZS4gRm9yIHRoYXQgbWF0dGVyLCBJIGZlZWwgdGhhdCB0aGUgZmlyc3Qg b3V0cHV0IG9mIHRoZSBncm91cCBzaG91bGQgYmUgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHRo YXQgdGFrZXMgdGhlIGNvbmNlcm5zIGZyb20gYWxsIHRoZSByZWxldmFudCBzdGFrZWhvbGRlcnMv YWN0b3JzIGluLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSBzaG91bGQgYWxzbyBiZSBjb2duaXphbnQgb2YgdGhlIGFjY2VzcyZu YnNwO2NvbnRyb2wgbW9kZWxzIGxpa2UgQUJBQy4gRm9yIHRoYXQsIGRlY291cGxpbmcgb2YgaWRl bnRpdHkgKD0gc2V0IG9mIGNsYWltcykgYXNzZXJ0aW9uIGFuZCBhdXRob3JpemF0aW9uIGlzIGEg bmVjZXNzaXR5LiBXZSBjb3VsZCBvcHRpbWl6ZSBpdCBidXQgdGhlIGJhc2UgY2FzZSBzaG91bGQg dGFrZSBjYXJlIG9mIGl0LiAoSW4gdGhpcyByZXNwZWN0LA0KIEkgYW0gZmVlbGluZyB0aGF0IE9J REMgaGFzIHBlcmhhcHMgb3Zlci1vcHRpbWl6ZWQuKSBTbywgSSBmZWVsIHRoYXQgYXQgbGVhc3Qg YXMgdGhlIGZpcnN0IHN0ZXAsIFR4QXV0aCBzaG91bGQgY29uY2VudHJlIG9uIHRoZSBBY2Nlc3Mg Q29udHJvbC4gSWYgSSB3ZXJlIHRvIGdvIG9uZSBzdGVwIGZ1cnRoZXIsIGl0IHNob3VsZCBiZSBt b2RlbGxlZCBzbyB0aGF0IGl0IGNhbiBjb25zdW1lIHZhcmlvdXMgaWRlbnRpdHkgYXNzZXJ0aW9u cyAoYXV0aGVudGljYXRlZA0KIGlkZW50aXR5IGluIElTTy9JRUMgMjQ3NjAgc3BlYWspIGluY2x1 ZGluZyBJRCBUb2tlbiwgU0FNTCBBc3NlcnRpb24sIERJRCBWZXJpZmlhYmxlIENyZWRlbnRpYWxz LCBYLjUwOSBjZXJ0aWZpY2F0ZXMgKHN1Y2ggYXMgaW4gZUlEQVMgYW5kIEphcGFuZXNlIE5hdGlv bmFsIElEIHNjaGVtZSkmbmJzcDsgZXRjLiBXZSBhcmUgbm90IGdvaW5nIHRvIGdldCB0byBhIHVu aWZpZWQgaWRlbnRpdHkgd29ybGQgYW55dGltZSBzb29uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCBTYWtp bXVyYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFdlZCwgTWFyIDE4LCAyMDIwIGF0IDc6MDYgQU0gTWlrZSBKb25lcyAmbHQ7TWljaGFl bC5Kb25lcz08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGJlbGlldmUgaXQncyBzaWduaWZpY2FudCB0aGF0IGZvdXIgcGVvcGxlIGhhdmUgZXhw cmVzc2VkIGNvbmNlcm5zIHdpdGggaW5jbHVkaW5nIGRpZ2l0YWwgaWRlbnRpdHkgaW4gdGhlIGNo YXJ0ZXIgKHRoZSBvbmx5IGNvbmNlcm5zIHZvaWNlZCBhcyBmYXIgYXMgSSBjYW4gdGVsbCkuJm5i c3A7IEF0IGEgbWluaW11bSwgSSBiZWxpZXZlIHRoYXQgdGhhdCB3YXJyYW50cyBtYWtpbmcgdGhl IGluY2x1c2lvbiBvciBleGNsdXNpb24NCiBvZiBkaWdpdGFsIGlkZW50aXR5IGEgZGlzY3Vzc2lv biB0b3BpYyBkdXJpbmcgdGhlIHVwY29taW5nIHZpcnR1YWwgQm9GLCBiZWZvcmUgYWRvcHRpbmcg YW55IGNoYXJ0ZXIuPGJyPg0KPGJyPg0KSXQgd291bGQgYmUgbXkgcHJvcG9zYWwgdG8gaW5pdGlh bGx5IGNoYXJ0ZXIgd2l0aG91dCBkaWdpdGFsIGlkZW50aXR5IGFuZCBzZWUgaG93IGZhciB3ZSBn ZXQgd2l0aCBvdXIgZW5lcmdpZXMgaW50ZW50aW9uYWxseSBmb2N1c2VkIGluIHRoYXQgd2F5LiZu YnNwOyBJZiB0aGUgd29ya2luZyBncm91cCBkZWNpZGVzIHRvIHJlY2hhcnRlciB0byBpbmNsdWRl IGRpZ2l0YWwgaWRlbnRpdHksIHRoYXQgY2FuIGFsd2F5cyBoYXBwZW4gbGF0ZXIsIGFmdGVyIHRo ZQ0KIGF1dGhvcml6YXRpb24tZm9jdXNlZCB3b3JrIGhhcyBtYXR1cmVkLCBhbmQgb25jZSB0aGVy ZSdzIGEgY2xlYXIgY2FzZSB0byBhY3R1YWxseSBkbyBzby48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gTWlrZTxicj4N Cjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSnVzdGluIFJpY2hl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpy aWNoZXJAbWl0LmVkdTwvYT4mZ3Q7DQo8YnI+DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxNywgMjAy MCAyOjIwIFBNPGJyPg0KVG86IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208L2E+Jmd0Ozxicj4NCkNjOiBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWls dG86eWFyb25mLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWFyb25mLmlldGZAZ21h aWwuY29tPC9hPiZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBD YWxsIGZvciBjaGFydGVyIGNvbnNlbnN1cyAtIFR4QXV0aCBXRzxicj4NCjxicj4NCldoaWxlIEkg dW5kZXJzdGFuZCB0aGUgY29uY2VybnMgYXJvdW5kIGlkZW50aXR5IGluIHRoZSBjaGFydGVyLCBh bmQgSSBoYWQgaW5pdGlhbGx5IG5vdCBpbmNsdWRlZCBpdCwgSSB3YXMgY29udmluY2VkIHRoYXQg dGhlIGtpbmQgb2YgaWRlbnRpdHkgcHJvdG9jb2wgdGhhdCB3ZeKAmXJlIGxvb2tpbmcgYXQgaGVy ZSBpcyBhIG1pbm9yIGFkZGl0aW9uIHRvIHRoZSBhdXRob3JpemF0aW9uIGFuZCBkZWxlZ2F0aW9u IGVuZCBvZiB0aGluZ3MuPGJyPg0KPGJyPg0KQXMgeW91IGtub3csIG11Y2ggb2Ygd2hhdOKAmXMg aW4gT0lEQyBpcyB0aGVyZSB0byBmaXggcHJvYmxlbXMgd2l0aCBPQXV0aCAyIHdoZW4gaXTigJlz IHVzZWQgZm9yIGlkZW50aXR5LiBJZiBPQXV0aCAyIGhhZCBzb2x2ZWQgdGhvc2UgcHJvYmxlbXMg aW50ZXJuYWxseSwgdGhlbiBPSURDIHdvdWxkIGJlIG11Y2gsIG11Y2ggc2ltcGxlciBhbmQgc21h bGxlci4gV2XigJlyZSBub3cgc3RhcnRpbmcgYXQgYSBiYXNlIHdoZXJlIHRob3NlIHByb2JsZW1z IGRvbuKAmXQNCiBleGlzdCwgYnV0IHdlIGRvbuKAmXQgeWV0IGtub3cgd2hhdCBvdGhlciBwcm9i bGVtcyB0aGVyZSBtaWdodCBiZS4gPGJyPg0KPGJyPg0KVGhlIG1hcmtldCBoYXMgc2hvd24gdXMg dGhhdCB0aGUgbW9zdCBjb21tb24gYXBwbGljYXRpb24gb2YgT0F1dGggMiBpcyBmYXIgYW5kIGF3 YXkgYWNjZXNzIHRvIGlkZW50aXR5IGluZm9ybWF0aW9uIGFsb25nIHNpZGUgYWNjZXNzIHRvIGFu IEFQSS4gSSB0aGluayB3ZSBuZWVkIHRvIHBheSBhdHRlbnRpb24gdG8gdGhhdCBhbmQgbm90IG1h a2UgdGhpcyBzZXBhcmF0ZSBqdXN0IGJlY2F1c2Ugd2UgZGlkIGl0IHRoYXQgd2F5IGJlZm9yZS4g QW5kIHNvbWUNCiBvZiB0aGUgcHJvcG9zZWQgaW5ub3ZhdGlvbnMsIGluY2x1ZGluZyBnZXR0aW5n IGFuZCBzZW5kaW5nIFZD4oCZcywgYXJlIGFsbCBhYm91dCBpZGVudGl0eS48YnI+DQo8YnI+DQpG dXJ0aGVybW9yZSwgdGhpcyBjaGFydGVyIGRvZXMgbm90IHNwZWNpZnkgdGhlIGRvY3VtZW50IGFu ZCBzcGVjaWZpY2F0aW9uIHN0cnVjdHVyZSBvZiB0aGUgY29tcG9uZW50cywgbm9yIGRvZXMgaXQg c3BlY2lmeSB0aGUgcHVibGljYXRpb24gb3JkZXIgb3IgdGltaW5nIG9mIGFueSBkb2N1bWVudHMu IEkgcGVyc29uYWxseSB0aGluayB0aGF0IHRoZSBpZGVudGl0eSBsYXllciBzaG91bGQgYmUgc2Vw YXJhYmxlIHRvIGFuIGV4dGVudCwgdG8gdGhlDQogcG9pbnQgb2YgcHVibGlzaGluZyB0aGF0IGxh eWVyIGluIGl0cyBvd24gc3BlYyBhbG9uZ3NpZGUgdGhlIGNvcmUgYXV0aG9yaXphdGlvbiBkZWxl Z2F0aW9uIHN5c3RlbS4gSG93ZXZlciwgdGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgc2hvdWxk IGJlIGRldmVsb3BlZCBlbHNld2hlcmUuPGJyPg0KPGJyPg0KSWYgdGhlcmUgaXMgYmV0dGVyIGxh bmd1YWdlIHRvIHRpZ2h0ZW4gdGhlIGFzcGVjdHMgb2YgYW4gaWRlbnRpdHkgcHJvdG9jb2wgdGhh dCB3ZSB3aWxsIGV4cGxpY2l0bHkgY292ZXIsIHRoZW4gSSB3b3VsZCB3ZWxjb21lIHlvdSB0byBz dWdnZXN0IGFuIGFtZW5kZWQgdGV4dCB0byB0aGUgY2hhcnRlci4gSG93ZXZlciwgSSBiZWxpZXZl IHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCB3aXRoaW4gdGhlIGNvbW11bml0eSB0byB3b3JrIG9u IGlkZW50aXR5DQogaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBwcm90b2NvbCwgaW5jbHVkaW5nIGEg bGFyZ2UgbnVtYmVyIG9mIHBlb3BsZSBiZWluZyBPSyB3aXRoIGl0IGluIHRoZSBjaGFydGVyLCB0 aGF0IGl0IHdvdWxkIG5vdCBiZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8gcmVtb3ZlIGl0Ljxicj4N Cjxicj4NCiZuYnNwO+KAlCBKdXN0aW48YnI+DQo8YnI+DQomZ3Q7IE9uIE1hciAxNywgMjAyMCwg YXQgMToxMiBQTSwgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lcz08YSBocmVmPSJtYWlsdG86 NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3Nv ZnQuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDEuJm5ic3A7IERvIHlvdSBzdXBwb3J0IHRoZSBjaGFydGVyIHRleHQgcHJvdmlkZWQgYXQgdGhl IGVuZCBvZiB0aGlzIGVtYWlsPyZuYnNwOyBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25z LCBibG9ja2luZyBjb25jZXJucyBvciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgc2hhcmUgdGhlIGNvbmNlcm5zIGFib3V0IGluY2x1ZGlu ZyBpZGVudGl0eSBpbiB0aGUgY2hhcnRlciB0aGF0IHdlcmUgZXhwcmVzc2VkIGJ5IFRvcnN0ZW4g YW5kIGFncmVlZCB3aXRoIGJ5IERhdmlkIFNrYWlmZS4mbmJzcDsgSSdsbCBub3RlIHRoYXQgS2lt IENhbWVyb24gcHJldmlvdXNseSBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgaW5jbHVkaW5nIGlk ZW50aXR5IGluIGhpcyBlYXJsaWVyIGNoYXJ0ZXIgY3JpdGlxdWUgYXQNCjxhIGhyZWY9Imh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoL3VMOTJPX1ZrNW0zOERjYWNY U25zaFgyQ2FoRS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvdHhhdXRoL3VMOTJPX1ZrNW0zOERjYWNYU25zaFgyQ2FoRS88L2E+Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBJJ20gZmluZSB3aXRoIHJlZmFjdG9yaW5nIHRoZSBhdXRob3JpemF0 aW9uIHByb3RvY29sLiZuYnNwOyBCdXQgaWRlbnRpdHkgc2hvdWxkIGJlIGRlY291cGxlZCBmcm9t IHRoZSBUeEF1dGggd29yayB0byBmb2N1cyBpdHMgc2NvcGUgb24gYXJlYXMgd2hlcmUgaW5ub3Zh dGlvbiBpcyBiZWluZyBwcm9wb3NlZC4mbmJzcDsgRGlnaXRhbCBpZGVudGl0eSBjYW4gYWx3YXlz IGJlIGFkZGVkIGFzIGEgbGF5ZXIgaWYgbmVlZGVkLCBqdXN0IGFzIE9wZW5JRCBDb25uZWN0DQog bGF5ZXJlZCBpZGVudGl0eSBvbnRvIE9BdXRoIDIuMC48YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxl YXNlIHJldmlzZSB0aGUgY2hhcnRlciB0byByZW1vdmUgZGlnaXRhbCBpZGVudGl0eSBmcm9tIHRo ZSBzY29wZSBvZiB0aGUgd29yay48YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4mbmJzcDsgQXJlIHlv dSB3aWxsaW5nIHRvIGF1dGhvciBvciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2ZWxvcG1lbnQgb2Yg dGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXM8YnI+DQomZ3Q7 IDxicj4NCiZndDsgMy4mbmJzcDsgQXJlIHlvdSB3aWxsaW5nIHRvIGhlbHAgcmV2aWV3IHRoZSBk cmFmdHMgb2YgdGhpcyBXRz88YnI+DQomZ3Q7IDxicj4NCiZndDsgWWVzPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDQuJm5ic3A7IEFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcgZHJhZnRz IG9mIHRoaXMgV0c/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vdCBhdCB0aGlzIHRpbWUuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7LS0gTWlrZTxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogVHhhdXRoICZsdDs8YSBocmVmPSJtYWlsdG86dHhh dXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGgtYm91bmNlc0BpZXRm Lm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KJmd0OyBT ZW50OiBTYXR1cmRheSwgTWFyY2ggNywgMjAyMCA3OjE4IEFNPGJyPg0KJmd0OyBUbzogWWFyb24g U2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogPGEg aHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUeGF1dGhdIENhbGwg Zm9yIGNoYXJ0ZXIgY29uc2Vuc3VzIC0gVHhBdXRoIFdHPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhp LDxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgQW0gMDYuMDMuMjAyMCB1bSAxNzo0NSBzY2hyaWVi IFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyDvu79IaSBFdmVyeW9uZSw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBJdCBhcHBlYXJzIHRoYXQgbW9tZW50dW0gaXMgZm9ybWluZyBhcm91bmQgdGhlIHBy b3Bvc2VkIGZvcm1hdGlvbiBvZiBhIFR4QXV0aCB3b3JraW5nIGdyb3VwLiZuYnNwOyBXZeKAmWQg bGlrZSB0byBtb3JlIGZvcm1hbGx5IGdhdWdlIGludGVyZXN0IGluIHByb2NlZWRpbmcgd2l0aCB0 aGlzIHdvcmsuJm5ic3A7IFBsZWFzZSBkbyBzbyBieSByZXNwb25kaW5nIHRvIHRoZSBmb2xsb3dp bmcgcXVlc3Rpb25zOjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDEuJm5ic3A7IERvIHlv dSBzdXBwb3J0IHRoZSBjaGFydGVyIHRleHQgcHJvdmlkZWQgYXQgdGhlIGVuZCBvZiB0aGlzIGVt YWlsPyZuYnNwOyBPciBkbyB5b3UgaGF2ZSBtYWpvciBvYmplY3Rpb25zLCBibG9ja2luZyBjb25j ZXJucyBvciBmZWVkYmFjayAoaWYgc28gcGxlYXNlIGVsYWJvcmF0ZSk/PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEnigJhtIGluIGFsdGhvdWdoIEkgaGF2ZSB0byBhZG1pdCBJ4oCYbSBzbGlnaHRseSBj b25jZXJuZWQgdGhlIHNjb3BlIG9mIHRoZSBjaGFydGVyIGlzIHRvbyBicm9hZCwgZS5nLiBpZGVu dGlmeSBhbG9uZSBpcyBhIGh1Z2UgdG9waWMuLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXZSBuZWVk IHRvIGtlZXAgYW4gZXllIG9uIHRoaXMgYXNwZWN0IGluIG9yZGVyIHRvIG1ha2Ugc3VyZSwgdGhl IGdyb3VwIGlzIGFibGUgdG8gd29yayBlZmZlY3RpdmVseSBhbmQgdGhlIHNwZWNzIHdlIHdpbGwg YmUgcHJvZHVjaW5nIGFyZSBhcyBzaW1wbGUgYXMgcG9zc2libGUgYW5kIGZvc3RlciBpbnRlcm9w ZXJhYmlsaXR5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgMi4mbmJz cDsgQXJlIHlvdSB3aWxsaW5nIHRvIGF1dGhvciBvciBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2ZWxv cG1lbnQgb2YgdGhlIGRyYWZ0cyBvZiB0aGlzIFdHPzxicj4NCiZndDsgPGJyPg0KJmd0OyB5ZXM8 YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDMuJm5ic3A7IEFyZSB5b3Ug d2lsbGluZyB0byBoZWxwIHJldmlldyB0aGUgZHJhZnRzIG9mIHRoaXMgV0c/PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IHllczxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgNC4m bmJzcDsgQXJlIHlvdSBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyBkcmFmdHMgb2YgdGhpcyBX Rz88YnI+DQomZ3Q7IDxicj4NCiZndDsgeWVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGJlc3QgcmVn YXJkcyw8YnI+DQomZ3Q7IFRvcnN0ZW4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBUaGUgY2FsbCB3aWxsIHJ1biBmb3IgdHdvIHdlZWtzLCB1bnRpbCBNYXJjaCAyMS4g SWYgeW91IHRoaW5rIHRoYXQgdGhlIGNoYXJ0ZXIgc2hvdWxkIGJlIGFtZW5kZWQgSW4gYSBzaWdu aWZpY2FudCB3YXksIHBsZWFzZSByZXBseSBvbiBhIHNlcGFyYXRlIHRocmVhZC48YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGUgZmVlZGJhY2sgcHJvdmlkZWQgaGVyZSB3aWxsIGhlbHAg dGhlIElFU0cgY29tZSB0byBhIGRlY2lzaW9uIG9uIHRoZSBmb3JtYXRpb24gb2YgYSBuZXcgV0cu IEdpdmVuIHRoZSBjb25zdHJhaW50cyBvZiB0aGUgY2hhcnRlcmluZyBwcm9jZXNzLCByZWdhcmRs ZXNzIG9mIHRoZSBvdXRjb21lIG9mIHRoaXMgY29uc2Vuc3VzIGNhbGwsIHdlIHdpbGwgYmUgbWVl dGluZyBpbiBWYW5jb3V2ZXIgYXMgYSBCb0YuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg VGhhbmtzLDxicj4NCiZndDsmZ3Q7IFlhcm9uIGFuZCBEaWNrPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgLS0tIENoYXJ0ZXIgVGV4dCBGb2xsb3dzIC0tLTxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7IFRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBmaW5lLWdyYWlu ZWQgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgYXV0aG9yaXphdGlvbiwgaWRlbnRpdHksIGFuZCBB UEkgYWNjZXNzLiBUaGlzIHByb3RvY29sIHdpbGwgYWxsb3cgYW4gYXV0aG9yaXppbmcgcGFydHkg dG8gZGVsZWdhdGUgYWNjZXNzIHRvIGNsaWVudCBzb2Z0d2FyZSB0aHJvdWdoIGFuIGF1dGhvcml6 YXRpb24gc2VydmVyLiBJdCB3aWxsIGV4cGFuZCB1cG9uIHRoZQ0KIHVzZXMgY2FzZXMgY3VycmVu dGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IChpdHNlbGYgYW4g ZXh0ZW5zaW9uIG9mIE9BdXRoIDIuMCkgdG8gc3VwcG9ydCBhdXRob3JpemF0aW9ucyBzY29wZWQg YXMgbmFycm93bHkgYXMgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHByb3ZpZGUgYSBjbGVhciBmcmFt ZXdvcmsgZm9yIGludGVyYWN0aW9uIGFtb25nIGFsbCBwYXJ0aWVzIGludm9sdmVkIGluIHRoZSBw cm90b2NvbCBmbG93LA0KIGFuZCByZW1vdmUgdW5uZWNlc3NhcnkgZGVwZW5kZW5jZSBvbiBhIGJy b3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0aW9ucy4NCjxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBh Y3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHByb3RvY29sLCBlYWNoIHBlcmZv cm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50 ZXJhY3Rpb24gY2hhbm5lbHMsIHN1Y2ggYXMgdGhlIGVuZCB1c2Vy4oCZcyBicm93c2VyLCBmcm9t IHRoZSBkZWxlZ2F0aW9uIGNoYW5uZWwsIHdoaWNoIGhhcHBlbnMgZGlyZWN0bHkgYmV0d2Vlbg0K IHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0 aCBPQXV0aCAyLjAgd2hpY2ggaXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3Rpbmcg dGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUgY2xpZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1 c2VyIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3Vn aCBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluZGljYXRlZA0KIGJ5IHRoZSBwcm90b2NvbC4gVGhp cyBkZWNvdXBsaW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVj aG5pY2FsIGNoYWxsZW5nZXMgb2YgT0F1dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2 ZSBwYXRoIGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFj dGlvbiBjaGFubmVscy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBZGRpdGlvbmFsbHks IHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxvdyBmb3I6PGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3M8YnI+DQom Z3Q7Jmd0OyAtIEFwcHJvdmFsIG9mIEFTIGF0dGVzdGF0aW9uIHRvIGlkZW50aXR5IGNsYWltczxi cj4NCiZndDsmZ3Q7IC0gQXBwcm92YWwgb2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBh bmQgQVBJcyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbjxicj4NCiZndDsmZ3Q7IC0gU2VwYXJhdGlv biBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVy YXRpbmcgdGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2Vzczxicj4NCiZndDsmZ3Q7IC0gQSB2YXJp ZXR5IG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyBXZWIsIG1vYmlsZSwgc2luZ2xl LXBhZ2UsIGFuZCBpbnRlcmFjdGlvbi1jb25zdHJhaW5lZCBhcHBsaWNhdGlvbnM8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50 cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5j bHVkaW5nOjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0gQ3J5cHRvZ3JhcGhpYyBhZ2ls aXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9u IDxicj4NCiZndDsmZ3Q7IC0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluY2x1ZGluZyB3 ZWIgYW5kIG5vbi13ZWIgbWV0aG9kczxicj4NCiZndDsmZ3Q7IC0gTWVjaGFuaXNtcyBmb3IgY29u dmV5aW5nIHVzZXIsIHNvZnR3YXJlLCBvcmdhbml6YXRpb24sIGFuZCBvdGhlciBwaWVjZXMgb2Yg aW5mb3JtYXRpb24gdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uczxicj4NCiZndDsmZ3Q7 IC0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVycyBh bmQgYmluZGluZyByZXNvdXJjZSByZXF1ZXN0cyB0byB0b2tlbnMgYW5kIGFzc29jaWF0ZWQgY3J5 cHRvZ3JhcGhpYyBrZXlzPGJyPg0KJmd0OyZndDsgLSBPcHRpbWl6ZWQgaW5jbHVzaW9uIG9mIGFk ZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIChpbmNs dWRpbmcgaWRlbnRpdHkpPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQWRkaXRpb25hbGx5 LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhl IHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRpbmc6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgLSBEaXNjb3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyPGJyPg0KJmd0OyZndDsg LSBSZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbnM8YnI+DQomZ3Q7Jmd0OyAtIFF1ZXJ5IG9mIHRv a2VuIHJpZ2h0cyBieSByZXNvdXJjZSBzZXJ2ZXJzPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQg b3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3Ig T3BlbklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxsIGF0dGVtcHQgdG8gc2ltcGxpZnkgbWlncmF0 aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3IHByb3RvY29s IHdoZXJlIHBvc3NpYmxlLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoaXMgZ3JvdXAg aXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGV4dGVuc2lvbnMgdG8gT0F1dGggMi4wLCBhbmQg YXMgc3VjaCB3aWxsIGZvY3VzIG9uIG5ldyB0ZWNobm9sb2dpY2FsIHNvbHV0aW9ucyBub3QgbmVj ZXNzYXJpbHkgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1 aWxkcyBkaXJlY3RseSBvbiBPQXV0aCAyLjAgd2lsbCBiZSBkZXZlbG9wZWQgaW4gdGhlIE9BdXRo IFdvcmtpbmcgR3JvdXAsDQogaW5jbHVkaW5nIGZ1bmN0aW9uYWxpdHkgYmFjay1wb3J0ZWQgZnJv bSB0aGUgcHJvdG9jb2wgZGV2ZWxvcGVkIGhlcmUgdG8gT0F1dGggMi4wLjxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IFRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBtZWNoYW5p c21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1Y2ggYXMgSk9TRSBhbmQg Q09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91cCBpcyBub3QgY2hhcnRl cmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy4NCjxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IFRoZSBpbml0aWFsIHdvcmsgd2lsbCBmb2N1cyBvbiB1c2luZyBIVFRQ IGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbiBmZWF0dXJlcyBvZiBI VFRQMiBhbmQgSFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxsIHN0cml2ZSB0byBlbmFibGUg c2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXMNCiBDT0FQIHdoZW4gZG9p bmcgc28gZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgcHJpbWFyeSBmb2N1cy48YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBNaWxlc3RvbmVzIHRvIGluY2x1ZGU6PGJyPg0KJmd0OyZndDsg LSBDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2w8YnI+DQomZ3Q7Jmd0OyAtIEtleSBwcmVzZW50YXRp b24gbWVjaGFuaXNtIGJpbmRpbmdzIHRvIHRoZSBjb3JlIHByb3RvY29sIGZvciBUTFMsIGRldGFj aGVkIEhUVFAgc2lnbmF0dXJlLCBhbmQgZW1iZWRkZWQgSFRUUCBzaWduYXR1cmVzPGJyPg0KJmd0 OyZndDsgLSBJZGVudGl0eSBhbmQgYXV0aGVudGljYXRpb24gY29udmV5YW5jZSBtZWNoYW5pc21z PGJyPg0KJmd0OyZndDsgLSBHdWlkZWxpbmVzIGZvciB1c2Ugb2YgcHJvdG9jb2wgZXh0ZW5zaW9u IHBvaW50czxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0tIDxi cj4NCiZndDsmZ3Q7IFR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJt YWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9h Pjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90eGF1dGg8L2E+PGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFR4YXV0aCBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjxicj4N Ci0tIDxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQg U2FraW11cmEgKD1uYXQpPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KPGEgaHJlZj0iaHR0cDovL25hdC5z YWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9h Pjxicj4NCkBfbmF0X2VuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM6PR00MB0682ADE62F89284C8AA5F8B6F5F50DM6PR00MB0682namp_-- From nobody Fri Mar 20 12:28:46 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931BE3A0DB4 for ; Fri, 20 Mar 2020 12:28:33 -0700 (PDT) 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 9oMd8deV4kkX for ; Fri, 20 Mar 2020 12:28:27 -0700 (PDT) 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 EDDD03A0E14 for ; Fri, 20 Mar 2020 12:28:26 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id v4so1784379lfo.12 for ; Fri, 20 Mar 2020 12:28:26 -0700 (PDT) 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=AzJNp1rGhtLx8cD3vSB0Q3DWSsjdHzV0pIAkZJLnqzY=; b=XJfqu/4as6Q0kEgCS0bsY1SInLW9JEl+Rjq3WTjMY/5prBQABJ+a+wMHHP8ADTlVGG uq5+q4X7or0w9RTUmYgIbsKbTV1Vmf0cNCoCi/zqpAWu/po69BicP5rmhkbXQzpxqRu/ UHgAp1N/7x+FM2Ok8IcfAurqkE3dGWFs53ot758CDmJHCHqzqFXo6Fj+3jFhB7S6i7sZ VddA9Rtk4kLe7T4oYszKBarqfk1yYni4W4a/AONaum3w5LA0zDLdrimeNNKerPBZ4B05 /dqUAkt0FuxGBQZdNxEabEo6SPoWU9T6GF3/ILHtverd6Aglnle105ZfsrFTj7oPUOtq 7Bpw== 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=AzJNp1rGhtLx8cD3vSB0Q3DWSsjdHzV0pIAkZJLnqzY=; b=el/+7l9j7ke7utkWa0PiBsHLGim6ucUdmVTaMP62HKI82IMCur6p416+R7eZt5py9y ijclVtGuxkBe7A0kJHUjX7OP8YhDM7MdYkPRk2+fnJLM4mlGWyi4wT38myf8D2dBXcgn ycMwFtgA0RotIaKiUd3ISaEEOiqRvkG6uyPOCMetuwgP5XW3KvnHUrY67+L5nLJKGbsL 1j7qQa5yHN5hNqUvqZHxbFgCxB3VSCQZp/nZZ/as5RRNRkmR13bFq3i3y06f/5bY2z0v 00YPEKS7aFVSq3t9vpgbMDG9DEDC1Hgz3/mN5voF/wkcNGapVhGEXAERYVp3Tl81Ivc5 DvTw== X-Gm-Message-State: ANhLgQ3YTq+duiH891bQMMBmtJFoxbNMwGSS/sqCG+Xo4pM65jtmkQdj xswjiVozSCAOKbkHoqDakUy09hypiws3PEkplVs= X-Google-Smtp-Source: ADFU+vv+vnzDLNff4GVGmTSkux55flYl5V3JNNlhaelLNMR9xnrPFCWbtSzSgutguMjIOK/Dte6NOwL+yRWaTqo0RfA= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr736320lfm.91.1584732504758; Fri, 20 Mar 2020 12:28:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 12:27:58 -0700 Message-ID: To: Mike Jones Cc: Justin Richer , Yaron Sheffer , Torsten Lodderstedt , Nat Sakimura , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000002a0f505a14e4ad0" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 19:28:45 -0000 --00000000000002a0f505a14e4ad0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2020 at 11:47 AM Mike Jones wrote: > I agree with many of the points that Dick makes below =E2=80=93 especiall= y that we > should be reusing existing technologies where applicable and only inventi= ng > when doing so creates unique new value. > I like this phrasing. > > > *Reusing Existing Technology: *To the specific point about reusing > existing identity representations, I would request that this point be add= ed > to the charter: > > - The working group will not create new identity representations; it > may enable the use of existing identity representations or new identit= y > representations created by others. > > Why not use the same phrasing as above? The WG will reuse identity representations, and only create new representations if doing so creates unique, new value. I hope we don't need to create new representations, as it is non-trivial, but I would not want to constrain the group if we have the right collection of people to do it in the WG and we are creating unique, new value. > > - > > > > *AS<->RS relationship:* I believe that introspection is unnecessary for > many use cases, and indeed, requiring it would be a regression relative t= o > OAuth 2.0. Therefore, I support Dick=E2=80=99s proposed modification: > > - communication of token attributes between the authorization server > and resource server > > > > *OAuth 2.0 scopes: * I agree that the existing OAuth 2.0 scopes should be > easily used in requests and responses. > > > > -- Mike > > > > *From:* Txauth *On Behalf Of *Dick Hardt > *Sent:* Friday, March 20, 2020 11:04 AM > *To:* Justin Richer > *Cc:* Yaron Sheffer ; Torsten Lodderstedt < > torsten@lodderstedt.net>; Nat Sakimura ; Mike Jones > ; txauth@ietf.org > *Subject:* Re: [Txauth] Call for charter consensus - TxAuth WG > > > > Nat: thanks for chiming in. Useful insights as always! > > > > Vittorio: I'll reinterpret your statement about "marketing" the work, to > be that we should solve real problems that people don't have solutions fo= r > today. > > > > *AS<->RS relationship* > > > > TL;DR: I think the charter misses the mark in the AS<->RS relationship > being in scope and we should expand it. > > > > In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast to > OAuth 1.0, but the interactions / communication between the AS and the RS > were out of scope, as the uses cases at the time had the AS and RS operat= ed > by the same entity. New use cases have a weaker coupling between the AS a= nd > RS, and to enable interop, extensions have been written for Token > Introspection, and JWT Profile for OAuth 2.0 Access Tokens . > > > > The TxAuth charter includes introspection: > > > > - Query of token rights by resource servers > > > > -- but does not include the common design pattern where the RS can > directly interpret the token. > > > > Here is proposed updated text to the line above to be broader in scope > than just a query: > > > > - communication of token attributes between the authorization server and > resource server > > > > > > *Architecture and Use Case documents* > > > > TL;DR: Yes to use case doc, no to architecture doc. > > > > I agree with Justin that an architecture document is unlikely to prove > useful long term. I disagree with him on the use cases. I don't think the > use cases need to be exhaustive, but example use cases helps everyone > understand everyone else's primary use cases. If your use case is not > similar to others, then you should write it up and the WG can decide if i= t > is in scope or not. If it is, it gets added to the use case document. I > would consider this a living document while working on the core protocol. > It would NOT be a use case document that scopes the WG work. The charter > does that. It would be a companion document to the core protocol. I > strongly think a use case document resolves many of the miscommunications > that happen where people are talking past each other, because they don't > understand each other's use case. > > > > *Reusing Existing Technology* > > > > TL;DR: we should be reusing existing specifications where ever possible. > > > > Reading between the lines, I think the concern around identity may be tha= t > the TxAuth charter implies that the WG is going to create > yet-another-identity-representation and ignore all the previous efforts. = I > think creating yet-another-identity-representation to solve use cases tha= t > are already solved with existing representations would be misguided effor= t. > My own interest in TxAuth is being able to use one protocol to request an= d > receive any existing and future identity representation. One of my > motivations for writing the XAuth document was to show how different > representations could be requested and received, as this was missing in > XYZ. If a use case requires a new representation, then perhaps TxAuth ma= y > be a place for that work to happen, but I think it is more likely to happ= en > in other forums. > > > > It is not clear to me how, or if, reusing existing technology fits into > the charter, but I do strongly think it should be a tenet of the WG. > > > > On a related note, I also strongly think that the existing OAuth 2.0 > scopes should be easily used in requests and responses. XAuth shows an > example of how that can be done. > > > > /Dick > > > > > > > > > > On Fri, Mar 20, 2020 at 6:39 AM Justin Richer wrote: > > I agree with a lot of that argument. Let me see if I can more clearly > restate what I was trying to say earlier in this thread: the relationship= s > between the different parties are separable and depend on the kind of > deployments and use cases that are being addressed by people. So in an > OAuth/OIDC-style world, we=E2=80=99ve got three components (ignoring peop= le), and > three relationships between them: > > > > C<->AS > > > > C<->RS > > > > AS<->RS > > > > For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, =E2= =80=9Chow to use a > token=E2=80=9D, and =E2=80=9Chow to interpret a token=E2=80=9D. For authe= ntication, it=E2=80=99s > additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, =E2= =80=9Chow do I ask for a > profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80= =9D. I still believe this > is a good separation of concerns. The client doesn=E2=80=99t need to know= what=E2=80=99s in > the access token, or if it=E2=80=99s a reference or self-contained, or re= ally > concern itself at all with what the RS does with it. Are there overlaps? > Certainly =E2=80=94 the client needs to know how to ask for a token that = the RS > will accept for what the client is going to do, and to do that the client > needs to be able to describe what it wants to do in a way that the AS can > interpret and map to a set of rights that the RS will eventually interpre= t. > > > > I believe the proposed charter already covers this split with the > following items: > > > > - Fine-grained specification of access > - Approval of access to multiple resources and APIs in a single interacti= on > - Separation between the party authorizing access and the party operating > the client requesting access > > - Revocation of active tokens > - Query of token rights by resource servers > > > > It=E2=80=99s the combination of the rich request and the lifecycle manage= ment that > puts the AS and RS in scope. I think things like declaring a single token > format are absolutely out =E2=80=94 if you want to use JWT, or CWT, or UU= ID=E2=80=99s, > that=E2=80=99s all just fine. However, something that I think is in scope= is > defining a structure for what a token represents. And I think that if we > can do that in this WG in a general way, then that=E2=80=99s useful. Beca= use then > that structure can be represented by mapping to a token format or an > introspection response or a database entry. I think Nat=E2=80=99s comment= s on ABAC > are important: we are going to need a place to put those attributes. > Whether they=E2=80=99re communicated to the RS through the token itself o= r through > some other channel is, I strongly believe, a matter of deployment choice. > > > > So, what can the charter say to make this more clear? > > > > All that said, I=E2=80=99m against having an architecture document as a w= orking > group output. In my experience, when a WG puts its effort into a formal > architecture doc *as a deliverable*, there is a lot of conjectural energy > that goes into what might be a good idea, and then not all of it works ou= t > when you try to hammer the details of making that architecture into a rea= l > engineered thing.You end up baking in assumptions and abstractions that > don=E2=80=99t make sense anymore, and then trying to engineer solutions a= round > those when they don=E2=80=99t fit right. If the architecture can=E2=80=99= t change in light > of new information, which is the case with an RFC, then it becomes a > shackle instead of a scaffold. But a malleable document that the group ca= n > use as a guide while engineering the actual parts =E2=80=94 yes, that mak= es sense. > The architecture can be refactored and changed as decisions are made and > things come into focus. I feel the same about use case documents as forma= l > artifacts. > > > > Thanks, Nat. > > =E2=80=94 Justin > > > > On Mar 20, 2020, at 2:19 AM, Nat Sakimura wrote: > > > > I thought I should keep my mouth shut as anything I say may be deemed > biased as my other hat is the chairman of OIDF, but here is my 2c. > > > > As Torsten indicated, there is much to be desired to standardize the AS - > RS communication patterns. You may say that the charter includes it, but = I > cannot read it out of the charter just like Torsten could not. As a new > protocol, it would be good to include it. > > > > In this respect, I am not sure if we should start off from OAuth 2.0 and > OIDC model. If we are creating a new protocol, I feel that we should > architect is more fully. Not mentioning AS - RS relationship to me feels > like an indication of this failure. For that matter, I feel that the firs= t > output of the group should be an architecture document that takes the > concerns from all the relevant stakeholders/actors in. > > > > We should also be cognizant of the access control models like ABAC. For > that, decoupling of identity (=3D set of claims) assertion and authorizat= ion > is a necessity. We could optimize it but the base case should take care o= f > it. (In this respect, I am feeling that OIDC has perhaps over-optimized.) > So, I feel that at least as the first step, TxAuth should concentre on th= e > Access Control. If I were to go one step further, it should be modelled s= o > that it can consume various identity assertions (authenticated identity i= n > ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable > Credentials, X.509 certificates (such as in eIDAS and Japanese National I= D > scheme) etc. We are not going to get to a unified identity world anytime > soon. > > > > Cheers, > > > > Nat Sakimura > > > > > > On Wed, Mar 18, 2020 at 7:06 AM Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > I believe it's significant that four people have expressed concerns with > including digital identity in the charter (the only concerns voiced as fa= r > as I can tell). At a minimum, I believe that that warrants making the > inclusion or exclusion of digital identity a discussion topic during the > upcoming virtual BoF, before adopting any charter. > > It would be my proposal to initially charter without digital identity and > see how far we get with our energies intentionally focused in that way. = If > the working group decides to recharter to include digital identity, that > can always happen later, after the authorization-focused work has matured= , > and once there's a clear case to actually do so. > > -- Mike > > -----Original Message----- > From: Justin Richer > Sent: Tuesday, March 17, 2020 2:20 PM > To: Mike Jones > Cc: Yaron Sheffer ; Torsten Lodderstedt < > torsten@lodderstedt.net>; txauth@ietf.org > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > > While I understand the concerns around identity in the charter, and I had > initially not included it, I was convinced that the kind of identity > protocol that we=E2=80=99re looking at here is a minor addition to the > authorization and delegation end of things. > > As you know, much of what=E2=80=99s in OIDC is there to fix problems with= OAuth 2 > when it=E2=80=99s used for identity. If OAuth 2 had solved those problems > internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now > starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know > what other problems there might be. > > The market has shown us that the most common application of OAuth 2 is fa= r > and away access to identity information along side access to an API. I > think we need to pay attention to that and not make this separate just > because we did it that way before. And some of the proposed innovations, > including getting and sending VC=E2=80=99s, are all about identity. > > Furthermore, this charter does not specify the document and specification > structure of the components, nor does it specify the publication order or > timing of any documents. I personally think that the identity layer shoul= d > be separable to an extent, to the point of publishing that layer in its o= wn > spec alongside the core authorization delegation system. However, that do= es > not mean that it should be developed elsewhere. > > If there is better language to tighten the aspects of an identity protoco= l > that we will explicitly cover, then I would welcome you to suggest an > amended text to the charter. However, I believe there is enough interest > within the community to work on identity in the context of this protocol, > including a large number of people being OK with it in the charter, that = it > would not be a reasonable thing to remove it. > > =E2=80=94 Justin > > > On Mar 17, 2020, at 1:12 PM, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > > > > 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > > > I share the concerns about including identity in the charter that were > expressed by Torsten and agreed with by David Skaife. I'll note that Kim > Cameron previously expressed concerns about including identity in his > earlier charter critique at > https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/= . > > > > I'm fine with refactoring the authorization protocol. But identity > should be decoupled from the TxAuth work to focus its scope on areas wher= e > innovation is being proposed. Digital identity can always be added as a > layer if needed, just as OpenID Connect layered identity onto OAuth 2.0. > > > > Please revise the charter to remove digital identity from the scope of > the work. > > > > 2. Are you willing to author or participate in the development of the > drafts of this WG? > > > > Yes > > > > 3. Are you willing to help review the drafts of this WG? > > > > Yes > > > > 4. Are you interested in implementing drafts of this WG? > > > > Not at this time. > > > > -- Mike > > > > -----Original Message----- > > From: Txauth On Behalf Of Torsten Lodderstedt > > Sent: Saturday, March 7, 2020 7:18 AM > > To: Yaron Sheffer > > Cc: txauth@ietf.org > > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG > > > > Hi, > > > >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer : > >> > >> =EF=BB=BFHi Everyone, > >> > >> It appears that momentum is forming around the proposed formation of a > TxAuth working group. We=E2=80=99d like to more formally gauge interest = in > proceeding with this work. Please do so by responding to the following > questions: > >> > >> 1. Do you support the charter text provided at the end of this email? > Or do you have major objections, blocking concerns or feedback (if so > please elaborate)? > > > > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned = the scope of the > charter is too broad, e.g. identify alone is a huge topic.. > > > > We need to keep an eye on this aspect in order to make sure, the group > is able to work effectively and the specs we will be producing are as > simple as possible and foster interoperability. > > > >> > >> 2. Are you willing to author or participate in the development of the > drafts of this WG? > > > > yes > > > >> > >> 3. Are you willing to help review the drafts of this WG? > > > > yes > > > >> > >> 4. Are you interested in implementing drafts of this WG? > > > > yes > > > > best regards, > > Torsten. > > > >> > >> The call will run for two weeks, until March 21. If you think that the > charter should be amended In a significant way, please reply on a separat= e > thread. > >> > >> The feedback provided here will help the IESG come to a decision on th= e > formation of a new WG. Given the constraints of the chartering process, > regardless of the outcome of this consensus call, we will be meeting in > Vancouver as a BoF. > >> > >> Thanks, > >> Yaron and Dick > >> > >> --- Charter Text Follows --- > >> > >> This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > >> > >> The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > >> > >> Additionally, the delegation process will allow for: > >> > >> - Fine-grained specification of access > >> - Approval of AS attestation to identity claims > >> - Approval of access to multiple resources and APIs in a single > interaction > >> - Separation between the party authorizing access and the party > operating the client requesting access > >> - A variety of client applications, including Web, mobile, single-page= , > and interaction-constrained applications > >> > >> The group will define extension points for this protocol to allow for > flexibility in areas including: > >> > >> - Cryptographic agility for keys, message signatures, and proof of > possession > >> - User interaction mechanisms including web and non-web methods > >> - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > >> - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > >> - Optimized inclusion of additional information through the delegation > process (including identity) > >> > >> Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > >> > >> - Discovery of the authorization server > >> - Revocation of active tokens > >> - Query of token rights by resource servers > >> > >> Although the artifacts for this work are not intended or expected to b= e > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > >> > >> This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > >> > >> The group is chartered to develop mechanisms for applying cryptographi= c > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > >> > >> The initial work will focus on using HTTP for communication between th= e > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > >> > >> Milestones to include: > >> - Core delegation protocol > >> - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > >> - Identity and authentication conveyance mechanisms > >> - Guidelines for use of protocol extension points > >> > >> > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --00000000000002a0f505a14e4ad0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 20, 2020 at 11:47 AM Mike= Jones <Michael.Jones@mic= rosoft.com> wrote:

I agree with many= of the points that Dick makes below =E2=80=93 especially that we should be= reusing existing technologies where applicable and only inventing when doi= ng so creates unique new value.

I like this phrasing.
=C2=A0

=C2=A0<= /u>

Reusing Existing Technology: To the specific point about reusing existing identity re= presentations, I would request that this point be added to the charter:<= /u>

  • The working group will not create new identity representations; it may enab= le the use of existing identity representations or new identity representat= ions created by others.

Why not use the same phrasing as above?

The WG will reuse=C2=A0identity representations, and only cr= eate new representations if doing so creates unique, new value.
=

I hope we don&#= 39;t need to create new representations, as it is non-trivial, but I would = not want to constrain the group if we have the right collection of people t= o do it in the WG and we are creating unique, new value.
=C2=A0
<= div class=3D"gmail-m_-931027204636000034WordSection1">

=C2=A0<= /u>

AS<->RS relationship: I believe that introspection is unnecessary for many use = cases, and indeed, requiring it would be a regression relative to OAuth 2.0= .=C2=A0 Therefore, I support Dick=E2=80=99s proposed modification:

  • communication of token attributes between the authorization server and reso= urce server

=C2=A0<= /u>

OAuth 2.0 scopes: =C2=A0I agree that the existing OAuth 2.0 scopes should be easily used in requests and = responses.

=C2=A0

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

=C2=A0<= /u>

From: Txauth <txauth-bounces@ietf.org> On Beha= lf Of Dick Hardt
Sent: Friday, March 20, 2020 11:04 AM
To: Justin Richer <jricher@mit.edu>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.n= et>; Nat Sakimura <sakimura@gmail.com>; Mike Jones <Michael.Jones=3D40microsoft= .com@dmarc.ietf.org>; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG<= u>

=C2=A0

Nat: thanks for chiming in. Useful=C2=A0insights as = always!

=C2=A0

Vittorio: I'll reinterpret your statement about = "marketing" the work, to be that we should solve real problems th= at people don't have solutions for today.=C2=A0

=C2=A0

AS<->RS relationship

=C2=A0

TL;DR: I think the charter misses the mark in the AS= <->RS relationship being in scope and we should expand it.<= /u>

=C2=A0

In OAuth 2.0 (RFC6749)l, the AS and RS were separate= roles in contrast to OAuth 1.0, but the interactions / communication betwe= en the AS and the RS were out of scope, as the uses cases at the time had t= he AS and RS operated by the same entity. New use cases have a weaker coupling between the AS and RS, and to= enable interop, extensions have been written for Token Introspection, and = JWT Profile for OAuth 2.0 Access Tokens .=C2=A0

=C2=A0

The TxAuth charter includes introspection:=

=C2=A0

- Query of token rights by resource servers=C2=A0=

=C2=A0

-- but does not include the common design pattern wh= ere the RS can directly interpret the token.

=C2=A0

Here is proposed updated=C2=A0text to the line above= to be broader in scope than just a query:

=C2=A0

- communication=C2=A0of token attributes=C2=A0betwee= n the authorization server and resource server

=C2=A0

=C2=A0

Architecture and Use Case documents=

=C2=A0

TL;DR: Yes to use case doc, no to architecture doc.<= u>

=C2=A0

I agree with Justin that an architecture=C2=A0docume= nt is unlikely to prove useful long term. I disagree with him on the use ca= ses. I don't think the use cases need to be exhaustive, but example use= cases helps everyone understand everyone else's primary use cases. If your use case is not similar to others, then you sho= uld write it up and the WG can decide if it is in scope or not. If it is, i= t gets added to the use case document. I would consider this a living docum= ent while working on the core protocol. It would NOT be a use case document that scopes the WG work. The charter d= oes that. It would be a companion document to the core protocol. I strongly= think a use case document resolves many of the miscommunications that happ= en where people are talking past each other, because they don't understand each other's use case.

=C2=A0

Reusing Existing Technology

=C2=A0

TL;DR: we should be reusing existing specifications = where ever possible.

=C2=A0

Reading between the lines, I think the concern aroun= d identity may be that the TxAuth charter implies that the WG is going to c= reate yet-another-identity-representation and ignore all the previous effor= ts. I think creating=C2=A0yet-another-identity-representation to solve use cases that are already solved with existing representations w= ould be misguided effort. My own interest in TxAuth is being able to use on= e protocol to request and receive any existing and future identity represen= tation. One of my motivations for writing the XAuth document was to show how different representations could= be requested and received, as this was missing in XYZ.=C2=A0 If a use case= requires a new representation, then perhaps TxAuth may be a place for that= work to happen, but I think it is more likely to happen in other forums.

=C2=A0

It is not clear to me how, or if, reusing existing t= echnology fits into the charter, but I do strongly think it should be a ten= et of the WG.

=C2=A0

On a related note, I also strongly think that the ex= isting OAuth 2.0 scopes should be easily used in requests and responses. XA= uth shows an example of how that can be done.

=C2=A0

/Dick=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Mar 20, 2020 at 6:39 AM Justin Richer <jricher@mit.edu> = wrote:

I agree with a lot of that argument. Let me see if I= can more clearly restate what I was trying to say earlier in this thread: = the relationships between the different parties are separable and depend on= the kind of deployments and use cases that are being addressed by people. So in an OAuth/OIDC-style world, we=E2= =80=99ve got three components (ignoring people), and three relationships be= tween them:

=C2=A0

C<->AS

=C2=A0

C<->RS

=C2=A0

AS<->RS

=C2=A0

For authorization, these map to =E2=80=9Chow to get = a token=E2=80=9D, =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow to= interpret a token=E2=80=9D. For authentication, it=E2=80=99s additionally = =E2=80=9Chow do I get the authentication info=E2=80=9D, =E2=80=9Chow do I a= sk for a profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80=9D. I still believe this is a good separation of con= cerns. The client doesn=E2=80=99t need to know what=E2=80=99s in the access= token, or if it=E2=80=99s a reference or self-contained, or really concern= itself at all with what the RS does with it. Are there overlaps? Certainly =E2=80=94 the client needs to know how to ask for a token that t= he RS will accept for what the client is going to do, and to do that the cl= ient needs to be able to describe what it wants to do in a way that the AS = can interpret and map to a set of rights that the RS will eventually interpret.=C2=A0

=C2=A0

I believe the proposed charter already covers this s= plit with the following items:

=C2=A0

- Fine-grained specification of access
- Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operating t= he client requesting access

- Revocation of active tokens
- Query of token rights by resource servers

=C2=A0

It=E2=80=99s the combination of the rich request and= the lifecycle management that puts the AS and RS in scope. I think things = like declaring a single token format are absolutely out =E2=80=94 if you wa= nt to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just fine. However, something that I think is in scope is defining a structure = for what a token represents. And I think that if we can do that in this WG = in a general way, then that=E2=80=99s useful. Because then that structure c= an be represented by mapping to a token format or an introspection response or a database entry. I think Nat=E2=80= =99s comments on ABAC are important: we are going to need a place to put th= ose attributes. Whether they=E2=80=99re communicated to the RS through the = token itself or through some other channel is, I strongly believe, a matter of deployment choice.

=C2=A0

So, what can the charter say to make this more clear= ?

=C2=A0

All that said, I=E2=80=99m against having an archite= cture document as a working group output. In my experience, when a WG puts = its effort into a formal architecture doc as a deliverable, there is a lot of conjectural energy that goes int= o what might be a good idea, and then not all of it works out when you try = to hammer the details of making that architecture into a real engineered th= ing.You end up baking in assumptions and abstractions that don=E2=80=99t make sense anymore, and then trying to= engineer solutions around those when they don=E2=80=99t fit right. If the = architecture can=E2=80=99t change in light of new information, which is the= case with an RFC, then it becomes a shackle instead of a scaffold. But a malleable document that the group can use as a guide whi= le engineering the actual parts =E2=80=94 yes, that makes sense. The archit= ecture can be refactored and changed as decisions are made and things come = into focus. I feel the same about use case documents as formal artifacts.=C2=A0

=C2=A0

Thanks, Nat.

=C2=A0=E2=80=94 Justin



On Mar 20, 2020, at 2:19 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0

I thought I should keep my mouth=C2=A0shut as anythi= ng I say may be deemed biased as my other hat is the chairman of OIDF, but = here is my 2c.=C2=A0

=C2=A0

As Torsten indicated, there is much to be desired to= standardize the AS - RS communication patterns. You may say that the chart= er includes it, but I cannot read it out of the charter just like Torsten c= ould not. As a new protocol, it would be good to include it.=C2=A0

=C2=A0

In this respect, I am not sure if we should start of= f from OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel = that we should architect is more fully. Not mentioning AS - RS relationship= to me feels like an indication of this failure. For that matter, I feel that the first output of the group s= hould be an architecture document that takes the concerns from all the rele= vant stakeholders/actors in.=C2=A0

=C2=A0

We should also be cognizant of the access=C2=A0contr= ol models like ABAC. For that, decoupling of identity (=3D set of claims) a= ssertion and authorization is a necessity. We could optimize it but the bas= e case should take care of it. (In this respect, I am feeling that OIDC has perhaps over-optimized.) So, I feel that at lea= st as the first step, TxAuth should concentre on the Access Control. If I w= ere to go one step further, it should be modelled so that it can consume va= rious identity assertions (authenticated identity in ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID V= erifiable Credentials, X.509 certificates (such as in eIDAS and Japanese Na= tional ID scheme)=C2=A0 etc. We are not going to get to a unified identity = world anytime soon.=C2=A0

=C2=A0

Cheers,=C2=A0

=C2=A0

Nat Sakimura

=C2=A0

=C2=A0

On Wed, Mar 18, 2020 at 7:06 AM Mike Jones <Micha= el.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I believe it's significant that four people have= expressed concerns with including digital identity in the charter (the onl= y concerns voiced as far as I can tell).=C2=A0 At a minimum, I believe that= that warrants making the inclusion or exclusion of digital identity a discussion topic during the upcoming virtual BoF, be= fore adopting any charter.

It would be my proposal to initially charter without digital identity and s= ee how far we get with our energies intentionally focused in that way.=C2= =A0 If the working group decides to recharter to include digital identity, = that can always happen later, after the authorization-focused work has matured, and once there's a clear case = to actually do so.

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

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net&= gt;; txauth@ietf.org Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had i= nitially not included it, I was convinced that the kind of identity protoco= l that we=E2=80=99re looking at here is a minor addition to the authorizati= on and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems with O= Auth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now starting at a base where those problems don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems there might be. <= br>
The market has shown us that the most common application of OAuth 2 is far = and away access to identity information along side access to an API. I thin= k we need to pay attention to that and not make this separate just because = we did it that way before. And some of the proposed innovations, including getting and sending VC=E2=80=99s, a= re all about identity.

Furthermore, this charter does not specify the document and specification s= tructure of the components, nor does it specify the publication order or ti= ming of any documents. I personally think that the identity layer should be= separable to an extent, to the point of publishing that layer in its own spec alongside the core authoriz= ation delegation system. However, that does not mean that it should be deve= loped elsewhere.

If there is better language to tighten the aspects of an identity protocol = that we will explicitly cover, then I would welcome you to suggest an amend= ed text to the charter. However, I believe there is enough interest within = the community to work on identity in the context of this protocol, including a large number of people being = OK with it in the charter, that it would not be a reasonable thing to remov= e it.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
>
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?
>
> I share the concerns about including identity in the charter that were= expressed by Torsten and agreed with by David Skaife.=C2=A0 I'll note = that Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.
>
> I'm fine with refactoring the authorization protocol.=C2=A0 But id= entity should be decoupled from the TxAuth work to focus its scope on areas= where innovation is being proposed.=C2=A0 Digital identity can always be a= dded as a layer if needed, just as OpenID Connect layered identity onto OAuth 2.0.
>
> Please revise the charter to remove digital identity from the scope of= the work.
>
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?
>
> Yes
>
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.o= rg
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>: >>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed formation = of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in proceeding with this work.=C2=A0 Please do so by responding to t= he following questions:
>>
>> 1.=C2=A0 Do you support the charter text provided at the end of th= is email?=C2=A0 Or do you have major objections, blocking concerns or feedb= ack (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the charter is too broad, e.g. identify alone is a huge topic= ..
>
> We need to keep an eye on this aspect in order to make sure, the group= is able to work effectively and the specs we will be producing are as simp= le as possible and foster interoperability.
>
>>
>> 2.=C2=A0 Are you willing to author or participate in the developme= nt of the drafts of this WG?
>
> yes
>
>>
>> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> yes
>
>>
>> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think that= the charter should be amended In a significant way, please reply on a sepa= rate thread.
>>
>> The feedback provided here will help the IESG come to a decision o= n the formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation proto= col for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an author= ization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an = extension of OAuth 2.0) to support authorizations scoped as narrowly as a s= ingle transaction, provide a clear framework for interaction among all part= ies involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinat= ing interactions.
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the de= legation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which = is initiated by the client redirecting the user=E2=80=99s browser). The cli= ent and AS will involve a user to make an authorization decision as necessa= ry through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and = technical challenges of OAuth 2.0 and provides a non-invasive path for supp= orting future types of clients and interaction channels.
>>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single in= teraction
>> - Separation between the party authorizing access and the party op= erating the client requesting access
>> - A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof of= possession
>> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other= pieces of information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding= resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the delega= tion process (including identity)
>>
>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new= protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OA= uth 2.0.
>>
>> The group is chartered to develop mechanisms for applying cryptogr= aphic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication betwee= n the client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable simp= le mapping to other protocols such as COAP when doing so does not conflict with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for TLS= , detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth


=C2=A0

--

Nat Sakimura (=3Dnat)

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

=C2=A0

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

--00000000000002a0f505a14e4ad0-- From nobody Fri Mar 20 12:32:03 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF43A0D29 for ; Fri, 20 Mar 2020 12:32:00 -0700 (PDT) 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_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=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 AGRdkqU430Eg for ; Fri, 20 Mar 2020 12:31:58 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 A16D93A0D21 for ; Fri, 20 Mar 2020 12:31:58 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id r22so657766ljh.0 for ; Fri, 20 Mar 2020 12:31:58 -0700 (PDT) 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=gMNH7WQd/aigc4S0Lnwg/xVba4W7PYNyG/oGXFD2r2U=; b=h80PglNhOUkkPWnoQrtyJjQUWrcC2Gjxo5jx3i7/MO53T6WaxEgUAWlL9t/kEk807+ jglw4ytMf29OtHIPXpsBip9jnSlNGG79dqbusLkHlGeIM6lRHezYELTeb9J7HfQj9SZ4 gnjdlm4XFmO+F42uNb4m7xprjv3bzsVc88PkxIeDfFCZPWSSk84yKymIFdFER8dbp4y0 /UG23uQwqXZxcbvmrDPuoI9oqpqMO4We84/CEM/goicRru6Vd2GWA4Nu0vtVMAR8auuW IalbfclbOx2RkICtpoZlLAoQEegU86lGcU+5RbxHzKnPaCFdbhalVRFyY88xZT3ib9W8 rvgA== 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=gMNH7WQd/aigc4S0Lnwg/xVba4W7PYNyG/oGXFD2r2U=; b=JO3duoneo6+ZUlJRFKuxKLS2SWeWYwMpfrKsAMv6rpwKU3BzG1Z5CIPzccN+OJhRcf z4c2SIpwmLJpbnaOSnRU1uI9mkrQSWQD018BMJushvh6kEDRWj+ETctdeCQBCJ3MXYCh 9P6TXypEgfpbG2jaUKL2NehKI2GIfUlNCoZCv3BvVaoE5VYOi1U7dBXKN3eYmbfVgTZv eBJ9xsjhhiEJ/JgNdTcGXN2Cy+MdnbRU3mOz3Qkgr1FjMwlhnAV6KGupewydVH6KSzR+ I1BheDjXqWtq8Do8m33vH5W9xZht7zAPG9HohNXjb52BP7+8T+Sjb3Dt+ybUihfymRtr haKA== X-Gm-Message-State: ANhLgQ0bUDWLyE3+LWiO874Q9qGrx8bTTVQEgvMQM0v0ZWFP2Z3fi5fr pNZv+8B9wlE3tO4GD5j98QKCIpLrN+CaN1J8wFDN0RPe X-Google-Smtp-Source: ADFU+vt9nuyD/y/6SlGClhsU2jx+wEJ6frQsn1igT7Yq9ZeoMYeVPJLgp6err2tSaiE60tSpl+Mrge4jN6Zo0ygaEcQ= X-Received: by 2002:a2e:9a0d:: with SMTP id o13mr6163846lji.151.1584732716561; Fri, 20 Mar 2020 12:31:56 -0700 (PDT) MIME-Version: 1.0 References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <8CA9DB9C-017C-4CF8-88F2-08823CD26256@mit.edu> In-Reply-To: <8CA9DB9C-017C-4CF8-88F2-08823CD26256@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 12:31:30 -0700 Message-ID: To: Roman Danyliw , Benjamin Kaduk Cc: Yaron Sheffer , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000a2787e05a14e5601" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 19:32:02 -0000 --000000000000a2787e05a14e5601 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roman / Ben Is there a reason we can't change the name of the list, or create a new list when the WG is formed? On Tue, Mar 17, 2020 at 6:10 AM Justin Richer wrote: > And another thought =E2=80=94 there=E2=80=99s a pretty decent chance that= we=E2=80=99ll end up > branding this whole effort OAuth 3 in the future. > > The list is named =E2=80=98txauth=E2=80=99. Therefore, calling what we=E2= =80=99re working on > anything different from that seems silly and premature. > > I say we just stick with TxAuth to match the list and avoid the whole > naming discussion entirely. > > =E2=80=94 Justin > > On Mar 16, 2020, at 9:56 PM, Justin Richer wrote: > > Yes, naming things is hard =E2=80=94 but I still believe in the name TxAu= th. We=E2=80=99re > moving beyond OAuth, and taking the process of getting an authorization > delegated to the client software as a multi-step, multi-party transaction > is, I believe, the key insight that=E2=80=99s letting us move beyond OAut= h=E2=80=99s > limitations here. It=E2=80=99s not just about going to the AS first =E2= =80=94 we had that > in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I reall= y think > it=E2=80=99s about the transaction at the core. > > Having come of age in the 1990=E2=80=99s, I have particular dislike for X= Auth. It > sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and = if you read either of those with a > growling yell in your head then you know exactly what I=E2=80=99m talking= about. > And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT s= ee this > work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think that= does a disservice > to the kind of change we have an opportunity to make here. > > =E2=80=94 Justin > > On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: > > Hello everyone > > I prompted a thread around the name of the protocol a while back: > > https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ > > As Justin stated "naming is hard" > > Wearing my marketing hat I want to ensure that the name will be > perceived properly in the broader community. > > A recent example that comes to mind are the privacy related works on the > browser storage API. Given that name, one would think that it is local > storage. It is actually about browser cookies. > > Justin discussed his reasons for TxAuth in the thread above (and I'm sure > in other places) > > I chose XAuth in my draft to reflect the eXtensibility goal that we have > over OAuth -- and XAuth is OAuth but with an X to reflect all the extra > features. =3D) > > Other suggestions? > > This will be an agenda item in the BoF -- but the name will NOT be an ope= n > discussion item -- we will summarize what has been discussed on the list > and perhaps do a poll of options presented unless consensus is obvious fr= om > this thread. > > /Dick > > > > > > =E1=90=A7 > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000a2787e05a14e5601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roman / Ben

Is there a reason we can= 9;t change the name of the list, or create a new list when the WG is formed= ?

On Tue, Mar 17, 2020 at 6:10 AM Justin Richer <jricher@mit.edu> wrote:
=
And another thought = =E2=80=94 there=E2=80=99s a pretty decent chance that we=E2=80=99ll end up = branding this whole effort OAuth 3 in the future.=C2=A0

= The list is named =E2=80=98txauth=E2=80=99. Therefore, calling what we=E2= =80=99re working on anything different from that seems silly and premature.=

I say we just stick with TxAuth to match the list= and avoid the whole naming discussion entirely.

= =C2=A0=E2=80=94 Justin

On Mar 16= , 2020, at 9:56 PM, Justin Richer <jricher@mit.edu> wrote:

Yes, naming things is hard =E2=80=94 but I still believe in the name T= xAuth. We=E2=80=99re moving beyond OAuth, and taking the process of getting= an authorization delegated to the client software as a multi-step, multi-p= arty transaction is, I believe, the key insight that=E2=80=99s letting us m= ove beyond OAuth=E2=80=99s limitations here. It=E2=80=99s not just about go= ing to the AS first =E2=80=94 we had that in OAuth 1 and we=E2=80=99re patc= hing that into OAuth 2 with PAR. I really think it=E2=80=99s about the tran= saction at the core.=C2=A0

Having come of age in the 199= 0=E2=80=99s, I have particular dislike for XAuth. It sounds too =E2=80=9CX-= TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you read either of th= ose with a growling yell in your head then you know exactly what I=E2=80=99= m talking about. And to Dick=E2=80=99s rationale for the name below, I abso= lutely do NOT see this work as =E2=80=9COAuth with all the extra features= =E2=80=9D. I think that does a disservice to the kind of change we have an = opportunity to make here.=C2=A0

=C2=A0=E2=80=94 Ju= stin

On Mar 16, 2020, at 7:04 PM= , Dick Hardt <= dick.hardt@gmail.com> wrote:

Hello ev= eryone

I prompted a thread around the name of the pr= otocol a while back:




--
Txauth mailing list
Txauth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/txauth
<= br>
--000000000000a2787e05a14e5601-- From nobody Fri Mar 20 12:32:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3F83A0D3A for ; Fri, 20 Mar 2020 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_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=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 GIA6IZGMHeyY for ; Fri, 20 Mar 2020 12:32:48 -0700 (PDT) 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 279AF3A0D29 for ; Fri, 20 Mar 2020 12:32:48 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id m15so5495261lfp.2 for ; Fri, 20 Mar 2020 12:32:47 -0700 (PDT) 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=RBwA1mK7V5iipgjr7aKgPvCw+SGjfEXyafyr0ZmvsnE=; b=B0Y4fX/2kD3ADmRRZzb7i9LLrVsfR8HuRhcqg+SlYtO39MqMfKEsnK0dmA0gT7f3/X JCY77QeK7XxFTH9/yLnPvppO9XqwwmQA4dcgYTQpy+b0hzZLj/tHBEtssIDUacCy57VO 0ESOtAkxgYBCf9iTzn0verdnjn8+OkHD+drUxSaYS5gAgMG7MpNiRN+kPPjaG0S2oRDG lv/f/ICdNYhjP0D9o6RcE4IY7w71EiavdcntkWE1HF7faDkbHa1bHcjgHQWlMqy3Vajc bXw/86VZde/36L5QPOpynpj7rlUDmcdnHjdVNRYb2AXkbZDaDwcX/msM+2z9DKIHi4up iSfA== 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=RBwA1mK7V5iipgjr7aKgPvCw+SGjfEXyafyr0ZmvsnE=; b=ba1G3yRi9WoNpNxQUk6EWlJfsrk5ehEVHN10WuA0FeyThuCUG1OVVv7BHGmGoe69jO uFbA6NeDDifA0uBZu6Gzbc6zRe5fqnhTAkZ7q3jKqZer4vZdeEhiXS6H8AHRyJdhiP2z +S+E0q4tndK8zsPoBtf1ORlncyQVXbil0FneZh9JLHRWHg6TyG2fmGCi94w6MpWJB6TT gxeZFof9+TU9uHFX+tdt0sN0T+g9jZFyPORC0jXmPqfDAaEIwSySsHwYB56ibX+NxK4K GnLCvWqDHW7CZFK4e0/Z6uj4XFySA8aBRM3K6JmBItQ4qeK5j6ZM6wim+hU5361MH4y2 HfeA== X-Gm-Message-State: ANhLgQ1kDT/UdsBkd5a4WWKypy0Vt/k7kvTxFTxIH47Um+EdgLyyJYrA ccNCxCKtk066xP1hvZsA8nQ5dyvQi0q8KGaRBV8= X-Google-Smtp-Source: ADFU+vskTJICNFA4od9XL3mugH3No6Dc/LLtBT6eosGyviIYupmOUTarYebyo9xOLJkDMKmjWURenrnwRcGAMQQG3UI= X-Received: by 2002:a19:4cc2:: with SMTP id z185mr6345451lfa.0.1584732766016; Fri, 20 Mar 2020 12:32:46 -0700 (PDT) MIME-Version: 1.0 References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> In-Reply-To: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 12:32:19 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000951b3005a14e59a2" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 19:32:51 -0000 --000000000000951b3005a14e59a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable not a transaction - there are multiple transactions backchannel innovation is combination of here is who I am, and here is what I want to do childhood trauma therapy group On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: > Yes, naming things is hard =E2=80=94 but I still believe in the name TxAu= th. We=E2=80=99re > moving beyond OAuth, and taking the process of getting an authorization > delegated to the client software as a multi-step, multi-party transaction > is, I believe, the key insight that=E2=80=99s letting us move beyond OAut= h=E2=80=99s > limitations here. It=E2=80=99s not just about going to the AS first =E2= =80=94 we had that > in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I reall= y think > it=E2=80=99s about the transaction at the core. > OAuth 2.0 had multi-step, multi-party. TxAuth extends that. I think the big shift is going to the AS. This enables the request to be richer with JSON, instead of name/value pairs parameters in a URI. It allows the client and AS to negotiate, and to short circuit having to redirect the user to the AS. PAR does some of this, but it is constrained by having to do it in the OAuth 2.0 context. My concern is that the protocol is MUCH MORE than a transaction. While the initial interaction between client, AS, user and RO is a transaction. The protocol also covers the client and RS interactions. The access token refreshes. Access token revocation. Access token introspection. As described in the charter, there is a whole lifecycle, that consists of multiple transactions. >From https://www.merriam-webster.com/dictionary/transaction: Definition of *transaction* 1a: something transacted especially : an exchange or transfer = of goods, services, or fundselectronic transactions b: transactions plural : the often published record of the meeting of a society or association 2a: an act, process, or instance of transacting b: a communicative action or activity involving two parties or things that reciprocally affect or influence each other Calling the protocol a transaction will confusing to people. > > Having come of age in the 1990=E2=80=99s, I have particular dislike for X= Auth. It > sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and = if you read either of those with a > growling yell in your head then you know exactly what I=E2=80=99m talking= about. > In case you are confused, this is not a childhood trauma support group. :) Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. X-Men, Xbox, X-Factor, X-files. https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 https://english.stackexchange.com/questions/358181/whats-the-purpose-of-usi= ng-letter-x-or-x-as-a-suffix-in-brand-names > And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT s= ee this > work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think that= does a disservice > to the kind of change we have an opportunity to make here. > >From the charter "It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0)" Which sounds pretty similar to =E2=80=9COAuth with all the extra features= =E2=80=9D While I think XAuth captures what we are doing, a placeholder name would be preferable to an incorrect descriptive name such as TxAuth. For example, XYZ is a good placeholder name. Or XYZAuth. Let's not mislead people. > > =E2=80=94 Justin > > On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: > > Hello everyone > > I prompted a thread around the name of the protocol a while back: > > https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ > > As Justin stated "naming is hard" > > Wearing my marketing hat I want to ensure that the name will be > perceived properly in the broader community. > > A recent example that comes to mind are the privacy related works on the > browser storage API. Given that name, one would think that it is local > storage. It is actually about browser cookies. > > Justin discussed his reasons for TxAuth in the thread above (and I'm sure > in other places) > > I chose XAuth in my draft to reflect the eXtensibility goal that we have > over OAuth -- and XAuth is OAuth but with an X to reflect all the extra > features. =3D) > > Other suggestions? > > This will be an agenda item in the BoF -- but the name will NOT be an ope= n > discussion item -- we will summarize what has been discussed on the list > and perhaps do a poll of options presented unless consensus is obvious fr= om > this thread. > > /Dick > > > > > > =E1=90=A7 > > > --000000000000951b3005a14e59a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



not a transaction - there are multiple transactions

= backchannel innovation is combination=C2=A0of here is who I am, and here is= what I want to do


childhood trauma= therapy group



On Mon, Mar 16, 2020 at 6= :56 PM Justin Richer <jricher@mit.edu> wrote:
Yes, naming things is hard =E2=80=94 but I still bel= ieve in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the = process of getting an authorization delegated to the client software as a m= ulti-step, multi-party transaction is, I believe, the key insight that=E2= =80=99s letting us move beyond OAuth=E2=80=99s limitations here. It=E2=80= =99s not just about going to the AS first =E2=80=94 we had that in OAuth 1 = and we=E2=80=99re patching that into OAuth 2 with PAR. I really think it=E2= =80=99s about the transaction at the core.=C2=A0
OAuth 2.0 had multi-step, multi-party. TxAuth extends that.

I think the big shift is going to the AS. This enable= s the request to be richer with JSON, instead of name/value pairs parameter= s in a URI. It allows the client and AS to negotiate, and to short circuit = having to redirect the user to the AS. PAR does=C2=A0some of this, but it i= s constrained by having to do it in the OAuth 2.0 context.

My concern is that the protocol is MUCH MORE than a transaction. W= hile the initial interaction between client, AS, user and RO is a transacti= on. The protocol also covers the client=C2=A0and RS interactions. The acces= s token refreshes. Access token revocation. Access token introspection. As = described in the charter, there is a whole lifecycle, that consists of mult= iple transactions.


Definition of=C2= =A0transaction

1a:=C2=A0something=C2=A0transacte= despecially=C2=A0:=C2=A0an exc= hange or=C2=A0transfer=C2=A0of goods, services, or fundselectronic=C2=A0transactions=
b:=C2=A0transactions=C2=A0plural=C2=A0:=C2=A0the often published record of the meeting = of a society or association
2a:=C2=A0an act, process, or= instance of=C2=A0transacting
b:=C2=A0a communicative action or activity involving two parties or things that = reciprocally affect or influence each other

Calling the protocol a transaction will co= nfusing to people.
=C2=A0

Having come of age in the 1990=E2= =80=99s, I have particular dislike for XAuth. It sounds too =E2=80=9CX-TREM= E=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you read either of those = with a growling yell in your head then you know exactly what I=E2=80=99m ta= lking about.

In case you are co= nfused, this is not a childhood=C2=A0trauma support group.=C2=A0 :)

Unlike "X-TREME" or "X-CITING", XAuth= is using the "X" as a placeholder. X-Men, Xbox, X-Factor, X-file= s.=C2=A0


=C2=A0
And to Dick=E2=80=99s rationale for the name below,= I absolutely do NOT see this work as =E2=80=9COAuth with all the extra fea= tures=E2=80=9D. I think that does a disservice to the kind of change we hav= e an opportunity to make here.=C2=A0

From the charter=C2=A0

"It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0)"

Which sounds pretty= similar to=C2=A0=E2=80=9COAuth with all the extra features=E2=80=9D
<= div>
While I think XAuth captures what we are doing, a placeh= older name would be preferable to an incorrect descriptive name such as TxA= uth.

For example, XYZ is a good placeholder name. = Or XYZAuth. Let's not mislead people.

=C2=A0

=C2= =A0=E2=80=94 Justin

On Mar 16, 2= 020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello everyone

I prompted a thread around t= he name of the protocol a while back:


As Justin stated "nam= ing is hard"

Wearing my marketing hat I want = to ensure that the name will be perceived=C2=A0properly in the broader comm= unity.

A recent example that comes to mind are the= privacy related works on the browser storage API. Given that name, one wou= ld think that it is local storage. It is actually about browser cookies.

Justin discussed his reasons for TxAuth in the threa= d above (and I'm sure in other places)

I chose= XAuth in my draft to reflect the eXtensibility goal that we have over OAut= h -- and XAuth is OAuth but with an X to reflect all the extra features. = =3D)

Other suggestions?

T= his will be an agenda item in the BoF -- but the name will NOT be an open d= iscussion item -- we will summarize=C2=A0what has been discussed on the lis= t and perhaps do a poll of options presented unless consensus is obvious fr= om this thread.

/Dick




3D""= =E1=90=A7

--000000000000951b3005a14e59a2-- From nobody Fri Mar 20 12:37:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E09B3A0D44 for ; Fri, 20 Mar 2020 12:37:26 -0700 (PDT) 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_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=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 0yI0w-OxplnF for ; Fri, 20 Mar 2020 12:37:22 -0700 (PDT) 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 BE4413A0D84 for ; Fri, 20 Mar 2020 12:37:21 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id n20so5482277lfl.10 for ; Fri, 20 Mar 2020 12:37:21 -0700 (PDT) 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=Kv6mlL6Xt4+A/bYTk0TFC0kFB8UjY2xrkh8K68AMWA4=; b=hCbpqTnsfQ51cVNo4eyVmG5rDlPOJs9jzFRPOLNHQ6gCn7v/o6slBvEYsV+Q9Y573K xOJEAUV1OKHGk3/OAkk0PuF99d8o13y70QcH0oU2aJYqUmO3MeNP16iNa9u1M5JZkD7m rea0Tz7wpPo/Zm7x/o4n+G9ekb9qKW7KWzNKB7J1Augh6abjmrh8eW2IfHzaDJHa7xeM q3+8rini82x9wV4wBO+UCALpc0E8ys5KRBPS9mYTTY3K/+FGFZD9kEPEJkov+q/G33A0 2yMqty1LoTwrkIN7J5p0hpBYgDku1cBNKFH/u7Gjk15faMqqa6qZMzc3zE89qq5ooFue bzDA== 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=Kv6mlL6Xt4+A/bYTk0TFC0kFB8UjY2xrkh8K68AMWA4=; b=IK8QkZ696xPHdUb1pg3ZfS3CftohkOOJlgQKv1vADPThlhYrYZfS9Uj3+8uJ+j6F6Q gA7XaBgKkO/opWX9noyRWoYWxxgFDOaSrfmYvvQKFqx3214S4I0OcrXm54PqMLKhYj9f Xb+5XzPlt/dBQfpEz1IH6rh+jG50+L2hew+zCrtCCliYvCgN40KhxPzUpFuXOY2DmKUH 2Ej+aCzTo4CR6dK1VPzK6mnOqwdYltb83iCYpOaGnRld5QciJHQBUbLBm8L0FFqxJMOQ 95BEEGdn6W0Wxz8eg6GpOzj35jxBCXTdIxS9FfiEMwVhOBYgg4iWo3JC7B/KwFRcPPer gYRg== X-Gm-Message-State: ANhLgQ2TL7O6N4PQN79Faqwu23YyH1MwurXFK8CmH7FJYOQC9a5C6Gtk IWSpD7dRULY3pDrStqpuYtAuJdmT/uW4j+EZquk= X-Google-Smtp-Source: ADFU+vs24l8gWvdcQV/1kRmHccMPvK1nKglHiUgRx20BHQsKtAufkXQ9dwzNS1wkpsdhOT3z5Ex7fI2HYKejAPPcUO8= X-Received: by 2002:a19:a401:: with SMTP id q1mr6232254lfc.157.1584733039692; Fri, 20 Mar 2020 12:37:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 12:36:53 -0700 Message-ID: To: Mike Jones Cc: Justin Richer , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e511aa05a14e6903" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 19:37:27 -0000 --000000000000e511aa05a14e6903 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Mike, particularly as per the charter it covers both OAuth and OpenID Connect use cases per the charter: It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) On Tue, Mar 17, 2020 at 9:24 AM Mike Jones wrote: > If this work were happening in the OAuth working group, calling it OAuth = 3 > would be a decision that could be taken by the working group. But unless > it moves to the OAuth working group, I believe that it would be > unreasonable to usurp branding belonging to a different working group. > TxAuth should have its own distinct brand chosen by its to-be-formed > working group. > > > > -- Mike > > > > *From:* Txauth *On Behalf Of *Justin Richer > *Sent:* Tuesday, March 17, 2020 6:11 AM > *To:* Dick Hardt > *Cc:* Yaron Sheffer ; txauth@ietf.org > *Subject:* Re: [Txauth] WG name: TxAuth? XAuth? Something else? > > > > And another thought =E2=80=94 there=E2=80=99s a pretty decent chance that= we=E2=80=99ll end up > branding this whole effort OAuth 3 in the future. > > > > The list is named =E2=80=98txauth=E2=80=99. Therefore, calling what we=E2= =80=99re working on > anything different from that seems silly and premature. > > > > I say we just stick with TxAuth to match the list and avoid the whole > naming discussion entirely. > > > > =E2=80=94 Justin > > > > On Mar 16, 2020, at 9:56 PM, Justin Richer wrote: > > > > Yes, naming things is hard =E2=80=94 but I still believe in the name TxAu= th. We=E2=80=99re > moving beyond OAuth, and taking the process of getting an authorization > delegated to the client software as a multi-step, multi-party transaction > is, I believe, the key insight that=E2=80=99s letting us move beyond OAut= h=E2=80=99s > limitations here. It=E2=80=99s not just about going to the AS first =E2= =80=94 we had that > in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I reall= y think > it=E2=80=99s about the transaction at the core. > > > > Having come of age in the 1990=E2=80=99s, I have particular dislike for X= Auth. It > sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and = if you read either of those with a > growling yell in your head then you know exactly what I=E2=80=99m talking= about. > And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT s= ee this > work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think that= does a disservice > to the kind of change we have an opportunity to make here. > > > > =E2=80=94 Justin > > > > On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: > > > > Hello everyone > > > > I prompted a thread around the name of the protocol a while back: > > > > https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ > > > > As Justin stated "naming is hard" > > > > Wearing my marketing hat I want to ensure that the name will be > perceived properly in the broader community. > > > > A recent example that comes to mind are the privacy related works on the > browser storage API. Given that name, one would think that it is local > storage. It is actually about browser cookies. > > > > Justin discussed his reasons for TxAuth in the thread above (and I'm sure > in other places) > > > > I chose XAuth in my draft to reflect the eXtensibility goal that we have > over OAuth -- and XAuth is OAuth but with an X to reflect all the extra > features. =3D) > > > > Other suggestions? > > > > This will be an agenda item in the BoF -- but the name will NOT be an ope= n > discussion item -- we will summarize what has been discussed on the list > and perhaps do a poll of options presented unless consensus is obvious fr= om > this thread. > > > > /Dick > > > > > > > > > > > > =E1=90=A7 > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000e511aa05a14e6903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Mike, particularly as per the charter it cove= rs both OAuth and OpenID Connect use cases per the charter:

<= blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
It will= expand upon the uses cases currently supported by OAuth 2.0 and OpenID Con= nect (itself an extension of OAuth 2.0)

On Tue, Mar 17, 2= 020 at 9:24 AM Mike Jones <Michael.Jones@microsoft.com> wrote:

If this work were= happening in the OAuth working group, calling it OAuth 3 would be a decisi= on that could be taken by the working group.=C2=A0 But unless it moves to t= he OAuth working group, I believe that it would be unreasonable to usurp branding belonging to a different working group.= =C2=A0 TxAuth should have its own distinct brand chosen by its to-be-formed= working group.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: Txauth <txauth-bounces@ietf.org> On Beha= lf Of Justin Richer
Sent: Tuesday, March 17, 2020 6:11 AM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else?=

=C2=A0

And another thought =E2=80=94 there=E2=80=99s a pret= ty decent chance that we=E2=80=99ll end up branding this whole effort OAuth= 3 in the future.=C2=A0

=C2=A0

The list is named =E2=80=98txauth=E2=80=99. Therefor= e, calling what we=E2=80=99re working on anything different from that seems= silly and premature.

=C2=A0

I say we just stick with TxAuth to match the list an= d avoid the whole naming discussion entirely.

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 16, 2020, at 9:56 PM, Justin Richer <jricher@mit.edu> wro= te:

=C2=A0

Yes, naming things is hard =E2=80=94 but I still bel= ieve in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the = process of getting an authorization delegated to the client software as a m= ulti-step, multi-party transaction is, I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2=80=99s limi= tations here. It=E2=80=99s not just about going to the AS first =E2=80=94 w= e had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR= . I really think it=E2=80=99s about the transaction at the core.=C2=A0

=C2=A0

Having come of age in the 1990=E2=80=99s, I have par= ticular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you read either of those with a growling ye= ll in your head then you know exactly what I=E2=80=99m talking about. And t= o Dick=E2=80=99s rationale for the name below, I absolutely do NOT see this work as =E2=80= =9COAuth with all the extra features=E2=80=9D. I think that does a disservi= ce to the kind of change we have an opportunity to make here.=C2=A0<= u>

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Hello everyone

=C2=A0

I prompted a thread around the name of the protocol = a while back:

=C2=A0

=C2=A0

As Justin stated "naming is hard"

=C2=A0

Wearing my marketing hat I want to ensure that the n= ame will be perceived=C2=A0properly in the broader community.=

=C2=A0

A recent example that comes to mind are the privacy = related works on the browser storage API. Given that name, one would think = that it is local storage. It is actually about browser cookies.

=C2=A0

Justin discussed his reasons for TxAuth in the threa= d above (and I'm sure in other places)

=C2=A0

I chose XAuth in my draft to reflect the eXtensibili= ty goal that we have over OAuth -- and XAuth is OAuth but with an X to refl= ect all the extra features. =3D)

=C2=A0

Other suggestions?

=C2=A0

This will be an agenda item in the BoF -- but the na= me will NOT be an open discussion item -- we will summarize=C2=A0what has b= een discussed on the list and perhaps do a poll of options presented unless= consensus is obvious from this thread.

=C2=A0

/Dick

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

=C2=A0

--000000000000e511aa05a14e6903-- From nobody Fri Mar 20 12:41:45 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD603A0D44 for ; Fri, 20 Mar 2020 12:41:41 -0700 (PDT) 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_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=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 8uE7sC9oLW8Q for ; Fri, 20 Mar 2020 12:41:39 -0700 (PDT) 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 5D9183A0C32 for ; Fri, 20 Mar 2020 12:41:39 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id j188so1656381lfj.11 for ; Fri, 20 Mar 2020 12:41:39 -0700 (PDT) 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=qvZw9xADmxCkl5x+Ksw23/V3wQZwNCqM0mPlwsWRbqk=; b=VrGUDCy2UOyg3rkiSPKCRBiMtnr8foYGfBt9xBoYgsq1vBl36XJ5RMyelF2NWIjFvL vjPT/FCHune5hkaOPXacT9gNfgv13r0AC76TLYIyoiojiAWqeWfIjNq2yzk41CHq1KNw trLJ/OrHSN0ZcRtn4+vDtJExdvUmAqtGp8HIvDeAjvskj/JUkLEPaIISbXyX+QEej955 v0bp+xj0smWjkLyxMUXXZUddlw1v/EymbEijjviUPKfRI9xomGlSwfxOirn6yjMeReW6 FP2KUVTA2yXpBqvdd6YE6UYQOx3wxi5BViYXIf3MZRrzFSZ1vEUdGbUQq9bqwpxN5ntJ ILsQ== 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=qvZw9xADmxCkl5x+Ksw23/V3wQZwNCqM0mPlwsWRbqk=; b=QkJtm5yIH6JvmIaWdl1JI7U3NqJPYsCFwv4qiMX43tF3J5nvBLFHoFh/TagO+0igqw ONBqsvt1LHsnBoWvmwJPSom90FmH0HbSCT8c59BKbTMRUihOfzSbgnZhqroyj6bfinDJ ClEje0QeBWqP2e4XxnKTsv4knc44qAEIo8HCs7GN4RG8ddylyzpDC0/rSkyIQriTqOZi 02hSkikYj0qXleyql3hCFKRGRLvbZ1WstdBmEsO0ndfHPMdlEV0U3zwfob5CJ5tBl/WX Y9zwy8SX/BmTPutqE0y2P+enWALvwvhrqp7ja8E66R3i/ilFfXf8j1jRemgb5sPzr1vG /LbQ== X-Gm-Message-State: ANhLgQ2PgunpxrAdsQilqmNaGQdG6iSu7gpVpFOzXeNJ2lMj7yPzaRL2 erdg4g0vuZOpaASkPUeDUi0j/lG19u8V3rZG/wM= X-Google-Smtp-Source: ADFU+vskBB9oC9vVrQuwuAUtYt4T6iPHDs4/p2EkHdWmcc46p3HowK5rA3rp17zsfcnL2vMevsREHvmjA9ZlJn5t2C8= X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr6399466lfe.23.1584733297216; Fri, 20 Mar 2020 12:41:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 12:41:11 -0700 Message-ID: To: Mike Jones Cc: Justin Richer , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003e923e05a14e79c4" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 19:41:43 -0000 --0000000000003e923e05a14e79c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I forgot to share an anecdote about name confusion: I'm lurking in the W3C privacy community group virtual meetings, which are dominated by browser vendors. There was discussion about access control for the Storage API. It took me a while before I realized the Storage API is how a browser accesses cookies, and is NOT how a browser access local storage. On Fri, Mar 20, 2020 at 12:36 PM Dick Hardt wrote: > I agree with Mike, particularly as per the charter it covers both OAuth > and OpenID Connect use cases per the charter: > > It will expand upon the uses cases currently supported by OAuth 2.0 and > OpenID Connect (itself an extension of OAuth 2.0) > > > On Tue, Mar 17, 2020 at 9:24 AM Mike Jones > wrote: > >> If this work were happening in the OAuth working group, calling it OAuth >> 3 would be a decision that could be taken by the working group. But unl= ess >> it moves to the OAuth working group, I believe that it would be >> unreasonable to usurp branding belonging to a different working group. >> TxAuth should have its own distinct brand chosen by its to-be-formed >> working group. >> >> >> >> -- Mike >> >> >> >> *From:* Txauth *On Behalf Of *Justin Richer >> *Sent:* Tuesday, March 17, 2020 6:11 AM >> *To:* Dick Hardt >> *Cc:* Yaron Sheffer ; txauth@ietf.org >> *Subject:* Re: [Txauth] WG name: TxAuth? XAuth? Something else? >> >> >> >> And another thought =E2=80=94 there=E2=80=99s a pretty decent chance tha= t we=E2=80=99ll end up >> branding this whole effort OAuth 3 in the future. >> >> >> >> The list is named =E2=80=98txauth=E2=80=99. Therefore, calling what we= =E2=80=99re working on >> anything different from that seems silly and premature. >> >> >> >> I say we just stick with TxAuth to match the list and avoid the whole >> naming discussion entirely. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Mar 16, 2020, at 9:56 PM, Justin Richer wrote: >> >> >> >> Yes, naming things is hard =E2=80=94 but I still believe in the name TxA= uth. >> We=E2=80=99re moving beyond OAuth, and taking the process of getting an >> authorization delegated to the client software as a multi-step, multi-pa= rty >> transaction is, I believe, the key insight that=E2=80=99s letting us mov= e beyond >> OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to t= he AS first =E2=80=94 we >> had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PA= R. I really >> think it=E2=80=99s about the transaction at the core. >> >> >> >> Having come of age in the 1990=E2=80=99s, I have particular dislike for = XAuth. It >> sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and= if you read either of those with a >> growling yell in your head then you know exactly what I=E2=80=99m talkin= g about. >> And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this >> work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think tha= t does a disservice >> to the kind of change we have an opportunity to make here. >> >> >> >> =E2=80=94 Justin >> >> >> >> On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >> >> >> >> Hello everyone >> >> >> >> I prompted a thread around the name of the protocol a while back: >> >> >> >> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc= / >> >> >> >> As Justin stated "naming is hard" >> >> >> >> Wearing my marketing hat I want to ensure that the name will be >> perceived properly in the broader community. >> >> >> >> A recent example that comes to mind are the privacy related works on the >> browser storage API. Given that name, one would think that it is local >> storage. It is actually about browser cookies. >> >> >> >> Justin discussed his reasons for TxAuth in the thread above (and I'm sur= e >> in other places) >> >> >> >> I chose XAuth in my draft to reflect the eXtensibility goal that we have >> over OAuth -- and XAuth is OAuth but with an X to reflect all the extra >> features. =3D) >> >> >> >> Other suggestions? >> >> >> >> This will be an agenda item in the BoF -- but the name will NOT be an >> open discussion item -- we will summarize what has been discussed on the >> list and perhaps do a poll of options presented unless consensus is obvi= ous >> from this thread. >> >> >> >> /Dick >> >> >> >> >> >> >> >> >> >> >> >> =E1=90=A7 >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> > --0000000000003e923e05a14e79c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I forgot to share an anecdote about name confusion:

I'm lurking in the W3C privacy community group virtua= l meetings, which are dominated by browser vendors. There was discussion ab= out access control for the Storage API. It took me a while before I realize= d the Storage API is how a browser accesses cookies, and is NOT how a brows= er access local storage.=C2=A0



On = Fri, Mar 20, 2020 at 12:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
I agree with Mike, particula= rly as per the charter it covers both OAuth and OpenID Connect use cases pe= r the charter:

It will expand upon the uses cases currently s= upported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0)=

On Tue, Mar 17, 2020 at 9:24 AM Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

If this work were= happening in the OAuth working group, calling it OAuth 3 would be a decisi= on that could be taken by the working group.=C2=A0 But unless it moves to t= he OAuth working group, I believe that it would be unreasonable to usurp branding belonging to a different working group.= =C2=A0 TxAuth should have its own distinct brand chosen by its to-be-formed= working group.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: Txauth <txauth-bounces@ietf.org> On Beha= lf Of Justin Richer
Sent: Tuesday, March 17, 2020 6:11 AM
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else?=

=C2=A0

And another thought =E2=80=94 there=E2=80=99s a pret= ty decent chance that we=E2=80=99ll end up branding this whole effort OAuth= 3 in the future.=C2=A0

=C2=A0

The list is named =E2=80=98txauth=E2=80=99. Therefor= e, calling what we=E2=80=99re working on anything different from that seems= silly and premature.

=C2=A0

I say we just stick with TxAuth to match the list an= d avoid the whole naming discussion entirely.

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 16, 2020, at 9:56 PM, Justin Richer <jricher@mit.edu> wro= te:

=C2=A0

Yes, naming things is hard =E2=80=94 but I still bel= ieve in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the = process of getting an authorization delegated to the client software as a m= ulti-step, multi-party transaction is, I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2=80=99s limi= tations here. It=E2=80=99s not just about going to the AS first =E2=80=94 w= e had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR= . I really think it=E2=80=99s about the transaction at the core.=C2=A0

=C2=A0

Having come of age in the 1990=E2=80=99s, I have par= ticular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you read either of those with a growling ye= ll in your head then you know exactly what I=E2=80=99m talking about. And t= o Dick=E2=80=99s rationale for the name below, I absolutely do NOT see this work as =E2=80= =9COAuth with all the extra features=E2=80=9D. I think that does a disservi= ce to the kind of change we have an opportunity to make here.=C2=A0<= u>

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Hello everyone

=C2=A0

I prompted a thread around the name of the protocol = a while back:

=C2=A0

=C2=A0

As Justin stated "naming is hard"

=C2=A0

Wearing my marketing hat I want to ensure that the n= ame will be perceived=C2=A0properly in the broader community.=

=C2=A0

A recent example that comes to mind are the privacy = related works on the browser storage API. Given that name, one would think = that it is local storage. It is actually about browser cookies.

=C2=A0

Justin discussed his reasons for TxAuth in the threa= d above (and I'm sure in other places)

=C2=A0

I chose XAuth in my draft to reflect the eXtensibili= ty goal that we have over OAuth -- and XAuth is OAuth but with an X to refl= ect all the extra features. =3D)

=C2=A0

Other suggestions?

=C2=A0

This will be an agenda item in the BoF -- but the na= me will NOT be an open discussion item -- we will summarize=C2=A0what has b= een discussed on the list and perhaps do a poll of options presented unless= consensus is obvious from this thread.

=C2=A0

/Dick

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

=C2=A0

--0000000000003e923e05a14e79c4-- From nobody Fri Mar 20 12:48:51 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039783A0DA8 for ; Fri, 20 Mar 2020 12:48:41 -0700 (PDT) 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 EZVP3MacGgvS for ; Fri, 20 Mar 2020 12:48:32 -0700 (PDT) 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 434613A0DA6 for ; Fri, 20 Mar 2020 12:48:31 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id o10so7744621ljc.8 for ; Fri, 20 Mar 2020 12:48:31 -0700 (PDT) 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=bBFiFdV6AE61sLKp6mQS7kQ9p057C6n6HkWcI28dcRw=; b=QzWgY9FEhQe6XM2NSfNfqiyjyvOS6B+PfRtlnUIltHY57kdGuuKySzmqZbAlvOiMaI 4nacaR1X9JAe3qi/ocU5qIU83DVtziFucCVS/ZXywvpiuuL8rfghB9O1sMFLEvEBzhck IUCubRCOE/fIcneSObSmD6x9THhEpvryRySd9a6m+gmRgl+QfCUZ2YDcNHjxegewMyQF /wbI5bJb4KegC8vgYciEHbx/cT/9wAEFWZmVf0l0gty8vUiwvHDrArgwNtHNQ8Fa33ER f9xlLnoMfvHXzB86V1i+fVEAQTXWERRayjrwLluW9V0QumXO5s8OoCZPGo8ZTPv5AOFA so7Q== 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=bBFiFdV6AE61sLKp6mQS7kQ9p057C6n6HkWcI28dcRw=; b=fc5vPgLUeUDtozgq1iyghY4qB01amThPYb/EoZar/hipTnd95tG2d16X0ZgEOnXYZV 8PVm1W6vHjzyStqMi9UjAURghK8ZvKk280F8nwYBFwUy2cYYekaoy0zcawq/cWZPDZ2x GFG1bBTQKUorjdZAAdK9UWAujOYBWalE7KhpV2I/RwJdoHHSxFqfSkcDDtDP3y20R8Bd N0tR0/e51WidO74GNama0SYxxsa52MwB6EGvalbSQ67+uhUBT7ciykz80FHGXxKv/U2B x1TCrNtY8GfYOmlEW3HX/A/B/85XW3pQfH0FnWoZwn2QiJfM8Y2lz/FWXyzefSqwA/Jj ogrQ== X-Gm-Message-State: ANhLgQ0KRkr9Qyd6TH/irZtOjJwH1Ge65JH7Pu1dGMt7SlNrIi0sJ+Qi 0FpHT2RRiq/hytX/7o4ynnHLiGZNN1qTp/IdbNRouw/2 X-Google-Smtp-Source: ADFU+vt7FmH6YRZzBtnVwdAGkmKlARaa/jI3dtYLfdb32TAVaKgfyQ1F0tPokdt7HWOsoOSQA84v/r8SKpCRSf7FXnA= X-Received: by 2002:a2e:7811:: with SMTP id t17mr6427748ljc.150.1584733708618; Fri, 20 Mar 2020 12:48:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 12:48:02 -0700 Message-ID: To: Tobias Looker Cc: txauth@ietf.org Content-Type: multipart/related; boundary="000000000000c4567905a14e916b" Archived-At: Subject: Re: [Txauth] Client bound user assertions X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 19:48:46 -0000 --000000000000c4567905a14e916b Content-Type: multipart/alternative; boundary="000000000000c4567605a14e916a" --000000000000c4567605a14e916a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tobias Let me see if I understand the end goal. The Client presents a assertion about the user created by the AS, when their are interacting with to a relying party. Correct? There are a number of ways to solve this, but in my opinion, creating the missing features for this to be done would be in scope of TxAuth. On Thu, Mar 19, 2020 at 3:23 PM Tobias Looker wrote: > Hi, > > I'm unsure of the best way to articulate this idea on this forum, but see > my below explanation for an attempt. I'm also aware that it as a discussi= on > topic is dependent on how "identity" fits into TxAuth in general. > > With OpenID connect today the format of the user assertions we get are > often bound to the client (or a small audience) mainly by the issuer usin= g > the audience field in the id_token to communicate who it is for (e.g this > is for client x) which gives all parties a way to determine whether they > are the intended audience of the assertion. However, this does not enable= a > client to authenticate as the intended audience of the user assertion to > other parties. If a client was instead able to authenticate as the rightf= ul > audience of a user assertion then they would be able to onward disclose t= he > user assertion to a relying party, such that the relying party would be > able to authenticate both the original issuer of the assertion and the > client now presenting the assertion. > > See below for a simple example. > > Here the client obtains a user assertion from the OP or Authorization > server that is suitably bound to the client in an authenticatable way. > > [image: Screen Shot 2020-03-12 at 10.05.15 AM.png] > > The relying party now makes a request to the client who is in possession > of the assertion from the authorization server and the client can respond= , > presenting the assertion. In this flow, with regards to OIDC, the client = is > essentially taking a similar role to that of a self issued openid connect > provider. > > [image: Screen Shot 2020-03-12 at 10.05.20 AM.png] > > How this could be realized in TxnAuth? > > If the client strongly authenticates at the start of an authorization > transaction e.g by signing the original authorization request with either > an ephemeral or static key, the resulting assertion could be bound to thi= s > key enabling the client to authenticate as the rightful audience of the > assertion to other relying parties. Similar to how DPOP for access_tokens > works. > > Why is this interesting and what use cases does it enable? > > Being able to obtain user assertions that can be bound to the client such > that the client can onward disclose them enables new opportunities around > how users can manage different sources of their identity information > through a single client. This can help to eliminate things like the nasca= r > problem and presentations to relying parties that require aggregating > assertions from multiple authorization servers. > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c4567605a14e916a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tobias

Let me see if I understand th= e end goal.=C2=A0

The Client presents a assertion= =C2=A0about the user created by the AS, when their are interacting with to = a relying party.

Correct?

There are a number of ways to solve this, but in my opinion, creating the = missing features for this to be done would be in scope of TxAuth.



On Thu, Mar 19, 2020 at 3:23 PM Tobias Looker <= ;tobias.looker@mattr.global> wrote:
Hi,

I= 'm unsure of the best way to articulate this idea on this forum, but se= e my below explanation for an attempt. I'm also aware that it as a disc= ussion topic is dependent on how "identity" fits into TxAuth in g= eneral.=C2=A0

With OpenID connect today the format= of the user assertions we get are often bound to the client (or a small au= dience) mainly by the issuer using the audience field in the id_token to co= mmunicate who=C2=A0it is for (e.g this is for client x) which gives all par= ties a way to determine whether they are the intended audience of the asser= tion. However, this does not enable a client to authenticate as the intende= d audience of the user assertion to other parties. If a client was instead = able to authenticate as the rightful audience of a user assertion then they= would be able to onward disclose the user assertion to a relying party, su= ch that the relying party would be able to authenticate both the original i= ssuer of the assertion and the client now presenting the assertion.

See below for a simple example.

= Here the client obtains a user assertion from the OP or Authorization serve= r that is suitably bound to the client in an authenticatable way.

3D"Screen<= /div>

The relying party now makes a request to the clien= t who is in possession of the assertion from the authorization server and t= he client can respond, presenting the assertion.=C2=A0In this flow, with re= gards to OIDC, the client is essentially taking a similar role to that of a= self issued openid connect provider.

3D"Screen
=C2=A0
=
How this could be realized in TxnAuth?=C2=A0

= If the client strongly authenticates at the start of an authorization trans= action e.g by signing the original authorization request with either an eph= emeral or static key, the resulting assertion could be bound to this key en= abling the client to authenticate as the rightful audience of the assertion= to other relying parties. Similar to how DPOP for access_tokens works.

Why is this interesting and what use cases does it en= able?

Being able to obtain user assertions that ca= n be bound to the client such that the client can onward disclose them enab= les new opportunities around how users can manage different sources of thei= r identity information through a single client. This can help to eliminate = things like the nascar problem and presentations to relying parties that re= quire aggregating assertions from multiple authorization servers.

Thanks,

This communication= , including any attachments, is confidential. If you are not the intended r= ecipient, you should not read it - please contact me immediately, destroy i= t, and do not copy or use any part of this communication or disclose anythi= ng about it. Thank you. Please note that this communication does not design= ate an information system for the purposes of the Electronic Transactions A= ct 2002.

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
-- <= br> Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000c4567605a14e916a-- --000000000000c4567905a14e916b Content-Type: image/png; name="Screen Shot 2020-03-12 at 10.05.15 AM.png" Content-Disposition: inline; filename="Screen Shot 2020-03-12 at 10.05.15 AM.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_k7ntxqmx2 iVBORw0KGgoAAAANSUhEUgAAAv4AAAG5CAYAAAD20DDwAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV lgdUk1kWx9/3fekktECkE3qT3gJICT0UQTqISkgCCSWGhCBiR8QRsKEiAuqIDUTBsQAyqIgotkGx gH1AREUdBws2VPYDljCze3b37D3n5f3OzX333fvOd8/5A0D+xhaJMmBFADKF2eKIAG96XHwCHf8U QAABROAIDNgciYgZHh4CUJva/24fe9Bo1G5Zjuf69///qylxeRIOAFA4yslcCScT5RPoesIRibMB QMpRv8GibNE4t6KsIkYLRPnGOKdO8tNxTp7kzxMxURE+AGDIABDIbLY4FQCyGuqn53BS0TxkBso2 Qq5AiDIfZQ8On81FuQblmZmZC8f5NsqmyX/Jk/q3nMmynGx2qowne5kwgq9AIspgL/4/n+N/W2aG dOoOYzDegDgwAt1J6JvdTV8YLGNh8uywKRZwJ+InmC8NjJ5ijsQnYYq5bN9g2dmM2SFTnCLwZ8ny ZLOippgn8YucYvHCCNldKWIf5hSzxdP3StOjZX4+jyXLn8ePip3iHEHM7CmWpEcGT8f4yPxiaYSs fp4wwHv6Xn9Z75mSv/QrYMnOZvOjAmW9s6fr5wmZ0zklcbLauDxfv+mYaFm8KNtbdpcoI1wWz8sI kPklOZGys9noBzl9Nlz2hmnsoPApBnbAAZ03G4C+RjYvN3u8AZ+FosViQSo/m85EJ4tHZwk5VjPp djZ2NgCMz+nkZ/CeNjF/EO3KtC83GQD3dADgwGlfXBwADaYAqMdN+4w1AaCiM9e0niMV50z6MOM/ WLQqBaAC1IEOMACmwBKtzwm4AS/gB4JAGIgC8WA+4AA+yARisAgsBatAISgGm8A2UAF2g72gBhwB x0ATaAXnwEVwFdwAd8AD0AcGwSswDD6CUQiC8BAFokLqkC5kBFlAdhAD8oD8oBAoAoqHkqBUSAhJ oaXQaqgYKoUqoD1QLfQLdAo6B12GuqF7UD80BL2DvsIITIZVYG3YGLaGGTATDoaj4HlwKpwF58EF 8Aa4HK6GD8ON8Dn4KnwH7oNfwSMIQOQQGqKHWCIMxAcJQxKQFESMLEeKkDKkGqlHWpBO5BbSh7xG vmBwGCqGjrHEuGECMdEYDiYLsxxTgqnA1GAaMR2YW5h+zDDmB5aC1cJaYF2xLGwcNhW7CFuILcMe wJ7EXsDewQ5iP+JwOBrOBOeMC8TF49JwS3AluJ24Blwbrhs3gBvB4/HqeAu8Oz4Mz8Zn4wvxO/CH 8WfxN/GD+M8EOYIuwY7gT0ggCAn5hDLCIcIZwk3Cc8IoUZFoRHQlhhG5xMXEjcR9xBbideIgcZSk RDIhuZOiSGmkVaRyUj3pAukh6b2cnJy+nIvcHDmB3Eq5crmjcpfk+uW+kJXJ5mQfciJZSt5APkhu I98jv6dQKMYUL0oCJZuygVJLOU95TPksT5W3kmfJc+VXyFfKN8rflH+jQFQwUmAqzFfIUyhTOK5w XeG1IlHRWNFHka24XLFS8ZRir+KIElXJVilMKVOpROmQ0mWlF8p4ZWNlP2WucoHyXuXzygNUhGpA 9aFyqKup+6gXqIMqOBUTFZZKmkqxyhGVLpVhVWVVB9UY1VzVStXTqn00hGZMY9EyaBtpx2g9tK8z tGcwZ/BmrJtRP+PmjE9qmmpeajy1IrUGtTtqX9Xp6n7q6eqb1ZvUH2lgNMw15mgs0tilcUHjtaaK ppsmR7NI85jmfS1Yy1wrQmuJ1l6ta1oj2jraAdoi7R3a57Vf69B0vHTSdLbqnNEZ0qXqeugKdLfq ntV9SVelM+kZ9HJ6B31YT0svUE+qt0evS29U30Q/Wj9fv0H/kQHJgGGQYrDVoN1g2FDXMNRwqWGd 4X0johHDiG+03ajT6JOxiXGs8VrjJuMXJmomLJM8kzqTh6YUU0/TLNNq09tmODOGWbrZTrMb5rC5 oznfvNL8ugVs4WQhsNhp0T0TO9NlpnBm9cxeS7Il0zLHss6y34pmFWKVb9Vk9cba0DrBerN1p/UP G0ebDJt9Ng9slW2DbPNtW2zf2Znbcewq7W7bU+z97VfYN9u/dbBw4DnscrjrSHUMdVzr2O743cnZ SexU7zTkbOic5Fzl3MtQYYQzShiXXLAu3i4rXFpdvrg6uWa7HnP9083SLd3tkNuLWSazeLP2zRpw 13dnu+9x7/OgeyR5/OzR56nnyfas9nziZeDF9Trg9ZxpxkxjHma+8bbxFnuf9P7k4+qzzKfNF/EN 8C3y7fJT9ov2q/B77K/vn+pf5z8c4BiwJKAtEBsYHLg5sJelzeKwalnDQc5By4I6gsnBkcEVwU9C zEPEIS2hcGhQ6JbQh7ONZgtnN4WBMFbYlrBH4SbhWeG/zsHNCZ9TOedZhG3E0ojOSGrkgshDkR+j vKM2Rj2INo2WRrfHKMQkxtTGfIr1jS2N7YuzjlsWdzVeI14Q35yAT4hJOJAwMtdv7ra5g4mOiYWJ PfNM5uXOuzxfY37G/NMLFBawFxxPwibFJh1K+sYOY1ezR5JZyVXJwxwfznbOK64Xdyt3iOfOK+U9 T3FPKU15keqeuiV1iO/JL+O/FvgIKgRv0wLTdqd9Sg9LP5g+lhGb0ZBJyEzKPCVUFqYLOxbqLMxd 2C2yEBWK+rJcs7ZlDYuDxQckkGSepDlbBRVE16Sm0jXS/hyPnMqcz4tiFh3PVcoV5l5bbL543eLn ef55+5dglnCWtC/VW7pqaf8y5rI9y6HlycvbVxisKFgxuDJgZc0q0qr0Vb/l2+SX5n9YHbu6pUC7 YGXBwJqANXWF8oXiwt61bmt3/4T5SfBT1zr7dTvW/SjiFl0ptikuK/5Wwim5st52ffn6sQ0pG7o2 Om3ctQm3SbipZ7Pn5ppSpdK80oEtoVsat9K3Fm39sG3BtstlDmW7t5O2S7f3lYeUN+8w3LFpx7cK fsWdSu/KhiqtqnVVn3Zyd97c5bWrfrf27uLdX38W/Hx3T8Cexmrj6rK9uL05e5/ti9nXuZ+xv/aA xoHiA98PCg/21UTUdNQ619Ye0jq0sQ6uk9YNHU48fOOI75Hmesv6PQ20huKj4Kj06Mtfkn7pORZ8 rP0443j9CaMTVSepJ4saocbFjcNN/Ka+5vjm7lNBp9pb3FpO/mr168FWvdbK06qnN54hnSk4M3Y2 7+xIm6jt9bnUcwPtC9ofnI87f7tjTkfXheALly76Xzzfyew8e8n9Uutl18unrjCuNF11utp4zfHa yd8cfzvZ5dTVeN35evMNlxst3bO6z9z0vHnulu+ti7dZt6/emX2nuye6525vYm/fXe7dF/cy7r29 n3N/9MHKh9iHRY8UH5U91npc/bvZ7w19Tn2n+337rz2JfPJggDPw6qnk6bfBgmeUZ2XPdZ/XvrB7 0TrkP3Tj5dyXg69Er0ZfF/6h9EfVG9M3J/70+vPacNzw4Fvx27F3Je/V3x/84PChfSR85PHHzI+j n4o+q3+u+cL40vk19uvz0UXf8N/Kv5t9b/kR/OPhWObYmIgtZk9IAQRdcEoKAO8OAkCJR7UCqrtJ cyd19IRBk9p/gsB/4kmtPWFOAOxvAyB6JQCB6F6J7sboruwFwLgUivICsL29bP3TJCn2dpO5yKii xH4eG3uvDQC+BYDv4rGx0Z1jY9/3ocXeA6Ata1K/T0iYAQAM0aRQbBfJKRf8i/0D0d0MkN0RdPQA AAGdaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjc2 NjwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj40 NDE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KsQmUcwAAQABJREFUeAHsnQm4HUWZv+smN/tyb3bWJBBCIOw7 SJAAIoJRUEBwVLbRUXQWdEZhHEdgnkfFGZ0ZRwXRPw6MGyiCQERQloSwKIZNQiBsSQiB7Lk3+37/ 9aukDn36dPfps91zTt+3nufe7q71q7fqdH9dXfVVS5d1JsZ1dnaatra2mNBk74ULF5px48YlR4oJ raTcZkwLq5iOEOENqwgoMV6wigET4Q2rCCgxXrCKARPhDasIKDFesIoBE+ENqwgoMV6wKgTTq9AL HwhAAAIQgAAEIAABCEAgawRQ/LPWotQHAhCAAAQgAAEIQAACEQRQ/COg4AUBCEAAAhCAAAQgAIGs EUDxz1qLUh8IQAACEIAABCAAAQhEEEDxj4CCFwQgAAEIQAACEIAABLJGAMU/ay1KfSAAAQhAAAIQ gAAEIBBBAMU/AgpeEIAABCAAAQhAAAIQyBoBFP+stSj1gQAEIAABCEAAAhCAQAQBFP8IKHhBAAIQ gAAEIAABCEAgawRQ/LPWotQHAhCAAAQgAAEIQAACEQRQ/COg4AUBCEAAAhCAAAQgAIGsEWjp6Ojo qkWlbL6mvb29FllnLk9YpW9SWMEqPYH0MelXsEpPIH1M+hWs0hNIH5N+Bav0BApjtra1tRX67vLp 7Ow0SeGxCW2AOma5aSsptxnTwiqpJ+WHwSqfR9IVrJLo5IfBKp9H0hWskujkh8Eqn0fSFayS6OSH wSqfR9IVrArpMNWnkAk+EIAABCAAAQhAAAIQyBwBFP/MNSkVggAEIAABCEAAAhCAQCEBFP9CJvhA AAIQgAAEIAABCEAgcwRQ/DPXpFQIAhCAAAQgAAEIQAAChQRQ/AuZ4AMBCEAAAhCAAAQgAIHMEUDx z1yTUiEIQAACEIAABCAAAQgUEkDxL2SCDwQgAAEIQAACEIAABDJHAMU/c01KhSAAAQhAAAIQgAAE IFBIAMW/kAk+EIAABCAAAQhAAAIQyBwBFP/MNSkVggAEIAABCEAAAhCAQCEBFP9CJvhAAAIQgAAE IAABCEAgcwRQ/DPXpFQIAhCAAAQgAAEIQAAChQRQ/AuZ4AMBCEAAAhCAAAQgAIHMEWjp6OjoqkWt bL6mvb29FllnLk9YpW9SWMEqPYH0MelXsEpPIH1M+hWs0hNIH5N+Bav0BApjtra1tRX67vLp7Ow0 SeGxCW2AOma5aSsptxnTwiqpJ+WHwSqfR9IVrJLo5IfBKp9H0hWskujkh8Eqn0fSFayS6OSHwSqf R9IVrArpMNWnkAk+EIAABCAAAQhAAAIQyByBhlH8t2/fbq699lr31x2UZ8yY0a3ldUedKGMngQUL Fri2VRsXc6XELZYX4Y1HoFnad/HixQ13P9L9+Oabby5o1D/84Q9O1t/85jcuLC5eQcIID38fVjsV c48++mjq33WxvBotvBH6aTXa8Y033mg0tMgDAQiECNRM8f/Vr35lPv3pT5uTTjrJTfnZf//9zXnn nWf++Z//2UTd5Ldt29btN3Xd6BrJPfvss+bUU081n//8551YeujqWv649ARKeYiWEje9BMRsFALd 1b6V/nb/9Kc/ufvfCSec0CjonDxhxV/3pr/5m79xYd/5znecrNVQGKOeCWEQKP5hItW9rkY7ovhX t03IDQK1INBai0wvuOACI8V/0KBB5tBDDzWXXnqp0Q1BD8df//rX5vvf/775n//5H3PJJZfkipfi 39WVfp2xHkh//dd/bfSloFz34IMPmpaWlnKTVz3d4Ycfbh5++GHz7ne/2+Wth6GuNUcNVxqBUvpS KXFLk4LY3Ung+eefd7+dHTt25IrVb0q/83322SfnV4uTSn+7Tz75pBk/frw57rjjaiFeWXmKW9BA g+5D//3f/2323HNPI9Y+LByv1MJK+f2VErdUOeodvzvrNnz4cHPHHXeYqVOn5qrdne2YK5QTCECg 2wlUXfHXqMEvf/lLc/7555tvfetbZu+9984p17qx3XrrreaKK64wl112mdFXgHe9612u0lL8S3Ev vPBCSS8K4byDN7xwWKNd+wdso8mFPBBoJAJSRsPKk347p5xySt3ETPvb1Yi/RvvLNYhQiwqGuflR +fe+971m2LBhuSLD8XIBnDQkAbXj6tWrC2Tz7SgDGTgIQCC7BKqq+D/xxBPuE/Bpp51m/uM//sOM HTs2j5xG1z/60Y+6h8aZZ57ppgL98Y9/dF8Gtm7dmov7yiuvmNmzZxuNgm3YsMHsu+++5utf/7oL 14P93/7t38zcuXPdtZ+uc/XVV+fSa97o/fff7+KMGDHCjBs3zr2ITJ48OS/OzJkz3bXSKt9vfvOb pl+/fkbXP/3pT83TTz9tXn/9dXPggQeaf/qnfzLKK43T1w6N1L/00ktO9iOPPNKVP2rUqDTJc3G8 0qDRRDnVSzJLvltuucX96QXr8ssvd+G6oetLip8apBHED37wg+acc85x4cX+Kb3yPfnkk93oozjL T+7iiy92f+7C/tMXHI0YKa7kVFxx/q//+i8fxWgO8COPPJKTR/X4+7//+5zSoPDnnnvO5StZw05f dRYuXOjq68P0xUif/P1XkLPPPtul96x8PH8UCzFRPfRyqa9Eqksxp/zF4q677nJR9fVKU9XSpFWC qH7py4wKe/HFF90L85IlS1ydxfX00083EyZM8MlyR6X38Q444ABzxBFHmI985COu7/pIiqM6fPnL Xza//e1vzf/93/+5tgr+TnxcfwzWWaxGjhxpPF8fxx/FU3z8b0jy6i/8Qp02nvJVfrfffrtZv369 K8aXHWxb/xtQO/i2veiiixwzjVjKBfn68sOy+bqq/ylO3759je5J//AP/+Dy8P+CfVD9VRyVVv1V fdn/Nn18f/Qyx4X7eDrOmTPHSPH/93//96B33rlG2qWQxbWf6qzfX/Arqu+/klcuiWfwniKeyieY p+eufNRXg2HBc4XLeb7+9yMeaoMPfehDsS83KkO/VaVVfMmR5t6l9qvkvid5VbbaVnn5+1TwnhTs B6qv+v1//ud/5to/SgbJH/WlSf1WZemoeqofxbkojr4dg2mC8qku3/72t93vKNxPFc//Zv3vV78l xfPtqDbyLm35Pj5HCECgCQhYhTfW2R99bFhUwGc/+1nN1em66aabuuyNMCpKzs8qYC7u3Xff7fze fvttd20Vh64TTzyxy958u+zDqGu//fZz/nb6kItnP+N32QeI+7MvErlzn/EnPvGJLvlbJb9L8tgH h7vu1atXnkxWMXf+11xzTS5fpbOjHl2f+tSnXJjKt4qzK99+gvdFRB7Fyr6wdJ111lkureqh9FYx d9fHH398ZDp5BlkpjWSTmz9/vsvDXdh/CpOM//u//+uO9kHfddVVV7ngZ555psuOwjlZ7YOhy97M uxSu+Haqlc8i7xhuX89EaZWXOCsvOwpZkM/06dOdn1WUcuUqnXf24eHCDzvsMCeL8lI+ynfWrFku mq+H8gg7OyKVS+/DVA/VR3mKhWTTtfJUfO9UD/VDH+7rYb8+ufj2i5OP6lgrrvLzTtztAztXluQ7 +OCD3bVVsn20xKPaX/nKhTnLX+He2alvXXb6hONzxhlndNk51F32QezKs2tifDR3tMqEy1fp/Z8Y TJkypcsqZLm4qo/KsUqAy0fnvq/nIgVOxE91U17iduWVVzrOug7X2bebZBQb/Xl5xdbXt1i8QPGu j6ostZHyU5vpWm2rvu2d6iV/f1Sfsi+bLv7QoUNdnZVWf3K+Tyu+d8H2VTyVZ1/uXb7huipc5Ymd 6ig28hNPyaa8fH1VhsqTk3+wTOcZ8U9pf/SjH7n87EBHRIydXpJRctx55525OL5c+SlMceSCbel/ fzoqjuqncJ9WMspfDHXUPcPLrWvVVU5t6eutvqpzX14wnuIGy1c85efLt1M/FSXnFCaWvn6KL8b+ nqNyvdO9TnGVxru09z1fX58ueAzeV1S2v2/6spVWcqme6geek2/rJBl0/w8631aqn8rSn/qV7p3h uv3lL38puA95jnH9VO1oXybcc0gyB/up5BBn1U/+yktx/O/Lt6NnFWxHySnuceUrTHnquVCuCz4H S83Dy1xqOsVvxrSwSt/SsCpktVMzKfR3PqX+ILyyY0eD85TZqOyvv/56d6P48Y9/7IIXLVrkrpWH bvBS8OV0tCOtLkxKjPfzN2KF+7h2ipGLp5uQ91N8vYjopvSlL33Jpdc/3bTl55Uhxde1FH+lt2sH cnH10qEwa80i5xc+ESu78M3Fu+222/KC7eiZ87/nnnvy/P1F2o7pb656UNivEa6Ovo2kqEpG+Xun OumGLX/VN+x8Wu/vmSi+Hnqe4apVq9wNX/7+IaEbvK79Q8vHVV5KqzA9zLy/jpJN/nbBty/SPeCV R9jpAaa4yktO5erajoLn8pS/HXVz/r4d5Resh/qXl0Gc9eBSPvOtYhaMK7be6WVRcYJp9RD0/CVb Med/C4oX5qy8Fe6dzqUIPPTQQ97LyWy/FHUdc8wxXXZam/O3X6GcXHZ6XNe6detycb/3ve85f730 eudlVfsr3DPw4eGj5y2ecpJZabxCElQ49duTvOoX3imu72v2K43zLhZPTOWC/cX7KT/xECv9Jr3z 9VKfCbaP4mvAQPF1rj853xeUzju9lIbbd77tD76uwfZVHRRX/cbXV3n7fqe44fb15aQ5Ku0nP/nJ rqOPPjoxuu//ktE7X66XW3WQ029BMkvJ8xx0FC/5637k0wZ5+nuKy8T+U1zV3zvlEc5XYeF4vj2V d7B8X5b/TSut91N/Cpb/+uuvuz6mlyvvohT/tPc9X1+flz96VmrPoKxewRVTpQ32g6CcykcyePl9 vuor/vegPuhdVFxfV3EUD+/e//73O7bhfu6ZRfVT/S5UtmRWfXw/9S9pytun1+/L11n+vh09q/A9 QXEU3/e34D3B54niL0rpnOecLnZ+rLQ6Q36qnVeVlNuMaWFV2AuqqviPHj26y87bd6UUg62Rft1o 7OdtF183WF3379+/y5q2y5PUP0iCyp1uxBqhCDopDX/+85+77FSQoLe7WSlvjcZ75xUCn6duaIqj P/vZ3UdzR69Yffe7383zD17oB7Fs2bIu+9neKRvBMF+WXfMQ9M6dF2PlI/qba/AmrnKjlAKfRg8B 1Uk367AL/4i9nHrohZ1/CEgGOa/464EXdv4hqTYNO/8w9GH+IeKvfXx98ZHcXhHUUQ8q/7XAx9NR 8VSmd74eQT+Fqb6+Hv6h6eP6eqkc5Rdm4FlptEyyFXOlKP76zahMvbgGnfqkr7/81X8Vz06PC0Zz 5/qipLBXX33VXfu+opeYNE78xdeX5+sb5qO8xEajij5uMH/J7NMWi+fT+f7iFRbvr6P6uurly/L1 Uj8KO6/4B/3D8queyi/cN/Qb9L+VYPt62YJKjvIP5uPrGyw37fny5cu7NAr+d3/3d0WTqO+Ju3e+ XPkF+6uUv6jfpdL5NvFpPc+o+0MUJ/kFv5gpz3A8sQn2JcWRC7eF/JLK9/cGpZMLK/6l3Pd8fV1G gX9iF8VK8ks2laG0vh/4+4bPwtcpeE/2Yb4/+bAkeX0/V5ly6u/iGmxXF7DrX/g+5OXzL1XB+obb xzP3XH2+Pp5PW047ovh7msWPnnPxmIUx0uoMhSkLB6Ki4sT5VSJzvdLCqrA1qzrH32Zv7x3pnFXa 8yL6xb1WgXFz/oOBfm7+m2++GfQuOLc3cTNx4kSzadMmI1vTjz/+eF6cjRs35l1HXWgx8rHHHpsX 5MtfuXJlnn/4QnP49ffyyy+bX/ziF+6oOJ7L2rVrw0nKug7Pe9WcTjkx9fM3nUfgn+38gavk03D+ im2VIZfI/njzEnv/oKfmTdsHlrEKSNDbnSu+5v1KHoVrLrHmmmr+tBZ9yylM81/tgz9nOURtq8Vn jz32mKujwsOyuMSBf1b5DlztPPXyxqVVvnL2U3oeS8071zx/OwKZW7OwM8fK///gBz9wZltlDUt9 XL8BLfRUewZ/J1r7ojD1Y9/mvnTF13oZ++Usb13ApEmTfJTEo9pCf2Kv9tMaGa130XXYqX9oPrDW rliFxc0dV1q5oLxp46nPKr2d2uDmJYuzd36hodol2J6+HX28tEdfn2BePq3aVv3W9wHvr2M4vq9v ME4551rLpHrbr5FFk+v3IXOa+q3436jO1ZetMpdLrzqKT9S9wI44u/bVGp1DDjkklyZcv1xAGSdi oz/Job7k+6pnH5Wlr08wzDOOS+fzLfe+5+8hVmkOFuvOda/Rn5zvgzoP9zsvg/pOFG+l8f3J33N8 vRTmnfh786jy82nC9yEfP+4+VO929PJxhAAEGpdAVRX/gw46yN3kiynowiEFRU4LCOW84u8uQv+U r5xPEwrOu5RCohuondNv7Jxf92dHdPLiJF2EFyQnxQ2HrVixwvzLv/yLsXN2jf1y4RaxSWHVXy2d f6Bo4ZaU6CinRbJyelBpb4Cgk9IQVByCYeFz/0AK+wevJY8UqCTnH+Z6UNnRKye3V/ylzMgFlQHl +eEPf9jJrzCZia0l1ziW/iVOMlTLScFQeXoh+sd//EeXrV5gtdhU+2Cce+65zk/KmpT/cPspME6u AQMGuLTF/qldv/CFL+T42tFz07t378iXK/uVzGUnmaWI6k9tofb66le/mlu8XSxeUAFSf/CKVlDW uHqFFbBgmqRz3+/i4sT1qTj/uHzS+tsvlO4eFR5siEovvlGKv+LqBVpOv285tWcSz7DiH2wLl0EF /8J9yf9W/X0qKuskvnFt5vOL+62qHH/fiyrTp48KK9VPzx39JTnfNlFx4uofV7e430Ut29Gbma4m tygW+EEAArUl0Kua2fuRcY22F3NPPfWUi5JG8befw13cwYMHJ2b7jW98w1mV+dznPmf0sJAibudP 5h6GiYl3Bdq502miRcbRQ/mHP/yh+du//Vs3cvnWW285y0KSqzuclHftaxD+s9MvHAfJoAeDlDP9 aZRRx6gRrzh5ww+WchWwYD5SaKQs+Ae8Xl70MhBU/MXWfpp2Co6+vNjP5u5afmGX9IANx4271kh2 kKP9bO+uxVJ/1Xb6uiErSfPmzXO20mXNRy+wssrjnV5g7SLjPLm8jF6uckf89FIllrIGojztehR3 bac2+OLzjlLq7VQAo9+xXUPjXsTsNAP3chaMmDae+oPK9ZyL1StOUQqWHXUe7HdR4d3tpxF/fa3R i14xJ9n1W/WWcjQSrd+KnfaUewn29VM8zzB49P3ELgYvVlzZ4XqBDPYl/1uN60vFCip2j0lz34sq o5zfSpws+g0EOftz/Uai7lFR8kT5he9DPl/fjlFpquUXvieoHvortx2rJRf5QAAClRGoquL/gQ98 wEnz85//PFEqTSPQjVKb1cj0p1zSiL9s9ssVG4335Uqh1SYzfqqEpoekdd6UYNr4Pp6dk+lMgGpj FJmW82XruGbNGh+tJkf/MNJITLDc8LkKl2IgZUx/2kVZx/AD0CvgQWH9KI9XLHyYFPawk9Ie99k7 Ku/gSL/ClWdQ6Vf+XpnXQ16fuX3dNJUgznmZg+FR5QfDvUIpGXwZUcdgmqTz8Ncv/zUjLo0UQJn3 034X2uNC08Z+//vfu+jq//rqFSWP94vLN8lfnKSgSFnUC5bPS8ekEVOFayqCNuiTQiAFVEqezK0G XVw836bqL2qXYLnh82B+1TiP6wfqt5KnO5wGNPTilGa038ujkX21l9jJTKucH+3Xuf996qUgzDB4 rbi1cuoL+uJXSl+Kuo94+fxv0l/7Yyn3PZ8mfFRbR/VxMVZfCPeTsJyet/II8g2fq9zwfTYoi/8t eD9f52rdh3y+aY/l3hPS5k88CECgfgRag/MXo8QoFh5Mo5GrCy+80CktX/va15wt/2C4zqUU2IVs zvu6664zst+vMnSjkZONaN3s/E1dfv7rgOYUe3n8i4K/VrylS5fq4Ebbg/6aby+n0Xzv7xX8zZs3 Oz//6VTz8H0cl8j+C8f1/sGjXdjrLmUPPJxe9ZSzi5YLwlyA/RdO4/2DR8kqJ3mC8cVFzi5ALPjc rE/62p/gM5/5TN6cXpfA/gvm4+sp5VTpglOkvPKpTdeCadQOwWvlqykqmreuFzFrmcIX5eIpb03B ksLo00mR10i2Roy1PkNOG7z5cF1rpMu7oP+//uu/Ou+gHJ6TeGj0MVgP/zXqPe95j8vf19n3A82B 1joPPfS1IVTwZVPlagRe02CC9fJyBY/ae0IPc9mW10uMl1mb28l5eRX+wAMPmN13373AnrdeirVO RUqF0tvFvW6/BL1Y6gtB0Gl/AmsZxu01oHUmnoGvVzBu+Ny/mHqZfLj6gF4M5Xw+8hMD7ccRZqA9 BfxotNgVi+f7sV5wVMcbbrjB/NVf/VWOlcqVn5Qo9V85Xy+tZ1AfinLBdgu3r9KofaP6uB84kDy+ vcREzl+HyysWHo4fvLYLSN09QVMZ4/IPxte5n+alfqS20G9JU3qC6dVP7r33XvdiEB7ZD/ZfpfE8 fVuEywv3CR8eLE9+4XgakQ7G0bnvS7pX+jBfvr526QUy6OSn+um35OMr3PfFUu97wTx8OWprPR/0 XAqueRAn3cO0n4v6uW/nMKejjjrKZaV7l150gk7to692ejFT3n4fGNUrHFd+cr5uSfchxQu2o669 fME6Bs+D7eOZh+sSzCfunqA8fTt6WZXO56nzYLm6LsWRNj0tWMEqjkDRvmEV3lhnlfHYsLgAu2mV syluBeqSTfIvfvGLzva0rCHIBrms9ijMTn/Jy8IqOM7fPsScDX47t9GFWyXHWe+RWcOg+/jHP+78 7WZZXbKDLiebycrbTldw5kRlPtPedLvsBldde+21V5e98bq4ViHrsqNSLq69ibm09kHlrocMGeKu g/9k4UH5+rjBMH9uN1Tqsg9wF+/GG2903rLSYl+Gun7yk584f+VhFRmfJHe0o0q586QTO9rt8pHs 3vk28mFWsemySo2zRqGjrq3i22VHdH2S3NGn9R6eiR0Fc+nESZYo7OZBrlw7iuejOksXqo8dJc75 +ROVpTKtQt+ldlQeykuyKI3djM1HzR3VPxRmR9AiLVl4Cx/a/0H5qW7qK/KXvHaEzLWprGF4FpJB Zfr2lk38sMy+zkrjnX0Iu3hBlnZ01ZWn9GELLz5d8Ki2V1z7FcxZQJK1Dfswd78J+dvRv1x0qzy4 vizTezLdKctQOrcKb5dVerrs1CYX1y7qdfWRv/qiOEt+nStP2f/3zjNI6rM+ro5iqDzU1spT/VT1 9/moXcRdzret8paf5FA7qw0UZpX4VPG8pR6l93nal+Rcf1H+qqssnnjn5dEx7LT3gOpgvyC5Nlf+ qov8gvHVFvILtq/uGeqvkkPyeKf+rbhRTv4KD/+OouJG+VnlzXGXNbBSnPq82kPlB9n4PNQmnqfa RfXRb8CbMRULL7POlY84hZ2vX9BffuIbdOF4uk/Iz/clyRDuS5Ip+FtV/5N8/p4j2/rKQ3X1LmzV R/5e/mBbRt33fH19Xv4oOYKsVL7/Pfn7ndL6cqI4qQ0kq+5HXn4vg31xcfx9eb4/+boqns49M5Xj nTffG6yb8lc5Ki94H/L5evmC9VVchXundPLTPUj5iYGcj+fThu8JUe3o7wmeD1Z9HMpU/zznVJFD kdLqDKFk7rKScpsxLawKe0H0E21XvHIbWUq0bFNrUxzdTPTw1p8erDK5F7Zzr+LsDq8urp2f36WH v5QkbbqldFKepQwFnW6YujEpXPHk7KhwbiMg+cu8qPKTkylNbeolf93sdIOUbF4x8oq/wsMujeIv VpLRbmfvylA+2ujG38jtzr9ddhqQCwvnn7Zj+purv7krn2AbKVwPMZXt//RAkd3pKBdMq3DPRPno Yebz0FEPjmA+SusfFFF5K67SBPOQbLJJHS5X6aUEKD/9STELO5nGU34K93l6pUfxfb1VB89JCnxU PZSXd8E6ez8dldb3L1+eruWf1tmvFnnyqh/bOfzOL6j4S/GTMqX+4svSUS8NerENOruTdZddQ5IX Vy+cvh/7uJ5B2N+Hh49qr2B9xVMvY3JesZFMcuInc5pBWXWu9lE+vn2LxXOZ7foX1V/0IqF6BJ2v V9hfcbThkerg+4jaNq591Q99n/H18PIHy/N9Lujnz1WOwn19vX/aox2977LzqNNGz8XzipvK94pX LnDXSRRPsdELpZyX2fMUp7Dz9Qv6y6+Y4q+ydd/xXIPt6F/OFKYyffn6XYmlT6Nygkq/ZIhS/OWv PMJtGb7v+foqfthJXrHxZeuo/u3vE0rr5YzipPyiZFB9NGAQdMpT/qqfL0/X/hmjfLxTuWnvQz5P /zIdrG9UO/r4ksGX6eP5tGEuase4e4LyUHoUf996xY+ec/GYhTHS6gyFKd/57UeFFfOrROZ6pYVV YavWRPFXMYItZVqNrR0ptUmJrvUX53yY0uhcO+Haz6WxabSJkZ0G5PL2eSqtypZ/cJMjhYfL9+X5 tLpphv18WJy/Dw92ar0A2OlKXfZTqg92x3D5PrCUjhmWI1iu8lO4bth6kOghE47vy9QxnFYPNd28 /YNAaZWPb7twWoUn5a8wpVUeksnHDZfr81W4j+P9gkeF2Tn9Lr9wvHDaYLjOJYPvk8E8dR6MGwyT v5c/Lm0wftS5vgTZ6Txdstfuy/HHcHxfnvaRsFPOXHASK/Ux2e2Py2/+rpG8cDlx1758tZVXIHxc hYXLUf8S13AfCcscF8/n7Y/KX5zD+flwfwzL4f1VrsIkv8r0Li6+j6vytD9EVDz5Rfkrbx8Wrq8v N+moF0D93uI29UtKqzCVHW6jcBrF8f1XR117F5Q56O/DdZR/OEzX4ftVXDxfdjAP30ZBP3+uo+8r 3i8oj08b9PPnip903wvW16cJHpU+Sl7F8WmjZArn4WVQXP2FWSm+/H1Zqq+uvb872fUvWG5U/GBc 5eHzkb9Pq/NwmPdTnvrzzscLp1Uc1SuYv88j6KfzYFqfb9pjFKu0aSsptxnTwiptz9ipi6aPnR+z GftGGplbraJXM2dHE9z8ajtNJ1UZiu+dzvfbbz9/GXmUvW8/zzMYwY7eRC7QC+av+FHXYT+fb5y/ Dw8evfnRoJ/OS8kjnNZfF8tD4fbTsI9e0VF52c/KsXmkkcV+uTH6S+PS5GdH9pwFmXB+4bTBa52r Hpr3FvT3eUT5KUz+Xv64tD6PuOOYMWNypl19nDTl+bhxR+VhRzXjgp1/XDlxiRTft1V4jmBUXlqb kdQ/fDlp46kMO6pYNM8oWXxZCgv3/7j4wbh+cabPxx/j0io8KcynjztqrUx4vUxc3Ch/lV2sfIX7 /huVh/eLyyfKvxS/uLLDefhrHYv1FR/Xy+6P8g+3uw9Lc1T6OHl9+riyg+FpZIgrKy7/uPi+XB3j 0saF+TyL5REVz6cJlxm+9vE4QgACjUWgqlZ9GqtqSAMBCEAAAhCAAAQgAAEIeAIo/p4ERwhAAAIQ gAAEIAABCGSYQE2n+mSYWyarJhOqdr5zbrpHJitJpSAAAQhAAAIQgEAPJYDi30MbPqraaeZXR6XD DwIQgAAEIAABCECg8Qkw1afx2wgJIQABCEAAAhCAAAQgUDEBFP+KEZIBBCAAAQhAAAIQgAAEGp8A in/jtxESQgACEIAABCAAAQhAoGICKP4VIyQDCEAAAhCAAAQgAAEIND4BFP/GbyMkhAAEIAABCEAA AhCAQMUEUPwrRkgGEIAABCAAAQhAAAIQaHwCLR0dHV21ENPma2QeElecAKyKM/IxYOVJFD/Cqjgj HwNWnkTxI6yKM/IxYOVJFD/CqjgjHwNWnkTxI6wKGbW2tbUV+u7y6ezsNEnhsQltgGCXm7aScpsx LaySelJ+GKzyeSRdwSqJTn4YrPJ5JF3BKolOfhis8nkkXcEqiU5+GKzyeSRdwaqQDlN9CpngAwEI QAACEIAABCAAgcwRQPHPXJNSIQhAAAIQgAAEIAABCBQSQPEvZIIPBCAAAQhAAAIQgAAEMkegNXM1 okIQgAAEIFAxge3bt5vNmzcbHeVaW1tNv379Ks6XDCAAAQhAoH4EUPzrx56SIQABCDQUgY0bN5pF ixaZpUuXGhlK0PW2bducjH369DEDBw50LwItLS1mjz32cC8DDVUBhIEABCAAgUQCKP6JeAiEAAQg kG0CUuxXr15tXnnlFfPyyy/nFP9169aZHTt2mK6uLvfXq1cvo79BgwaZl156yYwbN85MmjTJjB8/ 3gwZMsSFZZsUtYMABCDQ/ARQ/Ju/DakBBCAAgbIILF++3MybN8+88MILZu7cuU7pL5bRmjVrzNtv v21mz55t9ttvPzN58mT3N3HiRDN48OBiyQmHAAQgAIE6EkDxryN8ioYABCBQDwIaydcI/yOPPGLm zJnjFPktW7aUJMrWrVvdyP/ChQvdS8ORRx5ppkyZYsaMGVNSPkSGAAQgAIHuI4Di332sKQkCEIBA 3Qloao+m9DzwwAPmxRdfNBs2bChbJk0DUnpN/dFXgBUrVphp06a5+f9aB4CDAAQgAIHGIoDi31jt gTQQgAAEakZAVnqeffZZc8899zilX4p7NZzy0Q6ZM2fONPoScMYZZ7hpQCj/1aBLHhCAAASqRwA7 /tVjSU4QgAAEGpaApvf85S9/Mb/5zW+qqvQHK7xp0yYza9Ysc9dddxlNAcJBAAIQgEBjEUDxb6z2 QBoIQAACNSHw5ptvupH+V1991VnpqUkhNlON+D/11FPmvvvucyZBa1UO+UIAAhCAQOkEUPxLZ0YK CEAAAk1FQDb5f/vb37qRfr8hVy0roClFf/zjH93iYb8PQC3LI28IQAACEEhHoGXBggXVmeSZrjxi QQACEIBANxKQoq/pN/fff7/RVJzudCNHjjTnn3++2X///buzWMqCAAQgAIEYAq3ahCXOaZSora0t LjjRX/M7k/JOSlxJuc2YFlZJvSE/DFb5PJKuYJVEJz8sy6xee+018/TTT3e70i/CK1eudGUfd9xx ZujQoW7qT7nPFO7t+X026QpWSXTyw2CVzyPpClZJdPLDGpkVU33y24orCEAAApkhINv8mnKzZMmS utRJ1n60OZj+qmVBqC4VoVAIQAACGSGA4p+RhqQaEIAABMIEVq9e7XbY1YLbejnZ+dfLx8aNG+sl AuVCAAIQgMAuAij+dAUIQAACGSUg852LFy+ua+1kRnTu3Ll1++pQ18pTOAQgAIEGI4Di32ANgjgQ gAAEqkFAo/zaUKsRrOqsWrXKPPPMM9WoFnlAAAIQgEAFBFD8K4BHUghAAAKNSkAj/VrY2whO8/sf e+yxhngJaQQeyAABCECgXgRQ/OtFnnIhAAEI1JDAs88+a2RPv1HcokWLzNKlSxtFHOSAAAQg0CMJ oPj3yGan0hCAQJYJaF69LOk0ktN+AvPmzWskkZAFAhCAQI8jgOLf45qcCkMAAlknsH79+oYcXW+U qUdZb3/qBwEIQCCOAIp/HBn8IQABCDQpgY6Ojrps2FUMl/YT0NcIHAQgAAEI1IcAin99uFMqBCAA gZoRWLt2ramn7f64ismm/6ZNm+KC8YcABCAAgRoTQPGvMWCyhwAEINDdBLRZlubUN5qTTGzk1Wit gjwQgEBPIoDi35Nam7pCAAI9gsCWLVuMTGg2mpNMkg0HAQhAAAL1IYDiXx/ulAoBCECgpgQaVfFn jn9Nm53MIQABCCQSaLGLwGoyLKTFZe3t7YmFE7iTAKzS9wRYwSo9gfQxs9avZMP/Rz/6kdGc+kZy I0eONF/84hfN6NGjG0msmsmStX5VM1A2Y1ilpwsrWKUnUBizta2trdB3l09nZ6dJCo9NaAPUMctN W0m5zZgWVkk9KT8MVvk8kq5glUQnPyxrrIYNG2ZaW1vzK9kAV7169TKjRo0q69nAvT19A8IKVnEE mrFvVCJz1u7tce3q/dOwYqqPp8URAhCAQEYIDBo0qCEV/759+5qBAwdmhDLVgAAEINB8BFD8m6/N kBgCEIBAIgF9be3Tp09inHoEavpnI8pVDxaUCQEIQKAeBFD860GdMiEAAQjUkMDQoUPNkCFDalhC eVnvsccepqWlpbzEpIIABCAAgYoJoPhXjJAMIAABCDQWAU2pGTt2bGMJZaXZd999G04mBIIABCDQ kwig+Pek1qauEIBAjyFw8MEHN1RdNcUHxb+hmgRhIACBHkgAxb8HNjpVhgAEsk/goIMOMhr5bxS3 1157mREjRjSKOMgBAQhAoEcSQPHvkc1OpSEAgawTkM38/fbbr2GqedRRRxmZ88RBAAIQgED9CHAX rh97SoYABCBQMwJaRDtlypSGULZlwvPQQw+tWV3JGAIQgAAE0hFA8U/HiVgQgAAEmo6ApvsMHz68 7nJrobEs+uAgAAEIQKC+BFD868uf0iEAAQjUjIDm1B9wwAF1NaHZu3dvM3nyZDN48OCa1ZOMIQAB CEAgHQEU/3SciAUBCECg6Qj079/fHH744UbHejkp/IcddlhDLTSuFwvKhQAEIFBvAij+9W4ByocA BCBQIwJaTHvIIYeYPffcs0YlFM920qRJmPEsjokYEIAABLqFAIp/t2CmEAhAAAL1ISDrPlOnTjWy o9/dbtCgQeY973mP0REHAQhAAAL1J9DS0dHRVQsxbL6mvb29FllnLk9YpW9SWMEqPYH0MbPUr7Zt 22a2bNliZEnHuzVr1pgf/ehHZs6cOd6r5kdZFTrxxBPNxz/+cdOvXz9X3vbt283atWvN0KFDG8La UK0hZKlfwarWBNLnT7+CVXoChTFb29raCn13+XR2dpqk8NiENkAds9y0lZTbjGlhldST8sNglc8j 6QpWSXTyw7LAauvWrWbp0qXmz3/+sxt0efe73220sFZO9+IPfOADZvHixWb16tX5la/R1ZgxY8z7 3/9+M3r06FwJr732mnn44Yfd1B+tPdDgUFrb/tzbcxiLnsCqKKJcBFjlUBQ9gVVRRLkIjcyqNScl JxCAAAQg0JQEli9fbl544QXz7LPPmtmzZ5tx48a5uf2a5uOdTHsed9xx5oEHHjD6KlBLpx2DNdo/ fvz4XDFdXV3upeT3v/+928F34cKF5ogjjnBWh+q5+DgnICcQgAAEegAB5vj3gEamihCAQDYJSJnW KPpdd91l7rzzTvPYY4+ZDRs2mPnz55snn3wyr9IDBgwwp512WrcstJUJUX1x8FN8JIgU/VmzZrmX Dn2Z0AvAr3/9a3fU6BgOAhCAAARqTwDFv/aMKQECEIBA1Qloao/m7N9+++3moYceMosWLTKaQy+3 adMmp1C/9dZbuXI1514j8GeffbYbcc8FVPlkt912M+ecc06eJaH169eb3/3ud2bJkiW50jZv3mxe fPFF99Jy9913m7ffftvoRQYHAQhAAAK1I4DiXzu25AwBCECgJgS0ePeZZ55xI+aa2iNFP+zeeOMN c99995l169blgjTn/5hjjnGWdoLTgHIRKjzRfH7N6z/00ENzc/f1MqIpSH/6058KFPsdO3a4NQd6 Kbjnnnvcl4oKRSA5BCAAAQgkEEDxT4BDEAQgAIFGI6CR/kcffdTce++9bl6/H+WPklNTf55++unc lwDFaW1tNVOmTDFnnHGGs64Tla4cP1nqUZ6a4hNcsKsFxeEXkHD+enHRNCBNV3r11VfDwVxDAAIQ gECVCKD4Vwkk2UAAAhCoNQEp/U899ZSbHqM580lKv2TR3Pn777/fvPnmm3miya6+5vtrdH748OFG 04DKdUo7bNgwM23aNHPqqaeaIUOG5LKStSRN45k3b57R6H6S03QgrUuQ8q9pS0z7SaJFGAQgAIHy CKD4l8eNVBCAAAS6nYAs92ghb1iRjxNEyvbLL7/sptGE5/vLlOaZZ55pPvjBD5r999/ffQmIyyfO X18PJk6c6PJQXkETzitXrnQvHfo6kdaKkH+x0dcMpcdBAAIQgEB1CWDOs7o8yQ0CEIBATQhoFFyj 55oKU8pouL4KPP74487CjpR82df3bvDgweb00083u+++u/uSoK8JaRVujfIfddRR5uijjzYHH3xw 3oZhWlcgs6H62qD1CKU4xX/iiSfcbr8XXHBBXXYcLkVe4kIAAhBoJgIo/s3UWsgKAQj0SAKasjN9 +nRnxafY9J4oQJpD/8gjj7hRfW3k1adPn1w0mfmUPX1Z/Nl3333N3Llz3cuFylRZfoqOpvRohF8m OmWuU8q+0o0YMSL3tUAvJNolWKY6pfiXa6ZTeSj93nvv7dYj+I3IckJzAgEIQAACZRFA8S8LG4kg AAEIdA8BTZORRRyN2qedMhMlmebQz5gxwwUdeeSRRht6SZGX03HUqFHO2s8hhxziFH+Z3pQCLrOb Uv6l8GsBrxbuHn/88WaPPfbI7QysPBRHXyUkp0b6lbYSp/Sy9LPnnnuaCRMmVJIVaSEAAQhAYBcB FH+6AgQgAIEGJiAF/MEHH3Qbc1Uq5tq1a11espmvFwFN1QlusiWlXtN+9Ldx40YXR/PupdRrN96B Awca7RKskfig0wuJrAdJ6dcxaEI0GK/Uc71IaI8CvWTgIAABCECgcgIo/pUzJAcIQAACNSGgqTZS +rUTbynz+pOE0c6+squvufx6AZDyr0239AIQtO6jKUD6C7sVK1bkvPQ1QC8CUva1iFd7B5Q6pz+X WcSJXjpk6UfrCBj1jwCEFwQgAIESCaD4lwiM6BCAAAS6i4B2tp05c2ZFU3yiZNUIvV4mli5dal5/ /XVz4IEHujn+mu4jaz/BrwDh9Br9X716tVP4FyxY4NYEaDMxfU2ohVu1apXbB+Ciiy7KsxpUi7LI EwIQgEDWCbRYO8s12SNd9pv1AMEVJwCr4ox8DFh5EsWPsCrOyMdoRFaaanPLLbe4+f1ezlocNb1H 92pZ+9HIvxbr6k/z+TW1xy8E1ui+lHuZEtU0IZkH1RcDfTkoZ8FxKXWRDB/72MfMySefXEqyusdt xH5VdygxAsAqBkyEN6wioMR4waoQTGvQ7nI4WBYZksLD8YPXgl1u2krKbca0sAr2nORzWCXzCYbC Kkgj+bwRWWnajGzw19ppBF+j6hrF1+i/lGwp/bp/y9ynrjXNSIq/FtwuW7bMaAqOX/Rba/mUv8rT LsTacVgbjpXq6vVcaMR+VYwdrIoReiccVu+wKHYGq2KE3gmvNSum+rzDmjMIQAACDUFA8+Rnz55d sWWcUirjlXsp9FqcG9zwq5R8ahV38eLFblrRiSeemLcWoVblkS8EIACBLBJg594stip1ggAEmpqA Rnz+8pe/1HwKTTNB0tQnrSXQngQ4CEAAAhAojwCKf3ncSAUBCECgZgReeeWVhhtxr1llU2asLxLa XEzTknAQgAAEIFAeART/8riRCgIQgEBNCGjO/axZs9y89poU0MSZynToCy+80MQ1QHQIQAAC9SWA 4l9f/pQOAQhAII+A7OTPmTMnz4+LnQT8S5GOOAhAAAIQKJ0Ain/pzEgBAQhAoGYEpPTLXCYumoCm QWk3YxwEIAABCJROAMW/dGakgAAEIFATArKHrwWsuHgCsngEo3g+hEAAAhBIIoDin0SHMAhAAALd SEB28hcuXNiNJTZnUc899xwWj5qz6ZAaAhCoMwEU/zo3AMVDAAIQ8ASWLl3qbOj7a47RBGTTXyZP cRCAAAQgUBoBFP/SeBEbAhCAQM0IvP3229ipT0F3w4YNzPNPwYkoEIAABMIEUPzDRLiGAAQgUAcC slMvc5Waw45LJqBNvPR1BAcBCEAAAqURQPEvjRexIQABCNSEwNatW83KlSsNpiqL4xUrvSTpZQkH AQhAAALpCaD4p2dFTAhAAAI1IyBldvXq1TXLP0sZ6+VIO/iKGQ4CEIAABNITaOno6KjJkInN17S3 t6eXpAfHhFX6xocVrNITSB+zEfqVFqt+5zvfMfPnz08veA+OecQRR5hPfvKTZuDAgQ1LoRH6VcPC CQkGqxCQhEtYJcAJBcEqBMRetra1tRX67vLRgygpPDahDRDsctNWUm4zpoVVUk/KD4NVPo+kK1gl 0ckPawRWGr3W3HVcOgJa4DtgwIBUz5l6PRcaoV+lo/lOLFi9w6LYGayKEXonHFbvsCh2VmtWTPUp 1gKEQwACEOgGAtu2bWPH3hI4r1271ogZDgIQgAAE0hNA8U/PipgQgAAEakZAu/Yy4p8er0b8UfzT 8yImBCAAARFA8acfQAACEGgAAlL8WayaviH0koQFpPS8iAkBCEBABFD86QcQgAAEGoCARq8xT5m+ IbTfgV6WcBCAAAQgkJ4Ain96VsSEAAQgUDMCKLGlodVoP8xKY0ZsCEAAAij+9AEIQAACEGhKAkz1 acpmQ2gIQKCOBFD86wifoiEAAQh4An369PGnHFMS6NWLR1hKVESDAAQg4Ahw16QjQAACEGgAAq2t rUZ/uHQEpPT37t07XWRiQQACEICAI4DiT0eAAAQg0AAEpPQPGTKkASRpDhEGDx5s+ErSHG2FlBCA QOMQQPFvnLZAEghAoAcTGDhwoJkwYYJpaWnpwRTSVV2MxErMcBCAAAQgkJ4Ain96VsSEAAQgUDMC UmJPPfVUs//++6P8J1CW0j9x4kRz2mmnofgncCIIAhCAQBQBJpRGUcEPAhCAQDcT0FSfww8/3PTr 18/MmTPHLF261Kxbt87IXn2U9RqZsix3jnslaSVP3759y6JTbrmazy+Ff9iwYWbMmDHmoIMOMpMn T2ZNRFmtQCIIQKAnE0Dx78mtT90hAIGGItC/f39zxBFHOKV22bJliYr/+vXrzaBBg8qSv5K0kmv0 6NHdWq4Uf71w7Lbbbq5svRzhIAABCECgdAItCxYs6Co9GSkgAAEIQAACEIAABCAAgWYi0GK3iI9V /Ds7O01bW1tZ9Vm4cKEZN25cWWkrKbcZ08IqfTeBFaziCFTy26dfxVEt9IdVIZM4H1jFkSn0h1Uh kzgfWMWRKfSHVSETFvcWMsEHAhCAAAQgAAEIQAACmSOA4p+5JqVCEIAABCAAAQhAAAIQKCSA4l/I BB8IQAACEIAABCAAAQhkjgCKf+aalApBAAIQgAAEIAABCECgkACKfyETfCAAAQhAAAIQgAAEIJA5 Aij+mWtSKgQBCEAAAhCAAAQgAIFCAij+hUzwgQAEIAABCEAAAhCAQOYIoPhnrkmpEAQgAAEIQAAC EIAABAoJoPgXMsEHAhCAAAQgAAEIQAACmSOA4p+5JqVCEIAABCAAAQhAAAIQKCSA4l/IBB8IQAAC EIAABCAAAQhkjgCKf+aalApBAAIQgAAEIAABCECgkACKfyETfCAAAQhAAAIQgAAEIJA5Ai0dHR1d taiVzde0t7fXIuvM5Qmr9E0KK1ilJ5A+Jv0KVukJpI9Jv4JVegLpY9KvYJWeQGHM1ra2tkLfXT6d nZ0mKTw2oQ1Qxyw3bSXlNmNaWCX1pPwwWOXzSLqCVRKd/DBY5fNIuoJVEp38MFjl80i6glUSnfww WOXzSLqCVSEdpvoUMsEHAhCAAAQgAAEIQAACmSPQmrkaUSEIQAACPYTAtddeG1vTk08+2UydOjU2 PCqgq6vLtLa2mk2bNpk+ffpERcEPAhCAAASamAAj/k3ceIgOAQj0bAIzZswwUtaj/sols2PHDrNl y5Zyk5MOAhCAAAQamAAj/g3cOIgGAQhAoBgBjeonjezPnDnTaPT/ueeeM3fddZf56le/mpflAw88 YF544QUzbNgw84lPfMKFSfEfNGhQXjy9ZMjts88+7qh/3s+X/8QTT5gFCxaYl19+2Vx44YVm0qRJ ubgqZ+7cuaZfv35m3333NaeffroLC+ahLxhXX311Lg0nEIAABCBQXQKM+FeXJ7lBAAIQaCgCp5xy ilP2v/CFL5innnrK9O7d28yZM8fJeO+995ozzjjDzJ4927z++uvmox/9qPPfvHlzZB1OPfXUPH8p 7XqxkFP+55xzjrn//vvNq6++aiZPnuxeKBQmhf69732vefvtt82SJUtcmcFpSjofOXKkkTw4CEAA AhCoHQFG/GvHlpwhAAEI1JyAFG+vfAcL8yPnmga02267mQcffNAFX3rppebnP/+5OfHEE82vfvUr 8/Wvf91ceeWVLuy73/2uue2222Kn+iivOPf4448bpf/IRz7iokyYMMEsWrTIHHTQQa6cW2+91Sn8 svYmeRTXy6gE119/vTn//PPjsscfAhCAAASqQADFvwoQyQICEIBAvQgkKeNepqBCPW7cuNxLwKxZ s8xZZ53lo5l3v/vd7rycOf5f+9rX3Kj+woUL3RSfL33pS2bgwIFu9H/lypXmxRdfNM8++6yb6qNC 9FLw5ptvuvI0Rejhhx925/yDAAQgAIHaEUDxrx1bcoYABCBQcwLF5vhLgPB8fS+Upt0MHTrUX5qx Y8e683IU/9NOO829UNxxxx3mhz/8odm2bZtbAyClXwuGgwuQVcjnP/95p/zrPG5qkcJwEIAABCBQ PQIo/tVjSU4QgAAEGpKANrHR6HvYHXbYYeaNN97IefspQ0mK/7p163LxNb1HU4a8C76EaIrPNddc Y7797W+bZcuWuSk/mucf3tjRL+71eXCEAAQgAIHaEUDxrx1bcoYABCDQLQTilGdvbUc7mu+xxx4F spx99tlG1namTJniRuR/8YtfuDhRir/yOu6449wCXCn1WpD7rne9K5fnSSedZD7zmc+YadOmOcs+ AwYMMEcffbQZPny4m7v/k5/8xFkOmjhxorn55pvNH//4R3P77bfn0nMCAQhAAAK1J4DiX3vGlAAB CECgZgQ0qh7l/Oi7THlK8Y9yX/ziF91iXCnwZ555ptH10qVLYxf3XnHFFW7xr0x6XnzxxXlZ/vKX vzRXXXWV+cpXvuI2AZMFoM997nMuzg033GC+/OUvm8suu8xs3LjRHHHEEebGG2/MTUGSjDgIQAAC EKg9ART/2jOmBAhAAAI1IZBmQWz4a4BeFDS/Xq6lpcVZ3AkKF44fDJNt/hNOOMFogXDY7b777uaW W24Je7vrESNGOEVfLyDhqT56QUkqMzJDPCEAAQhAoCwCvcpKRSIIQAACEIAABCAAAQhAoKkItNhF X121kFiLydrb22uRdebyhFX6JoUVrNITSB+TfgWr9ATSx6RfwSo9gfQx6VewSk+gMGZr+LNrMErU Z9lgeNK5OmZS3klpKym3GdPCKqk35IfBKp9H0hWskujkh8Eqn0fSFayS6OSHwSqfR9IVrJLo5IfB Kp9H0hWsCukw1aeQCT4QgAAEIAABCEAAAhDIHAEU/8w1KRWCAAQgAAEIQAACEIBAIQEU/0Im+EAA AhCAAAQgAAEIQCBzBFD8M9ekVAgCEIAABCAAAQhAAAKFBFD8C5ngAwEIQAACEIAABCAAgcwRQPHP XJNSIQhAAAIQgAAEIAABCBQSQPEvZIIPBCAAAQhAAAIQgAAEMkcAxT9zTUqFIAABCEAAAhCAAAQg UEgAxb+QCT4QgAAEIAABCEAAAhDIHAEU/8w1KRWCAAQgAAEIQAACEIBAIQEU/0Im+EAAAhCAAAQg AAEIQCBzBFD8M9ekVAgCEIAABCAAAQhAAAKFBFD8C5ngAwEIQAACEIAABCAAgcwRaOno6OiqRa1s vqa9vb0WWWcuT1ilb1JYwSo9gfQx6VewSk8gfUz6FazSE0gfk34Fq/QECmO2trW1Ffru8uns7DRJ 4bEJbYA6ZrlpKym3GdPCKqkn5YfBKp9H0hWskujkh8Eqn0fw6uabb3aXl1xyiTvCymFI9Q9WqTDR r9JjghWsEgmk0YGZ6pOIkEAIQAACPZvALbfcYvSHgwAEIACB5ieA4t/8bUgNIAABCEAAAhCAAAQg UJQAin9RRESAAAQgAAEIQAACEIBA8xNA8W/+NqQGEIAABCAAAQhAAAIQKEoAxb8oIiJAAAIQgAAE ICMjYIYAAEAASURBVAABCECg+Qmg+Dd/G1IDCEAAAhCAAAQgAAEIFCWA4l8UEREgAAEIQAACEIAA BCDQ/ARQ/Ju/DakBBCAAAQhAAAIQgAAEihJA8S+KiAgQgAAEIAABCEAAAhBofgIo/s3fhtQAAhCA AAQgAAEIQAACRQmg+BdFRAQIQAACEIAABCAAAQg0PwEU/+ZvQ2oAAQhAAAIQgAAEIACBogRQ/Isi IgIEIAABCEAAAhCAAASan0BLR0dHVy2qYfM17e3ttcg6c3nCKn2TwgpW6Qmkj0m/imc1bdo0Fzh9 +nR3hFU8q3AIrMJE4q9hFc8mHAKrMJH4a1gVsmlta2sr9N3l09nZaZLCYxPaAMEuN20l5TZjWlgl 9aT8MFjl80i6glUSnfwwWOXzCF61tra6S38/h1WQTvI5rJL5BENhFaSRfA6rZD7BUFgFaew8Z6pP IRN8IAABCEAAAhCAAAQgkDkCKP6Za1IqBAEIQAACEIAABCAAgUICKP6FTPCBAAQgAAEIQAACEIBA 5gig+GeuSakQBCAAAQhAAAIQgAAECgmg+BcywQcCEIAABCAAAQhAAAKZI4Din7kmpUIQgAAEIAAB CEAAAhAoJIDiX8gEHwhAAAIQgAAEIAABCGSOAIp/5pqUCkEAAhCAAAQgAAEIQKCQAIp/IRN8IAAB CEAAAhCAAAQgkDkCKP6Za1IqBAEIQAACEIAABCAAgUICKP6FTPCBAAQgAAEIQAACEIBA5gig+Geu SakQBCAAAQhAAAIQgAAECgmg+BcywQcCEIAABCAAAQhAAAKZI9CyYMGCrszVigpBAAIQgEBVCFx4 4YUun1tvvbUq+ZEJBCAAAQjUj0DruHHjYkvv7Ow0bW1tseFJAQsXLjRJeSelraTcZkwLq6TekB8G q3weSVewSqKTHwarfB7Bq/79+7tLfz+HVZBO8jmskvkEQ2EVpJF8DqtkPsFQWAVp7Dxnqk8hE3wg AAEIQKBCAtdee63RHw4CEIAABBqHAIp/47QFkkAAAhBoegKPP/64OeGEE8wzzzxjurqYSdr0DUoF IACBTBFozVRtqAwEIAABCNSVwFe+8hVzwQUXmI6OjrrKQeEQgAAEIFBIgBH/Qib4QAACEIBAmQS+ 9a1vmSuuuKLM1CSDAAQgAIFaEkDxryVd8oYABCDQwwgceeSRrsYtLS09rOZUFwIQgEDjE0Dxb/w2 QkIIQAACEIAABCAAAQhUTADFv2KEZAABCEAAAlEEGPWPooIfBCAAgfoRQPGvH3tKhgAEIJBpAlj1 yXTzUjkIQKAJCWDVpwkbDZEhAAEINCqBGTNm5Inmr6dOnWoeffRRM3v2bHP11VfnxeECAhCAAAS6 hwCKf/dwphQIQAACPYKA37TLj/bPnDnT1VuKv9zDDz+M4u9I8A8CEIBA9xNA8e9+5pQIAQhAILME HnrooYK6+bn+U6ZMMWeddVZBOB4QgAAEINA9BFD8u4czpUAAAhDoEQS8kh9X2WLhcenwhwAEIACB ygmwuLdyhuQAAQhAAAIQgAAEIACBhifQYrdV76qFlNquvb29vRZZZy5PWKVvUljBKj2B9DHpV/Gs pk2b5gKnT5/ujrCKZxUOgVWYSPw1rOLZhENgFSYSfw2rQjatbW1thb67fDo7O01SeGxCGyDY5aat pNxmTAurpJ6UHwarfB5JV7BKopMfBqt8HsGr1tadM0L9/RxWQTrJ57BK5hMMhVWQRvI5rJL5BENh FaSx85ypPoVM8IEABCAAAQhAAAIQgEDmCKD4Z65JqRAEIAABCEAAAhCAAAQKCaD4FzLBBwIQgAAE IAABCEAAApkjgOKfuSalQhCAAAQgAAEIQAACECgkgOJfyAQfCEAAAhCAAAQgAAEIZI4Ain/mmpQK QQACEIAABCAAAQhAoJAAin8hE3wgAAEIQAACEIAABCCQOQIo/plrUioEAQhAAAIQgAAEIACBQgIo /oVM8IEABCAAAQhAAAIQgEDmCKD4Z65JqRAEIAABCEAAAhCAAAQKCaD4FzLBBwIQgAAEIAABCEAA ApkjgOKfuSalQhCAAAQgAAEIQAACECgkgOJfyAQfCEAAAhCAAAQgAAEIZI5AS0dHR1ctamXzNe3t 7bXIOnN5wip9k8IKVukJpI9Jv4pnNW3aNBc4ffp0d4RVPKtwCKzCROKvYRXPJhwCqzCR+GtYFbJp bWtrK/Td5dPZ2WmSwmMT2gDBLjdtJeU2Y1pYJfWk/DBY5fNIuoJVEp38MFjl8whetba2ukt/P4dV kE7yOayS+QRDYRWkkXwOq2Q+wVBYBWnsPGeqTyETfCAAAQhAAAIQgAAEIJA5Aij+mWtSKgQBCEAA AhCAAAQgAIFCAju/4Rb64wMBCEAAAj2QwIwZM8y1116bq/mCBQuM/k455RTnt2nTJvPpT3/aXHLJ Jbk4nEAAAhCAQHMQQPFvjnZCSghAAALdQmDq1Kk5JT9YoF4IvPvGN77hTzlCAAIVEtiyZYtZunSp WbFihdmwYYPZtm2b6eqKt7uiuPPnzy+r1PXr15tBgwZlJm1LS4vp06ePq9PIkSPN6NGj3XVZFewh iVD8e0hDU00IQAACaQlI+Q8q+sF0xx9/vFE4DgIQqIyAlPuVK1eaJ5980syePdu8+uqrTvnXV7Uk xV/h/fv3L6twvVT4BfulZtCIaXv16uVYSOmfNGmSOeaYY9yfjBHopQBXSADFv5AJPhCAAAR6NIGL L744UfHv0XCoPASqRGDVqlXmtttuM3fccYd57bXXzOrVq92I//bt2xMV/yoVn4lspNzrRWbAgAFm +PDh5pFHHjHnn3++Oe+888q2LJkJMAmVQPFPgEMQBCAAgZ5IQPP3L7300siqa8Qfly0C9957r9E+ DUOGDDHHHnusOffcc7NVwQasjZT7e+65x1x//fVO6d+8eXMDStn4IunLyNatW93fmjVrzJIlS8yy Zcuc0v/hD3+48StQBwmx6lMH6BQJAQhAoNEJjB8/vkBE+aH4F2Bpao8LLrjA/OxnPzOnnnqqGTFi hPnUpz5lUEJr36RvvfWWufHGG828efPgXUXcmgb1/PPPmxtuuMG9AFQx68xkheKfmaakIhCAAASq R+Dqq68uyAxLPgVImtpj7ty55uGHH3Yj/Joa8aUvfckceeSR5nvf+15T16sZhH/ooYfMM888YzTy j6suAa1FeOKJJ8zMmTOrm3FGckPxz0hDUg0IQAAC1SQQpeSffPLJ1SyCvOpMYPLkyW5UNDglQkrT hAkT6ixZ9ou/7777GOmvYTNv3LjR3HXXXTUsoXmzRvFv3rZDcghAAAI1JRCc7qNzrPnUFHfdM3/l lVdMZ2enOeecc+ouS9YFePbZZ7NexbrXT6P+uEICLO4tZIIPBCAAAQhYAlL0b775Zsci6gsAkLJD QCYlr7zySpT+bmrS5cuXx5ak353+opwWswY32AvHacS0kvGaa64Ji5r6+qqrroo1Xyqzw3Gmh7WO AldIAMW/kAk+EIAABCBgCcisp1f8meaT3S5x++23m8suu8z87ne/MwcffHB2K9pANdOUqjgn5T1q jY3ip1H865FW94e4ciV3pYq/7PJHOfGIU/y1MRqukECrPusluWLhpH2HAKzeYVHsDFbFCL0TDqt3 WBQ7g1UxQu+Ep2F1xBFHmLFjx7pEOvdp/PGd3NKfkbaxWGketL7mLFq0yAwePNgJRxt1TxvFlSLL NHFtIEU3ydUrrSxBxcmcJG/asLi801igikubpuwspm2Ne4sSEFU4KTwJWkdHR9lpKym3GdPCKqkn 5YfBKp9H0hWskujkh8Eqn0fwSmYeNb/fPwtgFaSTfN4MrPRF58EHHzQvv/yyq8z69evdC4BGnTWS KssoSSO5QQKVPH+bgVWwrjqvpL7hvILX2pXX/96C/jovpvjXK22/fv1iZQ7XoZzrOB4qt5iLS1ss XSXt28hpmepTrOUJhwAEINCDCegTvhR/XPYIPP3002bHjh15c8Y1BaVPnz5Gir+czH2mVfxdAv5B AAINTQDFv6GbB+EgAAEIpCOgkcBio4E+J8WTwpfGXXTRRS6aj19K2nD+4bQtLS1Gf7j6EJDN/vD8 6OBIpR/1r490lAoBCNSCAIp/LaiSJwQgAIFuILBu3XqzZk2nkc3qbdvTKfISS1vc91kWb1UkSfQN G9abzVu2JkWJDYsqt7V3bzNg4AAzdOhQM3jQoNi0BECgEQloqpTWSOAg0CwEUPybpaWQEwIQgMAu Aho537Bhg9mwcZNT/Ddv3pJ6BL8aEDfacqvlevXqZTRPd5PNs2vUSDu/fIj9ClCt3MkHArUlINOa l156qRlvp8PpBYBpUdXn/eijj5pBMYMCCxcurH6BGc8RxT/jDUz1IACB7BHYvn27Wb26w6yzCzGT zAI2Q801hch9sbBzy/VCM3DgQNO7d+9mEB0ZIZAjsGDBAmeyUmYreQnIYanKyXXXXWdaW6PVVXHH lUYgmmRpeRAbAhCAAAS6iYAUZZnsW7N2rdELQFbmyGsa0GprDW63TbuZAQP6G30JwEGgGQlEvQRo Twy9EOBKJ6ARf1z1CKD4V48lOUEAAhCoOQEp/hvsnP5SFsaWErfaFeiy8iZbHn+nxJ1122A++9nL zRtvvPFOgD3Tl424Ub+8iBEX9UqrFzSZVyzH1UvmepXbrKyKjTjHvQSU0ydIA4FqEEDxrwZF8oAA BCDQjQSkIKd1UvqlfA4fNsz06dsnbbKqxNu8abMbxdcmO5rGk8aVUrc0+REHAo1GoNjLQqPJizzZ IpBJxX/ZsmVmwfz5Zq39FL5jR7qHjZpV1ioGDizPqkQlaZcvX2Zenrdz85RSu1cl5Zaa1uoPbv7t 3nuPNUOGDilVVOJDAAJ1INDWNtTsvttuZqBdHNdLP+JudFLida9YsmSpXYS8JnXJN910U8HoftDM ZOqMdkWsV1otPBw3blyp4rr49ZK5XuU2K6vDDz/cJCnymt6jRb/aD0PmUXEQqDeBTCn+W7ZsMQ8/ 9JB5/rnnzKuvvOp21Stl9GibnS8r03LluErSbrZy9+vbt5xirQm/7pNZOsMgu6X7PuP3MZMPPth8 4IMfMEPb2sqSm0QQgEDtCfS1I/yD7W9WpjLrtWBW5a5bu86st1aIttvpOjgIZJ2AV/aZ15/1lm7O +mVG8dfCsF/eepv52U9/Yua/9vrORW+mxT7s0i8Q06fochfKVZJWLyflLmSrpNxS0+6wfLSY8Kk/ zzZjZs0yq1euNB+/5GLT3t7enL0fqSGQcQK9evU2fVr71E3pF17Ny9efvjZszzhvqtczCUjR158U fY3q6xwHgUYlkBnF/4E/PGBu+P73zZK33zaTDjzQHHvssWbkiBGmVwmKfyWLiypJ22HN8rUPK095 rqTcUtNq1tSazk7zF/tF5cknnzQ3//h/zcAhg81F9mZX7qK7Rv1hIBcEskBAL+pbt211L+z1GvHX YlH9lfL1NQvsqUPPICC7/ZrKU6rr06eP20gvKl14N+VgHA3YJbl6pZ05c6bRngaN5LQ/CK6QQCYU /+XLl5sf/+j/mbcWLzYHTD7QXPGFz5tjjzsubyTa/1jCI/p6GLVYLi29ermpQW2BqSsurCXdlvKV zItsprmN2jRIiv/3v/s985gd9f/lrbea4+xL1kGHHFLYu/CBAATqSkBfQt3uvna90yBrH7+lJf0X 0MoF73ILetesWev2G9BLCA4CWSNQjtIvBnvuuWfs2gAp70kKfBLDZkybVJ9Kwvbaa69Kkmc2basU 1iRXLLwR0s565BHz0otzjaaiXPDRjzqlXwq+ZJfyvn7dOmfzuo/93Nxmp6X4t0BtGqOFwJp3OmrU KLsIbahLowdUh7UnvaZzjRlsR7T1MtC3b/E5+M3AKtxe5ch84OTJ5rJP/rWd8vNn8+aiRea+3/3O 7DV2bDjrxOtyyvUZktaTKH6EVXFGPkazsNL9SfeutE712mzNSuqrYr++3TcCZtV+u9/AZncvlVWf NE4DNKqbFgJHfaFoljYK1hWZgzSSz3sSqxNOOCFW8U+mRGhaAsccc4yL2pP6lSpcrL6twRHuMEwl TgoPxw9eS3EuN22p5WpOv0a2NE/+lFNPzY306yHytp368+ADD5g5z89x8ij8yKOPMnYoyjxiP03N sn960BxmV+afceaZ7i389ddeM7+5806zaOEbZs+99jTvee97zaGHHZY4naVUmevFKlhuJTIfZBf3 7mnfpmU96fXX55fU1pWU2539qlqsKqlvJWlhFWzB5PNmYqVpM1vs/S6t031wk1W8Nchhv22mTVaV eCpbf2mdBmwGDBjgFiOHpw9W8luoV9pm6le+jWDlSRQ/VsJq2rRp5u677zbr7e7buOoT0A7g559/ vsu4u3TRYC0q6Ru1TpuJqT6CpJF9PSiCC02l0P/x8SfcNCBNp5GpzqVvLzGjRo9ypj5/9pOfmtl2 rrpeGrRgVWnPsj/G39xxp/nJ/91i3Nx766dRq912393ssccewXbt0ed6yRph11C89upO60k9GgaV h0CDE5DyvX17egW8wauDeBBoegLHH3+8M/H5hz/8IXauf9NXsk4V0PqJKVOmuL9Svo7WSdxuL7Y7 J3zWrHLbrdIvF/40vHHDRjNnzhz3OU0PvvXr15lnnn7arQV45eVXjEb2pfTLLbbrA555+hmjT9KP PfaYU/rlrxGbF2wey91omXxwnkAva6ZPXPXShYMABCAAAQhAIB2BYXZDvcsvv9xoHwB95cJVh4BY HmZnaHz2s581I0eOrE6mGcslEyP+cW3S2qfVNXxbe5vp7Og0egscvdsYZ9d69BhjxowZY1bYhcGa Mzvcjl6PHbu3+2ogU1wvvvCCmwKkTrSb3fxGtrBxEIAABJqBgL7IhQ0ZNIrcDBY0SksgRz0J6Dc6 1Zr+XL16tbntttvM3LlzzapVq+xGohucFSz9TnDFCeg+p9kemtozfPhwc8ABB5gLLrjAnGqndYsx rpBAphX/QXanynedeKKZ//prZt68eWaIVd5PP+MMM36ffexU1xbz/g98wPnJrOXBhx1qTrI762lr +w+d+2Gr9G8wb731llX6dzenv+8MpvkU9h18IACBBiKw8wHY2z0A+9pFvG6X3u6d0l+chtVl9IVW my16Bad4ImJAIJsENKB49tlnu7WFMpH90ksvGVkplE6S9CW9VFPcQXpaIxRePxMMTzpvxLRS7qW3 yUDLpEmTnCn3o48+2gwZMiSpKj06LNOKvzr3pAMmmYsvvdQsstZnBg4Y6K41uq/O8sFzzjYHHXSQ fQhtNuPsy4A+C+mrwNF2Jbh+kEuXLrXz2EeaiftPNAPs2yQOAhCAQKMS0FRHLWIbu/feznJZo474 y/qa5t2+8cYb1nrPWvfFtVGZIhcEak1Au2qfdNJJbqRaSr8W+2oKctKIv3QTzVgoxyl/DYqW4xox rXQ56Xqqk5T/0aNHl/1iUw6TZkyTOcVfb8Jh05v77Luvs0DTW7tY2i3svWk5zbE7/Mgj3A9MCr9M yOmBpAfmJPu5SOnkrwdqsQUiUeWm7RBKWyz/uLwqLTfMKq6csP+mjckjEuH4XEMAArUloGmJe1gj BBr9amSnLxHaU2B3O4Vy6xa7zwBWTRq5uZCtGwhIz5DxkLQGRJpp7x+Pr9aWanw5HIsTyJTir7n6 d//mrrIXykj5LneRTSVpV61aaeemjSjeWhExKim3krTr7N4ILHiOaBC8IFAnAr3tyJffo6ROIpRU rGSVgQAcBCAAAQh0H4GMKf47zM033VT2gg7NqSt3MUglaSuZN1dJuZWk1TxdLUrCQQACDULAzudv 1Ok90YQabQFCtJT4QgACEMgSgUwp/nqMDB46pMCsZ9oG0xeDsEnQ7kirhW7lTrmpl8za7Xjt2rVp 8RAPAhCAAAQgAAEIQKDOBDKl+Etp/+SnPuWsWpTDVVYmZBKqHFdJWi3o0aKUclwl5VaSdo1V+m/5 8c1m3ksvliM2aSAAAQhAAAIQgAAEuplAphT/Xr17manWdmuzbc/8ht1VeOy4cWU1fb0WzKxYscKt pyhLaBJBAAIQgAAEIAABCHQ7gUwp/qKnKTPlTpupV9o+TSizWDXXfOJu/21RIAQgAAEIQCCRgNba adrs888/b15++WWjQTVZ60sy59nR0WHa29sT840LVN7lWv5qxLTSQ2SUxdvxP/jgg505dvSTuB5g TOYU//iqEgIBCEAAAhCAAAQag4Ds9WvTrjvuuMPMmjXLvPLKK07xl8W9JMW/MaRvDClkkMVv4KVd e0+2G7Gee+65ZsKECWWv2WyMmtVOipYFCxY0/b7Q3/6Pb5nfTZ/uTMP9/qEHa0eLnHMEZInoi1/4 R/PMU0+ZI446yvzX/3wnF8YJBCBQOwIaIdxoR+20+ZXOvWtvbzP7T5zYNJvXbLR7gbz2+utu/xRf Bz3Eh1oDDQPsXgTlWljzeXGEQCMTkGKvEf4f/OAH5sEHH8z7HTSy3I0um/Znet/73mc+/elPm3F2 CjUj/4Ut1iowca6S+ePducGEtmZW4+pPn7+abY5/d7IKtnUl7avPkf5zoY5J/ShYps4rKbcZWVVS 30rSwirc8+Kvm4mVXrpXrFxppwesi69Qk4ZI2R9hd1YfMXx4wQtMJb+FeqVtpn7luwysPInix0pY LV682Ey3A5b33ntvblPR4iUSoxgBmRm/++67zb52A9Yvf/nLRsZTStFPgvlX0r6NnLZXsJKcQwAC EIAABCAAAQjUloDm9N96660o/TXAvN7uBn7LLbe4aVQ1yL7ps0Txb/ompAIQgAAEIAABCDQTAY30 azQaVxsCb775pvntb39bm8ybPFcU/yZvQMSHAAQgAAEIQKC5CDzyyCPNJXATSnv//fc3odS1Fxmr PrVnTAkQgAAEIAABCEAgR+B1u7A9zo0fP97oL8ppUfDMmTOjgpxfI6aVYDNmzHDylfNvypQpBWt+ fD7WQI3RX5R78UU2GI3iguIfRQU/CEAAAhCAAAQgUCMC69bFL86fOnWqufjiiyNLluJ/qt2oNM41 YlrJWonif9VVV5lBgwZFVllz+W+++ebIMC2wxRUSQPEvZIIPBCAAAQhAAAIQqBmBJDv9GrWXAh/l ktIpfr3SynJOnMxR9SjFTyP+cdYak14otm/fXkoxPSZurx5TUyoKAQhAAAIQgAAEIACBHkwAxb8H Nz5VhwAEIAABCEAAAhDoOQRQ/HtOW1NTCEAAAhCAAAQgAIEeTADFvwc3PlWHAAQgAAEIQAACEOg5 BFD8e05bU1MIQAACEIAABCAAgR5MAKs+PbjxqToEIAABCEAAAhBoZALXXXed6d+/f6SISXsaRCbA 06D40wkgAAEIQAACEIAABBqSgBR/XPUItBbb4KBYeJIo3ZV2y5YtTgxv37a7yg3XvaeVu23bNodA x1LrXmr8IGvSBmkkn8MqmU8wtFlYyTb1xo0bg6Jn5lz3cNVtzZo1pnfv3gX1apY2CgqOzEEayec9 jVUcjU2bNsU+U72e02hpN2/eHCtznKzd5d/T+lWx+rbGbYqgBlHipPCkRuvo6Cg7banl9u3b14nS 0tLijuXKXGq5wfpXkrY7WVVL5hUrVuS20G5tbS2prXsaq0rqW0naZuxXldS3krTNxEov2lu2bg3+ lDNzrnv4gAEDzNChQ3P3F1+5Stq3XmmbqV/Vm3NPY+V5Rx01rSVOjymm+Ncrbb9+/WJljqpjd/rF sSwmQ73uG7Uul8W9xVqecAhAAAIQgAAEIAABCGSAAIp/BhqRKkAAAhCAAAQgAAEIQKAYART/YoQI hwAEIAABCEAAAhCAQAYIYNUnA41IFSAAAQhAAAIQaB4CvXr1Mjt27IgUeMGCBWbGjBmRYcXm+Ncr 7cKFC2NljqxIN3hGGQjohmIbvggU/4ZvIgSEAAQgAAEIQCBLBNrb282qVasiqySlXwp8lCum+Ddi 2qh6dIffsGHDuqOYpisDxb/pmgyBIQABCEAAAhBoZgIHHnigeeyxxyKrIKU/TvGPTBDwbMa0AfGr ejp58uSq5peVzJjjn5WWpB4QgAAEIAABCDQFgfe+973GmyBvCoGbUMgzzzyzCaWuvcgo/rVnTAkQ gAAEIAABCEAgR+D00083++yzT+6ak+oSGDdunDnrrLOqm2lGckPxz0hDUg0IQAACEIAABJqDwL77 7msuu+wyt1ldc0jcPFIOGTLEXHrppWbixInNI3Q3Ssoc/26ETVEQgAAEIACBRiNw7733munTp5ut dkfoD33oQ4yUdkMDaYfdj33sY2bJkiXmV7/6lVm6dGk3lJr9IkaNGmXOO+88c9FFFxkxxhUSQPEv ZIIPBCAAAQhAoEcQuOCCC0xra6tT+F955RVz4YUXmptuusmcf/75PaL+9azk3nvvba644gozduxY 8/DDD5sXX3zRLF++3GzcuDHW1Gc95W3EsmUWdcCAAUYK/wEHHGCmTp1qzj33XMeUNRTRLYbiH80F XwhAAAIQgECmCcydO9cpnD/4wQ/Mhz/8YVfXBx980I1Ao/jXvullZ15Tfi6//HJz8sknG7WHV/yT zHZ2dHQYmQMtx23atKnskfBGTCvFXyP7o0ePdor/QQcdZAYNGsTC6YTOgeKfAIcgCEAAAhCAQFYJ yNzhsmXL8qqn+dFHHnlknh8XtSOgUenBgwebY4891v2lKUmbZWnxajmus7PTtLW1lZPUNGPasiqa 8UStasgkVyy8EdJu2bLFieHfkJtB5jC3ZpR527Ztrho6lip/qfGDvEgbpJF8DqtkPsHQZmG1fft2 NxUgKHtWznUP1zSHNWvWmKhdN5uljYLt0QwyP/roo+bOO+80ixcvdkqhrKGUK3e56cSMtMGek3wO q2Q+wVBYBWkY05r05idYSeH5WeVf6VNUuWlLLbdv376ucD+fq7vKDda4VJmDabuTVbDcSmResWKF mxeq/DQ/tBTmlZTbjKwqqW8laWEV7O3J583ESi/aW+wizCw63cM1X3fo0KG5+4uvZyW/hXqlbZZ+ pakRffr0cdMjduzYUfI9vRpt1CysfF11pF8FaSSfwyqZTzC01qww5xmkzTkEIAABCECghxHQgsgb brjByLrPoYceaj71qU/1MAJUFwI9hwCKf89pa2oKAQhAAAIQyBG49tprjTaSCjp9cXnrrbeCXpxD AAIZIoDin6HGpCoQgAAEIACBtARks18mJDXaL2syM2fONA899JC5+uqrXRYzZswwejnAQQAC2SGA VZ/stCU1gQAEejKBLmO8gYOejIG6pyegaT0//OEPnaJ/zTXXuLn92vjokksuyWUi+/L+RSDnyUlV CchAiTbw0tq5DRs2GK3jSfotK+78+fPLkmH9+vXO3GU5iRsxrdYFaX2K1qmMHDnSmfXUNS6eAIp/ PBtCIAABCDQNge07thvZ2W6Wh96mTRuNLBTh6ktAFnz0550WFnqnuf8a9cfVhoCU+5UrV5onn3zS zJ4927z66qtO+dfvOEnxr8Sevl4qZJCjHNeIab0dfyn9kyZNMsccc4z7k8ERb/ClnLpmOU15rZ9l ItQNAhCAQBMS2Lx5i1lhlYgWu6FNXzvipQdiIzpZjZGsK1etMt4Uc6VyLliwwCmowZHqSvMkPQRq TWCV/Q3cdttt5o477jCvvfaaWb16tRvx1wtxkuJfa7maKX8p93qR0dqU4cOHm0ceecTtOn3eeeeV ZG2wmepcqawo/pUSJD0EIACBBiAgJXr58hVuFH3gwIGmd6/eDSBVvgh2NpKTT1MGZL5RI4jlOq/s a176zTff7LJB8S+XJum6m4CU+3vuucdcf/31TunfvHlzd4uQifL0grTVmjfWn/b/WLJkiduUTiP+ fjfqTFS0ipXIhOJvX/h2OtsBcN1IwOPONUA3lk1REIBAAQEp0suWLS/wz4qHV/ZvueUWpqBkpVF7 aD1kOenGG2808+bNY8pbFfuApkE9//zzbsH6lClTqphzdrLKhOLfr19/N5dLD71qfTrOThPXriYb Nqy30wpaTL9+/WpXCDlDAAI9moBX9m+66SajHWZxEMgCAVlPeuaZZ1D6a9CY0gWfeOIJZ6Xq+OOP r0EJzZ1lJhT/cePGuTle+lQ276V5ZtSoUc3dKk0gvRYkLV78ptGuyXvvvXcTSIyIEIBAqQQ0f7a3 XSugj3uam99d844XLlxoZs2aZUod2T/llFMiqyhFoB4LGlmEGdkckZ49jZXmpDO9J7IrVMVz48aN 5q677jIo/oU4M6H4H3f8caZ9+DCjeaM/++lPzX77TTC77b57YW3xqQqBtWvXmtt/+Suzws4nHj1m tDnppJOqki+ZQAACjUGgf//+pm3oUDNkyJCclaAtW7eYzs41Zu3aNW5xbq0llfKPg0BWCTz77LNZ rVrD1Euj/rhCAplQ/Cfst585225E8v9u/KF56MEHzLD2NnOs/bwzcuQo07t3essW9bJRK5u8by1e XNg6KXy6U2aN+MnU23NPP2tuv+2XbrT/pJNPNsced2wKSYkCAQg0A4FBdmGwrGMMGzbMWsrob++h OxcJb7OLEQfaUcp+9iufrJFstHNpa+X0FVe24/WnqT4a+X/ggQeKTvWRzfkop/uWFvuV4ypJq5cX 1aUcV0m5zZi2p7FKMrsrM6r6i3L66pa0qVojplU9tE9Eue6qq64yGoyIcjOsuVn9RTl2oI6iYkwm FH99wv34xz9hVthFbfdOn+5Gox9/7HG3mYN/aEVXP9+Xz8H5PMJXO6yd8A77AF34+gLTq7W3mWo/ q19y6aWmrb09HJVrCECgCQnofjnMfj0dNWpkwYO21YbpC4Di7OiyJjmXLnPTf2pdzfHjx7sXgCuu uMKZO/TTf+Ie9rWWh/whUA0C0jfinJT3uE3T0ij+9Uh7sh0EjCtX9axU8Y97cRePuHsBaz6je1ir RgaSXLHwRkk7aPAg84mLLzLtVgl98k9/MoveeMOssvPQm8HpIdqrJf2XiXrWSbbB950wwRx17NHm fWeeafYeO9Z9BShVpmbpV8F6IXOQRvI5rJL5BENLZSUzgJq/WgunEf62oW0FSn+wLM1Nbrej56tX d7gNw4JhlZ7rIa66ySxf1KCNvkLoBUB/b9h7/M9//vPcUWUnsUwKKyY3aYsReiccVu+wKPdM6x3i OOo3kuTqlVbrFeJkTpI3bVhc3mnWScSlTVN2FtO2xr1FCYgqnBSeBE02mstNW265h9jtx9vbh5kT rQmn+fNfd/LvsA/JtE4dqFwLNZWkLbe+qlcl5ZaetsUMsfN+97KLeSfYdRQTJ05MizYvXiX1rUe/ kvCVyFyvtLDK63aJF83ESiOFW6zN6lq4wYMG5+b0x+WvBb9a1D940KCqK/7KWy8WQ+19JrwYN/w7 OuSQQ8w3vvENJ+bXvvY1Nx0o7pkTThtXtyj/StI2U7/yda+kvpWk7WmsPO+oo1tjEzM1rZjiX6+0 0p3ifn9RdSzVLy7vNDpbXNpiMlTSnxs5bSam+gQbb2jbUHPyKVPNiSdNcTvgaV56WqdRJj1wynGV pF20aFHZlnEqKbfUtC2mxQwcNNApBurUOAhAIFsEetspfL2sid5izln7sXEbxfnpQI0iD3JAAAIQ aFQCmVP8PWiNFpWqxOthVu6bYSVppURrilI5rpJyK0lbjqykgQAEGpvAtq3bUs3b37FDu2XGz1Fu 7FoiHQQgAIGeS6A5Jpb33Pah5hCAAAS6jcC6devcJohJ0wkUtmXLZvdFtdsEoyAIQAACEKgKgcyO +FeFDplAAAIQaEACWmRfC+cXBva183VlujPKbdiwwXR0dNZs8yHVTV8jcRCAAAREQDt2D7JriqIc +31EUUn2Q/FP5kMoBCAAgYYiIMW4v1XMdZSFn2q67XZN1CprrafF5j3cWtDRwjm/yHarXVC8adNm Z8N/tTXekPRVoFyZfN1Q/MslSDoIZI/Addddl7sPhWu3wO7zgSuNAIp/abyIDQEIQKCuBKQcD7Sb bEn5l/GCaiv/Mqe5zO6JoqPMdvbrt3PjnE2bNhop/GvXrjNJNsjLhaPNFvWVQVZ9VEccBCAAARHQ iD+uegRQ/KvHkpwgAAEIdAsB2bgfMWKEMXavkvV26o1eALTgtjSn+NZWV8SsGpn61d+KFbXaC8UX 2uWUfI3w62Vmr732jLTfX1q9iA0BCEAAAnEEUPzjyOAPAQhAoEEJ7FSU7UZa7fuaFVb5X7z4LTvv fnVJ0naZLqn9dlrPTiXcT93RWLum+sg5P70Z2HcEjcKrXL1k9LJHecu19OptunQe2FhIJkFbTC/n 1dKy84VkVzY2rY1vveTby4a1t7eZ0aNGm2HD2t1oP9N8RBUHAQhAoDYEUPxrw5VcIQABCNSUgBRk bdaz25gx5q233jZzX5prNm3cnLrMneq4lO8Wp4TvTOh9pbjvVM59hk7Pd9q7jbNL6VeYYvpUkXHz PHem8F7aKfikKSea0aNHuTm8KP2eDEcIQAACtSGA4l8bruQKAQhAoOYENAqvXXT1AqAR9jVr19a8 zGoW0L/fGNPPyt+nT59qZkteEIAABCAQQ4AVVDFg8IYABCDQLARk6m6YtcLTbE4yx5npa7a6IC8E IACBZiDAiH8ztBIyQgACEEggMMzu/H3AAZOsBZ6+CbHeCZJpznJH2WXHXwtxy3Hhcifsu6+R7DgI 9DQC+v3p9xDlZsyYEeXt/PxanLgI9Uo7c+ZMc+2118aJVRd/mSPGFRJA8S9kgg8EIACBpiIwcuQI c+KI4827jj8uldxr1qwxQ4cOTRU3HOmNN94wY8eODXunug6Xqzn9zOtPhY5IGSOw5557mjgb9FLe kxT4JBTNmDapPpWE7bXXXpUkz2zalo6OjvC6rKpU1uZrrTUwkpMGJqzSUNoZB1awSk8gfUz6FazS E0gfk34FqzgCl19+ufnFL34RF4x/FQhceOGFRpt/oYvmw2xtsxu0xLnOzk6TFB6XTv664ZWbtpJy mzEtrJJ6Un4YrPJ5JF3BKolOfhis8nkkXcEqiU5+GKzyeSRd9TRW06ZNM3fffbdZv359EhbCyiSg 6Yjnn3++S40umg+Rxb35PLiCAAQgAAEIQAACNSVw/PHHm5NPPrnstTY1Fa7JM9f6iSlTpri/Jq9K TcRH8a8JVjKFAAQgAAEIQAAC0QRk0UrTfQ4//HC3cV10LHxLJTBgwABz2GGHmc9+9rNm5MiRpSbv EfFZ3NsjmplKQgACEIAABCDQKAS0B8fUqVPN6tWrzW233Wbmzp1rVq1aZWQ1a9u2bTt3zW4UYRtY DhkHaG1tdZbGhg8fbq2bHWAuuOACc+qpp7rdxhtY9LqJhuJfN/QUDAEIQAACEIBATyUwePBgc/bZ ZxtZ+HnyySfNSy+9ZJYvX242bdpkduzYEYtF4dq0rxynlwopymmdZFqyZEle9N12280p2HmeRS5K LTeYXVJavUCJxahRo8ykSZPMsccea44++mgzZMiQYBacBwikb/1AIk4hAAEIQAACEIAABCojILO6 J510klOkpfRrsa/s+yfZ61+6dKkZM2ZMWQUr/1I2zbvvvvvMN7/5zbyyrrzySjdFKc+zyEWp5Qaz S0orxV8vMqqTlP/Ro0eX9GITLKennKP495SWpp4QgAAEIAABCDQcAS1G3WOPPdxfGuEWLlxoxo0b lyZqQZxSLR9qOpKmIvk9B8aPH2+uuOKKgnyLeZRabjC/StIG8+F8JwEW99IT/n97ZwKt1fT+8R2t ZRm7yJBi/f0QkSmRMqyFUIaQEiFRpiJj5jEyhcxFGUslIbMylzlDFFYyrGUoylBYpsW6//PZel77 fc95zz33vt3p7fus9d5zzp7O3p9z7j7P3vvZe4uACIiACIiACIiACCQSQPk3QfGXNG4CUvwb9/NT 7kVABERABERABESg1giw7KjJxRdfbKc6NlICUvwb6YNTtkVABERABERABESgtgn07dvX32KDDTZw Ye9/bd9X6dcOASn+tcNVqYqACIiACIiACIhAWRBA+UfxlzR+Aprc2/ifoUogAiIgAiIgAiIgArVG AHOfHj161Fr6SrjuCEjxrzvWupMIiIAIiIAIiIAINDoC9Pizuo6k8ROQqU/jf4YqgQiIgAiIgAiI gAiIgAhUSaBJtDZrZZWhaiHA77//7u644w6/SUXSmrA33nijv+txxx3nVlxxxcw5YKmpCRMmuB13 3NG99NJL7sILL3Rrrrmmu+CCC/wwla1FmznBIgHHjh3rd9m7/PLLYyEs73jYJhzrr7++22OPPVxF RUUsfJLD//73Pzd+/HjXoUOHJG/v9sYbb7jevXu7zz//vGiYmnjcdtttfjOMlVZayR/ZAQ+erDUs EQERWLoEbrjhBv//xf9YKLgjSfVjGI7zDTfc0Nd7SfUF6VBXUC8uDaHu+/jjj93QoUOLJjd37lz3 ySef+B0/27Zt6zbZZBO3xhpr+PBhfsLzoonJQwREQAREYKkRaJq2CUQpmyZk2WDir7/+cpMmTXLD hw/PKxD3HTdunFfUN9tsszy/qi4ef/xxxzbYlOuLL75wO+20k0/r5JNPdi+88ELqphfVKS8ftj33 3DOXXhj3vffec+HyV+SZco4ePdrdeeedrmPHjnnFSGLFdt3szJf2fCjf5MmTU8Pk3ajgIsxz6DVs 2DDHkl3slsdvwYIFrk+fPq5fv35u1KhRPmixuGE64fmxxx7rjjjiCM+lunHDdJJYhf5p56XctzHG Fau0tyHfrz5ZzZw50x1wwAGx/+NmzZq5l19+OeZuOQ/fSToYitUXpMOW9mFdEsa19LIeqd+6deuW l14Yt1evXl7p33LLLX2e2Pzn4YcfdhMnTnR77bWXC/NDOmlphemm5ZkOnaOPPtq9+OKLYZTceVrc XKAiJ6XErc/3Cs41kVLKW0pcscr+tMRKrIoRyPI/WK82/sccc4y79dZb3axZsxwfCZOPPvrIsSU1 /sjzzz/ve7VRhjfaaCPXuXNn785HEUHJHjJkiLvooosc2zc3adLEfzDxYwRg2rRp7pBDDsn1vuOO PPHEE+6dd97xvWVbb721D4u7pfvDDz+42bNn+3RxN/n55599D9p5551nTrEjS16Fy16Rt3333dfR MDHF/7fffnNPPvmke/31132P33777efoZTehHIxaIGFa8+bN8x9W/CkvEoYj/3PmzHGMloTy2GOP OT7a++yzj9t+++3dK6+84vMUhuEcJYL7hY2Xbbfd1isnNAps1IKP7IwZM9zmm2/utttuO9eiRQuf lOWFC/LSs2dPX8bDDz/c55PGBCxCsThhOUN/nYvAsk6AUVLqiw8//NBtscUWbpdddvFKdBIXOgQ+ /fRTt/HGG8e8qXceffRR3zHSpk0bt//++/tRVf7vqSsR/m+5Llyzm7qPOuSKK66IpYsDSj/p08my +uqr58Lccsstvh7goxSK1V/mRtynnnrKffbZZ75eplFAowV59dVX/Qgk9Q/lO+2009xqq62Wyyth rO4O6y7cJSIgAiIgAv8S+FdrrCca7dq18+Yvd911V14OxowZ493xv/TSS72i/8033/hhY3rZcUP4 MF1yySXelIcPIoJCibv1/Hz99df+HLdQqcRE5uyzz86F3W233dyUKVN8Gnzsvv32W3fGGWfk0vEe S/6gqGO607p169A59ZwPHB9heumRhQsX+g/3gw8+6PNw0003+WvcQ3n77bdjQ/30umNORJn4aJvs vvvujp71kSNH+t/yyy/vzLTp/vvvdwceeKBXBq677jrvH8a1NIodaSgglh69a9dcc42j54FGTatW rdwHH3zgw/DxRZE/8sgj/ZHnhbKCW8uWLX3P3PTp031Y+0Pemzat13aoZUVHEWgQBGjYm8yfP9/t vPPOOfNIzCT33ntv9/3331uQ3JG64fzzz3fUfe+//37OnRNG70jnkUce8fUHYbm2dKgjFy1a5O69 9968eHZB3bfeeusVrfvopKHDIVT6iXvSSSdZEnlH6gTqcIS80ZhhZIBGDnljxNbyRt2OiRF1HB02 9GhTr1EPkg5uU6dO9dc+Qf0RAREQARGIEah3TYtefX6huQ/mMHfffbfPLIoxHwJ6jRF6lVGSw54o FF3z94GiP3xM+PHx5Gg9QfjTS/3000/7Hm96zhDMULCpZ2QAoUcJ2/nw4+s9oj/YyybZ0pp/0pHG DSMMI0aM8N6UC5tXyobyTEOCUQ/cBwwYkEsC5Xnw4MF+PoGZPd1+++3O7H/56JlwTs888TlnngDl /r9o1IO5DvTSnXPOOT445Q3jWhp2DP1+/PFHr3DQcNlmm238B5pGD8zp6ScsygAjCFtttZVPAlOo Z555xvdMMlJDOWlcYetLryA9gHzkEcygaFiggEhEYFkkwP9pWEcVMkDRRzFGuTWhEc3/VVhf4EfH AOFRmhEa/CbUL82bN3f33HOPV5ypR7HBx/2EE07wwa699lrf425xwiN1H3VAkqCUM0q6ww47JHkn uoX1DPUA87EoE0LeyCt5O/HEE70bDY+33nrLn7PKyHPPPZf7VlAvps078JH0RwREQASWcQL1rvjT 807vMSYw9EBzRHBnqJoPCaY/1suP31dffeV7szjnQ2C9+1xnEXrBUDL50PBDUGrprTJByU5S+vF/ 88033cCBAy1o4pGJvKFgnnT99de7Ll26eGd6qMgD5TKbLBRpPu4mfBSx20X5ZxSEj9q7777rVlhh Bd9AIY1CsQYQeUfhtxEGjphJmWBuRG9ZMaGxQc8feeNHjz7KOrL22mu7QYMGeUX/tdde80P73Csc rcAcyRpVhRxR/FH6acBRPnoXed4SEVhWCYQKcBIDTPfMRND8UbBRxEPFnwY3o2tM9jWhgWAmNjQu qHeuvvpqX48QhjoD00qTyy67zE5jR+o+q2MKPemlRxhprImEdaLFp14O6xVMf0yoc8LGEnO7JCIg AiIgAukE6l3xJ3vYajIBDMWflSfsQ4bST29x4UeR8Cj/yJ9//umPxf6gJCNhGqTLdehGmCw9zijQ fIQLV+Agfig0Isy0CAWXEQ2bm0C4X3/91ZcNpTgpL2Fa9M7zsaXX/r777suNSoRh7Hyttday09gR e1gTRhjSBFt+E3brQ3kwltjv8gwOO+wwb3/Lx9n8LE6hsm/uHBnZwAaXnj3KRsONUR6JCCyrBKgr rL4wBmFnB41w7PFD4X+ycEWvn376yQexFXS4CP/vf/nlF/fPP//E6pzw/zU8D+9ndR+jiklidQr1 Iz311RXLW3j/rl275tXTjAgUk5VXXrmYl9xFQAREQASWEGgQiv/xxx/vzVJQjlnNx+xSMQuhB5ye 46RepqQe78InaxPDQnfMVOjVwkSInmwT6xWz66QjIwwo/WkfoMJ49I5jWsQ9sYtHKBMT6VB6q5qh z0oYfEhRlOGDHWtNhPuYYJZTlRQqIhaeXjZW+WEOhMnNN9+c94EubFRZODti3kUc5j7wbBlFkIiA CCQToL5gcmsomCzuuuuuoVNulI0GAZPukS+//DIXhnSYX4ONf+GqL1X9z1rdV2i/b4nT6dC/f3/f OWFmRuaH2R8dF2kLImByZHWixavOUYp/dWgprAiIwLJKoF4n9xp0hqU7derkbTk52rJz9FqhFGLm wpA2iiu9YPQCsTJMFknaAwBFmo8UvcwMI9PQ4KOTZvpi96qJfT9x6fWnF/3ZZ5/1STFRjYYL9qsI H3XyYHMbvGPwB0WZsAzvF7OxDYLHTo866ihvysQEXBoO1riKBczgQEMGpZ1hf8wKMN2BMxMQmQ9Q KPTgoSwQ1spPw4E8UCabV1EYT9ciIAL/EqC+QPG2+gITRWzdWQksFJRfFH7CMSmWBv7ff/+dC2L1 Dqv6INQ7NL4t3VzAhJMsdR/ziJhfgPkmc5ow+aPOps6gnmASfzGxvJn5JXljtNFs+ovFw529RuCD hOY/3kF/REAEREAEcgQahOJPbjAd4ePDMRQmwzKh99BDD3Xt27f3HyrbYIpwhcu2FfY0WY8/vVkW lo8jHyeUUCbAsoY2DQyWm6xK+LhUd2IvaTJ6wSoVfBgxX6I3HeUZW1tsVRn16NGjh/9gEh7/sAcO xZ8PKWFCCc2TiFNMmMxHeqeccoo3q2Jfg2KSlg5xGO1g5AJmzAUgT+SPDXto4CQJ92P+BnMCTIjz xx9/+IacuekoAiIQJ8D/JP9bV111lZ97xOR+JrNanWZHYjIplh59lih+6KGH8v6/mGBPPcR8Ixrk rMCDeSX/ywjphPWOd1zyJ0vdR4cKIwx02jDCyVwp6llGB88888wwudi5lfHKK6/M5Y263iYLF9bt YQIsMnDwwQf71eBCd52LgAiIgAgUEIgq+aIS2ZUW9avKI1r2saogRf1LuW9txo0U9kp+SVLKfbOw ilYFqoxGRiqjkY6822e9bzS6UMnPJBpZqIwaDXZZ7WPW+yYlbHGjBk9ltIJIUpCibllYFYts9y3m n+beGOOKVdoTzfdrTKysDir1nbR08kkkX4V1X12wSspbqeVNLlnVrqXcty5YJZWglDzXV1yxSnqS yW5ilcwlyVWs4lSWK2gH6DKFAD1k4cSzlKBLzYtJzPSWs1Y+owPhBl/VuQlzCehRw9yIoXB64Fgt qD6EXsju3bv7JTzDeQL1kRfdUwQaG4GlVQdVJ526rvuqk7fG9vyUXxEQARGoTwINYnJvfQJo6Pdm B0tMa0aPHu037Klpfk8//XS/HCD2stj9sjum7QtQ0zRrGo9lWrHn7devX02TUDwREAEREAEREAER EIFqEpDiX01gdR2cXnp+pQpL+rHTJz+TLKsYWdileWTH5MIVRZZm+kpLBERABERABERABEQgTkCm PnEmchEBERABERABERABERCBsiPQhIk8tVGqKF1XUVFRG0mXXZpilf2RipVYZSeQPaTeK7HKTiB7 SL1X9cuKeXEIo8wNWVhanOWuWW0rSVgpa/z48W6fffbxG2DW9L3CxHaXXXZx55xzTtJtquXG6lss uctqg0tLaiNNY8UGgSxJzIpnLAe/zjrruK222spvIrq08t9o0onP9/3PJQL230U1zzSTOjswsRKr YgT0P1iMTNxdrOJMirmIVTEycXexijMp5tLQWEVmspXR8rbFsuvdS8nz0oob7bNTee+99xbNJ/7R /kaVHJGsOsN7771XGS3R6+Pwh/NIUc9dV/ckLG+0k3cl6WeVMK7FYfUunlG0+Ih3KpZmUlxLo6qj sYoaO3RyV0ZLp/v7RUvHV0bLrOeYJqVTyn0bclzZ+DeaJpoyKgIiIAIiIAIiUFMCbAL6zjvvOHa2 3nHHHV24Dw69wZHi6fejYd+gTTfd1N/GNoSLlObE699//909+eSTvse+TZs2bv/99/cbWhLY4s6a NctvbsnqfIXy888/+57oYrtaRwqkY8M9eqrZh4M9PEzwYyNMyxvukaLrvbG4IB5z+chHGIbNQ3Fj M1D2MQoFd/zxI45ZbsycOdPvzzF58mS/ySr7D5ngVzhnkHl8ttkoeXrggQf8vj3cz9y5Fz/KEKZn 6VI+/NkslPmJYRlwZ68S7s05fsXmQ0ZKvYsaVn4fpXPPPdcnT1ie1XXXXedHLWwzREYweEfYWHaj jTZytn8I9zCBD/FZIIWRAxMLQ15+++03v4cJIzm8F926dXO2r5SFY0NVNj1l75W6FNn41yVt3UsE REAEREAERKDOCaB4olzed999jmWy2V167NixPh9sHIpiNmXKFMeqcyhqKGwICh6Kownnl1xyib9k d2waDxMnTvRh2ByP64ULF3p/wv3www9+07wwDUuLIxvjrb/++q5169ahc+7cFG3ygULJZpyh4B4K DQPCoDSzjPdPP/3kjxZm3Lhx3p/8sKGnlQX/bbfd1g0fPtyXJdohLNc6AAAL4ElEQVTrxzc0SAc5 9dRTvYkQ/ijy3MM2XEX55l72O/DAA/2O3cSjwYKiT6OLe4aNFxRo3KKRg1ia5Jv8kI9oZMArx7bz N3Eo90EHHeTgwzXn5ClJWB54r732cpT9o48+ygUhLyj6pvT37t3bm4WRHmWhYfD000/78FyTXzZ6 feGFF7xZ1qhRo3JpEQdGb7/9tvvuu+9cly5dYu8F7wvhOnfu7N+LYhue5hKtpRP1+NcSWCUrAiIg AiIgAiLQMAjQu0rPqim6KGa//vqr++abb3yP8q233prbwZqe3q+//tptscUWqZlH6WSXahR/hPTb tm3rHnzwQTdgwADvRo8yu9oX25uCkYYOHTr4sEl/aEygUCJ9+/b1CjVKLmJKub9Y8sd66GnkoByj rFqZCYLiaQoyYUgffxoMKNso4SYo7JSR+yLMNUDJR8I0zR930iZdFHaEcuOGks0oAH70vlMmeA0Z MsSnb3n1kaI/5Iuw3J/RBFYmhDVpRSZPPhj5oyGCwIJ0w7x4jyV/uBfKf6dOnfxoT8eOHX1jATt/ hKXOn3nmGTd9+vTcc+/Tp49/ll27dvVheI5Tp051m2++uW9AkuYFF1zg/RgtYuSCncppZLIMu70X jPTYe3HCCSf4ESHmc8ydO9fHres/UvzrmrjuJwIiIAIiIAIiUKcEhg4d6pVQFFHMeFD8Irt5r1Re dtllbs899/S9zvidddZZmTbLZE8cevgvvfTSXFl69uzpTU9M8UfZLKb0EwkzloEDB+bihyco2SiU 9KAjKLUozDQWyDs979UVJveaoFibIk9adh/z59r8cQvjWpjwSKOBUQB6x60BQhqYtjDReoUVVnDc pyqhcUKDhcZCKJj2MHKAwDQ0U7L7heHDc0x3UNzpwX/uuee8kk/jhZGfu+66y9EwxKxn0qRJ/kfc li1b+lECS2f+/Ple6eea58zz4PmQ9oQJE/x18+bNfd4xJQvfi0MOOcQtWLDAJ7Xyyiv7983Srevj cnV9Q91PBERABERABERABOqawOzZs/0t6SWmN58eYmSPPfbw5huYALGbPH6mYPoARf4wYoAZCoqq /QiKqVAWQWmcM2eO74FOCk8vPL3dq6++eq7RwjUjCjWVDTbYIDEqCnmS8hwq6uGciMJEKAsc6ek3 G37C0FBBQabHHlMlGiz1JTQWWBmJ3nZMrMwsimeNSZY9QzuSz2OOOSaX3bABt+KKK7r+/fv73n3C jxgxwjFCgBR7Lywh4sKjvkQ9/vVFXvcVAREQAREQARGoMwIo9Pww0aCXnR5f6+XG1IQfShxmGfiZ uQoTNU1ee+01O/UK/rRp03wPd86xGicon/QMYxZSKGa6Qu85+TKhBx7bd/zpsS8UesrD8IX+SZNw CYOyHvbu48Z1qMQXxiUMgolQ9+7dHSYtxhN3WGLH/vDDD+dMfTDdqUpQsGmEFJoycf+abP6JORFc aDCFrGkE0PjDzj9a4cddfvnlbuTIka5Vq1Y+i1Xdj0ngzJPA9Ic8G3feMZ6tTeINywuTlVZaya26 6qqhc52eL1end9PNREAEREAEREAERKCOCaDo9+rVy/fk08NLr+v222/vc3H66ae7+++/3/euY/KB X/v27b0f9uSY4zBhF/vyGTNm5HLOSjMolDbJk3XtaTRYgyEXsMhJmn0/96J33JRJSwJFnBEF/FH8 UYTpuUZQqsMeetxQXlGgTYlmhaFQTLGnV55VgCgPwpFr3E0K45o7/EjH5iKYO0fyZ3kiTRoTKMSW H8KE51wjKNQo5cRBKC/phPnxHhn+9OvXz5vZcKQRglA28vvHH384zHAwycJMh4YK7wf5xAxo8ODB Re+AKRKjSNj0h+ZaNCgwA7ORGc7D92KVVVaR4l+UqjxEQAREQAREQAREoEQCTN5dd911vV14u3bt /KReW5WGjaOYtIny2qNHD4e/KXIof/Ror7322u7dd9/1CqllBdOXMWPGeKWUHt/jjjvOxydOFqFX uNjEXhRPRh2SBAUWfwSlnx895CjJxKFBgKAk08PMNUoz5QtNfYhjYTkyukB8ysKRa/MvjIs7bqSP mQ8/Gin2QykmHRRtlHbuiyJPo4gVlJigjP+gQYO8gk0YS5O8Ex+THPJBXFZjCucOYDYUmiaFcYkf Crb6TLSlwcT9WrRo4Zf2pOFHumuttZZDGcdO/+OPP/blYuSCsg0bNixMKu+c/GPuM2/evNxkbgKw +hDv1FVXXeXLGO0d4OcE8F4Qh4ZlTUYu8m5ewkWTqGD/rVNVkFBVwxwFwfMuaTHV1JarlPs2xrhi lffqpF6IVSqePE+xysOReiFWqXjyPMUqD0fqhVil4snzbOisUJVQ2kIJ9Y0k/zBs4Tm93Ch/hWkW hku6buiskvIcskryT3MrJW59s6ruewGHUsqbJa5MfdLeNvmJgAiIgAiIgAgs8wSqUtCr8i8ESPjq xilMQ9cNn0BDfMZS/Bv+e6McioAIiIAIiIAIiIAIiEDJBKT4l4xQCYiACIiACIiACIiACIhAwycg xb/hPyPlUAREQAREQAREQAREQARKJtAkmmBSdHJvKakzcSWccV1KWuUeV6yyP2GxEqvsBLKH1Hsl VtkJZA+p90qsshPIHlLvlVhlJxAP2TRtSaEss4PjSf7rwouZlnaxeLiXct/GGFes0t6GfD+xyueR diVWaXTy/cQqn0falVil0cn3E6t8HmlXYpVGJ99PrPJ5pF2JVZyOTH3iTOQiAiIgAiIgAiIgAiIg AmVHQIp/2T1SFUgEREAEREAEREAEREAE4gSk+MeZyEUEREAEREAEREAEREAEyo6AFP+ye6QqkAiI gAiIgAiIgAiIgAjECUjxjzORiwiIgAiIgAiIgAiIgAiUHQEp/mX3SFUgERABERABERABERABEYgT kOIfZyIXERABERABERABERABESg7AlL8y+6RqkAiIAIiIAIiIAIiIAIiECcgxT/ORC4iIAIiIAIi IAIiIAIiUHYEpPiX3SNVgURABERABERABERABEQgTkCKf5yJXERABERABERABERABESg7AhI8S+7 R6oCiYAIiIAIiIAIiIAIiECcgBT/OBO5iIAIiIAIiIAIiIAIiEDZEWiyaNGiytooVZSuq6ioqI2k yy5Nscr+SMVKrLITyB5S75VYZSeQPaTeK7HKTiB7SL1XYpWdQDxk02bNmsVdl7gsXrzYpfkXjRh5 8GLWNG4p922MccUq7U3K9xOrfB5pV2KVRiffT6zyeaRdiVUanXw/scrnkXYlVml08v3EKp9H2pVY xenI1CfORC4iIAIiIAIiIAIiIAIiUHYEpPiX3SNVgURABERABERABERABEQgTkCKf5yJXERABERA BERABERABESg7AhI8S+7R6oCiYAIiIAIiIAIiIAIiECcgBT/OBO5iIAIiIAIiIAIiIAIiEDZEZDi X3aPVAUSAREQAREQAREQAREQgTgBKf5xJnIRAREQAREQAREQAREQgbIjIMW/7B6pCiQCIiACIiAC IiACIiACcQJS/ONM5CICIiACIiACIiACIiACZUdAin/ZPVIVSAREQAREQAREQAREQATiBKT4x5nI RQREQAREQAREQAREQATKjoAU/7J7pCqQCIiACIiACIiACIiACMQJSPGPM5GLCIiACIiACIiACIiA CJQdgSaLFi2qrI1SRem6ioqK2ki67NIUq+yPVKzEKjuB7CH1XolVdgLZQ+q9EqvsBLKH1HslVtkJ xEM2bdasWdx1icvixYtdmn/RiJEHL2ZN45Zy38YYV6zS3qR8P7HK55F2JVZpdPL9xCqfR9qVWKXR yfcTq3weaVdilUYn30+s8nmkXYlVnI5MfeJM5CICIiACIiACIiACIiACZUdAin/ZPVIVSAREQARE QAREQAREQATiBKT4x5nIRQREQAREQAREQAREQATKjoAU/7J7pCqQCIiACIiACIiACIiACMQJSPGP M5GLCIiACIiACIiACIiACJQdASn+ZfdIVSAREAEREAEREAEREAERiBOQ4h9nIhcREAEREAEREAER EAERKDsC/w9HOugTkx3aXQAAAABJRU5ErkJggg== --000000000000c4567905a14e916b Content-Type: image/png; name="Screen Shot 2020-03-12 at 10.05.20 AM.png" Content-Disposition: inline; filename="Screen Shot 2020-03-12 at 10.05.20 AM.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_k7ntxqms1 iVBORw0KGgoAAAANSUhEUgAAAwMAAAGvCAYAAAAHYwmfAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV lgdUk1kWx9/3fekktECkE3qT3gJICT0UQTqISkgCCSWGhCBiR8QRsKEiAuqIDUTBsQAyqIgotkGx gH1AREUdBws2VPYDljCze3b37D3n5f3OzX333fvOd8/5A0D+xhaJMmBFADKF2eKIAG96XHwCHf8U QAABROAIDNgciYgZHh4CUJva/24fe9Bo1G5Zjuf69///qylxeRIOAFA4yslcCScT5RPoesIRibMB QMpRv8GibNE4t6KsIkYLRPnGOKdO8tNxTp7kzxMxURE+AGDIABDIbLY4FQCyGuqn53BS0TxkBso2 Qq5AiDIfZQ8On81FuQblmZmZC8f5NsqmyX/Jk/q3nMmynGx2qowne5kwgq9AIspgL/4/n+N/W2aG dOoOYzDegDgwAt1J6JvdTV8YLGNh8uywKRZwJ+InmC8NjJ5ijsQnYYq5bN9g2dmM2SFTnCLwZ8ny ZLOippgn8YucYvHCCNldKWIf5hSzxdP3StOjZX4+jyXLn8ePip3iHEHM7CmWpEcGT8f4yPxiaYSs fp4wwHv6Xn9Z75mSv/QrYMnOZvOjAmW9s6fr5wmZ0zklcbLauDxfv+mYaFm8KNtbdpcoI1wWz8sI kPklOZGys9noBzl9Nlz2hmnsoPApBnbAAZ03G4C+RjYvN3u8AZ+FosViQSo/m85EJ4tHZwk5VjPp djZ2NgCMz+nkZ/CeNjF/EO3KtC83GQD3dADgwGlfXBwADaYAqMdN+4w1AaCiM9e0niMV50z6MOM/ WLQqBaAC1IEOMACmwBKtzwm4AS/gB4JAGIgC8WA+4AA+yARisAgsBatAISgGm8A2UAF2g72gBhwB x0ATaAXnwEVwFdwAd8AD0AcGwSswDD6CUQiC8BAFokLqkC5kBFlAdhAD8oD8oBAoAoqHkqBUSAhJ oaXQaqgYKoUqoD1QLfQLdAo6B12GuqF7UD80BL2DvsIITIZVYG3YGLaGGTATDoaj4HlwKpwF58EF 8Aa4HK6GD8ON8Dn4KnwH7oNfwSMIQOQQGqKHWCIMxAcJQxKQFESMLEeKkDKkGqlHWpBO5BbSh7xG vmBwGCqGjrHEuGECMdEYDiYLsxxTgqnA1GAaMR2YW5h+zDDmB5aC1cJaYF2xLGwcNhW7CFuILcMe wJ7EXsDewQ5iP+JwOBrOBOeMC8TF49JwS3AluJ24Blwbrhs3gBvB4/HqeAu8Oz4Mz8Zn4wvxO/CH 8WfxN/GD+M8EOYIuwY7gT0ggCAn5hDLCIcIZwk3Cc8IoUZFoRHQlhhG5xMXEjcR9xBbideIgcZSk RDIhuZOiSGmkVaRyUj3pAukh6b2cnJy+nIvcHDmB3Eq5crmjcpfk+uW+kJXJ5mQfciJZSt5APkhu I98jv6dQKMYUL0oCJZuygVJLOU95TPksT5W3kmfJc+VXyFfKN8rflH+jQFQwUmAqzFfIUyhTOK5w XeG1IlHRWNFHka24XLFS8ZRir+KIElXJVilMKVOpROmQ0mWlF8p4ZWNlP2WucoHyXuXzygNUhGpA 9aFyqKup+6gXqIMqOBUTFZZKmkqxyhGVLpVhVWVVB9UY1VzVStXTqn00hGZMY9EyaBtpx2g9tK8z tGcwZ/BmrJtRP+PmjE9qmmpeajy1IrUGtTtqX9Xp6n7q6eqb1ZvUH2lgNMw15mgs0tilcUHjtaaK ppsmR7NI85jmfS1Yy1wrQmuJ1l6ta1oj2jraAdoi7R3a57Vf69B0vHTSdLbqnNEZ0qXqeugKdLfq ntV9SVelM+kZ9HJ6B31YT0svUE+qt0evS29U30Q/Wj9fv0H/kQHJgGGQYrDVoN1g2FDXMNRwqWGd 4X0johHDiG+03ajT6JOxiXGs8VrjJuMXJmomLJM8kzqTh6YUU0/TLNNq09tmODOGWbrZTrMb5rC5 oznfvNL8ugVs4WQhsNhp0T0TO9NlpnBm9cxeS7Il0zLHss6y34pmFWKVb9Vk9cba0DrBerN1p/UP G0ebDJt9Ng9slW2DbPNtW2zf2Znbcewq7W7bU+z97VfYN9u/dbBw4DnscrjrSHUMdVzr2O743cnZ SexU7zTkbOic5Fzl3MtQYYQzShiXXLAu3i4rXFpdvrg6uWa7HnP9083SLd3tkNuLWSazeLP2zRpw 13dnu+9x7/OgeyR5/OzR56nnyfas9nziZeDF9Trg9ZxpxkxjHma+8bbxFnuf9P7k4+qzzKfNF/EN 8C3y7fJT9ov2q/B77K/vn+pf5z8c4BiwJKAtEBsYHLg5sJelzeKwalnDQc5By4I6gsnBkcEVwU9C zEPEIS2hcGhQ6JbQh7ONZgtnN4WBMFbYlrBH4SbhWeG/zsHNCZ9TOedZhG3E0ojOSGrkgshDkR+j vKM2Rj2INo2WRrfHKMQkxtTGfIr1jS2N7YuzjlsWdzVeI14Q35yAT4hJOJAwMtdv7ra5g4mOiYWJ PfNM5uXOuzxfY37G/NMLFBawFxxPwibFJh1K+sYOY1ezR5JZyVXJwxwfznbOK64Xdyt3iOfOK+U9 T3FPKU15keqeuiV1iO/JL+O/FvgIKgRv0wLTdqd9Sg9LP5g+lhGb0ZBJyEzKPCVUFqYLOxbqLMxd 2C2yEBWK+rJcs7ZlDYuDxQckkGSepDlbBRVE16Sm0jXS/hyPnMqcz4tiFh3PVcoV5l5bbL543eLn ef55+5dglnCWtC/VW7pqaf8y5rI9y6HlycvbVxisKFgxuDJgZc0q0qr0Vb/l2+SX5n9YHbu6pUC7 YGXBwJqANXWF8oXiwt61bmt3/4T5SfBT1zr7dTvW/SjiFl0ptikuK/5Wwim5st52ffn6sQ0pG7o2 Om3ctQm3SbipZ7Pn5ppSpdK80oEtoVsat9K3Fm39sG3BtstlDmW7t5O2S7f3lYeUN+8w3LFpx7cK fsWdSu/KhiqtqnVVn3Zyd97c5bWrfrf27uLdX38W/Hx3T8Cexmrj6rK9uL05e5/ti9nXuZ+xv/aA xoHiA98PCg/21UTUdNQ619Ye0jq0sQ6uk9YNHU48fOOI75Hmesv6PQ20huKj4Kj06Mtfkn7pORZ8 rP0443j9CaMTVSepJ4saocbFjcNN/Ka+5vjm7lNBp9pb3FpO/mr168FWvdbK06qnN54hnSk4M3Y2 7+xIm6jt9bnUcwPtC9ofnI87f7tjTkfXheALly76Xzzfyew8e8n9Uutl18unrjCuNF11utp4zfHa yd8cfzvZ5dTVeN35evMNlxst3bO6z9z0vHnulu+ti7dZt6/emX2nuye6525vYm/fXe7dF/cy7r29 n3N/9MHKh9iHRY8UH5U91npc/bvZ7w19Tn2n+337rz2JfPJggDPw6qnk6bfBgmeUZ2XPdZ/XvrB7 0TrkP3Tj5dyXg69Er0ZfF/6h9EfVG9M3J/70+vPacNzw4Fvx27F3Je/V3x/84PChfSR85PHHzI+j n4o+q3+u+cL40vk19uvz0UXf8N/Kv5t9b/kR/OPhWObYmIgtZk9IAQRdcEoKAO8OAkCJR7UCqrtJ cyd19IRBk9p/gsB/4kmtPWFOAOxvAyB6JQCB6F6J7sboruwFwLgUivICsL29bP3TJCn2dpO5yKii xH4eG3uvDQC+BYDv4rGx0Z1jY9/3ocXeA6Ata1K/T0iYAQAM0aRQbBfJKRf8i/0D0d0MkN0RdPQA AAGdaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjc3 MTwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj40 MzE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KsuiogAAAQABJREFUeAHsnQm8XVV97/83uZmHezOQMGQChCDz jDXBBCgog6IISFtlsH19Ra3Svj6t9vMKtLZq24+1tiKIA9TKLIpEUAQhzDIIaAhTIAkhgYQM92ae 79u/FdbNPvvsfc4+87C/C2723mv911r/9V3rnLP+e00dfYGzAq63t9e6uroKSCQHLV682KZOnZos UCCkknxbMS6sCjSGSBCsIkAKPMKqAJxIEKwiQAo8wqoAnEgQrCJACjzCqgCcSBCsIkAKPMKqAJx3 ggYUF0ECAhCAAAQgAAEIQAACEGhHAhgD7VirlAkCEIAABCAAAQhAAAIpCGAMpICECAQgAAEIQAAC EIAABNqRAMZAO9YqZYIABCAAAQhAAAIQgEAKAhgDKSAhAgEIQAACEIAABCAAgXYkgDHQjrVKmSAA AQhAAAIQgAAEIJCCAMZACkiIQAACEIAABCAAAQhAoB0JYAy0Y61SJghAAAIQgAAEIAABCKQggDGQ AhIiEIAABCAAAQhAAAIQaEcCGAPtWKuUCQIQgAAEIAABCEAAAikIYAykgIQIBCAAAQhAAAIQgAAE 2pEAxkA71iplggAEIAABCEAAAhCAQAoCGAMpICECAQhAAAIQgAAEIACBdiTQsWjRor52LBhlggAE IAABCEAAAhCAAAQKE+joC1whkd7eXuvq6iokkhi2ePFimzp1amJ4oYBK8m3FuLAq1Bpyw2CVy6PQ E6wK0ckNg1Uuj0JPsCpEJzcMVrk8Cj3BqhCd3DBY5fIo9ASrQnR2hTFNqDgjJCAAAQhAAAIQgAAE INCWBDAG2rJaKRQEIAABCEAAAhCAAASKE8AYKM4ICQhAAAIQgAAEIAABCLQlAYyBtqxWCgUBCEAA AhCAAAQgAIHiBDAGijNCAgIQgAAEIAABCEAAAm1JAGOgLauVQkEAAhCAAAQgAAEIQKA4AYyB4oyQ gAAEIAABCEAAAhCAQFsSwBhoy2qlUBCAAAQgAAEIQAACEChOAGOgOCMkIAABCEAAAhCAAAQg0JYE MAbaslopFAQgAAEIQAACEIAABIoTwBgozggJCEAAAhCAAAQgAAEItCUBjIG2rFYKBQEIQAACEIAA BCAAgeIEMAaKM0ICAhCAAAQgAAEIQAACbUmgo6enp69WJQvStu7u7lol31bpwip9dcIKVukJpJek XcEqPYH0krQrWKUnkF6SdgWr9ASKS3Z2dXUVlOrt7bViMkkJqLGWG7eSfFsxLqySWlG+P6zymST5 wCqJTL4/rPKZJPnAKolMvj+s8pkk+cAqiUy+P6zymST5wCqJzG5/pgntZsEdBCAAAQhAAAIQgAAE MkUAYyBT1U1ha0Fg0aJFduWVV9oDDzxQi+RLSnPp0qVOF+nTLE66XHfddXnq3HHHHU7Xn/70py4s SS4vYoyH2Cv+66+/HhOa6+Vlm6G+cjWr/KkZ2mI16lHlwEEAAhCAQH0IVN0Y0A/sySef7P7+6I/+ yN7//vebrp/+9Kft7//+723u3Ln1KRm5QKBOBNRxueKKK6wZOpe/+c1vnC5/8Ad/UKfSF89GbKLG wGWXXWYf/vCHna7f+MY3XCJxcsVT3yUh9oqf1hiQbDPUV9rypZVrhrZYjXrEGEhb48hBAAIQqJxA Z+VJ5Kdw//3326xZs2znzp22ZcsWe/PNN93fs88+a1/+8pft2GOPtSeeeCI/Yhv4fOYzn7E99tjD Lr/88jYoDUWIElAbPuqoo6yvb/e6+yOPPNLU5qdNmxYVr/uzPlf77ruvnXDCCXXPOylDsQlvJKD5 m//xH/9hU6dONfH0YVG5pPTwbx4CY8aMsZ/85Cc2e/bsfqWox34U3EAAAhBoCQI1MQZUcv04XHzx xe4H35NYt26dfe9737O//uu/tgsuuMBuuukmH9Q21+eff94ZQm1TIAqSQ0Cd16hTZzbcGYqG1/NZ IwMaFSh34X4tdI2y8W99NTLgDQHl6+W0AQCu+QmoHmXYRZ2vx6g/zxCAAAQg0JwEamYMdHR0mP/z RR89erT91V/9lf3oRz+ym2++2b761a+6t6kartf0Ib1Nv+uuu+zf/u3fbPv27fbggw/6qG4+sOZD L1iwwHW2Dz/8cPvIRz7SH+5vXnzxRfvv//5vW7NmjS1evNhOP/109/eud73Li/RfNbdVab766qv2 vve9z5SmpjiFnWTkNNKxdetW+93vfmePPvqoTZgwwXW6LrroIhcuOY2CeGPAxys2QnDrrbfar3/9 a/eG9OCDD7ZjjjnGzjvvPDe64BIu8I+G4+XENOp8mL8q/IUXXrBbbrnFjdKIjX601XFU2aNO8d56 6y3H8KCDDrKjjz7azj//fBsyZEi/qOpPz5oC9vOf/9yuv/56l2ahMqvzILnbbrvNOjs7XWdQnULP sT/x4EadDcn66RzSV/WgN99hlyQn+ai78cYb7Ze//GV/J8bnHe6U+vYondT511ts3b/88sv22GOP uSTD9evzl27hPH1ZlYba7fjx41345z73uRy1NIVG9SFumj+vMiuuRhokGy1vTuTQw7x580zGwL/8 y7+EfHNvNSVHne2kOlK59MZehrx30kd6+Y5fIWZKV/Lf/e537U//9E9dOuE0PVul/dxzz7nPtc/P y4U/156hX1fgDS/VR7jOvK66Kg/VmeJKRrLSuZh74403THy8wSf+Z599dqq4Pm3lrfKrTWjESPWn dLwL17XKK/l//Md/tJkzZzoRxZPuYR2kf7hd+bQk853vfMd9rlXOaLvycrrGcdQUzr/4i78Ii7np XL4thjn6tqgyyenzq/Ymp/Lq+1t6Ss7XY7gNhfPXd7s+C74duUT4BwIQgAAEGkcgmO5Q0AVf4gXD o4HBELHmT/QFnYK+4IctGuyeFSYZycrpGhgOfY888oi7Kiz4cXRh+if4kXH+wQ9in/6CaRru+bTT TusLOmj9ct/61rf69tlnn77grWhf8CPeF3Sq+yZPntw3YMCAvqCD1C8Xl2bQCXdpBsZATppBp9j5 S8fhw4e7/D/+8Y/3jRo1yvkHP+4uXcmdeOKJrlxeT/kluVdeeaUvMFT65YM51E5flT2Y4pEULcdf +Ug+ro7kr3DvxGbvvffuCwyyvqAT0Pfnf/7nfcEPt4sf1fMTn/hEv16+LEpvxowZfYFB4ZPs+9u/ /VsnF3Qa3FUy0bT6hYObwEDrCzoTTvaMM85wbeSII45wz/IPux/84AfOP+go9gWdHPene+XxyU9+ sl+0kJzihV3QOclJM+i8u+egI9X3zDPP9Iv69umvak///u//7sqve+mguPqTU9uQn+S9W7hwYT9f yV166aV9SWVVuI+vMqrtej/pFhigPtmC12uvvdalE0wV6peLfgbFRHkFUzv6ZfyN/BTmuQWdwv76 ku76HIbLoPr0zrMSJ6Whz53noWeVR0715cumsure5+flfHsOtxfJKb1w/i7Bd/5RmOKLs09HHH19 KV/vvKyu3qn+9dlQXMVTWX17U7sp5qSzb1/SUWn4+OG8fdm9DpKZM2eOS146qL7T6ODrSjorL5+f 9Fb8cNnCbVG6iXcSR6+f6tF/j3o/6aa05PQZ9OVTWpLxnyHP3wkG/4TrUXrqeyMpf89Fn6k459tG XFgxv0bFjX4Gi+kZDm+Uzo3KF1bh2i98D6vCfMKhsArTiL+3eO/dvqV+KYQ7RkkVoE7o2LFj+zPx cf71X//V/Yjt2LGjb/Xq1S7861//uvtxU8feu2C6UZ86z/rRCd6Ke2/X+dWP45133tnvp7SCt9qu gx28tXf+wchEXpqSC0Yk8tJU51b5BKMGffeHfqCC0QHnf+aZZ/bnpXyjP8T9gZEb6S3Z4E29C/Gs fIciXIZI1P7HUowByerHPVwGJaQf5fe85z19ns3//M//OL3e+9739m3YsKE/LxkT0leGkHfeGPjQ hz7Up/BizncUdQ23K9+BCXdQ1bmQvuEOp9JXZ0J6eP+0cuqQKV6wmD1HTfGQf9hw8h0StdNwR046 Kz/Jh51PI9wBC956Ojkf35fXl1UMvPNpqi58uRTmeX3lK1/xogWvf/Znf9YXrMfJkfHtynuqwyb9 pUfUed18h8/Xr++se3nPMpyGZ6YOovLw5VUc5acyhp38wrwU5uV8XJ9PVM7n5dkqrvfT5993SuWv sqgdqSPrnZfV1TtvGIfjKsy3t+jnxsfzV88qXK8K851ezzRc1z4vX17pIF29v+KrPcTp4GUfeugh iTnnyxpl6+OHeSlCnM5eP9VjXFv0bUHtynOMsvH1uEur3e3Ys/Hl9e0t/LlPStOn5eP651KujYob /Qy2gs6wSl9LsIJVEoFGtY1y8h0QfHHXzc2fP98NSwdfjm7qTjTjxx9/3ILOtwVv8t2fpuVo2D74 IXfTW7z8yJEj3dD6XnvtZZr24Z3SDTr1tnnzZu/l0nnqqafc9A5Nw5G74YYb8tJUnv/n//wft7hZ 4VF34IEHWtBh7PfW9BotFH766af7/TQtKq374he/6KYUKY2wC34g3eNLL70U9q74ftmyZW56yNtv v52Tlob3NfUlzEYCwQ+3BSMh/bKf+tSnLDAaLDAW3LSq/oDgRuwUXsxpWkDQcbDA4MkR9c9+aoQC g8bsppnlCAYPmi6ielabkCskF3xA++U0PUNOU5vCTnUadHDcdA2lFXZBRy5P13B40r30k55Bxyov vt85R1Mrok5t35dLYX5qS/DmOCqa97xt2za3KL/YLkKa5hF09Ezbekad/FTmoKPpgvQ5CDqn7jMY llV9SS4uDfH0U0nCccq5V1pqL9p5KOzkLyfOURcY5zn5qyziqLrVtJc4p3antD760Y/mxJWsbzf+ Ghdfft/+9rcdq6iuqu+gg+vyD8cVwzAn6SYdov5qDz5vP1XK66tyHXbYYf3JqqyKH3Yqt6/XaFhg DLi2kKYt+nKFP6PhfArdl/K5L5QOYRCAAAQgUBsCnbVJ1tw8eK0LUCdl/fr1FrxldlflF7xddvNi o3lPnz49x0sdWG0VqB/NuB/yc845x4I30rZq1SobN26c+9G95JJL7G/+5m/cmgHNv9dc92gnPZii 4+Zhx6V5/PHHm4wHn6ZXSPNro+6QQw6J1SsqF/csI0B/mjcvg0a7wKjj5Z0WW1fTXXPNNXbSSSe5 ef/BaIvr2Md1HMVGnf6NGzfmlU3yMtiWLFli+++/f7960XrrD4jcqLOiP3V6ZBg++eSTTkLPUacO hOYeq/7UWQ/ebrq45crJ6FHemuccvEHNScYvWFVHx3c0JRDurOVEKPLgyxNOy0dR504d6bhOVVRe +qZ1qhetZ/n85z9fNIo6dlpnos6lOMvpXh1HdVy98589sYs6rWPQnH+VNaxntAzReKU8K139KQ/l 5T+vek5yMgaizuuXFM+nq++JuLIqvaS4ClNdqg3J+Is68YhjEm1bXgftzpOkg28z3mj15Qrnqby0 5sA7H0c7YEXT1Xey8vMyPo6ucTqHw0u5l576E0PVo9bsaK2RnnEQgAAEINB4AjUzBrQQVwvR9HZf b6P1Y6C3WFqMeuqpp8aWfPDgwTn+2pJUTj9W6sgmORkNMgb05mvt2rUWTLGxYE68E3/3u9/tFhpr oVwwj9n5qZOj0YM0afo84xYg+7ByritXrrQvfelLFszztqFDh1qwBsGVIfxmuJx0k+Lox11vANXp 025OcgcccICdcsopFkzz6R+pERsZBIXYRPMYNmxY1Cv2WfWovH3Hxy9c9p2bcCS9JZfTW1F1XPUn Nuq8amGq3m7LFZLTuRZqd96p83HWWWf5x/6rRhDiXLTDFicT51esk5NUx0n+cXlE/WQMBFNkTMZs MSeGccaA4vm3x76Okj57npnKGmYcvi+mR7HwaHvRAn8ximsvPq1CDJPqxaenRbE//vGPfVI5V32X JTkfPym8FH8ZwPor5HzdxMkklV+fo7gRAF+P0bRqWY/B2iMbOHBgwXqM6sMzBCAAAQjUjkDNjAGp rI6a77SVUwRNB5JTR1Y77qRxn/3sZ92uFitWrLC7777b/f3zP/+z6U37N7/5TZeE3sDrzfbvf//7 vCT1hi/8hj5PoEoeejurXZX+8i//0umlzoZY6Ye+lI54KepceOGFpj/tbOPZXH311S5P7bokp7Jr p6Q4NqXkFSerkRy9ldfIhEZwPGeVWcZj1Kn96E21OoX6U2cmmPfsRlH8TiaKkySnOL/97W/7k1UH J5iP3Z9vf8A7N9ERpKSOVTRe9LmaHalo2knPfktRGXjFnPTTW2w/zUedWbHV6Isvsy+D5DRVJ8lF mSXJleMvw1F5q734aSpKJ6m9FMujmHGnEShNjyvVlfMWPUkXbb3sDbJS9SgkH1e2en3XhT/3qkef b7n1WKichEEAAhCAQOkEBpQepX4xgt1v+jNTp6PQX7/gOzfqFMkw0FaaGpL+z//8TzdlScFTpkwx bSNYKL1adnKCxdHOEAgWUfcbKF5/jWyU6jQyEnZ+bnHYL3yvUQ4ZIZrGpcOptB3rPffc40TERtOA qu3U4ZQhoM6l3kqH2Rd66yo5TXGQ8aCOoTqs2r5VHYmwi5NTx9/LydDSm+FwvtH7cHrVuE96E63p GpUYyVHdNPImYyDNqICPqw6n6kR8fHsJd0K9MaCOW5RT+NmnV4ur6ltTqkppL4WMWG/oRHX1HXO9 MAiXLXofjRd+1qhjXDsWY9V3tC3IUA07z1tpRPMNPytOIePDt3efti+z8gunE7338tW+lvu5r7Ye pAcBCEAAAskEOvVjX8ylkfFpaB6qnPbcl0sT18fR1J2wvObTa0qDOivBtqN26KGHujT9P9r3XtM+ 9KfpNpp6o2lBwbZ3OekoDXV8tRZAC2W1p7fmq2tubbgDpHQ1BUUnJGuvf+2F7cshHcO6SVb7ZctF /RUn6ucE3/lH03DkNC0qLKf7YOcYF6bzD8JhzjPyz3777ec6c1pvEDacVFY56ac07rvvPrv33ntN C65lIIVdsD2r60iqEyLZYMtP+4d/+AdnpPjFzF7eszn33HNzzkEoVl7F90aO10l+yk9/erMv59PR VCVNoQp2/rHoHHBNM9MbbdWHOn5p5JRHsDuS66xpUewf//Efu/z8P1r8qc6R33Pd17mm3sgQCTtf 58pbhpOcb79ef8VR51DtVmXxIyDSQ+cxyEkfPcv5NP2z84z8UyhMo2YybrWGJU4uzs+PxMhYlo6a YqQRqbCs2oLO/ZDOfh98r5a4a7qHrx/PLPw5CacVrnefhufln3WNstAp5uF0dO/bi0b/fJjPX/oG 24uGk7Tbb7/dlU+fF8l7WZ+/1qXIySD26fkExOZrX/uaaxvhxbo+3F/FR2t/Hn744ZxFveKk0Tct vNf8fF++MCelofVNchr5kvETdtJBaejzIB00JVJO5ZJsWGf5yfmyaW2H2qIMknCbdULBPzojJFyP Xr9wml5W13A9eo7RsoTl4j73CleZfD16XeVfKE2FyyXptiu08L/ELcwnHAqrMI3C97AqzCccCqsw jcL3dWUVzBkt6II3OwXDo4HB2zxNwO4LpncknjNQKI4P8/n6LTyDjnlfMM3HBQc/+C595RMMqzu/ YNqIyzeYWtQX7ODRF3S4++TntyYNOkp9waJYJ6t92xVXf5IN3qz3SW/pLD/twe9d8IPl/BQedcEb Ohfm/YNDutxZBMrrF7/4RZ+2So1zmzZt6pOM8goW9joRbc2pLT5/+MMfOn+FBZ3UuOj9ftqWVHI6 r0D6aevA4A2jO0dA/tLPO52jID/x0DaiYTbBSEFfsGDaiUq3oDPrZMUjeJvv0o5j47cmFKM0Lngb 7tIVc+2tHsxjdnn5tKW731Yx6ED3BZ0nd26B/KSH5IM3ne6MB7/tYSE5hXk5xdez4it/pRm8RXXp B4ZA/173KofXR9ewU5v0YcF0Bxdf6Yu92IblVRfyE8vAKOjTFpDSX2WSHtLHu2C0xMn65/BVaeh8 h0Iu6HD2BZ2+vqBznCcWvJHO8/Me2tpRzJVHMI3Ee/dfg0P/nK7SWbpLZzELDgXLK6/nIhZy/vOr e6WvMoad/MK8FOblfNxgVMD5qb6Ublx7kU6qA59/0PF1+klP1XEwouTSUFm987Lh/L2fry/FVb3p OVpfPp3wNVgYm8PKty2VSeXwzufjOcnfl1d1IPnAKHOcC+ng20zwIsTJSlfVi2cWLltgILh0w2WT fv5clPDWnj7dsH5ed18/ela78mcd6HtG6aku5MJyeg5/7pWuvteki2cR/tx7v7j8lZZnpftSXaPi FvoMFitDo3RuVL6wKtYidofDajeLYnewKkYo+N4uJlLql4K+xPVjoC/1tBUQjuP1Ceerzrv2yg4W qrq0lb46t74j7ePoADIdOiTDQTL+L3iT3b+PvpfVj7f2x1fn0MsFowZu720vo2spxoB09j9mSjPc GQ+nqXt1yHVoms974sSJLq7Cgt2Q3DkMCivmdPiPT0PXYMcfd2ia7sP5B1NJ3NkMOngsLC9DQsZV 2Mkg+MxnPuMOcPOyMl6inf5SjYFg/r7rGKjzrT+x93uP+46Q/OV0zoTq3Mv6qzorwZvqfnULySm/ sNOzOtY+LV2lg+os7HwdRv1Vv+rw+M6N4qvtxrVfpff973/fdRDD+Un/qF6+AxbWwd+LfzFjIHjL 3/exj33MR8m5FvoM+s6c8lDHM+pUXukq/cJlUPllVIadZyYWcuHPr9JXGmEnvyhfL+fjKm91bn3e 4bry+fk68M86JyOsr9IMGwLSwcvqGnZqg+r4+/x0Vf7R+grH8feeldiE46sN+zNTJOvz9pzk58vr w6M6qDxRHZSm/FU+n5+eg1Ei5xctmwyCqG4ynOQfdj5Nb0SHw3z9yM+3Ky8vHXyeYTnJSvdw3ipf 0uc+jo/S8C7MyvulvTYqrmeVVs+wXKN0blS+sArXfuF7WBXmEw6FVZhG/L3reQVf3olOwxTBl3di eDQgyKbfS0PBwY9A/3PSTThO8KPixOLy1RCy9sTX0LemaHjZaLrLly93Q8kaotbUAM3NL+SCjlD/ NALFCZc3Tjeflg/zenidVW5NWZo0aZJbjOvl467aYlND71rXkHaLzmg6WhAc/Hi7svopBFGZ8HPw wXA7PGnKlPIOlzcsp3ttV6mF3OIYdb68Uf9Cz2Km/DWtRVMrPDvFifKUn8rl51cHbxBNf3HtKk4u nLbSkgt+5Fw+StOnFycnXaL+vrwK8/E19UMuTt77S1bTvgKDyuUZTTeu3C7Rd9JVvkFH2HvlXAMD 2PyakcD4ywnTg6Z/FfoMFso7XF7Vmf7SMvNxpUNcHnG8vFz4Myg/n7fKF2bn5b2fnhVXU55Uz+Ie jSN95CTr4+3y2cVK3yuKp/haSyDuUTkvH7768hbS18tH8/Zxw+FeB1+ncTooHU390TbIYV2j6YfT 9SwlrzSj7Upx5ZLy82G+XUleacrpe1kuLg0vJ66SC+cblddzXP5KO8pKfmldo+J6Vmn1DMs1SudG 5QurcO0XvodVYT7hUFiFacTfV303oaQv8fjsd/mmjaMOs/9xLJSetuoM3rQXEskJC4asc57DD4V0 SwpTh8LPJw+nFXfvD/tSYy3X6byCUrY+9R065acv/UJO2zlW04mZOgMy0KL8os/KV53tNLsrpZVT HuqIFEszThfPQWHRNpMk72VlTCUZXUlxlZ/CCoXrMDz9lesKpe3TlIzqTH+FXFJacf6l+CXlHU3D P+tarD142Wh55B+t26hMoWfFT9LXx0vKOxyeRgelI0Mv+hlNSl/+Yd3iPvtJcaVbXJhP0+ueRi6a bzTd6HM4be4hAAEIQKD6BJp6N6HqF5cUIQABCEAAAhCAAAQgAAFPAGPAk+AKAQhAAAIQgAAEIACB jBHAGMhYhVNcCEAAAhCAAAQgAAEIeAIYA54EVwhAAAIQgAAEIAABCGSMAMZAxiqc4kIAAhCAAAQg AAEIQMATwBjwJLhCAAIQgAAEIAABCEAgYwQwBjJW4RQXAhCAAAQgAAEIQAACngDGgCfBFQIQgAAE IAABCEAAAhkjgDGQsQqnuBCAAAQgAAEIQAACEPAEMAY8Ca4QgAAEIAABCEAAAhDIGIGOnp6evlqV OUjburu7a5V8W6ULq/TVCStYpSeQXpJ2Bav0BNJL0q5glZ5AeknaFazSEygu2dnV1VVQqre314rJ JCWgxlpu3ErybcW4sEpqRfn+sMpnkuQDqyQy+f6wymeS5AOrJDL5/rDKZ5LkA6skMvn+sMpnkuQD qyQyu/2ZJrSbBXcQgAAEIAABCEAAAhDIFAGMgUxVN4WFAAQgAAEIQAACEIDAbgIYA7tZcAcBCEAA AhCAAAQgAIFMEejMVGkpLAQgAIEME9ixY4dt2bLFdF2/fr0NHjzYhgwZYgMG8F4ow82CokMAAhkn gDGQ8QZA8SEAgfYmsGnTJluyZIktX77ctLmCnrdv326bN2+2UaNG2fDhw23s2LG29957u7/OTn4W 2rtFUDoIQAACuQT41s/lwRMEIACBliegzv6aNWvslVdesZdffrnfGNBowM6dO62vr89dBw4c6EYF xowZ4wyBqVOn2vTp023atGnOUGDEoOWbAgWAAAQgUJQAxkBRRAhAAAIQaB0Cb7/9tr300kv2/PPP 2/z5850hUEz7tWvX2uLFi+2pp56yd73rXXbwwQe7vwMOOMBGjhxZLDrhEIAABCDQwgQwBlq48lAd AhCAgCegN/6vvvqqPfjggzZv3jx78803bevWrT441XXbtm324osvOsNAhsTRRx9tM2fOtIkTJ6aK jxAEIAABCLQeAYyB1qszNIYABCCQQ0DTgtSJv+OOO+yFF16wjRs35oSX8qApRIqv9GRQrFy50s46 6yw3jaijo6OUpJCFAAQgAIEWIIAx0AKVhIoQgAAEkghod6Bnn33W7r77bvv973/v1gMkyZbiL6NA J3fOnTvXNGLw/ve/300hwiAohSKyEIAABJqfAPvJNX8doSEEIACBWAKaGvS73/3OfvrTn1bVEAhn pl2HHnroITfqoHUFOAhAAAIQaC8CGAPtVZ+UBgIQyBCBZcuW2Z133mkLFiyo2ohAHD6NDDz99NP2 i1/8wm1PGieDHwQgAAEItCYBjIHWrDe0hgAEMk5AZwbce++9bo2ADhGrtdN0pMcff9wtUK5HfrUu D+lDAAIQgMAuAh3BnNC+WsHQfNPu7u5aJd9W6cIqfXXCClbpCaSXbKV2pQXD9913n5u6o0PE6um0 s9A555xjxx9/fD2zbdm8WqldNRoyrNLXAKxglZ5AccnOrq6uglJ6+1RMJikBNdZy41aSbyvGhVVS K8r3h1U+kyQfWCWRyfdvJVbaQvSRRx5xpwnnl6S2PitWrLCHH37YTjjhBBs9enTJmbXi93MlOrdS u/KVWUl5K4kLK18Dxa+wKs7IS8DKk0i+Mk0omQ0hEIAABJqOgM4O0HSdt956qyG6aZchGSM61Ez3 OAhAAAIQaG0CGAOtXX9oDwEIZIzAmjVr3EnBWtTbKKepSTJI6j1FqVHlJV8IQAAC7UwAY6Cda5ey QQACbUdAW4kuXbq0oeXSiIBOKG7U6ERDC0/mEIAABNqMAMZAm1UoxYEABNqXgEYDdAiYFhA32q1e vdqeeeaZRqtB/hCAAAQgUCEBjIEKARIdAhCAQL0IaERA8/WbwWl0QIuYm8EwaQYe6AABCECgVQlg DLRqzaE3BCCQOQLPPvusab//ZnFLliwxHXyGgwAEIACB1iWAMdC6dYfmEIBAhgjs3LnT7eDTTEXW 4WNaO4CDAAQgAIHWJYAx0Lp1h+YQgECGCGzYsMGWL1/edCV++eWXm04nFIIABCAAgfQEMAbSs0IS AhCAQMMI6OCczZs3Nyz/pIy1jkGjFjgIQAACEGhNAhgDrVlvaA0BCGSMwLp166yRZwsk4daIRTMa KUn64g8BCEAAArkEMAZyefAEAQhAoCkJ6IAvzdFvNiedOHys2WoFfSAAAQikJ4AxkJ4VkhCAAAQa RmDr1q2m7TybzUkn6YaDAAQgAIHWJIAx0Jr1htYQgEAGCTSjMaD1AqwZyGBjpMgQgEDbEOhYtGhR 871qahu8FAQCEIBAdQjMmzfPbrjhhqabkjN27Fj71Kc+ZePGjatOQUkFAhCAAATqSqBz6tSpBTPs 7e21rq6ugjJJgYsXL7Zi6SfFrSTfVowLq6SWkO8Pq3wmST6wSiKT79/srPS9NmjQoKYzBgYPHmz7 7befdXd350ON8WnF7+dKdG72dhVTRVZJeSuJC6u42oj3g1U8lzhfWMVRyfVjmlAuD54gAAEINCWB ESNGWGdnZ9PpNmTIEBs+fHjT6YVCEIAABCCQjgDGQDpOSEEAAhBoKAGN0GpkoNncmDFjmlKvZuOE PhCAAASalQDGQLPWDHpBAAIQCBEYPXq0jRo1KuTTHLeTJ0+2jo6O5lAGLSAAAQhAoGQCGAMlIyMC BCAAgfoT0Nz8KVOm1D/jIjkecMABRSQIhgAEIACBZiaAMdDMtYNuEIAABEIEDj300NBT4281bQlj oPH1gAYQgAAEKiGAMVAJPeJCAAIQqCOBQw45xDRC0Cxu0qRJNn78+GZRBz0gAAEIQKAMAhgDZUAj CgQgAIFGEFDH+13velcjso7N85hjjrGBAwfGhuEJAQhAAAKtQQBjoDXqCS0hAAEIuIW6M2fOtAED Gv/Vre1EDz/8cGoFAhCAAARanEDjf1FaHCDqQwACEKgnAU0V0qm/jXZazLz33ns3Wg3yhwAEIACB CglgDFQIkOgQgAAE6klg3LhxdtBBBzV0O09NDTr44INt5MiR9Sw6eUEAAhCAQA0IYAzUACpJQgAC EKgVgaFDh9qRRx5pujbKaYrQEUcc0VSLmRvFgnwhAAEItDoBjIFWr0H0hwAEMkVA6wUOO+ww22ef fRpW7mnTptl+++3XsPzJGAIQgAAEqkcAY6B6LEkJAhCAQF0IaFeh2bNnm/b5r7cbMWKEnXDCCaYr DgIQgAAEWp9AR09PT1+tihGkbd3d3bVKvq3ShVX66oQVrNITSC/ZzO1q+/bttnXrVtP0HO/Wrl1r 1157rc2bN8971fza0dFhM2bMsA9+8IM2YcIEl9+OHTts3bp1Nnr06KbY5ajmEErMoJnbVYlFqbk4 rNIjhhWs0hMoLtnZ1dVVUKq3t9eKySQloMZabtxK8m3FuLBKakX5/rDKZ5LkA6skMvn+zchq27Zt tnz5cnvyySfdi5X3ve99/fv667v1lFNOsaVLl9qaNWvyC1QDn4kTJ9qZZ57p1gr47/YVK1bYr371 KzdtSGsZ9AKo0Nanrfj9XInOzdiuijWNSspbSVxYFauZ3eGw2s2i2B2sihEy6ywuggQEIAABCNSb wNtvv23PP/+8Pfvss/bUU0/Z1KlT3VqB8Im/06dPd1N27r33XtPoQS2dTj7WqIDWC7z11lsuq76+ Pnv00UftnnvuMe1ytHjxYjvqqKPcbkeNXOBcSw6kDQEIQKDdCLBmoN1qlPJAAAItTUAd7FdffdXu uOMO+8lPfmKPPPKIbdy40RYuXGhPPPFETtnU4dboQD0W82o7U41MDBkypF8Hdf7vu+8+Z4hoBENG wY9//GN31RtiHAQgAAEIND8BjIHmryM0hAAEMkJA04K0BuC2226zX//617ZkyRLTnHy5zZs3u072 smXL+mloDr/e1J999tm2xx579PtX+2bPPfe0D3/4wzk7GG3YsMHuvvtue/PNN/uz27Jli73wwgvO kPnZz37mwmTc4CAAAQhAoHkJYAw0b92gGQQgkCECWiCsN/96s65pQer8R93rr79uv/jFL2z9+vX9 QToA7LjjjrMzzjjDwlOI+gUqvNFCYa0TOPzww/vXAshA0fSl3/zmN7Zz586cHPSsNQwyFO688043 opEjwAMEIAABCDQVAYyBpqoOlIEABLJIQCMCDz/8sJsWpHUCfjQgjoWmDf32t7/Nkens7LSTTjrJ 3v/+97tdfeLileOnHYKUpqYHhRcFa9Fw1CiJpi9j5qGHHnJlWrBgQTSYZwhAAAIQaBICGANNUhGo AQEIZJOADIGnn37aTa3RuoBChoAIaS7+L3/5S3vjjTdygI0aNcqtH9Bb/LFjx5qmEJXrFHfMmDF2 1lln2cknn2xK2zvtzPHAAw/YSy+9lDcq4GX8VVOJNNqhtQ+a8sSUIU+GKwQgAIHmIYAx0Dx1gSYQ gEAGCahTrcXC6tyn6SxrGs7LL7/spuD4XX2ETR14bet5+umn24c+9CE78MADTSMGpTrFOeCAA1wa SstvIap0Vq1a5QyRZ555JvXuRd7Yueuuu1z8UvVBHgIQgAAEakug9F+K2upD6hCAAAQyQ0Bvy/WW X9No0hgCHoxGD7SlpzcAtP+/dyNHjrRTTz3V9tprLzfioFEHdeLTOI0GHHPMMXbsscfaoYcemnPI mdYpaAtT6asOfilO6yEee+wxd2rxBz7wgVKiIgsBCEAAAjUmgDFQY8AkDwEIQCCOgKb7zJkzx+2+ U2xqUFx8zclXB1unEutE4PDi4WHDhrn9/rXTkLYdnT9/vjM4lKfy0uiCjA+tA9BIwIgRI+xd73qX MwB0ToDODPCjCpLTacfaNlTGQLlbhioNxVfap512Wv/haXFlww8CEIAABOpHAGOgfqzJCQIQgIAj oAPCtBOP3u6XYwh4jDp/QPP35bTIVweT+U68rtpu9A//8A/dYWUafdC0InXKtQWojAmtBdAiYclp atDee++d00mX0aDRC+mpEQHFrcR5o0J57b///hWta6hED+JCAAIQgMBuAhgDu1lwBwEIQKAuBNQp 12Fd6sxX6tatW+fS0onFM2fOdNN8wgeD6e2/pgzpb9OmTaZFvZrmo465FhprZEF/0QXHMli0a5EM AV3D25lWovPSpUvdGQoyPJQvDgIQgAAEGksAY6Cx/MkdAhDIGAGNBMgQ0M5BpawTKIRJRoXOJtAp wDoETPP+dVCYjIJwJ1/Th/Qnp454eHGwT1+jBjIsZABou1OdbaA5/9VyMjK0w5DWJRx99NHVSpZ0 IAABCECgTAIYA2WCIxoEIACBcgjohN65c+em3o0nbR7qZMvAkEHw2muv2bvf/W7TmgFNAdIuQ+HR gmiamg6ktQAyAhYtWuTWGGjHII061MKtXr3anVOgdQqapoSDAAQgAIHGEegI9oyu2Vnx2o9aP0K4 4gRgVZyRl4CVJ1H8CqvijLxEPVhpms7111/v1gv4fGtx1dQgffdqlyGNEGjRrv7U8daIwKBBg1y2 GgVQh1+7Da1cudKWLVvmRhb0XMlahjRlkg5/8id/YrNmzUoj3rIy9WhXLQsnojisIkAKPMKqAJxI EKwiQGIeO+OGicNyeltUTCYsH75XBZQbt5J8WzEurMItp/A9rArzCYfCKkyj8H09WGnKjc4IqLXT m369fV+zZo0bJVDHW4aAvo+19aieNfVHclo7oM6/FhTLOJBfPZzWLWgRtdY5aO1CGsd3expKu2Rg BaskAq3YNirRuR7f7XGsK9G53nGZJhRXg/hBAAIQqDIBdb41r7/SHXlKUUtrEtTB158WAOvNfzM5 GUfa9nTGjBk5axuaSUd0gQAEINDuBDiBuN1rmPJBAAJNQUBven73u9/VfPpNUxQ2pRKaNqW1CRqV wEEAAhCAQGMIYAw0hju5QgACGSPwyiuvNN2b+UZXgaYkaWRAU5pwEIAABCDQGAIYA43hTq4QgECG CKjT+9BDD7n9/TNU7FRF1Q5Gzz//fCpZhCAAAQhAoPoEMAaqz5QUIQABCOQQ0E498+bNy/HjYRcB byjVa+Ey3CEAAQhAIJcAxkAuD54gAAEIVJ2ADAGd/IuLJ6ApVDqVGQcBCEAAAvUngDFQf+bkCAEI ZIiA9uvXIllcMgHttASjZD6EQAACEKglAYyBWtIlbQhAIPMEtJXo4sWLM8+hGIDnnnuOnZaKQSIc AhCAQA0IYAzUACpJQgACEPAEli9f7vb4989c4wksXbrUtP0qDgIQgAAE6ksAY6C+vMkNAhDIGIE3 33yTffRT1PnGjRtZN5CCEyIQgAAEqk0AY6DaREkPAhCAwDsEdAKwts7UnHhcYQI6eEyjKDgIQAAC EKgvAYyB+vImNwhAIEMEtm3bZqtWrTK2zSxe6WIlw0kGFA4CEIAABOpHAGOgfqzJCQIQyBgBdXDX rFmTsVKXV1wZTDqJWMxwEIAABCBQPwIdPT09NXsNE6Rt3d3d9StNC+cEq/SVBytYpSeQXrIW7UoL Yv/jP/7DFi5cmF6RDEseddRR9md/9mc2fPjwtqFQi3bVNnAiBYFVBEiBR1gVgBMJglUESMxjZ1dX V4z3bi/9mBWT2S2de6cKKDduJfm2YlxY5badQk+wKkQnNwxWuTwKPdWCld5yay48Lh0BLSIeNmxY 4u8G3+3pOEoKVrBKItCKbaMSnWvx3Z7ENuxfic71jss0oXDNcQ8BCECgigS2b9/OycMl8Fy3bp2J GQ4CEIAABOpHAGOgfqzJCQIQyBgBnT7MyED6StfIAMZAel5IQgACEKgGAYyBalAkDQhAAAIxBGQM sCA2BkyClwwndl5KgIM3BCAAgRoRwBioEViShQAEIKC33GyVmb4d6DwGGVA4CEAAAhCoHwGMgfqx JicIQCBjBOjYllbhGhWAWWnMkIYABCBQKQGMgUoJEh8CEIAABKpGgGlCVUNJQhCAAARSEcAYSIUJ IQhAAAKlExg0aFDpkTIcQ1OqBgzgZynDTYCiQwACDSDAt24DoJMlBCCQDQKdnZ2mP1w6AgMHDjT9 4SAAAQhAoH4EMAbqx5qcIACBjBGQITBq1KiMlbr84o4cOdIYTSmfHzEhAAEIlEMAY6AcasSBAAQg kILA8OHDbf/997eOjo4U0tkWESOxEjMcBCAAAQjUjwDGQP1YkxMEIJAxAurYnnzyyXbggQdiEBSo exkCBxxwgJ1yyikYAwU4EQQBCECgFgSYzFoLqqQJAQhAICCgaUJHHnmkDRkyxObNm2fLly+39evX m/bT97vmaCvNcufJNyqu9B88eHBZdex11kJhTQnSNKqJEyfaIYccYgcffDBrLMqiSiQIQAAC5RPA GCifHTEhAAEIFCUwdOhQO+qoo1xHd8WKFXnGwIYNG2zEiBFF04kTaFRclWPChAlxKhX18zqHjQGl JYMJBwEIQAAC9SfQ0dPT01erbIO0rbu7u1bJt1W6sEpfnbCCVXoC6SVpV7BKTyC9JO0KVukJpJek XcEqPYHikp1dXV0FpXp7e62YTFICaqzlxq0k31aMC6ukVpTvD6t8Jkk+sEoik+8Pq3wmST6wSiKT 7w+rfCZJPrBKIpPvD6t8Jkk+sEois9ufBcS7WXAHAQhAAAIQgAAEIACBTBHAGMhUdVNYCEAAAhCA AAQgAAEI7CaAMbCbBXcQgAAEIAABCEAAAhDIFAGMgUxVN4WFAAQgAAEIQAACEIDAbgIYA7tZcAcB CEAAAhCAAAQgAIFMEcAYyFR1U1gIQAACEIAABCAAAQjsJoAxsJsFdxCAAAQgAAEIQAACEMgUAYyB TFU3hYUABCAAAQhAAAIQgMBuAhgDu1lwBwEIQAACEIAABCAAgUwRwBjIVHVTWAhAAAIQgAAEIAAB COwmgDGwmwV3EIAABCAAAQhAAAIQyBQBjIFMVTeFhQAEIAABCEAAAhCAwG4CGAO7WXAHAQhAAAIQ gAAEIACBTBHoWLRoUV+mSkxhIQABCEAAAhCAAAQgAAFHoKMvcIVY9Pb2WldXVyGRxLDFixfb1KlT E8MLBVSSbyvGhVWh1pAbBqtcHoWeYFWITm4YrHJ5FHqCVSE6uWGwyuVR6AlWhejkhsEql0ehJ1gV orMrjGlCxRkhAQEIQAACEIAABCAAgbYk0NmWpaJQEIAABFqUwJVXXpmo+axZs2z27NmJ4XEBGvwd OHCgbdmyxQYNGhQngh8EIAABCGSYACMDGa58ig4BCDQfgQceeMDUgY/7K1dbpbV169ZyoxMPAhCA AATamAAjA21cuRQNAhBoTQJ6+19oBGDu3LmmUYJ58+bZfffdZ3//93+fU9B7773Xnn/+eRszZox9 4hOfcGEyBkaMGJEjJ8NDLpxX1O+xxx6zYKMJe/nll+2CCy6w6dOnuzj6R/ksXLjQdu7cafvtt5+d euqpLiychkY6Lr/88v443EAAAhCAQHMRYGSgueoDbSAAAQgUJaDO+//7f//PvvjFL9rTTz9tAwYM sOeee87Fu+uuu+y0006zp556yl577TXXgVeApgnFuZNOOinHWx15GRtyf/VXf2Vnn322/fKXv7QF CxbYu9/9bmdkKEydfHX+ly5dam+99ZbLMzzFSffjxo0z6YODAAQgAIHmJcDIQPPWDZpBAAIZJaDO uO+QhxGE37Dvtddeduedd7rd3i655BK77rrr7N///d/t1ltvta985Sv2hS98wUX9z//8T7vlllvK miakUYFvfetbdt5557m09t9/f1uyZIkzCpSP0vVh0ueb3/xmzijA1Vdf3R8eLgf3EIAABCDQPAQw BpqnLtAEAhCAgCOgOf7FnO+ES05bOHvj4aGHHrIzzjijP/r73vc+d1/OmoF/+qd/cm//NU1I04M+ //nP2/Dhw11eq1atsvnz57sRAp+ZDIU33njDPcqQuP/++30QVwhAAAIQaFICGANNWjGoBQEIZJeA pgHpr5DT/P9t27bliWjKzujRo/v9p0yZ4u7LMQZOOeUUtybhJz/5iV177bW2fft218Hv6elx6wSi RoumFckgkEualuQC+QcCEIAABJqGAMZA01QFikAAAhBIT0Ad8uiCYMU+4ogj7PXXX+9PyI8YFDIG 1q5d229APProozZjxoz++FpToD91/A899FA3EvC5z33OVqxYYYccckjsNCC/gLg/EW4gAAEIQKBp CWAMNG3VoBgEIJBlAkkdaj9ioJPW44wBLfjVLj8zZ850Hfgbb7zRYYwzBpTWCSecYLfddpt98pOf dB399773vf3YNcXof//v/21nnXWW21Fo2LBhdswxx1h3d7czAn74wx/a5MmTTesFtGbhN7/5jVuz 0J8ANxCAAAQg0PQEMAaavopQEAIQyBqB8K484bL7Q8d0lTGw9957h4Pd/f/9v//Xzj//fPd2//TT Tzc9L1++PHEB8WWXXWZz5syxL3/5y3bhhRfmpHfTTTe5HYu0c1FnZ6cbIfj0pz9tixcvtquuusr+ 7u/+zv7oj/7INmzYYEceeaRpwbA3UKQjDgIQgAAEmp8AxkDz1xEaQgACGSKgRbfRufi++B0dHe5W MrqXQSB3xRVXuKv+kb92+lEaUfl+odCNzg7QX1jeB8vYuP766/v18ekpfPz48XbNNdfEhmnEgcXD niJXCEAAAs1NAGOguesH7SAAgQwSCHe644pfLFxxwjLh+7j0ovJRmULxk8KS/KNp8wwBCEAAAo0l 0BEsQiu+h12ZOmqBm+aW4ooTgFVxRl4CVp5E8SusijPyErDyJIpfYVWckZeAlSdR/Aqr4oy8BKw8 ieJXWBVn1NnV1VVQSsPQxWSSElAFlBu3knxbMS6sklpRvj+s8pkk+cAqiUy+P6zymST5wCqJTL4/ rPKZJPnAKolMvj+s8pkk+cAqicxu/wG7b7mDAAQgAAEIQAACEIAABLJEAGMgS7VNWSEAAQhAAAIQ gAAEIBAigDEQgsEtBCAAAQhAAAIQgAAEskQAYyBLtU1ZIQABCEAAAhCAAAQgECKAMRCCwS0EIAAB CEAAAhCAAASyRABjIEu1TVkhAAEIQAACEIAABCAQIoAxEILBLQQgAAEIQAACEIAABLJEAGMgS7VN WSEAAQhAAAIQgAAEIBAigDEQgsEtBCAAAQhAAAIQgAAEskQAYyBLtU1ZIQABCEAAAhCAAAQgECKA MRCCwS0EIAABCEAAAhCAAASyRABjIEu1TVkhAAEIQAACEIAABCAQIoAxEILBLQQgAAEIQAACEIAA BLJEoKOnp6evVgUO0rbu7u5aJd9W6cIqfXXCClbpCaSXpF3BKj2B9JK0K1ilJ5BeknYFq/QEikt2 dnV1FZTq7e21YjJJCaixlhu3knxbMS6sklpRvj+s8pkk+cAqiUy+f5ZYLVq0yMaMGVP293OWWKml VPKbAqv8z1qSD6ySyOT7wyqfSZIPrJLI7PZnmtBuFtxBAAIQyAQBGQM33HBDJspKISEAAQhAoDAB jIHCfAiFAAQg0HYErrzySnv44YfbrlwUCAIQgAAESieAMVA6M2JAAAIQaFkCGhV44IEHGBlo2RpE cQhAAALVJYAxUF2epAYBCECgqQnIGPDuuuuu87dcIQABCEAgowQwBjJa8RQbAhDIJgFNEfJu7ty5 /pYrBCAAAQhklADGQEYrnmJDAALZI+CnCPmSMzLgSXCFAAQgkF0CGAPZrXtKDgEIZIxAeIqQL7rW D+AgAAEIQCC7BDAGslv3lBwCEMgYgeuvvz6vxHF+eUJ4QAACEIBA2xLAGGjbqqVgEIAABHYT0KhA 3LSgOL/dsbiDAAQgAIF2J4Ax0O41TPkgAAEIBATipgh5MEwV8iS4QgACEMgeAYyB7NU5JYYABDJI oNDOQUwVymCDoMgQgAAE3iGAMUBTgAAEIJABAoXe/jNVKAMNgCJCAAIQSCCAMZAABm8IQAAC7UJA hkAhY0DlLBbeLiwoBwQgAAEI5BLo6Onp6cv1qt5TkLZ1d3dXL8E2TglW6SsXVrBKTyC9ZDu3q9df f90efvjhfhhf/epXbcqUKfbHf/zH/X56njlzZv9zoZt2ZlWo3OWEwSo9NVjBKj2B9JK0q+KsOru6 ugpK9fb2WjGZpARUAeXGrSTfVowLq6RWlO8Pq3wmST6wSiKT79/OrA477DDTn3e33HKLbd++3S69 9FLvVdK1nVnFgajkNwVWcUTj/WAVzyXOF1ZxVOL9YBXPJezLNKEwDe4hAAEIQAACEIAABCCQIQIY AxmqbIoKAQhAAAIQgAAEIACBMAGMgTAN7iEAAQhAAAIQgAAEIJAhAhgDGapsigoBCEAAAhCAAAQg AIEwAYyBMA3uIQABCEAAAhCAAAQgkCECGAMZqmyKCgEIQAACEIAABCAAgTABjIEwDe4hAAEIQAAC EIAABCCQIQIYAxmqbIoKAQhAAAIQgAAEIACBMAGMgTAN7iEAAQhAAAIQgAAEIJAhAhgDGapsigoB CEAAAhCAAAQgAIEwAYyBMA3uIQABCEAAAhCAAAQgkCECGAMZqmyKCgEIQAACEIAABCAAgTABjIEw De4hAAEIQAACEIAABCCQIQIdPT09fbUqb5C2dXd31yr5tkoXVumrE1awSk8gvWSW2tVZZ53lwMyZ Myc9oJBklliFil3WLazSY4MVrNITSC9JuyrOqrOrq6ugVG9vrxWTSUpAFVBu3ErybcW4sEpqRfn+ sMpnkuQDqyQy+f5ZYtXZ2Wnbt28v+/s5S6zUUir5TYFV/mctyQdWSWTy/WGVzyTJB1ZJZHb7d+6+ 5Q4CEIAABCAQT+Cuu+4yjSSMGjXKDjnkELvwwgvjBfGFAAQgAIGWIsCagZaqLpSFAAQgUH8CH/vY x+xHP/qRnXzyyTZu3Dj73Oc+Z1u2bKm/IuQIAQhAAAJVJ4AxUHWkJAgBCECgfQjMnz/f7r//fvvo Rz9q5557rn3+85+3ww8/3P7rv/6rfQpJSSAAAQhkmADThDJc+RQdAhCAQDECBx98sK1YsSJHbMeO Hbb//vvn+PEAAQhAAAKtSYCRgdasN7SGAAQg0BACr7zyiq1du9Y+/OEPNyR/MoUABCAAgeoSwBio Lk9SgwAEINC2BJ544gn78z//czvjjDPatowUDAIQgEDWCDBNKGs1TnkhAAEIlEHgtttus09+8pN2 90jU5uQAAEAASURBVN1326RJk8pIgSgQgAAEINCMBDAGmrFW0AkCEIBAExGQIXD++ee7/fa1teji xYubSDtUgQAEIACBSghgDFRCj7gQgAAEMkDgqquusvvuu8+eeuopV9rly5fbwoULbfbs2fbAAw/Y 3Llz7fLLL88ACYoIAQhAoP0IYAy0X51SIghAAAJVI/Db3/7Wdu7caVdeeWV/mps3b7Zhw4Y5Y0Ce 2noUY6AfDzcQgAAEWooAxkBLVRfKQgACEKgvgaOPPtq9/Q/nqmlCU6dOdV5+dCAczj0EIAABCLQO AXYTap26QlMIQAACEIAABCAAAQhUlQDGQFVxkhgEIAABCEAAAhCAAARah0DHokWL+lpHXTSFAAQg AIFKCVxwwQUuiZtuuqnSpIgPAQhAAAItTqDTz/tMKkdvb691dXUlBRf0D88rLSgYE1hJvq0YF1Yx jSDBC1YJYGK8YRUDJcErS6yGDh1q27dv75/3n4Ak0TtLrAShkt8UWCU2o7wAWOUhSfSAVSKavABY 5SHJ82CaUB4SPCAAAQhAAAIQgAAEIJANAhgD2ahnSgkBCEAAAhCAAAQgAIE8AhgDeUjwgAAEIAAB CEAAAhCAQDYIYAxko54pJQQgAAEIQAACEIAABPIIYAzkIcEDAhCAAAQgAAEIQAAC2SCAMZCNeqaU EIAABCAAAQhAAAIQyCOAMZCHBA8IQAACEIAABCAAAQhkgwDGQDbqmVJCAAIQgAAEIAABCEAgjwDG QB4SPCAAAQhAAAIQgAAEIJANAhgD2ahnSgkBCEAAAhCAAAQgAIE8AhgDeUjwgAAEIAABCEAAAhCA QDYIYAxko54pJQQgAAEIQAACEIAABPIIYAzkIcEDAhCAAAQgAAEIQAAC2SDQ0dPT01erogZpW3d3 d62Sb6t0YZW+OmEFq/QE0ktmqV2dddZZDsycOXPSAwpJZolVqNhl3cIqPTZYwSo9gfSStKvirDq7 uroKSvX29loxmaQEVAHlxq0k31aMC6ukVpTvD6t8Jkk+sEoik++fJVadnZ22ffv2sr+fs8RKLaWS 3xRY5X/WknxglUQm3x9W+UySfGCVRGa3P9OEdrPgDgIQgAAEIAABCEAAApkigDGQqeqmsBCAAAQg AAEIQAACENhNAGNgNwvuIAABCEAAAhCAAAQgkCkCnZkqLYWFAAQgAAEIQAACNSawdetWW758ua1c udI2btzo1uj09eXu17JhwwYbMWJEWZoo7YULF5YVt5J86xG3o6PDBg0a5NiMHz/eJkyYUFY5iZSe AMZAelZIQgACEIAABCAAgUQC6vCvWrXKnnjiCXvqqadswYIFziDYvHmzRY0BLeLXYv5ynNIbOnRo OVGdYVJuvpXonDbugAEDXNlkCEyfPt2OO+44O/DAA2306NEmQwFXfQLltcLq60GKEIAABCAAAQhA oKUJrF692m6++Wa7/fbb7dVXX7U1a9a4kYEdO3bkGQMtXdAaKq8Ov4yVYcOG2dixY+3BBx+0M888 0y688MKyd0CrobptkTTGQFtUI4WAAAQgAAEIQKCRBNThv/POO+2qq65yhsCWLVsaqU7L5q0RlG3b trm/tWvX2ltvvWVvvvmm7bXXXnbOOeeYRg5w1SUA0eryJDUIQAACEIAABDJI4I033rBrrrnGXnrp JcMQqF4D0JSo+fPn27e//W1bsWJF9RImpX4CGAP9KLiBAAQgAAEIQAAC5RG455577JlnnjGNEOCq S0DrDR577DGbO3dudRMmNUcAY4CGAAEIQAACEIAABCokMGfOHEYEKmRYKPqmTZvsjjvuKCRCWJkE MAbKBEc0CEAAAhCAAAQg4Ak8/fTT/pZrjQhodABXfQIsIK4+U1KEAAQgAAEIQCBjBLT3f5KbPXu2 6S/s/PagWjB75ZVXhoNy7uPi9vT0WHd3t9uhqNS4leTr40rBK664IkfPUh4KxX3ggQdMf3Fu2bJl cd74VUgAY6BCgESHAAQgAAEIQAACmtee5NShv/zyy3OCe3t73VaZaYyBaNzFixfb1KlTUxkD0bhp 8501a1aizipIoQ59TkFjHqI6hUXEI8kY0GFuuOoT6FSjKObSyCSlQdwkMvn+sMpnkuQDq3wyX/va 15znF77whZxAWOXgKPiQFVa+05KV8vpKp7yeRPErrIoz8hJpWOmNepyc/NT5LeQaFVc7IiXpXEjf NGFx6fp4xXZiKhTXpxG9lhPHp5GFuJ1dXV2+vLFXQSgmExsx8NQwVrlxK8m3FePCKqkV5fvDKpfJ o48+an/9139te+65px155JE5nzlY5bIq9JQlVjrQRwZBud/PWWKlNlPJbwqsCn3qcsPamZVOC45+ 3ny7KmYMxMX1rMqJmzbfIUOGJOqcW3OlP0VZhFNQvoVcobhx8TyruLBifp5VMbm48FaKyzShuBrE DwItRODv/u7v7IILLnDGdwupjaoQgAAEIAABCDQBAYyBJqgEVIBAJQS+/vWv21FHHVXR/M1K8idu 7QjorV+hN38K27lzZ8kKfO9737P169eXFVeZFcq3o6PD9IeDAAQgAIHWIIAx0Br1hJYQSCQgQ0BO HbBCHcfEBAhoKgLr12+wtWt7TXtqb9+hjn7yfOJt27bZoDJP5BwwcKC9smBBWWXfuHGjbUlcyNdh nUHaw4YPs9GjR9vIESPKyoNIEIAABCBQHwIYA/XhTC4QgAAEChKQIbdu3Xp7e+VKZwxs2bK17Df3 BTOqUuCmTZsTUxowYIBp3u/mQKZvj/E2cuSowFhNFCcAAhDIGIGk3YKEQTsl4epLAGOgvrzJDQI1 JcD0jJrirWniO3bssOXBW/41a9a4xb01zazGiWvqkhvZCBYpy8gZNny4Gy2ocbYkDwEItAiBQmcj LFq0qEVK0T5qYgy0T11SEggwTahF24A6z9o+sB0MgXAVaBrTmmBXuT0372kDhg01jRjgIAABCBQa GYBO/QlgDNSfOTlCoKoEol+q/lmH3Dz++ON23XXX5R0cU1UFSKxiAjIGNgZrBEpx4YW69ZqCE7zk d05v+9OuT9lVto02ZOgQwxQopYaRhQAEIFAfAhgD9eFMLhCoGYHoKZAyBtRRlDEgd//992MMOBLN /Y86zWmd6ld7j48dM8YGDR6UNlpV5LZs3uLe9utgoFIMgkC4KvmTCAQgAAEIVJdAyxgDK4K5tIsW LgwW2K0LFtUV/lHZuHGDDR9e3g4WjYr79tsr7OWXXi6rdivReVPAavwee9jkyVNs0uRJbAlYVg00 NpIfCYjT4j3veY997GMfiwvCr0YENBf28ssvr1Hqu5LVoTt7BYfMjRgxvO6fWRkto0ePsjffWh4s dF5b03KSOAQgAAEI1J5A0xsDW4Pt69TZ+U1wyuqCVxa4kyCLvUHbHizE09Z25bhGxdU2fUMGDy5H 5WD7wfLLq0WLXd1dtu+0fe3Y44+3U/7wFBtd5FTqspQkEgQyQkAjNfrTyIz+qm0YDA5GAkaOHOE6 5APL/J6rtCqUr3Y+2hBsMbojWCSMgwAEIACB1iXQ1MaAFp/dctPNdtONN9iCl18xdVyD42xs4MDC M081dF3uriqNiisDp9zFdZXovCNgtTPg+vSTT9kjjzxqS5cssY9ffJF1d3e3bqtGcwg0AQG9xNCf DINp06bZxRdfXBXDYMCAgTaoc1DwPVjeC49qoOns7DT9DQimK+2oRoKkAQEIQAACDSPQ1MbAvb+6 1779rW/ZW2++adPf/W47PnhzPX7cOBtQxBjQrhyaT1uOa1TcnjU91j2mvA54JTpvDPYB3xrM/f3d c8/Zk088Ydd9/wc2fNRIu/Cii9yPfTkMiQMBCOQS0FZ5Mgr0V6lhoJci27Zvcy9HGmUQbA9GA7YF f8VGaXMp8ASB9iYwaNAg00vMOKcXA1Hnf7uLrb2Ji9sT7NKll3blxE2b79y5cy26BaiPGy1LvZ51 fgmu+gSa1hhYGRy88/1rv2vLli61Qw471D572WV2/Akn5Lyx9h+C6CiAtufrDqa6dAzIH0HQj5fk o3E82t7eXtN83HJcJXF1yMbUqVPLydZNnapEZ32ByRj4zrevtgeCxaa33HSTe+N3/Q9/WFAfdQj0 drAcV0ncSr6MKsm3FePCKn3rrBerqGFwwQUX2D/+4z+mVlSdDXdKcbB+akSwf39HR/73XOrEShbc tYvQ2rXrbMOGDc4gKTkJIkCgTQlMnjzZXnvttdjSqUMf16mPFY54tmLcSBGq9jhp0qSqpUVCuwl0 qgNbzKWRSUqj3LjPPfusvfjCfNsZTGM59/zznSGgDrzSU4d+w/r1tjb4MRwUdEa7AuvYW4s66MYv Nt4jWBg7avRop5repsmSXtu71kYGb77VeR48eHCs2uXqrMRaMa46F+8++GD7RDA96PHHHrM3gqlC r7zySqqDj9RBLtcRNz05WLUnK/9m/e6777ZDDzus6Fs+T0HfM1uCEVCNJg4ZXL83ZYEpEJyHsMV9 l2o3oTROL230vazFxn4koxW/J9E5TW3vkskqqxOCF5ZJxkB6ekgWInDccceV1c/KapssxDIc1lns jbIAFpMJJxi+V+e73LgvzH/BDbdpHv3ZH/5w/4iAfljeDKYN3XfvvTbv9/Nc+iedfLIdfewxpq3r HgyGte771a/cG6sjjjzSzgt2Uhk1apS99uqr9tOf/MSWLH7d9pm0j/3haafZ4Ucckfdmu5LyVhK3 ElaV5BuO+wfvfW/AZpLbtUnTlh566KFwdebdh+PmBRbxqCRuI0dRym3PlZS3kriwKtIQQ8HVYpU0 6qisNEVIf1pYfFEwFU/3qt8RI0bYylWrEkcsQ2q6W30Pbg4643rxYdYRDa7ps/LWX1onHsOGDQsW PI9237eVtOdWjNsM3+1p68rLNYpzq7M6P3hx+bOf/cyNmnmWXKtHYHgwEnreeeeV3K9s9XZVKsFy Pr/lzfEoVbMy5PUWSW/NNA1lTLCXtnd6w/T4o4+5KUT68dYWosvffMv2mLCH23b0Rz/8H3sqmPuu t91aFLv33vvY7JNPsp/e/hP74X9fb25ufjCSoLdbe+61VxC+t08681e9tRsXrMl4dcGuXZsyDwQA EKgCAXX49afOvxYRV8upQ75jR/pOebXyJR0IQCCewIwZM2zWrFn2q+CFZNLagfiY+BYjoL7gzJkz 3V8xWcJLJ9C0xoAfPvfDyr5omzZusnnz5pnm3cpt2LDenvntb93agreCfa81AuA/hEuD9QZPPfmk /cGM9wY75TziDAHFkZX4fJDG28FbNYwBEdntBgQGgToZnv/uEO4gAIG0BNT519t/dQyqaQCkzR85 CECg/gT0Mu3SSy+1t99+2/VT9PISVzkBjSwedNBB9qlPfcrGjx9feYKkkEegaY2BPE3f8egc1Oka g/bG7+3pNS1+nbDnxGDf7ZE2YaLZxIkTbWXwQdQagbHBB3PatKludEE/zi88/7ybu6qGtWdwYI/i 4CAAAQhUk8APfvCDmhgAmjJZaApSNctQalq8QCiVGPLtSECf0dnBSwBtYnLzzTfb/PnzbfXq1bYx OI9D675KmV7XjnzSlknfcxoJ0LSgsWPHOkPggx/8oJ0cTAkXY1z1CbScMaC5te8NhuIWvvaqvfTS SzYq6NCf+v7327R99w2mznbYmUGDGRZsK6oP3qFHHG4nnXKK22b0Ix89JzAENtqyZcsCQ2AvO/UD 72dUoPrtiRQhkHkC1RwJ2PWjOND9KA4OFgprX/86LxEoXp/BTKUdwZROHRDpOz3FIyEBgfYkoJeM Z599tu2zzz72RDBl+cUXX3QjBdqtLDrirn5KuTvy1Wv3s2gtVaJz2rjq8Gt7eG0CM336dLet/IEH HujWf0b14bk6BFrOGNAHZ/pB0+2iSy6xJcGuN8OHDXfPGgVQA/rQh8+2acEowKBgBGFqYCBMCrb6 0g/qscEKdH1Ily9fHsyLH28HHHiADQusThwEIACBZiWgaZJdXd02ZfIkt2Oavsua0WnXN02JeP31 14Ndg9ax5WgzVhI61Y2AFsufeOKJ7o22pgxpG15NX46ODMhfLzjLcerLaCZEOa6SfOsRV3059fXE RgbBhAkTWJRdTkWXEKcljIG4eXf77ref2/lmoE7jHDzI/DZ3Wmx8WDAioB2ENIVI1rOcfkSnB3PO FE/++pGNS1fySVuOFuNaadw4fYrlqfBK8/Xl1ZdV9M1FmvyRgQAEakNAUxr33mvPsg9RrI1W+alq xEJnHuwVTL/ctjU4ByHo5OAgkGUC6mdoTWKhdYnl7PrimVZr9zOfXtprJTpXEjetfsiVR6DpjQHN /f/xrbeVVDp1qvUjWo5rVNzVq1cFc+PGlaNy/zqIciKHyyvWWlSNgwAEmoPAwOANmT9DpTk0KqyF dNUmBDgIQAACEGgdAi1gDOy0a666qiSiertd7iKTRsVNO5cuDkS1dNYmhauCvc5xEIBAkxDQEoEm nRoUT6g5pzHF64ovBCAAAQiIQNMbA/ppGdW16xThtFWmN9zRLUmbPa4W3/npOml19XJVK28w71fD eDgIQAACEIAABCAAgWwQaHpjQJ36T3/mMyXVhna00JZU5bhGxdUiIy2UKcdVS+ftgRH17f+6yl56 8YVy1CAOBCAAAQhAAAIQgECLEWh6Y2DAwAFu69BSuFaySKVRcV8PTlOeMnVqKcXsl62WzlpAfNMN N/anyw0EIAABCEAAAhCAQHsTaHpjQPhLnT4j+VLj+GpuVNxBTaCz5ia31vxkX2tcIQABCEAAAs1B QOv41q1bZ7///e/t5ZdftpUrV7pd/6Jbi2onQO2nX47r6emx7u7ucqI6XcrNtxKd08ZVP0SbwPhz Bg499NC8bVnLKjiREgm0hDGQqD0BEIAABCAAAQhAoEkIaIRdB43dfvvt9tBDD9krr7zijAHt3Bc1 BppE5aZTI3zo2EHBlvCzZs2y0047zY488siy14M2XSGbTKHONAtG08gklauSuEpTH55y0ignji9D VuPqS0y7GsnpmoZDGhnPNXolbpRI8jOsktlEQ1qR1dq1a90Wwe3YWVCZ1BFSGf3GDq1YR+gc/aQl P2eVldr6Cy+8YN/4xjfsl7/8Zarf0GSK2Q3RyIrWQuosBf09+eST9tJLL9nnPvc52zc4TLacGQxZ bZNpW1FnV1dXQVkBLCaTlICGscqN69NUpZeaRiU6NypuJayqpbOMAX80uq7FuFcrX1/Xaa/NwCqt rl4OVp5E8WsWWenE0q3B56+cH7niRBsr4Yf8VUZ9rzSqfhuVL99X6dtfq7PS1KAbb7zR7rjjjv6D UNOXHskkAqtXr7Zbb73VJk2aZF/60pdK3iCm1dtVEpck/3K+6wYkJYY/BCAAAQhAAAIQgEA6As8+ +6zddNNNGALpcJUkpZGC66+/3k3BKikiwqkIYAykwoQQBCAAAQhAAAIQSCbws5/9zLRNOK42BN54 4w37+c9/XpvEM54qxkDGGwDFhwAEIAABCECgcgK//vWvK0+EFAoS0FoMXPUJsJtQ9ZmSIgQgAAEI QAACGSOwYMGCxBJPmzbN9Bd22qhD62i08Hju3LnhoJz7uLh+m85y4laSr48rBR944IEcPUt5mD17 dqL4okWLTH9xTgu0cdUngDFQfaakCAEIQAACEIBAxghoAXGSU+f3oosuygnesGGDjRgxwhkDJ598 ck5Y+CEu7vLly23ixIllxa0kXx9X+lViDFx++eXhIubca23Addddl+PnH7Q4Fld9AhgD1WdKihCA AAQgAAEIZIyA3tInOb3dj74N97u+FIqn9OLiasvNqVOnOmMgKc+kuGnzVfpJOhfKM01YNN1wnEJG xo4dO8Ki3FeJAGsGqgSSZCAAAQhAAAIQgAAEINBqBDAGWq3G0BcCEIAABCAAAQhAAAJVIoAxUCWQ JAMBCEAAAhCAAAQgAIFWI4Ax0Go1hr4QgAAEIAABCEAAAhCoEgGMgSqBJBkIQAACEIAABCAAAQi0 GgF2E2q1GkNfCEAAAhCAAAQg0MIErrzyykTtC525kBiJgIoIYAxUhI/IEIAABCAAAQhAAAKlELji iitKEUe2xgQ6tVdtMdfT01NMJDE8Tfpxkbds2eL2z9X+u+WkUYnOjYpbTjk9u2rorJMFdaqhnK5p 9KlGvr4MpVzT6JaUXqN0blS+sEpqCfn+jWK1evVq2xR85nbu3JmvVIv7qEyrVq2yjcEBSwMG7JqZ 2qjPQqPybVS7alR5K8m3XVmJSVzZ5F/snIGkuEqv3Lhp8tV5BEk6N/JrKU6nYvqUE8enKVblulaJ 26lDJQo5fzhFIZmkMMEvln5S3CFDhlhHR4f7KzWNSnRuVNxKWFVL523bttnQoUNdlehajHu18k1q A0n+zcAqSbckf1glkcn3zyIrnUK6Mugwr1+/oe0MAhkA48aNs3Fjx1pnZ6c1qn4blS/fV/mf8SSf dmbV3d2d95vq22SxDn1cXM+qnLhp8+3q6krUOakO6+FfrG8S1cGzivqnefas0shGZVopLguIo7XH MwQgAAEIQAACEIAABDJCAGMgIxVNMSEAAQhAAAIQgAAEIBAlgDEQJcIzBCAAAQhAAAIQgAAEMkKA 3YQyUtEUEwIQgAAEIACB2hEYOHCg7dixIzaDRYsW2QMPPJATtiFYVK/1QsXm/cfFXb58uS1cuLCs uGnz1Vz7JJ1zClLHBzHGVZ8AxkD1mZIiBCAAAQhAAAIZI6CFvto5K86pU61OfdhpBz8tqi9mDMTF 1Y5/2uijnLiV5OvjhstRz/sxY8bUM7vM5IUxkJmqpqAQgAAEIAABCNSKwKGHHmpJB2bJEIgaA2n1 aMW4actWqtzBBx9cahTkUxBgzUAKSIhAAAIQgAAEIACBQgTOOOMMtx16IRnCKiNw+umnV5YAsWMJ YAzEYsETAhCAAAQgAAEIpCegjuq+++6bPgKSJRHQ+QIyuHDVJ4AxUH2mpAgBCEAAAhCAQMYIHHDA AfbJT37SRo8enbGS1764I0eOtEsuucTEGFd9AhgD1WdKihCAAAQgAAEIZIyAFvT+yZ/8iV144YU2 ceLEjJW+dsXdY4897GMf+5jjKsa46hNgAXH1mZIiBOpO4K677rI5c+bYtm3b7OMf/7jNmjWr7jqQ IQQgAIGsE5g8ebJddtllNmXKFLv//vvthRdesLfffts2bdpkO3fuzDqeVOUfMGCADRs2zGQEHHTQ QTZ79mw77bTTHNOOjo5UaSBUGgGMgdJ4IQ2BpiOgNybanu4jH/mIvfLKK/ahD33Ivvvd79p5553X dLqiEAQgAIF2JqB98Pfbbz+79NJL3UuZ+fPn9xsD0W1A/fag5fDo6ekxbWVajqsk33rElTGgEYAJ EyY4Y+CQQw4xbWnKGQPl1Ha6OBgD6TghBYGmJKAfGr19uvrqq+2cc85xOmpru1tvvRVjoClrDKUg AIF2J6C315rjfvzxx7u/pPL29vZaV1dXUnBBfx0IpgW15bhK8m1k3HLKSpx0BDpVscVcGpmkNCqJ qzRlSZeTRjlxfBmyGldTTGR9y+mahkMaGc81eiVulEjycxKrffbZx40GKKaX0fCq9mL2z/6anHpy CHGT2URDKmG1du1aN40g+uYwmkcrPqtMmiKhMvo3e5WwIm76VgArWCURoG0kkcn3zwKrzmJWqSAU k8lHt8tHw1jlxvVpysIuNY1KdG5U3EpYVUtnGQOabiKnazHu1crX13XaazOwSqurl6s1K51Qecst t9iSJUvc0PFFF13k6g9WvgaKXxvJSruPbA0+f+04H1ZlkoGqMup7pdafhaSablS+jWxXxb7DYbWL QKPaRiX50q6SWm++P6zymUR92E0oSoRnCLQoAb2B3bFjh1ukpjexOAhAAAIQgAAEIFCMAMZAMUKE Q6AFCGi3hW9/+9umXYWOOuoo+1//63+1gNaoCAEIQAACEIBAowlgDDS6BsgfAhUQuPLKK+3UU0/N SWH48OG2bNmyHD8eIAABCEAAAhCAQBwBdhOKo4IfBFqEgLYTvfbaa92owLnnnmvaXeiee+6xyy+/ 3JXg8ccft+uuu67/uUWKhZqeQN+uTRT8I1cIQKA1CGzdutWWL19uK1eutI0bN7pNOaIbBGzYsMFG jBhRVoGU9sKFC8uKW0m+9YirdUaDBg1ybMaPH++2GC2roERKTQBjIDUqBCHQfAQOP/xw+853vuM6 +1dccYVboKkpQhdffHG/stp61BsH/Z7ctASBHTt3mPb11g9jK7jNmze5dSutoCs6QqAWBNThX7Vq lT3xxBP21FNP2YIFC5xBoM9x1BjQrn1+045Sdalkv/9K8q1HXH/OgAyB6dOn23HHHWcHHnig24Sg HTdZKLXuayGPMVALqqQJgToSOOOMM0x/ce4973mPO8Y9Lgy/5iewZctWWxl0LDqCQ3gGBwaBfiSb 0elkVem6avVq0xtRHASySmB18Bm4+eab7fbbb7dXX33V1qxZ40YGtLlD1BjIKqNi5VaHX0aSdiEb O3asPfjgg3bmmWfahRdeWHSXw2JpEx5PAGMgngu+ZRBYtGiR6U+LWXEQgEDlBNSxfvvtle5tu9aC DBwwsPJEq5xCMJPJ6afpA9rCT28OcRDIIgF1+O+880676qqrnCGwZcuWLGKouMwymrTVuf50Pslb b71lb775pu21117ucM1mfSlSccEbmEDzGwNBo8DVkYDHHVjmaZw6/9dff71pn3v9aXoKxkAacshA IB0Bda5XrHg7nTBSEIBAwwi88cYbds0119hLL73EdLkq1oKmRGk9nHbMmzlzpu25555VTJ2kRKBp jYEhQ4a4A3j0Q6i3Y4MHD6bG6kBg48YNwZSEDhP/JOcNgHvvvdcefvjhJDH8IQABCEAAApkhoM0b nnnmGQyBGtS4+oKPPfaYzZ07l6mvNeDbtMbA5MmT3ZwxDbPNf36+HXnUkTUoPkmGCWjXg6VL33CG l/iHnTcA/AhAOIx7CECgdQhoPu7AAQNMg4Ca68885tapOzRtbgJz5swJ1s4wNahWtaTDNO+44w6M gRoAblpj4JjjjrXusWNM81C///3v25e+9EXbM5gvhqsNgXXr1tkNP/yRrQzmJ0+YOMFOPPFE8waA tqbUfRonY+Gkk04qKiorn10UimJyArBKx0lSrcpqv/32s6/9y7+kL2gZkkOHDrWu0aNt1KhR/bsT bd221Xp719q6dWvdAuAykiUKBCDwDoGnn34aFjUmoNEBXPUJNK0xsO+++9rZwR7q373mO3bPL+62 kcOH2fHBzijjx+9hAwcW3lGjHvvgxlVFJflqz+BlS5fGJVvUr5J8ZQSoA/Xcb5+122691Y0KnDhr lh1/wvG2JlgMKJfWECiqKAIQgEAsgcWLF8f6V8tzRLD4WLtyjBkzJtihY2jwHbprIfL2YMHj8GDH jiHBNEztgrIpmJuLgwAEyiOg3/Ekp7V00fV0fntQjc7pAMkkFxdXi/W7u7vdyF6pcSvJ18eVrtrO ulxXKG6hGQgcqFku8cLxmtYY0Fvjj3/8E7YyWDh3989/brfdcqs9+sijgTEwvv+HLKlolbwdbFTc 8AcsqVxJ/pXorPUY6zest8WvLbKBgzptdvBW/+JLLrGu4EtGf9qfXn8yCLRQuNgogb60fvCDHySp 2u/f29tb9hZh6jhNnTq1P61SbirJtxXjwip962gkKx08pC1Ea+HU8R8TjLLuscd40+hA2HUGYRop kMzOvmB70OUr3NShsAz3EIBAOgL6LU5y+m2Mnvfif1PSGAPRuP77qpy4afOdFbwYjObr46qchTr0 SRy8fzRd76+ryiSDIM6xdXEclcr9OlWxxVwamaQ0Kok7YuQI+8RFFzrr94nf/MaWvP66ra7RD2aS /vXy1w/xgI7CIx610kXbdO23//52zPHH2gdOP90mT5kSTB3IbRd6o3jZZZe5v9eDerjhhhvcn+7D Th/UaNxwePg+rVw4jr8nridR/Aqr4oy8RKNYafs8zYfVj2C1nUYCukZ35RkC4Xy0n3d3V1ewJ3qP O+QsHFbpvcqksqmMfkSiUZzJN31twqq6rPTCL46p/Ip97hsVV+sfknROTydeMi5dL1ls3UWhuD6N 6LWcOD6NLMTt7Ap+AAo5QSgmkxRfw1jlxvX5HhacsDplylSbEWwntXDha65h7gyGtgs5NaRCu+E0 Y1xf3kK6JYVVVt6tNn6PPWxSsGD4qGCR9sQUW3Yddthh9pWvfMX+9m//1h2oEh4x0K5Paeq8kvJW o10lsSzkX4nOjYoLq0I1mhvWSFajg7n8W4M9tWtxuubIESP71wjklnj3k/LVZ3dkMEKhjkc1ndKW saEyasS3UZ+FRuXbyHaV5rs4rq5hFUcl3i8tK7dmJ9Lf8nGLGQNxcX27Kidu2nzVj4q2IR83nkZ6 32i64ZjF+m+F4obT8feelX8u5VpJeVspbtNOEwpXVld3l806abbNOHGmO8lPO2AUcnoDpR+eclyj 4i5ZssSiO/ik1b8SndetXRcszN6zaGchSZdp06blTCVifUESKfwh0BgCAzsHBicXdxTN3O0yFMji IAABCEAgWwRawhjwVaK3Smk6+fpRK9Vy9Hk0Kq4sSC0GKsdVqvOgQYPKyTYvjgwD/eEgAIHmIbB9 2/ZU6wB27tSpn8lznpunRGgCAQhAAALVJNCYSerVLAFpQQACEIBAIoH169e7gxsLTSdQ2NatW9zI a2JCBEAAAhCAQFsSaKmRgbasAQoFAQhAICCghfy1cH7x4eBg/q+2EY1zGzdutJ6e3podmKSyaQQT BwEIQEAEknYLUph2SsLVlwDGQH15kxsEIACBPALqLA8NOuu1MAh2BGusVge7BHUEeYwNdgXT4jx/ 4N+2YNHy5s1b3BkDOlek0OhBntIpPXzZMAZSAkMMAhkgUOhsBNYe1r8BYAzUnzk5QgACEMghoA7z 8OBgsBEjhtuOYLc0/VXTaWvPFcGZLbpqC9EhQ3adN7B58yZ3uOC6devd4YPVzFNp6YBIjUZoN6Fa GDrV1pf0IACB+hAoNDJQHw3IJUwAYyBMg3sIQAACDSKgPfj33mtv277tddsQTNvRrmla1FuaS5bX dCH9rVxZm8PNzPw0oD7X8ddIgAycSZP26T9foLSyIA0BCEAAAvUggDFQD8rkAQEIQKAIAXWeR48e Zfvvv587jXjp0mXBPP41RWLlBvdZX9AlD/57ZytRP+1HqxE0TUjO+Wn+fmA36G39ruk7wUPwv5/W 3zFgoPWpbx86BE3bk3bYAOe1c+cO99Zf8rvi7/KXKTKgoy/YGa3LJuwxwcaM6XajArtklDsOAhCA AASajQDGQLPVCPpAAAKZJaBOsw4Y2nPiRFu27E2b/+J827xpS2oe6oy79/P+n1Bnvr+nH0rNiYWe +2+9VdDv8U667zzn5iPPICV5Bm7Y8CF2YnBI5IQJe7i1CRgCu7jwLwQgAIFmJYAx0Kw1g14QgEAm CehtvU4DllGgN/Fr161rKQ5Dh060IYH+1Tq/pKUKj7IQgAAEWpBAbfaya0EQqAwBCECgmQiMGDEi mGYzpplUSqWLdJbuOAhAAAIQaA0CjAy0Rj2hJQQgkDECY4ITyQ86aHqw88/gxJJra9By38BXElfn EmhxcJzbf7/9TLrjIJA1Avos6nMV5+J2z9GCfo0A+rU9cfHkFxe3J9gKuDv4nJUTN22+c+fOtegW oD5ukq619tfWyLjqE8AYqD5TUoQABCBQMYHx48fZjHHvsfe+54TEtNauXRssOh6dGF4ooJK4r7/+ uk2ZMiU2ea0RYJ1ALBo825zA5MmT7bXXXostpTr0cZ36WOGIZyvGjRShao+TJk2qWloktJtAR2Bd vrPsa7dnte685Vqt9No5HVilr11YwSo9gfSStCtYpSeQXpJ2lR1Wl156qd14443pC4xkyQQuuOAC u/rqq0uKx2ewOK7OruAAmkKut7fXiskkxVcFlBu3knxbMS6sklpRvj+s8pkk+cAqiUy+P6zymST5 wCqJTL4/rPKZJPm0Oqvzzz/ffvazn9mGDRuSioh/BQQ0NfG8884ruV/Z6u2qVGTl9IFZQFwqZeQh AAEIQAACEIBAhMCMGTNs1qxZZa/jiSTHY4hAZ2enzQy2LNYfrvoEMAaqz5QUIQABCEAAAhDIGIFx 48aZpgodeeSR7rC9jBW/ZsUdNmyYHXbYYfapT33Kxo8fX7N8spwwC4izXPuUHQIQgAAEIACBqhDQ GSGzZ8+2NWvW2M0332zz58+31atXm3bf2r59e9Gdf6qiRBskog0INBKgaUFjx44NdlU7yD74wQ/a ySef7E5Nb4MiNl0RMAaarkpQCAIQgAAEIACBViQwcuRIO/vss22fffaxJ554wl588UV7++23TVty 7ty5M6dIMhDU6S3HVbLFp4yUFStW5GS75557uk53jmfMQyU6p40ro0pbru6xxx42ffp0O/744+3A Aw+0UaNGxWiEVzUIlNcKq5EzaUAAAhCAAAQgAIE2I6Dtfk888UTXuZYhoAXFOn8geiaA/Ms9oG/5 8uU2ceLEssjdcccd9o1vfCMn7he+8AU3vSnHM+ahEp3TxpUxICNJbGQQTJgwgUXZMXVRTS+MgWrS JC0IQAACEIAABDJPQAeQ7b333u4vCUY5u774tBYvXmxTp071jyVdjzrqKPvpT39qixYtcvGmTZtm l112Wao0KtG5kriplEOobAIsIC4bHREhAAEIQAACEIBA6xHQ2gbvZAzgsk0AYyDb9U/pIQABCEAA AhDIGAFtgerd5Zdf7m+5ZpQAxkBGK55iQwACEIAABCCQTQIXX3yxK7hGBcKjBNmkQakxBmgDEIAA BCAAAQhAIGMEZBAwRShjlZ5QXBYQJ4DBGwIQgAAEIAABCLQrAU0Vuuiii9q1eJSrBAIYAyXAQhQC EIAABCAAAQi0AwE/VagdykIZKiPANKHK+BEbAhCAAAQgAAEIQAACLUugo6enp69a2m/atMm++c1v uuR0gEWQtnV3d/cn/7Wvfc3df/azn7Vhw4b1+xe7URpz5syxmTNn2q9+9Sv7m7/5G3cQxZe//GX7 wAc+4PIplkaa8O9973v2/PPP29e//vU8ca+7AvzBIdrjV/mPGTMmTz7OQ3Iqx4wZM/KCPauHH37Y Hbut48yr6VQmHeCh0xH1p5P8xHPw4MHVzKYuaXlWdcmsxTOBVfoKrCYrfV/oc67PWNj57xF9PxZz hb4vvvrVr5q+K/R9Ug1X6LvPp6+TVPW3bNky23///e3YY4+1cePGueCwPuF7HzfL12q2q3bnCKv0 NQwrWKUnUFyys6urq6BUKYdEKK21a9fabbfdZv/8z//sOunh9L///e/bueeeazr2upgL5/vrX//a Ojo6TGn9//bOBdiq6Y/jWzJiGOYv0UTjXVGhhDKZ6cXoQUWiPEYlPTxKkyFpEJMR4zUVMh6lUCMj k9IUyjuK0mR6MZOIJoYJk1f9z2fpd+66+6x9zr733LqO8/3N3Hv2Xq+91mfvvfb6rfVba61evTpq 27ZtNHPmzOiGG26I8POvQbp+3ELX8f1XrVrl0o6nR5gPPvgg8pfiwu25556LHnnkkYhykadC10WJ oEEeSp8XG3f8Fy9eHAzDNUNS6LrEufvuu6M777wzQmFjR0Skd+/e0ZVXXhlNmzbNnVf131VXXRUN HDgwh0uadNLkOSkdY5Xkn8+9mOuWYlyxyvc0VParSVbUF+edd17Oe4zyvWTJkkruSc9Vvvpi//33 dzt0UoJQfVK5ZOEz/7rUfR07dkxMq2/fvtG6deuiFi1auF1Ply5dGuE2a9asqE+fPpHlh7xQ7lDZ LRf+dc0t9MuGSNdcc0301ltvZb3Txs1G8A5qK25NPldecQoe1lZ5i7muWBW8rdkAYpVFUfBArAoi imp8zsCAAQOiSZMmRZ9//nnEltwmnLN9Nv4IDd4vv/wy2rlzp+tl6ty5s3PnQ4mcdtpprgE7bty4 iK2pEfNj9jsfo0svvTTbS+8CZP7RU/b++++7bcBPPfXUiD/E4v7www9OoSBdX1BiPvzwQ6dg+O7+ Mctv+UtwsTZv165do9dee80pA4T97bffonnz5kVr1qyJmjVrFnXv3j068MADs8mg1Lz99tvu3E8L Nl999ZVTeiywH478r127Nho8eLB5u9+5c+e6fPfq1Stq06aNS9tP1w+Mu6/QtGrVKrrwwgvdaI6N 4PDh/fjjj6OTTz45at26ddSwYUOXhOWFE/JCA+CTTz5x99P84tdNcvfzpGMRKGcCKOevvvqqe/dP OeWUqFu3bomjpuwYumHDhuiEE07IQUa98/rrr7uRTeqdHj16uHRQKKgrEd5bzuNrilvdN2bMmJx0 caDRT/p0vNgoKLufUu9RD8TF6mtzt7xt3LgxOvbYY10dZAqM1cvUP5Rv5MiR7rtheSUNC+PXXZa2 fkVABERABIon8E8ru/h0sinQwOzUqZPrLc86Zg4YhsYd/7vuuiui8f/NN99E3333XdSlSxfnRng+ VvRg89GgUY3QyMTdeog2b97sjnHzG6D9+vWLGH63sB06dMgOo/MB5FqjRo3KpuMS3/2Pnryjjz46 +KH1w/nHNOz5MNOIR7Zt2+bMAmbPnu3ywKgBZgLWE29xaUTfdNNNdup+X3jhBTfKQN7JtwnHgwYN iqZMmRI9/vjjTjGyLcRnzJgRXXTRRU6peuCBB5y/H9fSSPplmB+x9FCu7r///ogP/R133BE1atQo oscQ4YNM4/6KK65wv9yjL774wh0TjgbDO++848LaP/JSt25dO9WvCJQ9AeoMky1btrj64dlnn3X1 xZNPPunOqUfiQl1y++23R9R9K1eurOS9detWF49eeuoPq3csHepIesYYyQyJ1X0nnXRSyNt13NAJ YYqABbr++uvtsNIv9QT1A0Le2rdv70YQUHzI2/nnn+/qSvzJG/XItddeGy1fvtyNTFCvUQ7SwW3h woXunPASERABERCBmiewR1pq9P7zN2LEiGyOacw+88wz7pzGsg0v40DvM3MN/B6rhx56KGfJKz4w /PFB5dd6jEiD3uz58+c7O9qjjjrKfVRouGICQ+88Qs8ToxH+B9l5ZP4xKnDWWWfZaapfzIMYiaBs COljQ0vZEMrTvHnziPIOGzbMufEP05zRo0c7+9umTZs6d8yeHnvssWwY/wAFyuKjJFHuYzKjI2PH jo2wzx0yZEi2vH68+DEfWJMff/wxeuKJJ6LjjjvOjcLw0WY0gB5FRgQQ7gt2yS1btnTn69evdx9m wpEW5aLBf+KJJ7oykX8+/AimYmeeeaZrpDgH/ROBMiPAe+rXUfHi0/jnvfNNHemQoP6w993iTJ06 NSK8zTfq2bOnebn3sH79+sF6h7oBobOAnvmQ5Kv7aKgzmsq7nFb8eoZ6IF4nck7dMXToUJckysiy ZcvcMaubLFq0KPutoI669957015a4URABERABKpBYI8oA/TQY+tJpY5NOcPJCO4Mc/NxwYyGEQKT r7/+2vV6cc7HgYZ1VYTeMnrh+fj8/vvvzoaVXnv/Y0zDO6QIcJ2PPvooGj58eN5LYlPrCyMaTMxl EjFCw5k8+OViGJ0PvgkfyiOOOMI1nqdPn+4+dCtWrHATeemZpzcsLv5QPEqAjUTQo09j3oR5C/Sq JQkTr+khxKaTPxoejAQgDRo0cAoKozGYWTG0z7X8UQ0mDqIIhAQFB9MuzJ0oH72Q3G+JCJQrAb9R HGKA2R/vrC+c0zj3lQGUcBY2oCPAhNE43mGEOi5U7/AumowfP94Oc37z1X305iP77rtvTrw0DtRn 8bxRZ/n1CqaKJtQ5fp3NYgcSERABERCBPUtgjygDZBnbT3rNUQZefPFFd447igDzBOIfSsKjECA0 5vMJk9UQPw3S5dz/I0waO1Ma13yYzz77bKIkCj14DGsjjGQwemFzHXD79ddfXdmSFA7CmDBqQSMf cxx/9ML8/d/DDz/cP6107M/LoHGfT+gdNGncuLEzA9qxY4dzomwoCygk9erVc+ZPxtni5CsXczNg Ta8mZcOkC9MwiQiUKwHqCqsvjIHfUYBijn2/L7zD9Mb7YiuL/e9//8s6++/99u3bo7///juno8N/ X/3jbCKZg0J1n9Up1I+MPlRVQnmjE8Wvu21FolDaLKggEQEREAER2LME9pgycN1117lea3qAMIHB PAfBpISecibL+T3eVsxQz7j52S+N1bhg70rvF3b1LJtpE9Ti4ULnjESgCPBRst62UDjfjeVRMUvi mta7zsgDk/VsboMfPn7Mahs2tA+fJHveeLz4Ofb9psQwMlFI4o0TUwbojWNugt8jidmP/9H2j0PX wTSMOEwg5N4y2iARAREIE6AOfO+99yp5UheZKZB5EA6hDrWRuU2bNpm3q0uZr4NCH5dC76xf98Xj ck5HBPUCHRbxfC1YsMB1ZuQz48FMMl4nUsemrZ+lDITuitxEQAREoGYJVFIG6F2PCytN/PXXX5Wc 8/XkWECGtOktZnIc9qb0ZFn6THql1xg3TEpYTYOhcUx88gnxbdiaY/KGcIydOz1nNEaZ7IYJTf/+ /d2EYUyWQmL5QQHho2Vppi0vowMoIfR08ccQP9dnLgFlZPidCcs0sM1kxvJMfmg8YzsLH/vI+/m0 sJZP/P7880/HADcm7aKQkPdffvklZ2KhnxbHpOenZW6Ul958RjkwrcIEgaVI2QuCSY7ML4gLPY18 0LH1ZaIiSgYroTAShHKDsmTXSvO8kL6Fj1+ruueh9GCQ9v7GrwuHeNx4GM5rurxpJ2GHykuvctzU Im3+SrG8xdzfEKti7m/ofcP8jneYe8X8GkbrMIm8+uqrXf1H43zChAmVLkuDmPqBDgPeL8yGLB3u EelgrsicLExu2AsAt5deeskt5VwpMe+EuH7d53lVOmSZaBT7P/74I7r44ovdIhAPP/ywW+CBupaO DUwLrVzU0XZsZbS8UScSZ86cOQXnITDaAQ9YkX67du1cHRZ/B//tz3MlmHlOQu9vMc9zKb6/oXfw 335/i6mfi7m/IVahxystv9DzF0qvtspbis9zMfd3b5e3kjJAgzIumL7El4pL+3DRO0ylz6QwP20m /06cONF92Phw0JBnopj1AsVNe+ycNPggkR+O+SAy6dfS5qPFahUsbUqvO0pAkiJAOS0eHygaspxX pbyMcnA9rstKSazBjRkAH0o+2igKLD3KB5q06cEnzyYoA0wCtonV5k7DGoENcSyfuPGBhAFubGDE PAdWUOJa7LvAyhshIU3S89MinJWX9c+5L9wrbP+N2+TJk51JVMjM4PLLL3cNgtNPP91tQER6KCjY N/v5Tvu8xPNGesVIKD0rr59u2vyF4vrp2HHa9EL5szT8X1v21XcLHYfS43mLu6fNXymWN5TntOUN sQpxTpte6H3j3eUd5p7QWcI7h7kh7x0978wjsvrOfskDixEQFoWAusrmR1Fe3lf8UQioU1AcMM2k /mVkgHRCIwTE9eu+UFlxY3NFRiKo1xgJxYypSZMmrqODEWATK1eojJY36kyObUKyX0ZLx37pmLjg ggtc/cnqazAr5v6G4tq1/N+09zf+XvlpVOc4lF4oz2nzF4obylfa9EL5C6Wn+ipEpaK94fuG7lHa +1HT9dXeuL/FlDcU12dpx2n5qbxG7J/ffTIfiewSM5icxAWbT8xufOHjkEbozaGXuZCE0gsNJYfy F0qbyijNMDTpWfGtsVtMedkQLc4qlD8rL0oAH1fiYU5l7hanUHn5kCMs1Ud5GYWhsZBkphRKr6bL SyOFXk6WCjSJlwv3Yu4v8UNp4u7L3iivfz07DuWtmPJW5Xm2PNgvy/fG38FQ/iy8/1vV59mPW1vl LeZ5rs36ilFSq4N8jv5xmueZ+oxJuGmEvV+orwpdN/S8kJe4eyh/fj7IG9cq5nku5v7W1vMMgzgr n4sdh/iVYnmLub+qr9I9KzwztVlfpW1f2bNtv7X1PFenvrI8F/M811Z5q/P9rWsF5jekUe23336V Ng/zwxc6Zl3qUJqF4iX5p02LHqo0EkqvmPJipuRP7EvKAxOlmWeAeQC9ZP6mZH6cUP58/88++8yZ FGDSc+6557qeOnrvkiSUXk2VFxMvRoHY+OzWW29NykJe91D+QhHSDmeG0qup8obyVVW3UP5CaRTz PNN7lPY68WunfZ7j8ZLO0+ajmPIWc39rs74q1CCHaYhfMeUlvTT1VdL9jLuH8hcPw3lt3d/aep5V X4WegvDzrPoqzCrkWpv1VSg/cbdQfVBMfVVb72+51FeVlIG4bTE3FxAh9/iND53TyK1u3FB6adNC K0ojofSKKS9mTqE043lh0zFelKeeesr16sf97bxQWjS6GWZngh6Th9mBNN9eCaH0aqq8aN7Mk8A8 qroSyl8orbQf11B6NVXeUL6q6hbKXyiNYp7nYt7BtM9zKM8ht71R3mLubzGsSrG85XZ/a6u8qq9C b0cU/FYW8w7W1v0tpn5WfRV+NkKu5XZ/93Z5KykDoRsgt5ongP2+zQsoJnV69TARwj4/zbBdMdcq FNffMK5QWPmLgAiIgAiIgAiIgAj8OwjU+XdkQ7kQAREQAREQAREQAREQARHY2wT2ySzBmZ1AvLcv ruuJgAiIgAiIgAiIQFoCNi9uxIgRaaPUSrjnn3/erbyVtA/H5s2bo5dfftktSx5aWjxNppmUz6p+ WAfUBA9WNmNhElYjqynZE2la3lgRCLNrNrhlvgn7orAvC5unSqpIIPMw5ZXMLpl5/fN5omhUV4q5 binGFav0T4pYiVUSgWLefT1XSVRz3cUql0mSi1glkcl1T8MqY2K7K2OWmhO5mHd/T8TNrKq3K7O6 X04+zQH/zA7fuzLLCptTqt8VK1bsggGsdu7c6Y4zKwimimuBksqb2ZF816effmrBgr9JcS1wPE9+ moXiWhqh31DczLxJOrN3ZZY43gWDkSNH7sosX7wLtr6kea788P5x6Lq+f77jUoqrOQNVVJ4UXARE QAREQARE4N9BgMUrli9fHq1Zs8bNxWN5axM2M800RqN169ZFl112mdsfA78lS5a4ILbPBTuBM2HT ztkjZN68eW7PnGbNmkU9evRwm3D6cVmal42h2AMjLmw2xbXHjBkT93LnbBg2d+5ct7M3+xDRe84S lkimAek2ELW84JZpzPLjwhCPScv04Ddu3Ni5848NBCkX+46wmIcvuOOPH+na6mWsSMhSxGz8yvK3 HJvgF58czdxENpRFyBPxyC/XI22Ea/G3cuXKSuk5z8w/wuNP+hmlJsvc4rL/Cn6EIa+ECUmmEe6W Umefp9tuu80FISz36sEHH3SjBd27d3fuixcvjljF0TbD5RoI1zCBD/GbNm3qNsM1d//ZYPSBhVrY S4nngntXr149F9TSWrVqlXsuSm0eZR0rsH5FQAREQAREQAREoFQIsMs2Ddhp06ZF7FHAZpmY5yCZ XmLXWHvjjTeiDRs2uMYbjTiERh+NSROO2dQPYc8fFIpZs2a5MGwsyjnuCOFYIQp3Pw3nufsfO2dn ev3dZqC+ux1b45t0WRacPYJMSLNDhw526n4xjSIMSgT7CKGEcA2E8OwvhD/HKCdsfmp+bAqKsoEf ext17NjRNfI5x7SIP/xp3JMG3BAa5FzL/nr27JlN95VXXnGNfxQt0iG/Zr5Foxq3zAhDTpooAuSH fBCGBjP5QTjnvvTq1cstu845x+QpJCg07H4+c+ZMpwhaGPKC2ZApAv369Yvuu+8+lz5l4Xrz5893 wTknv/3794/efPNNt9T71KlTLSkXB0UDU6Tvv/8++Fxs27bNhevcubN7Lh599NFs/FI60MhAKd0t 5VUEREAEREAERMARoBeWBiUNdHqx2YgLO3J6gek5nzRpktuJm8AHtOfbAAAJu0lEQVTHH398hJ0+ NuX5ZPbs2RFr2qMMIKTfvHnzCPdhw4Y5N3qeGW2gQRrvPScAowJJy3zTyEWRoNFOfHYfZ68gs/mn wRwXRg0IS882DWZ6oS28hbVG8zEZ5YgGKfnmOqRHwxzh2jTGGfUYMmSIc2NkhYY/AkcT8mVC2qRL Ix4hL7ihICD4oZCQJ65LeYhPXmlsm0yZMsWFZY8lhPzAmrQypj3OjREGlBOEvJOunxfnsfsf10Ih aNeunZs30bZtW6dAtGzZ0oVYtmxZtGDBggilsUuXLs5t0KBB7l6yuznCfVy4cKHbuR2lkjTHjh3r /FB2GAEib6RRv3797HMxbty47HMBywMOOMApE+vXr3dxS+2flIFSu2PKrwiIgAiIgAiIQMTkXBqm /NET36lTp+xuz+PHj3cNQHq8mzRpEt1yyy2JG3z6KGm80mNvvev49enTxzXATRmgAco1kwRFZPjw 4UFvGt7kyRrSNDTpjee6NJ7xq6r4JkWY+1jj3r8OaZJnrksD14Rr5hMUCfJHLzpKCcoPaaCQGKM0 eabhj8kNPei+YLKDQoKQP9/EyUyn/PD+McoRjXl6+hctWuQa/ig0jBA9/fTTEcriOeec40x7UBQR nhP8TLZs2eIUAc65zygeKAGkzURqRhZQArg/pGVlJjwTlbdu3cqhMzMzhcM5lNi/OiWWX2VXBERA BERABERABByB1atXu9/Jkye7Xn96khEUA0w/GCUYNWqU87NGpwuQ8G/79u1RZhKs67WmAcsfgo14 GqEhuXbtWtdTHQpvvfXsIExjt06dOtke8FD4Qm40oI/J9MyHhEZ6qEG9adMmF5y4viIRT4OywJER AZsTQBhGAGg0M4eA+CggtSWUoWvXrq5XHtMpM6niXmPOZffP7iW/AwYMyGaX+Cb07jNywCgA4RjJ YLUmhBGn0HPhx63JHd0t3b31q5GBvUVa1xEBERABERABEahRApj98EcDlQm79AybyQm93vzRsMPU Bz8zdWEyqAk9+SaEW7p0qesJN7eq/NIgZanPww47LCcaNv+YotDLTr7oZadBTe9769atnXlMvGFP 3umVjs8j8BOPmxbZJqQ04G2UwMJz3qJFCzt1ikj2xDsgr717944wh7FRDLzJD2ZIc+bMybqb2Y8X PeeQRjf5iufVGOREKOCAKRJcMN/yWaMYoBAybyCzslB0zz33OLMf7kkaYaI5Jlws90qeGSVCeMbe fffdiMnIcYEJu2cffPDBca+SOa9TMjlVRkVABERABERABERgNwFMcfr27evMTBgBoGe3TZs2zvfm m2+OZsyY4RrcmIvgd8YZZzg/lAUUACYFY6+eWa4zy7Rbt26ukWkTSTFtQUEwJSIbMOEg33wBGqn0 oqMI+EKjHTt38oIyQKPZJuTS0I6b4dCAZsUiGtY0RFm5x4QGrPXiU04mK9NoRlBCWI0I0xckHtc5 7v4HP9KJz03Am/xZnkgbBQOzIb+h7x9butjWw8DyQ3lJh1GGqsrAgQOdiQ6/KCYIZSW/O3bscCY8 mHNh4sO9s7kRPC+jR49OvBxKF6NNjA74pl4oGeQb5QNBMfCfi4MOOkjKQCJVeYiACIiACIiACIjA HiDABOEjjzzS2ZmzKg8rCtlqOBMmTHATQ2nQXnLJJVGrVq2yjTtsyun5btCggVMEhg4dms0dDfXp 06e7hjkN68GDB7v4xEkjjAwkTR6m0cwE1bhwHRqxNOo5ZgItygAmPjSyGdEwUxwa+Jir0GNNA5fy mR/pEueY3WZD2L1jKkV80qU3nXOWJOU8Hpd4uKEkYCLEHzzsj4Yy8Wh805DnWjTuaWyzzCar/+B/ 4403Ort9wlia5K19+/bOnIf8ENdGSThGMDmyY879uJz70qhRIzeZF/MtrtewYcOIZUZRBkmXDcho oGP3v3HjRlcuRjgo28SJE/2kKh2Tf0yFvv322+yEcQKwChH3hJWJCJPZ28DNMeC54Bxl00ZkKiVY Iif7ZMD8YxCXkOHqDuGQHA+q/5AmXCLoXMx1SzGuWAUfg6CjWAWxBB3FKogl6ChWQSxBR7EKYgk6 ilUQS9Bxb7Oi+UNDLqnNYP7BzO529ONac4o004gfN014P8zeZmXXLibPtRW3plmleS7gVVvlrc51 69oN1q8IiIAIiIAIiIAIlAuBQo32Qv5xTlUNH4+v89Ig8F+8z5ozUBrPnnIpAiIgAiIgAiIgAiIg AjVOQMpAjSNVgiIgAiIgAiIgAiIgAiJQGgSkDJTGfVIuRUAEREAEREAEREAERKDGCeyTWf4p7wTi Yq7I0lL+zPBi0vqvxxWr9HdYrMQqPYH0IfVciVV6AulD6rkSq/QE0ofUcyVW6QkUDlm30FJI1ZmV bJflYS2UvoWN/xZz3VKMK1bxJyD5XKyS2cR9xCpOJPlcrJLZxH3EKk4k+VysktnEfcQqTiT5XKyS 2cR9xCpOJPdcZkK5TOQiAiIgAiIgAiIgAiIgAmVBQMpAWdxmFVIEREAEREAEREAEREAEcglIGchl IhcREAEREAEREAEREAERKAsCUgbK4jarkCIgAiIgAiIgAiIgAiKQS0DKQC4TuYiACIiACIiACIiA CIhAWRCQMlAWt1mFFAEREAEREAEREAEREIFcAlIGcpnIRQREQAREQAREQAREQATKgoCUgbK4zSqk CIiACIiACIiACIiACOQSkDKQy0QuIiACIiACIiACIiACIlAWBKQMlMVtViFFQAREQAREQAREQARE IJeAlIFcJnIRAREQAREQAREQAREQgbIgIGWgLG6zCikCIiACIiACIiACIiACuQSkDOQykYsIiIAI iIAIiIAIiIAIlAWBfX766adde6qkmbSjQw89dE8l/59KV6zS306xEqv0BNKH1HMlVukJpA+p50qs 0hNIH1LPlVilJ1A4ZN1DDjkkb6iff/45KhQmKQEe1urGLea6pRhXrJKeolx3scplkuQiVklkct3F KpdJkotYJZHJdRerXCZJLmKVRCbXXaxymSS5iFUSmQp3mQlVsNCRCIiACIiACIiACIiACJQVASkD ZXW7VVgREAEREAEREAEREAERqCAgZaCChY5EQAREQAREQAREQAREoKwISBkoq9utwoqACIiACIiA CIiACIhABQEpAxUsdCQCIiACIiACIiACIiACZUVAykBZ3W4VVgREQAREQAREQAREQAQqCEgZqGCh IxEQAREQAREQAREQAREoKwJSBsrqdquwIiACIiACIiACIiACIlBBQMpABQsdiYAIiIAIiIAIiIAI iEBZEZAyUFa3W4UVAREQAREQAREQAREQgQoC/werEY5fD3OeXwAAAABJRU5ErkJggg== --000000000000c4567905a14e916b-- From nobody Fri Mar 20 13:10:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5493A0DEF for ; Fri, 20 Mar 2020 13:10:27 -0700 (PDT) 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=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 674vC-T2p2qa for ; Fri, 20 Mar 2020 13:10:24 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 7F3C53A0DEB for ; Fri, 20 Mar 2020 13:10:23 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id r22so773598ljh.0 for ; Fri, 20 Mar 2020 13:10:23 -0700 (PDT) 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=ESiPeOH0eD9NaJ21f3wCV5ljDkuLf5gG776u7p5IVBY=; b=GZ4519k9gX+poPGWnsTHm3z4eVO2mituLZZD9+J7wpy/8d0BKSd655E7e3D1vs7HWK G9BHikp5Pr57W/dY2Vo9VF14xuUIRnIPBO0g5VA8Vrx2P49dgFq/Pqp99C3p0qZjlmf8 C/hAK/hO8Oe8BGlPAIG+E042n1ehTnsxYGeGsV9/8S6d9wvcVir4X3pbZX0PsvHWtWqX HayXYoMbNgSioeB+DjGhkxF+38Yy4XO/w/KS2vviCVfRT7Z8xCA82XgdrtjTyTzWFGq1 w7xkEcmqdpl2E88VJSFjWnBhQxL2qTG1L0Li3t73uj5T7U7IKzMVELzr/dJkXhWpjOrO yEhg== 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=ESiPeOH0eD9NaJ21f3wCV5ljDkuLf5gG776u7p5IVBY=; b=JD8Tp3Fa9Lt3ZvfI2EY4Frn5BWEFc2C/I061ARPUbbpp6GU3gXMK/Lp6CmQ3mhQbBQ OGdr/IeStm8+4rhwTTPFASdxnC4l3TCFKEDnn8Nbtk4ca4eFOj54BvtH3oaFiul70Th0 tpuZywtjdoBq/5p1YYGJWb18QjDAWoKwgomIqjBh8HBXDiQr6XDs96yHV6FDi5esn6/K CcbN+o/Rfv/bGIeaiEcGI1WPtuxp3bcm87QlJ0DVZ6hLrR3ANIlMwpi8qV6RFaUQULGy h7u1ZJzGk3Z32bYVqe5RH8C5DfARoBKhRxE111j8a8dPTnfA3aOCurhqVV3kFaXNmrdg PbgQ== X-Gm-Message-State: ANhLgQ0zQrHzlKSRRwdVc3xioAs62arersgrRdj8Em0Kz0oUhaUFseeD bCjOUDeFybbeCUks2IU9m97pjiRcvVdG7Jj2/Jnca7kF X-Google-Smtp-Source: ADFU+vvRgCPrlKMug0cLtv6IVVv2VM39wJAydhc2rDQ2mmsVO6fIwXEOyrETG54v7PUe/QvStHodL13J5Nqdoa6Bu9g= X-Received: by 2002:a2e:9dc8:: with SMTP id x8mr6595651ljj.212.1584735021462; Fri, 20 Mar 2020 13:10:21 -0700 (PDT) MIME-Version: 1.0 References: <2E748537-841E-4C1C-8787-145DC1CCA6BF@mit.edu> <807F99DF-11EE-4904-9688-86059BC249D4@mit.edu> <30E67E8A-CD0F-40CD-92C5-12D23E6FB1FA@mit.edu> In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 13:09:54 -0700 Message-ID: To: David Skaife Cc: Stephen Moore , Justin Richer , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000047ab505a14ee0fe" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 20:10:27 -0000 --000000000000047ab505a14ee0fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let me clarify the reference to "authentication mechanisms" in the XAuth rationale. It is how the Client can authenticate to the GS. It might be JOSE, MTLS, or ... Most clients today are bespoke in that they know a priori how they will interact with the user and the AS. In XAuth, the use cases that discovery enables are: - a client to interact with an arbitrary GS that provides a standardized set of capabilities, but may have different mechanisms for doing them. - a developer to use a library that encapsulates different mechanisms in different GS without the developer having to . - a GS can add new mechanisms without the Client having to change code. While some types of features can be easily negotiated, some features are difficult to negotiate, and a discovery mechanism is simpler. When I was discussing the differences with Justin, he contended that the capability negotiation in XYZ was discovery. I think that is only a subset of the problem. It is a somewhat different topic wrt. interaction capabilities. The Client knows it can do a redirect or not. Negotiation is not needed. For security reasons, I think the GS should always support a redirect. The GS can also decide if it will support Clients that don't support a redirect. Discovery allows the client to determine if the GS will allow not using a redirect before the Client puts together a request that will fail -- BUT this is only needed where the GS is not known by the Client a priori. /Dick On Wed, Mar 18, 2020 at 3:12 PM David Skaife < blue.ringed.octopus.guy@gmail.com> wrote: > Thanks for explaining further Justin - that makes more sense now. > > I think the confusion was that the topic here is simply "Discovery" and > also the XAuth rationale section in the original email says "Client can > make unauthenticated call to GS URI to learn what GS supports, *such as > authentication mechanisms*" - which sounds like an example where the > options would potentially be mutually exclusive. So certainly in my mind = I > was focusing on the mutually exclusive scenarios, which I now appreciate > isn't what you intended for the XYZ capabilities feature. > > Was a useful discussion, thanks. > > David Skaife > > On Wed, Mar 18, 2020 at 9:24 PM Stephen Moore wrote: > >> That makes more sense to me now. Thanks Justin! >> I also like that particular solution, rather basically relying on cachin= g >> or re-discovery before the transaction begins since, I think, that allow= s >> for more flexible client 'requirements'. >> -steve >> >> On Wed, Mar 18, 2020 at 5:18 PM Justin Richer wrote: >> >>> Speaking with someone on another channel, let me explain it this way. >>> >>> This isn=E2=80=99t like =E2=80=9CI will send this to you in JSON or CBO= R, which do you >>> want?=E2=80=9D It=E2=80=99s more like =E2=80=9CI can take a signed ID t= oken=E2=80=9D and =E2=80=9CI speak French=E2=80=9D. >>> So there isn=E2=80=99t an order or a preference or an exclusivity. If y= ou can do >>> either of them, or both of them, you just do them. >>> >>> Doing the OPTIONS call would let the client fetch from the server all o= f >>> that at once, if it wanted too. Allowing it inline lets the client do a= ll >>> of that without making a second network call or remembering anything. B= ut >>> it always has the option to do so. >>> >>> =E2=80=94 Justin >>> >>> On Mar 18, 2020, at 5:04 PM, Justin Richer wrote: >>> >>> I wasn=E2=80=99t showing just the happy path, but I think my example mi= ght have >>> been too simple. Also, I think we've got a different model for what=E2= =80=99s in >>> the capabilities. It=E2=80=99s not about a set of mutually exclusive op= tions that >>> the client has to choose from. >>> >>> Thanks Stephen and Justin for your responses. >>> >>> I certainly accept some of the points you've raised here. One thing I'd >>> like to add though is that the examples you've provided only show the >>> happy-path scenario (from a client's perspective) - where the AS >>> conveniently supports only one of the capabilities provided by the clie= nt. >>> What about if we consider the following scenario: >>> >>> - Client can do A, B, C and D. The AS can do A, B, C, D and E. >>> - The client sends [A, B, C, D]. >>> - Does the AS now send back [A, B, C, D] >>> >>> >>> Yes, the AS sends back [A, B, C, D] because that=E2=80=99s the subset o= f the >>> client=E2=80=99s capabilities. >>> >>> , and then force the client to make a decision (i.e. complexity on the >>> client)? Or instead, does the AS make a decision itself and then only s= end >>> one result back? If the latter, then how would the AS make this decisio= n, >>> and could this potentially result in an undesirable outcome from a clie= nt's >>> perspective? >>> >>> >>> The client is already declaring that it can do all of those, and so it >>> needs to figure out which of those it=E2=80=99s going to use and how th= ey work >>> together. My intent wasn=E2=80=99t to say that the client could only do= one of >>> those at a time, but rather that these were different things that the >>> client could support that were optional at the AS, and the AS is tellin= g >>> the client which bits that it knows about and can handle. Maybe this is= a >>> list of extensions, maybe it=E2=80=99s a list of optional features, but= it=E2=80=99s on top >>> of the =E2=80=9Ccore=E2=80=9D portions of the protocol. >>> >>> I=E2=80=99ll also say that this is completely separate from the discuss= ion on >>> how to handle interaction =E2=80=94 I think the information patterns on= that (which >>> are in a different thread) are much clearer. >>> >>> >>> As you've mentioned, in reality the client would likely "remember" the >>> capabilities that the AS supports. So if the AS were instead probed by = the >>> client to retrieve the list of its capabilities, this additional comple= xity >>> needed on the client side would not be something that is present in eve= ry >>> interaction - as the client would simply need to pass it's preferred >>> (supported) method on each interaction, rather than having to keep prob= ing >>> and filtering on each request. Additionally, this concept of the client >>> remembering what the AS supports would negate the argument about there >>> being an increase in network traffic raised by Stephen. >>> >>> >>> The reality is that most clients aren=E2=80=99t really going to discove= r and >>> declare things, especially if the client can start the whole protocol w= ith >>> just one bit of information. XYZ originally started with zero discovery= , >>> because all of the important parts are revealed during the protocol. >>> >>> >>> I don't think it's as clear-cut as you've presented in your responses, >>> but I do accept that there are merits to trying to push complexity to t= he >>> server. >>> >>> >>> I agree that it=E2=80=99s not that clear cut yet =E2=80=94 but that=E2= =80=99s largely because >>> there aren=E2=80=99t a lot of concrete things that would go in this =E2= =80=9Cdiscovery=E2=80=9D >>> document yet. At least with XYZ, we deliberately minimized what the cli= ent >>> would need to know going in, for both simplicity and security. When you >>> make the core protocol such that you don=E2=80=99t need a lot of extra = bits in >>> order for things to function, then you aren=E2=80=99t creating problems= that you >>> need solutions for. >>> >>> Thanks for raising the discussion! >>> >>> >>> Many thanks, >>> David Skaife >>> >>> On Wed, Mar 18, 2020 at 8:22 PM Justin Richer wrote: >>> >>>> OAuth 2 has taught us that wherever possible, you should push the >>>> complexity to the server, not the client. That=E2=80=99s the idea behi= nd the kind >>>> of publication/negotiation here where the client can do something simp= le >>>> and the AS needs to make the actual comparison and decision, whatever = that >>>> is. Clients need to stay simple because, for the most part, the focus = of >>>> the client is on calling whatever API and implementing whatever >>>> functionality it is doing, not on the security layer. The AS is a dedi= cated >>>> security component, so it=E2=80=99s got the mandate to figure this stu= ff out. This >>>> mindset is one of OAuth 2=E2=80=99s biggest strengths. >>>> >>>> So how would this work in XYZ? I=E2=80=99ll say that we haven=E2=80=99= t really :used: >>>> this feature beyond making sure the protocol can be passed back and fo= rth, >>>> since there=E2=80=99s not a lot of optionality that really needs to be= negotiated >>>> here. >>>> >>>> So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D= , and X. >>>> If the client doesn=E2=80=99t know anything at all about the AS, the c= lient sends: >>>> >>>> [A, B, C] >>>> >>>> And the server looks at that, compares with what it can do, and return= s: >>>> >>>> [B] >>>> >>>> The server doesn=E2=80=99t send D, or X, because the client wouldn=E2= =80=99t have any >>>> clue what to do about that. The client can remember that if it wants t= o >>>> cache that part of the response. >>>> >>>> So the question is, what if the client knew that only B would be >>>> successful for this server? That=E2=80=99s pretty common because a lot= of clients >>>> get written and configured with a static set of capabilities for a ser= ver. >>>> And with the negotiation above, the client just needs to remember afte= r the >>>> first call. So in both cases, the client would only send [B], or leave= it >>>> off entirely because it doesn=E2=80=99t need to negotiate, and you=E2= =80=99re done. >>>> >>>> But the thing is, you could do both styles with one simple twist. If >>>> you want to do the discovery portion in a pre-flight request, I think = it=E2=80=99s >>>> a good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80=99t ma= ke any sense >>>> to me to allow it on any other endpoints, especially because some of t= hose >>>> are going to be user-facing (so the client is not going to be talking = to >>>> the URL itself). The client makes this call and gets back: >>>> >>>> [B, D, X] >>>> >>>> And now the client has to put together its possible capabilities from >>>> that list and what it knows it can do. By putting OPTIONS on the endpo= int >>>> then we can stick with the same mantra of the client having one piece = of >>>> info to get started =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 = and learning everything else >>>> from that. I think that part is simple enough to potentially work, and= XYZ >>>> doesn=E2=80=99t have other endpoints or aspects that need to be discov= ered out of >>>> band, unlike OAuth 2. >>>> >>>> =E2=80=94 Justin >>>> >>>> >>>> >>>> On Mar 18, 2020, at 3:44 PM, David Skaife < >>>> blue.ringed.octopus.guy@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> My thoughts on these different approaches are: >>>> >>>> 1. For XYZ, it feels a bit strange and unnecessary to require the >>>> client to have to state it's full set of capabilities to the AS. It fe= els >>>> like it should be the other way around - i.e. the client is able to pr= obe >>>> what the AS supports. In my view it's more natural for the AS to be >>>> "advertising" its capabilities rather than the client. >>>> >>>> 2. I prefer the XYZ approach of having a single URL that the client >>>> knows it needs to interact to start the transaction, vs the more compl= ex >>>> approach provided by XAuth. >>>> >>>> 3. Hopefully there is a middle ground between the two approaches that >>>> addresses the two points above. >>>> >>>> >>>> Many thanks, >>>> David Skaife >>>> >>>> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt >>>> wrote: >>>> >>>>> >>>>> *Discovery* >>>>> XYZ >>>>> - Client always starts at the tx endpoint, all other information is >>>>> dispatched from responses from the endpoint >>>>> - Clients sends capabilities list in transaction request, AS selects >>>>> and returns which capabilities are supported >>>>> >>>>> XYZ Rationale: client needs a single URL to start talking to an AS, >>>>> giving developers multiple ways to get information is confusing and c= an >>>>> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by = OIDC=E2=80=99s >>>>> discovery approach) >>>>> >>>>> XAuth >>>>> - Client sends an OPTIONS call to the GS URI, Grant URI, or >>>>> Authorization URI >>>>> >>>>> XAuth Rationale: Client can make unauthenticated call to GS URI to >>>>> learn what GS supports, such as authentication mechanisms. Authentica= ted >>>>> calls return what a specific Client can do. >>>>> >>>>> >>>>> =E1=90=A7 >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> >>>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000047ab505a14ee0fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let me clarify the=C2=A0reference=C2=A0to "authe= ntication mechanisms" in the XAuth rationale. It is how the Client can= authenticate=C2=A0to the GS. It might be JOSE, MTLS, or ...

=
Most clients today are bespoke in that they know a priori how th= ey will interact with the user and the AS. In XAuth, the use cases that dis= covery enables are:

- a client to interact with an= arbitrary GS that provides a standardized set of capabilities, but may hav= e different mechanisms for doing them.=C2=A0

- a d= eveloper to use a library that encapsulates=C2=A0different mechanisms in di= fferent GS without the developer having to .

- a G= S can add new mechanisms without the Client having to change code.

While some types of features can be easily negotiated, som= e features are difficult to negotiate, and a discovery mechanism is simpler= .

When I was discussing the differences with Justi= n, he contended that the capability negotiation in XYZ was discovery. I thi= nk that is only a subset of the problem.

It is a s= omewhat=C2=A0different topic wrt. interaction capabilities. The Client know= s it can do a redirect or not. Negotiation is not needed. For security reas= ons, I think the GS should always support a redirect. The GS can also decid= e if it will support Clients that don't support a redirect. Discovery a= llows the client to determine if the GS will allow not using a redirect bef= ore the Client puts together a request that will fail -- BUT this is only n= eeded where the GS is not known by the Client a priori.

/Dick


<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 18, 2020 at 3:12 PM David = Skaife <blue.ringed= .octopus.guy@gmail.com> wrote:
Thanks=C2=A0for explaining further J= ustin - that makes more sense now.

I think the confusion was t= hat the topic here is simply "Discovery" and also the XAuth ratio= nale section in the original email says "Client can make unauthenticat= ed call to GS URI to learn what GS supports, such as authentication mech= anisms" - which sounds like an example where the options would pot= entially be mutually exclusive. So certainly in my mind I was focusing on t= he mutually=C2=A0exclusive scenarios, which I now appreciate isn't what= you intended for the XYZ capabilities feature.

Was a useful discuss= ion, thanks.

David Skaife

On Wed, Mar 1= 8, 2020 at 9:24 PM Stephen Moore <srmoore@gmail.com> wrote:
T= hat makes more sense to me now. Thanks Justin!
I also like that particu= lar solution, rather basically relying on caching or re-discovery before th= e transaction begins since, I think, that allows for more flexible client &= #39;requirements'.
-steve

On Wed, Mar 18, 2020 at 5:18 P= M Justin Richer <jricher@mit.edu> wrote:
Speaking with someone on another= channel, let me explain it this way.

This isn=E2=80=99t= like =E2=80=9CI will send this to you in JSON or CBOR, which do you want?= =E2=80=9D It=E2=80=99s more like =E2=80=9CI can take a signed ID token=E2= =80=9D and =E2=80=9CI speak French=E2=80=9D. So there isn=E2=80=99t an orde= r or a preference or an exclusivity. If you can do either of them, or both = of them, you just do them.

Doing the OPTIONS call = would let the client fetch from the server all of that at once, if it wante= d too. Allowing it inline lets the client do all of that without making a s= econd network call or remembering anything. But it always has the option to= do so.

=C2=A0=E2=80=94 Justin

On Mar 18, 2020, at 5:04 PM, Justin Richer <j= richer@mit.edu> wrote:

I wasn=E2=80=99t showing just the happy path, but I think = my example might have been too simple. Also, I think we've got a differ= ent model for what=E2=80=99s in the capabilities. It=E2=80=99s not about a = set of mutually exclusive options that the client has to choose from.

Thanks Stephen and Justin for your responses.
=
I certainly accept some of the points you've raised here. One thing= I'd like to add though is that the examples you've provided only s= how the happy-path scenario (from a client's perspective) - where the A= S conveniently supports only one of the capabilities provided by the client= . What about if we consider the following scenario:

- Client can do = A, B, C and D. The AS can do A, B, C, D and E.
- The client sends [A, B,= C, D].
- Does the AS now send back [A, B, C, D]

Yes, the AS sends back [A, B, C, D] because that=E2=80= =99s the subset of the client=E2=80=99s capabilities.=C2=A0

, and then force the client to ma= ke a decision (i.e. complexity on the client)? Or instead, does the AS make= a decision=C2=A0itself and then only send one result back? If the latter, = then how would the AS make this decision, and could this potentially result= in an undesirable outcome from a client's perspective?
=

The client is already declaring that it ca= n do all of those, and so it needs to figure out which of those it=E2=80=99= s going to use and how they work together. My intent wasn=E2=80=99t to say = that the client could only do one of those at a time, but rather that these= were different things that the client could support that were optional at = the AS, and the AS is telling the client which bits that it knows about and= can handle. Maybe this is a list of extensions, maybe it=E2=80=99s a list = of optional features, but it=E2=80=99s on top of the =E2=80=9Ccore=E2=80=9D= portions of the protocol.=C2=A0

I=E2=80=99ll also= say that this is completely separate from the discussion on how to handle = interaction =E2=80=94 I think the information patterns on that (which are i= n a different thread) are much clearer.=C2=A0


As you've mentioned, in reality the cli= ent would likely "remember" the capabilities=C2=A0that the AS sup= ports. So if the AS were instead probed by the client to retrieve the list = of its capabilities, this additional complexity needed on the client side w= ould not be something that is present in every interaction - as the client = would simply need to pass it's preferred (supported) method on each int= eraction, rather than having to keep probing and filtering on each request.= Additionally, this concept of the client remembering what the AS supports = would negate the argument about there being an increase in network traffic = raised by Stephen.

The real= ity is that most clients aren=E2=80=99t really going to discover and declar= e things, especially if the client can start the whole protocol with just o= ne bit of information. XYZ originally started with zero discovery, because = all of the important parts are revealed during the protocol.=C2=A0

I don't think it&#= 39;s as clear-cut as you've presented in your responses, but I do accep= t that there are merits to trying to push complexity to the server.

=

I agree that it=E2=80=99s not = that clear cut yet =E2=80=94 but that=E2=80=99s largely because there aren= =E2=80=99t a lot of concrete things that would go in this =E2=80=9Cdiscover= y=E2=80=9D document yet. At least with XYZ, we deliberately minimized what = the client would need to know going in, for both simplicity and security. W= hen you make the core protocol such that you don=E2=80=99t need a lot of ex= tra bits in order for things to function, then you aren=E2=80=99t creating = problems that you need solutions for.

Thanks for r= aising the discussion!


Many thanks,
David Skaife

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 18, 2020 at 8:22 PM Justin= Richer <jricher@mit.edu> wrote:
OAuth 2 has taught us that wherever poss= ible, you should push the complexity to the server, not the client. That=E2= =80=99s the idea behind the kind of publication/negotiation here where the = client can do something simple and the AS needs to make the actual comparis= on and decision, whatever that is. Clients need to stay simple because, for= the most part, the focus of the client is on calling whatever API and impl= ementing whatever functionality it is doing, not on the security layer. The= AS is a dedicated security component, so it=E2=80=99s got the mandate to f= igure this stuff out. This mindset is one of OAuth 2=E2=80=99s biggest stre= ngths.=C2=A0

So how would this work in XYZ? I=E2=80=99ll= say that we haven=E2=80=99t really :used: this feature beyond making sure = the protocol can be passed back and forth, since there=E2=80=99s not a lot = of optionality that really needs to be negotiated here.

<= div>So let=E2=80=99s say the client can do A, B, and C. The AS can do B, D,= and X. If the client doesn=E2=80=99t know anything at all about the AS, th= e client sends:

[A, B, C]

And the server looks at that, compares with what it can do, and returns:

[B]

The server doesn=E2=80= =99t send D, or X, because the client wouldn=E2=80=99t have any clue what t= o do about that. The client can remember that if it wants to cache that par= t of the response.

So the question is, what if the= client knew that only B would be successful for this server? That=E2=80=99= s pretty common because a lot of clients get written and configured with a = static set of capabilities for a server. And with the negotiation above, th= e client just needs to remember after the first call. So in both cases, the= client would only send [B], or leave it off entirely because it doesn=E2= =80=99t need to negotiate, and you=E2=80=99re done.=C2=A0

But the thing is, you could do both styles with one simple twist. I= f you want to do the discovery portion in a pre-flight request, I think it= =E2=80=99s a good idea to allow OPTIONS on the tx endpoint. It doesn=E2=80= =99t make any sense to me to allow it on any other endpoints, especially be= cause some of those are going to be user-facing (so the client is not going= to be talking to the URL itself). The client makes this call and gets back= :

[B, D, X]

And now the c= lient has to put together its possible capabilities from that list and what= it knows it can do. By putting OPTIONS on the endpoint then we can stick w= ith the same mantra of the client having one piece of info to get started = =E2=80=94 the tx endpoint=E2=80=99s URL =E2=80=94 and learning everything e= lse from that. I think that part is simple enough to potentially work, and = XYZ doesn=E2=80=99t have other endpoints or aspects that need to be discove= red out of band, unlike OAuth 2.

=C2=A0=E2=80=94 J= ustin



= On Mar 18, 2020, at 3:44 PM, David Skaife <blue.ringed.octopus.guy@gm= ail.com> wrote:

Hi,

My thoughts on these different approaches are:

1. For XYZ, it feel= s a bit strange and unnecessary to require the client to have to state it&#= 39;s full set of capabilities to the AS. It feels like it should be the oth= er way around - i.e. the client is able to probe what the AS supports. In m= y view it's more natural for the AS to be "advertising" its c= apabilities rather than the client.

2. I prefer the XYZ approach of = having a single URL that the client knows it needs to interact to start the= transaction, vs the more complex approach=C2=A0provided by XAuth.

3= . Hopefully there is a middle ground between the two approaches that addres= ses the two points above.


Many thanks,
David Skaife

On M= on, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com>= wrote:
Discovery

XYZ
=C2=A0- Client always starts at the= tx endpoint, all other information is dispatched from responses from the e= ndpoint
=C2=A0- Clients sends capabilities list in transaction request, = AS selects and returns which capabilities are supported

XYZ Rational= e: client needs a single URL to start talking to an AS, giving developers m= ultiple ways to get information is confusing and can lead to serious errors= (see OAuth2=E2=80=99s mix-up attack caused by OIDC=E2=80=99s discovery app= roach)

XAuth
=C2=A0- Client sends an OPTIONS call to the GS URI, = Grant URI, or Authorization URI

XAuth Rationale: Client can make una= uthenticated call to GS URI to learn what GS supports, such as authenticati= on mechanisms. Authenticated calls return what a specific Client can do.

=E1=90=A7
--=C2=A0
T= xauth mailing list
Txauth@ietf.org
https= ://www.ietf.org/mailman/listinfo/txauth


= --=C2=A0
Txauth mailing list
Txauth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--000000000000047ab505a14ee0fe-- From nobody Fri Mar 20 13:19:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615AA3A0DDE for ; Fri, 20 Mar 2020 13:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 dQ4NwgtkpHsy for ; Fri, 20 Mar 2020 13:18:57 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 50C533A0DE8 for ; Fri, 20 Mar 2020 13:18:57 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id w4so7828007lji.11 for ; Fri, 20 Mar 2020 13:18:57 -0700 (PDT) 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=IsiNhPEp9iw86NNb6AEJoAB9J5MbsgXfPuNzvsQx8pE=; b=O76H5c/Nv3fzjuRf1f0IC2fThLe8Ph9OOKGKK0dBrjtjJ6ECjdqehngRfuMVk+2Dpn TsYLChjExnKtIugVxyv8SrEIBIenM7DFDx6dqxQ3V4NFbDb17m/k3mAQA6rDAhWrCMEN t7vs+YxhNwNfFeujxE+F6wew3oaVA/CzNZpgdpKx6N3HmuyGuouSOpAeXvVQKNPsPH6w aBw6bRO2uZ+EH23REAhRxbiC7yIfFs74zdB1utuOIjYMmhgVHy1MfpOwBKedKQETbtur dDddiPg8IK5wwQ/1JARrkHrmyN857Ncrgb9IBfwXaUFpDTUZYC8vr7LvIjx8xtxIcaXw DqLQ== 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=IsiNhPEp9iw86NNb6AEJoAB9J5MbsgXfPuNzvsQx8pE=; b=qY9JH/DM5lP3MZu2jJAplxfd2uHUsgG9MsO+dyMOtzTw+bKwUDHsUQVhMke3ce+sdr uOCJrcPFgdKmpfR/cFg9vFQBuY+rcKL58Ma/NziMDip54soS+dc8DAxIJoKYySTX+pqi 9ZjT+o3t0Nx3fUiQ4dDStfIIO/i5kOCukjca/1D2/V2+FYf5qgWtMWr8ismddjhOmp1O E3YBbVTK5RPS0XoauCKiEVrp9kYqSIpzTbvpr/yhKFr3atSVb+B10dvGRuyYzrKhlgPE GGq0UqVnCx49vzrU0HDgHpqamVaOjOdy3Zv1YOdCacFb3ILeEM0VfLsIzhQ9qkyJ9rth kJcw== X-Gm-Message-State: ANhLgQ1nWB/8msfYZHmBSfed+kGuR8YGkJNl8HJhob7U9FasWLfzJjve mLp5/7IL/d/B2a5zEjKkiVnDIci4NauUgThH8TIoRZjzhZo= X-Google-Smtp-Source: ADFU+vtpjNsNn+c2xPPpmIVSi9/uglrbuPYXqlr59rZpZlNtHOmJ4Lrp6jMmLd3pA+z9vNzK14g1zJ+AOb8qBPqShwA= X-Received: by 2002:a2e:9dc8:: with SMTP id x8mr6614011ljj.212.1584735535028; Fri, 20 Mar 2020 13:18:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 13:18:29 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer Content-Type: multipart/alternative; boundary="000000000000a0dd2505a14efe07" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 20:19:00 -0000 --000000000000a0dd2505a14efe07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ACTION REMINDER *Please weigh in with your preference, your rationale, as well as any pros and cons not described.* Yaron and I were hopeful that we would get more feedback on these topics, as it would help determine if either the XYZ or XAuth documents are roughly aligned with the consensus direction of the group so that we have a starting document. We will NOT be able to do hums in the BoF ... so we will not be able to use that to judge rough consensus. /Dick On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt wrote: > Hello everyone > > Justin and I have had some emails back and forth comparing and contrastin= g > XYZ and XAuth. I'm going to post a message for each of the major points, > with Justin's rationale and my rationale for our respective design > decisions. Feel free to ask clarifying questions in those threads. > > *Please weigh in with your preference, your rationale, as well as any pro= s > and cons not described.* > > We would like to get a sense for the group's views on these topics for th= e > virtual BoF in a week. > > The latest drafts are: > > XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 > > XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 > > Thanks! > > /Dick > =E1=90=A7 > --000000000000a0dd2505a14efe07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ACTION REMINDER

Ple= ase weigh in with your preference, your rationale, as well as any pros and = cons not described.

Yaron and I we= re hopeful=C2=A0that we would get more feedback on these topics, as it woul= d help determine if either the XYZ or XAuth documents are roughly aligned w= ith the consensus direction of the group so that we have a starting documen= t.

We will NOT be able to do hums in the BoF ... so we w= ill not be able to use that to judge rough consensus.

<= div>/Dick

On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello= everyone

Justin and I have had some emails back and fort= h comparing and contrasting XYZ and XAuth. I'm going to post a message = for each of the major points, with Justin's rationale and my rationale = for our respective design decisions.=C2=A0Feel free to ask clarifying quest= ions in those threads.

Please weigh in with you= r preference, your rationale, as well as any pros and cons not described.

We would like to get a sense for the grou= p's views on these topics for the virtual BoF in a week.

=
The latest drafts are:



Tha= nks!

/Dick
3D""=E1=90= =A7
--000000000000a0dd2505a14efe07-- From nobody Fri Mar 20 13:24:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B4F3A0DF8 for ; Fri, 20 Mar 2020 13:24:01 -0700 (PDT) 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_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=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 ZzJStc2MqyM9 for ; Fri, 20 Mar 2020 13:23:59 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 89E603A0DF7 for ; Fri, 20 Mar 2020 13:23:59 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id w1so7860855ljh.5 for ; Fri, 20 Mar 2020 13:23:59 -0700 (PDT) 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=Qy2Bop4ZAbZarO3XIbi5gqs3jqVfc+17oJh9Ha51VGA=; b=mCumdRUeUYbmP+BcLa/j6pTEEcOR/WlFe6BfwAPBl+VAC1/6sJ4MQNE6WGmVwuaq5z 0BRZeGKxR0VtQr2dHcCjZaNgXdfggYMMoO2uaDh/lKuWM+6FpfMbM2MBceb0U1YxX2LF fhYhJZjhoIYELZ1tfPMYTVdOLVVPGNpIUo3zCsNDbS1gtTRqcgRDiMwAsofQPRxvTy11 DJ1AWNZp2jU96pMlq0iphzoBeZRM62r5UvKy/go+ygKJ7q4g63wbzSzsmjV5kMOy64UV dBvhNqVswFRlyDhvwfECm/BNu3atOGkYrn8kcaq6jJB8RTcbyOIMDDI8dgSjI1YQCJZh aq6g== 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=Qy2Bop4ZAbZarO3XIbi5gqs3jqVfc+17oJh9Ha51VGA=; b=QWKFQQZegki+PrwsgzlmLMbgVoGFr5Uy/YoA8QlpLyAvjbznGusvcJU2p4hd7dHHxq Rdu6jtsQ8f9bzguxO+1JvJGdTfw/GcP/IY0n1QgBsCpuNbq56O7tOutIndQgn3zsrTXh DyhUOcR4EptyaDvWk/xyudDzViN1Qs2aMnNr73Cbrbkh3wogr/xJLdEBm1ItXoA7XdlS UxIaiwso5pNxKnwADOr0pGT9oYs/JmahFMczJZANJTce8gmCNM054xS4L2vDdAcP92Cw ACsWooxAY5hLn8BZF6dy/rkJtIlWlL42gH1FE+S9aCuaikrDVWTm/Nr+IwwQeQcjuYLf XJKg== X-Gm-Message-State: ANhLgQ2WAZkmvQtS0pmnF5eG2kp7StIgbc0p3l6ZAFoTctJNiKIXQB71 +VEE26amjHlQvBZ7e7CNlZ1swjda95oUKBGtXcA= X-Google-Smtp-Source: ADFU+vvxOiZkbW6FBvR80Q/9gR6/K1Y8OelkQWOT1JWKWVGDCnE7c0oMWoSaaQz6+/QbMzDJapRBeUPuANDPFkazdDc= X-Received: by 2002:a2e:9a0d:: with SMTP id o13mr6274207lji.151.1584735837644; Fri, 20 Mar 2020 13:23:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 13:23:31 -0700 Message-ID: To: David Skaife Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000aa6d3d05a14f1007" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 20:24:03 -0000 --000000000000aa6d3d05a14f1007 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To clarify on point 2 made below about XAuth being more complex: XAuth has a single URI to interact with to start, the GS URI. The Grant URL is the GS URL + identifier which seems equivalent to the TxAurh endpoint and transaction handle. An advantage of the Grant URI, is the Client knows which GS it belongs to. David: would you clarify what you think is more complex in XAuth? /Dick On Wed, Mar 18, 2020 at 12:44 PM David Skaife < blue.ringed.octopus.guy@gmail.com> wrote: > Hi, > > My thoughts on these different approaches are: > > 1. For XYZ, it feels a bit strange and unnecessary to require the client > to have to state it's full set of capabilities to the AS. It feels like i= t > should be the other way around - i.e. the client is able to probe what th= e > AS supports. In my view it's more natural for the AS to be "advertising" > its capabilities rather than the client. > > 2. I prefer the XYZ approach of having a single URL that the client knows > it needs to interact to start the transaction, vs the more complex > approach provided by XAuth. > > 3. Hopefully there is a middle ground between the two approaches that > addresses the two points above. > > > Many thanks, > David Skaife > > On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote: > >> >> *Discovery* >> XYZ >> - Client always starts at the tx endpoint, all other information is >> dispatched from responses from the endpoint >> - Clients sends capabilities list in transaction request, AS selects an= d >> returns which capabilities are supported >> >> XYZ Rationale: client needs a single URL to start talking to an AS, >> giving developers multiple ways to get information is confusing and can >> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OID= C=E2=80=99s >> discovery approach) >> >> XAuth >> - Client sends an OPTIONS call to the GS URI, Grant URI, or >> Authorization URI >> >> XAuth Rationale: Client can make unauthenticated call to GS URI to learn >> what GS supports, such as authentication mechanisms. Authenticated calls >> return what a specific Client can do. >> >> >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000aa6d3d05a14f1007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To clarify on point 2 made below about XAuth being mo= re complex:

XAuth has a single URI to interact wit= h to start, the GS URI.

The Grant URL is the GS UR= L=C2=A0+ identifier which seems equivalent to the TxAurh=C2=A0endpoint and = transaction handle.

An advantage of the Grant URI,= is the Client knows which GS it belongs to.

David= : would you clarify what you think is more complex in XAuth?

=
/Dick

On Wed, Mar 18, 2020 at 12:44 PM David Skaife <blue.ringed.octopus.guy@gmail= .com> wrote:
Hi,

My thoughts on these different = approaches are:

1. For XYZ, it feels a bit strange and unnecessary t= o require the client to have to state it's full set of capabilities to = the AS. It feels like it should be the other way around - i.e. the client i= s able to probe what the AS supports. In my view it's more natural for = the AS to be "advertising" its capabilities rather than the clien= t.

2. I prefer the XYZ approach of having a single URL that the clie= nt knows it needs to interact to start the transaction, vs the more complex= approach=C2=A0provided by XAuth.

3. Hopefully there is a middle gro= und between the two approaches that addresses the two points above.

=
Many thanks,
David Skaife

=
On Mon, Mar 16, 2020 at 11:06 PM Dick= Hardt <dick.h= ardt@gmail.com> wrote:
Discovery

XYZ
=C2=A0- Clien= t always starts at the tx endpoint, all other information is dispatched fro= m responses from the endpoint
=C2=A0- Clients sends capabilities list in= transaction request, AS selects and returns which capabilities are support= ed

XYZ Rationale: client needs a single URL to start talking to an A= S, giving developers multiple ways to get information is confusing and can = lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OIDC= =E2=80=99s discovery approach)

XAuth
=C2=A0- Client sends an OPTI= ONS call to the GS URI, Grant URI, or Authorization URI

XAuth Ration= ale: Client can make unauthenticated call to GS URI to learn what GS suppor= ts, such as authentication mechanisms. Authenticated calls return what a sp= ecific Client can do.


--000000000000aa6d3d05a14f1007-- From nobody Fri Mar 20 13:43:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0B3A0E0F for ; Fri, 20 Mar 2020 13:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 mClaY0iif2xq for ; Fri, 20 Mar 2020 13:42:59 -0700 (PDT) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (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 AA89D3A0E0C for ; Fri, 20 Mar 2020 13:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1584736980; x=1616272980; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=ora+7vMhw3heV8kOiZiIXFIxaf9FcrujEWc8X0YKv8U=; b=vETZE0ChO4P+ZaFYISv/wk9wZQnxbRnzRxnDYPq6XM8BeD0QzVXw9HPC DZqJXk0d6oM/DKRrniAhBzWgEMch0x54w5y7oamn8IhleDgfhCPsbyy3Q xxGn8MumXDGNcxhbwmNdkGjz/mHlpmW21xa6st8TTDAIidWrgiwC5WrSO 0=; IronPort-SDR: O/5asePoJZx0c+p5jYoheMU1X7NlAUw2J1G+GTH8X1ruit8Io19nwsi6gxiioAbi89UZEDXXpP IyhLHNj2QNRQ== X-IronPort-AV: E=Sophos; i="5.72,285,1580774400"; d="scan'208,217"; a="32457834" Thread-Topic: [Txauth] Multiple Access Tokens in XYZ Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-859fe132.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 20 Mar 2020 20:42:56 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-859fe132.us-west-2.amazon.com (Postfix) with ESMTPS id 7C349221969; Fri, 20 Mar 2020 20:42:55 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 20 Mar 2020 20:42:54 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 20 Mar 2020 20:42:54 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Fri, 20 Mar 2020 20:42:54 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Justin Richer CC: Torsten Lodderstedt , "txauth@ietf.org" Thread-Index: AQHV/D2pNyaLF7VPskmHhMHMOPJA4KhP7p4AgAGo3wCAADzqAP//rgcA Date: Fri, 20 Mar 2020 20:42:54 +0000 Message-ID: References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.167] Content-Type: multipart/alternative; boundary="_000_A81FDB11C05F49E09FA63A2C420282B5amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 20:43:07 -0000 --_000_A81FDB11C05F49E09FA63A2C420282B5amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBhbHNvIG9wcG9zZWQgdG8gcmVxdWlyaW5nIENsaWVudHMgdG8gc3VwcG9ydCBhcmJpdHJh cmlseSBzcGxpdCBhY2Nlc3MgdG9rZW5zLiBJZiB3ZSBhcmUgdG8gc3VwcG9ydCBtdWx0aXBsZSBh Y2Nlc3MgdG9rZW5zLCB3ZSBuZWVkIHRvIGRvIHNvIGluIGEgd2F5IHRoYXQgZG9lcyBub3QgYWR2 ZXJzZWx5IGltcGFjdCB0aGUgbWFueSBkZXBsb3ltZW50cyBmb3Igd2hpY2ggdGhleSBhcmUgYW4g dW5uZWNlc3NhcnkgY29tcGxpY2F0aW9uLiBTZWNvbmRpbmcgRGlja+KAmXMgY29tbWVudCB0aGF0 IOKAnHNwbGl0X3Rva2Vuc+KAnSBpcyBvdmVybHkgY29tcGxleC4gSXQgZmVlbHMgdG8gbWUgbGlr ZSB0aGUgc29ydCBvZiBvcHRpb24gdGhhdCB3b3VsZCBodXJ0IGludGVyb3BlcmFiaWxpdHkgaW4g dGhlIGxvbmcgcnVuLg0KDQpJIHdhbnQgdG8gbWFrZSBzdXJlIHdlIGFyZSBub3QgcG9zaXRpb25p bmcgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBhcyBhIG5lY2Vzc2FyeSByZXF1aXJlbWVudCBmb3Ig QVNlcyB0aGF0IHN1cHBvcnQgbXVsdGlwbGUgUlNlcy4gVGhlcmUgYXJlIG90aGVyIHdheXMgdG8g ZG8gdGhhdCwgZWFjaCB3aXRoIGRpZmZlcmVudCBwcm9zIGFuZCBjb25zIHRoYXQgY2Fu4oCZdCBi ZSBwcm9wZXJseSBldmFsdWF0ZWQgb3V0c2lkZSB0aGUgY29udGV4dCBvZiBhbiBhY3R1YWwgcHJv dG9jb2wsIGFuZCBldmVuIHRoZW4gZGlmZmVyZW50IGRlcGxveW1lbnRzIG1heSB3ZWlnaCB0aG9z ZSBwcm9zIGFuZCBjb25zIGRpZmZlcmVudGx5Lg0KDQpTaW1pbGFybHksIHdlIHNob3VsZCBub3Qg YmUgY29uc3RyYWluaW5nIGhvdyBBU2VzIGFuZCBSU2VzIHNoYXJlIGluZm9ybWF0aW9uLiBBZ2Fp biwgZGlmZmVyZW50IGRlcGxveW1lbnRzIHdpbGwgY2FsbCBmb3IgZGlmZmVyZW50IGFwcHJvYWNo ZXMuIEkgZG8gbGlrZSBKdXN0aW7igJlzIHN1Z2dlc3Rpb24gKHBlcmhhcHMgb24gYW5vdGhlciB0 aHJlYWQ/KSBvZiBzdGFuZGFyZGl6aW5nIGEgc2NoZW1hIHRoYXQgdG9rZW4gY2xhaW1zLCBBUEkg cmVzdWx0cywgZXRjLiBjb3VsZCBhZGhlcmUgdG8uDQoNCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4g KHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkv DQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KRGF0ZTogRnJpZGF5LCBNYXJjaCAy MCwgMjAyMCBhdCAxMTozNyBBTQ0KVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4N CkNjOiBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4sICJ0eGF1 dGhAaWV0Zi5vcmciIDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0VYVEVSTkFMXSBb VHhhdXRoXSBNdWx0aXBsZSBBY2Nlc3MgVG9rZW5zIGluIFhZWg0KDQoNCkNBVVRJT046IFRoaXMg ZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90 IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBjYW4gY29uZmlybSB0 aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoNCg0KSSBhZ3JlZSB3aXRo IEp1c3RpbiB0aGF0IHRoZSBDbGllbnQgdW5leHBlY3RlZGx5IGdldHRpbmcgc3BsaXQgYWNjZXNz IHRva2VucyBpcyB1bmRlc2lyYWJsZS4NCg0KSSBhZ3JlZSB3aXRoIE1pa2UgYW5kIFRvcnN0ZW4g dGhhdCB0b2tlbnMgc2hvdWxkIGJlIHNlbGYgY29udGFpbmVkLCBhbmQgYWJsZSB0byBiZSBpbmRl cGVuZGVudCBiZXR3ZWVuIHJlc291cmNlcy4gSSB3b3VsZCBhZGQgdGhhdCB0aGV5IHNob3VsZCBi ZSBhcyBmaW5lIGdyYWluZWQgYXMgcHJhY3RpY2FsLCB3aGljaCBpcyBwYXJ0IG9mIHRoZSBjaGFy dGVyLg0KDQpSYXRoZXIgdGhlbiB0aGUgY2xpZW50IHRoaW5raW5nIGl0IGlzIGdldHRpbmcgbXVs dGlwbGUgYWNjZXNzIHRva2VucywgaG93IGFib3V0IHRoaW5raW5nIG9mIHRoZSBjbGllbnQgZ2V0 dGluZyBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzPw0KDQpUaGUgQVMgcHJvdmlkZXMgYW4g YWNjZXNzIHRva2VuIGZvciBlYWNoIHJlc291cmNlLiBUaGUgYWNjZXNzIHRva2VucyBtYXkgYWxs IGJlIHRoZSBzYW1lLCBhbGwgYmUgZGlmZmVyZW50LCBvciBhIG1peC4NCg0KVGhlIENsaWVudCBk b2VzIG5vdCBuZWVkIHRvIGtub3cgd2hpY2ggb25lcyBhcmUgdGhlIHNhbWUgb3IgZGlmZmVyZW50 IGFoZWFkIG9mIHRpbWUsIGJ1dCBpdCBkb2VzIGtub3cgd2hpY2ggb25lIGl0IHdpbGwgdXNlIGZv ciBhY2Nlc3Npbmcgd2hpY2ggcmVzb3VyY2UuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSBu ZWVkIGZvciBhICJzcGxpdF90b2tlbnMiIGZsYWcuIFRoYXQgc291bmRzIG92ZXJseSBjb21wbGlj YXRlZC4NCg0KDQoNCg0KDQoNCk9uIEZyaSwgTWFyIDIwLCAyMDIwIGF0IDc6NTkgQU0gSnVzdGlu IFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToN ClNvIGZ1bmRhbWVudGFsbHksIEkgZG9u4oCZdCB3YW50IHRoZSBBUyB0byBhbGxvd2VkIHRvIHNw bGl0IHRva2VucyB3aGVuIHRoZSBjbGllbnQgaXNu4oCZdCBleHBlY3RpbmcgaXQuIFdvdWxkIGEg c2ltcGxlIGZlYXR1cmUgZmxhZyB0byBhbGxvdyB0aGF0IGJlaGF2aW9yIGF0IHRoZSBBUyBiZSBl bm91Z2ggdG8gc3dpdGNoIGJvdGggY2FzZXM/DQoNClNvIGxldOKAmXMgc2F5IHdlICBqdXN0IGRv IHRoZSBzaW1wbGUgdGhpbmcgYW5kIG1ha2UgaXQgYSBib29sZWFuIHRvcC1sZXZlbCBmbGFnLiBJ ZiB0aGUgY2xpZW50IHNlbmRzIOKAnHNwbGl0X3Rva2VuczogdHJ1ZeKAnSB0aGVuIHRoZSBBUyBh bHdheXMgcmV0dXJucyB0aGUg4oCcbXVsdGlwbGVfYWNjZXNzX3Rva2Vuc+KAnSBzdHJ1Y3R1cmUg YW5kIGl0IGNvbWVzIHVwIHdpdGggd2hhdGV2ZXIgbmFtZXMgaXQgbWFrZXMgc2Vuc2UgZm9yIHRo ZSByZXN1bHRpbmcgdG9rZW5zLiBUaGUgY2xpZW50IGNhbiBkbyBlaXRoZXIgdGhlIHNpbmdsZSBv ciBtdWx0aXBsZSB0b2tlbiByZXF1ZXN0IHN0eWxlLiBUaGUgY2xpZW50IG5lZWRzIHRvIGJlIGFi bGUgdG8gZmlndXJlIG91dCBmcm9tIHRoZSB0b2tlbiByZXNwb25zZXMgaG93IHRvIHB1dCB3aGlj aCB0b2tlbiBpbiB3aGljaCBwbGFjZSwgYW5kIEkgdGhpbmsgd2UgY2FuIGRvIHNvbWUgdGhpbmdz IHdpdGggdGhlIGd1dHMgb2YgdGhlIOKAnHJlc291cmNlc+KAnSByZXF1ZXN0IG9iamVjdCwgbGlr ZSB1c2luZyDigJxsb2NhdGlvbnPigJ0gYW5kIG1heWJlIG90aGVyIGZpZWxkcy4gSWYgdGhlIGNs aWVudCBkb2VzbuKAmXQgc2VuZCDigJxzcGxpdF90b2tlbnM6IHRydWXigJ0gdGhlbiB0aGUgQVMg c2VuZHMgYSBzaW5nbGUgdG9rZW4gZm9yIGEgc2luZ2xlIHRva2VuIHJlcXVlc3QsIGFuZCBtdWx0 aXBsZSB0b2tlbnMgZm9yIGEgbXVsdGlwbGUgdG9rZW4gcmVxdWVzdCwgZXhhY3RseSBtYXBwZWQg dG8gd2hhdCB0aGUgY2xpZW50IHJlcXVlc3RlZCBpbiBlYWNoIHJlc291cmNlcyBibG9jay4gSWYg dGhlIGNsaWVudCBhc2tzIGZvciByZXNvdXJjZXMgdGhhdCBjcm9zcyBkb21haW5zIGluIGEgd2F5 IHRoYXQgQVMgY2Fu4oCZdCBzdXBwb3J0LCBpdCByZXR1cm5zIGFuIGVycm9yLg0KDQpUaGUgc3lu dGF4IG5lZWRzIHdvcmssIGJ1dCBpdCB3b3VsZCBhdCBsZWFzdCBhbGxvdyBib3RoIG1vZGVzIG9m IG9wZXJhdGlvbi4gQW5kIGl0IGNvbGxhcHNlcyBuaWNlbHkgaW50byB0aGUgc2luZ2xlLXRva2Vu IHVzZSBjYXNlLCB3aGljaCBpcyBvbmUgb2YgbXkgZ29hbHMgaGVyZS4gSSBkb27igJl0IHdhbnQg YSBjbGllbnQgdG8gYXNrIGZvciAxIHRva2VuIGFuZCBnZXQgMiBvciBhc2sgZm9yIDIgdG9rZW5z IGFuZCBnZXQgMywgdW5sZXNzIGl04oCZcyBmdWxseSBwcmVwYXJlZCBmb3IgdGhhdC4NCg0KV291 bGQgc29tZXRoaW5nIGxpa2UgdGhhdCBmbHkgZm9yIHlvdT8NCg0KIOKAlCBKdXN0aW4NCg0KPiBP biBNYXIgMTksIDIwMjAsIGF0IDk6MzcgQU0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVk dTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQo+DQo+IEkgc2VlIHdoYXQgeW914oCZ cmUgZ29pbmcgZm9yIGhlcmUuIEkgdGhpbmsgdGhlIGtleSBwb2ludCBjb21lcyBkb3duIHRvIHRo aXM6DQo+DQo+PiAtIFRoZSBjbGllbnQga25vd3Mgd2hhdCBpdCB3YW50cyB0byBkbyBhbmQgd2hl cmUNCj4NCj4gVGhhdOKAmXMga25vd2xlZGdlIGlzIGV4YWN0bHkgd2h5IEkgd291bGQgYXJndWUg dGhhdCB0aGUgY2xpZW50IHdvdWxkIGhhdmUgdG8gZXhwbGljaXRseSByZXF1ZXN0IG11bHRpcGxl IGFjY2VzcyB0b2tlbnMgaW4gb3JkZXIgdG8gZ2V0IHRoZW0uDQo+DQo+IEnigJltIHdvcnJpZWQg YWJvdXQgcmVxdWlyaW5nIGFsbCBjbGllbnRzIHRvIGJlIHByZXBhcmVkIHRvIGFjY2VwdCBtdWx0 aXBsZSBhY2Nlc3MgdG9rZW5zLiBJbiBhIGxvdCBvZiBiaWcgY2xvdWQgZGVwbG95bWVudHMsIGl0 4oCZcyBhYnNvbHV0ZWx5IGJhc2VkIG9uIGxvY2F0aW9uLiBCdXQgdGhhdOKAmXMgbm90IHRoZSBv bmx5IGRpc3BhdGNoIGZvciBzZWN1cml0eSBkb21haW5zLiBBIGNsaWVudCB3b3VsZCBuZWVkIHRv IGtub3csIHVsdGltYXRlbHksIHdoYXQgYSB0b2tlbiBpcyBmb3IgYW5kIHdoZXJlIHRvIHVzZSBp dC4gQW5kIHdl4oCZZCBhbHNvIG5lZWQgdG8gZGVhbCB3aXRoIGNhc2VzIHRoYXQgYWxsb3cgZm9y IHN1YmRvbWFpbnMsIHBhdGhzLCBxdWVyeSBwYXJhbWV0ZXJzLCBhbmQgb3RoZXIgdmFyaWFiaWxp dHkgb2YgYW4gQVBJ4oCZcyBVUkxzLiBBZnRlciBhbGwsIEnigJltIHByb2JhYmx5IGdvaW5nIHRv IHNlbmQgdGhhdCBzYW1lIHRva2VuIHRvIGEgYnVuY2ggb2YgZGlmZmVyZW50IFVSTHMgaW4gb3Jk ZXIgdG8gZG8gYSBidW5jaCBvZiBkaWZmZXJlbnQgdGhpbmdzLCBldmVuIGlmIHRoZXnigJlyZSBh bGwgd2l0aGluIHRoZSBzYW1lIOKAnFJT4oCdIG9yIOKAnGRvbWFpbuKAnSBvciB3aGF0ZXZlci4g V2hpY2ggYnJpbmdzIHVzIHRvIGFuIHVuZGVybHlpbmcgcHJvYmxlbSDigJQgSSBkb27igJl0IHRo aW5rIHRoZXJl4oCZcyBhIGdvb2Qgd2F5IHRvIHJlZmVyZW5jZSB0aGUgaWRlbnRpdHkgb2YgYW4g UlMuIFNvbGlkIGlzIGF0dGVtcHRpbmcgdG8gZG8gdGhhdCB1c2luZyBXZWJJROKAmXMgYXMgc2Vy dmljZSBpZGVudGlmaWVycywgYW5kIHdoaWxlIHRoYXTigJlzIGludGVyZXN0aW5nLCBpdOKAmXMg ZGVlcGx5IHRpZWQgdG8gdGhlaXIgc3lzdGVtIHdoZXJlIGV2ZXJ5dGhpbmcga25vd3Mgd2hhdCBh IFdlYklEIGlzIGFuZCB3aGF0IHRvIGRvIHdpdGggaXQuIEkgdGhpbmsgaXTigJlzIGEgYmFkIGlk ZWEgdG8gZGVwZW5kIG9uIHRoYXQga2luZCBvZiB0aGluZyBmb3IgYSBnZW5lcmFsIHB1cnBvc2Ug c3lzdGVtLg0KPg0KPiBJ4oCZbSBoZXNpdGFudCB0byBoYXZlIGNsaWVudHMgZGVwZW5kIG9uIGJl aW5nIHRvbGQgdGhhdCBpbmZvcm1hdGlvbi4gSSB0aGluayBpZiB3ZSBnbyBkb3duIHRoYXQgcm91 dGUgd2XigJlyZSBnb2luZyB0byBoYXZlIHRvIGFsc28gdGVsbCBjbGllbnRzIHRoaW5ncyBsaWtl IOKAnHRoaXMgaXMgb25seSBnb29kIGZvciBHRVQgcmVxdWVzdHPigJ0gYW5kIOKAnHRoaXMgaXMg Z29vZCBmb3Igc3ViZG9tYWlucyBvbiB0aGlzIGxvY2F0aW9u4oCdIGFuZCDigJx0aGlzIGNhbiBi ZSB1c2VkIGZvciBhbnl0aGluZyBleGNlcHQgdGhpcyBvbmUgZXhjZXB0aW9u4oCdLiBBbmQgaXQg ZG9lc27igJl0IGZpdCB3ZWxsIHdoZW4geW914oCZcmUgdHJ5aW5nIHRvIG1peCB0d28gZGlmZmVy ZW50IEFQSXMgdGhhdCBoYXZlIHJlYWxseSBkaWZmZXJlbnQgc3RydWN0dXJlcy4gVGhpbmdzIGxp a2UgR3JhcGhRTCBhbmQgUkVTVCBsZWFkIHRvIHByZXR0eSBkaWZmZXJlbnQgVVJMIGRlc2lnbnMs IGFuZCBUeEF1dGggc2hvdWxkIGJlIHVzYWJsZSBmb3IgYWxsIG9mIHRoYXQuIEl0IGZlZWxzIGxp a2UgdG9vIG11Y2ggYXV0b21hdGVkIGNvbmZpZ3VyYXRpb24gb2YgYSBjbGllbnQgaW5zdGVhZCBv ZiB0aGUgY2xpZW50IGp1c3Qg4oCcZG9pbmcgc29tZXRoaW5n4oCdLCB3aGljaCBJIHRoaW5rIGlz IGdvaW5nIHRvIGJlIHRoZSBjb21tb24gY2FzZS4gSW4gb3RoZXIgd29yZHMsIEkgZG8gdGhpbmsg dGhhdCB0aGUgY2xpZW50IHNvZnR3YXJlIGlzIGdvaW5nIHRvIGJlIGJlc3Bva2UgZm9yIHRoZSBB UEkgdGhhdCBpdOKAmXMgY2FsbGluZy4gSG93ZXZlciwgdGhlIHNlY3VyaXR5IGxpYnJhcnkgdGhh dCBzcGVha3MgdGhlIFR4QXV0aCBwaWVjZSBkb2VzbuKAmXQgaGF2ZSB0byBiZSwgYW5kIHRoZSBw cm90b2NvbCBpdHNlbGYgZG9lc27igJl0IG5lZWQgdG8gYmUuIEJ1dCB0aGUgcHJvdG9jb2xzIHNo b3VsZCBhbGxvdyB0aGUgY2xpZW50IHNvZnR3YXJlIHRvIGV4cHJlc3MgdG8gdGhlIHNlY3VyaXR5 IGxheWVyIHdoYXQgaXQga25vd3MgYWJvdXQgdGhlIEFQSS4NCj4NCj4gQW5kIHNwZWFraW5nIG9m IGNvbW1vbiBjYXNlcywgSSB0aGluayBpdOKAmXMgYWN0dWFsbHkgbXVjaCBtb3JlIHJhcmUgdG8g aGF2ZSBtdWx0aXBsZSBzZWN1cml0eSBkb21haW5zIGNvdmVyZWQgYnkgYW4gQVMgaW4gYSB3YXkg dGhhdCB3b3VsZCBuZWVkIG11bHRpcGxlIGVuY3J5cHRpb25zIG9yIHRhcmdldHMuIEkgdGhpbmsg bWFueSBvZiB1cyBzZWUgaXQgYmVjYXVzZSB3ZSB3b3JrIHdpdGggbGFyZ2UgZW50ZXJwcmlzZS1z Y2FsZSBzeXN0ZW1zIHdpdGggbXVsdGlwbGUgZG9tYWlucyB0aGF0IHdlIHdhbnQgdG8gbWFuYWdl IGFsbCBhdCBvbmNlLiBJbiBteSBleHBlcmllbmNlLCBpdOKAmXMgbXVjaCBtb3JlIGNvbW1vbiB0 byBoYXZlIGEgY2xpZW50IHRhbGsgdG8gb25lIEFTIHRvIGdldCBvbmUgdG9rZW4gZm9yIG9uZSBS Uy4gT25lIG9mIG15IGdvYWxzIHdpdGggdGhpcyBpcyB0byBub3QgbWFrZSBpdCBjb21wbGljYXRl ZCBmb3Igc2ltcGxlIGNsaWVudHMsIGFuZCBJIHRoaW5rIGhhdmluZyB0byBiZSBwcmVwYXJlZCB0 byBnZXQgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBpcyB0b28gY29tcGxleCBmb3Igc2ltcGxlIGNs aWVudHMuIEkgbWlnaHQgYmUgd3JvbmcsIGJ1dCBpdOKAmXMgYmFzZWQgb24gbXkgZXhwZXJpZW5j ZSBhY3Jvc3MgYSBsb3Qgb2YgZGlmZmVyZW50IGtpbmRzIG9mIEFQSXMuIFRoZSBpZGVhIG9mIHNw bGl0dGluZyB1cCB0b2tlbnMgbGlrZSBiZWxvdyBmZWVscyBSRUFMTFkgY29tcGxleCwgZXNwZWNp YWxseSB3aGVuIEkgYXNrZWQgZm9yIGEgc2luZ2xlIG9uZS4gSSBnZXQgd2h5IHlvdSB3YW50IHRv IGRvIGl0LCBpdCBtYWtlcyBzZW5zZSBmb3IgdGhlIEFTIHRvIGJlIGFibGUgdG8gZG8gc29tZXRo aW5nIGxpa2UgdGhhdCwgYnV0IGZyb20gYSBjbGllbnTigJlzIHBlcnNwZWN0aXZlIGl04oCZcyBh IGxvdCBtb3JlIGNvbXBsaWNhdGVkIHdpdGhvdXQgYSBjbGVhciBpZGVhIG9mIHdoYXQgdGhlIGlk ZW50aXR5IG9mIGFuIFJTIGlzLiBJIHRoaW5rIHNvbHZpbmcgdGhhdCBwcm9ibGVtIGlzIGEgSFVH RSBpc3N1ZSB0aGF0IHdlIHNob3VsZCBwdXQgZmlybWx5IG91dCBvZiBzY29wZS4NCj4NCj4gVGhl IHRoaW5nIGlzLCB0aG91Z2gsIHlvdeKAmXJlIGFic29sdXRlbHkgcmlnaHQgdGhhdCB0aGVyZeKA mXMgYSBuZWVkIGZvciB0aGlzIGtpbmQgb2YgbXVsdGlwbGUgdG9rZW5zLiBTbyBpbiBteSB2aWV3 LCB0aGUgbGlmdCBvZiBoYXZpbmcgYSBjbGllbnQga25vdyBhYm91dCB0aGUgZG9tYWlucyB0aGF0 IGl04oCZcyBjYWxsaW5nIGlzIGEgbG90IGxlc3MgdGhhbiB0aGUgY2xpZW50IGhhdmluZyB0byBw b3RlbnRpYWxseSBkZWFsIHdpdGggbW9yZSB0b2tlbnMgdGhhbiBpdCBhc2tlZCBmb3IsIGFuZCBr bm93aW5nIGhvdyB0byBjb3JyZWN0bHkgZGlzcGF0Y2ggdGhvc2UuIEFsc28gdGhlIHNlbWFudGlj cyBvZiB3aGF0IHRoZSDigJxyZXNvdXJjZXPigJ0gb2JqZWN0IHJlcHJlc2VudHMgY2hhbmdlcywg c2luY2UgSSBjb3VsZCBwb3RlbnRpYWxseSBiZSBnZXR0aW5nIHR3byB0b2tlbnMgYmFjayB0aGF0 IGRvIHBhcnRzIG9mIHRoZSBvbmUgdGhpbmcgdGhhdCBJIGFza2VkIGZvciwgYW5kIHRoZSBjbGll bnQgbm93IG5lZWRzIHRvIGtub3cgd2hpY2ggdG8gdXNlIGZvciB3aGF0LiBJZiB0aGUgY2xpZW50 IGhhcyB0byBuYW1lIHRoZSBzcGxpdHMgaXRzZWxmLCB0aGF0IGltcGxpZXMgdGhlIGNsaWVudCBr bm93cyB3aGF0IGVhY2gg4oCccmVzb3VyY2Vz4oCdIHN1Yi1vYmplY3QgcmVwcmVzZW50cyBhbmQg a25vd3MgaG93IHRvIGFwcGx5IHRoYXQgdG8gaXRzIOKAnGNhbGwgdGhlIEFQSeKAnSBjb2RlLiBU aGUgc2VjdXJpdHkgbGF5ZXIgZG9lc27igJl0IGtub3cgb3IgY2FyZSwgYnV0IHRoZSBjb2RlIHRo YXQga25vd3MgaG93IHRvIG1hbmlwdWxhdGUgdGhlIEFQSSBhbmQgaXRzIGRhdGEga25vd3MgYW5k IGNhcmVzLg0KPg0KPiBBcyBmb3IgdGhlIHRva2VuIGNvbnRlbnQg4oCUIHRoYXTigJlzIHNvbGlk bHkgYW4gaW1wbGVtZW50YXRpb24gZGVjaXNpb24gYW5kIG9ydGhvZ29uYWwgdG8gdGhpcyBkaXNj dXNzaW9uLiBZb3UgY2FuIGRvIGFsbCBvZiB0aGlzIG11bHRpIGFjY2VzcyB0b2tlbiBzdHVmZiB3 aXRoIGludHJvc3BlY3Rpb24gYW5kIHJlZmVyZW5jZS1iYXNlZCB0b2tlbnMuIEFjY2VzcyB0b2tl bnMgdGhlbXNlbHZlcyBuZWVkIHRvIHN0YXkgb3BhcXVlIHRvIHRoZSBjbGllbnQgYW5kIHRvIHRo ZSBwcm90b2NvbCBhdCBsYXJnZS4gSSBkb27igJl0IGJlbGlldmUgdGhhdOKAmXMgdXAgZm9yIGRl YmF0ZS4NCj4NCj4gVGhhbmtzIHNvIG11Y2ggZm9yIHB1c2hpbmcgdGhpcyBjb252ZXJzYXRpb24s IGFuZCBub3cgSeKAmW0gbW9yZSBjb252aW5jZWQgdGhhbiBldmVyIHRoYXQgaGFuZGxpbmcgbXVs dGlwbGUgdG9rZW5zIGluIHRoZSByZXNwb25zZSBpcyBzb21ldGhpbmcgd2UgbmVlZCB0byBmaWd1 cmUgb3V0IHdpdGhpbiB0aGlzIGdyb3VwLg0KPg0KPiDigJQgSnVzdGluDQo+DQo+PiBPbiBNYXIg MTcsIDIwMjAsIGF0IDU6MjIgQU0sIFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4+IHdyb3RlOg0KPj4NCj4+ IEhpIEp1c3RpbiwNCj4+DQo+PiB0aGFua3MgZm9yIGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVudCBv cHRpb25zLiBJ4oCZbSB3ZWxsIGF3YXJlIG9mIHRoZSBzdXBlciByZWZyZXNoIHRva2VuIChhbmQg cmVtZW1iZXIgdGhlIGRpc2N1c3Npb25zIGJhY2sgdGhlbiBpbiBUYWlwZWkgOi0pKSwgSSBoYXZl IGltcGxlbWVudGVkIHN5c3RlbXMgdXNpbmcgdGhpcyBhbmQgb3RoZXIgcGF0dGVybnMsIHRvby4N Cj4+DQo+PiBUaGUgdW5kZXJseWluZyBhc3N1bXB0aW9uIGZvciBtb3N0IG9mIHRob3NlIHBhdHRl cm5zIGlzIHRoYXQgdGhlIGNsaWVudCB1cGZyb250IGtub3dzIHRoZSBib3VuZGFyaWVzIGJldHdl ZW4gUlMgc2VjdXJpdHkgZG9tYWlucywgd2hpY2ggdHlwaWNhbGx5IG1lYW5zIHRoZSBzb2x1dGlv biBpcyBiZXNwb2tlbi4NCj4+DQo+PiBUWEF1dGggaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBw cm90b2NvbCBhbmQgbm90IGEgZnJhbWV3b3JrLiBXaGF0IEnigJltIGxvb2tpbmcgZm9yIGlzIGlu dGVyb3BlcmFibGUgcHJvdG9jb2wgc3VwcG9ydCBmb3IgdXNlIG9mIFJTLXNwZWNpZmljIHNlbGYt Y29udGFpbmVkIGFjY2VzcyB0b2tlbnMgaW4gbXVsdGktUlMgZGVwbG95bWVudHMuDQo+Pg0KPj4g V2h5IFJTLXNwZWNpZmljIHNlbGYtY29udGFpbmVkIGFjY2VzcyB0b2tlbnM/DQo+PiBUaGlzIGlz IGluIG15IGV4cGVyaWVuY2UgdGhlIG1vc3QgZWZmaWNpZW50IHdheSB0byBlbXBvd2VyIGhpZ2gt dm9sdW1lL2hpZ2gtbG9hZCBzZXJ2aWNlcyBpbiBhIHZlcnkgZWZmaWNpZW50LCBzZWN1cmUsIGFu ZCBwcml2YWN5IHByZXNlcnZpbmcgZmFzaGlvbi4NCj4+DQo+PiAtIEV2ZXJ5IHRva2VuIGNvbnRh aW5zIGV4YWN0bHkgdGhlIGRhdGEgdGhlIFJTIG5lZWRzIHRvIHBlcmZvcm0gYWNjZXNzIGNvbnRy b2wgZGVjaXNpb25zIGxvY2FsbHkuIE5vIG5lZWQgZm9yIGZ1cnRoZXIgZGF0YWJhc2UgbG9va3Vw cyBvciBBUyBjYWxsYmFja3MsIHRoYXTigJlzIHJlYWxseSBmYXN0IGFuZCBrZWVwcyBjb3N0IG9m IHRoZSBBUyBmdW5jdGlvbiBsb3cuLg0KPj4gLSBUaGUgdG9rZW4gaXRzZWxmIGNhbiBiZSBlbmNy eXB0ZWQgdG8gcHJvdGVjdCB0aGlzIGRhdGEgdXNpbmcgYSBSUy1zcGVjaWZpYyBrZXksIG9uZSBj b3VsZCBldmVuIHVzZSBITUFDcyB0byBwcm90ZWN0IGludGVncml0eSBhbmQgYXV0aGVudGljaXR5 IChmYXN0IGFzIHdlbGwpLg0KPj4gLSBUaGUgdG9rZW4gY2FuIGhhdmUgYSBSUy1zcGVjaWZpYyBs aWZldGltZS4NCj4+IC0gU2luY2UgZXZlcnkgdG9rZW4gaXMgcmVzdHJpY3RlZCB0byBhIHNpbmds ZSBSUyBhdWRpZW5jZSwgdGhvc2UgdG9rZW5zIGFsc28gaGF2ZSBhIGJhc2VsaW5lIHJlcGxheSBk ZXRlY3Rpb24gYnVpbHQtaW4uDQo+Pg0KPj4gSSB0aGluayB0aGlzIHBhdHRlcm4gbWFrZXMgc2Vu c2UgaW4gZW52aXJvbm1lbnRzIHdpdGggbXVsdGlwbGUgUlNzIChlLmcuIGRpZmZlcmVudCBwcm9k dWN0cykgYXMgd2VsbC4gQnV0IHNpbmNlIGV2ZXJ5IHRva2VuIGlzIG1pbnRlZCB0byB0aGUgc3Bl Y2lmaWMgcmVxdWlyZW1lbnRzIG9mIGEgY2VydGFpbiBSUywgdGhlIEFTIG11c3QgYmUgYWJsZSB0 byBtaW50IGRpZmZlcmVudCB0b2tlbnMuIFRoYXQgZG9lc27igJl0IHdvcmsgcHJvcGVybHkgd2l0 aG91dCBzb21lIHN1cHBvcnQgaW4gdGhlIHByb3RvY29sLg0KPj4NCj4+IElzIHRoZXJlIGEgbmVl ZCBmb3IgbXVsdGkgYWNjZXNzIHRva2VucyBzdXBwb3J0Pw0KPj4gV2VsbCwgeW91IGltcGxlbWVu dGVkIGl0LCBJIGltcGxlbWVudGVkIGl0LCBhbmQgSSB0aGluayBhIGNvdXBsZSBvZiBvdGhlciBp bXBsZW1lbnRlcnMgZGlkIGl0IHdpdGggT0F1dGggMiBpbiB0aGUgcGFzdC4gU28gdGhlcmUgc2Vl bXMgdG8gYmUgc29tZSBuZWVkLiBXaHkgZG9lcyB0aGUgcmVzdCB1c2UgdGhlIHNpbmdsZSB0b2tl biBwYXR0ZXJuPyBJIHRoaW5rIHNvbWUgZGVwbG95bWVudHMgd2lsbCBpbmRlZWQgb25seSBoYXZl IGEgc2luZ2xlIHNlcnZpY2UsIGJ1dCBJIGJldCBhIGxvdCBvZiBpbXBsZW1lbnRlcnMgZGlkIGl0 IGJlY2F1c2UgdGhlaXIgcHJvZHVjdCBkb2VzIG5vdCBzdXBwb3J0IGFueXRoaW5nIGVsc2UuDQo+ Pg0KPj4gSSBoYXZlIGV4cGVyaWVuY2VkIHRoaXMgbXlzZWxmIHdoZW4gSSBkZXNpZ25lZCB0aGUg YXJjaGl0ZWN0dXJlIG9mIHRoZSB5ZXMgZWNvc3lzdGVtLiBJdCBpcyBhIGZlZGVyYXRpb24gb2Yg YXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHdpdGggYXNzb2NpYXRlZCBzZXJ2aWNlcyB3aGVyZSBldmVy eSBBUyByZXByZXNlbnRzIGEgY2VydGFpbiBiYW5rLiBTaW5jZSBvdXIgcGFydG5lcnMgc2hhbGwg YmUgYWJsZSB0byBpbXBsZW1lbnQgdGhlaXIgQVMgdXNpbmcgdGhlIHByb2R1Y3QgdGhleSBsaWtl LCBJIG5lZWRlZCB0byBnbyB3aXRoIHRoZSBsZWFzdCBjb21tb24gZGVub21pbmF0b3IgLSBzaW5n bGUgYWNjZXNzIHRva2VuLiBUaGlzIGhhcyBhIHNpZ25pZmljYW50IGNvbnNlcXVlbmNlczogb3Vy IHRva2VucyBhcmUgYmFzaWNhbGx5IGhhbmRsZXMsIHNvIGV2ZXJ5IHNlcnZpY2UgY2FsbHMgYmFj ayB0byB0aGUgQVMgdG8gb2J0YWluIGl0cyBkYXRhIGZvciBldmVyeSBzZXJ2aWNlIHJlcXVlc3Qu IFRoaXMgZGVncmFkZXMgcGVyZm9ybWFuY2Ugc2lnbmlmaWNhbnRseSBhbmQsIHNpbmNlIHRob3Nl IHRva2VucyBhcmUgZ29vZCBmb3IgbXVsdGkgYXVkaWVuY2VzLCBpdCBmb3JjZXMgdXMgdG8gZ2Vu ZXJhbGx5IHVzZSBzZW5kZXIgY29uc3RyYWluZWQgdG9rZW5zLCB3aGljaCBpbmNyZWFzZXMgY29t cGxleGl0eSBmb3IgY2xpZW50cy4NCj4+DQo+PiBJIHdvdWxkIGxpa2UgdG8gZ2l2ZSBpbXBsZW1l bnRlcnMgbW9yZSBvcHRpb25zIGluIHRoZSBUWEF1dGggc3BhY2UuLiBUaGF04oCZcyB3aHkgSSBh ZHZvY2F0ZSB0byBidWlsZC1pbiBzdXBwb3J0IGbDvHIgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBp bnRvIFRYQXV0aC4NCj4+DQo+PiBNeSBwcm9wb3NhbCBpcyBiYXNlZCBvbiB0aGUgZm9sbG93aW5n IGFzc3VtcHRpb25zOg0KPj4gLSBUb2tlbiBmb3JtYXQsIGNvbnRlbnQsIGVuY3J5cHRpb24ga2V5 cyBhbmQgc28gb24gYXJlIGRlZmluZWQgYXMgcGFydCBvZiB0aGUgaW50ZXJmYWNlIGJldHdlZW4g QVMgYW5kIFJTDQo+PiAtIFRoZSBjbGllbnQga25vd3Mgd2hhdCBpdCB3YW50cyB0byBkbyBhbmQg d2hlcmUNCj4+IC0gRXZlcnkgcGFydHkgY29udHJpYnV0ZXMgdGhlIGluZm9ybWF0aW9uIGl0IGhh cyB0byB0aGUgb3ZlcmFsbCBwcm9jZXNzIHRvIG1ha2UgaXQgd29yayBzaW1wbHkgYW5kIGVmZmVj dGl2ZWx5IGZvciBldmVyeW9uZS4NCj4+DQo+PiBUaGVyZSBpcyBubyBjaGFuZ2UvYWRkaXRpb24g bmVlZGVkIHRvIHRoZSByZXF1ZXN0IHN5bnRheC4gQWxsIGl0IHRha2VzIGlzIHlvdXIgbmV3IG11 bHRpIHRva2VuIHN5bnRheCAoKyBhIHNtYWxsIGFkZGl0aW9uKSBpbiB0aGUgcmVzcG9uc2UuDQo+ Pg0KPj4gVGhlIGNsaWVudCB1c2VzIHRoZSDigJxyZXNvdXJjZXMiIHN0cnVjdHVyZSB0byBjb21t dW5pY2F0ZSB3aGF0IChhY3Rpb25zLCBmdXJ0aGVyIGVsZW1lbnRzKSBpdCB3YW50cyB0byBkbyBh bmQgd2hlcmUgKGxvY2F0aW9ucykuDQo+Pg0KPj4gWw0KPj4gICB7DQo+PiAgICAg4oCcYWN0aW9u cyI6IFsicmVhZCIsICJ3cml0ZSJdLA0KPj4gICAgICJsb2NhdGlvbnMiOiBbImh0dHBzOi8vZXhh bXBsZS5jb20vcmVzb3VyY2UiXSwNCj4+ICAgICDigJxkYXRhIjogWyJmb28iLCAiYmFyIl0NCj4+ ICAgfSwNCj4+ICAgew0KPj4gICAgIOKAnGFjdGlvbnMiOiBbIndyaXRlIl0sDQo+PiAgICAgImxv Y2F0aW9ucyI6IFsiaHR0cHM6Ly9vdGhlcl9leGFtcGxlLmNvbS9yZXNvdXJjZSJdLA0KPj4gICAg IOKAnGRhdGEiOiBbImZvbyIsICJiYXIiXQ0KPj4gICB9DQo+PiBdDQo+Pg0KPj4gT25lIGRlcGxv eW1lbnQgbWlnaHQgdXNlIGEgc2luZ2xlIHRva2VuIGZvciBhbGwgUlNzLCBpbiB0aGlzIGNhc2Ug dGhlIHRva2VuIHJlc3BvbnNlIHJlbWFpbnMgdW5jaGFuZ2VkOg0KPj4NCj4+IHsNCj4+ICJhY2Nl c3NfdG9rZW4iOnsNCj4+ICAidmFsdWUiOiIwOHVyNGthaGZnYTA5dTIzcm5ramFzZGYiLA0KPj4g ICJ0eXBlIjoiYmVhcmVyIg0KPj4gfQ0KPj4gfQ0KPj4NCj4+IElmIHRoZSBBUyBoYXMgdGhlIG5l ZWQgdG8gaXNzdWUgbXVsdGlwbGUgYWNjZXNzIHRva2VucywgaXQgY291bGQsIGZvciBleGFtcGxl LCB1c2UgdGhlIOKAnGxvY2F0aW9ucyIgZWxlbWVudHMgdG8gZGV0ZXJtaW5lIHdoYXQgdG9rZW5z IGl0IG5lZWRzIHRvIGNyZWF0ZS4gU3VjaCBhbiBBUyB0aGVuIHVzZXMgdGhlIG11bHRpcGxlX2Fj Y2Vzc190b2tlbnMgc3RydWN0dXJlIGF1Z21lbnRlZCBieSBjb3JyZXNwb25kaW5nICJsb2NhdGlv bnPigJ0gZW50cmllcyBpbiB0aGUgdG9rZW4gcmVzcG9uc2U6DQo+Pg0KPj4gIm11bHRpcGxlX2Fj Y2Vzc190b2tlbnMiOnsNCj4+ICAidG9rZW5fYSI6ew0KPj4gICAgInZhbHVlIjoiT1M5TTJQTUhL VVI2NFRCOE42Qlc3T1pCOENERk9OUDIxOVJQMUxUMCIsDQo+PiAgICAidHlwZSI6ImJlYXJlciIs DQo+PiAgICAibG9jYXRpb25zIjpbDQo+PiAgICAgICJodHRwczovL2V4YW1wbGUuY29tL3Jlc291 cmNlIg0KPj4gICAgXQ0KPj4gIH0sDQo+PiAgInRva2VuX2IiOnsNCj4+ICAgICJ2YWx1ZSI6IlVG R0xPMkZEQUZHN1ZHWlpQSjNJWkVNTjIxRVZVNzFGSENBUlA0SjEiLA0KPj4gICAgInR5cGUiOiJi ZWFyZXIiLA0KPj4gICAgImxvY2F0aW9ucyI6Ww0KPj4gICAgICAiaHR0cHM6Ly9vdGhlcl9leGFt cGxlLmNvbS9yZXNvdXJjZSINCj4+ICAgIF0NCj4+ICB9DQo+PiB9DQo+Pg0KPj4gU2luY2UgdGhl IGNsaWVudCBwYXNzZWQgdGhlIGxvY2F0aW9ucyB2YWx1ZXMgaW4gdGhlIHJlcXVlc3QsIGl0IGlz IGFsc28gYWJsZSB0byBkZXRlcm1pbmUgd2hlcmUgdG8gdXNlIHdoYXQgYWNjZXNzIHRva2VuLg0K Pj4NCj4+IEkgdGhpbmsgdGhhdOKAmXMgcHJldHR5IHNpbXBsZSwgZXNwZWNpYWxseSBmcm9tIGEg Y2xpZW50IHBlcnNwZWN0aXZlLg0KPj4NCj4+IEFuZCBJZiB0aGUgY2xpZW50IHdhbnRzIHRvIHNw bGl0IGFjY2VzcyB0b2tlbnMgZnVydGhlciBhcGFydCwgZS5nLiB0byBvYnRhaW4gdG9rZW5zIHdp dGggbGVzcyBwcml2aWxlZ2VzLCBpdCBjYW4gZG8gc28gdXNpbmcgdGhlIHJlcXVlc3Qgc3ludGF4 IHlvdSBkZWZpbmVkOg0KPj4NCj4+IHJlc291cmNlczogew0KPj4gIHRva2VuMTogW3sNCj4+ICAg ICAgICAgIGFjdGlvbnM6IFsicmVhZCIsICJ3cml0ZSIsICJkb2xwaGluIl0sDQo+PiAgICAgICAg ICBsb2NhdGlvbnM6IFsiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvIiwgImh0dHBzOi8vcmVz b3VyY2UubG9jYWwvb3RoZXIiXSwNCj4+ICAgICAgICAgIGRhdGF0eXBlczogWyJtZXRhZGF0YSIs ICJpbWFnZXMiXQ0KPj4gICB9XSwNCj4+ICAgdG9rZW4yOiBbew0KPj4gICAgICAgICAgYWN0aW9u czogWyJmb28iLCAiYmFyIiwgImRvbHBoaW4iXSwNCj4+ICAgICAgICAgIGxvY2F0aW9uczogWyJo dHRwczovL3Jlc291cmNlLi5vdGhlci88aHR0cHM6Ly9yZXNvdXJjZS5vdGhlci8+Il0sDQo+PiAg ICAgICAgICBkYXRhdHlwZXM6IFsiZGF0YSIsICJwaWN0dXJlcyJdDQo+PiAgIH1dDQo+PiB9DQo+ Pg0KPj4gSW4gdGhlIHNpbXBsZXN0IGNhc2UsIHRoZSBBUyB3b3VsZCByZXR1cm4gdGhlIGRhdGEg YXMgaW4geW91ciBwcm9wb3NhbC4NCj4+DQo+PiBJZiB0aGUgY2xpZW50IGFza3MgZm9yIGEgcGFy dGl0aW9uaW5nIG9mIHByaXZpbGVnZXMgdGhhdCBnb2VzIGFjcm9zcyBSUyBzZWN1cml0eSBkb21h aW5zIGxpa2UgdGhpcw0KPj4NCj4+IHsNCj4+ICJyZXNvdXJjZXMiOnsNCj4+ICAidG9rZW4xIjpb DQo+PiAgICB7DQo+PiAgICAgICJhY3Rpb25zIjpbICJyZWFkIiwgIndyaXRlIiwiZG9scGhpbiIg XSwNCj4+ICAgICAgImxvY2F0aW9ucyI6WyAiaHR0cHM6Ly9zZXJ2ZXIuLmV4YW1wbGUubmV0Lzxo dHRwczovL3NlcnZlci5leGFtcGxlLm5ldC8+IiwiaHR0cHM6Ly9yZXNvdXJjZS5sb2NhbC9vdGhl ciJdLA0KPj4gICAgICAiZGF0YXR5cGVzIjpbICJtZXRhZGF0YSIsImltYWdlcyJdDQo+PiAgICB9 LA0KPj4gICAgew0KPj4gICAgICAiYWN0aW9ucyI6WyJyZWFkIiwid3JpdGUiXSwNCj4+ICAgICAg ImxvY2F0aW9ucyI6WyJodHRwczovL2V4YW1wbGUuY29tL3Jlc291cmNlIl0NCj4+ICAgIH0NCj4+ ICBdLA0KPj4gICJ0b2tlbjIiOlsNCj4+ICAgIHsNCj4+ICAgICAgImFjdGlvbnMiOlsiZm9vIiwi YmFyIiwgImRvbHBoaW4iXSwNCj4+ICAgICAgImxvY2F0aW9ucyI6WyJodHRwczovL3Jlc291cmNl Lm90aGVyLyJdLA0KPj4gICAgICAiZGF0YXR5cGVzIjpbImRhdGEiLCJwaWN0dXJlcyJdDQo+PiAg ICB9DQo+PiAgXQ0KPj4gfQ0KPj4gfQ0KPj4NCj4+IHRoZSBBUyB3b3VsZCBuZWVkIHRvIGZ1cnRo ZXIgcGFydGl0aW9uIHRoZSBwcmUtZGVmaW5lZCB0b2tlbnMgbGlrZSB0aGlzOg0KPj4NCj4+ICJt dWx0aXBsZV9hY2Nlc3NfdG9rZW5z4oCdOnsNCj4+ICDigJx0b2tlbjEvYSI6ew0KPj4gICAgInZh bHVlIjoiT1M5TTJQTUhLVVI2NFRCOE42Qlc3T1pCOENERk9OUDIxOVJQMUxUMCIsDQo+PiAgICAi dHlwZSI6ImJlYXJlciIsDQo+PiAgICAibG9jYXRpb25zIjpbImh0dHBzOi8vc2VydmVyLmV4YW1w bGUuLm5ldC88aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvPiIsImh0dHBzOi8vcmVzb3VyY2Uu bG9jYWwvb3RoZXIiXQ0KPj4gIH0sDQo+PiAg4oCcdG9rZW4xL2IiOnsNCj4+ICAgICJ2YWx1ZSI6 Ik9TOU0yUE1IS1VSNjRUQjhONkJXN09aQjhDREZPTlAyMTlSUDFMVDAiLA0KPj4gICAgInR5cGUi OiJiZWFyZXIiLA0KPj4gICAgImxvY2F0aW9ucyI6WyJodHRwczovL2V4YW1wbGUuY29tL3Jlc291 cmNlIl0NCj4+ICB9LA0KPj4gIOKAnHRva2VuMiI6ew0KPj4gICAgInZhbHVlIjoiVUZHTE8yRkRB Rkc3VkdaWlBKM0laRU1OMjFFVlU3MUZIQ0FSUDRKMSIsDQo+PiAgICAidHlwZSI6ImJlYXJlciIs DQo+PiAgICAibG9jYXRpb25zIjpbDQo+PiAgICAgICJodHRwczovL290aGVyX2V4YW1wbGUuY29t L3Jlc291cmNlIg0KPj4gICAgXQ0KPj4gIH0NCj4+IH0NCj4+DQo+PiBOYW1pbmcgb2YgdGhlIHRv a2VucyBpcyBhIGJpdCB0cmlja3kgYnV0IEkgdGhpbmsgc29sdmFibGUuDQo+Pg0KPj4gV2hhdCBk byB5b3UgdGhpbms/DQo+Pg0KPj4gYmVzdCByZWdhcmRzLA0KPj4gVG9yc3Rlbi4NCj4+DQo+Pj4g T24gMTUuIE1hciAyMDIwLCBhdCAxNToyNiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1 PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCj4+Pg0KPj4+IE9uIE1hciAxNSwgMjAy MCwgYXQgODo1OCBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBP biAxNS4gTWFyIDIwMjAsIGF0IDAzOjI1LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8 bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IFNvIGlmIHRoZSBB UyBuZWVkcyBhIGNsaWVudCB0byBnZXQgZGlmZmVyZW50IGFjY2VzcyB0b2tlbnMgdG8gY2FsbCBk aWZmZXJlbnQgUlMgZG9tYWlucywgaXQgZG9lcyBleGFjdGx5IHdoYXQgd2UgZG8gaW4gT0F1dGgg MiB0b2RheSDigJQgaXQgdGVsbHMgdGhlIGNsaWVudCB0byBnZXQgdHdvIGRpZmZlcmVudCBhY2Nl c3MgdG9rZW5zLg0KPj4+Pg0KPj4+PiBIb3cgZG9lcyB0aGlzIHdvcmsgaW4gWFlaPw0KPj4+Pg0K Pj4+DQo+Pj4gV2l0aG91dCB1c2luZyB0aGUgbXVsdGktYWNjZXNzLXRva2VuIHRoaW5nIEnigJlt IHByb3Bvc2luZyBpbiB0aGlzIHRocmVhZCwgdGhlIGNsaWVudCB3b3VsZCBqdXN0IG1ha2UgdHdv IHNlcGFyYXRlIHRyYW5zYWN0aW9uIGNhbGxzIHRvIGdldCB0d28gZGlmZmVyZW50IHRva2Vucy4g VGhlcmXigJlzIGEgZmV3IHdheXMgdGhhdCBzaGFrZXMgb3V0IGRlcGVuZGluZyBvbiBzb21lIG9m IHRoZSBkZXRhaWxzLiBJbiB0aGUgT0F1dGggd29ybGQgdGhhdCBhbW91bnRzIHRvIGludm9sdmlu ZyB0aGUgdXNlciB0d2ljZSwgYW5kIGl0IG1pZ2h0IGJlIHRoZSBzYW1lIGluIFhZWiBpZiB5b3Xi gJlyZSBhc2tpbmcgZm9yIGRpZmZlcmVudCB0aGluZ3M6DQo+Pj4NCj4+PiAxLiBDbGllbnQ6IFN0 YXJ0IFRYLTEgKFItMSkNCj4+PiAyLiBVc2VyOiBBcHByb3ZlIFItMQ0KPj4+IDMuIEFTOiBJc3N1 ZSBBVC0xKFItMSkNCj4+PiA0LiBDbGllbnQ6IFN0YXJ0IFRYLTIgKFItMSkNCj4+PiA1LiBVc2Vy OiBhcHByb3ZlIFItMg0KPj4+IDYuIEFTOiBJc3N1ZSBBVC0yKFItMikNCj4+Pg0KPj4+IFVubGVz cyB5b3XigJlyZSBnZXR0aW5nIGEgc3VwZXIgcmVmcmVzaCB0b2tlbiB1cGZyb250IGFuZCB0aGVu IGNhbGxpbmcgZm9yIHR3byBkb3duZ3JhZGVkIGFjY2VzcyB0b2tlbnMgbGF0ZXIg4oCUIHdoaWNo IGRvZXMgd29yaywgYW5kIEnigJl2ZSBidWlsdCBvdXQgc3lzdGVtcyB0aGF0IGRvIGV4YWN0bHkg dGhhdC4gWFlaIGNhbiBkbyB0aGF0IHRyaWNrIHRvby4NCj4+Pg0KPj4+IDEuIENsaWVudDogU3Rh cnQgVFgtMSAoUi0xLCBSLTIpDQo+Pj4gMi4gVXNlcjogQXBwcm92ZSBSLTEsIFItMg0KPj4+IDMu IEFTOiBJc3N1ZSBBVDEgKFItMSwgUi0yKQ0KPj4+IDQuIENsaWVudDogQ29udGludWUgVFgtMSAo Ui0yKQ0KPj4+IDUuIEFTOiBJc3N1ZSBBVC0yIChSLTIpDQo+Pj4NCj4+PiBCdXQgd2XigJl2ZSBn b3QgYW5vdGhlciB0aGluZyB3ZSBjYW4gdXNlIGluIFhZWiB0byBoZWxwIHRoaXMsIHRoZSB1c2Vy IGhhbmRsZS4gVGhpcyBsZXRzIGEgdHJ1c3RlZCBjbGllbnQgdGVsbCB0aGUgQVMgdGhhdCBpdCBi ZWxpZXZlcyB0aGUgc2FtZSB1c2VyIGlzIHN0aWxsIHRoZXJlIGFuZCBhc2tpbmcgdGhlIHF1ZXN0 aW9uLCBzbyBpZiB0aGUgYWNjZXNzIHJpZ2h0cyBhcmUgT0sgdGhlbiB5b3UgZG9u4oCZdCBuZWVk IHRvIGludm9sdmUgdGhlIHVzZXIgYWdhaW4uIFdlIGludmVudGVkIHRoaXMgY29uc3RydWN0IHdp dGggVU1BMiwgd2hlcmUgaXTigJlzIGNhbGxlZCB0aGUgcGVyc2lzdGVkIGNsYWltcyB0b2tlbiAo UENUKS4NCj4+Pg0KPj4+IDEuIENsaWVudDogU3RhcnQgVFgtMSAoUi0xKQ0KPj4+IDIuIFVzZXI6 IEFwcHJvdmUgUi0xDQo+Pj4gMy4gQVM6IElzc3VlIEFULTEgKFItMSksIHVzZXIgaGFuZGxlIFUt MQ0KPj4+IDQuIENsaWVudCBTdGFydCBUWC0yIChSLTIsIFUtMSkNCj4+PiA1LiBBUzogSXNzdWUg QVQtMiAoUi0yKQ0KPj4+DQo+Pj4gTm93OiBXaXRoIHRoZSBtdWx0aS10b2tlbiByZXF1ZXN0LCB3 ZSBjYW4gY29sbGFwc2UgdGhpcyBhbGwgYmFjayB0byBhIHNpbmdsZSB0cmFuc2FjdGlvbiB3aXRo IG11bHRpcGxlIG91dHB1dHM6DQo+Pj4NCj4+PiAxLiBDbGllbnQ6IFN0YXJ0IFRYLTIgKHRva2Vu MTogUi0xLCB0b2tlbjI6IFItMikNCj4+PiAyLiBVc2VyIEFwcHJvdmUgUi0xLCBSLTINCj4+PiAz LiBBUzogSXNzdWUgQVQtMSAodG9rZW4xOiBSLTEpLCBBVC0yICh0b2tlbjI6IFItMikNCj4+Pg0K Pj4+IEkgaGF2ZW7igJl0IGxpa2VkIGFueSBvZiB0aGUgbXVsdGktYWNjZXNzLXRva2VuIHNvbHV0 aW9ucyB0byBkYXRlIGJlY2F1c2UgdGhleSBtYWtlIHRoaW5ncyB3ZWlyZCBmb3Igc2luZ2xlIGFj Y2VzcyB0b2tlbiByZXF1ZXN0cy4gSSBsaWtlIHRoaXMgaWRlYSBiZWNhdXNlIGl04oCZcyBhbiBv cHRpbWl6YXRpb24gZm9yIGEgY29tcGxleCBjYXNlIHRoYXQgZG9lc27igJl0IGNoYW5nZSB0aGUg YmVoYXZpb3IgZm9yIHRoZSBzaW1wbGUgY2FzZSwgYW5kIGluIGZhY3QgZG9lc27igJl0IGV2ZW4g Y2hhbmdlIHRoZSBleHBlY3RhdGlvbnMgZm9yIHRoZSBzaW1wbGUgY2FzZS4gVG8gbWUsIHRoYXTi gJlzIGltcG9ydGFudC4NCj4+Pg0KPj4+IOKAlCBKdXN0aW4NCj4+DQo+DQo+IC0tDQo+IFR4YXV0 aCBtYWlsaW5nIGxpc3QNCj4gVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCi0tDQpU eGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo= --_000_A81FDB11C05F49E09FA63A2C420282B5amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6E9EFE69236DED4AB8794D9291ABEE59@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYWxz byBvcHBvc2VkIHRvIHJlcXVpcmluZyBDbGllbnRzIHRvIHN1cHBvcnQgYXJiaXRyYXJpbHkgc3Bs aXQgYWNjZXNzIHRva2Vucy4gSWYgd2UgYXJlIHRvIHN1cHBvcnQgbXVsdGlwbGUgYWNjZXNzIHRv a2Vucywgd2UgbmVlZCB0byBkbyBzbyBpbiBhIHdheSB0aGF0IGRvZXMgbm90IGFkdmVyc2VseSBp bXBhY3QgdGhlIG1hbnkgZGVwbG95bWVudHMgZm9yIHdoaWNoIHRoZXkgYXJlIGFuIHVubmVjZXNz YXJ5DQogY29tcGxpY2F0aW9uLiBTZWNvbmRpbmcgRGlja+KAmXMgY29tbWVudCB0aGF0IOKAnHNw bGl0X3Rva2Vuc+KAnSBpcyBvdmVybHkgY29tcGxleC4gSXQgZmVlbHMgdG8gbWUgbGlrZSB0aGUg c29ydCBvZiBvcHRpb24gdGhhdCB3b3VsZCBodXJ0IGludGVyb3BlcmFiaWxpdHkgaW4gdGhlIGxv bmcgcnVuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhbnQgdG8gbWFrZSBzdXJlIHdlIGFy ZSBub3QgcG9zaXRpb25pbmcgbXVsdGlwbGUgYWNjZXNzIHRva2VucyBhcyBhIG5lY2Vzc2FyeSBy ZXF1aXJlbWVudCBmb3IgQVNlcyB0aGF0IHN1cHBvcnQgbXVsdGlwbGUgUlNlcy4gVGhlcmUgYXJl IG90aGVyIHdheXMgdG8gZG8gdGhhdCwgZWFjaCB3aXRoIGRpZmZlcmVudCBwcm9zIGFuZCBjb25z IHRoYXQgY2Fu4oCZdCBiZSBwcm9wZXJseSBldmFsdWF0ZWQgb3V0c2lkZQ0KIHRoZSBjb250ZXh0 IG9mIGFuIGFjdHVhbCBwcm90b2NvbCwgYW5kIGV2ZW4gdGhlbiBkaWZmZXJlbnQgZGVwbG95bWVu dHMgbWF5IHdlaWdoIHRob3NlIHByb3MgYW5kIGNvbnMgZGlmZmVyZW50bHkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNpbWlsYXJseSwgd2Ugc2hvdWxkIG5vdCBiZSBjb25zdHJhaW5pbmcgaG93 IEFTZXMgYW5kIFJTZXMgc2hhcmUgaW5mb3JtYXRpb24uIEFnYWluLCBkaWZmZXJlbnQgZGVwbG95 bWVudHMgd2lsbCBjYWxsIGZvciBkaWZmZXJlbnQgYXBwcm9hY2hlcy4gSSBkbyBsaWtlIEp1c3Rp buKAmXMgc3VnZ2VzdGlvbiAocGVyaGFwcyBvbiBhbm90aGVyIHRocmVhZD8pIG9mIHN0YW5kYXJk aXppbmcgYSBzY2hlbWEgdGhhdCB0b2tlbg0KIGNsYWltcywgQVBJIHJlc3VsdHMsIGV0Yy4gY291 bGQgYWRoZXJlIHRvLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPuKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Bbm5hYmVsbGUgQmFja21h biAoc2hlL2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxhIGhyZWY9Imh0dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvIj48c3BhbiBzdHls ZT0iY29sb3I6IzA1NjNDMSI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9pZGVudGl0eS88L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBNYXJjaCAyMCwgMjAyMCBhdCAxMTozNyBBTTxicj4NCjxi PlRvOiA8L2I+SnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkNj OiA8L2I+VG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7 LCAmcXVvdDt0eGF1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtFWFRFUk5BTF0gW1R4YXV0aF0gTXVsdGlwbGUgQWNjZXNz IFRva2VucyBpbiBYWVo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjYyMiIgc3R5bGU9 IndpZHRoOjQ2Ni41cHQ7bWFyZ2luLWxlZnQ6LjVpbjtib3JkZXItY29sbGFwc2U6Y29sbGFwc2Ui Pg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMjVwdCI+DQo8dGQgd2lkdGg9IjYyMiIg dmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDo0NjYuNXB0O2JvcmRlcjpzb2xpZCAjRUQ3RDMxIDEu NXB0O3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdDtoZWlnaHQ6MTUuMjVwdCI+DQo8cD48c3Ry b25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDojRkZGRjk5Ij5DQVVUSU9OPC9zcGFuPjwvc3Ryb25n PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOiNGRkZGOTkiPjogVGhpcyBlbWFp bCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xp Y2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MNCiB5b3UgY2FuIGNvbmZpcm0gdGhl IHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkkgYWdyZWUgd2l0aCBKdXN0aW4gdGhhdCB0aGUgQ2xpZW50IHVuZXhwZWN0ZWRseSBnZXR0 aW5nIHNwbGl0IGFjY2VzcyB0b2tlbnMgaXMgdW5kZXNpcmFibGUuDQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSBhZ3JlZSB3aXRoIE1pa2UgYW5kIFRvcnN0ZW4gdGhh dCB0b2tlbnMgc2hvdWxkIGJlIHNlbGYgY29udGFpbmVkLCBhbmQgYWJsZSB0byBiZSBpbmRlcGVu ZGVudCBiZXR3ZWVuIHJlc291cmNlcy4gSSB3b3VsZCBhZGQgdGhhdCB0aGV5IHNob3VsZCBiZSBh cyBmaW5lIGdyYWluZWQgYXMgcHJhY3RpY2FsLCB3aGljaCBpcyBwYXJ0IG9mIHRoZSBjaGFydGVy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlJhdGhlciB0 aGVuIHRoZSBjbGllbnQgdGhpbmtpbmcmbmJzcDtpdCBpcyBnZXR0aW5nIG11bHRpcGxlIGFjY2Vz cyB0b2tlbnMsIGhvdyBhYm91dCB0aGlua2luZyBvZiB0aGUgY2xpZW50IGdldHRpbmcgYWNjZXNz IHRvIG11bHRpcGxlIHJlc291cmNlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5UaGUgQVMgcHJvdmlkZXMgYW4gYWNjZXNzIHRva2VuIGZvciBlYWNoIHJl c291cmNlLiBUaGUgYWNjZXNzIHRva2VucyBtYXkgYWxsIGJlIHRoZSBzYW1lLCBhbGwgYmUgZGlm ZmVyZW50LCBvciBhIG1peC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5UaGUgQ2xpZW50IGRvZXMgbm90IG5lZWQgdG8ga25vdyB3aGljaCBvbmVzIGFyZSB0 aGUgc2FtZSBvciBkaWZmZXJlbnQgYWhlYWQgb2YgdGltZSwgYnV0IGl0IGRvZXMga25vdyB3aGlj aCBvbmUgaXQgd2lsbCB1c2UgZm9yIGFjY2Vzc2luZyB3aGljaCByZXNvdXJjZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIGRvbid0IHRoaW5rIHRoZXJl IGlzIGEgbmVlZCBmb3IgYSAmcXVvdDtzcGxpdF90b2tlbnMmcXVvdDsgZmxhZy4gVGhhdCBzb3Vu ZHMgb3Zlcmx5IGNvbXBsaWNhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIEZyaSwgTWFyIDIwLCAyMDIwIGF0 IDc6NTkgQU0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVk dSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+U28gZnVuZGFtZW50YWxseSwgSSBkb27igJl0IHdhbnQgdGhlIEFTIHRvIGFsbG93ZWQgdG8g c3BsaXQgdG9rZW5zIHdoZW4gdGhlIGNsaWVudCBpc27igJl0IGV4cGVjdGluZyBpdC4gV291bGQg YSBzaW1wbGUgZmVhdHVyZSBmbGFnIHRvIGFsbG93IHRoYXQgYmVoYXZpb3IgYXQgdGhlIEFTIGJl IGVub3VnaCB0byBzd2l0Y2ggYm90aCBjYXNlcz8NCjxicj4NCjxicj4NClNvIGxldOKAmXMgc2F5 IHdlJm5ic3A7IGp1c3QgZG8gdGhlIHNpbXBsZSB0aGluZyBhbmQgbWFrZSBpdCBhIGJvb2xlYW4g dG9wLWxldmVsIGZsYWcuIElmIHRoZSBjbGllbnQgc2VuZHMg4oCcc3BsaXRfdG9rZW5zOiB0cnVl 4oCdIHRoZW4gdGhlIEFTIGFsd2F5cyByZXR1cm5zIHRoZSDigJxtdWx0aXBsZV9hY2Nlc3NfdG9r ZW5z4oCdIHN0cnVjdHVyZSBhbmQgaXQgY29tZXMgdXAgd2l0aCB3aGF0ZXZlciBuYW1lcyBpdCBt YWtlcyBzZW5zZSBmb3IgdGhlIHJlc3VsdGluZyB0b2tlbnMuDQogVGhlIGNsaWVudCBjYW4gZG8g ZWl0aGVyIHRoZSBzaW5nbGUgb3IgbXVsdGlwbGUgdG9rZW4gcmVxdWVzdCBzdHlsZS4gVGhlIGNs aWVudCBuZWVkcyB0byBiZSBhYmxlIHRvIGZpZ3VyZSBvdXQgZnJvbSB0aGUgdG9rZW4gcmVzcG9u c2VzIGhvdyB0byBwdXQgd2hpY2ggdG9rZW4gaW4gd2hpY2ggcGxhY2UsIGFuZCBJIHRoaW5rIHdl IGNhbiBkbyBzb21lIHRoaW5ncyB3aXRoIHRoZSBndXRzIG9mIHRoZSDigJxyZXNvdXJjZXPigJ0g cmVxdWVzdCBvYmplY3QsDQogbGlrZSB1c2luZyDigJxsb2NhdGlvbnPigJ0gYW5kIG1heWJlIG90 aGVyIGZpZWxkcy4gSWYgdGhlIGNsaWVudCBkb2VzbuKAmXQgc2VuZCDigJxzcGxpdF90b2tlbnM6 IHRydWXigJ0gdGhlbiB0aGUgQVMgc2VuZHMgYSBzaW5nbGUgdG9rZW4gZm9yIGEgc2luZ2xlIHRv a2VuIHJlcXVlc3QsIGFuZCBtdWx0aXBsZSB0b2tlbnMgZm9yIGEgbXVsdGlwbGUgdG9rZW4gcmVx dWVzdCwgZXhhY3RseSBtYXBwZWQgdG8gd2hhdCB0aGUgY2xpZW50IHJlcXVlc3RlZCBpbiBlYWNo DQogcmVzb3VyY2VzIGJsb2NrLiBJZiB0aGUgY2xpZW50IGFza3MgZm9yIHJlc291cmNlcyB0aGF0 IGNyb3NzIGRvbWFpbnMgaW4gYSB3YXkgdGhhdCBBUyBjYW7igJl0IHN1cHBvcnQsIGl0IHJldHVy bnMgYW4gZXJyb3IuPGJyPg0KPGJyPg0KVGhlIHN5bnRheCBuZWVkcyB3b3JrLCBidXQgaXQgd291 bGQgYXQgbGVhc3QgYWxsb3cgYm90aCBtb2RlcyBvZiBvcGVyYXRpb24uIEFuZCBpdCBjb2xsYXBz ZXMgbmljZWx5IGludG8gdGhlIHNpbmdsZS10b2tlbiB1c2UgY2FzZSwgd2hpY2ggaXMgb25lIG9m IG15IGdvYWxzIGhlcmUuIEkgZG9u4oCZdCB3YW50IGEgY2xpZW50IHRvIGFzayBmb3IgMSB0b2tl biBhbmQgZ2V0IDIgb3IgYXNrIGZvciAyIHRva2VucyBhbmQgZ2V0IDMsIHVubGVzcyBpdOKAmXMN CiBmdWxseSBwcmVwYXJlZCBmb3IgdGhhdC48YnI+DQo8YnI+DQpXb3VsZCBzb21ldGhpbmcgbGlr ZSB0aGF0IGZseSBmb3IgeW91Pzxicj4NCjxicj4NCiZuYnNwO+KAlCBKdXN0aW48YnI+DQo8YnI+ DQomZ3Q7IE9uIE1hciAxOSwgMjAyMCwgYXQgOTozNyBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0 LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHNlZSB3aGF0IHlvdeKA mXJlIGdvaW5nIGZvciBoZXJlLiBJIHRoaW5rIHRoZSBrZXkgcG9pbnQgY29tZXMgZG93biB0byB0 aGlzOjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgLSBUaGUgY2xpZW50IGtub3dzIHdoYXQgaXQg d2FudHMgdG8gZG8gYW5kIHdoZXJlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXTigJlzIGtub3ds ZWRnZSBpcyBleGFjdGx5IHdoeSBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIGNsaWVudCB3b3VsZCBo YXZlIHRvIGV4cGxpY2l0bHkgcmVxdWVzdCBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIGluIG9yZGVy IHRvIGdldCB0aGVtLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEnigJltIHdvcnJpZWQgYWJvdXQg cmVxdWlyaW5nIGFsbCBjbGllbnRzIHRvIGJlIHByZXBhcmVkIHRvIGFjY2VwdCBtdWx0aXBsZSBh Y2Nlc3MgdG9rZW5zLiBJbiBhIGxvdCBvZiBiaWcgY2xvdWQgZGVwbG95bWVudHMsIGl04oCZcyBh YnNvbHV0ZWx5IGJhc2VkIG9uIGxvY2F0aW9uLiBCdXQgdGhhdOKAmXMgbm90IHRoZSBvbmx5IGRp c3BhdGNoIGZvciBzZWN1cml0eSBkb21haW5zLiBBIGNsaWVudCB3b3VsZCBuZWVkIHRvIGtub3cs IHVsdGltYXRlbHksDQogd2hhdCBhIHRva2VuIGlzIGZvciBhbmQgd2hlcmUgdG8gdXNlIGl0LiBB bmQgd2XigJlkIGFsc28gbmVlZCB0byBkZWFsIHdpdGggY2FzZXMgdGhhdCBhbGxvdyBmb3Igc3Vi ZG9tYWlucywgcGF0aHMsIHF1ZXJ5IHBhcmFtZXRlcnMsIGFuZCBvdGhlciB2YXJpYWJpbGl0eSBv ZiBhbiBBUEnigJlzIFVSTHMuIEFmdGVyIGFsbCwgSeKAmW0gcHJvYmFibHkgZ29pbmcgdG8gc2Vu ZCB0aGF0IHNhbWUgdG9rZW4gdG8gYSBidW5jaCBvZiBkaWZmZXJlbnQgVVJMcyBpbg0KIG9yZGVy IHRvIGRvIGEgYnVuY2ggb2YgZGlmZmVyZW50IHRoaW5ncywgZXZlbiBpZiB0aGV54oCZcmUgYWxs IHdpdGhpbiB0aGUgc2FtZSDigJxSU+KAnSBvciDigJxkb21haW7igJ0gb3Igd2hhdGV2ZXIuIFdo aWNoIGJyaW5ncyB1cyB0byBhbiB1bmRlcmx5aW5nIHByb2JsZW0g4oCUIEkgZG9u4oCZdCB0aGlu ayB0aGVyZeKAmXMgYSBnb29kIHdheSB0byByZWZlcmVuY2UgdGhlIGlkZW50aXR5IG9mIGFuIFJT LiBTb2xpZCBpcyBhdHRlbXB0aW5nIHRvIGRvIHRoYXQgdXNpbmcNCiBXZWJJROKAmXMgYXMgc2Vy dmljZSBpZGVudGlmaWVycywgYW5kIHdoaWxlIHRoYXTigJlzIGludGVyZXN0aW5nLCBpdOKAmXMg ZGVlcGx5IHRpZWQgdG8gdGhlaXIgc3lzdGVtIHdoZXJlIGV2ZXJ5dGhpbmcga25vd3Mgd2hhdCBh IFdlYklEIGlzIGFuZCB3aGF0IHRvIGRvIHdpdGggaXQuIEkgdGhpbmsgaXTigJlzIGEgYmFkIGlk ZWEgdG8gZGVwZW5kIG9uIHRoYXQga2luZCBvZiB0aGluZyBmb3IgYSBnZW5lcmFsIHB1cnBvc2Ug c3lzdGVtLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEnigJltIGhlc2l0YW50IHRvIGhhdmUgY2xp ZW50cyBkZXBlbmQgb24gYmVpbmcgdG9sZCB0aGF0IGluZm9ybWF0aW9uLiBJIHRoaW5rIGlmIHdl IGdvIGRvd24gdGhhdCByb3V0ZSB3ZeKAmXJlIGdvaW5nIHRvIGhhdmUgdG8gYWxzbyB0ZWxsIGNs aWVudHMgdGhpbmdzIGxpa2Ug4oCcdGhpcyBpcyBvbmx5IGdvb2QgZm9yIEdFVCByZXF1ZXN0c+KA nSBhbmQg4oCcdGhpcyBpcyBnb29kIGZvciBzdWJkb21haW5zIG9uIHRoaXMgbG9jYXRpb27igJ0g YW5kIOKAnHRoaXMgY2FuDQogYmUgdXNlZCBmb3IgYW55dGhpbmcgZXhjZXB0IHRoaXMgb25lIGV4 Y2VwdGlvbuKAnS4gQW5kIGl0IGRvZXNu4oCZdCBmaXQgd2VsbCB3aGVuIHlvdeKAmXJlIHRyeWlu ZyB0byBtaXggdHdvIGRpZmZlcmVudCBBUElzIHRoYXQgaGF2ZSByZWFsbHkgZGlmZmVyZW50IHN0 cnVjdHVyZXMuIFRoaW5ncyBsaWtlIEdyYXBoUUwgYW5kIFJFU1QgbGVhZCB0byBwcmV0dHkgZGlm ZmVyZW50IFVSTCBkZXNpZ25zLCBhbmQgVHhBdXRoIHNob3VsZCBiZSB1c2FibGUgZm9yDQogYWxs IG9mIHRoYXQuIEl0IGZlZWxzIGxpa2UgdG9vIG11Y2ggYXV0b21hdGVkIGNvbmZpZ3VyYXRpb24g b2YgYSBjbGllbnQgaW5zdGVhZCBvZiB0aGUgY2xpZW50IGp1c3Qg4oCcZG9pbmcgc29tZXRoaW5n 4oCdLCB3aGljaCBJIHRoaW5rIGlzIGdvaW5nIHRvIGJlIHRoZSBjb21tb24gY2FzZS4gSW4gb3Ro ZXIgd29yZHMsIEkgZG8gdGhpbmsgdGhhdCB0aGUgY2xpZW50IHNvZnR3YXJlIGlzIGdvaW5nIHRv IGJlIGJlc3Bva2UgZm9yIHRoZSBBUEkgdGhhdA0KIGl04oCZcyBjYWxsaW5nLiBIb3dldmVyLCB0 aGUgc2VjdXJpdHkgbGlicmFyeSB0aGF0IHNwZWFrcyB0aGUgVHhBdXRoIHBpZWNlIGRvZXNu4oCZ dCBoYXZlIHRvIGJlLCBhbmQgdGhlIHByb3RvY29sIGl0c2VsZiBkb2VzbuKAmXQgbmVlZCB0byBi ZS4gQnV0IHRoZSBwcm90b2NvbHMgc2hvdWxkIGFsbG93IHRoZSBjbGllbnQgc29mdHdhcmUgdG8g ZXhwcmVzcyB0byB0aGUgc2VjdXJpdHkgbGF5ZXIgd2hhdCBpdCBrbm93cyBhYm91dCB0aGUgQVBJ Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBBbmQgc3BlYWtpbmcgb2YgY29tbW9uIGNhc2VzLCBJIHRo aW5rIGl04oCZcyBhY3R1YWxseSBtdWNoIG1vcmUgcmFyZSB0byBoYXZlIG11bHRpcGxlIHNlY3Vy aXR5IGRvbWFpbnMgY292ZXJlZCBieSBhbiBBUyBpbiBhIHdheSB0aGF0IHdvdWxkIG5lZWQgbXVs dGlwbGUgZW5jcnlwdGlvbnMgb3IgdGFyZ2V0cy4gSSB0aGluayBtYW55IG9mIHVzIHNlZSBpdCBi ZWNhdXNlIHdlIHdvcmsgd2l0aCBsYXJnZSBlbnRlcnByaXNlLXNjYWxlIHN5c3RlbXMgd2l0aA0K IG11bHRpcGxlIGRvbWFpbnMgdGhhdCB3ZSB3YW50IHRvIG1hbmFnZSBhbGwgYXQgb25jZS4gSW4g bXkgZXhwZXJpZW5jZSwgaXTigJlzIG11Y2ggbW9yZSBjb21tb24gdG8gaGF2ZSBhIGNsaWVudCB0 YWxrIHRvIG9uZSBBUyB0byBnZXQgb25lIHRva2VuIGZvciBvbmUgUlMuIE9uZSBvZiBteSBnb2Fs cyB3aXRoIHRoaXMgaXMgdG8gbm90IG1ha2UgaXQgY29tcGxpY2F0ZWQgZm9yIHNpbXBsZSBjbGll bnRzLCBhbmQgSSB0aGluayBoYXZpbmcgdG8gYmUgcHJlcGFyZWQNCiB0byBnZXQgbXVsdGlwbGUg YWNjZXNzIHRva2VucyBpcyB0b28gY29tcGxleCBmb3Igc2ltcGxlIGNsaWVudHMuIEkgbWlnaHQg YmUgd3JvbmcsIGJ1dCBpdOKAmXMgYmFzZWQgb24gbXkgZXhwZXJpZW5jZSBhY3Jvc3MgYSBsb3Qg b2YgZGlmZmVyZW50IGtpbmRzIG9mIEFQSXMuIFRoZSBpZGVhIG9mIHNwbGl0dGluZyB1cCB0b2tl bnMgbGlrZSBiZWxvdyBmZWVscyBSRUFMTFkgY29tcGxleCwgZXNwZWNpYWxseSB3aGVuIEkgYXNr ZWQgZm9yIGEgc2luZ2xlDQogb25lLiBJIGdldCB3aHkgeW91IHdhbnQgdG8gZG8gaXQsIGl0IG1h a2VzIHNlbnNlIGZvciB0aGUgQVMgdG8gYmUgYWJsZSB0byBkbyBzb21ldGhpbmcgbGlrZSB0aGF0 LCBidXQgZnJvbSBhIGNsaWVudOKAmXMgcGVyc3BlY3RpdmUgaXTigJlzIGEgbG90IG1vcmUgY29t cGxpY2F0ZWQgd2l0aG91dCBhIGNsZWFyIGlkZWEgb2Ygd2hhdCB0aGUgaWRlbnRpdHkgb2YgYW4g UlMgaXMuIEkgdGhpbmsgc29sdmluZyB0aGF0IHByb2JsZW0gaXMgYSBIVUdFIGlzc3VlDQogdGhh dCB3ZSBzaG91bGQgcHV0IGZpcm1seSBvdXQgb2Ygc2NvcGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoZSB0aGluZyBpcywgdGhvdWdoLCB5b3XigJlyZSBhYnNvbHV0ZWx5IHJpZ2h0IHRoYXQgdGhl cmXigJlzIGEgbmVlZCBmb3IgdGhpcyBraW5kIG9mIG11bHRpcGxlIHRva2Vucy4gU28gaW4gbXkg dmlldywgdGhlIGxpZnQgb2YgaGF2aW5nIGEgY2xpZW50IGtub3cgYWJvdXQgdGhlIGRvbWFpbnMg dGhhdCBpdOKAmXMgY2FsbGluZyBpcyBhIGxvdCBsZXNzIHRoYW4gdGhlIGNsaWVudCBoYXZpbmcg dG8gcG90ZW50aWFsbHkgZGVhbCB3aXRoIG1vcmUgdG9rZW5zDQogdGhhbiBpdCBhc2tlZCBmb3Is IGFuZCBrbm93aW5nIGhvdyB0byBjb3JyZWN0bHkgZGlzcGF0Y2ggdGhvc2UuIEFsc28gdGhlIHNl bWFudGljcyBvZiB3aGF0IHRoZSDigJxyZXNvdXJjZXPigJ0gb2JqZWN0IHJlcHJlc2VudHMgY2hh bmdlcywgc2luY2UgSSBjb3VsZCBwb3RlbnRpYWxseSBiZSBnZXR0aW5nIHR3byB0b2tlbnMgYmFj ayB0aGF0IGRvIHBhcnRzIG9mIHRoZSBvbmUgdGhpbmcgdGhhdCBJIGFza2VkIGZvciwgYW5kIHRo ZSBjbGllbnQgbm93IG5lZWRzDQogdG8ga25vdyB3aGljaCB0byB1c2UgZm9yIHdoYXQuIElmIHRo ZSBjbGllbnQgaGFzIHRvIG5hbWUgdGhlIHNwbGl0cyBpdHNlbGYsIHRoYXQgaW1wbGllcyB0aGUg Y2xpZW50IGtub3dzIHdoYXQgZWFjaCDigJxyZXNvdXJjZXPigJ0gc3ViLW9iamVjdCByZXByZXNl bnRzIGFuZCBrbm93cyBob3cgdG8gYXBwbHkgdGhhdCB0byBpdHMg4oCcY2FsbCB0aGUgQVBJ4oCd IGNvZGUuIFRoZSBzZWN1cml0eSBsYXllciBkb2VzbuKAmXQga25vdyBvciBjYXJlLCBidXQgdGhl IGNvZGUNCiB0aGF0IGtub3dzIGhvdyB0byBtYW5pcHVsYXRlIHRoZSBBUEkgYW5kIGl0cyBkYXRh IGtub3dzIGFuZCBjYXJlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgZm9yIHRoZSB0b2tlbiBj b250ZW50IOKAlCB0aGF04oCZcyBzb2xpZGx5IGFuIGltcGxlbWVudGF0aW9uIGRlY2lzaW9uIGFu ZCBvcnRob2dvbmFsIHRvIHRoaXMgZGlzY3Vzc2lvbi4gWW91IGNhbiBkbyBhbGwgb2YgdGhpcyBt dWx0aSBhY2Nlc3MgdG9rZW4gc3R1ZmYgd2l0aCBpbnRyb3NwZWN0aW9uIGFuZCByZWZlcmVuY2Ut YmFzZWQgdG9rZW5zLiBBY2Nlc3MgdG9rZW5zIHRoZW1zZWx2ZXMgbmVlZCB0byBzdGF5IG9wYXF1 ZSB0byB0aGUgY2xpZW50DQogYW5kIHRvIHRoZSBwcm90b2NvbCBhdCBsYXJnZS4gSSBkb27igJl0 IGJlbGlldmUgdGhhdOKAmXMgdXAgZm9yIGRlYmF0ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhh bmtzIHNvIG11Y2ggZm9yIHB1c2hpbmcgdGhpcyBjb252ZXJzYXRpb24sIGFuZCBub3cgSeKAmW0g bW9yZSBjb252aW5jZWQgdGhhbiBldmVyIHRoYXQgaGFuZGxpbmcgbXVsdGlwbGUgdG9rZW5zIGlu IHRoZSByZXNwb25zZSBpcyBzb21ldGhpbmcgd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdpdGhpbiB0 aGlzIGdyb3VwLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IOKAlCBKdXN0aW48YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7IE9uIE1hciAxNywgMjAyMCwgYXQgNToyMiBBTSwgVG9yc3RlbiBMb2RkZXJz dGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9 Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBIaSBKdXN0aW4sPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgdGhhbmtzIGZvciBleHBsYWluaW5nIHRoZSBkaWZmZXJlbnQgb3B0aW9ucy4gSeKAmW0gd2Vs bCBhd2FyZSBvZiB0aGUgc3VwZXIgcmVmcmVzaCB0b2tlbiAoYW5kIHJlbWVtYmVyIHRoZSBkaXNj dXNzaW9ucyBiYWNrIHRoZW4gaW4gVGFpcGVpIDotKSksIEkgaGF2ZSBpbXBsZW1lbnRlZCBzeXN0 ZW1zIHVzaW5nIHRoaXMgYW5kIG90aGVyIHBhdHRlcm5zLCB0b28uPGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgVGhlIHVuZGVybHlpbmcgYXNzdW1wdGlvbiBmb3IgbW9zdCBvZiB0aG9zZSBw YXR0ZXJucyBpcyB0aGF0IHRoZSBjbGllbnQgdXBmcm9udCBrbm93cyB0aGUgYm91bmRhcmllcyBi ZXR3ZWVuIFJTIHNlY3VyaXR5IGRvbWFpbnMsIHdoaWNoIHR5cGljYWxseSBtZWFucyB0aGUgc29s dXRpb24gaXMgYmVzcG9rZW4uDQo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUWEF1dGgg aXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBwcm90b2NvbCBhbmQgbm90IGEgZnJhbWV3b3JrLiBX aGF0IEnigJltIGxvb2tpbmcgZm9yIGlzIGludGVyb3BlcmFibGUgcHJvdG9jb2wgc3VwcG9ydCBm b3IgdXNlIG9mIFJTLXNwZWNpZmljIHNlbGYtY29udGFpbmVkIGFjY2VzcyB0b2tlbnMgaW4gbXVs dGktUlMgZGVwbG95bWVudHMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgV2h5IFJTLXNw ZWNpZmljIHNlbGYtY29udGFpbmVkIGFjY2VzcyB0b2tlbnM/IDxicj4NCiZndDsmZ3Q7IFRoaXMg aXMgaW4gbXkgZXhwZXJpZW5jZSB0aGUgbW9zdCBlZmZpY2llbnQgd2F5IHRvIGVtcG93ZXIgaGln aC12b2x1bWUvaGlnaC1sb2FkIHNlcnZpY2VzIGluIGEgdmVyeSBlZmZpY2llbnQsIHNlY3VyZSwg YW5kIHByaXZhY3kgcHJlc2VydmluZyBmYXNoaW9uLg0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0 OyZndDsgLSBFdmVyeSB0b2tlbiBjb250YWlucyBleGFjdGx5IHRoZSBkYXRhIHRoZSBSUyBuZWVk cyB0byBwZXJmb3JtIGFjY2VzcyBjb250cm9sIGRlY2lzaW9ucyBsb2NhbGx5LiBObyBuZWVkIGZv ciBmdXJ0aGVyIGRhdGFiYXNlIGxvb2t1cHMgb3IgQVMgY2FsbGJhY2tzLCB0aGF04oCZcyByZWFs bHkgZmFzdCBhbmQga2VlcHMgY29zdCBvZiB0aGUgQVMgZnVuY3Rpb24gbG93Li48YnI+DQomZ3Q7 Jmd0OyAtIFRoZSB0b2tlbiBpdHNlbGYgY2FuIGJlIGVuY3J5cHRlZCB0byBwcm90ZWN0IHRoaXMg ZGF0YSB1c2luZyBhIFJTLXNwZWNpZmljIGtleSwgb25lIGNvdWxkIGV2ZW4gdXNlIEhNQUNzIHRv IHByb3RlY3QgaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNpdHkgKGZhc3QgYXMgd2VsbCkuDQo8YnI+ DQomZ3Q7Jmd0OyAtIFRoZSB0b2tlbiBjYW4gaGF2ZSBhIFJTLXNwZWNpZmljIGxpZmV0aW1lLjxi cj4NCiZndDsmZ3Q7IC0gU2luY2UgZXZlcnkgdG9rZW4gaXMgcmVzdHJpY3RlZCB0byBhIHNpbmds ZSBSUyBhdWRpZW5jZSwgdGhvc2UgdG9rZW5zIGFsc28gaGF2ZSBhIGJhc2VsaW5lIHJlcGxheSBk ZXRlY3Rpb24gYnVpbHQtaW4uDQo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5r IHRoaXMgcGF0dGVybiBtYWtlcyBzZW5zZSBpbiBlbnZpcm9ubWVudHMgd2l0aCBtdWx0aXBsZSBS U3MgKGUuZy4gZGlmZmVyZW50IHByb2R1Y3RzKSBhcyB3ZWxsLiBCdXQgc2luY2UgZXZlcnkgdG9r ZW4gaXMgbWludGVkIHRvIHRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgb2YgYSBjZXJ0YWluIFJT LCB0aGUgQVMgbXVzdCBiZSBhYmxlIHRvIG1pbnQgZGlmZmVyZW50IHRva2Vucy4gVGhhdCBkb2Vz buKAmXQgd29yayBwcm9wZXJseSB3aXRob3V0DQogc29tZSBzdXBwb3J0IGluIHRoZSBwcm90b2Nv bC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJcyB0aGVyZSBhIG5lZWQgZm9yIG11bHRp IGFjY2VzcyB0b2tlbnMgc3VwcG9ydD8gPGJyPg0KJmd0OyZndDsgV2VsbCwgeW91IGltcGxlbWVu dGVkIGl0LCBJIGltcGxlbWVudGVkIGl0LCBhbmQgSSB0aGluayBhIGNvdXBsZSBvZiBvdGhlciBp bXBsZW1lbnRlcnMgZGlkIGl0IHdpdGggT0F1dGggMiBpbiB0aGUgcGFzdC4gU28gdGhlcmUgc2Vl bXMgdG8gYmUgc29tZSBuZWVkLiBXaHkgZG9lcyB0aGUgcmVzdCB1c2UgdGhlIHNpbmdsZSB0b2tl biBwYXR0ZXJuPyBJIHRoaW5rIHNvbWUgZGVwbG95bWVudHMgd2lsbCBpbmRlZWQgb25seSBoYXZl IGEgc2luZ2xlDQogc2VydmljZSwgYnV0IEkgYmV0IGEgbG90IG9mIGltcGxlbWVudGVycyBkaWQg aXQgYmVjYXVzZSB0aGVpciBwcm9kdWN0IGRvZXMgbm90IHN1cHBvcnQgYW55dGhpbmcgZWxzZS4N Cjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgaGF2ZSBleHBlcmllbmNlZCB0aGlzIG15 c2VsZiB3aGVuIEkgZGVzaWduZWQgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUgeWVzIGVjb3N5c3Rl bS4gSXQgaXMgYSBmZWRlcmF0aW9uIG9mIGF1dGhvcml6YXRpb24gc2VydmVycyB3aXRoIGFzc29j aWF0ZWQgc2VydmljZXMgd2hlcmUgZXZlcnkgQVMgcmVwcmVzZW50cyBhIGNlcnRhaW4gYmFuay4g U2luY2Ugb3VyIHBhcnRuZXJzIHNoYWxsIGJlIGFibGUgdG8gaW1wbGVtZW50IHRoZWlyIEFTIHVz aW5nDQogdGhlIHByb2R1Y3QgdGhleSBsaWtlLCBJIG5lZWRlZCB0byBnbyB3aXRoIHRoZSBsZWFz dCBjb21tb24gZGVub21pbmF0b3IgLSBzaW5nbGUgYWNjZXNzIHRva2VuLiBUaGlzIGhhcyBhIHNp Z25pZmljYW50IGNvbnNlcXVlbmNlczogb3VyIHRva2VucyBhcmUgYmFzaWNhbGx5IGhhbmRsZXMs IHNvIGV2ZXJ5IHNlcnZpY2UgY2FsbHMgYmFjayB0byB0aGUgQVMgdG8gb2J0YWluIGl0cyBkYXRh IGZvciBldmVyeSBzZXJ2aWNlIHJlcXVlc3QuIFRoaXMgZGVncmFkZXMNCiBwZXJmb3JtYW5jZSBz aWduaWZpY2FudGx5IGFuZCwgc2luY2UgdGhvc2UgdG9rZW5zIGFyZSBnb29kIGZvciBtdWx0aSBh dWRpZW5jZXMsIGl0IGZvcmNlcyB1cyB0byBnZW5lcmFsbHkgdXNlIHNlbmRlciBjb25zdHJhaW5l ZCB0b2tlbnMsIHdoaWNoIGluY3JlYXNlcyBjb21wbGV4aXR5IGZvciBjbGllbnRzLg0KPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSB3b3VsZCBsaWtlIHRvIGdpdmUgaW1wbGVtZW50ZXJz IG1vcmUgb3B0aW9ucyBpbiB0aGUgVFhBdXRoIHNwYWNlLi4gVGhhdOKAmXMgd2h5IEkgYWR2b2Nh dGUgdG8gYnVpbGQtaW4gc3VwcG9ydCBmw7xyIG11bHRpcGxlIGFjY2VzcyB0b2tlbnMgaW50byBU WEF1dGguDQo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBNeSBwcm9wb3NhbCBpcyBiYXNl ZCBvbiB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOjxicj4NCiZndDsmZ3Q7IC0gVG9rZW4gZm9y bWF0LCBjb250ZW50LCBlbmNyeXB0aW9uIGtleXMgYW5kIHNvIG9uIGFyZSBkZWZpbmVkIGFzIHBh cnQgb2YgdGhlIGludGVyZmFjZSBiZXR3ZWVuIEFTIGFuZCBSUzxicj4NCiZndDsmZ3Q7IC0gVGhl IGNsaWVudCBrbm93cyB3aGF0IGl0IHdhbnRzIHRvIGRvIGFuZCB3aGVyZTxicj4NCiZndDsmZ3Q7 IC0gRXZlcnkgcGFydHkgY29udHJpYnV0ZXMgdGhlIGluZm9ybWF0aW9uIGl0IGhhcyB0byB0aGUg b3ZlcmFsbCBwcm9jZXNzIHRvIG1ha2UgaXQgd29yayBzaW1wbHkgYW5kIGVmZmVjdGl2ZWx5IGZv ciBldmVyeW9uZS4NCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZXJlIGlzIG5vIGNo YW5nZS9hZGRpdGlvbiBuZWVkZWQgdG8gdGhlIHJlcXVlc3Qgc3ludGF4LiBBbGwgaXQgdGFrZXMg aXMgeW91ciBuZXcgbXVsdGkgdG9rZW4gc3ludGF4ICgmIzQzOyBhIHNtYWxsIGFkZGl0aW9uKSBp biB0aGUgcmVzcG9uc2UuDQo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUaGUgY2xpZW50 IHVzZXMgdGhlIOKAnHJlc291cmNlcyZxdW90OyBzdHJ1Y3R1cmUgdG8gY29tbXVuaWNhdGUgd2hh dCAoYWN0aW9ucywgZnVydGhlciBlbGVtZW50cykgaXQgd2FudHMgdG8gZG8gYW5kIHdoZXJlIChs b2NhdGlvbnMpLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFs8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDt7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO+KAnGFjdGlvbnMm cXVvdDs6IFsmcXVvdDtyZWFkJnF1b3Q7LCAmcXVvdDt3cml0ZSZxdW90O10sPGJyPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2xvY2F0aW9ucyZxdW90OzogWyZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vcmVzb3VyY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2V4YW1wbGUuY29tL3Jlc291cmNlPC9hPiZxdW90O10sPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO+KAnGRhdGEmcXVvdDs6IFsmcXVvdDtmb28mcXVvdDssICZxdW90O2JhciZxdW90 O108YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDt9LDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw O3s8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A74oCcYWN0aW9ucyZxdW90OzogWyZx dW90O3dyaXRlJnF1b3Q7XSw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 bG9jYXRpb25zJnF1b3Q7OiBbJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9vdGhlcl9leGFtcGxlLmNv bS9yZXNvdXJjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vb3RoZXJfZXhhbXBsZS5jb20vcmVz b3VyY2U8L2E+JnF1b3Q7XSw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A74oCcZGF0 YSZxdW90OzogWyZxdW90O2ZvbyZxdW90OywgJnF1b3Q7YmFyJnF1b3Q7XTxicj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jmd0OyBdPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgT25lIGRlcGxveW1lbnQgbWlnaHQgdXNlIGEgc2luZ2xlIHRva2VuIGZvciBhbGwgUlNzLCBp biB0aGlzIGNhc2UgdGhlIHRva2VuIHJlc3BvbnNlIHJlbWFpbnMgdW5jaGFuZ2VkOg0KPGJyPg0K Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgezxicj4NCiZndDsmZ3Q7ICZxdW90O2FjY2Vzc190b2tl biZxdW90Ozp7PGJyPg0KJmd0OyZndDsmbmJzcDsgJnF1b3Q7dmFsdWUmcXVvdDs6JnF1b3Q7MDh1 cjRrYWhmZ2EwOXUyM3Jua2phc2RmJnF1b3Q7LDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZxdW90O3R5 cGUmcXVvdDs6JnF1b3Q7YmVhcmVyJnF1b3Q7PGJyPg0KJmd0OyZndDsgfTxicj4NCiZndDsmZ3Q7 IH08YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJZiB0aGUgQVMgaGFzIHRoZSBuZWVkIHRv IGlzc3VlIG11bHRpcGxlIGFjY2VzcyB0b2tlbnMsIGl0IGNvdWxkLCBmb3IgZXhhbXBsZSwgdXNl IHRoZSDigJxsb2NhdGlvbnMmcXVvdDsgZWxlbWVudHMgdG8gZGV0ZXJtaW5lIHdoYXQgdG9rZW5z IGl0IG5lZWRzIHRvIGNyZWF0ZS4gU3VjaCBhbiBBUyB0aGVuIHVzZXMgdGhlIG11bHRpcGxlX2Fj Y2Vzc190b2tlbnMgc3RydWN0dXJlIGF1Z21lbnRlZCBieSBjb3JyZXNwb25kaW5nICZxdW90O2xv Y2F0aW9uc+KAnSBlbnRyaWVzDQogaW4gdGhlIHRva2VuIHJlc3BvbnNlOiA8YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyAmcXVvdDttdWx0aXBsZV9hY2Nlc3NfdG9rZW5zJnF1b3Q7Ons8YnI+ DQomZ3Q7Jmd0OyZuYnNwOyAmcXVvdDt0b2tlbl9hJnF1b3Q7Ons8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJnF1b3Q7dmFsdWUmcXVvdDs6JnF1b3Q7T1M5TTJQTUhLVVI2NFRCOE42Qlc3T1pC OENERk9OUDIxOVJQMUxUMCZxdW90Oyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJnF1b3Q7 dHlwZSZxdW90OzomcXVvdDtiZWFyZXImcXVvdDssPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZxdW90O2xvY2F0aW9ucyZxdW90OzpbPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmcXVvdDs8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29tL3Jlc291cmNlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9leGFtcGxlLmNvbS9yZXNvdXJjZTwvYT4mcXVvdDs8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgXTxicj4NCiZndDsmZ3Q7Jm5ic3A7IH0sPGJyPg0KJmd0OyZndDsmbmJz cDsgJnF1b3Q7dG9rZW5fYiZxdW90Ozp7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZxdW90 O3ZhbHVlJnF1b3Q7OiZxdW90O1VGR0xPMkZEQUZHN1ZHWlpQSjNJWkVNTjIxRVZVNzFGSENBUlA0 SjEmcXVvdDssPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZxdW90O3R5cGUmcXVvdDs6JnF1 b3Q7YmVhcmVyJnF1b3Q7LDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmcXVvdDtsb2NhdGlv bnMmcXVvdDs6Wzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7PGEgaHJl Zj0iaHR0cHM6Ly9vdGhlcl9leGFtcGxlLmNvbS9yZXNvdXJjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vb3RoZXJfZXhhbXBsZS5jb20vcmVzb3VyY2U8L2E+JnF1b3Q7PGJyPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7IF08YnI+DQomZ3Q7Jmd0OyZuYnNwOyB9PGJyPg0KJmd0OyZndDsgfTxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFNpbmNlIHRoZSBjbGllbnQgcGFzc2VkIHRoZSBsb2Nh dGlvbnMgdmFsdWVzIGluIHRoZSByZXF1ZXN0LCBpdCBpcyBhbHNvIGFibGUgdG8gZGV0ZXJtaW5l IHdoZXJlIHRvIHVzZSB3aGF0IGFjY2VzcyB0b2tlbi4NCjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IEkgdGhpbmsgdGhhdOKAmXMgcHJldHR5IHNpbXBsZSwgZXNwZWNpYWxseSBmcm9tIGEg Y2xpZW50IHBlcnNwZWN0aXZlLiZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBB bmQgSWYgdGhlIGNsaWVudCB3YW50cyB0byBzcGxpdCBhY2Nlc3MgdG9rZW5zIGZ1cnRoZXIgYXBh cnQsIGUuZy4gdG8gb2J0YWluIHRva2VucyB3aXRoIGxlc3MgcHJpdmlsZWdlcywgaXQgY2FuIGRv IHNvIHVzaW5nIHRoZSByZXF1ZXN0IHN5bnRheCB5b3UgZGVmaW5lZDoNCjxicj4NCiZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7IHJlc291cmNlczogezxicj4NCiZndDsmZ3Q7Jm5ic3A7IHRva2VuMTog W3s8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWN0aW9u czogWyZxdW90O3JlYWQmcXVvdDssICZxdW90O3dyaXRlJnF1b3Q7LCAmcXVvdDtkb2xwaGluJnF1 b3Q7XSw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbG9j YXRpb25zOiBbJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvPC9hPiZxdW90OywgJnF1b3Q7 PGEgaHJlZj0iaHR0cHM6Ly9yZXNvdXJjZS5sb2NhbC9vdGhlciIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vcmVzb3VyY2UubG9jYWwvb3RoZXI8L2E+JnF1b3Q7XSw8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGF0YXR5cGVzOiBbJnF1b3Q7bWV0YWRhdGEm cXVvdDssICZxdW90O2ltYWdlcyZxdW90O108YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDt9XSw8 YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDt0b2tlbjI6IFt7PGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFjdGlvbnM6IFsmcXVvdDtmb28mcXVvdDssICZx dW90O2JhciZxdW90OywgJnF1b3Q7ZG9scGhpbiZxdW90O10sPGJyPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxvY2F0aW9uczogWyZxdW90OzxhIGhyZWY9Imh0 dHBzOi8vcmVzb3VyY2Uub3RoZXIvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9yZXNvdXJjZS4u b3RoZXIvPC9hPiZxdW90O10sPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGRhdGF0eXBlczogWyZxdW90O2RhdGEmcXVvdDssICZxdW90O3BpY3R1cmVzJnF1 b3Q7XTxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO31dPGJyPg0KJmd0OyZndDsgfTxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEluIHRoZSBzaW1wbGVzdCBjYXNlLCB0aGUgQVMgd291bGQg cmV0dXJuIHRoZSBkYXRhIGFzIGluIHlvdXIgcHJvcG9zYWwuPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgSWYgdGhlIGNsaWVudCBhc2tzIGZvciBhIHBhcnRpdGlvbmluZyBvZiBwcml2aWxl Z2VzIHRoYXQgZ29lcyBhY3Jvc3MgUlMgc2VjdXJpdHkgZG9tYWlucyBsaWtlIHRoaXM8YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyB7PGJyPg0KJmd0OyZndDsgJnF1b3Q7cmVzb3VyY2VzJnF1 b3Q7Ons8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmcXVvdDt0b2tlbjEmcXVvdDs6Wzxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyB7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVv dDthY3Rpb25zJnF1b3Q7OlsgJnF1b3Q7cmVhZCZxdW90OywgJnF1b3Q7d3JpdGUmcXVvdDssJnF1 b3Q7ZG9scGhpbiZxdW90OyBdLDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1 b3Q7bG9jYXRpb25zJnF1b3Q7OlsgJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5uZXQvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuLmV4YW1wbGUubmV0LzwvYT4m cXVvdDssJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9yZXNvdXJjZS5sb2NhbC9vdGhlciIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vcmVzb3VyY2UubG9jYWwvb3RoZXI8L2E+JnF1b3Q7XSw8YnI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O2RhdGF0eXBlcyZxdW90OzpbICZxdW90 O21ldGFkYXRhJnF1b3Q7LCZxdW90O2ltYWdlcyZxdW90O108YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgfSw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgezxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJnF1b3Q7YWN0aW9ucyZxdW90OzpbJnF1b3Q7cmVhZCZxdW90OywmcXVv dDt3cml0ZSZxdW90O10sPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDts b2NhdGlvbnMmcXVvdDs6WyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vcmVzb3Vy Y2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL3Jlc291cmNlPC9hPiZxdW90 O108YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgfTxicj4NCiZndDsmZ3Q7Jm5ic3A7IF0sPGJy Pg0KJmd0OyZndDsmbmJzcDsgJnF1b3Q7dG9rZW4yJnF1b3Q7Ols8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgezxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7YWN0aW9u cyZxdW90OzpbJnF1b3Q7Zm9vJnF1b3Q7LCZxdW90O2JhciZxdW90OywgJnF1b3Q7ZG9scGhpbiZx dW90O10sPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtsb2NhdGlvbnMm cXVvdDs6WyZxdW90OzxhIGhyZWY9Imh0dHBzOi8vcmVzb3VyY2Uub3RoZXIvIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9yZXNvdXJjZS5vdGhlci88L2E+JnF1b3Q7XSw8YnI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O2RhdGF0eXBlcyZxdW90OzpbJnF1b3Q7ZGF0YSZxdW90 OywmcXVvdDtwaWN0dXJlcyZxdW90O108YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgfTxicj4N CiZndDsmZ3Q7Jm5ic3A7IF08YnI+DQomZ3Q7Jmd0OyB9PGJyPg0KJmd0OyZndDsgfTxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IHRoZSBBUyB3b3VsZCBuZWVkIHRvIGZ1cnRoZXIgcGFydGl0 aW9uIHRoZSBwcmUtZGVmaW5lZCB0b2tlbnMgbGlrZSB0aGlzOjxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7ICZxdW90O211bHRpcGxlX2FjY2Vzc190b2tlbnPigJ06ezxicj4NCiZndDsmZ3Q7 Jm5ic3A7IOKAnHRva2VuMS9hJnF1b3Q7Ons8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJnF1 b3Q7dmFsdWUmcXVvdDs6JnF1b3Q7T1M5TTJQTUhLVVI2NFRCOE42Qlc3T1pCOENERk9OUDIxOVJQ MUxUMCZxdW90Oyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJnF1b3Q7dHlwZSZxdW90Ozom cXVvdDtiZWFyZXImcXVvdDssPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZxdW90O2xvY2F0 aW9ucyZxdW90OzpbJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5uZXQvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS4ubmV0LzwvYT4mcXVvdDssJnF1 b3Q7PGEgaHJlZj0iaHR0cHM6Ly9yZXNvdXJjZS5sb2NhbC9vdGhlciIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vcmVzb3VyY2UubG9jYWwvb3RoZXI8L2E+JnF1b3Q7XTxicj4NCiZndDsmZ3Q7Jm5i c3A7IH0sPGJyPg0KJmd0OyZndDsmbmJzcDsg4oCcdG9rZW4xL2ImcXVvdDs6ezxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmcXVvdDt2YWx1ZSZxdW90OzomcXVvdDtPUzlNMlBNSEtVUjY0VEI4 TjZCVzdPWkI4Q0RGT05QMjE5UlAxTFQwJnF1b3Q7LDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmcXVvdDt0eXBlJnF1b3Q7OiZxdW90O2JlYXJlciZxdW90Oyw8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJnF1b3Q7bG9jYXRpb25zJnF1b3Q7OlsmcXVvdDs8YSBocmVmPSJodHRwczovL2V4 YW1wbGUuY29tL3Jlc291cmNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9leGFtcGxlLmNvbS9y ZXNvdXJjZTwvYT4mcXVvdDtdPGJyPg0KJmd0OyZndDsmbmJzcDsgfSw8YnI+DQomZ3Q7Jmd0OyZu YnNwOyDigJx0b2tlbjImcXVvdDs6ezxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmcXVvdDt2 YWx1ZSZxdW90OzomcXVvdDtVRkdMTzJGREFGRzdWR1paUEozSVpFTU4yMUVWVTcxRkhDQVJQNEox JnF1b3Q7LDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmcXVvdDt0eXBlJnF1b3Q7OiZxdW90 O2JlYXJlciZxdW90Oyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJnF1b3Q7bG9jYXRpb25z JnF1b3Q7Ols8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90OzxhIGhyZWY9 Imh0dHBzOi8vb3RoZXJfZXhhbXBsZS5jb20vcmVzb3VyY2UiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL290aGVyX2V4YW1wbGUuY29tL3Jlc291cmNlPC9hPiZxdW90Ozxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyBdPGJyPg0KJmd0OyZndDsmbmJzcDsgfTxicj4NCiZndDsmZ3Q7IH08YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBOYW1pbmcgb2YgdGhlIHRva2VucyBpcyBhIGJpdCB0cmlj a3kgYnV0IEkgdGhpbmsgc29sdmFibGUuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgV2hh dCBkbyB5b3UgdGhpbms/PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgYmVzdCByZWdhcmRz LDxicj4NCiZndDsmZ3Q7IFRvcnN0ZW4uPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7 IE9uIDE1LiBNYXIgMjAyMCwgYXQgMTU6MjYsIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9uIE1hciAx NSwgMjAyMCwgYXQgODo1OCBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDE1LiBNYXIgMjAyMCwgYXQgMDM6MjUsIEp1c3RpbiBSaWNo ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5q cmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTbyBpZiB0aGUgQVMgbmVlZHMgYSBjbGllbnQgdG8g Z2V0IGRpZmZlcmVudCBhY2Nlc3MgdG9rZW5zIHRvIGNhbGwgZGlmZmVyZW50IFJTIGRvbWFpbnMs IGl0IGRvZXMgZXhhY3RseSB3aGF0IHdlIGRvIGluIE9BdXRoIDIgdG9kYXkg4oCUIGl0IHRlbGxz IHRoZSBjbGllbnQgdG8gZ2V0IHR3byBkaWZmZXJlbnQgYWNjZXNzIHRva2Vucy4NCjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBIb3cgZG9lcyB0aGlzIHdvcmsg aW4gWFlaPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyBXaXRob3V0IHVzaW5nIHRoZSBtdWx0aS1hY2Nlc3MtdG9rZW4gdGhpbmcgSeKA mW0gcHJvcG9zaW5nIGluIHRoaXMgdGhyZWFkLCB0aGUgY2xpZW50IHdvdWxkIGp1c3QgbWFrZSB0 d28gc2VwYXJhdGUgdHJhbnNhY3Rpb24gY2FsbHMgdG8gZ2V0IHR3byBkaWZmZXJlbnQgdG9rZW5z LiBUaGVyZeKAmXMgYSBmZXcgd2F5cyB0aGF0IHNoYWtlcyBvdXQgZGVwZW5kaW5nIG9uIHNvbWUg b2YgdGhlIGRldGFpbHMuIEluIHRoZSBPQXV0aCB3b3JsZCB0aGF0DQogYW1vdW50cyB0byBpbnZv bHZpbmcgdGhlIHVzZXIgdHdpY2UsIGFuZCBpdCBtaWdodCBiZSB0aGUgc2FtZSBpbiBYWVogaWYg eW914oCZcmUgYXNraW5nIGZvciBkaWZmZXJlbnQgdGhpbmdzOjxicj4NCiZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyZndDsgMS4gQ2xpZW50OiBTdGFydCBUWC0xIChSLTEpPGJyPg0KJmd0OyZn dDsmZ3Q7IDIuIFVzZXI6IEFwcHJvdmUgUi0xPGJyPg0KJmd0OyZndDsmZ3Q7IDMuIEFTOiBJc3N1 ZSBBVC0xKFItMSk8YnI+DQomZ3Q7Jmd0OyZndDsgNC4gQ2xpZW50OiBTdGFydCBUWC0yIChSLTEp PGJyPg0KJmd0OyZndDsmZ3Q7IDUuIFVzZXI6IGFwcHJvdmUgUi0yPGJyPg0KJmd0OyZndDsmZ3Q7 IDYuIEFTOiBJc3N1ZSBBVC0yKFItMik8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7IFVubGVzcyB5b3XigJlyZSBnZXR0aW5nIGEgc3VwZXIgcmVmcmVzaCB0b2tlbiB1cGZyb250 IGFuZCB0aGVuIGNhbGxpbmcgZm9yIHR3byBkb3duZ3JhZGVkIGFjY2VzcyB0b2tlbnMgbGF0ZXIg 4oCUIHdoaWNoIGRvZXMgd29yaywgYW5kIEnigJl2ZSBidWlsdCBvdXQgc3lzdGVtcyB0aGF0IGRv IGV4YWN0bHkgdGhhdC4gWFlaIGNhbiBkbyB0aGF0IHRyaWNrIHRvby48YnI+DQomZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDEuIENsaWVudDogU3RhcnQgVFgtMSAoUi0xLCBSLTIpPGJy Pg0KJmd0OyZndDsmZ3Q7IDIuIFVzZXI6IEFwcHJvdmUgUi0xLCBSLTI8YnI+DQomZ3Q7Jmd0OyZn dDsgMy4gQVM6IElzc3VlIEFUMSAoUi0xLCBSLTIpPGJyPg0KJmd0OyZndDsmZ3Q7IDQuIENsaWVu dDogQ29udGludWUgVFgtMSAoUi0yKTxicj4NCiZndDsmZ3Q7Jmd0OyA1LiBBUzogSXNzdWUgQVQt MiAoUi0yKTxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQnV0IHdl4oCZdmUg Z290IGFub3RoZXIgdGhpbmcgd2UgY2FuIHVzZSBpbiBYWVogdG8gaGVscCB0aGlzLCB0aGUgdXNl ciBoYW5kbGUuIFRoaXMgbGV0cyBhIHRydXN0ZWQgY2xpZW50IHRlbGwgdGhlIEFTIHRoYXQgaXQg YmVsaWV2ZXMgdGhlIHNhbWUgdXNlciBpcyBzdGlsbCB0aGVyZSBhbmQgYXNraW5nIHRoZSBxdWVz dGlvbiwgc28gaWYgdGhlIGFjY2VzcyByaWdodHMgYXJlIE9LIHRoZW4geW91IGRvbuKAmXQgbmVl ZCB0byBpbnZvbHZlIHRoZQ0KIHVzZXIgYWdhaW4uIFdlIGludmVudGVkIHRoaXMgY29uc3RydWN0 IHdpdGggVU1BMiwgd2hlcmUgaXTigJlzIGNhbGxlZCB0aGUgcGVyc2lzdGVkIGNsYWltcyB0b2tl biAoUENUKS48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDEuIENsaWVudDog U3RhcnQgVFgtMSAoUi0xKTxicj4NCiZndDsmZ3Q7Jmd0OyAyLiBVc2VyOiBBcHByb3ZlIFItMTxi cj4NCiZndDsmZ3Q7Jmd0OyAzLiBBUzogSXNzdWUgQVQtMSAoUi0xKSwgdXNlciBoYW5kbGUgVS0x PGJyPg0KJmd0OyZndDsmZ3Q7IDQuIENsaWVudCBTdGFydCBUWC0yIChSLTIsIFUtMSk8YnI+DQom Z3Q7Jmd0OyZndDsgNS4gQVM6IElzc3VlIEFULTIgKFItMik8YnI+DQomZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7IE5vdzogV2l0aCB0aGUgbXVsdGktdG9rZW4gcmVxdWVzdCwgd2UgY2Fu IGNvbGxhcHNlIHRoaXMgYWxsIGJhY2sgdG8gYSBzaW5nbGUgdHJhbnNhY3Rpb24gd2l0aCBtdWx0 aXBsZSBvdXRwdXRzOjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgMS4gQ2xp ZW50OiBTdGFydCBUWC0yICh0b2tlbjE6IFItMSwgdG9rZW4yOiBSLTIpPGJyPg0KJmd0OyZndDsm Z3Q7IDIuIFVzZXIgQXBwcm92ZSBSLTEsIFItMjxicj4NCiZndDsmZ3Q7Jmd0OyAzLiBBUzogSXNz dWUgQVQtMSAodG9rZW4xOiBSLTEpLCBBVC0yICh0b2tlbjI6IFItMik8YnI+DQomZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEkgaGF2ZW7igJl0IGxpa2VkIGFueSBvZiB0aGUgbXVsdGkt YWNjZXNzLXRva2VuIHNvbHV0aW9ucyB0byBkYXRlIGJlY2F1c2UgdGhleSBtYWtlIHRoaW5ncyB3 ZWlyZCBmb3Igc2luZ2xlIGFjY2VzcyB0b2tlbiByZXF1ZXN0cy4gSSBsaWtlIHRoaXMgaWRlYSBi ZWNhdXNlIGl04oCZcyBhbiBvcHRpbWl6YXRpb24gZm9yIGEgY29tcGxleCBjYXNlIHRoYXQgZG9l c27igJl0IGNoYW5nZSB0aGUgYmVoYXZpb3IgZm9yIHRoZSBzaW1wbGUgY2FzZSwgYW5kIGluDQog ZmFjdCBkb2VzbuKAmXQgZXZlbiBjaGFuZ2UgdGhlIGV4cGVjdGF0aW9ucyBmb3IgdGhlIHNpbXBs ZSBjYXNlLiBUbyBtZSwgdGhhdOKAmXMgaW1wb3J0YW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsg4oCUIEp1c3Rpbjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyAtLSA8YnI+DQomZ3Q7IFR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9 Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHhhdXRoPC9hPjxicj4NCjxicj4NCi0tIDxicj4NClR4YXV0aCBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ VHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A81FDB11C05F49E09FA63A2C420282B5amazoncom_-- From nobody Fri Mar 20 13:53:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646B73A0E2C for ; Fri, 20 Mar 2020 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 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, PDS_HP_HELO_NORDNS=0.001, RDNS_NONE=0.793, 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 RhGs-NKW_fNz for ; Fri, 20 Mar 2020 13:53:18 -0700 (PDT) Received: from mail-lf1-x12d.google.com (unknown [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 813703A0E13 for ; Fri, 20 Mar 2020 13:53:12 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id i1so4933320lfo.1 for ; Fri, 20 Mar 2020 13:53:12 -0700 (PDT) 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=Ba54dvHSqrvd4JyMIR3P25UOepywp9aC7FglZoaU7DU=; b=S+ivIfG87hFNP1XKHUgh/j3i8nq0uW0rGI4G3YkRqi5LXAtwm1C+fLkilHIN0w8Zks OaK8WLqAslLIhoz8M6Z25DTOEYdT7DyLnYBeq1GuTHWFPeHARaZZoiY8wlDFtFTBgrjn tgJGqWv+2HiEC0u7xgFRgY/lsyWSpcB61gSHK8HoI3syoQ9uViW24VTqZ6Ru5qz4a1cX XyQ+U+EE0EOhyZKUdfhdXV39A36J4ylEHSujzPmU60NibIQKpO/XFHZnjjWQKqamIJWu I+BV8x/jY5YF5unMEwis3X9MoeZt/5zqV3nMaMoKq9M21O85yv53w9oIvD1yEfMCGDTd mQ6A== 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=Ba54dvHSqrvd4JyMIR3P25UOepywp9aC7FglZoaU7DU=; b=BcbWRWvGAcHLQ5gdaXw/z7adcOgRNy5DB7RRxfh7b8gLpSnJ9QcJQ+AHFsYWyyCTzE 5S9xuNIGcRWtJIW29dOTlb/dDZjbh8A3F6iwXKgcSxPL9OKRqdcNkhzxREla/FpUpAh4 wQZqk+7dNiZl0b38PZ7/2xNyfUVYjVU4ZIlc4/EfnL2hSNZBMH4yDjUNVnYfW8k/abph 6p2uJQjMm00kWnFYav0lP6p56TB6H8N8ydyaWl94AhYVQSKA3PihEKlHItYfEKyl+Xmw CnInp6WNwvGQfA+FzfcMqDW6fzeKBYQuGrywPvkW6YROO94nSGAnvB07hP98bslAr43X CS0w== X-Gm-Message-State: ANhLgQ3sYFswbBdU0hhydbwt4GQYibzBpduvYvNEGYN5ZJuNw5ZdtgXF LPtJuWmX1KgEhE72DJM10mYwBDjVq17ETsFWs0W9t/2b8xI= X-Google-Smtp-Source: ADFU+vu0DIrkoVylDlr+KUMk+eE96QOv1uiDP7pqkvWuzyVPU1UyznpDykyHF6LRV/DLhziepO3/WFSmOnQKyzSsPfw= X-Received: by 2002:a19:f015:: with SMTP id p21mr6588946lfc.10.1584737583584; Fri, 20 Mar 2020 13:53:03 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Fri, 20 Mar 2020 13:52:37 -0700 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000bb5ac305a14f7868" Archived-At: Subject: [Txauth] RFCs on protocol design X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 20:53:27 -0000 --000000000000bb5ac305a14f7868 Content-Type: text/plain; charset="UTF-8" Hello Everyone As we are working on a new protocol, I thought it would be useful to learn on what has been done before. I posted to the WG chairs list, and below are what I think are some useful documents for us to use as guidelines. /Diick *RFC 1958* *Architectural Principles of the Internet* Abstract The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. https://tools.ietf.org/html/rfc1958 *RFC 4775* *Procedures for Protocol Extensions and Variations* Abstract This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF. This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. https://tools.ietf.org/html/rfc4775 *RFC5218* *What Makes for a Successful Protocol?* Abstract The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. https://tools.ietf.org/html/rfc5218 *RFC 6709 * *Design Considerations for Protocol Extensions* Abstract This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. https://tools.ietf.org/html/rfc6709 *RFC 8170* *Planning for Protocol Adoption and Subsequent Transitions* Abstract Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan. https://tools.ietf.org/html/rfc8170 --000000000000bb5ac305a14f7868 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Everyone

As we are wor= king on a new protocol, I thought it would be useful to learn on what has b= een done before. I posted to the WG chairs list, and below are what I think= are some useful documents for us to use as guidelines.

/Diick

RFC 1958
Architec= tural Principles of the Internet

Abstract<= br>
=C2=A0 =C2=A0The Internet and its architecture have grown in evoluti= onary fashion
=C2=A0 =C2=A0from modest beginnings, rather than from a Gr= and Plan. While this
=C2=A0 =C2=A0process of evolution is one of the mai= n reasons for the technology's
=C2=A0 =C2=A0success, it nevertheless= seems useful to record a snapshot of the
=C2=A0 =C2=A0current principle= s of the Internet architecture. This is intended for
=C2=A0 =C2=A0genera= l guidance and general interest, and is in no way intended to
=C2=A0 =C2= =A0be a formal or invariant reference model.

<= a href=3D"https://tools.ietf.org/html/rfc1958">https://tools.ietf.org/html/= rfc1958

RFC 4775
Proce= dures for Protocol Extensions and Variations

<= /div>
Abstract

=C2=A0 =C2=A0This document discusses procedural i= ssues related to the
=C2=A0 =C2=A0extensibility of IETF protocols, inclu= ding when it is reasonable to
=C2=A0 =C2=A0extend IETF protocols with li= ttle or no review, and when extensions
=C2=A0 =C2=A0or variations need t= o be reviewed by the IETF community.=C2=A0 Experience
=C2=A0 =C2=A0has s= hown that extension of protocols without early IETF review can
=C2=A0 = =C2=A0carry risk.=C2=A0 The document also recommends that major extensions = to or
=C2=A0 =C2=A0variations of IETF protocols only take place through = normal IETF
=C2=A0 =C2=A0processes or in coordination with the IETF.
=
=C2=A0 =C2=A0This document is directed principally at other Standards D= evelopment
=C2=A0 =C2=A0Organizations (SDOs) and vendors considering req= uirements for
=C2=A0 =C2=A0extensions to IETF protocols.=C2=A0 It does n= ot modify formal IETF
=C2=A0 =C2=A0processes.

https://tools.ietf.org/h= tml/rfc4775

RFC5218
Wh= at Makes for a Successful Protocol?

Abstra= ct

=C2=A0 =C2=A0The Internet community has specified a large number = of protocols to
=C2=A0 =C2=A0date, and these protocols have achieved var= ying degrees of success.
=C2=A0 =C2=A0Based on case studies, this docume= nt attempts to ascertain factors
=C2=A0 =C2=A0that contribute to or hind= er a protocol's success.=C2=A0 It is hoped that
=C2=A0 =C2=A0these o= bservations can serve as guidance for future protocol work.
<= br>

RFC 6709=C2=A0
Design Considerations for Protocol Extensions
Abstract

=C2=A0 =C2=A0This document discusses archit= ectural issues related to the
=C2=A0 =C2=A0extensibility of Internet pro= tocols, with a focus on design
=C2=A0 =C2=A0considerations.=C2=A0 It is = intended to assist designers of both base
=C2=A0 =C2=A0protocols and ext= ensions.=C2=A0 Case studies are included.=C2=A0 A companion
=C2=A0 =C2= =A0document, RFC 4775 (BCP 125), discusses procedures relating to the
= =C2=A0 =C2=A0extensibility of IETF protocols.


RFC 8170
Plan= ning for Protocol Adoption and Subsequent Transitions
Abstract

=C2=A0 =C2=A0Over the many years since the intr= oduction of the Internet Protocol,
=C2=A0 =C2=A0we have seen a number of= transitions throughout the protocol stack,
=C2=A0 =C2=A0such as deployi= ng a new protocol, or updating or replacing an
=C2=A0 =C2=A0existing pro= tocol.=C2=A0 Many protocols and technologies were not designed
=C2=A0 = =C2=A0to enable smooth transition to alternatives or to easily deploy
= =C2=A0 =C2=A0extensions; thus, some transitions, such as the introduction o= f IPv6,
=C2=A0 =C2=A0have been difficult.=C2=A0 This document attempts t= o summarize some basic
=C2=A0 =C2=A0principles to enable future transiti= ons, and it also summarizes what
=C2=A0 =C2=A0makes for a good transitio= n plan.


<= div>
--000000000000bb5ac305a14f7868-- From nobody Fri Mar 20 14:03:18 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8423A0E3A for ; Fri, 20 Mar 2020 14:03:15 -0700 (PDT) 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_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=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 ooHSK8fZ6Jil for ; Fri, 20 Mar 2020 14:03:10 -0700 (PDT) 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 110F63A0E39 for ; Fri, 20 Mar 2020 14:03:10 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id a20so8796601edj.2 for ; Fri, 20 Mar 2020 14:03:09 -0700 (PDT) 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=52LsSwYufzgSwPlvOfT4STK6YQFtfEUuAZynWnu4jCY=; b=YH+yuGjgwZy87vNtzvGZLARG7mbXPqivB4EMw4L3zGhoCIXYTiV4iRhAF2SRVIc3SW 16CP1qnP8maQOmla0Bn0ibNN6hP4u5jAFNKHdLNmlhUwWTPM1OD6PnDpYGwo18viA259 NEESmIp+02sbiJJ7gAXU1Amwwp6XdSNjTEwpTx1sWxLqr9SF90ca/KubWKXwNBge5c3Y pB1YAQ+7+NtrjjE7ZMWHnAPuiMYlS/Y0bA0tDqJL7JKiUuImC0nIJqmdq5sraieDAAF8 4/1o5mTzpEQLX6VWYl3t+wwD/sTB6anAPjWiM+uQRjWIizOL5L/H0KqJaN8SBt3ZW7SA qSyw== 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=52LsSwYufzgSwPlvOfT4STK6YQFtfEUuAZynWnu4jCY=; b=ZpHDNDZsFIOoxn9T9qqSYVvDR/avxj6fPDcNv7bWha/ZCXycubYtozsczIoPDaIMwq AhpbP6c7RHZwYcuyBN+wA+QR4Gz3UuRsnLt6XrjiRuH3Anmzv47AO8rkDz0+c0mGOIEY s4Y00/mpNpgW98n5+lize3r5Ndx11JMjOLrFn379JNK+o874DsE91KHqkIfs2g0rjnP5 UspzQKX7QACb6zTU7kdN7/tJfi6DYJnQHl0HWn6uD3BLKzJfslSI+P1r1E/nXf1KcteC rU4fairizjqz7SMxuS2Qcym4hXUkPlam5NXMrsMb47BVwtaFkStTFw+g1nZKCbl1qUB9 Yz7Q== X-Gm-Message-State: ANhLgQ18i3+C5kMksNDjY6iL1naMUcIY6JCKqwvJuhDMnIq4b+81jgP4 1Rh0/aXXuEy3t6lmTnoSDO/9ooCX/dn/M5TdDbfcjU3hqms= X-Google-Smtp-Source: ADFU+vvo+up7qE+jKhly4gAjzSBctLjW+a9r0Uhhs1SDfd2dCPzECAr7D9zqUkM9fxFzwBdvK1+GfYQt+sYgJzU8aXY= X-Received: by 2002:aa7:cf01:: with SMTP id a1mr10147318edy.282.1584738187502; Fri, 20 Mar 2020 14:03:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Fri, 20 Mar 2020 21:02:57 +0000 Message-ID: To: Dick Hardt Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000ba662205a14f9c31" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:03:17 -0000 --000000000000ba662205a14f9c31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, As requested by Dick in the parallel email chain, I'll see if this response can start to kick off some discussion. If I'm understanding this correctly, then the main difference here is the debate around whether to have a "default" authentication method or not. Both XYZ and XAuth appear to support having multiple different authentication methods that the client can use (which I certainly agree is sensible), but for XYZ this is part of the "core" protocol, whereas for XAuth it's more of an extension. My view is that I don't think the argument "*choosing one auth method as a default makes too many assumptions about client=E2=80=99s nature and deploy= ment capabilities*" is necessarily a valid reason to avoid having a default. Having a default perhaps makes assumptions about the most *common* use cases and the most *common *clients, but it certainly doesn't prevent other more niche clients and use cases from being able to use the protocol. I share the concern raised in the XAuth rationale text that not having a default mechanism places a burden on the clients to choose, which may be off-putting or a distraction for some newcomers. I do however think the availability of different authentication methods should be part of the core protocol, to encourage each AS to implement as many different methods as possible - which it would be in there interest to do so as it would enable the AS to support more use cases. So in summary, I'm in favour of the protocol supporting multiple different authentication methods as part of the core protocol, but my preference would be to have a default selected if the client doesn't want (or need) to choose anything different. I don;t think having a default would be restrictive, and I think when the protocol is eventually launched/standardised in the future we'll have a clear view of what that default should be to ensure that it's aligned to the most common use cases. Many thanks, David Skaife On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote: > > *Client Authentication / Proof of Possession* > XYZ > - client proves use of bound keys via general-purpose mechanisms, > including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS > - RS access via bearer token or proof-of-possession through any allowable > key binding mechanism > > XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault" makes too = many > assumptions about client=E2=80=99s nature and deployment capabilities. AS= should > support as many as it can (and possibly have an MTI requirement), client > supports whatever method makes the most sense for it. PoP mechanisms for = RS > should be independent of mechanisms at AS. > > XAuth > - client proves use of bounds keys through an auth mechanism at GS > - specifies default mechanism using JOSE for GS and RS proof-of-possessio= n > calls > - RS access via bearer token just like OAuth 2.0 > - extensions can define other mechanisms such as HTTP Sig or MTLS to > replace JOSE for either GS and/or RS calls > > XAuth Rationale: having a Client Authentication mechanism defined and as > default removes burden of selecting mechanism for most deployments, and > ensures interop. > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ba662205a14f9c31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As requested by Dick in the parallel email chai= n, I'll see if this response can start to kick off some discussion.
=

If I'm understanding this correctly, then the main = difference here is the debate around whether to have a "default" = authentication method or not. Both XYZ and XAuth appear to support having m= ultiple different authentication methods that the client can use (which I c= ertainly agree is sensible), but for XYZ this is part of the "core&quo= t; protocol, whereas for XAuth it's more of an extension.

My vie= w is that I don't think the argument "choosing one auth method = as a default makes too many assumptions about client=E2=80=99s nature and d= eployment capabilities" is necessarily=C2=A0a valid reason to avoi= d having a default. Having a default perhaps makes assumptions about the mo= st common=C2=A0use cases and the most common clients, but it = certainly doesn't prevent other more niche clients and use cases from b= eing able to use the protocol. I share the concern raised in the XAuth rati= onale text that not having a default mechanism places a burden on the clien= ts to choose, which may be off-putting or a distraction for some newcomers.= I do however think the availability of different authentication methods sh= ould be part of the core protocol, to encourage each AS to implement as man= y different methods as possible - which it would be in there interest to do= so as it would enable the AS to support more use cases.

So in summa= ry, I'm in favour of the protocol supporting multiple different authent= ication methods as part of the core protocol, but my preference would be to= have a default selected if the client doesn't want (or need) to choose= anything different. I don;t think having a default would be restrictive, a= nd I think when the protocol is eventually launched/standardised in the fut= ure we'll have a clear view of what that default should be to ensure th= at it's aligned to the most common use cases.

=
Many thanks,
David Skaife

On Mon, Mar 16, 202= 0 at 11:06 PM Dick Hardt <dick.h= ardt@gmail.com> wrote:
Client Authentication / Proof of Possessi= on

XYZ
- client proves use of bound keys via general-purpose = mechanisms, including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
= - RS access via bearer token or proof-of-possession through any allowable k= ey binding mechanism

XYZ Rationale: choosing one auth method as a = =E2=80=9Cdefault" makes too many assumptions about client=E2=80=99s na= ture and deployment capabilities. AS should support as many as it can (and = possibly have an MTI requirement), client supports whatever method makes th= e most sense for it. PoP mechanisms for RS should be independent of mechani= sms at AS.

XAuth
- client proves use of bounds keys through an au= th mechanism at GS
- specifies default mechanism using JOSE for GS and R= S proof-of-possession calls
- RS access via bearer token just like OAuth= 2.0
- extensions can define other mechanisms such as HTTP Sig or MTLS t= o replace JOSE for either GS and/or RS calls

XAuth Rationale: having= a Client Authentication mechanism defined and as default removes burden of= selecting mechanism for most deployments, and ensures interop.
3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ba662205a14f9c31-- From nobody Fri Mar 20 14:08:24 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07743A0EA5 for ; Fri, 20 Mar 2020 14:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=humanpresent.onmicrosoft.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 1-aYX5liOglz for ; Fri, 20 Mar 2020 14:08:02 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680114.outbound.protection.outlook.com [40.107.68.114]) (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 CD7503A0E9B for ; Fri, 20 Mar 2020 14:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nWn/3Jze3+uQkpOD7dPCxNn+7n1E1EYaSMvD8EtZJ0imecLGUPt2PpUhDn7Ww56Oxh+3DJE8zuZ+ijKaVaD2yUjRxYE3zOsRstaaddQqO7P724eGsHjB29SUWkzZaZOyaAhAbHepbmoZLYxG4WErW6CFR+9bLaNYnw2cr6BPIqyBvarMNLVGRO/0pmWbDu7vSakCPL4kqRmT3brMMIP3E4outB/Bj3c8B/ZuR2ZDvgPmC437nz18PVdRs8qOjkhOo0HMENCybnbPjhXRTqesRVcRXy5M2j7TXyqkrGn9yaS5oCpJLrNB2D0Xnv9+Ey7maq1Y4dft2u3DiFM4NfhHBQ== 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=8Tn27LfVYTJEhYzCc+KqwmE8wQeeGcQ7dHAVzxgl69s=; b=eTBIwk02Jg+snlqlIsA0SFOxqVrZKGIes9ydJTz3jazEMFrwxX8Y1r2n1h2zkABUKs0fSfPmbI6ouswiGMSl/YZvDrngkexPwPQYSYkC1HHWc+T/JQm28rea0oKHkOX6SUr85rZ/rHrqHTwvfJUe4+yoE34e5n1em6VZ8R3rIg/GFs6Nf+w84QkuwiE2dRe8h8fgvbs8GAdJrVsFJMFuAp79Te8YSwvGd799OAt3z571/uWhK7RM/5S76NSRsLXCv8YrRtEpUd49/EGRtUPZz0I0MOXq8Fg9Ry7//VXUo3KKk/02iS5Bz5YN5StZsAEC3hpRTYE6h1ekoPzwQOWl8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=identityblog.com; dmarc=pass action=none header.from=identityblog.com; dkim=pass header.d=identityblog.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=humanpresent.onmicrosoft.com; s=selector2-humanpresent-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8Tn27LfVYTJEhYzCc+KqwmE8wQeeGcQ7dHAVzxgl69s=; b=kTu4EKXU4pyHxC8qVCcEoGUu7Pa7iiFGxucUuo9Gf2wDPYAtvpMtTK5falvHQX+/Hn3gP4EGSSyrAiRbSGx2jljgXFMcEMNZ16UtyJtYU4Gm2sbv/I9sxlQQMeKkpM6dOsc5wLwCfhVf5WT+V5P2+rZpKNsLLMIEFogz8KGYqvI= Received: from SA0PR16MB3775.namprd16.prod.outlook.com (2603:10b6:806:80::13) by SA0PR16MB3679.namprd16.prod.outlook.com (2603:10b6:806:8c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Fri, 20 Mar 2020 21:07:59 +0000 Received: from SA0PR16MB3775.namprd16.prod.outlook.com ([fe80::c176:383c:f00f:d567]) by SA0PR16MB3775.namprd16.prod.outlook.com ([fe80::c176:383c:f00f:d567%7]) with mapi id 15.20.2835.017; Fri, 20 Mar 2020 21:07:59 +0000 From: Kim To: Torsten Lodderstedt , "txauth@ietf.org" CC: Vladimir Dzhuvinov Thread-Topic: [Txauth] Call for charter consensus - TxAuth WG Thread-Index: AdX8qDR2vl6CizN9TBeow352Bw//MgAA6EaAAACHAoAAMjaigAAfaBKAAALCdwAAAw4qgAAAGQiAAAB8uQAAANszgAAA0meAAAEstYAANhSUYA== Date: Fri, 20 Mar 2020 21:07:59 +0000 Message-ID: References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> In-Reply-To: <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kim@identityblog.com; x-originating-ip: [199.167.24.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8b45c9e-9dba-41b9-8075-08d7cd12c529 x-ms-traffictypediagnostic: SA0PR16MB3679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(376002)(39830400003)(346002)(136003)(366004)(396003)(199004)(508600001)(66556008)(66946007)(66476007)(64756008)(76116006)(66446008)(52536014)(8676002)(966005)(110136005)(6506007)(55016002)(86362001)(81156014)(4326008)(53546011)(71200400001)(5660300002)(81166006)(7696005)(186003)(2906002)(9686003)(316002)(33656002)(8936002)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:SA0PR16MB3679; H:SA0PR16MB3775.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: identityblog.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xnOcOl3Mj+XUKHiKLYREDDnvSNde48AkZOe+V57hswOaX4QjPBHItVrtLMXsxwgKIMyg4C2kZYXmQ4w9XnvsxVMiA81fWe3RERar0J+wXmO86hXxIw8MCsu43hV4KFaVqTXTbMEt1e6+PnZQk3/VEqMOzptxw0Uxw0u+auVnAVZFchlC8JGiJEixtR9oc/eJDngKO4juNccDDIFqbcmvWxQrkNa8rWEyAZcx1ECV5QkSju2bwO5G6yJnwyeVnemSutORUcO6x6lMhmO/gYe/u6XHCrBoREDs7BK0SQeyn5dtAYQhgUDInWeuclYplqGeR+qPoVubjmr152iaFyE1srynrRQiXtT1hmrF/VT5tlBDLjizhtLzSeiPP1UxVQAwrrShpF3/xePQokpZKEoNy5TVU8v/hxdAxBYJmIoFn6DfyU3ob9qicXC66Rt1D8maLpv2zBXErAwvDi0pa254h0CxJVQZQTjH6KEcdLCUSoPBFArXrpnrnZY7uWI+qvN8T9lieb2w7YE6EnNCvTgTpg== x-ms-exchange-antispam-messagedata: +1Dwijt9QSp+s+t4Zh1eZyQTeg/ccGVBBPtKWLYqOD/lY4cSslEA78LXozoYewvWWQp+zy4KjbVHRFudSfEWYQWLNH+ba2db+Uzv6FbVZb2SfrG0YZom3bPUXl9e8pcYs59+FffsnGi6cLRkQHSIVA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: identityblog.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8b45c9e-9dba-41b9-8075-08d7cd12c529 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 21:07:59.5379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c3439b4d-884a-42b8-8e49-94af41f1b711 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CLB7VsRCZb+uwizPyHBpkZSnc32d/ocDdA/uHW9o00QAljISr7vljmp83o3kMiy/YYhwK0+kLDt1nSenHgmsKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR16MB3679 Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:08:21 -0000 SSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCBUb3JzdGVuJ3MgcHJvcG9zYWwgYW5kIHRoaW5rIGl0IHBy b3ZpZGVzIGEgd2F5IHRvIGZvY3VzIFR4QXV0aCdzIGluaXRpYXRpdmVzIG9uIHNvbHZpbmcgdGhl IG1hbnkgYW5kIGRlZXAgcHJvYmxlbXMgb2YgdGhlIGF1dGhvcml6YXRpb24gbGF5ZXIgYnkgYmV0 dGVyIGludGVncmF0aW5nIGl0IHdpdGggdGhlIGNsYWltcyBiYXNlZCBtb2RlbCBvZiBpZGVudGl0 eS4gIA0KDQpJdCBpcyBhbHNvIGNsZWFyIHRvIG1lIHRoYXQgdGhlcmUgaXMgemVybyBjb25zZW5z dXMgdGhhdCBUeEF1dGggc2hvdWxkIGJlIGNoYXJ0ZXJlZCB0byBiZSBhIHJlcGxhY2VtZW50IGZv ciBhbGwgZXhpc3RpbmcgaWRlbnRpdHkgdGVjaG5vbG9neS4gIA0KDQpJbnN0ZWFkLCB0aGVyZSBp cyB3aWRlIGNvbnNlbnN1cyB0aGF0IFR4QXV0aCBzaG91bGQgaW50ZWdyYXRlIHRoZSBjbGFpbXMg YmFzZWQgbW9kZWwgaW50byB0aGUgYXV0aG9yaXphdGlvbiBsYXllciBhbmQgYXR0YWNrIHRoZSBt YW55IHVuc29sdmVkIHByb2JsZW1zIHdlIGhhdmUgZXhwZXJpZW5jZWQgd2l0aCBpbmNyZWFzaW5n bHkgaW50ZXJkZXBlbmRlbnQgbmV0d29ya3Mgb2YgaW50ZXJhY3Rpbmcgc2VydmljZXMgLiAgDQoN ClN1cmVseSBkb2luZyBzbyBpcyBhbiBpbW1lbnNlIHRhc2sgYW5kIGEgc3VmZmljaWVudCBtYW5k YXRlLiAgTWVhbndoaWxlLCB3aGVuIHBlb3BsZSB3b3JraW5nIG9uIGF1dGhvcml6YXRpb24gZW5j b3VudGVyIGRlZmVjdHMgaW4gZXhpc3RpbmcgaWRlbnRpdHkgcHJvdG9jb2xzLCB0aG9zZSBwcm90 b2NvbHMgc2hvdWxkIGJlIGZpeGVkIHNvIHRoZSBpbXByb3ZlbWVudHMgYWNjcnVlIHRvIGFsbCBv ZiB0aGUgbGF5ZXJzIHRoYXQgYXJlIGRlcGVuZGVudCBvbiBjbGFpbXMsIG5vdCBqdXN0IGF1dGhv cml6YXRpb24uIA0KDQpJZGVudGl0eSBpbiBnZW5lcmFsIGhhcyBiaWcgcHJvYmxlbXMgdGhhdCBy ZW1haW4gdG8gYmUgc29sdmVkLiAgQnV0IGFzIHRoZSBkaWdpdGFsIHNwaGVyZSBleHBhbmRzIHRo ZSBncmVhdGVzdCBvZiB0aGVzZSBpcyB0aGF0IG9mIGNyZWF0aW5nIGEgaG9saXN0aWMgaWRlbnRp dHkgbGF5ZXIgdGhhdCBzZXJ2ZXMgdGhlIG5lZWRzIHdlIGhhdmUgYXMgaHVtYW4gYmVpbmdzIGFz IHdlbGwgYXMgaXQgc2VydmVzIHRob3NlIHdobyBvcGVyYXRlIGRpZ2l0YWwgZW50ZXJwcmlzZXMu ICBJZGVudGl0eSB0ZWNobm9sb2d5IHdpbGwgaGF2ZSB0byBlbWJyYWNlIG11Y2ggbW9yZSB0aGFu IHByb3RvY29scyBmb3IgZXhjaGFuZ2luZyBjbGFpbXMgYW5kIGRlY2lkaW5nIHdoZXRoZXIgdG8g dHJ1c3QgdGhlbS4gIEhvdyBjYW4gVHhBdXRoIHBvc3NpYmx5IHN1Y2NlZWQgYXQgc29sdmluZyB0 aGUgZGlmZmljdWx0IHByb2JsZW1zIG9mIGF1dGhvcml6YXRpb24gd2hpbGUgYXQgdGhlIHNhbWUg dGltZSB0YWtpbmcgb24gdGhpcyBvdGhlciB2YXN0IHNldCBvZiBoYXJkIHByb2JsZW1zPyANCg0K SXQgaXMgZmFyIGJldHRlciBmb3IgVHhBdXRoIHRvIGxpbWl0IGl0cyBzY29wZSB0byB0aGUga2lu ZHMgb2YgaW5pdGlhdGl2ZXMgcHJvcG9zZWQgYnkgVG9yc3RlbiBhbmQgdG8gcHJldmFpbCB1cG9u IGVudGl0aWVzIHN1Y2ggYXMgT0lEQyB0byBjb3JyZWN0IGFueSBkZWZpY2llbmNpZXMgdGhhdCBw cmV2ZW50IHRoZWlyIHdvcmsgZnJvbSBiZWluZyByZXVzZWQgaW4gdGhlIGF1dGhvcml6YXRpb24g bGF5ZXIgcmF0aGVyIHRoYW4gcmVpbnZlbnRpbmcgZXZlcnl0aGluZy4NCg0KSSBhbHNvIGFncmVl IHdpdGggdGhlIGNvbW1lbnRzIGFuZCBwcm9wb3NhbHMgbWFkZSBieSBOYXQsIE1pa2UgSm9uZXMg YW5kIFZpdHRvcmlvLiAgSWYgY29uc2Vuc3VzIGlzIHJlYWxseSBiZWluZyBzb3VnaHQsIGZvY3Vz aW5nIG9uIHRoZSBhdXRob3JpemF0aW9uIGxheWVyIGFuZCBpdHMgdXNlIG9mIGNsYWltcyByYXRo ZXIgdGhhbiBhbGwgb2YgaWRlbnRpdHkgd2lsbCBjZXJ0YWlubHkgYnJpbmcgaXQgYWJvdXQuDQoN CkJlc3QgcmVnYXJkcywNCg0KS2ltIENhbWVyb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxOSwgMjAyMCAxMjow OSBQTQ0KVG86IHR4YXV0aEBpZXRmLm9yZw0KQ2M6IFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGlt aXJAY29ubmVjdDJpZC5jb20+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gQ2FsbCBmb3IgY2hhcnRl ciBjb25zZW5zdXMgLSBUeEF1dGggV0cNCg0KSGkgYWxsLA0KDQpJIHN1Z2dlc3QgdG8gYWRkIHRo ZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQgdG8gdGhlIGNoYXJ0ZXI6DQoJ4oCiIFN1cHBvcnQgZm9y IFJTLXNwZWNpZmljIGFjY2VzcyB0b2tlbnMgaW4gTXVsdGktUlMgZGVwbG95bWVudHMgDQoNCkkg ZG9u4oCZdCBtaW5kIEhPVyB0aGlzIHJlcXVpcmVtZW50IGlzIHN1cHBvcnRlZCBpbiBUWEF1dGgu IEkgd2FudCB0byBtYWtlIHN1cmUgd2UgdHJ5IHRvIGJ1aWxkIGEgcHJvdG9jb2wgdGhhdCBzZXJ2 ZXMgdGhlIG5lZWRzIG9mIGEgYnJvYWQgc2V0IG9mIGRlcGxveW1lbnRzLiBNeSBjb25jZXJuIGlz IG90aGVyd2lzZSBUWEF1dGggd2lsbCBiZSBub3QgaW5ub3ZhdGl2ZSBlbm91Z2ggdG8gZ2FpbiB0 cmFjdGlvbiBpbiB0aGUgbWFya2V0IHJhcGlkbHkuIFNwZWFraW5nIGZvciBteXNlbGYsIEkgcmVh bGlzZWQgaW4gdGhlIGxhc3QgY291cGxlIG9mIGRheXMsIG1vc3RseSBpbiBjb252ZXJzYXRpb25z IHdpdGggSnVzdGluLCB0aGF0IHRoZSByZXN1bHQgb2YgdGhpcyB3b3JraW5nIGdyb3VwIGFzIGVu dmlzaW9uZWQgbm93IGlzIG5vdCBvZiBwYXJ0aWN1bGFyIGludGVyZXN0IHRvIHVzICh5ZXMuY29t KSBiZWNhdXNlIGl0IGRvZXMgbm90IHNvbHZlIG91ciByZWFsIHByb2JsZW1zLiANCg0KQW5kIGhl cmUgaXMgbXkgZXhwbGFuYXRpb246IA0KDQpPQXV0aCB0cmFkaXRpb25hbGx5IGhhcyB0aGUgcGhp bG9zb3BoeSBvZiBhIHNpbmdsZSBhY2Nlc3MgdG9rZW4uIFRoYXTigJlzIGZpbmUgZm9yIHNpbmds ZSBzZXJ2aWNlIGRlcGxveW1lbnRzLCBidXQgaXQgaGFkIHJlYWNoZWQgaXRzIGxpbWl0cyBhbHJl YWR5IGJlZm9yZSBSRkM2NzQ5IHdhcyBwdWJsaXNoZWQuIFRoZXJlIGFyZSBhIHJlYWwgaW1wbGVt ZW50YXRpb25zIG91dCB0aGVyZSBmb3JjaW5nIGNsaWVudHMgdG8gdXNlIGRpZmZlcmVudCBhY2Nl c3MgdG9rZW5zIGZvciBkaWZmZXJlbnQgc2VydmljZXMsIHR5cGljYWxseSBmb3IgcHJpdmFjeSBh bmQgc2VjdXJpdHkgcmVhc29ucy4gVGhlcmUgaXMgYWxzbyBhbiDigJxhbmNpZW50IiB0ZWNobm9s b2d5IGNhbGxlZCBLZXJiZXJvcyB0aGF0IHVzZXMgZXhhY3RseSB0aGlzIHBhdHRlcm4gYW5kIGlz IHdlbGwga25vd24gZm9yIHNlY3VyaXR5LCBwZXJmb3JtYW5jZSwgYW5kIHNjYWxhYmlsaXR5LiAN Cg0KQW5kIHRoZXJlIGFyZSBldmVuIG1vcmUgZXhhbXBsZXMgdG9kYXkgZm9yIG11bHRpIEFQSSBl bnZpcm9ubWVudHMgdGhhdCB3b3VsZCBiZW5lZml0IGZyb20gdGhhdCBmZWF0dXJlOiANCgnigKIg T3BlbiBiYW5raW5nOiBtb3N0IGJhbmtzIEkgd29ya2VkIHdpdGggaGF2ZSBtdWx0aXBsZSBBUElz LCBzZWdyZWdhdGlvbiBiZXR3ZWVuIEFQSXMgaXMgdG9kYXkgYWNoaWV2ZWQgYnkgbWFpbnRhaW5p bmcgZGlmZmVyZW50IGdyYW50cywgYmFzaWNhbGx5IHJlc3VsdGluZyBpbiB0aGUgZmFjdCB0aGF0 IHRoZSB1c2VycyBjYW5ub3QgY29uc2VudCB0byBkaWZmZXJlbnQgc2VydmljZXMgYXQgb25jZS4g V2hhdCBhIHRlcnJpYmxlIFVYIQ0KCeKAoiBFdmVyeW9uZSBpcyBkb2luZyBtaWNybyBzZXJ2aWNl cyB0b2RheS4gSGF2ZSB5b3UgZXZlcnkgdGhvdWdodCBhYm91dCB0aGUgY291cGxpbmcgY2F1c2Vk IGJ5IGEgc2luZ2xlIHRva2VuIGFjcm9zcyBtaWNybyBzZXJ2aWNlcz8gVGhpcyByZW1pbmRzIG1l IG9mIGhvdyBlYXN5IGl0IGlzIHRvIHRlc3Qgc2VydmljZXMgaW5kZXBlbmRlbnRseSB1c2luZyBz ZWxmLWNvbnRhaW5lZCBSUy1zcGVjaWZpYyB0b2tlbnMuDQoJ4oCiIElvVCAtIGV2ZXJ5IGRldmlj ZSBpbiBhIGhvdXNlaG9sZCBpcyBhIHBvdGVudGlhbCBSUyAoaW4gbXkgb3BpbmlvbikuIENvbnZl eWluZyBhbGwgbmVjZXNzYXJ5IGRhdGEgaW4gYW4gYWNjZXNzIHRva2VuIG5lZWRlZCB0byBtZWV0 IGFjY2VzcyBjb250cm9sIGRlY2lzaW9ucyBsb2NhbGx5IHdvdWxkIGJlIGEgaHVnZSBiZW5lZml0 IGluIHRlcm1zIG9mIHBlcmZvcm1hbmNlIGFuZCBkZWNvdXBsaW5nLiBVc2luZyBzeW1tZXRyaWMg Y3J5cHRvZ3JhcGh5IGZvciB0b2tlbiBpbnRlZ3JpdHksIGF1dGhlbnRpY2l0eSBhbmQgY29uZmlk ZW50aWFsaXR5IHdvdWxkIHJlc3VsdCBpbiBsb3dlciBjb21wdXRlIHJlcXVpcmVtZW50cy4NCg0K U2luY2Ugd2UgYXJlIHByZXBhcmluZyB0byBkZWZpbmUgYSBjb21wbGV0ZWx5IG5ldyBwcm90b2Nv bCBmb3IgQVBJIGFjY2VzcyBhdXRob3JpemF0aW9uIGFuZCBkZWxlZ2F0aW9uLCBJIHRoaW5rIHRo aXMgbmV3IHByb3RvY29sIHNob3VsZCBzdXBwb3J0IHRoaXMga2luZCBvZiBzY2VuYXJpb3MuIEl0 IHdpbGwgcmVxdWlyZSBzaWduaWZpY2FudCB3b3JrIHRvIGdldCBpdCByaWdodCBhbmQgc2ltcGxl LCBidXQgaWYgd2UganVzdCBzdGljayB0byB0aGUg4oCcYSBzaW5nbGUgYWNjZXNzIHRva2VuIGlz IGVub3VnaOKAnSBtYW50cmEsIHdlIG1pc3MgdGhlIGNoYW5jZSB0byBnaXZlIGltcGxlbWVudGVy cyBhIGJyb2FkZXIgcmFuZ2Ugb2YgZGVzaWduIGNob2ljZXMgb3V0IG9mIHRoZSBib3ggYW5kIHdl IHdvbuKAmXQgc3VjY2VzcyBpbiBhY2hpZXZpbmcgdHJ1ZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpI ZXJlIGFyZSBtb3JlIGFkdmFudGFnZXMgd2UgY2FuIGdhaW4gYnkgc3VwcG9ydGluZyBzdWNoIGEg ZmVhdHVyZTogDQoJ4oCiIFByaXZhY3k6DQoJCeKAoiBBIHNpbmdsZSBhY2Nlc3MgdG9rZW4gY2Fu IGJlIHVzZWQgdG8gdHJhY2sgdXNlciBhY3Jvc3Mgc2VydmljZXMuDQoJCeKAoiBSUy1zcGVjaWZp YyBhY2Nlc3MgdG9rZW5zIGNhbm5vdC4NCgkJ4oCiIFJTLXNwZWNpZmljIGFjY2VzcyB0b2tlbnMg Y2FuIGFsc28gYmUgZW5jcnlwdGVkIHRvIHByb3RlY3QgZGF0YSBjb25maWRlbnRpYWxpdHkgaW4g dHJhbnNpdC4NCgnigKIgU2VjdXJpdHk6IFJTLXNwZWNpZmljIGFjY2VzcyB0b2tlbnMgaGF2ZSBh IGJhc2VsaW5lIHJlcGxheSBkZXRlY3Rpb24uDQoJ4oCiIFBlcmZvcm1hbmNlOiBSUy1zcGVjaWZp YyBhY2Nlc3MgdG9rZW5zIGFsbG93IHRoZSBBUyB0byBjb252ZXkgYWxsIGRhdGEgcmVxdWlyZWQg dG8gYXV0aG9yaXplIGFuIEFQSSBjYWxsIGluIGEgdG9rZW4gKGUuZy4gYSBKV1QpIGFuZCB0byBS UyB0byBtZWV0IHRoZSBhY2Nlc3MgY29udHJvbCBkZWNpc2lvbiBiYXNlZCBvbiB0aGF0IGRhdGEu IFRoaXMgaXMgYSBodWdlIGFkdmFudGFnZSBpbiB0ZXJtcyBvZiBwZXJmb3JtYW5jZSwgc2NhbGFi aWxpdHkgYW5kIGNvc3Qgc2luY2UgdGhlcmUgaXMgbm8gbmVlZCBmb3IgVG9rZW4gSW50cm9zcGVj dGlvbiBvciBvdGhlciBraW5kcyBvZiBhY2Nlc3MgdG8gYW5vdGhlciBzZXJ2aWNlcyBvciBkYXRh YmFzZS4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCmJlc3QgcmVnYXJkcywNClRvcnN0ZW4uIA0K DQo+IE9uIDE5LiBNYXIgMjAyMCwgYXQgMTg6MzUsIFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGlt aXJAY29ubmVjdDJpZC5jb20+IHdyb3RlOg0KPiANCj4gDQo+IE9uIDE5LzAzLzIwMjAgMTk6MTEs IFRvcnN0ZW4gTG9kZGVyc3RlZHQgd3JvdGU6DQo+PiBPbiAxOS4gTWFyIDIwMjAsIGF0IDE3OjQ3 LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KPj4+IFdlbGwsIGl04oCZ cyBpbiBzY29wZSBhcyBtdWNoIGFzIGRlc2NyaWJpbmcgYW55IG90aGVyIGFzcGVjdCBvZiB3aGF0 IHRoZSB0b2tlbiBpcyBmb3IgYW5kIHdoYXQgaXQgcmVwcmVzZW50cyBpcyBpbiBzY29wZS4gVGhh dCBpcyBhbG9uZ3NpZGUgdGhpbmdzIGxpa2UgdGhlIGludGVuZGVkIGF1ZGllbmNlIG9mIHRoZSB0 b2tlbiwgdGhlIGFjY2VzcyByaWdodHMgZm9yIHRoZSB0b2tlbiwgdGhlIHByZXNlbnRhdGlvbiBr ZXlzIHRoZSB0b2tlbiBpcyBib3VuZCB0bywgZXRjLiBJdCBjb3VsZCBiZSBpbmZvcm1hdGlvbiBp biB0aGUgdG9rZW4gdGV4dCBpdHNlbGYgKGxpa2UgYSBKV1QpLCBpdCBjb3VsZCBiZSBpbnRyb3Nw ZWN0ZWQgZnJvbSB0aGUgQVMsIGl0IGNvdWxkIGJlIHJlZmVyZW5jZWQgaW4gc29tZSBvdGhlciB3 YXkuIFNvIGlmIHdlIGNhbiBkZWZpbmUgaWRlbnRpdHkgYXNwZWN0cyBpbiB0aGF0LCB0aGVuIHdl 4oCZcmUgZmluZSBpbiBjb3ZlcmluZyBpdCB0aGVyZS4gDQo+Pj4gDQo+Pj4gQnV0IGhlcmXigJlz IHRoZSB0aGluZzogbm9uZSBvZiB0aGF0IGhhcyBhbiBpbXBhY3Qgb24gdGhlIGNvcmUgcHJvdG9j b2wuIFRoYXQgaXMgZW50aXJlbHkgdXAgdG8gdGhlIEFTIGFuZCB0aGUgUlMgdG8gYWdyZWUgb24s IGFuZCB0aGUgY2xpZW50IG5ldmVyIHNlZXMgb3IgaGFzIGFueSBpbmZsdWVuY2Ugb24gaXQuIFRo YXQgcG9ydGlvbiBvZiB0aGUgcHJvdG9jb2wgaXMgY29tcGxldGVseSBvcGFxdWUgdG8gdGhlIGNs aWVudC4gVGhlcmVmb3JlLCBpdCBkb2VzbuKAmXQgcmVhbGx5IGFmZmVjdCB0aGUgYXV0aG9yaXph dGlvbiBhbmQgZGVsZWdhdGlvbiBwb3J0aW9ucyBvZiB0aGUgY2xpZW50IHRhbGtpbmcgdG8gdGhl IEFTIGFuZCB0aGUgY2xpZW50IHRhbGtpbmcgdG8gdGhlIFJTLg0KPj4+IA0KPj4+IFRoaXMgZG9l cyByYWlzZSB0aGUgcXVlc3Rpb24gb2Ygd2hhdCBvdXIgYmFyIG9mIGludGVyb3BlcmFiaWxpdHkg aXMgZ29pbmcgdG8gYmUgd2l0aCBUeEF1dGg6IGRvIHdlIGV4cGVjdCBpbmRlcGVuZGVudCBBUyBh bmQgUlMgaW1wbGVtZW50YXRpb25zIHRvIHRhbGsgdG8gZWFjaCBvdGhlcj8gVGhhdOKAmXMgbm90 IHNvbWV0aGluZyBPQXV0aCAyIHdhcyBldmVyIGNvbmNlcm5lZCB3aXRoLCB0aG91Z2ggb2J2aW91 c2x5IEpXVCBhbmQgaW50cm9zcGVjdGlvbiBhcmUgYm90aCBmcm9tIHRoZSBPQXV0aDIgV0cgYW5k IHNvbHZlIHRoYXQgcHJvYmxlbS4NCj4+IFRoZXJlIGFyZSB0d28gYXNwZWN0cyB0byBpdDogaW50 ZXJvcGVyYWJpbGl0eSBhbmQgdmVuZG9yIHN1cHBvcnQuIA0KPj4gDQo+PiBJbnRlcm9wZXJhYmls aXR5IGJldHdlZW4gQVMgYW5kIFJTIGlzIGltcG9ydGFudCBpZiBkZXBsb3ltZW50cyB3YW50IHRv IGNvbWJpbmUgcHJlLXBhY2thZ2VkIFRYQXV0aCBhbmQgQVBJIGltcGxlbWVudGF0aW9ucy4gSSB0 aGluayB0aGF0IG1ha2VzIGEgbG90IG9mIHNlbnNlIGFuZCBzaG91bGQgYmUgaW5jbHVkZWQgaW4g dGhlIGNoYXJ0ZXIuDQo+IA0KPiArMQ0KPiANCj4gVGhlIGN1cnJlbnQgT0F1dGggMi4wIHN0YXR1 cyBxdW8gb2YgdGhlIGxhcmdlbHkgdW5zcGVjaWZpZWQgDQo+IHJlbGF0aW9uc2hpcCBiZXR3ZWVu IEFTIGFuZCBSUyBpcyBhbHNvIG1ha2luZyB0aGUgbGlmZSBvZiB3ZWIgJiBzZWMgDQo+IGZyYW1l d29yayBtYWludGFpbmVycyBkaWZmaWN1bHQuIFdlIHdpdG5lc3NpbmcgdGhpcyB3aXRoIHBlb3Bs ZSANCj4gaW50ZWdyYXRpbmcgdGhlIE9BdXRoIFNESyBpbnRvIGZyYW1ld29ya3MuIFZpdHRvcmlv J3MgcmVjZW50IHdvcmsgdG8gDQo+IHB1dCB0b2dldGhlciBhIG1pbmltYWwgaW50ZXJvcGVyYWJs ZSBKV1QgcHJvZmlsZSBmb3IgYWNjZXNzIHRva2VucyBpcyANCj4gaGVscGZ1bCwgYnV0IGl0IGhh cyBjb21lIGFmdGVyIHRoZSBmYWN0LiBBbmQgdGhlcmUgaXMgbm90IGFncmVlbWVudCBvbiANCj4g dGhpbmdzIGxpa2UgYXV0aG9yaXNpbmcgYWNjZXNzIHRvIGNsYWltcy4NCj4gDQo+IEludGVncmF0 aW5nIGFwcHMgKFJTcykgd2l0aCBUeEF1dGggc2hvdWxkIGJlIHN0cmFpZ2h0Zm9yd2FyZCBhbmQg c2ltcGxlLg0KPiANCj4gVGhpcyBjYW4gaGF2ZSBhIGVub3Jtb3VzIGVmZmVjdCBvbiBhZG9wdGlv bi4NCj4gDQo+IA0KPj4gVmVuZG9ycyBzdXBwb3J0OiB2ZW5kb3Igc3VwcG9ydCB3aGVuIGl0IGNv bWVzIHRvICJ3aGF0IGNhbiBnbyBpbnRvIGFuIGFjY2VzcyB0b2tlbiIgYW5kICJ3aGF0IGNhbiBi ZSBjb252ZXllZCBpbiBhIHRva2VuIGludHJvc3BlY3Rpb24gcmVzcG9uc2XigJ0gZ3JlYXRseSBk ZXZpYXRlcyBpbiBteSBvYnNlcnZhdGlvbi4gVGhpcyBhbHNvIG1lYW5zIGltcGxlbWVudGF0aW9u IHVzZSB2ZW5kb3JzIHNwZWNpZmljIGZlYXR1cmVzIHJlc3RyaWN0aW5nIHRoZWlyIGFiaWxpdHkg dG8gdXNlIG90aGVyIHNvbHV0aW9ucy4gVFhBdXRoIHNob3VsZCBhaW0gYXQgaW1wcm92aW5nIHRo ZSBzaXR1YXRpb24uICANCj4gDQo+ICsxDQo+IA0KPiANCj4+IEkgYWxzbyB0aGluayBpdCBpcyBh IGdvb2QgZXhlcmNpc2UgZm9yIHRoZSBncm91cCB0byB0aGluayB0aGUgd2hvbGUgcHJvY2VzcyAi ZnJvbSB0aGUgZW5k4oCdLiBUaGUgcHVycG9zZSBvZiBUWEF1dGggKGFuZCBPQXV0aCkgaXMgbm90 IHRvIHByb3ZpZGUgY2xpZW50cyB3aXRoIGFjY2VzcyB0b2tlbnMuIFRoZSBwdXJwb3NlIGlzIHRv IGVuYWJsZSBBUEkgcmVxdWVzdCBwcm9jZXNzaW5nIGluIGEgc2VjdXJlIG1hbm5lci4gV2hhdCBp dCByZWFsbHkgdGFrZXMgdG8gYWNoaWV2ZSB0aGF0IGdvYWwgaXMgbm90IG9idmlvdXMgaWYgdGhl IHdvcmsgYWx3YXlzIHN0b3BzIGF0IHRoZSDigJx5b3UgaGF2ZSB5b3VyIGFjY2VzcyB0b2tlbiwg Z29vZCBsdWNr4oCdIHN0YWdlLiANCj4gDQo+ICsxDQo+IA0KPiBWbGFkaW1pcg0KPiANCj4gDQo+ IC0tDQo+IFR4YXV0aCBtYWlsaW5nIGxpc3QNCj4gVHhhdXRoQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCi0tDQpUeGF1dGggbWFpbGlu ZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoDQo= From nobody Fri Mar 20 14:32:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42763A0DC5 for ; Fri, 20 Mar 2020 14:31:59 -0700 (PDT) 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, 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=mattr-global.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 FHe39P6_EBS4 for ; Fri, 20 Mar 2020 14:31:57 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 990253A0EC3 for ; Fri, 20 Mar 2020 14:31:56 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id d8so8670577qka.2 for ; Fri, 20 Mar 2020 14:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8cFqRJGSN2AF26tSvd04kwfmtOI06gqXF79suUwV20o=; b=B2eMRaisr3JLP72DXzOY2gPjWHRN6IF/mN+PgKh+mUlmy5riDeRo5uuvDlec5efARo jhUgduvTNV6xh6az+OsCv4zyIiVYFm71oU8hKE7sR++Rqr22yu2Iu35RNNetWrL4piAO 3osQ/ZzRMOIuW0IPgQaDubcsDUSISi3DQQbSXNtZf/FiYnQ70FzpVUZZ3aFn/hAsBmhf smS8JhRpA8SG5W2E8qbFAqmm+j8S4Caf9JdEtx8CbUVumK/IQ0ZqoFVAyk5oG0O6y+xJ Ja+DJq3RUQauB5tcVRWtpz6jNyoY3fWhgQ2nMa2RDk5P+qVQT0fsJydoLXydvT1uhhTL d4GA== 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=8cFqRJGSN2AF26tSvd04kwfmtOI06gqXF79suUwV20o=; b=cLrckc1rcTcDnHYJBipYGexLOp4u20Ov1b8mfTZ2UCpvjObihnT4N5KCqoUVHPubtJ YMnMIwopD/OAWbG09s43BxswMP33WKfMsRJjIweIhvpIgl5Sl0nlvWzpNRdDgoPNKXZ6 7xTQbnOqvRTxZcmhEnJ147UEhPVzJx8A8hpjQjaSX54ZwWGhL9wE3Sn0Vi0QYgFUyaXw T1Bim9xNbRe7Wo14SxAEYpKvRNp4oCU2vc036KJLsmP2Ce8OVUoAfwtaSzC5jQozxBNW hMSOxsHLGMups+s/winTKVJ3TyrLzsyB1voPdRYr8UzgYSC0kYEJ1FEQxTPbdbvkfupW fyrg== X-Gm-Message-State: ANhLgQ3wFxXioCe/rjU1CGYV3toHbRiH2vkhZUL4Eqfp70IsfgaRDfNU c6jeLvArlGL46ps542ZkIEe3Kxux27ViuFI8BNqTVoYM4PGPtEvq4kmwSpwIZwWfvo0Q4guwxGo XejIeT1rUlG+qR6/d7w== X-Google-Smtp-Source: ADFU+vuU1v5bRIkgbUpZApKW3jUB3IlgJsGa12MQ2DxKfRM4k54Vac8WfinqNtPQOnj3VLg2bG22BZ4lL5bu4XUtfZ0= X-Received: by 2002:a37:844:: with SMTP id 65mr9634367qki.15.1584739914805; Fri, 20 Mar 2020 14:31:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Looker Date: Sat, 21 Mar 2020 10:31:43 +1300 Message-ID: To: Dick Hardt Cc: txauth@ietf.org Content-Type: multipart/related; boundary="000000000000af253105a1500301" Archived-At: Subject: Re: [Txauth] Client bound user assertions X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:32:00 -0000 --000000000000af253105a1500301 Content-Type: multipart/alternative; boundary="000000000000af252f05a1500300" --000000000000af252f05a1500300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, Yes that's correct. Thanks, Tobias On Sat, 21 Mar 2020, 08:48 Dick Hardt, wrote: > Hi Tobias > > Let me see if I understand the end goal. > > The Client presents a assertion about the user created by the AS, when > their are interacting with to a relying party. > > Correct? > > There are a number of ways to solve this, but in my opinion, creating the > missing features for this to be done would be in scope of TxAuth. > > > > On Thu, Mar 19, 2020 at 3:23 PM Tobias Looker > wrote: > >> Hi, >> >> I'm unsure of the best way to articulate this idea on this forum, but se= e >> my below explanation for an attempt. I'm also aware that it as a discuss= ion >> topic is dependent on how "identity" fits into TxAuth in general. >> >> With OpenID connect today the format of the user assertions we get are >> often bound to the client (or a small audience) mainly by the issuer usi= ng >> the audience field in the id_token to communicate who it is for (e.g thi= s >> is for client x) which gives all parties a way to determine whether they >> are the intended audience of the assertion. However, this does not enabl= e a >> client to authenticate as the intended audience of the user assertion to >> other parties. If a client was instead able to authenticate as the right= ful >> audience of a user assertion then they would be able to onward disclose = the >> user assertion to a relying party, such that the relying party would be >> able to authenticate both the original issuer of the assertion and the >> client now presenting the assertion. >> >> See below for a simple example. >> >> Here the client obtains a user assertion from the OP or Authorization >> server that is suitably bound to the client in an authenticatable way. >> >> [image: Screen Shot 2020-03-12 at 10.05.15 AM.png] >> >> The relying party now makes a request to the client who is in possession >> of the assertion from the authorization server and the client can respon= d, >> presenting the assertion. In this flow, with regards to OIDC, the client= is >> essentially taking a similar role to that of a self issued openid connec= t >> provider. >> >> [image: Screen Shot 2020-03-12 at 10.05.20 AM.png] >> >> How this could be realized in TxnAuth? >> >> If the client strongly authenticates at the start of an authorization >> transaction e.g by signing the original authorization request with eithe= r >> an ephemeral or static key, the resulting assertion could be bound to th= is >> key enabling the client to authenticate as the rightful audience of the >> assertion to other relying parties. Similar to how DPOP for access_token= s >> works. >> >> Why is this interesting and what use cases does it enable? >> >> Being able to obtain user assertions that can be bound to the client suc= h >> that the client can onward disclose them enables new opportunities aroun= d >> how users can manage different sources of their identity information >> through a single client. This can help to eliminate things like the nasc= ar >> problem and presentations to relying parties that require aggregating >> assertions from multiple authorization servers. >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --=20 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --000000000000af252f05a1500300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

Yes that's correct.

Thanks,
Tobias


On Sat, 21 Mar = 2020, 08:48 Dick Hardt, <dick.hardt@gmail.com> wrote:
Hi Tobias

Let me see if I= understand the end goal.=C2=A0

The Client present= s a assertion=C2=A0about the user created by the AS, when their are interac= ting with to a relying party.

Correct?
<= br>
There are a number of ways to solve this, but in my opinion, = creating the missing features for this to be done would be in scope of TxAu= th.



On Thu, Mar 19, 2020 at 3:23 PM Tobi= as Looker <tobias.looker@mattr.global> wrote:
Hi,
I'm unsure of the best way to articulate this idea on this = forum, but see my below explanation for an attempt. I'm also aware that= it as a discussion topic is dependent on how "identity" fits int= o TxAuth in general.=C2=A0

With OpenID connect tod= ay the format of the user assertions we get are often bound to the client (= or a small audience) mainly by the issuer using the audience field in the i= d_token to communicate who=C2=A0it is for (e.g this is for client x) which = gives all parties a way to determine whether they are the intended audience= of the assertion. However, this does not enable a client to authenticate a= s the intended audience of the user assertion to other parties. If a client= was instead able to authenticate as the rightful audience of a user assert= ion then they would be able to onward disclose the user assertion to a rely= ing party, such that the relying party would be able to authenticate both t= he original issuer of the assertion and the client now presenting the asser= tion.

See below for a simple example.
Here the client obtains a user assertion from the OP or Author= ization server that is suitably bound to the client in an authenticatable w= ay.

3D"Screen

The relying party now makes a request t= o the client who is in possession of the assertion from the authorization s= erver and the client can respond, presenting the assertion.=C2=A0In this fl= ow, with regards to OIDC, the client is essentially taking a similar role t= o that of a self issued openid connect provider.

<= img src=3D"cid:ii_k7ntxqms1" alt=3D"Screen Shot 2020-03-12 at 10.05.20 AM.p= ng" width=3D"562" height=3D"314" style=3D"outline:0px">
=C2= =A0
How this could be realized in TxnAuth?=C2=A0

If the client strongly authenticates at the start of an authorizat= ion transaction e.g by signing the original authorization request with eith= er an ephemeral or static key, the resulting assertion could be bound to th= is key enabling the client to authenticate as the rightful audience of the = assertion to other relying parties. Similar to how DPOP for access_tokens w= orks.

Why is this interesting and what use cases d= oes it enable?

Being able to obtain user assertion= s that can be bound to the client such that the client can onward disclose = them enables new opportunities around how users can manage different source= s of their identity information through a single client. This can help to e= liminate things like the nascar problem and presentations to relying partie= s that require aggregating assertions from multiple authorization servers.<= /div>

Thanks,
=3D"Mattr=C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D=3D"Ma=3D"Mattr
3D"Mattr=C2=A0
Tobia= s Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"=3D"Mattr3D"Mattr

This communication, including any attachments, is confidential. If you are= not the intended recipient, you should not read it - please contact me imm= ediately, destroy it, and do not copy or use any part of this communication= or disclose anything about it. Thank you. Please note that this communicat= ion does not designate an information system for the purposes of the Electr= onic Transactions Act 2002.

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
-- <= br> Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--000000000000af252f05a1500300-- --000000000000af253105a1500301 Content-Type: image/png; name="Screen Shot 2020-03-12 at 10.05.15 AM.png" Content-Disposition: inline; filename="Screen Shot 2020-03-12 at 10.05.15 AM.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_k7ntxqmx2 iVBORw0KGgoAAAANSUhEUgAAAv4AAAG5CAYAAAD20DDwAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV lgdUk1kWx9/3fekktECkE3qT3gJICT0UQTqISkgCCSWGhCBiR8QRsKEiAuqIDUTBsQAyqIgotkGx gH1AREUdBws2VPYDljCze3b37D3n5f3OzX333fvOd8/5A0D+xhaJMmBFADKF2eKIAG96XHwCHf8U QAABROAIDNgciYgZHh4CUJva/24fe9Bo1G5Zjuf69///qylxeRIOAFA4yslcCScT5RPoesIRibMB QMpRv8GibNE4t6KsIkYLRPnGOKdO8tNxTp7kzxMxURE+AGDIABDIbLY4FQCyGuqn53BS0TxkBso2 Qq5AiDIfZQ8On81FuQblmZmZC8f5NsqmyX/Jk/q3nMmynGx2qowne5kwgq9AIspgL/4/n+N/W2aG dOoOYzDegDgwAt1J6JvdTV8YLGNh8uywKRZwJ+InmC8NjJ5ijsQnYYq5bN9g2dmM2SFTnCLwZ8ny ZLOippgn8YucYvHCCNldKWIf5hSzxdP3StOjZX4+jyXLn8ePip3iHEHM7CmWpEcGT8f4yPxiaYSs fp4wwHv6Xn9Z75mSv/QrYMnOZvOjAmW9s6fr5wmZ0zklcbLauDxfv+mYaFm8KNtbdpcoI1wWz8sI kPklOZGys9noBzl9Nlz2hmnsoPApBnbAAZ03G4C+RjYvN3u8AZ+FosViQSo/m85EJ4tHZwk5VjPp djZ2NgCMz+nkZ/CeNjF/EO3KtC83GQD3dADgwGlfXBwADaYAqMdN+4w1AaCiM9e0niMV50z6MOM/ WLQqBaAC1IEOMACmwBKtzwm4AS/gB4JAGIgC8WA+4AA+yARisAgsBatAISgGm8A2UAF2g72gBhwB x0ATaAXnwEVwFdwAd8AD0AcGwSswDD6CUQiC8BAFokLqkC5kBFlAdhAD8oD8oBAoAoqHkqBUSAhJ oaXQaqgYKoUqoD1QLfQLdAo6B12GuqF7UD80BL2DvsIITIZVYG3YGLaGGTATDoaj4HlwKpwF58EF 8Aa4HK6GD8ON8Dn4KnwH7oNfwSMIQOQQGqKHWCIMxAcJQxKQFESMLEeKkDKkGqlHWpBO5BbSh7xG vmBwGCqGjrHEuGECMdEYDiYLsxxTgqnA1GAaMR2YW5h+zDDmB5aC1cJaYF2xLGwcNhW7CFuILcMe wJ7EXsDewQ5iP+JwOBrOBOeMC8TF49JwS3AluJ24Blwbrhs3gBvB4/HqeAu8Oz4Mz8Zn4wvxO/CH 8WfxN/GD+M8EOYIuwY7gT0ggCAn5hDLCIcIZwk3Cc8IoUZFoRHQlhhG5xMXEjcR9xBbideIgcZSk RDIhuZOiSGmkVaRyUj3pAukh6b2cnJy+nIvcHDmB3Eq5crmjcpfk+uW+kJXJ5mQfciJZSt5APkhu I98jv6dQKMYUL0oCJZuygVJLOU95TPksT5W3kmfJc+VXyFfKN8rflH+jQFQwUmAqzFfIUyhTOK5w XeG1IlHRWNFHka24XLFS8ZRir+KIElXJVilMKVOpROmQ0mWlF8p4ZWNlP2WucoHyXuXzygNUhGpA 9aFyqKup+6gXqIMqOBUTFZZKmkqxyhGVLpVhVWVVB9UY1VzVStXTqn00hGZMY9EyaBtpx2g9tK8z tGcwZ/BmrJtRP+PmjE9qmmpeajy1IrUGtTtqX9Xp6n7q6eqb1ZvUH2lgNMw15mgs0tilcUHjtaaK ppsmR7NI85jmfS1Yy1wrQmuJ1l6ta1oj2jraAdoi7R3a57Vf69B0vHTSdLbqnNEZ0qXqeugKdLfq ntV9SVelM+kZ9HJ6B31YT0svUE+qt0evS29U30Q/Wj9fv0H/kQHJgGGQYrDVoN1g2FDXMNRwqWGd 4X0johHDiG+03ajT6JOxiXGs8VrjJuMXJmomLJM8kzqTh6YUU0/TLNNq09tmODOGWbrZTrMb5rC5 oznfvNL8ugVs4WQhsNhp0T0TO9NlpnBm9cxeS7Il0zLHss6y34pmFWKVb9Vk9cba0DrBerN1p/UP G0ebDJt9Ng9slW2DbPNtW2zf2Znbcewq7W7bU+z97VfYN9u/dbBw4DnscrjrSHUMdVzr2O743cnZ SexU7zTkbOic5Fzl3MtQYYQzShiXXLAu3i4rXFpdvrg6uWa7HnP9083SLd3tkNuLWSazeLP2zRpw 13dnu+9x7/OgeyR5/OzR56nnyfas9nziZeDF9Trg9ZxpxkxjHma+8bbxFnuf9P7k4+qzzKfNF/EN 8C3y7fJT9ov2q/B77K/vn+pf5z8c4BiwJKAtEBsYHLg5sJelzeKwalnDQc5By4I6gsnBkcEVwU9C zEPEIS2hcGhQ6JbQh7ONZgtnN4WBMFbYlrBH4SbhWeG/zsHNCZ9TOedZhG3E0ojOSGrkgshDkR+j vKM2Rj2INo2WRrfHKMQkxtTGfIr1jS2N7YuzjlsWdzVeI14Q35yAT4hJOJAwMtdv7ra5g4mOiYWJ PfNM5uXOuzxfY37G/NMLFBawFxxPwibFJh1K+sYOY1ezR5JZyVXJwxwfznbOK64Xdyt3iOfOK+U9 T3FPKU15keqeuiV1iO/JL+O/FvgIKgRv0wLTdqd9Sg9LP5g+lhGb0ZBJyEzKPCVUFqYLOxbqLMxd 2C2yEBWK+rJcs7ZlDYuDxQckkGSepDlbBRVE16Sm0jXS/hyPnMqcz4tiFh3PVcoV5l5bbL543eLn ef55+5dglnCWtC/VW7pqaf8y5rI9y6HlycvbVxisKFgxuDJgZc0q0qr0Vb/l2+SX5n9YHbu6pUC7 YGXBwJqANXWF8oXiwt61bmt3/4T5SfBT1zr7dTvW/SjiFl0ptikuK/5Wwim5st52ffn6sQ0pG7o2 Om3ctQm3SbipZ7Pn5ppSpdK80oEtoVsat9K3Fm39sG3BtstlDmW7t5O2S7f3lYeUN+8w3LFpx7cK fsWdSu/KhiqtqnVVn3Zyd97c5bWrfrf27uLdX38W/Hx3T8Cexmrj6rK9uL05e5/ti9nXuZ+xv/aA xoHiA98PCg/21UTUdNQ619Ye0jq0sQ6uk9YNHU48fOOI75Hmesv6PQ20huKj4Kj06Mtfkn7pORZ8 rP0443j9CaMTVSepJ4saocbFjcNN/Ka+5vjm7lNBp9pb3FpO/mr168FWvdbK06qnN54hnSk4M3Y2 7+xIm6jt9bnUcwPtC9ofnI87f7tjTkfXheALly76Xzzfyew8e8n9Uutl18unrjCuNF11utp4zfHa yd8cfzvZ5dTVeN35evMNlxst3bO6z9z0vHnulu+ti7dZt6/emX2nuye6525vYm/fXe7dF/cy7r29 n3N/9MHKh9iHRY8UH5U91npc/bvZ7w19Tn2n+337rz2JfPJggDPw6qnk6bfBgmeUZ2XPdZ/XvrB7 0TrkP3Tj5dyXg69Er0ZfF/6h9EfVG9M3J/70+vPacNzw4Fvx27F3Je/V3x/84PChfSR85PHHzI+j n4o+q3+u+cL40vk19uvz0UXf8N/Kv5t9b/kR/OPhWObYmIgtZk9IAQRdcEoKAO8OAkCJR7UCqrtJ cyd19IRBk9p/gsB/4kmtPWFOAOxvAyB6JQCB6F6J7sboruwFwLgUivICsL29bP3TJCn2dpO5yKii xH4eG3uvDQC+BYDv4rGx0Z1jY9/3ocXeA6Ata1K/T0iYAQAM0aRQbBfJKRf8i/0D0d0MkN0RdPQA AAGdaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjc2 NjwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj40 NDE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KsQmUcwAAQABJREFUeAHsnQm4HUWZv+smN/tyb3bWJBBCIOw7 SJAAIoJRUEBwVLbRUXQWdEZhHEdgnkfFGZ0ZRwXRPw6MGyiCQERQloSwKIZNQiBsSQiB7Lk3+37/ 9aukDn36dPfps91zTt+3nufe7q71q7fqdH9dXfVVS5d1JsZ1dnaatra2mNBk74ULF5px48YlR4oJ raTcZkwLq5iOEOENqwgoMV6wigET4Q2rCCgxXrCKARPhDasIKDFesIoBE+ENqwgoMV6wKgTTq9AL HwhAAAIQgAAEIAABCEAgawRQ/LPWotQHAhCAAAQgAAEIQAACEQRQ/COg4AUBCEAAAhCAAAQgAIGs EUDxz1qLUh8IQAACEIAABCAAAQhEEEDxj4CCFwQgAAEIQAACEIAABLJGAMU/ay1KfSAAAQhAAAIQ gAAEIBBBAMU/AgpeEIAABCAAAQhAAAIQyBoBFP+stSj1gQAEIAABCEAAAhCAQAQBFP8IKHhBAAIQ gAAEIAABCEAgawRQ/LPWotQHAhCAAAQgAAEIQAACEQRQ/COg4AUBCEAAAhCAAAQgAIGsEWjp6Ojo qkWlbL6mvb29FllnLk9YpW9SWMEqPYH0MelXsEpPIH1M+hWs0hNIH5N+Bav0BApjtra1tRX67vLp 7Ow0SeGxCW2AOma5aSsptxnTwiqpJ+WHwSqfR9IVrJLo5IfBKp9H0hWskujkh8Eqn0fSFayS6OSH wSqfR9IVrArpMNWnkAk+EIAABCAAAQhAAAIQyBwBFP/MNSkVggAEIAABCEAAAhCAQCEBFP9CJvhA AAIQgAAEIAABCEAgcwRQ/DPXpFQIAhCAAAQgAAEIQAAChQRQ/AuZ4AMBCEAAAhCAAAQgAIHMEUDx z1yTUiEIQAACEIAABCAAAQgUEkDxL2SCDwQgAAEIQAACEIAABDJHAMU/c01KhSAAAQhAAAIQgAAE IFBIAMW/kAk+EIAABCAAAQhAAAIQyBwBFP/MNSkVggAEIAABCEAAAhCAQCEBFP9CJvhAAAIQgAAE IAABCEAgcwRQ/DPXpFQIAhCAAAQgAAEIQAAChQRQ/AuZ4AMBCEAAAhCAAAQgAIHMEWjp6OjoqkWt bL6mvb29FllnLk9YpW9SWMEqPYH0MelXsEpPIH1M+hWs0hNIH5N+Bav0BApjtra1tRX67vLp7Ow0 SeGxCW2AOma5aSsptxnTwiqpJ+WHwSqfR9IVrJLo5IfBKp9H0hWskujkh8Eqn0fSFayS6OSHwSqf R9IVrArpMNWnkAk+EIAABCAAAQhAAAIQyByBhlH8t2/fbq699lr31x2UZ8yY0a3ldUedKGMngQUL Fri2VRsXc6XELZYX4Y1HoFnad/HixQ13P9L9+Oabby5o1D/84Q9O1t/85jcuLC5eQcIID38fVjsV c48++mjq33WxvBotvBH6aTXa8Y033mg0tMgDAQiECNRM8f/Vr35lPv3pT5uTTjrJTfnZf//9zXnn nWf++Z//2UTd5Ldt29btN3Xd6BrJPfvss+bUU081n//8551YeujqWv649ARKeYiWEje9BMRsFALd 1b6V/nb/9Kc/ufvfCSec0CjonDxhxV/3pr/5m79xYd/5znecrNVQGKOeCWEQKP5hItW9rkY7ovhX t03IDQK1INBai0wvuOACI8V/0KBB5tBDDzWXXnqp0Q1BD8df//rX5vvf/775n//5H3PJJZfkipfi 39WVfp2xHkh//dd/bfSloFz34IMPmpaWlnKTVz3d4Ycfbh5++GHz7ne/2+Wth6GuNUcNVxqBUvpS KXFLk4LY3Ung+eefd7+dHTt25IrVb0q/83322SfnV4uTSn+7Tz75pBk/frw57rjjaiFeWXmKW9BA g+5D//3f/2323HNPI9Y+LByv1MJK+f2VErdUOeodvzvrNnz4cHPHHXeYqVOn5qrdne2YK5QTCECg 2wlUXfHXqMEvf/lLc/7555tvfetbZu+9984p17qx3XrrreaKK64wl112mdFXgHe9612u0lL8S3Ev vPBCSS8K4byDN7xwWKNd+wdso8mFPBBoJAJSRsPKk347p5xySt3ETPvb1Yi/RvvLNYhQiwqGuflR +fe+971m2LBhuSLD8XIBnDQkAbXj6tWrC2Tz7SgDGTgIQCC7BKqq+D/xxBPuE/Bpp51m/uM//sOM HTs2j5xG1z/60Y+6h8aZZ57ppgL98Y9/dF8Gtm7dmov7yiuvmNmzZxuNgm3YsMHsu+++5utf/7oL 14P93/7t38zcuXPdtZ+uc/XVV+fSa97o/fff7+KMGDHCjBs3zr2ITJ48OS/OzJkz3bXSKt9vfvOb pl+/fkbXP/3pT83TTz9tXn/9dXPggQeaf/qnfzLKK43T1w6N1L/00ktO9iOPPNKVP2rUqDTJc3G8 0qDRRDnVSzJLvltuucX96QXr8ssvd+G6oetLip8apBHED37wg+acc85x4cX+Kb3yPfnkk93oozjL T+7iiy92f+7C/tMXHI0YKa7kVFxx/q//+i8fxWgO8COPPJKTR/X4+7//+5zSoPDnnnvO5StZw05f dRYuXOjq68P0xUif/P1XkLPPPtul96x8PH8UCzFRPfRyqa9Eqksxp/zF4q677nJR9fVKU9XSpFWC qH7py4wKe/HFF90L85IlS1ydxfX00083EyZM8MlyR6X38Q444ABzxBFHmI985COu7/pIiqM6fPnL Xza//e1vzf/93/+5tgr+TnxcfwzWWaxGjhxpPF8fxx/FU3z8b0jy6i/8Qp02nvJVfrfffrtZv369 K8aXHWxb/xtQO/i2veiiixwzjVjKBfn68sOy+bqq/ylO3759je5J//AP/+Dy8P+CfVD9VRyVVv1V fdn/Nn18f/Qyx4X7eDrOmTPHSPH/93//96B33rlG2qWQxbWf6qzfX/Arqu+/klcuiWfwniKeyieY p+eufNRXg2HBc4XLeb7+9yMeaoMPfehDsS83KkO/VaVVfMmR5t6l9qvkvid5VbbaVnn5+1TwnhTs B6qv+v1//ud/5to/SgbJH/WlSf1WZemoeqofxbkojr4dg2mC8qku3/72t93vKNxPFc//Zv3vV78l xfPtqDbyLm35Pj5HCECgCQhYhTfW2R99bFhUwGc/+1nN1em66aabuuyNMCpKzs8qYC7u3Xff7fze fvttd20Vh64TTzyxy958u+zDqGu//fZz/nb6kItnP+N32QeI+7MvErlzn/EnPvGJLvlbJb9L8tgH h7vu1atXnkxWMXf+11xzTS5fpbOjHl2f+tSnXJjKt4qzK99+gvdFRB7Fyr6wdJ111lkureqh9FYx d9fHH398ZDp5BlkpjWSTmz9/vsvDXdh/CpOM//u//+uO9kHfddVVV7ngZ555psuOwjlZ7YOhy97M uxSu+Haqlc8i7xhuX89EaZWXOCsvOwpZkM/06dOdn1WUcuUqnXf24eHCDzvsMCeL8lI+ynfWrFku mq+H8gg7OyKVS+/DVA/VR3mKhWTTtfJUfO9UD/VDH+7rYb8+ufj2i5OP6lgrrvLzTtztAztXluQ7 +OCD3bVVsn20xKPaX/nKhTnLX+He2alvXXb6hONzxhlndNk51F32QezKs2tifDR3tMqEy1fp/Z8Y TJkypcsqZLm4qo/KsUqAy0fnvq/nIgVOxE91U17iduWVVzrOug7X2bebZBQb/Xl5xdbXt1i8QPGu j6ostZHyU5vpWm2rvu2d6iV/f1Sfsi+bLv7QoUNdnZVWf3K+Tyu+d8H2VTyVZ1/uXb7huipc5Ymd 6ig28hNPyaa8fH1VhsqTk3+wTOcZ8U9pf/SjH7n87EBHRIydXpJRctx55525OL5c+SlMceSCbel/ fzoqjuqncJ9WMspfDHXUPcPLrWvVVU5t6eutvqpzX14wnuIGy1c85efLt1M/FSXnFCaWvn6KL8b+ nqNyvdO9TnGVxru09z1fX58ueAzeV1S2v2/6spVWcqme6geek2/rJBl0/w8631aqn8rSn/qV7p3h uv3lL38puA95jnH9VO1oXybcc0gyB/up5BBn1U/+yktx/O/Lt6NnFWxHySnuceUrTHnquVCuCz4H S83Dy1xqOsVvxrSwSt/SsCpktVMzKfR3PqX+ILyyY0eD85TZqOyvv/56d6P48Y9/7IIXLVrkrpWH bvBS8OV0tCOtLkxKjPfzN2KF+7h2ipGLp5uQ91N8vYjopvSlL33Jpdc/3bTl55Uhxde1FH+lt2sH cnH10qEwa80i5xc+ESu78M3Fu+222/KC7eiZ87/nnnvy/P1F2o7pb656UNivEa6Ovo2kqEpG+Xun OumGLX/VN+x8Wu/vmSi+Hnqe4apVq9wNX/7+IaEbvK79Q8vHVV5KqzA9zLy/jpJN/nbBty/SPeCV R9jpAaa4yktO5erajoLn8pS/HXVz/r4d5Resh/qXl0Gc9eBSPvOtYhaMK7be6WVRcYJp9RD0/CVb Med/C4oX5qy8Fe6dzqUIPPTQQ97LyWy/FHUdc8wxXXZam/O3X6GcXHZ6XNe6detycb/3ve85f730 eudlVfsr3DPw4eGj5y2ecpJZabxCElQ49duTvOoX3imu72v2K43zLhZPTOWC/cX7KT/xECv9Jr3z 9VKfCbaP4mvAQPF1rj853xeUzju9lIbbd77tD76uwfZVHRRX/cbXV3n7fqe44fb15aQ5Ku0nP/nJ rqOPPjoxuu//ktE7X66XW3WQ029BMkvJ8xx0FC/5637k0wZ5+nuKy8T+U1zV3zvlEc5XYeF4vj2V d7B8X5b/TSut91N/Cpb/+uuvuz6mlyvvohT/tPc9X1+flz96VmrPoKxewRVTpQ32g6CcykcyePl9 vuor/vegPuhdVFxfV3EUD+/e//73O7bhfu6ZRfVT/S5UtmRWfXw/9S9pytun1+/L11n+vh09q/A9 QXEU3/e34D3B54niL0rpnOecLnZ+rLQ6Q36qnVeVlNuMaWFV2AuqqviPHj26y87bd6UUg62Rft1o 7OdtF183WF3379+/y5q2y5PUP0iCyp1uxBqhCDopDX/+85+77FSQoLe7WSlvjcZ75xUCn6duaIqj P/vZ3UdzR69Yffe7383zD17oB7Fs2bIu+9neKRvBMF+WXfMQ9M6dF2PlI/qba/AmrnKjlAKfRg8B 1Uk367AL/4i9nHrohZ1/CEgGOa/464EXdv4hqTYNO/8w9GH+IeKvfXx98ZHcXhHUUQ8q/7XAx9NR 8VSmd74eQT+Fqb6+Hv6h6eP6eqkc5Rdm4FlptEyyFXOlKP76zahMvbgGnfqkr7/81X8Vz06PC0Zz 5/qipLBXX33VXfu+opeYNE78xdeX5+sb5qO8xEajij5uMH/J7NMWi+fT+f7iFRbvr6P6uurly/L1 Uj8KO6/4B/3D8queyi/cN/Qb9L+VYPt62YJKjvIP5uPrGyw37fny5cu7NAr+d3/3d0WTqO+Ju3e+ XPkF+6uUv6jfpdL5NvFpPc+o+0MUJ/kFv5gpz3A8sQn2JcWRC7eF/JLK9/cGpZMLK/6l3Pd8fV1G gX9iF8VK8ks2laG0vh/4+4bPwtcpeE/2Yb4/+bAkeX0/V5ly6u/iGmxXF7DrX/g+5OXzL1XB+obb xzP3XH2+Pp5PW047ovh7msWPnnPxmIUx0uoMhSkLB6Ki4sT5VSJzvdLCqrA1qzrH32Zv7x3pnFXa 8yL6xb1WgXFz/oOBfm7+m2++GfQuOLc3cTNx4kSzadMmI1vTjz/+eF6cjRs35l1HXWgx8rHHHpsX 5MtfuXJlnn/4QnP49ffyyy+bX/ziF+6oOJ7L2rVrw0nKug7Pe9WcTjkx9fM3nUfgn+38gavk03D+ im2VIZfI/njzEnv/oKfmTdsHlrEKSNDbnSu+5v1KHoVrLrHmmmr+tBZ9yylM81/tgz9nOURtq8Vn jz32mKujwsOyuMSBf1b5DlztPPXyxqVVvnL2U3oeS8071zx/OwKZW7OwM8fK///gBz9wZltlDUt9 XL8BLfRUewZ/J1r7ojD1Y9/mvnTF13oZ++Usb13ApEmTfJTEo9pCf2Kv9tMaGa130XXYqX9oPrDW rliFxc0dV1q5oLxp46nPKr2d2uDmJYuzd36hodol2J6+HX28tEdfn2BePq3aVv3W9wHvr2M4vq9v ME4551rLpHrbr5FFk+v3IXOa+q3436jO1ZetMpdLrzqKT9S9wI44u/bVGp1DDjkklyZcv1xAGSdi oz/Job7k+6pnH5Wlr08wzDOOS+fzLfe+5+8hVmkOFuvOda/Rn5zvgzoP9zsvg/pOFG+l8f3J33N8 vRTmnfh786jy82nC9yEfP+4+VO929PJxhAAEGpdAVRX/gw46yN3kiynowiEFRU4LCOW84u8uQv+U r5xPEwrOu5RCohuondNv7Jxf92dHdPLiJF2EFyQnxQ2HrVixwvzLv/yLsXN2jf1y4RaxSWHVXy2d f6Bo4ZaU6CinRbJyelBpb4Cgk9IQVByCYeFz/0AK+wevJY8UqCTnH+Z6UNnRKye3V/ylzMgFlQHl +eEPf9jJrzCZia0l1ziW/iVOMlTLScFQeXoh+sd//EeXrV5gtdhU+2Cce+65zk/KmpT/cPspME6u AQMGuLTF/qldv/CFL+T42tFz07t378iXK/uVzGUnmaWI6k9tofb66le/mlu8XSxeUAFSf/CKVlDW uHqFFbBgmqRz3+/i4sT1qTj/uHzS+tsvlO4eFR5siEovvlGKv+LqBVpOv285tWcSz7DiH2wLl0EF /8J9yf9W/X0qKuskvnFt5vOL+62qHH/fiyrTp48KK9VPzx39JTnfNlFx4uofV7e430Ut29Gbma4m tygW+EEAArUl0Kua2fuRcY22F3NPPfWUi5JG8befw13cwYMHJ2b7jW98w1mV+dznPmf0sJAibudP 5h6GiYl3Bdq502miRcbRQ/mHP/yh+du//Vs3cvnWW285y0KSqzuclHftaxD+s9MvHAfJoAeDlDP9 aZRRx6gRrzh5ww+WchWwYD5SaKQs+Ae8Xl70MhBU/MXWfpp2Co6+vNjP5u5afmGX9IANx4271kh2 kKP9bO+uxVJ/1Xb6uiErSfPmzXO20mXNRy+wssrjnV5g7SLjPLm8jF6uckf89FIllrIGojztehR3 bac2+OLzjlLq7VQAo9+xXUPjXsTsNAP3chaMmDae+oPK9ZyL1StOUQqWHXUe7HdR4d3tpxF/fa3R i14xJ9n1W/WWcjQSrd+KnfaUewn29VM8zzB49P3ELgYvVlzZ4XqBDPYl/1uN60vFCip2j0lz34sq o5zfSpws+g0EOftz/Uai7lFR8kT5he9DPl/fjlFpquUXvieoHvortx2rJRf5QAAClRGoquL/gQ98 wEnz85//PFEqTSPQjVKb1cj0p1zSiL9s9ssVG4335Uqh1SYzfqqEpoekdd6UYNr4Pp6dk+lMgGpj FJmW82XruGbNGh+tJkf/MNJITLDc8LkKl2IgZUx/2kVZx/AD0CvgQWH9KI9XLHyYFPawk9Ie99k7 Ku/gSL/ClWdQ6Vf+XpnXQ16fuX3dNJUgznmZg+FR5QfDvUIpGXwZUcdgmqTz8Ncv/zUjLo0UQJn3 034X2uNC08Z+//vfu+jq//rqFSWP94vLN8lfnKSgSFnUC5bPS8ekEVOFayqCNuiTQiAFVEqezK0G XVw836bqL2qXYLnh82B+1TiP6wfqt5KnO5wGNPTilGa038ujkX21l9jJTKucH+3Xuf996qUgzDB4 rbi1cuoL+uJXSl+Kuo94+fxv0l/7Yyn3PZ8mfFRbR/VxMVZfCPeTsJyet/II8g2fq9zwfTYoi/8t eD9f52rdh3y+aY/l3hPS5k88CECgfgRag/MXo8QoFh5Mo5GrCy+80CktX/va15wt/2C4zqUU2IVs zvu6664zst+vMnSjkZONaN3s/E1dfv7rgOYUe3n8i4K/VrylS5fq4Ebbg/6aby+n0Xzv7xX8zZs3 Oz//6VTz8H0cl8j+C8f1/sGjXdjrLmUPPJxe9ZSzi5YLwlyA/RdO4/2DR8kqJ3mC8cVFzi5ALPjc rE/62p/gM5/5TN6cXpfA/gvm4+sp5VTpglOkvPKpTdeCadQOwWvlqykqmreuFzFrmcIX5eIpb03B ksLo00mR10i2Roy1PkNOG7z5cF1rpMu7oP+//uu/Ou+gHJ6TeGj0MVgP/zXqPe95j8vf19n3A82B 1joPPfS1IVTwZVPlagRe02CC9fJyBY/ae0IPc9mW10uMl1mb28l5eRX+wAMPmN13373AnrdeirVO RUqF0tvFvW6/BL1Y6gtB0Gl/AmsZxu01oHUmnoGvVzBu+Ny/mHqZfLj6gF4M5Xw+8hMD7ccRZqA9 BfxotNgVi+f7sV5wVMcbbrjB/NVf/VWOlcqVn5Qo9V85Xy+tZ1AfinLBdgu3r9KofaP6uB84kDy+ vcREzl+HyysWHo4fvLYLSN09QVMZ4/IPxte5n+alfqS20G9JU3qC6dVP7r33XvdiEB7ZD/ZfpfE8 fVuEywv3CR8eLE9+4XgakQ7G0bnvS7pX+jBfvr526QUy6OSn+um35OMr3PfFUu97wTx8OWprPR/0 XAqueRAn3cO0n4v6uW/nMKejjjrKZaV7l150gk7to692ejFT3n4fGNUrHFd+cr5uSfchxQu2o669 fME6Bs+D7eOZh+sSzCfunqA8fTt6WZXO56nzYLm6LsWRNj0tWMEqjkDRvmEV3lhnlfHYsLgAu2mV syluBeqSTfIvfvGLzva0rCHIBrms9ijMTn/Jy8IqOM7fPsScDX47t9GFWyXHWe+RWcOg+/jHP+78 7WZZXbKDLiebycrbTldw5kRlPtPedLvsBldde+21V5e98bq4ViHrsqNSLq69ibm09kHlrocMGeKu g/9k4UH5+rjBMH9uN1Tqsg9wF+/GG2903rLSYl+Gun7yk584f+VhFRmfJHe0o0q586QTO9rt8pHs 3vk28mFWsemySo2zRqGjrq3i22VHdH2S3NGn9R6eiR0Fc+nESZYo7OZBrlw7iuejOksXqo8dJc75 +ROVpTKtQt+ldlQeykuyKI3djM1HzR3VPxRmR9AiLVl4Cx/a/0H5qW7qK/KXvHaEzLWprGF4FpJB Zfr2lk38sMy+zkrjnX0Iu3hBlnZ01ZWn9GELLz5d8Ki2V1z7FcxZQJK1Dfswd78J+dvRv1x0qzy4 vizTezLdKctQOrcKb5dVerrs1CYX1y7qdfWRv/qiOEt+nStP2f/3zjNI6rM+ro5iqDzU1spT/VT1 9/moXcRdzret8paf5FA7qw0UZpX4VPG8pR6l93nal+Rcf1H+qqssnnjn5dEx7LT3gOpgvyC5Nlf+ qov8gvHVFvILtq/uGeqvkkPyeKf+rbhRTv4KD/+OouJG+VnlzXGXNbBSnPq82kPlB9n4PNQmnqfa RfXRb8CbMRULL7POlY84hZ2vX9BffuIbdOF4uk/Iz/clyRDuS5Ip+FtV/5N8/p4j2/rKQ3X1LmzV R/5e/mBbRt33fH19Xv4oOYKsVL7/Pfn7ndL6cqI4qQ0kq+5HXn4vg31xcfx9eb4/+boqns49M5Xj nTffG6yb8lc5Ki94H/L5evmC9VVchXundPLTPUj5iYGcj+fThu8JUe3o7wmeD1Z9HMpU/zznVJFD kdLqDKFk7rKScpsxLawKe0H0E21XvHIbWUq0bFNrUxzdTPTw1p8erDK5F7Zzr+LsDq8urp2f36WH v5QkbbqldFKepQwFnW6YujEpXPHk7KhwbiMg+cu8qPKTkylNbeolf93sdIOUbF4x8oq/wsMujeIv VpLRbmfvylA+2ujG38jtzr9ddhqQCwvnn7Zj+purv7krn2AbKVwPMZXt//RAkd3pKBdMq3DPRPno Yebz0FEPjmA+SusfFFF5K67SBPOQbLJJHS5X6aUEKD/9STELO5nGU34K93l6pUfxfb1VB89JCnxU PZSXd8E6ez8dldb3L1+eruWf1tmvFnnyqh/bOfzOL6j4S/GTMqX+4svSUS8NerENOruTdZddQ5IX Vy+cvh/7uJ5B2N+Hh49qr2B9xVMvY3JesZFMcuInc5pBWXWu9lE+vn2LxXOZ7foX1V/0IqF6BJ2v V9hfcbThkerg+4jaNq591Q99n/H18PIHy/N9Lujnz1WOwn19vX/aox2977LzqNNGz8XzipvK94pX LnDXSRRPsdELpZyX2fMUp7Dz9Qv6y6+Y4q+ydd/xXIPt6F/OFKYyffn6XYmlT6Nygkq/ZIhS/OWv PMJtGb7v+foqfthJXrHxZeuo/u3vE0rr5YzipPyiZFB9NGAQdMpT/qqfL0/X/hmjfLxTuWnvQz5P /zIdrG9UO/r4ksGX6eP5tGEuase4e4LyUHoUf996xY+ec/GYhTHS6gyFKd/57UeFFfOrROZ6pYVV YavWRPFXMYItZVqNrR0ptUmJrvUX53yY0uhcO+Haz6WxabSJkZ0G5PL2eSqtypZ/cJMjhYfL9+X5 tLpphv18WJy/Dw92ar0A2OlKXfZTqg92x3D5PrCUjhmWI1iu8lO4bth6kOghE47vy9QxnFYPNd28 /YNAaZWPb7twWoUn5a8wpVUeksnHDZfr81W4j+P9gkeF2Tn9Lr9wvHDaYLjOJYPvk8E8dR6MGwyT v5c/Lm0wftS5vgTZ6Txdstfuy/HHcHxfnvaRsFPOXHASK/Ux2e2Py2/+rpG8cDlx1758tZVXIHxc hYXLUf8S13AfCcscF8/n7Y/KX5zD+flwfwzL4f1VrsIkv8r0Li6+j6vytD9EVDz5Rfkrbx8Wrq8v N+moF0D93uI29UtKqzCVHW6jcBrF8f1XR117F5Q56O/DdZR/OEzX4ftVXDxfdjAP30ZBP3+uo+8r 3i8oj08b9PPnip903wvW16cJHpU+Sl7F8WmjZArn4WVQXP2FWSm+/H1Zqq+uvb872fUvWG5U/GBc 5eHzkb9Pq/NwmPdTnvrzzscLp1Uc1SuYv88j6KfzYFqfb9pjFKu0aSsptxnTwiptz9ipi6aPnR+z GftGGplbraJXM2dHE9z8ajtNJ1UZiu+dzvfbbz9/GXmUvW8/zzMYwY7eRC7QC+av+FHXYT+fb5y/ Dw8evfnRoJ/OS8kjnNZfF8tD4fbTsI9e0VF52c/KsXmkkcV+uTH6S+PS5GdH9pwFmXB+4bTBa52r Hpr3FvT3eUT5KUz+Xv64tD6PuOOYMWNypl19nDTl+bhxR+VhRzXjgp1/XDlxiRTft1V4jmBUXlqb kdQ/fDlp46kMO6pYNM8oWXxZCgv3/7j4wbh+cabPxx/j0io8KcynjztqrUx4vUxc3Ch/lV2sfIX7 /huVh/eLyyfKvxS/uLLDefhrHYv1FR/Xy+6P8g+3uw9Lc1T6OHl9+riyg+FpZIgrKy7/uPi+XB3j 0saF+TyL5REVz6cJlxm+9vE4QgACjUWgqlZ9GqtqSAMBCEAAAhCAAAQgAAEIeAIo/p4ERwhAAAIQ gAAEIAABCGSYQE2n+mSYWyarJhOqdr5zbrpHJitJpSAAAQhAAAIQgEAPJYDi30MbPqraaeZXR6XD DwIQgAAEIAABCECg8Qkw1afx2wgJIQABCEAAAhCAAAQgUDEBFP+KEZIBBCAAAQhAAAIQgAAEGp8A in/jtxESQgACEIAABCAAAQhAoGICKP4VIyQDCEAAAhCAAAQgAAEIND4BFP/GbyMkhAAEIAABCEAA AhCAQMUEUPwrRkgGEIAABCAAAQhAAAIQaHwCLR0dHV21ENPma2QeElecAKyKM/IxYOVJFD/Cqjgj HwNWnkTxI6yKM/IxYOVJFD/CqjgjHwNWnkTxI6wKGbW2tbUV+u7y6ezsNEnhsQltgGCXm7aScpsx LaySelJ+GKzyeSRdwSqJTn4YrPJ5JF3BKolOfhis8nkkXcEqiU5+GKzyeSRdwaqQDlN9CpngAwEI QAACEIAABCAAgcwRQPHPXJNSIQhAAAIQgAAEIAABCBQSQPEvZIIPBCAAAQhAAAIQgAAEMkegNXM1 okIQgAAEIFAxge3bt5vNmzcbHeVaW1tNv379Ks6XDCAAAQhAoH4EUPzrx56SIQABCDQUgY0bN5pF ixaZpUuXGhlK0PW2bducjH369DEDBw50LwItLS1mjz32cC8DDVUBhIEABCAAgUQCKP6JeAiEAAQg kG0CUuxXr15tXnnlFfPyyy/nFP9169aZHTt2mK6uLvfXq1cvo79BgwaZl156yYwbN85MmjTJjB8/ 3gwZMsSFZZsUtYMABCDQ/ARQ/Ju/DakBBCAAgbIILF++3MybN8+88MILZu7cuU7pL5bRmjVrzNtv v21mz55t9ttvPzN58mT3N3HiRDN48OBiyQmHAAQgAIE6EkDxryN8ioYABCBQDwIaydcI/yOPPGLm zJnjFPktW7aUJMrWrVvdyP/ChQvdS8ORRx5ppkyZYsaMGVNSPkSGAAQgAIHuI4Di332sKQkCEIBA 3Qloao+m9DzwwAPmxRdfNBs2bChbJk0DUnpN/dFXgBUrVphp06a5+f9aB4CDAAQgAIHGIoDi31jt gTQQgAAEakZAVnqeffZZc8899zilX4p7NZzy0Q6ZM2fONPoScMYZZ7hpQCj/1aBLHhCAAASqRwA7 /tVjSU4QgAAEGpaApvf85S9/Mb/5zW+qqvQHK7xp0yYza9Ysc9dddxlNAcJBAAIQgEBjEUDxb6z2 QBoIQAACNSHw5ptvupH+V1991VnpqUkhNlON+D/11FPmvvvucyZBa1UO+UIAAhCAQOkEUPxLZ0YK CEAAAk1FQDb5f/vb37qRfr8hVy0roClFf/zjH93iYb8PQC3LI28IQAACEEhHoGXBggXVmeSZrjxi QQACEIBANxKQoq/pN/fff7/RVJzudCNHjjTnn3++2X///buzWMqCAAQgAIEYAq3ahCXOaZSora0t LjjRX/M7k/JOSlxJuc2YFlZJvSE/DFb5PJKuYJVEJz8sy6xee+018/TTT3e70i/CK1eudGUfd9xx ZujQoW7qT7nPFO7t+X026QpWSXTyw2CVzyPpClZJdPLDGpkVU33y24orCEAAApkhINv8mnKzZMmS utRJ1n60OZj+qmVBqC4VoVAIQAACGSGA4p+RhqQaEIAABMIEVq9e7XbY1YLbejnZ+dfLx8aNG+sl AuVCAAIQgMAuAij+dAUIQAACGSUg852LFy+ua+1kRnTu3Ll1++pQ18pTOAQgAIEGI4Di32ANgjgQ gAAEqkFAo/zaUKsRrOqsWrXKPPPMM9WoFnlAAAIQgEAFBFD8K4BHUghAAAKNSkAj/VrY2whO8/sf e+yxhngJaQQeyAABCECgXgRQ/OtFnnIhAAEI1JDAs88+a2RPv1HcokWLzNKlSxtFHOSAAAQg0CMJ oPj3yGan0hCAQJYJaF69LOk0ktN+AvPmzWskkZAFAhCAQI8jgOLf45qcCkMAAlknsH79+oYcXW+U qUdZb3/qBwEIQCCOAIp/HBn8IQABCDQpgY6Ojrps2FUMl/YT0NcIHAQgAAEI1IcAin99uFMqBCAA gZoRWLt2ramn7f64ismm/6ZNm+KC8YcABCAAgRoTQPGvMWCyhwAEINDdBLRZlubUN5qTTGzk1Wit gjwQgEBPIoDi35Nam7pCAAI9gsCWLVuMTGg2mpNMkg0HAQhAAAL1IYDiXx/ulAoBCECgpgQaVfFn jn9Nm53MIQABCCQSaLGLwGoyLKTFZe3t7YmFE7iTAKzS9wRYwSo9gfQxs9avZMP/Rz/6kdGc+kZy I0eONF/84hfN6NGjG0msmsmStX5VM1A2Y1ilpwsrWKUnUBizta2trdB3l09nZ6dJCo9NaAPUMctN W0m5zZgWVkk9KT8MVvk8kq5glUQnPyxrrIYNG2ZaW1vzK9kAV7169TKjRo0q69nAvT19A8IKVnEE mrFvVCJz1u7tce3q/dOwYqqPp8URAhCAQEYIDBo0qCEV/759+5qBAwdmhDLVgAAEINB8BFD8m6/N kBgCEIBAIgF9be3Tp09inHoEavpnI8pVDxaUCQEIQKAeBFD860GdMiEAAQjUkMDQoUPNkCFDalhC eVnvsccepqWlpbzEpIIABCAAgYoJoPhXjJAMIAABCDQWAU2pGTt2bGMJZaXZd999G04mBIIABCDQ kwig+Pek1qauEIBAjyFw8MEHN1RdNcUHxb+hmgRhIACBHkgAxb8HNjpVhgAEsk/goIMOMhr5bxS3 1157mREjRjSKOMgBAQhAoEcSQPHvkc1OpSEAgawTkM38/fbbr2GqedRRRxmZ88RBAAIQgED9CHAX rh97SoYABCBQMwJaRDtlypSGULZlwvPQQw+tWV3JGAIQgAAE0hFA8U/HiVgQgAAEmo6ApvsMHz68 7nJrobEs+uAgAAEIQKC+BFD868uf0iEAAQjUjIDm1B9wwAF1NaHZu3dvM3nyZDN48OCa1ZOMIQAB CEAgHQEU/3SciAUBCECg6Qj079/fHH744UbHejkp/IcddlhDLTSuFwvKhQAEIFBvAij+9W4ByocA BCBQIwJaTHvIIYeYPffcs0YlFM920qRJmPEsjokYEIAABLqFAIp/t2CmEAhAAAL1ISDrPlOnTjWy o9/dbtCgQeY973mP0REHAQhAAAL1J9DS0dHRVQsxbL6mvb29FllnLk9YpW9SWMEqPYH0MbPUr7Zt 22a2bNliZEnHuzVr1pgf/ehHZs6cOd6r5kdZFTrxxBPNxz/+cdOvXz9X3vbt283atWvN0KFDG8La UK0hZKlfwarWBNLnT7+CVXoChTFb29raCn13+XR2dpqk8NiENkAds9y0lZTbjGlhldST8sNglc8j 6QpWSXTyw7LAauvWrWbp0qXmz3/+sxt0efe73220sFZO9+IPfOADZvHixWb16tX5la/R1ZgxY8z7 3/9+M3r06FwJr732mnn44Yfd1B+tPdDgUFrb/tzbcxiLnsCqKKJcBFjlUBQ9gVVRRLkIjcyqNScl JxCAAAQg0JQEli9fbl544QXz7LPPmtmzZ5tx48a5uf2a5uOdTHsed9xx5oEHHjD6KlBLpx2DNdo/ fvz4XDFdXV3upeT3v/+928F34cKF5ogjjnBWh+q5+DgnICcQgAAEegAB5vj3gEamihCAQDYJSJnW KPpdd91l7rzzTvPYY4+ZDRs2mPnz55snn3wyr9IDBgwwp512WrcstJUJUX1x8FN8JIgU/VmzZrmX Dn2Z0AvAr3/9a3fU6BgOAhCAAARqTwDFv/aMKQECEIBA1Qloao/m7N9+++3moYceMosWLTKaQy+3 adMmp1C/9dZbuXI1514j8GeffbYbcc8FVPlkt912M+ecc06eJaH169eb3/3ud2bJkiW50jZv3mxe fPFF99Jy9913m7ffftvoRQYHAQhAAAK1I4DiXzu25AwBCECgJgS0ePeZZ55xI+aa2iNFP+zeeOMN c99995l169blgjTn/5hjjnGWdoLTgHIRKjzRfH7N6z/00ENzc/f1MqIpSH/6058KFPsdO3a4NQd6 Kbjnnnvcl4oKRSA5BCAAAQgkEEDxT4BDEAQgAIFGI6CR/kcffdTce++9bl6/H+WPklNTf55++unc lwDFaW1tNVOmTDFnnHGGs64Tla4cP1nqUZ6a4hNcsKsFxeEXkHD+enHRNCBNV3r11VfDwVxDAAIQ gECVCKD4Vwkk2UAAAhCoNQEp/U899ZSbHqM580lKv2TR3Pn777/fvPnmm3miya6+5vtrdH748OFG 04DKdUo7bNgwM23aNHPqqaeaIUOG5LKStSRN45k3b57R6H6S03QgrUuQ8q9pS0z7SaJFGAQgAIHy CKD4l8eNVBCAAAS6nYAs92ghb1iRjxNEyvbLL7/sptGE5/vLlOaZZ55pPvjBD5r999/ffQmIyyfO X18PJk6c6PJQXkETzitXrnQvHfo6kdaKkH+x0dcMpcdBAAIQgEB1CWDOs7o8yQ0CEIBATQhoFFyj 55oKU8pouL4KPP74487CjpR82df3bvDgweb00083u+++u/uSoK8JaRVujfIfddRR5uijjzYHH3xw 3oZhWlcgs6H62qD1CKU4xX/iiSfcbr8XXHBBXXYcLkVe4kIAAhBoJgIo/s3UWsgKAQj0SAKasjN9 +nRnxafY9J4oQJpD/8gjj7hRfW3k1adPn1w0mfmUPX1Z/Nl3333N3Llz3cuFylRZfoqOpvRohF8m OmWuU8q+0o0YMSL3tUAvJNolWKY6pfiXa6ZTeSj93nvv7dYj+I3IckJzAgEIQAACZRFA8S8LG4kg AAEIdA8BTZORRRyN2qedMhMlmebQz5gxwwUdeeSRRht6SZGX03HUqFHO2s8hhxziFH+Z3pQCLrOb Uv6l8GsBrxbuHn/88WaPPfbI7QysPBRHXyUkp0b6lbYSp/Sy9LPnnnuaCRMmVJIVaSEAAQhAYBcB FH+6AgQgAIEGJiAF/MEHH3Qbc1Uq5tq1a11espmvFwFN1QlusiWlXtN+9Ldx40YXR/PupdRrN96B Awca7RKskfig0wuJrAdJ6dcxaEI0GK/Uc71IaI8CvWTgIAABCECgcgIo/pUzJAcIQAACNSGgqTZS +rUTbynz+pOE0c6+squvufx6AZDyr0239AIQtO6jKUD6C7sVK1bkvPQ1QC8CUva1iFd7B5Q6pz+X WcSJXjpk6UfrCBj1jwCEFwQgAIESCaD4lwiM6BCAAAS6i4B2tp05c2ZFU3yiZNUIvV4mli5dal5/ /XVz4IEHujn+mu4jaz/BrwDh9Br9X716tVP4FyxY4NYEaDMxfU2ohVu1apXbB+Ciiy7KsxpUi7LI EwIQgEDWCbRYO8s12SNd9pv1AMEVJwCr4ox8DFh5EsWPsCrOyMdoRFaaanPLLbe4+f1ezlocNb1H 92pZ+9HIvxbr6k/z+TW1xy8E1ui+lHuZEtU0IZkH1RcDfTkoZ8FxKXWRDB/72MfMySefXEqyusdt xH5VdygxAsAqBkyEN6wioMR4waoQTGvQ7nI4WBYZksLD8YPXgl1u2krKbca0sAr2nORzWCXzCYbC Kkgj+bwRWWnajGzw19ppBF+j6hrF1+i/lGwp/bp/y9ynrjXNSIq/FtwuW7bMaAqOX/Rba/mUv8rT LsTacVgbjpXq6vVcaMR+VYwdrIoReiccVu+wKHYGq2KE3gmvNSum+rzDmjMIQAACDUFA8+Rnz55d sWWcUirjlXsp9FqcG9zwq5R8ahV38eLFblrRiSeemLcWoVblkS8EIACBLBJg594stip1ggAEmpqA Rnz+8pe/1HwKTTNB0tQnrSXQngQ4CEAAAhAojwCKf3ncSAUBCECgZgReeeWVhhtxr1llU2asLxLa XEzTknAQgAAEIFAeART/8riRCgIQgEBNCGjO/axZs9y89poU0MSZynToCy+80MQ1QHQIQAAC9SWA 4l9f/pQOAQhAII+A7OTPmTMnz4+LnQT8S5GOOAhAAAIQKJ0Ain/pzEgBAQhAoGYEpPTLXCYumoCm QWk3YxwEIAABCJROAMW/dGakgAAEIFATArKHrwWsuHgCsngEo3g+hEAAAhBIIoDin0SHMAhAAALd SEB28hcuXNiNJTZnUc899xwWj5qz6ZAaAhCoMwEU/zo3AMVDAAIQ8ASWLl3qbOj7a47RBGTTXyZP cRCAAAQgUBoBFP/SeBEbAhCAQM0IvP3229ipT0F3w4YNzPNPwYkoEIAABMIEUPzDRLiGAAQgUAcC slMvc5Waw45LJqBNvPR1BAcBCEAAAqURQPEvjRexIQABCNSEwNatW83KlSsNpiqL4xUrvSTpZQkH AQhAAALpCaD4p2dFTAhAAAI1IyBldvXq1TXLP0sZ6+VIO/iKGQ4CEIAABNITaOno6KjJkInN17S3 t6eXpAfHhFX6xocVrNITSB+zEfqVFqt+5zvfMfPnz08veA+OecQRR5hPfvKTZuDAgQ1LoRH6VcPC CQkGqxCQhEtYJcAJBcEqBMRetra1tRX67vLRgygpPDahDRDsctNWUm4zpoVVUk/KD4NVPo+kK1gl 0ckPawRWGr3W3HVcOgJa4DtgwIBUz5l6PRcaoV+lo/lOLFi9w6LYGayKEXonHFbvsCh2VmtWTPUp 1gKEQwACEOgGAtu2bWPH3hI4r1271ogZDgIQgAAE0hNA8U/PipgQgAAEakZAu/Yy4p8er0b8UfzT 8yImBCAAARFA8acfQAACEGgAAlL8WayaviH0koQFpPS8iAkBCEBABFD86QcQgAAEGoCARq8xT5m+ IbTfgV6WcBCAAAQgkJ4Ain96VsSEAAQgUDMCKLGlodVoP8xKY0ZsCEAAAij+9AEIQAACEGhKAkz1 acpmQ2gIQKCOBFD86wifoiEAAQh4An369PGnHFMS6NWLR1hKVESDAAQg4Ahw16QjQAACEGgAAq2t rUZ/uHQEpPT37t07XWRiQQACEICAI4DiT0eAAAQg0AAEpPQPGTKkASRpDhEGDx5s+ErSHG2FlBCA QOMQQPFvnLZAEghAoAcTGDhwoJkwYYJpaWnpwRTSVV2MxErMcBCAAAQgkJ4Ain96VsSEAAQgUDMC UmJPPfVUs//++6P8J1CW0j9x4kRz2mmnofgncCIIAhCAQBQBJpRGUcEPAhCAQDcT0FSfww8/3PTr 18/MmTPHLF261Kxbt87IXn2U9RqZsix3jnslaSVP3759y6JTbrmazy+Ff9iwYWbMmDHmoIMOMpMn T2ZNRFmtQCIIQKAnE0Dx78mtT90hAIGGItC/f39zxBFHOKV22bJliYr/+vXrzaBBg8qSv5K0kmv0 6NHdWq4Uf71w7Lbbbq5svRzhIAABCECgdAItCxYs6Co9GSkgAAEIQAACEIAABCAAgWYi0GK3iI9V /Ds7O01bW1tZ9Vm4cKEZN25cWWkrKbcZ08IqfTeBFaziCFTy26dfxVEt9IdVIZM4H1jFkSn0h1Uh kzgfWMWRKfSHVSETFvcWMsEHAhCAAAQgAAEIQAACmSOA4p+5JqVCEIAABCAAAQhAAAIQKCSA4l/I BB8IQAACEIAABCAAAQhkjgCKf+aalApBAAIQgAAEIAABCECgkACKfyETfCAAAQhAAAIQgAAEIJA5 Aij+mWtSKgQBCEAAAhCAAAQgAIFCAij+hUzwgQAEIAABCEAAAhCAQOYIoPhnrkmpEAQgAAEIQAAC EIAABAoJoPgXMsEHAhCAAAQgAAEIQAACmSOA4p+5JqVCEIAABCAAAQhAAAIQKCSA4l/IBB8IQAAC EIAABCAAAQhkjgCKf+aalApBAAIQgAAEIAABCECgkACKfyETfCAAAQhAAAIQgAAEIJA5Ai0dHR1d taiVzde0t7fXIuvM5Qmr9E0KK1ilJ5A+Jv0KVukJpI9Jv4JVegLpY9KvYJWeQGHM1ra2tkLfXT6d nZ0mKTw2oQ1Qxyw3bSXlNmNaWCX1pPwwWOXzSLqCVRKd/DBY5fNIuoJVEp38MFjl80i6glUSnfww WOXzSLqCVSEdpvoUMsEHAhCAAAQgAAEIQAACmSPQmrkaUSEIQAACPYTAtddeG1vTk08+2UydOjU2 PCqgq6vLtLa2mk2bNpk+ffpERcEPAhCAAASamAAj/k3ceIgOAQj0bAIzZswwUtaj/sols2PHDrNl y5Zyk5MOAhCAAAQamAAj/g3cOIgGAQhAoBgBjeonjezPnDnTaPT/ueeeM3fddZf56le/mpflAw88 YF544QUzbNgw84lPfMKFSfEfNGhQXjy9ZMjts88+7qh/3s+X/8QTT5gFCxaYl19+2Vx44YVm0qRJ ubgqZ+7cuaZfv35m3333NaeffroLC+ahLxhXX311Lg0nEIAABCBQXQKM+FeXJ7lBAAIQaCgCp5xy ilP2v/CFL5innnrK9O7d28yZM8fJeO+995ozzjjDzJ4927z++uvmox/9qPPfvHlzZB1OPfXUPH8p 7XqxkFP+55xzjrn//vvNq6++aiZPnuxeKBQmhf69732vefvtt82SJUtcmcFpSjofOXKkkTw4CEAA AhCoHQFG/GvHlpwhAAEI1JyAFG+vfAcL8yPnmga02267mQcffNAFX3rppebnP/+5OfHEE82vfvUr 8/Wvf91ceeWVLuy73/2uue2222Kn+iivOPf4448bpf/IRz7iokyYMMEsWrTIHHTQQa6cW2+91Sn8 svYmeRTXy6gE119/vTn//PPjsscfAhCAAASqQADFvwoQyQICEIBAvQgkKeNepqBCPW7cuNxLwKxZ s8xZZ53lo5l3v/vd7rycOf5f+9rX3Kj+woUL3RSfL33pS2bgwIFu9H/lypXmxRdfNM8++6yb6qNC 9FLw5ptvuvI0Rejhhx925/yDAAQgAIHaEUDxrx1bcoYABCBQcwLF5vhLgPB8fS+Upt0MHTrUX5qx Y8e683IU/9NOO829UNxxxx3mhz/8odm2bZtbAyClXwuGgwuQVcjnP/95p/zrPG5qkcJwEIAABCBQ PQIo/tVjSU4QgAAEGpKANrHR6HvYHXbYYeaNN97IefspQ0mK/7p163LxNb1HU4a8C76EaIrPNddc Y7797W+bZcuWuSk/mucf3tjRL+71eXCEAAQgAIHaEUDxrx1bcoYABCDQLQTilGdvbUc7mu+xxx4F spx99tlG1namTJniRuR/8YtfuDhRir/yOu6449wCXCn1WpD7rne9K5fnSSedZD7zmc+YadOmOcs+ AwYMMEcffbQZPny4m7v/k5/8xFkOmjhxorn55pvNH//4R3P77bfn0nMCAQhAAAK1J4DiX3vGlAAB CECgZgQ0qh7l/Oi7THlK8Y9yX/ziF91iXCnwZ555ptH10qVLYxf3XnHFFW7xr0x6XnzxxXlZ/vKX vzRXXXWV+cpXvuI2AZMFoM997nMuzg033GC+/OUvm8suu8xs3LjRHHHEEebGG2/MTUGSjDgIQAAC EKg9ART/2jOmBAhAAAI1IZBmQWz4a4BeFDS/Xq6lpcVZ3AkKF44fDJNt/hNOOMFogXDY7b777uaW W24Je7vrESNGOEVfLyDhqT56QUkqMzJDPCEAAQhAoCwCvcpKRSIIQAACEIAABCAAAQhAoKkItNhF X121kFiLydrb22uRdebyhFX6JoUVrNITSB+TfgWr9ATSx6RfwSo9gfQx6VewSk+gMGZr+LNrMErU Z9lgeNK5OmZS3klpKym3GdPCKqk35IfBKp9H0hWskujkh8Eqn0fSFayS6OSHwSqfR9IVrJLo5IfB Kp9H0hWsCukw1aeQCT4QgAAEIAABCEAAAhDIHAEU/8w1KRWCAAQgAAEIQAACEIBAIQEU/0Im+EAA AhCAAAQgAAEIQCBzBFD8M9ekVAgCEIAABCAAAQhAAAKFBFD8C5ngAwEIQAACEIAABCAAgcwRQPHP XJNSIQhAAAIQgAAEIAABCBQSQPEvZIIPBCAAAQhAAAIQgAAEMkcAxT9zTUqFIAABCEAAAhCAAAQg UEgAxb+QCT4QgAAEIAABCEAAAhDIHAEU/8w1KRWCAAQgAAEIQAACEIBAIQEU/0Im+EAAAhCAAAQg AAEIQCBzBFD8M9ekVAgCEIAABCAAAQhAAAKFBFD8C5ngAwEIQAACEIAABCAAgcwRaOno6OiqRa1s vqa9vb0WWWcuT1ilb1JYwSo9gfQx6VewSk8gfUz6FazSE0gfk34Fq/QECmO2trW1Ffru8uns7DRJ 4bEJbYA6ZrlpKym3GdPCKqkn5YfBKp9H0hWskujkh8Eqn0fw6uabb3aXl1xyiTvCymFI9Q9WqTDR r9JjghWsEgmk0YGZ6pOIkEAIQAACPZvALbfcYvSHgwAEIACB5ieA4t/8bUgNIAABCEAAAhCAAAQg UJQAin9RRESAAAQgAAEIQAACEIBA8xNA8W/+NqQGEIAABCAAAQhAAAIQKEoAxb8oIiJAAAIQgAAE ICMjYIYAAEAASURBVAABCECg+Qmg+Dd/G1IDCEAAAhCAAAQgAAEIFCWA4l8UEREgAAEIQAACEIAA BCDQ/ARQ/Ju/DakBBCAAAQhAAAIQgAAEihJA8S+KiAgQgAAEIAABCEAAAhBofgIo/s3fhtQAAhCA AAQgAAEIQAACRQmg+BdFRAQIQAACEIAABCAAAQg0PwEU/+ZvQ2oAAQhAAAIQgAAEIACBogRQ/Isi IgIEIAABCEAAAhCAAASan0BLR0dHVy2qYfM17e3ttcg6c3nCKn2TwgpW6Qmkj0m/imc1bdo0Fzh9 +nR3hFU8q3AIrMJE4q9hFc8mHAKrMJH4a1gVsmlta2sr9N3l09nZaZLCYxPaAMEuN20l5TZjWlgl 9aT8MFjl80i6glUSnfwwWOXzCF61tra6S38/h1WQTvI5rJL5BENhFaSRfA6rZD7BUFgFaew8Z6pP IRN8IAABCEAAAhCAAAQgkDkCKP6Za1IqBAEIQAACEIAABCAAgUICKP6FTPCBAAQgAAEIQAACEIBA 5gig+GeuSakQBCAAAQhAAAIQgAAECgmg+BcywQcCEIAABCAAAQhAAAKZI4Din7kmpUIQgAAEIAAB CEAAAhAoJIDiX8gEHwhAAAIQgAAEIAABCGSOAIp/5pqUCkEAAhCAAAQgAAEIQKCQAIp/IRN8IAAB CEAAAhCAAAQgkDkCKP6Za1IqBAEIQAACEIAABCAAgUICKP6FTPCBAAQgAAEIQAACEIBA5gig+Geu SakQBCAAAQhAAAIQgAAECgmg+BcywQcCEIAABCAAAQhAAAKZI9CyYMGCrszVigpBAAIQgEBVCFx4 4YUun1tvvbUq+ZEJBCAAAQjUj0DruHHjYkvv7Ow0bW1tseFJAQsXLjRJeSelraTcZkwLq6TekB8G q3weSVewSqKTHwarfB7Bq/79+7tLfz+HVZBO8jmskvkEQ2EVpJF8DqtkPsFQWAVp7Dxnqk8hE3wg AAEIQKBCAtdee63RHw4CEIAABBqHAIp/47QFkkAAAhBoegKPP/64OeGEE8wzzzxjurqYSdr0DUoF IACBTBFozVRtqAwEIAABCNSVwFe+8hVzwQUXmI6OjrrKQeEQgAAEIFBIgBH/Qib4QAACEIBAmQS+ 9a1vmSuuuKLM1CSDAAQgAIFaEkDxryVd8oYABCDQwwgceeSRrsYtLS09rOZUFwIQgEDjE0Dxb/w2 QkIIQAACEIAABCAAAQhUTADFv2KEZAABCEAAAlEEGPWPooIfBCAAgfoRQPGvH3tKhgAEIJBpAlj1 yXTzUjkIQKAJCWDVpwkbDZEhAAEINCqBGTNm5Inmr6dOnWoeffRRM3v2bHP11VfnxeECAhCAAAS6 hwCKf/dwphQIQAACPYKA37TLj/bPnDnT1VuKv9zDDz+M4u9I8A8CEIBA9xNA8e9+5pQIAQhAILME HnrooYK6+bn+U6ZMMWeddVZBOB4QgAAEINA9BFD8u4czpUAAAhDoEQS8kh9X2WLhcenwhwAEIACB ygmwuLdyhuQAAQhAAAIQgAAEIACBhifQYrdV76qFlNquvb29vRZZZy5PWKVvUljBKj2B9DHpV/Gs pk2b5gKnT5/ujrCKZxUOgVWYSPw1rOLZhENgFSYSfw2rQjatbW1thb67fDo7O01SeGxCGyDY5aat pNxmTAurpJ6UHwarfB5JV7BKopMfBqt8HsGr1tadM0L9/RxWQTrJ57BK5hMMhVWQRvI5rJL5BENh FaSx85ypPoVM8IEABCAAAQhAAAIQgEDmCKD4Z65JqRAEIAABCEAAAhCAAAQKCaD4FzLBBwIQgAAE IAABCEAAApkjgOKfuSalQhCAAAQgAAEIQAACECgkgOJfyAQfCEAAAhCAAAQgAAEIZI4Ain/mmpQK QQACEIAABCAAAQhAoJAAin8hE3wgAAEIQAACEIAABCCQOQIo/plrUioEAQhAAAIQgAAEIACBQgIo /oVM8IEABCAAAQhAAAIQgEDmCKD4Z65JqRAEIAABCEAAAhCAAAQKCaD4FzLBBwIQgAAEIAABCEAA ApkjgOKfuSalQhCAAAQgAAEIQAACECgkgOJfyAQfCEAAAhCAAAQgAAEIZI5AS0dHR1ctamXzNe3t 7bXIOnN5wip9k8IKVukJpI9Jv4pnNW3aNBc4ffp0d4RVPKtwCKzCROKvYRXPJhwCqzCR+GtYFbJp bWtrK/Td5dPZ2WmSwmMT2gDBLjdtJeU2Y1pYJfWk/DBY5fNIuoJVEp38MFjl8whetba2ukt/P4dV kE7yOayS+QRDYRWkkXwOq2Q+wVBYBWnsPGeqTyETfCAAAQhAAAIQgAAEIJA5Aij+mWtSKgQBCEAA AhCAAAQgAIFCAju/4Rb64wMBCEAAAj2QwIwZM8y1116bq/mCBQuM/k455RTnt2nTJvPpT3/aXHLJ Jbk4nEAAAhCAQHMQQPFvjnZCSghAAALdQmDq1Kk5JT9YoF4IvPvGN77hTzlCAAIVEtiyZYtZunSp WbFihdmwYYPZtm2b6eqKt7uiuPPnzy+r1PXr15tBgwZlJm1LS4vp06ePq9PIkSPN6NGj3XVZFewh iVD8e0hDU00IQAACaQlI+Q8q+sF0xx9/vFE4DgIQqIyAlPuVK1eaJ5980syePdu8+uqrTvnXV7Uk xV/h/fv3L6twvVT4BfulZtCIaXv16uVYSOmfNGmSOeaYY9yfjBHopQBXSADFv5AJPhCAAAR6NIGL L744UfHv0XCoPASqRGDVqlXmtttuM3fccYd57bXXzOrVq92I//bt2xMV/yoVn4lspNzrRWbAgAFm +PDh5pFHHjHnn3++Oe+888q2LJkJMAmVQPFPgEMQBCAAgZ5IQPP3L7300siqa8Qfly0C9957r9E+ DUOGDDHHHnusOffcc7NVwQasjZT7e+65x1x//fVO6d+8eXMDStn4IunLyNatW93fmjVrzJIlS8yy Zcuc0v/hD3+48StQBwmx6lMH6BQJAQhAoNEJjB8/vkBE+aH4F2Bpao8LLrjA/OxnPzOnnnqqGTFi hPnUpz5lUEJr36RvvfWWufHGG828efPgXUXcmgb1/PPPmxtuuMG9AFQx68xkheKfmaakIhCAAASq R+Dqq68uyAxLPgVImtpj7ty55uGHH3Yj/Joa8aUvfckceeSR5nvf+15T16sZhH/ooYfMM888YzTy j6suAa1FeOKJJ8zMmTOrm3FGckPxz0hDUg0IQAAC1SQQpeSffPLJ1SyCvOpMYPLkyW5UNDglQkrT hAkT6ixZ9ou/7777GOmvYTNv3LjR3HXXXTUsoXmzRvFv3rZDcghAAAI1JRCc7qNzrPnUFHfdM3/l lVdMZ2enOeecc+ouS9YFePbZZ7NexbrXT6P+uEICLO4tZIIPBCAAAQhYAlL0b775Zsci6gsAkLJD QCYlr7zySpT+bmrS5cuXx5ak353+opwWswY32AvHacS0kvGaa64Ji5r6+qqrroo1Xyqzw3Gmh7WO AldIAMW/kAk+EIAABCBgCcisp1f8meaT3S5x++23m8suu8z87ne/MwcffHB2K9pANdOUqjgn5T1q jY3ip1H865FW94e4ciV3pYq/7PJHOfGIU/y1MRqukECrPusluWLhpH2HAKzeYVHsDFbFCL0TDqt3 WBQ7g1UxQu+Ep2F1xBFHmLFjx7pEOvdp/PGd3NKfkbaxWGketL7mLFq0yAwePNgJRxt1TxvFlSLL NHFtIEU3ydUrrSxBxcmcJG/asLi801igikubpuwspm2Ne4sSEFU4KTwJWkdHR9lpKym3GdPCKqkn 5YfBKp9H0hWskujkh8Eqn0fwSmYeNb/fPwtgFaSTfN4MrPRF58EHHzQvv/yyq8z69evdC4BGnTWS KssoSSO5QQKVPH+bgVWwrjqvpL7hvILX2pXX/96C/jovpvjXK22/fv1iZQ7XoZzrOB4qt5iLS1ss XSXt28hpmepTrOUJhwAEINCDCegTvhR/XPYIPP3002bHjh15c8Y1BaVPnz5Gir+czH2mVfxdAv5B AAINTQDFv6GbB+EgAAEIpCOgkcBio4E+J8WTwpfGXXTRRS6aj19K2nD+4bQtLS1Gf7j6EJDN/vD8 6OBIpR/1r490lAoBCNSCAIp/LaiSJwQgAIFuILBu3XqzZk2nkc3qbdvTKfISS1vc91kWb1UkSfQN G9abzVu2JkWJDYsqt7V3bzNg4AAzdOhQM3jQoNi0BECgEQloqpTWSOAg0CwEUPybpaWQEwIQgMAu Aho537Bhg9mwcZNT/Ddv3pJ6BL8aEDfacqvlevXqZTRPd5PNs2vUSDu/fIj9ClCt3MkHArUlINOa l156qRlvp8PpBYBpUdXn/eijj5pBMYMCCxcurH6BGc8RxT/jDUz1IACB7BHYvn27Wb26w6yzCzGT zAI2Q801hch9sbBzy/VCM3DgQNO7d+9mEB0ZIZAjsGDBAmeyUmYreQnIYanKyXXXXWdaW6PVVXHH lUYgmmRpeRAbAhCAAAS6iYAUZZnsW7N2rdELQFbmyGsa0GprDW63TbuZAQP6G30JwEGgGQlEvQRo Twy9EOBKJ6ARf1z1CKD4V48lOUEAAhCoOQEp/hvsnP5SFsaWErfaFeiy8iZbHn+nxJ1122A++9nL zRtvvPFOgD3Tl424Ub+8iBEX9UqrFzSZVyzH1UvmepXbrKyKjTjHvQSU0ydIA4FqEEDxrwZF8oAA BCDQjQSkIKd1UvqlfA4fNsz06dsnbbKqxNu8abMbxdcmO5rGk8aVUrc0+REHAo1GoNjLQqPJizzZ IpBJxX/ZsmVmwfz5Zq39FL5jR7qHjZpV1ioGDizPqkQlaZcvX2Zenrdz85RSu1cl5Zaa1uoPbv7t 3nuPNUOGDilVVOJDAAJ1INDWNtTsvttuZqBdHNdLP+JudFLida9YsmSpXYS8JnXJN910U8HoftDM ZOqMdkWsV1otPBw3blyp4rr49ZK5XuU2K6vDDz/cJCnymt6jRb/aD0PmUXEQqDeBTCn+W7ZsMQ8/ 9JB5/rnnzKuvvOp21Stl9GibnS8r03LluErSbrZy9+vbt5xirQm/7pNZOsMgu6X7PuP3MZMPPth8 4IMfMEPb2sqSm0QQgEDtCfS1I/yD7W9WpjLrtWBW5a5bu86st1aIttvpOjgIZJ2AV/aZ15/1lm7O +mVG8dfCsF/eepv52U9/Yua/9vrORW+mxT7s0i8Q06fochfKVZJWLyflLmSrpNxS0+6wfLSY8Kk/ zzZjZs0yq1euNB+/5GLT3t7enL0fqSGQcQK9evU2fVr71E3pF17Ny9efvjZszzhvqtczCUjR158U fY3q6xwHgUYlkBnF/4E/PGBu+P73zZK33zaTDjzQHHvssWbkiBGmVwmKfyWLiypJ22HN8rUPK095 rqTcUtNq1tSazk7zF/tF5cknnzQ3//h/zcAhg81F9mZX7qK7Rv1hIBcEskBAL+pbt211L+z1GvHX YlH9lfL1NQvsqUPPICC7/ZrKU6rr06eP20gvKl14N+VgHA3YJbl6pZ05c6bRngaN5LQ/CK6QQCYU /+XLl5sf/+j/mbcWLzYHTD7QXPGFz5tjjzsubyTa/1jCI/p6GLVYLi29ermpQW2BqSsurCXdlvKV zItsprmN2jRIiv/3v/s985gd9f/lrbea4+xL1kGHHFLYu/CBAATqSkBfQt3uvna90yBrH7+lJf0X 0MoF73ILetesWev2G9BLCA4CWSNQjtIvBnvuuWfs2gAp70kKfBLDZkybVJ9Kwvbaa69Kkmc2basU 1iRXLLwR0s565BHz0otzjaaiXPDRjzqlXwq+ZJfyvn7dOmfzuo/93Nxmp6X4t0BtGqOFwJp3OmrU KLsIbahLowdUh7UnvaZzjRlsR7T1MtC3b/E5+M3AKtxe5ch84OTJ5rJP/rWd8vNn8+aiRea+3/3O 7DV2bDjrxOtyyvUZktaTKH6EVXFGPkazsNL9SfeutE712mzNSuqrYr++3TcCZtV+u9/AZncvlVWf NE4DNKqbFgJHfaFoljYK1hWZgzSSz3sSqxNOOCFW8U+mRGhaAsccc4yL2pP6lSpcrL6twRHuMEwl TgoPxw9eS3EuN22p5WpOv0a2NE/+lFNPzY306yHytp368+ADD5g5z89x8ij8yKOPMnYoyjxiP03N sn960BxmV+afceaZ7i389ddeM7+5806zaOEbZs+99jTvee97zaGHHZY4naVUmevFKlhuJTIfZBf3 7mnfpmU96fXX55fU1pWU2539qlqsKqlvJWlhFWzB5PNmYqVpM1vs/S6t031wk1W8Nchhv22mTVaV eCpbf2mdBmwGDBjgFiOHpw9W8luoV9pm6le+jWDlSRQ/VsJq2rRp5u677zbr7e7buOoT0A7g559/ vsu4u3TRYC0q6Ru1TpuJqT6CpJF9PSiCC02l0P/x8SfcNCBNp5GpzqVvLzGjRo9ypj5/9pOfmtl2 rrpeGrRgVWnPsj/G39xxp/nJ/91i3Nx766dRq912393ssccewXbt0ed6yRph11C89upO60k9GgaV h0CDE5DyvX17egW8wauDeBBoegLHH3+8M/H5hz/8IXauf9NXsk4V0PqJKVOmuL9Svo7WSdxuL7Y7 J3zWrHLbrdIvF/40vHHDRjNnzhz3OU0PvvXr15lnnn7arQV45eVXjEb2pfTLLbbrA555+hmjT9KP PfaYU/rlrxGbF2wey91omXxwnkAva6ZPXPXShYMABCAAAQhAIB2BYXZDvcsvv9xoHwB95cJVh4BY HmZnaHz2s581I0eOrE6mGcslEyP+cW3S2qfVNXxbe5vp7Og0egscvdsYZ9d69BhjxowZY1bYhcGa Mzvcjl6PHbu3+2ogU1wvvvCCmwKkTrSb3fxGtrBxEIAABJqBgL7IhQ0ZNIrcDBY0SksgRz0J6Dc6 1Zr+XL16tbntttvM3LlzzapVq+xGohucFSz9TnDFCeg+p9kemtozfPhwc8ABB5gLLrjAnGqndYsx rpBAphX/QXanynedeKKZ//prZt68eWaIVd5PP+MMM36ffexU1xbz/g98wPnJrOXBhx1qTrI762lr +w+d+2Gr9G8wb731llX6dzenv+8MpvkU9h18IACBBiKw8wHY2z0A+9pFvG6X3u6d0l+chtVl9IVW my16Bad4ImJAIJsENKB49tlnu7WFMpH90ksvGVkplE6S9CW9VFPcQXpaIxRePxMMTzpvxLRS7qW3 yUDLpEmTnCn3o48+2gwZMiSpKj06LNOKvzr3pAMmmYsvvdQsstZnBg4Y6K41uq/O8sFzzjYHHXSQ fQhtNuPsy4A+C+mrwNF2Jbh+kEuXLrXz2EeaiftPNAPs2yQOAhCAQKMS0FRHLWIbu/feznJZo474 y/qa5t2+8cYb1nrPWvfFtVGZIhcEak1Au2qfdNJJbqRaSr8W+2oKctKIv3QTzVgoxyl/DYqW4xox rXQ56Xqqk5T/0aNHl/1iUw6TZkyTOcVfb8Jh05v77Luvs0DTW7tY2i3svWk5zbE7/Mgj3A9MCr9M yOmBpAfmJPu5SOnkrwdqsQUiUeWm7RBKWyz/uLwqLTfMKq6csP+mjckjEuH4XEMAArUloGmJe1gj BBr9amSnLxHaU2B3O4Vy6xa7zwBWTRq5uZCtGwhIz5DxkLQGRJpp7x+Pr9aWanw5HIsTyJTir7n6 d//mrrIXykj5LneRTSVpV61aaeemjSjeWhExKim3krTr7N4ILHiOaBC8IFAnAr3tyJffo6ROIpRU rGSVgQAcBCAAAQh0H4GMKf47zM033VT2gg7NqSt3MUglaSuZN1dJuZWk1TxdLUrCQQACDULAzudv 1Ok90YQabQFCtJT4QgACEMgSgUwp/nqMDB46pMCsZ9oG0xeDsEnQ7kirhW7lTrmpl8za7Xjt2rVp 8RAPAhCAAAQgAAEIQKDOBDKl+Etp/+SnPuWsWpTDVVYmZBKqHFdJWi3o0aKUclwl5VaSdo1V+m/5 8c1m3ksvliM2aSAAAQhAAAIQgAAEuplAphT/Xr17manWdmuzbc/8ht1VeOy4cWU1fb0WzKxYscKt pyhLaBJBAAIQgAAEIAABCHQ7gUwp/qKnKTPlTpupV9o+TSizWDXXfOJu/21RIAQgAAEIQCCRgNba adrs888/b15++WWjQTVZ60sy59nR0WHa29sT840LVN7lWv5qxLTSQ2SUxdvxP/jgg505dvSTuB5g TOYU//iqEgIBCEAAAhCAAAQag4Ds9WvTrjvuuMPMmjXLvPLKK07xl8W9JMW/MaRvDClkkMVv4KVd e0+2G7Gee+65ZsKECWWv2WyMmtVOipYFCxY0/b7Q3/6Pb5nfTZ/uTMP9/qEHa0eLnHMEZInoi1/4 R/PMU0+ZI446yvzX/3wnF8YJBCBQOwIaIdxoR+20+ZXOvWtvbzP7T5zYNJvXbLR7gbz2+utu/xRf Bz3Eh1oDDQPsXgTlWljzeXGEQCMTkGKvEf4f/OAH5sEHH8z7HTSy3I0um/Znet/73mc+/elPm3F2 CjUj/4Ut1iowca6S+ePducGEtmZW4+pPn7+abY5/d7IKtnUl7avPkf5zoY5J/ShYps4rKbcZWVVS 30rSwirc8+Kvm4mVXrpXrFxppwesi69Qk4ZI2R9hd1YfMXx4wQtMJb+FeqVtpn7luwysPInix0pY LV682Ey3A5b33ntvblPR4iUSoxgBmRm/++67zb52A9Yvf/nLRsZTStFPgvlX0r6NnLZXsJKcQwAC EIAABCAAAQjUloDm9N96660o/TXAvN7uBn7LLbe4aVQ1yL7ps0Txb/ompAIQgAAEIAABCDQTAY30 azQaVxsCb775pvntb39bm8ybPFcU/yZvQMSHAAQgAAEIQKC5CDzyyCPNJXATSnv//fc3odS1Fxmr PrVnTAkQgAAEIAABCEAgR+B1u7A9zo0fP97oL8ppUfDMmTOjgpxfI6aVYDNmzHDylfNvypQpBWt+ fD7WQI3RX5R78UU2GI3iguIfRQU/CEAAAhCAAAQgUCMC69bFL86fOnWqufjiiyNLluJ/qt2oNM41 YlrJWonif9VVV5lBgwZFVllz+W+++ebIMC2wxRUSQPEvZIIPBCAAAQhAAAIQqBmBJDv9GrWXAh/l ktIpfr3SynJOnMxR9SjFTyP+cdYak14otm/fXkoxPSZurx5TUyoKAQhAAAIQgAAEIACBHkwAxb8H Nz5VhwAEIAABCEAAAhDoOQRQ/HtOW1NTCEAAAhCAAAQgAIEeTADFvwc3PlWHAAQgAAEIQAACEOg5 BFD8e05bU1MIQAACEIAABCAAgR5MAKs+PbjxqToEIAABCEAAAhBoZALXXXed6d+/f6SISXsaRCbA 06D40wkgAAEIQAACEIAABBqSgBR/XPUItBbb4KBYeJIo3ZV2y5YtTgxv37a7yg3XvaeVu23bNodA x1LrXmr8IGvSBmkkn8MqmU8wtFlYyTb1xo0bg6Jn5lz3cNVtzZo1pnfv3gX1apY2CgqOzEEayec9 jVUcjU2bNsU+U72e02hpN2/eHCtznKzd5d/T+lWx+rbGbYqgBlHipPCkRuvo6Cg7banl9u3b14nS 0tLijuXKXGq5wfpXkrY7WVVL5hUrVuS20G5tbS2prXsaq0rqW0naZuxXldS3krTNxEov2lu2bg3+ lDNzrnv4gAEDzNChQ3P3F1+5Stq3XmmbqV/Vm3NPY+V5Rx01rSVOjymm+Ncrbb9+/WJljqpjd/rF sSwmQ73uG7Uul8W9xVqecAhAAAIQgAAEIAABCGSAAIp/BhqRKkAAAhCAAAQgAAEIQKAYART/YoQI hwAEIAABCEAAAhCAQAYIYNUnA41IFSAAAQhAAAIQaB4CvXr1Mjt27IgUeMGCBWbGjBmRYcXm+Ncr 7cKFC2NljqxIN3hGGQjohmIbvggU/4ZvIgSEAAQgAAEIQCBLBNrb282qVasiqySlXwp8lCum+Ddi 2qh6dIffsGHDuqOYpisDxb/pmgyBIQABCEAAAhBoZgIHHnigeeyxxyKrIKU/TvGPTBDwbMa0AfGr ejp58uSq5peVzJjjn5WWpB4QgAAEIAABCDQFgfe+973GmyBvCoGbUMgzzzyzCaWuvcgo/rVnTAkQ gAAEIAABCEAgR+D00083++yzT+6ak+oSGDdunDnrrLOqm2lGckPxz0hDUg0IQAACEIAABJqDwL77 7msuu+wyt1ldc0jcPFIOGTLEXHrppWbixInNI3Q3Ssoc/26ETVEQgAAEIACBRiNw7733munTp5ut dkfoD33oQ4yUdkMDaYfdj33sY2bJkiXmV7/6lVm6dGk3lJr9IkaNGmXOO+88c9FFFxkxxhUSQPEv ZIIPBCAAAQhAoEcQuOCCC0xra6tT+F955RVz4YUXmptuusmcf/75PaL+9azk3nvvba644gozduxY 8/DDD5sXX3zRLF++3GzcuDHW1Gc95W3EsmUWdcCAAUYK/wEHHGCmTp1qzj33XMeUNRTRLYbiH80F XwhAAAIQgECmCcydO9cpnD/4wQ/Mhz/8YVfXBx980I1Ao/jXvullZ15Tfi6//HJz8sknG7WHV/yT zHZ2dHQYmQMtx23atKnskfBGTCvFXyP7o0ePdor/QQcdZAYNGsTC6YTOgeKfAIcgCEAAAhCAQFYJ yNzhsmXL8qqn+dFHHnlknh8XtSOgUenBgwebY4891v2lKUmbZWnxajmus7PTtLW1lZPUNGPasiqa 8UStasgkVyy8EdJu2bLFieHfkJtB5jC3ZpR527Ztrho6lip/qfGDvEgbpJF8DqtkPsHQZmG1fft2 NxUgKHtWznUP1zSHNWvWmKhdN5uljYLt0QwyP/roo+bOO+80ixcvdkqhrKGUK3e56cSMtMGek3wO q2Q+wVBYBWkY05r05idYSeH5WeVf6VNUuWlLLbdv376ucD+fq7vKDda4VJmDabuTVbDcSmResWKF mxeq/DQ/tBTmlZTbjKwqqW8laWEV7O3J583ESi/aW+wizCw63cM1X3fo0KG5+4uvZyW/hXqlbZZ+ pakRffr0cdMjduzYUfI9vRpt1CysfF11pF8FaSSfwyqZTzC01qww5xmkzTkEIAABCECghxHQgsgb brjByLrPoYceaj71qU/1MAJUFwI9hwCKf89pa2oKAQhAAAIQyBG49tprjTaSCjp9cXnrrbeCXpxD AAIZIoDin6HGpCoQgAAEIACBtARks18mJDXaL2syM2fONA899JC5+uqrXRYzZswwejnAQQAC2SGA VZ/stCU1gQAEejKBLmO8gYOejIG6pyegaT0//OEPnaJ/zTXXuLn92vjokksuyWUi+/L+RSDnyUlV CchAiTbw0tq5DRs2GK3jSfotK+78+fPLkmH9+vXO3GU5iRsxrdYFaX2K1qmMHDnSmfXUNS6eAIp/ PBtCIAABCDQNge07thvZ2W6Wh96mTRuNLBTh6ktAFnz0550WFnqnuf8a9cfVhoCU+5UrV5onn3zS zJ4927z66qtO+dfvOEnxr8Sevl4qZJCjHNeIab0dfyn9kyZNMsccc4z7k8ERb/ClnLpmOU15rZ9l ItQNAhCAQBMS2Lx5i1lhlYgWu6FNXzvipQdiIzpZjZGsK1etMt4Uc6VyLliwwCmowZHqSvMkPQRq TWCV/Q3cdttt5o477jCvvfaaWb16tRvx1wtxkuJfa7maKX8p93qR0dqU4cOHm0ceecTtOn3eeeeV ZG2wmepcqawo/pUSJD0EIACBBiAgJXr58hVuFH3gwIGmd6/eDSBVvgh2NpKTT1MGZL5RI4jlOq/s a176zTff7LJB8S+XJum6m4CU+3vuucdcf/31TunfvHlzd4uQifL0grTVmjfWn/b/WLJkiduUTiP+ fjfqTFS0ipXIhOJvX/h2OtsBcN1IwOPONUA3lk1REIBAAQEp0suWLS/wz4qHV/ZvueUWpqBkpVF7 aD1kOenGG2808+bNY8pbFfuApkE9//zzbsH6lClTqphzdrLKhOLfr19/N5dLD71qfTrOThPXriYb Nqy30wpaTL9+/WpXCDlDAAI9moBX9m+66SajHWZxEMgCAVlPeuaZZ1D6a9CY0gWfeOIJZ6Xq+OOP r0EJzZ1lJhT/cePGuTle+lQ276V5ZtSoUc3dKk0gvRYkLV78ptGuyXvvvXcTSIyIEIBAqQQ0f7a3 XSugj3uam99d844XLlxoZs2aZUod2T/llFMiqyhFoB4LGlmEGdkckZ49jZXmpDO9J7IrVMVz48aN 5q677jIo/oU4M6H4H3f8caZ9+DCjeaM/++lPzX77TTC77b57YW3xqQqBtWvXmtt/+Suzws4nHj1m tDnppJOqki+ZQAACjUGgf//+pm3oUDNkyJCclaAtW7eYzs41Zu3aNW5xbq0llfKPg0BWCTz77LNZ rVrD1Euj/rhCAplQ/Cfst585225E8v9u/KF56MEHzLD2NnOs/bwzcuQo07t3essW9bJRK5u8by1e XNg6KXy6U2aN+MnU23NPP2tuv+2XbrT/pJNPNsced2wKSYkCAQg0A4FBdmGwrGMMGzbMWsrob++h OxcJb7OLEQfaUcp+9iufrJFstHNpa+X0FVe24/WnqT4a+X/ggQeKTvWRzfkop/uWFvuV4ypJq5cX 1aUcV0m5zZi2p7FKMrsrM6r6i3L66pa0qVojplU9tE9Eue6qq64yGoyIcjOsuVn9RTl2oI6iYkwm FH99wv34xz9hVthFbfdOn+5Gox9/7HG3mYN/aEVXP9+Xz8H5PMJXO6yd8A77AF34+gLTq7W3mWo/ q19y6aWmrb09HJVrCECgCQnofjnMfj0dNWpkwYO21YbpC4Di7OiyJjmXLnPTf2pdzfHjx7sXgCuu uMKZO/TTf+Ie9rWWh/whUA0C0jfinJT3uE3T0ij+9Uh7sh0EjCtX9axU8Y97cRePuHsBaz6je1ir RgaSXLHwRkk7aPAg84mLLzLtVgl98k9/MoveeMOssvPQm8HpIdqrJf2XiXrWSbbB950wwRx17NHm fWeeafYeO9Z9BShVpmbpV8F6IXOQRvI5rJL5BENLZSUzgJq/WgunEf62oW0FSn+wLM1Nbrej56tX d7gNw4JhlZ7rIa66ySxf1KCNvkLoBUB/b9h7/M9//vPcUWUnsUwKKyY3aYsReiccVu+wKPdM6x3i OOo3kuTqlVbrFeJkTpI3bVhc3mnWScSlTVN2FtO2xr1FCYgqnBSeBE02mstNW265h9jtx9vbh5kT rQmn+fNfd/LvsA/JtE4dqFwLNZWkLbe+qlcl5ZaetsUMsfN+97KLeSfYdRQTJ05MizYvXiX1rUe/ kvCVyFyvtLDK63aJF83ESiOFW6zN6lq4wYMG5+b0x+WvBb9a1D940KCqK/7KWy8WQ+19JrwYN/w7 OuSQQ8w3vvENJ+bXvvY1Nx0o7pkTThtXtyj/StI2U7/yda+kvpWk7WmsPO+oo1tjEzM1rZjiX6+0 0p3ifn9RdSzVLy7vNDpbXNpiMlTSnxs5bSam+gQbb2jbUHPyKVPNiSdNcTvgaV56WqdRJj1wynGV pF20aFHZlnEqKbfUtC2mxQwcNNApBurUOAhAIFsEetspfL2sid5izln7sXEbxfnpQI0iD3JAAAIQ aFQCmVP8PWiNFpWqxOthVu6bYSVppURrilI5rpJyK0lbjqykgQAEGpvAtq3bUs3b37FDu2XGz1Fu 7FoiHQQgAIGeS6A5Jpb33Pah5hCAAAS6jcC6devcJohJ0wkUtmXLZvdFtdsEoyAIQAACEKgKgcyO +FeFDplAAAIQaEACWmRfC+cXBva183VlujPKbdiwwXR0dNZs8yHVTV8jcRCAAAREQDt2D7JriqIc +31EUUn2Q/FP5kMoBCAAgYYiIMW4v1XMdZSFn2q67XZN1CprrafF5j3cWtDRwjm/yHarXVC8adNm Z8N/tTXekPRVoFyZfN1Q/MslSDoIZI/Addddl7sPhWu3wO7zgSuNAIp/abyIDQEIQKCuBKQcD7Sb bEn5l/GCaiv/Mqe5zO6JoqPMdvbrt3PjnE2bNhop/GvXrjNJNsjLhaPNFvWVQVZ9VEccBCAAARHQ iD+uegRQ/KvHkpwgAAEIdAsB2bgfMWKEMXavkvV26o1eALTgtjSn+NZWV8SsGpn61d+KFbXaC8UX 2uWUfI3w62Vmr732jLTfX1q9iA0BCEAAAnEEUPzjyOAPAQhAoEEJ7FSU7UZa7fuaFVb5X7z4LTvv fnVJ0naZLqn9dlrPTiXcT93RWLum+sg5P70Z2HcEjcKrXL1k9LJHecu19OptunQe2FhIJkFbTC/n 1dKy84VkVzY2rY1vveTby4a1t7eZ0aNGm2HD2t1oP9N8RBUHAQhAoDYEUPxrw5VcIQABCNSUgBRk bdaz25gx5q233jZzX5prNm3cnLrMneq4lO8Wp4TvTOh9pbjvVM59hk7Pd9q7jbNL6VeYYvpUkXHz PHem8F7aKfikKSea0aNHuTm8KP2eDEcIQAACtSGA4l8bruQKAQhAoOYENAqvXXT1AqAR9jVr19a8 zGoW0L/fGNPPyt+nT59qZkteEIAABCAQQ4AVVDFg8IYABCDQLARk6m6YtcLTbE4yx5npa7a6IC8E IACBZiDAiH8ztBIyQgACEEggMMzu/H3AAZOsBZ6+CbHeCZJpznJH2WXHXwtxy3Hhcifsu6+R7DgI 9DQC+v3p9xDlZsyYEeXt/PxanLgI9Uo7c+ZMc+2118aJVRd/mSPGFRJA8S9kgg8EIACBpiIwcuQI c+KI4827jj8uldxr1qwxQ4cOTRU3HOmNN94wY8eODXunug6Xqzn9zOtPhY5IGSOw5557mjgb9FLe kxT4JBTNmDapPpWE7bXXXpUkz2zalo6OjvC6rKpU1uZrrTUwkpMGJqzSUNoZB1awSk8gfUz6FazS E0gfk34FqzgCl19+ufnFL34RF4x/FQhceOGFRpt/oYvmw2xtsxu0xLnOzk6TFB6XTv664ZWbtpJy mzEtrJJ6Un4YrPJ5JF3BKolOfhis8nkkXcEqiU5+GKzyeSRd9TRW06ZNM3fffbdZv359EhbCyiSg 6Yjnn3++S40umg+Rxb35PLiCAAQgAAEIQAACNSVw/PHHm5NPPrnstTY1Fa7JM9f6iSlTpri/Jq9K TcRH8a8JVjKFAAQgAAEIQAAC0QRk0UrTfQ4//HC3cV10LHxLJTBgwABz2GGHmc9+9rNm5MiRpSbv EfFZ3NsjmplKQgACEIAABCDQKAS0B8fUqVPN6tWrzW233Wbmzp1rVq1aZWQ1a9u2bTt3zW4UYRtY DhkHaG1tdZbGhg8fbq2bHWAuuOACc+qpp7rdxhtY9LqJhuJfN/QUDAEIQAACEIBATyUwePBgc/bZ ZxtZ+HnyySfNSy+9ZJYvX242bdpkduzYEYtF4dq0rxynlwopymmdZFqyZEle9N12280p2HmeRS5K LTeYXVJavUCJxahRo8ykSZPMsccea44++mgzZMiQYBacBwikb/1AIk4hAAEIQAACEIAABCojILO6 J510klOkpfRrsa/s+yfZ61+6dKkZM2ZMWQUr/1I2zbvvvvvMN7/5zbyyrrzySjdFKc+zyEWp5Qaz S0orxV8vMqqTlP/Ro0eX9GITLKennKP495SWpp4QgAAEIAABCDQcAS1G3WOPPdxfGuEWLlxoxo0b lyZqQZxSLR9qOpKmIvk9B8aPH2+uuOKKgnyLeZRabjC/StIG8+F8JwEW99IT/n97ZwKt1fT+8R2t ZRm7yJBi/f0QkSmRMqyFUIaQEiFRpiJj5jEyhcxFGUslIbMylzlDFFYyrGUoylBYpsW6//PZel77 fc95zz33vt3p7fus9d5zzp7O3p9z7j7P3vvZe4uACIiACIiACIiACCQSQPk3QfGXNG4CUvwb9/NT 7kVABERABERABESg1giw7KjJxRdfbKc6NlICUvwb6YNTtkVABERABERABESgtgn07dvX32KDDTZw Ye9/bd9X6dcOASn+tcNVqYqACIiACIiACIhAWRBA+UfxlzR+Aprc2/ifoUogAiIgAiIgAiIgArVG AHOfHj161Fr6SrjuCEjxrzvWupMIiIAIiIAIiIAINDoC9Pizuo6k8ROQqU/jf4YqgQiIgAiIgAiI gAiIgAhUSaBJtDZrZZWhaiHA77//7u644w6/SUXSmrA33nijv+txxx3nVlxxxcw5YKmpCRMmuB13 3NG99NJL7sILL3Rrrrmmu+CCC/wwla1FmznBIgHHjh3rd9m7/PLLYyEs73jYJhzrr7++22OPPVxF RUUsfJLD//73Pzd+/HjXoUOHJG/v9sYbb7jevXu7zz//vGiYmnjcdtttfjOMlVZayR/ZAQ+erDUs EQERWLoEbrjhBv//xf9YKLgjSfVjGI7zDTfc0Nd7SfUF6VBXUC8uDaHu+/jjj93QoUOLJjd37lz3 ySef+B0/27Zt6zbZZBO3xhpr+PBhfsLzoonJQwREQAREYKkRaJq2CUQpmyZk2WDir7/+cpMmTXLD hw/PKxD3HTdunFfUN9tsszy/qi4ef/xxxzbYlOuLL75wO+20k0/r5JNPdi+88ELqphfVKS8ftj33 3DOXXhj3vffec+HyV+SZco4ePdrdeeedrmPHjnnFSGLFdt3szJf2fCjf5MmTU8Pk3ajgIsxz6DVs 2DDHkl3slsdvwYIFrk+fPq5fv35u1KhRPmixuGE64fmxxx7rjjjiCM+lunHDdJJYhf5p56XctzHG Fau0tyHfrz5ZzZw50x1wwAGx/+NmzZq5l19+OeZuOQ/fSToYitUXpMOW9mFdEsa19LIeqd+6deuW l14Yt1evXl7p33LLLX2e2Pzn4YcfdhMnTnR77bWXC/NDOmlphemm5ZkOnaOPPtq9+OKLYZTceVrc XKAiJ6XErc/3Cs41kVLKW0pcscr+tMRKrIoRyPI/WK82/sccc4y79dZb3axZsxwfCZOPPvrIsSU1 /sjzzz/ve7VRhjfaaCPXuXNn785HEUHJHjJkiLvooosc2zc3adLEfzDxYwRg2rRp7pBDDsn1vuOO PPHEE+6dd97xvWVbb721D4u7pfvDDz+42bNn+3RxN/n55599D9p5551nTrEjS16Fy16Rt3333dfR MDHF/7fffnNPPvmke/31132P33777efoZTehHIxaIGFa8+bN8x9W/CkvEoYj/3PmzHGMloTy2GOP OT7a++yzj9t+++3dK6+84vMUhuEcJYL7hY2Xbbfd1isnNAps1IKP7IwZM9zmm2/utttuO9eiRQuf lOWFC/LSs2dPX8bDDz/c55PGBCxCsThhOUN/nYvAsk6AUVLqiw8//NBtscUWbpdddvFKdBIXOgQ+ /fRTt/HGG8e8qXceffRR3zHSpk0bt//++/tRVf7vqSsR/m+5Llyzm7qPOuSKK66IpYsDSj/p08my +uqr58Lccsstvh7goxSK1V/mRtynnnrKffbZZ75eplFAowV59dVX/Qgk9Q/lO+2009xqq62Wyyth rO4O6y7cJSIgAiIgAv8S+FdrrCca7dq18+Yvd911V14OxowZ493xv/TSS72i/8033/hhY3rZcUP4 MF1yySXelIcPIoJCibv1/Hz99df+HLdQqcRE5uyzz86F3W233dyUKVN8Gnzsvv32W3fGGWfk0vEe S/6gqGO607p169A59ZwPHB9heumRhQsX+g/3gw8+6PNw0003+WvcQ3n77bdjQ/30umNORJn4aJvs vvvujp71kSNH+t/yyy/vzLTp/vvvdwceeKBXBq677jrvH8a1NIodaSgglh69a9dcc42j54FGTatW rdwHH3zgw/DxRZE/8sgj/ZHnhbKCW8uWLX3P3PTp031Y+0Pemzat13aoZUVHEWgQBGjYm8yfP9/t vPPOOfNIzCT33ntv9/3331uQ3JG64fzzz3fUfe+//37OnRNG70jnkUce8fUHYbm2dKgjFy1a5O69 9968eHZB3bfeeusVrfvopKHDIVT6iXvSSSdZEnlH6gTqcIS80ZhhZIBGDnljxNbyRt2OiRF1HB02 9GhTr1EPkg5uU6dO9dc+Qf0RAREQARGIEah3TYtefX6huQ/mMHfffbfPLIoxHwJ6jRF6lVGSw54o FF3z94GiP3xM+PHx5Gg9QfjTS/3000/7Hm96zhDMULCpZ2QAoUcJ2/nw4+s9oj/YyybZ0pp/0pHG DSMMI0aM8N6UC5tXyobyTEOCUQ/cBwwYkEsC5Xnw4MF+PoGZPd1+++3O7H/56JlwTs888TlnngDl /r9o1IO5DvTSnXPOOT445Q3jWhp2DP1+/PFHr3DQcNlmm238B5pGD8zp6ScsygAjCFtttZVPAlOo Z555xvdMMlJDOWlcYetLryA9gHzkEcygaFiggEhEYFkkwP9pWEcVMkDRRzFGuTWhEc3/VVhf4EfH AOFRmhEa/CbUL82bN3f33HOPV5ypR7HBx/2EE07wwa699lrf425xwiN1H3VAkqCUM0q6ww47JHkn uoX1DPUA87EoE0LeyCt5O/HEE70bDY+33nrLn7PKyHPPPZf7VlAvps078JH0RwREQASWcQL1rvjT 807vMSYw9EBzRHBnqJoPCaY/1suP31dffeV7szjnQ2C9+1xnEXrBUDL50PBDUGrprTJByU5S+vF/ 88033cCBAy1o4pGJvKFgnnT99de7Ll26eGd6qMgD5TKbLBRpPu4mfBSx20X5ZxSEj9q7777rVlhh Bd9AIY1CsQYQeUfhtxEGjphJmWBuRG9ZMaGxQc8feeNHjz7KOrL22mu7QYMGeUX/tdde80P73Csc rcAcyRpVhRxR/FH6acBRPnoXed4SEVhWCYQKcBIDTPfMRND8UbBRxEPFnwY3o2tM9jWhgWAmNjQu qHeuvvpqX48QhjoD00qTyy67zE5jR+o+q2MKPemlRxhprImEdaLFp14O6xVMf0yoc8LGEnO7JCIg AiIgAukE6l3xJ3vYajIBDMWflSfsQ4bST29x4UeR8Cj/yJ9//umPxf6gJCNhGqTLdehGmCw9zijQ fIQLV+Agfig0Isy0CAWXEQ2bm0C4X3/91ZcNpTgpL2Fa9M7zsaXX/r777suNSoRh7Hyttday09gR e1gTRhjSBFt+E3brQ3kwltjv8gwOO+wwb3/Lx9n8LE6hsm/uHBnZwAaXnj3KRsONUR6JCCyrBKgr rL4wBmFnB41w7PFD4X+ycEWvn376yQexFXS4CP/vf/nlF/fPP//E6pzw/zU8D+9ndR+jiklidQr1 Iz311RXLW3j/rl275tXTjAgUk5VXXrmYl9xFQAREQASWEGgQiv/xxx/vzVJQjlnNx+xSMQuhB5ye 46RepqQe78InaxPDQnfMVOjVwkSInmwT6xWz66QjIwwo/WkfoMJ49I5jWsQ9sYtHKBMT6VB6q5qh z0oYfEhRlOGDHWtNhPuYYJZTlRQqIhaeXjZW+WEOhMnNN9+c94EubFRZODti3kUc5j7wbBlFkIiA CCQToL5gcmsomCzuuuuuoVNulI0GAZPukS+//DIXhnSYX4ONf+GqL1X9z1rdV2i/b4nT6dC/f3/f OWFmRuaH2R8dF2kLImByZHWixavOUYp/dWgprAiIwLJKoF4n9xp0hqU7derkbTk52rJz9FqhFGLm wpA2iiu9YPQCsTJMFknaAwBFmo8UvcwMI9PQ4KOTZvpi96qJfT9x6fWnF/3ZZ5/1STFRjYYL9qsI H3XyYHMbvGPwB0WZsAzvF7OxDYLHTo866ihvysQEXBoO1riKBczgQEMGpZ1hf8wKMN2BMxMQmQ9Q KPTgoSwQ1spPw4E8UCabV1EYT9ciIAL/EqC+QPG2+gITRWzdWQksFJRfFH7CMSmWBv7ff/+dC2L1 Dqv6INQ7NL4t3VzAhJMsdR/ziJhfgPkmc5ow+aPOps6gnmASfzGxvJn5JXljtNFs+ovFw529RuCD hOY/3kF/REAEREAEcgQahOJPbjAd4ePDMRQmwzKh99BDD3Xt27f3HyrbYIpwhcu2FfY0WY8/vVkW lo8jHyeUUCbAsoY2DQyWm6xK+LhUd2IvaTJ6wSoVfBgxX6I3HeUZW1tsVRn16NGjh/9gEh7/sAcO xZ8PKWFCCc2TiFNMmMxHeqeccoo3q2Jfg2KSlg5xGO1g5AJmzAUgT+SPDXto4CQJ92P+BnMCTIjz xx9/+IacuekoAiIQJ8D/JP9bV111lZ97xOR+JrNanWZHYjIplh59lih+6KGH8v6/mGBPPcR8Ixrk rMCDeSX/ywjphPWOd1zyJ0vdR4cKIwx02jDCyVwp6llGB88888wwudi5lfHKK6/M5Y263iYLF9bt YQIsMnDwwQf71eBCd52LgAiIgAgUEIgq+aIS2ZUW9avKI1r2saogRf1LuW9txo0U9kp+SVLKfbOw ilYFqoxGRiqjkY6822e9bzS6UMnPJBpZqIwaDXZZ7WPW+yYlbHGjBk9ltIJIUpCibllYFYts9y3m n+beGOOKVdoTzfdrTKysDir1nbR08kkkX4V1X12wSspbqeVNLlnVrqXcty5YJZWglDzXV1yxSnqS yW5ilcwlyVWs4lSWK2gH6DKFAD1k4cSzlKBLzYtJzPSWs1Y+owPhBl/VuQlzCehRw9yIoXB64Fgt qD6EXsju3bv7JTzDeQL1kRfdUwQaG4GlVQdVJ526rvuqk7fG9vyUXxEQARGoTwINYnJvfQJo6Pdm B0tMa0aPHu037Klpfk8//XS/HCD2stj9sjum7QtQ0zRrGo9lWrHn7devX02TUDwREAEREAEREAER EIFqEpDiX01gdR2cXnp+pQpL+rHTJz+TLKsYWdileWTH5MIVRZZm+kpLBERABERABERABEQgTkCm PnEmchEBERABERABERABERCBsiPQhIk8tVGqKF1XUVFRG0mXXZpilf2RipVYZSeQPaTeK7HKTiB7 SL1X9cuKeXEIo8wNWVhanOWuWW0rSVgpa/z48W6fffbxG2DW9L3CxHaXXXZx55xzTtJtquXG6lss uctqg0tLaiNNY8UGgSxJzIpnLAe/zjrruK222spvIrq08t9o0onP9/3PJQL230U1zzSTOjswsRKr YgT0P1iMTNxdrOJMirmIVTEycXexijMp5tLQWEVmspXR8rbFsuvdS8nz0oob7bNTee+99xbNJ/7R /kaVHJGsOsN7771XGS3R6+Pwh/NIUc9dV/ckLG+0k3cl6WeVMK7FYfUunlG0+Ih3KpZmUlxLo6qj sYoaO3RyV0ZLp/v7RUvHV0bLrOeYJqVTyn0bclzZ+DeaJpoyKgIiIAIiIAIiUFMCbAL6zjvvOHa2 3nHHHV24Dw69wZHi6fejYd+gTTfd1N/GNoSLlObE699//909+eSTvse+TZs2bv/99/cbWhLY4s6a NctvbsnqfIXy888/+57oYrtaRwqkY8M9eqrZh4M9PEzwYyNMyxvukaLrvbG4IB5z+chHGIbNQ3Fj M1D2MQoFd/zxI45ZbsycOdPvzzF58mS/ySr7D5ngVzhnkHl8ttkoeXrggQf8vj3cz9y5Fz/KEKZn 6VI+/NkslPmJYRlwZ68S7s05fsXmQ0ZKvYsaVn4fpXPPPdcnT1ie1XXXXedHLWwzREYweEfYWHaj jTZytn8I9zCBD/FZIIWRAxMLQ15+++03v4cJIzm8F926dXO2r5SFY0NVNj1l75W6FNn41yVt3UsE REAEREAERKDOCaB4olzed999jmWy2V167NixPh9sHIpiNmXKFMeqcyhqKGwICh6Kownnl1xyib9k d2waDxMnTvRh2ByP64ULF3p/wv3www9+07wwDUuLIxvjrb/++q5169ahc+7cFG3ygULJZpyh4B4K DQPCoDSzjPdPP/3kjxZm3Lhx3p/8sKGnlQX/bbfd1g0fPtyXJdohLNc6AAAL4ElEQVTrxzc0SAc5 9dRTvYkQ/ijy3MM2XEX55l72O/DAA/2O3cSjwYKiT6OLe4aNFxRo3KKRg1ia5Jv8kI9oZMArx7bz N3Eo90EHHeTgwzXn5ClJWB54r732cpT9o48+ygUhLyj6pvT37t3bm4WRHmWhYfD000/78FyTXzZ6 feGFF7xZ1qhRo3JpEQdGb7/9tvvuu+9cly5dYu8F7wvhOnfu7N+LYhue5hKtpRP1+NcSWCUrAiIg AiIgAiLQMAjQu0rPqim6KGa//vqr++abb3yP8q233prbwZqe3q+//tptscUWqZlH6WSXahR/hPTb tm3rHnzwQTdgwADvRo8yu9oX25uCkYYOHTr4sEl/aEygUCJ9+/b1CjVKLmJKub9Y8sd66GnkoByj rFqZCYLiaQoyYUgffxoMKNso4SYo7JSR+yLMNUDJR8I0zR930iZdFHaEcuOGks0oAH70vlMmeA0Z MsSnb3n1kaI/5Iuw3J/RBFYmhDVpRSZPPhj5oyGCwIJ0w7x4jyV/uBfKf6dOnfxoT8eOHX1jATt/ hKXOn3nmGTd9+vTcc+/Tp49/ll27dvVheI5Tp051m2++uW9AkuYFF1zg/RgtYuSCncppZLIMu70X jPTYe3HCCSf4ESHmc8ydO9fHres/UvzrmrjuJwIiIAIiIAIiUKcEhg4d6pVQFFHMeFD8Irt5r1Re dtllbs899/S9zvidddZZmTbLZE8cevgvvfTSXFl69uzpTU9M8UfZLKb0EwkzloEDB+bihyco2SiU 9KAjKLUozDQWyDs979UVJveaoFibIk9adh/z59r8cQvjWpjwSKOBUQB6x60BQhqYtjDReoUVVnDc pyqhcUKDhcZCKJj2MHKAwDQ0U7L7heHDc0x3UNzpwX/uuee8kk/jhZGfu+66y9EwxKxn0qRJ/kfc li1b+lECS2f+/Ple6eea58zz4PmQ9oQJE/x18+bNfd4xJQvfi0MOOcQtWLDAJ7Xyyiv7983Srevj cnV9Q91PBERABERABERABOqawOzZs/0t6SWmN58eYmSPPfbw5huYALGbPH6mYPoARf4wYoAZCoqq /QiKqVAWQWmcM2eO74FOCk8vPL3dq6++eq7RwjUjCjWVDTbYIDEqCnmS8hwq6uGciMJEKAsc6ek3 G37C0FBBQabHHlMlGiz1JTQWWBmJ3nZMrMwsimeNSZY9QzuSz2OOOSaX3bABt+KKK7r+/fv73n3C jxgxwjFCgBR7Lywh4sKjvkQ9/vVFXvcVAREQAREQARGoMwIo9Pww0aCXnR5f6+XG1IQfShxmGfiZ uQoTNU1ee+01O/UK/rRp03wPd86xGicon/QMYxZSKGa6Qu85+TKhBx7bd/zpsS8UesrD8IX+SZNw CYOyHvbu48Z1qMQXxiUMgolQ9+7dHSYtxhN3WGLH/vDDD+dMfTDdqUpQsGmEFJoycf+abP6JORFc aDCFrGkE0PjDzj9a4cddfvnlbuTIka5Vq1Y+i1Xdj0ngzJPA9Ic8G3feMZ6tTeINywuTlVZaya26 6qqhc52eL1end9PNREAEREAEREAERKCOCaDo9+rVy/fk08NLr+v222/vc3H66ae7+++/3/euY/KB X/v27b0f9uSY4zBhF/vyGTNm5HLOSjMolDbJk3XtaTRYgyEXsMhJmn0/96J33JRJSwJFnBEF/FH8 UYTpuUZQqsMeetxQXlGgTYlmhaFQTLGnV55VgCgPwpFr3E0K45o7/EjH5iKYO0fyZ3kiTRoTKMSW H8KE51wjKNQo5cRBKC/phPnxHhn+9OvXz5vZcKQRglA28vvHH384zHAwycJMh4YK7wf5xAxo8ODB Re+AKRKjSNj0h+ZaNCgwA7ORGc7D92KVVVaR4l+UqjxEQAREQAREQAREoEQCTN5dd911vV14u3bt /KReW5WGjaOYtIny2qNHD4e/KXIof/Ror7322u7dd9/1CqllBdOXMWPGeKWUHt/jjjvOxydOFqFX uNjEXhRPRh2SBAUWfwSlnx895CjJxKFBgKAk08PMNUoz5QtNfYhjYTkyukB8ysKRa/MvjIs7bqSP mQ8/Gin2QykmHRRtlHbuiyJPo4gVlJigjP+gQYO8gk0YS5O8Ex+THPJBXFZjCucOYDYUmiaFcYkf Crb6TLSlwcT9WrRo4Zf2pOFHumuttZZDGcdO/+OPP/blYuSCsg0bNixMKu+c/GPuM2/evNxkbgKw +hDv1FVXXeXLGO0d4OcE8F4Qh4ZlTUYu8m5ewkWTqGD/rVNVkFBVwxwFwfMuaTHV1JarlPs2xrhi lffqpF6IVSqePE+xysOReiFWqXjyPMUqD0fqhVil4snzbOisUJVQ2kIJ9Y0k/zBs4Tm93Ch/hWkW hku6buiskvIcskryT3MrJW59s6ruewGHUsqbJa5MfdLeNvmJgAiIgAiIgAgs8wSqUtCr8i8ESPjq xilMQ9cNn0BDfMZS/Bv+e6McioAIiIAIiIAIiIAIiEDJBKT4l4xQCYiACIiACIiACIiACIhAwycg xb/hPyPlUAREQAREQAREQAREQARKJtAkmmBSdHJvKakzcSWccV1KWuUeV6yyP2GxEqvsBLKH1Hsl VtkJZA+p90qsshPIHlLvlVhlJxAP2TRtSaEss4PjSf7rwouZlnaxeLiXct/GGFes0t6GfD+xyueR diVWaXTy/cQqn0falVil0cn3E6t8HmlXYpVGJ99PrPJ5pF2JVZyOTH3iTOQiAiIgAiIgAiIgAiIg AmVHQIp/2T1SFUgEREAEREAEREAEREAE4gSk+MeZyEUEREAEREAEREAEREAEyo6AFP+ye6QqkAiI gAiIgAiIgAiIgAjECUjxjzORiwiIgAiIgAiIgAiIgAiUHQEp/mX3SFUgERABERABERABERABEYgT kOIfZyIXERABERABERABERABESg7AlL8y+6RqkAiIAIiIAIiIAIiIAIiECcgxT/ORC4iIAIiIAIi IAIiIAIiUHYEpPiX3SNVgURABERABERABERABEQgTkCKf5yJXERABERABERABERABESg7AhI8S+7 R6oCiYAIiIAIiIAIiIAIiECcgBT/OBO5iIAIiIAIiIAIiIAIiEDZEWiyaNGiytooVZSuq6ioqI2k yy5Nscr+SMVKrLITyB5S75VYZSeQPaTeK7HKTiB7SL1XYpWdQDxk02bNmsVdl7gsXrzYpfkXjRh5 8GLWNG4p922MccUq7U3K9xOrfB5pV2KVRiffT6zyeaRdiVUanXw/scrnkXYlVml08v3EKp9H2pVY xenI1CfORC4iIAIiIAIiIAIiIAIiUHYEpPiX3SNVgURABERABERABERABEQgTkCKf5yJXERABERA BERABERABESg7AhI8S+7R6oCiYAIiIAIiIAIiIAIiECcgBT/OBO5iIAIiIAIiIAIiIAIiEDZEZDi X3aPVAUSAREQAREQAREQAREQgTgBKf5xJnIRAREQAREQAREQAREQgbIjIMW/7B6pCiQCIiACIiAC IiACIiACcQJS/ONM5CICIiACIiACIiACIiACZUdAin/ZPVIVSAREQAREQAREQAREQATiBKT4x5nI RQREQAREQAREQAREQATKjoAU/7J7pCqQCIiACIiACIiACIiACMQJSPGPM5GLCIiACIiACIiACIiA CJQdgSaLFi2qrI1SRem6ioqK2ki67NIUq+yPVKzEKjuB7CH1XolVdgLZQ+q9EqvsBLKH1HslVtkJ xEM2bdasWdx1icvixYtdmn/RiJEHL2ZN45Zy38YYV6zS3qR8P7HK55F2JVZpdPL9xCqfR9qVWKXR yfcTq3weaVdilUYn30+s8nmkXYlVnI5MfeJM5CICIiACIiACIiACIiACZUdAin/ZPVIVSAREQARE QAREQAREQATiBKT4x5nIRQREQAREQAREQAREQATKjoAU/7J7pCqQCIiACIiACIiACIiACMQJSPGP M5GLCIiACIiACIiACIiACJQdASn+ZfdIVSAREAEREAEREAEREAERiBOQ4h9nIhcREAEREAEREAER EAERKDsC/w9HOugTkx3aXQAAAABJRU5ErkJggg== --000000000000af253105a1500301 Content-Type: image/png; name="Screen Shot 2020-03-12 at 10.05.20 AM.png" Content-Disposition: inline; filename="Screen Shot 2020-03-12 at 10.05.20 AM.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_k7ntxqms1 iVBORw0KGgoAAAANSUhEUgAAAwMAAAGvCAYAAAAHYwmfAAAKu2lDQ1BJQ0MgUHJvZmlsZQAASImV lgdUk1kWx9/3fekktECkE3qT3gJICT0UQTqISkgCCSWGhCBiR8QRsKEiAuqIDUTBsQAyqIgotkGx gH1AREUdBws2VPYDljCze3b37D3n5f3OzX333fvOd8/5A0D+xhaJMmBFADKF2eKIAG96XHwCHf8U QAABROAIDNgciYgZHh4CUJva/24fe9Bo1G5Zjuf69///qylxeRIOAFA4yslcCScT5RPoesIRibMB QMpRv8GibNE4t6KsIkYLRPnGOKdO8tNxTp7kzxMxURE+AGDIABDIbLY4FQCyGuqn53BS0TxkBso2 Qq5AiDIfZQ8On81FuQblmZmZC8f5NsqmyX/Jk/q3nMmynGx2qowne5kwgq9AIspgL/4/n+N/W2aG dOoOYzDegDgwAt1J6JvdTV8YLGNh8uywKRZwJ+InmC8NjJ5ijsQnYYq5bN9g2dmM2SFTnCLwZ8ny ZLOippgn8YucYvHCCNldKWIf5hSzxdP3StOjZX4+jyXLn8ePip3iHEHM7CmWpEcGT8f4yPxiaYSs fp4wwHv6Xn9Z75mSv/QrYMnOZvOjAmW9s6fr5wmZ0zklcbLauDxfv+mYaFm8KNtbdpcoI1wWz8sI kPklOZGys9noBzl9Nlz2hmnsoPApBnbAAZ03G4C+RjYvN3u8AZ+FosViQSo/m85EJ4tHZwk5VjPp djZ2NgCMz+nkZ/CeNjF/EO3KtC83GQD3dADgwGlfXBwADaYAqMdN+4w1AaCiM9e0niMV50z6MOM/ WLQqBaAC1IEOMACmwBKtzwm4AS/gB4JAGIgC8WA+4AA+yARisAgsBatAISgGm8A2UAF2g72gBhwB x0ATaAXnwEVwFdwAd8AD0AcGwSswDD6CUQiC8BAFokLqkC5kBFlAdhAD8oD8oBAoAoqHkqBUSAhJ oaXQaqgYKoUqoD1QLfQLdAo6B12GuqF7UD80BL2DvsIITIZVYG3YGLaGGTATDoaj4HlwKpwF58EF 8Aa4HK6GD8ON8Dn4KnwH7oNfwSMIQOQQGqKHWCIMxAcJQxKQFESMLEeKkDKkGqlHWpBO5BbSh7xG vmBwGCqGjrHEuGECMdEYDiYLsxxTgqnA1GAaMR2YW5h+zDDmB5aC1cJaYF2xLGwcNhW7CFuILcMe wJ7EXsDewQ5iP+JwOBrOBOeMC8TF49JwS3AluJ24Blwbrhs3gBvB4/HqeAu8Oz4Mz8Zn4wvxO/CH 8WfxN/GD+M8EOYIuwY7gT0ggCAn5hDLCIcIZwk3Cc8IoUZFoRHQlhhG5xMXEjcR9xBbideIgcZSk RDIhuZOiSGmkVaRyUj3pAukh6b2cnJy+nIvcHDmB3Eq5crmjcpfk+uW+kJXJ5mQfciJZSt5APkhu I98jv6dQKMYUL0oCJZuygVJLOU95TPksT5W3kmfJc+VXyFfKN8rflH+jQFQwUmAqzFfIUyhTOK5w XeG1IlHRWNFHka24XLFS8ZRir+KIElXJVilMKVOpROmQ0mWlF8p4ZWNlP2WucoHyXuXzygNUhGpA 9aFyqKup+6gXqIMqOBUTFZZKmkqxyhGVLpVhVWVVB9UY1VzVStXTqn00hGZMY9EyaBtpx2g9tK8z tGcwZ/BmrJtRP+PmjE9qmmpeajy1IrUGtTtqX9Xp6n7q6eqb1ZvUH2lgNMw15mgs0tilcUHjtaaK ppsmR7NI85jmfS1Yy1wrQmuJ1l6ta1oj2jraAdoi7R3a57Vf69B0vHTSdLbqnNEZ0qXqeugKdLfq ntV9SVelM+kZ9HJ6B31YT0svUE+qt0evS29U30Q/Wj9fv0H/kQHJgGGQYrDVoN1g2FDXMNRwqWGd 4X0johHDiG+03ajT6JOxiXGs8VrjJuMXJmomLJM8kzqTh6YUU0/TLNNq09tmODOGWbrZTrMb5rC5 oznfvNL8ugVs4WQhsNhp0T0TO9NlpnBm9cxeS7Il0zLHss6y34pmFWKVb9Vk9cba0DrBerN1p/UP G0ebDJt9Ng9slW2DbPNtW2zf2Znbcewq7W7bU+z97VfYN9u/dbBw4DnscrjrSHUMdVzr2O743cnZ SexU7zTkbOic5Fzl3MtQYYQzShiXXLAu3i4rXFpdvrg6uWa7HnP9083SLd3tkNuLWSazeLP2zRpw 13dnu+9x7/OgeyR5/OzR56nnyfas9nziZeDF9Trg9ZxpxkxjHma+8bbxFnuf9P7k4+qzzKfNF/EN 8C3y7fJT9ov2q/B77K/vn+pf5z8c4BiwJKAtEBsYHLg5sJelzeKwalnDQc5By4I6gsnBkcEVwU9C zEPEIS2hcGhQ6JbQh7ONZgtnN4WBMFbYlrBH4SbhWeG/zsHNCZ9TOedZhG3E0ojOSGrkgshDkR+j vKM2Rj2INo2WRrfHKMQkxtTGfIr1jS2N7YuzjlsWdzVeI14Q35yAT4hJOJAwMtdv7ra5g4mOiYWJ PfNM5uXOuzxfY37G/NMLFBawFxxPwibFJh1K+sYOY1ezR5JZyVXJwxwfznbOK64Xdyt3iOfOK+U9 T3FPKU15keqeuiV1iO/JL+O/FvgIKgRv0wLTdqd9Sg9LP5g+lhGb0ZBJyEzKPCVUFqYLOxbqLMxd 2C2yEBWK+rJcs7ZlDYuDxQckkGSepDlbBRVE16Sm0jXS/hyPnMqcz4tiFh3PVcoV5l5bbL543eLn ef55+5dglnCWtC/VW7pqaf8y5rI9y6HlycvbVxisKFgxuDJgZc0q0qr0Vb/l2+SX5n9YHbu6pUC7 YGXBwJqANXWF8oXiwt61bmt3/4T5SfBT1zr7dTvW/SjiFl0ptikuK/5Wwim5st52ffn6sQ0pG7o2 Om3ctQm3SbipZ7Pn5ppSpdK80oEtoVsat9K3Fm39sG3BtstlDmW7t5O2S7f3lYeUN+8w3LFpx7cK fsWdSu/KhiqtqnVVn3Zyd97c5bWrfrf27uLdX38W/Hx3T8Cexmrj6rK9uL05e5/ti9nXuZ+xv/aA xoHiA98PCg/21UTUdNQ619Ye0jq0sQ6uk9YNHU48fOOI75Hmesv6PQ20huKj4Kj06Mtfkn7pORZ8 rP0443j9CaMTVSepJ4saocbFjcNN/Ka+5vjm7lNBp9pb3FpO/mr168FWvdbK06qnN54hnSk4M3Y2 7+xIm6jt9bnUcwPtC9ofnI87f7tjTkfXheALly76Xzzfyew8e8n9Uutl18unrjCuNF11utp4zfHa yd8cfzvZ5dTVeN35evMNlxst3bO6z9z0vHnulu+ti7dZt6/emX2nuye6525vYm/fXe7dF/cy7r29 n3N/9MHKh9iHRY8UH5U91npc/bvZ7w19Tn2n+337rz2JfPJggDPw6qnk6bfBgmeUZ2XPdZ/XvrB7 0TrkP3Tj5dyXg69Er0ZfF/6h9EfVG9M3J/70+vPacNzw4Fvx27F3Je/V3x/84PChfSR85PHHzI+j n4o+q3+u+cL40vk19uvz0UXf8N/Kv5t9b/kR/OPhWObYmIgtZk9IAQRdcEoKAO8OAkCJR7UCqrtJ cyd19IRBk9p/gsB/4kmtPWFOAOxvAyB6JQCB6F6J7sboruwFwLgUivICsL29bP3TJCn2dpO5yKii xH4eG3uvDQC+BYDv4rGx0Z1jY9/3ocXeA6Ata1K/T0iYAQAM0aRQbBfJKRf8i/0D0d0MkN0RdPQA AAGdaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5z Om1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA1LjQuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0i aHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmV4aWY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vZXhpZi8xLjAvIj4KICAgICAgICAgPGV4aWY6UGl4ZWxYRGltZW5zaW9uPjc3 MTwvZXhpZjpQaXhlbFhEaW1lbnNpb24+CiAgICAgICAgIDxleGlmOlBpeGVsWURpbWVuc2lvbj40 MzE8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgPC9y ZGY6UkRGPgo8L3g6eG1wbWV0YT4KsuiogAAAQABJREFUeAHsnQm8XVV97/83uZmHezOQMGQChCDz jDXBBCgog6IISFtlsH19Ra3Svj6t9vMKtLZq24+1tiKIA9TKLIpEUAQhzDIIaAhTIAkhgYQM92ae 79u/FdbNPvvsfc4+87C/C2723mv911r/9V3rnLP+e00dfYGzAq63t9e6uroKSCQHLV682KZOnZos UCCkknxbMS6sCjSGSBCsIkAKPMKqAJxIEKwiQAo8wqoAnEgQrCJACjzCqgCcSBCsIkAKPMKqAJx3 ggYUF0ECAhCAAAQgAAEIQAACEGhHAhgD7VirlAkCEIAABCAAAQhAAAIpCGAMpICECAQgAAEIQAAC EIAABNqRAMZAO9YqZYIABCAAAQhAAAIQgEAKAhgDKSAhAgEIQAACEIAABCAAgXYkgDHQjrVKmSAA AQhAAAIQgAAEIJCCAMZACkiIQAACEIAABCAAAQhAoB0JYAy0Y61SJghAAAIQgAAEIAABCKQggDGQ AhIiEIAABCAAAQhAAAIQaEcCGAPtWKuUCQIQgAAEIAABCEAAAikIYAykgIQIBCAAAQhAAAIQgAAE 2pEAxkA71iplggAEIAABCEAAAhCAQAoCGAMpICECAQhAAAIQgAAEIACBdiTQsWjRor52LBhlggAE IAABCEAAAhCAAAQKE+joC1whkd7eXuvq6iokkhi2ePFimzp1amJ4oYBK8m3FuLAq1Bpyw2CVy6PQ E6wK0ckNg1Uuj0JPsCpEJzcMVrk8Cj3BqhCd3DBY5fIo9ASrQnR2hTFNqDgjJCAAAQhAAAIQgAAE INCWBDAG2rJaKRQEIAABCEAAAhCAAASKE8AYKM4ICQhAAAIQgAAEIAABCLQlAYyBtqxWCgUBCEAA AhCAAAQgAIHiBDAGijNCAgIQgAAEIAABCEAAAm1JAGOgLauVQkEAAhCAAAQgAAEIQKA4AYyB4oyQ gAAEIAABCEAAAhCAQFsSwBhoy2qlUBCAAAQgAAEIQAACEChOAGOgOCMkIAABCEAAAhCAAAQg0JYE MAbaslopFAQgAAEIQAACEIAABIoTwBgozggJCEAAAhCAAAQgAAEItCUBjIG2rFYKBQEIQAACEIAA BCAAgeIEMAaKM0ICAhCAAAQgAAEIQAACbUmgo6enp69WJQvStu7u7lol31bpwip9dcIKVukJpJek XcEqPYH0krQrWKUnkF6SdgWr9ASKS3Z2dXUVlOrt7bViMkkJqLGWG7eSfFsxLqySWlG+P6zymST5 wCqJTL4/rPKZJPnAKolMvj+s8pkk+cAqiUy+P6zymST5wCqJzG5/pgntZsEdBCAAAQhAAAIQgAAE MkUAYyBT1U1ha0Fg0aJFduWVV9oDDzxQi+RLSnPp0qVOF+nTLE66XHfddXnq3HHHHU7Xn/70py4s SS4vYoyH2Cv+66+/HhOa6+Vlm6G+cjWr/KkZ2mI16lHlwEEAAhCAQH0IVN0Y0A/sySef7P7+6I/+ yN7//vebrp/+9Kft7//+723u3Ln1KRm5QKBOBNRxueKKK6wZOpe/+c1vnC5/8Ad/UKfSF89GbKLG wGWXXWYf/vCHna7f+MY3XCJxcsVT3yUh9oqf1hiQbDPUV9rypZVrhrZYjXrEGEhb48hBAAIQqJxA Z+VJ5Kdw//3326xZs2znzp22ZcsWe/PNN93fs88+a1/+8pft2GOPtSeeeCI/Yhv4fOYzn7E99tjD Lr/88jYoDUWIElAbPuqoo6yvb/e6+yOPPNLU5qdNmxYVr/uzPlf77ruvnXDCCXXPOylDsQlvJKD5 m//xH/9hU6dONfH0YVG5pPTwbx4CY8aMsZ/85Cc2e/bsfqWox34U3EAAAhBoCQI1MQZUcv04XHzx xe4H35NYt26dfe9737O//uu/tgsuuMBuuukmH9Q21+eff94ZQm1TIAqSQ0Cd16hTZzbcGYqG1/NZ IwMaFSh34X4tdI2y8W99NTLgDQHl6+W0AQCu+QmoHmXYRZ2vx6g/zxCAAAQg0JwEamYMdHR0mP/z RR89erT91V/9lf3oRz+ym2++2b761a+6t6kartf0Ib1Nv+uuu+zf/u3fbPv27fbggw/6qG4+sOZD L1iwwHW2Dz/8cPvIRz7SH+5vXnzxRfvv//5vW7NmjS1evNhOP/109/eud73Li/RfNbdVab766qv2 vve9z5SmpjiFnWTkNNKxdetW+93vfmePPvqoTZgwwXW6LrroIhcuOY2CeGPAxys2QnDrrbfar3/9 a/eG9OCDD7ZjjjnGzjvvPDe64BIu8I+G4+XENOp8mL8q/IUXXrBbbrnFjdKIjX601XFU2aNO8d56 6y3H8KCDDrKjjz7azj//fBsyZEi/qOpPz5oC9vOf/9yuv/56l2ahMqvzILnbbrvNOjs7XWdQnULP sT/x4EadDcn66RzSV/WgN99hlyQn+ai78cYb7Ze//GV/J8bnHe6U+vYondT511ts3b/88sv22GOP uSTD9evzl27hPH1ZlYba7fjx41345z73uRy1NIVG9SFumj+vMiuuRhokGy1vTuTQw7x580zGwL/8 y7+EfHNvNSVHne2kOlK59MZehrx30kd6+Y5fIWZKV/Lf/e537U//9E9dOuE0PVul/dxzz7nPtc/P y4U/156hX1fgDS/VR7jOvK66Kg/VmeJKRrLSuZh74403THy8wSf+Z599dqq4Pm3lrfKrTWjESPWn dLwL17XKK/l//Md/tJkzZzoRxZPuYR2kf7hd+bQk853vfMd9rlXOaLvycrrGcdQUzr/4i78Ii7np XL4thjn6tqgyyenzq/Ymp/Lq+1t6Ss7XY7gNhfPXd7s+C74duUT4BwIQgAAEGkcgmO5Q0AVf4gXD o4HBELHmT/QFnYK+4IctGuyeFSYZycrpGhgOfY888oi7Kiz4cXRh+if4kXH+wQ9in/6CaRru+bTT TusLOmj9ct/61rf69tlnn77grWhf8CPeF3Sq+yZPntw3YMCAvqCD1C8Xl2bQCXdpBsZATppBp9j5 S8fhw4e7/D/+8Y/3jRo1yvkHP+4uXcmdeOKJrlxeT/kluVdeeaUvMFT65YM51E5flT2Y4pEULcdf +Ug+ro7kr3DvxGbvvffuCwyyvqAT0Pfnf/7nfcEPt4sf1fMTn/hEv16+LEpvxowZfYFB4ZPs+9u/ /VsnF3Qa3FUy0bT6hYObwEDrCzoTTvaMM85wbeSII45wz/IPux/84AfOP+go9gWdHPene+XxyU9+ sl+0kJzihV3QOclJM+i8u+egI9X3zDPP9Iv69umvak///u//7sqve+mguPqTU9uQn+S9W7hwYT9f yV166aV9SWVVuI+vMqrtej/pFhigPtmC12uvvdalE0wV6peLfgbFRHkFUzv6ZfyN/BTmuQWdwv76 ku76HIbLoPr0zrMSJ6Whz53noWeVR0715cumsure5+flfHsOtxfJKb1w/i7Bd/5RmOKLs09HHH19 KV/vvKyu3qn+9dlQXMVTWX17U7sp5qSzb1/SUWn4+OG8fdm9DpKZM2eOS146qL7T6ODrSjorL5+f 9Fb8cNnCbVG6iXcSR6+f6tF/j3o/6aa05PQZ9OVTWpLxnyHP3wkG/4TrUXrqeyMpf89Fn6k459tG XFgxv0bFjX4Gi+kZDm+Uzo3KF1bh2i98D6vCfMKhsArTiL+3eO/dvqV+KYQ7RkkVoE7o2LFj+zPx cf71X//V/Yjt2LGjb/Xq1S7861//uvtxU8feu2C6UZ86z/rRCd6Ke2/X+dWP45133tnvp7SCt9qu gx28tXf+wchEXpqSC0Yk8tJU51b5BKMGffeHfqCC0QHnf+aZZ/bnpXyjP8T9gZEb6S3Z4E29C/Gs fIciXIZI1P7HUowByerHPVwGJaQf5fe85z19ns3//M//OL3e+9739m3YsKE/LxkT0leGkHfeGPjQ hz7Up/BizncUdQ23K9+BCXdQ1bmQvuEOp9JXZ0J6eP+0cuqQKV6wmD1HTfGQf9hw8h0StdNwR046 Kz/Jh51PI9wBC956Ojkf35fXl1UMvPNpqi58uRTmeX3lK1/xogWvf/Znf9YXrMfJkfHtynuqwyb9 pUfUed18h8/Xr++se3nPMpyGZ6YOovLw5VUc5acyhp38wrwU5uV8XJ9PVM7n5dkqrvfT5993SuWv sqgdqSPrnZfV1TtvGIfjKsy3t+jnxsfzV88qXK8K851ezzRc1z4vX17pIF29v+KrPcTp4GUfeugh iTnnyxpl6+OHeSlCnM5eP9VjXFv0bUHtynOMsvH1uEur3e3Ys/Hl9e0t/LlPStOn5eP651KujYob /Qy2gs6wSl9LsIJVEoFGtY1y8h0QfHHXzc2fP98NSwdfjm7qTjTjxx9/3ILOtwVv8t2fpuVo2D74 IXfTW7z8yJEj3dD6XnvtZZr24Z3SDTr1tnnzZu/l0nnqqafc9A5Nw5G74YYb8tJUnv/n//wft7hZ 4VF34IEHWtBh7PfW9BotFH766af7/TQtKq374he/6KYUKY2wC34g3eNLL70U9q74ftmyZW56yNtv v52Tlob3NfUlzEYCwQ+3BSMh/bKf+tSnLDAaLDAW3LSq/oDgRuwUXsxpWkDQcbDA4MkR9c9+aoQC g8bsppnlCAYPmi6ielabkCskF3xA++U0PUNOU5vCTnUadHDcdA2lFXZBRy5P13B40r30k55Bxyov vt85R1Mrok5t35dLYX5qS/DmOCqa97xt2za3KL/YLkKa5hF09Ezbekad/FTmoKPpgvQ5CDqn7jMY llV9SS4uDfH0U0nCccq5V1pqL9p5KOzkLyfOURcY5zn5qyziqLrVtJc4p3antD760Y/mxJWsbzf+ Ghdfft/+9rcdq6iuqu+gg+vyD8cVwzAn6SYdov5qDz5vP1XK66tyHXbYYf3JqqyKH3Yqt6/XaFhg DLi2kKYt+nKFP6PhfArdl/K5L5QOYRCAAAQgUBsCnbVJ1tw8eK0LUCdl/fr1FrxldlflF7xddvNi o3lPnz49x0sdWG0VqB/NuB/yc845x4I30rZq1SobN26c+9G95JJL7G/+5m/cmgHNv9dc92gnPZii 4+Zhx6V5/PHHm4wHn6ZXSPNro+6QQw6J1SsqF/csI0B/mjcvg0a7wKjj5Z0WW1fTXXPNNXbSSSe5 ef/BaIvr2Md1HMVGnf6NGzfmlU3yMtiWLFli+++/f7960XrrD4jcqLOiP3V6ZBg++eSTTkLPUacO hOYeq/7UWQ/ebrq45crJ6FHemuccvEHNScYvWFVHx3c0JRDurOVEKPLgyxNOy0dR504d6bhOVVRe +qZ1qhetZ/n85z9fNIo6dlpnos6lOMvpXh1HdVy98589sYs6rWPQnH+VNaxntAzReKU8K139KQ/l 5T+vek5yMgaizuuXFM+nq++JuLIqvaS4ClNdqg3J+Is68YhjEm1bXgftzpOkg28z3mj15Qrnqby0 5sA7H0c7YEXT1Xey8vMyPo6ucTqHw0u5l576E0PVo9bsaK2RnnEQgAAEINB4AjUzBrQQVwvR9HZf b6P1Y6C3WFqMeuqpp8aWfPDgwTn+2pJUTj9W6sgmORkNMgb05mvt2rUWTLGxYE68E3/3u9/tFhpr oVwwj9n5qZOj0YM0afo84xYg+7ByritXrrQvfelLFszztqFDh1qwBsGVIfxmuJx0k+Lox11vANXp 025OcgcccICdcsopFkzz6R+pERsZBIXYRPMYNmxY1Cv2WfWovH3Hxy9c9p2bcCS9JZfTW1F1XPUn Nuq8amGq3m7LFZLTuRZqd96p83HWWWf5x/6rRhDiXLTDFicT51esk5NUx0n+cXlE/WQMBFNkTMZs MSeGccaA4vm3x76Okj57npnKGmYcvi+mR7HwaHvRAn8ximsvPq1CDJPqxaenRbE//vGPfVI5V32X JTkfPym8FH8ZwPor5HzdxMkklV+fo7gRAF+P0bRqWY/B2iMbOHBgwXqM6sMzBCAAAQjUjkDNjAGp rI6a77SVUwRNB5JTR1Y77qRxn/3sZ92uFitWrLC7777b/f3zP/+z6U37N7/5TZeE3sDrzfbvf//7 vCT1hi/8hj5PoEoeejurXZX+8i//0umlzoZY6Ye+lI54KepceOGFpj/tbOPZXH311S5P7bokp7Jr p6Q4NqXkFSerkRy9ldfIhEZwPGeVWcZj1Kn96E21OoX6U2cmmPfsRlH8TiaKkySnOL/97W/7k1UH J5iP3Z9vf8A7N9ERpKSOVTRe9LmaHalo2knPfktRGXjFnPTTW2w/zUedWbHV6Isvsy+D5DRVJ8lF mSXJleMvw1F5q734aSpKJ6m9FMujmHGnEShNjyvVlfMWPUkXbb3sDbJS9SgkH1e2en3XhT/3qkef b7n1WKichEEAAhCAQOkEBpQepX4xgt1v+jNTp6PQX7/gOzfqFMkw0FaaGpL+z//8TzdlScFTpkwx bSNYKL1adnKCxdHOEAgWUfcbKF5/jWyU6jQyEnZ+bnHYL3yvUQ4ZIZrGpcOptB3rPffc40TERtOA qu3U4ZQhoM6l3kqH2Rd66yo5TXGQ8aCOoTqs2r5VHYmwi5NTx9/LydDSm+FwvtH7cHrVuE96E63p GpUYyVHdNPImYyDNqICPqw6n6kR8fHsJd0K9MaCOW5RT+NmnV4ur6ltTqkppL4WMWG/oRHX1HXO9 MAiXLXofjRd+1qhjXDsWY9V3tC3IUA07z1tpRPMNPytOIePDt3efti+z8gunE7338tW+lvu5r7Ye pAcBCEAAAskEOvVjX8ylkfFpaB6qnPbcl0sT18fR1J2wvObTa0qDOivBtqN26KGHujT9P9r3XtM+ 9KfpNpp6o2lBwbZ3OekoDXV8tRZAC2W1p7fmq2tubbgDpHQ1BUUnJGuvf+2F7cshHcO6SVb7ZctF /RUn6ucE3/lH03DkNC0qLKf7YOcYF6bzD8JhzjPyz3777ec6c1pvEDacVFY56ac07rvvPrv33ntN C65lIIVdsD2r60iqEyLZYMtP+4d/+AdnpPjFzF7eszn33HNzzkEoVl7F90aO10l+yk9/erMv59PR VCVNoQp2/rHoHHBNM9MbbdWHOn5p5JRHsDuS66xpUewf//Efu/z8P1r8qc6R33Pd17mm3sgQCTtf 58pbhpOcb79ef8VR51DtVmXxIyDSQ+cxyEkfPcv5NP2z84z8UyhMo2YybrWGJU4uzs+PxMhYlo6a YqQRqbCs2oLO/ZDOfh98r5a4a7qHrx/PLPw5CacVrnefhufln3WNstAp5uF0dO/bi0b/fJjPX/oG 24uGk7Tbb7/dlU+fF8l7WZ+/1qXIySD26fkExOZrX/uaaxvhxbo+3F/FR2t/Hn744ZxFveKk0Tct vNf8fF++MCelofVNchr5kvETdtJBaejzIB00JVJO5ZJsWGf5yfmyaW2H2qIMknCbdULBPzojJFyP Xr9wml5W13A9eo7RsoTl4j73CleZfD16XeVfKE2FyyXptiu08L/ELcwnHAqrMI3C97AqzCccCqsw jcL3dWUVzBkt6II3OwXDo4HB2zxNwO4LpncknjNQKI4P8/n6LTyDjnlfMM3HBQc/+C595RMMqzu/ YNqIyzeYWtQX7ODRF3S4++TntyYNOkp9waJYJ6t92xVXf5IN3qz3SW/pLD/twe9d8IPl/BQedcEb Ohfm/YNDutxZBMrrF7/4RZ+2So1zmzZt6pOM8goW9joRbc2pLT5/+MMfOn+FBZ3UuOj9ftqWVHI6 r0D6aevA4A2jO0dA/tLPO52jID/x0DaiYTbBSEFfsGDaiUq3oDPrZMUjeJvv0o5j47cmFKM0Lngb 7tIVc+2tHsxjdnn5tKW731Yx6ED3BZ0nd26B/KSH5IM3ne6MB7/tYSE5hXk5xdez4it/pRm8RXXp B4ZA/173KofXR9ewU5v0YcF0Bxdf6Yu92IblVRfyE8vAKOjTFpDSX2WSHtLHu2C0xMn65/BVaeh8 h0Iu6HD2BZ2+vqBznCcWvJHO8/Me2tpRzJVHMI3Ee/dfg0P/nK7SWbpLZzELDgXLK6/nIhZy/vOr e6WvMoad/MK8FOblfNxgVMD5qb6Ublx7kU6qA59/0PF1+klP1XEwouTSUFm987Lh/L2fry/FVb3p OVpfPp3wNVgYm8PKty2VSeXwzufjOcnfl1d1IPnAKHOcC+ng20zwIsTJSlfVi2cWLltgILh0w2WT fv5clPDWnj7dsH5ed18/ela78mcd6HtG6aku5MJyeg5/7pWuvteki2cR/tx7v7j8lZZnpftSXaPi FvoMFitDo3RuVL6wKtYidofDajeLYnewKkYo+N4uJlLql4K+xPVjoC/1tBUQjuP1Ceerzrv2yg4W qrq0lb46t74j7ePoADIdOiTDQTL+L3iT3b+PvpfVj7f2x1fn0MsFowZu720vo2spxoB09j9mSjPc GQ+nqXt1yHVoms974sSJLq7Cgt2Q3DkMCivmdPiPT0PXYMcfd2ia7sP5B1NJ3NkMOngsLC9DQsZV 2Mkg+MxnPuMOcPOyMl6inf5SjYFg/r7rGKjzrT+x93uP+46Q/OV0zoTq3Mv6qzorwZvqfnULySm/ sNOzOtY+LV2lg+os7HwdRv1Vv+rw+M6N4qvtxrVfpff973/fdRDD+Un/qF6+AxbWwd+LfzFjIHjL 3/exj33MR8m5FvoM+s6c8lDHM+pUXukq/cJlUPllVIadZyYWcuHPr9JXGmEnvyhfL+fjKm91bn3e 4bry+fk68M86JyOsr9IMGwLSwcvqGnZqg+r4+/x0Vf7R+grH8feeldiE46sN+zNTJOvz9pzk58vr w6M6qDxRHZSm/FU+n5+eg1Ei5xctmwyCqG4ynOQfdj5Nb0SHw3z9yM+3Ky8vHXyeYTnJSvdw3ipf 0uc+jo/S8C7MyvulvTYqrmeVVs+wXKN0blS+sArXfuF7WBXmEw6FVZhG/L3reQVf3olOwxTBl3di eDQgyKbfS0PBwY9A/3PSTThO8KPixOLy1RCy9sTX0LemaHjZaLrLly93Q8kaotbUAM3NL+SCjlD/ NALFCZc3Tjeflg/zenidVW5NWZo0aZJbjOvl467aYlND71rXkHaLzmg6WhAc/Hi7svopBFGZ8HPw wXA7PGnKlPIOlzcsp3ttV6mF3OIYdb68Uf9Cz2Km/DWtRVMrPDvFifKUn8rl51cHbxBNf3HtKk4u nLbSkgt+5Fw+StOnFycnXaL+vrwK8/E19UMuTt77S1bTvgKDyuUZTTeu3C7Rd9JVvkFH2HvlXAMD 2PyakcD4ywnTg6Z/FfoMFso7XF7Vmf7SMvNxpUNcHnG8vFz4Myg/n7fKF2bn5b2fnhVXU55Uz+Ie jSN95CTr4+3y2cVK3yuKp/haSyDuUTkvH7768hbS18tH8/Zxw+FeB1+ncTooHU390TbIYV2j6YfT 9SwlrzSj7Upx5ZLy82G+XUleacrpe1kuLg0vJ66SC+cblddzXP5KO8pKfmldo+J6Vmn1DMs1SudG 5QurcO0XvodVYT7hUFiFacTfV303oaQv8fjsd/mmjaMOs/9xLJSetuoM3rQXEskJC4asc57DD4V0 SwpTh8LPJw+nFXfvD/tSYy3X6byCUrY+9R065acv/UJO2zlW04mZOgMy0KL8os/KV53tNLsrpZVT HuqIFEszThfPQWHRNpMk72VlTCUZXUlxlZ/CCoXrMDz9lesKpe3TlIzqTH+FXFJacf6l+CXlHU3D P+tarD142Wh55B+t26hMoWfFT9LXx0vKOxyeRgelI0Mv+hlNSl/+Yd3iPvtJcaVbXJhP0+ueRi6a bzTd6HM4be4hAAEIQKD6BJp6N6HqF5cUIQABCEAAAhCAAAQgAAFPAGPAk+AKAQhAAAIQgAAEIACB jBHAGMhYhVNcCEAAAhCAAAQgAAEIeAIYA54EVwhAAAIQgAAEIAABCGSMAMZAxiqc4kIAAhCAAAQg AAEIQMATwBjwJLhCAAIQgAAEIAABCEAgYwQwBjJW4RQXAhCAAAQgAAEIQAACngDGgCfBFQIQgAAE IAABCEAAAhkjgDGQsQqnuBCAAAQgAAEIQAACEPAEMAY8Ca4QgAAEIAABCEAAAhDIGIGOnp6evlqV OUjburu7a5V8W6ULq/TVCStYpSeQXpJ2Bav0BNJL0q5glZ5AeknaFazSEygu2dnV1VVQqre314rJ JCWgxlpu3ErybcW4sEpqRfn+sMpnkuQDqyQy+f6wymeS5AOrJDL5/rDKZ5LkA6skMvn+sMpnkuQD qyQyu/2ZJrSbBXcQgAAEIAABCEAAAhDIFAGMgUxVN4WFAAQgAAEIQAACEIDAbgIYA7tZcAcBCEAA AhCAAAQgAIFMEejMVGkpLAQgAIEME9ixY4dt2bLFdF2/fr0NHjzYhgwZYgMG8F4ow82CokMAAhkn gDGQ8QZA8SEAgfYmsGnTJluyZIktX77ctLmCnrdv326bN2+2UaNG2fDhw23s2LG29957u7/OTn4W 2rtFUDoIQAACuQT41s/lwRMEIACBliegzv6aNWvslVdesZdffrnfGNBowM6dO62vr89dBw4c6EYF xowZ4wyBqVOn2vTp023atGnOUGDEoOWbAgWAAAQgUJQAxkBRRAhAAAIQaB0Cb7/9tr300kv2/PPP 2/z5850hUEz7tWvX2uLFi+2pp56yd73rXXbwwQe7vwMOOMBGjhxZLDrhEIAABCDQwgQwBlq48lAd AhCAgCegN/6vvvqqPfjggzZv3jx78803bevWrT441XXbtm324osvOsNAhsTRRx9tM2fOtIkTJ6aK jxAEIAABCLQeAYyB1qszNIYABCCQQ0DTgtSJv+OOO+yFF16wjRs35oSX8qApRIqv9GRQrFy50s46 6yw3jaijo6OUpJCFAAQgAIEWIIAx0AKVhIoQgAAEkghod6Bnn33W7r77bvv973/v1gMkyZbiL6NA J3fOnTvXNGLw/ve/300hwiAohSKyEIAABJqfAPvJNX8doSEEIACBWAKaGvS73/3OfvrTn1bVEAhn pl2HHnroITfqoHUFOAhAAAIQaC8CGAPtVZ+UBgIQyBCBZcuW2Z133mkLFiyo2ohAHD6NDDz99NP2 i1/8wm1PGieDHwQgAAEItCYBjIHWrDe0hgAEMk5AZwbce++9bo2ADhGrtdN0pMcff9wtUK5HfrUu D+lDAAIQgMAuAh3BnNC+WsHQfNPu7u5aJd9W6cIqfXXCClbpCaSXbKV2pQXD9913n5u6o0PE6um0 s9A555xjxx9/fD2zbdm8WqldNRoyrNLXAKxglZ5AccnOrq6uglJ6+1RMJikBNdZy41aSbyvGhVVS K8r3h1U+kyQfWCWRyfdvJVbaQvSRRx5xpwnnl6S2PitWrLCHH37YTjjhBBs9enTJmbXi93MlOrdS u/KVWUl5K4kLK18Dxa+wKs7IS8DKk0i+Mk0omQ0hEIAABJqOgM4O0HSdt956qyG6aZchGSM61Ez3 OAhAAAIQaG0CGAOtXX9oDwEIZIzAmjVr3EnBWtTbKKepSTJI6j1FqVHlJV8IQAAC7UwAY6Cda5ey QQACbUdAW4kuXbq0oeXSiIBOKG7U6ERDC0/mEIAABNqMAMZAm1UoxYEABNqXgEYDdAiYFhA32q1e vdqeeeaZRqtB/hCAAAQgUCEBjIEKARIdAhCAQL0IaERA8/WbwWl0QIuYm8EwaQYe6AABCECgVQlg DLRqzaE3BCCQOQLPPvusab//ZnFLliwxHXyGgwAEIACB1iWAMdC6dYfmEIBAhgjs3LnT7eDTTEXW 4WNaO4CDAAQgAIHWJYAx0Lp1h+YQgECGCGzYsMGWL1/edCV++eWXm04nFIIABCAAgfQEMAbSs0IS AhCAQMMI6OCczZs3Nyz/pIy1jkGjFjgIQAACEGhNAhgDrVlvaA0BCGSMwLp166yRZwsk4daIRTMa KUn64g8BCEAAArkEMAZyefAEAQhAoCkJ6IAvzdFvNiedOHys2WoFfSAAAQikJ4AxkJ4VkhCAAAQa RmDr1q2m7TybzUkn6YaDAAQgAIHWJIAx0Jr1htYQgEAGCTSjMaD1AqwZyGBjpMgQgEDbEOhYtGhR 871qahu8FAQCEIBAdQjMmzfPbrjhhqabkjN27Fj71Kc+ZePGjatOQUkFAhCAAATqSqBz6tSpBTPs 7e21rq6ugjJJgYsXL7Zi6SfFrSTfVowLq6SWkO8Pq3wmST6wSiKT79/srPS9NmjQoKYzBgYPHmz7 7befdXd350ON8WnF7+dKdG72dhVTRVZJeSuJC6u42oj3g1U8lzhfWMVRyfVjmlAuD54gAAEINCWB ESNGWGdnZ9PpNmTIEBs+fHjT6YVCEIAABCCQjgDGQDpOSEEAAhBoKAGN0GpkoNncmDFjmlKvZuOE PhCAAASalQDGQLPWDHpBAAIQCBEYPXq0jRo1KuTTHLeTJ0+2jo6O5lAGLSAAAQhAoGQCGAMlIyMC BCAAgfoT0Nz8KVOm1D/jIjkecMABRSQIhgAEIACBZiaAMdDMtYNuEIAABEIEDj300NBT4281bQlj oPH1gAYQgAAEKiGAMVAJPeJCAAIQqCOBQw45xDRC0Cxu0qRJNn78+GZRBz0gAAEIQKAMAhgDZUAj CgQgAIFGEFDH+13velcjso7N85hjjrGBAwfGhuEJAQhAAAKtQQBjoDXqCS0hAAEIuIW6M2fOtAED Gv/Vre1EDz/8cGoFAhCAAARanEDjf1FaHCDqQwACEKgnAU0V0qm/jXZazLz33ns3Wg3yhwAEIACB CglgDFQIkOgQgAAE6klg3LhxdtBBBzV0O09NDTr44INt5MiR9Sw6eUEAAhCAQA0IYAzUACpJQgAC EKgVgaFDh9qRRx5pujbKaYrQEUcc0VSLmRvFgnwhAAEItDoBjIFWr0H0hwAEMkVA6wUOO+ww22ef fRpW7mnTptl+++3XsPzJGAIQgAAEqkcAY6B6LEkJAhCAQF0IaFeh2bNnm/b5r7cbMWKEnXDCCaYr DgIQgAAEWp9AR09PT1+tihGkbd3d3bVKvq3ShVX66oQVrNITSC/ZzO1q+/bttnXrVtP0HO/Wrl1r 1157rc2bN8971fza0dFhM2bMsA9+8IM2YcIEl9+OHTts3bp1Nnr06KbY5ajmEErMoJnbVYlFqbk4 rNIjhhWs0hMoLtnZ1dVVUKq3t9eKySQloMZabtxK8m3FuLBKakX5/rDKZ5LkA6skMvn+zchq27Zt tnz5cnvyySfdi5X3ve99/fv667v1lFNOsaVLl9qaNWvyC1QDn4kTJ9qZZ57p1gr47/YVK1bYr371 KzdtSGsZ9AKo0Nanrfj9XInOzdiuijWNSspbSVxYFauZ3eGw2s2i2B2sihEy6ywuggQEIAABCNSb wNtvv23PP/+8Pfvss/bUU0/Z1KlT3VqB8Im/06dPd1N27r33XtPoQS2dTj7WqIDWC7z11lsuq76+ Pnv00UftnnvuMe1ytHjxYjvqqKPcbkeNXOBcSw6kDQEIQKDdCLBmoN1qlPJAAAItTUAd7FdffdXu uOMO+8lPfmKPPPKIbdy40RYuXGhPPPFETtnU4dboQD0W82o7U41MDBkypF8Hdf7vu+8+Z4hoBENG wY9//GN31RtiHAQgAAEIND8BjIHmryM0hAAEMkJA04K0BuC2226zX//617ZkyRLTnHy5zZs3u072 smXL+mloDr/e1J999tm2xx579PtX+2bPPfe0D3/4wzk7GG3YsMHuvvtue/PNN/uz27Jli73wwgvO kPnZz37mwmTc4CAAAQhAoHkJYAw0b92gGQQgkCECWiCsN/96s65pQer8R93rr79uv/jFL2z9+vX9 QToA7LjjjrMzzjjDwlOI+gUqvNFCYa0TOPzww/vXAshA0fSl3/zmN7Zz586cHPSsNQwyFO688043 opEjwAMEIAABCDQVAYyBpqoOlIEABLJIQCMCDz/8sJsWpHUCfjQgjoWmDf32t7/Nkens7LSTTjrJ 3v/+97tdfeLileOnHYKUpqYHhRcFa9Fw1CiJpi9j5qGHHnJlWrBgQTSYZwhAAAIQaBICGANNUhGo AQEIZJOADIGnn37aTa3RuoBChoAIaS7+L3/5S3vjjTdygI0aNcqtH9Bb/LFjx5qmEJXrFHfMmDF2 1lln2cknn2xK2zvtzPHAAw/YSy+9lDcq4GX8VVOJNNqhtQ+a8sSUIU+GKwQgAIHmIYAx0Dx1gSYQ gEAGCahTrcXC6tyn6SxrGs7LL7/spuD4XX2ETR14bet5+umn24c+9CE78MADTSMGpTrFOeCAA1wa SstvIap0Vq1a5QyRZ555JvXuRd7Yueuuu1z8UvVBHgIQgAAEakug9F+K2upD6hCAAAQyQ0Bvy/WW X9No0hgCHoxGD7SlpzcAtP+/dyNHjrRTTz3V9tprLzfioFEHdeLTOI0GHHPMMXbsscfaoYcemnPI mdYpaAtT6asOfilO6yEee+wxd2rxBz7wgVKiIgsBCEAAAjUmgDFQY8AkDwEIQCCOgKb7zJkzx+2+ U2xqUFx8zclXB1unEutE4PDi4WHDhrn9/rXTkLYdnT9/vjM4lKfy0uiCjA+tA9BIwIgRI+xd73qX MwB0ToDODPCjCpLTacfaNlTGQLlbhioNxVfap512Wv/haXFlww8CEIAABOpHAGOgfqzJCQIQgIAj oAPCtBOP3u6XYwh4jDp/QPP35bTIVweT+U68rtpu9A//8A/dYWUafdC0InXKtQWojAmtBdAiYclp atDee++d00mX0aDRC+mpEQHFrcR5o0J57b///hWta6hED+JCAAIQgMBuAhgDu1lwBwEIQKAuBNQp 12Fd6sxX6tatW+fS0onFM2fOdNN8wgeD6e2/pgzpb9OmTaZFvZrmo465FhprZEF/0QXHMli0a5EM AV3D25lWovPSpUvdGQoyPJQvDgIQgAAEGksAY6Cx/MkdAhDIGAGNBMgQ0M5BpawTKIRJRoXOJtAp wDoETPP+dVCYjIJwJ1/Th/Qnp454eHGwT1+jBjIsZABou1OdbaA5/9VyMjK0w5DWJRx99NHVSpZ0 IAABCECgTAIYA2WCIxoEIACBcgjohN65c+em3o0nbR7qZMvAkEHw2muv2bvf/W7TmgFNAdIuQ+HR gmiamg6ktQAyAhYtWuTWGGjHII061MKtXr3anVOgdQqapoSDAAQgAIHGEegI9oyu2Vnx2o9aP0K4 4gRgVZyRl4CVJ1H8CqvijLxEPVhpms7111/v1gv4fGtx1dQgffdqlyGNEGjRrv7U8daIwKBBg1y2 GgVQh1+7Da1cudKWLVvmRhb0XMlahjRlkg5/8id/YrNmzUoj3rIy9WhXLQsnojisIkAKPMKqAJxI EKwiQGIeO+OGicNyeltUTCYsH75XBZQbt5J8WzEurMItp/A9rArzCYfCKkyj8H09WGnKjc4IqLXT m369fV+zZo0bJVDHW4aAvo+19aieNfVHclo7oM6/FhTLOJBfPZzWLWgRtdY5aO1CGsd3expKu2Rg BaskAq3YNirRuR7f7XGsK9G53nGZJhRXg/hBAAIQqDIBdb41r7/SHXlKUUtrEtTB158WAOvNfzM5 GUfa9nTGjBk5axuaSUd0gQAEINDuBDiBuN1rmPJBAAJNQUBven73u9/VfPpNUxQ2pRKaNqW1CRqV wEEAAhCAQGMIYAw0hju5QgACGSPwyiuvNN2b+UZXgaYkaWRAU5pwEIAABCDQGAIYA43hTq4QgECG CKjT+9BDD7n9/TNU7FRF1Q5Gzz//fCpZhCAAAQhAoPoEMAaqz5QUIQABCOQQ0E498+bNy/HjYRcB byjVa+Ey3CEAAQhAIJcAxkAuD54gAAEIVJ2ADAGd/IuLJ6ApVDqVGQcBCEAAAvUngDFQf+bkCAEI ZIiA9uvXIllcMgHttASjZD6EQAACEKglAYyBWtIlbQhAIPMEtJXo4sWLM8+hGIDnnnuOnZaKQSIc AhCAQA0IYAzUACpJQgACEPAEli9f7vb4989c4wksXbrUtP0qDgIQgAAE6ksAY6C+vMkNAhDIGIE3 33yTffRT1PnGjRtZN5CCEyIQgAAEqk0AY6DaREkPAhCAwDsEdAKwts7UnHhcYQI6eEyjKDgIQAAC EKgvAYyB+vImNwhAIEMEtm3bZqtWrTK2zSxe6WIlw0kGFA4CEIAABOpHAGOgfqzJCQIQyBgBdXDX rFmTsVKXV1wZTDqJWMxwEIAABCBQPwIdPT09NXsNE6Rt3d3d9StNC+cEq/SVBytYpSeQXrIW7UoL Yv/jP/7DFi5cmF6RDEseddRR9md/9mc2fPjwtqFQi3bVNnAiBYFVBEiBR1gVgBMJglUESMxjZ1dX V4z3bi/9mBWT2S2de6cKKDduJfm2YlxY5badQk+wKkQnNwxWuTwKPdWCld5yay48Lh0BLSIeNmxY 4u8G3+3pOEoKVrBKItCKbaMSnWvx3Z7ENuxfic71jss0oXDNcQ8BCECgigS2b9/OycMl8Fy3bp2J GQ4CEIAABOpHAGOgfqzJCQIQyBgBnT7MyED6StfIAMZAel5IQgACEKgGAYyBalAkDQhAAAIxBGQM sCA2BkyClwwndl5KgIM3BCAAgRoRwBioEViShQAEIKC33GyVmb4d6DwGGVA4CEAAAhCoHwGMgfqx JicIQCBjBOjYllbhGhWAWWnMkIYABCBQKQGMgUoJEh8CEIAABKpGgGlCVUNJQhCAAARSEcAYSIUJ IQhAAAKlExg0aFDpkTIcQ1OqBgzgZynDTYCiQwACDSDAt24DoJMlBCCQDQKdnZ2mP1w6AgMHDjT9 4SAAAQhAoH4EMAbqx5qcIACBjBGQITBq1KiMlbr84o4cOdIYTSmfHzEhAAEIlEMAY6AcasSBAAQg kILA8OHDbf/997eOjo4U0tkWESOxEjMcBCAAAQjUjwDGQP1YkxMEIJAxAurYnnzyyXbggQdiEBSo exkCBxxwgJ1yyikYAwU4EQQBCECgFgSYzFoLqqQJAQhAICCgaUJHHnmkDRkyxObNm2fLly+39evX m/bT97vmaCvNcufJNyqu9B88eHBZdex11kJhTQnSNKqJEyfaIYccYgcffDBrLMqiSiQIQAAC5RPA GCifHTEhAAEIFCUwdOhQO+qoo1xHd8WKFXnGwIYNG2zEiBFF04kTaFRclWPChAlxKhX18zqHjQGl JYMJBwEIQAAC9SfQ0dPT01erbIO0rbu7u1bJt1W6sEpfnbCCVXoC6SVpV7BKTyC9JO0KVukJpJek XcEqPYHikp1dXV0FpXp7e62YTFICaqzlxq0k31aMC6ukVpTvD6t8Jkk+sEoik+8Pq3wmST6wSiKT 7w+rfCZJPrBKIpPvD6t8Jkk+sEois9ufBcS7WXAHAQhAAAIQgAAEIACBTBHAGMhUdVNYCEAAAhCA AAQgAAEI7CaAMbCbBXcQgAAEIAABCEAAAhDIFAGMgUxVN4WFAAQgAAEIQAACEIDAbgIYA7tZcAcB CEAAAhCAAAQgAIFMEcAYyFR1U1gIQAACEIAABCAAAQjsJoAxsJsFdxCAAAQgAAEIQAACEMgUAYyB TFU3hYUABCAAAQhAAAIQgMBuAhgDu1lwBwEIQAACEIAABCAAgUwRwBjIVHVTWAhAAAIQgAAEIAAB COwmgDGwmwV3EIAABCAAAQhAAAIQyBQBjIFMVTeFhQAEIAABCEAAAhCAwG4CGAO7WXAHAQhAAAIQ gAAEIACBTBHoWLRoUV+mSkxhIQABCEAAAhCAAAQgAAFHoKMvcIVY9Pb2WldXVyGRxLDFixfb1KlT E8MLBVSSbyvGhVWh1pAbBqtcHoWeYFWITm4YrHJ5FHqCVSE6uWGwyuVR6AlWhejkhsEql0ehJ1gV orMrjGlCxRkhAQEIQAACEIAABCAAgbYk0NmWpaJQEIAABFqUwJVXXpmo+axZs2z27NmJ4XEBGvwd OHCgbdmyxQYNGhQngh8EIAABCGSYACMDGa58ig4BCDQfgQceeMDUgY/7K1dbpbV169ZyoxMPAhCA AATamAAjA21cuRQNAhBoTQJ6+19oBGDu3LmmUYJ58+bZfffdZ3//93+fU9B7773Xnn/+eRszZox9 4hOfcGEyBkaMGJEjJ8NDLpxX1O+xxx6zYKMJe/nll+2CCy6w6dOnuzj6R/ksXLjQdu7cafvtt5+d euqpLiychkY6Lr/88v443EAAAhCAQHMRYGSgueoDbSAAAQgUJaDO+//7f//PvvjFL9rTTz9tAwYM sOeee87Fu+uuu+y0006zp556yl577TXXgVeApgnFuZNOOinHWx15GRtyf/VXf2Vnn322/fKXv7QF CxbYu9/9bmdkKEydfHX+ly5dam+99ZbLMzzFSffjxo0z6YODAAQgAIHmJcDIQPPWDZpBAAIZJaDO uO+QhxGE37Dvtddeduedd7rd3i655BK77rrr7N///d/t1ltvta985Sv2hS98wUX9z//8T7vlllvK miakUYFvfetbdt5557m09t9/f1uyZIkzCpSP0vVh0ueb3/xmzijA1Vdf3R8eLgf3EIAABCDQPAQw BpqnLtAEAhCAgCOgOf7FnO+ES05bOHvj4aGHHrIzzjijP/r73vc+d1/OmoF/+qd/cm//NU1I04M+ //nP2/Dhw11eq1atsvnz57sRAp+ZDIU33njDPcqQuP/++30QVwhAAAIQaFICGANNWjGoBQEIZJeA pgHpr5DT/P9t27bliWjKzujRo/v9p0yZ4u7LMQZOOeUUtybhJz/5iV177bW2fft218Hv6elx6wSi RoumFckgkEualuQC+QcCEIAABJqGAMZA01QFikAAAhBIT0Ad8uiCYMU+4ogj7PXXX+9PyI8YFDIG 1q5d229APProozZjxoz++FpToD91/A899FA3EvC5z33OVqxYYYccckjsNCC/gLg/EW4gAAEIQKBp CWAMNG3VoBgEIJBlAkkdaj9ioJPW44wBLfjVLj8zZ850Hfgbb7zRYYwzBpTWCSecYLfddpt98pOf dB399773vf3YNcXof//v/21nnXWW21Fo2LBhdswxx1h3d7czAn74wx/a5MmTTesFtGbhN7/5jVuz 0J8ANxCAAAQg0PQEMAaavopQEAIQyBqB8K484bL7Q8d0lTGw9957h4Pd/f/9v//Xzj//fPd2//TT Tzc9L1++PHEB8WWXXWZz5syxL3/5y3bhhRfmpHfTTTe5HYu0c1FnZ6cbIfj0pz9tixcvtquuusr+ 7u/+zv7oj/7INmzYYEceeaRpwbA3UKQjDgIQgAAEmp8AxkDz1xEaQgACGSKgRbfRufi++B0dHe5W MrqXQSB3xRVXuKv+kb92+lEaUfl+odCNzg7QX1jeB8vYuP766/v18ekpfPz48XbNNdfEhmnEgcXD niJXCEAAAs1NAGOguesH7SAAgQwSCHe644pfLFxxwjLh+7j0ovJRmULxk8KS/KNp8wwBCEAAAo0l 0BEsQiu+h12ZOmqBm+aW4ooTgFVxRl4CVp5E8SusijPyErDyJIpfYVWckZeAlSdR/Aqr4oy8BKw8 ieJXWBVn1NnV1VVQSsPQxWSSElAFlBu3knxbMS6sklpRvj+s8pkk+cAqiUy+P6zymST5wCqJTL4/ rPKZJPnAKolMvj+s8pkk+cAqicxu/wG7b7mDAAQgAAEIQAACEIAABLJEAGMgS7VNWSEAAQhAAAIQ gAAEIBAigDEQgsEtBCAAAQhAAAIQgAAEskQAYyBLtU1ZIQABCEAAAhCAAAQgECKAMRCCwS0EIAAB CEAAAhCAAASyRABjIEu1TVkhAAEIQAACEIAABCAQIoAxEILBLQQgAAEIQAACEIAABLJEAGMgS7VN WSEAAQhAAAIQgAAEIBAigDEQgsEtBCAAAQhAAAIQgAAEskQAYyBLtU1ZIQABCEAAAhCAAAQgECKA MRCCwS0EIAABCEAAAhCAAASyRABjIEu1TVkhAAEIQAACEIAABCAQIoAxEILBLQQgAAEIQAACEIAA BLJEoKOnp6evVgUO0rbu7u5aJd9W6cIqfXXCClbpCaSXpF3BKj2B9JK0K1ilJ5BeknYFq/QEikt2 dnV1FZTq7e21YjJJCaixlhu3knxbMS6sklpRvj+s8pkk+cAqiUy+f5ZYLVq0yMaMGVP293OWWKml VPKbAqv8z1qSD6ySyOT7wyqfSZIPrJLI7PZnmtBuFtxBAAIQyAQBGQM33HBDJspKISEAAQhAoDAB jIHCfAiFAAQg0HYErrzySnv44YfbrlwUCAIQgAAESieAMVA6M2JAAAIQaFkCGhV44IEHGBlo2RpE cQhAAALVJYAxUF2epAYBCECgqQnIGPDuuuuu87dcIQABCEAgowQwBjJa8RQbAhDIJgFNEfJu7ty5 /pYrBCAAAQhklADGQEYrnmJDAALZI+CnCPmSMzLgSXCFAAQgkF0CGAPZrXtKDgEIZIxAeIqQL7rW D+AgAAEIQCC7BDAGslv3lBwCEMgYgeuvvz6vxHF+eUJ4QAACEIBA2xLAGGjbqqVgEIAABHYT0KhA 3LSgOL/dsbiDAAQgAIF2J4Ax0O41TPkgAAEIBATipgh5MEwV8iS4QgACEMgeAYyB7NU5JYYABDJI oNDOQUwVymCDoMgQgAAE3iGAMUBTgAAEIJABAoXe/jNVKAMNgCJCAAIQSCCAMZAABm8IQAAC7UJA hkAhY0DlLBbeLiwoBwQgAAEI5BLo6Onp6cv1qt5TkLZ1d3dXL8E2TglW6SsXVrBKTyC9ZDu3q9df f90efvjhfhhf/epXbcqUKfbHf/zH/X56njlzZv9zoZt2ZlWo3OWEwSo9NVjBKj2B9JK0q+KsOru6 ugpK9fb2WjGZpARUAeXGrSTfVowLq6RWlO8Pq3wmST6wSiKT79/OrA477DDTn3e33HKLbd++3S69 9FLvVdK1nVnFgajkNwVWcUTj/WAVzyXOF1ZxVOL9YBXPJezLNKEwDe4hAAEIQAACEIAABCCQIQIY AxmqbIoKAQhAAAIQgAAEIACBMAGMgTAN7iEAAQhAAAIQgAAEIJAhAhgDGapsigoBCEAAAhCAAAQg AIEwAYyBMA3uIQABCEAAAhCAAAQgkCECGAMZqmyKCgEIQAACEIAABCAAgTABjIEwDe4hAAEIQAAC EIAABCCQIQIYAxmqbIoKAQhAAAIQgAAEIACBMAGMgTAN7iEAAQhAAAIQgAAEIJAhAhgDGapsigoB CEAAAhCAAAQgAIEwAYyBMA3uIQABCEAAAhCAAAQgkCECGAMZqmyKCgEIQAACEIAABCAAgTABjIEw De4hAAEIQAACEIAABCCQIQIdPT09fbUqb5C2dXd31yr5tkoXVumrE1awSk8gvWSW2tVZZ53lwMyZ Myc9oJBklliFil3WLazSY4MVrNITSC9JuyrOqrOrq6ugVG9vrxWTSUpAFVBu3ErybcW4sEpqRfn+ sMpnkuQDqyQy+f5ZYtXZ2Wnbt28v+/s5S6zUUir5TYFV/mctyQdWSWTy/WGVzyTJB1ZJZHb7d+6+ 5Q4CEIAABCAQT+Cuu+4yjSSMGjXKDjnkELvwwgvjBfGFAAQgAIGWIsCagZaqLpSFAAQgUH8CH/vY x+xHP/qRnXzyyTZu3Dj73Oc+Z1u2bKm/IuQIAQhAAAJVJ4AxUHWkJAgBCECgfQjMnz/f7r//fvvo Rz9q5557rn3+85+3ww8/3P7rv/6rfQpJSSAAAQhkmADThDJc+RQdAhCAQDECBx98sK1YsSJHbMeO Hbb//vvn+PEAAQhAAAKtSYCRgdasN7SGAAQg0BACr7zyiq1du9Y+/OEPNyR/MoUABCAAgeoSwBio Lk9SgwAEINC2BJ544gn78z//czvjjDPatowUDAIQgEDWCDBNKGs1TnkhAAEIlEHgtttus09+8pN2 90jU5uQAAEAASURBVN1326RJk8pIgSgQgAAEINCMBDAGmrFW0AkCEIBAExGQIXD++ee7/fa1teji xYubSDtUgQAEIACBSghgDFRCj7gQgAAEMkDgqquusvvuu8+eeuopV9rly5fbwoULbfbs2fbAAw/Y 3Llz7fLLL88ACYoIAQhAoP0IYAy0X51SIghAAAJVI/Db3/7Wdu7caVdeeWV/mps3b7Zhw4Y5Y0Ce 2noUY6AfDzcQgAAEWooAxkBLVRfKQgACEKgvgaOPPtq9/Q/nqmlCU6dOdV5+dCAczj0EIAABCLQO AXYTap26QlMIQAACEIAABCAAAQhUlQDGQFVxkhgEIAABCEAAAhCAAARah0DHokWL+lpHXTSFAAQg AIFKCVxwwQUuiZtuuqnSpIgPAQhAAAItTqDTz/tMKkdvb691dXUlBRf0D88rLSgYE1hJvq0YF1Yx jSDBC1YJYGK8YRUDJcErS6yGDh1q27dv75/3n4Ak0TtLrAShkt8UWCU2o7wAWOUhSfSAVSKavABY 5SHJ82CaUB4SPCAAAQhAAAIQgAAEIJANAhgD2ahnSgkBCEAAAhCAAAQgAIE8AhgDeUjwgAAEIAAB CEAAAhCAQDYIYAxko54pJQQgAAEIQAACEIAABPIIYAzkIcEDAhCAAAQgAAEIQAAC2SCAMZCNeqaU EIAABCAAAQhAAAIQyCOAMZCHBA8IQAACEIAABCAAAQhkgwDGQDbqmVJCAAIQgAAEIAABCEAgjwDG QB4SPCAAAQhAAAIQgAAEIJANAhgD2ahnSgkBCEAAAhCAAAQgAIE8AhgDeUjwgAAEIAABCEAAAhCA QDYIYAxko54pJQQgAAEIQAACEIAABPIIYAzkIcEDAhCAAAQgAAEIQAAC2SDQ0dPT01erogZpW3d3 d62Sb6t0YZW+OmEFq/QE0ktmqV2dddZZDsycOXPSAwpJZolVqNhl3cIqPTZYwSo9gfSStKvirDq7 uroKSvX29loxmaQEVAHlxq0k31aMC6ukVpTvD6t8Jkk+sEoik++fJVadnZ22ffv2sr+fs8RKLaWS 3xRY5X/WknxglUQm3x9W+UySfGCVRGa3P9OEdrPgDgIQgAAEIAABCEAAApkigDGQqeqmsBCAAAQg AAEIQAACENhNAGNgNwvuIAABCEAAAhCAAAQgkCkCnZkqLYWFAAQgAAEIQAACNSawdetWW758ua1c udI2btzo1uj09eXu17JhwwYbMWJEWZoo7YULF5YVt5J86xG3o6PDBg0a5NiMHz/eJkyYUFY5iZSe AMZAelZIQgACEIAABCAAgUQC6vCvWrXKnnjiCXvqqadswYIFziDYvHmzRY0BLeLXYv5ynNIbOnRo OVGdYVJuvpXonDbugAEDXNlkCEyfPt2OO+44O/DAA2306NEmQwFXfQLltcLq60GKEIAABCAAAQhA oKUJrF692m6++Wa7/fbb7dVXX7U1a9a4kYEdO3bkGQMtXdAaKq8Ov4yVYcOG2dixY+3BBx+0M888 0y688MKyd0CrobptkTTGQFtUI4WAAAQgAAEIQKCRBNThv/POO+2qq65yhsCWLVsaqU7L5q0RlG3b trm/tWvX2ltvvWVvvvmm7bXXXnbOOeeYRg5w1SUA0eryJDUIQAACEIAABDJI4I033rBrrrnGXnrp JcMQqF4D0JSo+fPn27e//W1bsWJF9RImpX4CGAP9KLiBAAQgAAEIQAAC5RG455577JlnnjGNEOCq S0DrDR577DGbO3dudRMmNUcAY4CGAAEIQAACEIAABCokMGfOHEYEKmRYKPqmTZvsjjvuKCRCWJkE MAbKBEc0CEAAAhCAAAQg4Ak8/fTT/pZrjQhodABXfQIsIK4+U1KEAAQgAAEIQCBjBLT3f5KbPXu2 6S/s/PagWjB75ZVXhoNy7uPi9vT0WHd3t9uhqNS4leTr40rBK664IkfPUh4KxX3ggQdMf3Fu2bJl cd74VUgAY6BCgESHAAQgAAEIQAACmtee5NShv/zyy3OCe3t73VaZaYyBaNzFixfb1KlTUxkD0bhp 8501a1aizipIoQ59TkFjHqI6hUXEI8kY0GFuuOoT6FSjKObSyCSlQdwkMvn+sMpnkuQDq3wyX/va 15znF77whZxAWOXgKPiQFVa+05KV8vpKp7yeRPErrIoz8hJpWOmNepyc/NT5LeQaFVc7IiXpXEjf NGFx6fp4xXZiKhTXpxG9lhPHp5GFuJ1dXV2+vLFXQSgmExsx8NQwVrlxK8m3FePCKqkV5fvDKpfJ o48+an/9139te+65px155JE5nzlY5bIq9JQlVjrQRwZBud/PWWKlNlPJbwqsCn3qcsPamZVOC45+ 3ny7KmYMxMX1rMqJmzbfIUOGJOqcW3OlP0VZhFNQvoVcobhx8TyruLBifp5VMbm48FaKyzShuBrE DwItRODv/u7v7IILLnDGdwupjaoQgAAEIAABCDQBAYyBJqgEVIBAJQS+/vWv21FHHVXR/M1K8idu 7QjorV+hN38K27lzZ8kKfO9737P169eXFVeZFcq3o6PD9IeDAAQgAIHWIIAx0Br1hJYQSCQgQ0BO HbBCHcfEBAhoKgLr12+wtWt7TXtqb9+hjn7yfOJt27bZoDJP5BwwcKC9smBBWWXfuHGjbUlcyNdh nUHaw4YPs9GjR9vIESPKyoNIEIAABCBQHwIYA/XhTC4QgAAEChKQIbdu3Xp7e+VKZwxs2bK17Df3 BTOqUuCmTZsTUxowYIBp3u/mQKZvj/E2cuSowFhNFCcAAhDIGIGk3YKEQTsl4epLAGOgvrzJDQI1 JcD0jJrirWniO3bssOXBW/41a9a4xb01zazGiWvqkhvZCBYpy8gZNny4Gy2ocbYkDwEItAiBQmcj LFq0qEVK0T5qYgy0T11SEggwTahF24A6z9o+sB0MgXAVaBrTmmBXuT0372kDhg01jRjgIAABCBQa GYBO/QlgDNSfOTlCoKoEol+q/lmH3Dz++ON23XXX5R0cU1UFSKxiAjIGNgZrBEpx4YW69ZqCE7zk d05v+9OuT9lVto02ZOgQwxQopYaRhQAEIFAfAhgD9eFMLhCoGYHoKZAyBtRRlDEgd//992MMOBLN /Y86zWmd6ld7j48dM8YGDR6UNlpV5LZs3uLe9utgoFIMgkC4KvmTCAQgAAEIVJdAyxgDK4K5tIsW LgwW2K0LFtUV/lHZuHGDDR9e3g4WjYr79tsr7OWXXi6rdivReVPAavwee9jkyVNs0uRJbAlYVg00 NpIfCYjT4j3veY997GMfiwvCr0YENBf28ssvr1Hqu5LVoTt7BYfMjRgxvO6fWRkto0ePsjffWh4s dF5b03KSOAQgAAEI1J5A0xsDW4Pt69TZ+U1wyuqCVxa4kyCLvUHbHizE09Z25bhGxdU2fUMGDy5H 5WD7wfLLq0WLXd1dtu+0fe3Y44+3U/7wFBtd5FTqspQkEgQyQkAjNfrTyIz+qm0YDA5GAkaOHOE6 5APL/J6rtCqUr3Y+2hBsMbojWCSMgwAEIACB1iXQ1MaAFp/dctPNdtONN9iCl18xdVyD42xs4MDC M081dF3uriqNiisDp9zFdZXovCNgtTPg+vSTT9kjjzxqS5cssY9ffJF1d3e3bqtGcwg0AQG9xNCf DINp06bZxRdfXBXDYMCAgTaoc1DwPVjeC49qoOns7DT9DQimK+2oRoKkAQEIQAACDSPQ1MbAvb+6 1779rW/ZW2++adPf/W47PnhzPX7cOBtQxBjQrhyaT1uOa1TcnjU91j2mvA54JTpvDPYB3xrM/f3d c8/Zk088Ydd9/wc2fNRIu/Cii9yPfTkMiQMBCOQS0FZ5Mgr0V6lhoJci27Zvcy9HGmUQbA9GA7YF f8VGaXMp8ASB9iYwaNAg00vMOKcXA1Hnf7uLrb2Ji9sT7NKll3blxE2b79y5cy26BaiPGy1LvZ51 fgmu+gSa1hhYGRy88/1rv2vLli61Qw471D572WV2/Akn5Lyx9h+C6CiAtufrDqa6dAzIH0HQj5fk o3E82t7eXtN83HJcJXF1yMbUqVPLydZNnapEZ32ByRj4zrevtgeCxaa33HSTe+N3/Q9/WFAfdQj0 drAcV0ncSr6MKsm3FePCKn3rrBerqGFwwQUX2D/+4z+mVlSdDXdKcbB+akSwf39HR/73XOrEShbc tYvQ2rXrbMOGDc4gKTkJIkCgTQlMnjzZXnvttdjSqUMf16mPFY54tmLcSBGq9jhp0qSqpUVCuwl0 qgNbzKWRSUqj3LjPPfusvfjCfNsZTGM59/zznSGgDrzSU4d+w/r1tjb4MRwUdEa7AuvYW4s66MYv Nt4jWBg7avRop5repsmSXtu71kYGb77VeR48eHCs2uXqrMRaMa46F+8++GD7RDA96PHHHrM3gqlC r7zySqqDj9RBLtcRNz05WLUnK/9m/e6777ZDDzus6Fs+T0HfM1uCEVCNJg4ZXL83ZYEpEJyHsMV9 l2o3oTROL230vazFxn4koxW/J9E5TW3vkskqqxOCF5ZJxkB6ekgWInDccceV1c/KapssxDIc1lns jbIAFpMJJxi+V+e73LgvzH/BDbdpHv3ZH/5w/4iAfljeDKYN3XfvvTbv9/Nc+iedfLIdfewxpq3r HgyGte771a/cG6sjjjzSzgt2Uhk1apS99uqr9tOf/MSWLH7d9pm0j/3haafZ4Ucckfdmu5LyVhK3 ElaV5BuO+wfvfW/AZpLbtUnTlh566KFwdebdh+PmBRbxqCRuI0dRym3PlZS3kriwKtIQQ8HVYpU0 6qisNEVIf1pYfFEwFU/3qt8RI0bYylWrEkcsQ2q6W30Pbg4643rxYdYRDa7ps/LWX1onHsOGDQsW PI9237eVtOdWjNsM3+1p68rLNYpzq7M6P3hx+bOf/cyNmnmWXKtHYHgwEnreeeeV3K9s9XZVKsFy Pr/lzfEoVbMy5PUWSW/NNA1lTLCXtnd6w/T4o4+5KUT68dYWosvffMv2mLCH23b0Rz/8H3sqmPuu t91aFLv33vvY7JNPsp/e/hP74X9fb25ufjCSoLdbe+61VxC+t08681e9tRsXrMl4dcGuXZsyDwQA EKgCAXX49afOvxYRV8upQ75jR/pOebXyJR0IQCCewIwZM2zWrFn2q+CFZNLagfiY+BYjoL7gzJkz 3V8xWcJLJ9C0xoAfPvfDyr5omzZusnnz5pnm3cpt2LDenvntb93agreCfa81AuA/hEuD9QZPPfmk /cGM9wY75TziDAHFkZX4fJDG28FbNYwBEdntBgQGgToZnv/uEO4gAIG0BNT519t/dQyqaQCkzR85 CECg/gT0Mu3SSy+1t99+2/VT9PISVzkBjSwedNBB9qlPfcrGjx9feYKkkEegaY2BPE3f8egc1Oka g/bG7+3pNS1+nbDnxGDf7ZE2YaLZxIkTbWXwQdQagbHBB3PatKludEE/zi88/7ybu6qGtWdwYI/i 4CAAAQhUk8APfvCDmhgAmjJZaApSNctQalq8QCiVGPLtSECf0dnBSwBtYnLzzTfb/PnzbfXq1bYx OI9D675KmV7XjnzSlknfcxoJ0LSgsWPHOkPggx/8oJ0cTAkXY1z1CbScMaC5te8NhuIWvvaqvfTS SzYq6NCf+v7327R99w2mznbYmUGDGRZsK6oP3qFHHG4nnXKK22b0Ix89JzAENtqyZcsCQ2AvO/UD 72dUoPrtiRQhkHkC1RwJ2PWjOND9KA4OFgprX/86LxEoXp/BTKUdwZROHRDpOz3FIyEBgfYkoJeM Z599tu2zzz72RDBl+cUXX3QjBdqtLDrirn5KuTvy1Wv3s2gtVaJz2rjq8Gt7eG0CM336dLet/IEH HujWf0b14bk6BFrOGNAHZ/pB0+2iSy6xJcGuN8OHDXfPGgVQA/rQh8+2acEowKBgBGFqYCBMCrb6 0g/qscEKdH1Ily9fHsyLH28HHHiADQusThwEIACBZiWgaZJdXd02ZfIkt2Oavsua0WnXN02JeP31 14Ndg9ax5WgzVhI61Y2AFsufeOKJ7o22pgxpG15NX46ODMhfLzjLcerLaCZEOa6SfOsRV3059fXE RgbBhAkTWJRdTkWXEKcljIG4eXf77ref2/lmoE7jHDzI/DZ3Wmx8WDAioB2ENIVI1rOcfkSnB3PO FE/++pGNS1fySVuOFuNaadw4fYrlqfBK8/Xl1ZdV9M1FmvyRgQAEakNAUxr33mvPsg9RrI1W+alq xEJnHuwVTL/ctjU4ByHo5OAgkGUC6mdoTWKhdYnl7PrimVZr9zOfXtprJTpXEjetfsiVR6DpjQHN /f/xrbeVVDp1qvUjWo5rVNzVq1cFc+PGlaNy/zqIciKHyyvWWlSNgwAEmoPAwOANmT9DpTk0KqyF dNUmBDgIQAACEGgdAi1gDOy0a666qiSiertd7iKTRsVNO5cuDkS1dNYmhauCvc5xEIBAkxDQEoEm nRoUT6g5pzHF64ovBCAAAQiIQNMbA/ppGdW16xThtFWmN9zRLUmbPa4W3/npOml19XJVK28w71fD eDgIQAACEIAABCAAgWwQaHpjQJ36T3/mMyXVhna00JZU5bhGxdUiIy2UKcdVS+ftgRH17f+6yl56 8YVy1CAOBCAAAQhAAAIQgECLEWh6Y2DAwAFu69BSuFaySKVRcV8PTlOeMnVqKcXsl62WzlpAfNMN N/anyw0EIAABCEAAAhCAQHsTaHpjQPhLnT4j+VLj+GpuVNxBTaCz5ia31vxkX2tcIQABCEAAAs1B QOv41q1bZ7///e/t5ZdftpUrV7pd/6Jbi2onQO2nX47r6emx7u7ucqI6XcrNtxKd08ZVP0SbwPhz Bg499NC8bVnLKjiREgm0hDGQqD0BEIAABCAAAQhAoEkIaIRdB43dfvvt9tBDD9krr7zijAHt3Bc1 BppE5aZTI3zo2EHBlvCzZs2y0047zY488siy14M2XSGbTKHONAtG08gklauSuEpTH55y0ignji9D VuPqS0y7GsnpmoZDGhnPNXolbpRI8jOsktlEQ1qR1dq1a90Wwe3YWVCZ1BFSGf3GDq1YR+gc/aQl P2eVldr6Cy+8YN/4xjfsl7/8Zarf0GSK2Q3RyIrWQuosBf09+eST9tJLL9nnPvc52zc4TLacGQxZ bZNpW1FnV1dXQVkBLCaTlICGscqN69NUpZeaRiU6NypuJayqpbOMAX80uq7FuFcrX1/Xaa/NwCqt rl4OVp5E8WsWWenE0q3B56+cH7niRBsr4Yf8VUZ9rzSqfhuVL99X6dtfq7PS1KAbb7zR7rjjjv6D UNOXHskkAqtXr7Zbb73VJk2aZF/60pdK3iCm1dtVEpck/3K+6wYkJYY/BCAAAQhAAAIQgEA6As8+ +6zddNNNGALpcJUkpZGC66+/3k3BKikiwqkIYAykwoQQBCAAAQhAAAIQSCbws5/9zLRNOK42BN54 4w37+c9/XpvEM54qxkDGGwDFhwAEIAABCECgcgK//vWvK0+EFAoS0FoMXPUJsJtQ9ZmSIgQgAAEI QAACGSOwYMGCxBJPmzbN9Bd22qhD62i08Hju3LnhoJz7uLh+m85y4laSr48rBR944IEcPUt5mD17 dqL4okWLTH9xTgu0cdUngDFQfaakCAEIQAACEIBAxghoAXGSU+f3oosuygnesGGDjRgxwhkDJ598 ck5Y+CEu7vLly23ixIllxa0kXx9X+lViDFx++eXhIubca23Addddl+PnH7Q4Fld9AhgD1WdKihCA AAQgAAEIZIyA3tInOb3dj74N97u+FIqn9OLiasvNqVOnOmMgKc+kuGnzVfpJOhfKM01YNN1wnEJG xo4dO8Ki3FeJAGsGqgSSZCAAAQhAAAIQgAAEINBqBDAGWq3G0BcCEIAABCAAAQhAAAJVIoAxUCWQ JAMBCEAAAhCAAAQgAIFWI4Ax0Go1hr4QgAAEIAABCEAAAhCoEgGMgSqBJBkIQAACEIAABCAAAQi0 GgF2E2q1GkNfCEAAAhCAAAQg0MIErrzyykTtC525kBiJgIoIYAxUhI/IEIAABCAAAQhAAAKlELji iitKEUe2xgQ6tVdtMdfT01NMJDE8Tfpxkbds2eL2z9X+u+WkUYnOjYpbTjk9u2rorJMFdaqhnK5p 9KlGvr4MpVzT6JaUXqN0blS+sEpqCfn+jWK1evVq2xR85nbu3JmvVIv7qEyrVq2yjcEBSwMG7JqZ 2qjPQqPybVS7alR5K8m3XVmJSVzZ5F/snIGkuEqv3Lhp8tV5BEk6N/JrKU6nYvqUE8enKVblulaJ 26lDJQo5fzhFIZmkMMEvln5S3CFDhlhHR4f7KzWNSnRuVNxKWFVL523bttnQoUNdlehajHu18k1q A0n+zcAqSbckf1glkcn3zyIrnUK6Mugwr1+/oe0MAhkA48aNs3Fjx1pnZ6c1qn4blS/fV/mf8SSf dmbV3d2d95vq22SxDn1cXM+qnLhp8+3q6krUOakO6+FfrG8S1cGzivqnefas0shGZVopLguIo7XH MwQgAAEIQAACEIAABDJCAGMgIxVNMSEAAQhAAAIQgAAEIBAlgDEQJcIzBCAAAQhAAAIQgAAEMkKA 3YQyUtEUEwIQgAAEIACB2hEYOHCg7dixIzaDRYsW2QMPPJATtiFYVK/1QsXm/cfFXb58uS1cuLCs uGnz1Vz7JJ1zClLHBzHGVZ8AxkD1mZIiBCAAAQhAAAIZI6CFvto5K86pU61OfdhpBz8tqi9mDMTF 1Y5/2uijnLiV5OvjhstRz/sxY8bUM7vM5IUxkJmqpqAQgAAEIAABCNSKwKGHHmpJB2bJEIgaA2n1 aMW4actWqtzBBx9cahTkUxBgzUAKSIhAAAIQgAAEIACBQgTOOOMMtx16IRnCKiNw+umnV5YAsWMJ YAzEYsETAhCAAAQgAAEIpCegjuq+++6bPgKSJRHQ+QIyuHDVJ4AxUH2mpAgBCEAAAhCAQMYIHHDA AfbJT37SRo8enbGS1764I0eOtEsuucTEGFd9AhgD1WdKihCAAAQgAAEIZIyAFvT+yZ/8iV144YU2 ceLEjJW+dsXdY4897GMf+5jjKsa46hNgAXH1mZIiBOpO4K677rI5c+bYtm3b7OMf/7jNmjWr7jqQ IQQgAIGsE5g8ebJddtllNmXKFLv//vvthRdesLfffts2bdpkO3fuzDqeVOUfMGCADRs2zGQEHHTQ QTZ79mw77bTTHNOOjo5UaSBUGgGMgdJ4IQ2BpiOgNybanu4jH/mIvfLKK/ahD33Ivvvd79p5553X dLqiEAQgAIF2JqB98Pfbbz+79NJL3UuZ+fPn9xsD0W1A/fag5fDo6ekxbWVajqsk33rElTGgEYAJ EyY4Y+CQQw4xbWnKGQPl1Ha6OBgD6TghBYGmJKAfGr19uvrqq+2cc85xOmpru1tvvRVjoClrDKUg AIF2J6C315rjfvzxx7u/pPL29vZaV1dXUnBBfx0IpgW15bhK8m1k3HLKSpx0BDpVscVcGpmkNCqJ qzRlSZeTRjlxfBmyGldTTGR9y+mahkMaGc81eiVulEjycxKrffbZx40GKKaX0fCq9mL2z/6anHpy CHGT2URDKmG1du1aN40g+uYwmkcrPqtMmiKhMvo3e5WwIm76VgArWCURoG0kkcn3zwKrzmJWqSAU k8lHt8tHw1jlxvVpysIuNY1KdG5U3EpYVUtnGQOabiKnazHu1crX13XaazOwSqurl6s1K51Qecst t9iSJUvc0PFFF13k6g9WvgaKXxvJSruPbA0+f+04H1ZlkoGqMup7pdafhaSablS+jWxXxb7DYbWL QKPaRiX50q6SWm++P6zymUR92E0oSoRnCLQoAb2B3bFjh1ukpjexOAhAAAIQgAAEIFCMAMZAMUKE Q6AFCGi3hW9/+9umXYWOOuoo+1//63+1gNaoCAEIQAACEIBAowlgDDS6BsgfAhUQuPLKK+3UU0/N SWH48OG2bNmyHD8eIAABCEAAAhCAQBwBdhOKo4IfBFqEgLYTvfbaa92owLnnnmvaXeiee+6xyy+/ 3JXg8ccft+uuu67/uUWKhZqeQN+uTRT8I1cIQKA1CGzdutWWL19uK1eutI0bN7pNOaIbBGzYsMFG jBhRVoGU9sKFC8uKW0m+9YirdUaDBg1ybMaPH++2GC2roERKTQBjIDUqBCHQfAQOP/xw+853vuM6 +1dccYVboKkpQhdffHG/stp61BsH/Z7ctASBHTt3mPb11g9jK7jNmze5dSutoCs6QqAWBNThX7Vq lT3xxBP21FNP2YIFC5xBoM9x1BjQrn1+045Sdalkv/9K8q1HXH/OgAyB6dOn23HHHWcHHnig24Sg HTdZKLXuayGPMVALqqQJgToSOOOMM0x/ce4973mPO8Y9Lgy/5iewZctWWxl0LDqCQ3gGBwaBfiSb 0elkVem6avVq0xtRHASySmB18Bm4+eab7fbbb7dXX33V1qxZ40YGtLlD1BjIKqNi5VaHX0aSdiEb O3asPfjgg3bmmWfahRdeWHSXw2JpEx5PAGMgngu+ZRBYtGiR6U+LWXEQgEDlBNSxfvvtle5tu9aC DBwwsPJEq5xCMJPJ6afpA9rCT28OcRDIIgF1+O+880676qqrnCGwZcuWLGKouMwymrTVuf50Pslb b71lb775pu21117ucM1mfSlSccEbmEDzGwNBo8DVkYDHHVjmaZw6/9dff71pn3v9aXoKxkAacshA IB0Bda5XrHg7nTBSEIBAwwi88cYbds0119hLL73EdLkq1oKmRGk9nHbMmzlzpu25555VTJ2kRKBp jYEhQ4a4A3j0Q6i3Y4MHD6bG6kBg48YNwZSEDhP/JOcNgHvvvdcefvjhJDH8IQABCEAAApkhoM0b nnnmGQyBGtS4+oKPPfaYzZ07l6mvNeDbtMbA5MmT3ZwxDbPNf36+HXnUkTUoPkmGCWjXg6VL33CG l/iHnTcA/AhAOIx7CECgdQhoPu7AAQNMg4Ca68885tapOzRtbgJz5swJ1s4wNahWtaTDNO+44w6M gRoAblpj4JjjjrXusWNM81C///3v25e+9EXbM5gvhqsNgXXr1tkNP/yRrQzmJ0+YOMFOPPFE8waA tqbUfRonY+Gkk04qKiorn10UimJyArBKx0lSrcpqv/32s6/9y7+kL2gZkkOHDrWu0aNt1KhR/bsT bd221Xp719q6dWvdAuAykiUKBCDwDoGnn34aFjUmoNEBXPUJNK0xsO+++9rZwR7q373mO3bPL+62 kcOH2fHBzijjx+9hAwcW3lGjHvvgxlVFJflqz+BlS5fGJVvUr5J8ZQSoA/Xcb5+122691Y0KnDhr lh1/wvG2JlgMKJfWECiqKAIQgEAsgcWLF8f6V8tzRLD4WLtyjBkzJtihY2jwHbprIfL2YMHj8GDH jiHBNEztgrIpmJuLgwAEyiOg3/Ekp7V00fV0fntQjc7pAMkkFxdXi/W7u7vdyF6pcSvJ18eVrtrO ulxXKG6hGQgcqFku8cLxmtYY0Fvjj3/8E7YyWDh3989/brfdcqs9+sijgTEwvv+HLKlolbwdbFTc 8AcsqVxJ/pXorPUY6zest8WvLbKBgzptdvBW/+JLLrGu4EtGf9qfXn8yCLRQuNgogb60fvCDHySp 2u/f29tb9hZh6jhNnTq1P61SbirJtxXjwip962gkKx08pC1Ea+HU8R8TjLLuscd40+hA2HUGYRop kMzOvmB70OUr3NShsAz3EIBAOgL6LU5y+m2Mnvfif1PSGAPRuP77qpy4afOdFbwYjObr46qchTr0 SRy8fzRd76+ryiSDIM6xdXEclcr9OlWxxVwamaQ0Kok7YuQI+8RFFzrr94nf/MaWvP66ra7RD2aS /vXy1w/xgI7CIx610kXbdO23//52zPHH2gdOP90mT5kSTB3IbRd6o3jZZZe5v9eDerjhhhvcn+7D Th/UaNxwePg+rVw4jr8nridR/Aqr4oy8RKNYafs8zYfVj2C1nUYCukZ35RkC4Xy0n3d3V1ewJ3qP O+QsHFbpvcqksqmMfkSiUZzJN31twqq6rPTCL46p/Ip97hsVV+sfknROTydeMi5dL1ls3UWhuD6N 6LWcOD6NLMTt7Ap+AAo5QSgmkxRfw1jlxvX5HhacsDplylSbEWwntXDha65h7gyGtgs5NaRCu+E0 Y1xf3kK6JYVVVt6tNn6PPWxSsGD4qGCR9sQUW3Yddthh9pWvfMX+9m//1h2oEh4x0K5Paeq8kvJW o10lsSzkX4nOjYoLq0I1mhvWSFajg7n8W4M9tWtxuubIESP71wjklnj3k/LVZ3dkMEKhjkc1ndKW saEyasS3UZ+FRuXbyHaV5rs4rq5hFUcl3i8tK7dmJ9Lf8nGLGQNxcX27Kidu2nzVj4q2IR83nkZ6 32i64ZjF+m+F4obT8feelX8u5VpJeVspbtNOEwpXVld3l806abbNOHGmO8lPO2AUcnoDpR+eclyj 4i5ZssSiO/ik1b8SndetXRcszN6zaGchSZdp06blTCVifUESKfwh0BgCAzsHBicXdxTN3O0yFMji IAABCEAgWwRawhjwVaK3Smk6+fpRK9Vy9Hk0Kq4sSC0GKsdVqvOgQYPKyTYvjgwD/eEgAIHmIbB9 2/ZU6wB27tSpn8lznpunRGgCAQhAAALVJNCYSerVLAFpQQACEIBAIoH169e7gxsLTSdQ2NatW9zI a2JCBEAAAhCAQFsSaKmRgbasAQoFAQhAICCghfy1cH7x4eBg/q+2EY1zGzdutJ6e3podmKSyaQQT BwEIQEAEknYLUph2SsLVlwDGQH15kxsEIACBPALqLA8NOuu1MAh2BGusVge7BHUEeYwNdgXT4jx/ 4N+2YNHy5s1b3BkDOlek0OhBntIpPXzZMAZSAkMMAhkgUOhsBNYe1r8BYAzUnzk5QgACEMghoA7z 8OBgsBEjhtuOYLc0/VXTaWvPFcGZLbpqC9EhQ3adN7B58yZ3uOC6devd4YPVzFNp6YBIjUZoN6Fa GDrV1pf0IACB+hAoNDJQHw3IJUwAYyBMg3sIQAACDSKgPfj33mtv277tddsQTNvRrmla1FuaS5bX dCH9rVxZm8PNzPw0oD7X8ddIgAycSZP26T9foLSyIA0BCEAAAvUggDFQD8rkAQEIQKAIAXWeR48e Zfvvv587jXjp0mXBPP41RWLlBvdZX9AlD/57ZytRP+1HqxE0TUjO+Wn+fmA36G39ruk7wUPwv5/W 3zFgoPWpbx86BE3bk3bYAOe1c+cO99Zf8rvi7/KXKTKgoy/YGa3LJuwxwcaM6XajArtklDsOAhCA AASajQDGQLPVCPpAAAKZJaBOsw4Y2nPiRFu27E2b/+J827xpS2oe6oy79/P+n1Bnvr+nH0rNiYWe +2+9VdDv8U667zzn5iPPICV5Bm7Y8CF2YnBI5IQJe7i1CRgCu7jwLwQgAIFmJYAx0Kw1g14QgEAm CehtvU4DllGgN/Fr161rKQ5Dh060IYH+1Tq/pKUKj7IQgAAEWpBAbfaya0EQqAwBCECgmQiMGDEi mGYzpplUSqWLdJbuOAhAAAIQaA0CjAy0Rj2hJQQgkDECY4ITyQ86aHqw88/gxJJra9By38BXElfn EmhxcJzbf7/9TLrjIJA1Avos6nMV5+J2z9GCfo0A+rU9cfHkFxe3J9gKuDv4nJUTN22+c+fOtegW oD5ukq619tfWyLjqE8AYqD5TUoQABCBQMYHx48fZjHHvsfe+54TEtNauXRssOh6dGF4ooJK4r7/+ uk2ZMiU2ea0RYJ1ALBo825zA5MmT7bXXXostpTr0cZ36WOGIZyvGjRShao+TJk2qWloktJtAR2Bd vrPsa7dnte685Vqt9No5HVilr11YwSo9gfSStCtYpSeQXpJ2lR1Wl156qd14443pC4xkyQQuuOAC u/rqq0uKx2ewOK7OruAAmkKut7fXiskkxVcFlBu3knxbMS6sklpRvj+s8pkk+cAqiUy+P6zymST5 wCqJTL4/rPKZJPm0Oqvzzz/ffvazn9mGDRuSioh/BQQ0NfG8884ruV/Z6u2qVGTl9IFZQFwqZeQh AAEIQAACEIBAhMCMGTNs1qxZZa/jiSTHY4hAZ2enzQy2LNYfrvoEMAaqz5QUIQABCEAAAhDIGIFx 48aZpgodeeSR7rC9jBW/ZsUdNmyYHXbYYfapT33Kxo8fX7N8spwwC4izXPuUHQIQgAAEIACBqhDQ GSGzZ8+2NWvW2M0332zz58+31atXm3bf2r59e9Gdf6qiRBskog0INBKgaUFjx44NdlU7yD74wQ/a ySef7E5Nb4MiNl0RMAaarkpQCAIQgAAEIACBViQwcuRIO/vss22fffaxJ554wl588UV7++23TVty 7ty5M6dIMhDU6S3HVbLFp4yUFStW5GS75557uk53jmfMQyU6p40ro0pbru6xxx42ffp0O/744+3A Aw+0UaNGxWiEVzUIlNcKq5EzaUAAAhCAAAQgAIE2I6Dtfk888UTXuZYhoAXFOn8geiaA/Ms9oG/5 8uU2ceLEssjdcccd9o1vfCMn7he+8AU3vSnHM+ahEp3TxpUxICNJbGQQTJgwgUXZMXVRTS+MgWrS JC0IQAACEIAABDJPQAeQ7b333u4vCUY5u774tBYvXmxTp071jyVdjzrqKPvpT39qixYtcvGmTZtm l112Wao0KtG5kriplEOobAIsIC4bHREhAAEIQAACEIBA6xHQ2gbvZAzgsk0AYyDb9U/pIQABCEAA AhDIGAFtgerd5Zdf7m+5ZpQAxkBGK55iQwACEIAABCCQTQIXX3yxK7hGBcKjBNmkQakxBmgDEIAA BCAAAQhAIGMEZBAwRShjlZ5QXBYQJ4DBGwIQgAAEIAABCLQrAU0Vuuiii9q1eJSrBAIYAyXAQhQC EIAABCAAAQi0AwE/VagdykIZKiPANKHK+BEbAhCAAAQgAAEIQAACLUugo6enp69a2m/atMm++c1v uuR0gEWQtnV3d/cn/7Wvfc3df/azn7Vhw4b1+xe7URpz5syxmTNn2q9+9Sv7m7/5G3cQxZe//GX7 wAc+4PIplkaa8O9973v2/PPP29e//vU8ca+7AvzBIdrjV/mPGTMmTz7OQ3Iqx4wZM/KCPauHH37Y Hbut48yr6VQmHeCh0xH1p5P8xHPw4MHVzKYuaXlWdcmsxTOBVfoKrCYrfV/oc67PWNj57xF9PxZz hb4vvvrVr5q+K/R9Ug1X6LvPp6+TVPW3bNky23///e3YY4+1cePGueCwPuF7HzfL12q2q3bnCKv0 NQwrWKUnUFyys6urq6BUKYdEKK21a9fabbfdZv/8z//sOunh9L///e/bueeeazr2upgL5/vrX//a Ojo6TGn9//bOBdiq6Y/jWzJiGOYv0UTjXVGhhDKZ6cXoQUWiPEYlPTxKkyFpEJMR4zUVMh6lUCMj k9IUyjuK0mR6MZOIJoYJk1f9z2fpd+66+6x9zr733LqO8/3N3Hv2Xq+91mfvvfb6rfVba61evTpq 27ZtNHPmzOiGG26I8POvQbp+3ELX8f1XrVrl0o6nR5gPPvgg8pfiwu25556LHnnkkYhykadC10WJ oEEeSp8XG3f8Fy9eHAzDNUNS6LrEufvuu6M777wzQmFjR0Skd+/e0ZVXXhlNmzbNnVf131VXXRUN HDgwh0uadNLkOSkdY5Xkn8+9mOuWYlyxyvc0VParSVbUF+edd17Oe4zyvWTJkkruSc9Vvvpi//33 dzt0UoJQfVK5ZOEz/7rUfR07dkxMq2/fvtG6deuiFi1auF1Ply5dGuE2a9asqE+fPpHlh7xQ7lDZ LRf+dc0t9MuGSNdcc0301ltvZb3Txs1G8A5qK25NPldecQoe1lZ5i7muWBW8rdkAYpVFUfBArAoi imp8zsCAAQOiSZMmRZ9//nnEltwmnLN9Nv4IDd4vv/wy2rlzp+tl6ty5s3PnQ4mcdtpprgE7bty4 iK2pEfNj9jsfo0svvTTbS+8CZP7RU/b++++7bcBPPfXUiD/E4v7www9OoSBdX1BiPvzwQ6dg+O7+ Mctv+UtwsTZv165do9dee80pA4T97bffonnz5kVr1qyJmjVrFnXv3j068MADs8mg1Lz99tvu3E8L Nl999ZVTeiywH478r127Nho8eLB5u9+5c+e6fPfq1Stq06aNS9tP1w+Mu6/QtGrVKrrwwgvdaI6N 4PDh/fjjj6OTTz45at26ddSwYUOXhOWFE/JCA+CTTz5x99P84tdNcvfzpGMRKGcCKOevvvqqe/dP OeWUqFu3bomjpuwYumHDhuiEE07IQUa98/rrr7uRTeqdHj16uHRQKKgrEd5bzuNrilvdN2bMmJx0 caDRT/p0vNgoKLufUu9RD8TF6mtzt7xt3LgxOvbYY10dZAqM1cvUP5Rv5MiR7rtheSUNC+PXXZa2 fkVABERABIon8E8ru/h0sinQwOzUqZPrLc86Zg4YhsYd/7vuuiui8f/NN99E3333XdSlSxfnRng+ VvRg89GgUY3QyMTdeog2b97sjnHzG6D9+vWLGH63sB06dMgOo/MB5FqjRo3KpuMS3/2Pnryjjz46 +KH1w/nHNOz5MNOIR7Zt2+bMAmbPnu3ywKgBZgLWE29xaUTfdNNNdup+X3jhBTfKQN7JtwnHgwYN iqZMmRI9/vjjTjGyLcRnzJgRXXTRRU6peuCBB5y/H9fSSPplmB+x9FCu7r///ogP/R133BE1atQo oscQ4YNM4/6KK65wv9yjL774wh0TjgbDO++848LaP/JSt25dO9WvCJQ9AeoMky1btrj64dlnn3X1 xZNPPunOqUfiQl1y++23R9R9K1eurOS9detWF49eeuoPq3csHepIesYYyQyJ1X0nnXRSyNt13NAJ YYqABbr++uvtsNIv9QT1A0Le2rdv70YQUHzI2/nnn+/qSvzJG/XItddeGy1fvtyNTFCvUQ7SwW3h woXunPASERABERCBmiewR1pq9P7zN2LEiGyOacw+88wz7pzGsg0v40DvM3MN/B6rhx56KGfJKz4w /PFB5dd6jEiD3uz58+c7O9qjjjrKfVRouGICQ+88Qs8ToxH+B9l5ZP4xKnDWWWfZaapfzIMYiaBs COljQ0vZEMrTvHnziPIOGzbMufEP05zRo0c7+9umTZs6d8yeHnvssWwY/wAFyuKjJFHuYzKjI2PH jo2wzx0yZEi2vH68+DEfWJMff/wxeuKJJ6LjjjvOjcLw0WY0gB5FRgQQ7gt2yS1btnTn69evdx9m wpEW5aLBf+KJJ7oykX8+/AimYmeeeaZrpDgH/ROBMiPAe+rXUfHi0/jnvfNNHemQoP6w993iTJ06 NSK8zTfq2bOnebn3sH79+sF6h7oBobOAnvmQ5Kv7aKgzmsq7nFb8eoZ6IF4nck7dMXToUJckysiy ZcvcMaubLFq0KPutoI669957015a4URABERABKpBYI8oA/TQY+tJpY5NOcPJCO4Mc/NxwYyGEQKT r7/+2vV6cc7HgYZ1VYTeMnrh+fj8/vvvzoaVXnv/Y0zDO6QIcJ2PPvooGj58eN5LYlPrCyMaTMxl EjFCw5k8+OViGJ0PvgkfyiOOOMI1nqdPn+4+dCtWrHATeemZpzcsLv5QPEqAjUTQo09j3oR5C/Sq JQkTr+khxKaTPxoejAQgDRo0cAoKozGYWTG0z7X8UQ0mDqIIhAQFB9MuzJ0oH72Q3G+JCJQrAb9R HGKA2R/vrC+c0zj3lQGUcBY2oCPAhNE43mGEOi5U7/AumowfP94Oc37z1X305iP77rtvTrw0DtRn 8bxRZ/n1CqaKJtQ5fp3NYgcSERABERCBPUtgjygDZBnbT3rNUQZefPFFd447igDzBOIfSsKjECA0 5vMJk9UQPw3S5dz/I0waO1Ma13yYzz77bKIkCj14DGsjjGQwemFzHXD79ddfXdmSFA7CmDBqQSMf cxx/9ML8/d/DDz/cP6107M/LoHGfT+gdNGncuLEzA9qxY4dzomwoCygk9erVc+ZPxtni5CsXczNg Ta8mZcOkC9MwiQiUKwHqCqsvjIHfUYBijn2/L7zD9Mb7YiuL/e9//8s6++/99u3bo7///juno8N/ X/3jbCKZg0J1n9Up1I+MPlRVQnmjE8Wvu21FolDaLKggEQEREAER2LME9pgycN1117lea3qAMIHB PAfBpISecibL+T3eVsxQz7j52S+N1bhg70rvF3b1LJtpE9Ti4ULnjESgCPBRst62UDjfjeVRMUvi mta7zsgDk/VsboMfPn7Mahs2tA+fJHveeLz4Ofb9psQwMlFI4o0TUwbojWNugt8jidmP/9H2j0PX wTSMOEwg5N4y2iARAREIE6AOfO+99yp5UheZKZB5EA6hDrWRuU2bNpm3q0uZr4NCH5dC76xf98Xj ck5HBPUCHRbxfC1YsMB1ZuQz48FMMl4nUsemrZ+lDITuitxEQAREoGYJVFIG6F2PCytN/PXXX5Wc 8/XkWECGtOktZnIc9qb0ZFn6THql1xg3TEpYTYOhcUx88gnxbdiaY/KGcIydOz1nNEaZ7IYJTf/+ /d2EYUyWQmL5QQHho2Vppi0vowMoIfR08ccQP9dnLgFlZPidCcs0sM1kxvJMfmg8YzsLH/vI+/m0 sJZP/P7880/HADcm7aKQkPdffvklZ2KhnxbHpOenZW6Ul958RjkwrcIEgaVI2QuCSY7ML4gLPY18 0LH1ZaIiSgYroTAShHKDsmTXSvO8kL6Fj1+ruueh9GCQ9v7GrwuHeNx4GM5rurxpJ2GHykuvctzU Im3+SrG8xdzfEKti7m/ofcP8jneYe8X8GkbrMIm8+uqrXf1H43zChAmVLkuDmPqBDgPeL8yGLB3u EelgrsicLExu2AsAt5deeskt5VwpMe+EuH7d53lVOmSZaBT7P/74I7r44ovdIhAPP/ywW+CBupaO DUwLrVzU0XZsZbS8UScSZ86cOQXnITDaAQ9YkX67du1cHRZ/B//tz3MlmHlOQu9vMc9zKb6/oXfw 335/i6mfi7m/IVahxystv9DzF0qvtspbis9zMfd3b5e3kjJAgzIumL7El4pL+3DRO0ylz6QwP20m /06cONF92Phw0JBnopj1AsVNe+ycNPggkR+O+SAy6dfS5qPFahUsbUqvO0pAkiJAOS0eHygaspxX pbyMcnA9rstKSazBjRkAH0o+2igKLD3KB5q06cEnzyYoA0wCtonV5k7DGoENcSyfuPGBhAFubGDE PAdWUOJa7LvAyhshIU3S89MinJWX9c+5L9wrbP+N2+TJk51JVMjM4PLLL3cNgtNPP91tQER6KCjY N/v5Tvu8xPNGesVIKD0rr59u2vyF4vrp2HHa9EL5szT8X1v21XcLHYfS43mLu6fNXymWN5TntOUN sQpxTpte6H3j3eUd5p7QWcI7h7kh7x0978wjsvrOfskDixEQFoWAusrmR1Fe3lf8UQioU1AcMM2k /mVkgHRCIwTE9eu+UFlxY3NFRiKo1xgJxYypSZMmrqODEWATK1eojJY36kyObUKyX0ZLx37pmLjg ggtc/cnqazAr5v6G4tq1/N+09zf+XvlpVOc4lF4oz2nzF4obylfa9EL5C6Wn+ipEpaK94fuG7lHa +1HT9dXeuL/FlDcU12dpx2n5qbxG7J/ffTIfiewSM5icxAWbT8xufOHjkEbozaGXuZCE0gsNJYfy F0qbyijNMDTpWfGtsVtMedkQLc4qlD8rL0oAH1fiYU5l7hanUHn5kCMs1Ud5GYWhsZBkphRKr6bL SyOFXk6WCjSJlwv3Yu4v8UNp4u7L3iivfz07DuWtmPJW5Xm2PNgvy/fG38FQ/iy8/1vV59mPW1vl LeZ5rs36ilFSq4N8jv5xmueZ+oxJuGmEvV+orwpdN/S8kJe4eyh/fj7IG9cq5nku5v7W1vMMgzgr n4sdh/iVYnmLub+qr9I9KzwztVlfpW1f2bNtv7X1PFenvrI8F/M811Z5q/P9rWsF5jekUe23336V Ng/zwxc6Zl3qUJqF4iX5p02LHqo0EkqvmPJipuRP7EvKAxOlmWeAeQC9ZP6mZH6cUP58/88++8yZ FGDSc+6557qeOnrvkiSUXk2VFxMvRoHY+OzWW29NykJe91D+QhHSDmeG0qup8obyVVW3UP5CaRTz PNN7lPY68WunfZ7j8ZLO0+ajmPIWc39rs74q1CCHaYhfMeUlvTT1VdL9jLuH8hcPw3lt3d/aep5V X4WegvDzrPoqzCrkWpv1VSg/cbdQfVBMfVVb72+51FeVlIG4bTE3FxAh9/iND53TyK1u3FB6adNC K0ojofSKKS9mTqE043lh0zFelKeeesr16sf97bxQWjS6GWZngh6Th9mBNN9eCaH0aqq8aN7Mk8A8 qroSyl8orbQf11B6NVXeUL6q6hbKXyiNYp7nYt7BtM9zKM8ht71R3mLubzGsSrG85XZ/a6u8qq9C b0cU/FYW8w7W1v0tpn5WfRV+NkKu5XZ/93Z5KykDoRsgt5ongP2+zQsoJnV69TARwj4/zbBdMdcq FNffMK5QWPmLgAiIgAiIgAiIgAj8OwjU+XdkQ7kQAREQAREQAREQAREQARHY2wT2ySzBmZ1AvLcv ruuJgAiIgAiIgAiIQFoCNi9uxIgRaaPUSrjnn3/erbyVtA/H5s2bo5dfftktSx5aWjxNppmUz6p+ WAfUBA9WNmNhElYjqynZE2la3lgRCLNrNrhlvgn7orAvC5unSqpIIPMw5ZXMLpl5/fN5omhUV4q5 binGFav0T4pYiVUSgWLefT1XSVRz3cUql0mSi1glkcl1T8MqY2K7K2OWmhO5mHd/T8TNrKq3K7O6 X04+zQH/zA7fuzLLCptTqt8VK1bsggGsdu7c6Y4zKwimimuBksqb2ZF816effmrBgr9JcS1wPE9+ moXiWhqh31DczLxJOrN3ZZY43gWDkSNH7sosX7wLtr6kea788P5x6Lq+f77jUoqrOQNVVJ4UXARE QAREQARE4N9BgMUrli9fHq1Zs8bNxWN5axM2M800RqN169ZFl112mdsfA78lS5a4ILbPBTuBM2HT ztkjZN68eW7PnGbNmkU9evRwm3D6cVmal42h2AMjLmw2xbXHjBkT93LnbBg2d+5ct7M3+xDRe84S lkimAek2ELW84JZpzPLjwhCPScv04Ddu3Ni5848NBCkX+46wmIcvuOOPH+na6mWsSMhSxGz8yvK3 HJvgF58czdxENpRFyBPxyC/XI22Ea/G3cuXKSuk5z8w/wuNP+hmlJsvc4rL/Cn6EIa+ECUmmEe6W Umefp9tuu80FISz36sEHH3SjBd27d3fuixcvjljF0TbD5RoI1zCBD/GbNm3qNsM1d//ZYPSBhVrY S4nngntXr149F9TSWrVqlXsuSm0eZR0rsH5FQAREQAREQAREoFQIsMs2Ddhp06ZF7FHAZpmY5yCZ XmLXWHvjjTeiDRs2uMYbjTiERh+NSROO2dQPYc8fFIpZs2a5MGwsyjnuCOFYIQp3Pw3nufsfO2dn ev3dZqC+ux1b45t0WRacPYJMSLNDhw526n4xjSIMSgT7CKGEcA2E8OwvhD/HKCdsfmp+bAqKsoEf ext17NjRNfI5x7SIP/xp3JMG3BAa5FzL/nr27JlN95VXXnGNfxQt0iG/Zr5Foxq3zAhDTpooAuSH fBCGBjP5QTjnvvTq1cstu845x+QpJCg07H4+c+ZMpwhaGPKC2ZApAv369Yvuu+8+lz5l4Xrz5893 wTknv/3794/efPNNt9T71KlTLSkXB0UDU6Tvv/8++Fxs27bNhevcubN7Lh599NFs/FI60MhAKd0t 5VUEREAEREAERMARoBeWBiUNdHqx2YgLO3J6gek5nzRpktuJm8AHtOfbAAAJu0lEQVTHH398hJ0+ NuX5ZPbs2RFr2qMMIKTfvHnzCPdhw4Y5N3qeGW2gQRrvPScAowJJy3zTyEWRoNFOfHYfZ68gs/mn wRwXRg0IS882DWZ6oS28hbVG8zEZ5YgGKfnmOqRHwxzh2jTGGfUYMmSIc2NkhYY/AkcT8mVC2qRL Ix4hL7ihICD4oZCQJ65LeYhPXmlsm0yZMsWFZY8lhPzAmrQypj3OjREGlBOEvJOunxfnsfsf10Ih aNeunZs30bZtW6dAtGzZ0oVYtmxZtGDBggilsUuXLs5t0KBB7l6yuznCfVy4cKHbuR2lkjTHjh3r /FB2GAEib6RRv3797HMxbty47HMBywMOOMApE+vXr3dxS+2flIFSu2PKrwiIgAiIgAiIQMTkXBqm /NET36lTp+xuz+PHj3cNQHq8mzRpEt1yyy2JG3z6KGm80mNvvev49enTxzXATRmgAco1kwRFZPjw 4UFvGt7kyRrSNDTpjee6NJ7xq6r4JkWY+1jj3r8OaZJnrksD14Rr5hMUCfJHLzpKCcoPaaCQGKM0 eabhj8kNPei+YLKDQoKQP9/EyUyn/PD+McoRjXl6+hctWuQa/ig0jBA9/fTTEcriOeec40x7UBQR nhP8TLZs2eIUAc65zygeKAGkzURqRhZQArg/pGVlJjwTlbdu3cqhMzMzhcM5lNi/OiWWX2VXBERA BERABERABByB1atXu9/Jkye7Xn96khEUA0w/GCUYNWqU87NGpwuQ8G/79u1RZhKs67WmAcsfgo14 GqEhuXbtWtdTHQpvvfXsIExjt06dOtke8FD4Qm40oI/J9MyHhEZ6qEG9adMmF5y4viIRT4OywJER AZsTQBhGAGg0M4eA+CggtSWUoWvXrq5XHtMpM6niXmPOZffP7iW/AwYMyGaX+Cb07jNywCgA4RjJ YLUmhBGn0HPhx63JHd0t3b31q5GBvUVa1xEBERABERABEahRApj98EcDlQm79AybyQm93vzRsMPU Bz8zdWEyqAk9+SaEW7p0qesJN7eq/NIgZanPww47LCcaNv+YotDLTr7oZadBTe9769atnXlMvGFP 3umVjs8j8BOPmxbZJqQ04G2UwMJz3qJFCzt1ikj2xDsgr717944wh7FRDLzJD2ZIc+bMybqb2Y8X PeeQRjf5iufVGOREKOCAKRJcMN/yWaMYoBAybyCzslB0zz33OLMf7kkaYaI5Jlws90qeGSVCeMbe fffdiMnIcYEJu2cffPDBca+SOa9TMjlVRkVABERABERABERgNwFMcfr27evMTBgBoGe3TZs2zvfm m2+OZsyY4RrcmIvgd8YZZzg/lAUUACYFY6+eWa4zy7Rbt26ukWkTSTFtQUEwJSIbMOEg33wBGqn0 oqMI+EKjHTt38oIyQKPZJuTS0I6b4dCAZsUiGtY0RFm5x4QGrPXiU04mK9NoRlBCWI0I0xckHtc5 7v4HP9KJz03Am/xZnkgbBQOzIb+h7x9butjWw8DyQ3lJh1GGqsrAgQOdiQ6/KCYIZSW/O3bscCY8 mHNh4sO9s7kRPC+jR49OvBxKF6NNjA74pl4oGeQb5QNBMfCfi4MOOkjKQCJVeYiACIiACIiACIjA HiDABOEjjzzS2ZmzKg8rCtlqOBMmTHATQ2nQXnLJJVGrVq2yjTtsyun5btCggVMEhg4dms0dDfXp 06e7hjkN68GDB7v4xEkjjAwkTR6m0cwE1bhwHRqxNOo5ZgItygAmPjSyGdEwUxwa+Jir0GNNA5fy mR/pEueY3WZD2L1jKkV80qU3nXOWJOU8Hpd4uKEkYCLEHzzsj4Yy8Wh805DnWjTuaWyzzCar/+B/ 4403Ort9wlia5K19+/bOnIf8ENdGSThGMDmyY879uJz70qhRIzeZF/MtrtewYcOIZUZRBkmXDcho oGP3v3HjRlcuRjgo28SJE/2kKh2Tf0yFvv322+yEcQKwChH3hJWJCJPZ28DNMeC54Bxl00ZkKiVY Iif7ZMD8YxCXkOHqDuGQHA+q/5AmXCLoXMx1SzGuWAUfg6CjWAWxBB3FKogl6ChWQSxBR7EKYgk6 ilUQS9Bxb7Oi+UNDLqnNYP7BzO529ONac4o004gfN014P8zeZmXXLibPtRW3plmleS7gVVvlrc51 69oN1q8IiIAIiIAIiIAIlAuBQo32Qv5xTlUNH4+v89Ig8F+8z5ozUBrPnnIpAiIgAiIgAiIgAiIg AjVOQMpAjSNVgiIgAiIgAiIgAiIgAiJQGgSkDJTGfVIuRUAEREAEREAEREAERKDGCeyTWf4p7wTi Yq7I0lL+zPBi0vqvxxWr9HdYrMQqPYH0IfVciVV6AulD6rkSq/QE0ofUcyVW6QkUDlm30FJI1ZmV bJflYS2UvoWN/xZz3VKMK1bxJyD5XKyS2cR9xCpOJPlcrJLZxH3EKk4k+VysktnEfcQqTiT5XKyS 2cR9xCpOJPdcZkK5TOQiAiIgAiIgAiIgAiIgAmVBQMpAWdxmFVIEREAEREAEREAEREAEcglIGchl IhcREAEREAEREAEREAERKAsCUgbK4jarkCIgAiIgAiIgAiIgAiKQS0DKQC4TuYiACIiACIiACIiA CIhAWRCQMlAWt1mFFAEREAEREAEREAEREIFcAlIGcpnIRQREQAREQAREQAREQATKgoCUgbK4zSqk CIiACIiACIiACIiACOQSkDKQy0QuIiACIiACIiACIiACIlAWBKQMlMVtViFFQAREQAREQAREQARE IJeAlIFcJnIRAREQAREQAREQAREQgbIgIGWgLG6zCikCIiACIiACIiACIiACuQSkDOQykYsIiIAI iIAIiIAIiIAIlAWBfX766adde6qkmbSjQw89dE8l/59KV6zS306xEqv0BNKH1HMlVukJpA+p50qs 0hNIH1LPlVilJ1A4ZN1DDjkkb6iff/45KhQmKQEe1urGLea6pRhXrJKeolx3scplkuQiVklkct3F KpdJkotYJZHJdRerXCZJLmKVRCbXXaxymSS5iFUSmQp3mQlVsNCRCIiACIiACIiACIiACJQVASkD ZXW7VVgREAEREAEREAEREAERqCAgZaCChY5EQAREQAREQAREQAREoKwISBkoq9utwoqACIiACIiA CIiACIhABQEpAxUsdCQCIiACIiACIiACIiACZUVAykBZ3W4VVgREQAREQAREQAREQAQqCEgZqGCh IxEQAREQAREQAREQAREoKwJSBsrqdquwIiACIiACIiACIiACIlBBQMpABQsdiYAIiIAIiIAIiIAI iEBZEZAyUFa3W4UVAREQAREQAREQAREQgQoC/werEY5fD3OeXwAAAABJRU5ErkJggg== --000000000000af253105a1500301-- From nobody Fri Mar 20 14:32:22 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F9F3A0DC5 for ; Fri, 20 Mar 2020 14:32:20 -0700 (PDT) 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_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=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 TG1olSbMls7p for ; Fri, 20 Mar 2020 14:32:17 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450: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 5F1743A0EA8 for ; Fri, 20 Mar 2020 14:32:17 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id i24so8886688eds.1 for ; Fri, 20 Mar 2020 14:32:17 -0700 (PDT) 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=wo7Spj1+EUy/FUHDCg1piLB0D/cG7KUQuo7NlOEpSvQ=; b=DX0iZhcZ6EHoe0aMunmcZLL1DLy5Rsfo2YnhSn32munRz2GJJvApBq7u+0pOc1EN+q UuEWgLxF/dTgS21Y7aG4LFOe4ZqOWcq/dFChnRGgOBtgJ6zfwXPSf3dU7OZ2+55ZKJB0 J+EiVuKAjMRYskoNMmPEyqaM5IZxqNCAI5KfG+TqAxWDK95OfbI9jrjizCJ2Sk/Nl1E8 HaPYNjytuu0zRvhBgRBdZG7fAZj1lswG5LslGOwoOXs63Xy7qI4y1KZJ/rmFdsDBs2Fw zedNuLLd1UKGxnwzGwmTXnwO0DcnjNVbIQFVovh8Cpw9OMQTOrh+KoDwM+mwr+TGqxXM Szbg== 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=wo7Spj1+EUy/FUHDCg1piLB0D/cG7KUQuo7NlOEpSvQ=; b=ebOOWi3t2XOWR4Ac10I+q9rZ+tlgSur860+g70XXh5WvY5aEoxU1g7hpqj2dZIyz5F L/vkchIG6HL08v7X44yWR06r/nahk25HEv6UjHZgsSiHroI/mHJBunh5D1rYotZPJCEp wLsoXhHfqpaXyK3lDxGfBE/SEiELgMg5dlwGVo4UOCUwwOGwwbPDc8gTPb/bbu6UKw/r 1Vn3EgpHtuVfvF1gVRJ+RNfewGpxNy8O0B3jlXy/o1KObqsEbU/IdLRU1xWQmBj5kG4X wG8EZqgaXszBoElPy8GOKxztHo6XlwIVEqRw7r16BZ3TQWDmXDQ7lfs++x3wmpKdPAag XJsw== X-Gm-Message-State: ANhLgQ2eiVDdJnl6femGj6S+KT5iObZWBJyh17DsdqX4F2V2VGR6NVxK ny2cLcqEmyZWkwTTJnJLvbs4oYXTEODoYDKgX1qkHcDL X-Google-Smtp-Source: ADFU+vv/MEvHfwpbMHpJj1qzfr83qgz10APfMPLFrJenYly+p7QRAFmiHLHR6SLY+WfwSAzP4nxPNY0EHW56Am0tMx0= X-Received: by 2002:a50:c043:: with SMTP id u3mr10126746edd.253.1584739935729; Fri, 20 Mar 2020 14:32:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Fri, 20 Mar 2020 21:32:06 +0000 Message-ID: To: Dick Hardt Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000ee3efc05a150047b" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:32:21 -0000 --000000000000ee3efc05a150047b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, It might be a misunderstanding on my part, but the extra complexity I was referring to is that XAuth provides multiple different URIs to communicate with the GS. Depending on the nature of the interaction, the client needs to work out whether to use the GS URI, the Grant URI or the Authorization URI - from a "discovery" perspective, this seems to me more complex than having a single URI. Happy to be corrected if I've misunderstood. David Skaife On Fri, Mar 20, 2020 at 8:23 PM Dick Hardt wrote: > To clarify on point 2 made below about XAuth being more complex: > > XAuth has a single URI to interact with to start, the GS URI. > > The Grant URL is the GS URL + identifier which seems equivalent to the > TxAurh endpoint and transaction handle. > > An advantage of the Grant URI, is the Client knows which GS it belongs to= . > > David: would you clarify what you think is more complex in XAuth? > > /Dick > > On Wed, Mar 18, 2020 at 12:44 PM David Skaife < > blue.ringed.octopus.guy@gmail.com> wrote: > >> Hi, >> >> My thoughts on these different approaches are: >> >> 1. For XYZ, it feels a bit strange and unnecessary to require the client >> to have to state it's full set of capabilities to the AS. It feels like = it >> should be the other way around - i.e. the client is able to probe what t= he >> AS supports. In my view it's more natural for the AS to be "advertising" >> its capabilities rather than the client. >> >> 2. I prefer the XYZ approach of having a single URL that the client know= s >> it needs to interact to start the transaction, vs the more complex >> approach provided by XAuth. >> >> 3. Hopefully there is a middle ground between the two approaches that >> addresses the two points above. >> >> >> Many thanks, >> David Skaife >> >> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote= : >> >>> >>> *Discovery* >>> XYZ >>> - Client always starts at the tx endpoint, all other information is >>> dispatched from responses from the endpoint >>> - Clients sends capabilities list in transaction request, AS selects >>> and returns which capabilities are supported >>> >>> XYZ Rationale: client needs a single URL to start talking to an AS, >>> giving developers multiple ways to get information is confusing and can >>> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by OI= DC=E2=80=99s >>> discovery approach) >>> >>> XAuth >>> - Client sends an OPTIONS call to the GS URI, Grant URI, or >>> Authorization URI >>> >>> XAuth Rationale: Client can make unauthenticated call to GS URI to lear= n >>> what GS supports, such as authentication mechanisms. Authenticated call= s >>> return what a specific Client can do. >>> >>> >>> =E1=90=A7 >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> --000000000000ee3efc05a150047b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

It might be a misunderstanding= on my part, but the extra complexity I was referring to is that XAuth prov= ides multiple different URIs to communicate with the GS. Depending on the n= ature of the interaction, the client needs to work out whether to use the G= S URI, the Grant URI or the Authorization URI - from a "discovery"= ; perspective, this seems to me more complex than having a single URI.

Happy to be corrected if I've misunderstood.
=


David Skaife

On Fri, Mar 20, 2020= at 8:23 PM Dick Hardt <dick.har= dt@gmail.com> wrote:
To clarify on point 2 made below about XA= uth being more complex:

XAuth has a single URI to = interact with to start, the GS URI.

The Grant URL = is the GS URL=C2=A0+ identifier which seems equivalent to the TxAurh=C2=A0e= ndpoint and transaction handle.

An advantage of th= e Grant URI, is the Client knows which GS it belongs to.

David: would you clarify what you think is more complex in XAuth?

/Dick

On Wed, Mar 18, 2020 at 12:44 PM David Skaife= <blue.ringed.octopus.guy@gmail.com> wrote:
Hi,

M= y thoughts on these different approaches are:

1. For XYZ, it feels a= bit strange and unnecessary to require the client to have to state it'= s full set of capabilities to the AS. It feels like it should be the other = way around - i.e. the client is able to probe what the AS supports. In my v= iew it's more natural for the AS to be "advertising" its capa= bilities rather than the client.

2. I prefer the XYZ approach of hav= ing a single URL that the client knows it needs to interact to start the tr= ansaction, vs the more complex approach=C2=A0provided by XAuth.

3. H= opefully there is a middle ground between the two approaches that addresses= the two points above.


Many thanks,
David Skaife
<= br>
On Mon,= Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery
XYZ
=C2=A0- Client always starts at the tx endpoint, all other= information is dispatched from responses from the endpoint
=C2=A0- Clie= nts sends capabilities list in transaction request, AS selects and returns = which capabilities are supported

XYZ Rationale: client needs a singl= e URL to start talking to an AS, giving developers multiple ways to get inf= ormation is confusing and can lead to serious errors (see OAuth2=E2=80=99s = mix-up attack caused by OIDC=E2=80=99s discovery approach)

XAuth
= =C2=A0- Client sends an OPTIONS call to the GS URI, Grant URI, or Authoriza= tion URI

XAuth Rationale: Client can make unauthenticated call to GS= URI to learn what GS supports, such as authentication mechanisms. Authenti= cated calls return what a specific Client can do.


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ee3efc05a150047b-- From nobody Fri Mar 20 14:46:58 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66B43A0EF5 for ; Fri, 20 Mar 2020 14:46:41 -0700 (PDT) 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_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=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 4W0MZG--20dG for ; Fri, 20 Mar 2020 14:46:39 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0: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 84CC73A0EF3 for ; Fri, 20 Mar 2020 14:46:39 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id k29so7071228ilg.0 for ; Fri, 20 Mar 2020 14:46:39 -0700 (PDT) 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=KBPmR2tsafkWnXTh+aoRDDMINPNUbiajg1pJyIBoNRE=; b=vDSfRYZo+C+pvGiFNal33TuSusBX0iuxt7O2gvYjdlNyE8VmTJjKE6BmvFEcWdm1QX LTqVupJtKdFlAl2haV5vSF1idG9MSzef+8ruIqiYD0GqKGB5E1u2UG0zX3hIhlhpA9aN BVhpf/D1a8bwJP+v2Or3s25Tu229xdY+kPaff0/re2c2d7y4dCNYX/2hVpmwdkwW5er/ 7rithMtg11SfEDBxmQwqkq80MDCZE4p/3YofrNtAjp+59PSDi0nHH/wij6rCUO2KWv1h 3/uouB084Rc9dE/k6guFPUaNBO04yVj4smALpv1yQIaqoebGiH+qWBwF6MUbMKWT7NWO m+bA== 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=KBPmR2tsafkWnXTh+aoRDDMINPNUbiajg1pJyIBoNRE=; b=q1GqlGvLJrOjCYIGsFT/lif+FdRFIumVqW8e/PGA6aJd0VPj+1ak+lf4Qu0TjdZtYS mV0b1E0Rf/c4+bBnaW6EzE8Pgg8YeH5pov3RvOpfLJfDxxctCjYyB3Jy3jI5lyWqMlZX lFGGnhbP1jYvpg+VDTppKD4WBFX6pEfrJmGeumKeEEoTOxIt84Ckt6JDQjXVhSkQndzU FaPsYlEOyqDeldGlHAv6SYLmGisLjYge8Cpq9qJwaoVHZ08mm/FAIf8GlBQJwZmOtY5V cI1FxjiiTMjJByn+kMr/6fBklUlZhAIn5CcBpZsROYJPJlfQUiVuZ+a0TZjo5d74xCP1 3QDQ== X-Gm-Message-State: ANhLgQ2tMGZ6oIiGxkJc1hOdESvLE2pDWsWAI7Brbiaq18kBKgKhM9ah 9KJkntIZG584DQzNrhQXqZJVewbaOW7pZmkMa8A= X-Google-Smtp-Source: ADFU+vvM8woWvJ0vx/0IMoTQz2Fa/9vxKnTq8goKq0dl6pZGrKJ5XbtX7rkP1/Q4QJu765v23HeY9XRCn4T2YJhoyNI= X-Received: by 2002:a92:3958:: with SMTP id g85mr4557209ila.302.1584740798682; Fri, 20 Mar 2020 14:46:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay IETF Date: Sat, 21 Mar 2020 03:16:27 +0530 Message-ID: To: David Skaife Cc: Dick Hardt , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="0000000000005ddc5c05a15038b3" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:46:55 -0000 --0000000000005ddc5c05a15038b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, +1 for XYZ Rationale. I prefer de facto over de jure. My understanding is that the AS is *not* preventing a client implementation to choose a de facto auth method that supports the most common use cases. I see no compelling need for the AS to implement a de jure default since there will eventually be one or two popular and widely used client side implementations that anyway will pick a de facto auth method for their intended users/customers. XYZ rational allows for AS to evolve independently without the burden of supporting a default that may be onerous in constrained environments. --- Vijay PS: I am assuming top post is acceptable in this group. Let me know if that's not the case. On Sat, 21 Mar 2020 at 02:33, David Skaife < blue.ringed.octopus.guy@gmail.com> wrote: > Hi, > > As requested by Dick in the parallel email chain, I'll see if this > response can start to kick off some discussion. > > If I'm understanding this correctly, then the main difference here is the > debate around whether to have a "default" authentication method or not. > Both XYZ and XAuth appear to support having multiple different > authentication methods that the client can use (which I certainly agree i= s > sensible), but for XYZ this is part of the "core" protocol, whereas for > XAuth it's more of an extension. > > My view is that I don't think the argument "*choosing one auth method as > a default makes too many assumptions about client=E2=80=99s nature and de= ployment > capabilities*" is necessarily a valid reason to avoid having a default. > Having a default perhaps makes assumptions about the most *common* use > cases and the most *common *clients, but it certainly doesn't prevent > other more niche clients and use cases from being able to use the protoco= l. > I share the concern raised in the XAuth rationale text that not having a > default mechanism places a burden on the clients to choose, which may be > off-putting or a distraction for some newcomers. I do however think the > availability of different authentication methods should be part of the co= re > protocol, to encourage each AS to implement as many different methods as > possible - which it would be in there interest to do so as it would enabl= e > the AS to support more use cases. > > So in summary, I'm in favour of the protocol supporting multiple differen= t > authentication methods as part of the core protocol, but my preference > would be to have a default selected if the client doesn't want (or need) = to > choose anything different. I don;t think having a default would be > restrictive, and I think when the protocol is eventually > launched/standardised in the future we'll have a clear view of what that > default should be to ensure that it's aligned to the most common use case= s. > > > Many thanks, > David Skaife > > On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote: > >> >> *Client Authentication / Proof of Possession* >> XYZ >> - client proves use of bound keys via general-purpose mechanisms, >> including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS >> - RS access via bearer token or proof-of-possession through any allowabl= e >> key binding mechanism >> >> XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault" makes too= many >> assumptions about client=E2=80=99s nature and deployment capabilities. A= S should >> support as many as it can (and possibly have an MTI requirement), client >> supports whatever method makes the most sense for it. PoP mechanisms for= RS >> should be independent of mechanisms at AS. >> >> XAuth >> - client proves use of bounds keys through an auth mechanism at GS >> - specifies default mechanism using JOSE for GS and RS >> proof-of-possession calls >> - RS access via bearer token just like OAuth 2.0 >> - extensions can define other mechanisms such as HTTP Sig or MTLS to >> replace JOSE for either GS and/or RS calls >> >> XAuth Rationale: having a Client Authentication mechanism defined and as >> default removes burden of selecting mechanism for most deployments, and >> ensures interop. >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000005ddc5c05a15038b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

+1 for = XYZ Rationale. I prefer de facto over de jure.

My understanding is that the AS is *not* preventing a client implementati= on to choose a de facto auth method that supports the most common use cases= .

I see no compelling need for the AS to impl= ement a de jure default since there will eventually be one or two popular a= nd widely used client side implementations that anyway will pick a de facto= auth method for their intended users/customers.

<= div>XYZ rational allows for AS to evolve independently without the burden o= f supporting a default that may be onerous in constrained environments.
=

---
Vijay

PS: = I am assuming top post is acceptable in this group. Let me know if that'= ;s not the case.


On Sat, 21 Mar 2020 at 02:33, Davi= d Skaife <blue.ring= ed.octopus.guy@gmail.com> wrote:
Hi,

As requested by Dick in= the parallel email chain, I'll see if this response can start to kick = off some discussion.

If I'm understanding this c= orrectly, then the main difference here is the debate around whether to hav= e a "default" authentication method or not. Both XYZ and XAuth ap= pear to support having multiple different authentication methods that the c= lient can use (which I certainly agree is sensible), but for XYZ this is pa= rt of the "core" protocol, whereas for XAuth it's more of an = extension.

My view is that I don't think the argument "c= hoosing one auth method as a default makes too many assumptions about clien= t=E2=80=99s nature and deployment capabilities" is necessarily=C2= =A0a valid reason to avoid having a default. Having a default perhaps makes= assumptions about the most common=C2=A0use cases and the most co= mmon clients, but it certainly doesn't prevent other more niche cli= ents and use cases from being able to use the protocol. I share the concern= raised in the XAuth rationale text that not having a default mechanism pla= ces a burden on the clients to choose, which may be off-putting or a distra= ction for some newcomers. I do however think the availability of different = authentication methods should be part of the core protocol, to encourage ea= ch AS to implement as many different methods as possible - which it would b= e in there interest to do so as it would enable the AS to support more use = cases.

So in summary, I'm in favour of the protocol supporting m= ultiple different authentication methods as part of the core protocol, but = my preference would be to have a default selected if the client doesn't= want (or need) to choose anything different. I don;t think having a defaul= t would be restrictive, and I think when the protocol is eventually launche= d/standardised in the future we'll have a clear view of what that defau= lt should be to ensure that it's aligned to the most common use cases.<= /div>


Many thanks,
David Skaife=

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<= b>Client Authentication / Proof of Possession

XYZ
- client pr= oves use of bound keys via general-purpose mechanisms, including detached J= WS, DPoP, OAuth PoP, HTTP Sig, and MTLS
- RS access via bearer token or = proof-of-possession through any allowable key binding mechanism

XYZ = Rationale: choosing one auth method as a =E2=80=9Cdefault" makes too m= any assumptions about client=E2=80=99s nature and deployment capabilities. = AS should support as many as it can (and possibly have an MTI requirement),= client supports whatever method makes the most sense for it. PoP mechanism= s for RS should be independent of mechanisms at AS.

XAuth
- clien= t proves use of bounds keys through an auth mechanism at GS
- specifies = default mechanism using JOSE for GS and RS proof-of-possession calls
- R= S access via bearer token just like OAuth 2.0
- extensions can define ot= her mechanisms such as HTTP Sig or MTLS to replace JOSE for either GS and/o= r RS calls

XAuth Rationale: having a Client Authentication mechanism= defined and as default removes burden of selecting mechanism for most depl= oyments, and ensures interop.
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000005ddc5c05a15038b3-- From nobody Fri Mar 20 14:50:20 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F13A0ED4 for ; Fri, 20 Mar 2020 14:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 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_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 4IxWXGFTgVjY for ; Fri, 20 Mar 2020 14:50:15 -0700 (PDT) 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 5F4CB3A0ED2 for ; Fri, 20 Mar 2020 14:50:15 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id p12so7041092ilm.7 for ; Fri, 20 Mar 2020 14:50:15 -0700 (PDT) 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=VQfKv3+jivlXt/lwImtdU2bjPqHbarfBm/q+lemlU2s=; b=lGsLJBTDun7qbzhrufkX813jrnIxG8hyMc6f3apUam/NxwhtGzXSevhVzdZO2jpIkQ 0frLaHMrhb0lChGGOm8mAxWEqRjl+DqIOd6L/JtIQpxyHYURZLa9DbeBtBMtQ7T8D4w9 c8ywMd2amoQxiPmemuemC9k/iqYWvKfhOQtt5uMuSJjRPagR8Elg4z5dsiRRnu4U3iDq ykm9GXg3aykB8RRq8TktczmZIQcFODwxvv6pfWXI/M10V4fhPqvQC4zs5qh4QY+8L441 PPvG2aPkljv5l7v4lkQjdyOOf6VsOr87fA+evXS8lcCufjGKY7emTJrQjL60/Sw0+sIo lm1w== 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=VQfKv3+jivlXt/lwImtdU2bjPqHbarfBm/q+lemlU2s=; b=j4+icd77qTO/gcDorL+94dCub6qZGDXYitfunSSEjg5W8zCH+c6RSjAuDyzm2sCt6r HQqMOUtCFMBI8kiqMk3BdZdwdv5U2HJlfoykPiJhwtEaTHAcnD/4dHMHSddYaklTbUi+ TEbMB3s3UFU4SNYTMf7DVtSBUDivtVF+vu9isTn3rYZFK9gX9tai9eqnW943lZk9/zT1 WQwr5OcdfT0AmQxGuMCmEE6hwHnLHrzhuv+Zhr5jmlHbYtIApDNWNcXXj7btfuSi0BtK fcEEcwarDG3zeTNF0gLUaxpe9r5/nAKR26CQyULAIllP1uVkfkE/FPkRXA8d6KPYlWbe aMMQ== X-Gm-Message-State: ANhLgQ2b49M/C0OcbzgCZ21ZT8/HFCPbsFrWENDxi5sz1A0xZ/d5dlvj Uo/RU/mwf5tzM1djCjUMbTHTvPVVJKsK0kz1tjo= X-Google-Smtp-Source: ADFU+vviZgVkb6o/RllY+QrERF31DdXipaIPQ/1fK3S3vRhekDNAUBE67B9uz44txJAdiBCKX3euxr8i7P/ZnTiQfJU= X-Received: by 2002:a92:3958:: with SMTP id g85mr4567772ila.302.1584741014565; Fri, 20 Mar 2020 14:50:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay IETF Date: Sat, 21 Mar 2020 03:20:03 +0530 Message-ID: To: Dick Hardt Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="0000000000003bfba705a1504535" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:50:17 -0000 --0000000000003bfba705a1504535 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dick, Super helpful. Thanks for doing this. --- Vijay On Tue, 17 Mar 2020 at 04:35, Dick Hardt wrote: > Hello everyone > > Justin and I have had some emails back and forth comparing and contrastin= g > XYZ and XAuth. I'm going to post a message for each of the major points, > with Justin's rationale and my rationale for our respective design > decisions. Feel free to ask clarifying questions in those threads. > > *Please weigh in with your preference, your rationale, as well as any pro= s > and cons not described.* > > We would like to get a sense for the group's views on these topics for th= e > virtual BoF in a week. > > The latest drafts are: > > XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 > > XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 > > > Thanks! > > /Dick > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000003bfba705a1504535 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

Super helpful. Than= ks for doing this.

---
Vijay

On= Tue, 17 Mar 2020 at 04:35, Dick Hardt <dick.hardt@gmail.com> wrote:
Hello everyone

Justin and I have had some emails back and forth comparing and contrasti= ng XYZ and XAuth. I'm going to post a message for each of the major poi= nts, with Justin's rationale and my rationale for our respective design= decisions.=C2=A0Feel free to ask clarifying questions in those threads.

Please weigh in with your preference, your ration= ale, as well as any pros and cons not described.

We would like to get a sense for the group's views on these to= pics for the virtual BoF in a week.

The latest dra= fts are:

3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000003bfba705a1504535-- From nobody Fri Mar 20 14:52:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1492C3A0ECF for ; Fri, 20 Mar 2020 14:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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=mattr-global.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 XPeVp0_ahBva for ; Fri, 20 Mar 2020 14:51:58 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 EE1163A0ECA for ; Fri, 20 Mar 2020 14:51:57 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id c28so3865845qvb.10 for ; Fri, 20 Mar 2020 14:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jk6LuUMYDJfHj80x1Yd23dVhlxOq55nf1soabPXMmKs=; b=F6595I0PD8+SE7OPkyO5u3aBdM21UYIgIiPMXzC1TLYiAxt6SSy9ZUUFxl+2a4/R9G KpFuHXlQDCDBY9prp/9cXcSM43yQH2q1sS2K4lm0Itxqf+gD6E5x7ZKHa3V1x9CGHHlm OM3OfNGjl+7KLoD6YvtHgBpkyI6OkYXjtM6PrUKpySF3PU0ak/nJ7V+KloTd1fPg6yCK ldZ4I7ECkGGaMA8jOwATFF2acnLPXbRZytKBX2Hp77YtQcbc59qElaWBGuZdJExZhmc+ jLM7myw7mjEB2XjSxpnq907RtpLIOYO6Jy7H0RpOr/yg3Zpx25dmR8y8c6XzXG++yVyR gg2A== 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=Jk6LuUMYDJfHj80x1Yd23dVhlxOq55nf1soabPXMmKs=; b=YAOqGxRse3e3gzlXtAbdWaXRQ1mgAC0fqw6CkdTDGbWky9GOtsnny+XxJfS8ZXtGgo xKYdaf/A9uAHRht66qgd12S9WTxj3mFjWPe8cZthtvCJ/KwFdELfKVYlMwqkKOuv+cv/ fluN+9txMMZ5bJSsw7NqRgjPwW/7R9R/puLrv7/JXPLwCSZ+uwdTTsegHHdxBAcYoFu3 fTSsNYY8k1pztRJJTwou2NGxCi384QgrUF36uGJHL9I1dColuJWViYdJZ+n8cwvmFnpS 4iufqz0bxgrarVZ8IvqU6MfyVSW2ejU7gSpb/Hzy/Ttalyco5I2CTpiorVMHjVK+q/Oz WihQ== X-Gm-Message-State: ANhLgQ23WAntn3wtCakaDEq5lpCes9dlTXRc1Wk40H4A87cR4VTCOZ7w Jl7MCxK/riUQTrt30lgC2zyTWb1IPpLcovsCiyx59Zevxfrcm6WoHnUOUpF0Lq1b0DjJYjyhlsV c7qbLYdY9r/iJfYgL8Q== X-Google-Smtp-Source: ADFU+vuSnnQB2aq75Vgvy62WEy9zpvtN6IaOwp+9WFNaaj9YdAJwfDDWMDhV2Ab57izjIamNWH6rYmTwhZVpn5tUdMo= X-Received: by 2002:ad4:5850:: with SMTP id de16mr10627525qvb.84.1584741116983; Fri, 20 Mar 2020 14:51:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Looker Date: Sat, 21 Mar 2020 10:51:46 +1300 Message-ID: To: Dick Hardt Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="00000000000056d0d105a1504bae" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 21:52:00 -0000 --00000000000056d0d105a1504bae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One of the questions I have about normatively defining a default is what happens if that default becomes vulnerable in time and or the ecosystem moves to a newer approach? Does having the default not cause all parties then to have to carry that legacy? Although not a perfect analogy I think there are some lessons from protocols like TLS that would be relivant here? Would specifying this in a recommended implementation section not act as enough of a forcing function for interoperability but also enable future evolution? Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Tue, Mar 17, 2020 at 12:06 PM Dick Hardt wrote: > > *Client Authentication / Proof of Possession* > XYZ > - client proves use of bound keys via general-purpose mechanisms, > including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS > - RS access via bearer token or proof-of-possession through any allowable > key binding mechanism > > XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault" makes too = many > assumptions about client=E2=80=99s nature and deployment capabilities. AS= should > support as many as it can (and possibly have an MTI requirement), client > supports whatever method makes the most sense for it. PoP mechanisms for = RS > should be independent of mechanisms at AS. > > XAuth > - client proves use of bounds keys through an auth mechanism at GS > - specifies default mechanism using JOSE for GS and RS proof-of-possessio= n > calls > - RS access via bearer token just like OAuth 2.0 > - extensions can define other mechanisms such as HTTP Sig or MTLS to > replace JOSE for either GS and/or RS calls > > XAuth Rationale: having a Client Authentication mechanism defined and as > default removes burden of selecting mechanism for most deployments, and > ensures interop. > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --00000000000056d0d105a1504bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the questions I have about normat= ively defining a default is what happens if that default becomes vulnerable= in time and or the ecosystem moves to a newer approach? Does having the de= fault not cause all parties then to have to carry that legacy? Although not= a perfect analogy I think there are some lessons from protocols like TLS t= hat would be relivant here? Would specifying this in a recommended implemen= tation section not act as enough of a forcing function for interoperability= but also enable future evolution?
=C2=A0
T= hanks,
3D"Mattr=C2=A0
Tobias Looker=
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D=

This communication, inclu= ding any attachments, is confidential. If you are not the intended recipien= t, you should not read it - please contact me immediately, destroy it, and = do not copy or use any part of this communication or disclose anything abou= t it. Thank you. Please note that this communication does not designate an = information system for the purposes of the Electronic Transactions Act 2002= .


On Tue, Mar 17, 2020 at 12:06 PM D= ick Hardt <dick.hardt@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Client Authentication / Proof of Possession

X= YZ
- client proves use of bound keys via general-purpose mechanisms, inc= luding detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
- RS access via= bearer token or proof-of-possession through any allowable key binding mech= anism

XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault&= quot; makes too many assumptions about client=E2=80=99s nature and deployme= nt capabilities. AS should support as many as it can (and possibly have an = MTI requirement), client supports whatever method makes the most sense for = it. PoP mechanisms for RS should be independent of mechanisms at AS.
XAuth
- client proves use of bounds keys through an auth mechanism at G= S
- specifies default mechanism using JOSE for GS and RS proof-of-posses= sion calls
- RS access via bearer token just like OAuth 2.0
- extensi= ons can define other mechanisms such as HTTP Sig or MTLS to replace JOSE fo= r either GS and/or RS calls

XAuth Rationale: having a Client Authent= ication mechanism defined and as default removes burden of selecting mechan= ism for most deployments, and ensures interop.
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--00000000000056d0d105a1504bae-- From nobody Fri Mar 20 15:03:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0046F3A0EDE for ; Fri, 20 Mar 2020 15:03:07 -0700 (PDT) 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_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=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 RbQ6Abaz8zB9 for ; Fri, 20 Mar 2020 15:03:05 -0700 (PDT) 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 D55413A0EDC for ; Fri, 20 Mar 2020 15:03:04 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id i1so5049142lfo.1 for ; Fri, 20 Mar 2020 15:03:04 -0700 (PDT) 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=oE0vbeMmCZa5JyVeZUh8LG3jqLEmTs7JUpeJsC64Jxg=; b=NGgJxlPMka/8odHmJh7q4LeuLEmLMH8L6/m3Scwk3EJT+fYqHwxZxuE9bdkud795Up f9OtYeWtHk61ZrmKVaybMAz7vQghuo00Ma9WXX0yxkDEjWsNOZ7STLLvRfvYeUuEbzph mX/nJfgSqyzCFS4XCH26FKJ8chzIm4rCL3SdLMfiw/S+G+Y4lIJAs97eKiQ4vYNvLB95 pk3ixGpOr6yXPLvtCut7Kqtxp3epbS0CcG1A1sePkioQgz9lGuB4Ts3FJB8eHft1gn0t fPVIheDpDroUOtFv1h3Xks6KeyvhHt319bHuhJmeMbUxseT7rfmhqE47765ZvELaW3Y6 KD9g== 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=oE0vbeMmCZa5JyVeZUh8LG3jqLEmTs7JUpeJsC64Jxg=; b=hRjE1Ls0IK1gPS/b59qKDx3BDo2tTZEM5Dcv233khbvO9Xdd/rg7+RmeW48uRl7RdI tC+LuUFseM7oh3LcHUM+ZaqUr0FEUbkeZpCv8jsjfcIJs4qBsvMPAylO7/uI/44nehyF SYkZJrhp1z2dz54a5xclMDzRyHnFtAivLXwfAvg2l5kG8u6tMwroT8WhR0LQtX9d4JiF Z2dYNHPHma5KU8RQwr3rHGFfRV2fg2kPS06oIET+b0yvBrDiRM/5ta06XnHbjsf1/b9m Bjpgsp1KzuQlQRwtdXUDQMvLNwZ2CgBhb6ZtmwMUSeD875loiAbVzp+JwJ+dS3HLGp70 EWbg== X-Gm-Message-State: ANhLgQ1T/hftHqwnO7rDOF2HbfYKnuepytFAfZP3QJ4vZGLt1vzCbTyk WoIKgTqE+7jng16oRGR3uJT3y7uijcZxTBLQhg0= X-Google-Smtp-Source: ADFU+vsE6J3Ohyop3WH1YDVbjr4kDuq39B5GO6eN++RjjqwG4eqiIMjUex5RcVll2CStWtmiUEBf/uwGMCIjJjjKun4= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr1022817lfm.91.1584741782750; Fri, 20 Mar 2020 15:03:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 15:02:36 -0700 Message-ID: To: David Skaife Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000058b6705a1507335" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Discovery X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 22:03:07 -0000 --000000000000058b6705a1507335 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the clarification! All GS information would be discovered off the GS URI with an OPTIONS call. The results may be different if the client has authenticated. In case it was useful, the GS could support an OPTIONS call for each Grant URI that was issued to allow the Client to discovery what could be done with a given Grant. Similarly if it was useful to allow discovery on a specific Authorization. On Fri, Mar 20, 2020 at 2:32 PM David Skaife < blue.ringed.octopus.guy@gmail.com> wrote: > Hi Dick, > > It might be a misunderstanding on my part, but the extra complexity I was > referring to is that XAuth provides multiple different URIs to communicat= e > with the GS. Depending on the nature of the interaction, the client needs > to work out whether to use the GS URI, the Grant URI or the Authorization > URI - from a "discovery" perspective, this seems to me more complex than > having a single URI. > > Happy to be corrected if I've misunderstood. > > > David Skaife > > On Fri, Mar 20, 2020 at 8:23 PM Dick Hardt wrote: > >> To clarify on point 2 made below about XAuth being more complex: >> >> XAuth has a single URI to interact with to start, the GS URI. >> >> The Grant URL is the GS URL + identifier which seems equivalent to the >> TxAurh endpoint and transaction handle. >> >> An advantage of the Grant URI, is the Client knows which GS it belongs t= o. >> >> David: would you clarify what you think is more complex in XAuth? >> >> /Dick >> >> On Wed, Mar 18, 2020 at 12:44 PM David Skaife < >> blue.ringed.octopus.guy@gmail.com> wrote: >> >>> Hi, >>> >>> My thoughts on these different approaches are: >>> >>> 1. For XYZ, it feels a bit strange and unnecessary to require the clien= t >>> to have to state it's full set of capabilities to the AS. It feels like= it >>> should be the other way around - i.e. the client is able to probe what = the >>> AS supports. In my view it's more natural for the AS to be "advertising= " >>> its capabilities rather than the client. >>> >>> 2. I prefer the XYZ approach of having a single URL that the client >>> knows it needs to interact to start the transaction, vs the more comple= x >>> approach provided by XAuth. >>> >>> 3. Hopefully there is a middle ground between the two approaches that >>> addresses the two points above. >>> >>> >>> Many thanks, >>> David Skaife >>> >>> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt >>> wrote: >>> >>>> >>>> *Discovery* >>>> XYZ >>>> - Client always starts at the tx endpoint, all other information is >>>> dispatched from responses from the endpoint >>>> - Clients sends capabilities list in transaction request, AS selects >>>> and returns which capabilities are supported >>>> >>>> XYZ Rationale: client needs a single URL to start talking to an AS, >>>> giving developers multiple ways to get information is confusing and ca= n >>>> lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused by O= IDC=E2=80=99s >>>> discovery approach) >>>> >>>> XAuth >>>> - Client sends an OPTIONS call to the GS URI, Grant URI, or >>>> Authorization URI >>>> >>>> XAuth Rationale: Client can make unauthenticated call to GS URI to >>>> learn what GS supports, such as authentication mechanisms. Authenticat= ed >>>> calls return what a specific Client can do. >>>> >>>> >>>> =E1=90=A7 >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> --000000000000058b6705a1507335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarification!

All GS in= formation would be discovered off the GS URI with an OPTIONS call. The resu= lts may be different if the client has authenticated.

<= div>In case it was useful, the GS could support an OPTIONS call for each Gr= ant URI that was issued to allow the Client to discovery what could be done= with a given Grant.

Similarly if it was useful to= allow discovery on a specific Authorization.

On Fri, Mar 20, 2020 at = 2:32 PM David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:
Hi Dick,

It might be a misunderstanding on my part, but the extra complexity I= was referring to is that XAuth provides multiple different URIs to communi= cate with the GS. Depending on the nature of the interaction, the client ne= eds to work out whether to use the GS URI, the Grant URI or the Authorizati= on URI - from a "discovery" perspective, this seems to me more co= mplex than having a single URI.

Happy to be correc= ted if I've misunderstood.


Davi= d Skaife

On Fri, Mar 20, 2020 at 8:23 PM Dick Hardt <dick.hardt@gmail.com> = wrote:
To clarify on point 2 made below about XAuth being more compl= ex:

XAuth has a single URI to interact with to sta= rt, the GS URI.

The Grant URL is the GS URL=C2=A0+= identifier which seems equivalent to the TxAurh=C2=A0endpoint and transact= ion handle.

An advantage of the Grant URI, is the = Client knows which GS it belongs to.

David: would = you clarify what you think is more complex in XAuth?

/Dick

On Wed, Mar 18, 2020 at 12:44 PM David Skaife <blue.ringed.octopus.g= uy@gmail.com> wrote:
Hi,

My thoughts on these di= fferent approaches are:

1. For XYZ, it feels a bit strange and unnec= essary to require the client to have to state it's full set of capabili= ties to the AS. It feels like it should be the other way around - i.e. the = client is able to probe what the AS supports. In my view it's more natu= ral for the AS to be "advertising" its capabilities rather than t= he client.

2. I prefer the XYZ approach of having a single URL that = the client knows it needs to interact to start the transaction, vs the more= complex approach=C2=A0provided by XAuth.

3. Hopefully there is a mi= ddle ground between the two approaches that addresses the two points above.=


Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06= PM Dick Hardt <dick.hardt@gmail.com> wrote:
Discovery

XYZ
=C2= =A0- Client always starts at the tx endpoint, all other information is disp= atched from responses from the endpoint
=C2=A0- Clients sends capabiliti= es list in transaction request, AS selects and returns which capabilities a= re supported

XYZ Rationale: client needs a single URL to start talki= ng to an AS, giving developers multiple ways to get information is confusin= g and can lead to serious errors (see OAuth2=E2=80=99s mix-up attack caused= by OIDC=E2=80=99s discovery approach)

XAuth
=C2=A0- Client sends= an OPTIONS call to the GS URI, Grant URI, or Authorization URI

XAut= h Rationale: Client can make unauthenticated call to GS URI to learn what G= S supports, such as authentication mechanisms. Authenticated calls return w= hat a specific Client can do.


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000058b6705a1507335-- From nobody Fri Mar 20 16:15:06 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E3E3A0F3A for ; Fri, 20 Mar 2020 16:15:00 -0700 (PDT) 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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=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 7QA5pgQzFT6B for ; Fri, 20 Mar 2020 16:14:49 -0700 (PDT) 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 A22BF3A0F38 for ; Fri, 20 Mar 2020 16:14:48 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id c5so391862lfp.5 for ; Fri, 20 Mar 2020 16:14:48 -0700 (PDT) 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=IvHPhzqqehX1KZf3Ywx+VRWJ7WF09QHAc14B8f8kBUk=; b=MK8dmNaK/Xi/72tz5csdfwWGfXKZbFfNBObPmXMt4tfMrOdVlXMoJwIYa/8M8AGpja BtP3GHuZysNDPcsMcoiXLI9X80HAAyHOWQgCzJh2oyTQpfcIufO9s+d72oTObsH3YcdY Y4HDOdth/sZsxG+QlVTbDBMv4pcWQV86aG7n9Kc66dxP7GGyeYVTCfx89WuU0zL0SVHB 7/a4sg69U4y3hkFZs3zJBJDgx5uXF/GYs/kRQIdeEPiiDaZ8mlRR5rL8TFgvzIA2tY4u pQLFr2pu154dySMwju4eOhiAS0zpuAMnYKCe1wz2c6tVvYarPnfXJGcZHWxPgqHZfxek PRSA== 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=IvHPhzqqehX1KZf3Ywx+VRWJ7WF09QHAc14B8f8kBUk=; b=WdJ+Jen4RA3V2D0yfoRpYFjaDA8IcrUyDiD6dQfTqaAAlVaFcXLu6hSRvmkOopdZlQ JN5eY4ixkh+YoAqXYE/OtCTMxX4Z7PKSghteHBQjZpEWZjaxSA0Gje/mGBzsL7DPMIS1 yua2Hr+HuMe3IMuOj23UrAPTtwyKlBSr1Jryr+9CpN/JJKLV1754dlEBBfWkuUWI6B3a genWii698Bk2A9D3GF1yCk8yG5VCbUQJoGFGCHJXHf+vevY5ozUA5nEumdewj7Udye62 fYIE7Jxs5ZzAiJPIFNfejioKU0pv++bclA+X+FjPLL+7JV7Vhzc9pgO8pa3vYIfOsMFU +Xog== X-Gm-Message-State: ANhLgQ2JVZ01aQHIe6NIaX5mT+nHAeVY/8fmj4GFoHkIKM4JkhlNv+Rk ui1WBfBuKeRLiCVm5KLQD9K0ygrGdLa65Tnbw7BGWsK4IFStgjSWP3DuYbU+JLy3B7p7G5PVqdh ByfheUq2u0qrtQyW9htAF X-Google-Smtp-Source: ADFU+vsgWRvanucYt/5/HtDfxJU9S0NLWqQrq4cLWTEUqXQR7CN5nGFD55n6oCzm5682VTGhFyGE81OHeBOAZI75uRg= X-Received: by 2002:ac2:5465:: with SMTP id e5mr6638670lfn.210.1584746085847; Fri, 20 Mar 2020 16:14:45 -0700 (PDT) MIME-Version: 1.0 References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> In-Reply-To: From: Brian Campbell Date: Fri, 20 Mar 2020 17:14:19 -0600 Message-ID: To: Kim Cc: Torsten Lodderstedt , "txauth@ietf.org" , Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary="00000000000081b2e305a1517382" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 23:15:01 -0000 --00000000000081b2e305a1517382 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've previously expressed concern about this endeavour and the ramifications of even the perception that there is work underway to create a successor to OAuth and/or OIDC. Unquestionably those protocols have their problems (on many levels) but I remain highly skeptical that developing something completely new is the right thing to do or that it will improve the situation at large. With that said, I do realize there are folks here that are excited about the prospect of working on this and that there's now momentum behind the creation of a WG, so my concerns are likely moot anyway. And due to circumstances, I'm rather compelled to try and follow the work and so will endeavor to contribute to the extent I can. As a meta point, I do think that having a more focused and better shared understanding of the goals and desired outcome would be valuable. For me personally, when reading the charter and trying to follow some of the email, it doesn't seem like it's there yet. I tend to agree with Justin about the lack of longer term value and eventual maintenance debt in use-case or architecture documents. So I wouldn't go so far as to suggest that that be a deliverable But I do think that doing something more to drive to censuses and shared understanding of the problems to be solved would be useful (including but not limited to "identity" being in or out of scope) before comparisons of XYZ and X or discussions of what a particular bit of JSON might look like. My apologies to Yaron, but my answers to questions 1), 2), 3) and 4) are kinda buried in that little rant somewhere. On Fri, Mar 20, 2020 at 3:08 PM Kim wrote: > I very much agree with Torsten's proposal and think it provides a way to > focus TxAuth's initiatives on solving the many and deep problems of the > authorization layer by better integrating it with the claims based model = of > identity. > > It is also clear to me that there is zero consensus that TxAuth should be > chartered to be a replacement for all existing identity technology. > > Instead, there is wide consensus that TxAuth should integrate the claims > based model into the authorization layer and attack the many unsolved > problems we have experienced with increasingly interdependent networks of > interacting services . > > Surely doing so is an immense task and a sufficient mandate. Meanwhile, > when people working on authorization encounter defects in existing identi= ty > protocols, those protocols should be fixed so the improvements accrue to > all of the layers that are dependent on claims, not just authorization. > > Identity in general has big problems that remain to be solved. But as th= e > digital sphere expands the greatest of these is that of creating a holist= ic > identity layer that serves the needs we have as human beings as well as i= t > serves those who operate digital enterprises. Identity technology will > have to embrace much more than protocols for exchanging claims and decidi= ng > whether to trust them. How can TxAuth possibly succeed at solving the > difficult problems of authorization while at the same time taking on this > other vast set of hard problems? > > It is far better for TxAuth to limit its scope to the kinds of initiative= s > proposed by Torsten and to prevail upon entities such as OIDC to correct > any deficiencies that prevent their work from being reused in the > authorization layer rather than reinventing everything. > > I also agree with the comments and proposals made by Nat, Mike Jones and > Vittorio. If consensus is really being sought, focusing on the > authorization layer and its use of claims rather than all of identity wil= l > certainly bring it about. > > Best regards, > > Kim Cameron > > > -----Original Message----- > From: Txauth On Behalf Of Torsten Lodderstedt > Sent: Thursday, March 19, 2020 12:09 PM > To: txauth@ietf.org > Cc: Vladimir Dzhuvinov > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > > Hi all, > > I suggest to add the following requirement to the charter: > =E2=80=A2 Support for RS-specific access tokens in Multi-RS deplo= yments > > I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I want = to make > sure we try to build a protocol that serves the needs of a broad set of > deployments. My concern is otherwise TXAuth will be not innovative enough > to gain traction in the market rapidly. Speaking for myself, I realised i= n > the last couple of days, mostly in conversations with Justin, that the > result of this working group as envisioned now is not of particular > interest to us (yes.com) because it does not solve our real problems. > > And here is my explanation: > > OAuth traditionally has the philosophy of a single access token. That=E2= =80=99s > fine for single service deployments, but it had reached its limits alread= y > before RFC6749 was published. There are a real implementations out there > forcing clients to use different access tokens for different services, > typically for privacy and security reasons. There is also an =E2=80=9Canc= ient" > technology called Kerberos that uses exactly this pattern and is well kno= wn > for security, performance, and scalability. > > And there are even more examples today for multi API environments that > would benefit from that feature: > =E2=80=A2 Open banking: most banks I worked with have multiple AP= Is, > segregation between APIs is today achieved by maintaining different grant= s, > basically resulting in the fact that the users cannot consent to differen= t > services at once. What a terrible UX! > =E2=80=A2 Everyone is doing micro services today. Have you every = thought > about the coupling caused by a single token across micro services? This > reminds me of how easy it is to test services independently using > self-contained RS-specific tokens. > =E2=80=A2 IoT - every device in a household is a potential RS (in= my > opinion). Conveying all necessary data in an access token needed to meet > access control decisions locally would be a huge benefit in terms of > performance and decoupling. Using symmetric cryptography for token > integrity, authenticity and confidentiality would result in lower compute > requirements. > > Since we are preparing to define a completely new protocol for API access > authorization and delegation, I think this new protocol should support th= is > kind of scenarios. It will require significant work to get it right and > simple, but if we just stick to the =E2=80=9Ca single access token is eno= ugh=E2=80=9D > mantra, we miss the chance to give implementers a broader range of design > choices out of the box and we won=E2=80=99t success in achieving true > interoperability. > > Here are more advantages we can gain by supporting such a feature: > =E2=80=A2 Privacy: > =E2=80=A2 A single access token can be used to track user= across > services. > =E2=80=A2 RS-specific access tokens cannot. > =E2=80=A2 RS-specific access tokens can also be encrypted= to > protect data confidentiality in transit. > =E2=80=A2 Security: RS-specific access tokens have a baseline rep= lay > detection. > =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey > all data required to authorize an API call in a token (e.g. a JWT) and to > RS to meet the access control decision based on that data. This is a huge > advantage in terms of performance, scalability and cost since there is no > need for Token Introspection or other kinds of access to another services > or database. > > What do you think? > > best regards, > Torsten. > > > On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov > wrote: > > > > > > On 19/03/2020 19:11, Torsten Lodderstedt wrote: > >> On 19. Mar 2020, at 17:47, Justin Richer wrote: > >>> Well, it=E2=80=99s in scope as much as describing any other aspect of= what the > token is for and what it represents is in scope. That is alongside things > like the intended audience of the token, the access rights for the token, > the presentation keys the token is bound to, etc. It could be information > in the token text itself (like a JWT), it could be introspected from the > AS, it could be referenced in some other way. So if we can define identit= y > aspects in that, then we=E2=80=99re fine in covering it there. > >>> > >>> But here=E2=80=99s the thing: none of that has an impact on the core = protocol. > That is entirely up to the AS and the RS to agree on, and the client neve= r > sees or has any influence on it. That portion of the protocol is complete= ly > opaque to the client. Therefore, it doesn=E2=80=99t really affect the aut= horization > and delegation portions of the client talking to the AS and the client > talking to the RS. > >>> > >>> This does raise the question of what our bar of interoperability is > going to be with TxAuth: do we expect independent AS and RS implementatio= ns > to talk to each other? That=E2=80=99s not something OAuth 2 was ever conc= erned > with, though obviously JWT and introspection are both from the OAuth2 WG > and solve that problem. > >> There are two aspects to it: interoperability and vendor support. > >> > >> Interoperability between AS and RS is important if deployments want to > combine pre-packaged TXAuth and API implementations. I think that makes a > lot of sense and should be included in the charter. > > > > +1 > > > > The current OAuth 2.0 status quo of the largely unspecified > > relationship between AS and RS is also making the life of web & sec > > framework maintainers difficult. We witnessing this with people > > integrating the OAuth SDK into frameworks. Vittorio's recent work to > > put together a minimal interoperable JWT profile for access tokens is > > helpful, but it has come after the fact. And there is not agreement on > > things like authorising access to claims. > > > > Integrating apps (RSs) with TxAuth should be straightforward and simple= . > > > > This can have a enormous effect on adoption. > > > > > >> Vendors support: vendor support when it comes to "what can go into an > access token" and "what can be conveyed in a token introspection response= =E2=80=9D > greatly deviates in my observation. This also means implementation use > vendors specific features restricting their ability to use other solution= s. > TXAuth should aim at improving the situation. > > > > +1 > > > > > >> I also think it is a good exercise for the group to think the whole > process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not = to provide > clients with access tokens. The purpose is to enable API request processi= ng > in a secure manner. What it really takes to achieve that goal is not > obvious if the work always stops at the =E2=80=9Cyou have your access tok= en, good > luck=E2=80=9D stage. > > > > +1 > > > > Vladimir > > > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=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._ --00000000000081b2e305a1517382 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've previously expressed concern about this ende= avour and the ramifications of even the perception that there is work under= way to create a successor to OAuth an= d/or OIDC. Unquestionably those protocols have their problems (on many lev= els) but I remain highly skeptical th= at developing something completely new is the right thing to do or that it = will improve the situation at large. With that said, I do realize there are= folks here that are excited about the prospect of working on this and that= there's now momentum behind the creation of a WG, so my concerns are likely moot anyway. And due to circums= tances, I'm rather compelled to try and follow the work and so will end= eavor to contribute to the extent I can.

As = a meta point, I do think that having a more focused and better shared under= standing of the goals and desired outcome would be valuable. For me persona= lly, when reading the charter and trying to follow some of the email, it do= esn't seem like it's there yet. I tend to agree with Justin about t= he lack of longer term value and eventual maintenance debt in use-case or a= rchitecture documents. So I wouldn't go so far as to suggest that that = be a deliverable=C2=A0 But I do think that doing something more to drive to= censuses and shared understanding of the problems to be solved would be us= eful (including but not limited to "identity" being in or out of = scope) before comparisons of=C2=A0 XYZ and X or discussions of what a parti= cular bit of JSON might look like.

My apologie= s to Yaron, but my answers to questions 1), 2), 3) and 4) are kinda buried = in that little rant somewhere. =C2=A0

On Fri, Mar 20, 2020 at 3:08 PM= Kim <kim@iden= tityblog.com> wrote:
I very much agree with Torsten's proposal and think it prov= ides a way to focus TxAuth's initiatives on solving the many and deep p= roblems of the authorization layer by better integrating it with the claims= based model of identity.=C2=A0

It is also clear to me that there is zero consensus that TxAuth should be c= hartered to be a replacement for all existing identity technology.=C2=A0
Instead, there is wide consensus that TxAuth should integrate the claims ba= sed model into the authorization layer and attack the many unsolved problem= s we have experienced with increasingly interdependent networks of interact= ing services .=C2=A0

Surely doing so is an immense task and a sufficient mandate.=C2=A0 Meanwhil= e, when people working on authorization encounter defects in existing ident= ity protocols, those protocols should be fixed so the improvements accrue t= o all of the layers that are dependent on claims, not just authorization. <= br>
Identity in general has big problems that remain to be solved.=C2=A0 But as= the digital sphere expands the greatest of these is that of creating a hol= istic identity layer that serves the needs we have as human beings as well = as it serves those who operate digital enterprises.=C2=A0 Identity technolo= gy will have to embrace much more than protocols for exchanging claims and = deciding whether to trust them.=C2=A0 How can TxAuth possibly succeed at so= lving the difficult problems of authorization while at the same time taking= on this other vast set of hard problems?

It is far better for TxAuth to limit its scope to the kinds of initiatives = proposed by Torsten and to prevail upon entities such as OIDC to correct an= y deficiencies that prevent their work from being reused in the authorizati= on layer rather than reinventing everything.

I also agree with the comments and proposals made by Nat, Mike Jones and Vi= ttorio.=C2=A0 If consensus is really being sought, focusing on the authoriz= ation layer and its use of claims rather than all of identity will certainl= y bring it about.

Best regards,

Kim Cameron


-----Original Message-----
From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
Sent: Thursday, March 19, 2020 12:09 PM
To: txauth@ietf.org
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

Hi all,

I suggest to add the following requirement to the charter:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Support for RS-specific access tokens= in Multi-RS deployments

I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I want to= make sure we try to build a protocol that serves the needs of a broad set = of deployments. My concern is otherwise TXAuth will be not innovative enoug= h to gain traction in the market rapidly. Speaking for myself, I realised i= n the last couple of days, mostly in conversations with Justin, that the re= sult of this working group as envisioned now is not of particular interest = to us (yes.= com) because it does not solve our real problems.

And here is my explanation:

OAuth traditionally has the philosophy of a single access token. That=E2=80= =99s fine for single service deployments, but it had reached its limits alr= eady before RFC6749 was published. There are a real implementations out the= re forcing clients to use different access tokens for different services, t= ypically for privacy and security reasons. There is also an =E2=80=9Cancien= t" technology called Kerberos that uses exactly this pattern and is we= ll known for security, performance, and scalability.

And there are even more examples today for multi API environments that woul= d benefit from that feature:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Open banking: most banks I worked wit= h have multiple APIs, segregation between APIs is today achieved by maintai= ning different grants, basically resulting in the fact that the users canno= t consent to different services at once. What a terrible UX!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Everyone is doing micro services toda= y. Have you every thought about the coupling caused by a single token acros= s micro services? This reminds me of how easy it is to test services indepe= ndently using self-contained RS-specific tokens.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 IoT - every device in a household is = a potential RS (in my opinion). Conveying all necessary data in an access t= oken needed to meet access control decisions locally would be a huge benefi= t in terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower com= pute requirements.

Since we are preparing to define a completely new protocol for API access a= uthorization and delegation, I think this new protocol should support this = kind of scenarios. It will require significant work to get it right and sim= ple, but if we just stick to the =E2=80=9Ca single access token is enough= =E2=80=9D mantra, we miss the chance to give implementers a broader range o= f design choices out of the box and we won=E2=80=99t success in achieving t= rue interoperability.

Here are more advantages we can gain by supporting such a feature:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Privacy:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 A single = access token can be used to track user across services.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 RS-specif= ic access tokens cannot.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 RS-specif= ic access tokens can also be encrypted to protect data confidentiality in t= ransit.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Security: RS-specific access tokens h= ave a baseline replay detection.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Performance: RS-specific access token= s allow the AS to convey all data required to authorize an API call in a to= ken (e.g. a JWT) and to RS to meet the access control decision based on tha= t data. This is a huge advantage in terms of performance, scalability and c= ost since there is no need for Token Introspection or other kinds of access= to another services or database.

What do you think?

best regards,
Torsten.

> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov <vladimir@connect2id.com> wr= ote:
>
>
> On 19/03/2020 19:11, Torsten Lodderstedt wrote:
>> On 19. Mar 2020, at 17:47, Justin Richer <jricher@mit.edu> wrote:
>>> Well, it=E2=80=99s in scope as much as describing any other as= pect of what the token is for and what it represents is in scope. That is a= longside things like the intended audience of the token, the access rights = for the token, the presentation keys the token is bound to, etc. It could b= e information in the token text itself (like a JWT), it could be introspect= ed from the AS, it could be referenced in some other way. So if we can defi= ne identity aspects in that, then we=E2=80=99re fine in covering it there. =
>>>
>>> But here=E2=80=99s the thing: none of that has an impact on th= e core protocol. That is entirely up to the AS and the RS to agree on, and = the client never sees or has any influence on it. That portion of the proto= col is completely opaque to the client. Therefore, it doesn=E2=80=99t reall= y affect the authorization and delegation portions of the client talking to= the AS and the client talking to the RS.
>>>
>>> This does raise the question of what our bar of interoperabili= ty is going to be with TxAuth: do we expect independent AS and RS implement= ations to talk to each other? That=E2=80=99s not something OAuth 2 was ever= concerned with, though obviously JWT and introspection are both from the O= Auth2 WG and solve that problem.
>> There are two aspects to it: interoperability and vendor support. =
>>
>> Interoperability between AS and RS is important if deployments wan= t to combine pre-packaged TXAuth and API implementations. I think that make= s a lot of sense and should be included in the charter.
>
> +1
>
> The current OAuth 2.0 status quo of the largely unspecified
> relationship between AS and RS is also making the life of web & se= c
> framework maintainers difficult. We witnessing this with people
> integrating the OAuth SDK into frameworks. Vittorio's recent work = to
> put together a minimal interoperable JWT profile for access tokens is =
> helpful, but it has come after the fact. And there is not agreement on=
> things like authorising access to claims.
>
> Integrating apps (RSs) with TxAuth should be straightforward and simpl= e.
>
> This can have a enormous effect on adoption.
>
>
>> Vendors support: vendor support when it comes to "what can go= into an access token" and "what can be conveyed in a token intro= spection response=E2=80=9D greatly deviates in my observation. This also me= ans implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation.=C2=A0=
>
> +1
>
>
>> I also think it is a good exercise for the group to think the whol= e process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is= not to provide clients with access tokens. The purpose is to enable API re= quest processing in a secure manner. What it really takes to achieve that g= oal is not obvious if the work always stops at the =E2=80=9Cyou have your a= ccess token, good luck=E2=80=9D stage.
>
> +1
>
> Vladimir
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

<= 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. --00000000000081b2e305a1517382-- From nobody Fri Mar 20 17:30:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00F3A1003 for ; Fri, 20 Mar 2020 17:30:28 -0700 (PDT) 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_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=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 sUZrmLjomH64 for ; Fri, 20 Mar 2020 17:30:25 -0700 (PDT) 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 1E2963A0FDF for ; Fri, 20 Mar 2020 17:30:25 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id a43so9297111edf.6 for ; Fri, 20 Mar 2020 17:30:25 -0700 (PDT) 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=r7FRVEmgSj+VMDmPeIEYG6i7qo5ln6bvgftZimalarI=; b=HaP0sPZkV7kq9+KSrTiS1MFhfgJIqVrqCsN/ETBFrNwo06WPF3OuT6AxXeyoExcA79 LqZsD3Tr2i8r1OmK7hAEb3pe0y+UxximuYwZEjkG3Q/KN8zTfqND950uazne6Ku5Spba oiDG/qw/6R7I6KOUyvIS8BqHfd3VC0IHFxgrW5ChyynVfy4fgjqL1C1nyVDLaQnkdxWl +lADFKBpBcrAI40aNn34c02TwyAwjcebBjMV5IF0nJbLo2ZFgHgtEa2JMXQRNrJj25D+ 1BtxzSLKJG9fXvuiGMCzb4t1n82hMJutS6v+rJm5FHnQY4YM3LA8Neya+HXpYsLBc9VZ pu2g== 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=r7FRVEmgSj+VMDmPeIEYG6i7qo5ln6bvgftZimalarI=; b=k4aKhA8lpK/357eotRX2r2RMW1qf/V1OGFqwrcFw7sZs+J/UpLo25ciOWTauZq7lCF nFAtIrJX1XXp2CdGESNzm0sNGj0noZvaM2E13N3WlBPPlZSPpBemy4Jpr6WpJaYduCzv Uax5dJMI/g+Lbb9hXF0lpawS8Mr7QbiivCPeGBzRFWrfEubhp8TDfIqRs6QGAcm9WkD3 MJEu5M/dsnNPK5rYHzz/kTizjOw98XLSTAxi3bpyuKGQS3HGqqZFZ9GOhOX/V7VjGWQh NChoZQYJeUTOne0Cw2+yyorBycnxVmkO/dt1bb3K6TfVq053IWI4RWa4jgrn0FbmfMty YtnA== X-Gm-Message-State: ANhLgQ0al0GE/XItxDUdIcwMdpP+s56iHYdH/z4XiUZf74P1Z0zkPtPd sdSApK1buWe6vGXQGXhaSi58cjX8EXOJhxpg8Fg= X-Google-Smtp-Source: ADFU+vvwfD5IbjHpG+fQakBa6h2av6wqIpjnsWAeYVXYANG6PpxDP7i4o2bAiLFiQ7RwlcR1367BGkIvqMa93dRwOpw= X-Received: by 2002:a17:906:374e:: with SMTP id e14mr10616858ejc.194.1584750623358; Fri, 20 Mar 2020 17:30:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 17:29:55 -0700 Message-ID: To: Vijay IETF Cc: David Skaife , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000f682e905a1528124" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 00:30:39 -0000 --000000000000f682e905a1528124 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vijay wrt. constrained environments, as I noted in XAuth https://tools.ietf.org/html/draft-hardt-xauth-protocol-05#section-11 Constrained environments could use CBOR [RFC7049] instead of JSON, and COSE [RFC8152] instead of JOSE, and CoAP [RFC8323] instead of HTTP/2. I would NOT expect a constrained environment to use the same mechanisms that others use, for the same reasons CBOR, COSE, and CoAP exist. wrt. a de jure default, it is not any more de jure than JSON, JOSE, or MTLS= . Both XYZ and XAuth use JSON for payloads and HTTPS for transport. For some environments, MTLS will be a better choice, for others, JOSE will be a better choice. Myself, I think JOSE is easier for most environments (I'm not including constrained environments in this argument for the reasons above) -- but I would also be ok with a different mechanism as the default. If all choices are equal (no default), then ALL the choices have to be implemented in a general purpose implementation, which increases the attack surface and vulnerability of an implementation, ie a coding error. On Fri, Mar 20, 2020 at 2:46 PM Vijay IETF wrote: > Hi, > > +1 for XYZ Rationale. I prefer de facto over de jure. > > My understanding is that the AS is *not* preventing a client > implementation to choose a de facto auth method that supports the most > common use cases. > > I see no compelling need for the AS to implement a de jure default since > there will eventually be one or two popular and widely used client side > implementations that anyway will pick a de facto auth method for their > intended users/customers. > > XYZ rational allows for AS to evolve independently without the burden of > supporting a default that may be onerous in constrained environments. > > --- > Vijay > > PS: I am assuming top post is acceptable in this group. Let me know if > that's not the case. > > > On Sat, 21 Mar 2020 at 02:33, David Skaife < > blue.ringed.octopus.guy@gmail.com> wrote: > >> Hi, >> >> As requested by Dick in the parallel email chain, I'll see if this >> response can start to kick off some discussion. >> >> If I'm understanding this correctly, then the main difference here is th= e >> debate around whether to have a "default" authentication method or not. >> Both XYZ and XAuth appear to support having multiple different >> authentication methods that the client can use (which I certainly agree = is >> sensible), but for XYZ this is part of the "core" protocol, whereas for >> XAuth it's more of an extension. >> >> My view is that I don't think the argument "*choosing one auth method as >> a default makes too many assumptions about client=E2=80=99s nature and d= eployment >> capabilities*" is necessarily a valid reason to avoid having a default. >> Having a default perhaps makes assumptions about the most *common* use >> cases and the most *common *clients, but it certainly doesn't prevent >> other more niche clients and use cases from being able to use the protoc= ol. >> I share the concern raised in the XAuth rationale text that not having a >> default mechanism places a burden on the clients to choose, which may be >> off-putting or a distraction for some newcomers. I do however think the >> availability of different authentication methods should be part of the c= ore >> protocol, to encourage each AS to implement as many different methods as >> possible - which it would be in there interest to do so as it would enab= le >> the AS to support more use cases. >> >> So in summary, I'm in favour of the protocol supporting multiple >> different authentication methods as part of the core protocol, but my >> preference would be to have a default selected if the client doesn't wan= t >> (or need) to choose anything different. I don;t think having a default >> would be restrictive, and I think when the protocol is eventually >> launched/standardised in the future we'll have a clear view of what that >> default should be to ensure that it's aligned to the most common use cas= es. >> >> >> Many thanks, >> David Skaife >> >> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt wrote= : >> >>> >>> *Client Authentication / Proof of Possession* >>> XYZ >>> - client proves use of bound keys via general-purpose mechanisms, >>> including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS >>> - RS access via bearer token or proof-of-possession through any >>> allowable key binding mechanism >>> >>> XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault" makes to= o many >>> assumptions about client=E2=80=99s nature and deployment capabilities. = AS should >>> support as many as it can (and possibly have an MTI requirement), clien= t >>> supports whatever method makes the most sense for it. PoP mechanisms fo= r RS >>> should be independent of mechanisms at AS. >>> >>> XAuth >>> - client proves use of bounds keys through an auth mechanism at GS >>> - specifies default mechanism using JOSE for GS and RS >>> proof-of-possession calls >>> - RS access via bearer token just like OAuth 2.0 >>> - extensions can define other mechanisms such as HTTP Sig or MTLS to >>> replace JOSE for either GS and/or RS calls >>> >>> XAuth Rationale: having a Client Authentication mechanism defined and a= s >>> default removes burden of selecting mechanism for most deployments, and >>> ensures interop. >>> =E1=90=A7 >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --000000000000f682e905a1528124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vijay

wrt. constrained=C2=A0environm= ents, as I noted in XAuth=C2=A0

=
<= div>Constrained environments could use CBOR [RFC7049] instead of JSON, and = COSE [RFC8152] instead of JOSE, and CoAP=C2=A0[RFC8323] instead of HTTP/2.<= /div>

I would=C2=A0NOT expect a constrained= environment to use the same mechanisms that others use, for the same reaso= ns CBOR, COSE, and CoAP exist.

wrt. a de jure defa= ult, it is not any more de jure than JSON, JOSE, or MTLS.

Both XYZ and XAuth use JSON for payloads and HTTPS for transport.= =C2=A0

For some environments, MTLS will be a bette= r choice, for others, JOSE will be a better choice.=C2=A0

Myself, I think JOSE is easier for most environments (I'm not i= ncluding constrained environments in this argument for the reasons above) -= - but I would also be ok with a different mechanism=C2=A0as the default.

If all choices are equal (no default), then ALL the = choices have to be implemented in a general purpose implementation, which i= ncreases the attack surface and vulnerability of an implementation, ie a co= ding error.






On Fri, Mar 20, 2020 at 2:46 PM Vijay IETF <vijay.ietf@gmail.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">
Hi,

+1 for XYZ Rationale. I prefer d= e facto over de jure.

My understanding is tha= t the AS is *not* preventing a client implementation to choose a de facto a= uth method that supports the most common use cases.

I see no compelling need for the AS to implement a de jure default s= ince there will eventually be one or two popular and widely used client sid= e implementations that anyway will pick a de facto auth method for their in= tended users/customers.

XYZ rational allows f= or AS to evolve independently without the burden of supporting a default th= at may be onerous in constrained environments.

---
Vijay

PS: I am assuming top post is= acceptable in this group. Let me know if that's not the case.


On Sat, 21 Mar 2020 at 02:33, David Skaife <blue.ringed.octo= pus.guy@gmail.com> wrote:
Hi,

As requested by Dick in the pa= rallel email chain, I'll see if this response can start to kick off som= e discussion.

If I'm understanding this correctl= y, then the main difference here is the debate around whether to have a &qu= ot;default" authentication method or not. Both XYZ and XAuth appear to= support having multiple different authentication methods that the client c= an use (which I certainly agree is sensible), but for XYZ this is part of t= he "core" protocol, whereas for XAuth it's more of an extensi= on.

My view is that I don't think the argument "choosing= one auth method as a default makes too many assumptions about client=E2=80= =99s nature and deployment capabilities" is necessarily=C2=A0a val= id reason to avoid having a default. Having a default perhaps makes assumpt= ions about the most common=C2=A0use cases and the most common clients, but it certainly doesn't prevent other more niche clients and= use cases from being able to use the protocol. I share the concern raised = in the XAuth rationale text that not having a default mechanism places a bu= rden on the clients to choose, which may be off-putting or a distraction fo= r some newcomers. I do however think the availability of different authenti= cation methods should be part of the core protocol, to encourage each AS to= implement as many different methods as possible - which it would be in the= re interest to do so as it would enable the AS to support more use cases.
So in summary, I'm in favour of the protocol supporting multiple = different authentication methods as part of the core protocol, but my prefe= rence would be to have a default selected if the client doesn't want (o= r need) to choose anything different. I don;t think having a default would = be restrictive, and I think when the protocol is eventually launched/standa= rdised in the future we'll have a clear view of what that default shoul= d be to ensure that it's aligned to the most common use cases.


Many thanks,
David Skaife

On= Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <dick.hardt@gmail.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">
Client= Authentication / Proof of Possession

XYZ
- client proves use= of bound keys via general-purpose mechanisms, including detached JWS, DPoP= , OAuth PoP, HTTP Sig, and MTLS
- RS access via bearer token or proof-of= -possession through any allowable key binding mechanism

XYZ Rational= e: choosing one auth method as a =E2=80=9Cdefault" makes too many assu= mptions about client=E2=80=99s nature and deployment capabilities. AS shoul= d support as many as it can (and possibly have an MTI requirement), client = supports whatever method makes the most sense for it. PoP mechanisms for RS= should be independent of mechanisms at AS.

XAuth
- client proves= use of bounds keys through an auth mechanism at GS
- specifies default = mechanism using JOSE for GS and RS proof-of-possession calls
- RS access= via bearer token just like OAuth 2.0
- extensions can define other mech= anisms such as HTTP Sig or MTLS to replace JOSE for either GS and/or RS cal= ls

XAuth Rationale: having a Client Authentication mechanism defined= and as default removes burden of selecting mechanism for most deployments,= and ensures interop.
3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f682e905a1528124-- From nobody Fri Mar 20 17:38:11 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6453A0FEB for ; Fri, 20 Mar 2020 17:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 u-rZ_8ivwhvM for ; Fri, 20 Mar 2020 17:37:51 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 18D9C3A1011 for ; Fri, 20 Mar 2020 17:37:51 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id q19so8359250ljp.9 for ; Fri, 20 Mar 2020 17:37:50 -0700 (PDT) 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=T5Zyw0y2ypjMp8SlHe9z/IdQh/LMXt2FNxYZwjGSFzA=; b=FIprLc2qwbZaoso26lQYO92j24t9ex/j2+vBgCwTNWzbtQNhfft/WCnX1JIzR7Ouup BxHyAI+3TR2LiDvXrW4t4dY/dsu1VYg/3fCQ5D77Ogku9lyHgtBFDN+iXxSae/eb+/hU lgsURUfVqlWAuz5nuU828zlOxqPn4/pSsN3zWwP2nsynaM34e3NcyYA0MyIPemGJcSep FEOSKpZ5UOvhDZOBcjOTkUcjp7vvtWYUvtGRV5OW8ns+kf8fYZrmtFbb+FNx7NRRAOmw WNKCd5spuV0AGW0o/fPDbfnAK0r6ntrJfphXZ0InbTn441gkbu14YLsvtYZGqoVV80QA ahcw== 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=T5Zyw0y2ypjMp8SlHe9z/IdQh/LMXt2FNxYZwjGSFzA=; b=DJT3rOkRFw4e8e/4Fe+xOlqTmIBCwRlFgUQ9V2bpI4UaJGJFSAL5I/7m2VT+XJRgSb 5zcvecU3uAgp6KYr0klaZcu77aZbWvbY/WmWowqljW/hKtdVDNfEnXA3I/4zZlyBGvdW zpSXGgGaXa+/T9gKCh/xs1rvPoLz3jJ6tn89FhqpsIN08gwtTb6oBe2HfJkLm9Oip1eC WTioJ+kkyeoZ8oNK8Y85xLDkuWe97v760rYpqu55HZHNLyCdeQtOjpd7uRkJgrILZiLB 5tswufvLpymHgD2g/oSIPKlM0RCHaV4yIWmY0bX3pOGAw+usBkzVOIS47QC4vlJQw9xC RRPA== X-Gm-Message-State: ANhLgQ2PHH7ZIOUDqmBDHZcwISigvP886qruqmMePI1GqhItiIkdWU+g SlMFgKfJUwGBBT5FPxC0HQsulpOoXHvGOks5fck= X-Google-Smtp-Source: ADFU+vsLL4DfM9kbKz9JL2wmoifwQx0LO3MtV/SfAkzEBM0xr4EcvVAa/Dt2lGt/4l7Zsu16IAX1qpmBxdoD03rn7u0= X-Received: by 2002:a2e:8518:: with SMTP id j24mr7043653lji.138.1584751069031; Fri, 20 Mar 2020 17:37:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 20 Mar 2020 17:37:22 -0700 Message-ID: To: Tobias Looker Cc: txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="00000000000086f02f05a1529c72" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 00:38:10 -0000 --00000000000086f02f05a1529c72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tobias Good question about vulnerabilities. They could happen anywhere in the protocol, not just in the client authentication mechanism. There are likely some lessons from TLS on what worked, and what was problematic. Let's learn from them (and others) and adopt what worked. But just as TLS has evolved, rather than be replaced, I would expect that a default mechanism would evolve, rather than be replaced. And also like TLS, new crypto algorithms are introduced, and compromised algorithms are deprecated. Crypto agility is built into both MTLS and JOSE, which are two of the proposed client authentication mechanisms. /Dick On Fri, Mar 20, 2020 at 2:51 PM Tobias Looker wrote: > One of the questions I have about normatively defining a default is what > happens if that default becomes vulnerable in time and or the ecosystem > moves to a newer approach? Does having the default not cause all parties > then to have to carry that legacy? Although not a perfect analogy I think > there are some lessons from protocols like TLS that would be relivant her= e? > Would specifying this in a recommended implementation section not act as > enough of a forcing function for interoperability but also enable future > evolution? > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Tue, Mar 17, 2020 at 12:06 PM Dick Hardt wrote: > >> >> *Client Authentication / Proof of Possession* >> XYZ >> - client proves use of bound keys via general-purpose mechanisms, >> including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS >> - RS access via bearer token or proof-of-possession through any allowabl= e >> key binding mechanism >> >> XYZ Rationale: choosing one auth method as a =E2=80=9Cdefault" makes too= many >> assumptions about client=E2=80=99s nature and deployment capabilities. A= S should >> support as many as it can (and possibly have an MTI requirement), client >> supports whatever method makes the most sense for it. PoP mechanisms for= RS >> should be independent of mechanisms at AS. >> >> XAuth >> - client proves use of bounds keys through an auth mechanism at GS >> - specifies default mechanism using JOSE for GS and RS >> proof-of-possession calls >> - RS access via bearer token just like OAuth 2.0 >> - extensions can define other mechanisms such as HTTP Sig or MTLS to >> replace JOSE for either GS and/or RS calls >> >> XAuth Rationale: having a Client Authentication mechanism defined and as >> default removes burden of selecting mechanism for most deployments, and >> ensures interop. >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > --00000000000086f02f05a1529c72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tobias

Good question about vulnerabi= lities. They could happen anywhere in the protocol, not just in the client = authentication mechanism.

There are likely some le= ssons from TLS on what worked, and what was problematic. Let's learn fr= om them (and others) and adopt what worked.

But ju= st as TLS has evolved, rather than be replaced, I would expect that a defau= lt mechanism would evolve, rather than be replaced.

And also like TLS, new crypto algorithms are introduced, and compromised = algorithms are deprecated. Crypto agility is built into both MTLS and JOSE,= which are two of the proposed client authentication mechanisms.
=
/Dick

On Fri, Mar 20, 2020 at 2:51 PM Tobias Looker <= ;tobias.looker@mattr.global> wrote:
One= of the questions I have about normatively defining a default is what happe= ns if that default becomes vulnerable in time and or the ecosystem moves to= a newer approach? Does having the default not cause all parties then to ha= ve to carry that legacy? Although not a perfect analogy I think there are s= ome lessons from protocols like TLS that would be relivant here? Would spec= ifying this in a recommended implementation section not act as enough of a = forcing function for interoperability but also enable future evolution?
=C2=A0
Thanks,
3D"Mattr=C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr= .global
=
3D"Mattr<= a href=3D"https://www.linkedin.com/company/mattrglobal" style=3D"border:non= e;color:rgb(51,49,50);margin-right:12px" target=3D"_blank">3D"Mattr3D"Mattr3D"Mattr

This communication, including any attach= ments, is confidential. If you are not the intended recipient, you should n= ot read it - please contact me immediately, destroy it, and do not copy or = use any part of this communication or disclose anything about it. Thank you= . Please note that this communication does not designate an information sys= tem for the purposes of the Electronic Transactions Act 2002.


On Tue, Mar 17, 2020 at 12:06 PM Dick Hardt <<= a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c= om> wrote:
Client Authentication / Proof of Possession
XYZ
- client proves use of bound keys via general-purpose mechanisms, = including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
- RS access = via bearer token or proof-of-possession through any allowable key binding m= echanism

XYZ Rationale: choosing one auth method as a =E2=80=9Cdefau= lt" makes too many assumptions about client=E2=80=99s nature and deplo= yment capabilities. AS should support as many as it can (and possibly have = an MTI requirement), client supports whatever method makes the most sense f= or it. PoP mechanisms for RS should be independent of mechanisms at AS.
=
XAuth
- client proves use of bounds keys through an auth mechanism a= t GS
- specifies default mechanism using JOSE for GS and RS proof-of-pos= session calls
- RS access via bearer token just like OAuth 2.0
- exte= nsions can define other mechanisms such as HTTP Sig or MTLS to replace JOSE= for either GS and/or RS calls

XAuth Rationale: having a Client Auth= entication mechanism defined and as default removes burden of selecting mec= hanism for most deployments, and ensures interop.
3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--00000000000086f02f05a1529c72-- From nobody Fri Mar 20 17:54:11 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562343A0FFA for ; Fri, 20 Mar 2020 17:54:09 -0700 (PDT) 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, 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 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 SQdGvJSeIfkL for ; Fri, 20 Mar 2020 17:54:04 -0700 (PDT) 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 6E9A13A0FFE for ; Fri, 20 Mar 2020 17:54:03 -0700 (PDT) Received: from [192.168.1.5] (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 02L0rtOk007676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 20:53:56 -0400 From: Justin Richer Message-Id: <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_59F2C7CE-7645-44FA-95A1-BF2353194C5C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Mar 2020 20:53:55 -0400 In-Reply-To: Cc: txauth@ietf.org, Yaron Sheffer To: Dick Hardt References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 00:54:10 -0000 --Apple-Mail=_59F2C7CE-7645-44FA-95A1-BF2353194C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dick, thanks for pulling the definitions up: > a communicative action or activity involving two parties or things = that reciprocally affect or influence each other This is the kind of thing that I had in mind. The client and the AS are = in a conversation over time that each one contributes to and each = changes.=20 Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D = doesn=E2=80=99t stand for =E2=80=9CTransactional Auth=E2=80=9D much the = same way we decided that the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D= doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore.=20 None of the arguments below in favor of XAuth have made me like that = name better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, = then why come up with something new? =E2=80=94 Justin > On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: >=20 >=20 >=20 >=20 > not a transaction - there are multiple transactions >=20 > backchannel innovation is combination of here is who I am, and here is = what I want to do >=20 >=20 > childhood trauma therapy group >=20 >=20 >=20 > On Mon, Mar 16, 2020 at 6:56 PM Justin Richer > wrote: > Yes, naming things is hard =E2=80=94 but I still believe in the name = TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of = getting an authorization delegated to the client software as a = multi-step, multi-party transaction is, I believe, the key insight = that=E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. = It=E2=80=99s not just about going to the AS first =E2=80=94 we had that = in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I = really think it=E2=80=99s about the transaction at the core.=20 >=20 > OAuth 2.0 had multi-step, multi-party. TxAuth extends that. >=20 > I think the big shift is going to the AS. This enables the request to = be richer with JSON, instead of name/value pairs parameters in a URI. It = allows the client and AS to negotiate, and to short circuit having to = redirect the user to the AS. PAR does some of this, but it is = constrained by having to do it in the OAuth 2.0 context. >=20 > My concern is that the protocol is MUCH MORE than a transaction. While = the initial interaction between client, AS, user and RO is a = transaction. The protocol also covers the client and RS interactions. = The access token refreshes. Access token revocation. Access token = introspection. As described in the charter, there is a whole lifecycle, = that consists of multiple transactions. >=20 > =46rom https://www.merriam-webster.com/dictionary/transaction = : >=20 > Definition of transaction > 1a: something transacted = > especially : an exchange or transfer = of goods, = services, or funds > electronic transactions > b: transactions plural : the often published record of the meeting of = a society or association > 2a: an act, process, or instance of transacting = > b: a communicative action or activity involving two parties or things = that reciprocally affect or influence each other >=20 > Calling the protocol a transaction will confusing to people. > =20 >=20 > Having come of age in the 1990=E2=80=99s, I have particular dislike = for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2= =80=9D, and if you read either of those with a growling yell in your = head then you know exactly what I=E2=80=99m talking about. >=20 > In case you are confused, this is not a childhood trauma support = group. :) >=20 > Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a = placeholder. X-Men, Xbox, X-Factor, X-files.=20 >=20 > = https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 = = >=20 > = https://english.stackexchange.com/questions/358181/whats-the-purpose-of-us= ing-letter-x-or-x-as-a-suffix-in-brand-names = >=20 > =20 > And to Dick=E2=80=99s rationale for the name below, I absolutely do = NOT see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. = I think that does a disservice to the kind of change we have an = opportunity to make here.=20 >=20 > =46rom the charter=20 >=20 > "It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0)" >=20 > Which sounds pretty similar to =E2=80=9COAuth with all the extra = features=E2=80=9D >=20 > While I think XAuth captures what we are doing, a placeholder name = would be preferable to an incorrect descriptive name such as TxAuth. >=20 > For example, XYZ is a good placeholder name. Or XYZAuth. Let's not = mislead people. >=20 > =20 >=20 > =E2=80=94 Justin >=20 >> On Mar 16, 2020, at 7:04 PM, Dick Hardt > wrote: >>=20 >> Hello everyone >>=20 >> I prompted a thread around the name of the protocol a while back: >>=20 >> = https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ = >>=20 >> As Justin stated "naming is hard" >>=20 >> Wearing my marketing hat I want to ensure that the name will be = perceived properly in the broader community. >>=20 >> A recent example that comes to mind are the privacy related works on = the browser storage API. Given that name, one would think that it is = local storage. It is actually about browser cookies. >>=20 >> Justin discussed his reasons for TxAuth in the thread above (and I'm = sure in other places) >>=20 >> I chose XAuth in my draft to reflect the eXtensibility goal that we = have over OAuth -- and XAuth is OAuth but with an X to reflect all the = extra features. =3D) >>=20 >> Other suggestions? >>=20 >> This will be an agenda item in the BoF -- but the name will NOT be an = open discussion item -- we will summarize what has been discussed on the = list and perhaps do a poll of options presented unless consensus is = obvious from this thread. >>=20 >> /Dick >>=20 >>=20 >>=20 >>=20 >>=20 >> =E1=90=A7 >=20 --Apple-Mail=_59F2C7CE-7645-44FA-95A1-BF2353194C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dick,= thanks for pulling the definitions up:

> a communicative = action or activity involving two parties or things that reciprocally = affect or influence each other

This is the kind of thing that I had in = mind. The client and the AS are in a conversation over time that each = one contributes to and each changes. 

Also =E2=80=94 we can just as easily = decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand for = =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that = the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D doesn=E2=80=99t stand = for =E2=80=9COpen=E2=80=9D anymore. 

None of the arguments below in favor of = XAuth have made me like that name better. If it=E2=80=99s just a = =E2=80=9Cplaceholder=E2=80=9D name, then why come up with something = new?

 =E2=80= =94 Justin

On Mar 20, 2020, at 3:32 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:




not a transaction - there are multiple = transactions

backchannel innovation is combination of here is who I = am, and here is what I want to do


childhood trauma therapy group



On Mon, Mar 16, 2020 at 6:56 PM Justin Richer = <jricher@mit.edu> wrote:
Yes, naming = things is hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80=99= re moving beyond OAuth, and taking the process of getting an = authorization delegated to the client software as a multi-step, = multi-party transaction is, I believe, the key insight that=E2=80=99s = letting us move beyond OAuth=E2=80=99s limitations here. It=E2=80=99s = not just about going to the AS first =E2=80=94 we had that in OAuth 1 = and we=E2=80=99re patching that into OAuth 2 with PAR. I really think = it=E2=80=99s about the transaction at the = core. 

OAuth 2.0 had multi-step, multi-party. TxAuth extends = that.

I think = the big shift is going to the AS. This enables the request to be richer = with JSON, instead of name/value pairs parameters in a URI. It allows = the client and AS to negotiate, and to short circuit having to redirect = the user to the AS. PAR does some of this, but it is constrained by = having to do it in the OAuth 2.0 context.

My concern is that the protocol is MUCH = MORE than a transaction. While the initial interaction between client, = AS, user and RO is a transaction. The protocol also covers the = client and RS interactions. The access token refreshes. Access = token revocation. Access token introspection. As described in the = charter, there is a whole lifecycle, that consists of multiple = transactions.

From https://www.merriam-webster.com/dictionary/transaction:

Definition = of transaction

1a: something transactedespecially : an exchange or transfer of goods, services, or fundselectronic transactions
b: transactions plural : the often published record of the meeting of a = society or association
2a: an act, process, or instance of transacting
b: a communicative action or activity involving two = parties or things that reciprocally affect or influence each = other

Calling the protocol a transaction will = confusing to people.
 

Having come of age in = the 1990=E2=80=99s, I have particular dislike for XAuth. It sounds too = =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you = read either of those with a growling yell in your head then you know = exactly what I=E2=80=99m talking about.

In case you are = confused, this is not a childhood trauma support group.  = :)

Unlike = "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. X-Men, = Xbox, X-Factor, X-files. 

https://www.businessinsider.com/the-indisputable-power-of-brand= -x-2012-4

https://english.stackexchange.com/questions/358181/whats-the-pu= rpose-of-using-letter-x-or-x-as-a-suffix-in-brand-names

 
= And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I = think that does a disservice to the kind of change we have an = opportunity to make here. 

=46rom the = charter 

"It will expand upon the uses = cases currently supported by OAuth 2.0 and OpenID Connect (itself an = extension of OAuth 2.0)"

Which sounds pretty similar to =E2=80=9COAuth with all = the extra features=E2=80=9D

While I think XAuth captures what we are doing, a = placeholder name would be preferable to an incorrect descriptive name = such as TxAuth.

For example, XYZ is a good placeholder name. Or XYZAuth. = Let's not mislead people.

 

 =E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello everyone

I prompted a thread = around the name of the protocol a while back:

https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDX= OrTr_s_wc/

As Justin stated "naming is = hard"

Wearing = my marketing hat I want to ensure that the name will be = perceived properly in the broader community.
A recent example that comes to mind = are the privacy related works on the browser storage API. Given that = name, one would think that it is local storage. It is actually about = browser cookies.

Justin discussed his reasons for TxAuth in the thread above = (and I'm sure in other places)

I chose XAuth in my draft to reflect = the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but = with an X to reflect all the extra features. =3D)
Other suggestions?

This will be an agenda = item in the BoF -- but the name will NOT be an open discussion item -- = we will summarize what has been discussed on the list and perhaps = do a poll of options presented unless consensus is obvious from this = thread.

/Dick





3D""=E1=90=A7


= --Apple-Mail=_59F2C7CE-7645-44FA-95A1-BF2353194C5C-- From nobody Fri Mar 20 17:56:08 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3A3A0FFE for ; Fri, 20 Mar 2020 17:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.998, 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 wjjIS9IbUTRe for ; Fri, 20 Mar 2020 17:56:01 -0700 (PDT) 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 3540C3A0FFD for ; Fri, 20 Mar 2020 17:56:00 -0700 (PDT) Received: from [192.168.1.5] (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 02L0twBN008077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 20:55:59 -0400 From: Justin Richer Message-Id: <63F0BF67-31BC-4AF2-8AD3-88AAF76F0C30@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_05D937B6-0A3D-4C1F-B069-EA6992B2120E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Mar 2020 20:55:58 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <6750F9C8-425E-45B1-BCE8-52674F7BCDC5@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 00:56:07 -0000 --Apple-Mail=_05D937B6-0A3D-4C1F-B069-EA6992B2120E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Our implementation currently refreshes all of them together when a = refresh is requested. Will we need finer grained access than that? = Maybe.=20 As I=E2=80=99ve said on the list before, I think there=E2=80=99s merit = in exploring the per-access-token management URL idea in XAuth, but I = still am not a fan of separating the concept of the =E2=80=9Crefresh = token=E2=80=9D back out. =E2=80=94 Justin > On Mar 20, 2020, at 2:45 PM, Dick Hardt wrote: >=20 > Justin: How are each of the access tokens refreshed in the multiple = access token scenario?=20 >=20 > On Fri, Mar 13, 2020 at 3:13 PM Justin Richer > wrote: > I took some time to implement an idea that was tossed out on the list = here recently, and that=E2=80=99s how we might support requests and = responses for multiple access tokens. I=E2=80=99ve got a method that I = think works pretty well without getting in the way of the common, simple = case of requesting a single access token. I=E2=80=99ve implemented this = in our Java implementation of XYZ and I=E2=80=99ve updated the = https://oauth.xyz/ website with more details. = I=E2=80=99ll update my ID spec text when I get a chance to reflect this, = but I wanted to start this discussion first. Everything in here is based = on the XYZ protocol. >=20 > Normally, the =E2=80=9Cresources=E2=80=9D element of a tx request is = an array of items: >=20 > resources: [ > { > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/ = ", "https://resource.local/other = "], > datatypes: ["metadata", "images"] > }, > { > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/ = "], > datatypes: ["data", "pictures"] > } > ] >=20 > This tells the AS that the client is asking for a single access token = with multiple, perhaps orthogonal sets of access. This is in parallel to = RAR being developed in OAuth 2. However, if we allow the =E2=80=9Cresource= s=E2=80=9D item to be an object instead of an array, we can let the = client signal to the AS that it wants multiple access tokens. The client = picks =E2=80=9Clabels=E2=80=9D for these access tokens, in this case = =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D, and sends a = request like this. >=20 > resources: { > token1: [{ > actions: ["read", "write", "dolphin"], > locations: ["https://server.example.net/ = ", "https://resource.local/other = "], > datatypes: ["metadata", "images"] > }], > token2: [{ > actions: ["foo", "bar", "dolphin"], > locations: ["https://resource.other/ = "], > datatypes: ["data", "pictures"] > }] > } >=20 > The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this: >=20 > { > access_token: { > value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > type: "bearer" > } > } >=20 > Or multiple access tokens in a tx response like this: >=20 > { > multiple_access_tokens: { > token1: { > value: "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", > type: "bearer" > }, > token2: { > value: "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", > type: "bearer" > } > } > } >=20 > These fields are mutually exclusive, so you either get a single = unnamed token or a set of named tokens. Since the client pics the labels = for the access tokens, it=E2=80=99s clear which part of the request maps = to which part of the response. It=E2=80=99s more complexity for the = client to track, but that complexity is only seen and borne by clients = that need it. Simple clients get to stay simple while letting a complex = problem get solved.=20 >=20 > A note about the polymorphic JSON that=E2=80=99s in user here, though = it=E2=80=99s already a key part of XYZ=E2=80=99s protocol design. For = those unfamiliar with the concept, this is when a given field can have a = value that takes multiple different types: a string, a boolean, an = object, an array, etc. This is pretty simple to deal with in dynamically = typed languages, you just check the type of the resulting object and it = will tell you what you=E2=80=99re dealing with. It=E2=80=99s trickier in = statically typed languages, but I=E2=80=99ve found that pretty much = every platform and library has hooks for custom serialization and = deserialization that will let you dispatch to different types during the = process, so you can still call your top-level parser and toString = methods and things will work as expected. This is one of the reasons = that I did an implementation in Java, to prove that we could do this = kind of thing in a strongly typed language that=E2=80=99s not very = flexible about what goes in objects, and I=E2=80=99ve done it without = resorting to generic collections for the dynamic fields. Previously, = I=E2=80=99ve used this feature in XYZ to allow a single string to stand = in as a reference for an object =E2=80=94 something XYZ calls = =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2. >=20 > resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ] >=20 > Polymorphic JSON is great for things like this because it means you = don=E2=80=99t have to have multiple fields and normative rules for = mutual exclusivity, like we=E2=80=99d have to have otherwise. The type = switching only works when the base type is significantly different, = though =E2=80=94 that=E2=80=99s why I have =E2=80=9Caccess_token=E2=80=9D = and =E2=80=9Cmultiple_access_tokens=E2=80=9D above, since both are = objects at the top level and you can=E2=80=99t cleanly switch at the = parser level, and you don=E2=80=99t want to have to dig down into the = object to see what to do with it. >=20 >=20 >=20 > People have been asking for a good way to do multiple access tokens = with OAuth for years, but we=E2=80=99ve never had a good or clean way to = pull it off because of OAuth=E2=80=99s model and the assumptions that it = makes. I think TxAuth gives us the opportunity to solve this in a way = that=E2=80=99s consistent with the rest of the protocol, and do so in a = way that doesn=E2=80=99t make the simple cases we know and love too = complicated for average developers. >=20 > =E2=80=94 Justin >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_05D937B6-0A3D-4C1F-B069-EA6992B2120E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Our = implementation currently refreshes all of them together when a refresh = is requested. Will we need finer grained access than that? = Maybe. 

As = I=E2=80=99ve said on the list before, I think there=E2=80=99s merit in = exploring the per-access-token management URL idea in XAuth, but I still = am not a fan of separating the concept of the =E2=80=9Crefresh token=E2=80= =9D back out.

 =E2=80=94 Justin

On Mar 20, 2020, at 2:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin: How are each of the = access tokens refreshed in the multiple access token = scenario? 

On Fri, Mar 13, 2020 at 3:13 PM Justin = Richer <jricher@mit.edu> wrote:
I took some = time to implement an idea that was tossed out on the list here recently, = and that=E2=80=99s how we might support requests and responses for multiple access tokens. I=E2=80=99ve got a method that I = think works pretty well without getting in the way of the common, simple = case of requesting a single access token. I=E2=80=99ve implemented this = in our Java implementation of XYZ and I=E2=80=99ve updated the https://oauth.xyz/ website with more details. I=E2=80=99= ll update my ID spec text when I get a chance to reflect this, but I = wanted to start this discussion first. Everything in here is based on = the XYZ protocol.

Normally, the =E2=80=9Cresources=E2=80=9D element of a tx = request is an array of items:

resources: = [
= {
            = actions: ["read", "write", "dolphin"],
  =           locations: ["https://server.example.net/", "https://resource.local/other"],
 =           datatypes: ["metadata", = "images"]
        },
= {
            = actions: ["foo", "bar", "dolphin"],
    =         locations: ["https://resource.other/"],
  =           datatypes: ["data", = "pictures"]
        }
]

This tells the AS that the client is asking for a single = access token with multiple, perhaps orthogonal sets of access. This is = in parallel to RAR being developed in OAuth 2. However, if we allow the = =E2=80=9Cresources=E2=80=9D item to be an object instead of an array, we = can let the client signal to the AS that it wants multiple access = tokens. The client picks =E2=80=9Clabels=E2=80=9D for these access = tokens, in this case =E2=80=9Ctoken1=E2=80=9D and =E2=80=9Ctoken2=E2=80=9D= , and sends a request like this.

resources: {
    token1: = [{
            = actions: ["read", "write", "dolphin"],
  =           locations: ["https://server.example.net/", "https://resource.local/other"],
 =           datatypes: ["metadata", = "images"]
     }],
     token2: [{
  =           actions: ["foo", "bar", = "dolphin"],
          =   locations: ["https://resource.other/"],
  =           datatypes: ["data", = "pictures"]
     }]
}

The client could request multiple kinds of access within each = sub-object=E2=80=99s array (the value of the =E2=80=9Ctoken1=E2=80=9D = and =E2=80=9Ctoken2=E2=80=9D fields), but I wanted to keep it simple = here. This example is the same total set of resources that the client is = asking for in the first case, but here the client=E2=80=99s saying it = wants them as two different access tokens instead of a single one. The = AS can tell the difference in the request because the first type is an = array at the top and the second type is an object at the top. So that = means that the AS can send back a single access token in a tx response = like this:

{
      =   access_token: {
        =     value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =           type: "bearer"
        }
}

Or multiple access tokens in a tx response like = this:

{
    multiple_access_tokens: = {
          token1: = {
            value: = "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
  =           type: "bearer"
          },
          token2: {
            value: = "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
  =           type: "bearer"
          }
    }
}

These fields are = mutually exclusive, so you either get a single unnamed token or a set of = named tokens. Since the client pics the labels for the access tokens, = it=E2=80=99s clear which part of the request maps to which part of the = response. It=E2=80=99s more complexity for the client to track, but that = complexity is only seen and borne by clients that need it. Simple = clients get to stay simple while letting a complex problem get = solved. 

A note about the polymorphic JSON that=E2=80=99s in user = here, though it=E2=80=99s already a key part of XYZ=E2=80=99s protocol = design. For those unfamiliar with the concept, this is when a given = field can have a value that takes multiple different types: a string, a = boolean, an object, an array, etc. This is pretty simple to deal with in = dynamically typed languages, you just check the type of the resulting = object and it will tell you what you=E2=80=99re dealing with. It=E2=80=99s= trickier in statically typed languages, but I=E2=80=99ve found that = pretty much every platform and library has hooks for custom = serialization and deserialization that will let you dispatch to = different types during the process, so you can still call your top-level = parser and toString methods and things will work as expected. This is = one of the reasons that I did an implementation in Java, to prove that = we could do this kind of thing in a strongly typed language that=E2=80=99s= not very flexible about what goes in objects, and I=E2=80=99ve done it = without resorting to generic collections for the dynamic fields. = Previously, I=E2=80=99ve used this feature in XYZ to allow a single = string to stand in as a reference for an object =E2=80=94 something XYZ = calls =E2=80=9Chandles=E2=80=9D. These let you have constructs akin to a = client_id, a scope, a refresh token, and a few other items without = having to create explicit elements for these, since they always stand in = for the object they replace there=E2=80=99s no ambiguity. So for things = like a resource request, each of these can be replaced by a string using = resource handles and polymorphic JSON (see note below) to act like a = scope in OAuth2.

resources: [ =E2=80=9Cmetadata-readwrite=E2=80=9D, = =E2=80=9Cfoobar-pictures=E2=80=9D ]

Polymorphic JSON is great for things = like this because it means you don=E2=80=99t have to have multiple = fields and normative rules for mutual exclusivity, like we=E2=80=99d = have to have otherwise. The type switching only works when the base type = is significantly different, though =E2=80=94 that=E2=80=99s why I have = =E2=80=9Caccess_token=E2=80=9D and =E2=80=9Cmultiple_access_tokens=E2=80=9D= above, since both are objects at the top level and you can=E2=80=99t = cleanly switch at the parser level, and you don=E2=80=99t want to have = to dig down into the object to see what to do with it.



People have been asking = for a good way to do multiple access tokens with OAuth for years, but = we=E2=80=99ve never had a good or clean way to pull it off because of = OAuth=E2=80=99s model and the assumptions that it makes. I think TxAuth = gives us the opportunity to solve this in a way that=E2=80=99s = consistent with the rest of the protocol, and do so in a way that = doesn=E2=80=99t make the simple cases we know and love too complicated = for average developers.

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_05D937B6-0A3D-4C1F-B069-EA6992B2120E-- From nobody Fri Mar 20 18:00:35 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3603A100D for ; Fri, 20 Mar 2020 18:00:32 -0700 (PDT) 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=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 zRzFVkh5WIgG for ; Fri, 20 Mar 2020 18:00:28 -0700 (PDT) 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 165E83A100A for ; Fri, 20 Mar 2020 18:00:27 -0700 (PDT) Received: from [192.168.1.5] (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 02L10Nij009156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 21:00:23 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C73045C4-FB22-4D50-B773-3E3DF032B92F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Mar 2020 21:00:22 -0400 In-Reply-To: Cc: Nat Sakimura , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" To: Dick Hardt References: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:00:33 -0000 --Apple-Mail=_C73045C4-FB22-4D50-B773-3E3DF032B92F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > One of my motivations for writing the XAuth document was to show how = different representations could be requested and received, as this was = missing in XYZ. If a use case requires a new representation, then = perhaps TxAuth may be a place for that work to happen, but I think it is = more likely to happen in other forums. >=20 I have added this to XYZ since draft -05, and posted to the list about = this. I don=E2=80=99t want to come up with an assertion format. I do = want to allow non-assertion basic claims to be passed back. >=20 > On a related note, I also strongly think that the existing OAuth 2.0 = scopes should be easily used in requests and responses. XAuth shows an = example of how that can be done. >=20 Reusing existing OAuth scopes is explicitly supported in XYZ as well, = through the use of resource handles.=20 > /Dick=20 >=20 >=20 >=20 >=20 > On Fri, Mar 20, 2020 at 6:39 AM Justin Richer > wrote: > I agree with a lot of that argument. Let me see if I can more clearly = restate what I was trying to say earlier in this thread: the = relationships between the different parties are separable and depend on = the kind of deployments and use cases that are being addressed by = people. So in an OAuth/OIDC-style world, we=E2=80=99ve got three = components (ignoring people), and three relationships between them: >=20 > C<->AS >=20 > C<->RS >=20 > AS<->RS >=20 > For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, = =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow to interpret a = token=E2=80=9D. For authentication, it=E2=80=99s additionally =E2=80=9Chow= do I get the authentication info=E2=80=9D, =E2=80=9Chow do I ask for a = profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80=9D= . I still believe this is a good separation of concerns. The client = doesn=E2=80=99t need to know what=E2=80=99s in the access token, or if = it=E2=80=99s a reference or self-contained, or really concern itself at = all with what the RS does with it. Are there overlaps? Certainly =E2=80=94= the client needs to know how to ask for a token that the RS will accept = for what the client is going to do, and to do that the client needs to = be able to describe what it wants to do in a way that the AS can = interpret and map to a set of rights that the RS will eventually = interpret.=20 >=20 > I believe the proposed charter already covers this split with the = following items: >=20 > - Fine-grained specification of access > - Approval of access to multiple resources and APIs in a single = interaction > - Separation between the party authorizing access and the party = operating the client requesting access > - Revocation of active tokens > - Query of token rights by resource servers >=20 > It=E2=80=99s the combination of the rich request and the lifecycle = management that puts the AS and RS in scope. I think things like = declaring a single token format are absolutely out =E2=80=94 if you want = to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just fine. = However, something that I think is in scope is defining a structure for = what a token represents. And I think that if we can do that in this WG = in a general way, then that=E2=80=99s useful. Because then that = structure can be represented by mapping to a token format or an = introspection response or a database entry. I think Nat=E2=80=99s = comments on ABAC are important: we are going to need a place to put = those attributes. Whether they=E2=80=99re communicated to the RS through = the token itself or through some other channel is, I strongly believe, a = matter of deployment choice. >=20 > So, what can the charter say to make this more clear? >=20 > All that said, I=E2=80=99m against having an architecture document as = a working group output. In my experience, when a WG puts its effort into = a formal architecture doc as a deliverable, there is a lot of = conjectural energy that goes into what might be a good idea, and then = not all of it works out when you try to hammer the details of making = that architecture into a real engineered thing.You end up baking in = assumptions and abstractions that don=E2=80=99t make sense anymore, and = then trying to engineer solutions around those when they don=E2=80=99t = fit right. If the architecture can=E2=80=99t change in light of new = information, which is the case with an RFC, then it becomes a shackle = instead of a scaffold. But a malleable document that the group can use = as a guide while engineering the actual parts =E2=80=94 yes, that makes = sense. The architecture can be refactored and changed as decisions are = made and things come into focus. I feel the same about use case = documents as formal artifacts.=20 >=20 > Thanks, Nat. > =E2=80=94 Justin >=20 >> On Mar 20, 2020, at 2:19 AM, Nat Sakimura > wrote: >>=20 >> I thought I should keep my mouth shut as anything I say may be deemed = biased as my other hat is the chairman of OIDF, but here is my 2c.=20 >>=20 >> As Torsten indicated, there is much to be desired to standardize the = AS - RS communication patterns. You may say that the charter includes = it, but I cannot read it out of the charter just like Torsten could not. = As a new protocol, it would be good to include it.=20 >>=20 >> In this respect, I am not sure if we should start off from OAuth 2.0 = and OIDC model. If we are creating a new protocol, I feel that we should = architect is more fully. Not mentioning AS - RS relationship to me feels = like an indication of this failure. For that matter, I feel that the = first output of the group should be an architecture document that takes = the concerns from all the relevant stakeholders/actors in.=20 >>=20 >> We should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme) etc. We are not = going to get to a unified identity world anytime soon.=20 >>=20 >> Cheers,=20 >>=20 >> Nat Sakimura >>=20 >>=20 >> On Wed, Mar 18, 2020 at 7:06 AM Mike Jones = > wrote: >> I believe it's significant that four people have expressed concerns = with including digital identity in the charter (the only concerns voiced = as far as I can tell). At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter. >>=20 >> It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way. If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Justin Richer >=20 >> Sent: Tuesday, March 17, 2020 2:20 PM >> To: Mike Jones > >> Cc: Yaron Sheffer >; Torsten Lodderstedt = >; = txauth@ietf.org >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >>=20 >> While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things. >>=20 >> As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.=20 >>=20 >> The market has shown us that the most common application of OAuth 2 = is far and away access to identity information along side access to an = API. I think we need to pay attention to that and not make this separate = just because we did it that way before. And some of the proposed = innovations, including getting and sending VC=E2=80=99s, are all about = identity. >>=20 >> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >>=20 >> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >>=20 >> =E2=80=94 Justin >>=20 >> > On Mar 17, 2020, at 1:12 PM, Mike Jones = > wrote: >> >=20 >> > 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >> >=20 >> > I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/ = . >> >=20 >> > I'm fine with refactoring the authorization protocol. But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed. Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0. >> >=20 >> > Please revise the charter to remove digital identity from the scope = of the work. >> >=20 >> > 2. Are you willing to author or participate in the development of = the drafts of this WG? >> >=20 >> > Yes >> >=20 >> > 3. Are you willing to help review the drafts of this WG? >> >=20 >> > Yes >> >=20 >> > 4. Are you interested in implementing drafts of this WG? >> >=20 >> > Not at this time. >> >=20 >> > -- Mike >> >=20 >> > -----Original Message----- >> > From: Txauth > On Behalf Of Torsten Lodderstedt >> > Sent: Saturday, March 7, 2020 7:18 AM >> > To: Yaron Sheffer > >> > Cc: txauth@ietf.org >> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG >> >=20 >> > Hi, >> >=20 >> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = >: >> >>=20 >> >> =EF=BB=BFHi Everyone, >> >>=20 >> >> It appears that momentum is forming around the proposed formation = of a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: >> >>=20 >> >> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >> >=20 >> > I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. >> >=20 >> > We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. >> >=20 >> >>=20 >> >> 2. Are you willing to author or participate in the development of = the drafts of this WG? >> >=20 >> > yes >> >=20 >> >>=20 >> >> 3. Are you willing to help review the drafts of this WG? >> >=20 >> > yes >> >=20 >> >>=20 >> >> 4. Are you interested in implementing drafts of this WG? >> >=20 >> > yes >> >=20 >> > best regards, >> > Torsten. >> >=20 >> >>=20 >> >> The call will run for two weeks, until March 21. If you think that = the charter should be amended In a significant way, please reply on a = separate thread. >> >>=20 >> >> The feedback provided here will help the IESG come to a decision = on the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. >> >>=20 >> >> Thanks, >> >> Yaron and Dick >> >>=20 >> >> --- Charter Text Follows --- >> >>=20 >> >> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >> >>=20 >> >> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >> >>=20 >> >> Additionally, the delegation process will allow for: >> >>=20 >> >> - Fine-grained specification of access >> >> - Approval of AS attestation to identity claims >> >> - Approval of access to multiple resources and APIs in a single = interaction >> >> - Separation between the party authorizing access and the party = operating the client requesting access >> >> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >> >>=20 >> >> The group will define extension points for this protocol to allow = for flexibility in areas including: >> >>=20 >> >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >> >> - User interaction mechanisms including web and non-web methods >> >> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions >> >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys >> >> - Optimized inclusion of additional information through the = delegation process (including identity) >> >>=20 >> >> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: >> >>=20 >> >> - Discovery of the authorization server >> >> - Revocation of active tokens >> >> - Query of token rights by resource servers >> >>=20 >> >> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. >> >>=20 >> >> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >> >>=20 >> >> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.=20 >> >>=20 >> >> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >> >>=20 >> >> Milestones to include: >> >> - Core delegation protocol >> >> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures >> >> - Identity and authentication conveyance mechanisms >> >> - Guidelines for use of protocol extension points >> >>=20 >> >>=20 >> >> --=20 >> >> Txauth mailing list >> >> Txauth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth = >> > --=20 >> > Txauth mailing list >> > Txauth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_C73045C4-FB22-4D50-B773-3E3DF032B92F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
One of my = motivations for writing the XAuth document was to show how different = representations could be requested and received, as this was missing in = XYZ.  If a use case requires a new representation, then perhaps = TxAuth may be a place for that work to happen, but I think it is more = likely to happen in other forums.


I have added this to XYZ since draft -05, and = posted to the list about this. I don=E2=80=99t want to come up with an = assertion format. I do want to allow non-assertion basic claims to be = passed back.


On a = related note, I also strongly think that the existing OAuth 2.0 scopes = should be easily used in requests and responses. XAuth shows an example = of how that can be done.


Reusing existing OAuth scopes is explicitly = supported in XYZ as well, through the use of resource = handles. 


/Dick 




On Fri, Mar 20, 2020 at 6:39 AM Justin Richer = <jricher@mit.edu> = wrote:
I agree with a lot of that argument. Let me see = if I can more clearly restate what I was trying to say earlier in this = thread: the relationships between the different parties are separable = and depend on the kind of deployments and use cases that are being = addressed by people. So in an OAuth/OIDC-style world, we=E2=80=99ve got = three components (ignoring people), and three relationships between = them:

C<->AS

C<->RS

AS<->RS

For authorization, these map to =E2=80=9Chow to get a = token=E2=80=9D, =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow = to interpret a token=E2=80=9D. For authentication, it=E2=80=99s = additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, = =E2=80=9Chow do I ask for a profile=E2=80=9D, and =E2=80=9Chow do I know = whose profile this is=E2=80=9D. I still believe this is a good = separation of concerns. The client doesn=E2=80=99t need to know what=E2=80= =99s in the access token, or if it=E2=80=99s a reference or = self-contained, or really concern itself at all with what the RS does = with it. Are there overlaps? Certainly =E2=80=94 the client needs to = know how to ask for a token that the RS will accept for what the client = is going to do, and to do that the client needs to be able to describe = what it wants to do in a way that the AS can interpret and map to a set = of rights that the RS will eventually interpret. 

I believe the proposed = charter already covers this split with the following items:

- Fine-grained = specification of access
- Approval of access to multiple = resources and APIs in a single interaction
- Separation = between the party authorizing access and the party operating the client = requesting access
- = Revocation of active tokens
- Query of token rights by = resource servers

It=E2=80=99s the combination of the = rich request and the lifecycle management that puts the AS and RS in = scope. I think things like declaring a single token format are = absolutely out =E2=80=94 if you want to use JWT, or CWT, or UUID=E2=80=99s= , that=E2=80=99s all just fine. However, something that I think is in = scope is defining a structure for what a token represents. And I think = that if we can do that in this WG in a general way, then that=E2=80=99s = useful. Because then that structure can be represented by mapping to a = token format or an introspection response or a database entry. I think = Nat=E2=80=99s comments on ABAC are important: we are going to need a = place to put those attributes. Whether they=E2=80=99re communicated to = the RS through the token itself or through some other channel is, I = strongly believe, a matter of deployment choice.

So, what can the charter say to make = this more clear?

All that said, I=E2=80=99m against having an architecture = document as a working group output. In my experience, when a WG puts its = effort into a formal architecture doc as a = deliverable, there is a lot of conjectural energy that goes into = what might be a good idea, and then not all of it works out when you try = to hammer the details of making that architecture into a real engineered = thing.You end up baking in assumptions and abstractions that don=E2=80=99t= make sense anymore, and then trying to engineer solutions around those = when they don=E2=80=99t fit right. If the architecture can=E2=80=99t = change in light of new information, which is the case with an RFC, then = it becomes a shackle instead of a scaffold. But a malleable document = that the group can use as a guide while engineering the actual parts =E2=80= =94 yes, that makes sense. The architecture can be refactored and = changed as decisions are made and things come into focus. I feel the = same about use case documents as formal artifacts. 

Thanks, = Nat.
 =E2=80=94 Justin

On Mar 20, 2020, at 2:19 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

I thought I should keep my = mouth shut as anything I say may be deemed biased as my other hat = is the chairman of OIDF, but here is my 2c. 

As Torsten indicated, there is much to = be desired to standardize the AS - RS communication patterns. You may = say that the charter includes it, but I cannot read it out of the = charter just like Torsten could not. As a new protocol, it would be good = to include it. 

In this respect, I am not sure if we should start off from = OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel that = we should architect is more fully. Not mentioning AS - RS relationship = to me feels like an indication of this failure. For that matter, I feel = that the first output of the group should be an architecture document = that takes the concerns from all the relevant stakeholders/actors = in. 

We = should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme)  etc. We are not = going to get to a unified identity world anytime soon. 

Cheers, 

Nat Sakimura


On Wed, Mar = 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
I = believe it's significant that four people have expressed concerns with = including digital identity in the charter (the only concerns voiced as = far as I can tell).  At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter.

It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way.  If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so.

                    =             -- Mike

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten = Lodderstedt <torsten@lodderstedt.net>; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.

The market has shown us that the most common application of OAuth 2 is = far and away access to identity information along side access to an API. = I think we need to pay attention to that and not make this separate just = because we did it that way before. And some of the proposed innovations, = including getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere.

If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it.

 =E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>
> 1.  Do you support the charter text provided at the end of = this email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
>
> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife.  I'll = note that Kim Cameron previously expressed concerns about including = identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXS= nshX2CahE/.
>
> I'm fine with refactoring the authorization protocol.  But = identity should be decoupled from the TxAuth work to focus its scope on = areas where innovation is being proposed.  Digital identity can = always be added as a layer if needed, just as OpenID Connect layered = identity onto OAuth 2.0.
>
> Please revise the charter to remove digital identity from the scope = of the work.
>
> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>
> Yes
>
> 3.  Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.  Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>                  =              -- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Torsten Lodderstedt
> Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.org
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed = formation of a TxAuth working group.  We=E2=80=99d like to more = formally gauge interest in proceeding with this work.  Please do so = by responding to the following questions:
>>
>> 1.  Do you support the charter text provided at the end of = this email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic.
>
> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability.
>
>>
>> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>
> yes
>
>>
>> 3.  Are you willing to help review the drafts of this = WG?
>
> yes
>
>>
>> 4.  Are you interested in implementing drafts of this = WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think = that the charter should be amended In a significant way, please reply on = a separate thread.
>>
>> The feedback provided here will help the IESG come to a = decision on the formation of a new WG. Given the constraints of the = chartering process, regardless of the outcome of this consensus call, we = will be meeting in Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.
>>
>> The delegation process will be acted upon by multiple parties = in the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.
>>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single = interaction
>> - Separation between the party authorizing access and the party = operating the client requesting access
>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to = allow for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof = of possession
>> - User interaction mechanisms including web and non-web = methods
>> - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions
= >> - Mechanisms for presenting tokens to resource servers and = binding resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the = delegation process (including identity)
>>
>> Additionally, the group will provide mechanisms for management = of the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth = 2.0.
>>
>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
= > --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


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

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_C73045C4-FB22-4D50-B773-3E3DF032B92F-- From nobody Fri Mar 20 18:02:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FAD3A1009 for ; Fri, 20 Mar 2020 18:02:16 -0700 (PDT) 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 uUMKNEAwxz4j for ; Fri, 20 Mar 2020 18:02:11 -0700 (PDT) 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 5A7863A0FC7 for ; Fri, 20 Mar 2020 18:02:10 -0700 (PDT) Received: from [192.168.1.5] (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 02L127ps009536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 21:02:08 -0400 From: Justin Richer Message-Id: <076F0929-164F-417C-BC2F-FB4ECA10E7B2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_775F3265-DECA-4613-A8E1-8AC7B5CE1671" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Mar 2020 21:02:07 -0400 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , Torsten Lodderstedt , Nat Sakimura , "txauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:02:17 -0000 --Apple-Mail=_775F3265-DECA-4613-A8E1-8AC7B5CE1671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 20, 2020, at 2:47 PM, Mike Jones = wrote: >=20 > I agree with many of the points that Dick makes below =E2=80=93 = especially that we should be reusing existing technologies where = applicable and only inventing when doing so creates unique new value. > =20 > Reusing Existing Technology: To the specific point about reusing = existing identity representations, I would request that this point be = added to the charter: > The working group will not create new identity representations; it may = enable the use of existing identity representations or new identity = representations created by others. What is an =E2=80=9Cidentity representation=E2=80=9D, exactly? If you = mean a structured assertion and the like, then I=E2=80=99m with you = completely. If you mean that we can=E2=80=99t return an email address = for the current user, then I don=E2=80=99t agree at all. > AS<->RS relationship: I believe that introspection is unnecessary for = many use cases, and indeed, requiring it would be a regression relative = to OAuth 2.0. Therefore, I support Dick=E2=80=99s proposed = modification: > communication of token attributes between the authorization server and = resource server I=E2=80=99m fine with this modification. > OAuth 2.0 scopes: I agree that the existing OAuth 2.0 scopes should = be easily used in requests and responses. I agree that the syntax should allow it with clear semantics of how to = interpret it. Both proposed input protocols have this feature. > =20 > -- Mike > =20 > From: Txauth > On Behalf Of Dick Hardt > Sent: Friday, March 20, 2020 11:04 AM > To: Justin Richer > > Cc: Yaron Sheffer >; Torsten Lodderstedt = >; Nat Sakimura = >; Mike Jones = >; = txauth@ietf.org > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG > =20 > Nat: thanks for chiming in. Useful insights as always! > =20 > Vittorio: I'll reinterpret your statement about "marketing" the work, = to be that we should solve real problems that people don't have = solutions for today.=20 > =20 > AS<->RS relationship > =20 > TL;DR: I think the charter misses the mark in the AS<->RS relationship = being in scope and we should expand it. > =20 > In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast = to OAuth 1.0, but the interactions / communication between the AS and = the RS were out of scope, as the uses cases at the time had the AS and = RS operated by the same entity. New use cases have a weaker coupling = between the AS and RS, and to enable interop, extensions have been = written for Token Introspection, and JWT Profile for OAuth 2.0 Access = Tokens .=20 > =20 > The TxAuth charter includes introspection: > =20 > - Query of token rights by resource servers=20 > =20 > -- but does not include the common design pattern where the RS can = directly interpret the token. > =20 > Here is proposed updated text to the line above to be broader in scope = than just a query: > =20 > - communication of token attributes between the authorization server = and resource server > =20 > =20 > Architecture and Use Case documents > =20 > TL;DR: Yes to use case doc, no to architecture doc. > =20 > I agree with Justin that an architecture document is unlikely to prove = useful long term. I disagree with him on the use cases. I don't think = the use cases need to be exhaustive, but example use cases helps = everyone understand everyone else's primary use cases. If your use case = is not similar to others, then you should write it up and the WG can = decide if it is in scope or not. If it is, it gets added to the use case = document. I would consider this a living document while working on the = core protocol. It would NOT be a use case document that scopes the WG = work. The charter does that. It would be a companion document to the = core protocol. I strongly think a use case document resolves many of the = miscommunications that happen where people are talking past each other, = because they don't understand each other's use case. > =20 > Reusing Existing Technology > =20 > TL;DR: we should be reusing existing specifications where ever = possible. > =20 > Reading between the lines, I think the concern around identity may be = that the TxAuth charter implies that the WG is going to create = yet-another-identity-representation and ignore all the previous efforts. = I think creating yet-another-identity-representation to solve use cases = that are already solved with existing representations would be misguided = effort. My own interest in TxAuth is being able to use one protocol to = request and receive any existing and future identity representation. One = of my motivations for writing the XAuth document was to show how = different representations could be requested and received, as this was = missing in XYZ. If a use case requires a new representation, then = perhaps TxAuth may be a place for that work to happen, but I think it is = more likely to happen in other forums. > =20 > It is not clear to me how, or if, reusing existing technology fits = into the charter, but I do strongly think it should be a tenet of the = WG. > =20 > On a related note, I also strongly think that the existing OAuth 2.0 = scopes should be easily used in requests and responses. XAuth shows an = example of how that can be done. > =20 > /Dick=20 > =20 > =20 > =20 > =20 > On Fri, Mar 20, 2020 at 6:39 AM Justin Richer > wrote: > I agree with a lot of that argument. Let me see if I can more clearly = restate what I was trying to say earlier in this thread: the = relationships between the different parties are separable and depend on = the kind of deployments and use cases that are being addressed by = people. So in an OAuth/OIDC-style world, we=E2=80=99ve got three = components (ignoring people), and three relationships between them: > =20 > C<->AS > =20 > C<->RS > =20 > AS<->RS > =20 > For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, = =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow to interpret a = token=E2=80=9D. For authentication, it=E2=80=99s additionally =E2=80=9Chow= do I get the authentication info=E2=80=9D, =E2=80=9Chow do I ask for a = profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80=9D= . I still believe this is a good separation of concerns. The client = doesn=E2=80=99t need to know what=E2=80=99s in the access token, or if = it=E2=80=99s a reference or self-contained, or really concern itself at = all with what the RS does with it. Are there overlaps? Certainly =E2=80=94= the client needs to know how to ask for a token that the RS will accept = for what the client is going to do, and to do that the client needs to = be able to describe what it wants to do in a way that the AS can = interpret and map to a set of rights that the RS will eventually = interpret.=20 > =20 > I believe the proposed charter already covers this split with the = following items: > =20 > - Fine-grained specification of access > - Approval of access to multiple resources and APIs in a single = interaction > - Separation between the party authorizing access and the party = operating the client requesting access > - Revocation of active tokens > - Query of token rights by resource servers > =20 > It=E2=80=99s the combination of the rich request and the lifecycle = management that puts the AS and RS in scope. I think things like = declaring a single token format are absolutely out =E2=80=94 if you want = to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just fine. = However, something that I think is in scope is defining a structure for = what a token represents. And I think that if we can do that in this WG = in a general way, then that=E2=80=99s useful. Because then that = structure can be represented by mapping to a token format or an = introspection response or a database entry. I think Nat=E2=80=99s = comments on ABAC are important: we are going to need a place to put = those attributes. Whether they=E2=80=99re communicated to the RS through = the token itself or through some other channel is, I strongly believe, a = matter of deployment choice. > =20 > So, what can the charter say to make this more clear? > =20 > All that said, I=E2=80=99m against having an architecture document as = a working group output. In my experience, when a WG puts its effort into = a formal architecture doc as a deliverable, there is a lot of = conjectural energy that goes into what might be a good idea, and then = not all of it works out when you try to hammer the details of making = that architecture into a real engineered thing.You end up baking in = assumptions and abstractions that don=E2=80=99t make sense anymore, and = then trying to engineer solutions around those when they don=E2=80=99t = fit right. If the architecture can=E2=80=99t change in light of new = information, which is the case with an RFC, then it becomes a shackle = instead of a scaffold. But a malleable document that the group can use = as a guide while engineering the actual parts =E2=80=94 yes, that makes = sense. The architecture can be refactored and changed as decisions are = made and things come into focus. I feel the same about use case = documents as formal artifacts.=20 > =20 > Thanks, Nat. > =E2=80=94 Justin >=20 >=20 > On Mar 20, 2020, at 2:19 AM, Nat Sakimura > wrote: > =20 > I thought I should keep my mouth shut as anything I say may be deemed = biased as my other hat is the chairman of OIDF, but here is my 2c.=20 > =20 > As Torsten indicated, there is much to be desired to standardize the = AS - RS communication patterns. You may say that the charter includes = it, but I cannot read it out of the charter just like Torsten could not. = As a new protocol, it would be good to include it.=20 > =20 > In this respect, I am not sure if we should start off from OAuth 2.0 = and OIDC model. If we are creating a new protocol, I feel that we should = architect is more fully. Not mentioning AS - RS relationship to me feels = like an indication of this failure. For that matter, I feel that the = first output of the group should be an architecture document that takes = the concerns from all the relevant stakeholders/actors in.=20 > =20 > We should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme) etc. We are not = going to get to a unified identity world anytime soon.=20 > =20 > Cheers,=20 > =20 > Nat Sakimura > =20 > =20 > On Wed, Mar 18, 2020 at 7:06 AM Mike Jones = > wrote: > I believe it's significant that four people have expressed concerns = with including digital identity in the charter (the only concerns voiced = as far as I can tell). At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter. >=20 > It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way. If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so. >=20 > -- Mike >=20 > -----Original Message----- > From: Justin Richer >=20 > Sent: Tuesday, March 17, 2020 2:20 PM > To: Mike Jones > > Cc: Yaron Sheffer >; Torsten Lodderstedt = >; = txauth@ietf.org > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >=20 > While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things. >=20 > As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.=20 >=20 > The market has shown us that the most common application of OAuth 2 is = far and away access to identity information along side access to an API. = I think we need to pay attention to that and not make this separate just = because we did it that way before. And some of the proposed innovations, = including getting and sending VC=E2=80=99s, are all about identity. >=20 > Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >=20 > If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >=20 > =E2=80=94 Justin >=20 > > On Mar 17, 2020, at 1:12 PM, Mike Jones = > wrote: > >=20 > > 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? > >=20 > > I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique = athttps://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE= / = . > >=20 > > I'm fine with refactoring the authorization protocol. But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed. Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0. > >=20 > > Please revise the charter to remove digital identity from the scope = of the work. > >=20 > > 2. Are you willing to author or participate in the development of = the drafts of this WG? > >=20 > > Yes > >=20 > > 3. Are you willing to help review the drafts of this WG? > >=20 > > Yes > >=20 > > 4. Are you interested in implementing drafts of this WG? > >=20 > > Not at this time. > >=20 > > -- Mike > >=20 > > -----Original Message----- > > From: Txauth > On Behalf Of Torsten Lodderstedt > > Sent: Saturday, March 7, 2020 7:18 AM > > To: Yaron Sheffer > > > Cc: txauth@ietf.org > > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth = WG > >=20 > > Hi, > >=20 > >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer >: > >>=20 > >> =EF=BB=BFHi Everyone, > >>=20 > >> It appears that momentum is forming around the proposed formation = of a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: > >>=20 > >> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? > >=20 > > I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic.. > >=20 > > We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. > >=20 > >>=20 > >> 2. Are you willing to author or participate in the development of = the drafts of this WG? > >=20 > > yes > >=20 > >>=20 > >> 3. Are you willing to help review the drafts of this WG? > >=20 > > yes > >=20 > >>=20 > >> 4. Are you interested in implementing drafts of this WG? > >=20 > > yes > >=20 > > best regards, > > Torsten. > >=20 > >>=20 > >> The call will run for two weeks, until March 21. If you think that = the charter should be amended In a significant way, please reply on a = separate thread. > >>=20 > >> The feedback provided here will help the IESG come to a decision on = the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. > >>=20 > >> Thanks, > >> Yaron and Dick > >>=20 > >> --- Charter Text Follows --- > >>=20 > >> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 > >>=20 > >> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. > >>=20 > >> Additionally, the delegation process will allow for: > >>=20 > >> - Fine-grained specification of access > >> - Approval of AS attestation to identity claims > >> - Approval of access to multiple resources and APIs in a single = interaction > >> - Separation between the party authorizing access and the party = operating the client requesting access > >> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications > >>=20 > >> The group will define extension points for this protocol to allow = for flexibility in areas including: > >>=20 > >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 > >> - User interaction mechanisms including web and non-web methods > >> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > >> - Optimized inclusion of additional information through the = delegation process (including identity) > >>=20 > >> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: > >>=20 > >> - Discovery of the authorization server > >> - Revocation of active tokens > >> - Query of token rights by resource servers > >>=20 > >> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. > >>=20 > >> This group is not chartered to develop extensions to OAuth 2.0, and = as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. > >>=20 > >> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.=20 > >>=20 > >> The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. > >>=20 > >> Milestones to include: > >> - Core delegation protocol > >> - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures > >> - Identity and authentication conveyance mechanisms > >> - Guidelines for use of protocol extension points > >>=20 > >>=20 > >> --=20 > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 > =20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > =20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_775F3265-DECA-4613-A8E1-8AC7B5CE1671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 20, 2020, at 2:47 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I agree with many of the = points that Dick makes below =E2=80=93 especially that we should be = reusing existing technologies where applicable and only inventing when = doing so creates unique new value.
 
Reusing Existing Technology: To the specific point about reusing existing = identity representations, I would request that this point be added to = the charter:
  • The = working group will not create new identity representations; it may = enable the use of existing identity representations or new identity = representations created by = others.

What is an =E2=80=9Cidentity representation=E2=80=9D= , exactly? If you mean a structured assertion and the like, then I=E2=80=99= m with you completely. If you mean that we can=E2=80=99t return an email = address for the current user, then I don=E2=80=99t agree at = all.

AS<->RS relationship: I = believe that introspection is unnecessary for many use cases, and = indeed, requiring it would be a regression relative to OAuth 2.0.  = Therefore, I support Dick=E2=80=99s proposed modification:
  • communication of token = attributes between the authorization server and resource = server

I=E2=80=99= m fine with this modification.

OAuth 2.0 scopes:  I agree that the existing OAuth = 2.0 scopes should be easily used in requests and responses.

I = agree that the syntax should allow it with clear semantics of how to = interpret it. Both proposed input protocols have this = feature.


 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Friday, March 20, 2020 = 11:04 AM
To: Justin Richer <jricher@mit.edu>
Cc: Yaron= Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net>; = Nat Sakimura <sakimura@gmail.com>; = Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>; txauth@ietf.org
Subject: Re: [Txauth] Call for = charter consensus - TxAuth WG
 
Nat: = thanks for chiming in. Useful insights as always!
 
Vittorio: I'll reinterpret your = statement about "marketing" the work, to be that we should solve real = problems that people don't have solutions for today. 
 
AS<->RS = relationship
 
TL;DR: I think the charter misses the mark in the = AS<->RS relationship being in scope and we should expand it.
 
In OAuth 2.0 (RFC6749)l, the AS and RS = were separate roles in contrast to OAuth 1.0, but the interactions / = communication between the AS and the RS were out of scope, as the uses = cases at the time had the AS and RS operated by the same entity. New use = cases have a weaker coupling between the AS and RS, and to enable = interop, extensions have been written for Token Introspection, and JWT = Profile for OAuth 2.0 Access Tokens . 
 
The TxAuth charter includes = introspection:
 
- Query of token rights by resource = servers 
 
-- but does not include the common design pattern where the = RS can directly interpret the token.
 
Here is proposed updated text to the line above to be = broader in scope than just a query:
 
- communication of token = attributes between the authorization server and resource server
 
 
Architecture and Use Case = documents
 
TL;DR: Yes to use case doc, no to architecture doc.
 
I agree with Justin that an = architecture document is unlikely to prove useful long term. I = disagree with him on the use cases. I don't think the use cases need to = be exhaustive, but example use cases helps everyone understand everyone = else's primary use cases. If your use case is not similar to others, = then you should write it up and the WG can decide if it is in scope or = not. If it is, it gets added to the use case document. I would consider = this a living document while working on the core protocol. It would NOT = be a use case document that scopes the WG work. The charter does that. = It would be a companion document to the core protocol. I strongly think = a use case document resolves many of the miscommunications that happen = where people are talking past each other, because they don't understand = each other's use case.
 
Reusing Existing Technology
 
TL;DR: we should be reusing existing = specifications where ever possible.
 
Reading between the lines, I think the concern around = identity may be that the TxAuth charter implies that the WG is going to = create yet-another-identity-representation and ignore all the previous = efforts. I think creating yet-another-identity-representation to = solve use cases that are already solved with existing representations = would be misguided effort. My own interest in TxAuth is being able to = use one protocol to request and receive any existing and future identity = representation. One of my motivations for writing the XAuth document was = to show how different representations could be requested and received, = as this was missing in XYZ.  If a use case requires a new = representation, then perhaps TxAuth may be a place for that work to = happen, but I think it is more likely to happen in other forums.
 
It is not clear to me how, or if, = reusing existing technology fits into the charter, but I do strongly = think it should be a tenet of the WG.
 
On a related note, I also strongly think that the existing = OAuth 2.0 scopes should be easily used in requests and responses. XAuth = shows an example of how that can be done.
 
/Dick 
 
 
 
 
On Fri, = Mar 20, 2020 at 6:39 AM Justin Richer <jricher@mit.edu> wrote:
I agree = with a lot of that argument. Let me see if I can more clearly restate = what I was trying to say earlier in this thread: the relationships = between the different parties are separable and depend on the kind of = deployments and use cases that are being addressed by people. So in an = OAuth/OIDC-style world, we=E2=80=99ve got three components (ignoring = people), and three relationships between them:
 
C<->AS
 
C<->RS
 
AS<->RS
 
For authorization, these map to =E2=80=9C= how to get a token=E2=80=9D, =E2=80=9Chow to use a token=E2=80=9D, and = =E2=80=9Chow to interpret a token=E2=80=9D. For authentication, it=E2=80=99= s additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, = =E2=80=9Chow do I ask for a profile=E2=80=9D, and =E2=80=9Chow do I know = whose profile this is=E2=80=9D. I still believe this is a good = separation of concerns. The client doesn=E2=80=99t need to know what=E2=80= =99s in the access token, or if it=E2=80=99s a reference or = self-contained, or really concern itself at all with what the RS does = with it. Are there overlaps? Certainly =E2=80=94 the client needs to = know how to ask for a token that the RS will accept for what the client = is going to do, and to do that the client needs to be able to describe = what it wants to do in a way that the AS can interpret and map to a set = of rights that the RS will eventually interpret. 
 
I believe the proposed charter already = covers this split with the following items:
 
- Fine-grained specification of = access
- Approval of access to multiple resources and APIs = in a single interaction
- Separation between the party = authorizing access and the party operating the client requesting = access
- Revocation of active tokens
- Query of token rights by resource servers
 
It=E2=80=99s the combination of the = rich request and the lifecycle management that puts the AS and RS in = scope. I think things like declaring a single token format are = absolutely out =E2=80=94 if you want to use JWT, or CWT, or UUID=E2=80=99s= , that=E2=80=99s all just fine. However, something that I think is in = scope is defining a structure for what a token represents. And I think = that if we can do that in this WG in a general way, then that=E2=80=99s = useful. Because then that structure can be represented by mapping to a = token format or an introspection response or a database entry. I think = Nat=E2=80=99s comments on ABAC are important: we are going to need a = place to put those attributes. Whether they=E2=80=99re communicated to = the RS through the token itself or through some other channel is, I = strongly believe, a matter of deployment choice.
 
So, what can the charter say to make = this more clear?
 
All that said, I=E2=80=99m against having an architecture = document as a working group output. In my experience, when a WG puts its = effort into a formal architecture doc as a = deliverable, there is a lot of conjectural energy that goes into = what might be a good idea, and then not all of it works out when you try = to hammer the details of making that architecture into a real engineered = thing.You end up baking in assumptions and abstractions that don=E2=80=99t= make sense anymore, and then trying to engineer solutions around those = when they don=E2=80=99t fit right. If the architecture can=E2=80=99t = change in light of new information, which is the case with an RFC, then = it becomes a shackle instead of a scaffold. But a malleable document = that the group can use as a guide while engineering the actual parts =E2=80= =94 yes, that makes sense. The architecture can be refactored and = changed as decisions are made and things come into focus. I feel the = same about use case documents as formal artifacts. 
 
Thanks, Nat.
 =E2=80=94 Justin


On Mar 20, 2020, at 2:19 AM, Nat Sakimura <sakimura@gmail.com> = wrote:
 
I thought I should keep my = mouth shut as anything I say may be deemed biased as my other hat = is the chairman of OIDF, but here is my 2c. 
 
As Torsten indicated, there is much to = be desired to standardize the AS - RS communication patterns. You may = say that the charter includes it, but I cannot read it out of the = charter just like Torsten could not. As a new protocol, it would be good = to include it. 
 
In this respect, I am not sure if we should start off from = OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel that = we should architect is more fully. Not mentioning AS - RS relationship = to me feels like an indication of this failure. For that matter, I feel = that the first output of the group should be an architecture document = that takes the concerns from all the relevant stakeholders/actors = in. 
 
We should also be cognizant of the access control models = like ABAC. For that, decoupling of identity (=3D set of claims) = assertion and authorization is a necessity. We could optimize it but the = base case should take care of it. (In this respect, I am feeling that = OIDC has perhaps over-optimized.) So, I feel that at least as the first = step, TxAuth should concentre on the Access Control. If I were to go one = step further, it should be modelled so that it can consume various = identity assertions (authenticated identity in ISO/IEC 24760 speak) = including ID Token, SAML Assertion, DID Verifiable Credentials, X.509 = certificates (such as in eIDAS and Japanese National ID scheme)  = etc. We are not going to get to a unified identity world anytime = soon. 
 
Cheers, 
 
Nat Sakimura
 
 
On Wed, Mar 18, 2020 at = 7:06 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
I believe it's = significant that four people have expressed concerns with including = digital identity in the charter (the only concerns voiced as far as I = can tell).  At a minimum, I believe that that warrants making the = inclusion or exclusion of digital identity a discussion topic during the = upcoming virtual BoF, before adopting any charter.

It would be my proposal to initially charter without digital = identity and see how far we get with our energies intentionally focused = in that way.  If the working group decides to recharter to include = digital identity, that can always happen later, after the = authorization-focused work has matured, and once there's a clear case to = actually do so.

        =                     =     -- Mike

-----Original = Message-----
From: Justin Richer <jricher@mit.edu> 
Sent: = Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron = Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net>; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth = WG

While I understand the concerns around = identity in the charter, and I had initially not included it, I was = convinced that the kind of identity protocol that we=E2=80=99re looking = at here is a minor addition to the authorization and delegation end of = things.

As you know, much of what=E2=80=99s = in OIDC is there to fix problems with OAuth 2 when it=E2=80=99s used for = identity. If OAuth 2 had solved those problems internally, then OIDC = would be much, much simpler and smaller. We=E2=80=99re now starting at a = base where those problems don=E2=80=99t exist, but we don=E2=80=99t yet = know what other problems there might be. 

The market has shown us that the most common application of = OAuth 2 is far and away access to identity information along side access = to an API. I think we need to pay attention to that and not make this = separate just because we did it that way before. And some of the = proposed innovations, including getting and sending VC=E2=80=99s, are = all about identity.

Furthermore, this = charter does not specify the document and specification structure of the = components, nor does it specify the publication order or timing of any = documents. I personally think that the identity layer should be = separable to an extent, to the point of publishing that layer in its own = spec alongside the core authorization delegation system. However, that = does not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an = identity protocol that we will explicitly cover, then I would welcome = you to suggest an amended text to the charter. However, I believe there = is enough interest within the community to work on identity in the = context of this protocol, including a large number of people being OK = with it in the charter, that it would not be a reasonable thing to = remove it.

 =E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
> 
> 1.  Do you support the charter text provided at the = end of this email?  Or do you have major objections, blocking = concerns or feedback (if so please elaborate)?
> 
> I share = the concerns about including identity in the charter that were expressed = by Torsten and agreed with by David Skaife.  I'll note that Kim = Cameron previously expressed concerns about including identity in his = earlier charter critique athttps://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXS= nshX2CahE/.
> 
> I'm = fine with refactoring the authorization protocol.  But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed.  Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0.
> 
> Please = revise the charter to remove digital identity from the scope of the = work.
> 
> = 2.  Are you willing to author or participate in the development of = the drafts of this WG?
> 
> Yes
> 
> 3.  Are you willing to help review the drafts of = this WG?
> 
> Yes
> 
> 4.  Are you interested in implementing drafts of = this WG?
> 
> Not at = this time.
> 
>  =                     =          -- Mike
> 
> = -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten = Lodderstedt
> Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.org
> Subject: [EXTERNAL] Re: [Txauth] Call for charter = consensus - TxAuth WG
> 
> Hi,
> 
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>> 
>> = =EF=BB=BFHi Everyone,
>> 
>> It = appears that momentum is forming around the proposed formation of a = TxAuth working group.  We=E2=80=99d like to more formally gauge = interest in proceeding with this work.  Please do so by responding = to the following questions:
>> 
>> = 1.  Do you support the charter text provided at the end of this = email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
> 
> I=E2=80=98= m in although I have to admit I=E2=80=98m slightly concerned the scope = of the charter is too broad, e.g. identify alone is a huge topic..
> 
> We need to keep an eye on this aspect in order to make = sure, the group is able to work effectively and the specs we will be = producing are as simple as possible and foster interoperability.
> 
>> 
>> 2.  Are you willing to author or participate in = the development of the drafts of this WG?
> 
> yes
> 
>> 
>> 3.  Are you willing to help review the drafts = of this WG?
> 
> yes
> 
>> 
>> 4.  Are you interested in implementing drafts = of this WG?
> 
> yes
> 
> best regards,
> Torsten.
> 
>> 
>> The call will run for two weeks, until March 21. If = you think that the charter should be amended In a significant way, = please reply on a separate thread.
>> 
>> The = feedback provided here will help the IESG come to a decision on the = formation of a new WG. Given the constraints of the chartering process, = regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>> 
>> = Thanks,
>> Yaron and Dick
>> 
>> --- = Charter Text Follows ---
>> 
>> = This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. 
>> 
>> The = delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.
>> 
>> = Additionally, the delegation process will allow for:
>> 
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs = in a single interaction
>> - Separation between the = party authorizing access and the party operating the client requesting = access
>> - A variety of client applications, = including Web, mobile, single-page, and interaction-constrained = applications
>> 
>> The = group will define extension points for this protocol to allow for = flexibility in areas including:
>> 
>> - = Cryptographic agility for keys, message signatures, and proof of = possession 
>> - User interaction mechanisms including web and = non-web methods
>> - Mechanisms for conveying user, = software, organization, and other pieces of information used in = authorization decisions
>> - Mechanisms for = presenting tokens to resource servers and binding resource requests to = tokens and associated cryptographic keys
>> - = Optimized inclusion of additional information through the delegation = process (including identity)
>> 
>> = Additionally, the group will provide mechanisms for management of the = protocol lifecycle including:
>> 
>> - = Discovery of the authorization server
>> - = Revocation of active tokens
>> - Query of token = rights by resource servers
>> 
>> = Although the artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible.
>> 
>> = This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth = 2.0.
>> 
>> The = group is chartered to develop mechanisms for applying cryptographic = methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods. 
>> 
>> The = initial work will focus on using HTTP for communication between the = client and the authorization server, taking advantage of optimization = features of HTTP2 and HTTP3 where possible, and will strive to enable = simple mapping to other protocols such as COAP when doing so does not = conflict with the primary focus.
>> 
>> = Milestones to include:
>> - Core delegation = protocol
>> - Key presentation mechanism bindings to = the core protocol for TLS, detached HTTP signature, and embedded HTTP = signatures
>> - Identity and authentication = conveyance mechanisms
>> - Guidelines for use of = protocol extension points
>> 
>> 
>> = -- 
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

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

= --Apple-Mail=_775F3265-DECA-4613-A8E1-8AC7B5CE1671-- From nobody Fri Mar 20 18:13:14 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55323A0FF6 for ; Fri, 20 Mar 2020 18:13:11 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 9zVIJQ4Y3vhq for ; Fri, 20 Mar 2020 18:13:09 -0700 (PDT) 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 EB78F3A0EBF for ; Fri, 20 Mar 2020 18:13:08 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id 19so8433835ljj.7 for ; Fri, 20 Mar 2020 18:13:08 -0700 (PDT) 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=jYQH8b3NN3dMLKLq5XbXkoJvoYXD8BHsj3pyKD9rJ7g=; b=NBZXZ1vA+SO6Y/+8v3EL1BwntaHKpMwKQlk3qs01tOb7TlLyrEUnlmcdVaCt0X7P/O U4jWoDTGxgTlixvF3F8JMkq/F7xl/6XNzvTl9Ee14E/0Us3avahDCYYKX2OMwgfCzA/h Xqv3vOz6tq3m/U07gYdLcdaKYrneD9SHSUkXIUASRvmoOYujdEMg4coHP++zBWe7Is7u JdT8kmtZARYOcEpLMe1i/GGBQFajpWLdR3SnVfB4oiPV4afSW7SLIsiuXP9qKHAn2VGb 5ZoNDlTaigsFz+KSjxOwEGUCFFGFfxSJORhE2JM/lxXDWIzGql5opFzmwWdJXxoPB0k5 TWlQ== 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=jYQH8b3NN3dMLKLq5XbXkoJvoYXD8BHsj3pyKD9rJ7g=; b=PP4uOmJVMvaxob/ks8+O6FC6ly86/1X+ahEBVqrsKC0rXPVpvGXRFEGtI1KLEMr+2a M0GNONP9lFv65C5vLSn5N1nCLmympwo5uk84y8Z3A0ELV3XsZaju+Jw77UbmoAKh+RU1 /BTkv6wRxPFjuteQrHk0k2AazL75KcjHyLOMRoyCCo/mRebbvyjXzdIqL5FZJFg9tY/i 8pbMQKnyEO3R6gB7yXUvtJRCm/RAzpgHo8IgT8PS2Dwxr4mBwYkWUTomcUqenkqFosaY 92r6XVKwtNlpeaeZc41W6dsgAmYSjCPliowh8c6qubi/Xg6/WqcvCSwmptcgGr7ebu5E 93Zw== X-Gm-Message-State: ANhLgQ0hGDU3c/7IpiKwXDD1JQzb/pAsMZu8XWI4DDR0A6Lw/cFAD3my iuUrLNqXybqsMtQbp/XBOXzmdz8xvPEjcoWAUbE= X-Google-Smtp-Source: ADFU+vvIjsQF3q3dezgdnbpe6+l42nAJUVGJHs5BHuysbfhQ8Dc4J8iNlp3w3+oQIbRlt4FEAYT1BdAewbHlCOm3AYI= X-Received: by 2002:a2e:9a0d:: with SMTP id o13mr6798887lji.151.1584753186459; Fri, 20 Mar 2020 18:13:06 -0700 (PDT) MIME-Version: 1.0 References: <076F0929-164F-417C-BC2F-FB4ECA10E7B2@mit.edu> In-Reply-To: <076F0929-164F-417C-BC2F-FB4ECA10E7B2@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 18:12:40 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Yaron Sheffer , Torsten Lodderstedt , Nat Sakimura , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bc563805a1531ac0" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:13:12 -0000 --000000000000bc563805a1531ac0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2020 at 6:02 PM Justin Richer wrote: > On Mar 20, 2020, at 2:47 PM, Mike Jones > wrote: > > > I agree with many of the points that Dick makes below =E2=80=93 especiall= y that we > should be reusing existing technologies where applicable and only inventi= ng > when doing so creates unique new value. > > *Reusing Existing Technology: *To the specific point about reusing > existing identity representations, I would request that this point be add= ed > to the charter: > > - The working group will not create new identity representations; it > may enable the use of existing identity representations or new identit= y > representations created by others. > > > What is an =E2=80=9Cidentity representation=E2=80=9D, exactly? If you mea= n a structured > assertion and the like, then I=E2=80=99m with you completely. If you mean= that we > can=E2=80=99t return an email address for the current user, then I don=E2= =80=99t agree at > all. > When you say email address, I would assume you mean an existing email address standard, and that the group is not defining a new way to represent an email address. Correct? As I am sure you are aware, schemas are hard, and I don't think it is appropriate for this group to define new ones for phone numbers or postal addresses. The same would go with the various ways to represent a person's name. I think we should reference existing standards in this area unless we absolutely must to create new, unique value. --000000000000bc563805a1531ac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 20, 2020 at 6:02 PM Justi= n Richer <jricher@mit.edu> wro= te:
On Mar 20, 2020, at 2:47 PM, Mike Jones <= ;Michael.J= ones@microsoft.com> wrote:

I agree= with many of the points that Dick makes below =E2=80=93 especially that we= should be reusing existing technologies where applicable and only inventin= g when doing so creates unique new value.
=C2=A0
Reusing Existing Technology:=C2=A0To the specific point about reusing existing identity r= epresentations, I would request that this point be added to the charter:=
  • The working group will not create new= identity representations; it may enable the use of existing identity repre= sentations or new identity representations created by others.

What is an =E2=80=9Cidentity repre= sentation=E2=80=9D, exactly? If you mean a structured assertion and the lik= e, then I=E2=80=99m with you completely. If you mean that we can=E2=80=99t = return an email address for the current user, then I don=E2=80=99t agree at= all.

When you say email = address, I would assume you mean an existing email address standard, and th= at the group is not defining a new way to represent an email address. Corre= ct?

As I am sure you are aware, schemas are hard, = and I don't think it is appropriate for this group to define new ones f= or phone numbers or postal addresses.=C2=A0

The sa= me would go with the various ways to represent a person's name. I think= we should reference existing standards in this area unless we absolutely m= ust to create=C2=A0new, unique value.=C2=A0





--000000000000bc563805a1531ac0-- From nobody Fri Mar 20 18:17:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3503A102A for ; Fri, 20 Mar 2020 18:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_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=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 UfkYPMIPjD0o for ; Fri, 20 Mar 2020 18:17:00 -0700 (PDT) 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 C62C93A1028 for ; Fri, 20 Mar 2020 18:16:59 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id o10so8444978ljc.8 for ; Fri, 20 Mar 2020 18:16:59 -0700 (PDT) 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=4wxJJ6WoT1Pg0Fqkg1TObJCCyAvcectEJYyMCv3rdsc=; b=a/BHqgJs/se9+9GQCLRbDz4w0dV67+RhzFqYKf8v//V7TXnhJRF4zN/LZnyrYpZ7up m8YQnaTE1wuimhM0uyzi7JSlXvTvU45QmIrlorkHdcyDU1JoQiDb279Cc3khn0SBDn/6 1VQTgxDRgmE61Z8wFZICmvijoyUAFmdWku/3yebK29LtJc/gqpDLxQJXCfSuCkkdXrE2 /xxuFXStLYVbNlu4v0V+QYDxKS93/mlpHzJrCx+rMnTN1M9/2o1nh2FEiqmpD2+GZ8yp TRcWo2JGzFHcXdE5m58W533ZDjrgIaCU+KiwfYCfPyXWs9glagxInfwVjYPYikJZWhsH A/JQ== 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=4wxJJ6WoT1Pg0Fqkg1TObJCCyAvcectEJYyMCv3rdsc=; b=l+FiLTQtaVfx5xjiQy64oWKBu6SQmPTN0SaFzTh+gPM8iK3tWqPx0oNfdOF+j/wP13 0Q6MLCmhssglH/eXbcU53nS8xPDHC67GiTMKf8qUE4sfK1ZqPsOBL2HIFg41YJPmI+2p ILFYLpukzBAq/LPW8a8JAW5xt5qPlNmAzAjiZApsrUhyY+XnI+ykEMKKb56ZHVyvukeW tz3Rq2MXz69N7rJoIKlXHfia2QCjj7HwMcZSM46K0vqhQ/z9We6dNGjW6z97G6/wu23f gfGTzy47KnlOEqxfRnByNMZltcWeanfbyudEr4ekXRXjw2Zt1kLhWGfzlFnYVwBtVzuU gHGg== X-Gm-Message-State: ANhLgQ0xSCd9RkOLqaLds7sF36F0LcK2kNIfMFKly/rZpL6Lwb2Jq48u u0/xigfPL43QvO4+qrvTEME+vMhRGHX/CTkV0Tk= X-Google-Smtp-Source: ADFU+vsl9cbW+ozgoSTiZP0jKQ/qgna8f30W+tLYPIGAwGWNVUN8x1nSy2DU0oVjDv/nafh4XaEmSzUDBpSPKHLGCpU= X-Received: by 2002:a2e:9a0d:: with SMTP id o13mr6804830lji.151.1584753416555; Fri, 20 Mar 2020 18:16:56 -0700 (PDT) MIME-Version: 1.0 References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> In-Reply-To: <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> From: Dick Hardt Date: Fri, 20 Mar 2020 18:16:30 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000734fcc05a1532880" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 01:17:08 -0000 --000000000000734fcc05a1532880 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That would be easier if it was TAuth rather than TxAuth. "Tx" is well known to mean transaction -- regardless of what we decide. "O" could mean anything that starts with "O", and my experience has been few people know the work started as OpenAuth. I've made my argument, I'm fine going with the group consensus. I do reserve the right in the future to say "I told you so!" =3D) Does anyone else have an opinion? On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: > Dick, thanks for pulling the definitions up: > > > a communicative action or activity involving two parties or things that > reciprocally affect or influence each other > > This is the kind of thing that I had in mind. The client and the AS are i= n > a conversation over time that each one contributes to and each changes. > > Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D= doesn=E2=80=99t stand for > =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that th= e =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D > doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. > > None of the arguments below in favor of XAuth have made me like that name > better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then w= hy come up with something > new? > > =E2=80=94 Justin > > On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: > > > > > not a transaction - there are multiple transactions > > backchannel innovation is combination of here is who I am, and here is > what I want to do > > > childhood trauma therapy group > > > > On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: > >> Yes, naming things is hard =E2=80=94 but I still believe in the name TxA= uth. >> We=E2=80=99re moving beyond OAuth, and taking the process of getting an >> authorization delegated to the client software as a multi-step, multi-pa= rty >> transaction is, I believe, the key insight that=E2=80=99s letting us mov= e beyond >> OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to t= he AS first =E2=80=94 we >> had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PA= R. I really >> think it=E2=80=99s about the transaction at the core. >> > > OAuth 2.0 had multi-step, multi-party. TxAuth extends that. > > I think the big shift is going to the AS. This enables the request to be > richer with JSON, instead of name/value pairs parameters in a URI. It > allows the client and AS to negotiate, and to short circuit having to > redirect the user to the AS. PAR does some of this, but it is constrained > by having to do it in the OAuth 2.0 context. > > My concern is that the protocol is MUCH MORE than a transaction. While th= e > initial interaction between client, AS, user and RO is a transaction. The > protocol also covers the client and RS interactions. The access token > refreshes. Access token revocation. Access token introspection. As > described in the charter, there is a whole lifecycle, that consists of > multiple transactions. > > From https://www.merriam-webster.com/dictionary/transaction: > > Definition of *transaction* > > 1a: something transacted > especially : an > exchange or transfer of > goods, services, or fundselectronic transactions > b: transactions plural : the often published record of the meeting of a > society or association > 2a: an act, process, or instance of transacting > > b: a communicative action or activity involving two parties or things > that reciprocally affect or influence each other > > Calling the protocol a transaction will confusing to people. > > >> >> Having come of age in the 1990=E2=80=99s, I have particular dislike for = XAuth. It >> sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and= if you read either of those with a >> growling yell in your head then you know exactly what I=E2=80=99m talkin= g about. >> > > In case you are confused, this is not a childhood trauma support group. = :) > > Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. > X-Men, Xbox, X-Factor, X-files. > > https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 > > > https://english.stackexchange.com/questions/358181/whats-the-purpose-of-u= sing-letter-x-or-x-as-a-suffix-in-brand-names > > > >> And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this >> work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think tha= t does a disservice >> to the kind of change we have an opportunity to make here. >> > > From the charter > > "It will expand upon the uses cases currently supported by OAuth 2.0 and > OpenID Connect (itself an extension of OAuth 2.0)" > > > Which sounds pretty similar to =E2=80=9COAuth with all the extra features= =E2=80=9D > > While I think XAuth captures what we are doing, a placeholder name would > be preferable to an incorrect descriptive name such as TxAuth. > > For example, XYZ is a good placeholder name. Or XYZAuth. Let's not mislea= d > people. > > > >> >> =E2=80=94 Justin >> >> On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >> >> Hello everyone >> >> I prompted a thread around the name of the protocol a while back: >> >> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc= / >> >> As Justin stated "naming is hard" >> >> Wearing my marketing hat I want to ensure that the name will be >> perceived properly in the broader community. >> >> A recent example that comes to mind are the privacy related works on the >> browser storage API. Given that name, one would think that it is local >> storage. It is actually about browser cookies. >> >> Justin discussed his reasons for TxAuth in the thread above (and I'm sur= e >> in other places) >> >> I chose XAuth in my draft to reflect the eXtensibility goal that we have >> over OAuth -- and XAuth is OAuth but with an X to reflect all the extra >> features. =3D) >> >> Other suggestions? >> >> This will be an agenda item in the BoF -- but the name will NOT be an >> open discussion item -- we will summarize what has been discussed on the >> list and perhaps do a poll of options presented unless consensus is obvi= ous >> from this thread. >> >> /Dick >> >> >> >> >> >> =E1=90=A7 >> >> >> > --000000000000734fcc05a1532880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That would be easier if it was TAuth rather than TxAuth. &= quot;Tx" is well known to mean transaction -- regardless of what we de= cide. "O" could mean anything that starts with "O", and= my experience has been few people know the work started as OpenAuth.
= =C2=A0
I've made my argument, I'm fine going=C2=A0wit= h the group consensus. I do reserve the right in the future to say "I = told you so!" =3D)

Does anyone else have an= =C2=A0opinion?

On Fri, Mar 20, 2020 at 5:53 PM Justin Richer <jricher@mit.edu> wrote:
Dick, thanks for pulling the definitions up:

>=C2=A0a comm= unicative action or activity involving two parties or things that reciproca= lly affect or influence each other

This is = the kind of thing that I had in mind. The client and the AS are in a conver= sation over time that each one contributes to and each changes.=C2=A0
=

Also =E2=80=94 we can just as easily decide that =E2=80= =9CTxAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9CTransactional Auth=E2= =80=9D much the same way we decided that the =E2=80=9CO=E2=80=9D in =E2=80= =9COAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore.= =C2=A0

None of the arguments below in favor of XAu= th have made me like that name better. If it=E2=80=99s just a =E2=80=9Cplac= eholder=E2=80=9D name, then why come up with something new?

<= /div>
=C2=A0=E2=80=94 Justin

On Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



not a transaction - there are multiple transactions

backchannel innovation is combination=C2=A0of here is who I am, and here= is what I want to do


childhood tra= uma therapy group



On Mon, Mar 16, 2020= at 6:56 PM Justin Richer <jricher@mit.edu> wrote:
Yes, naming things is hard =E2=80=94 but I stil= l believe in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking= the process of getting an authorization delegated to the client software a= s a multi-step, multi-party transaction is, I believe, the key insight that= =E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. It=E2= =80=99s not just about going to the AS first =E2=80=94 we had that in OAuth= 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I really think it= =E2=80=99s about the transaction at the core.=C2=A0
=
OAuth 2.0 had multi-step, multi-party. TxAuth extends that.<= /div>

I think the big shift is going to the AS. This ena= bles the request to be richer with JSON, instead of name/value pairs parame= ters in a URI. It allows the client and AS to negotiate, and to short circu= it having to redirect the user to the AS. PAR does=C2=A0some of this, but i= t is constrained by having to do it in the OAuth 2.0 context.
My concern is that the protocol is MUCH MORE than a transaction= . While the initial interaction between client, AS, user and RO is a transa= ction. The protocol also covers the client=C2=A0and RS interactions. The ac= cess token refreshes. Access token revocation. Access token introspection. = As described in the charter, there is a whole lifecycle, that consists of m= ultiple transactions.


Definition of=C2=A0transaction

1a:=C2=A0<= /span>something=C2=A0transactedespecially=C2=A0:=C2=A0an = exchange or=C2=A0transfer=C2=A0of goods, services, or fundselectronic=C2=A0transactions
b:=C2=A0transactions=C2=A0plural=C2=A0:=C2=A0the often published record of the meeting of a society or association<= /span>
2a:=C2=A0an act, process, or instance of=C2=A0transacting
b:=C2=A0a communicative= action or activity involving two parties or things that reciprocally affec= t or influence each other
=
Calling the protocol a transaction will confusing to people.=
=C2=A0

Having come of age in the 1990=E2=80=99s, I have par= ticular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you read either of those with a growling ye= ll in your head then you know exactly what I=E2=80=99m talking about.
=

In case you are confused, this is no= t a childhood=C2=A0trauma support group.=C2=A0 :)

= Unlike "X-TREME" or "X-CITING", XAuth is using the &quo= t;X" as a placeholder. X-Men, Xbox, X-Factor, X-files.=C2=A0


=C2=A0
=
And to Dick=E2=80=99s rationale for the name below, I absolutely do N= OT see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I = think that does a disservice to the kind of change we have an opportunity t= o make here.=C2=A0

From the cha= rter=C2=A0

"It wi= ll expand upon the uses cases currently supported by OAuth 2.0 and OpenID C= onnect (itself an extension of OAuth 2.0)"

Which sounds pretty similar to= =C2=A0=E2=80=9COAuth with all the extra features=E2=80=9D

While I think XAuth captures what we are doing, a placeholder name = would be preferable to an incorrect descriptive name such as TxAuth.
<= div>
For example, XYZ is a good placeholder name. Or XYZAuth.= Let's not mislead people.

=C2=A0

=C2=A0=E2=80= =94 Justin

On Mar 16, 2020, at 7= :04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

He= llo everyone

I prompted a thread around the name of = the protocol a while back:


As Justin stated "naming is hard= "

Wearing my marketing hat I want to ensure t= hat the name will be perceived=C2=A0properly in the broader community.

A recent example that comes to mind are the privacy re= lated works on the browser storage API. Given that name, one would think th= at it is local storage. It is actually about browser cookies.
Justin discussed his reasons for TxAuth in the thread above (an= d I'm sure in other places)

I chose XAuth in m= y draft to reflect the eXtensibility goal that we have over OAuth -- and XA= uth is OAuth but with an X to reflect all the extra features. =3D)

Other suggestions?

This will be a= n agenda item in the BoF -- but the name will NOT be an open discussion ite= m -- we will summarize=C2=A0what has been discussed on the list and perhaps= do a poll of options presented unless consensus is obvious from this threa= d.

/Dick


<= br>


3D""=E1=90=A7


--000000000000734fcc05a1532880-- From nobody Sat Mar 21 01:29:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7683A125C for ; Sat, 21 Mar 2020 01:29:39 -0700 (PDT) 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 dudl-M16CeAC for ; Sat, 21 Mar 2020 01:29:38 -0700 (PDT) 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 F11C33A125B for ; Sat, 21 Mar 2020 01:29:37 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id o16so5551442ilm.2 for ; Sat, 21 Mar 2020 01:29:37 -0700 (PDT) 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=O0Z6VTrX7HFh7FAPXgP6MPdWUkmKZecVqw5zQCBSOlM=; b=F9iAZbjxe9n5XquIZlvdVDqEC111JBXMPxVrD2cN9YC+EM286VL11fGy2/feZNXyGt FiFOU2KzVYo5QGWpThomGAx2+R2xB20yVpkxbFvJZxgaq7iBcq2/BXCtLd8tuuF+euCr YVZzgIBqSNnow9c68gUxzFThaQms4M8C6ukPW02yQMd+y1AdgL2QWFKU3VKtN7LK+aqI zVgATePSG56OhlZlYnfdcDEdncnOyPlAbntD1FJqj+6b9Pc6Y+7IegzN1lB5VzEKpOWL h241JwG7guzm9vetDrvIQaqmhEHXAFVTRvAa/Fss+ACULHEUeyiL+8oAq+sV9zoQ6j7F HSvA== 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=O0Z6VTrX7HFh7FAPXgP6MPdWUkmKZecVqw5zQCBSOlM=; b=KPPtXlqg6ysdgOzq+8fhmm2n1cZn/jVq6OgSYK5HqufNXzCth5IZpKAjDPk6KauxrU DK5T2EFiN2GOTIaFSrjtlZdbNNmU83hN0LjApkCwlPjdxOniKqRNX9FzUjDWT00tA6Y9 SC121sVqCDuvTRm34KEoGFKke9RKMUA6YLQrDcdJHmeAryXU6ibl6cAxfFQnz2tZ9foy tjls62RIIfF5VUwDBIBi9hOnwYIEHKZXuRsU8fD8Ei5aGWf+EGzMpZJAsBDonptV8mQy ho2enCsOoBdC7HxzKg5UcBQijLHMW0aeBK5YPHaxqWNixXAk8qfF4ptYnW4ILK3tgXVm LkDA== X-Gm-Message-State: ANhLgQ0EWuFi/w1hRWKwWmhARP4x09gylsRr1Mag0ye7xSRLqg0E03+B ZhqGqv2WTZcestmkRrNzHq0mBKy8lCLccIpGufw= X-Google-Smtp-Source: ADFU+vvkPu728h8fjYGuOPKGCh5Kz1FLJEq/GmMPX8W8hCMUme1YrDRkhEosXUodQSn1SQOND2EqwZi2xLoWmjvERkE= X-Received: by 2002:a92:3993:: with SMTP id h19mr12647223ilf.177.1584779376915; Sat, 21 Mar 2020 01:29:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay IETF Date: Sat, 21 Mar 2020 13:59:25 +0530 Message-ID: To: Dick Hardt Cc: David Skaife , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000cf099d05a15933f4" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 08:29:40 -0000 --000000000000cf099d05a15933f4 Content-Type: text/plain; charset="UTF-8" Hi Dick, Thanks for the additional context for reasoning. My response inline. On Sat, 21 Mar 2020 at 06:00, Dick Hardt wrote: > > If all choices are equal (no default), then ALL the choices have to be > implemented in a general purpose implementation, which increases the attack > surface and vulnerability of an implementation, ie a coding error. > > I do not see how having a no default implies all choices being equal. I am missing the nuance here. The +1 for xyz rationale was to favor implementations that have the freedom to implement what they see fit and still be "compliant" with the protocol. I am not a fan of bloated general purpose software implementations, so I don't have much to comment on that. Sorry. --- Vijay --000000000000cf099d05a15933f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

Thanks for the addi= tional context for reasoning. My response inline.

On Sat, 21 Mar 2020 = at 06:00, Dick Hardt <dick.hardt= @gmail.com> wrote:
<snip>
If all choices are equal (= no default), then ALL the choices have to be implemented in a general purpo= se implementation, which increases the attack surface and vulnerability of = an implementation, ie a coding error.


I do not see how having a no default=C2=A0 implies al= l choices being equal. I am missing the nuance here.

The +1 for xyz rationale was to favor implementations that have th= e freedom to implement what they see fit and still be "compliant"= with the protocol. I am not a fan of bloated general purpose software impl= ementations, so I don't have much to comment on that. Sorry.
<= div>=C2=A0
---
Vijay
--000000000000cf099d05a15933f4-- From nobody Sat Mar 21 05:47:01 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80353A08C7 for ; Sat, 21 Mar 2020 05:46:58 -0700 (PDT) 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 MbuAlyMwk8xT for ; Sat, 21 Mar 2020 05:46:55 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 AB9EE3A08CA for ; Sat, 21 Mar 2020 05:46:54 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id 6so9309234wmi.5 for ; Sat, 21 Mar 2020 05:46:54 -0700 (PDT) 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=soywugxvatTQp1KzNPstGmuZpBJ3+iVJqHtbZ7hkOak=; b=OgRvKLAhbQMZFXE33nQ7lwRboD6o3XhMpdm49If8oDRMLsp8AwoTRfCR3AfnU5Qezw UCbiqRJS9FFke8WeeH76Ch8cVDOaB9Q8jaH7ryPuxZNWKlqO4CMf9cuu2xvdCJIrS49V 9dG7WVWNg/gJkXoC/cy3nrHZfEQq5aT04+sSQFfzHvfPD2r0IxSgatEp9FAqgOlODkl8 xcqfkE4wvo5kJqLVjPBBOvaqmIGTsI+Tv2NmZLB+5WT/3WLb7RWu2iNwiUvykQmBy2bT EKYu2fPtBUW5q5yF/ksbIdCcIUB7MnQOUiTpjf+hHMdLa2ZuWXXO1LSieJgPl2Mq+ehR jr9w== 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=soywugxvatTQp1KzNPstGmuZpBJ3+iVJqHtbZ7hkOak=; b=A/JYVmbkeU28cSDnY/yfshlKYFkAgCdkeTEaM3mT1BnGv9XGwIZQ2n9TdG05selhlj ptAvoiU9WvRuzpwdjyGdraybEKmB/3t8zOhFYkAzbGYuNFituLyVyAW79UmgL6P8Qnk7 SiKQhioVg0g4rOgLk80OF/VgWy1SCtZBR0Ynasa5vtFqsQA6S4atLQKRaDeuKFpU6TKW 8VQnI41BxkLP3CM8Z5RSdI2HzPVekbstaHVIDvV8ASVzAhdcyiraoi7JLs0b7xV8nOez glSOdIgTaFNdIuzUE7sC7jBNe/v5CNlbzcJ+5dGxD2IEK1YX6gFau5AZ/7QGzJ06RvsV vVGQ== X-Gm-Message-State: ANhLgQ0jKjw2Q3wSndTBTEmMYdRoIT+Gz2RozzHlJepQzTCTXPvcxzBt pMFXx0Udn1DpsSAzjTJKq4G3mA== X-Google-Smtp-Source: ADFU+vsg3a4iZEaaaMEyyFo7xxxQiQ5ZgVoqlDPS+JcRS2A9JYoe9VhGIV4cSImsfs2iYRtTrDpmzw== X-Received: by 2002:a05:600c:4109:: with SMTP id j9mr1093761wmi.140.1584794812508; Sat, 21 Mar 2020 05:46:52 -0700 (PDT) Received: from p200300eb8f2625ca05c39e1b37cae8fc.dip0.t-ipconnect.de (p200300EB8F2625CA05C39E1B37CAE8FC.dip0.t-ipconnect.de. [2003:eb:8f26:25ca:5c3:9e1b:37ca:e8fc]) by smtp.gmail.com with ESMTPSA id s127sm12629920wmf.28.2020.03.21.05.46.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2020 05:46:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 21 Mar 2020 13:46:48 +0100 Cc: Dick Hardt , Justin Richer , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <32B3E525-B4C1-4791-8DD9-B5327B418E0B@lodderstedt.net> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> To: Annabelle Backman X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 12:46:59 -0000 > On 20. Mar 2020, at 21:42, Richard Backman, Annabelle = wrote: >=20 > I am also opposed to requiring Clients to support arbitrarily split = access tokens. If we are to support multiple access tokens, we need to = do so in a way that does not adversely impact the many deployments for = which they are an unnecessary complication. Seconding Dick=E2=80=99s = comment that =E2=80=9Csplit_tokens=E2=80=9D is overly complex. It feels = to me like the sort of option that would hurt interoperability in the = long run. > =20 > I want to make sure we are not positioning multiple access tokens as a = necessary requirement for ASes that support multiple RSes. There are = other ways to do that, each with different pros and cons that can=E2=80=99= t be properly evaluated outside the context of an actual protocol, and = even then different deployments may weigh those pros and cons = differently. I did not propose to make support for RS-specific access tokens a = requirement for ASs, I suggested to give ASs this additional option and = make that a first class citizen in the protocol. Otherwise, the =E2=80=9Co= ne access tokens is sufficient=E2=80=9D statement will be a self = fulfilling prophecy and will force deployments with requirements that = cannot be fulfilled using single token + token introspection to go = proprietary.=20 > =20 > Similarly, we should not be constraining how ASes and RSes share = information. The proposal is to consider this interface as it is more or less = completely undefined in OAuth 2 and the current TXAuth charter. This = causes lot of misconceptions and functional gaps/differences in = products/libraries. I think we are able, in the same as for client, to = define rails to foster interoperability while allowing for a broad range = of implementation options. > Again, different deployments will call for different approaches. I think we should discuss exactly this different approaches = (experiences) to get a sense of the size of the playing field.=20 > I do like Justin=E2=80=99s suggestion (perhaps on another thread?) of = standardizing a schema that token claims, API results, etc. could adhere = to. > =20 That might be a result, I personally like Nat=E2=80=99s idea of writing = up an architecture document first. I think the WG (and implementers) = would benefit from some documented architectural assumptions.=20 > =E2=80=93 > Annabelle Backman (she/her) > AWS Identity > https://aws.amazon.com/identity/ > =20 > =20 > From: Txauth on behalf of Dick Hardt = > Date: Friday, March 20, 2020 at 11:37 AM > To: Justin Richer > Cc: Torsten Lodderstedt , "txauth@ietf.org" = > Subject: RE: [EXTERNAL] [Txauth] Multiple Access Tokens in XYZ > =20 > CAUTION: This email originated from outside of the organization. Do = not click links or open attachments unless you can confirm the sender = and know the content is safe. > =20 > I agree with Justin that the Client unexpectedly getting split access = tokens is undesirable. > =20 > I agree with Mike and Torsten that tokens should be self contained, = and able to be independent between resources. I would add that they = should be as fine grained as practical, which is part of the charter. > =20 > Rather then the client thinking it is getting multiple access tokens, = how about thinking of the client getting access to multiple resources? > =20 > The AS provides an access token for each resource. The access tokens = may all be the same, all be different, or a mix. > =20 > The Client does not need to know which ones are the same or different = ahead of time, but it does know which one it will use for accessing = which resource. > =20 > I don't think there is a need for a "split_tokens" flag. That sounds = overly complicated. > =20 > =20 > =20 > =20 > =20 > =20 > On Fri, Mar 20, 2020 at 7:59 AM Justin Richer wrote: >> So fundamentally, I don=E2=80=99t want the AS to allowed to split = tokens when the client isn=E2=80=99t expecting it. Would a simple = feature flag to allow that behavior at the AS be enough to switch both = cases?=20 >>=20 >> So let=E2=80=99s say we just do the simple thing and make it a = boolean top-level flag. If the client sends =E2=80=9Csplit_tokens: = true=E2=80=9D then the AS always returns the = =E2=80=9Cmultiple_access_tokens=E2=80=9D structure and it comes up with = whatever names it makes sense for the resulting tokens. The client can = do either the single or multiple token request style. The client needs = to be able to figure out from the token responses how to put which token = in which place, and I think we can do some things with the guts of the = =E2=80=9Cresources=E2=80=9D request object, like using =E2=80=9Clocations=E2= =80=9D and maybe other fields. If the client doesn=E2=80=99t send = =E2=80=9Csplit_tokens: true=E2=80=9D then the AS sends a single token = for a single token request, and multiple tokens for a multiple token = request, exactly mapped to what the client requested in each resources = block. If the client asks for resources that cross domains in a way that = AS can=E2=80=99t support, it returns an error. >>=20 >> The syntax needs work, but it would at least allow both modes of = operation. And it collapses nicely into the single-token use case, which = is one of my goals here. I don=E2=80=99t want a client to ask for 1 = token and get 2 or ask for 2 tokens and get 3, unless it=E2=80=99s fully = prepared for that. >>=20 >> Would something like that fly for you? >>=20 >> =E2=80=94 Justin >>=20 >> > On Mar 19, 2020, at 9:37 AM, Justin Richer wrote: >> >=20 >> > I see what you=E2=80=99re going for here. I think the key point = comes down to this: >> >=20 >> >> - The client knows what it wants to do and where >> >=20 >> > That=E2=80=99s knowledge is exactly why I would argue that the = client would have to explicitly request multiple access tokens in order = to get them.=20 >> >=20 >> > I=E2=80=99m worried about requiring all clients to be prepared to = accept multiple access tokens. In a lot of big cloud deployments, it=E2=80= =99s absolutely based on location. But that=E2=80=99s not the only = dispatch for security domains. A client would need to know, ultimately, = what a token is for and where to use it. And we=E2=80=99d also need to = deal with cases that allow for subdomains, paths, query parameters, and = other variability of an API=E2=80=99s URLs. After all, I=E2=80=99m = probably going to send that same token to a bunch of different URLs in = order to do a bunch of different things, even if they=E2=80=99re all = within the same =E2=80=9CRS=E2=80=9D or =E2=80=9Cdomain=E2=80=9D or = whatever. Which brings us to an underlying problem =E2=80=94 I don=E2=80=99= t think there=E2=80=99s a good way to reference the identity of an RS. = Solid is attempting to do that using WebID=E2=80=99s as service = identifiers, and while that=E2=80=99s interesting, it=E2=80=99s deeply = tied to their system where everything knows what a WebID is and what to = do with it. I think it=E2=80=99s a bad idea to depend on that kind of = thing for a general purpose system.=20 >> >=20 >> > I=E2=80=99m hesitant to have clients depend on being told that = information. I think if we go down that route we=E2=80=99re going to = have to also tell clients things like =E2=80=9Cthis is only good for GET = requests=E2=80=9D and =E2=80=9Cthis is good for subdomains on this = location=E2=80=9D and =E2=80=9Cthis can be used for anything except this = one exception=E2=80=9D. And it doesn=E2=80=99t fit well when you=E2=80=99r= e trying to mix two different APIs that have really different = structures. Things like GraphQL and REST lead to pretty different URL = designs, and TxAuth should be usable for all of that. It feels like too = much automated configuration of a client instead of the client just = =E2=80=9Cdoing something=E2=80=9D, which I think is going to be the = common case. In other words, I do think that the client software is = going to be bespoke for the API that it=E2=80=99s calling. However, the = security library that speaks the TxAuth piece doesn=E2=80=99t have to = be, and the protocol itself doesn=E2=80=99t need to be. But the = protocols should allow the client software to express to the security = layer what it knows about the API. >> >=20 >> > And speaking of common cases, I think it=E2=80=99s actually much = more rare to have multiple security domains covered by an AS in a way = that would need multiple encryptions or targets. I think many of us see = it because we work with large enterprise-scale systems with multiple = domains that we want to manage all at once. In my experience, it=E2=80=99s= much more common to have a client talk to one AS to get one token for = one RS. One of my goals with this is to not make it complicated for = simple clients, and I think having to be prepared to get multiple access = tokens is too complex for simple clients. I might be wrong, but it=E2=80=99= s based on my experience across a lot of different kinds of APIs. The = idea of splitting up tokens like below feels REALLY complex, especially = when I asked for a single one. I get why you want to do it, it makes = sense for the AS to be able to do something like that, but from a = client=E2=80=99s perspective it=E2=80=99s a lot more complicated without = a clear idea of what the identity of an RS is. I think solving that = problem is a HUGE issue that we should put firmly out of scope. >> >=20 >> > The thing is, though, you=E2=80=99re absolutely right that = there=E2=80=99s a need for this kind of multiple tokens. So in my view, = the lift of having a client know about the domains that it=E2=80=99s = calling is a lot less than the client having to potentially deal with = more tokens than it asked for, and knowing how to correctly dispatch = those. Also the semantics of what the =E2=80=9Cresources=E2=80=9D object = represents changes, since I could potentially be getting two tokens back = that do parts of the one thing that I asked for, and the client now = needs to know which to use for what. If the client has to name the = splits itself, that implies the client knows what each =E2=80=9Cresources=E2= =80=9D sub-object represents and knows how to apply that to its =E2=80=9Cc= all the API=E2=80=9D code. The security layer doesn=E2=80=99t know or = care, but the code that knows how to manipulate the API and its data = knows and cares. >> >=20 >> > As for the token content =E2=80=94 that=E2=80=99s solidly an = implementation decision and orthogonal to this discussion. You can do = all of this multi access token stuff with introspection and = reference-based tokens. Access tokens themselves need to stay opaque to = the client and to the protocol at large. I don=E2=80=99t believe = that=E2=80=99s up for debate. >> >=20 >> > Thanks so much for pushing this conversation, and now I=E2=80=99m = more convinced than ever that handling multiple tokens in the response = is something we need to figure out within this group.=20 >> >=20 >> > =E2=80=94 Justin >> >=20 >> >> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt = wrote: >> >>=20 >> >> Hi Justin, >> >>=20 >> >> thanks for explaining the different options. I=E2=80=99m well = aware of the super refresh token (and remember the discussions back then = in Taipei :-)), I have implemented systems using this and other = patterns, too. >> >>=20 >> >> The underlying assumption for most of those patterns is that the = client upfront knows the boundaries between RS security domains, which = typically means the solution is bespoken.=20 >> >>=20 >> >> TXAuth is chartered to develop a protocol and not a framework. = What I=E2=80=99m looking for is interoperable protocol support for use = of RS-specific self-contained access tokens in multi-RS deployments. >> >>=20 >> >> Why RS-specific self-contained access tokens?=20 >> >> This is in my experience the most efficient way to empower = high-volume/high-load services in a very efficient, secure, and privacy = preserving fashion.=20 >> >>=20 >> >> - Every token contains exactly the data the RS needs to perform = access control decisions locally. No need for further database lookups = or AS callbacks, that=E2=80=99s really fast and keeps cost of the AS = function low.. >> >> - The token itself can be encrypted to protect this data using a = RS-specific key, one could even use HMACs to protect integrity and = authenticity (fast as well).=20 >> >> - The token can have a RS-specific lifetime. >> >> - Since every token is restricted to a single RS audience, those = tokens also have a baseline replay detection built-in.=20 >> >>=20 >> >> I think this pattern makes sense in environments with multiple RSs = (e.g. different products) as well. But since every token is minted to = the specific requirements of a certain RS, the AS must be able to mint = different tokens. That doesn=E2=80=99t work properly without some = support in the protocol. >> >>=20 >> >> Is there a need for multi access tokens support?=20 >> >> Well, you implemented it, I implemented it, and I think a couple = of other implementers did it with OAuth 2 in the past. So there seems to = be some need. Why does the rest use the single token pattern? I think = some deployments will indeed only have a single service, but I bet a lot = of implementers did it because their product does not support anything = else. >> >>=20 >> >> I have experienced this myself when I designed the architecture of = the yes ecosystem. It is a federation of authorization servers with = associated services where every AS represents a certain bank. Since our = partners shall be able to implement their AS using the product they = like, I needed to go with the least common denominator - single access = token. This has a significant consequences: our tokens are basically = handles, so every service calls back to the AS to obtain its data for = every service request. This degrades performance significantly and, = since those tokens are good for multi audiences, it forces us to = generally use sender constrained tokens, which increases complexity for = clients.=20 >> >>=20 >> >> I would like to give implementers more options in the TXAuth = space.. That=E2=80=99s why I advocate to build-in support f=C3=BCr = multiple access tokens into TXAuth.=20 >> >>=20 >> >> My proposal is based on the following assumptions: >> >> - Token format, content, encryption keys and so on are defined as = part of the interface between AS and RS >> >> - The client knows what it wants to do and where >> >> - Every party contributes the information it has to the overall = process to make it work simply and effectively for everyone.=20 >> >>=20 >> >> There is no change/addition needed to the request syntax. All it = takes is your new multi token syntax (+ a small addition) in the = response.=20 >> >>=20 >> >> The client uses the =E2=80=9Cresources" structure to communicate = what (actions, further elements) it wants to do and where (locations). >> >>=20 >> >> [ >> >> { >> >> =E2=80=9Cactions": ["read", "write"], >> >> "locations": ["https://example.com/resource"], >> >> =E2=80=9Cdata": ["foo", "bar"] >> >> }, >> >> { >> >> =E2=80=9Cactions": ["write"], >> >> "locations": ["https://other_example.com/resource"], >> >> =E2=80=9Cdata": ["foo", "bar"] >> >> } >> >> ] >> >>=20 >> >> One deployment might use a single token for all RSs, in this case = the token response remains unchanged:=20 >> >>=20 >> >> { >> >> "access_token":{ >> >> "value":"08ur4kahfga09u23rnkjasdf", >> >> "type":"bearer" >> >> } >> >> } >> >>=20 >> >> If the AS has the need to issue multiple access tokens, it could, = for example, use the =E2=80=9Clocations" elements to determine what = tokens it needs to create. Such an AS then uses the = multiple_access_tokens structure augmented by corresponding = "locations=E2=80=9D entries in the token response:=20 >> >>=20 >> >> "multiple_access_tokens":{ >> >> "token_a":{ >> >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> >> "type":"bearer", >> >> "locations":[ >> >> "https://example.com/resource" >> >> ] >> >> }, >> >> "token_b":{ >> >> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >> >> "type":"bearer", >> >> "locations":[ >> >> "https://other_example.com/resource" >> >> ] >> >> } >> >> } >> >>=20 >> >> Since the client passed the locations values in the request, it is = also able to determine where to use what access token.=20 >> >>=20 >> >> I think that=E2=80=99s pretty simple, especially from a client = perspective. =20 >> >>=20 >> >> And If the client wants to split access tokens further apart, e.g. = to obtain tokens with less privileges, it can do so using the request = syntax you defined:=20 >> >>=20 >> >> resources: { >> >> token1: [{ >> >> actions: ["read", "write", "dolphin"], >> >> locations: ["https://server.example.net/", = "https://resource.local/other"], >> >> datatypes: ["metadata", "images"] >> >> }], >> >> token2: [{ >> >> actions: ["foo", "bar", "dolphin"], >> >> locations: ["https://resource..other/"], >> >> datatypes: ["data", "pictures"] >> >> }] >> >> } >> >>=20 >> >> In the simplest case, the AS would return the data as in your = proposal. >> >>=20 >> >> If the client asks for a partitioning of privileges that goes = across RS security domains like this >> >>=20 >> >> { >> >> "resources":{ >> >> "token1":[ >> >> { >> >> "actions":[ "read", "write","dolphin" ], >> >> "locations":[ = "https://server..example.net/","https://resource.local/other"], >> >> "datatypes":[ "metadata","images"] >> >> }, >> >> { >> >> "actions":["read","write"], >> >> "locations":["https://example.com/resource"] >> >> } >> >> ], >> >> "token2":[ >> >> { >> >> "actions":["foo","bar", "dolphin"], >> >> "locations":["https://resource.other/"], >> >> "datatypes":["data","pictures"] >> >> } >> >> ] >> >> } >> >> } >> >>=20 >> >> the AS would need to further partition the pre-defined tokens like = this: >> >>=20 >> >> "multiple_access_tokens=E2=80=9D:{ >> >> =E2=80=9Ctoken1/a":{ >> >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> >> "type":"bearer", >> >> = "locations":["https://server.example..net/","https://resource.local/other"= ] >> >> }, >> >> =E2=80=9Ctoken1/b":{ >> >> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >> >> "type":"bearer", >> >> "locations":["https://example.com/resource"] >> >> }, >> >> =E2=80=9Ctoken2":{ >> >> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >> >> "type":"bearer", >> >> "locations":[ >> >> "https://other_example.com/resource" >> >> ] >> >> } >> >> } >> >>=20 >> >> Naming of the tokens is a bit tricky but I think solvable. >> >>=20 >> >> What do you think? >> >>=20 >> >> best regards, >> >> Torsten. >> >>=20 >> >>> On 15. Mar 2020, at 15:26, Justin Richer wrote: >> >>>=20 >> >>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt = wrote: >> >>>>=20 >> >>>>> On 15. Mar 2020, at 03:25, Justin Richer = wrote: >> >>>>>=20 >> >>>>> So if the AS needs a client to get different access tokens to = call different RS domains, it does exactly what we do in OAuth 2 today = =E2=80=94 it tells the client to get two different access tokens.=20 >> >>>>=20 >> >>>> How does this work in XYZ? >> >>>>=20 >> >>>=20 >> >>> Without using the multi-access-token thing I=E2=80=99m proposing = in this thread, the client would just make two separate transaction = calls to get two different tokens. There=E2=80=99s a few ways that = shakes out depending on some of the details. In the OAuth world that = amounts to involving the user twice, and it might be the same in XYZ if = you=E2=80=99re asking for different things: >> >>>=20 >> >>> 1. Client: Start TX-1 (R-1) >> >>> 2. User: Approve R-1 >> >>> 3. AS: Issue AT-1(R-1) >> >>> 4. Client: Start TX-2 (R-1) >> >>> 5. User: approve R-2 >> >>> 6. AS: Issue AT-2(R-2) >> >>>=20 >> >>> Unless you=E2=80=99re getting a super refresh token upfront and = then calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can = do that trick too. >> >>>=20 >> >>> 1. Client: Start TX-1 (R-1, R-2) >> >>> 2. User: Approve R-1, R-2 >> >>> 3. AS: Issue AT1 (R-1, R-2) >> >>> 4. Client: Continue TX-1 (R-2) >> >>> 5. AS: Issue AT-2 (R-2) >> >>>=20 >> >>> But we=E2=80=99ve got another thing we can use in XYZ to help = this, the user handle. This lets a trusted client tell the AS that it = believes the same user is still there and asking the question, so if the = access rights are OK then you don=E2=80=99t need to involve the user = again. We invented this construct with UMA2, where it=E2=80=99s called = the persisted claims token (PCT). >> >>>=20 >> >>> 1. Client: Start TX-1 (R-1) >> >>> 2. User: Approve R-1 >> >>> 3. AS: Issue AT-1 (R-1), user handle U-1 >> >>> 4. Client Start TX-2 (R-2, U-1) >> >>> 5. AS: Issue AT-2 (R-2) >> >>>=20 >> >>> Now: With the multi-token request, we can collapse this all back = to a single transaction with multiple outputs: >> >>>=20 >> >>> 1. Client: Start TX-2 (token1: R-1, token2: R-2) >> >>> 2. User Approve R-1, R-2 >> >>> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) >> >>>=20 >> >>> I haven=E2=80=99t liked any of the multi-access-token solutions = to date because they make things weird for single access token requests. = I like this idea because it=E2=80=99s an optimization for a complex case = that doesn=E2=80=99t change the behavior for the simple case, and in = fact doesn=E2=80=99t even change the expectations for the simple case. = To me, that=E2=80=99s important. >> >>>=20 >> >>> =E2=80=94 Justin >> >>=20 >> >=20 >> > --=20 >> > Txauth mailing list >> > Txauth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Mar 21 06:18:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620133A13BA for ; Sat, 21 Mar 2020 06:18:07 -0700 (PDT) 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 VfICJIzsyoWp for ; Sat, 21 Mar 2020 06:18:05 -0700 (PDT) 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 B1AAF3A08FD for ; Sat, 21 Mar 2020 06:18:04 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id d1so9363202wmb.2 for ; Sat, 21 Mar 2020 06:18:04 -0700 (PDT) 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=0UmFz04O8AZ6wHgzgrrqB4KhTY1CVd3fbGx97ZPvMjs=; b=Fy4ceI6XA82DEyzrAPG05kZ71QqEtTenwHgcNYqbiv51QbQkbUFkGKsP7krfr1lH3/ menoQCxeTSmbPuyaXt/nuAKGmwOwvNy93fP+wtfiabVIP9CGxqi1wurDHiFSY5PffUxq JEhIkCYusPpDAPGSliv80IIxYUzyARRATohHYjFlbDr2Kv8pSSdyIIR7WZ82uWNKpep1 mEfzTZeeChZD/LxD7Cx45qxVD+o0o5QNbf+bNOUKuwfw+5fZEDBV1v30lSR+u+yrZOTG dn/Zm9v0/RYLs8+RsLSeMbl+nVb3Y+eVoJyRW3nWaRGPJIAMRVFqu5TGDI0W1uPx6akY iTkg== 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=0UmFz04O8AZ6wHgzgrrqB4KhTY1CVd3fbGx97ZPvMjs=; b=NY6fp9gRZI1+EqQUqiRrGWosxITtSuRg5vzshLo0gDhiIycLAmBS7QCG8vH3c7waFv en+aNkXW7XfORP6PmYGwTEPPY59+GSdwqva/d8aUar1ph6rbrSUAC4xvODg/WrjzxC8b e3pvEmS17tRjNE7OrUpF2KrI4cKXSErAmcYFPJIsDM29OryS7wVOn0UHU67wH6oWi1ZI LFZhUKZ3sfpzpG86wmO23yUKKN0fgcbvtOfkZIBTKec29+waKszP6dxJJEm1A9fNYBu+ lqlQkh61Y4uEA1Eq6cyCc8NHUHr1JILCzM8Z06GiUrwD1u5doozMbtz3nQakpwZLF77U Dauw== X-Gm-Message-State: ANhLgQ1aRivbsOtyVD+HYwIjwH4EdkWXOut+K8d+vSjqhmslySy4E/TH kPWNkpC3MZfkio1QwmOL4Srf5Q== X-Google-Smtp-Source: ADFU+vsKKJKhBHnJTDnkQWJbbZ9JGzkmU9XWB2FQR9guOfkvtp9k6FHYFFMrIfKZrBhxC4SmhP3cdQ== X-Received: by 2002:a1c:dc8b:: with SMTP id t133mr15276234wmg.99.1584796682568; Sat, 21 Mar 2020 06:18:02 -0700 (PDT) Received: from p200300eb8f2625ca05c39e1b37cae8fc.dip0.t-ipconnect.de (p200300EB8F2625CA05C39E1B37CAE8FC.dip0.t-ipconnect.de. [2003:eb:8f26:25ca:5c3:9e1b:37ca:e8fc]) by smtp.gmail.com with ESMTPSA id t5sm12151045wmi.34.2020.03.21.06.18.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2020 06:18:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 21 Mar 2020 14:18:00 +0100 Cc: Justin Richer , txauth@ietf.org, Torsten Lodderstedt , Vladimir Dzhuvinov Content-Transfer-Encoding: quoted-printable Message-Id: References: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> To: Dick Hardt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 13:18:08 -0000 Hi Dick,=20 > On 20. Mar 2020, at 01:57, Dick Hardt wrote: >=20 > Rereading the charter I would consider the proposed charter change: >=20 > - Support for directed, audience-restricted access tokens in multi-RS = deployments >=20 > To be covered by the two highlighted lines below: >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Separation between the party authorizing access and the party = operating the client requesting access > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >=20 > Torsten: Does the scope of fine-grained access combined with approval = of access to multiple resources cover your requirements? I initially thought =E2=80=9CApproval of access to multiple resources = and APIs in a single interaction=E2=80=9D would do. But obviously it = doesn=E2=80=99t mention access tokens and the charter, in general, is = quiet regarding desired capabilities for token issuance and = relationships between access tokens and resources. =20 It also became obvious during the recent discussions there are different = interpretations, expectations, and objectives.=20 I therefore think another bullet to explicitly spell this out makes a = lot of sense.=20 In order to cover more use cases and be more explicit at the same time, = I suggest the following wording: - Support for directed, audience-restricted access tokens in multi-RS = deployments at client or AS discretion >=20 > Note that we are not stating how we do it, just what is in scope. Absolutely, I can think of various ways to implement it, but that=E2=80=99= s another step. First we need to agree on the objectives.=20 thanks, Torsten.=20 >=20 > /Dick >=20 > On Thu, Mar 19, 2020 at 1:48 PM Justin Richer wrote: > On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = wrote: > >=20 > >> Am 19.03.2020 um 21:07 schrieb Justin Richer : > >>=20 > >> =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99= ve described, > >=20 > > Given our recent discussion, I don=E2=80=99t see how it is already = in scope=20 >=20 > What I mean is that a client can already ask for separate tokens and = use the =E2=80=9Cresources=E2=80=9D block to describe which resource = servers it wants. However, right now, it=E2=80=99s up to the client to = determine what the split is =E2=80=94 either by asking for separate = tokens in either the single-token format (with multiple requests) or = multi-token format (with a single request).=20 >=20 > >=20 > >> with the caveat that identifying "the RS" is really, really hard to = do. > >=20 > > I don=E2=80=99t think it=E2=80=99s difficult to use URLs to identify = at least =E2=80=9Edestinations=E2=80=9C, it works for cookies as well.=20= >=20 > I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99m = trying to push back against optimizing for that one kind of identity. = And cookies have all kinds of rules for paths and domains and origins = that protect them, so if that=E2=80=99s the model we=E2=80=99re arguing = for we need to at least consider all of that. We also need to consider = that cookies fail in a lot of ways! :) >=20 > >=20 > >> What if instead it=E2=80=99s: > >>=20 > >> - Support for directed, audience-restricted access tokens in = multi-RS deployments > >>=20 > >> Would that work? To me the difference is that it=E2=80=99s getting = away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more = towards the notion of getting a token directed to a specific set of = actions and/or locations. > >=20 > > wfm, as long it is clear the AS/RS determines the boundaries. >=20 > Ultimately they always do, and they=E2=80=99ll always need to deal = with the situation where a client asks for rights that cross boundaries. = The question is what to do in those situations, and I think there=E2=80=99= s a lot more discussion we need to have on that front! Do we allow the = AS to split a token request, do we have errors for this, do we have a = client indicate that it can receive split tokens =E2=80=A6 etc. I think = it=E2=80=99s an interesting area, but complex and not nearly as = clean-cut as your own use case and deployment might let it be. >=20 > =E2=80=94 Justin >=20 > >=20 > > best regards, > > Torsten. > >=20 > >>=20 > >> =E2=80=94 Justin > >>=20 > >>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: > >>>=20 > >>> Hi all, > >>>=20 > >>> I suggest to add the following requirement to the charter: > >>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 > >>>=20 > >>> I don=E2=80=99t mind HOW this requirement is supported in TXAuth. = I want to make sure we try to build a protocol that serves the needs of = a broad set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 > >>>=20 > >>> And here is my explanation:=20 > >>>=20 > >>> OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 > >>>=20 > >>> And there are even more examples today for multi API environments = that would benefit from that feature:=20 > >>> =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! > >>> =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. > >>> =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. > >>>=20 > >>> Since we are preparing to define a completely new protocol for API = access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get = it right and simple, but if we just stick to the =E2=80=9Ca single = access token is enough=E2=80=9D mantra, we miss the chance to give = implementers a broader range of design choices out of the box and we = won=E2=80=99t success in achieving true interoperability. > >>>=20 > >>> Here are more advantages we can gain by supporting such a feature:=20= > >>> =E2=80=A2 Privacy: > >>> =E2=80=A2 A single access token can be used to track user = across services. > >>> =E2=80=A2 RS-specific access tokens cannot. > >>> =E2=80=A2 RS-specific access tokens can also be encrypted to = protect data confidentiality in transit. > >>> =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. > >>> =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. > >>>=20 > >>> What do you think? > >>>=20 > >>> best regards, > >>> Torsten.=20 > >>>=20 > >>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: > >>>>=20 > >>>>=20 > >>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: > >>>>> On 19. Mar 2020, at 17:47, Justin Richer = wrote: > >>>>>> Well, it=E2=80=99s in scope as much as describing any other = aspect of what the token is for and what it represents is in scope. That = is alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 > >>>>>>=20 > >>>>>> But here=E2=80=99s the thing: none of that has an impact on the = core protocol. That is entirely up to the AS and the RS to agree on, and = the client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. > >>>>>>=20 > >>>>>> This does raise the question of what our bar of = interoperability is going to be with TxAuth: do we expect independent AS = and RS implementations to talk to each other? That=E2=80=99s not = something OAuth 2 was ever concerned with, though obviously JWT and = introspection are both from the OAuth2 WG and solve that problem. > >>>>> There are two aspects to it: interoperability and vendor = support.=20 > >>>>>=20 > >>>>> Interoperability between AS and RS is important if deployments = want to combine pre-packaged TXAuth and API implementations. I think = that makes a lot of sense and should be included in the charter. > >>>>=20 > >>>> +1 > >>>>=20 > >>>> The current OAuth 2.0 status quo of the largely unspecified = relationship > >>>> between AS and RS is also making the life of web & sec framework > >>>> maintainers difficult. We witnessing this with people integrating = the > >>>> OAuth SDK into frameworks. Vittorio's recent work to put together = a > >>>> minimal interoperable JWT profile for access tokens is helpful, = but it > >>>> has come after the fact. And there is not agreement on things = like > >>>> authorising access to claims. > >>>>=20 > >>>> Integrating apps (RSs) with TxAuth should be straightforward and = simple. > >>>>=20 > >>>> This can have a enormous effect on adoption. > >>>>=20 > >>>>=20 > >>>>> Vendors support: vendor support when it comes to "what can go = into an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= > >>>>=20 > >>>> +1 > >>>>=20 > >>>>=20 > >>>>> I also think it is a good exercise for the group to think the = whole process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) = is not to provide clients with access tokens. The purpose is to enable = API request processing in a secure manner. What it really takes to = achieve that goal is not obvious if the work always stops at the =E2=80=9C= you have your access token, good luck=E2=80=9D stage.=20 > >>>>=20 > >>>> +1 > >>>>=20 > >>>> Vladimir > >>>>=20 > >>>>=20 > >>>> --=20 > >>>> Txauth mailing list > >>>> Txauth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/txauth > >>>=20 > >>> --=20 > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth > >>=20 > >> --=20 > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Mar 21 06:31:34 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89E63A13C6 for ; Sat, 21 Mar 2020 06:31:29 -0700 (PDT) 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 98-83_fgEHCa for ; Sat, 21 Mar 2020 06:31:27 -0700 (PDT) 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 2DE4B3A0927 for ; Sat, 21 Mar 2020 06:31:27 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id w10so10846451wrm.4 for ; Sat, 21 Mar 2020 06:31:27 -0700 (PDT) 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=P4y4b20hTlMV+n+OjjLgCsWfGn/19/HhVUXtL/Zsw0Y=; b=o4PfZPpUhemWdcpALfYXcusBw4FLvdaMS8Dn62twTR3L6VWYITjk1xbFREpUxqihpW uaykFc1bH2KoVcrT9GNJKX0TolAuKB63d07Sv2QTJMQvN3VNOos8U5zVbb42gRYDPJMN /97qitz6HmgQC3QfmJrJAsqmgtC5YSey9TaGSdv4PutXUlRh+AO2hGyf9fmTo+mK99zV q69C/g6sSHj/d5CGuqyKtX8wbB6SaUPISOwLV8QVlbqEt2+Edg4P+t3uXxZJzW2PRjpX iUQ8oPNlnL+9otbSxgCs9kK/uEJNqziTRdeA9ujAvCnEPynfSN0Jcunj70DIDykHtc9T Nk9Q== 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=P4y4b20hTlMV+n+OjjLgCsWfGn/19/HhVUXtL/Zsw0Y=; b=gM6hcl/ycidAzp2O+C7Kzp6f/MGsuo5Oe3//+3mR3MTOV7caRhZIPKUHRz7aTu/LB/ 8lWMaJ2jVzPQ2T7r/XVa7hzxu/bq2uNxX1BcfDfjdppmhqJC+0HZDgoRHzPDtLqe8JjL mr/B95Urn/C7vnYjI+rMPWXbwHfWxpJhZrjfAj9f8q3D9ahzcFLA5X3DFSBFcWH8E5XW u28+aQlt5AcqdAUHV+ibU+ibvLOFxSnm88pTVKjZ+KnjjfKK7dNXtG7AIOMpd+GrzkYp COCmOaa/Uitv2zCjvUebYDU+Q6AO8No+H9P+4G7uerknENVKqC8JcIMNTv1RbvxE3bgZ bN/g== X-Gm-Message-State: ANhLgQ3ZklG5HuNJDYvz0OO/K9F6XOaTqmaVs4Tenm5Tve4XWdwm1TJ1 gyMVOc7+mBtnKZADp18zykyUIw== X-Google-Smtp-Source: ADFU+vsmnA1FoDokbQQP7PK7+P2vvo2pBQSCJzMLw7jnpAgxOVHwLHUXqliofEfBydlWzeSexzVIvQ== X-Received: by 2002:adf:9526:: with SMTP id 35mr18508286wrs.164.1584797485609; Sat, 21 Mar 2020 06:31:25 -0700 (PDT) Received: from p200300eb8f2625ca05c39e1b37cae8fc.dip0.t-ipconnect.de (p200300EB8F2625CA05C39E1B37CAE8FC.dip0.t-ipconnect.de. [2003:eb:8f26:25ca:5c3:9e1b:37ca:e8fc]) by smtp.gmail.com with ESMTPSA id f14sm12028750wmb.3.2020.03.21.06.31.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2020 06:31:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: <30E029DE-4083-4B65-A97B-EE4F5BF4B7E2@mit.edu> Date: Sat, 21 Mar 2020 14:31:24 +0100 Cc: Mike Jones , Yaron Sheffer , Dick Hardt , "txauth@ietf.org" , "Richard Backman, Annabelle" Content-Transfer-Encoding: quoted-printable Message-Id: <414056FE-0FE2-4B9B-A6BA-4ABC565798E3@lodderstedt.net> References: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> <30E029DE-4083-4B65-A97B-EE4F5BF4B7E2@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 13:31:32 -0000 Hi,=20 +1 for adding identity slices and AS - RS interop to the agenda. I would also ask for time to discuss my proposal to support RS-specific = access tokens and Nat=E2=80=99s suggestion to write an architecture = document.=20 As this will have an impact on the agenda, I fully support Mike's = statement: agreeing on the charter is more important now than discussing = the different drafts. Adopting the agenda accordingly is reasonable.=20 best regards, Torsten,=20 > On 19. Mar 2020, at 20:11, Justin Richer wrote: >=20 > +1 to adding both of these discussions to the agenda. >=20 > =E2=80=94 Justin >=20 >> On Mar 19, 2020, at 2:00 PM, Mike Jones = wrote: >>=20 >> Given that four people have raised questions about the identity = aspect of the proposed charter, I would request that the chairs allocate = at least 20 minutes to discussion of whether identity should be in or = out of scope, and if in scope, what aspects of identity should be in and = out of scope. This should have its own time slot, rather than including = it in the 20 minutes of charter and naming discussions currently = allocated, as it=E2=80=99s a foundational decision to scoping the work, = and is likely to need at least 20 minutes on its own. >> =20 >> Torsten=E2=80=99s and Vladimir=E2=80=99s feedback about = interoperability among authorization servers and resource servers should = also be explicitly included somewhere in the charter discussions. >> =20 >> If we=E2=80=99re short on time, I=E2=80=99d rather we first get = agreement on the charter and scope than discuss the engineering merits = and tradeoffs among particular proposed starting point drafts. >> =20 >> Thanks, >> -- Mike >> =20 >> From: Txauth On Behalf Of Richard Backman, = Annabelle >> Sent: Thursday, March 19, 2020 8:28 AM >> To: Dick Hardt ; txauth@ietf.org >> Cc: Yaron Sheffer >> Subject: [EXTERNAL] Re: [Txauth] TxAuth BoF draft agenda >> =20 >> I expect a lot of discussion around whether/to what extent it should = include =E2=80=9Cidentity=E2=80=9D and without some structure that could = easily consume the whole meeting. Should we timebox that discussion, = and/or get some volunteers to summarize the various positions? >> =20 >> =E2=80=93 >> Annabelle Backman (she/her) >> AWS Identity >> https://aws.amazon.com/identity/ >> =20 >> =20 >> From: Txauth on behalf of Dick Hardt = >> Date: Monday, March 16, 2020 at 4:07 PM >> To: "txauth@ietf.org" >> Cc: Yaron Sheffer >> Subject: [EXTERNAL][Txauth] TxAuth BoF draft agenda >> =20 >> Virtual Meeting: =20 >> =20 >> Monday, March 23 >> 20:00 - 22:00 UTC *=20 >> =20 >> Agenda >> Chair slides, agenda bashing - 10 min. >> Charter (link, solicit comments, discuss WG name) - 20 min. >> XYZ - Justin (with Q&A) - 20 min. >> XAuth - Dick (with Q&A) - 20 min. >> Yaron , Dick, Justin - Discussion of differences between protocols - = 40 min. >> Next steps - 10 min. >> =20 >> Additions / suggestions? >> =20 >> Tech >> The technology to be used is still TBD. We will update the list when = we know. We are expecting it will be the IETF WebEx. (my preference = would be Zoom if anyone has an account to have LOTS of people on it =3D) >> =20 >> We are planning on using EtherPad for notes, and for queue = management. >> =20 >> Scribe >> Would someone like to volunteer to be the scribe on EtherPad? We = would like to get as much coordination done prior as possible to make = the best use of the time. >> =20 >> /Dick >> =20 >> * Some time math for 20:00 - 22:00 UTC: >> =20 >> Pacific Time 13:00-15:00 >> Eastern Time 16:00-18:00 >> Coordinated Universal Time 20:00-02:00 >> Central European Time 21:00-23:00 >> India Standard Time 01:30-03:30 >> China Standard Time 04:00-06:00 >> Australian Eastern Standard Time 07:00-09:00 >> =E1=90=A7 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Mar 21 09:46:52 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E421A3A03EB for ; Sat, 21 Mar 2020 09:46:46 -0700 (PDT) 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=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 jZM1JTLjJtwS for ; Sat, 21 Mar 2020 09:46:44 -0700 (PDT) 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 846413A03EA for ; Sat, 21 Mar 2020 09:46:43 -0700 (PDT) Received: from [192.168.1.5] (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 02LGkWGe011684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 12:46:33 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B9C2920C-C1E3-4D66-A44C-27B091F7EAF4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Mar 2020 12:46:32 -0400 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org, Torsten Lodderstedt , Vladimir Dzhuvinov To: Torsten Lodderstedt References: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 16:46:49 -0000 --Apple-Mail=_B9C2920C-C1E3-4D66-A44C-27B091F7EAF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Torsten, what if we walk that back to: - Support for multiple access tokens in a single request - Support for directed, audience-restricted access requests I propose that we split these because I think the two of them are useful = separately, and considering them separately might influence how we end = up solving it overall. I understand that you=E2=80=99re looking at a use = case that combines both of them, and I think enabling that makes some = sense.=20 =E2=80=94 Justin > On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt = wrote: >=20 > Hi Dick,=20 >=20 >> On 20. Mar 2020, at 01:57, Dick Hardt wrote: >>=20 >> Rereading the charter I would consider the proposed charter change: >>=20 >> - Support for directed, audience-restricted access tokens in multi-RS = deployments >>=20 >> To be covered by the two highlighted lines below: >>=20 >> Additionally, the delegation process will allow for: >>=20 >> - Fine-grained specification of access >> - Approval of AS attestation to identity claims >> - Approval of access to multiple resources and APIs in a single = interaction >> - Separation between the party authorizing access and the party = operating the client requesting access >> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>=20 >> Torsten: Does the scope of fine-grained access combined with approval = of access to multiple resources cover your requirements? >=20 > I initially thought =E2=80=9CApproval of access to multiple resources = and APIs in a single interaction=E2=80=9D would do. But obviously it = doesn=E2=80=99t mention access tokens and the charter, in general, is = quiet regarding desired capabilities for token issuance and = relationships between access tokens and resources. =20 >=20 > It also became obvious during the recent discussions there are = different interpretations, expectations, and objectives.=20 >=20 > I therefore think another bullet to explicitly spell this out makes a = lot of sense.=20 >=20 > In order to cover more use cases and be more explicit at the same = time, I suggest the following wording: >=20 > - Support for directed, audience-restricted access tokens in multi-RS = deployments at client or AS discretion >=20 >>=20 >> Note that we are not stating how we do it, just what is in scope. >=20 > Absolutely, I can think of various ways to implement it, but that=E2=80=99= s another step. First we need to agree on the objectives.=20 >=20 > thanks, > Torsten.=20 >=20 >>=20 >> /Dick >>=20 >> On Thu, Mar 19, 2020 at 1:48 PM Justin Richer = wrote: >> On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = wrote: >>>=20 >>>> Am 19.03.2020 um 21:07 schrieb Justin Richer : >>>>=20 >>>> =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99= ve described, >>>=20 >>> Given our recent discussion, I don=E2=80=99t see how it is already = in scope=20 >>=20 >> What I mean is that a client can already ask for separate tokens and = use the =E2=80=9Cresources=E2=80=9D block to describe which resource = servers it wants. However, right now, it=E2=80=99s up to the client to = determine what the split is =E2=80=94 either by asking for separate = tokens in either the single-token format (with multiple requests) or = multi-token format (with a single request).=20 >>=20 >>>=20 >>>> with the caveat that identifying "the RS" is really, really hard to = do. >>>=20 >>> I don=E2=80=99t think it=E2=80=99s difficult to use URLs to identify = at least =E2=80=9Edestinations=E2=80=9C, it works for cookies as well.=20= >>=20 >> I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99m = trying to push back against optimizing for that one kind of identity. = And cookies have all kinds of rules for paths and domains and origins = that protect them, so if that=E2=80=99s the model we=E2=80=99re arguing = for we need to at least consider all of that. We also need to consider = that cookies fail in a lot of ways! :) >>=20 >>>=20 >>>> What if instead it=E2=80=99s: >>>>=20 >>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>>=20 >>>> Would that work? To me the difference is that it=E2=80=99s getting = away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more = towards the notion of getting a token directed to a specific set of = actions and/or locations. >>>=20 >>> wfm, as long it is clear the AS/RS determines the boundaries. >>=20 >> Ultimately they always do, and they=E2=80=99ll always need to deal = with the situation where a client asks for rights that cross boundaries. = The question is what to do in those situations, and I think there=E2=80=99= s a lot more discussion we need to have on that front! Do we allow the = AS to split a token request, do we have errors for this, do we have a = client indicate that it can receive split tokens =E2=80=A6 etc. I think = it=E2=80=99s an interesting area, but complex and not nearly as = clean-cut as your own use case and deployment might let it be. >>=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> I suggest to add the following requirement to the charter: >>>>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >>>>>=20 >>>>> I don=E2=80=99t mind HOW this requirement is supported in TXAuth. = I want to make sure we try to build a protocol that serves the needs of = a broad set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 >>>>>=20 >>>>> And here is my explanation:=20 >>>>>=20 >>>>> OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 >>>>>=20 >>>>> And there are even more examples today for multi API environments = that would benefit from that feature:=20 >>>>> =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! >>>>> =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. >>>>> =E2=80=A2 IoT - every device in a household is a potential RS (in = my opinion). Conveying all necessary data in an access token needed to = meet access control decisions locally would be a huge benefit in terms = of performance and decoupling. Using symmetric cryptography for token = integrity, authenticity and confidentiality would result in lower = compute requirements. >>>>>=20 >>>>> Since we are preparing to define a completely new protocol for API = access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get = it right and simple, but if we just stick to the =E2=80=9Ca single = access token is enough=E2=80=9D mantra, we miss the chance to give = implementers a broader range of design choices out of the box and we = won=E2=80=99t success in achieving true interoperability. >>>>>=20 >>>>> Here are more advantages we can gain by supporting such a feature:=20= >>>>> =E2=80=A2 Privacy: >>>>> =E2=80=A2 A single access token can be used to track user = across services. >>>>> =E2=80=A2 RS-specific access tokens cannot. >>>>> =E2=80=A2 RS-specific access tokens can also be encrypted to = protect data confidentiality in transit. >>>>> =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. >>>>> =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >>>>>=20 >>>>> What do you think? >>>>>=20 >>>>> best regards, >>>>> Torsten.=20 >>>>>=20 >>>>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>>>>>=20 >>>>>>=20 >>>>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>>>>>> On 19. Mar 2020, at 17:47, Justin Richer = wrote: >>>>>>>> Well, it=E2=80=99s in scope as much as describing any other = aspect of what the token is for and what it represents is in scope. That = is alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>>>>>=20 >>>>>>>> But here=E2=80=99s the thing: none of that has an impact on the = core protocol. That is entirely up to the AS and the RS to agree on, and = the client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. >>>>>>>>=20 >>>>>>>> This does raise the question of what our bar of = interoperability is going to be with TxAuth: do we expect independent AS = and RS implementations to talk to each other? That=E2=80=99s not = something OAuth 2 was ever concerned with, though obviously JWT and = introspection are both from the OAuth2 WG and solve that problem. >>>>>>> There are two aspects to it: interoperability and vendor = support.=20 >>>>>>>=20 >>>>>>> Interoperability between AS and RS is important if deployments = want to combine pre-packaged TXAuth and API implementations. I think = that makes a lot of sense and should be included in the charter. >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> The current OAuth 2.0 status quo of the largely unspecified = relationship >>>>>> between AS and RS is also making the life of web & sec framework >>>>>> maintainers difficult. We witnessing this with people integrating = the >>>>>> OAuth SDK into frameworks. Vittorio's recent work to put together = a >>>>>> minimal interoperable JWT profile for access tokens is helpful, = but it >>>>>> has come after the fact. And there is not agreement on things = like >>>>>> authorising access to claims. >>>>>>=20 >>>>>> Integrating apps (RSs) with TxAuth should be straightforward and = simple. >>>>>>=20 >>>>>> This can have a enormous effect on adoption. >>>>>>=20 >>>>>>=20 >>>>>>> Vendors support: vendor support when it comes to "what can go = into an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>>=20 >>>>>>> I also think it is a good exercise for the group to think the = whole process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) = is not to provide clients with access tokens. The purpose is to enable = API request processing in a secure manner. What it really takes to = achieve that goal is not obvious if the work always stops at the =E2=80=9C= you have your access token, good luck=E2=80=9D stage.=20 >>>>>>=20 >>>>>> +1 >>>>>>=20 >>>>>> Vladimir >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>=20 >>>>> --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_B9C2920C-C1E3-4D66-A44C-27B091F7EAF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Torsten, what if we walk that back to:

 - Support for multiple access = tokens in a single request
 - Support for = directed, audience-restricted access requests

I propose that we split these because I = think the two of them are useful separately, and considering them = separately might influence how we end up solving it overall. I = understand that you=E2=80=99re looking at a use case that combines both = of them, and I think enabling that makes some sense. 

 =E2=80=94 = Justin

On Mar 21, 2020, at 9:18 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Dick, 

On = 20. Mar 2020, at 01:57, Dick Hardt <dick.hardt@gmail.com> wrote:

Rereading the charter I would consider the proposed charter = change:

- Support for directed, = audience-restricted access tokens in multi-RS deployments

To be covered by the two highlighted lines = below:

Additionally, the delegation process = will allow for:

- Fine-grained = specification of access
- Approval of AS attestation to = identity claims
- Approval of access to multiple resources = and APIs in a single interaction
- Separation between the = party authorizing access and the party operating the client requesting = access
- A variety of client applications, including Web, = mobile, single-page, and interaction-constrained applications

Torsten: Does the scope of fine-grained access = combined with approval of access to multiple resources cover your = requirements?

I initially thought =E2=80=9CApproval of access to multiple = resources and APIs in a single interaction=E2=80=9D would do. But = obviously it doesn=E2=80=99t mention access tokens and the charter, in = general, is quiet regarding desired capabilities for token issuance and = relationships between access tokens and resources.  

It also became obvious during = the recent discussions there are different interpretations, = expectations, and objectives. 

I therefore think another bullet = to explicitly spell this out makes a lot of sense. 

In order to cover more use cases = and be more explicit at the same time, I suggest the following = wording:

- Support for = directed, audience-restricted access tokens in multi-RS deployments at = client or AS discretion


Note that we are not = stating how we do it, just what is in scope.

Absolutely, I can think of various ways to implement it, but = that=E2=80=99s another step. First we need to agree on the = objectives. 

thanks,
Torsten. 


/Dick

On Thu, Mar 19, 2020 at = 1:48 PM Justin Richer <jricher@mit.edu> wrote:
On Mar 19, 2020, = at 4:41 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Am 19.03.2020 um 21:07 schrieb Justin Richer = <jricher@mit.edu>:

=EF=BB=BF= I think this is already in scope in the ways that I=E2=80=99ve = described,

Given our recent = discussion, I don=E2=80=99t see how it is already in scope 

What I mean is that a client can = already ask for separate tokens and use the =E2=80=9Cresources=E2=80=9D = block to describe which resource servers it wants. However, right now, = it=E2=80=99s up to the client to determine what the split is =E2=80=94 = either by asking for separate tokens in either the single-token format = (with multiple requests) or multi-token format (with a single = request). 


with the caveat that = identifying "the RS" is really, really hard to do.

I don=E2=80=99t think it=E2=80=99s = difficult to use URLs to identify at least =E2=80=9Edestinations=E2=80=9C,= it works for cookies as well. 

I think that=E2=80=99s an aspect, = but not the only aspect. I=E2=80=99m trying to push back against = optimizing for that one kind of identity. And cookies have all kinds of = rules for paths and domains and origins that protect them, so if = that=E2=80=99s the model we=E2=80=99re arguing for we need to at least = consider all of that. We also need to consider that cookies fail in a = lot of ways! :)


What if = instead it=E2=80=99s:

- Support for = directed, audience-restricted access tokens in multi-RS deployments

Would that work? To me the difference is that = it=E2=80=99s getting away from a fixed notion of what an =E2=80=9CRS=E2=80= =9D is and more towards the notion of getting a token directed to a = specific set of actions and/or locations.

wfm, as long it is clear the AS/RS determines the = boundaries.

Ultimately they = always do, and they=E2=80=99ll always need to deal with the situation = where a client asks for rights that cross boundaries. The question is = what to do in those situations, and I think there=E2=80=99s a lot more = discussion we need to have on that front! Do we allow the AS to split a = token request, do we have errors for this, do we have a client indicate = that it can receive split tokens =E2=80=A6 etc. I think it=E2=80=99s an = interesting area, but complex and not nearly as clean-cut as your own = use case and deployment might let it be.

=E2=80= =94 Justin


best regards,
Torsten.


=E2=80=94 Justin

On Mar 19, 2020, at 2:08 PM, Torsten = Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Hi all,

I suggest = to add the following requirement to the charter:
 =E2=80= =A2 Support for RS-specific access tokens in Multi-RS deployments 

I don=E2=80=99t mind HOW this requirement is supported in = TXAuth. I want to make sure we try to build a protocol that serves the = needs of a broad set of deployments. My concern is otherwise TXAuth will = be not innovative enough to gain traction in the market rapidly. = Speaking for myself, I realised in the last couple of days, mostly in = conversations with Justin, that the result of this working group as = envisioned now is not of particular interest to us (yes.com) because it does not = solve our real problems. 

And here is my explanation: 

OAuth traditionally has the philosophy of a single access = token. That=E2=80=99s fine for single service deployments, but it had = reached its limits already before RFC6749 was published. There are a = real implementations out there forcing clients to use different access = tokens for different services, typically for privacy and security = reasons. There is also an =E2=80=9Cancient" technology called Kerberos = that uses exactly this pattern and is well known for security, = performance, and scalability. 

And there are even more examples today for multi API = environments that would benefit from that feature: 
 =E2=80=A2= Open banking: most banks I worked with have multiple APIs, segregation = between APIs is today achieved by maintaining different grants, = basically resulting in the fact that the users cannot consent to = different services at once. What a terrible UX!
 =E2=80= =A2 Everyone is doing micro services today. Have you every thought about = the coupling caused by a single token across micro services? This = reminds me of how easy it is to test services independently using = self-contained RS-specific tokens.
 =E2=80=A2 IoT - = every device in a household is a potential RS (in my opinion). Conveying = all necessary data in an access token needed to meet access control = decisions locally would be a huge benefit in terms of performance and = decoupling. Using symmetric cryptography for token integrity, = authenticity and confidentiality would result in lower compute = requirements.

Since we are preparing to = define a completely new protocol for API access authorization and = delegation, I think this new protocol should support this kind of = scenarios. It will require significant work to get it right and simple, = but if we just stick to the =E2=80=9Ca single access token is enough=E2=80= =9D mantra, we miss the chance to give implementers a broader range of = design choices out of the box and we won=E2=80=99t success in achieving = true interoperability.

Here are more = advantages we can gain by supporting such a feature: 
 =E2=80=A2= Privacy:
     =E2=80=A2 A single = access token can be used to track user across services.
     =E2=80=A2 RS-specific access = tokens cannot.
     =E2=80=A2 = RS-specific access tokens can also be encrypted to protect data = confidentiality in transit.
 =E2=80=A2 Security: = RS-specific access tokens have a baseline replay detection.
 =E2=80=A2 Performance: RS-specific access tokens allow = the AS to convey all data required to authorize an API call in a token = (e.g. a JWT) and to RS to meet the access control decision based on that = data. This is a huge advantage in terms of performance, scalability and = cost since there is no need for Token Introspection or other kinds of = access to another services or database.

What = do you think?

best regards,
Torsten. 

On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:


On 19/03/2020 = 19:11, Torsten Lodderstedt wrote:
On 19. Mar 2020, at 17:47, Justin Richer <jricher@mit.edu> = wrote:
Well, it=E2=80=99= s in scope as much as describing any other aspect of what the token is = for and what it represents is in scope. That is alongside things like = the intended audience of the token, the access rights for the token, the = presentation keys the token is bound to, etc. It could be information in = the token text itself (like a JWT), it could be introspected from the = AS, it could be referenced in some other way. So if we can define = identity aspects in that, then we=E2=80=99re fine in covering it = there. 

But here=E2=80=99s the thing: none of that has = an impact on the core protocol. That is entirely up to the AS and the RS = to agree on, and the client never sees or has any influence on it. That = portion of the protocol is completely opaque to the client. Therefore, = it doesn=E2=80=99t really affect the authorization and delegation = portions of the client talking to the AS and the client talking to the = RS.

This does raise the question of what = our bar of interoperability is going to be with TxAuth: do we expect = independent AS and RS implementations to talk to each other? That=E2=80=99= s not something OAuth 2 was ever concerned with, though obviously JWT = and introspection are both from the OAuth2 WG and solve that problem.
There are two aspects to it: interoperability = and vendor support. 

Interoperability between AS and RS is = important if deployments want to combine pre-packaged TXAuth and API = implementations. I think that makes a lot of sense and should be = included in the charter.

+1

The current OAuth 2.0 status quo of the = largely unspecified relationship
between AS and RS is also = making the life of web & sec framework
maintainers = difficult. We witnessing this with people integrating the
OAuth SDK into frameworks. Vittorio's recent work to put = together a
minimal interoperable JWT profile for access = tokens is helpful, but it
has come after the fact. And = there is not agreement on things like
authorising access = to claims.

Integrating apps (RSs) with = TxAuth should be straightforward and simple.

This can have a enormous effect on adoption.


Vendors = support: vendor support when it comes to "what can go into an access = token" and "what can be conveyed in a token introspection response=E2=80=9D= greatly deviates in my observation. This also means implementation use = vendors specific features restricting their ability to use other = solutions. TXAuth should aim at improving the situation.  

+1

I also think it is a = good exercise for the group to think the whole process "from the end=E2=80= =9D. The purpose of TXAuth (and OAuth) is not to provide clients with = access tokens. The purpose is to enable API request processing in a = secure manner. What it really takes to achieve that goal is not obvious = if the work always stops at the =E2=80=9Cyou have your access token, = good luck=E2=80=9D stage. 

+1

Vladimir


-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_B9C2920C-C1E3-4D66-A44C-27B091F7EAF4-- From nobody Sat Mar 21 10:00:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4B63A0440 for ; Sat, 21 Mar 2020 10:00:16 -0700 (PDT) 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_REMOTE_IMAGE=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 mj_07V1Dv-uL for ; Sat, 21 Mar 2020 10:00:13 -0700 (PDT) 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 47AFF3A043D for ; Sat, 21 Mar 2020 10:00:12 -0700 (PDT) Received: from [192.168.1.5] (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 02LH09ZW015169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 13:00:11 -0400 From: Justin Richer Message-Id: <69E6651E-8838-4A63-8EEE-46251E498EAE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_6A0B6942-F7C7-4D70-A885-1BFBC47BC06D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Mar 2020 13:00:08 -0400 In-Reply-To: Cc: txauth@ietf.org To: Tobias Looker References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Client bound user assertions X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:00:18 -0000 --Apple-Mail=_6A0B6942-F7C7-4D70-A885-1BFBC47BC06D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tobias, I think this is a new pattern that we=E2=80=99re going to be seeing more = of, with smart clients and credential wallets enabling things with = mobile devices that we couldn=E2=80=99t do before.=20 One of the first things we built into XYZ was the ability to pass and = receive assertions between the client and the AS in both directions. In = addition to the client being able to get an assertion about a user (like = in OIDC), it was an important feature that the client be able to present = an assertion back to the AS itself, so that the AS can make an access = determination without bugging the user, in the right circumstances. I = think what you=E2=80=99re proposing here is an interesting and valid = extension of that.=20 The assertions in OIDC are really designed to primarily be one-time = messages to the client from the AS. This is fantastic for logging in to = the client as an app, but the ID token really wasn=E2=80=99t meant to go = beyond that. I think that the structure of things like VCs,, with = presentation proofs through different keys and the like, is a powerful = pattern that we can enable in TxAuth.=20 I agree with Dick that there are a few missing pieces, like instructions = for how an AS can bind the client=E2=80=99s presented key to an = assertion, that can be facilitated. I am not convinced that solving = those within the TxAuth working group is the right approach =E2=80=94 I = think this is a part of the larger field of identity that would be = better solved by a dedicated group.=20 =E2=80=94 Justin > On Mar 19, 2020, at 6:22 PM, Tobias Looker = wrote: >=20 > Hi, >=20 > I'm unsure of the best way to articulate this idea on this forum, but = see my below explanation for an attempt. I'm also aware that it as a = discussion topic is dependent on how "identity" fits into TxAuth in = general.=20 >=20 > With OpenID connect today the format of the user assertions we get are = often bound to the client (or a small audience) mainly by the issuer = using the audience field in the id_token to communicate who it is for = (e.g this is for client x) which gives all parties a way to determine = whether they are the intended audience of the assertion. However, this = does not enable a client to authenticate as the intended audience of the = user assertion to other parties. If a client was instead able to = authenticate as the rightful audience of a user assertion then they = would be able to onward disclose the user assertion to a relying party, = such that the relying party would be able to authenticate both the = original issuer of the assertion and the client now presenting the = assertion. >=20 > See below for a simple example. >=20 > Here the client obtains a user assertion from the OP or Authorization = server that is suitably bound to the client in an authenticatable way. >=20 > >=20 > The relying party now makes a request to the client who is in = possession of the assertion from the authorization server and the client = can respond, presenting the assertion. In this flow, with regards to = OIDC, the client is essentially taking a similar role to that of a self = issued openid connect provider. >=20 > > =20 > How this could be realized in TxnAuth?=20 >=20 > If the client strongly authenticates at the start of an authorization = transaction e.g by signing the original authorization request with = either an ephemeral or static key, the resulting assertion could be = bound to this key enabling the client to authenticate as the rightful = audience of the assertion to other relying parties. Similar to how DPOP = for access_tokens works. >=20 > Why is this interesting and what use cases does it enable? >=20 > Being able to obtain user assertions that can be bound to the client = such that the client can onward disclose them enables new opportunities = around how users can manage different sources of their identity = information through a single client. This can help to eliminate things = like the nascar problem and presentations to relying parties that = require aggregating assertions from multiple authorization servers. >=20 > Thanks, > =09 > Tobias Looker > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > = = = > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >=20 > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_6A0B6942-F7C7-4D70-A885-1BFBC47BC06D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tobias,

I think this = is a new pattern that we=E2=80=99re going to be seeing more of, with = smart clients and credential wallets enabling things with mobile devices = that we couldn=E2=80=99t do before. 

One of the first things we built into = XYZ was the ability to pass and receive assertions between the client = and the AS in both directions. In addition to the client being able to = get an assertion about a user (like in OIDC), it was an important = feature that the client be able to present an assertion back to the AS = itself, so that the AS can make an access determination without bugging = the user, in the right circumstances. I think what you=E2=80=99re = proposing here is an interesting and valid extension of = that. 

The = assertions in OIDC are really designed to primarily be one-time messages = to the client from the AS. This is fantastic for logging in to the = client as an app, but the ID token really wasn=E2=80=99t meant to go = beyond that. I think that the structure of things like VCs,, with = presentation proofs through different keys and the like, is a powerful = pattern that we can enable in TxAuth. 

I agree with Dick that there are a few = missing pieces, like instructions for how an AS can bind the client=E2=80=99= s presented key to an assertion, that can be facilitated. I am not = convinced that solving those within the TxAuth working group is the = right approach =E2=80=94 I think this is a part of the larger field of = identity that would be better solved by a dedicated = group. 

 =E2=80=94 Justin

On Mar = 19, 2020, at 6:22 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

Hi,

I'm unsure of the best = way to articulate this idea on this forum, but see my below explanation = for an attempt. I'm also aware that it as a discussion topic is = dependent on how "identity" fits into TxAuth in general. 

With OpenID connect = today the format of the user assertions we get are often bound to the = client (or a small audience) mainly by the issuer using the audience = field in the id_token to communicate who it is for (e.g this is for = client x) which gives all parties a way to determine whether they are = the intended audience of the assertion. However, this does not enable a = client to authenticate as the intended audience of the user assertion to = other parties. If a client was instead able to authenticate as the = rightful audience of a user assertion then they would be able to onward = disclose the user assertion to a relying party, such that the relying = party would be able to authenticate both the original issuer of the = assertion and the client now presenting the assertion.

See below for a simple = example.

Here = the client obtains a user assertion from the OP or Authorization server = that is suitably bound to the client in an authenticatable = way.

<Screen Shot 2020-03-12 at 10.05.15 = AM.png>

The relying party now makes a request to the client who is in = possession of the assertion from the authorization server and the client = can respond, presenting the assertion. In this flow, with regards = to OIDC, the client is essentially taking a similar role to that of a = self issued openid connect provider.

<Screen = Shot 2020-03-12 at 10.05.20 AM.png>
 
How this could be realized in = TxnAuth? 

If the client strongly authenticates at the start of an = authorization transaction e.g by signing the original authorization = request with either an ephemeral or static key, the resulting assertion = could be bound to this key enabling the client to authenticate as the = rightful audience of the assertion to other relying parties. Similar to = how DPOP for access_tokens works.

Why is this interesting and what use = cases does it enable?

Being able to obtain user assertions that can be bound to the = client such that the client can onward disclose them enables new = opportunities around how users can manage different sources of their = identity information through a single client. This can help to eliminate = things like the nascar problem and presentations to relying parties that = require aggregating assertions from multiple authorization = servers.

Thanks,
3D"Mattr 
Tobias Looker
Mattr
+64 = (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is = confidential. If you are not the intended recipient, you should not read = it - please contact me immediately, destroy it, and do not copy or use = any part of this communication or disclose anything about it. Thank you. = Please note that this communication does not designate an information = system for the purposes of the Electronic Transactions Act = 2002.

This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act 2002.
-- =
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_6A0B6942-F7C7-4D70-A885-1BFBC47BC06D-- From nobody Sat Mar 21 10:07:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6763A05A6 for ; Sat, 21 Mar 2020 10:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=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 Ha5uWeZRpWSA for ; Sat, 21 Mar 2020 10:07:32 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 2568E3A0593 for ; Sat, 21 Mar 2020 10:07:32 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id f130so8614883wmf.4 for ; Sat, 21 Mar 2020 10:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=WE3rs5pXUBDzVpUTWItxAC6QU4vGxjCOjsE2hCb35Hw=; b=cvB/xJai5diq56NZm2aauReN2h8jF8GKYBOP0SrnNQlL6zW3WjuKFm37RpDUhNbs3t AngLZEACmiAsT7a5yQjdR8sfe714rOsqez1C3RkKwUiG3kF8JaN9Pceelu4tRkLE6E9s NtocAEHX2IAnMWInLw7+6GM5PQ/5yx6rijbEp5RcxvqkNfVVD045kQMxuzn1u+vVzbVh AzDEBPPsq2qTKQMotdPXqE5H6V2b6B4t+bnczm2fircQS6eMxh/sBMUStrKTaNn8ylYb wv+vnHZpLS4ajyBuTO8h90UXdjBIgNDiNuhuMkGCm/ZLwBTADNt4RRK6f4TLtNLmk0EN VnQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=WE3rs5pXUBDzVpUTWItxAC6QU4vGxjCOjsE2hCb35Hw=; b=IsuTlyvRdElr4bfIegb9cA3fAhA0XUKls00Fu4Eqdu9JOr/to028mipA/jQr9LBV5e dhxqbD5krDdDs0Dh/85WwbLXA8tXAbkLObu1HQ4FLCnamwzDypx4EJMOh+nO76p7K42A bfFUAM4q3NQMgI6J2y7DW61ovKs+TlwRAFcjx2Ee7+0kDt43iL/J6FWYsfSAAKjnqt35 UB0fyHETLOocMduRPa9cb4pSdhbyIf8fqphLwAfDcth9InA0bLdOqVo4vVydbWvCPRF+ NeXye7b+8cJk2IZNzt+oL66Cm/GrePciAvCH9OEoqWew/zHJ3T7UcufIq6K3f3QFS9ZW uHrA== X-Gm-Message-State: ANhLgQ3jexjWQ9O+eTT9gG5Dv8uQQFM0gR4Nyon1qt+atoBmRbGLvywj l+7YukMrDtyVEuztQJb0RWg= X-Google-Smtp-Source: ADFU+vssbvLoFr4/Ac8dJR93bzXoOGvCdU5D5S8HaxEq2p6jMt8XwXaCbu4KWBf8GDl4RT+4kBsRcQ== X-Received: by 2002:a1c:456:: with SMTP id 83mr17294821wme.54.1584810450328; Sat, 21 Mar 2020 10:07:30 -0700 (PDT) Received: from [10.0.0.144] (bzq-79-178-61-110.red.bezeqint.net. [79.178.61.110]) by smtp.gmail.com with ESMTPSA id z129sm13205564wmb.7.2020.03.21.10.07.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2020 10:07:29 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Sat, 21 Mar 2020 19:07:28 +0200 From: Yaron Sheffer To: Dick Hardt , Justin Richer CC: Message-ID: Thread-Topic: WG name: TxAuth? XAuth? Something else? References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3667662449_1941853725" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:07:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3667662449_1941853725 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Personally, I don=E2=80=99t mind the =E2=80=9CTx=E2=80=9D but I hate the =E2=80=9Cauth=E2=80=9D, which ev= erybody outside of this community understands as =E2=80=9Cauthentication=E2=80=9D. =20 Having said that, IMHO this discussion is not the best use of our time, and= I=E2=80=99d rather spend it on coming up with a great protocol. Regardless of wha= t the WG is called. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Dick Hardt Date: Saturday, March 21, 2020 at 03:16 To: Justin Richer Cc: , Yaron Sheffer Subject: Re: WG name: TxAuth? XAuth? Something else? =20 That would be easier if it was TAuth rather than TxAuth. "Tx" is well known= to mean transaction -- regardless of what we decide. "O" could mean anythin= g that starts with "O", and my experience has been few people know the work = started as OpenAuth. =20 I've made my argument, I'm fine going with the group consensus. I do reserv= e the right in the future to say "I told you so!" =3D) =20 Does anyone else have an opinion? =20 On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: Dick, thanks for pulling the definitions up: =20 > a communicative action or activity involving two parties or things that r= eciprocally affect or influence each other =20 This is the kind of thing that I had in mind. The client and the AS are in = a conversation over time that each one contributes to and each changes.=20 =20 Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand for= =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that the =E2=80=9CO=E2=80=9D in =E2= =80=9COAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore.=20 =20 None of the arguments below in favor of XAuth have made me like that name b= etter. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then why come up with someth= ing new? =20 =E2=80=94 Justin On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: =20 =20 =20 =20 not a transaction - there are multiple transactions =20 backchannel innovation is combination of here is who I am, and here is what= I want to do =20 =20 childhood trauma therapy group =20 =20 =20 On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: Yes, naming things is hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80= =99re moving beyond OAuth, and taking the process of getting an authorization = delegated to the client software as a multi-step, multi-party transaction is= , I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2=80=99s limit= ations here. It=E2=80=99s not just about going to the AS first =E2=80=94 we had that in = OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I really think it=E2=80= =99s about the transaction at the core.=20 =20 OAuth 2.0 had multi-step, multi-party. TxAuth extends that. =20 I think the big shift is going to the AS. This enables the request to be ri= cher with JSON, instead of name/value pairs parameters in a URI. It allows t= he client and AS to negotiate, and to short circuit having to redirect the u= ser to the AS. PAR does some of this, but it is constrained by having to do = it in the OAuth 2.0 context. =20 My concern is that the protocol is MUCH MORE than a transaction. While the = initial interaction between client, AS, user and RO is a transaction. The pr= otocol also covers the client and RS interactions. The access token refreshe= s. Access token revocation. Access token introspection. As described in the = charter, there is a whole lifecycle, that consists of multiple transactions. =20 >From https://www.merriam-webster.com/dictionary/transaction: =20 Definition of transaction 1a: something transactedespecially : an exchange or transfer of goods, serv= ices, or fundselectronic transactions b: transactions plural : the often published record of the meeting of a soc= iety or association 2a: an act, process, or instance of transacting b: a communicative action or activity involving two parties or things that = reciprocally affect or influence each other =20 Calling the protocol a transaction will confusing to people. =20 =20 Having come of age in the 1990=E2=80=99s, I have particular dislike for XAuth. It= sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you read either of thos= e with a growling yell in your head then you know exactly what I=E2=80=99m talking= about. =20 In case you are confused, this is not a childhood trauma support group. :) =20 Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. X-= Men, Xbox, X-Factor, X-files.=20 =20 https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 =20 https://english.stackexchange.com/questions/358181/whats-the-purpose-of-usi= ng-letter-x-or-x-as-a-suffix-in-brand-names =20 =20 And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT see this = work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think that does a disserv= ice to the kind of change we have an opportunity to make here.=20 =20 >From the charter=20 =20 "It will expand upon the uses cases currently supported by OAuth 2.0 and Op= enID Connect (itself an extension of OAuth 2.0)" =20 Which sounds pretty similar to =E2=80=9COAuth with all the extra features=E2=80=9D =20 While I think XAuth captures what we are doing, a placeholder name would be= preferable to an incorrect descriptive name such as TxAuth. =20 For example, XYZ is a good placeholder name. Or XYZAuth. Let's not mislead = people. =20 =20 =E2=80=94 Justin On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: =20 Hello everyone =20 I prompted a thread around the name of the protocol a while back: =20 https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ =20 As Justin stated "naming is hard" =20 Wearing my marketing hat I want to ensure that the name will be perceived p= roperly in the broader community. =20 A recent example that comes to mind are the privacy related works on the br= owser storage API. Given that name, one would think that it is local storage= . It is actually about browser cookies. =20 Justin discussed his reasons for TxAuth in the thread above (and I'm sure i= n other places) =20 I chose XAuth in my draft to reflect the eXtensibility goal that we have ov= er OAuth -- and XAuth is OAuth but with an X to reflect all the extra featur= es. =3D) =20 Other suggestions? =20 This will be an agenda item in the BoF -- but the name will NOT be an open = discussion item -- we will summarize what has been discussed on the list and= perhaps do a poll of options presented unless consensus is obvious from thi= s thread. =20 /Dick =20 =20 =20 =20 =20 =E1=90=A7 =20 =20 --B_3667662449_1941853725 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Personally, I don=E2=80=99t mind = the =E2=80=9CTx=E2=80=9D but I hate the =E2=80=9Cauth=E2=80=9D, which everybody outside of this comm= unity understands as =E2=80=9Cauthentication=E2=80=9D.

=  

Having said that, IMHO this discussi= on is not the best use of our time, and I=E2=80=99d rather spend it on coming up w= ith a great protocol. Regardless of what the WG is called.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Dick Hardt <dick.hardt@gmail.com>
Date: Satur= day, March 21, 2020 at 03:16
To: Justin Richer <jricher@mit.edu= >
Cc: <txauth@ietf.org>, Yaron Sheffer <yaronf.ietf@gm= ail.com>
Subject: Re: WG name: TxAuth? XAuth? Something else?

 

That would be easier if it was TAuth rather than Tx= Auth. "Tx" is well known to mean transaction -- regardless of what= we decide. "O" could mean anything that starts with "O"= , and my experience has been few people know the work started as OpenAuth.

 

I've made my argument, I'm fine going with the group consen= sus. I do reserve the right in the future to say "I told you so!" = =3D)

 

Does anyone else have an opinion?

<= /div>

 

On Fri, Mar 20, 2020 at 5:53 PM Justin Richer <jricher@mit.edu> wrote:

Dick, thanks for = pulling the definitions up:

 = ;

> a communicati= ve action or activity involving two parties or things that reciprocally affe= ct or influence each other

 

This is the kind of thi= ng that I had in mind. The client and the AS are in a conversation over time= that each one contributes to and each changes. 

 

Als= o =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9C= Transactional Auth=E2=80=9D much the same way we decided that the =E2=80=9CO=E2=80=9D in =E2=80=9COA= uth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. 

 

None= of the arguments below in favor of XAuth have made me like that name better= . If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then why come up with something n= ew?

 

<= div>

 =E2=80=94 Justin



On Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

 

 

 

 

not a transaction - there are multiple transa= ctions

 

backchannel innovation is combination of here is wh= o I am, and here is what I want to do

 

 

childhood trauma therapy group

 

 

 <= /p>

On Mon, Mar 16, 2020 at 6:56 PM Justin Riche= r <jricher@mit.edu&g= t; wrote:

Yes, naming things is hard =E2=80=94 but I still believ= e in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of= getting an authorization delegated to the client software as a multi-step, = multi-party transaction is, I believe, the key insight that=E2=80=99s letting us m= ove beyond OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to the AS= first =E2=80=94 we had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 wit= h PAR. I really think it=E2=80=99s about the transaction at the core. 

 

OAuth 2.0 had multi-step, multi-party. TxAuth exte= nds that.

 

<= /div>

I think the big shift is going to the AS. This = enables the request to be richer with JSON, instead of name/value pairs para= meters in a URI. It allows the client and AS to negotiate, and to short circ= uit having to redirect the user to the AS. PAR does some of this, but i= t is constrained by having to do it in the OAuth 2.0 context.

=

 

My concern is that the protocol is MUCH MORE than a transaction. While = the initial interaction between client, AS, user and RO is a transaction. Th= e protocol also covers the client and RS interactions. The access token= refreshes. Access token revocation. Access token introspection. As describe= d in the charter, there is a whole lifecycle, that consists of multiple tran= sactions.

 

<= /div>

 

Definition of&= nbsp;t= ransaction

1a: something t= ransactedespecially : an exchange or transfer of goods, services, or fundselectronic transactions

<= span style=3D'font-size:13.5pt;font-family:Helvetica;color:#212529;letter-spac= ing:.15pt;border:none windowtext 1.0pt;padding:0in'>b: transactions plural<= /span> = : = the often published= record of the meeting of a society or association

2a: an act, process, or instance of transacting

b: a communicative action or activity involving two partie= s or things that reciprocally affect or influence each other

 

Calling the protocol a transaction will confusing to people.

 

=  

Having come of age in the 1990= =E2=80=99s, I have particular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you read either of those with a growling yell in your = head then you know exactly what I=E2=80=99m talking about.

 

In case you are confused, this is not a childhood trauma= support group.  :)

&n= bsp;

Unlike "X-TREME" or &q= uot;X-CITING", XAuth is using the "X" as a placeholder. X-Men= , Xbox, X-Factor, X-files. 

 

 

 

And to Dick=E2=80=99s rationale for the = name below, I absolutely do NOT see this work as =E2=80=9COAuth with all the extra= features=E2=80=9D. I think that does a disservice to the kind of change we have a= n opportunity to make here. 

 

From= the charter 

 

=

"It will expand upon the uses cases curren= tly supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0)"

 

Which sounds pretty si= milar to =E2=80=9COAuth with all the extra features=E2=80=9D

 

Whi= le I think XAuth captures what we are doing, a placeholder name would be pre= ferable to an incorrect descriptive name such as TxAuth.

 

For example, XYZ is a good placeholder name. Or= XYZAuth. Let's not mislead people.

 

 

 =E2=80=94 Justin



=

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

 

Hello everyone

 

I prompted a thread around the name of= the protocol a while back:

 

 

As Justin stated "naming is hard"

 

Wearing my marketing hat I want to ensure that the name will be perceived=  properly in the broader community.

 

A recent example= that comes to mind are the privacy related works on the browser storage API= . Given that name, one would think that it is local storage. It is actually = about browser cookies.

&nbs= p;

Justin discussed his reasons for T= xAuth in the thread above (and I'm sure in other places)

 

= I chose XAuth in my draft to reflect the eXtensibility goal that we have ove= r OAuth -- and XAuth is OAuth but with an X to reflect all the extra feature= s. =3D)

 

Other suggestions?

 

This will be = an agenda item in the BoF -- but the name will NOT be an open discussion ite= m -- we will summarize what has been discussed on the list and perhaps = do a poll of options presented unless consensus is obvious from this thread.=

 

/Dick

&= nbsp;

 

 

=  

 

3D"Image=E1=90=A7

 

 

--B_3667662449_1941853725-- From nobody Sat Mar 21 10:13:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52973A0745 for ; Sat, 21 Mar 2020 10:13:00 -0700 (PDT) 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=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 hkgAN3iaXxuB for ; Sat, 21 Mar 2020 10:12:58 -0700 (PDT) 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 8DCEA3A05A6 for ; Sat, 21 Mar 2020 10:12:58 -0700 (PDT) Received: from [192.168.1.5] (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 02LHCnCg018199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 13:12:50 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Sat, 21 Mar 2020 13:12:49 -0400 Cc: Torsten Lodderstedt , "txauth@ietf.org" , Vladimir Dzhuvinov Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net> <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu> <255028E2-8B99-438F-80DB-434B000114B1@lodderstedt.net> <0CD3C061-D85F-45AC-898E-633682CF4C77@lodderstedt.net> <11014BC4-4DA5-4A21-8D35-6F3B4698EC37@lodderstedt.net> To: Kim X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:13:01 -0000 Kim, I don=E2=80=99t believe anybody is claiming that TxAuth should = =E2=80=9Creplace all existing identity technology.=E2=80=9D Because = let=E2=80=99s be real =E2=80=94 it=E2=80=99s not even going to replace = OAuth 2, for many people. There are still many SAML deployments and = Kerberos installations going up today, even though OIDC does those = things and does them better.=20 But what we can do is enable new things. And I especially think we need = to pay attention to the identity use cases and enable passing of a few = simple claims is a reasonable scope.=20 We aren=E2=80=99t trying to rebuild the world, here. But we=E2=80=99d be = foolish to ignore identity completely, and having the right hooks in = place will help us have a stronger base to build the eventual larger = identity process.=20 People want to use protocols like this to pass identity information. = Twitter and Facebook showed us that back before OAuth 2 was ratified, = and OIDC confirmed it even further. I think it=E2=80=99s high time we = admitted that the real world doesn=E2=80=99t hold to the same idealistic = separation. That said, I completely agree that we need to limit the scope of what = parts of identity we work on, especially in terms of what we work on = when. The points that address identity in the charter are: Work items in different categories: - Approval of AS attestation to identity claims - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions - Optimized inclusion of additional information through the delegation = process (including identity) As a milestone: - Identity and authentication conveyance mechanisms How would you recommend we narrow the scope of these so that it=E2=80=99s = more clearly manageable, and that the eventual chairs will be able to = decide what is in and out of scope based on that? Thanks, =E2=80=94 Justin > On Mar 20, 2020, at 5:07 PM, Kim wrote: >=20 > I very much agree with Torsten's proposal and think it provides a way = to focus TxAuth's initiatives on solving the many and deep problems of = the authorization layer by better integrating it with the claims based = model of identity. =20 >=20 > It is also clear to me that there is zero consensus that TxAuth should = be chartered to be a replacement for all existing identity technology. =20= >=20 > Instead, there is wide consensus that TxAuth should integrate the = claims based model into the authorization layer and attack the many = unsolved problems we have experienced with increasingly interdependent = networks of interacting services . =20 >=20 > Surely doing so is an immense task and a sufficient mandate. = Meanwhile, when people working on authorization encounter defects in = existing identity protocols, those protocols should be fixed so the = improvements accrue to all of the layers that are dependent on claims, = not just authorization.=20 >=20 > Identity in general has big problems that remain to be solved. But as = the digital sphere expands the greatest of these is that of creating a = holistic identity layer that serves the needs we have as human beings as = well as it serves those who operate digital enterprises. Identity = technology will have to embrace much more than protocols for exchanging = claims and deciding whether to trust them. How can TxAuth possibly = succeed at solving the difficult problems of authorization while at the = same time taking on this other vast set of hard problems?=20 >=20 > It is far better for TxAuth to limit its scope to the kinds of = initiatives proposed by Torsten and to prevail upon entities such as = OIDC to correct any deficiencies that prevent their work from being = reused in the authorization layer rather than reinventing everything. >=20 > I also agree with the comments and proposals made by Nat, Mike Jones = and Vittorio. If consensus is really being sought, focusing on the = authorization layer and its use of claims rather than all of identity = will certainly bring it about. >=20 > Best regards, >=20 > Kim Cameron >=20 >=20 > -----Original Message----- > From: Txauth On Behalf Of Torsten = Lodderstedt > Sent: Thursday, March 19, 2020 12:09 PM > To: txauth@ietf.org > Cc: Vladimir Dzhuvinov > Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >=20 > Hi all, >=20 > I suggest to add the following requirement to the charter: > =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >=20 > I don=E2=80=99t mind HOW this requirement is supported in TXAuth. I = want to make sure we try to build a protocol that serves the needs of a = broad set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 >=20 > And here is my explanation:=20 >=20 > OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 >=20 > And there are even more examples today for multi API environments that = would benefit from that feature:=20 > =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! > =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. > =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. >=20 > Since we are preparing to define a completely new protocol for API = access authorization and delegation, I think this new protocol should = support this kind of scenarios. It will require significant work to get = it right and simple, but if we just stick to the =E2=80=9Ca single = access token is enough=E2=80=9D mantra, we miss the chance to give = implementers a broader range of design choices out of the box and we = won=E2=80=99t success in achieving true interoperability. >=20 > Here are more advantages we can gain by supporting such a feature:=20 > =E2=80=A2 Privacy: > =E2=80=A2 A single access token can be used to track = user across services. > =E2=80=A2 RS-specific access tokens cannot. > =E2=80=A2 RS-specific access tokens can also be = encrypted to protect data confidentiality in transit. > =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. > =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >=20 > What do you think? >=20 > best regards, > Torsten.=20 >=20 >> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>=20 >>=20 >> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>> On 19. Mar 2020, at 17:47, Justin Richer wrote: >>>> Well, it=E2=80=99s in scope as much as describing any other aspect = of what the token is for and what it represents is in scope. That is = alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>=20 >>>> But here=E2=80=99s the thing: none of that has an impact on the = core protocol. That is entirely up to the AS and the RS to agree on, and = the client never sees or has any influence on it. That portion of the = protocol is completely opaque to the client. Therefore, it doesn=E2=80=99t= really affect the authorization and delegation portions of the client = talking to the AS and the client talking to the RS. >>>>=20 >>>> This does raise the question of what our bar of interoperability is = going to be with TxAuth: do we expect independent AS and RS = implementations to talk to each other? That=E2=80=99s not something = OAuth 2 was ever concerned with, though obviously JWT and introspection = are both from the OAuth2 WG and solve that problem. >>> There are two aspects to it: interoperability and vendor support.=20 >>>=20 >>> Interoperability between AS and RS is important if deployments want = to combine pre-packaged TXAuth and API implementations. I think that = makes a lot of sense and should be included in the charter. >>=20 >> +1 >>=20 >> The current OAuth 2.0 status quo of the largely unspecified=20 >> relationship between AS and RS is also making the life of web & sec=20= >> framework maintainers difficult. We witnessing this with people=20 >> integrating the OAuth SDK into frameworks. Vittorio's recent work to=20= >> put together a minimal interoperable JWT profile for access tokens is=20= >> helpful, but it has come after the fact. And there is not agreement = on=20 >> things like authorising access to claims. >>=20 >> Integrating apps (RSs) with TxAuth should be straightforward and = simple. >>=20 >> This can have a enormous effect on adoption. >>=20 >>=20 >>> Vendors support: vendor support when it comes to "what can go into = an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>=20 >> +1 >>=20 >>=20 >>> I also think it is a good exercise for the group to think the whole = process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) is not = to provide clients with access tokens. The purpose is to enable API = request processing in a secure manner. What it really takes to achieve = that goal is not obvious if the work always stops at the =E2=80=9Cyou = have your access token, good luck=E2=80=9D stage.=20 >>=20 >> +1 >>=20 >> Vladimir >>=20 >>=20 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Mar 21 10:15:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3B43A0763 for ; Sat, 21 Mar 2020 10:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_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=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 ahyL1ap3EH4P for ; Sat, 21 Mar 2020 10:15:30 -0700 (PDT) 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 506BF3A0747 for ; Sat, 21 Mar 2020 10:15:30 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id i1so6263872lfo.1 for ; Sat, 21 Mar 2020 10:15:30 -0700 (PDT) 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=kbul042ksE4m7dL39XRzCWT21HaGVPS2g7pwfppkpkg=; b=kgM+dikjMw9VHUtdT/58PeB3hDHZvYgXiMr9C/00A6XFRhPwm3zfAFUhwZFl+2+Lch hBIUANVsAZmGU2Y029I3RzQEmIlzJQsQUi63oB4cjSrUV4K27N8/UvbVsrFl8hacNzfi soKHZLPafIzPCJN3nFVFnTjk8FTPgPGR8CHOlFtO9fluv5cbo4EhVkgz8gSpMcqrmEtx Ki+aHzlpy9LJw8fMyWDe0+dVN47SJXV9zIMBMtIYCMqkiLE3y3XiXXRn/IJS3FxMAHQ5 ivQSw+BrkVyPIm609Zb1wQWuei2CmiTSfXdXmOgezdR+a2TIBt/am1jpO+IXSivzi0NL PTGA== 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=kbul042ksE4m7dL39XRzCWT21HaGVPS2g7pwfppkpkg=; b=VRGcwh+A1g7Z+1cb1rXzgv8pWQ5GQSyRkCQz9vNLIiNew/oPxx1puXzeLAhu1xpnTY 7HYn1ORuzKSUWibUQhaGonmZvWasf1VQj1m++s7BD6SosH8degqVArBqoyOmm8Dw3lQp GGq16IO3TvYK7it7ZLhsa2BspCU5hcOMULabrn6/RzuJxVrGUHZuxouN9Aq6zAkrBUV6 Dbr2RhKyik9QWBnZ0UhGK/0Yx3GSFQ4a5IGqC0KYVhbl6D0y/b7lebRjKW86MSFqJ2Bc FEINBwZx1sXZ0aNrOT64PUPjZ9upOAYeEOUst+oK8mYT3NdYXGvnLAr4MZqP8+8D1iK8 x3SQ== X-Gm-Message-State: ANhLgQ0ayyHl4Lt7NdwW+UcIwSjlHBPkPDEZgOndVQpHzd1RotAZVY8/ uYWYMbS6jdLkOGzfH8Ob3Ow5Q2dDeufuqrjCZTs= X-Google-Smtp-Source: ADFU+vsk+TRR3foEimfYQvPgqSuGUaDoCV6exdOCnKzbcjd3b+6I3U5R9GuIwJBjvTHR7eB88oICyMVcCTQIG0h3o0E= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr2979781lfm.91.1584810928068; Sat, 21 Mar 2020 10:15:28 -0700 (PDT) MIME-Version: 1.0 References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> In-Reply-To: <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> From: Dick Hardt Date: Sat, 21 Mar 2020 10:15:01 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Yaron Sheffer Content-Type: multipart/alternative; boundary="000000000000675e1105a1608c9f" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:15:34 -0000 --000000000000675e1105a1608c9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To clarify -- you agree it is not a transaction, and we will take the word transaction out of the WG title? On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: > Dick, thanks for pulling the definitions up: > > > a communicative action or activity involving two parties or things that > reciprocally affect or influence each other > > This is the kind of thing that I had in mind. The client and the AS are i= n > a conversation over time that each one contributes to and each changes. > > Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D= doesn=E2=80=99t stand for > =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that th= e =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D > doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. > > None of the arguments below in favor of XAuth have made me like that name > better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then w= hy come up with something > new? > > =E2=80=94 Justin > > On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: > > > > > not a transaction - there are multiple transactions > > backchannel innovation is combination of here is who I am, and here is > what I want to do > > > childhood trauma therapy group > > > > On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: > >> Yes, naming things is hard =E2=80=94 but I still believe in the name TxA= uth. >> We=E2=80=99re moving beyond OAuth, and taking the process of getting an >> authorization delegated to the client software as a multi-step, multi-pa= rty >> transaction is, I believe, the key insight that=E2=80=99s letting us mov= e beyond >> OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to t= he AS first =E2=80=94 we >> had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PA= R. I really >> think it=E2=80=99s about the transaction at the core. >> > > OAuth 2.0 had multi-step, multi-party. TxAuth extends that. > > I think the big shift is going to the AS. This enables the request to be > richer with JSON, instead of name/value pairs parameters in a URI. It > allows the client and AS to negotiate, and to short circuit having to > redirect the user to the AS. PAR does some of this, but it is constrained > by having to do it in the OAuth 2.0 context. > > My concern is that the protocol is MUCH MORE than a transaction. While th= e > initial interaction between client, AS, user and RO is a transaction. The > protocol also covers the client and RS interactions. The access token > refreshes. Access token revocation. Access token introspection. As > described in the charter, there is a whole lifecycle, that consists of > multiple transactions. > > From https://www.merriam-webster.com/dictionary/transaction: > > Definition of *transaction* > > 1a: something transacted > especially : an > exchange or transfer of > goods, services, or fundselectronic transactions > b: transactions plural : the often published record of the meeting of a > society or association > 2a: an act, process, or instance of transacting > > b: a communicative action or activity involving two parties or things > that reciprocally affect or influence each other > > Calling the protocol a transaction will confusing to people. > > >> >> Having come of age in the 1990=E2=80=99s, I have particular dislike for = XAuth. It >> sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and= if you read either of those with a >> growling yell in your head then you know exactly what I=E2=80=99m talkin= g about. >> > > In case you are confused, this is not a childhood trauma support group. = :) > > Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. > X-Men, Xbox, X-Factor, X-files. > > https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 > > > https://english.stackexchange.com/questions/358181/whats-the-purpose-of-u= sing-letter-x-or-x-as-a-suffix-in-brand-names > > > >> And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this >> work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think tha= t does a disservice >> to the kind of change we have an opportunity to make here. >> > > From the charter > > "It will expand upon the uses cases currently supported by OAuth 2.0 and > OpenID Connect (itself an extension of OAuth 2.0)" > > > Which sounds pretty similar to =E2=80=9COAuth with all the extra features= =E2=80=9D > > While I think XAuth captures what we are doing, a placeholder name would > be preferable to an incorrect descriptive name such as TxAuth. > > For example, XYZ is a good placeholder name. Or XYZAuth. Let's not mislea= d > people. > > > >> >> =E2=80=94 Justin >> >> On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >> >> Hello everyone >> >> I prompted a thread around the name of the protocol a while back: >> >> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc= / >> >> As Justin stated "naming is hard" >> >> Wearing my marketing hat I want to ensure that the name will be >> perceived properly in the broader community. >> >> A recent example that comes to mind are the privacy related works on the >> browser storage API. Given that name, one would think that it is local >> storage. It is actually about browser cookies. >> >> Justin discussed his reasons for TxAuth in the thread above (and I'm sur= e >> in other places) >> >> I chose XAuth in my draft to reflect the eXtensibility goal that we have >> over OAuth -- and XAuth is OAuth but with an X to reflect all the extra >> features. =3D) >> >> Other suggestions? >> >> This will be an agenda item in the BoF -- but the name will NOT be an >> open discussion item -- we will summarize what has been discussed on the >> list and perhaps do a poll of options presented unless consensus is obvi= ous >> from this thread. >> >> /Dick >> >> >> >> >> >> =E1=90=A7 >> >> >> > --000000000000675e1105a1608c9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To clarify -- you agree it is not a transaction, and we wi= ll take the word transaction out of the WG title?

On Fri, Mar 20, 2020= at 5:53 PM Justin Richer <jricher@mi= t.edu> wrote:
Dick, thanks for pulling the= definitions up:

>=C2=A0a communicative action or activity involving t= wo parties or things that reciprocally affect or influence each other

This is the kind of thing that I had in mind. Th= e client and the AS are in a conversation over time that each one contribut= es to and each changes.=C2=A0

Also =E2=80=94 we ca= n just as easily decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand= for =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that= the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D doesn=E2=80=99t stand f= or =E2=80=9COpen=E2=80=9D anymore.=C2=A0

None of t= he arguments below in favor of XAuth have made me like that name better. If= it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then why come up w= ith something new?

=C2=A0=E2=80=94 Justin
=
On Mar 20, 2020, at 3:32 PM, Dick Hardt = <dick.hardt@gm= ail.com> wrote:




not a transaction - there are mult= iple transactions

backchannel innovation is combination= =C2=A0of here is who I am, and here is what I want to do


childhood trauma therapy group



On Mon, Mar 16, 2020 at 6:56 PM Justin Richer <jricher@mit.edu> wrote:
=
Yes, naming th= ings is hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80=99r= e moving beyond OAuth, and taking the process of getting an authorization d= elegated to the client software as a multi-step, multi-party transaction is= , I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2= =80=99s limitations here. It=E2=80=99s not just about going to the AS first= =E2=80=94 we had that in OAuth 1 and we=E2=80=99re patching that into OAut= h 2 with PAR. I really think it=E2=80=99s about the transaction at the core= .=C2=A0

OAuth 2.0 had multi-step, mul= ti-party. TxAuth extends that.

I think the big shi= ft is going to the AS. This enables the request to be richer with JSON, ins= tead of name/value pairs parameters in a URI. It allows the client and AS t= o negotiate, and to short circuit having to redirect the user to the AS. PA= R does=C2=A0some of this, but it is constrained by having to do it in the O= Auth 2.0 context.

My concern is that the protocol = is MUCH MORE than a transaction. While the initial interaction between clie= nt, AS, user and RO is a transaction. The protocol also covers the client= =C2=A0and RS interactions. The access token refreshes. Access token revocat= ion. Access token introspection. As described in the charter, there is a wh= ole lifecycle, that consists of multiple transactions.

=

Definition of=C2=A0= transaction

1a:=C2=A0something=C2=A0transactedespe= cially=C2=A0:=C2=A0an exchange or=C2=A0transfer=C2=A0of goods, services, = or fundselectronic=C2=A0transactions
b:=C2=A0transactio= ns=C2= =A0plural=C2=A0:=C2=A0the often published record of the mee= ting of a society or association
2a:=C2=A0an act, process, or instance of=C2=A0transacting<= /span>
b:=C2=A0a communicative action or activity involving two parties o= r things that reciprocally affect or influence each other

Calling the protocol a trans= action will confusing to people.
=C2=A0

Having come of age i= n the 1990=E2=80=99s, I have particular dislike for XAuth. It sounds too = =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you read e= ither of those with a growling yell in your head then you know exactly what= I=E2=80=99m talking about.

In = case you are confused, this is not a childhood=C2=A0trauma support group.= =C2=A0 :)

Unlike "X-TREME" or "X-CI= TING", XAuth is using the "X" as a placeholder. X-Men, Xbox,= X-Factor, X-files.=C2=A0


=C2=A0
And to Dick=E2=80=99s rationale fo= r the name below, I absolutely do NOT see this work as =E2=80=9COAuth with = all the extra features=E2=80=9D. I think that does a disservice to the kind= of change we have an opportunity to make here.=C2=A0

From the charter=C2=A0

"It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0= )"

<= div>Which sounds pretty similar to=C2=A0=E2=80=9COAuth with all the extra f= eatures=E2=80=9D

While I think XAuth captures what= we are doing, a placeholder name would be preferable to an incorrect descr= iptive name such as TxAuth.

For example, XYZ is a = good placeholder name. Or XYZAuth. Let's not mislead people.

=C2=A0
=

=C2=A0=E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Hello everyone

I promp= ted a thread around the name of the protocol a while back:


As Ju= stin stated "naming is hard"

Wearing my = marketing hat I want to ensure that the name will be perceived=C2=A0properl= y in the broader community.

A recent example that = comes to mind are the privacy related works on the browser storage API. Giv= en that name, one would think that it is local storage. It is actually abou= t browser cookies.

Justin discussed his reasons fo= r TxAuth in the thread above (and I'm sure in other places)
<= br>
I chose XAuth in my draft to reflect the eXtensibility goal t= hat we have over OAuth -- and XAuth is OAuth but with an X to reflect all t= he extra features. =3D)

Other suggestions?

This will be an agenda item in the BoF -- but the name wi= ll NOT be an open discussion item -- we will summarize=C2=A0what has been d= iscussed on the list and perhaps do a poll of options presented unless cons= ensus is obvious from this thread.

/Dick





3D""=E1=90=A7


--000000000000675e1105a1608c9f-- From nobody Sat Mar 21 10:22:15 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081BD3A077A for ; Sat, 21 Mar 2020 10:22:14 -0700 (PDT) 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 DciDfGpFeBfX for ; Sat, 21 Mar 2020 10:22:12 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 3A6233A0778 for ; Sat, 21 Mar 2020 10:22:12 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id g27so1117857ljn.10 for ; Sat, 21 Mar 2020 10:22:12 -0700 (PDT) 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=sWT8hHA0J1/DRfLdZMqQFZn9XdBk5XJR2o5PvOkyYWI=; b=g8M1CBT1JRviRle/cf1vtLIMEV3Wnnq1VUuVzfskmvo7HGIMLQ1pRF9EFqvo4FhYY4 pjN/zEx+Jw3p32Mk0uhCXtqxE5j+5XsTgAELCi36hQyljhjGYnh22ztyHZwXedJsZfW/ RhUNBElM97LxoeF8r336vCK/vLECgsImS+jb01wQPodmi+9FFM4psG7jl/V7foC8Q0Xq mmnu7BTa8X9s7d2cO8KUGeOgMnW7clINFHX+CAyp1O5vn2n8KG+QpkSeyGM+6yxnlAwn onDDCnUUDnKSRZFBEbQyOoBkL2yG7782n9i/GtNLujphIuH25l7JxERXAT4f3GCAspMi GLRA== 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=sWT8hHA0J1/DRfLdZMqQFZn9XdBk5XJR2o5PvOkyYWI=; b=UOXPNps1QblYGv9FtQBi5clQp3VIlUoN16N46X8F7gTQvIbj1Ls/JJd8Y3TqMlmuKl YOdTXCG0ECtJyfYkpH3NIkJrgmrMyKddZiek7Y/UVxuao8RvCKun32pDlv34/1bes6yb cR+d+9l4IfdIt5QWeTaNYHLroELmRZ9lmGxjezvL4J8bFB6y4cePwdzIFK1d5h5gwgIg AzVcDuNxTQLsXm6jmduS27dtkvtklLPNDiwJEhuJpsY2n1dJ0VBrFawtA8LKpzKvXPD4 IKdFMGUfygrcOCYmvj5esfgsgozYf2UyCvufpxKNL4TpvIpbu5WR/mOrUB5qPDxgTgB9 x6mA== X-Gm-Message-State: ANhLgQ1/OytjetYg6RM0qpq6we/SMqSE4NylSHccEXiqM5sAnkFNaqxa ler6DSX2jbMwmbHfUDI2uI+KFzrx1RQvEYfF4/w= X-Google-Smtp-Source: ADFU+vvzBoFqUp8zAZzbfk6CA9lZuMN2yQCs28jhGYiQwVrMv1ciFOff7NNNcBqr4TT410kfCU8xk+qWkKZCJmoHa4U= X-Received: by 2002:a2e:9dc8:: with SMTP id x8mr9039450ljj.212.1584811330148; Sat, 21 Mar 2020 10:22:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 21 Mar 2020 10:21:44 -0700 Message-ID: To: Vijay IETF Cc: David Skaife , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="0000000000005e9bfe05a160a479" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:22:14 -0000 --0000000000005e9bfe05a160a479 Content-Type: text/plain; charset="UTF-8" Hi Vijay Thanks for asking for clarification. If there is no default or minimum to implement (MTI) requirement, then for interop to be guaranteed between a client and an AS, one of the parties will need to support all of the choices since the other party could choose to support only one of the choices. In this work, we have tended to push complexity to the AS, so the AS would need to implement all choices to be compliant. If there is a default, then only the default MUST be implemented by both parties to be compliant. Of course, any bespoke implementation can do whatever they want. While you may not personally be a fan of general purpose software, others are, and as a group we need to anticipate the implications for all implementors. On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF wrote: > Hi Dick, > > Thanks for the additional context for reasoning. My response inline. > > On Sat, 21 Mar 2020 at 06:00, Dick Hardt wrote: > >> >> > If all choices are equal (no default), then ALL the choices have to be >> implemented in a general purpose implementation, which increases the attack >> surface and vulnerability of an implementation, ie a coding error. >> >> > I do not see how having a no default implies all choices being equal. I > am missing the nuance here. > > The +1 for xyz rationale was to favor implementations that have the > freedom to implement what they see fit and still be "compliant" with the > protocol. I am not a fan of bloated general purpose software > implementations, so I don't have much to comment on that. Sorry. > > --- > Vijay > --0000000000005e9bfe05a160a479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vijay

Thanks for asking for clarific= ation.=C2=A0

If there is no default or minimum to = implement (MTI) requirement, then for interop to be guaranteed between a cl= ient and an AS, one of the parties will need to support all of the choices = since the other party could choose to support only one of the choices. In t= his work, we have tended to push complexity to the AS, so the AS would need= to implement all choices to be compliant.=C2=A0

I= f there is a default, then only the default MUST be implemented by both par= ties to be compliant.

Of course, any bespoke imple= mentation can do whatever they want.=C2=A0

While y= ou may not personally be a fan of general purpose software, others are, and= as a group we need to anticipate the implications for all implementors.






On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF <vijay.ietf@gmail.com> wrote:
= Hi Dick,

Thanks for the additional context for rea= soning. My response inline.

On Sat, 21 Mar 2020 at 06:00, Dick Hardt <= ;dick.hardt@gmail= .com> wrote:
<snip>
If all choices are equal (no defa= ult), then ALL the choices have to be implemented in a general purpose impl= ementation, which increases the attack surface and vulnerability of an impl= ementation, ie a coding error.

=
I do not see how having a no default=C2=A0 implies all choic= es being equal. I am missing the nuance here.

The +1 for xyz rationale was to favor implementations that have the freed= om to implement what they see fit and still be "compliant" with t= he protocol. I am not a fan of bloated general purpose software implementat= ions, so I don't have much to comment on that. Sorry.
=C2= =A0
---
Vijay
--0000000000005e9bfe05a160a479-- From nobody Sat Mar 21 10:43:51 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401AB3A07CC for ; Sat, 21 Mar 2020 10:43:48 -0700 (PDT) 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, 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 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 vJ7rSU0gnNeK for ; Sat, 21 Mar 2020 10:43:45 -0700 (PDT) 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 509B03A07C2 for ; Sat, 21 Mar 2020 10:43:43 -0700 (PDT) Received: from [192.168.1.5] (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 02LHheFQ025386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 13:43:41 -0400 From: Justin Richer Message-Id: <79DD451B-B1AD-426D-BF4B-535AE6235A90@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F155A994-DAB4-4222-9357-8A33B7395EAA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Mar 2020 13:43:40 -0400 In-Reply-To: Cc: txauth@ietf.org, Yaron Sheffer To: Dick Hardt References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:43:49 -0000 --Apple-Mail=_F155A994-DAB4-4222-9357-8A33B7395EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As you can see in the email you replied to, that is not even close to = what I said. I believe it is a transaction, and therefore, I do not = agree that it=E2=80=99s not a transaction. But if we take =E2=80=9CTransactional=E2=80=9D out of the WG title, I = won=E2=80=99t be offended. If we just call it =E2=80=9CTxAuth=E2=80=9D = without expansion, then that=E2=80=99s fine. I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAuth"= was floated during naming the list, but rejected because (among other = reasons) it would likely be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D= or something. TxAuth reads as =E2=80=9CTee - ex - oth=E2=80=9D more = naturally, which was the intent.=20 So how about we take a page from the OAuth working group and name it: TxAuth - Next Generation Web Authorization Protocol Working = Group =E2=80=94 Justin > On Mar 21, 2020, at 1:15 PM, Dick Hardt wrote: >=20 > To clarify -- you agree it is not a transaction, and we will take the = word transaction out of the WG title? >=20 > On Fri, Mar 20, 2020 at 5:53 PM Justin Richer > wrote: > Dick, thanks for pulling the definitions up: >=20 > > a communicative action or activity involving two parties or things = that reciprocally affect or influence each other >=20 > This is the kind of thing that I had in mind. The client and the AS = are in a conversation over time that each one contributes to and each = changes.=20 >=20 > Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D= doesn=E2=80=99t stand for =E2=80=9CTransactional Auth=E2=80=9D much the = same way we decided that the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D= doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore.=20 >=20 > None of the arguments below in favor of XAuth have made me like that = name better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, = then why come up with something new? >=20 > =E2=80=94 Justin >=20 >> On Mar 20, 2020, at 3:32 PM, Dick Hardt > wrote: >>=20 >>=20 >>=20 >>=20 >> not a transaction - there are multiple transactions >>=20 >> backchannel innovation is combination of here is who I am, and here = is what I want to do >>=20 >>=20 >> childhood trauma therapy group >>=20 >>=20 >>=20 >> On Mon, Mar 16, 2020 at 6:56 PM Justin Richer > wrote: >> Yes, naming things is hard =E2=80=94 but I still believe in the name = TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of = getting an authorization delegated to the client software as a = multi-step, multi-party transaction is, I believe, the key insight = that=E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. = It=E2=80=99s not just about going to the AS first =E2=80=94 we had that = in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I = really think it=E2=80=99s about the transaction at the core.=20 >>=20 >> OAuth 2.0 had multi-step, multi-party. TxAuth extends that. >>=20 >> I think the big shift is going to the AS. This enables the request to = be richer with JSON, instead of name/value pairs parameters in a URI. It = allows the client and AS to negotiate, and to short circuit having to = redirect the user to the AS. PAR does some of this, but it is = constrained by having to do it in the OAuth 2.0 context. >>=20 >> My concern is that the protocol is MUCH MORE than a transaction. = While the initial interaction between client, AS, user and RO is a = transaction. The protocol also covers the client and RS interactions. = The access token refreshes. Access token revocation. Access token = introspection. As described in the charter, there is a whole lifecycle, = that consists of multiple transactions. >>=20 >> =46rom https://www.merriam-webster.com/dictionary/transaction = : >>=20 >> Definition of transaction >> 1a: something transacted = >> especially : an exchange or transfer = of goods, = services, or funds >> electronic transactions >> b: transactions plural : the often published record of the meeting of = a society or association >> 2a: an act, process, or instance of transacting = >> b: a communicative action or activity involving two parties or things = that reciprocally affect or influence each other >>=20 >> Calling the protocol a transaction will confusing to people. >> =20 >>=20 >> Having come of age in the 1990=E2=80=99s, I have particular dislike = for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2= =80=9D, and if you read either of those with a growling yell in your = head then you know exactly what I=E2=80=99m talking about. >>=20 >> In case you are confused, this is not a childhood trauma support = group. :) >>=20 >> Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a = placeholder. X-Men, Xbox, X-Factor, X-files.=20 >>=20 >> = https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 = = >>=20 >> = https://english.stackexchange.com/questions/358181/whats-the-purpose-of-us= ing-letter-x-or-x-as-a-suffix-in-brand-names = >>=20 >> =20 >> And to Dick=E2=80=99s rationale for the name below, I absolutely do = NOT see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. = I think that does a disservice to the kind of change we have an = opportunity to make here.=20 >>=20 >> =46rom the charter=20 >>=20 >> "It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0)" >>=20 >> Which sounds pretty similar to =E2=80=9COAuth with all the extra = features=E2=80=9D >>=20 >> While I think XAuth captures what we are doing, a placeholder name = would be preferable to an incorrect descriptive name such as TxAuth. >>=20 >> For example, XYZ is a good placeholder name. Or XYZAuth. Let's not = mislead people. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 16, 2020, at 7:04 PM, Dick Hardt > wrote: >>>=20 >>> Hello everyone >>>=20 >>> I prompted a thread around the name of the protocol a while back: >>>=20 >>> = https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ = >>>=20 >>> As Justin stated "naming is hard" >>>=20 >>> Wearing my marketing hat I want to ensure that the name will be = perceived properly in the broader community. >>>=20 >>> A recent example that comes to mind are the privacy related works on = the browser storage API. Given that name, one would think that it is = local storage. It is actually about browser cookies. >>>=20 >>> Justin discussed his reasons for TxAuth in the thread above (and I'm = sure in other places) >>>=20 >>> I chose XAuth in my draft to reflect the eXtensibility goal that we = have over OAuth -- and XAuth is OAuth but with an X to reflect all the = extra features. =3D) >>>=20 >>> Other suggestions? >>>=20 >>> This will be an agenda item in the BoF -- but the name will NOT be = an open discussion item -- we will summarize what has been discussed on = the list and perhaps do a poll of options presented unless consensus is = obvious from this thread. >>>=20 >>> /Dick >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> =E1=90=A7 >>=20 >=20 --Apple-Mail=_F155A994-DAB4-4222-9357-8A33B7395EAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = you can see in the email you replied to, that is not even close to what = I said. I believe it is a transaction, and therefore, I do not agree = that it=E2=80=99s not a transaction.

But if we take =E2=80=9CTransactional=E2=80= =9D out of the WG title, I won=E2=80=99t be offended. If we just call it = =E2=80=9CTxAuth=E2=80=9D without expansion, then that=E2=80=99s = fine.

I do not = like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAuth" was = floated during naming the list, but rejected because (among other = reasons) it would likely be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D= or something. TxAuth reads as =E2=80=9CTee - ex - oth=E2=80=9D more = naturally, which was the intent. 

So how about we take a page from the = OAuth working group and name it:

TxAuth - Next Generation Web = Authorization Protocol Working Group


 =E2=80=94 Justin

On Mar = 21, 2020, at 1:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

To clarify -- you agree it is not = a transaction, and we will take the word transaction out of the WG = title?

On Fri, Mar 20, 2020 at 5:53 PM Justin = Richer <jricher@mit.edu> wrote:
Dick, thanks for pulling the definitions up:

> a communicative action or activity involving two parties or = things that reciprocally affect or influence each other

This is the kind of = thing that I had in mind. The client and the AS are in a conversation = over time that each one contributes to and each changes. 

Also =E2=80=94 we can = just as easily decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t = stand for =E2=80=9CTransactional Auth=E2=80=9D much the same way we = decided that the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D = doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D = anymore. 

None of the arguments below in favor of XAuth have made me = like that name better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D= name, then why come up with something new?

 =E2=80=94 Justin

On Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:




not a transaction - there are multiple = transactions

backchannel innovation is combination of here is who I = am, and here is what I want to do


childhood trauma therapy group



On Mon, Mar 16, 2020 at 6:56 PM Justin Richer = <jricher@mit.edu> wrote:
Yes, naming = things is hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80=99= re moving beyond OAuth, and taking the process of getting an = authorization delegated to the client software as a multi-step, = multi-party transaction is, I believe, the key insight that=E2=80=99s = letting us move beyond OAuth=E2=80=99s limitations here. It=E2=80=99s = not just about going to the AS first =E2=80=94 we had that in OAuth 1 = and we=E2=80=99re patching that into OAuth 2 with PAR. I really think = it=E2=80=99s about the transaction at the = core. 

OAuth 2.0 had multi-step, multi-party. TxAuth extends = that.

I think = the big shift is going to the AS. This enables the request to be richer = with JSON, instead of name/value pairs parameters in a URI. It allows = the client and AS to negotiate, and to short circuit having to redirect = the user to the AS. PAR does some of this, but it is constrained by = having to do it in the OAuth 2.0 context.

My concern is that the protocol is MUCH = MORE than a transaction. While the initial interaction between client, = AS, user and RO is a transaction. The protocol also covers the = client and RS interactions. The access token refreshes. Access = token revocation. Access token introspection. As described in the = charter, there is a whole lifecycle, that consists of multiple = transactions.

From https://www.merriam-webster.com/dictionary/transaction:

Definition = of transaction

1a: something transactedespecially : an exchange or transfer of goods, services, or = fundselectronic transactions
b: transactions plural : the often published record of the meeting = of a society or association
2a: an act, process, or instance of transacting
b: a communicative action or activity = involving two parties or things that reciprocally affect or influence = each other
Calling the protocol a transaction = will confusing to people.
 

Having come of age in = the 1990=E2=80=99s, I have particular dislike for XAuth. It sounds too = =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you = read either of those with a growling yell in your head then you know = exactly what I=E2=80=99m talking about.

In case you are = confused, this is not a childhood trauma support group.  = :)

Unlike = "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. X-Men, = Xbox, X-Factor, X-files. 

https://www.businessinsider.com/the-indisputable-power-of-brand= -x-2012-4

https://english.stackexchange.com/questions/358181/whats-the-pu= rpose-of-using-letter-x-or-x-as-a-suffix-in-brand-names

 
= And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I = think that does a disservice to the kind of change we have an = opportunity to make here. 

=46rom the = charter 

"It will expand upon the uses = cases currently supported by OAuth 2.0 and OpenID Connect (itself an = extension of OAuth 2.0)"

Which sounds pretty similar to =E2=80=9COAuth with all = the extra features=E2=80=9D

While I think XAuth captures what we are doing, a = placeholder name would be preferable to an incorrect descriptive name = such as TxAuth.

For example, XYZ is a good placeholder name. Or XYZAuth. = Let's not mislead people.

 

 =E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello everyone

I prompted a thread = around the name of the protocol a while back:

https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDX= OrTr_s_wc/

As Justin stated "naming is = hard"

Wearing = my marketing hat I want to ensure that the name will be = perceived properly in the broader community.
A recent example that comes to mind = are the privacy related works on the browser storage API. Given that = name, one would think that it is local storage. It is actually about = browser cookies.

Justin discussed his reasons for TxAuth in the thread above = (and I'm sure in other places)

I chose XAuth in my draft to reflect = the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but = with an X to reflect all the extra features. =3D)
Other suggestions?

This will be an agenda = item in the BoF -- but the name will NOT be an open discussion item -- = we will summarize what has been discussed on the list and perhaps = do a poll of options presented unless consensus is obvious from this = thread.

/Dick





3D""=E1=90=A7



= --Apple-Mail=_F155A994-DAB4-4222-9357-8A33B7395EAA-- From nobody Sat Mar 21 10:59:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D443E3A081F for ; Sat, 21 Mar 2020 10:58:59 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 jKRBOeKdoCa6 for ; Sat, 21 Mar 2020 10:58:54 -0700 (PDT) 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 5EE703A081B for ; Sat, 21 Mar 2020 10:58:52 -0700 (PDT) Received: from [192.168.1.5] (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 02LHwPRa028774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 13:58:50 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_07A36ED1-A992-499B-98CA-0A45BC9E4701" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Mar 2020 13:58:50 -0400 In-Reply-To: Cc: Vijay IETF , David Skaife , txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 17:59:01 -0000 --Apple-Mail=_07A36ED1-A992-499B-98CA-0A45BC9E4701 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dick, I think there=E2=80=99s a big difference between a =E2=80=9Cdefault=E2=80=9D= and =E2=80=9CMTI=E2=80=9D. If you mean that the protocol chooses one = key proofing method as =E2=80=9CMTI=E2=80=9D for the AS, then I can = maybe get behind that idea. I think the realm of MTI is something that = we do need to decide as a group, but that goes for all of the various = features and options in the protocol. I think OAuth 2 went too far into = the =E2=80=9Ceverything=E2=80=99s optional=E2=80=9D world, but at the = same time, we don=E2=80=99t want to go too far into the OAuth 1 world of = =E2=80=9Cthis is all mandatory because of one tiny use case=E2=80=9D.=20 Also, an observation - if we mandate discovery as you=E2=80=99ve = proposed in XAuth, then doesn=E2=80=99t the argument for any MTI fall a = little flat? Since a client can discover which methods are available, a = smarter client can discover and configure itself based on that set of = options.=20 I contend that that clients, even general purpose ones, aren=E2=80=99t = going to be very smart in that regard. I think it=E2=80=99s vanishingly = rare for a piece of client software in the OAuth 2 world to call the = discovery document and change which authentication method it=E2=80=99s = going to use. Instead, this tends to be driven by the developer who=E2=80=99= s configured the client software library to behave in a specific way. I = think we=E2=80=99ll continue to see that pattern here with TxAuth, = especially as things go to embedded systems that get hardcoded to work = in one specific way. =E2=80=94 Justin > On Mar 21, 2020, at 1:21 PM, Dick Hardt wrote: >=20 > Hi Vijay >=20 > Thanks for asking for clarification.=20 >=20 > If there is no default or minimum to implement (MTI) requirement, then = for interop to be guaranteed between a client and an AS, one of the = parties will need to support all of the choices since the other party = could choose to support only one of the choices. In this work, we have = tended to push complexity to the AS, so the AS would need to implement = all choices to be compliant.=20 >=20 > If there is a default, then only the default MUST be implemented by = both parties to be compliant. >=20 > Of course, any bespoke implementation can do whatever they want.=20 >=20 > While you may not personally be a fan of general purpose software, = others are, and as a group we need to anticipate the implications for = all implementors. >=20 >=20 >=20 >=20 >=20 >=20 > On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF > wrote: > Hi Dick, >=20 > Thanks for the additional context for reasoning. My response inline. >=20 > On Sat, 21 Mar 2020 at 06:00, Dick Hardt > wrote: > =20 > If all choices are equal (no default), then ALL the choices have to be = implemented in a general purpose implementation, which increases the = attack surface and vulnerability of an implementation, ie a coding = error. >=20 >=20 > I do not see how having a no default implies all choices being equal. = I am missing the nuance here.=20 >=20 > The +1 for xyz rationale was to favor implementations that have the = freedom to implement what they see fit and still be "compliant" with the = protocol. I am not a fan of bloated general purpose software = implementations, so I don't have much to comment on that. Sorry. > =20 > --- > Vijay --Apple-Mail=_07A36ED1-A992-499B-98CA-0A45BC9E4701 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dick,

I = think there=E2=80=99s a big difference between a =E2=80=9Cdefault=E2=80=9D= and =E2=80=9CMTI=E2=80=9D. If you mean that the protocol chooses one = key proofing method as =E2=80=9CMTI=E2=80=9D for the AS, then I can = maybe get behind that idea. I think the realm of MTI is something that = we do need to decide as a group, but that goes for all of the various = features and options in the protocol. I think OAuth 2 went too far into = the =E2=80=9Ceverything=E2=80=99s optional=E2=80=9D world, but at the = same time, we don=E2=80=99t want to go too far into the OAuth 1 world of = =E2=80=9Cthis is all mandatory because of one tiny use = case=E2=80=9D. 

Also, an observation - if we mandate discovery as you=E2=80=99v= e proposed in XAuth, then doesn=E2=80=99t the argument for any MTI fall = a little flat? Since a client can discover which methods are available, = a smarter client can discover and configure itself based on that set of = options. 

I= contend that that clients, even general purpose ones, aren=E2=80=99t = going to be very smart in that regard. I think it=E2=80=99s vanishingly = rare for a piece of client software in the OAuth 2 world to call the = discovery document and change which authentication method it=E2=80=99s = going to use. Instead, this tends to be driven by the developer who=E2=80=99= s configured the client software library to behave in a specific way. I = think we=E2=80=99ll continue to see that pattern here with TxAuth, = especially as things go to embedded systems that get hardcoded to work = in one specific way.

 =E2=80=94 Justin



On Mar = 21, 2020, at 1:21 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hi Vijay

Thanks for asking for = clarification. 

If there is no default or minimum to implement (MTI) = requirement, then for interop to be guaranteed between a client and an = AS, one of the parties will need to support all of the choices since the = other party could choose to support only one of the choices. In this = work, we have tended to push complexity to the AS, so the AS would need = to implement all choices to be compliant. 

If there is a default, then only the = default MUST be implemented by both parties to be compliant.

Of course, any bespoke = implementation can do whatever they want. 

While you may not personally be a fan = of general purpose software, others are, and as a group we need to = anticipate the implications for all implementors.



On Sat, Mar 21, 2020 at 1:29 AM Vijay = IETF <vijay.ietf@gmail.com> wrote:
Hi Dick,

Thanks for the additional context for reasoning. My response = inline.

On Sat, 21 Mar 2020 at 06:00, Dick = Hardt <dick.hardt@gmail.com> wrote:
<snip>
If all choices are equal (no default), then ALL the choices = have to be implemented in a general purpose implementation, which = increases the attack surface and vulnerability of an implementation, ie = a coding error.


I do not see how having a no = default  implies all choices being equal. I am missing the nuance = here.

The +1 for xyz rationale was to favor implementations that = have the freedom to implement what they see fit and still be "compliant" = with the protocol. I am not a fan of bloated general purpose software = implementations, so I don't have much to comment on that. Sorry.
 
---
Vijay

= --Apple-Mail=_07A36ED1-A992-499B-98CA-0A45BC9E4701-- From nobody Sat Mar 21 11:03:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF64A3A0839 for ; Sat, 21 Mar 2020 11:03:16 -0700 (PDT) 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 EAIy_LExJ4Nn for ; Sat, 21 Mar 2020 11:03:14 -0700 (PDT) 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 8745A3A0838 for ; Sat, 21 Mar 2020 11:03:14 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id o16so6418917ilm.2 for ; Sat, 21 Mar 2020 11:03:14 -0700 (PDT) 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=t9vYbNJDS9kJ+Pxiykr5vZGMj5LhYr5MtjhWMUTaUeI=; b=bn9PJWYSCwfhNAaXrixUZKx5NHAMfr7ApNDJR8d19r5RYZtTbH9L+Y4AQtfykeprkf x6NjzwQ4008dnhyJ+MQjUrRG6SaSYVmTS0eRI/drMaWodm+RVpxhZ/IUcK29QGRnqecT 67M8QMK2Q88llehM+OwrndqRLW3aBjD0Ahi8deXB/UlOVPKGxmTipcbFit99F2vpulZF GuHd3F4/yccTTxqF0tG7vvWpMC4yivbxB8SR0CITas22rP54PSwu9mgcTsHH9pJX0Wst y5+M3e9OO5XkqRgAK6whxjfnE7VpErr/t5eOQ5wh73hOXbGACWb1kPg2qzaN4ruXAKBu YDLw== 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=t9vYbNJDS9kJ+Pxiykr5vZGMj5LhYr5MtjhWMUTaUeI=; b=s36Mqk5hA797w/da0RcBThc115HggPkEN/TEWAe3N5O1/AANF1RexRVCLAqTb81W8g 8eoB3zbMDnwenUCSmg3wyjriBUti/3PGJvZuuFwWRhONZ63k3ZWBfSEQsUrN0OdjJgLs kQOPVBW/Jr4JKCTmaGAPwpCYZLqguYk/ePO2WP1Wdh2H6s4vdIjHJwVhttgj8Ks3QbDy 5xm3fpSYYWRsqfe1cjvZylURGUoqpWmWdT5IXnvPLECF2KNonX/6QE48Bgna533Y7nyv ZZ67nrzsiHf7m5r6hsSGFL/4RklVBs6SSZTMx2VvD8yDLGWalBvCoPFpVPd7WotczRMO +SMg== X-Gm-Message-State: ANhLgQ2BKAFOPLE/TZ7R8hjqquuaedLdMzR567j4uzQJWgMlj95zxNx/ 40irQ94NT71awnlMvKZuVbVe1+NDtnH8KtFRKL8= X-Google-Smtp-Source: ADFU+vv0ILcRnoorfMCp69P/Ui9KbvHUGcA7yDk42lLjPI+btTjdSnLjAtZqjKAqP9Lr/IUcSWwLHcbJfA2tWuUvQgo= X-Received: by 2002:a92:3c57:: with SMTP id j84mr14357707ila.265.1584813793869; Sat, 21 Mar 2020 11:03:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay IETF Date: Sat, 21 Mar 2020 23:33:02 +0530 Message-ID: To: Dick Hardt Cc: David Skaife , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="0000000000003802c505a161372e" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:03:18 -0000 --0000000000003802c505a161372e Content-Type: text/plain; charset="UTF-8" Hi Dick, Thanks. I think I understand the concern now. Response inline. On Sat, 21 Mar 2020 at 22:52, Dick Hardt wrote: > Hi Vijay > > > > If there is no default or minimum to implement (MTI) requirement, then for > interop to be guaranteed between a client and an AS, one of the parties > will need to support all of the choices since the other party could choose > to support only one of the choices. In this work, we have tended to push > complexity to the AS, so the AS would need to implement all choices to be > compliant. > > If there is a default, then only the default MUST be implemented by both > parties to be compliant. > I get it. IMHO, your concern if it were to be the case is a lazy/inefficient way to handle/attain interop compliance. I believe there is another way. We could take inspiration from [Bluetooth Profiles]( https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles). Each profile could then specify the defaults that client and AS need to agree on. > > Of course, any bespoke implementation can do whatever they want. > > While you may not personally be a fan of general purpose software, others > are, and as a group we need to anticipate the implications for all > implementors. > > > I hear you. I just didn't have any better way to state my bias towards XYZ's rationale in this instance. And I don't agree with a "global" default being the normative recommendation. --- Vijay --0000000000003802c505a161372e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

Th= anks. I think I understand the concern now. Response inline.

On Sa= t, 21 Mar 2020 at 22:52, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Vijay

<s= nip>

If there is no default or minimum to imple= ment (MTI) requirement, then for interop to be guaranteed between a client = and an AS, one of the parties will need to support all of the choices since= the other party could choose to support only one of the choices. In this w= ork, we have tended to push complexity to the AS, so the AS would need to i= mplement all choices to be compliant.=C2=A0

If the= re is a default, then only the default MUST be implemented by both parties = to be compliant.

I get it.
=

IMHO, your concern if it were to be the case is a= lazy/inefficient way to handle/attain interop compliance. I believe there = is another way. We could take inspiration from [Bluetooth Profiles](https://en.wi= kipedia.org/wiki/List_of_Bluetooth_profiles). Each profile could then s= pecify the defaults that client and AS need to agree on.=C2=A0
= =C2=A0

Of course, any bespoke implementation can do whatev= er they want.=C2=A0

While you may not personally b= e a fan of general purpose software, others are, and as a group we need to = anticipate the implications for all implementors.

=

I hear you. I just didn= 9;t have any better way to state my bias towards XYZ's rationale in thi= s instance. And I don't agree with a "global" default being t= he normative recommendation.

---
Vijay
--0000000000003802c505a161372e-- From nobody Sat Mar 21 11:08:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1013A0846 for ; Sat, 21 Mar 2020 11:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_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=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 WnxCDSNVumge for ; Sat, 21 Mar 2020 11:08:28 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450: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 9C4A23A0832 for ; Sat, 21 Mar 2020 11:08:27 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id e5so1189283edq.5 for ; Sat, 21 Mar 2020 11:08:27 -0700 (PDT) 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=ueYwg5Q5luhbbNbZUZT2hFpteU6hllYmyncUr7yGAkM=; b=r3lOCRdIH9PT7PBDe333RqvzijQvXnQztpNsqqZckmj9llZCHmAQzjn9aZ8pFC2L3z wks5VTktC7+fX2o+vML9+Hhvt5cvHBb0VV6TOuV8dqVwHrjkN0iwZlMgavSoUJ3eTulg G1egP7e+XM937G6Ko9TNsCNm0asFlx5TV5uGk1KSGstjCyxgQ8FiRTwlrzvLVxCre7aD 0Rs26LfzBPzGRdYrStn2/s2GZDOvHtbl0qOL4uYnIiwjWUYD3CUzBSNYi4bh+Xy+y+O5 gojZlxSudGy+v0QDRv3mY26YBTbufiySRznI/AotBcwdPeHBxicjSdjgmE7dHmJ5oAEW Fg7g== 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=ueYwg5Q5luhbbNbZUZT2hFpteU6hllYmyncUr7yGAkM=; b=s1t9MfJOjN4f9BS7p4fckj0lloG5ReUiovO473pYj8UOzOJElStHtRdQGamjezQ/zd 0ACqEUMyovEavNdG2Hybj4vhisBLPixRONbqmZbTCZ7JfIWK9AFKHuU304qkEGtCQMWZ FDkFcK/Q29jpqU+tE3IiKkdI1Loqo7eCyAhgrPxIwkCEK1PCmg8Dt0svZrDIV1HVlZjJ 5CZzDLkC+9bubjT6+tGCNbUBNWZzWVrMFwnizsFKWoidQ0FxJZK19B+xxRVoPrg0qIol 4qYSwYJfynNDWZCj6Ma/S0HZY6jisIwSH0gLAgIsjBiigvoxNCG5xHTTeXwtrKXzpi2H sLZA== X-Gm-Message-State: ANhLgQ2hhp+jWhTzaA62lNJRmL3qVJvSawhWMFnBHQXe5xsqcav4gy2Q XEDXkYiiarbcsMKWMgoTnijPFt3tNI0M/QABqO8= X-Google-Smtp-Source: ADFU+vuL9Ly2s6tmY+UOrouybyzTLiOKtXEXNr43hJCGe28gajyqNhZy3OdYmDYUsUjlmZ6Aa8vhGLaCZH+aPqwvOqw= X-Received: by 2002:a50:c043:: with SMTP id u3mr14115149edd.253.1584814106187; Sat, 21 Mar 2020 11:08:26 -0700 (PDT) MIME-Version: 1.0 References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> <79DD451B-B1AD-426D-BF4B-535AE6235A90@mit.edu> In-Reply-To: <79DD451B-B1AD-426D-BF4B-535AE6235A90@mit.edu> From: David Skaife Date: Sat, 21 Mar 2020 18:08:16 +0000 Message-ID: To: Justin Richer Cc: Dick Hardt , Yaron Sheffer , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d59a2605a1614969" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:08:33 -0000 --000000000000d59a2605a1614969 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to throw in another suggestion, to address Yaron's point about some people mistakenly thinking that "Auth" stands for authentication rather than authorization, how about naming the working group *AuthZ* Nice and simple, and it makes it clear what the group is focused on. I think the name of the actual protocol that we produce is far, far more important that the name of the working group - and the name of that protocol doesn't need to correlate to the WG name. Also, we have much more time before we need to decide on the name of that protocol, even if the initial draft documents that we produce end up using a placeholder name. On Sat, Mar 21, 2020 at 5:44 PM Justin Richer wrote: > As you can see in the email you replied to, that is not even close to wha= t > I said. I believe it is a transaction, and therefore, I do not agree that > it=E2=80=99s not a transaction. > > But if we take =E2=80=9CTransactional=E2=80=9D out of the WG title, I won= =E2=80=99t be offended. > If we just call it =E2=80=9CTxAuth=E2=80=9D without expansion, then that= =E2=80=99s fine. > > I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAuth= " was floated during > naming the list, but rejected because (among other reasons) it would like= ly > be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D or something. TxAuth r= eads as =E2=80=9CTee - ex > - oth=E2=80=9D more naturally, which was the intent. > > So how about we take a page from the OAuth working group and name it: > > TxAuth - Next Generation Web Authorization Protocol Working Group > > > =E2=80=94 Justin > > On Mar 21, 2020, at 1:15 PM, Dick Hardt wrote: > > To clarify -- you agree it is not a transaction, and we will take the wor= d > transaction out of the WG title? > > On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: > >> Dick, thanks for pulling the definitions up: >> >> > a communicative action or activity involving two parties or things >> that reciprocally affect or influence each other >> >> This is the kind of thing that I had in mind. The client and the AS are >> in a conversation over time that each one contributes to and each change= s. >> >> Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80= =9D doesn=E2=80=99t stand for >> =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that t= he =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D >> doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. >> >> None of the arguments below in favor of XAuth have made me like that nam= e >> better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then = why come up with something >> new? >> >> =E2=80=94 Justin >> >> On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: >> >> >> >> >> not a transaction - there are multiple transactions >> >> backchannel innovation is combination of here is who I am, and here is >> what I want to do >> >> >> childhood trauma therapy group >> >> >> >> On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: >> >>> Yes, naming things is hard =E2=80=94 but I still believe in the name Tx= Auth. >>> We=E2=80=99re moving beyond OAuth, and taking the process of getting an >>> authorization delegated to the client software as a multi-step, multi-p= arty >>> transaction is, I believe, the key insight that=E2=80=99s letting us mo= ve beyond >>> OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to = the AS first =E2=80=94 we >>> had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with P= AR. I really >>> think it=E2=80=99s about the transaction at the core. >>> >> >> OAuth 2.0 had multi-step, multi-party. TxAuth extends that. >> >> I think the big shift is going to the AS. This enables the request to be >> richer with JSON, instead of name/value pairs parameters in a URI. It >> allows the client and AS to negotiate, and to short circuit having to >> redirect the user to the AS. PAR does some of this, but it is constraine= d >> by having to do it in the OAuth 2.0 context. >> >> My concern is that the protocol is MUCH MORE than a transaction. While >> the initial interaction between client, AS, user and RO is a transaction= . >> The protocol also covers the client and RS interactions. The access toke= n >> refreshes. Access token revocation. Access token introspection. As >> described in the charter, there is a whole lifecycle, that consists of >> multiple transactions. >> >> From https://www.merriam-webster.com/dictionary/transaction: >> >> Definition of *transaction* >> >> 1a: something transacted >> especially : an >> exchange or transfer >> of goods, >> services, or fundselectronic transactions >> b: transactions plural : the often published record of the meeting of a >> society or association >> 2a: an act, process, or instance of transacting >> >> b: a communicative action or activity involving two parties or things >> that reciprocally affect or influence each other >> >> Calling the protocol a transaction will confusing to people. >> >> >>> >>> Having come of age in the 1990=E2=80=99s, I have particular dislike for= XAuth. >>> It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D,= and if you read either of those >>> with a growling yell in your head then you know exactly what I=E2=80=99= m talking >>> about. >>> >> >> In case you are confused, this is not a childhood trauma support group. >> :) >> >> Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. >> X-Men, Xbox, X-Factor, X-files. >> >> https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 >> >> >> https://english.stackexchange.com/questions/358181/whats-the-purpose-of-= using-letter-x-or-x-as-a-suffix-in-brand-names >> >> >> >>> And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT= see this >>> work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think th= at does a disservice >>> to the kind of change we have an opportunity to make here. >>> >> >> From the charter >> >> "It will expand upon the uses cases currently supported by OAuth 2.0 and >> OpenID Connect (itself an extension of OAuth 2.0)" >> >> >> Which sounds pretty similar to =E2=80=9COAuth with all the extra feature= s=E2=80=9D >> >> While I think XAuth captures what we are doing, a placeholder name would >> be preferable to an incorrect descriptive name such as TxAuth. >> >> For example, XYZ is a good placeholder name. Or XYZAuth. Let's not >> mislead people. >> >> >> >>> >>> =E2=80=94 Justin >>> >>> On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >>> >>> Hello everyone >>> >>> I prompted a thread around the name of the protocol a while back: >>> >>> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_w= c/ >>> >>> As Justin stated "naming is hard" >>> >>> Wearing my marketing hat I want to ensure that the name will be >>> perceived properly in the broader community. >>> >>> A recent example that comes to mind are the privacy related works on th= e >>> browser storage API. Given that name, one would think that it is local >>> storage. It is actually about browser cookies. >>> >>> Justin discussed his reasons for TxAuth in the thread above (and I'm >>> sure in other places) >>> >>> I chose XAuth in my draft to reflect the eXtensibility goal that we hav= e >>> over OAuth -- and XAuth is OAuth but with an X to reflect all the extra >>> features. =3D) >>> >>> Other suggestions? >>> >>> This will be an agenda item in the BoF -- but the name will NOT be an >>> open discussion item -- we will summarize what has been discussed on th= e >>> list and perhaps do a poll of options presented unless consensus is obv= ious >>> from this thread. >>> >>> /Dick >>> >>> >>> >>> >>> >>> =E1=90=A7 >>> >>> >>> >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d59a2605a1614969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to throw in another suggestion, to address Yaron'= s point about some people mistakenly thinking that "Auth" stands = for authentication rather than authorization, how about naming the working = group AuthZ
Nice and simple, and it makes it clear what the grou= p is focused on.

I think the name of the actual protocol that we pro= duce is far, far more important that the name of the working group - and th= e name of that protocol doesn't need to correlate to the WG name. Also,= we have much more time before we need to decide on the name of that protoc= ol, even if the initial=C2=A0draft documents that we produce end up using a= placeholder name.

On Sat, Mar 21, 2020 at 5:44 PM 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:1px solid rgb(204,204,204);padding-left:1ex">
As you can see in the email you replied to, that is not eve= n close to what I said. I believe it is a transaction, and therefore, I do = not agree that it=E2=80=99s not a transaction.

But if we= take =E2=80=9CTransactional=E2=80=9D out of the WG title, I won=E2=80=99t = be offended. If we just call it =E2=80=9CTxAuth=E2=80=9D without expansion,= then that=E2=80=99s fine.

I do not like calling i= t =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAuth" was floated during= naming the list, but rejected because (among other reasons) it would likel= y be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D or something. TxAuth r= eads as =E2=80=9CTee - ex - oth=E2=80=9D more naturally, which was the inte= nt.=C2=A0

So how about we take a page from the OAu= th working group and name it:

TxAuth - Next Generation Web Authorization Protoco= l Working Group


=C2=A0=E2=80= =94 Justin

On Mar 21, 2020, at 1= :15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

To= clarify -- you agree it is not a transaction, and we will take the word tr= ansaction out of the WG title?

On Fri, Mar 20, 2020 at 5:53 PM Justin Ri= cher <jricher@mit.e= du> wrote:
a communica= tive action or activity involving two parties or things that reciprocally a= ffect or influence each other

This is the k= ind of thing that I had in mind. The client and the AS are in a conversatio= n over time that each one contributes to and each changes.=C2=A0
=
Also =E2=80=94 we can just as easily decide that =E2=80=9CTx= Auth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9CTransactional Auth=E2=80= =9D much the same way we decided that the =E2=80=9CO=E2=80=9D in =E2=80=9CO= Auth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore.=C2= =A0

None of the arguments below in favor of XAuth = have made me like that name better. If it=E2=80=99s just a =E2=80=9Cplaceho= lder=E2=80=9D name, then why come up with something new?

=C2=A0=E2=80=94 Justin

On= Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=



not a transaction - there are multiple transactions

= backchannel innovation is combination=C2=A0of here is who I am, and here is= what I want to do


childhood trauma= therapy group



On Mon, Mar 16, 2020 at 6= :56 PM Justin Richer <jricher@mit.edu> wrote:
Yes, naming things is hard =E2=80=94 but I still bel= ieve in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the = process of getting an authorization delegated to the client software as a m= ulti-step, multi-party transaction is, I believe, the key insight that=E2= =80=99s letting us move beyond OAuth=E2=80=99s limitations here. It=E2=80= =99s not just about going to the AS first =E2=80=94 we had that in OAuth 1 = and we=E2=80=99re patching that into OAuth 2 with PAR. I really think it=E2= =80=99s about the transaction at the core.=C2=A0
OAuth 2.0 had multi-step, multi-party. TxAuth extends that.

I think the big shift is going to the AS. This enable= s the request to be richer with JSON, instead of name/value pairs parameter= s in a URI. It allows the client and AS to negotiate, and to short circuit = having to redirect the user to the AS. PAR does=C2=A0some of this, but it i= s constrained by having to do it in the OAuth 2.0 context.

My concern is that the protocol is MUCH MORE than a transaction. W= hile the initial interaction between client, AS, user and RO is a transacti= on. The protocol also covers the client=C2=A0and RS interactions. The acces= s token refreshes. Access token revocation. Access token introspection. As = described in the charter, there is a whole lifecycle, that consists of mult= iple transactions.


<= div style=3D"box-sizing:border-box;padding:0px;border:0px;font-variant-liga= tures:no-common-ligatures;font-variant-numeric:inherit;font-variant-east-as= ian:inherit;font-stretch:inherit;font-size:16px;line-height:inherit;font-fa= mily:Lato,Helvetica,Arial,sans-serif;vertical-align:baseline;display:flex;c= olor:rgb(33,37,41)">

Definition of=C2=A0transaction

<= /p>

= 1a:=C2=A0something=C2=A0transactedespecially=C2=A0:=C2=A0an exch= ange or=C2=A0t= ransfer=C2=A0of goods, services, or fundselectronic=C2=A0transactions
b:=C2=A0transactions=C2=A0plural=C2=A0:=C2=A0the often published record of the meeting of a society or association
2a:=C2=A0an a= ct, process, or instance of=C2=A0transacting
b:=C2=A0a communicative acti= on or activity involving two parties or things that reciprocally affect or = influence each other

<= /div>
Calling the protocol a transaction will confusing to people.
=C2=A0

Having come of age in the 1990=E2=80=99s, I have particul= ar dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9C= X-CITING=E2=80=9D, and if you read either of those with a growling yell in = your head then you know exactly what I=E2=80=99m talking about.
=

In case you are confused, this is not a ch= ildhood=C2=A0trauma support group.=C2=A0 :)

Unlike= "X-TREME" or "X-CITING", XAuth is using the "X&qu= ot; as a placeholder. X-Men, Xbox, X-Factor, X-files.=C2=A0

<= /div>

<= a href=3D"https://english.stackexchange.com/questions/358181/whats-the-purp= ose-of-using-letter-x-or-x-as-a-suffix-in-brand-names" target=3D"_blank">ht= tps://english.stackexchange.com/questions/358181/whats-the-purpose-of-using= -letter-x-or-x-as-a-suffix-in-brand-names

=C2=A0
= And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT see= this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think = that does a disservice to the kind of change we have an opportunity to make= here.=C2=A0

From the charter= =C2=A0

"It will e= xpand upon the uses cases currently supported by OAuth 2.0 and OpenID Conne= ct (itself an extension of OAuth 2.0)"

Which sounds pretty similar to=C2= =A0=E2=80=9COAuth with all the extra features=E2=80=9D

=
While I think XAuth captures what we are doing, a placeholder name wou= ld be preferable to an incorrect descriptive name such as TxAuth.

For example, XYZ is a good placeholder name. Or XYZAuth. Le= t's not mislead people.

=C2=A0

=C2=A0=E2=80=94 J= ustin

On Mar 16, 2020, at 7:04 P= M, Dick Hardt <dick.hardt@gmail.com> wrote:




--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d59a2605a1614969-- From nobody Sat Mar 21 11:18:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58D93A0868 for ; Sat, 21 Mar 2020 11:18:55 -0700 (PDT) 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, 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 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 uDxEYRlLbvfm for ; Sat, 21 Mar 2020 11:18:51 -0700 (PDT) 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 14DFF3A0867 for ; Sat, 21 Mar 2020 11:18:50 -0700 (PDT) Received: from [192.168.1.5] (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 02LIHn1j000618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 14:18:48 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_91FDEDA4-A049-4C48-9A6E-841CE950243F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Mar 2020 14:18:48 -0400 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , txauth@ietf.org To: David Skaife References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> <79DD451B-B1AD-426D-BF4B-535AE6235A90@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:18:57 -0000 --Apple-Mail=_91FDEDA4-A049-4C48-9A6E-841CE950243F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I disagree on the working group name being super important. Nobody knows = that the OAuth WG is actually named =E2=80=9CThe Web Authorization = Protocol Working Group=E2=80=9D, and nobody cares. My proposal is that we name the protocol we work on =E2=80=9CTxAuth=E2=80=9D= (and keep the mailing list), and that we name the working group = something like =E2=80=9CNext Generation Web Authorization Protocol=E2=80=9D= to say what we=E2=80=99re doing. -- Justin > On Mar 21, 2020, at 2:08 PM, David Skaife = wrote: >=20 > Just to throw in another suggestion, to address Yaron's point about = some people mistakenly thinking that "Auth" stands for authentication = rather than authorization, how about naming the working group AuthZ > Nice and simple, and it makes it clear what the group is focused on. >=20 > I think the name of the actual protocol that we produce is far, far = more important that the name of the working group - and the name of that = protocol doesn't need to correlate to the WG name. Also, we have much = more time before we need to decide on the name of that protocol, even if = the initial draft documents that we produce end up using a placeholder = name. >=20 > On Sat, Mar 21, 2020 at 5:44 PM Justin Richer > wrote: > As you can see in the email you replied to, that is not even close to = what I said. I believe it is a transaction, and therefore, I do not = agree that it=E2=80=99s not a transaction. >=20 > But if we take =E2=80=9CTransactional=E2=80=9D out of the WG title, I = won=E2=80=99t be offended. If we just call it =E2=80=9CTxAuth=E2=80=9D = without expansion, then that=E2=80=99s fine. >=20 > I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAut= h" was floated during naming the list, but rejected because (among other = reasons) it would likely be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D= or something. TxAuth reads as =E2=80=9CTee - ex - oth=E2=80=9D more = naturally, which was the intent.=20 >=20 > So how about we take a page from the OAuth working group and name it: >=20 > TxAuth - Next Generation Web Authorization Protocol Working = Group >=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 21, 2020, at 1:15 PM, Dick Hardt > wrote: >>=20 >> To clarify -- you agree it is not a transaction, and we will take the = word transaction out of the WG title? >>=20 >> On Fri, Mar 20, 2020 at 5:53 PM Justin Richer > wrote: >> Dick, thanks for pulling the definitions up: >>=20 >> > a communicative action or activity involving two parties or things = that reciprocally affect or influence each other >>=20 >> This is the kind of thing that I had in mind. The client and the AS = are in a conversation over time that each one contributes to and each = changes.=20 >>=20 >> Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D= doesn=E2=80=99t stand for =E2=80=9CTransactional Auth=E2=80=9D much the = same way we decided that the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D= doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore.=20 >>=20 >> None of the arguments below in favor of XAuth have made me like that = name better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, = then why come up with something new? >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 20, 2020, at 3:32 PM, Dick Hardt > wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>> not a transaction - there are multiple transactions >>>=20 >>> backchannel innovation is combination of here is who I am, and here = is what I want to do >>>=20 >>>=20 >>> childhood trauma therapy group >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 16, 2020 at 6:56 PM Justin Richer > wrote: >>> Yes, naming things is hard =E2=80=94 but I still believe in the name = TxAuth. We=E2=80=99re moving beyond OAuth, and taking the process of = getting an authorization delegated to the client software as a = multi-step, multi-party transaction is, I believe, the key insight = that=E2=80=99s letting us move beyond OAuth=E2=80=99s limitations here. = It=E2=80=99s not just about going to the AS first =E2=80=94 we had that = in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I = really think it=E2=80=99s about the transaction at the core.=20 >>>=20 >>> OAuth 2.0 had multi-step, multi-party. TxAuth extends that. >>>=20 >>> I think the big shift is going to the AS. This enables the request = to be richer with JSON, instead of name/value pairs parameters in a URI. = It allows the client and AS to negotiate, and to short circuit having to = redirect the user to the AS. PAR does some of this, but it is = constrained by having to do it in the OAuth 2.0 context. >>>=20 >>> My concern is that the protocol is MUCH MORE than a transaction. = While the initial interaction between client, AS, user and RO is a = transaction. The protocol also covers the client and RS interactions. = The access token refreshes. Access token revocation. Access token = introspection. As described in the charter, there is a whole lifecycle, = that consists of multiple transactions. >>>=20 >>> =46rom https://www.merriam-webster.com/dictionary/transaction = : >>>=20 >>> Definition of transaction >>> 1a: something transacted = >>> especially : an exchange or transfer = of goods, = services, or funds >>> electronic transactions >>> b: transactions plural : the often published record of the meeting = of a society or association >>> 2a: an act, process, or instance of transacting = >>> b: a communicative action or activity involving two parties or = things that reciprocally affect or influence each other >>>=20 >>> Calling the protocol a transaction will confusing to people. >>> =20 >>>=20 >>> Having come of age in the 1990=E2=80=99s, I have particular dislike = for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2= =80=9D, and if you read either of those with a growling yell in your = head then you know exactly what I=E2=80=99m talking about. >>>=20 >>> In case you are confused, this is not a childhood trauma support = group. :) >>>=20 >>> Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a = placeholder. X-Men, Xbox, X-Factor, X-files.=20 >>>=20 >>> = https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 = = >>>=20 >>> = https://english.stackexchange.com/questions/358181/whats-the-purpose-of-us= ing-letter-x-or-x-as-a-suffix-in-brand-names = >>>=20 >>> =20 >>> And to Dick=E2=80=99s rationale for the name below, I absolutely do = NOT see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. = I think that does a disservice to the kind of change we have an = opportunity to make here.=20 >>>=20 >>> =46rom the charter=20 >>>=20 >>> "It will expand upon the uses cases currently supported by OAuth 2.0 = and OpenID Connect (itself an extension of OAuth 2.0)" >>>=20 >>> Which sounds pretty similar to =E2=80=9COAuth with all the extra = features=E2=80=9D >>>=20 >>> While I think XAuth captures what we are doing, a placeholder name = would be preferable to an incorrect descriptive name such as TxAuth. >>>=20 >>> For example, XYZ is a good placeholder name. Or XYZAuth. Let's not = mislead people. >>>=20 >>> =20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 16, 2020, at 7:04 PM, Dick Hardt > wrote: >>>>=20 >>>> Hello everyone >>>>=20 >>>> I prompted a thread around the name of the protocol a while back: >>>>=20 >>>> = https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ = >>>>=20 >>>> As Justin stated "naming is hard" >>>>=20 >>>> Wearing my marketing hat I want to ensure that the name will be = perceived properly in the broader community. >>>>=20 >>>> A recent example that comes to mind are the privacy related works = on the browser storage API. Given that name, one would think that it is = local storage. It is actually about browser cookies. >>>>=20 >>>> Justin discussed his reasons for TxAuth in the thread above (and = I'm sure in other places) >>>>=20 >>>> I chose XAuth in my draft to reflect the eXtensibility goal that we = have over OAuth -- and XAuth is OAuth but with an X to reflect all the = extra features. =3D) >>>>=20 >>>> Other suggestions? >>>>=20 >>>> This will be an agenda item in the BoF -- but the name will NOT be = an open discussion item -- we will summarize what has been discussed on = the list and perhaps do a poll of options presented unless consensus is = obvious from this thread. >>>>=20 >>>> /Dick >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =E1=90=A7 >>>=20 >>=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_91FDEDA4-A049-4C48-9A6E-841CE950243F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = disagree on the working group name being super important. Nobody knows = that the OAuth WG is actually named =E2=80=9CThe Web Authorization = Protocol Working Group=E2=80=9D, and nobody cares.

My proposal is that we name the = protocol we work on =E2=80=9CTxAuth=E2=80=9D (and keep the mailing = list), and that we name the working group something like =E2=80=9CNext = Generation Web Authorization Protocol=E2=80=9D to say what we=E2=80=99re = doing.

 -- Justin

On Mar 21, 2020, at 2:08 PM, = David Skaife <blue.ringed.octopus.guy@gmail.com> wrote:

Just to throw in another = suggestion, to address Yaron's point about some people mistakenly = thinking that "Auth" stands for authentication rather than = authorization, how about naming the working group AuthZ
Nice and simple, and it makes it = clear what the group is focused on.

I think = the name of the actual protocol that we produce is far, far more = important that the name of the working group - and the name of that = protocol doesn't need to correlate to the WG name. Also, we have much = more time before we need to decide on the name of that protocol, even if = the initial draft documents that we produce end up using a = placeholder name.

On Sat, Mar = 21, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
As you can see in the email you replied to, that = is not even close to what I said. I believe it is a transaction, and = therefore, I do not agree that it=E2=80=99s not a transaction.

But if we take = =E2=80=9CTransactional=E2=80=9D out of the WG title, I won=E2=80=99t be = offended. If we just call it =E2=80=9CTxAuth=E2=80=9D without expansion, = then that=E2=80=99s fine.

I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term = =E2=80=9CTAuth" was floated during naming the list, but rejected because = (among other reasons) it would likely be awkwardly pronounced as = =E2=80=9Ctowth=E2=80=9D or something. TxAuth reads as =E2=80=9CTee - ex = - oth=E2=80=9D more naturally, which was the intent. 

So how about we take a = page from the OAuth working group and name it:

TxAuth - Next Generation Web Authorization = Protocol Working Group


 =E2=80= =94 Justin

On Mar 21, 2020, at 1:15 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

To clarify -- you agree it is not = a transaction, and we will take the word transaction out of the WG = title?

On Fri, Mar 20, 2020 at 5:53 PM Justin = Richer <jricher@mit.edu> wrote:
Dick, thanks = for pulling the definitions up:

> a communicative action or activity involving two parties or = things that reciprocally affect or influence each other

This is the kind of = thing that I had in mind. The client and the AS are in a conversation = over time that each one contributes to and each changes. 

Also =E2=80=94 we can = just as easily decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t = stand for =E2=80=9CTransactional Auth=E2=80=9D much the same way we = decided that the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D = doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D = anymore. 

None of the arguments below in favor of XAuth have made me = like that name better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D= name, then why come up with something new?

 =E2=80=94 Justin

On Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:




not a transaction - there are multiple = transactions

backchannel innovation is combination of here is who I = am, and here is what I want to do


childhood trauma therapy group



On Mon, Mar 16, 2020 at 6:56 PM Justin Richer = <jricher@mit.edu> wrote:
Yes, naming = things is hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80=99= re moving beyond OAuth, and taking the process of getting an = authorization delegated to the client software as a multi-step, = multi-party transaction is, I believe, the key insight that=E2=80=99s = letting us move beyond OAuth=E2=80=99s limitations here. It=E2=80=99s = not just about going to the AS first =E2=80=94 we had that in OAuth 1 = and we=E2=80=99re patching that into OAuth 2 with PAR. I really think = it=E2=80=99s about the transaction at the = core. 

OAuth 2.0 had multi-step, multi-party. TxAuth extends = that.

I think = the big shift is going to the AS. This enables the request to be richer = with JSON, instead of name/value pairs parameters in a URI. It allows = the client and AS to negotiate, and to short circuit having to redirect = the user to the AS. PAR does some of this, but it is constrained by = having to do it in the OAuth 2.0 context.

My concern is that the protocol is MUCH = MORE than a transaction. While the initial interaction between client, = AS, user and RO is a transaction. The protocol also covers the = client and RS interactions. The access token refreshes. Access = token revocation. Access token introspection. As described in the = charter, there is a whole lifecycle, that consists of multiple = transactions.

From https://www.merriam-webster.com/dictionary/transaction:

Definition = of transaction

1a: something transactedespecially : an exchange or transfer of goods, services, or = fundselectronic transactions
b: transactions plural : the often published record of the meeting = of a society or association
2a: an act, process, or instance of transacting
b: a communicative action or activity = involving two parties or things that reciprocally affect or influence = each other
Calling the protocol a transaction = will confusing to people.
 

Having come of age in = the 1990=E2=80=99s, I have particular dislike for XAuth. It sounds too = =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you = read either of those with a growling yell in your head then you know = exactly what I=E2=80=99m talking about.

In case you are = confused, this is not a childhood trauma support group.  = :)

Unlike = "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. X-Men, = Xbox, X-Factor, X-files. 

https://www.businessinsider.com/the-indisputable-power-of-brand= -x-2012-4

https://english.stackexchange.com/questions/358181/whats-the-pu= rpose-of-using-letter-x-or-x-as-a-suffix-in-brand-names

 
= And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I = think that does a disservice to the kind of change we have an = opportunity to make here. 

=46rom the = charter 

"It will expand upon the uses = cases currently supported by OAuth 2.0 and OpenID Connect (itself an = extension of OAuth 2.0)"

Which sounds pretty similar to =E2=80=9COAuth with all = the extra features=E2=80=9D

While I think XAuth captures what we are doing, a = placeholder name would be preferable to an incorrect descriptive name = such as TxAuth.

For example, XYZ is a good placeholder name. Or XYZAuth. = Let's not mislead people.

 

 =E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello everyone

I prompted a thread = around the name of the protocol a while back:

https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDX= OrTr_s_wc/

As Justin stated "naming is = hard"

Wearing = my marketing hat I want to ensure that the name will be = perceived properly in the broader community.
A recent example that comes to mind = are the privacy related works on the browser storage API. Given that = name, one would think that it is local storage. It is actually about = browser cookies.

Justin discussed his reasons for TxAuth in the thread above = (and I'm sure in other places)

I chose XAuth in my draft to reflect = the eXtensibility goal that we have over OAuth -- and XAuth is OAuth but = with an X to reflect all the extra features. =3D)
Other suggestions?

This will be an agenda = item in the BoF -- but the name will NOT be an open discussion item -- = we will summarize what has been discussed on the list and perhaps = do a poll of options presented unless consensus is obvious from this = thread.

/Dick





3D""=E1=90=A7



--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
= --Apple-Mail=_91FDEDA4-A049-4C48-9A6E-841CE950243F-- From nobody Sat Mar 21 11:22:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA913A0874 for ; Sat, 21 Mar 2020 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_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=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 fBgAYKmhOyMz for ; Sat, 21 Mar 2020 11:22:26 -0700 (PDT) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 6F7F33A0870 for ; Sat, 21 Mar 2020 11:22:26 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id a20so11234837edj.2 for ; Sat, 21 Mar 2020 11:22:26 -0700 (PDT) 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=wi4pmIg1YWYGdnTn/7xQQj6B4X9/W5QVYaSnfAciRn8=; b=uZyutPE7A4+UNVYrRtRwnUUpGQ00VUKgUzPRbBtOBFLd8hI6/iaGnO6Ul7hvsYPeht sCNGZ5JXQQo+mHv4okGzAtBL5LOdpmbYHLTRFvlgP52d86TIhcQoG3XZ1ALQIlqxKCFF QDar/zj5owFwM0B5Gqh06h7q5itt8HJqsIInBiXZZdDTYP1osHjScD5VXyGdkzSoiw1n fkWXryDw7DyFLyhuBIBtW6fd4zsykIz8dlQ7QZin/zoEzw3E3IBx0LUV0/RJRoXFX5Ns Se+J+7jkcIJWIciL4biqEwdh6PBgEijmqW1GahYHNUwtekObrvDrMvSMUDn2uuV8c01o abZw== 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=wi4pmIg1YWYGdnTn/7xQQj6B4X9/W5QVYaSnfAciRn8=; b=St3D+2vfTvojTacDov27xt4YHhpOPPEua4mVklit0KF9kRBCXjOJ4ZF1b7RQcBo/RK Deh4zLBz45jHDunDHym2FgFLbc9AuucZyy4/nVcaJKNS88CaAFewQqWOZaiJkTIx/yq1 cg8fIdJa69zn98/fndQxzMEv2jnwYs89uO+LasbR1UqPUP8uHENYFv/BxHUkG1voExUg 9FFF40jYgLfBB5umOcJ08pfpFehNduuTxC0zGqyuzS4O8A2PyXbmV1Mj2U8KJgNQcTdF Hr3pAexzcbSsQcBSVk1yqCQU+isaNCNjvMK0aibh0XKeCeXSEHAPC+vj+8N4FDdhcqOV oCdw== X-Gm-Message-State: ANhLgQ0Q7x7P7BxbxfyN3QMkEFJy2xggcKG6AGE6kItTiFckiFqnW5PH 4ivYk3xglVPSebWijFl4WDQBQ7ORoY432lzoKIE= X-Google-Smtp-Source: ADFU+vtmARoccsX0035yn+1xBZojD8RouXkRwXTAc5i9DJ7F1+/0OzPqVj/HxeLP7ZF3Ker5qVhvk1ktFSD3naY5szM= X-Received: by 2002:a17:907:6f1:: with SMTP id yh17mr13851899ejb.20.1584814944656; Sat, 21 Mar 2020 11:22:24 -0700 (PDT) MIME-Version: 1.0 References: <307C827F-D587-4B04-9B11-38528905DB37@mit.edu> <69955994-1286-4956-A3C1-8B76CEDC927D@mit.edu> <79DD451B-B1AD-426D-BF4B-535AE6235A90@mit.edu> In-Reply-To: From: David Skaife Date: Sat, 21 Mar 2020 18:22:15 +0000 Message-ID: To: Justin Richer Cc: Dick Hardt , Yaron Sheffer , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000cfa36405a1617b79" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:22:31 -0000 --000000000000cfa36405a1617b79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we're saying the same thing with regards to the working group name - I was saying it *isn't* particularly important in comparison to the name of the protocol (which obviously is very important). On Sat, Mar 21, 2020 at 6:18 PM Justin Richer wrote: > I disagree on the working group name being super important. Nobody knows > that the OAuth WG is actually named =E2=80=9CThe Web Authorization Protoc= ol Working > Group=E2=80=9D, and nobody cares. > > My proposal is that we name the protocol we work on =E2=80=9CTxAuth=E2=80= =9D (and keep the > mailing list), and that we name the working group something like =E2=80= =9CNext > Generation Web Authorization Protocol=E2=80=9D to say what we=E2=80=99re = doing. > > -- Justin > > On Mar 21, 2020, at 2:08 PM, David Skaife < > blue.ringed.octopus.guy@gmail.com> wrote: > > Just to throw in another suggestion, to address Yaron's point about some > people mistakenly thinking that "Auth" stands for authentication rather > than authorization, how about naming the working group *AuthZ* > Nice and simple, and it makes it clear what the group is focused on. > > I think the name of the actual protocol that we produce is far, far more > important that the name of the working group - and the name of that > protocol doesn't need to correlate to the WG name. Also, we have much mor= e > time before we need to decide on the name of that protocol, even if the > initial draft documents that we produce end up using a placeholder name. > > On Sat, Mar 21, 2020 at 5:44 PM Justin Richer wrote: > >> As you can see in the email you replied to, that is not even close to >> what I said. I believe it is a transaction, and therefore, I do not agre= e >> that it=E2=80=99s not a transaction. >> >> But if we take =E2=80=9CTransactional=E2=80=9D out of the WG title, I wo= n=E2=80=99t be offended. >> If we just call it =E2=80=9CTxAuth=E2=80=9D without expansion, then that= =E2=80=99s fine. >> >> I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAut= h" was floated during >> naming the list, but rejected because (among other reasons) it would lik= ely >> be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D or something. TxAuth = reads as =E2=80=9CTee - ex >> - oth=E2=80=9D more naturally, which was the intent. >> >> So how about we take a page from the OAuth working group and name it: >> >> TxAuth - Next Generation Web Authorization Protocol Working Group >> >> >> =E2=80=94 Justin >> >> On Mar 21, 2020, at 1:15 PM, Dick Hardt wrote: >> >> To clarify -- you agree it is not a transaction, and we will take the >> word transaction out of the WG title? >> >> On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: >> >>> Dick, thanks for pulling the definitions up: >>> >>> > a communicative action or activity involving two parties or things >>> that reciprocally affect or influence each other >>> >>> This is the kind of thing that I had in mind. The client and the AS are >>> in a conversation over time that each one contributes to and each chang= es. >>> >>> Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80= =9D doesn=E2=80=99t stand for >>> =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that = the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D >>> doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. >>> >>> None of the arguments below in favor of XAuth have made me like that >>> name better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name,= then why come up with >>> something new? >>> >>> =E2=80=94 Justin >>> >>> On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: >>> >>> >>> >>> >>> not a transaction - there are multiple transactions >>> >>> backchannel innovation is combination of here is who I am, and here is >>> what I want to do >>> >>> >>> childhood trauma therapy group >>> >>> >>> >>> On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: >>> >>>> Yes, naming things is hard =E2=80=94 but I still believe in the name T= xAuth. >>>> We=E2=80=99re moving beyond OAuth, and taking the process of getting a= n >>>> authorization delegated to the client software as a multi-step, multi-= party >>>> transaction is, I believe, the key insight that=E2=80=99s letting us m= ove beyond >>>> OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to= the AS first =E2=80=94 we >>>> had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with = PAR. I really >>>> think it=E2=80=99s about the transaction at the core. >>>> >>> >>> OAuth 2.0 had multi-step, multi-party. TxAuth extends that. >>> >>> I think the big shift is going to the AS. This enables the request to b= e >>> richer with JSON, instead of name/value pairs parameters in a URI. It >>> allows the client and AS to negotiate, and to short circuit having to >>> redirect the user to the AS. PAR does some of this, but it is constrain= ed >>> by having to do it in the OAuth 2.0 context. >>> >>> My concern is that the protocol is MUCH MORE than a transaction. While >>> the initial interaction between client, AS, user and RO is a transactio= n. >>> The protocol also covers the client and RS interactions. The access tok= en >>> refreshes. Access token revocation. Access token introspection. As >>> described in the charter, there is a whole lifecycle, that consists of >>> multiple transactions. >>> >>> From https://www.merriam-webster.com/dictionary/transaction: >>> >>> Definition of *transaction* >>> >>> 1a: something transacted >>> especially : an >>> exchange or transfer >>> of goods, >>> services, or fundselectronic transactions >>> b: transactions plural : the often published record of the meeting of a >>> society or association >>> 2a: an act, process, or instance of transacting >>> >>> b: a communicative action or activity involving two parties or things >>> that reciprocally affect or influence each other >>> >>> Calling the protocol a transaction will confusing to people. >>> >>> >>>> >>>> Having come of age in the 1990=E2=80=99s, I have particular dislike fo= r XAuth. >>>> It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D= , and if you read either of those >>>> with a growling yell in your head then you know exactly what I=E2=80= =99m talking >>>> about. >>>> >>> >>> In case you are confused, this is not a childhood trauma support group. >>> :) >>> >>> Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder= . >>> X-Men, Xbox, X-Factor, X-files. >>> >>> https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-= 4 >>> >>> >>> https://english.stackexchange.com/questions/358181/whats-the-purpose-of= -using-letter-x-or-x-as-a-suffix-in-brand-names >>> >>> >>> >>>> And to Dick=E2=80=99s rationale for the name below, I absolutely do NO= T see >>>> this work as =E2=80=9COAuth with all the extra features=E2=80=9D. I th= ink that does a >>>> disservice to the kind of change we have an opportunity to make here. >>>> >>> >>> From the charter >>> >>> "It will expand upon the uses cases currently supported by OAuth 2.0 an= d >>> OpenID Connect (itself an extension of OAuth 2.0)" >>> >>> >>> Which sounds pretty similar to =E2=80=9COAuth with all the extra featur= es=E2=80=9D >>> >>> While I think XAuth captures what we are doing, a placeholder name woul= d >>> be preferable to an incorrect descriptive name such as TxAuth. >>> >>> For example, XYZ is a good placeholder name. Or XYZAuth. Let's not >>> mislead people. >>> >>> >>> >>>> >>>> =E2=80=94 Justin >>>> >>>> On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >>>> >>>> Hello everyone >>>> >>>> I prompted a thread around the name of the protocol a while back: >>>> >>>> >>>> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_= wc/ >>>> >>>> As Justin stated "naming is hard" >>>> >>>> Wearing my marketing hat I want to ensure that the name will be >>>> perceived properly in the broader community. >>>> >>>> A recent example that comes to mind are the privacy related works on >>>> the browser storage API. Given that name, one would think that it is l= ocal >>>> storage. It is actually about browser cookies. >>>> >>>> Justin discussed his reasons for TxAuth in the thread above (and I'm >>>> sure in other places) >>>> >>>> I chose XAuth in my draft to reflect the eXtensibility goal that we >>>> have over OAuth -- and XAuth is OAuth but with an X to reflect all the >>>> extra features. =3D) >>>> >>>> Other suggestions? >>>> >>>> This will be an agenda item in the BoF -- but the name will NOT be an >>>> open discussion item -- we will summarize what has been discussed on t= he >>>> list and perhaps do a poll of options presented unless consensus is ob= vious >>>> from this thread. >>>> >>>> /Dick >>>> >>>> >>>> >>>> >>>> >>>> =E1=90=A7 >>>> >>>> >>>> >>> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --000000000000cfa36405a1617b79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we're saying the same thing with regards to th= e working group name - I was saying it isn't particularly import= ant in comparison to the name of the protocol (which obviously is very impo= rtant).

On Sat, Mar 21, 2020 at 6:18 PM Justin Richer <jricher@mit.edu> wrote:
= I disagree on the working group name being super important. Nobody knows th= at the OAuth WG is actually named =E2=80=9CThe Web Authorization Protocol W= orking Group=E2=80=9D, and nobody cares.

My proposal is = that we name the protocol we work on =E2=80=9CTxAuth=E2=80=9D (and keep the= mailing list), and that we name the working group something like =E2=80=9C= Next Generation Web Authorization Protocol=E2=80=9D to say what we=E2=80=99= re doing.

=C2=A0-- Justin

On Mar 21, 2020, at 2:08 PM, David Skaife <blue.ring= ed.octopus.guy@gmail.com> wrote:

Just= to throw in another suggestion, to address Yaron's point about some pe= ople mistakenly thinking that "Auth" stands for authentication ra= ther than authorization, how about naming the working group AuthZNice and simple, and it makes it clear what the group is focused on.
<= br>I think the name of the actual protocol that we produce is far, far more= important that the name of the working group - and the name of that protoc= ol doesn't need to correlate to the WG name. Also, we have much more ti= me before we need to decide on the name of that protocol, even if the initi= al=C2=A0draft documents that we produce end up using a placeholder name.

On Sat, Mar 21, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
As you can see in the em= ail you replied to, that is not even close to what I said. I believe it is = a transaction, and therefore, I do not agree that it=E2=80=99s not a transa= ction.

But if we take =E2=80=9CTransactional=E2=80=9D ou= t of the WG title, I won=E2=80=99t be offended. If we just call it =E2=80= =9CTxAuth=E2=80=9D without expansion, then that=E2=80=99s fine.
<= br>
I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term = =E2=80=9CTAuth" was floated during naming the list, but rejected becau= se (among other reasons) it would likely be awkwardly pronounced as =E2=80= =9Ctowth=E2=80=9D or something. TxAuth reads as =E2=80=9CTee - ex - oth=E2= =80=9D more naturally, which was the intent.=C2=A0

So how about we take a page from the OAuth working group and name it:

TxAuth - = Next Generation Web Authorization Protocol Working Group


=C2=A0=E2=80=94 Justin

On Mar 21, 2020, at 1:15 PM, Dick Hardt <dick.hardt@gmail.com> w= rote:

To clarify -- you agree it is not a tr= ansaction, and we will take the word transaction out of the WG title?

On= Fri, Mar 20, 2020 at 5:53 PM Justin Richer <jricher@mit.edu> wrote:
Dick, thanks for pulling the = definitions up:

>=C2=A0a communicative action or activity involving tw= o parties or things that reciprocally affect or influence each other=

This is the kind of thing that I had in mind. The= client and the AS are in a conversation over time that each one contribute= s to and each changes.=C2=A0

Also =E2=80=94 we can= just as easily decide that =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand = for =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that = the =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D doesn=E2=80=99t stand fo= r =E2=80=9COpen=E2=80=9D anymore.=C2=A0

None of th= e arguments below in favor of XAuth have made me like that name better. If = it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then why come up wi= th something new?

=C2=A0=E2=80=94 Justin
<= br>
On Mar 20, 2020, at 3:32 PM, Dick Hardt &= lt;dick.hardt@gma= il.com> wrote:

=


not a transaction - there are multi= ple transactions

backchannel innovation is combination= =C2=A0of here is who I am, and here is what I want to do


childhood trauma therapy group



On Mon, Mar 16, 2020 at 6:56 PM Justin Richer <jricher@mit.edu> wrote:
=
Yes, naming th= ings is hard =E2=80=94 but I still believe in the name TxAuth. We=E2=80=99r= e moving beyond OAuth, and taking the process of getting an authorization d= elegated to the client software as a multi-step, multi-party transaction is= , I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2= =80=99s limitations here. It=E2=80=99s not just about going to the AS first= =E2=80=94 we had that in OAuth 1 and we=E2=80=99re patching that into OAut= h 2 with PAR. I really think it=E2=80=99s about the transaction at the core= .=C2=A0

OAuth 2.0 had multi-step, mul= ti-party. TxAuth extends that.

I think the big shi= ft is going to the AS. This enables the request to be richer with JSON, ins= tead of name/value pairs parameters in a URI. It allows the client and AS t= o negotiate, and to short circuit having to redirect the user to the AS. PA= R does=C2=A0some of this, but it is constrained by having to do it in the O= Auth 2.0 context.

My concern is that the protocol = is MUCH MORE than a transaction. While the initial interaction between clie= nt, AS, user and RO is a transaction. The protocol also covers the client= =C2=A0and RS interactions. The access token refreshes. Access token revocat= ion. Access token introspection. As described in the charter, there is a wh= ole lifecycle, that consists of multiple transactions.

=

Definition of=C2=A0= transaction

1a:=C2=A0something=C2=A0transactedespe= cially=C2=A0:=C2=A0an exchange or=C2=A0transfer=C2=A0of goods, services, = or fundselectronic=C2=A0transactions
b:=C2=A0transactio= ns=C2= =A0plural=C2=A0:=C2=A0the often published record of the mee= ting of a society or association
2a:=C2=A0an act, process, or instance of=C2=A0transacting<= /span>
b:=C2=A0a communicative action or activity involving two parties o= r things that reciprocally affect or influence each other

Calling the protocol a trans= action will confusing to people.
=C2=A0

Having come of age i= n the 1990=E2=80=99s, I have particular dislike for XAuth. It sounds too = =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and if you read e= ither of those with a growling yell in your head then you know exactly what= I=E2=80=99m talking about.

In = case you are confused, this is not a childhood=C2=A0trauma support group.= =C2=A0 :)

Unlike "X-TREME" or "X-CI= TING", XAuth is using the "X" as a placeholder. X-Men, Xbox,= X-Factor, X-files.=C2=A0


=C2=A0
And to Dick=E2=80=99s rationale fo= r the name below, I absolutely do NOT see this work as =E2=80=9COAuth with = all the extra features=E2=80=9D. I think that does a disservice to the kind= of change we have an opportunity to make here.=C2=A0

From the charter=C2=A0

"It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0= )"

<= div>Which sounds pretty similar to=C2=A0=E2=80=9COAuth with all the extra f= eatures=E2=80=9D

While I think XAuth captures what= we are doing, a placeholder name would be preferable to an incorrect descr= iptive name such as TxAuth.

For example, XYZ is a = good placeholder name. Or XYZAuth. Let's not mislead people.

=C2=A0
=

=C2=A0=E2=80=94 Justin

On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Hello everyone

I promp= ted a thread around the name of the protocol a while back:


As Ju= stin stated "naming is hard"

Wearing my = marketing hat I want to ensure that the name will be perceived=C2=A0properl= y in the broader community.

A recent example that = comes to mind are the privacy related works on the browser storage API. Giv= en that name, one would think that it is local storage. It is actually abou= t browser cookies.

Justin discussed his reasons fo= r TxAuth in the thread above (and I'm sure in other places)
<= br>
I chose XAuth in my draft to reflect the eXtensibility goal t= hat we have over OAuth -- and XAuth is OAuth but with an X to reflect all t= he extra features. =3D)

Other suggestions?

This will be an agenda item in the BoF -- but the name wi= ll NOT be an open discussion item -- we will summarize=C2=A0what has been d= iscussed on the list and perhaps do a poll of options presented unless cons= ensus is obvious from this thread.

/Dick





3D""=E1=90=A7



--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--000000000000cfa36405a1617b79-- From nobody Sat Mar 21 11:31:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C573A0891 for ; Sat, 21 Mar 2020 11:31:13 -0700 (PDT) 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 15YQYhO9l24V for ; Sat, 21 Mar 2020 11:31:10 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 D6EB63A088D for ; Sat, 21 Mar 2020 11:31:09 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id b2so11500227wrj.10 for ; Sat, 21 Mar 2020 11:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pd40J1NR3PL4LymoSmiX/iiIRoS5zxKND81bqphrzZU=; b=o9hby5R9zhb0q/g4/rjGwNmtpTH4YZUn81nNbG2voAJSaGJQblIdGCQVSKBVQbw5G+ ruI7Mk+altCid0xS9HS+CpG8GbkxaLdtOuXoslZ1A4WI6ZppBX/vZYaShg3wySzVF978 f6CkOOvUtJNV0giukE2/1dMvzDJq2MkU1csGUUIUyvNmGilSi5NaOPOoFh+Ofuo/tY+3 KYKXKwsQsbEsdDPKVSiIyWJw1fHNk9WynXQLMhgIKKEy32BW+JdQ518AA4sv8x2nRX8f xjYhhC/yWJGOh+cETRch4DEXFWDRflk7LprGxAhBDSNImKvTANlWO5Rm8hUD2pRl3zsT CvbA== 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=pd40J1NR3PL4LymoSmiX/iiIRoS5zxKND81bqphrzZU=; b=dSrbJ0qB+X+ie08ldm9sTv6J29vCUCH7MZb+DDk3OJwEu98qXkEgtdVDL0S36loX1h cJv9e/0LuArRd7VTTg7k5DRDrlAWlkfgyWdBW9yivrH2ucgFMzY19VKh1j6ew/jJGEig vwKPKhhUE433wYJIhPvqx9Ph16DYbP+iqAHtJi/I3ZSHd3HiHAemT0KdUW6dnVzoxs1a 4BWyDe/AiD1+hhCiES/4IlCxtJBE+LICELI1hvsYdY3eEeS4xudSI4YoVoByrqZzAEqP E2XncrlNaofSAz+YPRsIJ0fdDACVaaO8ajTytp/t0sQibrhkgqtr9HiCWiJeH9WN/8Tf pDFw== X-Gm-Message-State: ANhLgQ2t6UlTzU7O4aJqgSADDAsL4teq6Dt+bWlJCtZffxUoigo1Jbiw Q8dulpBcXOMxrZKFp5uuWq+fmXFCAb0= X-Google-Smtp-Source: ADFU+vtCuNZoNK+ufaDCAWRJ/8iu+aSNC+xa9QUAdvSoXVdnT2HUr1ze/980H2wugmZnIbEk0Q3H7Q== X-Received: by 2002:a05:6000:1626:: with SMTP id v6mr17832566wrb.251.1584815467955; Sat, 21 Mar 2020 11:31:07 -0700 (PDT) Received: from p200300eb8f2625ca05c39e1b37cae8fc.dip0.t-ipconnect.de (p200300EB8F2625CA05C39E1B37CAE8FC.dip0.t-ipconnect.de. [2003:eb:8f26:25ca:5c3:9e1b:37ca:e8fc]) by smtp.gmail.com with ESMTPSA id f9sm14600798wrc.71.2020.03.21.11.31.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2020 11:31:07 -0700 (PDT) From: Torsten Lodderstedt Message-Id: <07EA221E-FA0D-4381-80E9-DB138C9E260C@lodderstedt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9EFE1BAD-132D-4884-B9B8-1A353B76437F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Sat, 21 Mar 2020 19:31:06 +0100 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org, Torsten Lodderstedt , Vladimir Dzhuvinov To: Justin Richer References: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:31:14 -0000 --Apple-Mail=_9EFE1BAD-132D-4884-B9B8-1A353B76437F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin,=20 > On 21. Mar 2020, at 17:46, Justin Richer wrote: >=20 > Torsten, what if we walk that back to: >=20 > - Support for multiple access tokens in a single request I think this should be a requirements wrt the response and needs text = about who determines the split. =E2=80=9C=E2=80=A6 in a single response at the discretion of the AS or = as requested by the client=E2=80=9D seems appropriate in my opinion. Note: this slightly reduces the solution space since it would not allow = to implement RS-specific access tokens in Multi RS setups using the = =E2=80=9Csuper refresh token" pattern. That=E2=80=99s fine with me since = I anyway believe issuing all access tokens at once is easier to handle = for the client. The =E2=80=9Csuper refresh token=E2=80=9D pattern in = contrast requires the client to know the boundaries between RSs. =20 > - Support for directed, audience-restricted access requests Can you please explain what this means? I understand "directed, = audience-restricted access tokens=E2=80=9D but what are a "directed, = audience-restricted access requests" >=20 > I propose that we split these because I think the two of them are = useful separately, and considering them separately might influence how = we end up solving it overall. I understand that you=E2=80=99re looking = at a use case that combines both of them, and I think enabling that = makes some sense.=20 Thanks for your proposal.=20 best regards, Torsten.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt = wrote: >>=20 >> Hi Dick,=20 >>=20 >>> On 20. Mar 2020, at 01:57, Dick Hardt wrote: >>>=20 >>> Rereading the charter I would consider the proposed charter change: >>>=20 >>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>=20 >>> To be covered by the two highlighted lines below: >>>=20 >>> Additionally, the delegation process will allow for: >>>=20 >>> - Fine-grained specification of access >>> - Approval of AS attestation to identity claims >>> - Approval of access to multiple resources and APIs in a single = interaction >>> - Separation between the party authorizing access and the party = operating the client requesting access >>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>>=20 >>> Torsten: Does the scope of fine-grained access combined with = approval of access to multiple resources cover your requirements? >>=20 >> I initially thought =E2=80=9CApproval of access to multiple resources = and APIs in a single interaction=E2=80=9D would do. But obviously it = doesn=E2=80=99t mention access tokens and the charter, in general, is = quiet regarding desired capabilities for token issuance and = relationships between access tokens and resources. =20 >>=20 >> It also became obvious during the recent discussions there are = different interpretations, expectations, and objectives.=20 >>=20 >> I therefore think another bullet to explicitly spell this out makes a = lot of sense.=20 >>=20 >> In order to cover more use cases and be more explicit at the same = time, I suggest the following wording: >>=20 >> - Support for directed, audience-restricted access tokens in multi-RS = deployments at client or AS discretion >>=20 >>>=20 >>> Note that we are not stating how we do it, just what is in scope. >>=20 >> Absolutely, I can think of various ways to implement it, but that=E2=80= =99s another step. First we need to agree on the objectives.=20 >>=20 >> thanks, >> Torsten.=20 >>=20 >>>=20 >>> /Dick >>>=20 >>> On Thu, Mar 19, 2020 at 1:48 PM Justin Richer = wrote: >>> On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = wrote: >>>>=20 >>>>> Am 19.03.2020 um 21:07 schrieb Justin Richer : >>>>>=20 >>>>> =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99= ve described, >>>>=20 >>>> Given our recent discussion, I don=E2=80=99t see how it is already = in scope=20 >>>=20 >>> What I mean is that a client can already ask for separate tokens and = use the =E2=80=9Cresources=E2=80=9D block to describe which resource = servers it wants. However, right now, it=E2=80=99s up to the client to = determine what the split is =E2=80=94 either by asking for separate = tokens in either the single-token format (with multiple requests) or = multi-token format (with a single request).=20 >>>=20 >>>>=20 >>>>> with the caveat that identifying "the RS" is really, really hard = to do. >>>>=20 >>>> I don=E2=80=99t think it=E2=80=99s difficult to use URLs to = identify at least =E2=80=9Edestinations=E2=80=9C, it works for cookies = as well.=20 >>>=20 >>> I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99m= trying to push back against optimizing for that one kind of identity. = And cookies have all kinds of rules for paths and domains and origins = that protect them, so if that=E2=80=99s the model we=E2=80=99re arguing = for we need to at least consider all of that. We also need to consider = that cookies fail in a lot of ways! :) >>>=20 >>>>=20 >>>>> What if instead it=E2=80=99s: >>>>>=20 >>>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>>>=20 >>>>> Would that work? To me the difference is that it=E2=80=99s getting = away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and more = towards the notion of getting a token directed to a specific set of = actions and/or locations. >>>>=20 >>>> wfm, as long it is clear the AS/RS determines the boundaries. >>>=20 >>> Ultimately they always do, and they=E2=80=99ll always need to deal = with the situation where a client asks for rights that cross boundaries. = The question is what to do in those situations, and I think there=E2=80=99= s a lot more discussion we need to have on that front! Do we allow the = AS to split a token request, do we have errors for this, do we have a = client indicate that it can receive split tokens =E2=80=A6 etc. I think = it=E2=80=99s an interesting area, but complex and not nearly as = clean-cut as your own use case and deployment might let it be. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>>=20 >>>> best regards, >>>> Torsten. >>>>=20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I suggest to add the following requirement to the charter: >>>>>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >>>>>>=20 >>>>>> I don=E2=80=99t mind HOW this requirement is supported in TXAuth. = I want to make sure we try to build a protocol that serves the needs of = a broad set of deployments. My concern is otherwise TXAuth will be not = innovative enough to gain traction in the market rapidly. Speaking for = myself, I realised in the last couple of days, mostly in conversations = with Justin, that the result of this working group as envisioned now is = not of particular interest to us (yes.com) because it does not solve our = real problems.=20 >>>>>>=20 >>>>>> And here is my explanation:=20 >>>>>>=20 >>>>>> OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 >>>>>>=20 >>>>>> And there are even more examples today for multi API environments = that would benefit from that feature:=20 >>>>>> =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! >>>>>> =E2=80=A2 Everyone is doing micro services today. Have you every = thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. >>>>>> =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. >>>>>>=20 >>>>>> Since we are preparing to define a completely new protocol for = API access authorization and delegation, I think this new protocol = should support this kind of scenarios. It will require significant work = to get it right and simple, but if we just stick to the =E2=80=9Ca = single access token is enough=E2=80=9D mantra, we miss the chance to = give implementers a broader range of design choices out of the box and = we won=E2=80=99t success in achieving true interoperability. >>>>>>=20 >>>>>> Here are more advantages we can gain by supporting such a = feature:=20 >>>>>> =E2=80=A2 Privacy: >>>>>> =E2=80=A2 A single access token can be used to track user = across services. >>>>>> =E2=80=A2 RS-specific access tokens cannot. >>>>>> =E2=80=A2 RS-specific access tokens can also be encrypted to = protect data confidentiality in transit. >>>>>> =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. >>>>>> =E2=80=A2 Performance: RS-specific access tokens allow the AS to = convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >>>>>>=20 >>>>>> What do you think? >>>>>>=20 >>>>>> best regards, >>>>>> Torsten.=20 >>>>>>=20 >>>>>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>>>>>>> On 19. Mar 2020, at 17:47, Justin Richer = wrote: >>>>>>>>> Well, it=E2=80=99s in scope as much as describing any other = aspect of what the token is for and what it represents is in scope. That = is alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>>>>>>=20 >>>>>>>>> But here=E2=80=99s the thing: none of that has an impact on = the core protocol. That is entirely up to the AS and the RS to agree on, = and the client never sees or has any influence on it. That portion of = the protocol is completely opaque to the client. Therefore, it doesn=E2=80= =99t really affect the authorization and delegation portions of the = client talking to the AS and the client talking to the RS. >>>>>>>>>=20 >>>>>>>>> This does raise the question of what our bar of = interoperability is going to be with TxAuth: do we expect independent AS = and RS implementations to talk to each other? That=E2=80=99s not = something OAuth 2 was ever concerned with, though obviously JWT and = introspection are both from the OAuth2 WG and solve that problem. >>>>>>>> There are two aspects to it: interoperability and vendor = support.=20 >>>>>>>>=20 >>>>>>>> Interoperability between AS and RS is important if deployments = want to combine pre-packaged TXAuth and API implementations. I think = that makes a lot of sense and should be included in the charter. >>>>>>>=20 >>>>>>> +1 >>>>>>>=20 >>>>>>> The current OAuth 2.0 status quo of the largely unspecified = relationship >>>>>>> between AS and RS is also making the life of web & sec framework >>>>>>> maintainers difficult. We witnessing this with people = integrating the >>>>>>> OAuth SDK into frameworks. Vittorio's recent work to put = together a >>>>>>> minimal interoperable JWT profile for access tokens is helpful, = but it >>>>>>> has come after the fact. And there is not agreement on things = like >>>>>>> authorising access to claims. >>>>>>>=20 >>>>>>> Integrating apps (RSs) with TxAuth should be straightforward and = simple. >>>>>>>=20 >>>>>>> This can have a enormous effect on adoption. >>>>>>>=20 >>>>>>>=20 >>>>>>>> Vendors support: vendor support when it comes to "what can go = into an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>>>>>>=20 >>>>>>> +1 >>>>>>>=20 >>>>>>>=20 >>>>>>>> I also think it is a good exercise for the group to think the = whole process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) = is not to provide clients with access tokens. The purpose is to enable = API request processing in a secure manner. What it really takes to = achieve that goal is not obvious if the work always stops at the =E2=80=9C= you have your access token, good luck=E2=80=9D stage.=20 >>>>>>>=20 >>>>>>> +1 >>>>>>>=20 >>>>>>> Vladimir >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>=20 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>=20 >>>>> --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >=20 --Apple-Mail=_9EFE1BAD-132D-4884-B9B8-1A353B76437F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Justin, 

On 21. = Mar 2020, at 17:46, Justin Richer <jricher@mit.edu> wrote:

Torsten, what if we walk that back to:

 - Support for multiple access tokens in a single = request

I = think this should be a requirements wrt the response and needs text = about who determines the split.

=E2=80=9C=E2=80=A6  in a single = response at the discretion of the AS or as requested by the client=E2=80=9D= seems appropriate in my opinion.

Note: this slightly reduces the = solution space since it would not allow to implement RS-specific access = tokens in Multi RS setups using the =E2=80=9Csuper refresh token" = pattern. That=E2=80=99s fine with me since I anyway believe issuing all = access tokens at once is easier to handle for the client. The =E2=80=9Csup= er refresh token=E2=80=9D pattern in contrast requires the client to = know the boundaries between RSs.  

 - Support for directed, = audience-restricted access requests

Can you please explain what this means? I understand = "directed, audience-restricted access tokens=E2=80=9D but what are a = "directed, audience-restricted access requests"


I propose that we split these = because I think the two of them are useful separately, and considering = them separately might influence how we end up solving it overall. I = understand that you=E2=80=99re looking at a use case that combines = both of them, and I think enabling that makes some sense. 

Thanks for = your proposal. 

best regards,
Torsten. 


 =E2=80=94 Justin

On Mar 21, 2020, at 9:18 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Dick, 

On = 20. Mar 2020, at 01:57, Dick Hardt <dick.hardt@gmail.com> = wrote:

Rereading the charter I would = consider the proposed charter change:

- = Support for directed, audience-restricted access tokens in multi-RS = deployments

To be covered by the two = highlighted lines below:

Additionally, the = delegation process will allow for:

- = Fine-grained specification of access
- Approval of AS = attestation to identity claims
- Approval of access to = multiple resources and APIs in a single interaction
- = Separation between the party authorizing access and the party operating = the client requesting access
- A variety of client = applications, including Web, mobile, single-page, and = interaction-constrained applications

Torsten:= Does the scope of fine-grained access combined with approval of access = to multiple resources cover your requirements?

I initially thought =E2=80=9CApprov= al of access to multiple resources and APIs in a single interaction=E2=80=9D= would do. But obviously it doesn=E2=80=99t mention access tokens and = the charter, in general, is quiet regarding desired capabilities for = token issuance and relationships between access tokens and = resources.  

It also became obvious = during the recent discussions there are different interpretations, = expectations, and objectives. 

I = therefore think another bullet to explicitly spell this out makes a lot = of sense. 

In order to cover more use = cases and be more explicit at the same time, I suggest the following = wording:

- Support for directed, = audience-restricted access tokens in multi-RS deployments at client or = AS discretion


Note that we are not = stating how we do it, just what is in scope.

Absolutely, I can think of = various ways to implement it, but that=E2=80=99s another step. First we = need to agree on the objectives. 

thanks,
Torsten. 


/Dick

On Thu, Mar 19, 2020 at = 1:48 PM Justin Richer <jricher@mit.edu> wrote:
On = Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = <torsten@lodderstedt.net> wrote:

Am 19.03.2020 um 21:07 schrieb Justin Richer = <jricher@mit.edu>:

=EF=BB=BFI think = this is already in scope in the ways that I=E2=80=99ve described,

Given our recent discussion, I = don=E2=80=99t see how it is already in scope 

What I mean is that a client can = already ask for separate tokens and use the =E2=80=9Cresources=E2=80=9D = block to describe which resource servers it wants. However, right now, = it=E2=80=99s up to the client to determine what the split is =E2=80=94 = either by asking for separate tokens in either the single-token = format (with multiple requests) or multi-token format (with a single = request). 


with the = caveat that identifying "the RS" is really, really hard to do.

I don=E2=80=99t think it=E2=80=99s = difficult to use URLs to identify at least =E2=80=9Edestinations=E2=80=9C,= it works for cookies as well. 

I think that=E2=80=99s an aspect, but not the only aspect. = I=E2=80=99m trying to push back against optimizing for that one kind of = identity. And cookies have all kinds of rules for paths and domains and = origins that protect them, so if that=E2=80=99s the model we=E2=80=99re = arguing for we need to at least consider all of that. We also need = to consider that cookies fail in a lot of ways! :)


What if instead it=E2=80=99s:

- Support for directed, audience-restricted access tokens in = multi-RS deployments

Would that work? To me = the difference is that it=E2=80=99s getting away from a fixed notion of = what an =E2=80=9CRS=E2=80=9D is and more towards the notion of getting a = token directed to a specific set of actions and/or locations.

wfm, as long it is clear the = AS/RS determines the boundaries.

Ultimately they always do, and they=E2=80=99ll always need to = deal with the situation where a client asks for rights that cross = boundaries. The question is what to do in those situations, and I think = there=E2=80=99s a lot more discussion we need to have on that front! Do = we allow the AS to split a token request, do we have errors for = this, do we have a client indicate that it can receive split tokens =E2=80= =A6 etc. I think it=E2=80=99s an interesting area, but complex and not = nearly as clean-cut as your own use case and deployment might let it = be.

=E2=80=94 Justin


best = regards,
Torsten.


=E2=80=94 Justin
On Mar 19, 2020, at = 2:08 PM, Torsten Lodderstedt = <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Hi all,

I suggest = to add the following requirement to the charter:
 =E2=80= =A2 Support for RS-specific access tokens in Multi-RS = deployments 

I don=E2=80=99t mind HOW = this requirement is supported in TXAuth. I want to make sure we try to = build a protocol that serves the needs of a broad set of deployments. My = concern is otherwise TXAuth will be not innovative enough to gain = traction in the market rapidly. Speaking for myself, I realised in = the last couple of days, mostly in conversations with Justin, that the = result of this working group as envisioned now is not of particular = interest to us (yes.com) because it does not solve our real = problems. 

And here is my = explanation: 

OAuth traditionally has = the philosophy of a single access token. That=E2=80=99s fine for single = service deployments, but it had reached its limits already before = RFC6749 was published. There are a real implementations out there = forcing clients to use different access tokens for different = services, typically for privacy and security reasons. There is also an = =E2=80=9Cancient" technology called Kerberos that uses exactly this = pattern and is well known for security, performance, and = scalability. 

And there are even more = examples today for multi API environments that would benefit from that = feature: 
 =E2=80=A2 Open banking: most banks I = worked with have multiple APIs, segregation between APIs is today = achieved by maintaining different grants, basically resulting in the = fact that the users cannot consent to different services at once. What a = terrible UX!
 =E2=80=A2 Everyone is doing micro = services today. Have you every thought about the coupling caused by a = single token across micro services? This reminds me of how easy it is to = test services independently using self-contained RS-specific tokens.
 =E2=80=A2 IoT - every device in a household is a = potential RS (in my opinion). Conveying all necessary data in an access = token needed to meet access control decisions locally would be a huge = benefit in terms of performance and decoupling. Using = symmetric cryptography for token integrity, authenticity and = confidentiality would result in lower compute requirements.

Since we are preparing to define a completely = new protocol for API access authorization and delegation, I think this = new protocol should support this kind of scenarios. It will require = significant work to get it right and simple, but if we just stick to the = =E2=80=9Ca single access token is enough=E2=80=9D mantra, we miss = the chance to give implementers a broader range of design choices out of = the box and we won=E2=80=99t success in achieving true = interoperability.

Here are more advantages = we can gain by supporting such a feature: 
 =E2=80= =A2 Privacy:
     =E2=80=A2 A single access = token can be used to track user across services.
  =    =E2=80=A2 RS-specific access tokens cannot.
     =E2=80=A2 RS-specific access tokens can = also be encrypted to protect data confidentiality in transit.
 =E2=80=A2 Security: RS-specific access tokens have a = baseline replay detection.
 =E2=80=A2 Performance: = RS-specific access tokens allow the AS to convey all data required to = authorize an API call in a token (e.g. a JWT) and to RS to meet the = access control decision based on that data. This is a huge advantage in = terms of performance, scalability and cost since there is no need = for Token Introspection or other kinds of access to another services or = database.

What do you think?

best regards,
Torsten. 

On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:


On 19/03/2020 19:11, Torsten Lodderstedt = wrote:
On 19. Mar = 2020, at 17:47, Justin Richer <jricher@mit.edu> wrote:
Well, it=E2=80=99s in = scope as much as describing any other aspect of what the token is for = and what it represents is in scope. That is alongside things like the = intended audience of the token, the access rights for the token, the = presentation keys the token is bound to, etc. It could be = information in the token text itself (like a JWT), it could be = introspected from the AS, it could be referenced in some other way. So = if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there. 

But here=E2=80=99s = the thing: none of that has an impact on the core protocol. That is = entirely up to the AS and the RS to agree on, and the client never sees = or has any influence on it. That portion of the protocol is completely = opaque to the client. Therefore, it doesn=E2=80=99t really affect = the authorization and delegation portions of the client talking to the = AS and the client talking to the RS.

This = does raise the question of what our bar of interoperability is going to = be with TxAuth: do we expect independent AS and RS implementations to = talk to each other? That=E2=80=99s not something OAuth 2 was ever = concerned with, though obviously JWT and introspection are both = from the OAuth2 WG and solve that problem.
There are two aspects to it: interoperability = and vendor support. 

Interoperability = between AS and RS is important if deployments want to combine = pre-packaged TXAuth and API implementations. I think that makes a lot of = sense and should be included in the charter.

+1

The= current OAuth 2.0 status quo of the largely unspecified relationship
between AS and RS is also making the life of web & sec = framework
maintainers difficult. We witnessing this with = people integrating the
OAuth SDK into frameworks. = Vittorio's recent work to put together a
minimal = interoperable JWT profile for access tokens is helpful, but it
has come after the fact. And there is not agreement on things = like
authorising access to claims.

Integrating apps (RSs) with TxAuth should be straightforward = and simple.

This can have a enormous effect = on adoption.


Vendors support: vendor support when it comes = to "what can go into an access token" and "what can be conveyed in a = token introspection response=E2=80=9D greatly deviates in my = observation. This also means implementation use vendors = specific features restricting their ability to use other solutions. = TXAuth should aim at improving the situation.  

+1

I also think it is a = good exercise for the group to think the whole process "from the end=E2=80= =9D. The purpose of TXAuth (and OAuth) is not to provide clients with = access tokens. The purpose is to enable API request processing in a = secure manner. What it really takes to achieve that goal is not = obvious if the work always stops at the =E2=80=9Cyou have your access = token, good luck=E2=80=9D stage. 

+1

Vladimir


-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


= --Apple-Mail=_9EFE1BAD-132D-4884-B9B8-1A353B76437F-- From nobody Sat Mar 21 11:36:02 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3474D3A0894 for ; Sat, 21 Mar 2020 11:36:00 -0700 (PDT) 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 KLAJmtlamwB5 for ; Sat, 21 Mar 2020 11:35:50 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 A27563A0895 for ; Sat, 21 Mar 2020 11:35:48 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id r22so3019409ljh.0 for ; Sat, 21 Mar 2020 11:35:48 -0700 (PDT) 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=s1lcXh9MaO23LpU5nkFdARL9DrkZdXib3UzAVQT/dN0=; b=lZrMVOuBuU74qo4iG5nuuuLGkZ0/QbtMOrxZ1Tr585mFQ4ktbVkOw593i75hhJAvOF d/lwqCyAX9n/MsTURNEQi0Ao8/peNR2cyxz7WPpLXb9/NVpOyTCmivwcgtnfVa3vOS5q SKqZkAPjgHFLNGQLd3POw8N6zzsMh7gGF1bTtQRgrOkCtpOnREifkrPjvcsTnT0TbCpe Lb0759EfOiZU0VPHNpJExjBxIFhrVU2zChwNtUc+HavJVt3jx57P0kBZs3fiaH/vBNH5 mMgnIqtcYP4QH9lglKeyccW4ISMktoN0N4Xl7djpZ+7OfiIdbZbItIygtpGnW0St4Jeh njGA== 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=s1lcXh9MaO23LpU5nkFdARL9DrkZdXib3UzAVQT/dN0=; b=aiZuXQqFq1R8tZA4sYTvUCiBfQpiABKdIi1PKKDRi5QZ+U4YmWyo0bPYDAtcg+I2FM ldYVTOkvaH5cFyFHYd8R8OUdU93OvgXKYLKp7lsZtP7b4A/xe0gSDF3QmZFEpD2ciysJ hBJVkPVUKBIdTijHiAE9+gNieKd/ps3rsKemYNG1R4z0w1XgLeCv9k1BGxP+QdmH8vtt v6/qOJEJeZForMAExEluy8TN2hVY7lkXaRSel8JsG2Ln0a5qpKr8yCtNalZbtzilcdLB 4epgCQmNr1Dtil2i+M7TeJvUESbx2Hzg1+3TIdMUHsJB1E1aW531/J/757sYJTu7P1F8 MxtQ== X-Gm-Message-State: ANhLgQ2K3a+5Q4p2CiNgFnKIJG0ZQb74iWX7iODkAU3qtynakNRGH3GB YuyTLmfZ6/0JzITNjNf80B0DrJuS9TemV/TSSi4= X-Google-Smtp-Source: ADFU+vsp/44QftXox02/UMVnkhEN9e/dKG/aH0rLX4PJ1LwT9li8gNGmPH4ZQ8Zc3sNPYK0ePmupZaDx9V1+gfX8q/U= X-Received: by 2002:a2e:7811:: with SMTP id t17mr9071830ljc.150.1584815746196; Sat, 21 Mar 2020 11:35:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 21 Mar 2020 11:35:20 -0700 Message-ID: To: Justin Richer Cc: Vijay IETF , David Skaife , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000096272f05a161abee" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:36:00 -0000 --00000000000096272f05a161abee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Discovery lets the client know what other mechanisms are available besides the MTI mechanism. If there is no MTI, then there is no interop unless ALL mechanisms are implemented independent of discovery. On Sat, Mar 21, 2020 at 10:58 AM Justin Richer wrote: > Dick, > > I think there=E2=80=99s a big difference between a =E2=80=9Cdefault=E2=80= =9D and =E2=80=9CMTI=E2=80=9D. If you > mean that the protocol chooses one key proofing method as =E2=80=9CMTI=E2= =80=9D for the AS, > then I can maybe get behind that idea. I think the realm of MTI is > something that we do need to decide as a group, but that goes for all of > the various features and options in the protocol. I think OAuth 2 went to= o > far into the =E2=80=9Ceverything=E2=80=99s optional=E2=80=9D world, but a= t the same time, we don=E2=80=99t > want to go too far into the OAuth 1 world of =E2=80=9Cthis is all mandato= ry because > of one tiny use case=E2=80=9D. > > Also, an observation - if we mandate discovery as you=E2=80=99ve proposed= in > XAuth, then doesn=E2=80=99t the argument for any MTI fall a little flat? = Since a > client can discover which methods are available, a smarter client can > discover and configure itself based on that set of options. > > I contend that that clients, even general purpose ones, aren=E2=80=99t go= ing to be > very smart in that regard. I think it=E2=80=99s vanishingly rare for a pi= ece of > client software in the OAuth 2 world to call the discovery document and > change which authentication method it=E2=80=99s going to use. Instead, th= is tends > to be driven by the developer who=E2=80=99s configured the client softwar= e library > to behave in a specific way. I think we=E2=80=99ll continue to see that p= attern > here with TxAuth, especially as things go to embedded systems that get > hardcoded to work in one specific way. > > =E2=80=94 Justin > > > > On Mar 21, 2020, at 1:21 PM, Dick Hardt wrote: > > Hi Vijay > > Thanks for asking for clarification. > > If there is no default or minimum to implement (MTI) requirement, then fo= r > interop to be guaranteed between a client and an AS, one of the parties > will need to support all of the choices since the other party could choos= e > to support only one of the choices. In this work, we have tended to push > complexity to the AS, so the AS would need to implement all choices to be > compliant. > > If there is a default, then only the default MUST be implemented by both > parties to be compliant. > > Of course, any bespoke implementation can do whatever they want. > > While you may not personally be a fan of general purpose software, others > are, and as a group we need to anticipate the implications for all > implementors. > > > > > > > On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF wrote: > >> Hi Dick, >> >> Thanks for the additional context for reasoning. My response inline. >> >> On Sat, 21 Mar 2020 at 06:00, Dick Hardt wrote: >> >>> >>> >> If all choices are equal (no default), then ALL the choices have to be >>> implemented in a general purpose implementation, which increases the at= tack >>> surface and vulnerability of an implementation, ie a coding error. >>> >>> >> I do not see how having a no default implies all choices being equal. I >> am missing the nuance here. >> >> The +1 for xyz rationale was to favor implementations that have the >> freedom to implement what they see fit and still be "compliant" with the >> protocol. I am not a fan of bloated general purpose software >> implementations, so I don't have much to comment on that. Sorry. >> >> --- >> Vijay >> > > --00000000000096272f05a161abee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Discovery lets the client know what other mechanisms are a= vailable besides the MTI mechanism.=C2=A0

If there is no= MTI, then there is no interop unless ALL mechanisms are implemented indepe= ndent=C2=A0of discovery.


On Sat, Mar 21, 2020 at 10:58 = AM Justin Richer <jricher@mit.edu= > wrote:
Dick,

I think ther= e=E2=80=99s a big difference between a =E2=80=9Cdefault=E2=80=9D and =E2=80= =9CMTI=E2=80=9D. If you mean that the protocol chooses one key proofing met= hod as =E2=80=9CMTI=E2=80=9D for the AS, then I can maybe get behind that i= dea. I think the realm of MTI is something that we do need to decide as a g= roup, but that goes for all of the various features and options in the prot= ocol. I think OAuth 2 went too far into the =E2=80=9Ceverything=E2=80=99s o= ptional=E2=80=9D world, but at the same time, we don=E2=80=99t want to go t= oo far into the OAuth 1 world of =E2=80=9Cthis is all mandatory because of = one tiny use case=E2=80=9D.=C2=A0

Also, an observa= tion - if we mandate discovery as you=E2=80=99ve proposed in XAuth, then do= esn=E2=80=99t the argument for any MTI fall a little flat? Since a client c= an discover which methods are available, a smarter client can discover and = configure itself based on that set of options.=C2=A0

I contend that that clients, even general purpose ones, aren=E2=80=99t g= oing to be very smart in that regard. I think it=E2=80=99s vanishingly rare= for a piece of client software in the OAuth 2 world to call the discovery = document and change which authentication method it=E2=80=99s going to use. = Instead, this tends to be driven by the developer who=E2=80=99s configured = the client software library to behave in a specific way. I think we=E2=80= =99ll continue to see that pattern here with TxAuth, especially as things g= o to embedded systems that get hardcoded to work in one specific way.
=

=C2=A0=E2=80=94 Justin



On Mar 21, 2020, at 1:21 PM, Dick Hard= t <dick.hardt@= gmail.com> wrote:

Hi Vijay

Thanks for asking for clarification.=C2=A0

If there is no default or minimum to implement (MTI) requirement, then fo= r interop to be guaranteed between a client and an AS, one of the parties w= ill need to support all of the choices since the other party could choose t= o support only one of the choices. In this work, we have tended to push com= plexity to the AS, so the AS would need to implement all choices to be comp= liant.=C2=A0

If there is a default, then only the = default MUST be implemented by both parties to be compliant.

=
Of course, any bespoke implementation can do whatever they want.= =C2=A0

While you may not personally be a fan of ge= neral purpose software, others are, and as a group we need to anticipate th= e implications for all implementors.






On Sat, Mar 21, 2020 at 1:29 AM V= ijay IETF <vij= ay.ietf@gmail.com> wrote:
Hi Dick,

Th= anks for the additional context for reasoning. My response inline.

On Sa= t, 21 Mar 2020 at 06:00, Dick Hardt <dick.hardt@gmail.com> wrote:
<snip>
If all choices are equal (no default), then ALL the choices have to b= e implemented in a general purpose implementation, which increases the atta= ck surface and vulnerability of an implementation, ie a coding error.
=


I do not see how havi= ng a no default=C2=A0 implies all choices being equal. I am missing the nua= nce here.

The +1 for xyz rationale was to fa= vor implementations that have the freedom to implement what they see fit an= d still be "compliant" with the protocol. I am not a fan of bloat= ed general purpose software implementations, so I don't have much to co= mment on that. Sorry.
=C2=A0
---
Vijay

--00000000000096272f05a161abee-- From nobody Sat Mar 21 11:42:13 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB493A08A2 for ; Sat, 21 Mar 2020 11:42:07 -0700 (PDT) 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 mqb26WeMfMyw for ; Sat, 21 Mar 2020 11:42:03 -0700 (PDT) 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 5955F3A089B for ; Sat, 21 Mar 2020 11:42:01 -0700 (PDT) Received: from [192.168.1.5] (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 02LIfqfh006402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Mar 2020 14:41:53 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3DA964F1-E4A8-4E53-A7D2-87B15045C3F1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Mar 2020 14:41:52 -0400 In-Reply-To: <07EA221E-FA0D-4381-80E9-DB138C9E260C@lodderstedt.net> Cc: Dick Hardt , txauth@ietf.org, Torsten Lodderstedt , Vladimir Dzhuvinov To: Torsten Lodderstedt References: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> <07EA221E-FA0D-4381-80E9-DB138C9E260C@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:42:09 -0000 --Apple-Mail=_3DA964F1-E4A8-4E53-A7D2-87B15045C3F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Mar 21, 2020, at 2:31 PM, Torsten Lodderstedt = wrote: >=20 > Justin,=20 >=20 >> On 21. Mar 2020, at 17:46, Justin Richer > wrote: >>=20 >> Torsten, what if we walk that back to: >>=20 >> - Support for multiple access tokens in a single request >=20 > I think this should be a requirements wrt the response and needs text = about who determines the split. >=20 > =E2=80=9C=E2=80=A6 in a single response at the discretion of the AS = or as requested by the client=E2=80=9D seems appropriate in my opinion. >=20 > Note: this slightly reduces the solution space since it would not = allow to implement RS-specific access tokens in Multi RS setups using = the =E2=80=9Csuper refresh token" pattern. That=E2=80=99s fine with me = since I anyway believe issuing all access tokens at once is easier to = handle for the client. The =E2=80=9Csuper refresh token=E2=80=9D pattern = in contrast requires the client to know the boundaries between RSs. =20 I think =E2=80=9Cwho gets to decide=E2=80=9D is an important = implementation detail for the WG to sort out. I don=E2=80=99t think we = have clear consensus for that right now and so we shouldn=E2=80=99t bake = an answer to that question in the charter. The text I=E2=80=99m = proposing allows us to address that question. >=20 >> - Support for directed, audience-restricted access requests >=20 > Can you please explain what this means? I understand "directed, = audience-restricted access tokens=E2=80=9D but what are a "directed, = audience-restricted access requests=E2=80=9D The =E2=80=9Ctoken=E2=80=9D is the result of the =E2=80=9Crequest=E2=80=9D= . So arguably, this could read =E2=80=9Caccess tokens=E2=80=9D instead = and mean basically the same thing. However, what I wanted to get at was = the protocol needs to have a way to identify directed access, whether in = the token itself or in the client=E2=80=99s request or in some = combination thereof. I=E2=80=99d be Ok with it saying =E2=80=9Caccess = tokens=E2=80=9D here because that at least allows the client to request = it. >=20 >>=20 >> I propose that we split these because I think the two of them are = useful separately, and considering them separately might influence how = we end up solving it overall. I understand that you=E2=80=99re looking = at a use case that combines both of them, and I think enabling that = makes some sense.=20 >=20 > Thanks for your proposal.=20 >=20 > best regards, > Torsten.=20 >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt = > wrote: >>>=20 >>> Hi Dick,=20 >>>=20 >>>> On 20. Mar 2020, at 01:57, Dick Hardt wrote: >>>>=20 >>>> Rereading the charter I would consider the proposed charter change: >>>>=20 >>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>>=20 >>>> To be covered by the two highlighted lines below: >>>>=20 >>>> Additionally, the delegation process will allow for: >>>>=20 >>>> - Fine-grained specification of access >>>> - Approval of AS attestation to identity claims >>>> - Approval of access to multiple resources and APIs in a single = interaction >>>> - Separation between the party authorizing access and the party = operating the client requesting access >>>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>>>=20 >>>> Torsten: Does the scope of fine-grained access combined with = approval of access to multiple resources cover your requirements? >>>=20 >>> I initially thought =E2=80=9CApproval of access to multiple = resources and APIs in a single interaction=E2=80=9D would do. But = obviously it doesn=E2=80=99t mention access tokens and the charter, in = general, is quiet regarding desired capabilities for token issuance and = relationships between access tokens and resources. =20 >>>=20 >>> It also became obvious during the recent discussions there are = different interpretations, expectations, and objectives.=20 >>>=20 >>> I therefore think another bullet to explicitly spell this out makes = a lot of sense.=20 >>>=20 >>> In order to cover more use cases and be more explicit at the same = time, I suggest the following wording: >>>=20 >>> - Support for directed, audience-restricted access tokens in = multi-RS deployments at client or AS discretion >>>=20 >>>>=20 >>>> Note that we are not stating how we do it, just what is in scope. >>>=20 >>> Absolutely, I can think of various ways to implement it, but = that=E2=80=99s another step. First we need to agree on the objectives.=20= >>>=20 >>> thanks, >>> Torsten.=20 >>>=20 >>>>=20 >>>> /Dick >>>>=20 >>>> On Thu, Mar 19, 2020 at 1:48 PM Justin Richer = wrote: >>>> On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = wrote: >>>>>=20 >>>>>> Am 19.03.2020 um 21:07 schrieb Justin Richer : >>>>>>=20 >>>>>> =EF=BB=BFI think this is already in scope in the ways that I=E2=80=99= ve described, >>>>>=20 >>>>> Given our recent discussion, I don=E2=80=99t see how it is already = in scope=20 >>>>=20 >>>> What I mean is that a client can already ask for separate tokens = and use the =E2=80=9Cresources=E2=80=9D block to describe which resource = servers it wants. However, right now, it=E2=80=99s up to the client to = determine what the split is =E2=80=94 either by asking for separate = tokens in either the single-token format (with multiple requests) or = multi-token format (with a single request).=20 >>>>=20 >>>>>=20 >>>>>> with the caveat that identifying "the RS" is really, really hard = to do. >>>>>=20 >>>>> I don=E2=80=99t think it=E2=80=99s difficult to use URLs to = identify at least =E2=80=9Edestinations=E2=80=9C, it works for cookies = as well.=20 >>>>=20 >>>> I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99= m trying to push back against optimizing for that one kind of identity. = And cookies have all kinds of rules for paths and domains and origins = that protect them, so if that=E2=80=99s the model we=E2=80=99re arguing = for we need to at least consider all of that. We also need to consider = that cookies fail in a lot of ways! :) >>>>=20 >>>>>=20 >>>>>> What if instead it=E2=80=99s: >>>>>>=20 >>>>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>>>>=20 >>>>>> Would that work? To me the difference is that it=E2=80=99s = getting away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and = more towards the notion of getting a token directed to a specific set of = actions and/or locations. >>>>>=20 >>>>> wfm, as long it is clear the AS/RS determines the boundaries. >>>>=20 >>>> Ultimately they always do, and they=E2=80=99ll always need to deal = with the situation where a client asks for rights that cross boundaries. = The question is what to do in those situations, and I think there=E2=80=99= s a lot more discussion we need to have on that front! Do we allow the = AS to split a token request, do we have errors for this, do we have a = client indicate that it can receive split tokens =E2=80=A6 etc. I think = it=E2=80=99s an interesting area, but complex and not nearly as = clean-cut as your own use case and deployment might let it be. >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>>=20 >>>>> best regards, >>>>> Torsten. >>>>>=20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: >>>>>>>=20 >>>>>>> Hi all, >>>>>>>=20 >>>>>>> I suggest to add the following requirement to the charter: >>>>>>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >>>>>>>=20 >>>>>>> I don=E2=80=99t mind HOW this requirement is supported in = TXAuth. I want to make sure we try to build a protocol that serves the = needs of a broad set of deployments. My concern is otherwise TXAuth will = be not innovative enough to gain traction in the market rapidly. = Speaking for myself, I realised in the last couple of days, mostly in = conversations with Justin, that the result of this working group as = envisioned now is not of particular interest to us (yes.com) because it = does not solve our real problems.=20 >>>>>>>=20 >>>>>>> And here is my explanation:=20 >>>>>>>=20 >>>>>>> OAuth traditionally has the philosophy of a single access token. = That=E2=80=99s fine for single service deployments, but it had reached = its limits already before RFC6749 was published. There are a real = implementations out there forcing clients to use different access tokens = for different services, typically for privacy and security reasons. = There is also an =E2=80=9Cancient" technology called Kerberos that uses = exactly this pattern and is well known for security, performance, and = scalability.=20 >>>>>>>=20 >>>>>>> And there are even more examples today for multi API = environments that would benefit from that feature:=20 >>>>>>> =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! >>>>>>> =E2=80=A2 Everyone is doing micro services today. Have you = every thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. >>>>>>> =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. >>>>>>>=20 >>>>>>> Since we are preparing to define a completely new protocol for = API access authorization and delegation, I think this new protocol = should support this kind of scenarios. It will require significant work = to get it right and simple, but if we just stick to the =E2=80=9Ca = single access token is enough=E2=80=9D mantra, we miss the chance to = give implementers a broader range of design choices out of the box and = we won=E2=80=99t success in achieving true interoperability. >>>>>>>=20 >>>>>>> Here are more advantages we can gain by supporting such a = feature:=20 >>>>>>> =E2=80=A2 Privacy: >>>>>>> =E2=80=A2 A single access token can be used to track user = across services. >>>>>>> =E2=80=A2 RS-specific access tokens cannot. >>>>>>> =E2=80=A2 RS-specific access tokens can also be encrypted = to protect data confidentiality in transit. >>>>>>> =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. >>>>>>> =E2=80=A2 Performance: RS-specific access tokens allow the AS = to convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >>>>>>>=20 >>>>>>> What do you think? >>>>>>>=20 >>>>>>> best regards, >>>>>>> Torsten.=20 >>>>>>>=20 >>>>>>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>>>>>>>> On 19. Mar 2020, at 17:47, Justin Richer = wrote: >>>>>>>>>> Well, it=E2=80=99s in scope as much as describing any other = aspect of what the token is for and what it represents is in scope. That = is alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>>>>>>>=20 >>>>>>>>>> But here=E2=80=99s the thing: none of that has an impact on = the core protocol. That is entirely up to the AS and the RS to agree on, = and the client never sees or has any influence on it. That portion of = the protocol is completely opaque to the client. Therefore, it doesn=E2=80= =99t really affect the authorization and delegation portions of the = client talking to the AS and the client talking to the RS. >>>>>>>>>>=20 >>>>>>>>>> This does raise the question of what our bar of = interoperability is going to be with TxAuth: do we expect independent AS = and RS implementations to talk to each other? That=E2=80=99s not = something OAuth 2 was ever concerned with, though obviously JWT and = introspection are both from the OAuth2 WG and solve that problem. >>>>>>>>> There are two aspects to it: interoperability and vendor = support.=20 >>>>>>>>>=20 >>>>>>>>> Interoperability between AS and RS is important if deployments = want to combine pre-packaged TXAuth and API implementations. I think = that makes a lot of sense and should be included in the charter. >>>>>>>>=20 >>>>>>>> +1 >>>>>>>>=20 >>>>>>>> The current OAuth 2.0 status quo of the largely unspecified = relationship >>>>>>>> between AS and RS is also making the life of web & sec = framework >>>>>>>> maintainers difficult. We witnessing this with people = integrating the >>>>>>>> OAuth SDK into frameworks. Vittorio's recent work to put = together a >>>>>>>> minimal interoperable JWT profile for access tokens is helpful, = but it >>>>>>>> has come after the fact. And there is not agreement on things = like >>>>>>>> authorising access to claims. >>>>>>>>=20 >>>>>>>> Integrating apps (RSs) with TxAuth should be straightforward = and simple. >>>>>>>>=20 >>>>>>>> This can have a enormous effect on adoption. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Vendors support: vendor support when it comes to "what can go = into an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>>>>>>>=20 >>>>>>>> +1 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I also think it is a good exercise for the group to think the = whole process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) = is not to provide clients with access tokens. The purpose is to enable = API request processing in a secure manner. What it really takes to = achieve that goal is not obvious if the work always stops at the =E2=80=9C= you have your access token, good luck=E2=80=9D stage.=20 >>>>>>>>=20 >>>>>>>> +1 >>>>>>>>=20 >>>>>>>> Vladimir >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Txauth mailing list >>>>>>>> Txauth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>=20 >>>>>>> --=20 >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>=20 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>=20 >=20 --Apple-Mail=_3DA964F1-E4A8-4E53-A7D2-87B15045C3F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Mar 21, 2020, at 2:31 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Justin, 

On 21. = Mar 2020, at 17:46, Justin Richer <jricher@mit.edu> wrote:

Torsten, what if we walk that back to:

 - Support for multiple access tokens in a single = request

I = think this should be a requirements wrt the response and needs text = about who determines the split.

=E2=80=9C=E2=80=A6  in a single = response at the discretion of the AS or as requested by the client=E2=80=9D= seems appropriate in my opinion.

Note: this slightly reduces the = solution space since it would not allow to implement RS-specific access = tokens in Multi RS setups using the =E2=80=9Csuper refresh token" = pattern. That=E2=80=99s fine with me since I anyway believe issuing all = access tokens at once is easier to handle for the client. The =E2=80=9Csup= er refresh token=E2=80=9D pattern in contrast requires the client to = know the boundaries between RSs. =  

I think =E2=80=9Cwho gets to decide=E2=80=9D is an = important implementation detail for the WG to sort out. I don=E2=80=99t = think we have clear consensus for that right now and so we shouldn=E2=80=99= t bake an answer to that question in the charter. The text I=E2=80=99m = proposing allows us to address that question.


 - Support for directed, = audience-restricted access requests

Can you please explain what this means? I understand = "directed, audience-restricted access tokens=E2=80=9D but what are a = "directed, audience-restricted access requests=E2=80=9D

The =E2=80=9Ctoken=E2=80=9D is the result of the = =E2=80=9Crequest=E2=80=9D. So arguably, this could read =E2=80=9Caccess = tokens=E2=80=9D instead and mean basically the same thing. However, what = I wanted to get at was the protocol needs to have a way to identify = directed access, whether in the token itself or in the client=E2=80=99s = request or in some combination thereof. I=E2=80=99d be Ok with it saying = =E2=80=9Caccess tokens=E2=80=9D here because that at least allows the = client to request it.



I propose that we split these because I think the two of them = are useful separately, and considering them separately might influence = how we end up solving it overall. I understand that you=E2=80=99re = looking at a use case that combines both of them, and I think = enabling that makes some sense. 

Thanks for your = proposal. 

best regards,
Torsten. 


 =E2=80=94 Justin

On Mar 21, 2020, at 9:18 AM, Torsten = Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Dick, 

On = 20. Mar 2020, at 01:57, Dick Hardt <dick.hardt@gmail.com> wrote:

Rereading the charter I would consider the proposed charter = change:

- Support for directed, = audience-restricted access tokens in multi-RS deployments

To be covered by the two highlighted lines = below:

Additionally, the delegation process = will allow for:

- Fine-grained = specification of access
- Approval of AS attestation to = identity claims
- Approval of access to multiple resources = and APIs in a single interaction
- Separation between the = party authorizing access and the party operating the client requesting = access
- A variety of client applications, including Web, = mobile, single-page, and interaction-constrained applications

Torsten: Does the scope of fine-grained access = combined with approval of access to multiple resources cover your = requirements?

I initially = thought =E2=80=9CApproval of access to multiple resources and APIs in a = single interaction=E2=80=9D would do. But obviously it doesn=E2=80=99t = mention access tokens and the charter, in general, is quiet regarding = desired capabilities for token issuance and relationships between = access tokens and resources.  

It also = became obvious during the recent discussions there are different = interpretations, expectations, and objectives. 

I therefore think another bullet to explicitly spell this out = makes a lot of sense. 

In order to = cover more use cases and be more explicit at the same time, I suggest = the following wording:

- Support for = directed, audience-restricted access tokens in multi-RS deployments at = client or AS discretion


Note that we are not stating how we do it, just what is in = scope.

Absolutely, I can think = of various ways to implement it, but that=E2=80=99s another step. First = we need to agree on the objectives. 

thanks,
Torsten. 


/Dick

On Thu, Mar 19, 2020 at = 1:48 PM Justin Richer <jricher@mit.edu> wrote:
On Mar 19, 2020, = at 4:41 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Am 19.03.2020 um 21:07 schrieb Justin Richer = <jricher@mit.edu>:

=EF=BB=BF= I think this is already in scope in the ways that I=E2=80=99ve = described,

Given our recent = discussion, I don=E2=80=99t see how it is already in scope 

What I mean is that a client can = already ask for separate tokens and use the =E2=80=9Cresources=E2=80=9D = block to describe which resource servers it wants. However, right now, = it=E2=80=99s up to the client to determine what the split is =E2=80=94 = either by asking for separate tokens in either the single-token = format (with multiple requests) or multi-token format (with a single = request). 


with the = caveat that identifying "the RS" is really, really hard to do.

I don=E2=80=99t think it=E2=80=99s = difficult to use URLs to identify at least =E2=80=9Edestinations=E2=80=9C,= it works for cookies as well. 

I think that=E2=80=99s an aspect, but not the only aspect. = I=E2=80=99m trying to push back against optimizing for that one kind of = identity. And cookies have all kinds of rules for paths and domains and = origins that protect them, so if that=E2=80=99s the model we=E2=80=99re = arguing for we need to at least consider all of that. We also need = to consider that cookies fail in a lot of ways! :)


What if instead it=E2=80=99s:

- Support for directed, audience-restricted access tokens in = multi-RS deployments

Would that work? To me = the difference is that it=E2=80=99s getting away from a fixed notion of = what an =E2=80=9CRS=E2=80=9D is and more towards the notion of getting a = token directed to a specific set of actions and/or locations.

wfm, as long it is clear the = AS/RS determines the boundaries.

Ultimately they always do, and they=E2=80=99ll always need to = deal with the situation where a client asks for rights that cross = boundaries. The question is what to do in those situations, and I think = there=E2=80=99s a lot more discussion we need to have on that front! Do = we allow the AS to split a token request, do we have errors for = this, do we have a client indicate that it can receive split tokens =E2=80= =A6 etc. I think it=E2=80=99s an interesting area, but complex and not = nearly as clean-cut as your own use case and deployment might let it = be.

=E2=80=94 Justin


best = regards,
Torsten.


=E2=80=94 Justin
On Mar 19, 2020, at = 2:08 PM, Torsten Lodderstedt <torsten=3D40lodderstedt.net@dmarc.ietf.org> wrote:

Hi all,

I suggest = to add the following requirement to the charter:
 =E2=80= =A2 Support for RS-specific access tokens in Multi-RS = deployments 

I don=E2=80=99t mind HOW = this requirement is supported in TXAuth. I want to make sure we try to = build a protocol that serves the needs of a broad set of deployments. My = concern is otherwise TXAuth will be not innovative enough to gain = traction in the market rapidly. Speaking for myself, I realised in = the last couple of days, mostly in conversations with Justin, that the = result of this working group as envisioned now is not of particular = interest to us (yes.com) = because it does not solve our real problems. 

And here is my explanation: 

OAuth traditionally has the philosophy of a single access = token. That=E2=80=99s fine for single service deployments, but it had = reached its limits already before RFC6749 was published. There are a = real implementations out there forcing clients to use = different access tokens for different services, typically for = privacy and security reasons. There is also an =E2=80=9Cancient" = technology called Kerberos that uses exactly this pattern and is well = known for security, performance, and scalability. 

And there are even more examples today for multi API = environments that would benefit from that feature: 
 =E2=80=A2 Open banking: most banks I worked with have = multiple APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX!
 =E2=80=A2 Everyone is doing micro services today. Have = you every thought about the coupling caused by a single token across = micro services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens.
 =E2=80=A2 IoT - every device in a household is a = potential RS (in my opinion). Conveying all necessary data in an access = token needed to meet access control decisions locally would be a huge = benefit in terms of performance and decoupling. Using = symmetric cryptography for token integrity, authenticity and = confidentiality would result in lower compute requirements.

Since we are preparing to define a completely = new protocol for API access authorization and delegation, I think this = new protocol should support this kind of scenarios. It will require = significant work to get it right and simple, but if we just stick to the = =E2=80=9Ca single access token is enough=E2=80=9D mantra, we miss = the chance to give implementers a broader range of design choices out of = the box and we won=E2=80=99t success in achieving true = interoperability.

Here are more advantages = we can gain by supporting such a feature: 
 =E2=80= =A2 Privacy:
     =E2=80=A2 A single access = token can be used to track user across services.
  =    =E2=80=A2 RS-specific access tokens cannot.
     =E2=80=A2 RS-specific access tokens can = also be encrypted to protect data confidentiality in transit.
 =E2=80=A2 Security: RS-specific access tokens have a = baseline replay detection.
 =E2=80=A2 Performance: = RS-specific access tokens allow the AS to convey all data required to = authorize an API call in a token (e.g. a JWT) and to RS to meet the = access control decision based on that data. This is a huge advantage in = terms of performance, scalability and cost since there is no need = for Token Introspection or other kinds of access to another services or = database.

What do you think?

best regards,
Torsten. 

On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:


On 19/03/2020 = 19:11, Torsten Lodderstedt wrote:
On 19. Mar 2020, at 17:47, Justin Richer <jricher@mit.edu> = wrote:
Well, it=E2=80=99= s in scope as much as describing any other aspect of what the token is = for and what it represents is in scope. That is alongside things like = the intended audience of the token, the access rights for the token, the = presentation keys the token is bound to, etc. It could be = information in the token text itself (like a JWT), it could be = introspected from the AS, it could be referenced in some other way. So = if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there. 

But here=E2=80=99s = the thing: none of that has an impact on the core protocol. That is = entirely up to the AS and the RS to agree on, and the client never sees = or has any influence on it. That portion of the protocol is completely = opaque to the client. Therefore, it doesn=E2=80=99t really affect = the authorization and delegation portions of the client talking to the = AS and the client talking to the RS.

This = does raise the question of what our bar of interoperability is going to = be with TxAuth: do we expect independent AS and RS implementations to = talk to each other? That=E2=80=99s not something OAuth 2 was ever = concerned with, though obviously JWT and introspection are both = from the OAuth2 WG and solve that problem.
There are two aspects to it: interoperability = and vendor support. 

Interoperability = between AS and RS is important if deployments want to combine = pre-packaged TXAuth and API implementations. I think that makes a lot of = sense and should be included in the charter.

+1

The= current OAuth 2.0 status quo of the largely unspecified relationship
between AS and RS is also making the life of web & sec = framework
maintainers difficult. We witnessing this with = people integrating the
OAuth SDK into frameworks. = Vittorio's recent work to put together a
minimal = interoperable JWT profile for access tokens is helpful, but it
has come after the fact. And there is not agreement on things = like
authorising access to claims.

Integrating apps (RSs) with TxAuth should be straightforward = and simple.

This can have a enormous effect = on adoption.


Vendors support: vendor support when it comes = to "what can go into an access token" and "what can be conveyed in a = token introspection response=E2=80=9D greatly deviates in my = observation. This also means implementation use vendors = specific features restricting their ability to use other solutions. = TXAuth should aim at improving the situation.  

+1

I also think it is a = good exercise for the group to think the whole process "from the end=E2=80= =9D. The purpose of TXAuth (and OAuth) is not to provide clients with = access tokens. The purpose is to enable API request processing in a = secure manner. What it really takes to achieve that goal is not = obvious if the work always stops at the =E2=80=9Cyou have your access = token, good luck=E2=80=9D stage. 

+1

Vladimir


-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth



= --Apple-Mail=_3DA964F1-E4A8-4E53-A7D2-87B15045C3F1-- From nobody Sat Mar 21 11:46:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756C63A08AE for ; Sat, 21 Mar 2020 11:46:02 -0700 (PDT) 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=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 viA-pWUUbsbj for ; Sat, 21 Mar 2020 11:45:57 -0700 (PDT) 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 89B8C3A08AA for ; Sat, 21 Mar 2020 11:45:56 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id s1so11556075wrv.5 for ; Sat, 21 Mar 2020 11:45:56 -0700 (PDT) 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=5fkndZNbsapHHUQ1g64lxYgp6Jdyo9erVVpIPDmxwRE=; b=H2MMFF9rbm0ATkL4PBJ1jMF8TEYTvyMYgcJ90hF5SgsDtITwF04dyOdE76Yw/x30zo BX+zpdaHS+2TKghwJi0Ehg9OC3w9X4S6K1tbqbHUF4TfsugBPXF1rs88HIt7bRS8LC2n VMZGCjEft20S7j7v6LlZXV1+aZzUJAcfOwrk0KJCuRC7unkH5hlLj5h/+Cf9BEGukTvo BoAJaN4DVyxCR5HN5FgH4PIV28tRTPsl2zgqcFCaRlamwj14wrzSzw9JBKFqN0aJvWtl N3BZVgChCKAumLHA8vpTgbHlCaop7UVxVNr9h2ekCOyI3gYltE9XbWOfDj88uqkKeN3u az8w== 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=5fkndZNbsapHHUQ1g64lxYgp6Jdyo9erVVpIPDmxwRE=; b=IQ6nUVIigRodFOkJxlSzlnCx1EYHXIAlMamoxskq+5rpJG3d+UXQnqKwnJuhQNVY3n BHWWBkMyIN0tqi3iA1v/UMmsX9qWn/SIJMc1Kmb5glKalWhzdNPb74N1OK7vSarczcFs WYD7CJSVFg38zrzf7Kmz7j0CU6ODP0xtXCOj4aaxeDsaHTVsyrL/nd9jJah3V97RrOik Erfuy+njiGsKaVYbpNFno1ARhqJeYNTr8omh5FGj2tMz+GvZn6Nb9mhkJikPUgFL3Nkx 9+bVvELl2aXwLyU4YngIPa+kCGY5o9JFOl5N6KgQKyKt9AuC+z6v+BWFl3jgljDGXNS1 N/kA== X-Gm-Message-State: ANhLgQ2F5svPBzrPTVIW6WKbWQRU4EwLgDdgzEoJZ/t4EsgtjSCGbN/8 1tS3RebvL1/SuzRIiEfU2V3pGQ== X-Google-Smtp-Source: ADFU+vvZmSkS5onzwjMKhj0Uu/KokxknnlDpiLB6MAmRwFnMhbpOj+WxHPEb4qNj4EyNUIKjVHIdVQ== X-Received: by 2002:a5d:4e05:: with SMTP id p5mr19007409wrt.59.1584816354296; Sat, 21 Mar 2020 11:45:54 -0700 (PDT) Received: from p200300eb8f2625ca05c39e1b37cae8fc.dip0.t-ipconnect.de (p200300EB8F2625CA05C39E1B37CAE8FC.dip0.t-ipconnect.de. [2003:eb:8f26:25ca:5c3:9e1b:37ca:e8fc]) by smtp.gmail.com with ESMTPSA id s7sm14223210wri.61.2020.03.21.11.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2020 11:45:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Sat, 21 Mar 2020 19:45:52 +0100 Cc: Dick Hardt , txauth@ietf.org, Torsten Lodderstedt , Vladimir Dzhuvinov Content-Transfer-Encoding: quoted-printable Message-Id: References: <80AE3B0D-C51D-4F9C-9996-6563D857248B@mit.edu> <07EA221E-FA0D-4381-80E9-DB138C9E260C@lodderstedt.net> To: Justin Richer X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:46:03 -0000 > On 21. Mar 2020, at 19:41, Justin Richer wrote: >=20 > On Mar 21, 2020, at 2:31 PM, Torsten Lodderstedt = wrote: >>=20 >> Justin,=20 >>=20 >>> On 21. Mar 2020, at 17:46, Justin Richer wrote: >>>=20 >>> Torsten, what if we walk that back to: >>>=20 >>> - Support for multiple access tokens in a single request >>=20 >> I think this should be a requirements wrt the response and needs text = about who determines the split. >>=20 >> =E2=80=9C=E2=80=A6 in a single response at the discretion of the AS = or as requested by the client=E2=80=9D seems appropriate in my opinion. >>=20 >> Note: this slightly reduces the solution space since it would not = allow to implement RS-specific access tokens in Multi RS setups using = the =E2=80=9Csuper refresh token" pattern. That=E2=80=99s fine with me = since I anyway believe issuing all access tokens at once is easier to = handle for the client. The =E2=80=9Csuper refresh token=E2=80=9D pattern = in contrast requires the client to know the boundaries between RSs. =20 >=20 > I think =E2=80=9Cwho gets to decide=E2=80=9D is an important = implementation detail for the WG to sort out. If it would be an implementation detail, we would not be arguing about = it for a week now.=20 It=E2=80=99s obviously not an implementation detail but a key protocol = requirement. So the WG needs to decide now whether it is part of the = scope or not.=20 > I don=E2=80=99t think we have clear consensus for that right now and = so we shouldn=E2=80=99t bake an answer to that question in the charter. = The text I=E2=80=99m proposing allows us to address that question. >=20 >>=20 >>> - Support for directed, audience-restricted access requests >>=20 >> Can you please explain what this means? I understand "directed, = audience-restricted access tokens=E2=80=9D but what are a "directed, = audience-restricted access requests=E2=80=9D >=20 > The =E2=80=9Ctoken=E2=80=9D is the result of the =E2=80=9Crequest=E2=80=9D= . So arguably, this could read =E2=80=9Caccess tokens=E2=80=9D instead = and mean basically the same thing. However, what I wanted to get at was = the protocol needs to have a way to identify directed access, whether in = the token itself or in the client=E2=80=99s request or in some = combination thereof. I=E2=80=99d be Ok with it saying =E2=80=9Caccess = tokens=E2=80=9D here because that at least allows the client to request = it. >=20 >>=20 >>>=20 >>> I propose that we split these because I think the two of them are = useful separately, and considering them separately might influence how = we end up solving it overall. I understand that you=E2=80=99re looking = at a use case that combines both of them, and I think enabling that = makes some sense.=20 >>=20 >> Thanks for your proposal.=20 >>=20 >> best regards, >> Torsten.=20 >>=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt = wrote: >>>>=20 >>>> Hi Dick,=20 >>>>=20 >>>>> On 20. Mar 2020, at 01:57, Dick Hardt = wrote: >>>>>=20 >>>>> Rereading the charter I would consider the proposed charter = change: >>>>>=20 >>>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>>>=20 >>>>> To be covered by the two highlighted lines below: >>>>>=20 >>>>> Additionally, the delegation process will allow for: >>>>>=20 >>>>> - Fine-grained specification of access >>>>> - Approval of AS attestation to identity claims >>>>> - Approval of access to multiple resources and APIs in a single = interaction >>>>> - Separation between the party authorizing access and the party = operating the client requesting access >>>>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >>>>>=20 >>>>> Torsten: Does the scope of fine-grained access combined with = approval of access to multiple resources cover your requirements? >>>>=20 >>>> I initially thought =E2=80=9CApproval of access to multiple = resources and APIs in a single interaction=E2=80=9D would do. But = obviously it doesn=E2=80=99t mention access tokens and the charter, in = general, is quiet regarding desired capabilities for token issuance and = relationships between access tokens and resources. =20 >>>>=20 >>>> It also became obvious during the recent discussions there are = different interpretations, expectations, and objectives.=20 >>>>=20 >>>> I therefore think another bullet to explicitly spell this out makes = a lot of sense.=20 >>>>=20 >>>> In order to cover more use cases and be more explicit at the same = time, I suggest the following wording: >>>>=20 >>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments at client or AS discretion >>>>=20 >>>>>=20 >>>>> Note that we are not stating how we do it, just what is in scope. >>>>=20 >>>> Absolutely, I can think of various ways to implement it, but = that=E2=80=99s another step. First we need to agree on the objectives.=20= >>>>=20 >>>> thanks, >>>> Torsten.=20 >>>>=20 >>>>>=20 >>>>> /Dick >>>>>=20 >>>>> On Thu, Mar 19, 2020 at 1:48 PM Justin Richer = wrote: >>>>> On Mar 19, 2020, at 4:41 PM, Torsten Lodderstedt = wrote: >>>>>>=20 >>>>>>> Am 19.03.2020 um 21:07 schrieb Justin Richer : >>>>>>>=20 >>>>>>> =EF=BB=BFI think this is already in scope in the ways that = I=E2=80=99ve described, >>>>>>=20 >>>>>> Given our recent discussion, I don=E2=80=99t see how it is = already in scope=20 >>>>>=20 >>>>> What I mean is that a client can already ask for separate tokens = and use the =E2=80=9Cresources=E2=80=9D block to describe which resource = servers it wants. However, right now, it=E2=80=99s up to the client to = determine what the split is =E2=80=94 either by asking for separate = tokens in either the single-token format (with multiple requests) or = multi-token format (with a single request).=20 >>>>>=20 >>>>>>=20 >>>>>>> with the caveat that identifying "the RS" is really, really hard = to do. >>>>>>=20 >>>>>> I don=E2=80=99t think it=E2=80=99s difficult to use URLs to = identify at least =E2=80=9Edestinations=E2=80=9C, it works for cookies = as well.=20 >>>>>=20 >>>>> I think that=E2=80=99s an aspect, but not the only aspect. I=E2=80=99= m trying to push back against optimizing for that one kind of identity. = And cookies have all kinds of rules for paths and domains and origins = that protect them, so if that=E2=80=99s the model we=E2=80=99re arguing = for we need to at least consider all of that. We also need to consider = that cookies fail in a lot of ways! :) >>>>>=20 >>>>>>=20 >>>>>>> What if instead it=E2=80=99s: >>>>>>>=20 >>>>>>> - Support for directed, audience-restricted access tokens in = multi-RS deployments >>>>>>>=20 >>>>>>> Would that work? To me the difference is that it=E2=80=99s = getting away from a fixed notion of what an =E2=80=9CRS=E2=80=9D is and = more towards the notion of getting a token directed to a specific set of = actions and/or locations. >>>>>>=20 >>>>>> wfm, as long it is clear the AS/RS determines the boundaries. >>>>>=20 >>>>> Ultimately they always do, and they=E2=80=99ll always need to deal = with the situation where a client asks for rights that cross boundaries. = The question is what to do in those situations, and I think there=E2=80=99= s a lot more discussion we need to have on that front! Do we allow the = AS to split a token request, do we have errors for this, do we have a = client indicate that it can receive split tokens =E2=80=A6 etc. I think = it=E2=80=99s an interesting area, but complex and not nearly as = clean-cut as your own use case and deployment might let it be. >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>>=20 >>>>>> best regards, >>>>>> Torsten. >>>>>>=20 >>>>>>>=20 >>>>>>> =E2=80=94 Justin >>>>>>>=20 >>>>>>>> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt = wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> I suggest to add the following requirement to the charter: >>>>>>>> =E2=80=A2 Support for RS-specific access tokens in Multi-RS = deployments=20 >>>>>>>>=20 >>>>>>>> I don=E2=80=99t mind HOW this requirement is supported in = TXAuth. I want to make sure we try to build a protocol that serves the = needs of a broad set of deployments. My concern is otherwise TXAuth will = be not innovative enough to gain traction in the market rapidly. = Speaking for myself, I realised in the last couple of days, mostly in = conversations with Justin, that the result of this working group as = envisioned now is not of particular interest to us (yes.com) because it = does not solve our real problems.=20 >>>>>>>>=20 >>>>>>>> And here is my explanation:=20 >>>>>>>>=20 >>>>>>>> OAuth traditionally has the philosophy of a single access = token. That=E2=80=99s fine for single service deployments, but it had = reached its limits already before RFC6749 was published. There are a = real implementations out there forcing clients to use different access = tokens for different services, typically for privacy and security = reasons. There is also an =E2=80=9Cancient" technology called Kerberos = that uses exactly this pattern and is well known for security, = performance, and scalability.=20 >>>>>>>>=20 >>>>>>>> And there are even more examples today for multi API = environments that would benefit from that feature:=20 >>>>>>>> =E2=80=A2 Open banking: most banks I worked with have multiple = APIs, segregation between APIs is today achieved by maintaining = different grants, basically resulting in the fact that the users cannot = consent to different services at once. What a terrible UX! >>>>>>>> =E2=80=A2 Everyone is doing micro services today. Have you = every thought about the coupling caused by a single token across micro = services? This reminds me of how easy it is to test services = independently using self-contained RS-specific tokens. >>>>>>>> =E2=80=A2 IoT - every device in a household is a potential RS = (in my opinion). Conveying all necessary data in an access token needed = to meet access control decisions locally would be a huge benefit in = terms of performance and decoupling. Using symmetric cryptography for = token integrity, authenticity and confidentiality would result in lower = compute requirements. >>>>>>>>=20 >>>>>>>> Since we are preparing to define a completely new protocol for = API access authorization and delegation, I think this new protocol = should support this kind of scenarios. It will require significant work = to get it right and simple, but if we just stick to the =E2=80=9Ca = single access token is enough=E2=80=9D mantra, we miss the chance to = give implementers a broader range of design choices out of the box and = we won=E2=80=99t success in achieving true interoperability. >>>>>>>>=20 >>>>>>>> Here are more advantages we can gain by supporting such a = feature:=20 >>>>>>>> =E2=80=A2 Privacy: >>>>>>>> =E2=80=A2 A single access token can be used to track user = across services. >>>>>>>> =E2=80=A2 RS-specific access tokens cannot. >>>>>>>> =E2=80=A2 RS-specific access tokens can also be encrypted = to protect data confidentiality in transit. >>>>>>>> =E2=80=A2 Security: RS-specific access tokens have a baseline = replay detection. >>>>>>>> =E2=80=A2 Performance: RS-specific access tokens allow the AS = to convey all data required to authorize an API call in a token (e.g. a = JWT) and to RS to meet the access control decision based on that data. = This is a huge advantage in terms of performance, scalability and cost = since there is no need for Token Introspection or other kinds of access = to another services or database. >>>>>>>>=20 >>>>>>>> What do you think? >>>>>>>>=20 >>>>>>>> best regards, >>>>>>>> Torsten.=20 >>>>>>>>=20 >>>>>>>>>> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov = wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 19/03/2020 19:11, Torsten Lodderstedt wrote: >>>>>>>>>> On 19. Mar 2020, at 17:47, Justin Richer = wrote: >>>>>>>>>>> Well, it=E2=80=99s in scope as much as describing any other = aspect of what the token is for and what it represents is in scope. That = is alongside things like the intended audience of the token, the access = rights for the token, the presentation keys the token is bound to, etc. = It could be information in the token text itself (like a JWT), it could = be introspected from the AS, it could be referenced in some other way. = So if we can define identity aspects in that, then we=E2=80=99re fine in = covering it there.=20 >>>>>>>>>>>=20 >>>>>>>>>>> But here=E2=80=99s the thing: none of that has an impact on = the core protocol. That is entirely up to the AS and the RS to agree on, = and the client never sees or has any influence on it. That portion of = the protocol is completely opaque to the client. Therefore, it doesn=E2=80= =99t really affect the authorization and delegation portions of the = client talking to the AS and the client talking to the RS. >>>>>>>>>>>=20 >>>>>>>>>>> This does raise the question of what our bar of = interoperability is going to be with TxAuth: do we expect independent AS = and RS implementations to talk to each other? That=E2=80=99s not = something OAuth 2 was ever concerned with, though obviously JWT and = introspection are both from the OAuth2 WG and solve that problem. >>>>>>>>>> There are two aspects to it: interoperability and vendor = support.=20 >>>>>>>>>>=20 >>>>>>>>>> Interoperability between AS and RS is important if = deployments want to combine pre-packaged TXAuth and API implementations. = I think that makes a lot of sense and should be included in the charter. >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>>=20 >>>>>>>>> The current OAuth 2.0 status quo of the largely unspecified = relationship >>>>>>>>> between AS and RS is also making the life of web & sec = framework >>>>>>>>> maintainers difficult. We witnessing this with people = integrating the >>>>>>>>> OAuth SDK into frameworks. Vittorio's recent work to put = together a >>>>>>>>> minimal interoperable JWT profile for access tokens is = helpful, but it >>>>>>>>> has come after the fact. And there is not agreement on things = like >>>>>>>>> authorising access to claims. >>>>>>>>>=20 >>>>>>>>> Integrating apps (RSs) with TxAuth should be straightforward = and simple. >>>>>>>>>=20 >>>>>>>>> This can have a enormous effect on adoption. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> Vendors support: vendor support when it comes to "what can go = into an access token" and "what can be conveyed in a token introspection = response=E2=80=9D greatly deviates in my observation. This also means = implementation use vendors specific features restricting their ability = to use other solutions. TXAuth should aim at improving the situation. =20= >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> I also think it is a good exercise for the group to think the = whole process "from the end=E2=80=9D. The purpose of TXAuth (and OAuth) = is not to provide clients with access tokens. The purpose is to enable = API request processing in a secure manner. What it really takes to = achieve that goal is not obvious if the work always stops at the =E2=80=9C= you have your access token, good luck=E2=80=9D stage.=20 >>>>>>>>>=20 >>>>>>>>> +1 >>>>>>>>>=20 >>>>>>>>> Vladimir >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Txauth mailing list >>>>>>>>> Txauth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Txauth mailing list >>>>>>>> Txauth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>>>=20 >>>>>>> --=20 >>>>>>> Txauth mailing list >>>>>>> Txauth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>>=20 >>>>> --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth From nobody Sat Mar 21 11:46:48 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A473D3A08A9 for ; Sat, 21 Mar 2020 11:46:37 -0700 (PDT) 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 H-ICPrXyKVV8 for ; Sat, 21 Mar 2020 11:46:32 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 007C03A08A8 for ; Sat, 21 Mar 2020 11:46:31 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id o10so10068646ljc.8 for ; Sat, 21 Mar 2020 11:46:31 -0700 (PDT) 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=FKWADu/JZmmOc3y+9mHHAl+wzQ9fDaeO9q/RdjqkczE=; b=N5C0ulvp5XNxWdVSy1gnmG/abbIDFr4g1h+QPWKTRQfNmx/SxAXj4R/td976XG7r3E LhNLe2MvVbXBcJ63QiJMetDqG56nTRLx9aFfZNZvj4zSlsC98/ah64LxiM74lywx37LO iF9jSlUXth7HZ26pkbYlWqEf8riIPVxHYHHnyl3hxUG1vR9ObwAMkYoCaDb8j2lMTEmQ nXDQJp2dL9sBy0UkMFQO3VlLxUS8Gmeh8a1+wpA+Nc2+IeRDdAFGijrvgPpLmWN/1rMg GMMAgEFhvsaNvlFOHBRwuAk+9DZQb+E0HCYg1s6V/bZq3fzIwuKiX07grbewJpAg2NXP rXBg== 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=FKWADu/JZmmOc3y+9mHHAl+wzQ9fDaeO9q/RdjqkczE=; b=dmqf/UqzNaiKdVGlYsxGBJF53/sGrDyaAz7lDw5wTd4pkBzgs1+o0pr5UWi+62P8mX E4Z7VJUiCYqac/X0yv75YR7ifRx9xmAL9d0wL1IF9CfZugTJEie6KbyXboZlRABMZoMI NXXNrBq4g/evLX1mcAa2ohLdwkbZT2QbzI3mvoQ5O2EXpgJiLUkTNVbGRTk87zT7WhVP vaaIZTmZv4oS11Z1tSadUvaZzztDTh1c52+AhNdC4IC5MCHlinwlsUOYDs9lfZcx+RN9 YTT3CLuqUHc/ifxwDOO62P8XKgNFnJ2h6p7p9Jm8DM/sCKE6W0OcvhKYHJvodIHoZHoV 1ckg== X-Gm-Message-State: ANhLgQ0Cp2M3b7/dQ5fBGTQWNFmTZsV3wgGh3+BCNczW1qdMFCEC3hMB ianvufdEt5iBmaYEw/w+eGOEudGBYKy3CCtorS4= X-Google-Smtp-Source: ADFU+vvCYtNcwBfsxJv1jX91tvOhGL723lHUkXGqmbtVFY2/CQhw8rCndFPAIAXkqsqeJm+/cExI6YXYhWXQcqlBEwU= X-Received: by 2002:a2e:8518:: with SMTP id j24mr9143285lji.138.1584816389779; Sat, 21 Mar 2020 11:46:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 21 Mar 2020 11:46:03 -0700 Message-ID: To: Vijay IETF Cc: David Skaife , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000f2773505a161d15c" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 18:46:39 -0000 --000000000000f2773505a161d15c Content-Type: text/plain; charset="UTF-8" Hi Vijay Profiles are needed for *frameworks*, since no interop is required -- both parties need to support the same profile to interop. The current charter is developing a *protocol*, which requires interop. For example, SCIM does not specify which mechanism to use for the client to authenticate, which makes SCIM deployments more challenging to setup. I started the FastFed WG in the OpenID Foundation to deal with getting enterprise federations setup because there is no MTI, and missing discovery mechanisms. I hear your concerns for constrained environments of not wanting any more code than is needed, and that a given mechanism that is the better choice for mobile and PCs may be problematic for a constrained environment. On Sat, Mar 21, 2020 at 11:03 AM Vijay IETF wrote: > Hi Dick, > > Thanks. I think I understand the concern now. Response inline. > > On Sat, 21 Mar 2020 at 22:52, Dick Hardt wrote: > >> Hi Vijay >> >> >> >> If there is no default or minimum to implement (MTI) requirement, then >> for interop to be guaranteed between a client and an AS, one of the parties >> will need to support all of the choices since the other party could choose >> to support only one of the choices. In this work, we have tended to push >> complexity to the AS, so the AS would need to implement all choices to be >> compliant. >> >> If there is a default, then only the default MUST be implemented by both >> parties to be compliant. >> > > I get it. > > IMHO, your concern if it were to be the case is a lazy/inefficient way to > handle/attain interop compliance. I believe there is another way. We could > take inspiration from [Bluetooth Profiles]( > https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles). Each profile > could then specify the defaults that client and AS need to agree on. > > >> >> Of course, any bespoke implementation can do whatever they want. >> >> While you may not personally be a fan of general purpose software, others >> are, and as a group we need to anticipate the implications for all >> implementors. >> >> >> > I hear you. I just didn't have any better way to state my bias towards > XYZ's rationale in this instance. And I don't agree with a "global" default > being the normative recommendation. > > --- > Vijay > --000000000000f2773505a161d15c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vijay

Profiles are needed for fra= meworks, since no interop is required -- both parties need to support t= he same profile to interop.

The current charter is= =C2=A0developing a protocol, which requires interop.=C2=A0

For example, SCIM does not specify which mechanism to use f= or the client to authenticate, which makes SCIM deployments more challengin= g to setup. I started the FastFed WG in the OpenID Foundation to deal with = getting enterprise federations setup because there is no MTI, and missing d= iscovery mechanisms.

I hear your concerns for cons= trained environments of not wanting any more code than is needed, and that = a given mechanism that is the better choice for mobile and PCs may be probl= ematic for a constrained environment.=C2=A0



On Sat, Mar 21, 2020 at 11:03 AM Vijay IETF <vijay.ietf@gmail.com> wrote:
Hi Dick,

Thanks. I think I understand the concern= now. Response inline.

On Sat, 21 Mar 2020 at 22:52, Dick Hardt &l= t;dick.hardt@gmai= l.com> wrote:
Hi Vijay

<snip>
If there is no default or minimum to implement (MTI) requireme= nt, then for interop to be guaranteed between a client and an AS, one of th= e parties will need to support all of the choices since the other party cou= ld choose to support only one of the choices. In this work, we have tended = to push complexity to the AS, so the AS would need to implement all choices= to be compliant.=C2=A0

If there is a default, the= n only the default MUST be implemented by both parties to be compliant.

I get it.

IMHO, your concern if it were to be the case is a lazy/inefficient wa= y to handle/attain interop compliance. I believe there is another way. We c= ould take inspiration from [Bluetooth Profiles](https://en.wiki= pedia.org/wiki/List_of_Bluetooth_profiles). Each profile could then spe= cify the defaults that client and AS need to agree on.=C2=A0
=C2= =A0

Of course, any bespoke implementation can do whatever = they want.=C2=A0

While you may not personally be a= fan of general purpose software, others are, and as a group we need to ant= icipate the implications for all implementors.


I hear you. I just didn't= have any better way to state my bias towards XYZ's rationale in this i= nstance. And I don't agree with a "global" default being the = normative recommendation.

---
Vijay
--000000000000f2773505a161d15c-- From nobody Sat Mar 21 12:07:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F653A08C0 for ; Sat, 21 Mar 2020 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=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 HHL_AtRoQRbI for ; Sat, 21 Mar 2020 12:07:00 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450: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 5C3893A08B6 for ; Sat, 21 Mar 2020 11:59:48 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id n20so7085697lfl.10 for ; Sat, 21 Mar 2020 11:59:48 -0700 (PDT) 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=N0sKkSLNZeHKF2vnbE8VCWaeRU5qHDklZf5e26i616c=; b=iDCSwDfEX715GJfgpK6Yy9q+NMVSWdZDu8brs/qQtvO4QQM6M4/ef+/40cD40rCyRE GgJziVl+DBmwX6BtQn9tLrloVhJej3prxhmstOZLbYc5GIzhQ/RZQf0gZboCIkq3KkNF d3FQBHKU9bVrCXprm+nSt56lR8pK3pWrfHtSxpwO+cy4F4nRcP7xaFFrH1erhGd8nzhK sowF41B6wj6t8TiB0dGNLlF6OqIDNbjqnJW78EH27uqX/NqC/WAzZyirr7iGc+hhpN+E B9ZbrCZSI1bMzPumqZybcV/JOg/3Q4+caoKrshUcptxb62WA6r8DVKDhbBVELmFQeUcV 2zPQ== 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=N0sKkSLNZeHKF2vnbE8VCWaeRU5qHDklZf5e26i616c=; b=hjLioQ4SRyfSw7OInFWaJwRNZAJpGedZZEJi6s5aNo9A7teY3ZSsnhHH8usmRAvkH0 907sXvAhctVqOFCdheUp20SX/k5jDMuliXfe/2LtsCa1NKn7/3Vc6PMNUXRFY9zrB9mL wB/aSK9eakXdfloRVEICe8GjAhPqWqQG1kypXv7y6AKmjXBY5uVQCvdLdO2nBVMLErQe QGbM0yXxfEHCLOVkqrKYB+0km5v1Xwy/3WgAkgauNTNFf7enItPpntdJl2/VK3Mo26cb /XlXTCOgxoFPidmOGIFesg+dpCTniE7tAMfp+qrAAGJamdBztsZIf7HXjBMV5xLonDEl tUrQ== X-Gm-Message-State: ANhLgQ1Qy2DF1q4c7NZYkg4uEtQG+WbASATeoSOy5WvwpkJn23KpnXFb CZ1AEHAl52LWkRV+Be0KZpXBE3vjAuxk+MnYRBc= X-Google-Smtp-Source: ADFU+vsL18NmQJ4GMnco5Tt4oT8GNxGvKW5YZfMWA4ZaMypbf/YjnOztZMY8t4T9/twY/TemF3IhBs7WsR7m9MIpmzc= X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr8773612lfe.23.1584817186630; Sat, 21 Mar 2020 11:59:46 -0700 (PDT) MIME-Version: 1.0 References: <563D324D-8F5F-4747-AA8E-F5C78AF0C81D@amazon.com> <30E029DE-4083-4B65-A97B-EE4F5BF4B7E2@mit.edu> <414056FE-0FE2-4B9B-A6BA-4ABC565798E3@lodderstedt.net> In-Reply-To: <414056FE-0FE2-4B9B-A6BA-4ABC565798E3@lodderstedt.net> From: Dick Hardt Date: Sat, 21 Mar 2020 11:59:20 -0700 Message-ID: To: Torsten Lodderstedt Cc: Justin Richer , Mike Jones , Yaron Sheffer , "txauth@ietf.org" , "Richard Backman, Annabelle" Content-Type: multipart/alternative; boundary="0000000000007171bc05a1620104" Archived-At: Subject: Re: [Txauth] TxAuth BoF draft agenda X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 19:07:30 -0000 --0000000000007171bc05a1620104 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten Our objectives for this meeting are in order of importance: - get consensus on charter - see if we can get some consensus on the different approaches between XYZ and XAuth to guide us to select a starting document Yaron, Justin, and I have been working on a slightly revised charter that attempts to address scope identity, multiple tokens in a response, and AS<->RS interactions. That will be posted really-soon-now. :) On Sat, Mar 21, 2020 at 6:31 AM Torsten Lodderstedt wrote: > Hi, > > +1 for adding identity slices and AS - RS interop to the agenda. > > I would also ask for time to discuss my proposal to support RS-specific > access tokens and Nat=E2=80=99s suggestion to write an architecture docum= ent. > > As this will have an impact on the agenda, I fully support Mike's > statement: agreeing on the charter is more important now than discussing > the different drafts. Adopting the agenda accordingly is reasonable. > > best regards, > Torsten, > > > On 19. Mar 2020, at 20:11, Justin Richer wrote: > > > > +1 to adding both of these discussions to the agenda. > > > > =E2=80=94 Justin > > > >> On Mar 19, 2020, at 2:00 PM, Mike Jones 40microsoft.com@dmarc.ietf.org> wrote: > >> > >> Given that four people have raised questions about the identity aspect > of the proposed charter, I would request that the chairs allocate at leas= t > 20 minutes to discussion of whether identity should be in or out of scope= , > and if in scope, what aspects of identity should be in and out of scope. > This should have its own time slot, rather than including it in the 20 > minutes of charter and naming discussions currently allocated, as it=E2= =80=99s a > foundational decision to scoping the work, and is likely to need at least > 20 minutes on its own. > >> > >> Torsten=E2=80=99s and Vladimir=E2=80=99s feedback about interoperabili= ty among > authorization servers and resource servers should also be explicitly > included somewhere in the charter discussions. > >> > >> If we=E2=80=99re short on time, I=E2=80=99d rather we first get agreem= ent on the > charter and scope than discuss the engineering merits and tradeoffs among > particular proposed starting point drafts. > >> > >> Thanks, > >> -- Mike > >> > >> From: Txauth On Behalf Of Richard Backman, > Annabelle > >> Sent: Thursday, March 19, 2020 8:28 AM > >> To: Dick Hardt ; txauth@ietf.org > >> Cc: Yaron Sheffer > >> Subject: [EXTERNAL] Re: [Txauth] TxAuth BoF draft agenda > >> > >> I expect a lot of discussion around whether/to what extent it should > include =E2=80=9Cidentity=E2=80=9D and without some structure that could = easily consume the > whole meeting. Should we timebox that discussion, and/or get some > volunteers to summarize the various positions? > >> > >> =E2=80=93 > >> Annabelle Backman (she/her) > >> AWS Identity > >> https://aws.amazon.com/identity/ > >> > >> > >> From: Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > >> Date: Monday, March 16, 2020 at 4:07 PM > >> To: "txauth@ietf.org" > >> Cc: Yaron Sheffer > >> Subject: [EXTERNAL][Txauth] TxAuth BoF draft agenda > >> > >> Virtual Meeting: > >> > >> Monday, March 23 > >> 20:00 - 22:00 UTC * > >> > >> Agenda > >> Chair slides, agenda bashing - 10 min. > >> Charter (link, solicit comments, discuss WG name) - 20 min. > >> XYZ - Justin (with Q&A) - 20 min. > >> XAuth - Dick (with Q&A) - 20 min. > >> Yaron , Dick, Justin - Discussion of differences between protocols - 4= 0 > min. > >> Next steps - 10 min. > >> > >> Additions / suggestions? > >> > >> Tech > >> The technology to be used is still TBD. We will update the list when w= e > know. We are expecting it will be the IETF WebEx. (my preference would be > Zoom if anyone has an account to have LOTS of people on it =3D) > >> > >> We are planning on using EtherPad for notes, and for queue management. > >> > >> Scribe > >> Would someone like to volunteer to be the scribe on EtherPad? We would > like to get as much coordination done prior as possible to make the best > use of the time. > >> > >> /Dick > >> > >> * Some time math for 20:00 - 22:00 UTC: > >> > >> Pacific Time 13:00-15:00 > >> Eastern Time 16:00-18:00 > >> Coordinated Universal Time 20:00-02:00 > >> Central European Time 21:00-23:00 > >> India Standard Time 01:30-03:30 > >> China Standard Time 04:00-06:00 > >> Australian Eastern Standard Time 07:00-09:00 > >> =E1=90=A7 > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > --0000000000007171bc05a1620104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten

Our objectives for this meet= ing are in order of importance:

- get consensus on= charter
- see if we can get some consensus on the different appr= oaches between XYZ and XAuth to guide us to select a starting=C2=A0document=

Yaron, Justin, and I have been working on a sligh= tly revised charter that attempts to address scope identity, multiple=C2=A0= tokens in a response, and AS<->RS interactions. That will be posted r= eally-soon-now. :)



<= br>

On Sat, Mar 21, 2020 at 6:31 AM Torsten Lodderstedt <torsten@lodderstedt.net<= /a>> wrote:
H= i,

+1 for adding identity slices and AS - RS interop to the agenda.

I would also ask for time to discuss my proposal to support RS-specific acc= ess tokens and Nat=E2=80=99s suggestion to write an architecture document. =

As this will have an impact on the agenda, I fully support Mike's state= ment: agreeing on the charter is more important now than discussing the dif= ferent drafts. Adopting the agenda accordingly is reasonable.

best regards,
Torsten,

> On 19. Mar 2020, at 20:11, Justin Richer <jricher@mit.edu> wrote:
>
> +1 to adding both of these discussions to the agenda.
>
>=C2=A0 =E2=80=94 Justin
>
>> On Mar 19, 2020, at 2:00 PM, Mike Jones <Michael.Jones=3D40microsoft.c= om@dmarc.ietf.org> wrote:
>>
>> Given that four people have raised questions about the identity as= pect of the proposed charter, I would request that the chairs allocate at l= east 20 minutes to discussion of whether identity should be in or out of sc= ope, and if in scope, what aspects of identity should be in and out of scop= e.=C2=A0 This should have its own time slot, rather than including it in th= e 20 minutes of charter and naming discussions currently allocated, as it= =E2=80=99s a foundational decision to scoping the work, and is likely to ne= ed at least 20 minutes on its own.
>>=C2=A0
>> Torsten=E2=80=99s and Vladimir=E2=80=99s feedback about interopera= bility among authorization servers and resource servers should also be expl= icitly included somewhere in the charter discussions.
>>=C2=A0
>> If we=E2=80=99re short on time, I=E2=80=99d rather we first get ag= reement on the charter and scope than discuss the engineering merits and tr= adeoffs among particular proposed starting point drafts.
>>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks= ,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mik= e
>>=C2=A0
>> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Richard Backman, A= nnabelle
>> Sent: Thursday, March 19, 2020 8:28 AM
>> To: Dick Hardt <dick.hardt@gmail.com>; txauth@ietf.org
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>
>> Subject: [EXTERNAL] Re: [Txauth] TxAuth BoF draft agenda
>>=C2=A0
>> I expect a lot of discussion around whether/to what extent it shou= ld include =E2=80=9Cidentity=E2=80=9D and without some structure that could= easily consume the whole meeting. Should we timebox that discussion, and/o= r get some volunteers to summarize the various positions?
>>=C2=A0
>> =E2=80=93
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>>=C2=A0
>>=C2=A0
>> From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com= >
>> Date: Monday, March 16, 2020 at 4:07 PM
>> To: "txa= uth@ietf.org" <txauth@ietf.org>
>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>
>> Subject: [EXTERNAL][Txauth] TxAuth BoF draft agenda
>>=C2=A0
>> Virtual Meeting:=C2=A0
>>=C2=A0
>> Monday, March 23
>> 20:00 - 22:00 UTC *
>>=C2=A0
>> Agenda
>> Chair slides, agenda bashing - 10 min.
>> Charter (link, solicit comments, discuss WG name) - 20 min.
>> XYZ - Justin (with Q&A) - 20 min.
>> XAuth - Dick=C2=A0 (with Q&A) - 20 min.
>> Yaron , Dick, Justin - Discussion of differences between protocols= - 40 min.
>> Next steps - 10 min.
>>=C2=A0
>> Additions / suggestions?
>>=C2=A0
>> Tech
>> The technology to be used is still TBD. We will update the list wh= en we know. We are expecting it will be the IETF WebEx. (my preference woul= d be Zoom if anyone has an account to have LOTS of people on it =3D)
>>=C2=A0
>> We are planning on using EtherPad for notes, and for queue managem= ent.
>>=C2=A0
>> Scribe
>> Would someone like to volunteer to be the scribe on EtherPad? We w= ould like to get as much coordination done prior as possible to make the be= st use of the time.
>>=C2=A0
>> /Dick
>>=C2=A0
>> * Some time math for 20:00 - 22:00 UTC:
>>=C2=A0
>> Pacific Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A013:00-15:00
>> Eastern Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A016:00-18:00
>> Coordinated Universal Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 20:00-02:00<= br> >> Central European Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21:00-23:0= 0
>> India Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 01:30= -03:30
>> China Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 04:00-06:00<= br> >> Australian Eastern Standard Time=C2=A0 =C2=A0 =C2=A0 =C2=A007:00-0= 9:00
>> =E1=90=A7
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--0000000000007171bc05a1620104-- From nobody Sat Mar 21 12:41:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423BC3A0906 for ; Sat, 21 Mar 2020 12:41:07 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 5MOQSaMKGcFO for ; Sat, 21 Mar 2020 12:41:05 -0700 (PDT) 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 0756F3A0901 for ; Sat, 21 Mar 2020 12:41:04 -0700 (PDT) Received: from [192.168.1.5] (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 02LJf2m4020621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 21 Mar 2020 15:41:03 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_4909B3CF-364F-45EE-BF7E-9F0C0BBAF097" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sat, 21 Mar 2020 15:41:02 -0400 To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 19:41:07 -0000 --Apple-Mail=_4909B3CF-364F-45EE-BF7E-9F0C0BBAF097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 After some great discussions on the list in the last week, Yaron, Dick, = and I have pulled together a new proposed charter. I think this is = version 5.0? But I forget exactly. :) I=E2=80=99ve highlighted the new lines in bold here, for those reading = this email in HTML. There=E2=80=99s a diff available online at = http://www.mergely.com/RehoJJvW/ = (note: go to view->word wrap to be able to read it better). I=E2=80=99m = attaching the .DIFF file generated by Mergely as well, for those of us = crusty old unix type folks who like to see that. This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. Additionally, the delegation process will allow for: - Fine-grained specification of access - Approval of AS attestation to identity claims - Approval of access to multiple resources and APIs in a single = interaction - Support for multiple access tokens in a single request - Support for directed, audience-restricted access tokens - Separation between the party authorizing access and the party = operating the client requesting access - A variety of client applications, including Web, mobile, single-page, = and interaction-constrained applications The group will define extension points for this protocol to allow for = flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of = possession=20 - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation = process (including asserted identity claims) Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Mechanisms for the AS and RS to communicate the access granted by an = access token Although the artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic = methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods. The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 The initial work will focus on using HTTP for communication between the = client and the authorization server, taking advantage of optimization = features of HTTP2 and HTTP3 where possible, and will strive to enable = simple mapping to other protocols such as COAP when doing so does not = conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures - Identity and authentication conveyance mechanisms - Guidelines for use of protocol extension points --Apple-Mail=_4909B3CF-364F-45EE-BF7E-9F0C0BBAF097 Content-Type: multipart/mixed; boundary="Apple-Mail=_88B2856C-88C9-4CBE-979C-1063FC2CECBE" --Apple-Mail=_88B2856C-88C9-4CBE-979C-1063FC2CECBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 After= some great discussions on the list in the last week, Yaron, Dick, and I = have pulled together a new proposed charter. I think this is version = 5.0? But I forget exactly. :)

I=E2=80=99ve highlighted the new lines in bold here, =  for those reading this email in HTML. There=E2=80=99s a diff = available online at  http://www.mergely.com/RehoJJvW/  (note: go to = view->word wrap to be able to read it better). I=E2=80=99m attaching = the .DIFF file generated by Mergely as well, for those of us crusty old = unix type folks who like to see that.





This = group is chartered to develop a fine-grained delegation protocol for = authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. 

The delegation process = will be acted upon by multiple parties in the protocol, each performing = a specific role. The protocol will decouple the interaction channels, = such as the end user=E2=80=99s browser, from the delegation channel, = which happens directly between the client and the authorization server = (in contrast with OAuth 2.0 which is initiated by the client redirecting = the user=E2=80=99s browser). The client and AS will involve a user to = make an authorization decision as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 and provides a = non-invasive path for supporting future types of clients and interaction = channels.

Additionally, the delegation process will allow = for:

- = Fine-grained specification of access
- Approval of = AS attestation to identity claims
- Approval of = access to multiple resources and APIs in a single interaction
- Support for multiple access tokens in a = single request
- Support for = directed, audience-restricted access tokens
- = Separation between the party authorizing access and the party operating = the client requesting access
- A variety of client = applications, including Web, mobile, single-page, and = interaction-constrained applications

The group will define extension points = for this protocol to allow for flexibility in areas including:

- Cryptographic agility = for keys, message signatures, and proof of possession 
- User interaction mechanisms including web and non-web = methods
- Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated = cryptographic keys
- Optimized inclusion of = additional information through the delegation process (including asserted identity claims)

Additionally, the group will provide mechanisms for = management of the protocol lifecycle including:

- Discovery of the authorization = server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate = the access granted by an access token

Although the artifacts for this work = are not intended or expected to be backwards-compatible with OAuth 2.0 = or OpenID Connect, the group will attempt to simplify migrating from = OAuth 2.0 and OpenID Connect to the new protocol where = possible.

This = group is not chartered to develop extensions to OAuth 2.0, and as such = will focus on new technological solutions not necessarily compatible = with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be = developed in the OAuth Working Group, including functionality = back-ported from the protocol developed here to OAuth 2.0.

The group is chartered = to develop mechanisms for applying cryptographic methods, such as JOSE = and COSE, to the delegation process. This group is not chartered to = develop new cryptographic methods.

The group is chartered to = develop mechanisms for conveying identity information within the = protocol including identifiers (such as email addresses, phone numbers, = usernames, and subject identifiers) and assertions (such as OpenID = Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The = group is not chartered to develop new formats for identifiers or = assertions, nor is the group chartered to develop schemas for user = information, profiles, or other identity attributes, unless a viable = existing format is not available. 

The initial work will focus on using = HTTP for communication between the client and the authorization server, = taking advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP when doing so does not conflict with the primary = focus.

Milestones to include:
- Core delegation = protocol
- Key presentation mechanism bindings to = the core protocol for TLS, detached HTTP signature, and embedded HTTP = signatures
- Identity and authentication conveyance = mechanisms
- Guidelines for use of protocol = extension points



= --Apple-Mail=_88B2856C-88C9-4CBE-979C-1063FC2CECBE Content-Disposition: attachment; filename="RehoJJvW(1).diff" Content-Type: application/octet-stream; x-unix-mode=0666; name="RehoJJvW(1).diff" Content-Transfer-Encoding: 7bit 9a10,11 > - Support for multiple access tokens in a single request > - Support for directed, audience-restricted access tokens 19c21 < - Optimized inclusion of additional information through the delegation process (including identity) --- > - Optimized inclusion of additional information through the delegation process (including asserted identity claims) 25c27 < - Query of token rights by resource servers --- > - Mechanisms for the AS and RS to communicate the access granted by an access token 32a35,36 > The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. > --Apple-Mail=_88B2856C-88C9-4CBE-979C-1063FC2CECBE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_88B2856C-88C9-4CBE-979C-1063FC2CECBE-- --Apple-Mail=_4909B3CF-364F-45EE-BF7E-9F0C0BBAF097-- From nobody Sat Mar 21 12:56:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF53A090F for ; Sat, 21 Mar 2020 12:56:13 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 RgOTbjExXdRV for ; Sat, 21 Mar 2020 12:56:11 -0700 (PDT) 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 43CCF3A090D for ; Sat, 21 Mar 2020 12:56:11 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id a2so10211163ljk.6 for ; Sat, 21 Mar 2020 12:56:11 -0700 (PDT) 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=vnwn9yZuQz/uPrM6PTzO9/RYbaR6elBrsgqNzdX2LOU=; b=c7vPJkde8P5LKOtM91mwl45OVLBroARIgGqeGaksCv9AXmHLPvTd0V7b6XmEcdJZvo Vylt6tZ+i6vXgqNal39nUYaWxKdDS4ioYkxm5jmEHc1w9ksU+7hLcKPquz0sEg8zDEFY yiXwD4GtsbPwrKKdzog+O2N2lrj3fMg4i0F43roe2s8yXRdHdCpm1gae0N7oFnsxvQDP zqRDJwXaBFu02ufmCDTYsqO0kFpYVGkvkBUwkPg7xvSY5DMNzpYghachK/eRragi8vlm iEcojWjUa3mI7T6wKmh/7IoKHBzaC9phaQbJbmQt96H1RB7lxWd90hbShY+s6eUdfScA VvxQ== 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=vnwn9yZuQz/uPrM6PTzO9/RYbaR6elBrsgqNzdX2LOU=; b=qVmrWj+I42stwRQeilT+1IlLwffMbLF2Ag2Du6hLd6mgh9Fjy0IA0kykuvrSNp3frp oqF0aSFCoy7yR0nSzJJFkZT7pBSQ8h6PMM6K7IjiXOJDN1Y1zlRWJNL+UeSjGMHPkekL PmZFQo7yzzxJQzv3co4TVln3ZcXc4w4nqZTZ3Q2GknxhBTxfu63ZHB8/eSG0Fynv8YSL xo0sEIZ78cxHR5VtDEvksNRZW6/2DC2ecT5fa2nfGXbw5AdkQAeKeuPKXhlq5TFCKPAZ svB8Iny/EGY/j3fCM1GSVec36uf3bIGH50VPQaQ1ijpbX0323ZJFoyG6Pu+nTyqdwF7S psVg== X-Gm-Message-State: ANhLgQ1kahiEsCdtLib6hGkcw+CSKlnHyv7oeFRDN7p7NtN39+4pd6gz rtOx2+CnTDf+N7q8a6+IvmXgUXwqAr9JjRIWoTE7z4/R X-Google-Smtp-Source: ADFU+vsLyGyE0n90V29I/Ly774Khi3YR7wjqjUuc5jsxB0BKFGTKsdb3W1cVe27xNbnCOTfXqmX9Wg2OHh86h+NivoE= X-Received: by 2002:a2e:9d84:: with SMTP id c4mr9366680ljj.51.1584820569252; Sat, 21 Mar 2020 12:56:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 21 Mar 2020 12:55:43 -0700 Message-ID: To: Mike Jones , Kim , Filip Skokan , Torsten Lodderstedt Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000010265005a162cb38" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 19:56:14 -0000 --00000000000010265005a162cb38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (replying with those that had expressed concerns about the charter on the To: list to bring it to the top of their inbox) Mike, Kim, Torsten, Filip: are your concerns addressed with the changes below? (apologies to anyone I missed in the To: list) On Sat, Mar 21, 2020 at 12:41 PM Justin Richer wrote: > After some great discussions on the list in the last week, Yaron, Dick, > and I have pulled together a new proposed charter. I think this is versio= n > 5.0? But I forget exactly. :) > > I=E2=80=99ve highlighted the new lines in bold here, for those reading t= his email > in HTML. There=E2=80=99s a diff available online at > http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be able > to read it better). I=E2=80=99m attaching the .DIFF file generated by Mer= gely as > well, for those of us crusty old unix type folks who like to see that. > > > > > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > *- Support for multiple access tokens in a single request* > *- Support for directed, audience-restricted access tokens* > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including *asserted* identity *claims*) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > *- Mechanisms for the AS and RS to communicate the access granted by an > access token* > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > *The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new format= s > for identifiers or assertions, nor is the group chartered to develop > schemas for user information, profiles, or other identity attributes, > unless a viable existing format is not available. * > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000010265005a162cb38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(replying with those that had expressed concerns about the= charter on the To: list to bring it to the top of their inbox)

Mike, Kim, Torsten, Filip: are your concerns addressed with the cha= nges below?

(apologies to anyone I missed in the T= o: list)

On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <jricher@mit.edu> wrote:
After some great discussions on the list in the last week, Yaron,= Dick, and I have pulled together a new proposed charter. I think this is v= ersion 5.0? But I forget exactly. :)





This gro= up is chartered to develop a fine-grained delegation protocol for authoriza= tion, identity, and API access. This protocol will allow an authorizing par= ty to delegate access to client software through an authorization server. I= t will expand upon the uses cases currently supported by OAuth 2.0 and Open= ID Connect (itself an extension of OAuth 2.0) to support authorizations sco= ped as narrowly as a single transaction, provide a clear framework for inte= raction among all parties involved in the protocol flow, and remove unneces= sary dependence on a browser or user-agent for coordinating interactions.= =C2=A0

The delegation process will be acted upon b= y multiple parties in the protocol, each performing a specific role. The pr= otocol will decouple the interaction channels, such as the end user=E2=80= =99s browser, from the delegation channel, which happens directly between t= he client and the authorization server (in contrast with OAuth 2.0 which is= initiated by the client redirecting the user=E2=80=99s browser). The clien= t and AS will involve a user to make an authorization decision as necessary= through interaction mechanisms indicated by the protocol. This decoupling = avoids many of the security concerns and technical challenges of OAuth 2.0 = and provides a non-invasive path for supporting future types of clients and= interaction channels.

Additionally, the delegatio= n process will allow for:

- Fine-grained specifica= tion of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single int= eraction
- Support for multiple access tokens in a single requ= est
- Support for directed, audience-restricted access tok= ens
- Separation between the party authorizing access and the= party operating the client requesting access
- A variety of clie= nt applications, including Web, mobile, single-page, and interaction-constr= ained applications

The group will define extension= points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, = and proof of possession=C2=A0
- User interaction mechanisms inclu= ding web and non-web methods
- Mechanisms for conveying user, sof= tware, organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to resource servers = and binding resource requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delega= tion process (including=C2=A0asserted=C2=A0identity=C2=A0claims)

Additionally, the group will provide mechanism= s for management of the protocol lifecycle including:

<= div>- Discovery of the authorization server
- Revocation of activ= e tokens
- Mechanisms for the AS and RS to communicate the acc= ess granted by an access token

Although the ar= tifacts for this work are not intended or expected to be backwards-compatib= le with OAuth 2.0 or OpenID Connect, the group will attempt to simplify mig= rating from OAuth 2.0 and OpenID Connect to the new protocol where possible= .

This group is not chartered to develop extension= s to OAuth 2.0, and as such will focus on new technological solutions not n= ecessarily compatible with OAuth 2.0. Functionality that builds directly on= OAuth 2.0 will be developed in the OAuth Working Group, including function= ality back-ported from the protocol developed here to OAuth 2.0.
=
The group is chartered to develop mechanisms for applying cr= yptographic methods, such as JOSE and COSE, to the delegation process. This= group is not chartered to develop new cryptographic methods.
The group is chartered to develop mechanisms for conveying i= dentity information within the protocol including identifiers (such as emai= l addresses, phone numbers, usernames, and subject identifiers) and asserti= ons (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Cred= entials). The group is not chartered to develop new formats for identifiers= or assertions, nor is the group chartered to develop schemas for user info= rmation, profiles, or other identity attributes, unless a viable existing f= ormat is not available.=C2=A0

The initial work= will focus on using HTTP for communication between the client and the auth= orization server, taking advantage of optimization features of HTTP2 and HT= TP3 where possible, and will strive to enable simple mapping to other proto= cols such as COAP when doing so does not conflict with the primary focus.

Milestones to include:
- Core delegation = protocol
- Key presentation mechanism bindings to the core protoc= ol for TLS, detached HTTP signature, and embedded HTTP signatures
- Identity and authentication conveyance mechanisms
- Guidelines= for use of protocol extension points



 --00000000000010265005a162cb38-- From nobody Sat Mar 21 13:54:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD033A0985 for ; Sat, 21 Mar 2020 13:54:35 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 t3SBiug1V7s0 for ; Sat, 21 Mar 2020 13:54:33 -0700 (PDT) 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 3F3243A095A for ; Sat, 21 Mar 2020 13:54:33 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id a20so11654496edj.2 for ; Sat, 21 Mar 2020 13:54:33 -0700 (PDT) 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=ATyWk2eehw6Oo8kCFI4xxuB7FqSkeLmnPIwtdEgYcC8=; b=rhabALu7TXdvUgnAftS8A32WEfW1kWbgmbiSvO/0B8dM/vlUWnyf7pDzk7dsJ9tG/c 44atgUrIsTlQNEoRHW3Fm0+SYIHdeYKMJERjaBXf4zDMXcraawb0/cMk2uyFc/U6NTiY i2X7pLj4+Ntwjpv/PSjXSe1DdTT7QCf46k/sPtjvpqTEcBW+6BpsbyPLXnXFOfDLRkZn i7OtCcQhhVeNtNHX74ZxpnhtyRSzSn0TRVdn9xdo3lrLjOFzNj/Nst3nR1iA4QSjjLWO yTlvdnkD3G6tPMG77dqfwNJTlXtnl4g1cY9FAUAAS78VVNgF5X6Ec0I+xTaehiqJdrHT eIFw== 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=ATyWk2eehw6Oo8kCFI4xxuB7FqSkeLmnPIwtdEgYcC8=; b=mI5pgEEToPmn2kF33EyfeA0lpparTjPo5yzfDe3T2UST2c9vnwE8digLPeVEEZbzVW q1/QlYh0cCimWqaAsbYkTt8pCZQW8PRCORjW8ucDVFE9Emk4Jpgvm6RFlnZfVYPaulem NItnzsBg18YnBgIUr2mY03nqRlNzqEdmETqEy1YkKE1Erc/mqgJnu9Nc0ByEGQtLfdJd B6JmuDz8FyQwQquiiXI76/enN+LuLYY7FAjx9NDBi56pRdNVTqIDPLniEb66VcYb9CJq hBIUJlp/XAjFM9h60hCtRUlYIL4jdJdfLsALgTBOUohGQPMnHX+NrFrjMb8lRx0hhE79 1Wiw== X-Gm-Message-State: ANhLgQ2MgiU0tC8S6lahXUdsC4SBLpOBH5L9Jk5Xu5xQ0rWdXqgIzxUs m6C4RLkrbSd4rGJi0dw2CwNR/lgz+fs9f8ajgkw= X-Google-Smtp-Source: ADFU+vvmrpv2Y8lT3AJ+zIpo1dbmfcS0qztPlVA8CMNlVr2A46xIaq74dEgKTkB0UCIg+MmJGv5uI7klI8UhJlOLIPA= X-Received: by 2002:a17:906:f24e:: with SMTP id gy14mr14231372ejb.165.1584824071736; Sat, 21 Mar 2020 13:54:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Skaife Date: Sat, 21 Mar 2020 20:54:22 +0000 Message-ID: To: Dick Hardt Cc: Mike Jones , Kim , Filip Skokan , Torsten Lodderstedt , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d3d09905a1639b9b" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 20:54:36 -0000 --000000000000d3d09905a1639b9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support this updated version of the charter. Good work on nailing the new wording! Many thanks, David Skaife On Sat, Mar 21, 2020 at 7:56 PM Dick Hardt wrote: > (replying with those that had expressed concerns about the charter on the > To: list to bring it to the top of their inbox) > > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes > below? > > (apologies to anyone I missed in the To: list) > > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer wrote: > >> After some great discussions on the list in the last week, Yaron, Dick, >> and I have pulled together a new proposed charter. I think this is versi= on >> 5.0? But I forget exactly. :) >> >> I=E2=80=99ve highlighted the new lines in bold here, for those reading = this >> email in HTML. There=E2=80=99s a diff available online at >> http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be >> able to read it better). I=E2=80=99m attaching the .DIFF file generated = by Mergely >> as well, for those of us crusty old unix type folks who like to see that= . >> >> >> >> >> >> This group is chartered to develop a fine-grained delegation protocol fo= r >> authorization, identity, and API access. This protocol will allow an >> authorizing party to delegate access to client software through an >> authorization server. It will expand upon the uses cases currently >> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth >> 2.0) to support authorizations scoped as narrowly as a single transactio= n, >> provide a clear framework for interaction among all parties involved in = the >> protocol flow, and remove unnecessary dependence on a browser or user-ag= ent >> for coordinating interactions. >> >> The delegation process will be acted upon by multiple parties in the >> protocol, each performing a specific role. The protocol will decouple th= e >> interaction channels, such as the end user=E2=80=99s browser, from the d= elegation >> channel, which happens directly between the client and the authorization >> server (in contrast with OAuth 2.0 which is initiated by the client >> redirecting the user=E2=80=99s browser). The client and AS will involve = a user to >> make an authorization decision as necessary through interaction mechanis= ms >> indicated by the protocol. This decoupling avoids many of the security >> concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve >> path for supporting future types of clients and interaction channels. >> >> Additionally, the delegation process will allow for: >> >> - Fine-grained specification of access >> - Approval of AS attestation to identity claims >> - Approval of access to multiple resources and APIs in a single >> interaction >> *- Support for multiple access tokens in a single request* >> *- Support for directed, audience-restricted access tokens* >> - Separation between the party authorizing access and the party operatin= g >> the client requesting access >> - A variety of client applications, including Web, mobile, single-page, >> and interaction-constrained applications >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other piece= s >> of information used in authorization decisions >> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >> - Optimized inclusion of additional information through the delegation >> process (including *asserted* identity *claims*) >> >> Additionally, the group will provide mechanisms for management of the >> protocol lifecycle including: >> >> - Discovery of the authorization server >> - Revocation of active tokens >> *- Mechanisms for the AS and RS to communicate the access granted by an >> access token* >> >> Although the artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will >> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the n= ew >> protocol where possible.. >> >> This group is not chartered to develop extensions to OAuth 2.0, and as >> such will focus on new technological solutions not necessarily compatibl= e >> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be >> developed in the OAuth Working Group, including functionality back-porte= d >> from the protocol developed here to OAuth 2.0. >> >> The group is chartered to develop mechanisms for applying cryptographic >> methods, such as JOSE and COSE, to the delegation process. This group is >> not chartered to develop new cryptographic methods. >> >> *The group is chartered to develop mechanisms for conveying identity >> information within the protocol including identifiers (such as email >> addresses, phone numbers, usernames, and subject identifiers) and >> assertions (such as OpenID Connect ID Tokens, SAML Assertions, and >> Verifiable Credentials). The group is not chartered to develop new forma= ts >> for identifiers or assertions, nor is the group chartered to develop >> schemas for user information, profiles, or other identity attributes, >> unless a viable existing format is not available. * >> >> The initial work will focus on using HTTP for communication between the >> client and the authorization server, taking advantage of optimization >> features of HTTP2 and HTTP3 where possible, and will strive to enable >> simple mapping to other protocols such as COAP when doing so does not >> conflict with the primary focus. >> >> Milestones to include: >> - Core delegation protocol >> - Key presentation mechanism bindings to the core protocol for TLS, >> detached HTTP signature, and embedded HTTP signatures >> - Identity and authentication conveyance mechanisms >> - Guidelines for use of protocol extension points >> >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d3d09905a1639b9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support this updated version of the charter. Good work o= n nailing the new wording!


Many thanks,
David Skaife
=


On Sat, Mar 21, 2020 at 7:56 PM Dick Hardt <dick.hardt@gmail.com> wrote:
(= replying with those that had expressed concerns about the charter on the To= : list to bring it to the top of their inbox)

Mike, Kim,= Torsten, Filip: are your concerns addressed with the changes below?
<= div>
(apologies to anyone I missed in the To: list)

On S= at, Mar 21, 2020 at 12:41 PM Justin Richer <jricher@mit.edu> wrote:
After some great discussions o= n the list in the last week, Yaron, Dick, and I have pulled together a new = proposed charter. I think this is version 5.0? But I forget exactly. :)
I=E2=80=99ve highlighted the new lines in bold here, =C2=A0= for those reading this email in HTML. There=E2=80=99s a diff available onli= ne at =C2=A0= http://www.mergely.com/RehoJJvW/=C2=A0 (note: go to view->word wrap = to be able to read it better). I=E2=80=99m attaching the .DIFF file generat= ed by Mergely as well, for those of us crusty old unix type folks who like = to see that.





This group is chartered to develop a fine-graine= d delegation protocol for authorization, identity, and API access. This pro= tocol will allow an authorizing party to delegate access to client software= through an authorization server. It will expand upon the uses cases curren= tly supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth= 2.0) to support authorizations scoped as narrowly as a single transaction,= provide a clear framework for interaction among all parties involved in th= e protocol flow, and remove unnecessary dependence on a browser or user-age= nt for coordinating interactions.=C2=A0

The delega= tion process will be acted upon by multiple parties in the protocol, each p= erforming a specific role. The protocol will decouple the interaction chann= els, such as the end user=E2=80=99s browser, from the delegation channel, w= hich happens directly between the client and the authorization server (in c= ontrast with OAuth 2.0 which is initiated by the client redirecting the use= r=E2=80=99s browser). The client and AS will involve a user to make an auth= orization decision as necessary through interaction mechanisms indicated by= the protocol. This decoupling avoids many of the security concerns and tec= hnical challenges of OAuth 2.0 and provides a non-invasive path for support= ing future types of clients and interaction channels.

<= div>Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS at= testation to identity claims
- Approval of access to multiple res= ources and APIs in a single interaction
- Support for multiple= access tokens in a single request
- Support for directed,= audience-restricted access tokens
- Separation between the p= arty authorizing access and the party operating the client requesting acces= s
- A variety of client applications, including Web, mobile, sing= le-page, and interaction-constrained applications

= The group will define extension points for this protocol to allow for flexi= bility in areas including:

- Cryptographic agility= for keys, message signatures, and proof of possession=C2=A0
- Us= er interaction mechanisms including web and non-web methods
- Mec= hanisms for conveying user, software, organization, and other pieces of inf= ormation used in authorization decisions
- Mechanisms for present= ing tokens to resource servers and binding resource requests to tokens and = associated cryptographic keys
- Optimized inclusion of additional= information through the delegation process (including=C2=A0asserted= =C2=A0identity=C2=A0claims)

Additionally, t= he group will provide mechanisms for management of the protocol lifecycle i= ncluding:

- Discovery of the authorization server<= /div>
- Revocation of active tokens
- Mechanisms for the A= S and RS to communicate the access granted by an access token

Although the artifacts for this work are not intended or ex= pected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the gro= up will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible..

This group is no= t chartered to develop extensions to OAuth 2.0, and as such will focus on n= ew technological solutions not necessarily compatible with OAuth 2.0. Funct= ionality that builds directly on OAuth 2.0 will be developed in the OAuth W= orking Group, including functionality back-ported from the protocol develop= ed here to OAuth 2.0.

The group is chartered to de= velop mechanisms for applying cryptographic methods, such as JOSE and COSE,= to the delegation process. This group is not chartered to develop new cryp= tographic methods.

The group is chartered to de= velop mechanisms for conveying identity information within the protocol inc= luding identifiers (such as email addresses, phone numbers, usernames, and = subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML= Assertions, and Verifiable Credentials). The group is not chartered to dev= elop new formats for identifiers or assertions, nor is the group chartered = to develop schemas for user information, profiles, or other identity attrib= utes, unless a viable existing format is not available.=C2=A0

The initial work will focus on using HTTP for communication= between the client and the authorization server, taking advantage of optim= ization features of HTTP2 and HTTP3 where possible, and will strive to enab= le simple mapping to other protocols such as COAP when doing so does not co= nflict with the primary focus.

Milestones to inclu= de:
- Core delegation protocol
- Key presentation mecha= nism bindings to the core protocol for TLS, detached HTTP signature, and em= bedded HTTP signatures
- Identity and authentication conveyance m= echanisms
- Guidelines for use of protocol extension points
=



<= /div>

= --
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d3d09905a1639b9b-- From nobody Sun Mar 22 02:05:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54283A03F8 for ; Sun, 22 Mar 2020 02:05:12 -0700 (PDT) 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, 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 8gzlpPOqT4AU for ; Sun, 22 Mar 2020 02:05:09 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 17A183A03F4 for ; Sun, 22 Mar 2020 02:05:08 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id z18so2131633wmk.2 for ; Sun, 22 Mar 2020 02:05:07 -0700 (PDT) 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=YaWgwdUmkdAyw6QIn91MRj6h16q+tIrZVoPddGxo3C4=; b=QalvmOBiJ2QXLbGARQA3Cd9X3v4uZvU7uiRzEvmYzEWdJ8He1FSUqR5hX1jDmcNDVq 2hBZEwbt4jFgTkcv4uE35UlC9FagsuAJif0W2prFbr+QzoJj8aVBkiqEziTMgWecR9k1 L7cnvMGI3HTi75NjCSRK/6ob8exHznURBqcTozjUGgO3KQ4XrB8rMBD1UIIpz9XApIT0 2TLwxNefpNJ3hJ0BeOCZr/Kx7qdydJp1g/UdJDElBryD6Yitwq8NUQJVGB2/ox8P/byW AgYlDRdWPEnE/v1PsrTnnSv8HDEt85bOt8rYrAb/CPn6H1CtQ8+VzZVaX1W12NQe6Uwm fkcg== 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=YaWgwdUmkdAyw6QIn91MRj6h16q+tIrZVoPddGxo3C4=; b=PSFXuPXVk/4ILNkozEXiREKJ1ONPDs2674EeU/DH9sWaaDCWZUwvyFMme9hft04Z24 K7EXoNEoa9MT8qycwYyM32kpZKKzkfDxLjAIxdxH9JraDUOLuQdwvRJ8jeOp0nUK1sXz wi0MHfTvUHHlTDpGaPvSc3jBJrPOVP4BK1rlqfPa1fHCS0rFktBydXQ9TqJP0Psvb9Ay /d1RAZrCh1jSRvRpteljI3ihrv0H0D/3IAKtXoJPoL0blQLWQCNukUe3qg9ZYnkYEBJ8 nyOn8BmNrDrv2eIOKkcuYtXuAECoHpcLy3Tre44tTumMe1g1wrBSp8Kf0L6clp8dNbtb 1caQ== X-Gm-Message-State: ANhLgQ0dDN/FMbUOTx2cwU6a43wJ9RsXcflzvZIOajP1lWvdscUd/7kG wNB4q71Xq3XTaEFJaF0MI7Fw3w== X-Google-Smtp-Source: ADFU+vuVNPdreEu6QHEgPpo+zJcN5wVblPIYTmA/H9IEmZaUWszZNCFaPJQVZkrCMZ3HE2pkHYsUKQ== X-Received: by 2002:a1c:3241:: with SMTP id y62mr21515771wmy.66.1584867905554; Sun, 22 Mar 2020 02:05:05 -0700 (PDT) Received: from ?IPv6:2003:eb:8f26:25ca:40d8:ce89:91f2:1925? (p200300EB8F2625CA40D8CE8991F21925.dip0.t-ipconnect.de. [2003:eb:8f26:25ca:40d8:ce89:91f2:1925]) by smtp.gmail.com with ESMTPSA id z16sm250459wrr.56.2020.03.22.02.05.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Mar 2020 02:05:04 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-06B721C5-BEA2-481B-9D00-4BC675F54F4C; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 22 Mar 2020 10:05:03 +0100 Message-Id: <2761C130-3CCA-4296-BD65-00CAB18BE476@lodderstedt.net> References: <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> Cc: txauth@ietf.org In-Reply-To: <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> To: Justin Richer X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 09:05:15 -0000 --Apple-Mail-06B721C5-BEA2-481B-9D00-4BC675F54F4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 20.03.2020 um 15:58 schrieb Justin Richer : >=20 > =EF=BB=BFSo fundamentally, I don=E2=80=99t want the AS to allowed to split= tokens when the client isn=E2=80=99t expecting it. Would a simple feature f= lag to allow that behavior at the AS be enough to switch both cases?=20 >=20 > So let=E2=80=99s say we just do the simple thing and make it a boolean to= p-level flag. If the client sends =E2=80=9Csplit_tokens: true=E2=80=9D then t= he AS always returns the =E2=80=9Cmultiple_access_tokens=E2=80=9D structure a= nd it comes up with whatever names it makes sense for the resulting tokens. T= he client can do either the single or multiple token request style. The clie= nt needs to be able to figure out from the token responses how to put which t= oken in which place, and I think we can do some things with the guts of the =E2= =80=9Cresources=E2=80=9D request object, like using =E2=80=9Clocations=E2=80= =9D and maybe other fields. If the client doesn=E2=80=99t send =E2=80=9Cspli= t_tokens: true=E2=80=9D then the AS sends a single token for a single token r= equest, and multiple tokens for a multiple token request, exactly mapped to w= hat the client requested in each resources block. If the client asks for res= ources that cross domains in a way that AS can=E2=80=99t support, it returns= an error. >=20 > The syntax needs work, but it would at least allow both modes of operation= . And it collapses nicely into the single-token use case, which is one of my= goals here. I don=E2=80=99t want a client to ask for 1 token and get 2 or a= sk for 2 tokens and get 3, unless it=E2=80=99s fully prepared for that. >=20 > Would something like that fly for you? If I understand you correctly, the addition to my proposal is to let the cli= ent indicate whether it supports multiple tokens, so the AS will respond wit= h an error if it would need to issue multiple tokens but the client is not p= repared to process multiple tokens? I would say let=E2=80=99s start with it and gather implementation experience= . We at yes.com would to implement a prototype for the multi RS scenario. >=20 > =E2=80=94 Justin >=20 >> On Mar 19, 2020, at 9:37 AM, Justin Richer wrote: >>=20 >> I see what you=E2=80=99re going for here. I think the key point comes dow= n to this: >>=20 >>> - The client knows what it wants to do and where >>=20 >> That=E2=80=99s knowledge is exactly why I would argue that the client wou= ld have to explicitly request multiple access tokens in order to get them.=20= >>=20 >> I=E2=80=99m worried about requiring all clients to be prepared to accept m= ultiple access tokens. In a lot of big cloud deployments, it=E2=80=99s absol= utely based on location. But that=E2=80=99s not the only dispatch for securi= ty domains. A client would need to know, ultimately, what a token is for and= where to use it. And we=E2=80=99d also need to deal with cases that allow f= or subdomains, paths, query parameters, and other variability of an API=E2=80= =99s URLs. After all, I=E2=80=99m probably going to send that same token to a= bunch of different URLs in order to do a bunch of different things, even if= they=E2=80=99re all within the same =E2=80=9CRS=E2=80=9D or =E2=80=9Cdomain= =E2=80=9D or whatever. Which brings us to an underlying problem =E2=80=94 I d= on=E2=80=99t think there=E2=80=99s a good way to reference the identity of a= n RS. Solid is attempting to do that using WebID=E2=80=99s as service identi= fiers, and while that=E2=80=99s interesting, it=E2=80=99s deeply tied to the= ir system where everything knows what a WebID is and what to do with it. I t= hink it=E2=80=99s a bad idea to depend on that kind of thing for a general p= urpose system.=20 >>=20 >> I=E2=80=99m hesitant to have clients depend on being told that informatio= n. I think if we go down that route we=E2=80=99re going to have to also tell= clients things like =E2=80=9Cthis is only good for GET requests=E2=80=9D an= d =E2=80=9Cthis is good for subdomains on this location=E2=80=9D and =E2=80=9C= this can be used for anything except this one exception=E2=80=9D. And it doe= sn=E2=80=99t fit well when you=E2=80=99re trying to mix two different APIs t= hat have really different structures. Things like GraphQL and REST lead to p= retty different URL designs, and TxAuth should be usable for all of that. It= feels like too much automated configuration of a client instead of the clie= nt just =E2=80=9Cdoing something=E2=80=9D, which I think is going to be the c= ommon case. In other words, I do think that the client software is going to b= e bespoke for the API that it=E2=80=99s calling. However, the security libra= ry that speaks the TxAuth piece doesn=E2=80=99t have to be, and the protocol= itself doesn=E2=80=99t need to be. But the protocols should allow the clien= t software to express to the security layer what it knows about the API. >>=20 >> And speaking of common cases, I think it=E2=80=99s actually much more rar= e to have multiple security domains covered by an AS in a way that would nee= d multiple encryptions or targets. I think many of us see it because we work= with large enterprise-scale systems with multiple domains that we want to m= anage all at once. In my experience, it=E2=80=99s much more common to have a= client talk to one AS to get one token for one RS. One of my goals with thi= s is to not make it complicated for simple clients, and I think having to be= prepared to get multiple access tokens is too complex for simple clients. I= might be wrong, but it=E2=80=99s based on my experience across a lot of dif= ferent kinds of APIs. The idea of splitting up tokens like below feels REALL= Y complex, especially when I asked for a single one. I get why you want to d= o it, it makes sense for the AS to be able to do something like that, but fr= om a client=E2=80=99s perspective it=E2=80=99s a lot more complicated withou= t a clear idea of what the identity of an RS is. I think solving that proble= m is a HUGE issue that we should put firmly out of scope. >>=20 >> The thing is, though, you=E2=80=99re absolutely right that there=E2=80=99= s a need for this kind of multiple tokens. So in my view, the lift of having= a client know about the domains that it=E2=80=99s calling is a lot less tha= n the client having to potentially deal with more tokens than it asked for, a= nd knowing how to correctly dispatch those. Also the semantics of what the =E2= =80=9Cresources=E2=80=9D object represents changes, since I could potentiall= y be getting two tokens back that do parts of the one thing that I asked for= , and the client now needs to know which to use for what. If the client has t= o name the splits itself, that implies the client knows what each =E2=80=9Cr= esources=E2=80=9D sub-object represents and knows how to apply that to its =E2= =80=9Ccall the API=E2=80=9D code. The security layer doesn=E2=80=99t know or= care, but the code that knows how to manipulate the API and its data knows a= nd cares. >>=20 >> As for the token content =E2=80=94 that=E2=80=99s solidly an implementati= on decision and orthogonal to this discussion. You can do all of this multi a= ccess token stuff with introspection and reference-based tokens. Access toke= ns themselves need to stay opaque to the client and to the protocol at large= . I don=E2=80=99t believe that=E2=80=99s up for debate. >>=20 >> Thanks so much for pushing this conversation, and now I=E2=80=99m more co= nvinced than ever that handling multiple tokens in the response is something= we need to figure out within this group.=20 >>=20 >> =E2=80=94 Justin >>=20 >>>> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt wrote: >>>=20 >>> Hi Justin, >>>=20 >>> thanks for explaining the different options. I=E2=80=99m well aware of t= he super refresh token (and remember the discussions back then in Taipei :-)= ), I have implemented systems using this and other patterns, too. >>>=20 >>> The underlying assumption for most of those patterns is that the client u= pfront knows the boundaries between RS security domains, which typically mea= ns the solution is bespoken.=20 >>>=20 >>> TXAuth is chartered to develop a protocol and not a framework. What I=E2= =80=99m looking for is interoperable protocol support for use of RS-specific= self-contained access tokens in multi-RS deployments. >>>=20 >>> Why RS-specific self-contained access tokens?=20 >>> This is in my experience the most efficient way to empower high-volume/h= igh-load services in a very efficient, secure, and privacy preserving fashio= n.=20 >>>=20 >>> - Every token contains exactly the data the RS needs to perform access c= ontrol decisions locally. No need for further database lookups or AS callbac= ks, that=E2=80=99s really fast and keeps cost of the AS function low. >>> - The token itself can be encrypted to protect this data using a RS-spec= ific key, one could even use HMACs to protect integrity and authenticity (fa= st as well).=20 >>> - The token can have a RS-specific lifetime. >>> - Since every token is restricted to a single RS audience, those tokens a= lso have a baseline replay detection built-in.=20 >>>=20 >>> I think this pattern makes sense in environments with multiple RSs (e.g.= different products) as well. But since every token is minted to the specifi= c requirements of a certain RS, the AS must be able to mint different tokens= . That doesn=E2=80=99t work properly without some support in the protocol. >>>=20 >>> Is there a need for multi access tokens support?=20 >>> Well, you implemented it, I implemented it, and I think a couple of othe= r implementers did it with OAuth 2 in the past. So there seems to be some ne= ed. Why does the rest use the single token pattern? I think some deployments= will indeed only have a single service, but I bet a lot of implementers did= it because their product does not support anything else.=20 >>>=20 >>> I have experienced this myself when I designed the architecture of the y= es ecosystem. It is a federation of authorization servers with associated se= rvices where every AS represents a certain bank. Since our partners shall be= able to implement their AS using the product they like, I needed to go with= the least common denominator - single access token. This has a significant c= onsequences: our tokens are basically handles, so every service calls back t= o the AS to obtain its data for every service request. This degrades perform= ance significantly and, since those tokens are good for multi audiences, it f= orces us to generally use sender constrained tokens, which increases complex= ity for clients.=20 >>>=20 >>> I would like to give implementers more options in the TXAuth space. That= =E2=80=99s why I advocate to build-in support f=C3=BCr multiple access token= s into TXAuth.=20 >>>=20 >>> My proposal is based on the following assumptions: >>> - Token format, content, encryption keys and so on are defined as part o= f the interface between AS and RS >>> - The client knows what it wants to do and where >>> - Every party contributes the information it has to the overall process t= o make it work simply and effectively for everyone.=20 >>>=20 >>> There is no change/addition needed to the request syntax. All it takes i= s your new multi token syntax (+ a small addition) in the response.=20 >>>=20 >>> The client uses the =E2=80=9Cresources" structure to communicate what (a= ctions, further elements) it wants to do and where (locations). >>>=20 >>> [ >>> { >>> =E2=80=9Cactions": ["read", "write"], >>> "locations": ["https://example.com/resource"], >>> =E2=80=9Cdata": ["foo", "bar"] >>> }, >>> { >>> =E2=80=9Cactions": ["write"], >>> "locations": ["https://other_example.com/resource"], >>> =E2=80=9Cdata": ["foo", "bar"] >>> } >>> ] >>>=20 >>> One deployment might use a single token for all RSs, in this case the to= ken response remains unchanged:=20 >>>=20 >>> { >>> "access_token":{ >>> "value":"08ur4kahfga09u23rnkjasdf", >>> "type":"bearer" >>> } >>> } >>>=20 >>> If the AS has the need to issue multiple access tokens, it could, for ex= ample, use the =E2=80=9Clocations" elements to determine what tokens it need= s to create. Such an AS then uses the multiple_access_tokens structure augme= nted by corresponding "locations=E2=80=9D entries in the token response:=20 >>>=20 >>> "multiple_access_tokens":{ >>> "token_a":{ >>> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>> "type":"bearer", >>> "locations":[ >>> "https://example.com/resource" >>> ] >>> }, >>> "token_b":{ >>> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >>> "type":"bearer", >>> "locations":[ >>> "https://other_example.com/resource" >>> ] >>> } >>> } >>>=20 >>> Since the client passed the locations values in the request, it is also a= ble to determine where to use what access token.=20 >>>=20 >>> I think that=E2=80=99s pretty simple, especially from a client perspecti= ve. =20 >>>=20 >>> And If the client wants to split access tokens further apart, e.g. to ob= tain tokens with less privileges, it can do so using the request syntax you d= efined:=20 >>>=20 >>> resources: { >>> token1: [{ >>> actions: ["read", "write", "dolphin"], >>> locations: ["https://server.example.net/", "https://resource.loc= al/other"], >>> datatypes: ["metadata", "images"] >>> }], >>> token2: [{ >>> actions: ["foo", "bar", "dolphin"], >>> locations: ["https://resource.other/"], >>> datatypes: ["data", "pictures"] >>> }] >>> } >>>=20 >>> In the simplest case, the AS would return the data as in your proposal. >>>=20 >>> If the client asks for a partitioning of privileges that goes across RS s= ecurity domains like this >>>=20 >>> { >>> "resources":{ >>> "token1":[ >>> { >>> "actions":[ "read", "write","dolphin" ], >>> "locations":[ "https://server.example.net/","https://resource.local/= other"], >>> "datatypes":[ "metadata","images"] >>> }, >>> { >>> "actions":["read","write"], >>> "locations":["https://example.com/resource"] >>> } >>> ], >>> "token2":[ >>> { >>> "actions":["foo","bar", "dolphin"], >>> "locations":["https://resource.other/"], >>> "datatypes":["data","pictures"] >>> } >>> ] >>> } >>> } >>>=20 >>> the AS would need to further partition the pre-defined tokens like this:= >>>=20 >>> "multiple_access_tokens=E2=80=9D:{ >>> =E2=80=9Ctoken1/a":{ >>> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>> "type":"bearer", >>> "locations":["https://server.example.net/","https://resource.local/oth= er"] >>> }, >>> =E2=80=9Ctoken1/b":{ >>> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>> "type":"bearer", >>> "locations":["https://example.com/resource"] >>> }, >>> =E2=80=9Ctoken2":{ >>> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >>> "type":"bearer", >>> "locations":[ >>> "https://other_example.com/resource" >>> ] >>> } >>> } >>>=20 >>> Naming of the tokens is a bit tricky but I think solvable. >>>=20 >>> What do you think? >>>=20 >>> best regards, >>> Torsten. >>>=20 >>>> On 15. Mar 2020, at 15:26, Justin Richer wrote: >>>>=20 >>>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt wrote: >>>>>=20 >>>>>> On 15. Mar 2020, at 03:25, Justin Richer wrote: >>>>>>=20 >>>>>> So if the AS needs a client to get different access tokens to call di= fferent RS domains, it does exactly what we do in OAuth 2 today =E2=80=94 it= tells the client to get two different access tokens.=20 >>>>>=20 >>>>> How does this work in XYZ? >>>>>=20 >>>>=20 >>>> Without using the multi-access-token thing I=E2=80=99m proposing in thi= s thread, the client would just make two separate transaction calls to get t= wo different tokens. There=E2=80=99s a few ways that shakes out depending on= some of the details. In the OAuth world that amounts to involving the user t= wice, and it might be the same in XYZ if you=E2=80=99re asking for different= things: >>>>=20 >>>> 1. Client: Start TX-1 (R-1) >>>> 2. User: Approve R-1 >>>> 3. AS: Issue AT-1(R-1) >>>> 4. Client: Start TX-2 (R-1) >>>> 5. User: approve R-2 >>>> 6. AS: Issue AT-2(R-2) >>>>=20 >>>> Unless you=E2=80=99re getting a super refresh token upfront and then ca= lling for two downgraded access tokens later =E2=80=94 which does work, and I= =E2=80=99ve built out systems that do exactly that. XYZ can do that trick to= o. >>>>=20 >>>> 1. Client: Start TX-1 (R-1, R-2) >>>> 2. User: Approve R-1, R-2 >>>> 3. AS: Issue AT1 (R-1, R-2) >>>> 4. Client: Continue TX-1 (R-2) >>>> 5. AS: Issue AT-2 (R-2) >>>>=20 >>>> But we=E2=80=99ve got another thing we can use in XYZ to help this, the= user handle. This lets a trusted client tell the AS that it believes the sa= me user is still there and asking the question, so if the access rights are O= K then you don=E2=80=99t need to involve the user again. We invented this co= nstruct with UMA2, where it=E2=80=99s called the persisted claims token (PCT= ). >>>>=20 >>>> 1. Client: Start TX-1 (R-1) >>>> 2. User: Approve R-1 >>>> 3. AS: Issue AT-1 (R-1), user handle U-1 >>>> 4. Client Start TX-2 (R-2, U-1) >>>> 5. AS: Issue AT-2 (R-2) >>>>=20 >>>> Now: With the multi-token request, we can collapse this all back to a s= ingle transaction with multiple outputs: >>>>=20 >>>> 1. Client: Start TX-2 (token1: R-1, token2: R-2) >>>> 2. User Approve R-1, R-2 >>>> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) >>>>=20 >>>> I haven=E2=80=99t liked any of the multi-access-token solutions to date= because they make things weird for single access token requests. I like thi= s idea because it=E2=80=99s an optimization for a complex case that doesn=E2= =80=99t change the behavior for the simple case, and in fact doesn=E2=80=99t= even change the expectations for the simple case. To me, that=E2=80=99s imp= ortant. >>>>=20 >>>> =E2=80=94 Justin >>>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 --Apple-Mail-06B721C5-BEA2-481B-9D00-4BC675F54F4C 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzIyMDkwNTAzWjAvBgkqhkiG9w0BCQQxIgQg e0YLi6Oqmng2jusPDOVobqDuBbL1Z+JIZ5G5OpIX8ywwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEAnAcwi2s9W5BIEbAgImsJjoGOhgIb41Fs5hO+j7GG7Il+0DW6jnww QKNLi5z5wuzyPxo6+5twGJhAdLiCrNKoTa0vP7QIkrA5ta6WhtxKHxgKDGe7/1JTXGLiCkt28aGj OzB1h6ruFvXWz1d4DhunSBlZWVMigRQpUhC46Vp1udKh35ld2wDLoSz3ZhLzuwyNAZVMS0wTsXaZ eDWTDv4CJSkL8optnoGgp+Wh4ybxNbXfyxcXbHIOPzRtgf6IIxito3xPe7ZtGqGsMRR4pjKCWCwN JMVfaro7pTvVXfnazPK1okFh08WavNLnCtt8x/O3o5X/0ggmL8ArXgA4cLn9LQAAAAAAAA== --Apple-Mail-06B721C5-BEA2-481B-9D00-4BC675F54F4C-- From nobody Sun Mar 22 02:09:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44EB3A03FC for ; Sun, 22 Mar 2020 02:09:07 -0700 (PDT) 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 w8oVuh-cBjF4 for ; Sun, 22 Mar 2020 02:09:06 -0700 (PDT) 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 3AD873A03F8 for ; Sun, 22 Mar 2020 02:09:06 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id b2so12688241wrj.10 for ; Sun, 22 Mar 2020 02:09:06 -0700 (PDT) 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=G6iLjOlFJPxn1fHWcLcAJWS0Rci6wj7yn0jVVA5oU1c=; b=xIKxZP/z5l3/xin1qSdjIDCdW/vjKdN62JyqYekXgh1N9yXfDUS0LPqDC16/JZop96 Eo5s7YNO90F2etiAqXuVjffMOrQd+tbtcQ+i8kfwT2F8bDWnMDMFDl/lcQ7wtpyJB3pB Q81ubL6aPM92aUsStSexXYQigKsOCYymu5LwnT6VbuSVSZUbD6bn6ntVEHgBajbj8Y+D khA1Js4sNXlK4EfaBrocV8X3LFcOf7uwTIFgBQY7GbCqoRBunpl2TPefw41tlph5W1Om Oy5fnZOJiWIr5G7S+One19UyJGJN2txqh0mhvaR87OOJtFugzbREhLLBb4pagIceDyI8 3pAw== 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=G6iLjOlFJPxn1fHWcLcAJWS0Rci6wj7yn0jVVA5oU1c=; b=dGiuVLH0E/wkf5RdIW4CSFPRQzHL8vqF43CNf7qYs3rBpXmWclnuoob43Mug4nNag9 j/v33hw98AmIcsbT3GexqQ4AVnHOduHmLUh6HRqCm7vVarKBVTzL/JOhUexEX6foOOMy yNjtwHJORhYRZikEW1yQn87+Ggd3QdnV3cZifuicZ6qa7MYrFM5spbbYZcj7xpV9EWy3 cS2ePRF3GJv9T2coKdezngUqQV04KQtpol5dW93wqZLM8nQW/qzk6DVYTaPIt3j2bS2e V1tGO7JF14H+0TGbeRoL6SikHrBHzve8tPeIXpNoxQo1QYzxfnFEH3lU5AaCzZ0xybbA RV2A== X-Gm-Message-State: ANhLgQ2lVRdkNzzQqNvwE8YxOybniBtCL45v/sxHJ7yy9V9iM0TpSv1k 6/pn1l6gZeq/9rMwZTmkzryJROQEKGU= X-Google-Smtp-Source: ADFU+vsZYtuyDIQpe87HLAbCeaL+YPtMLgZK9fnQYhdGgRHaMOGr6jJ+wVHh9YBuCs9BicXZUwMZvA== X-Received: by 2002:adf:9071:: with SMTP id h104mr22495659wrh.359.1584868144564; Sun, 22 Mar 2020 02:09:04 -0700 (PDT) Received: from [192.168.71.106] ([84.158.226.43]) by smtp.gmail.com with ESMTPSA id v2sm18580576wrt.58.2020.03.22.02.09.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Mar 2020 02:09:03 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-BCD7CFEB-DEE5-4460-801C-7E958749F3F0; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sun, 22 Mar 2020 10:08:57 +0100 Message-Id: References: Cc: txauth@ietf.org In-Reply-To: To: Justin Richer X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 09:09:08 -0000 --Apple-Mail-BCD7CFEB-DEE5-4460-801C-7E958749F3F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Justin, > Am 21.03.2020 um 20:41 schrieb Justin Richer : >=20 > - Support for multiple access tokens in a single request I would assume this should read =E2=80=9Eresponse=E2=80=9C instead of =E2=80= =9Erequest=E2=80=9C best regards, Torsten.= --Apple-Mail-BCD7CFEB-DEE5-4460-801C-7E958749F3F0 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 CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzIyMDkwODU3WjAvBgkqhkiG9w0BCQQxIgQg EdWm9j1yV1hN90g89vsFlS9HSIiBZ7wHaExHJMEUEHwwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQEBBQAEggEATkqe2/6HaR7EH4y7R52WP3OC/wC/nG0givRBm9Zo10LvT84YDipJ xEBrvTu59gG1P398Kv/G12THrkna5MTQE14yfhJN5Cmnl+ntt9XtgcK3wW89hZHhKWKsQzdHLk0N OY5etOMavQLqZQv7BcK1n+A+p7RZ+WRxFWyf5D21BfpHEeaH375n4adgOVUYI7LStfxnMSQC239v ld5PiZXmQ6GPnOn+vam+cwjJ6IitY1WH2MCXUzb4QnwjWcQ4f3d+7aFPUPBWDByB52B7vSKT/K5V EuxcXCfl85WzNdA4iLLZZ3NdzY0hUmvqXl4xBHXBkhmjVC2d9qydv9jfGf2tMAAAAAAAAA== --Apple-Mail-BCD7CFEB-DEE5-4460-801C-7E958749F3F0-- From nobody Sun Mar 22 05:35:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CB03A0538 for ; Sun, 22 Mar 2020 05:35:17 -0700 (PDT) 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 D9v_lccdKOBH for ; Sun, 22 Mar 2020 05:35:16 -0700 (PDT) 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 860F63A0767 for ; Sun, 22 Mar 2020 05:35:16 -0700 (PDT) Received: from [192.168.1.5] (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 02MCZDxZ017060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Mar 2020 08:35:14 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Sun, 22 Mar 2020 08:35:13 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5245DFBB-D967-4779-90F8-0E8F8F7C0CC3@mit.edu> References: To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 12:35:26 -0000 On Mar 22, 2020, at 5:08 AM, Torsten Lodderstedt = wrote: >=20 > Hi Justin, >=20 >> Am 21.03.2020 um 20:41 schrieb Justin Richer : >>=20 >> - Support for multiple access tokens in a single request >=20 > I would assume this should read =E2=80=9Eresponse=E2=80=9C instead of = =E2=80=9Erequest=E2=80=9C Again, ultimately, I think it=E2=80=99s both request and response that = need this capability, so maybe we should just say as much. =E2=80=94 Justin= From nobody Sun Mar 22 05:50:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136523A03F3 for ; Sun, 22 Mar 2020 05:50:05 -0700 (PDT) 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 60WrpDiWmPYd for ; Sun, 22 Mar 2020 05:50:02 -0700 (PDT) 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 9205F3A03ED for ; Sun, 22 Mar 2020 05:50:01 -0700 (PDT) Received: from [192.168.1.5] (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 02MCnxLh019894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Mar 2020 08:49:59 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <2761C130-3CCA-4296-BD65-00CAB18BE476@lodderstedt.net> Date: Sun, 22 Mar 2020 08:49:59 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> <2761C130-3CCA-4296-BD65-00CAB18BE476@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 12:50:06 -0000 Not just multiple tokens =E2=80=94 but specifically =E2=80=9Cmore tokens = than I explicitly asked for=E2=80=9D. I think the path for a client = asking for one token and getting one token is clear, as is the path for = a client asking for 3 tokens and getting 3 tokens. In each case, using = the syntax I proposed, the client can directly map one =E2=80=9Cresources=E2= =80=9D block (array of objects/references) to a single, specific token. = But a client asking for 1 token and getting 3, a client asking for 2 = tokens and getting 5, etc, is where the client-side confusion lies. As = soon as you do that, you need to provide information to the client about = where and how each individual token is to be used since it can=E2=80=99t = rely on mapping it directly to a specific portion of its request. And = you=E2=80=99ll need that if the AS is allowed to determine that a = client=E2=80=99s request needs to be split across multiple RS=E2=80=99s = if the client didn=E2=80=99t do the splitting itself. I don=E2=80=99t = think every deployment can rely on the URL being the appropriate = director for this kind of split =E2=80=94 it=E2=80=99s something, and I = get that it works for you, but it=E2=80=99s not universal enough to = build the token dispatch on. I get that it works for your system, and it = probably is =E2=80=9Cgood enough=E2=80=9D for a lot of systems, but = I=E2=80=99m just not convinced that=E2=80=99s the only dimension that = we=E2=80=99ll see this kind of thing in. I am not particularly fond of a flag to solve this. It is complex, = it=E2=80=99s a hack at best, and we shouldn=E2=80=99t keep it like that; = but I think implementing something like this can give us some idea of = what the boundaries really are on the different use cases. Basically, = it=E2=80=99s a patch that can let us build out two different modes in = the same systems without them getting wrapped up in each other so that = we can see where the overlaps and differences really are on a real = system. When we can figure out what these changes really look like, then = we can figure out what this more advanced token-splitting is and how it = can fit in the overall TxAuth protocol. Maybe it=E2=80=99d be something = in an XYZ =E2=80=9Ccapabilities=E2=80=9D list instead?=20 I also think that this is going to drive an essential conversation about = how we identify an RS within this protocol. OAuth 2 has struggled with = identifying components its entire lifetime. The =E2=80=9Cclient_id=E2=80=9D= is almost meaningless in a world where the ID could mean it's is = shared between millions of instances of a mobile app, or re-used in = ephemeral copies of an SPA, or a locked down high security web service = on a single machine. I think we need to re-examine all of these = components, and identifying the RS should be a part of that. Do I think = we should have a =E2=80=9Cresource_id=E2=80=9D? Not really =E2=80=94 in = XYZ, I got rid of =E2=80=9Cclient_id=E2=80=9D for the reasons above (and = it=E2=80=99s not actually needed within the protocol anymore), but I=E2=80= =99m not sure what the answer is. =E2=80=94 Justin > On Mar 22, 2020, at 5:05 AM, Torsten Lodderstedt = wrote: >=20 >=20 >=20 >> Am 20.03.2020 um 15:58 schrieb Justin Richer : >>=20 >> =EF=BB=BFSo fundamentally, I don=E2=80=99t want the AS to allowed to = split tokens when the client isn=E2=80=99t expecting it. Would a simple = feature flag to allow that behavior at the AS be enough to switch both = cases?=20 >>=20 >> So let=E2=80=99s say we just do the simple thing and make it a = boolean top-level flag. If the client sends =E2=80=9Csplit_tokens: = true=E2=80=9D then the AS always returns the = =E2=80=9Cmultiple_access_tokens=E2=80=9D structure and it comes up with = whatever names it makes sense for the resulting tokens. The client can = do either the single or multiple token request style. The client needs = to be able to figure out from the token responses how to put which token = in which place, and I think we can do some things with the guts of the = =E2=80=9Cresources=E2=80=9D request object, like using =E2=80=9Clocations=E2= =80=9D and maybe other fields. If the client doesn=E2=80=99t send = =E2=80=9Csplit_tokens: true=E2=80=9D then the AS sends a single token = for a single token request, and multiple tokens for a multiple token = request, exactly mapped to what the client requested in each resources = block. If the client asks for resources that cross domains in a way that = AS can=E2=80=99t support, it returns an error. >>=20 >> The syntax needs work, but it would at least allow both modes of = operation. And it collapses nicely into the single-token use case, which = is one of my goals here. I don=E2=80=99t want a client to ask for 1 = token and get 2 or ask for 2 tokens and get 3, unless it=E2=80=99s fully = prepared for that. >>=20 >> Would something like that fly for you? >=20 > If I understand you correctly, the addition to my proposal is to let = the client indicate whether it supports multiple tokens, so the AS will = respond with an error if it would need to issue multiple tokens but the = client is not prepared to process multiple tokens? >=20 > I would say let=E2=80=99s start with it and gather implementation = experience. We at yes.com would to implement a prototype for the multi = RS scenario. >=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Mar 19, 2020, at 9:37 AM, Justin Richer wrote: >>>=20 >>> I see what you=E2=80=99re going for here. I think the key point = comes down to this: >>>=20 >>>> - The client knows what it wants to do and where >>>=20 >>> That=E2=80=99s knowledge is exactly why I would argue that the = client would have to explicitly request multiple access tokens in order = to get them.=20 >>>=20 >>> I=E2=80=99m worried about requiring all clients to be prepared to = accept multiple access tokens. In a lot of big cloud deployments, it=E2=80= =99s absolutely based on location. But that=E2=80=99s not the only = dispatch for security domains. A client would need to know, ultimately, = what a token is for and where to use it. And we=E2=80=99d also need to = deal with cases that allow for subdomains, paths, query parameters, and = other variability of an API=E2=80=99s URLs. After all, I=E2=80=99m = probably going to send that same token to a bunch of different URLs in = order to do a bunch of different things, even if they=E2=80=99re all = within the same =E2=80=9CRS=E2=80=9D or =E2=80=9Cdomain=E2=80=9D or = whatever. Which brings us to an underlying problem =E2=80=94 I don=E2=80=99= t think there=E2=80=99s a good way to reference the identity of an RS. = Solid is attempting to do that using WebID=E2=80=99s as service = identifiers, and while that=E2=80=99s interesting, it=E2=80=99s deeply = tied to their system where everything knows what a WebID is and what to = do with it. I think it=E2=80=99s a bad idea to depend on that kind of = thing for a general purpose system.=20 >>>=20 >>> I=E2=80=99m hesitant to have clients depend on being told that = information. I think if we go down that route we=E2=80=99re going to = have to also tell clients things like =E2=80=9Cthis is only good for GET = requests=E2=80=9D and =E2=80=9Cthis is good for subdomains on this = location=E2=80=9D and =E2=80=9Cthis can be used for anything except this = one exception=E2=80=9D. And it doesn=E2=80=99t fit well when you=E2=80=99r= e trying to mix two different APIs that have really different = structures. Things like GraphQL and REST lead to pretty different URL = designs, and TxAuth should be usable for all of that. It feels like too = much automated configuration of a client instead of the client just = =E2=80=9Cdoing something=E2=80=9D, which I think is going to be the = common case. In other words, I do think that the client software is = going to be bespoke for the API that it=E2=80=99s calling. However, the = security library that speaks the TxAuth piece doesn=E2=80=99t have to = be, and the protocol itself doesn=E2=80=99t need to be. But the = protocols should allow the client software to express to the security = layer what it knows about the API. >>>=20 >>> And speaking of common cases, I think it=E2=80=99s actually much = more rare to have multiple security domains covered by an AS in a way = that would need multiple encryptions or targets. I think many of us see = it because we work with large enterprise-scale systems with multiple = domains that we want to manage all at once. In my experience, it=E2=80=99s= much more common to have a client talk to one AS to get one token for = one RS. One of my goals with this is to not make it complicated for = simple clients, and I think having to be prepared to get multiple access = tokens is too complex for simple clients. I might be wrong, but it=E2=80=99= s based on my experience across a lot of different kinds of APIs. The = idea of splitting up tokens like below feels REALLY complex, especially = when I asked for a single one. I get why you want to do it, it makes = sense for the AS to be able to do something like that, but from a = client=E2=80=99s perspective it=E2=80=99s a lot more complicated without = a clear idea of what the identity of an RS is. I think solving that = problem is a HUGE issue that we should put firmly out of scope. >>>=20 >>> The thing is, though, you=E2=80=99re absolutely right that there=E2=80= =99s a need for this kind of multiple tokens. So in my view, the lift of = having a client know about the domains that it=E2=80=99s calling is a = lot less than the client having to potentially deal with more tokens = than it asked for, and knowing how to correctly dispatch those. Also the = semantics of what the =E2=80=9Cresources=E2=80=9D object represents = changes, since I could potentially be getting two tokens back that do = parts of the one thing that I asked for, and the client now needs to = know which to use for what. If the client has to name the splits itself, = that implies the client knows what each =E2=80=9Cresources=E2=80=9D = sub-object represents and knows how to apply that to its =E2=80=9Ccall = the API=E2=80=9D code. The security layer doesn=E2=80=99t know or care, = but the code that knows how to manipulate the API and its data knows and = cares. >>>=20 >>> As for the token content =E2=80=94 that=E2=80=99s solidly an = implementation decision and orthogonal to this discussion. You can do = all of this multi access token stuff with introspection and = reference-based tokens. Access tokens themselves need to stay opaque to = the client and to the protocol at large. I don=E2=80=99t believe = that=E2=80=99s up for debate. >>>=20 >>> Thanks so much for pushing this conversation, and now I=E2=80=99m = more convinced than ever that handling multiple tokens in the response = is something we need to figure out within this group.=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>>> On Mar 17, 2020, at 5:22 AM, Torsten Lodderstedt = wrote: >>>>=20 >>>> Hi Justin, >>>>=20 >>>> thanks for explaining the different options. I=E2=80=99m well aware = of the super refresh token (and remember the discussions back then in = Taipei :-)), I have implemented systems using this and other patterns, = too. >>>>=20 >>>> The underlying assumption for most of those patterns is that the = client upfront knows the boundaries between RS security domains, which = typically means the solution is bespoken.=20 >>>>=20 >>>> TXAuth is chartered to develop a protocol and not a framework. What = I=E2=80=99m looking for is interoperable protocol support for use of = RS-specific self-contained access tokens in multi-RS deployments. >>>>=20 >>>> Why RS-specific self-contained access tokens?=20 >>>> This is in my experience the most efficient way to empower = high-volume/high-load services in a very efficient, secure, and privacy = preserving fashion.=20 >>>>=20 >>>> - Every token contains exactly the data the RS needs to perform = access control decisions locally. No need for further database lookups = or AS callbacks, that=E2=80=99s really fast and keeps cost of the AS = function low. >>>> - The token itself can be encrypted to protect this data using a = RS-specific key, one could even use HMACs to protect integrity and = authenticity (fast as well).=20 >>>> - The token can have a RS-specific lifetime. >>>> - Since every token is restricted to a single RS audience, those = tokens also have a baseline replay detection built-in.=20 >>>>=20 >>>> I think this pattern makes sense in environments with multiple RSs = (e.g. different products) as well. But since every token is minted to = the specific requirements of a certain RS, the AS must be able to mint = different tokens. That doesn=E2=80=99t work properly without some = support in the protocol. >>>>=20 >>>> Is there a need for multi access tokens support?=20 >>>> Well, you implemented it, I implemented it, and I think a couple of = other implementers did it with OAuth 2 in the past. So there seems to be = some need. Why does the rest use the single token pattern? I think some = deployments will indeed only have a single service, but I bet a lot of = implementers did it because their product does not support anything = else.=20 >>>>=20 >>>> I have experienced this myself when I designed the architecture of = the yes ecosystem. It is a federation of authorization servers with = associated services where every AS represents a certain bank. Since our = partners shall be able to implement their AS using the product they = like, I needed to go with the least common denominator - single access = token. This has a significant consequences: our tokens are basically = handles, so every service calls back to the AS to obtain its data for = every service request. This degrades performance significantly and, = since those tokens are good for multi audiences, it forces us to = generally use sender constrained tokens, which increases complexity for = clients.=20 >>>>=20 >>>> I would like to give implementers more options in the TXAuth space. = That=E2=80=99s why I advocate to build-in support f=C3=BCr multiple = access tokens into TXAuth.=20 >>>>=20 >>>> My proposal is based on the following assumptions: >>>> - Token format, content, encryption keys and so on are defined as = part of the interface between AS and RS >>>> - The client knows what it wants to do and where >>>> - Every party contributes the information it has to the overall = process to make it work simply and effectively for everyone.=20 >>>>=20 >>>> There is no change/addition needed to the request syntax. All it = takes is your new multi token syntax (+ a small addition) in the = response.=20 >>>>=20 >>>> The client uses the =E2=80=9Cresources" structure to communicate = what (actions, further elements) it wants to do and where (locations). >>>>=20 >>>> [ >>>> { >>>> =E2=80=9Cactions": ["read", "write"], >>>> "locations": ["https://example.com/resource"], >>>> =E2=80=9Cdata": ["foo", "bar"] >>>> }, >>>> { >>>> =E2=80=9Cactions": ["write"], >>>> "locations": ["https://other_example.com/resource"], >>>> =E2=80=9Cdata": ["foo", "bar"] >>>> } >>>> ] >>>>=20 >>>> One deployment might use a single token for all RSs, in this case = the token response remains unchanged:=20 >>>>=20 >>>> { >>>> "access_token":{ >>>> "value":"08ur4kahfga09u23rnkjasdf", >>>> "type":"bearer" >>>> } >>>> } >>>>=20 >>>> If the AS has the need to issue multiple access tokens, it could, = for example, use the =E2=80=9Clocations" elements to determine what = tokens it needs to create. Such an AS then uses the = multiple_access_tokens structure augmented by corresponding = "locations=E2=80=9D entries in the token response:=20 >>>>=20 >>>> "multiple_access_tokens":{ >>>> "token_a":{ >>>> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>>> "type":"bearer", >>>> "locations":[ >>>> "https://example.com/resource" >>>> ] >>>> }, >>>> "token_b":{ >>>> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >>>> "type":"bearer", >>>> "locations":[ >>>> "https://other_example.com/resource" >>>> ] >>>> } >>>> } >>>>=20 >>>> Since the client passed the locations values in the request, it is = also able to determine where to use what access token.=20 >>>>=20 >>>> I think that=E2=80=99s pretty simple, especially from a client = perspective. =20 >>>>=20 >>>> And If the client wants to split access tokens further apart, e.g. = to obtain tokens with less privileges, it can do so using the request = syntax you defined:=20 >>>>=20 >>>> resources: { >>>> token1: [{ >>>> actions: ["read", "write", "dolphin"], >>>> locations: ["https://server.example.net/", = "https://resource.local/other"], >>>> datatypes: ["metadata", "images"] >>>> }], >>>> token2: [{ >>>> actions: ["foo", "bar", "dolphin"], >>>> locations: ["https://resource.other/"], >>>> datatypes: ["data", "pictures"] >>>> }] >>>> } >>>>=20 >>>> In the simplest case, the AS would return the data as in your = proposal. >>>>=20 >>>> If the client asks for a partitioning of privileges that goes = across RS security domains like this >>>>=20 >>>> { >>>> "resources":{ >>>> "token1":[ >>>> { >>>> "actions":[ "read", "write","dolphin" ], >>>> "locations":[ = "https://server.example.net/","https://resource.local/other"], >>>> "datatypes":[ "metadata","images"] >>>> }, >>>> { >>>> "actions":["read","write"], >>>> "locations":["https://example.com/resource"] >>>> } >>>> ], >>>> "token2":[ >>>> { >>>> "actions":["foo","bar", "dolphin"], >>>> "locations":["https://resource.other/"], >>>> "datatypes":["data","pictures"] >>>> } >>>> ] >>>> } >>>> } >>>>=20 >>>> the AS would need to further partition the pre-defined tokens like = this: >>>>=20 >>>> "multiple_access_tokens=E2=80=9D:{ >>>> =E2=80=9Ctoken1/a":{ >>>> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>>> "type":"bearer", >>>> = "locations":["https://server.example.net/","https://resource.local/other"]= >>>> }, >>>> =E2=80=9Ctoken1/b":{ >>>> "value":"OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0", >>>> "type":"bearer", >>>> "locations":["https://example.com/resource"] >>>> }, >>>> =E2=80=9Ctoken2":{ >>>> "value":"UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1", >>>> "type":"bearer", >>>> "locations":[ >>>> "https://other_example.com/resource" >>>> ] >>>> } >>>> } >>>>=20 >>>> Naming of the tokens is a bit tricky but I think solvable. >>>>=20 >>>> What do you think? >>>>=20 >>>> best regards, >>>> Torsten. >>>>=20 >>>>> On 15. Mar 2020, at 15:26, Justin Richer wrote: >>>>>=20 >>>>> On Mar 15, 2020, at 8:58 AM, Torsten Lodderstedt = wrote: >>>>>>=20 >>>>>>> On 15. Mar 2020, at 03:25, Justin Richer = wrote: >>>>>>>=20 >>>>>>> So if the AS needs a client to get different access tokens to = call different RS domains, it does exactly what we do in OAuth 2 today = =E2=80=94 it tells the client to get two different access tokens.=20 >>>>>>=20 >>>>>> How does this work in XYZ? >>>>>>=20 >>>>>=20 >>>>> Without using the multi-access-token thing I=E2=80=99m proposing = in this thread, the client would just make two separate transaction = calls to get two different tokens. There=E2=80=99s a few ways that = shakes out depending on some of the details. In the OAuth world that = amounts to involving the user twice, and it might be the same in XYZ if = you=E2=80=99re asking for different things: >>>>>=20 >>>>> 1. Client: Start TX-1 (R-1) >>>>> 2. User: Approve R-1 >>>>> 3. AS: Issue AT-1(R-1) >>>>> 4. Client: Start TX-2 (R-1) >>>>> 5. User: approve R-2 >>>>> 6. AS: Issue AT-2(R-2) >>>>>=20 >>>>> Unless you=E2=80=99re getting a super refresh token upfront and = then calling for two downgraded access tokens later =E2=80=94 which does = work, and I=E2=80=99ve built out systems that do exactly that. XYZ can = do that trick too. >>>>>=20 >>>>> 1. Client: Start TX-1 (R-1, R-2) >>>>> 2. User: Approve R-1, R-2 >>>>> 3. AS: Issue AT1 (R-1, R-2) >>>>> 4. Client: Continue TX-1 (R-2) >>>>> 5. AS: Issue AT-2 (R-2) >>>>>=20 >>>>> But we=E2=80=99ve got another thing we can use in XYZ to help = this, the user handle. This lets a trusted client tell the AS that it = believes the same user is still there and asking the question, so if the = access rights are OK then you don=E2=80=99t need to involve the user = again. We invented this construct with UMA2, where it=E2=80=99s called = the persisted claims token (PCT). >>>>>=20 >>>>> 1. Client: Start TX-1 (R-1) >>>>> 2. User: Approve R-1 >>>>> 3. AS: Issue AT-1 (R-1), user handle U-1 >>>>> 4. Client Start TX-2 (R-2, U-1) >>>>> 5. AS: Issue AT-2 (R-2) >>>>>=20 >>>>> Now: With the multi-token request, we can collapse this all back = to a single transaction with multiple outputs: >>>>>=20 >>>>> 1. Client: Start TX-2 (token1: R-1, token2: R-2) >>>>> 2. User Approve R-1, R-2 >>>>> 3. AS: Issue AT-1 (token1: R-1), AT-2 (token2: R-2) >>>>>=20 >>>>> I haven=E2=80=99t liked any of the multi-access-token solutions to = date because they make things weird for single access token requests. I = like this idea because it=E2=80=99s an optimization for a complex case = that doesn=E2=80=99t change the behavior for the simple case, and in = fact doesn=E2=80=99t even change the expectations for the simple case. = To me, that=E2=80=99s important. >>>>>=20 >>>>> =E2=80=94 Justin >>>>=20 >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>=20 From nobody Sun Mar 22 10:50:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64A3A0945 for ; Sun, 22 Mar 2020 10:50:50 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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=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 bLXlpnauPakx for ; Sun, 22 Mar 2020 10:50:47 -0700 (PDT) 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 971143A04BB for ; Sun, 22 Mar 2020 10:50:46 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id t7so9212195wrw.12 for ; Sun, 22 Mar 2020 10:50:46 -0700 (PDT) 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=nReawj4QzmE7MH/swIxcaCsTWAJHj1Vbcl/W4ssfscU=; b=y0xI90kRLh6WTOMz6zs5o9s7e2ZTd+JiJTG+pS2jyOBkV2pCkeVMNq8+VUN+PViSxI QFxGt5gfK20XfB8zKO+TI8jqcg3S2vFWXlak4DeojR9BBmBUQW9QqI8oqQPaIcSSxAZh LP85rw38IVEVpczX1Z+ih9IhekPiQjJSB1GzO0tcGO3XoCcwHrGqvhE+DqyfBeqFMgmK 4iqq53AXB4svSPiukMHlgVa5Z3fbk08IfcStE5meRkIDLSJXpX07Lqa7k+BRVY+mt1gd HoCc7VfrlJeYX0EE/MM0X0aVoYnCNNUw9yLtVOPLsI3VHyg9t5Yw/dmT7Ur/I5cTz5aW Wxrw== 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=nReawj4QzmE7MH/swIxcaCsTWAJHj1Vbcl/W4ssfscU=; b=VG5VCuKrr6b1XjESatEf8+GA4nAPILysyIjy+hL8A85qg844KSWC4b1Qr6nmzr1ueX 4ZUQfHUo48gZp0oG8H4ZdDXO0mwjTEL3DeTLrzwNsgqu6I+r6oO3RNUIMW2PqEGrJkka CItKATql5bDplQmaJ1Y1H1oiOxh/I3bd9WkqqF3tBoF+NeF7aWKNyxa0oE/d3M2nQc+/ MkPlWgRfXLiN5rEt/LPnDZAWbmtAaEttCxaxMHBwOxWKm+loxb9OK3nfWlX6FuQQSdzw XxOYfambm62GJc82+pil1OeAzZIHhyscMxLCHIS/78t+agXGCHx+VRqLysHQuwpRwNUO 4cKw== X-Gm-Message-State: ANhLgQ2y0zRfzfXaMwbZeNmyyyVSOi5+EK5I0W+pflmqAudgF4UeZryf Ea7+19KoQTGzmjM3OCM9jqp1Nw== X-Google-Smtp-Source: ADFU+vsj7+eB6EhsXh6z4Xes8LHwrG3SLbrU3Jm9sfsS6gWQHg0dXFOt3ECg8LtyfaniyEKpVOywZw== X-Received: by 2002:a5d:6245:: with SMTP id m5mr24922611wrv.154.1584899444604; Sun, 22 Mar 2020 10:50:44 -0700 (PDT) Received: from [192.168.71.111] (p549EE22B.dip0.t-ipconnect.de. [84.158.226.43]) by smtp.gmail.com with ESMTPSA id s8sm14895840wrv.97.2020.03.22.10.50.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2020 10:50:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Sun, 22 Mar 2020 18:50:43 +0100 Cc: Mike Jones , Kim Cameron , Filip Skokan , txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dick Hardt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 17:50:51 -0000 Hi Dick, thanks for trying to consider the concerns we have raced in an update to = the proposed charter.=20 > On 21. Mar 2020, at 20:55, Dick Hardt wrote: >=20 > (replying with those that had expressed concerns about the charter on = the To: list to bring it to the top of their inbox) >=20 > Mike, Kim, Torsten, Filip: are your concerns addressed with the = changes below? >=20 > (apologies to anyone I missed in the To: list) >=20 > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer = wrote: > After some great discussions on the list in the last week, Yaron, = Dick, and I have pulled together a new proposed charter. I think this is = version 5.0? But I forget exactly. :) >=20 > I=E2=80=99ve highlighted the new lines in bold here, for those = reading this email in HTML. There=E2=80=99s a diff available online at = http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be = able to read it better). I=E2=80=99m attaching the .DIFF file generated = by Mergely as well, for those of us crusty old unix type folks who like = to see that. >=20 >=20 >=20 >=20 >=20 > This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >=20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 I don't see how this list captures the requirement I raised.=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Support for multiple access tokens in a single request This item justifies Justin=E2=80=99s latest addition to XYZ to allow the = client to allocate resources to access tokens. That=E2=80=99s fine, but = it=E2=80=99s geared towards the client deciding how to split tokens.=20 I=E2=80=99m looking for a way to let the RS (with the AS acting on its = behalf) influence the token allocation and with that the token design. = As I have explained several times, the token format & content is part of = the AS to RS interface and the current charter limits this to a single = design option: handles + token introspection, at least in multi RS = scenarios.=20 The current charter therewith enshrines one of the big design = limitations OAuth 2 had, which has significant consequences with respect = to security, privacy, UX, performance, and cost.=20 I understand the intention to keep things for clients as simple as = possible, but it shouldn't be simpler and at the cost of other parties. = In particular, this optimisation is at the cost of resource server = implementers, whose options are very limited with the current charter. I = think the new protocol should leave the optimisation decision to = particular deployments and instead support a variety of design options = implementers can choose from.=20 I suggest to add the following bullet: - Support for a wide range of access token policies, including single = token per transaction and RS-specific access tokens at the discretion of = the AS > - Support for directed, audience-restricted access tokens This looks good on first sight but it misses the important point that = the AS on behalf of the RS can decide to issue such tokens. > - Separation between the party authorizing access and the party = operating the client requesting access > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation = process (including asserted identity claims) wfm although I don't understand why this is an extension point and not = incorporated in the bullet below. >=20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an = access token wfm =20 >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >=20 > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 I=E2=80=99m still not seeing the benefit of including identity at the = "AS to client" interface in this charter. This paragraph could be = removed without any impact on the rest of the charter.=20 >=20 > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points General observations: While I was reading the updated charter several times, I made the = following observations:=20 The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in = this charter.=20 So I=E2=80=99m asking: Do we intend to build a protocol for = interoperability?=20 If we are aiming for interoperability, what level of interoperability do = we want to achieve? I think we must aim for "on the wire" = interoperability that can be tested automatically. That would allow to = truly use TXAuth based authorization wherever an API is being protected = using TXAuth without the need for deployment specific customisation, = just like BASIC auth and TLS. If we are aiming for interoperability, where do we seek for = interoperability? At the client - AS interface only? Or do we consider = the AS - RS interface as well? And what is about the client - RS = interface? I think all of them should be in scope for various reasons.=20= Client - AS: clearly in scope even if not stated=20 AS - RS: would allow to combine ASs and RSs from different sources. = That's an important requirement for us (yes.com), since we run a >1000 = AS federation where the RSs can be invoked using tokens from all of = those ASs (that are built using different products). Combining software = on both ends from different sources (e.g. different vendors) is another = example. Interoperability between AS and RS is a key success factor in = such a scenario and is less than poorly supported today by OAuth 2. = TXAuth should do better.=20 Client - RS: there is an obvious reason, which is the way access tokens = are conveyed. The less obvious reason is to take a look into how a = client could find out what it takes to perform a suitable authorization = process to be able to invoke a particular RS.=20 It totally strikes me that the latter two interfaces seem to be mostly = out of scope. To me the current charter will cause the TXAuth WG to look = onto a small portion of the overall process (client to AS) only. The = result will be incomplete and needs to be patched together with the rest = in real implementations.=20 I therefore suggest to add the following text after the first paragraph=20= "The delegation protocol will enable interoperability between client and = authorization server, authorisation server and resource server and, as = needed to perform delegation, client and resource server. Conformance of = an implementation with the specifications can be tested automatically." Which also brings me to Nat=E2=80=99s proposal to write an architecture = document. I=E2=80=99m not convinced we need an architecture document (in = the sense of a RFC), but I=E2=80=99m sure we need to discuss and = document overall use cases and design options. Understanding those is = the prerequisite to design a suitable and as easy as possible protocol.=20= So please add the following bullet to the charter under Milestones:=20 "- documentation of the use cases and design options the new protocol = will support" best regards, Torsten.=20 >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Sun Mar 22 11:24:12 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F314B3A0989 for ; Sun, 22 Mar 2020 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 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, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=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 wK_Wtdo2wVzB for ; Sun, 22 Mar 2020 11:24:08 -0700 (PDT) Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) (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 DF0013A0871 for ; Sun, 22 Mar 2020 11:24:07 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id z15so14011271wrl.1 for ; Sun, 22 Mar 2020 11:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=EcuONjjl6GNEOeQXZaRfkNjM7jj0TwGRchu+2eFwDIQ=; b=UiXM/WatWWZ1iginEb+/OHUCNmF+CArGYTwaKQyGBSL699mrQBO/0WU5LjUZPRro6S +MIFBw5BCwBBttvo/QP6nVxv8Rv4Iy9yEUy4dRzeic2pTbEyQhcrJwlaVzDOKcyM81jI eG3y8qNpaCRBlsJccE6VwzV2nCE5TdAmmyDEXnlFwjkk+cjTQA4uixn+c/Hn6UgwuDVD rpVfmemDUI+fzdbkMqE5iYSZ/mqr9RPLhxgv95tP86v6QE5gtbI6SFxc4s2eCUyxmBER jkvMMnYAbH02ebDdaF9VL+BZpX4cUQZd2CJjvo+3rz0kzRt6pTjsIki187OfJtUILLQn w8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=EcuONjjl6GNEOeQXZaRfkNjM7jj0TwGRchu+2eFwDIQ=; b=Be6QEsgyVpFTBWr6NYkmUkxB9LkxD8Umw1bGwSVp2+iLVB5I7GEYFg4hLXUKxMwD62 PRLvI1sWYv4CBAMacWBdsPOB2KBppstjoZd6w97Gd9bv1mI1UBtyiDdD6+Nek8QKDYmw MSfjHmL//DeXzKPHKZQ1l9phUX3fmodfQoK8NjmRdhud71X4CHnUBxQwLE0SxcWzoMV7 5DVxII1WpCVKwxOwMhwXuva2ntUufNWOxLNGxD8hvlZ7/YYPqMXBlv+LHHn0QHpEp+XE avYqzFjPlugcX/Z16d1ZvN0hI+MyozBMOHxw0MWCS0pHILavGiypBb08N0bnnaIvnxrW zuaQ== X-Gm-Message-State: ANhLgQ08RLPLdX+2vRIGPURQLYn2Vom7sq1Id50+6AGZV8KyEgjMfs/4 fZO3CGsdvasppDGdKXm+bF8= X-Google-Smtp-Source: ADFU+vuKVYvwcBdJh+er9Q5u/YUVDirFNv+DxwVjbfKGcplZGSTOuOddFwk59LQux6ncUnmbEYvErg== X-Received: by 2002:a5d:4d07:: with SMTP id z7mr24165373wrt.89.1584901446234; Sun, 22 Mar 2020 11:24:06 -0700 (PDT) Received: from [10.0.0.157] (bzq-79-181-20-162.red.bezeqint.net. [79.181.20.162]) by smtp.gmail.com with ESMTPSA id w81sm18166540wmg.19.2020.03.22.11.24.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2020 11:24:05 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Sun, 22 Mar 2020 20:24:03 +0200 From: Yaron Sheffer To: Dick Hardt , Justin Richer CC: Vijay IETF , , David Skaife Message-ID: Thread-Topic: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3667753444_1535892466" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 18:24:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3667753444_1535892466 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Moreover, even if we have an MTI (which I support for the reasons Dick poin= ted out), a particular *deployment* may not support it, i.e. it may be disab= led by the AS. =E2=80=9CMust implement=E2=80=9D does not mean =E2=80=9Cmust use=E2=80=9D. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Txauth on behalf of Dick Hardt Date: Saturday, March 21, 2020 at 20:36 To: Justin Richer Cc: Vijay IETF , , David Skaife Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Posses= sion =20 Discovery lets the client know what other mechanisms are available besides = the MTI mechanism.=20 =20 If there is no MTI, then there is no interop unless ALL mechanisms are impl= emented independent of discovery. =20 =20 On Sat, Mar 21, 2020 at 10:58 AM Justin Richer wrote: Dick, =20 I think there=E2=80=99s a big difference between a =E2=80=9Cdefault=E2=80=9D and =E2=80=9CMTI=E2=80=9D. I= f you mean that the protocol chooses one key proofing method as =E2=80=9CMTI=E2=80=9D fo= r the AS, then I can maybe get behind that idea. I think the realm of MTI is= something that we do need to decide as a group, but that goes for all of th= e various features and options in the protocol. I think OAuth 2 went too far= into the =E2=80=9Ceverything=E2=80=99s optional=E2=80=9D world, but at the same time, we don=E2= =80=99t want to go too far into the OAuth 1 world of =E2=80=9Cthis is all mandatory be= cause of one tiny use case=E2=80=9D.=20 =20 Also, an observation - if we mandate discovery as you=E2=80=99ve proposed in XAut= h, then doesn=E2=80=99t the argument for any MTI fall a little flat? Since a clien= t can discover which methods are available, a smarter client can discover an= d configure itself based on that set of options.=20 =20 I contend that that clients, even general purpose ones, aren=E2=80=99t going to b= e very smart in that regard. I think it=E2=80=99s vanishingly rare for a piece of = client software in the OAuth 2 world to call the discovery document and chan= ge which authentication method it=E2=80=99s going to use. Instead, this tends to b= e driven by the developer who=E2=80=99s configured the client software library to = behave in a specific way. I think we=E2=80=99ll continue to see that pattern here = with TxAuth, especially as things go to embedded systems that get hardcoded = to work in one specific way. =20 =E2=80=94 Justin =20 =20 On Mar 21, 2020, at 1:21 PM, Dick Hardt wrote: =20 Hi Vijay =20 Thanks for asking for clarification.=20 =20 If there is no default or minimum to implement (MTI) requirement, then for = interop to be guaranteed between a client and an AS, one of the parties will= need to support all of the choices since the other party could choose to su= pport only one of the choices. In this work, we have tended to push complexi= ty to the AS, so the AS would need to implement all choices to be compliant.= =20 =20 If there is a default, then only the default MUST be implemented by both pa= rties to be compliant. =20 Of course, any bespoke implementation can do whatever they want.=20 =20 While you may not personally be a fan of general purpose software, others a= re, and as a group we need to anticipate the implications for all implemento= rs. =20 =20 =20 =20 =20 =20 On Sat, Mar 21, 2020 at 1:29 AM Vijay IETF wrote: Hi Dick, =20 Thanks for the additional context for reasoning. My response inline. =20 On Sat, 21 Mar 2020 at 06:00, Dick Hardt wrote: =20 If all choices are equal (no default), then ALL the choices have to be impl= emented in a general purpose implementation, which increases the attack surf= ace and vulnerability of an implementation, ie a coding error. =20 =20 I do not see how having a no default implies all choices being equal. I am= missing the nuance here.=20 =20 The +1 for xyz rationale was to favor implementations that have the freedom= to implement what they see fit and still be "compliant" with the protocol. = I am not a fan of bloated general purpose software implementations, so I don= 't have much to comment on that. Sorry. =20 --- Vijay =20 -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3667753444_1535892466 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Moreover, even if we have an MTI (which I support = for the reasons Dick pointed out), a particular *deployment* may not = support it, i.e. it may be disabled by the AS. =E2=80=9CMust implement=E2=80=9D does not= mean =E2=80=9Cmust use=E2=80=9D.

 

=

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in = 0in'>

From: = Txauth <txauth-boun= ces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
= Date: Saturday, March 21, 2020 at 20:36
To: Justin Richer <= jricher@mit.edu>
Cc: Vijay IETF <vijay.ietf@gmail.com>, &= lt;txauth@ietf.org>, David Skaife <blue.ringed.octopus.guy@gmail.com&g= t;
Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Pro= of of Possession

&nb= sp;

Discovery lets the client know wh= at other mechanisms are available besides the MTI mechanism. 

 

If there is no MTI, then there is no interop unless ALL mechanisms are i= mplemented independent of discovery.

 

 

On Sat, Mar 21, 2020 at 10:58 AM Justin = Richer <jricher@mit.edu> wrote:

Dick,

 

I think there=E2=80=99s a big difference betwee= n a =E2=80=9Cdefault=E2=80=9D and =E2=80=9CMTI=E2=80=9D. If you mean that the protocol chooses one k= ey proofing method as =E2=80=9CMTI=E2=80=9D for the AS, then I can maybe get behind that= idea. I think the realm of MTI is something that we do need to decide as a = group, but that goes for all of the various features and options in the prot= ocol. I think OAuth 2 went too far into the =E2=80=9Ceverything=E2=80=99s optional=E2=80=9D wo= rld, but at the same time, we don=E2=80=99t want to go too far into the OAuth 1 wo= rld of =E2=80=9Cthis is all mandatory because of one tiny use case=E2=80=9D. <= /o:p>

 

Also, an observation - if we mandate discovery as you=E2=80=99ve pro= posed in XAuth, then doesn=E2=80=99t the argument for any MTI fall a little flat? = Since a client can discover which methods are available, a smarter client ca= n discover and configure itself based on that set of options. 

 

I contend that that clients, even general purpose ones, aren=E2=80=99t = going to be very smart in that regard. I think it=E2=80=99s vanishingly rare for a= piece of client software in the OAuth 2 world to call the discovery documen= t and change which authentication method it=E2=80=99s going to use. Instead, this = tends to be driven by the developer who=E2=80=99s configured the client software l= ibrary to behave in a specific way. I think we=E2=80=99ll continue to see that pat= tern here with TxAuth, especially as things go to embedded systems that get = hardcoded to work in one specific way.

 

 =E2=80=94 Justin

 

<= p class=3DMsoNormal> 



=

On Mar 21, 2020, at 1:21 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

 

Hi Vijay

 

Thanks for asking for clarification. 

 

<= p class=3DMsoNormal>If there is no default or minimum to implement (MTI) requi= rement, then for interop to be guaranteed between a client and an AS, one of= the parties will need to support all of the choices since the other party c= ould choose to support only one of the choices. In this work, we have tended= to push complexity to the AS, so the AS would need to implement all choices= to be compliant. 

&nb= sp;

If there is a default, then only = the default MUST be implemented by both parties to be compliant.<= /p>

 

Of course, any bespoke implementation can do whatever they want.&nbs= p;

 

While you may not personally be a fan of general purpo= se software, others are, and as a group we need to anticipate the implicatio= ns for all implementors.

&n= bsp;

 

=

 

&= nbsp;

 

 

On Sa= t, Mar 21, 2020 at 1:29 AM Vijay IETF <vijay.ietf@gmail.com> wrote:

=

Hi Dick,

 

=

Thanks for the additional context for reasonin= g. My response inline.

 

On Sat, 21 Mar 2020 at 06:00, Dick Hardt= <dick.hardt@gmail.= com> wrote:

<snip>

If all choices are equal (no default), then ALL the choices have to= be implemented in a general purpose implementation, which increases the att= ack surface and vulnerability of an implementation, ie a coding error.<= /o:p>

 

 

I do not see how having a no default  implies all choices being= equal. I am missing the nuance here.

 

The +1 for xyz rat= ionale was to favor implementations that have the freedom to implement what = they see fit and still be "compliant" with the protocol. I am not = a fan of bloated general purpose software implementations, so I don't have m= uch to comment on that. Sorry.

&= nbsp;

---

Vijay

 

-- Txauth mailing list Txauth@ietf= .org https://www.ietf.org/mailman/listinfo/txauth

--B_3667753444_1535892466-- From nobody Sun Mar 22 11:31:40 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2505B3A099B for ; Sun, 22 Mar 2020 11:31:38 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 akJzIiFdprbH for ; Sun, 22 Mar 2020 11:31:35 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450: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 F000B3A0808 for ; Sun, 22 Mar 2020 11:31:34 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id j11so8445637lfg.4 for ; Sun, 22 Mar 2020 11:31:34 -0700 (PDT) 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=lbcHT4lhOBIaFEVTDgFR2mS5YHxSyqGjcMtxbs/aO9o=; b=CxqoGcM2fEu/jmhHfDO2ugjau9bHRRdiSNuYkhquq0hK/gOAx/KsjwDppsBmbcJB7w qPUZmzw8U7b7/AJBccY4Xj/1lQAjhOy649mT48wrJKqRAQAg4PtZcK9FV5w0Ds/HjNbp HWxJc3kM9ogQTwAteWHzKmoqPJBbBIpoBNPWWU1bSJCtNxqDVl+eSCs0f6wjbuLh6f2e feCLCxZfiHF3u9ZQ2I2qIDfHYz/kNwB0MV47KuydzV3KabfPa2UTnJlAHRPwjVtvwEtj jzFoBazf1lWeLQ4K9B70iDuxaRcmkkUJUggUeHp8Drr+WRlOmoUHzr2kJ+DFU1drauo4 nssg== 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=lbcHT4lhOBIaFEVTDgFR2mS5YHxSyqGjcMtxbs/aO9o=; b=WGK0pHWsfOCsOAd+4AfDboiENwO7GiIvaZtRVPTFIQLVDqdV7cSzULHbGO2VtIzdnt KjhoiXmCMFoZH7R3bNumgJ5tSP0jdsO2mOx0PT9TOOXpAPSanSC0fm2cNX1Fcvi3e3yy FLrgs0wNFcAWP5UijNUB25xAws68l/qGMh8rewTg77ZuCL4z22MZYHnMNg7CRoHhDa4H OYukRkhj5Rz/LdKNoXMQ7V9T2CHImrAJtuMKGDinTu0PxxWqIiU3IZplEKNoF3sX89+Z tg7dhg71Sr1IlQPuN3l79OAT1FBWKDF9/o8lNPsv5zhk56peIrMzR+H0/OPPsNfXUE8w pUwg== X-Gm-Message-State: ANhLgQ0HxvObpjei1O0LhNt0Sc9du1GBx62jcf8yfBUHfiPJm9hu9yIb jR0NW+F4n9xJEkG1TjMtpHySvkuVW2KS9fzdTT4= X-Google-Smtp-Source: ADFU+vtpz3oGnilrcV9YwD4ejk/T5YH4oF8o4TTvxIOKIGxiBOm0ToI2yYoD9qsMl60AirEVsoTd8HislQVZ7fkDe5A= X-Received: by 2002:a19:a401:: with SMTP id q1mr10702674lfc.157.1584901892889; Sun, 22 Mar 2020 11:31:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 22 Mar 2020 11:31:06 -0700 Message-ID: To: Torsten Lodderstedt Cc: Mike Jones , Kim Cameron , Filip Skokan , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005461f105a175ba16" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 18:31:38 -0000 --0000000000005461f105a175ba16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dick, > > thanks for trying to consider the concerns we have raced in an update to > the proposed charter. > > > On 21. Mar 2020, at 20:55, Dick Hardt wrote: > > > > (replying with those that had expressed concerns about the charter on > the To: list to bring it to the top of their inbox) > > > > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes > below? > > > > (apologies to anyone I missed in the To: list) > > > > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer wrote: > > After some great discussions on the list in the last week, Yaron, Dick, > and I have pulled together a new proposed charter. I think this is versio= n > 5.0? But I forget exactly. :) > > > > I=E2=80=99ve highlighted the new lines in bold here, for those reading= this > email in HTML. There=E2=80=99s a diff available online at > http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be able > to read it better). I=E2=80=99m attaching the .DIFF file generated by Mer= gely as > well, for those of us crusty old unix type folks who like to see that. > > > > > > > > > > > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > > > Additionally, the delegation process will allow for: > > > > I don't see how this list captures the requirement I raised. > > > - Fine-grained specification of access > > - Approval of AS attestation to identity claims > > - Approval of access to multiple resources and APIs in a single > interaction > > - Support for multiple access tokens in a single request > > This item justifies Justin=E2=80=99s latest addition to XYZ to allow the = client to > allocate resources to access tokens. I've multiple access tokens in XAuth since the first draft. No one told me that was not scope for the charter back then. I consider "fine grained specification of access" to include many different ways to be fine grained. We added multiple tokens to clarify > That=E2=80=99s fine, but it=E2=80=99s geared towards the client deciding = how to split > tokens. > I don't see why the scope is limited to the client deciding. In current OAuth 2.0 use cases, which is in scope, the AS decides what it will, and will not issue tokens for. Extending that to multiple tokens, and multiple resources to me implies the AS can still decide what each token can do. > > I=E2=80=99m looking for a way to let the RS (with the AS acting on its be= half) > influence the token allocation and with that the token design. As I have > explained several times, the token format & content is part of the AS to = RS > interface and the current charter limits this to a single design option: > handles + token introspection, at least in multi RS scenarios. > I don't think that is the case at all. XAuth has a different design pattern. Each Authorization is independent of each other. We also added the following to the charter. *- Mechanisms for the AS and RS to communicate the access granted by an access token* I would consider the token format and content to be one mechanism for the AS to communicate with the RS. > > The current charter therewith enshrines one of the big design limitations > OAuth 2 had, which has significant consequences with respect to security, > privacy, UX, performance, and cost. > > I understand the intention to keep things for clients as simple as > possible, but it shouldn't be simpler and at the cost of other parties. I= n > particular, this optimisation is at the cost of resource server > implementers, whose options are very limited with the current charter. I > think the new protocol should leave the optimisation decision to particul= ar > deployments and instead support a variety of design options implementers > can choose from. > > I suggest to add the following bullet: > > - Support for a wide range of access token policies, including single > token per transaction and RS-specific access tokens at the discretion of > the AS > I think that is already covered by the existing charter. > > > - Support for directed, audience-restricted access tokens > > This looks good on first sight but it misses the important point that the > AS on behalf of the RS can decide to issue such tokens. > The AS decides what tokens it will issue to a Client already in OAuth 2.0, so it is in scope. What am I missing? > > > - Separation between the party authorizing access and the party > operating the client requesting access > > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > > - Cryptographic agility for keys, message signatures, and proof of > possession > > - User interaction mechanisms including web and non-web methods > > - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > > - Optimized inclusion of additional information through the delegation > process (including asserted identity claims) > > wfm although I don't understand why this is an extension point and not > incorporated in the bullet below. > > > > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > > > - Discovery of the authorization server > > - Revocation of active tokens > > - Mechanisms for the AS and RS to communicate the access granted by an > access token > > wfm > > > > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new format= s > for identifiers or assertions, nor is the group chartered to develop > schemas for user information, profiles, or other identity attributes, > unless a viable existing format is not available. > > I=E2=80=99m still not seeing the benefit of including identity at the "AS= to > client" interface in this charter. This paragraph could be removed withou= t > any impact on the rest of the charter. > Are you questioning why identity is in scope, or that this statement is redundant? > > > > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > > > Milestones to include: > > - Core delegation protocol > > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > > - Identity and authentication conveyance mechanisms > > - Guidelines for use of protocol extension points > > General observations: > > While I was reading the updated charter several times, I made the > following observations: > > The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in th= is charter. > > So I=E2=80=99m asking: Do we intend to build a protocol for interoperabil= ity? > I would consider a protocol requires interoperability. A framework does not= . The charter states that we are building a protocol, which appears throughout the charter text. > > If we are aiming for interoperability, what level of interoperability do > we want to achieve? I think we must aim for "on the wire" interoperabilit= y > that can be tested automatically. That would allow to truly use TXAuth > based authorization wherever an API is being protected using TXAuth witho= ut > the need for deployment specific customisation, just like BASIC auth and > TLS. > > If we are aiming for interoperability, where do we seek for > interoperability? At the client - AS interface only? Or do we consider th= e > AS - RS interface as well? And what is about the client - RS interface? I > think all of them should be in scope for various reasons. > > Client - AS: clearly in scope even if not stated > > AS - RS: would allow to combine ASs and RSs from different sources. That'= s > an important requirement for us (yes.com), since we run a >1000 AS > federation where the RSs can be invoked using tokens from all of those AS= s > (that are built using different products). Combining software on both end= s > from different sources (e.g. different vendors) is another example. > Interoperability between AS and RS is a key success factor in such a > scenario and is less than poorly supported today by OAuth 2. TXAuth shoul= d > do better. > > Client - RS: there is an obvious reason, which is the way access tokens > are conveyed. The less obvious reason is to take a look into how a client > could find out what it takes to perform a suitable authorization process = to > be able to invoke a particular RS. > To clarify, you would like discovery at the RS to be in scope? Rereading the charter, I can see that is not specifically called out, and discovery at the RS could be considered out of scope. I could also argue that it is in scope in order for the client to know how to present tokens to the RS. > > It totally strikes me that the latter two interfaces seem to be mostly ou= t > of scope. To me the current charter will cause the TXAuth WG to look onto= a > small portion of the overall process (client to AS) only. The result will > be incomplete and needs to be patched together with the rest in real > implementations. > The former, how the client presents tokens, is in scope: - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys > > I therefore suggest to add the following text after the first paragraph > > "The delegation protocol will enable interoperability between client and > authorization server, authorisation server and resource server and, as > needed to perform delegation, client and resource server. Conformance of = an > implementation with the specifications can be tested automatically." > I think your first sentence is already covered, although each point is spread out through the charter. I think your second sentence is overly specific. > > Which also brings me to Nat=E2=80=99s proposal to write an architecture d= ocument. > I=E2=80=99m not convinced we need an architecture document (in the sense = of a RFC), > but I=E2=80=99m sure we need to discuss and document overall use cases an= d design > options. Understanding those is the prerequisite to design a suitable and > as easy as possible protocol. > > So please add the following bullet to the charter under Milestones: > > "- documentation of the use cases and design options the new protocol wil= l > support" > I think what we do to meet the "Core delegation protocol" milestone is up to the group to decide. I don't think we have to have it in the charter. > > best regards, > Torsten. > > > > > > > > > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > --0000000000005461f105a175ba16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 22, 2020 at 10:50 AM Tors= ten Lodderstedt <torsten@lodd= erstedt.net> wrote:
Hi Dick,

thanks for trying to consider the concerns we have raced in an update to th= e proposed charter.

> On 21. Mar 2020, at 20:55, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> (replying with those that had expressed concerns about the charter on = the To: list to bring it to the top of their inbox)
>
> Mike, Kim, Torsten, Filip: are your concerns addressed with the change= s below?
>
> (apologies to anyone I missed in the To: list)
>
> On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <jricher@mit.edu> wrote:
> After some great discussions on the list in the last week, Yaron, Dick= , and I have pulled together a new proposed charter. I think this is versio= n 5.0? But I forget exactly. :)
>
> I=E2=80=99ve highlighted the new lines in bold here,=C2=A0 for those r= eading this email in HTML. There=E2=80=99s a diff available online at=C2=A0= http://www.mergely.com/RehoJJvW/=C2=A0 (note: go to view->wo= rd wrap to be able to read it better). I=E2=80=99m attaching the .DIFF file= generated by Mergely as well, for those of us crusty old unix type folks w= ho like to see that.
>
>
>
>
>
> This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an au= thorizing party to delegate access to client software through an authorizat= ion server. It will expand upon the uses cases currently supported by OAuth= 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support autho= rizations scoped as narrowly as a single transaction, provide a clear frame= work for interaction among all parties involved in the protocol flow, and r= emove unnecessary dependence on a browser or user-agent for coordinating in= teractions.
>
> The delegation process will be acted upon by multiple parties in the p= rotocol, each performing a specific role. The protocol will decouple the in= teraction channels, such as the end user=E2=80=99s browser, from the delega= tion channel, which happens directly between the client and the authorizati= on server (in contrast with OAuth 2.0 which is initiated by the client redi= recting the user=E2=80=99s browser). The client and AS will involve a user = to make an authorization decision as necessary through interaction mechanis= ms indicated by the protocol. This decoupling avoids many of the security c= oncerns and technical challenges of OAuth 2.0 and provides a non-invasive p= ath for supporting future types of clients and interaction channels.
>
> Additionally, the delegation process will allow for:
>

I don't see how this list captures the requirement I raised.

> - Fine-grained specification of access
> - Approval of AS attestation to identity claims
> - Approval of access to multiple resources and APIs in a single intera= ction
> - Support for multiple access tokens in a single request

This item justifies Justin=E2=80=99s latest addition to XYZ to allow the cl= ient to allocate resources to access tokens.

I've multiple access=C2=A0tokens in XAuth since the first draft= . No one told me that was not scope for the charter back then. I consider &= quot;fine grained specification of access" to include many different w= ays to be fine grained.=C2=A0

We added multiple=C2= =A0tokens to clarify
=C2=A0
That=E2=80=99s fine, but it=E2=80=99s geared toward= s the client deciding how to split tokens.

=
I don't see why the scope is limited to the client deciding. In cu= rrent OAuth 2.0 use cases, which is in scope, the AS decides what it will, = and will not issue tokens for. Extending that to multiple tokens, and multi= ple resources to me implies the AS can still decide what each token can do.=
=C2=A0

I=E2=80=99m looking for a way to let the RS (with the AS acting on its beha= lf) influence the token allocation and with that the token design. As I hav= e explained several times, the token format & content is part of the AS= to RS interface and the current charter limits this to a single design opt= ion: handles + token introspection, at least in multi RS scenarios.

I don't think that is the case at all.=C2= =A0
XAuth has a different design pattern. Each Authorization is i= ndependent=C2=A0of each other. We also added the following to the charter.<= /div>

- Mechanisms for the AS and RS to communicate t= he access granted by an access token

I would c= onsider the token format and content to be one mechanism for the AS to comm= unicate with the RS.
=C2=A0

The current charter therewith enshrines one of the big design limitations O= Auth 2 had, which has significant consequences with respect to security, pr= ivacy, UX, performance, and cost.

I understand the intention to keep things for clients as simple as possible= , but it shouldn't be simpler and at the cost of other parties. In part= icular, this optimisation is at the cost of resource server implementers, w= hose options are very limited with the current charter. I think the new pro= tocol should leave the optimisation decision to particular deployments and = instead support a variety of design options implementers can choose from. <= br>
I suggest to add the following bullet:

- Support for a wide range of access token policies, including single token= per transaction and RS-specific access tokens at the discretion of the AS<= br>

I think that is already covered by the = existing charter.=C2=A0
=C2=A0

> - Support for directed, audience-restricted access tokens

This looks good on first sight but it misses the important point that the A= S on behalf of the RS can decide to issue such tokens.

The AS decides what tokens it will issue to a Client alread= y in OAuth 2.0, so it is in scope. What am I missing?
=C2=A0

> - Separation between the party authorizing access and the party operat= ing the client requesting access
> - A variety of client applications, including Web, mobile, single-page= , and interaction-constrained applications
>
> The group will define extension points for this protocol to allow for = flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of pos= session
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other pie= ces of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding res= ource requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information through the delegation= process (including asserted identity claims)

wfm although I don't understand why this is an extension point and not = incorporated in the bullet below.

>
> Additionally, the group will provide mechanisms for management of the = protocol lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Mechanisms for the AS and RS to communicate the access granted by an= access token

wfm

>
> Although the artifacts for this work are not intended or expected to b= e backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att= empt to simplify migrating from OAuth 2.0 and OpenID Connect to the new pro= tocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as= such will focus on new technological solutions not necessarily compatible = with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be dev= eloped in the OAuth Working Group, including functionality back-ported from= the protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographi= c methods, such as JOSE and COSE, to the delegation process. This group is = not chartered to develop new cryptographic methods.
>
> The group is chartered to develop mechanisms for conveying identity in= formation within the protocol including identifiers (such as email addresse= s, phone numbers, usernames, and subject identifiers) and assertions (such = as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). = The group is not chartered to develop new formats for identifiers or assert= ions, nor is the group chartered to develop schemas for user information, p= rofiles, or other identity attributes, unless a viable existing format is n= ot available.

I=E2=80=99m still not seeing the benefit of including identity at the "= ;AS to client" interface in this charter. This paragraph could be remo= ved without any impact on the rest of the charter.
Are you questioning why identity is in scope, or that this sta= tement is redundant?
=C2=A0

>
> The initial work will focus on using HTTP for communication between th= e client and the authorization server, taking advantage of optimization fea= tures of HTTP2 and HTTP3 where possible, and will strive to enable simple m= apping to other protocols such as COAP when doing so does not conflict with= the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol for TLS, de= tached HTTP signature, and embedded HTTP signatures
> - Identity and authentication conveyance mechanisms
> - Guidelines for use of protocol extension points

General observations:

While I was reading the updated charter several times, I made the following= observations:

The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in this= charter.

So I=E2=80=99m asking: Do we intend to build a protocol for interoperabilit= y?

I would consider a protocol require= s interoperability. A framework does not.

The char= ter states that we are building a protocol, which appears throughout the ch= arter text.
=C2=A0

If we are aiming for interoperability, what level of interoperability do we= want to achieve? I think we must aim for "on the wire" interoper= ability that can be tested automatically. That would allow to truly use TXA= uth based authorization wherever an API is being protected using TXAuth wit= hout the need for deployment specific customisation, just like BASIC auth a= nd TLS.

If we are aiming for interoperability, where do we seek for interoperabilit= y? At the client - AS interface only? Or do we consider the AS - RS interfa= ce as well? And what is about the client - RS interface? I think all of the= m should be in scope for various reasons.

Client - AS: clearly in scope even if not stated

AS - RS: would allow to combine ASs and RSs from different sources. That= 9;s an important requirement for us (yes.com), since we run a >1000 AS federati= on where the RSs can be invoked using tokens from all of those ASs (that ar= e built using different products). Combining software on both ends from dif= ferent sources (e.g. different vendors) is another example. Interoperabilit= y between AS and RS is a key success factor in such a scenario and is less = than poorly supported today by OAuth 2. TXAuth should do better.

Client - RS: there is an obvious reason, which is the way access tokens are= conveyed. The less obvious reason is to take a look into how a client coul= d find out what it takes to perform a suitable authorization process to be = able to invoke a particular RS.

To cla= rify, you would like discovery at the RS to be in scope? Rereading the char= ter, I can see that is not specifically called out, and discovery at the RS= could be considered out of scope.=C2=A0

I could a= lso argue that it is in scope in order for the client to know how to presen= t tokens to the RS.=C2=A0
=C2=A0

It totally strikes me that the latter two interfaces seem to be mostly out = of scope. To me the current charter will cause the TXAuth WG to look onto a= small portion of the overall process (client to AS) only. The result will = be incomplete and needs to be patched together with the rest in real implem= entations.

The former, how the client = presents tokens, is in scope:

<= div>- Mechanisms for presenting tokens to resource servers and binding reso= urce requests to tokens and associated cryptographic keys
=C2=A0

I therefore suggest to add the following text after the first paragraph
"The delegation protocol will enable interoperability between client a= nd authorization server, authorisation server and resource server and, as n= eeded to perform delegation, client and resource server. Conformance of an = implementation with the specifications can be tested automatically."


I think your first senten= ce is already covered, although each point is spread out through the charte= r.=C2=A0

I think your second sentence is overly sp= ecific.=C2=A0
=C2=A0

Which also brings me to Nat=E2=80=99s proposal to write an architecture doc= ument. I=E2=80=99m not convinced we need an architecture document (in the s= ense of a RFC), but I=E2=80=99m sure we need to discuss and document overal= l use cases and design options. Understanding those is the prerequisite to = design a suitable and as easy as possible protocol.

So please add the following bullet to the charter under Milestones:

"- documentation of the use cases and design options the new protocol = will support"

I think what we do t= o meet the "Core delegation protocol" milestone is up to the grou= p to decide. I don't think we have to have it in the charter.
=C2=A0

best regards,
Torsten.


>
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--0000000000005461f105a175ba16-- From nobody Sun Mar 22 11:43:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7F43A09A3 for ; Sun, 22 Mar 2020 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 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, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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=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 ZhAtnPJw1h38 for ; Sun, 22 Mar 2020 11:43:38 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 040F73A099E for ; Sun, 22 Mar 2020 11:43:37 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id h9so14051934wrc.8 for ; Sun, 22 Mar 2020 11:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=WOF8Yr6sQuHWRL3bN8aTqi/nHgIzLAo4KrPAVm0ve18=; b=rdLfDS7Bjd0TyBqU/DGM700c8a9OIJTUGOOdcbLkBniNLtc/mrF+BywWUtV3tJzpa1 jimq7ku/RUZI+ECNCZJIN7wj4VzOTL5yuRNWfgzxm/OsS80dypHcXb82gm2C4NH2l9kD y/K2yal2nyhHPbAvZCXqBdupCTfUENFp3h6bn5yuCjoWj7r4T/yEz7fB646Djt8OYnIp jm4KKjNh7Us2nk+PjYR+ZoQ1eWznwd6MrHDImI83CKDfoSw09TqbKmh1YyRDPhyd7idD vWaVsOkIgI3LOyaVAY/fCJ/NfFT0QUswOUgxVWxhRQXBe/xker9vgl7FG1vdWWcZU8X7 29zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=WOF8Yr6sQuHWRL3bN8aTqi/nHgIzLAo4KrPAVm0ve18=; b=IwihSNbvNKMC+nz9RYuvVjx/gy6epWK1fDUE3Z9gvbmC+AibdiG91mnTjse4Nud1rr IxTduGIvWNT15RCoybRLtDBEeOl78vzMHnBH9A67xgX3T54wagKov1Q+20zT1HHYwa3A DitmrlMvWbfMtXv584gMgp0NS6irYpCP4KCE7UWwS3xcU8gneLuSvKUKAZnmqg9s1FnQ hcZP3tVisZw8dM5hPydc/m77H3e75kLoRA2bBSHVymDhJWzKyCsvN08J7xTmhYtfNMMA FxJxOeztriC8ytNyeHj3bdpAx8sfjVdHAPxasR59m9de3e6uaJiRzV5dcrZq3cpDRfST Ugpw== X-Gm-Message-State: ANhLgQ22D66J/fXuMeGZbi6rdzAeIILooyb5ySPjnWENCz1fmxWcPPog fenbUOMBaPuDPe6IFUGOTlQ= X-Google-Smtp-Source: ADFU+vsecci5915h89M9Qlcp3/Hj5d8dcjsb7CiUhCrvnQY09GAJjYWsh7ZnQPyyM0nG2y0oo2wNig== X-Received: by 2002:adf:80cb:: with SMTP id 69mr23879486wrl.320.1584902616177; Sun, 22 Mar 2020 11:43:36 -0700 (PDT) Received: from [10.0.0.157] (bzq-79-181-20-162.red.bezeqint.net. [79.181.20.162]) by smtp.gmail.com with ESMTPSA id r18sm19737149wro.13.2020.03.22.11.43.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2020 11:43:35 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Sun, 22 Mar 2020 20:43:33 +0200 From: Yaron Sheffer To: Dick Hardt , Torsten Lodderstedt CC: Kim Cameron , Mike Jones , , Filip Skokan Message-ID: <1CE69263-A412-465D-AB19-7DF6D16AF1AF@gmail.com> Thread-Topic: [Txauth] Proposed TxAuth charter Text References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3667754615_816522418" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 18:43:42 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3667754615_816522418 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable If we have agreement on Torsten=E2=80=99s interoperability text (quoted below), I= think we should add it. If only for the word =E2=80=9Cinteroperability=E2=80=9D to appe= ar in the charter. =20 =E2=80=9CThe delegation protocol will enable interoperability between client and = authorization server, authorisation server and resource server and, as neede= d to perform delegation, client and resource server.=E2=80=9D =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Txauth on behalf of Dick Hardt Date: Sunday, March 22, 2020 at 20:31 To: Torsten Lodderstedt Cc: Kim Cameron , Mike Jones , , Filip Skokan Subject: Re: [Txauth] Proposed TxAuth charter Text =20 =20 =20 On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt wrote: Hi Dick, thanks for trying to consider the concerns we have raced in an update to th= e proposed charter.=20 > On 21. Mar 2020, at 20:55, Dick Hardt wrote: >=20 > (replying with those that had expressed concerns about the charter on the= To: list to bring it to the top of their inbox) >=20 > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes b= elow? >=20 > (apologies to anyone I missed in the To: list) >=20 > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer wrote: > After some great discussions on the list in the last week, Yaron, Dick, a= nd I have pulled together a new proposed charter. I think this is version 5.= 0? But I forget exactly. :) >=20 > I=E2=80=99ve highlighted the new lines in bold here, for those reading this em= ail in HTML. There=E2=80=99s a diff available online at http://www.mergely.com/Re= hoJJvW/ (note: go to view->word wrap to be able to read it better). I=E2=80=99m a= ttaching the .DIFF file generated by Mergely as well, for those of us crusty= old unix type folks who like to see that. >=20 >=20 >=20 >=20 >=20 > This group is chartered to develop a fine-grained delegation protocol for= authorization, identity, and API access. This protocol will allow an author= izing party to delegate access to client software through an authorization s= erver. It will expand upon the uses cases currently supported by OAuth 2.0 a= nd OpenID Connect (itself an extension of OAuth 2.0) to support authorizatio= ns scoped as narrowly as a single transaction, provide a clear framework for= interaction among all parties involved in the protocol flow, and remove unn= ecessary dependence on a browser or user-agent for coordinating interactions= .=20 >=20 > The delegation process will be acted upon by multiple parties in the prot= ocol, each performing a specific role. The protocol will decouple the intera= ction channels, such as the end user=E2=80=99s browser, from the delegation channe= l, which happens directly between the client and the authorization server (i= n contrast with OAuth 2.0 which is initiated by the client redirecting the u= ser=E2=80=99s browser). The client and AS will involve a user to make an authoriza= tion decision as necessary through interaction mechanisms indicated by the p= rotocol. This decoupling avoids many of the security concerns and technical = challenges of OAuth 2.0 and provides a non-invasive path for supporting futu= re types of clients and interaction channels. >=20 > Additionally, the delegation process will allow for: >=20 I don't see how this list captures the requirement I raised.=20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Support for multiple access tokens in a single request This item justifies Justin=E2=80=99s latest addition to XYZ to allow the client t= o allocate resources to access tokens.=20 =20 I've multiple access tokens in XAuth since the first draft.. No one told me= that was not scope for the charter back then. I consider "fine grained spec= ification of access" to include many different ways to be fine grained.=20 =20 We added multiple tokens to clarify =20 That=E2=80=99s fine, but it=E2=80=99s geared towards the client deciding how to split t= okens.=20 =20 I don't see why the scope is limited to the client deciding. In current OAu= th 2.0 use cases, which is in scope, the AS decides what it will, and will n= ot issue tokens for. Extending that to multiple tokens, and multiple resourc= es to me implies the AS can still decide what each token can do. =20 I=E2=80=99m looking for a way to let the RS (with the AS acting on its behalf) in= fluence the token allocation and with that the token design. As I have expla= ined several times, the token format & content is part of the AS to RS inter= face and the current charter limits this to a single design option: handles = + token introspection, at least in multi RS scenarios.=20 =20 I don't think that is the case at all.=20 XAuth has a different design pattern. Each Authorization is independent of = each other. We also added the following to the charter. =20 - Mechanisms for the AS and RS to communicate the access granted by an acce= ss token =20 I would consider the token format and content to be one mechanism for the A= S to communicate with the RS. =20 The current charter therewith enshrines one of the big design limitations O= Auth 2 had, which has significant consequences with respect to security, pri= vacy, UX, performance, and cost.=20 I understand the intention to keep things for clients as simple as possible= , but it shouldn't be simpler and at the cost of other parties. In particula= r, this optimisation is at the cost of resource server implementers, whose o= ptions are very limited with the current charter. I think the new protocol s= hould leave the optimisation decision to particular deployments and instead = support a variety of design options implementers can choose from.=20 I suggest to add the following bullet: - Support for a wide range of access token policies, including single token= per transaction and RS-specific access tokens at the discretion of the AS =20 I think that is already covered by the existing charter.=20 =20 > - Support for directed, audience-restricted access tokens This looks good on first sight but it misses the important point that the A= S on behalf of the RS can decide to issue such tokens. =20 The AS decides what tokens it will issue to a Client already in OAuth 2.0, = so it is in scope. What am I missing? =20 > - Separation between the party authorizing access and the party operating= the client requesting access > - A variety of client applications, including Web, mobile, single-page, a= nd interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for fle= xibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of posses= sion=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces= of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resour= ce requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation pr= ocess (including asserted identity claims) wfm although I don't understand why this is an extension point and not inco= rporated in the bullet below. >=20 > Additionally, the group will provide mechanisms for management of the pro= tocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an ac= cess token wfm >=20 > Although the artifacts for this work are not intended or expected to be b= ackwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt= to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol= where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as su= ch will focus on new technological solutions not necessarily compatible with= OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be develope= d in the OAuth Working Group, including functionality back-ported from the p= rotocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying cryptographic m= ethods, such as JOSE and COSE, to the delegation process. This group is not = chartered to develop new cryptographic methods. >=20 > The group is chartered to develop mechanisms for conveying identity infor= mation within the protocol including identifiers (such as email addresses, p= hone numbers, usernames, and subject identifiers) and assertions (such as Op= enID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The gr= oup is not chartered to develop new formats for identifiers or assertions, n= or is the group chartered to develop schemas for user information, profiles,= or other identity attributes, unless a viable existing format is not availa= ble.=20 I=E2=80=99m still not seeing the benefit of including identity at the "AS to clie= nt" interface in this charter. This paragraph could be removed without any i= mpact on the rest of the charter.=20 =20 Are you questioning why identity is in scope, or that this statement is red= undant? =20 >=20 > The initial work will focus on using HTTP for communication between the c= lient and the authorization server, taking advantage of optimization feature= s of HTTP2 and HTTP3 where possible, and will strive to enable simple mappin= g to other protocols such as COAP when doing so does not conflict with the p= rimary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, detac= hed HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points General observations: While I was reading the updated charter several times, I made the following= observations:=20 The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in this charter.=20 So I=E2=80=99m asking: Do we intend to build a protocol for interoperability?=20 =20 I would consider a protocol requires interoperability. A framework does not= . =20 The charter states that we are building a protocol, which appears throughou= t the charter text. =20 If we are aiming for interoperability, what level of interoperability do we= want to achieve? I think we must aim for "on the wire" interoperability tha= t can be tested automatically. That would allow to truly use TXAuth based au= thorization wherever an API is being protected using TXAuth without the need= for deployment specific customisation, just like BASIC auth and TLS. If we are aiming for interoperability, where do we seek for interoperabilit= y? At the client - AS interface only? Or do we consider the AS - RS interfac= e as well? And what is about the client - RS interface? I think all of them = should be in scope for various reasons.=20 Client - AS: clearly in scope even if not stated=20 AS - RS: would allow to combine ASs and RSs from different sources. That's = an important requirement for us (yes.com), since we run a >1000 AS federatio= n where the RSs can be invoked using tokens from all of those ASs (that are = built using different products). Combining software on both ends from differ= ent sources (e.g. different vendors) is another example. Interoperability be= tween AS and RS is a key success factor in such a scenario and is less than = poorly supported today by OAuth 2. TXAuth should do better.=20 Client - RS: there is an obvious reason, which is the way access tokens are= conveyed. The less obvious reason is to take a look into how a client could= find out what it takes to perform a suitable authorization process to be ab= le to invoke a particular RS.=20 =20 To clarify, you would like discovery at the RS to be in scope? Rereading th= e charter, I can see that is not specifically called out, and discovery at t= he RS could be considered out of scope.=20 =20 I could also argue that it is in scope in order for the client to know how = to present tokens to the RS.=20 =20 It totally strikes me that the latter two interfaces seem to be mostly out = of scope. To me the current charter will cause the TXAuth WG to look onto a = small portion of the overall process (client to AS) only. The result will be= incomplete and needs to be patched together with the rest in real implement= ations.=20 =20 The former, how the client presents tokens, is in scope: =20 - Mechanisms for presenting tokens to resource servers and binding resource= requests to tokens and associated cryptographic keys =20 I therefore suggest to add the following text after the first paragraph=20 "The delegation protocol will enable interoperability between client and au= thorization server, authorisation server and resource server and, as needed = to perform delegation, client and resource server. Conformance of an impleme= ntation with the specifications can be tested automatically." =20 =20 I think your first sentence is already covered, although each point is spre= ad out through the charter.=20 =20 I think your second sentence is overly specific.=20 =20 Which also brings me to Nat=E2=80=99s proposal to write an architecture document.= I=E2=80=99m not convinced we need an architecture document (in the sense of a RFC= ), but I=E2=80=99m sure we need to discuss and document overall use cases and desi= gn options. Understanding those is the prerequisite to design a suitable and= as easy as possible protocol.=20 So please add the following bullet to the charter under Milestones:=20 "- documentation of the use cases and design options the new protocol will = support" =20 I think what we do to meet the "Core delegation protocol" milestone is up t= o the group to decide. I don't think we have to have it in the charter. =20 best regards, Torsten.=20 >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3667754615_816522418 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

If we have agreement on Torsten=E2=80=99s interoperabili= ty text (quoted below), I think we should add it. If only for the word =E2=80=9Cin= teroperability=E2=80=9D to appear in the charter.

 

=E2=80=9CThe delegation protocol will ena= ble interoperability between client and authorization server, authorisation = server and resource server and, as needed to perform delegation, client and = resource server.=E2=80=9D

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Txauth <txauth-bounce= s@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Da= te: Sunday, March 22, 2020 at 20:31
To: Torsten Lodderstedt &l= t;torsten@lodderstedt.net>
Cc: Kim Cameron <kim@identityblog= .com>, Mike Jones <michael.jones@microsoft.com>, <txauth@ietf.or= g>, Filip Skokan <panva.ip@gmail.com>
Subject: Re: [Txaut= h] Proposed TxAuth charter Text

 

 

 

On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi Dick,

thanks for trying to consider the concerns we have raced= in an update to the proposed charter.

> On 21. Mar 2020, at 20:5= 5, Dick Hardt <dick= .hardt@gmail.com> wrote:
>
> (replying with those that h= ad expressed concerns about the charter on the To: list to bring it to the t= op of their inbox)
>
> Mike, Kim, Torsten, Filip: are your conc= erns addressed with the changes below?
>
> (apologies to anyone= I missed in the To: list)
>
> On Sat, Mar 21, 2020 at 12:41 PM= Justin Richer <jricher@= mit.edu> wrote:
> After some great discussions on the list in t= he last week, Yaron, Dick, and I have pulled together a new proposed charter= . I think this is version 5.0? But I forget exactly. :)
>
> I=E2=80= =99ve highlighted the new lines in bold here,  for those reading this ema= il in HTML. There=E2=80=99s a diff available online at  http://www.mergely.com/RehoJJvW/&n= bsp; (note: go to view->word wrap to be able to read it better). I=E2=80=99m at= taching the .DIFF file generated by Mergely as well, for those of us crusty = old unix type folks who like to see that.
>
>
>
>=
>
> This group is chartered to develop a fine-grained delegat= ion protocol for authorization, identity, and API access. This protocol will= allow an authorizing party to delegate access to client software through an= authorization server. It will expand upon the uses cases currently supporte= d by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to supp= ort authorizations scoped as narrowly as a single transaction, provide a cle= ar framework for interaction among all parties involved in the protocol flow= , and remove unnecessary dependence on a browser or user-agent for coordinat= ing interactions.
>
> The delegation process will be acted upo= n by multiple parties in the protocol, each performing a specific role. The = protocol will decouple the interaction channels, such as the end user=E2=80=99s br= owser, from the delegation channel, which happens directly between the clien= t and the authorization server (in contrast with OAuth 2.0 which is initiate= d by the client redirecting the user=E2=80=99s browser). The client and AS will in= volve a user to make an authorization decision as necessary through interact= ion mechanisms indicated by the protocol. This decoupling avoids many of the= security concerns and technical challenges of OAuth 2.0 and provides a non-= invasive path for supporting future types of clients and interaction channel= s.
>
> Additionally, the delegation process will allow for:
= >

I don't see how this list captures the requirement I raised.
> - Fine-grained specification of access
> - Approval of AS a= ttestation to identity claims
> - Approval of access to multiple resou= rces and APIs in a single interaction
> - Support for multiple access = tokens in a single request

This item justifies Justin=E2=80=99s latest addi= tion to XYZ to allow the client to allocate resources to access tokens.

 

<= div>

I've multiple access tokens in XAuth since = the first draft.. No one told me that was not scope for the charter back the= n. I consider "fine grained specification of access" to include ma= ny different ways to be fine grained. 

 

We added mult= iple tokens to clarify

&nbs= p;

 


I=E2=80=99m looking for a way to let the RS (with= the AS acting on its behalf) influence the token allocation and with that t= he token design. As I have explained several times, the token format & c= ontent is part of the AS to RS interface and the current charter limits this= to a single design option: handles + token introspection, at least in multi= RS scenarios.

&nbs= p;

I don't think that is the case at = all. 

XAuth has a different= design pattern. Each Authorization is independent of each other. We al= so added the following to the charter.

 

- Mechanisms fo= r the AS and RS to communicate the access granted by an access token

 

I would consider the token format and content to be one mech= anism for the AS to communicate with the RS.

 


The current charter therewith enshrines = one of the big design limitations OAuth 2 had, which has significant consequ= ences with respect to security, privacy, UX, performance, and cost.

= I understand the intention to keep things for clients as simple as possible,= but it shouldn't be simpler and at the cost of other parties. In particular= , this optimisation is at the cost of resource server implementers, whose op= tions are very limited with the current charter. I think the new protocol sh= ould leave the optimisation decision to particular deployments and instead s= upport a variety of design options implementers can choose from.

I s= uggest to add the following bullet:

- Support for a wide range of acc= ess token policies, including single token per transaction and RS-specific a= ccess tokens at the discretion of the AS

 

I think t= hat is already covered by the existing charter. 

 


> - Support for directed, au= dience-restricted access tokens

This looks good on first sight but it= misses the important point that the AS on behalf of the RS can decide to is= sue such tokens.

&nb= sp;

The AS decides what tokens it wil= l issue to a Client already in OAuth 2.0, so it is in scope. What am I missi= ng?

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0i= n 0in 6.0pt;margin-left:4.8pt;margin-right:0in'>


> = - Separation between the party authorizing access and the party operating th= e client requesting access
> - A variety of client applications, inclu= ding Web, mobile, single-page, and interaction-constrained applications
&= gt;
> The group will define extension points for this protocol to all= ow for flexibility in areas including:
>
> - Cryptographic agil= ity for keys, message signatures, and proof of possession
> - User in= teraction mechanisms including web and non-web methods
> - Mechanisms = for conveying user, software, organization, and other pieces of information = used in authorization decisions
> - Mechanisms for presenting tokens t= o resource servers and binding resource requests to tokens and associated cr= yptographic keys
> - Optimized inclusion of additional information thr= ough the delegation process (including asserted identity claims)

wfm = although I don't understand why this is an extension point and not incorpora= ted in the bullet below.

>
> Additionally, the group will p= rovide mechanisms for management of the protocol lifecycle including:
>= ;
> - Discovery of the authorization server
> - Revocation of a= ctive tokens
> - Mechanisms for the AS and RS to communicate the acces= s granted by an access token

wfm

>
> Although the ar= tifacts for this work are not intended or expected to be backwards-compatibl= e with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migra= ting from OAuth 2.0 and OpenID Connect to the new protocol where possible.>
> This group is not chartered to develop extensions to OAuth 2= .0, and as such will focus on new technological solutions not necessarily co= mpatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 wil= l be developed in the OAuth Working Group, including functionality back-port= ed from the protocol developed here to OAuth 2.0.
>
> The group= is chartered to develop mechanisms for applying cryptographic methods, such= as JOSE and COSE, to the delegation process. This group is not chartered to= develop new cryptographic methods.
>
> The group is chartered = to develop mechanisms for conveying identity information within the protocol= including identifiers (such as email addresses, phone numbers, usernames, a= nd subject identifiers) and assertions (such as OpenID Connect ID Tokens, SA= ML Assertions, and Verifiable Credentials). The group is not chartered to de= velop new formats for identifiers or assertions, nor is the group chartered = to develop schemas for user information, profiles, or other identity attribu= tes, unless a viable existing format is not available.

I=E2=80=99m still n= ot seeing the benefit of including identity at the "AS to client" = interface in this charter. This paragraph could be removed without any impac= t on the rest of the charter.

 

Are you questioning= why identity is in scope, or that this statement is redundant?

 


>
> The ini= tial work will focus on using HTTP for communication between the client and = the authorization server, taking advantage of optimization features of HTTP2= and HTTP3 where possible, and will strive to enable simple mapping to other= protocols such as COAP when doing so does not conflict with the primary foc= us.
>
> Milestones to include:
> - Core delegation protoc= ol
> - Key presentation mechanism bindings to the core protocol for TL= S, detached HTTP signature, and embedded HTTP signatures
> - Identity = and authentication conveyance mechanisms
> - Guidelines for use of pro= tocol extension points

General observations:

While I was readi= ng the updated charter several times, I made the following observations:
The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in this charter= .

So I=E2=80=99m asking: Do we intend to build a protocol for interoperabi= lity?

 <= /p>

I would consider a protocol requires intero= perability. A framework does not.

 

The charter states that= we are building a protocol, which appears throughout the charter text.=

 


If we are aim= ing for interoperability, what level of interoperability do we want to achie= ve? I think we must aim for "on the wire" interoperability that ca= n be tested automatically. That would allow to truly use TXAuth based author= ization wherever an API is being protected using TXAuth without the need for= deployment specific customisation, just like BASIC auth and TLS.

If = we are aiming for interoperability, where do we seek for interoperability? A= t the client - AS interface only? Or do we consider the AS - RS interface as= well? And what is about the client - RS interface? I think all of them shou= ld be in scope for various reasons.

Client - AS: clearly in scope ev= en if not stated

AS - RS: would allow to combine ASs and RSs from di= fferent sources. That's an important requirement for us (yes.com), since we run a >1000 AS federation wh= ere the RSs can be invoked using tokens from all of those ASs (that are buil= t using different products). Combining software on both ends from different = sources (e.g. different vendors) is another example. Interoperability betwee= n AS and RS is a key success factor in such a scenario and is less than poor= ly supported today by OAuth 2. TXAuth should do better.

Client - RS:= there is an obvious reason, which is the way access tokens are conveyed. Th= e less obvious reason is to take a look into how a client could find out wha= t it takes to perform a suitable authorization process to be able to invoke = a particular RS.

&n= bsp;

To clarify, you would like disco= very at the RS to be in scope? Rereading the charter, I can see that is not = specifically called out, and discovery at the RS could be considered out of = scope. 

 

I could also argue that it is in scope in or= der for the client to know how to present tokens to the RS. =

 


It totally strikes = me that the latter two interfaces seem to be mostly out of scope. To me the = current charter will cause the TXAuth WG to look onto a small portion of the= overall process (client to AS) only. The result will be incomplete and need= s to be patched together with the rest in real implementations. <= /p>

 

The former, how the client presents tokens, is in scope:=

 

- Mechanisms for presenting tokens to resource servers and binding res= ource requests to tokens and associated cryptographic keys

 


I = therefore suggest to add the following text after the first paragraph
"The delegation protocol will enable interoperability between client = and authorization server, authorisation server and resource server and, as n= eeded to perform delegation, client and resource server. Conformance of an i= mplementation with the specifications can be tested automatically."

 

<= div>

 

I = think your first sentence is already covered, although each point is spread = out through the charter. 

<= o:p> 

I think your second senten= ce is overly specific. 

&nb= sp;


Which also brings me to Nat=E2=80=99s proposal to write an arc= hitecture document. I=E2=80=99m not convinced we need an architecture document (in= the sense of a RFC), but I=E2=80=99m sure we need to discuss and document overall= use cases and design options. Understanding those is the prerequisite to de= sign a suitable and as easy as possible protocol.

So please add the = following bullet to the charter under Milestones:

"- documentat= ion of the use cases and design options the new protocol will support"<= o:p>

 

I think what we do to meet the "Core delegati= on protocol" milestone is up to the group to decide. I don't think we h= ave to have it in the charter.

&= nbsp;

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
best regards,
Torsten.=


>
>
>
>
> --
> Txauth mai= ling list
> Txauth@ie= tf.org
> https://www.ietf.org/mailman/listinfo/txauth

-- Txauth mailing list Txauth@i= etf.org https://www.ietf.org/mailman/listinfo/txauth

--B_3667754615_816522418-- From nobody Sun Mar 22 12:11:21 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ACD3A047F for ; Sun, 22 Mar 2020 12:11:19 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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=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 NncUimaea2tG for ; Sun, 22 Mar 2020 12:11:15 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 A156E3A0474 for ; Sun, 22 Mar 2020 12:11:14 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id r7so11609295wmg.0 for ; Sun, 22 Mar 2020 12:11:14 -0700 (PDT) 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=x4Bhh1v/OrsQufs9kikHljreNxwYFxyORnCjB7IUJNM=; b=n7+Re66G7s1xORQO83MEI9SCqhJ/8W6BrgKDzvUwOkOGOJHD3N/OrDvKKHO+sP+l3W O9W1NctlmGEFkp9dLH8NMWPacGa0b8npwb30RmOTghXJOru3bFROjofOd8JYeu2xH0Mg AZdS2XDkEhZMOwK7oVXJJ2q3RmeOc6jDOe4mQjEhC10NYwf+gWQYODx4ycKQlQ3gaJoD Etx1xgkotwn/pGYyYaYN8mE0D9uqV5eccg9KJELvSsLfpZOXiNnb7Lykgd9/wyyyh+9H DFk9X0TIuKJaHwh+XhpFqXUUEyd3TIqWyoSqElsgedNafZJ9J6Vfs+Xhv12cC8acxUwp PspQ== 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=x4Bhh1v/OrsQufs9kikHljreNxwYFxyORnCjB7IUJNM=; b=K3qc8ObKOWFqw0Myd51tV/uZIQOvZBrVHKTNpAV1DHGElO8Jw5dLH7Z0Kjm280bFPz 6SWeUSB3sZwJz/koOFcynx3MIwo2t1WVcPbRvjCtC2R4X+Iyn6/75ONohsftkWhpqS5e UkLD0pq0RHNg9MTOuoIhtH/ZfvvAC9COp+wGv9h70h3qFfojQFb8qKXgz3f6osUNodMC AOv1awGSeAeNCtJJP5/zZ/AqwhdWhJBVEWUS3MUzIEIZuAj4JZs5G4bE8ZjxPGMgsJtc +TmkJl4g+fQ0l06pMzKvYNXNii/Ae6lvmtLnJIsnpLrMYQzLZtv/R2pSHkEBssgGViuy Va8w== X-Gm-Message-State: ANhLgQ2dUXjZTmZxWyakPENEhsmzA0eBFs49xwLhZBY7CS1Eqm6XrVWf uwvy6moAgU8RqkhQqndji5+NoeTHd18= X-Google-Smtp-Source: ADFU+vs/WuMZQ9oT9PcYl+wkrKhSYMhi7lCRLzm+aM83JTMCu6sy3lyKIhImprdkuUTMb2qIFsLfIw== X-Received: by 2002:a1c:5443:: with SMTP id p3mr22102486wmi.149.1584904272474; Sun, 22 Mar 2020 12:11:12 -0700 (PDT) Received: from p200300eb8f2625445078fb1f8bbfc2ef.dip0.t-ipconnect.de (p200300EB8F2625445078FB1F8BBFC2EF.dip0.t-ipconnect.de. [2003:eb:8f26:2544:5078:fb1f:8bbf:c2ef]) by smtp.gmail.com with ESMTPSA id q185sm4226177wme.10.2020.03.22.12.11.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Mar 2020 12:11:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Torsten Lodderstedt In-Reply-To: Date: Sun, 22 Mar 2020 20:11:10 +0100 Cc: Mike Jones , Kim Cameron , Filip Skokan , txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9692BA55-6BCA-4879-930F-B8E4D72BD933@lodderstedt.net> References: To: Dick Hardt X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 19:11:20 -0000 Hi Dick,=20 > On 22. Mar 2020, at 19:31, Dick Hardt wrote: >=20 >=20 >=20 > On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt = wrote: > Hi Dick, >=20 > thanks for trying to consider the concerns we have raced in an update = to the proposed charter.=20 >=20 > > On 21. Mar 2020, at 20:55, Dick Hardt wrote: > >=20 > > (replying with those that had expressed concerns about the charter = on the To: list to bring it to the top of their inbox) > >=20 > > Mike, Kim, Torsten, Filip: are your concerns addressed with the = changes below? > >=20 > > (apologies to anyone I missed in the To: list) > >=20 > > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer = wrote: > > After some great discussions on the list in the last week, Yaron, = Dick, and I have pulled together a new proposed charter. I think this is = version 5.0? But I forget exactly. :) > >=20 > > I=E2=80=99ve highlighted the new lines in bold here, for those = reading this email in HTML. There=E2=80=99s a diff available online at = http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be = able to read it better). I=E2=80=99m attaching the .DIFF file generated = by Mergely as well, for those of us crusty old unix type folks who like = to see that. > >=20 > >=20 > >=20 > >=20 > >=20 > > This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 > >=20 > > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. > >=20 > > Additionally, the delegation process will allow for: > >=20 >=20 > I don't see how this list captures the requirement I raised.=20 >=20 > > - Fine-grained specification of access > > - Approval of AS attestation to identity claims > > - Approval of access to multiple resources and APIs in a single = interaction > > - Support for multiple access tokens in a single request >=20 > This item justifies Justin=E2=80=99s latest addition to XYZ to allow = the client to allocate resources to access tokens. >=20 > I've multiple access tokens in XAuth since the first draft. No one = told me that was not scope for the charter back then. Thanks for pointing this out, I have to admit I seems to have missed = that feature when I read your draft. I will give XAuth another detailed = read to find out whether it supports the features I=E2=80=99m looking = for.=20 > I consider "fine grained specification of access" to include many = different ways to be fine grained.=20 That=E2=80=99s your interpretation, I would have interpreted =E2=80=9CAppr= oval of access to multiple resources and APIs in a single interaction=E2=80= =9D accordingly. But it seems to me, other people interpret that = differently.=20 >=20 > We added multiple tokens to clarify It =E2=80=99s multiple access token in the request, not the response.=20 > =20 > That=E2=80=99s fine, but it=E2=80=99s geared towards the client = deciding how to split tokens.=20 >=20 > I don't see why the scope is limited to the client deciding. In = current OAuth 2.0 use cases, which is in scope, the AS decides what it = will, and will not issue tokens for. That=E2=80=99s works in multi RS setups with proprietary extensions = only. I want to get rid of those and have an interoperable solution for = it.=20 > Extending that to multiple tokens, and multiple resources to me = implies the AS can still decide what each token can do. =E2=80=9Cimplies=E2=80=9D is the key word here. I agree with you. Do = other WG members as well? > =20 >=20 > I=E2=80=99m looking for a way to let the RS (with the AS acting on its = behalf) influence the token allocation and with that the token design. = As I have explained several times, the token format & content is part of = the AS to RS interface and the current charter limits this to a single = design option: handles + token introspection, at least in multi RS = scenarios.=20 >=20 > I don't think that is the case at all.=20 XYZ is limited this way right now and I assume it=E2=80=99s considered = to be charter compliant as well. For me this means, we are in an area = governed by the decisions of the editors of the individual drafts.=20 > XAuth has a different design pattern. Each Authorization is = independent of each other. We also added the following to the charter. >=20 > - Mechanisms for the AS and RS to communicate the access granted by an = access token >=20 > I would consider the token format and content to be one mechanism for = the AS to communicate with the RS. Sure, but it does not determine who decides what to use and where. Just = saying JWT is a way to implement self contained access tokens gives an = AS the ability to issue one JWT to RS1 and another JWT to RS2. > =20 >=20 > The current charter therewith enshrines one of the big design = limitations OAuth 2 had, which has significant consequences with respect = to security, privacy, UX, performance, and cost.=20 >=20 > I understand the intention to keep things for clients as simple as = possible, but it shouldn't be simpler and at the cost of other parties. = In particular, this optimisation is at the cost of resource server = implementers, whose options are very limited with the current charter. I = think the new protocol should leave the optimisation decision to = particular deployments and instead support a variety of design options = implementers can choose from.=20 >=20 > I suggest to add the following bullet: >=20 > - Support for a wide range of access token policies, including single = token per transaction and RS-specific access tokens at the discretion of = the AS >=20 > I think that is already covered by the existing charter.=20 Please refer to the bullets that cover this without room for = interpretation. > =20 >=20 > > - Support for directed, audience-restricted access tokens >=20 > This looks good on first sight but it misses the important point that = the AS on behalf of the RS can decide to issue such tokens. >=20 > The AS decides what tokens it will issue to a Client already in OAuth = 2.0, so it is in scope. What am I missing? You are missing the dependency on the RS. RS1 wants a JWT with certain = claims and RS2 wants a handle to be queried via introspection (because = of immediate revocation support). How is that covered in OAuth 2?=20 > =20 >=20 > > - Separation between the party authorizing access and the party = operating the client requesting access > > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications > >=20 > > The group will define extension points for this protocol to allow = for flexibility in areas including: > >=20 > > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > > - User interaction mechanisms including web and non-web methods > > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > > - Optimized inclusion of additional information through the = delegation process (including asserted identity claims) >=20 > wfm although I don't understand why this is an extension point and not = incorporated in the bullet below. >=20 > >=20 > > Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: > >=20 > > - Discovery of the authorization server > > - Revocation of active tokens > > - Mechanisms for the AS and RS to communicate the access granted by = an access token >=20 > wfm >=20 > >=20 > > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. > >=20 > > This group is not chartered to develop extensions to OAuth 2.0, and = as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. > >=20 > > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. > >=20 > > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 >=20 > I=E2=80=99m still not seeing the benefit of including identity at the = "AS to client" interface in this charter. This paragraph could be = removed without any impact on the rest of the charter.=20 >=20 > Are you questioning why identity is in scope, or that this statement = is redundant? I=E2=80=99m questioning why identity at the client to AS interface is in = scope. That=E2=80=99s a separate topic independent of delegation. = Moreover, and I have already stated that, it has a different trust model = resulting in a different security threat model. Adding this to TXAuth = significantly increase complexity for all of us.=20 > =20 >=20 > >=20 > > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. > >=20 > > Milestones to include: > > - Core delegation protocol > > - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures > > - Identity and authentication conveyance mechanisms > > - Guidelines for use of protocol extension points >=20 > General observations: >=20 > While I was reading the updated charter several times, I made the = following observations:=20 >=20 > The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in = this charter.=20 >=20 > So I=E2=80=99m asking: Do we intend to build a protocol for = interoperability?=20 >=20 > I would consider a protocol requires interoperability. A framework = does not. That=E2=80=99s again interpretation and not clearly spelled out.=20 >=20 > The charter states that we are building a protocol, which appears = throughout the charter text. > =20 >=20 > If we are aiming for interoperability, what level of interoperability = do we want to achieve? I think we must aim for "on the wire" = interoperability that can be tested automatically. That would allow to = truly use TXAuth based authorization wherever an API is being protected = using TXAuth without the need for deployment specific customisation, = just like BASIC auth and TLS. >=20 > If we are aiming for interoperability, where do we seek for = interoperability? At the client - AS interface only? Or do we consider = the AS - RS interface as well? And what is about the client - RS = interface? I think all of them should be in scope for various reasons.=20= >=20 > Client - AS: clearly in scope even if not stated=20 >=20 > AS - RS: would allow to combine ASs and RSs from different sources. = That's an important requirement for us (yes.com), since we run a >1000 = AS federation where the RSs can be invoked using tokens from all of = those ASs (that are built using different products). Combining software = on both ends from different sources (e.g. different vendors) is another = example. Interoperability between AS and RS is a key success factor in = such a scenario and is less than poorly supported today by OAuth 2. = TXAuth should do better.=20 >=20 > Client - RS: there is an obvious reason, which is the way access = tokens are conveyed. The less obvious reason is to take a look into how = a client could find out what it takes to perform a suitable = authorization process to be able to invoke a particular RS.=20 >=20 > To clarify, you would like discovery at the RS to be in scope? = Rereading the charter, I can see that is not specifically called out, = and discovery at the RS could be considered out of scope.=20 >=20 > I could also argue that it is in scope in order for the client to know = how to present tokens to the RS.=20 > =20 >=20 > It totally strikes me that the latter two interfaces seem to be mostly = out of scope. To me the current charter will cause the TXAuth WG to look = onto a small portion of the overall process (client to AS) only. The = result will be incomplete and needs to be patched together with the rest = in real implementations.=20 >=20 > The former, how the client presents tokens, is in scope: >=20 > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > =20 >=20 > I therefore suggest to add the following text after the first = paragraph=20 >=20 > "The delegation protocol will enable interoperability between client = and authorization server, authorisation server and resource server and, = as needed to perform delegation, client and resource server. Conformance = of an implementation with the specifications can be tested = automatically." >=20 >=20 > I think your first sentence is already covered, although each point is = spread out through the charter.=20 Why not just make it explicit?=20 >=20 > I think your second sentence is overly specific.=20 Why? I=E2=80=99m not saying this WG shall write a test or maintain test = services. All I=E2=80=99m saying is implementations shall be testable = for conformance using an automatic test. This will drive protocol = definition to a whole new level, as we have learned with FAPI, since = there is no longer room for hand waving when it comes to gaps and = missing pieces.=20 > =20 >=20 > Which also brings me to Nat=E2=80=99s proposal to write an = architecture document. I=E2=80=99m not convinced we need an architecture = document (in the sense of a RFC), but I=E2=80=99m sure we need to = discuss and document overall use cases and design options. Understanding = those is the prerequisite to design a suitable and as easy as possible = protocol.=20 >=20 > So please add the following bullet to the charter under Milestones:=20 >=20 > "- documentation of the use cases and design options the new protocol = will support" >=20 > I think what we do to meet the "Core delegation protocol" milestone is = up to the group to decide. I don't think we have to have it in the = charter. Then why do we need milestones at all? I think we will see a lack of = consensus shining through in every feature discussion if we do not agree = on the use cases and design options.=20 best regards, Torsten.=20 > =20 >=20 > best regards, > Torsten.=20 >=20 >=20 > >=20 > >=20 > >=20 > >=20 > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth >=20 From nobody Sun Mar 22 12:12:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6433A047F for ; Sun, 22 Mar 2020 12:12:14 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 LM8yPKAwRs96 for ; Sun, 22 Mar 2020 12:12:10 -0700 (PDT) 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 118A63A0474 for ; Sun, 22 Mar 2020 12:12:09 -0700 (PDT) Received: from [192.168.1.5] (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 02MJBlA3015315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Mar 2020 15:11:48 -0400 From: Justin Richer Message-Id: <98A21CC8-7D8A-4C98-9B47-D798431DDE89@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_876096E6-72E4-4578-97EE-BA087654BB11" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 22 Mar 2020 15:11:47 -0400 In-Reply-To: <1CE69263-A412-465D-AB19-7DF6D16AF1AF@gmail.com> Cc: Dick Hardt , Torsten Lodderstedt , Kim Cameron , Mike Jones , txauth@ietf.org, Filip Skokan To: Yaron Sheffer References: <1CE69263-A412-465D-AB19-7DF6D16AF1AF@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 19:12:15 -0000 --Apple-Mail=_876096E6-72E4-4578-97EE-BA087654BB11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Dick that the fact that we=E2=80=99re building a protocol = implies interoperability, and I=E2=80=99d go further that merely putting = =E2=80=9Cinteroperability=E2=80=9D into the charter doesn=E2=80=99t = necessarily mean that you=E2=80=99re going to get something that works = out of the box between two systems every time.=20 That said, I would be OK with adding the following line to the Carter: The delegation protocol will enable interoperability between the = client and authorization server, client and resource server, and = resource server and authorization server.=20 Specifically I see those map to functions we=E2=80=99re already signing = up for doing. Respectively: - How to get a token (including how to ask for something specific) - How to use a token (and deal with security-level errors) - How to interpret a token (using at the very least a common model of = what a token represents) I think it=E2=80=99s redundant but it wouldn=E2=80=99t hurt to call it = out specifically. A few more responses to Torsten=E2=80=99s comments inline below. > On Mar 22, 2020, at 2:43 PM, Yaron Sheffer = wrote: >=20 > If we have agreement on Torsten=E2=80=99s interoperability text = (quoted below), I think we should add it. If only for the word = =E2=80=9Cinteroperability=E2=80=9D to appear in the charter. > =20 > =E2=80=9CThe delegation protocol will enable interoperability between = client and authorization server, authorisation server and resource = server and, as needed to perform delegation, client and resource = server.=E2=80=9D > =20 > Thanks, > Yaron > =20 > From: Txauth on behalf of Dick Hardt = > Date: Sunday, March 22, 2020 at 20:31 > To: Torsten Lodderstedt > Cc: Kim Cameron , Mike Jones = , , Filip Skokan = > Subject: Re: [Txauth] Proposed TxAuth charter Text > =20 > =20 > =20 > On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt = > wrote: >> Hi Dick, >>=20 >> thanks for trying to consider the concerns we have raced in an update = to the proposed charter.=20 >>=20 >> > On 21. Mar 2020, at 20:55, Dick Hardt > wrote: >> >=20 >> > (replying with those that had expressed concerns about the charter = on the To: list to bring it to the top of their inbox) >> >=20 >> > Mike, Kim, Torsten, Filip: are your concerns addressed with the = changes below? >> >=20 >> > (apologies to anyone I missed in the To: list) >> >=20 >> > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer > wrote: >> > After some great discussions on the list in the last week, Yaron, = Dick, and I have pulled together a new proposed charter.. I think this = is version 5.0? But I forget exactly. :) >> >=20 >> > I=E2=80=99ve highlighted the new lines in bold here, for those = reading this email in HTML. There=E2=80=99s a diff available online at = http://www.mergely.com/RehoJJvW/ = (note: go to view->word wrap to be able to read it better). I=E2=80=99m = attaching the .DIFF file generated by Mergely as well, for those of us = crusty old unix type folks who like to see that. >> >=20 >> >=20 >> >=20 >> >=20 >> >=20 >> > This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >> >=20 >> > The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >> >=20 >> > Additionally, the delegation process will allow for: >> >=20 >>=20 >> I don't see how this list captures the requirement I raised.=20 >>=20 >> > - Fine-grained specification of access >> > - Approval of AS attestation to identity claims >> > - Approval of access to multiple resources and APIs in a single = interaction >> > - Support for multiple access tokens in a single request >>=20 >> This item justifies Justin=E2=80=99s latest addition to XYZ to allow = the client to allocate resources to access tokens.=20 > =20 > I've multiple access tokens in XAuth since the first draft.. No one = told me that was not scope for the charter back then. I consider "fine = grained specification of access" to include many different ways to be = fine grained.=20 > =20 > We added multiple tokens to clarify I=E2=80=99ve always thought multiple access tokens were in scope for = work as well.=20 The XAuth method of multiple access tokens fits your model =E2=80=94 the = GS can simply return multiple tokens (or =E2=80=9Cauthorizations=E2=80=9D)= to any client at any time. I think there are severe problems with that = model in terms of client complexity and developer friendliness, and = that=E2=80=99s why XYZ=E2=80=99s multiple token support takes a = different approach.=20 But I do not see the charter text as limiting us to the client-directed = approach. I=E2=80=99m OK with the AS doing token allocation if we can = also solve all of the problems that it brings (which I brought up on the = other thread, the biggest of which is having a client know what exactly = to do with the tokens in the response). > =20 >> That=E2=80=99s fine, but it=E2=80=99s geared towards the client = deciding how to split tokens.=20 > =20 > I don't see why the scope is limited to the client deciding. In = current OAuth 2.0 use cases, which is in scope, the AS decides what it = will, and will not issue tokens for. Extending that to multiple tokens, = and multiple resources to me implies the AS can still decide what each = token can do. > =20 >>=20 >> I=E2=80=99m looking for a way to let the RS (with the AS acting on = its behalf) influence the token allocation and with that the token = design. As I have explained several times, the token format & content is = part of the AS to RS interface and the current charter limits this to a = single design option: handles + token introspection, at least in multi = RS scenarios.=20 > =20 > I don't think that is the case at all.=20 > XAuth has a different design pattern. Each Authorization is = independent of each other. We also added the following to the charter. > =20 > - Mechanisms for the AS and RS to communicate the access granted by an = access token > =20 > I would consider the token format and content to be one mechanism for = the AS to communicate with the RS. Yes =E2=80=94 the format of the token itself or an introspection = response or a database record lookup =E2=80=94 all are options for AS to = RS communication, and all should be based on the same model of =E2=80=9Cwh= at a token means=E2=80=9D. We kinda had to patch that together in OAuth2 = over time and we can do better now. > =20 >>=20 >> The current charter therewith enshrines one of the big design = limitations OAuth 2 had, which has significant consequences with respect = to security, privacy, UX, performance, and cost.=20 >>=20 >> I understand the intention to keep things for clients as simple as = possible, but it shouldn't be simpler and at the cost of other parties. = In particular, this optimisation is at the cost of resource server = implementers, whose options are very limited with the current charter. I = think the new protocol should leave the optimisation decision to = particular deployments and instead support a variety of design options = implementers can choose from.=20 >>=20 >> I suggest to add the following bullet: >>=20 >> - Support for a wide range of access token policies, including single = token per transaction and RS-specific access tokens at the discretion of = the AS > =20 The problem that I have with this is =E2=80=9CAt the discretion of the = AS=E2=80=9D. As stated in the other thread, I think it=E2=80=99s = completely normal for the AS to create an RS-specific token and return = that to the client. I think it=E2=80=99s another thing altogether for = the AS to create several different RS-specific tokens when the client = didn=E2=80=99t ask for that. That=E2=80=99s the only sticking point I = have in your proposal =E2=80=94 surprising the client with more tokens. = I think the charter does cover what you=E2=80=99re after and I=E2=80=99m = interested in finding a solution to it. > I think that is already covered by the existing charter.=20 > =20 >>=20 >> > - Support for directed, audience-restricted access tokens >>=20 >> This looks good on first sight but it misses the important point that = the AS on behalf of the RS can decide to issue such tokens. > =20 > The AS decides what tokens it will issue to a Client already in OAuth = 2.0, so it is in scope. What am I missing? > =20 >>=20 >> > - Separation between the party authorizing access and the party = operating the client requesting access >> > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >> >=20 >> > The group will define extension points for this protocol to allow = for flexibility in areas including: >> >=20 >> > - Cryptographic agility for keys, message signatures, and proof of = possession=20 >> > - User interaction mechanisms including web and non-web methods >> > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions >> > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys >> > - Optimized inclusion of additional information through the = delegation process (including asserted identity claims) >>=20 >> wfm although I don't understand why this is an extension point and = not incorporated in the bullet below. It needs to be an extension point because simple identity claims are = what we=E2=80=99re working on but others might want to return other bits = of info using the same structures (like payment information or = whatever). >>=20 >> >=20 >> > Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: >> >=20 >> > - Discovery of the authorization server >> > - Revocation of active tokens >> > - Mechanisms for the AS and RS to communicate the access granted by = an access token >>=20 >> wfm >>=20 >> >=20 >> > Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. >> >=20 >> > This group is not chartered to develop extensions to OAuth 2..0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >> >=20 >> > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >> >=20 >> > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 >>=20 >> I=E2=80=99m still not seeing the benefit of including identity at the = "AS to client" interface in this charter. This paragraph could be = removed without any impact on the rest of the charter.=20 The client is the consumer of the identity. It=E2=80=99s the app = you=E2=80=99re logging in to. This is a massively widespread use case = and at the core of what people think of as identity in this space. > =20 > Are you questioning why identity is in scope, or that this statement = is redundant? > =20 >>=20 >> >=20 >> > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >> >=20 >> > Milestones to include: >> > - Core delegation protocol >> > - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures >> > - Identity and authentication conveyance mechanisms >> > - Guidelines for use of protocol extension points >>=20 >> General observations: >>=20 >> While I was reading the updated charter several times, I made the = following observations:=20 >>=20 >> The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all = in this charter..=20 >>=20 >> So I=E2=80=99m asking: Do we intend to build a protocol for = interoperability?=20 > =20 > I would consider a protocol requires interoperability. A framework = does not. > =20 > The charter states that we are building a protocol, which appears = throughout the charter text. I agree that a protocol implies interoperability, but as stated above = I=E2=80=99m not against calling it out specifically. > =20 >>=20 >> If we are aiming for interoperability, what level of interoperability = do we want to achieve? I think we must aim for "on the wire" = interoperability that can be tested automatically. That would allow to = truly use TXAuth based authorization wherever an API is being protected = using TXAuth without the need for deployment specific customisation, = just like BASIC auth and TLS. >>=20 >> If we are aiming for interoperability, where do we seek for = interoperability? At the client - AS interface only? Or do we consider = the AS - RS interface as well? And what is about the client - RS = interface? I think all of them should be in scope for various reasons.=20= >>=20 >> Client - AS: clearly in scope even if not stated=20 >>=20 >> AS - RS: would allow to combine ASs and RSs from different sources. = That's an important requirement for us (yes.com ), = since we run a >1000 AS federation where the RSs can be invoked using = tokens from all of those ASs (that are built using different products). = Combining software on both ends from different sources (e.g. different = vendors) is another example. Interoperability between AS and RS is a key = success factor in such a scenario and is less than poorly supported = today by OAuth 2. TXAuth should do better.=20 I agree and think we can do better as well. OAuth 2 has a set of common = mechanisms for that (JWTs and introspection being the big two), and I = think at the very least we can offer an interoperable model that can = handle different deployment characteristics. Self-contained tokens = simply don=E2=80=99t work everywhere, and neither do lookup services. I = don=E2=80=99t want to pick one or the other but they should be parallel = to each other =E2=80=94 it should be the same information regardless of = whether yyou pull it out of the token itself or look it up. >>=20 >> Client - RS: there is an obvious reason, which is the way access = tokens are conveyed. The less obvious reason is to take a look into how = a client could find out what it takes to perform a suitable = authorization process to be able to invoke a particular RS.=20 This is something we=E2=80=99ve left space for in XYZ because of work = that=E2=80=99s been done with UMA. In XYZ, it=E2=80=99d work like this: C->RS: do an action of some type RS->AS: make a call to some other endpoint saying =E2=80=9Csomeone=E2=80=99= s trying to do this thing=E2=80=9D AS->RS: return a resource handle representing the thing the client=E2=80=99= s doing RS->C: return the resource handle C->AS: start TX with the resource handle (and maybe other resource info = as well, since the combination semantics are clear) > =20 > To clarify, you would like discovery at the RS to be in scope? = Rereading the charter, I can see that is not specifically called out, = and discovery at the RS could be considered out of scope.=20 > =20 > I could also argue that it is in scope in order for the client to know = how to present tokens to the RS.=20 > =20 >>=20 >> It totally strikes me that the latter two interfaces seem to be = mostly out of scope. To me the current charter will cause the TXAuth WG = to look onto a small portion of the overall process (client to AS) only. = The result will be incomplete and needs to be patched together with the = rest in real implementations.=20 > =20 > The former, how the client presents tokens, is in scope: > =20 >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > =20 >>=20 >> I therefore suggest to add the following text after the first = paragraph=20 >>=20 >> "The delegation protocol will enable interoperability between client = and authorization server, authorisation server and resource server and, = as needed to perform delegation, client and resource server. Conformance = of an implementation with the specifications can be tested = automatically.=E2=80=9D I think requiring automated testing for everything is too far =E2=80=94 = but I am completely in favor of us doing the automated testing anyway. I = would in fact recommend that we adopt the protocol testing framework = that I original designed for OBUK that=E2=80=99s now being used by OIDF = to test FAPI and, eventually, all the rest of the the systems. I = specifically wrote it to not be OAuth specific so that it can test other = protocols like this, and so it=E2=80=99s really a perfect fit for this = problem. > =20 > =20 > I think your first sentence is already covered, although each point is = spread out through the charter.=20 > =20 > I think your second sentence is overly specific.=20 > =20 >>=20 >> Which also brings me to Nat=E2=80=99s proposal to write an = architecture document. I=E2=80=99m not convinced we need an architecture = document (in the sense of a RFC), but I=E2=80=99m sure we need to = discuss and document overall use cases and design options. Understanding = those is the prerequisite to design a suitable and as easy as possible = protocol.=20 >>=20 >> So please add the following bullet to the charter under Milestones:=20= >>=20 >> "- documentation of the use cases and design options the new protocol = will support=E2=80=9D I didn=E2=80=99t put that in the milestones because I didn=E2=80=99t = want it to be considered a WG deliverable =E2=80=94 IE an RFC-track = document. As stated before, I=E2=80=99m absolutely in favor of both an = architecture doc and a use case doc being living artifacts that the = group uses to express and reference what it=E2=80=99s doing. We need to = write things down! But it doesn=E2=80=99t need to be =E2=80=9Cdelivered=E2= =80=9D anywhere outside of this group, nor does it need to be a = =E2=80=9Cmilestone=E2=80=9D created before the group can work on = something else like the actual protocol. =E2=80=94 Justin > =20 > I think what we do to meet the "Core delegation protocol" milestone is = up to the group to decide. I don't think we have to have it in the = charter. > =20 >>=20 >> best regards, >> Torsten.=20 >>=20 >>=20 >> >=20 >> >=20 >> >=20 >> >=20 >> > --=20 >> > Txauth mailing list >> > Txauth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth = > -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_876096E6-72E4-4578-97EE-BA087654BB11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Dick that the fact that we=E2=80=99re building a protocol = implies interoperability, and I=E2=80=99d go further that merely putting = =E2=80=9Cinteroperability=E2=80=9D into the charter doesn=E2=80=99t = necessarily mean that you=E2=80=99re going to get something that works = out of the box between two systems every time. 

That said, I would be OK with adding = the following line to the Carter:

The delegation protocol will = enable interoperability between the client and authorization server, = client and resource server, and resource server and authorization = server. 

Specifically I see those map to functions we=E2=80=99re = already signing up for doing. Respectively:

 - How to get a token (including = how to ask for something specific)
 - How to = use a token (and deal with security-level errors)
 - How to interpret a token (using at the very least a = common model of what a token represents)

I think it=E2=80=99s redundant but it = wouldn=E2=80=99t hurt to call it out specifically.

A few more responses to = Torsten=E2=80=99s comments inline below.

On Mar = 22, 2020, at 2:43 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

If we = have agreement on Torsten=E2=80=99s interoperability text (quoted = below), I think we should add it. If only for the word = =E2=80=9Cinteroperability=E2=80=9D to appear in the charter.
 
=E2=80=9CTh= e delegation protocol will enable interoperability between client and = authorization server, authorisation server and resource server and, as = needed to perform delegation, client and resource server.=E2=80=9D
 
Thanks,
          &nb= sp;     Yaron
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Sunday, March 22, 2020 = at 20:31
To: Torsten Lodderstedt = <torsten@lodderstedt.net>
Cc: Kim = Cameron <kim@identityblog..com>, Mike Jones <michael.jones@microsoft.com>, <txauth@ietf.org>, = Filip Skokan <panva.ip@gmail.com>
Subject: Re: [Txauth] Proposed = TxAuth charter Text
 
 
 
On Sun, Mar 22, 2020 at = 10:50 AM Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
Hi Dick,

thanks for trying to = consider the concerns we have raced in an update to the proposed = charter. 

> On 21. Mar 2020, at 20:55, Dick Hardt = <dick..hardt@gmail.com> wrote:
> 
> = (replying with those that had expressed concerns about the charter on = the To: list to bring it to the top of their inbox)
> 
> Mike, Kim, Torsten, Filip: are your concerns addressed = with the changes below?
> 
> = (apologies to anyone I missed in the To: list)
> 
> On Sat, = Mar 21, 2020 at 12:41 PM Justin Richer <jricher@mit.edu> = wrote:
> After some great discussions on the list in = the last week, Yaron, Dick, and I have pulled together a new proposed = charter.. I think this is version 5.0? But I forget exactly. :)
> 
> I=E2=80=99ve highlighted the new lines in bold = here,  for those reading this email in HTML. There=E2=80=99s a diff = available online at  http://www.mergely.com/RehoJJvW/  (note: go to = view->word wrap to be able to read it better). I=E2=80=99m attaching = the .DIFF file generated by Mergely as well, for those of us crusty old = unix type folks who like to see that.
> 
> 
> 
> 
> 
> This = group is chartered to develop a fine-grained delegation protocol for = authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. 
> 
> The = delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.
> 
> = Additionally, the delegation process will allow for:
> 

I don't see how this list captures the = requirement I raised. 

> - Fine-grained specification of access
> = - Approval of AS attestation to identity claims
> - = Approval of access to multiple resources and APIs in a single = interaction
> - Support for multiple access tokens in a = single request

This item justifies = Justin=E2=80=99s latest addition to XYZ to allow the client to allocate = resources to access tokens. 
 
I've multiple = access tokens in XAuth since the first draft.. No one told me that = was not scope for the charter back then. I consider "fine grained = specification of access" to include many different ways to be fine = grained. 
 
We added multiple tokens to = clarify

I=E2=80=99ve always thought multiple access tokens = were in scope for work as well. 

The XAuth method of multiple access tokens fits = your model =E2=80=94 the GS can simply return multiple tokens (or = =E2=80=9Cauthorizations=E2=80=9D) to any client at any time. I think = there are severe problems with that model in terms of client complexity = and developer friendliness, and that=E2=80=99s why XYZ=E2=80=99s = multiple token support takes a different approach. 

But I do not see the charter text as limiting us = to the client-directed approach. I=E2=80=99m OK with the AS doing token = allocation if we can also solve all of the problems that it brings = (which I brought up on the other thread, the biggest of which is having = a client know what exactly to do with the tokens in the = response).

 
That=E2=80=99s fine, but it=E2=80=99s geared towards the = client deciding how to split tokens. 
 
I don't see why the scope is limited to = the client deciding. In current OAuth 2.0 use cases, which is in scope, = the AS decides what it will, and will not issue tokens for. Extending = that to multiple tokens, and multiple resources to me implies the AS can = still decide what each token can do.
 

I=E2=80=99m looking for a way to let the RS (with the AS = acting on its behalf) influence the token allocation and with that the = token design. As I have explained several times, the token format & = content is part of the AS to RS interface and the current charter limits = this to a single design option: handles + token introspection, at least = in multi RS scenarios. 
 
I don't think that is the case at = all. 
XAuth has a different design pattern. = Each Authorization is independent of each other. We also added the = following to the charter.
 
- Mechanisms for the AS and RS to communicate = the access granted by an access token
 
I would consider the token format and = content to be one mechanism for the AS to communicate with the = RS.

Yes =E2=80=94 the format of the token itself or an = introspection response or a database record lookup =E2=80=94 all are = options for AS to RS communication, and all should be based on the same = model of =E2=80=9Cwhat a token means=E2=80=9D. We kinda had to patch = that together in OAuth2 over time and we can do better now.

 

The current charter = therewith enshrines one of the big design limitations OAuth 2 had, which = has significant consequences with respect to security, privacy, UX, = performance, and cost. 

I understand the intention to keep things for clients as = simple as possible, but it shouldn't be simpler and at the cost of other = parties. In particular, this optimisation is at the cost of resource = server implementers, whose options are very limited with the current = charter. I think the new protocol should leave the optimisation decision = to particular deployments and instead support a variety of design = options implementers can choose from. 

I suggest to add the following bullet:

- Support for a wide range of access token policies, = including single token per transaction and RS-specific access tokens at = the discretion of the AS
 

The problem that I have with this is =E2=80=9C= At the discretion of the AS=E2=80=9D. As stated in the other thread, I = think it=E2=80=99s completely normal for the AS to create an RS-specific = token and return that to the client. I think it=E2=80=99s another thing = altogether for the AS to create several different RS-specific tokens = when the client didn=E2=80=99t ask for that. That=E2=80=99s the only = sticking point I have in your proposal =E2=80=94 surprising the client = with more tokens. I think the charter does cover what you=E2=80=99re = after and I=E2=80=99m interested in finding a solution to it.

I think that is already = covered by the existing charter. 
 

> - Support for = directed, audience-restricted access tokens

This looks good on first sight but it misses the important = point that the AS on behalf of the RS can decide to issue such = tokens.
 
The AS decides what tokens it will issue to a Client already = in OAuth 2.0, so it is in scope. What am I missing?
 

> - Separation = between the party authorizing access and the party operating the client = requesting access
> - A variety of client applications, = including Web, mobile, single-page, and interaction-constrained = applications
> 
> The = group will define extension points for this protocol to allow for = flexibility in areas including:
> 
> - = Cryptographic agility for keys, message signatures, and proof of = possession 
> - User interaction mechanisms including web and non-web = methods
> - Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
> - Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated = cryptographic keys
> - Optimized inclusion of = additional information through the delegation process (including = asserted identity claims)

wfm although I = don't understand why this is an extension point and not incorporated in = the bullet below.
It needs to be an extension point because simple = identity claims are what we=E2=80=99re working on but others might want = to return other bits of info using the same structures (like payment = information or whatever).


> 
> = Additionally, the group will provide mechanisms for management of the = protocol lifecycle including:
> 
> - = Discovery of the authorization server
> - Revocation of = active tokens
> - Mechanisms for the AS and RS to = communicate the access granted by an access token

wfm

> 
> = Although the artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible.
> 
> This = group is not chartered to develop extensions to OAuth 2..0, and as such = will focus on new technological solutions not necessarily compatible = with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be = developed in the OAuth Working Group, including functionality = back-ported from the protocol developed here to OAuth 2.0.
> 
> The group is chartered to develop mechanisms for = applying cryptographic methods, such as JOSE and COSE, to the delegation = process. This group is not chartered to develop new cryptographic = methods.
> 
> The = group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available. 

I=E2=80=99m still not seeing the benefit of including = identity at the "AS to client" interface in this charter. This paragraph = could be removed without any impact on the rest of the charter. 

The client is = the consumer of the identity. It=E2=80=99s the app you=E2=80=99re = logging in to. This is a massively widespread use case and at the core = of what people think of as identity in this space.

 
Are you questioning why identity is in = scope, or that this statement is redundant?
 

> 
> The = initial work will focus on using HTTP for communication between the = client and the authorization server, taking advantage of optimization = features of HTTP2 and HTTP3 where possible, and will strive to enable = simple mapping to other protocols such as COAP when doing so does not = conflict with the primary focus.
> 
> = Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core = protocol for TLS, detached HTTP signature, and embedded HTTP = signatures
> - Identity and authentication conveyance = mechanisms
> - Guidelines for use of protocol extension = points

General observations:

While I was reading the updated charter = several times, I made the following observations: 

The word =E2=80=9Cinteroperability=E2=80=9D does not turn up = at all in this charter.. 

So I=E2=80=99m asking: Do we intend to build a protocol for = interoperability? 
 
I would consider a protocol requires = interoperability. A framework does not.
 
The charter states that we are building = a protocol, which appears throughout the charter = text.

I agree that a protocol implies interoperability, = but as stated above I=E2=80=99m not against calling it out = specifically.

 

If we are aiming for interoperability, what level of = interoperability do we want to achieve? I think we must aim for "on the = wire" interoperability that can be tested automatically. That would = allow to truly use TXAuth based authorization wherever an API is being = protected using TXAuth without the need for deployment specific = customisation, just like BASIC auth and TLS.

If we are aiming for interoperability, where do we seek for = interoperability? At the client - AS interface only? Or do we consider = the AS - RS interface as well? And what is about the client - RS = interface? I think all of them should be in scope for various = reasons. 

Client - AS: clearly in scope even if not = stated 

AS - RS: would allow to combine ASs and RSs = from different sources. That's an important requirement for us (yes.com), since we run a = >1000 AS federation where the RSs can be invoked using tokens from = all of those ASs (that are built using different products). Combining = software on both ends from different sources (e.g. different vendors) is = another example. Interoperability between AS and RS is a key success = factor in such a scenario and is less than poorly supported today by = OAuth 2. TXAuth should do better. 
I agree and think we can do better as well. = OAuth 2 has a set of common mechanisms for that (JWTs and introspection = being the big two), and I think at the very least we can offer an = interoperable model that can handle different deployment = characteristics. Self-contained tokens simply don=E2=80=99t work = everywhere, and neither do lookup services. I don=E2=80=99t want to pick = one or the other but they should be parallel to each other =E2=80=94 it = should be the same information regardless of whether yyou pull it out of = the token itself or look it up.


Client - RS: there is an obvious reason, which = is the way access tokens are conveyed. The less obvious reason is to = take a look into how a client could find out what it takes to perform a = suitable authorization process to be able to invoke a particular = RS. 

This is = something we=E2=80=99ve left space for in XYZ because of work that=E2=80=99= s been done with UMA. In XYZ, it=E2=80=99d work like this:

 C->RS: do an action of some = type
 RS->AS: make a call to some other endpoint = saying =E2=80=9Csomeone=E2=80=99s trying to do this = thing=E2=80=9D
 AS->RS: return a resource handle = representing the thing the client=E2=80=99s = doing
 RS->C: return the resource = handle
 C->AS: start TX with the resource handle (and = maybe other resource info as well, since the combination semantics are = clear)

 
To clarify, you would like discovery at = the RS to be in scope? Rereading the charter, I can see that is not = specifically called out, and discovery at the RS could be considered out = of scope. 
 
I could also argue that it is in scope in order for the = client to know how to present tokens to the RS. 
 

It totally strikes me = that the latter two interfaces seem to be mostly out of scope. To me the = current charter will cause the TXAuth WG to look onto a small portion of = the overall process (client to AS) only. The result will be incomplete = and needs to be patched together with the rest in real = implementations. 
 
The former, how the client presents = tokens, is in scope:
 
- Mechanisms for = presenting tokens to resource servers and binding resource requests to = tokens and associated cryptographic keys
 

I therefore suggest to add the following text after the first = paragraph 

"The delegation protocol will enable = interoperability between client and authorization server, authorisation = server and resource server and, as needed to perform delegation, client = and resource server. Conformance of an implementation with the = specifications can be tested = automatically.=E2=80=9D

I think requiring automated testing = for everything is too far =E2=80=94 but I am completely in favor of us = doing the automated testing anyway. I would in fact recommend that we = adopt the protocol testing framework that I original designed for OBUK = that=E2=80=99s now being used by OIDF to test FAPI and, eventually, all = the rest of the the systems. I specifically wrote it to not be OAuth = specific so that it can test other protocols like this, and so it=E2=80=99= s really a perfect fit for this problem.

 
 
I think your first sentence is already = covered, although each point is spread out through the = charter. 
 
I think your second sentence is overly specific. 
 

Which also brings me to = Nat=E2=80=99s proposal to write an architecture document. I=E2=80=99m = not convinced we need an architecture document (in the sense of a RFC), = but I=E2=80=99m sure we need to discuss and document overall use cases = and design options. Understanding those is the prerequisite to design a = suitable and as easy as possible protocol. 

So please add the following bullet to the charter under = Milestones: 

"- documentation of the use cases and design = options the new protocol will = support=E2=80=9D

I didn=E2=80=99t put that in the milestones = because I didn=E2=80=99t want it to be considered a WG deliverable =E2=80=94= IE an RFC-track document. As stated before, I=E2=80=99m absolutely in = favor of both an architecture doc and a use case doc being living = artifacts that the group uses to express and reference what it=E2=80=99s = doing. We need to write things down! But it doesn=E2=80=99t need to be = =E2=80=9Cdelivered=E2=80=9D anywhere outside of this group, nor does it = need to be a =E2=80=9Cmilestone=E2=80=9D created before the group can = work on something else like the actual protocol.

 =E2=80=94 Justin

 
I think what we do to meet the "Core = delegation protocol" milestone is up to the group to decide. I don't = think we have to have it in the charter.
 


best regards,
Torsten. 


> 
> 
> 
> 
> -- 
> Txauth = mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth

-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_876096E6-72E4-4578-97EE-BA087654BB11-- From nobody Sun Mar 22 12:42:57 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197053A0870 for ; Sun, 22 Mar 2020 12:42:55 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 tdh4s93hNTDv for ; Sun, 22 Mar 2020 12:42:52 -0700 (PDT) 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 D72263A086F for ; Sun, 22 Mar 2020 12:42:51 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id s1so8535427lfd.3 for ; Sun, 22 Mar 2020 12:42:51 -0700 (PDT) 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=LK5xpBfHjIi9a3yZQxK1iye2kxWN1ikwZKGMJj3FgJs=; b=OO9u5QUis84AMJ9/WmBlu4qQxdZyZoLar5gSM9p87c3QfAdRhsuh37c8fawEdosGLc A5e9hfdY9ashXKExyo1W+Ui7N40YUiIMAEjojnGl/aesIPnfh/KJLO7P1fPKwavrou9P W01GLMHlRBKIyHIhLIMQdQKNLjIONitWiFatqvsdutLj5OTb12YZ3zb6yVNndf1NWnQv 4hTlKQ+UO2/YiuWOEm0SkMFx1JMZxI9fxCo/jRdsm5xe7btcmRyFahynpAJ71SC5vi7a Y02aKtHM5oP8Eht45fx3lW80NxiQBfpXZk7tWH3Ix48GJyHy9xxNq/kY3S0HYuRMLE/n CY4g== 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=LK5xpBfHjIi9a3yZQxK1iye2kxWN1ikwZKGMJj3FgJs=; b=h2nYFcYoL1qIi/GZ7rp8ZvIBFcxi82EBC3KvQALOZM0XSRAxU+uFGHXdai8JEGhJTc NXi3hPeBm46O+u3QIqIes61ZvD/dv3zfSRwtjFRYAGXR2LZ8YJFL+bN2eGYM+YMJUn3u MuUXnV3o/FwNWbWgLSPT7UlBIa7HKCQWTv8Fot/RHykLaXKby438yVctrJshyYcEBEez LhhdHAWhIvcu9J7FZQml1p0JXB4AcBJbd58eTq0c/FWEgUsyEJj6OcN2+AeTHchVqXim FqB8vD3EbHrz1NMcgkMYx4omSLerJW73ofjww4WEVhvvJHFQhJmjnWuTopSB/2o9yjPO ASMw== X-Gm-Message-State: ANhLgQ08wHsBn6ZjUrTlaxKZOfA7UiCXWhZ5gdWLt+dJoWRczsHIL5eb jSAwLB9/LLa8Uv+ulg3v/nj0pd+bI8ttfCpoq9A= X-Google-Smtp-Source: ADFU+vu6X5jU/HiTEWt/0H9T+kBqvY7v8gixRkkeJbkkhMjv5/5SFFP1H4QYOa48WigMXzel9IMMz3nYyRxnJJNJjmU= X-Received: by 2002:a05:6512:31d5:: with SMTP id j21mr11158263lfe.23.1584906169700; Sun, 22 Mar 2020 12:42:49 -0700 (PDT) MIME-Version: 1.0 References: <1CE69263-A412-465D-AB19-7DF6D16AF1AF@gmail.com> In-Reply-To: <1CE69263-A412-465D-AB19-7DF6D16AF1AF@gmail.com> From: Dick Hardt Date: Sun, 22 Mar 2020 12:42:23 -0700 Message-ID: To: Yaron Sheffer Cc: Torsten Lodderstedt , Kim Cameron , Mike Jones , txauth@ietf.org, Filip Skokan Content-Type: multipart/alternative; boundary="0000000000003f559505a176b9c9" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 19:42:55 -0000 --0000000000003f559505a176b9c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm fine with that. Makes it clear. On Sun, Mar 22, 2020 at 11:43 AM Yaron Sheffer wrote: > If we have agreement on Torsten=E2=80=99s interoperability text (quoted b= elow), I > think we should add it. If only for the word =E2=80=9Cinteroperability=E2= =80=9D to appear > in the charter. > > > > =E2=80=9CThe delegation protocol will enable interoperability between cli= ent and > authorization server, authorisation server and resource server and, as > needed to perform delegation, client and resource server.=E2=80=9D > > > > Thanks, > > Yaron > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Sunday, March 22, 2020 at 20:31 > *To: *Torsten Lodderstedt > *Cc: *Kim Cameron , Mike Jones < > michael.jones@microsoft.com>, , Filip Skokan < > panva.ip@gmail.com> > *Subject: *Re: [Txauth] Proposed TxAuth charter Text > > > > > > > > On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi Dick, > > thanks for trying to consider the concerns we have raced in an update to > the proposed charter. > > > On 21. Mar 2020, at 20:55, Dick Hardt wrote: > > > > (replying with those that had expressed concerns about the charter on > the To: list to bring it to the top of their inbox) > > > > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes > below? > > > > (apologies to anyone I missed in the To: list) > > > > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer wrote: > > After some great discussions on the list in the last week, Yaron, Dick, > and I have pulled together a new proposed charter. I think this is versio= n > 5.0? But I forget exactly. :) > > > > I=E2=80=99ve highlighted the new lines in bold here, for those reading= this > email in HTML. There=E2=80=99s a diff available online at > http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be able > to read it better). I=E2=80=99m attaching the .DIFF file generated by Mer= gely as > well, for those of us crusty old unix type folks who like to see that. > > > > > > > > > > > > This group is chartered to develop a fine-grained delegation protocol > for authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > > > Additionally, the delegation process will allow for: > > > > I don't see how this list captures the requirement I raised. > > > - Fine-grained specification of access > > - Approval of AS attestation to identity claims > > - Approval of access to multiple resources and APIs in a single > interaction > > - Support for multiple access tokens in a single request > > This item justifies Justin=E2=80=99s latest addition to XYZ to allow the = client to > allocate resources to access tokens. > > > > I've multiple access tokens in XAuth since the first draft.. No one told > me that was not scope for the charter back then. I consider "fine grained > specification of access" to include many different ways to be fine graine= d. > > > > We added multiple tokens to clarify > > > > That=E2=80=99s fine, but it=E2=80=99s geared towards the client deciding = how to split > tokens. > > > > I don't see why the scope is limited to the client deciding. In current > OAuth 2.0 use cases, which is in scope, the AS decides what it will, and > will not issue tokens for. Extending that to multiple tokens, and multipl= e > resources to me implies the AS can still decide what each token can do. > > > > > I=E2=80=99m looking for a way to let the RS (with the AS acting on its be= half) > influence the token allocation and with that the token design. As I have > explained several times, the token format & content is part of the AS to = RS > interface and the current charter limits this to a single design option: > handles + token introspection, at least in multi RS scenarios. > > > > I don't think that is the case at all. > > XAuth has a different design pattern. Each Authorization is independent o= f > each other. We also added the following to the charter. > > > > *- Mechanisms for the AS and RS to communicate the access granted by an > access token* > > > > I would consider the token format and content to be one mechanism for the > AS to communicate with the RS. > > > > > The current charter therewith enshrines one of the big design limitations > OAuth 2 had, which has significant consequences with respect to security, > privacy, UX, performance, and cost. > > I understand the intention to keep things for clients as simple as > possible, but it shouldn't be simpler and at the cost of other parties. I= n > particular, this optimisation is at the cost of resource server > implementers, whose options are very limited with the current charter. I > think the new protocol should leave the optimisation decision to particul= ar > deployments and instead support a variety of design options implementers > can choose from. > > I suggest to add the following bullet: > > - Support for a wide range of access token policies, including single > token per transaction and RS-specific access tokens at the discretion of > the AS > > > > I think that is already covered by the existing charter. > > > > > > - Support for directed, audience-restricted access tokens > > This looks good on first sight but it misses the important point that the > AS on behalf of the RS can decide to issue such tokens. > > > > The AS decides what tokens it will issue to a Client already in OAuth 2.0= , > so it is in scope. What am I missing? > > > > > > - Separation between the party authorizing access and the party > operating the client requesting access > > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > > - Cryptographic agility for keys, message signatures, and proof of > possession > > - User interaction mechanisms including web and non-web methods > > - Mechanisms for conveying user, software, organization, and other > pieces of information used in authorization decisions > > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > > - Optimized inclusion of additional information through the delegation > process (including asserted identity claims) > > wfm although I don't understand why this is an extension point and not > incorporated in the bullet below. > > > > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > > > - Discovery of the authorization server > > - Revocation of active tokens > > - Mechanisms for the AS and RS to communicate the access granted by an > access token > > wfm > > > > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new format= s > for identifiers or assertions, nor is the group chartered to develop > schemas for user information, profiles, or other identity attributes, > unless a viable existing format is not available. > > I=E2=80=99m still not seeing the benefit of including identity at the "AS= to > client" interface in this charter. This paragraph could be removed withou= t > any impact on the rest of the charter. > > > > Are you questioning why identity is in scope, or that this statement is > redundant? > > > > > > > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > > > Milestones to include: > > - Core delegation protocol > > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > > - Identity and authentication conveyance mechanisms > > - Guidelines for use of protocol extension points > > General observations: > > While I was reading the updated charter several times, I made the > following observations: > > The word =E2=80=9Cinteroperability=E2=80=9D does not turn up at all in th= is charter. > > So I=E2=80=99m asking: Do we intend to build a protocol for interoperabil= ity? > > > > I would consider a protocol requires interoperability. A framework does > not. > > > > The charter states that we are building a protocol, which appears > throughout the charter text. > > > > > If we are aiming for interoperability, what level of interoperability do > we want to achieve? I think we must aim for "on the wire" interoperabilit= y > that can be tested automatically. That would allow to truly use TXAuth > based authorization wherever an API is being protected using TXAuth witho= ut > the need for deployment specific customisation, just like BASIC auth and > TLS. > > If we are aiming for interoperability, where do we seek for > interoperability? At the client - AS interface only? Or do we consider th= e > AS - RS interface as well? And what is about the client - RS interface? I > think all of them should be in scope for various reasons. > > Client - AS: clearly in scope even if not stated > > AS - RS: would allow to combine ASs and RSs from different sources. That'= s > an important requirement for us (yes.com), since we run a >1000 AS > federation where the RSs can be invoked using tokens from all of those AS= s > (that are built using different products). Combining software on both end= s > from different sources (e.g. different vendors) is another example. > Interoperability between AS and RS is a key success factor in such a > scenario and is less than poorly supported today by OAuth 2. TXAuth shoul= d > do better. > > Client - RS: there is an obvious reason, which is the way access tokens > are conveyed. The less obvious reason is to take a look into how a client > could find out what it takes to perform a suitable authorization process = to > be able to invoke a particular RS. > > > > To clarify, you would like discovery at the RS to be in scope? Rereading > the charter, I can see that is not specifically called out, and discovery > at the RS could be considered out of scope. > > > > I could also argue that it is in scope in order for the client to know ho= w > to present tokens to the RS. > > > > > It totally strikes me that the latter two interfaces seem to be mostly ou= t > of scope. To me the current charter will cause the TXAuth WG to look onto= a > small portion of the overall process (client to AS) only. The result will > be incomplete and needs to be patched together with the rest in real > implementations. > > > > The former, how the client presents tokens, is in scope: > > > > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > > > > > I therefore suggest to add the following text after the first paragraph > > "The delegation protocol will enable interoperability between client and > authorization server, authorisation server and resource server and, as > needed to perform delegation, client and resource server. Conformance of = an > implementation with the specifications can be tested automatically." > > > > > > I think your first sentence is already covered, although each point is > spread out through the charter. > > > > I think your second sentence is overly specific. > > > > > Which also brings me to Nat=E2=80=99s proposal to write an architecture d= ocument. > I=E2=80=99m not convinced we need an architecture document (in the sense = of a RFC), > but I=E2=80=99m sure we need to discuss and document overall use cases an= d design > options. Understanding those is the prerequisite to design a suitable and > as easy as possible protocol. > > So please add the following bullet to the charter under Milestones: > > "- documentation of the use cases and design options the new protocol wil= l > support" > > > > I think what we do to meet the "Core delegation protocol" milestone is up > to the group to decide. I don't think we have to have it in the charter. > > > > > best regards, > Torsten. > > > > > > > > > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000003f559505a176b9c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm fine with that. Makes it clear.

On Sun, Mar 22,= 2020 at 11:43 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

If we have agreement on Tors= ten=E2=80=99s interoperability text (quoted below), I think we should add i= t. If only for the word =E2=80=9Cinteroperability=E2=80=9D to appear in the= charter.

=C2=A0

<= p class=3D"MsoNormal">=E2=80=9CThe delegation protocol will enable interope= rability between client and authorization server, authorisation server and = resource server and, as needed to perform delegation, client and resource s= erver.=E2=80=9D

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Yaron

=C2= =A0

From: <= /b>Txauth <txauth-bounces@ietf.org> = on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Sunday, March 22, = 2020 at 20:31
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Kim Cameron <kim@identityblog.com>, Mike Jones <michael.jones@microsoft.com&= gt;, <txauth@ietf.o= rg>, Filip Skokan <panva.ip@gmail.com>
Subject: Re: [Txauth] Prop= osed TxAuth charter Text

=C2=A0

<= /u>=C2=A0

=C2=A0

On Sun, Mar 22, 2020 at 10:50 AM Torsten Lod= derstedt <t= orsten@lodderstedt.net> wrote:

Hi Dick,

thanks for trying to consid= er the concerns we have raced in an update to the proposed charter.
> On 21. Mar 2020, at 20:55, Dick Hardt <dick.hardt@gmail.com> wrote:
> =
> (replying with those that had expressed concerns about the charter= on the To: list to bring it to the top of their inbox)
>
> Mi= ke, Kim, Torsten, Filip: are your concerns addressed with the changes below= ?
>
> (apologies to anyone I missed in the To: list)
> <= br>> On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <jricher@mit.edu> wrote:
>= After some great discussions on the list in the last week, Yaron, Dick, an= d I have pulled together a new proposed charter. I think this is version 5.= 0? But I forget exactly. :)
>
> I=E2=80=99ve highlighted the n= ew lines in bold here,=C2=A0 for those reading this email in HTML. There=E2= =80=99s a diff available online at=C2=A0 http://www.mergely.com/RehoJJvW/=C2=A0 (no= te: go to view->word wrap to be able to read it better). I=E2=80=99m att= aching the .DIFF file generated by Mergely as well, for those of us crusty = old unix type folks who like to see that.
>
>
>
>= ;
>
> This group is chartered to develop a fine-grained deleg= ation protocol for authorization, identity, and API access. This protocol w= ill allow an authorizing party to delegate access to client software throug= h an authorization server. It will expand upon the uses cases currently sup= ported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) t= o support authorizations scoped as narrowly as a single transaction, provid= e a clear framework for interaction among all parties involved in the proto= col flow, and remove unnecessary dependence on a browser or user-agent for = coordinating interactions.
>
> The delegation process will be= acted upon by multiple parties in the protocol, each performing a specific= role. The protocol will decouple the interaction channels, such as the end= user=E2=80=99s browser, from the delegation channel, which happens directl= y between the client and the authorization server (in contrast with OAuth 2= .0 which is initiated by the client redirecting the user=E2=80=99s browser)= . The client and AS will involve a user to make an authorization decision a= s necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges of= OAuth 2.0 and provides a non-invasive path for supporting future types of = clients and interaction channels.
>
> Additionally, the delega= tion process will allow for:
>

I don't see how this list = captures the requirement I raised.

> - Fine-grained specificatio= n of access
> - Approval of AS attestation to identity claims
>= - Approval of access to multiple resources and APIs in a single interactio= n
> - Support for multiple access tokens in a single request

T= his item justifies Justin=E2=80=99s latest addition to XYZ to allow the cli= ent to allocate resources to access tokens.

=

=C2=A0

I've multiple access=C2=A0tokens in XAuth since the fir= st draft.. No one told me that was not scope for the charter back then. I c= onsider "fine grained specification of access" to include many di= fferent ways to be fine grained.=C2=A0

=C2=A0

We= added multiple=C2=A0tokens to clarify

=C2=A0

<= p class=3D"MsoNormal">That=E2=80=99s fine, but it=E2=80=99s geared towards = the client deciding how to split tokens.

=C2=A0

I don't see why the scope is limited to the client deciding. In= current OAuth 2.0 use cases, which is in scope, the AS decides what it wil= l, and will not issue tokens for. Extending that to multiple tokens, and mu= ltiple resources to me implies the AS can still decide what each token can = do.

=C2=A0=


I=E2=80=99m loo= king for a way to let the RS (with the AS acting on its behalf) influence t= he token allocation and with that the token design. As I have explained sev= eral times, the token format & content is part of the AS to RS interfac= e and the current charter limits this to a single design option: handles + = token introspection, at least in multi RS scenarios.

=C2=A0

I don't think that is the case at all.=C2=A0=

XAuth has a different design p= attern. Each Authorization is independent=C2=A0of each other. We also added= the following to the charter.

=C2=A0

- Mecha= nisms for the AS and RS to communicate the access granted by an access toke= n

=C2=A0

I would consider the token format a= nd content to be one mechanism for the AS to communicate with the RS.

=C2=A0


The current charter ther= ewith enshrines one of the big design limitations OAuth 2 had, which has si= gnificant consequences with respect to security, privacy, UX, performance, = and cost.

I understand the intention to keep things for clients as = simple as possible, but it shouldn't be simpler and at the cost of othe= r parties. In particular, this optimisation is at the cost of resource serv= er implementers, whose options are very limited with the current charter. I= think the new protocol should leave the optimisation decision to particula= r deployments and instead support a variety of design options implementers = can choose from.

I suggest to add the following bullet:

- Su= pport for a wide range of access token policies, including single token per= transaction and RS-specific access tokens at the discretion of the AS

=C2=A0<= /p>

I think that is already covered by the= existing charter.=C2=A0

=C2=A0


> - Support for directed, audience-restricted access tokens
This looks good on first sight but it misses the important point that the = AS on behalf of the RS can decide to issue such tokens.

=C2=A0

<= p class=3D"MsoNormal">The AS decides what tokens it will issue to a Client = already in OAuth 2.0, so it is in scope. What am I missing?

=C2=A0


> - Separation between the part= y authorizing access and the party operating the client requesting access> - A variety of client applications, including Web, mobile, single-pa= ge, and interaction-constrained applications
>
> The group wil= l define extension points for this protocol to allow for flexibility in are= as including:
>
> - Cryptographic agility for keys, message si= gnatures, and proof of possession
> - User interaction mechanisms in= cluding web and non-web methods
> - Mechanisms for conveying user, so= ftware, organization, and other pieces of information used in authorization= decisions
> - Mechanisms for presenting tokens to resource servers a= nd binding resource requests to tokens and associated cryptographic keys> - Optimized inclusion of additional information through the delegatio= n process (including asserted identity claims)

wfm although I don= 9;t understand why this is an extension point and not incorporated in the b= ullet below.

>
> Additionally, the group will provide mech= anisms for management of the protocol lifecycle including:
>
>= - Discovery of the authorization server
> - Revocation of active tok= ens
> - Mechanisms for the AS and RS to communicate the access grante= d by an access token

wfm

>
> Although the artifacts= for this work are not intended or expected to be backwards-compatible with= OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating = from OAuth 2.0 and OpenID Connect to the new protocol where possible.
&g= t;
> This group is not chartered to develop extensions to OAuth 2.0,= and as such will focus on new technological solutions not necessarily comp= atible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will= be developed in the OAuth Working Group, including functionality back-port= ed from the protocol developed here to OAuth 2.0.
>
> The grou= p is chartered to develop mechanisms for applying cryptographic methods, su= ch as JOSE and COSE, to the delegation process. This group is not chartered= to develop new cryptographic methods.
>
> The group is charte= red to develop mechanisms for conveying identity information within the pro= tocol including identifiers (such as email addresses, phone numbers, userna= mes, and subject identifiers) and assertions (such as OpenID Connect ID Tok= ens, SAML Assertions, and Verifiable Credentials). The group is not charter= ed to develop new formats for identifiers or assertions, nor is the group c= hartered to develop schemas for user information, profiles, or other identi= ty attributes, unless a viable existing format is not available.

I= =E2=80=99m still not seeing the benefit of including identity at the "= AS to client" interface in this charter. This paragraph could be remov= ed without any impact on the rest of the charter.

=C2=A0

Are you questioning why identity is in scope, or that this= statement is redundant?

=C2=A0


>
> The initial work will focus on using HTTP for communica= tion between the client and the authorization server, taking advantage of o= ptimization features of HTTP2 and HTTP3 where possible, and will strive to = enable simple mapping to other protocols such as COAP when doing so does no= t conflict with the primary focus.
>
> Milestones to include:<= br>> - Core delegation protocol
> - Key presentation mechanism bin= dings to the core protocol for TLS, detached HTTP signature, and embedded H= TTP signatures
> - Identity and authentication conveyance mechanisms<= br>> - Guidelines for use of protocol extension points

General ob= servations:

While I was reading the updated charter several times, I= made the following observations:

The word =E2=80=9Cinteroperabilit= y=E2=80=9D does not turn up at all in this charter.

So I=E2=80=99m = asking: Do we intend to build a protocol for interoperability?

=C2=A0

I would consider a protocol requires interope= rability. A framework does not.

=C2=A0

The chart= er states that we are building a protocol, which appears throughout the cha= rter text.

=C2=A0=


If we ar= e aiming for interoperability, what level of interoperability do we want to= achieve? I think we must aim for "on the wire" interoperability = that can be tested automatically. That would allow to truly use TXAuth base= d authorization wherever an API is being protected using TXAuth without the= need for deployment specific customisation, just like BASIC auth and TLS.<= br>
If we are aiming for interoperability, where do we seek for interope= rability? At the client - AS interface only? Or do we consider the AS - RS = interface as well? And what is about the client - RS interface? I think all= of them should be in scope for various reasons.

Client - AS: clear= ly in scope even if not stated

AS - RS: would allow to combine ASs = and RSs from different sources. That's an important requirement for us = (yes.com), since we run a = >1000 AS federation where the RSs can be invoked using tokens from all o= f those ASs (that are built using different products). Combining software o= n both ends from different sources (e.g. different vendors) is another exam= ple. Interoperability between AS and RS is a key success factor in such a s= cenario and is less than poorly supported today by OAuth 2. TXAuth should d= o better.

Client - RS: there is an obvious reason, which is the way= access tokens are conveyed. The less obvious reason is to take a look into= how a client could find out what it takes to perform a suitable authorizat= ion process to be able to invoke a particular RS.

=C2=A0

To clarify, you would like discovery at the RS to be in sc= ope? Rereading the charter, I can see that is not specifically called out, = and discovery at the RS could be considered out of scope.=C2=A0

=C2=A0

=

I could also argue that it is in scope in order for = the client to know how to present tokens to the RS.=C2=A0

=

=C2=A0


It totally strikes me that the latte= r two interfaces seem to be mostly out of scope. To me the current charter = will cause the TXAuth WG to look onto a small portion of the overall proces= s (client to AS) only. The result will be incomplete and needs to be patche= d together with the rest in real implementations.

=C2=A0

The former, how the client presents tokens, is in scope:

=C2=A0

<= /div>

- Mechanisms for presenting tokens to resource ser= vers and binding resource requests to tokens and associated cryptographic k= eys

=C2=A0


I therefore suggest to add the following text after the first para= graph

"The delegation protocol will enable interoperability be= tween client and authorization server, authorisation server and resource se= rver and, as needed to perform delegation, client and resource server. Conf= ormance of an implementation with the specifications can be tested automati= cally."

<= /u>=C2=A0

=C2=A0<= /p>

I think your first sentence is already= covered, although each point is spread out through the charter.=C2=A0

=C2=A0

I think your second sentence is overly specif= ic.=C2=A0

=C2=A0<= u>


Which als= o brings me to Nat=E2=80=99s proposal to write an architecture document. I= =E2=80=99m not convinced we need an architecture document (in the sense of = a RFC), but I=E2=80=99m sure we need to discuss and document overall use ca= ses and design options. Understanding those is the prerequisite to design a= suitable and as easy as possible protocol.

So please add the follo= wing bullet to the charter under Milestones:

"- documentation = of the use cases and design options the new protocol will support"<= /u>

=C2=A0=

I think what we do to meet the "= Core delegation protocol" milestone is up to the group to decide. I do= n't think we have to have it in the charter.

=C2=A0


best regards,Torsten.


>
>
>
>
> --
> = Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txa= uth

--= Txauth mailing list T= xauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =

--0000000000003f559505a176b9c9-- From nobody Sun Mar 22 12:53:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99883A088A for ; Sun, 22 Mar 2020 12:53:47 -0700 (PDT) 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 UUCsdgqkmLBa for ; Sun, 22 Mar 2020 12:53:45 -0700 (PDT) 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 18E663A087C for ; Sun, 22 Mar 2020 12:53:44 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id n20so8552866lfl.10 for ; Sun, 22 Mar 2020 12:53:44 -0700 (PDT) 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=vJvIWjQVhgT6kuLJf4u/2DVpGcevuv9uDx96tQXSngM=; b=p7kJJx4jq/12H2rKvrDLZLtrjF/8WPJvz7zM0B2EtDhNfs0yWczHnPkg1eHPj1W8eT RxBIqiWViwYFTT4o/nO7ykh+oPfx3QZCsbdgMrlfButSHYxXGO9t8Dq/AuXSli4Wanc/ 7IHnqAMLisEHz8fUJ3PXEDS5TAmSDCGEDa44ietUCygZgEph+LMaNkheXpW5GwikpCca AT1BgQ3PmyoS+xlAAkhDw4tBPYoEra2RsiO396uQojeV+2MlWfA/wxuJewk7nTAUn2gH GApCkv8cPfrnXyFR/g1gjZWa9GX5rJD+wEJOMamtxAsvVNq4ww5FE7RQOEYihT2ew+V8 jlMw== 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=vJvIWjQVhgT6kuLJf4u/2DVpGcevuv9uDx96tQXSngM=; b=DMiuSlQ5/b9+9mBvN5/RMpMZr17YIUawNMTh5m3JLi6JVWaqZ91nuFm2EIUHeJ+60T Y3dHaM4e0bV86erioyJY4vSnhKQzZyyeBfXxIZQmNo4BuI8noAQCr/U4cZC/DFmdGCvp 0zQUMABbt1SqWKRb7jYXvTZvTkqBwyYjM22gmI/TsjFdAWT8wEESuYqu8pAGk/XgV8Wu qwNS338K5+GMD/KJ09A/JLxPHKoklpukbGw4vOZu/PcXLfP70W7WcahY0QUssY0FQKQp fr7G8yYcmhwmZDsuXgy6i4covQwvQVWsxS1xxTSI7DmbAl9ktzNn6g1jbYU8AbalHtkV w43Q== X-Gm-Message-State: ANhLgQ0wHjSg4T0w1sx+YPwPjX5HtSU3So4QjMfZF9fXi9F49pl+lFrs f8AU/UNMagkRBsRoNdUIGR7Z0bESXY+x4a3fxx6+TCnn X-Google-Smtp-Source: ADFU+vunFnei3ScocTY/PgUw5qR9FtCP0qYNS15V3q9ZeO3UFUPV6WtY+2krnNc5P8fZaqurkx0+1qDP4si33GKbn/U= X-Received: by 2002:a19:a401:: with SMTP id q1mr10829570lfc.157.1584906822983; Sun, 22 Mar 2020 12:53:42 -0700 (PDT) MIME-Version: 1.0 References: <9692BA55-6BCA-4879-930F-B8E4D72BD933@lodderstedt.net> In-Reply-To: <9692BA55-6BCA-4879-930F-B8E4D72BD933@lodderstedt.net> From: Dick Hardt Date: Sun, 22 Mar 2020 12:53:16 -0700 Message-ID: To: Torsten Lodderstedt Cc: Mike Jones , Kim Cameron , Filip Skokan , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000002fa47105a176e004" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 19:53:50 -0000 --0000000000002fa47105a176e004 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten Sections deleted for readability ... comments inserted On Sun, Mar 22, 2020 at 12:11 PM Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > > > > > That=E2=80=99s fine, but it=E2=80=99s geared towards the client decidin= g how to split > tokens. > > > > I don't see why the scope is limited to the client deciding. In current > OAuth 2.0 use cases, which is in scope, the AS decides what it will, and > will not issue tokens for. > > That=E2=80=99s works in multi RS setups with proprietary extensions only.= I want > to get rid of those and have an interoperable solution for it. > I'm combining the OAuth 2.0 use case scope PLUS the multiple RS scope. > > > Extending that to multiple tokens, and multiple resources to me implies > the AS can still decide what each token can do. > > =E2=80=9Cimplies=E2=80=9D is the key word here. I agree with you. Do othe= r WG members as > well? > > > > > > > I=E2=80=99m looking for a way to let the RS (with the AS acting on its = behalf) > influence the token allocation and with that the token design. As I have > explained several times, the token format & content is part of the AS to = RS > interface and the current charter limits this to a single design option: > handles + token introspection, at least in multi RS scenarios. > > > > I don't think that is the case at all. > > XYZ is limited this way right now and I assume it=E2=80=99s considered to= be > charter compliant as well. For me this means, we are in an area governed = by > the decisions of the editors of the individual drafts. > I think the WG decides what is in the IDs. Just because XYZ does not have it does not mean it is not in the scope of the Charter. And just because something is in the scope of the charter, does not mean we will create a solution for it. > > > XAuth has a different design pattern. Each Authorization is independent > of each other. We also added the following to the charter. > > > > - Mechanisms for the AS and RS to communicate the access granted by an > access token > > > > I would consider the token format and content to be one mechanism for > the AS to communicate with the RS. > > Sure, but it does not determine who decides what to use and where. Just > saying JWT is a way to implement self contained access tokens gives an AS > the ability to issue one JWT to RS1 and another JWT to RS2. > The charter lets the AS and RS communicate however we as a group decide. It is a broad scope. > > > > > > > > - Support for directed, audience-restricted access tokens > > > > This looks good on first sight but it misses the important point that > the AS on behalf of the RS can decide to issue such tokens. > > > > The AS decides what tokens it will issue to a Client already in OAuth > 2.0, so it is in scope. What am I missing? > > You are missing the dependency on the RS. RS1 wants a JWT with certain > claims and RS2 wants a handle to be queried via introspection (because of > immediate revocation support). How is that covered in OAuth 2? > As stated above, another aspect of the scope is multiple RS support. > > > > Are you questioning why identity is in scope, or that this statement is > redundant? > > I=E2=80=99m questioning why identity at the client to AS interface is in = scope. > That=E2=80=99s a separate topic independent of delegation. Moreover, and = I have > already stated that, it has a different trust model resulting in a > different security threat model. Adding this to TXAuth significantly > increase complexity for all of us. > LOTS of use cases care about doing identity and delegation at the same time, or with the same AS. Someone has to deal with the complexity. I would rather it be at the core protocol than tacked on. > > > "The delegation protocol will enable interoperability between client an= d > authorization server, authorisation server and resource server and, as > needed to perform delegation, client and resource server. Conformance of = an > implementation with the specifications can be tested automatically." > > > > > > I think your first sentence is already covered, although each point is > spread out through the charter. > > Why not just make it explicit? > Sure. See Yaron's suggestion. I'm good with that. > > > > > I think your second sentence is overly specific. > > Why? I=E2=80=99m not saying this WG shall write a test or maintain test s= ervices. > All I=E2=80=99m saying is implementations shall be testable for conforman= ce using > an automatic test. This will drive protocol definition to a whole new > level, as we have learned with FAPI, since there is no longer room for ha= nd > waving when it comes to gaps and missing pieces. > I echo Justin's comments. Multiple, interoperating implementations is a goal for being advanced to an RFC from what I understand. > > > > > > > Which also brings me to Nat=E2=80=99s proposal to write an architecture > document. I=E2=80=99m not convinced we need an architecture document (in = the sense > of a RFC), but I=E2=80=99m sure we need to discuss and document overall u= se cases > and design options. Understanding those is the prerequisite to design a > suitable and as easy as possible protocol. > > > > So please add the following bullet to the charter under Milestones: > > > > "- documentation of the use cases and design options the new protocol > will support" > > > > I think what we do to meet the "Core delegation protocol" milestone is > up to the group to decide. I don't think we have to have it in the charte= r. > > Then why do we need milestones at all? I think we will see a lack of > consensus shining through in every feature discussion if we do not agree = on > the use cases and design options. > We don't list each sub item -- the major deliverables. I agree with Justin on this as well. These are good to help us create the end product which is the core protocol. I don't think they are all that useful independent of the core protocol /Dick --0000000000002fa47105a176e004 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Torsten

Sections de= leted for readability ... comments inserted

On Sun, Mar 22, 2020 at 12= :11 PM Torsten Lodderstedt <t= orsten@lodderstedt.net> wrote:

>=C2=A0
> That=E2=80=99s fine, but it=E2=80=99s geared towards the client decidi= ng how to split tokens.
>
> I don't see why the scope is limited to the client deciding. In cu= rrent OAuth 2.0 use cases, which is in scope, the AS decides what it will, = and will not issue tokens for.

That=E2=80=99s works in multi RS setups with proprietary extensions only. I= want to get rid of those and have an interoperable solution for it.

I'm combining the OAuth 2.0 use case sco= pe PLUS the multiple=C2=A0RS scope.
=C2=A0

> Extending that to multiple tokens, and multiple resources to me implie= s the AS can still decide what each token can do.

=E2=80=9Cimplies=E2=80=9D is the key word here. I agree with you. Do other = WG members as well?

>=C2=A0
>
> I=E2=80=99m looking for a way to let the RS (with the AS acting on its= behalf) influence the token allocation and with that the token design. As = I have explained several times, the token format & content is part of t= he AS to RS interface and the current charter limits this to a single desig= n option: handles + token introspection, at least in multi RS scenarios. >
> I don't think that is the case at all.

XYZ is limited this way right now and I assume it=E2=80=99s considered to b= e charter compliant as well. For me this means, we are in an area governed = by the decisions of the editors of the individual drafts.
=

I think the WG decides what is in the IDs. Just because= XYZ does not have it does not mean it is not in the scope of the Charter. = And just because something is in the scope of the charter, does not mean we= will create a solution for it.
=C2=A0

> XAuth has a different design pattern. Each Authorization is independen= t of each other. We also added the following to the charter.
>
> - Mechanisms for the AS and RS to communicate the access granted by an= access token
>
> I would consider the token format and content to be one mechanism for = the AS to communicate with the RS.

Sure, but it does not determine who decides what to use and where. Just say= ing JWT is a way to implement self contained access tokens gives an AS the = ability to issue one JWT to RS1 and another JWT to RS2.

The charter lets the AS and RS communicate however we as a= group decide. It is a broad scope.
=C2=A0

>=C2=A0
>
> > - Support for directed, audience-restricted access tokens
>
> This looks good on first sight but it misses the important point that = the AS on behalf of the RS can decide to issue such tokens.
>
> The AS decides what tokens it will issue to a Client already in OAuth = 2.0, so it is in scope. What am I missing?

You are missing the dependency on the RS. RS1 wants a JWT with certain clai= ms and RS2 wants a handle to be queried via introspection (because of immed= iate revocation support). How is that covered in OAuth 2?
=

As stated above, another aspect of the scope is multipl= e RS support.
=C2=A0
>
> Are you questioning why identity is in scope, or that this statement i= s redundant?

I=E2=80=99m questioning why identity at the client to AS interface is in sc= ope. That=E2=80=99s a separate topic independent of delegation. Moreover, a= nd I have already stated that, it has a different trust model resulting in = a different security threat model. Adding this to TXAuth significantly incr= ease complexity for all of us.

LOTS of = use cases care about doing identity and delegation at the same time, or wit= h the same AS. Someone has to deal with the complexity. I would rather it b= e at the core protocol than tacked on.

=C2=A0

> "The delegation protocol will enable interoperability between cli= ent and authorization server, authorisation server and resource server and,= as needed to perform delegation, client and resource server. Conformance o= f an implementation with the specifications can be tested automatically.&qu= ot;
>
>
> I think your first sentence is already covered, although each point is= spread out through the charter.

Why not just make it explicit?

Sure. S= ee Yaron's suggestion. I'm good with that.
=C2=A0

>
> I think your second sentence is overly specific.

Why? I=E2=80=99m not saying this WG shall write a test or maintain test ser= vices. All I=E2=80=99m saying is implementations shall be testable for conf= ormance using an automatic test. This will drive protocol definition to a w= hole new level, as we have learned with FAPI, since there is no longer room= for hand waving when it comes to gaps and missing pieces.

I echo Justin's comments. Multiple, interoperating= implementations is a goal for being advanced to an RFC from what I underst= and.
=C2=A0
Cc: Dick Hardt , Kim Cameron , Mike Jones , txauth@ietf.org, Filip Skokan To: Torsten Lodderstedt References: <9692BA55-6BCA-4879-930F-B8E4D72BD933@lodderstedt.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 20:31:07 -0000 --Apple-Mail=_DC573399-240C-4209-B432-B3715863F535 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A couple key responses: >> I consider "fine grained specification of access" to include many = different ways to be fine grained.=20 >=20 > That=E2=80=99s your interpretation, I would have interpreted = =E2=80=9CApproval of access to multiple resources and APIs in a single = interaction=E2=80=9D accordingly. But it seems to me, other people = interpret that differently.=20 I interpreted it this way as well, and that was my intent with the = charter. We don=E2=80=99t wan to constrain the style of APIs that we = protect with TxAuth to be =E2=80=9Cfine grained=E2=80=9D in a particular = way. Splitting the =E2=80=9Cgrains=E2=80=9D based on different RS=E2=80=99= s is one important way to do it. >=20 >>=20 >> We added multiple tokens to clarify >=20 > It =E2=80=99s multiple access token in the request, not the response.=20= I=E2=80=99m fine with changing that text to =E2=80=9Crequest and = response=E2=80=9D as stated on the other thread, so I hope this isn=E2=80=99= t the sticking point.=20 >> Extending that to multiple tokens, and multiple resources to me = implies the AS can still decide what each token can do. >=20 > =E2=80=9Cimplies=E2=80=9D is the key word here. I agree with you. Do = other WG members as well? The AS always decides what the token can do =E2=80=94 at least to the = point that the RS interprets it and then the RS finally decides what the = token can actually do by enforcing it. It=E2=80=99s a pseudo PEP-PDP = split all over again. >=20 >> I=E2=80=99m looking for a way to let the RS (with the AS acting on = its behalf) influence the token allocation and with that the token = design. As I have explained several times, the token format & content is = part of the AS to RS interface and the current charter limits this to a = single design option: handles + token introspection, at least in multi = RS scenarios.=20 >>=20 >> I don't think that is the case at all.=20 >=20 > XYZ is limited this way right now and I assume it=E2=80=99s considered = to be charter compliant as well. For me this means, we are in an area = governed by the decisions of the editors of the individual drafts.=20 Nothing is =E2=80=9Ccharter compliant=E2=80=9D right now. There is no = TxAuth protocol. Both XYZ and XAuth are inputs into the discussion, and = the charter is helping us determine what the rails are for the eventual = TxAuth solution. >>=20 >>> - Support for directed, audience-restricted access tokens >>=20 >> This looks good on first sight but it misses the important point that = the AS on behalf of the RS can decide to issue such tokens. >>=20 >> The AS decides what tokens it will issue to a Client already in OAuth = 2.0, so it is in scope. What am I missing? >=20 > You are missing the dependency on the RS. RS1 wants a JWT with certain = claims and RS2 wants a handle to be queried via introspection (because = of immediate revocation support). How is that covered in OAuth 2?=20 This would need to be covered by the on boarding process between the RS = and AS, which OAuth doesn=E2=80=99t have. UMA has a version of it, but = even then it doesn=E2=80=99t specify to the level of token format. I = think it would be an interesting exercise and part of the provision to = have the AS and RS communicate what tokens are for. =E2=80=94 Justin= --Apple-Mail=_DC573399-240C-4209-B432-B3715863F535 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
A couple key responses:

I = consider "fine grained specification of access" to include many = different ways to be fine grained. 

That=E2=80=99s your interpretation, I would have interpreted = =E2=80=9CApproval of access to multiple resources and APIs in a single = interaction=E2=80=9D accordingly. But it seems to me, other people = interpret that differently. 

I = interpreted it this way as well, and that was my intent with the = charter. We don=E2=80=99t wan to constrain the style of APIs that we = protect with TxAuth to be =E2=80=9Cfine grained=E2=80=9D in a particular = way. Splitting the =E2=80=9Cgrains=E2=80=9D based on different RS=E2=80=99= s is one important way to do it.



We added multiple = tokens to clarify

It =E2=80=99s multiple access token in the request, not the = response. 

I=E2=80=99m = fine with changing that text to =E2=80=9Crequest and response=E2=80=9D = as stated on the other thread, so I hope this isn=E2=80=99t the sticking = point. 

Extending that to multiple tokens, and multiple resources to = me implies the AS can still decide what each token can do.

=E2=80=9Cimplies=E2=80=9D is the key word here. I agree with = you. Do other WG members as well?

The AS always decides what the token can do =E2=80=94= at least to the point that the RS interprets it and then the RS finally = decides what the token can actually do by enforcing it. It=E2=80=99s a = pseudo PEP-PDP split all over again.


I=E2=80= =99m looking for a way to let the RS (with the AS acting on its behalf) = influence the token allocation and with that the token design. As I have = explained several times, the token format & content is part of the = AS to RS interface and the current charter limits this to a single = design option: handles + token introspection, at least in multi RS = scenarios. 

I don't think that is the case at all. 

XYZ is limited this way right now and I assume it=E2=80=99s = considered to be charter compliant as well. For me this means, we are in = an area governed by the decisions of the editors of the individual = drafts. 

Nothing is = =E2=80=9Ccharter compliant=E2=80=9D right now. There is no TxAuth = protocol. Both XYZ and XAuth are inputs into the discussion, and the = charter is helping us determine what the rails are for the eventual = TxAuth solution.



- Support for directed, audience-restricted = access tokens

This looks good = on first sight but it misses the important point that the AS on behalf = of the RS can decide to issue such tokens.

The AS decides what tokens it will issue to a Client already = in OAuth 2.0, so it is in scope. What am I missing?

You are missing the dependency on the RS. RS1 wants a JWT = with certain claims and RS2 wants a handle to be queried via = introspection (because of immediate revocation support). How is that = covered in OAuth 2? 

This would = need to be covered by the on boarding process between the RS and AS, = which OAuth doesn=E2=80=99t have. UMA has a version of it, but even then = it doesn=E2=80=99t specify to the level of token format. I think it = would be an interesting exercise and part of the provision to have the = AS and RS communicate what tokens are for.


 =E2=80=94 = Justin
= --Apple-Mail=_DC573399-240C-4209-B432-B3715863F535-- From nobody Sun Mar 22 16:15:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92B13A0143 for ; Sun, 22 Mar 2020 16:15:27 -0700 (PDT) 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 fsJrJs-Cvax5 for ; Sun, 22 Mar 2020 16:15:26 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 362963A0128 for ; Sun, 22 Mar 2020 16:15:26 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id 19so12518304ljj.7 for ; Sun, 22 Mar 2020 16:15:26 -0700 (PDT) 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=VR/FP9lSxj6WAFL11hQIPugZ7/6Gdf3wAH7SgjYAcyY=; b=L+Fsd6Pjq6U+NeVSNsjhDAe9XZq1rOjo6McKg5+QqWHDf9PKqDdUZjwIiAwI9JlM7M nWcA1kNqa/v1bS7Ev8/neNyC3sQ4VOlPV5lV/ecJA3asbBnjOziAhn77NPo2krVtI4Lu AGmlcPKluKX8vUxCj0Gec8OGz0u0XvIBTnkaRVB6l7wCJiBrTM0lm0zzMUschO0H1n50 fbxd667MGSwxO/YlA78mOD9HPVm03HX3kvFCqj+eWSbOvxUABngAWiO3Ei/yS5aGYlX9 k9MxEOTXMVDU8IwPpRuMwgE8Wnu7idJpZ4Lfe8gS140qNGdkyjFkY9X4PqtEx6zXIaxX IFOQ== 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=VR/FP9lSxj6WAFL11hQIPugZ7/6Gdf3wAH7SgjYAcyY=; b=KFSAv/jNoonZNoWnVxlvKj/RK6OvfmhTnLB4hggu4nxdhiWX0cdjZs24Ge51xEi93C gmziAEmshtkCQ/JBSVbXBVDgv4dUXmA+pT20noHpBZFynY2S5Nxh/ljawDOnNNo1N4t8 +hCxNxHVhjvz7z7xqFtBaYtBT1+AGaqI0jKg1htukxr4fUKJ3rihGo2A2LlbgBC5UngH IUGzI1+lDs+ecoGSbozf6zpZF+8B77UTIJ3Q70yTjkVHW5s4McirT2TllrB+3/Vx+nL3 t/e71BunFl7B50BPpI9PNwez7BLopIXZO0eYqfIsnU8mI3X3zZeovB2qqVnu73wzHqM1 nq3g== X-Gm-Message-State: ANhLgQ0SxTiBOyFGnh2PIMaHP74MkzMfvqU8eKlnh7yNbEMx3wJVvozW zdZ5gIUEdZ16ZXbPXP7jHNjkixqkOzAoX31bd3kUStIs X-Google-Smtp-Source: ADFU+vv2c2QNYbhbuV7Al22N3JSodgqmBP0h2qRK8DXW1+VK/b3DDQO6xI8DQsjbjOmHq3PmjPmZuXowdDvUE0BBToo= X-Received: by 2002:a2e:9b8e:: with SMTP id z14mr2257725lji.150.1584918923883; Sun, 22 Mar 2020 16:15:23 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Sun, 22 Mar 2020 16:14:57 -0700 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000074b75705a179b107" Archived-At: Subject: [Txauth] note taker needed for meeting tomorrow!!! X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2020 23:15:29 -0000 --00000000000074b75705a179b107 Content-Type: text/plain; charset="UTF-8" Hey List We need a note taker for the meeting tomorrow. A volunteer prior to starting the meeting will let us spend more time on our topics! /Dick --00000000000074b75705a179b107 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey List

We need a note taker for the m= eeting tomorrow. A volunteer prior to starting=C2=A0the meeting will let us= spend more time on our topics!

/Dick
--00000000000074b75705a179b107-- From nobody Sun Mar 22 20:41:04 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45C63A011D for ; Sun, 22 Mar 2020 20:41:00 -0700 (PDT) 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, HTML_MESSAGE=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=prPQjom2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mdIGIMnB 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 X4WbeC8uqfEb for ; Sun, 22 Mar 2020 20:40:59 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D55E3A00E1 for ; Sun, 22 Mar 2020 20:40:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7A65C470 for ; Sun, 22 Mar 2020 23:40:58 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sun, 22 Mar 2020 23:40:58 -0400 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:subject:content-type; s=fm2; bh=eWGGVsq J70tmFrSx6ej4C715greIOCuzC7FoWHEtLcw=; b=prPQjom244A89//zugXJKhq QSjGYRi8A4+bjb41Fb6Eyi5/udXPL6Vi0am+jRvlLqDs/BL6iP4x9MJlXLu3Mps/ yOBoxZCaGvxFyBtFjzKLsT79d/5Hv3ASQ8qmV/vgG9cMSj7UmqvBbUkLakBKBlVx nNb1u09zm6TIN4O8FvB72fYACR5O3ujYrwD03IXcGe8BgLfcxN87VN4HOB8sni7E VAE7d5J+7in498pAbjBM56eULNqw48CDT6NQCn10fo7XCZ71rp9an5Cxlk/7cTxC uSZuqcnmvpQHfXB1XX794uxJbqv8m5KN3K8bsf/2mL5EJRVhQlyMfCLMRNZcAWw= = 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=eWGGVs qJ70tmFrSx6ej4C715greIOCuzC7FoWHEtLcw=; b=mdIGIMnBqJ/vfS0DGGFUyi asPb1B1facfaXICj29i4H0ZJyH94SMjw2IF0Mymh2h8QK1lXqvOuhShnsiARGV3c Ns6cuAOHt6nu85tjxFdR4XLz+TmgOqWRb8/QlfvdKp/S/yMOeSm0p7J8i1oOrmLV rIWWgHdK98VL2w3GmGGFIstLJpntq6ElIN86XBQQAno63qH5NtVrDpbhmOAhz2V3 sPzrj+45XPc6wkHK9U0DRpubAkigCH9NAyfavriitL7DhQEs6K47q4RlrnUWC/Uc Tytb0L2SoAFDW63hhSr1KW0mqYjkF5cOhsf2/Uy6OU9nyx+bjXmq0lgokGob0wQA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegjedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhn ghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D3672180090; Sun, 22 Mar 2020 23:40:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 23 Mar 2020 14:41:14 +1100 From: "Bron Gondwana" To: txauth@ietf.org Content-Type: multipart/alternative; boundary=ea2aa29848104172801d7a05921b48ad Archived-At: Subject: Re: [Txauth] note taker needed for meeting tomorrow!!! X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 03:41:02 -0000 --ea2aa29848104172801d7a05921b48ad Content-Type: text/plain Sure, why not - I'm already taking notes for GenDispatch as well! Bron. On Mon, Mar 23, 2020, at 10:14, Dick Hardt wrote: > Hey List > > We need a note taker for the meeting tomorrow. A volunteer prior to starting the meeting will let us spend more time on our topics! > > /Dick > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --ea2aa29848104172801d7a05921b48ad Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Sure, why not - I'm already taking notes for GenDispatch a= s well!

Bron.
On Mon, Mar 23, 2020, at 10:14, Dick Hardt wrote:
=
Hey List

We need a note taker for the meeting tomorrow. A= volunteer prior to starting the meeting will let us spend more tim= e on our topics!

/Dick
= -- 
Txauth mailing list
Txauth@ietf.org=
https://www.ietf.org/mailman/listinfo/txauth


--
  Bron Gondwana, CEO, Fa= stmail Pty Ltd
  brong@fastmailteam.com


--ea2aa29848104172801d7a05921b48ad-- From nobody Sun Mar 22 20:46:48 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729C23A02BB for ; Sun, 22 Mar 2020 20:46:46 -0700 (PDT) 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 8oAONQqgQDOg for ; Sun, 22 Mar 2020 20:46:45 -0700 (PDT) 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 B93883A0140 for ; Sun, 22 Mar 2020 20:46:44 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id g12so12965252ljj.3 for ; Sun, 22 Mar 2020 20:46:44 -0700 (PDT) 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=KflebbjwPeHErQi+nHagYNIVatMh728JL8hpAsbZd3w=; b=onuyh960jWObv1KzGSW5IunWrc/8dIiRfgJp389IPUQK1Y3tPZUp30+MgW1zoflR6a aJ2qZWE+FMAz9Zob0Lb5kGf/nPMIBInZE942Jzi6MT9KHhSjD1BxuPsve0JqurItr+Yj 7SDobD+JieOgGO/C4NmuypzG0YgIvPj6EjVHBnuF2NEmJwpTd/V8JTjKWUrXrPefFQoZ BwcSIkXLBLe9AbDxwBTW6+7J7ruSv7Fmb2cdMq1l8E9quPNI3D6Ob+nA7YQaXx0fKyqH bmWn2ZRQ1KZzdcYXOaFm19eyaAQc8zYvkeh0UKtwpRaYryLUapujQdMi+IKiYAnc3cUi fWPQ== 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=KflebbjwPeHErQi+nHagYNIVatMh728JL8hpAsbZd3w=; b=szOTw5CsvbMcpdY00AQlmbzbDtuagAEMrGxlQ9S/C/eJcW0NuyO+Epew9WciIxR8ES qNLLdd544zdOTtYK00SmQCCXtMId/UurDeVY47QRm6KJUtNQ0AZJhlKGYyu/Ah9VtXnn 0HduKLW1sn4reDLUuMOaKtW+IyQDwtERtyKR+YXzwLq56S4qzcKZyoL7VRh6bqkt/Ojl z10Tkw3PsTxJ0lEqwDgbemZwvUVFJSXMo1DmZTwfDteCyYtxl2H0pphuNhFsyMQ2qx+8 s+ud3j07VwnzeZfgDiK5PnYYJVAB3JUYecw14sladCKNSMMmNrcIaB1HJLChlwAlXYXa e3mA== X-Gm-Message-State: ANhLgQ0ym3JCoqM1+bBkYmx6xZmj5Oo8v/pjobfxsnGb+HM+F68YouXZ 2Tao9X0T0MV1KrvaC52is8avwBZXKZZw2A47gifV2ckp X-Google-Smtp-Source: ADFU+vuYhvZnkquWPpr09ss4Fa5iF8Q+uNhHk94SpcS/7WpcP6RuherZpHVqDmu2C2zOo9tkid6QLwmV+DOQsSBcdOc= X-Received: by 2002:a2e:a548:: with SMTP id e8mr2757105ljn.151.1584935202692; Sun, 22 Mar 2020 20:46:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 22 Mar 2020 20:46:31 -0700 Message-ID: To: Bron Gondwana Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000bfa13a05a17d7bfc" Archived-At: Subject: Re: [Txauth] note taker needed for meeting tomorrow!!! X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 03:46:47 -0000 --000000000000bfa13a05a17d7bfc Content-Type: text/plain; charset="UTF-8" Thanks! On Sun, Mar 22, 2020 at 8:41 PM Bron Gondwana wrote: > Sure, why not - I'm already taking notes for GenDispatch as well! > > Bron. > > On Mon, Mar 23, 2020, at 10:14, Dick Hardt wrote: > > Hey List > > We need a note taker for the meeting tomorrow. A volunteer prior to > starting the meeting will let us spend more time on our topics! > > /Dick > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000bfa13a05a17d7bfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks!

On Sun, Mar 22, 2020 at 8:41 PM Br= on Gondwana <brong@fastmailtea= m.com> wrote:
Sure, why not - I'm already taking notes= for GenDispatch as well!

Bron.

On Mon, Mar 23, 2020, at 10:14, Dick Har= dt wrote:
Hey List

=
We need a note taker for the meeting tomorrow. A volunteer prior to st= arting=C2=A0the meeting will let us spend more time on our topics!

/Dick
--=C2=A0
Txauth mailing list


--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd
=C2=A0 brong= @fastmailteam.com



--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000bfa13a05a17d7bfc-- From nobody Mon Mar 23 08:09:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD63A07AC for ; Mon, 23 Mar 2020 08:09:04 -0700 (PDT) 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, FREEMAIL_FROM=0.001, 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 (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 fNaA5VLCfPnK for ; Mon, 23 Mar 2020 08:08:57 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 CBA6F3A0783 for ; Mon, 23 Mar 2020 08:08:56 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id t7so12836247wrw.12 for ; Mon, 23 Mar 2020 08:08:56 -0700 (PDT) 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=f9yL7Bw2d+2WKIHCIzU6I8RC8H/oB/kGfRtPK92i/pk=; b=fyi5YIOVbXCg4SZTm9iAHDFQSXFfwwJz/Km2GHTKizWXDD0sBaUX4SmJpn8KJVgKyT Ch2wHEksU+zGTYlXRoTO4tKaL/7hPwo0mtMmxB8ZW1Jnqmd8AIf1JvVk+h4JI0iSgFwn Uu6LewFDYix34SSptMg39y1JSBlc1cRe+Im5jur6bZIG7NqPr5WKQiDvvcqoBJbfvPg7 PYNRWs1BToEzzEMoNyQjWzXSIY442QqOTb8U/3FzEC8tv1yHKQ2Uh0XAwcnXpZHglaaX Ykcpf7V93PJVAsFmFOaOnZ4uCsI3tvLaePAeSvq6DLrEhoxeVLCyVSmIN97qM3n7q4Vh CH1w== 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=f9yL7Bw2d+2WKIHCIzU6I8RC8H/oB/kGfRtPK92i/pk=; b=o6YDpxUGAmBvZjcoa89G9R4JjormV2Rw8BzXZC6ALUgxLsRZFvdv9BwjuEZy9rGdpH 67+acKTiZwqd7n9PZctQ8eIs2w/WCLM3TGJs69fXLcj6Cl/jPdJ0MBiPz762cNlUuPZe Hyinh8ScLGObm6qJ2DZ4xfn7y2U2kFmjqEKesYnR0jzjXySVfG+pT3Texv0HP4XGgdvW /lfLW33dGaVofCJEFzvrB4s2LahqeBqKxe3ESIKy6S+bEYFwa4KCkN2xmnONL9+i4yWQ 3wTTBsszMdqRomvTBdWr3nep3tAyz7kwTvvJJajfDCr7MZsT1c8QD4v1xYm3zx9FssWG prrA== X-Gm-Message-State: ANhLgQ2h5pBcPo+UX/QZi1yVyLQdL2vAsVfiWuCVRNyzLQu0QyiKKvIp 3N7PSmy4FAGEZN/GVR5iRkR2jqmsHPB3zemQW74= X-Google-Smtp-Source: ADFU+vsKW0p7Xp9nGSqh3vVhsFolt0m/YcEMdHnUtI3Ob5lxban54Nm/ZlVaBQQVIwOvvjXks46LvFvKHn5E33fZ7Tg= X-Received: by 2002:adf:e8c1:: with SMTP id k1mr1059392wrn.381.1584976134884; Mon, 23 Mar 2020 08:08:54 -0700 (PDT) MIME-Version: 1.0 References: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> In-Reply-To: From: Nat Sakimura Date: Tue, 24 Mar 2020 00:08:42 +0900 Message-ID: To: Dick Hardt Cc: Justin Richer , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007f539405a18703e5" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 15:09:05 -0000 --0000000000007f539405a18703e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Dick. Just one point on the "Architecture" document. Perhaps "Architecture" was a way too loaded word. What I wanted to say was that documenting in a way or another who/what are the stakeholders/actors and what are the requirements laid out by them. For example, in OAuth 2.0 context, we tend to collapse Authentication Server and Authorization Server in one, but in the federated authorization case, clearly delineating them helps a lot. This can be captured in a use-case document or in a more abstract document and should have impacts on the actual protocol to be written. Another example is to list and consider stakeholder concerns. For example, in OAuth 2.0, we have not been explicitly considering the needs of the who undertakes the monitoring for example. They may not end up in the protocol that we will be writing, but if there is something that protocol can help their work, we should perhaps consider them. However, if we did not document them at all, it would be difficult to consider them systematically during the protocol design. It could even be just a wiki page, but I thought that kind of document, whatever it is called, is a useful side document to have handy. On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt wrote: > Nat: thanks for chiming in. Useful insights as always! > > Vittorio: I'll reinterpret your statement about "marketing" the work, to > be that we should solve real problems that people don't have solutions fo= r > today. > > *AS<->RS relationship* > > TL;DR: I think the charter misses the mark in the AS<->RS relationship > being in scope and we should expand it. > > In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast to > OAuth 1.0, but the interactions / communication between the AS and the RS > were out of scope, as the uses cases at the time had the AS and RS operat= ed > by the same entity. New use cases have a weaker coupling between the AS a= nd > RS, and to enable interop, extensions have been written for Token > Introspection, and JWT Profile for OAuth 2.0 Access Tokens . > > The TxAuth charter includes introspection: > > > - Query of token rights by resource servers > > > -- but does not include the common design pattern where the RS can > directly interpret the token. > > Here is proposed updated text to the line above to be broader in scope > than just a query: > > - communication of token attributes between the authorization server and > resource server > > > > *Architecture and Use Case documents* > > TL;DR: Yes to use case doc, no to architecture doc. > > I agree with Justin that an architecture document is unlikely to prove > useful long term. I disagree with him on the use cases. I don't think the > use cases need to be exhaustive, but example use cases helps everyone > understand everyone else's primary use cases. If your use case is not > similar to others, then you should write it up and the WG can decide if i= t > is in scope or not. If it is, it gets added to the use case document. I > would consider this a living document while working on the core protocol. > It would NOT be a use case document that scopes the WG work. The charter > does that. It would be a companion document to the core protocol. I > strongly think a use case document resolves many of the miscommunications > that happen where people are talking past each other, because they don't > understand each other's use case. > > *Reusing Existing Technology* > > TL;DR: we should be reusing existing specifications where ever possible. > > Reading between the lines, I think the concern around identity may be tha= t > the TxAuth charter implies that the WG is going to create > yet-another-identity-representation and ignore all the previous efforts. = I > think creating yet-another-identity-representation to solve use cases tha= t > are already solved with existing representations would be misguided effor= t. > My own interest in TxAuth is being able to use one protocol to request an= d > receive any existing and future identity representation. One of my > motivations for writing the XAuth document was to show how different > representations could be requested and received, as this was missing in > XYZ. If a use case requires a new representation, then perhaps TxAuth ma= y > be a place for that work to happen, but I think it is more likely to happ= en > in other forums. > > It is not clear to me how, or if, reusing existing technology fits into > the charter, but I do strongly think it should be a tenet of the WG. > > On a related note, I also strongly think that the existing OAuth 2.0 > scopes should be easily used in requests and responses. XAuth shows an > example of how that can be done. > > /Dick > > > > > On Fri, Mar 20, 2020 at 6:39 AM Justin Richer wrote: > >> I agree with a lot of that argument. Let me see if I can more clearly >> restate what I was trying to say earlier in this thread: the relationshi= ps >> between the different parties are separable and depend on the kind of >> deployments and use cases that are being addressed by people. So in an >> OAuth/OIDC-style world, we=E2=80=99ve got three components (ignoring peo= ple), and >> three relationships between them: >> >> C<->AS >> >> C<->RS >> >> AS<->RS >> >> For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, = =E2=80=9Chow to use a >> token=E2=80=9D, and =E2=80=9Chow to interpret a token=E2=80=9D. For auth= entication, it=E2=80=99s >> additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, =E2= =80=9Chow do I ask for a >> profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80= =9D. I still believe this >> is a good separation of concerns. The client doesn=E2=80=99t need to kno= w what=E2=80=99s in >> the access token, or if it=E2=80=99s a reference or self-contained, or r= eally >> concern itself at all with what the RS does with it. Are there overlaps? >> Certainly =E2=80=94 the client needs to know how to ask for a token that= the RS >> will accept for what the client is going to do, and to do that the clien= t >> needs to be able to describe what it wants to do in a way that the AS ca= n >> interpret and map to a set of rights that the RS will eventually interpr= et. >> >> I believe the proposed charter already covers this split with the >> following items: >> >> - Fine-grained specification of access >> - Approval of access to multiple resources and APIs in a single >> interaction >> - Separation between the party authorizing access and the party operatin= g >> the client requesting access >> - Revocation of active tokens >> - Query of token rights by resource servers >> >> It=E2=80=99s the combination of the rich request and the lifecycle manag= ement >> that puts the AS and RS in scope. I think things like declaring a single >> token format are absolutely out =E2=80=94 if you want to use JWT, or CWT= , or >> UUID=E2=80=99s, that=E2=80=99s all just fine. However, something that I = think is in scope >> is defining a structure for what a token represents. And I think that if= we >> can do that in this WG in a general way, then that=E2=80=99s useful. Bec= ause then >> that structure can be represented by mapping to a token format or an >> introspection response or a database entry. I think Nat=E2=80=99s commen= ts on ABAC >> are important: we are going to need a place to put those attributes. >> Whether they=E2=80=99re communicated to the RS through the token itself = or through >> some other channel is, I strongly believe, a matter of deployment choice= . >> >> So, what can the charter say to make this more clear? >> >> All that said, I=E2=80=99m against having an architecture document as a = working >> group output. In my experience, when a WG puts its effort into a formal >> architecture doc *as a deliverable*, there is a lot of conjectural >> energy that goes into what might be a good idea, and then not all of it >> works out when you try to hammer the details of making that architecture >> into a real engineered thing.You end up baking in assumptions and >> abstractions that don=E2=80=99t make sense anymore, and then trying to e= ngineer >> solutions around those when they don=E2=80=99t fit right. If the archite= cture can=E2=80=99t >> change in light of new information, which is the case with an RFC, then = it >> becomes a shackle instead of a scaffold. But a malleable document that t= he >> group can use as a guide while engineering the actual parts =E2=80=94 ye= s, that >> makes sense. The architecture can be refactored and changed as decisions >> are made and things come into focus. I feel the same about use case >> documents as formal artifacts. >> >> Thanks, Nat. >> =E2=80=94 Justin >> >> On Mar 20, 2020, at 2:19 AM, Nat Sakimura wrote: >> >> I thought I should keep my mouth shut as anything I say may be deemed >> biased as my other hat is the chairman of OIDF, but here is my 2c. >> >> As Torsten indicated, there is much to be desired to standardize the AS = - >> RS communication patterns. You may say that the charter includes it, but= I >> cannot read it out of the charter just like Torsten could not. As a new >> protocol, it would be good to include it. >> >> In this respect, I am not sure if we should start off from OAuth 2.0 and >> OIDC model. If we are creating a new protocol, I feel that we should >> architect is more fully. Not mentioning AS - RS relationship to me feels >> like an indication of this failure. For that matter, I feel that the fir= st >> output of the group should be an architecture document that takes the >> concerns from all the relevant stakeholders/actors in. >> >> We should also be cognizant of the access control models like ABAC. For >> that, decoupling of identity (=3D set of claims) assertion and authoriza= tion >> is a necessity. We could optimize it but the base case should take care = of >> it. (In this respect, I am feeling that OIDC has perhaps over-optimized.= ) >> So, I feel that at least as the first step, TxAuth should concentre on t= he >> Access Control. If I were to go one step further, it should be modelled = so >> that it can consume various identity assertions (authenticated identity = in >> ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable >> Credentials, X.509 certificates (such as in eIDAS and Japanese National = ID >> scheme) etc. We are not going to get to a unified identity world anytim= e >> soon. >> >> Cheers, >> >> Nat Sakimura >> >> >> On Wed, Mar 18, 2020 at 7:06 AM Mike Jones > 40microsoft.com@dmarc.ietf.org> wrote: >> >>> I believe it's significant that four people have expressed concerns wit= h >>> including digital identity in the charter (the only concerns voiced as = far >>> as I can tell). At a minimum, I believe that that warrants making the >>> inclusion or exclusion of digital identity a discussion topic during th= e >>> upcoming virtual BoF, before adopting any charter. >>> >>> It would be my proposal to initially charter without digital identity >>> and see how far we get with our energies intentionally focused in that >>> way. If the working group decides to recharter to include digital >>> identity, that can always happen later, after the authorization-focused >>> work has matured, and once there's a clear case to actually do so. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Justin Richer >>> Sent: Tuesday, March 17, 2020 2:20 PM >>> To: Mike Jones >>> Cc: Yaron Sheffer ; Torsten Lodderstedt < >>> torsten@lodderstedt.net>; txauth@ietf.org >>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >>> >>> While I understand the concerns around identity in the charter, and I >>> had initially not included it, I was convinced that the kind of identit= y >>> protocol that we=E2=80=99re looking at here is a minor addition to the >>> authorization and delegation end of things. >>> >>> As you know, much of what=E2=80=99s in OIDC is there to fix problems wi= th OAuth >>> 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those prob= lems >>> internally, then OIDC would be much, much simpler and smaller. We=E2=80= =99re now >>> starting at a base where those problems don=E2=80=99t exist, but we don= =E2=80=99t yet know >>> what other problems there might be. >>> >>> The market has shown us that the most common application of OAuth 2 is >>> far and away access to identity information along side access to an API= . I >>> think we need to pay attention to that and not make this separate just >>> because we did it that way before. And some of the proposed innovations= , >>> including getting and sending VC=E2=80=99s, are all about identity. >>> >>> Furthermore, this charter does not specify the document and >>> specification structure of the components, nor does it specify the >>> publication order or timing of any documents. I personally think that t= he >>> identity layer should be separable to an extent, to the point of publis= hing >>> that layer in its own spec alongside the core authorization delegation >>> system. However, that does not mean that it should be developed elsewhe= re. >>> >>> If there is better language to tighten the aspects of an identity >>> protocol that we will explicitly cover, then I would welcome you to sug= gest >>> an amended text to the charter. However, I believe there is enough inte= rest >>> within the community to work on identity in the context of this protoco= l, >>> including a large number of people being OK with it in the charter, tha= t it >>> would not be a reasonable thing to remove it. >>> >>> =E2=80=94 Justin >>> >>> > On Mar 17, 2020, at 1:12 PM, Mike Jones >> 40microsoft.com@dmarc.ietf.org> wrote: >>> > >>> > 1. Do you support the charter text provided at the end of this >>> email? Or do you have major objections, blocking concerns or feedback = (if >>> so please elaborate)? >>> > >>> > I share the concerns about including identity in the charter that wer= e >>> expressed by Torsten and agreed with by David Skaife. I'll note that K= im >>> Cameron previously expressed concerns about including identity in his >>> earlier charter critique at >>> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Cah= E/ >>> . >>> > >>> > I'm fine with refactoring the authorization protocol. But identity >>> should be decoupled from the TxAuth work to focus its scope on areas wh= ere >>> innovation is being proposed. Digital identity can always be added as = a >>> layer if needed, just as OpenID Connect layered identity onto OAuth 2.0= . >>> > >>> > Please revise the charter to remove digital identity from the scope o= f >>> the work. >>> > >>> > 2. Are you willing to author or participate in the development of th= e >>> drafts of this WG? >>> > >>> > Yes >>> > >>> > 3. Are you willing to help review the drafts of this WG? >>> > >>> > Yes >>> > >>> > 4. Are you interested in implementing drafts of this WG? >>> > >>> > Not at this time. >>> > >>> > -- Mike >>> > >>> > -----Original Message----- >>> > From: Txauth On Behalf Of Torsten >>> Lodderstedt >>> > Sent: Saturday, March 7, 2020 7:18 AM >>> > To: Yaron Sheffer >>> > Cc: txauth@ietf.org >>> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth = WG >>> > >>> > Hi, >>> > >>> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = : >>> >> >>> >> =EF=BB=BFHi Everyone, >>> >> >>> >> It appears that momentum is forming around the proposed formation of >>> a TxAuth working group. We=E2=80=99d like to more formally gauge inter= est in >>> proceeding with this work. Please do so by responding to the following >>> questions: >>> >> >>> >> 1. Do you support the charter text provided at the end of this >>> email? Or do you have major objections, blocking concerns or feedback = (if >>> so please elaborate)? >>> > >>> > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerne= d the scope of >>> the charter is too broad, e.g. identify alone is a huge topic. >>> > >>> > We need to keep an eye on this aspect in order to make sure, the grou= p >>> is able to work effectively and the specs we will be producing are as >>> simple as possible and foster interoperability. >>> > >>> >> >>> >> 2. Are you willing to author or participate in the development of >>> the drafts of this WG? >>> > >>> > yes >>> > >>> >> >>> >> 3. Are you willing to help review the drafts of this WG? >>> > >>> > yes >>> > >>> >> >>> >> 4. Are you interested in implementing drafts of this WG? >>> > >>> > yes >>> > >>> > best regards, >>> > Torsten. >>> > >>> >> >>> >> The call will run for two weeks, until March 21. If you think that >>> the charter should be amended In a significant way, please reply on a >>> separate thread. >>> >> >>> >> The feedback provided here will help the IESG come to a decision on >>> the formation of a new WG. Given the constraints of the chartering proc= ess, >>> regardless of the outcome of this consensus call, we will be meeting in >>> Vancouver as a BoF. >>> >> >>> >> Thanks, >>> >> Yaron and Dick >>> >> >>> >> --- Charter Text Follows --- >>> >> >>> >> This group is chartered to develop a fine-grained delegation protoco= l >>> for authorization, identity, and API access. This protocol will allow a= n >>> authorizing party to delegate access to client software through an >>> authorization server. It will expand upon the uses cases currently >>> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth >>> 2.0) to support authorizations scoped as narrowly as a single transacti= on, >>> provide a clear framework for interaction among all parties involved in= the >>> protocol flow, and remove unnecessary dependence on a browser or user-a= gent >>> for coordinating interactions. >>> >> >>> >> The delegation process will be acted upon by multiple parties in the >>> protocol, each performing a specific role. The protocol will decouple t= he >>> interaction channels, such as the end user=E2=80=99s browser, from the = delegation >>> channel, which happens directly between the client and the authorizatio= n >>> server (in contrast with OAuth 2.0 which is initiated by the client >>> redirecting the user=E2=80=99s browser). The client and AS will involve= a user to >>> make an authorization decision as necessary through interaction mechani= sms >>> indicated by the protocol. This decoupling avoids many of the security >>> concerns and technical challenges of OAuth 2.0 and provides a non-invas= ive >>> path for supporting future types of clients and interaction channels. >>> >> >>> >> Additionally, the delegation process will allow for: >>> >> >>> >> - Fine-grained specification of access >>> >> - Approval of AS attestation to identity claims >>> >> - Approval of access to multiple resources and APIs in a single >>> interaction >>> >> - Separation between the party authorizing access and the party >>> operating the client requesting access >>> >> - A variety of client applications, including Web, mobile, >>> single-page, and interaction-constrained applications >>> >> >>> >> The group will define extension points for this protocol to allow fo= r >>> flexibility in areas including: >>> >> >>> >> - Cryptographic agility for keys, message signatures, and proof of >>> possession >>> >> - User interaction mechanisms including web and non-web methods >>> >> - Mechanisms for conveying user, software, organization, and other >>> pieces of information used in authorization decisions >>> >> - Mechanisms for presenting tokens to resource servers and binding >>> resource requests to tokens and associated cryptographic keys >>> >> - Optimized inclusion of additional information through the >>> delegation process (including identity) >>> >> >>> >> Additionally, the group will provide mechanisms for management of th= e >>> protocol lifecycle including: >>> >> >>> >> - Discovery of the authorization server >>> >> - Revocation of active tokens >>> >> - Query of token rights by resource servers >>> >> >>> >> Although the artifacts for this work are not intended or expected to >>> be backwards-compatible with OAuth 2.0 or OpenID Connect, the group wil= l >>> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new >>> protocol where possible. >>> >> >>> >> This group is not chartered to develop extensions to OAuth 2.0, and >>> as such will focus on new technological solutions not necessarily >>> compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 >>> will be developed in the OAuth Working Group, including functionality >>> back-ported from the protocol developed here to OAuth 2.0. >>> >> >>> >> The group is chartered to develop mechanisms for applying >>> cryptographic methods, such as JOSE and COSE, to the delegation process= . >>> This group is not chartered to develop new cryptographic methods. >>> >> >>> >> The initial work will focus on using HTTP for communication between >>> the client and the authorization server, taking advantage of optimizati= on >>> features of HTTP2 and HTTP3 where possible, and will strive to enable >>> simple mapping to other protocols such as COAP when doing so does not >>> conflict with the primary focus. >>> >> >>> >> Milestones to include: >>> >> - Core delegation protocol >>> >> - Key presentation mechanism bindings to the core protocol for TLS, >>> detached HTTP signature, and embedded HTTP signatures >>> >> - Identity and authentication conveyance mechanisms >>> >> - Guidelines for use of protocol extension points >>> >> >>> >> >>> >> -- >>> >> Txauth mailing list >>> >> Txauth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/txauth >>> > -- >>> > Txauth mailing list >>> > Txauth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --0000000000007f539405a18703e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Dick.=C2=A0

Just one point on t= he "Architecture" document. Perhaps "Architecture" was = a way too loaded word.=C2=A0
What I wanted to say was that docume= nting in a way or another who/what are the stakeholders/actors and what are= the requirements laid out by them.=C2=A0

For exam= ple, in OAuth 2.0 context, we tend to collapse Authentication Server and Au= thorization Server in one, but in the federated authorization case, clearly= delineating them helps a lot. This can be captured in a use-case document = or in a more abstract document and should have impacts on the actual protoc= ol to be written.=C2=A0

Another example is to list= and consider stakeholder concerns. For example, in OAuth 2.0, we have not = been explicitly considering the needs of the who undertakes the monitoring = for example. They may not end up in the protocol that we will be writing, b= ut if there is something that protocol can help their work, we should perha= ps consider them. However, if we did not document them at all, it would be = difficult to consider them systematically during the protocol design.=C2=A0=

It could even be just a wiki page, but I thought = that kind of document, whatever it is called, is a useful side document to = have handy.=C2=A0

On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt <dick.hardt@gmail.com> wrote:
<= /div>
Nat: thanks for chiming in. Useful=C2=A0insights as always!

Vittorio: I'll reinterpret your statement about "m= arketing" the work, to be that we should solve real problems that peop= le don't have solutions for today.=C2=A0

AS= <->RS relationship

TL;DR: I think the = charter misses the mark in the AS<->RS relationship being in scope an= d we should expand it.

In OAuth 2.0 (RFC6749)l, the AS and RS = were separate roles in contrast to OAuth 1.0, but the interactions / commun= ication between the AS and the RS were out of scope, as the uses cases at t= he time had the AS and RS operated by the same entity. New use cases have a= weaker coupling between the AS and RS, and to enable interop, extensions h= ave been written for Token Introspection, and JWT Profile for OAuth 2.0 Acc= ess Tokens .=C2=A0

The TxAuth charter includes int= rospection:
=C2=A0
- Query of token rights by res= ource servers=C2=A0

-- but= does not include the common design pattern where the RS can directly inter= pret the token.

Here is proposed updated=C2=A0text= to the line above to be broader in scope than just a query:

=
- communication=C2=A0of token attributes=C2=A0between the = authorization server and resource server
=

Architecture and Use Case docume= nts

TL;DR: Yes to use case doc, no to architec= ture doc.

I agree with Justin that an architecture= =C2=A0document is unlikely to prove useful long term. I disagree with him o= n the use cases. I don't think the use cases need to be exhaustive, but= example use cases helps everyone understand everyone else's primary us= e cases. If your use case is not similar to others, then you should write i= t up and the WG can decide if it is in scope or not. If it is, it gets adde= d to the use case document. I would consider this a living document while w= orking on the core protocol. It would NOT be a use case document that scope= s the WG work. The charter does that. It would be a companion document to t= he core protocol. I strongly think a use case document resolves many of the= miscommunications that happen where people are talking past each other, be= cause they don't understand each other's use case.

Reusing Existing Technology

TL;DR: we should be reusing existing specifications where ever= possible.

Reading between the lines, I think the = concern around identity may be that the TxAuth charter implies that the WG = is going to create yet-another-identity-representation and ignore all the p= revious efforts. I think creating=C2=A0yet-another-identity-representation = to solve use cases that are already solved with existing representations wo= uld be misguided effort. My own interest in TxAuth is being able to use one= protocol to request and receive any existing and future identity represent= ation. One of my motivations for writing the XAuth document was to show how= different representations could be requested and received, as this was mis= sing in XYZ.=C2=A0 If a use case requires a new representation, then perhap= s TxAuth may be a place for that work to happen, but I think it is more lik= ely to happen in other forums.

It is not clear to = me how, or if, reusing existing technology fits into the charter, but I do = strongly think it should be a tenet of the WG.

On a related note, I also strongly think that the existing OAuth 2.0 scop= es should be easily used in requests and responses. XAuth shows an example = of how that can be done.

/Dick=C2=A0



On Fri, Mar 20, 2020 at 6:= 39 AM Justin Richer <jricher@mit.edu> wrote:
I agree with a lot of that argument. Let me see if I = can more clearly restate what I was trying to say earlier in this thread: t= he relationships between the different parties are separable and depend on = the kind of deployments and use cases that are being addressed by people. S= o in an OAuth/OIDC-style world, we=E2=80=99ve got three components (ignorin= g people), and three relationships between them:

C<-&= gt;AS

C<->RS

AS<= ->RS

For authorization, these map to =E2=80=9Ch= ow to get a token=E2=80=9D, =E2=80=9Chow to use a token=E2=80=9D, and =E2= =80=9Chow to interpret a token=E2=80=9D. For authentication, it=E2=80=99s a= dditionally =E2=80=9Chow do I get the authentication info=E2=80=9D, =E2=80= =9Chow do I ask for a profile=E2=80=9D, and =E2=80=9Chow do I know whose pr= ofile this is=E2=80=9D. I still believe this is a good separation of concer= ns. The client doesn=E2=80=99t need to know what=E2=80=99s in the access to= ken, or if it=E2=80=99s a reference or self-contained, or really concern it= self at all with what the RS does with it. Are there overlaps? Certainly = =E2=80=94 the client needs to know how to ask for a token that the RS will = accept for what the client is going to do, and to do that the client needs = to be able to describe what it wants to do in a way that the AS can interpr= et and map to a set of rights that the RS will eventually interpret.=C2=A0<= /div>

I believe the proposed charter already covers this= split with the following items:

- Fine-grained sp= ecification of access
- Approval of access to multiple resources and API= s in a single interaction
- Separation between the party authorizing acc= ess and the party operating the client requesting access
- Rev= ocation of active tokens
- Query of token rights by resource servers
=

It=E2=80=99s the combination of the rich request = and the lifecycle management that puts the AS and RS in scope. I think thin= gs like declaring a single token format are absolutely out =E2=80=94 if you= want to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just fine. = However, something that I think is in scope is defining a structure for wha= t a token represents. And I think that if we can do that in this WG in a ge= neral way, then that=E2=80=99s useful. Because then that structure can be r= epresented by mapping to a token format or an introspection response or a d= atabase entry. I think Nat=E2=80=99s comments on ABAC are important: we are= going to need a place to put those attributes. Whether they=E2=80=99re com= municated to the RS through the token itself or through some other channel = is, I strongly believe, a matter of deployment choice.

=
So, what can the charter say to make this more clear?

All that said, I=E2=80=99m against having an architecture document= as a working group output. In my experience, when a WG puts its effort int= o a formal architecture doc as a deliverable, there is a lot of conj= ectural energy that goes into what might be a good idea, and then not all o= f it works out when you try to hammer the details of making that architectu= re into a real engineered thing.You end up baking in assumptions and abstra= ctions that don=E2=80=99t make sense anymore, and then trying to engineer s= olutions around those when they don=E2=80=99t fit right. If the architectur= e can=E2=80=99t change in light of new information, which is the case with = an RFC, then it becomes a shackle instead of a scaffold. But a malleable do= cument that the group can use as a guide while engineering the actual parts= =E2=80=94 yes, that makes sense. The architecture can be refactored and ch= anged as decisions are made and things come into focus. I feel the same abo= ut use case documents as formal artifacts.=C2=A0

<= div>Thanks, Nat.
=C2=A0=E2=80=94 Justin

On Mar 20, 2020, at 2:19 AM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

I thought I should keep my mouth=C2= =A0shut as anything I say may be deemed biased as my other hat is the chair= man of OIDF, but here is my 2c.=C2=A0

As Torsten indicat= ed, there is much to be desired to standardize the AS - RS communication pa= tterns. You may say that the charter includes it, but I cannot read it out = of the charter just like Torsten could not. As a new protocol, it would be = good to include it.=C2=A0

In this respect, I am no= t sure if we should start off from OAuth 2.0 and OIDC model. If we are crea= ting a new protocol, I feel that we should architect is more fully. Not men= tioning AS - RS relationship to me feels like an indication of this failure= . For that matter, I feel that the first output of the group should be an a= rchitecture document that takes the concerns from all the relevant stakehol= ders/actors in.=C2=A0

We should also be cognizant = of the access=C2=A0control models like ABAC. For that, decoupling of identi= ty (=3D set of claims) assertion and authorization is a necessity. We could= optimize it but the base case should take care of it. (In this respect, I = am feeling that OIDC has perhaps over-optimized.) So, I feel that at least = as the first step, TxAuth should concentre on the Access Control. If I were= to go one step further, it should be modelled so that it can consume vario= us identity assertions (authenticated identity in ISO/IEC 24760 speak) incl= uding ID Token, SAML Assertion, DID Verifiable Credentials, X.509 certifica= tes (such as in eIDAS and Japanese National ID scheme)=C2=A0 etc. We are no= t going to get to a unified identity world anytime soon.=C2=A0
Cheers,=C2=A0

Nat Sakimura
=

On Wed, Mar 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microso= ft.com@dmarc.ietf.org> wrote:
I believe it's significant that four people have e= xpressed concerns with including digital identity in the charter (the only = concerns voiced as far as I can tell).=C2=A0 At a minimum, I believe that t= hat warrants making the inclusion or exclusion of digital identity a discus= sion topic during the upcoming virtual BoF, before adopting any charter.
It would be my proposal to initially charter without digital identity and s= ee how far we get with our energies intentionally focused in that way.=C2= =A0 If the working group decides to recharter to include digital identity, = that can always happen later, after the authorization-focused work has matu= red, and once there's a clear case to actually do so.

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

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net&= gt;; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had i= nitially not included it, I was convinced that the kind of identity protoco= l that we=E2=80=99re looking at here is a minor addition to the authorizati= on and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems with O= Auth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now starting at a base where those problems don=E2=80=99t exist, b= ut we don=E2=80=99t yet know what other problems there might be.

The market has shown us that the most common application of OAuth 2 is far = and away access to identity information along side access to an API. I thin= k we need to pay attention to that and not make this separate just because = we did it that way before. And some of the proposed innovations, including = getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and specification s= tructure of the components, nor does it specify the publication order or ti= ming of any documents. I personally think that the identity layer should be= separable to an extent, to the point of publishing that layer in its own s= pec alongside the core authorization delegation system. However, that does = not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol = that we will explicitly cover, then I would welcome you to suggest an amend= ed text to the charter. However, I believe there is enough interest within = the community to work on identity in the context of this protocol, includin= g a large number of people being OK with it in the charter, that it would n= ot be a reasonable thing to remove it.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
>
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?
>
> I share the concerns about including identity in the charter that were= expressed by Torsten and agreed with by David Skaife.=C2=A0 I'll note = that Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Ca= hE/.
>
> I'm fine with refactoring the authorization protocol.=C2=A0 But id= entity should be decoupled from the TxAuth work to focus its scope on areas= where innovation is being proposed.=C2=A0 Digital identity can always be a= dded as a layer if needed, just as OpenID Connect layered identity onto OAu= th 2.0.
>
> Please revise the charter to remove digital identity from the scope of= the work.
>
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?
>
> Yes
>
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.o= rg
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>: >>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed formation = of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in proceeding with this work.=C2=A0 Please do so by responding to t= he following questions:
>>
>> 1.=C2=A0 Do you support the charter text provided at the end of th= is email?=C2=A0 Or do you have major objections, blocking concerns or feedb= ack (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the charter is too broad, e.g. identify alone is a huge topic= .
>
> We need to keep an eye on this aspect in order to make sure, the group= is able to work effectively and the specs we will be producing are as simp= le as possible and foster interoperability.
>
>>
>> 2.=C2=A0 Are you willing to author or participate in the developme= nt of the drafts of this WG?
>
> yes
>
>>
>> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> yes
>
>>
>> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think that= the charter should be amended In a significant way, please reply on a sepa= rate thread.
>>
>> The feedback provided here will help the IESG come to a decision o= n the formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation proto= col for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an author= ization server. It will expand upon the uses cases currently supported by O= Auth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support a= uthorizations scoped as narrowly as a single transaction, provide a clear f= ramework for interaction among all parties involved in the protocol flow, a= nd remove unnecessary dependence on a browser or user-agent for coordinatin= g interactions.
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the de= legation channel, which happens directly between the client and the authori= zation server (in contrast with OAuth 2.0 which is initiated by the client = redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mech= anisms indicated by the protocol. This decoupling avoids many of the securi= ty concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve path for supporting future types of clients and interaction channels. >>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single in= teraction
>> - Separation between the party authorizing access and the party op= erating the client requesting access
>> - A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof of= possession
>> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other= pieces of information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding= resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the delega= tion process (including identity)
>>
>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new= protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported = from the protocol developed here to OAuth 2.0.
>>
>> The group is chartered to develop mechanisms for applying cryptogr= aphic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication betwee= n the client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable simp= le mapping to other protocols such as COAP when doing so does not conflict = with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for TLS= , detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


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

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--0000000000007f539405a18703e5-- From nobody Mon Mar 23 08:13:33 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E312D3A074B for ; Mon, 23 Mar 2020 08:13:29 -0700 (PDT) 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=unavailable 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 qw3VcfZbzESz for ; Mon, 23 Mar 2020 08:13:25 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 1C79D3A07C5 for ; Mon, 23 Mar 2020 08:13:20 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id 19so14955330ljj.7 for ; Mon, 23 Mar 2020 08:13:19 -0700 (PDT) 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=WxAW9aXo1FAFj5gD84S+F0gtVT0fJe6Qt0BFEXRVvAY=; b=g4PmDspqz0KM4jP93o3Gm/jMAeGIaK1SBG4CEl3AJxC4NTnAZvKH56VueuS/eQP6jr IBV9Yl4U6hNiBve3pReyi/K1D4qj9RB2ILMWvRWQ0B3Bb2+3vqlLF1e1WtCIWZHyfvtq 2J3Od5n5/2PJtpnRoivstQyAd2rcu/vIpeqMA+w/4FqqZQSyfPCAlmad45g1xr/JjJG9 /wzXzDo1KL86xlMviifGBgru37XOKwt5d8duowWbR0BIfl5qmXrdMkjha/EaOyHB/HQB 3fCnltfGD/NR7NzXrqN6mz4dZq9+kv1GImwoAzJ+mIbK9ZPk3cz5oQ01PLVqMkQmXfk8 mNdQ== 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=WxAW9aXo1FAFj5gD84S+F0gtVT0fJe6Qt0BFEXRVvAY=; b=GDwm+Lgz56mIzql6pBHd1PiMPNomHAnIuLjoWK188c05dsOaAARXRXLxBRKfF8AtdG A73ILVwszD9w8zBVqIENrwDGpPS70DdGq4OJxeZQFby2FBDt/FO0pWle8naHpryhu7KI wim0qVIvGtFYrnTEvxdvCtMo5atE280KYJz7HGEnQ69KpuC4HFK5/Bjwe9pFXlKgsUjN PUF57/C94kzGQHxYz9LwY3FbhdKjU0JFqF+LxGT28tKEtQvkIJ5TYk57ZWiuwmcwc6Zu hjoHvUobiRqJcdRs3hSQ4BGbBKySxPnK3ylZN4yfrFatx+GmMV6nZdl4CEkUZA5GFywd YujA== X-Gm-Message-State: ANhLgQ1LPHIj0HSaCHrPAO2NJchjAnsvUY857PxGk/XGI+F5oauc2FtP K7GbJLmMHSe2mx15n9K2xqYHVcB92HX3af3WeN4= X-Google-Smtp-Source: ADFU+vtsDT+r4ggtVkS3MM/9acvmG/VH2uuJhwytM0z8tqnMkTfy9jhPC5acFTGiNkDOo92skriWPx6XWUpK3GHKFXs= X-Received: by 2002:a2e:1653:: with SMTP id 19mr14816464ljw.112.1584976397875; Mon, 23 Mar 2020 08:13:17 -0700 (PDT) MIME-Version: 1.0 References: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 23 Mar 2020 08:13:06 -0700 Message-ID: To: Nat Sakimura Cc: Justin Richer , Mike Jones , Torsten Lodderstedt , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002c3e5805a1871306" Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 15:13:30 -0000 --0000000000002c3e5805a1871306 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nat Thanks for the clarification. I think what you describe sounds very useful. I=E2=80=99m hopeful that the group will use GitHub, and what you propose wo= uld be a useful tool there to provide context and ground the protocol work. On Mon, Mar 23, 2020 at 8:08 AM Nat Sakimura wrote: > Thanks, Dick. > > Just one point on the "Architecture" document. Perhaps "Architecture" was > a way too loaded word. > What I wanted to say was that documenting in a way or another who/what ar= e > the stakeholders/actors and what are the requirements laid out by them. > > For example, in OAuth 2.0 context, we tend to collapse Authentication > Server and Authorization Server in one, but in the federated authorizatio= n > case, clearly delineating them helps a lot. This can be captured in a > use-case document or in a more abstract document and should have impacts = on > the actual protocol to be written. > > Another example is to list and consider stakeholder concerns. For example= , > in OAuth 2.0, we have not been explicitly considering the needs of the wh= o > undertakes the monitoring for example. They may not end up in the protoco= l > that we will be writing, but if there is something that protocol can help > their work, we should perhaps consider them. However, if we did not > document them at all, it would be difficult to consider them systematical= ly > during the protocol design. > > It could even be just a wiki page, but I thought that kind of document, > whatever it is called, is a useful side document to have handy. > > On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt wrote: > >> Nat: thanks for chiming in. Useful insights as always! >> >> Vittorio: I'll reinterpret your statement about "marketing" the work, to >> be that we should solve real problems that people don't have solutions f= or >> today. >> >> *AS<->RS relationship* >> >> TL;DR: I think the charter misses the mark in the AS<->RS relationship >> being in scope and we should expand it. >> >> In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast t= o >> OAuth 1.0, but the interactions / communication between the AS and the R= S >> were out of scope, as the uses cases at the time had the AS and RS opera= ted >> by the same entity. New use cases have a weaker coupling between the AS = and >> RS, and to enable interop, extensions have been written for Token >> Introspection, and JWT Profile for OAuth 2.0 Access Tokens . >> >> The TxAuth charter includes introspection: >> >> >> - Query of token rights by resource servers >> >> >> -- but does not include the common design pattern where the RS can >> directly interpret the token. >> >> Here is proposed updated text to the line above to be broader in scope >> than just a query: >> >> - communication of token attributes between the authorization server and >> resource server >> >> >> >> *Architecture and Use Case documents* >> >> TL;DR: Yes to use case doc, no to architecture doc. >> >> I agree with Justin that an architecture document is unlikely to prove >> useful long term. I disagree with him on the use cases. I don't think th= e >> use cases need to be exhaustive, but example use cases helps everyone >> understand everyone else's primary use cases. If your use case is not >> similar to others, then you should write it up and the WG can decide if = it >> is in scope or not. If it is, it gets added to the use case document. I >> would consider this a living document while working on the core protocol= . >> It would NOT be a use case document that scopes the WG work. The charter >> does that. It would be a companion document to the core protocol. I >> strongly think a use case document resolves many of the miscommunication= s >> that happen where people are talking past each other, because they don't >> understand each other's use case. >> >> *Reusing Existing Technology* >> >> TL;DR: we should be reusing existing specifications where ever possible. >> >> Reading between the lines, I think the concern around identity may be >> that the TxAuth charter implies that the WG is going to create >> yet-another-identity-representation and ignore all the previous efforts.= I >> think creating yet-another-identity-representation to solve use cases th= at >> are already solved with existing representations would be misguided effo= rt. >> My own interest in TxAuth is being able to use one protocol to request a= nd >> receive any existing and future identity representation. One of my >> motivations for writing the XAuth document was to show how different >> representations could be requested and received, as this was missing in >> XYZ. If a use case requires a new representation, then perhaps TxAuth m= ay >> be a place for that work to happen, but I think it is more likely to hap= pen >> in other forums. >> >> It is not clear to me how, or if, reusing existing technology fits into >> the charter, but I do strongly think it should be a tenet of the WG. >> >> On a related note, I also strongly think that the existing OAuth 2.0 >> scopes should be easily used in requests and responses. XAuth shows an >> example of how that can be done. >> >> /Dick >> >> >> >> >> On Fri, Mar 20, 2020 at 6:39 AM Justin Richer wrote: >> >>> I agree with a lot of that argument. Let me see if I can more clearly >>> restate what I was trying to say earlier in this thread: the relationsh= ips >>> between the different parties are separable and depend on the kind of >>> deployments and use cases that are being addressed by people. So in an >>> OAuth/OIDC-style world, we=E2=80=99ve got three components (ignoring pe= ople), and >>> three relationships between them: >>> >>> C<->AS >>> >>> C<->RS >>> >>> AS<->RS >>> >>> For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, = =E2=80=9Chow to use a >>> token=E2=80=9D, and =E2=80=9Chow to interpret a token=E2=80=9D. For aut= hentication, it=E2=80=99s >>> additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, = =E2=80=9Chow do I ask for a >>> profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2= =80=9D. I still believe this >>> is a good separation of concerns. The client doesn=E2=80=99t need to kn= ow what=E2=80=99s in >>> the access token, or if it=E2=80=99s a reference or self-contained, or = really >>> concern itself at all with what the RS does with it. Are there overlaps= ? >>> Certainly =E2=80=94 the client needs to know how to ask for a token tha= t the RS >>> will accept for what the client is going to do, and to do that the clie= nt >>> needs to be able to describe what it wants to do in a way that the AS c= an >>> interpret and map to a set of rights that the RS will eventually interp= ret. >>> >>> I believe the proposed charter already covers this split with the >>> following items: >>> >>> - Fine-grained specification of access >>> - Approval of access to multiple resources and APIs in a single >>> interaction >>> - Separation between the party authorizing access and the party >>> operating the client requesting access >>> - Revocation of active tokens >>> - Query of token rights by resource servers >>> >>> It=E2=80=99s the combination of the rich request and the lifecycle mana= gement >>> that puts the AS and RS in scope. I think things like declaring a singl= e >>> token format are absolutely out =E2=80=94 if you want to use JWT, or CW= T, or >>> UUID=E2=80=99s, that=E2=80=99s all just fine. However, something that I= think is in scope >>> is defining a structure for what a token represents. And I think that i= f we >>> can do that in this WG in a general way, then that=E2=80=99s useful. Be= cause then >>> that structure can be represented by mapping to a token format or an >>> introspection response or a database entry. I think Nat=E2=80=99s comme= nts on ABAC >>> are important: we are going to need a place to put those attributes. >>> Whether they=E2=80=99re communicated to the RS through the token itself= or through >>> some other channel is, I strongly believe, a matter of deployment choic= e. >>> >>> So, what can the charter say to make this more clear? >>> >>> All that said, I=E2=80=99m against having an architecture document as a= working >>> group output. In my experience, when a WG puts its effort into a formal >>> architecture doc *as a deliverable*, there is a lot of conjectural >>> energy that goes into what might be a good idea, and then not all of it >>> works out when you try to hammer the details of making that architectur= e >>> into a real engineered thing.You end up baking in assumptions and >>> abstractions that don=E2=80=99t make sense anymore, and then trying to = engineer >>> solutions around those when they don=E2=80=99t fit right. If the archit= ecture can=E2=80=99t >>> change in light of new information, which is the case with an RFC, then= it >>> becomes a shackle instead of a scaffold. But a malleable document that = the >>> group can use as a guide while engineering the actual parts =E2=80=94 y= es, that >>> makes sense. The architecture can be refactored and changed as decision= s >>> are made and things come into focus. I feel the same about use case >>> documents as formal artifacts. >>> >>> Thanks, Nat. >>> =E2=80=94 Justin >>> >>> On Mar 20, 2020, at 2:19 AM, Nat Sakimura wrote: >>> >>> I thought I should keep my mouth shut as anything I say may be deemed >>> biased as my other hat is the chairman of OIDF, but here is my 2c. >>> >>> As Torsten indicated, there is much to be desired to standardize the AS >>> - RS communication patterns. You may say that the charter includes it, = but >>> I cannot read it out of the charter just like Torsten could not. As a n= ew >>> protocol, it would be good to include it. >>> >>> In this respect, I am not sure if we should start off from OAuth 2.0 an= d >>> OIDC model. If we are creating a new protocol, I feel that we should >>> architect is more fully. Not mentioning AS - RS relationship to me feel= s >>> like an indication of this failure. For that matter, I feel that the fi= rst >>> output of the group should be an architecture document that takes the >>> concerns from all the relevant stakeholders/actors in. >>> >>> We should also be cognizant of the access control models like ABAC. For >>> that, decoupling of identity (=3D set of claims) assertion and authoriz= ation >>> is a necessity. We could optimize it but the base case should take care= of >>> it. (In this respect, I am feeling that OIDC has perhaps over-optimized= .) >>> So, I feel that at least as the first step, TxAuth should concentre on = the >>> Access Control. If I were to go one step further, it should be modelled= so >>> that it can consume various identity assertions (authenticated identity= in >>> ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable >>> Credentials, X.509 certificates (such as in eIDAS and Japanese National= ID >>> scheme) etc. We are not going to get to a unified identity world anyti= me >>> soon. >>> >>> Cheers, >>> >>> Nat Sakimura >>> >>> >>> On Wed, Mar 18, 2020 at 7:06 AM Mike Jones >> 40microsoft.com@dmarc.ietf.org> wrote: >>> >>>> I believe it's significant that four people have expressed concerns >>>> with including digital identity in the charter (the only concerns voic= ed as >>>> far as I can tell). At a minimum, I believe that that warrants making= the >>>> inclusion or exclusion of digital identity a discussion topic during t= he >>>> upcoming virtual BoF, before adopting any charter. >>>> >>>> It would be my proposal to initially charter without digital identity >>>> and see how far we get with our energies intentionally focused in that >>>> way. If the working group decides to recharter to include digital >>>> identity, that can always happen later, after the authorization-focuse= d >>>> work has matured, and once there's a clear case to actually do so. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: Justin Richer >>>> Sent: Tuesday, March 17, 2020 2:20 PM >>>> To: Mike Jones >>>> Cc: Yaron Sheffer ; Torsten Lodderstedt < >>>> torsten@lodderstedt.net>; txauth@ietf.org >>>> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >>>> >>>> While I understand the concerns around identity in the charter, and I >>>> had initially not included it, I was convinced that the kind of identi= ty >>>> protocol that we=E2=80=99re looking at here is a minor addition to the >>>> authorization and delegation end of things. >>>> >>>> As you know, much of what=E2=80=99s in OIDC is there to fix problems w= ith OAuth >>>> 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems >>>> internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now >>>> starting at a base where those problems don=E2=80=99t exist, but we do= n=E2=80=99t yet know >>>> what other problems there might be. >>>> >>>> The market has shown us that the most common application of OAuth 2 is >>>> far and away access to identity information along side access to an AP= I. I >>>> think we need to pay attention to that and not make this separate just >>>> because we did it that way before. And some of the proposed innovation= s, >>>> including getting and sending VC=E2=80=99s, are all about identity. >>>> >>>> Furthermore, this charter does not specify the document and >>>> specification structure of the components, nor does it specify the >>>> publication order or timing of any documents. I personally think that = the >>>> identity layer should be separable to an extent, to the point of publi= shing >>>> that layer in its own spec alongside the core authorization delegation >>>> system. However, that does not mean that it should be developed elsewh= ere. >>>> >>>> If there is better language to tighten the aspects of an identity >>>> protocol that we will explicitly cover, then I would welcome you to su= ggest >>>> an amended text to the charter. However, I believe there is enough int= erest >>>> within the community to work on identity in the context of this protoc= ol, >>>> including a large number of people being OK with it in the charter, th= at it >>>> would not be a reasonable thing to remove it. >>>> >>>> =E2=80=94 Justin >>>> >>>> > On Mar 17, 2020, at 1:12 PM, Mike Jones >>> 40microsoft.com@dmarc.ietf.org> wrote: >>>> > >>>> > 1. Do you support the charter text provided at the end of this >>>> email? Or do you have major objections, blocking concerns or feedback= (if >>>> so please elaborate)? >>>> > >>>> > I share the concerns about including identity in the charter that >>>> were expressed by Torsten and agreed with by David Skaife. I'll note = that >>>> Kim Cameron previously expressed concerns about including identity in = his >>>> earlier charter critique at >>>> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Ca= hE/ >>>> . >>>> > >>>> > I'm fine with refactoring the authorization protocol. But identity >>>> should be decoupled from the TxAuth work to focus its scope on areas w= here >>>> innovation is being proposed. Digital identity can always be added as= a >>>> layer if needed, just as OpenID Connect layered identity onto OAuth 2.= 0. >>>> > >>>> > Please revise the charter to remove digital identity from the scope >>>> of the work. >>>> > >>>> > 2. Are you willing to author or participate in the development of >>>> the drafts of this WG? >>>> > >>>> > Yes >>>> > >>>> > 3. Are you willing to help review the drafts of this WG? >>>> > >>>> > Yes >>>> > >>>> > 4. Are you interested in implementing drafts of this WG? >>>> > >>>> > Not at this time. >>>> > >>>> > -- Mike >>>> > >>>> > -----Original Message----- >>>> > From: Txauth On Behalf Of Torsten >>>> Lodderstedt >>>> > Sent: Saturday, March 7, 2020 7:18 AM >>>> > To: Yaron Sheffer >>>> > Cc: txauth@ietf.org >>>> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth >>>> WG >>>> > >>>> > Hi, >>>> > >>>> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer >>> >: >>>> >> >>>> >> =EF=BB=BFHi Everyone, >>>> >> >>>> >> It appears that momentum is forming around the proposed formation o= f >>>> a TxAuth working group. We=E2=80=99d like to more formally gauge inte= rest in >>>> proceeding with this work. Please do so by responding to the followin= g >>>> questions: >>>> >> >>>> >> 1. Do you support the charter text provided at the end of this >>>> email? Or do you have major objections, blocking concerns or feedback= (if >>>> so please elaborate)? >>>> > >>>> > I=E2=80=98m in although I have to admit I=E2=80=98m slightly concern= ed the scope of >>>> the charter is too broad, e.g. identify alone is a huge topic. >>>> > >>>> > We need to keep an eye on this aspect in order to make sure, the >>>> group is able to work effectively and the specs we will be producing a= re as >>>> simple as possible and foster interoperability. >>>> > >>>> >> >>>> >> 2. Are you willing to author or participate in the development of >>>> the drafts of this WG? >>>> > >>>> > yes >>>> > >>>> >> >>>> >> 3. Are you willing to help review the drafts of this WG? >>>> > >>>> > yes >>>> > >>>> >> >>>> >> 4. Are you interested in implementing drafts of this WG? >>>> > >>>> > yes >>>> > >>>> > best regards, >>>> > Torsten. >>>> > >>>> >> >>>> >> The call will run for two weeks, until March 21. If you think that >>>> the charter should be amended In a significant way, please reply on a >>>> separate thread. >>>> >> >>>> >> The feedback provided here will help the IESG come to a decision on >>>> the formation of a new WG. Given the constraints of the chartering pro= cess, >>>> regardless of the outcome of this consensus call, we will be meeting i= n >>>> Vancouver as a BoF. >>>> >> >>>> >> Thanks, >>>> >> Yaron and Dick >>>> >> >>>> >> --- Charter Text Follows --- >>>> >> >>>> >> This group is chartered to develop a fine-grained delegation >>>> protocol for authorization, identity, and API access. This protocol wi= ll >>>> allow an authorizing party to delegate access to client software throu= gh an >>>> authorization server. It will expand upon the uses cases currently >>>> supported by OAuth 2.0 and OpenID Connect (itself an extension of OAut= h >>>> 2.0) to support authorizations scoped as narrowly as a single transact= ion, >>>> provide a clear framework for interaction among all parties involved i= n the >>>> protocol flow, and remove unnecessary dependence on a browser or user-= agent >>>> for coordinating interactions. >>>> >> >>>> >> The delegation process will be acted upon by multiple parties in th= e >>>> protocol, each performing a specific role. The protocol will decouple = the >>>> interaction channels, such as the end user=E2=80=99s browser, from the= delegation >>>> channel, which happens directly between the client and the authorizati= on >>>> server (in contrast with OAuth 2.0 which is initiated by the client >>>> redirecting the user=E2=80=99s browser). The client and AS will involv= e a user to >>>> make an authorization decision as necessary through interaction mechan= isms >>>> indicated by the protocol. This decoupling avoids many of the security >>>> concerns and technical challenges of OAuth 2.0 and provides a non-inva= sive >>>> path for supporting future types of clients and interaction channels. >>>> >> >>>> >> Additionally, the delegation process will allow for: >>>> >> >>>> >> - Fine-grained specification of access >>>> >> - Approval of AS attestation to identity claims >>>> >> - Approval of access to multiple resources and APIs in a single >>>> interaction >>>> >> - Separation between the party authorizing access and the party >>>> operating the client requesting access >>>> >> - A variety of client applications, including Web, mobile, >>>> single-page, and interaction-constrained applications >>>> >> >>>> >> The group will define extension points for this protocol to allow >>>> for flexibility in areas including: >>>> >> >>>> >> - Cryptographic agility for keys, message signatures, and proof of >>>> possession >>>> >> - User interaction mechanisms including web and non-web methods >>>> >> - Mechanisms for conveying user, software, organization, and other >>>> pieces of information used in authorization decisions >>>> >> - Mechanisms for presenting tokens to resource servers and binding >>>> resource requests to tokens and associated cryptographic keys >>>> >> - Optimized inclusion of additional information through the >>>> delegation process (including identity) >>>> >> >>>> >> Additionally, the group will provide mechanisms for management of >>>> the protocol lifecycle including: >>>> >> >>>> >> - Discovery of the authorization server >>>> >> - Revocation of active tokens >>>> >> - Query of token rights by resource servers >>>> >> >>>> >> Although the artifacts for this work are not intended or expected t= o >>>> be backwards-compatible with OAuth 2.0 or OpenID Connect, the group wi= ll >>>> attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the= new >>>> protocol where possible. >>>> >> >>>> >> This group is not chartered to develop extensions to OAuth 2.0, and >>>> as such will focus on new technological solutions not necessarily >>>> compatible with OAuth 2.0. Functionality that builds directly on OAuth= 2.0 >>>> will be developed in the OAuth Working Group, including functionality >>>> back-ported from the protocol developed here to OAuth 2.0. >>>> >> >>>> >> The group is chartered to develop mechanisms for applying >>>> cryptographic methods, such as JOSE and COSE, to the delegation proces= s. >>>> This group is not chartered to develop new cryptographic methods. >>>> >> >>>> >> The initial work will focus on using HTTP for communication between >>>> the client and the authorization server, taking advantage of optimizat= ion >>>> features of HTTP2 and HTTP3 where possible, and will strive to enable >>>> simple mapping to other protocols such as COAP when doing so does not >>>> conflict with the primary focus. >>>> >> >>>> >> Milestones to include: >>>> >> - Core delegation protocol >>>> >> - Key presentation mechanism bindings to the core protocol for TLS, >>>> detached HTTP signature, and embedded HTTP signatures >>>> >> - Identity and authentication conveyance mechanisms >>>> >> - Guidelines for use of protocol extension points >>>> >> >>>> >> >>>> >> -- >>>> >> Txauth mailing list >>>> >> Txauth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/txauth >>>> > -- >>>> > Txauth mailing list >>>> > Txauth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --0000000000002c3e5805a1871306 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nat

Thanks for the clarification. I think what you describe sounds = very useful. I=E2=80=99m hopeful that the group will use GitHub, and what y= ou propose would be a useful tool there to provide context and ground the p= rotocol work.

On Mon, Mar 23, 2020 at 8:08 AM Nat Sakimura <sakimura@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Thanks, Dick.=C2=A0

=
Just one point on the "Architecture" document. Perhaps= "Architecture" was a way too loaded word.=C2=A0
What I= wanted to say was that documenting in a way or another who/what are the st= akeholders/actors and what are the requirements laid out by them.=C2=A0

For example, in OAuth 2.0 context, we tend to collaps= e Authentication Server and Authorization Server in one, but in the federat= ed authorization case, clearly delineating them helps a lot. This can be ca= ptured in a use-case document or in a more abstract document and should hav= e impacts on the actual protocol to be written.=C2=A0

<= div>Another example is to list and consider stakeholder concerns. For examp= le, in OAuth 2.0, we have not been explicitly considering the needs of the = who undertakes the monitoring for example. They may not end up in the proto= col that we will be writing, but if there is something that protocol can he= lp their work, we should perhaps consider them. However, if we did not docu= ment them at all, it would be difficult to consider them systematically dur= ing the protocol design.=C2=A0

It could even be ju= st a wiki page, but I thought that kind of document, whatever it is called,= is a useful side document to have handy.=C2=A0

On Sat, Mar 21, 2020= at 3:04 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Nat: thanks for chim= ing in. Useful=C2=A0insights as always!

Vittor= io: I'll reinterpret your statement about "marketing" the wor= k, to be that we should solve real problems that people don't have solu= tions for today.=C2=A0

AS<->RS relationsh= ip

TL;DR: I think the charter misses the mar= k in the AS<->RS relationship being in scope and we should expand it.=

In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in= contrast to OAuth 1.0, but the interactions / communication between the AS= and the RS were out of scope, as the uses cases at the time had the AS and= RS operated by the same entity. New use cases have a weaker coupling betwe= en the AS and RS, and to enable interop, extensions have been written for T= oken Introspection, and JWT Profile for OAuth 2.0 Access Tokens .=C2=A0

The TxAuth charter includes introspection:
= =C2=A0
- Query of token rights by resource servers=C2=A0

-- but does not include the = common design pattern where the RS can directly interpret the token.
<= div>
Here is proposed updated=C2=A0text to the line above to = be broader in scope than just a query:

- com= munication=C2=A0of token attributes=C2=A0between the authorization server a= nd resource server

Architecture and Use Case documents

=
TL;DR: Yes to use case doc, no to architecture doc.
I agree with Justin that an architecture=C2=A0document is unli= kely to prove useful long term. I disagree with him on the use cases. I don= 't think the use cases need to be exhaustive, but example use cases hel= ps everyone understand everyone else's primary use cases. If your use c= ase is not similar to others, then you should write it up and the WG can de= cide if it is in scope or not. If it is, it gets added to the use case docu= ment. I would consider this a living document while working on the core pro= tocol. It would NOT be a use case document that scopes the WG work. The cha= rter does that. It would be a companion document to the core protocol. I st= rongly think a use case document resolves many of the miscommunications tha= t happen where people are talking past each other, because they don't u= nderstand each other's use case.

<= b>Reusing Existing Technology

TL;DR: we= should be reusing existing specifications where ever possible.
<= br>
Reading between the lines, I think the concern around identit= y may be that the TxAuth charter implies that the WG is going to create yet= -another-identity-representation and ignore all the previous efforts. I thi= nk creating=C2=A0yet-another-identity-representation to solve use cases tha= t are already solved with existing representations would be misguided effor= t. My own interest in TxAuth is being able to use one protocol to request a= nd receive any existing and future identity representation. One of my motiv= ations for writing the XAuth document was to show how different representat= ions could be requested and received, as this was missing in XYZ.=C2=A0 If = a use case requires a new representation, then perhaps TxAuth may be a plac= e for that work to happen, but I think it is more likely to happen in other= forums.

It is not clear to me how, or if, reusing= existing technology fits into the charter, but I do strongly think it shou= ld be a tenet of the WG.

On a related note, I= also strongly think that the existing OAuth 2.0 scopes should be easily us= ed in requests and responses. XAuth shows an example of how that can be don= e.

/Dick=C2=A0


=


On Fri, Mar 20, 2020 at 6:39 AM Justin Richer &l= t;jricher@mit.edu&= gt; wrote:
= I agree with a lot of that argument. Let me see if I can more clearly resta= te what I was trying to say earlier in this thread: the relationships betwe= en the different parties are separable and depend on the kind of deployment= s and use cases that are being addressed by people. So in an OAuth/OIDC-sty= le world, we=E2=80=99ve got three components (ignoring people), and three r= elationships between them:

C<->AS

C<->RS

AS<->RS

=
For authorization, these map to =E2=80=9Chow to get a token=E2= =80=9D, =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow to interpret= a token=E2=80=9D. For authentication, it=E2=80=99s additionally =E2=80=9Ch= ow do I get the authentication info=E2=80=9D, =E2=80=9Chow do I ask for a p= rofile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80=9D.= I still believe this is a good separation of concerns. The client doesn=E2= =80=99t need to know what=E2=80=99s in the access token, or if it=E2=80=99s= a reference or self-contained, or really concern itself at all with what t= he RS does with it. Are there overlaps? Certainly =E2=80=94 the client need= s to know how to ask for a token that the RS will accept for what the clien= t is going to do, and to do that the client needs to be able to describe wh= at it wants to do in a way that the AS can interpret and map to a set of ri= ghts that the RS will eventually interpret.=C2=A0

= I believe the proposed charter already covers this split with the following= items:

- Fine-grained specification of access
= - Approval of access to multiple resources and APIs in a single interaction=
- Separation between the party authorizing access and the party operati= ng the client requesting access
- Revocation of active tokens<= br>- Query of token rights by resource servers

It=E2=80=99s the combination of the rich request and the lifecycle managem= ent that puts the AS and RS in scope. I think things like declaring a singl= e token format are absolutely out =E2=80=94 if you want to use JWT, or CWT,= or UUID=E2=80=99s, that=E2=80=99s all just fine. However, something that I= think is in scope is defining a structure for what a token represents. And= I think that if we can do that in this WG in a general way, then that=E2= =80=99s useful. Because then that structure can be represented by mapping t= o a token format or an introspection response or a database entry. I think = Nat=E2=80=99s comments on ABAC are important: we are going to need a place = to put those attributes. Whether they=E2=80=99re communicated to the RS thr= ough the token itself or through some other channel is, I strongly believe,= a matter of deployment choice.

So, what can the c= harter say to make this more clear?

All that said,= I=E2=80=99m against having an architecture document as a working group out= put. In my experience, when a WG puts its effort into a formal architecture= doc as a deliverable, there is a lot of conjectural energy that goe= s into what might be a good idea, and then not all of it works out when you= try to hammer the details of making that architecture into a real engineer= ed thing.You end up baking in assumptions and abstractions that don=E2=80= =99t make sense anymore, and then trying to engineer solutions around those= when they don=E2=80=99t fit right. If the architecture can=E2=80=99t chang= e in light of new information, which is the case with an RFC, then it becom= es a shackle instead of a scaffold. But a malleable document that the group= can use as a guide while engineering the actual parts =E2=80=94 yes, that = makes sense. The architecture can be refactored and changed as decisions ar= e made and things come into focus. I feel the same about use case documents= as formal artifacts.=C2=A0

Thanks, Nat.
=C2=A0=E2=80=94 Justin

On Mar 20, 2020, at 2:19 AM, Nat Sakimura <sakimura@gmail.com> wrote:

I thought I should keep my mouth=C2=A0shut as anything I= say may be deemed biased as my other hat is the chairman of OIDF, but here= is my 2c.=C2=A0

As Torsten indicated, there is much to = be desired to standardize the AS - RS communication patterns. You may say t= hat the charter includes it, but I cannot read it out of the charter just l= ike Torsten could not. As a new protocol, it would be good to include it.= =C2=A0

In this respect, I am not sure if we should= start off from OAuth 2.0 and OIDC model. If we are creating a new protocol= , I feel that we should architect is more fully. Not mentioning AS - RS rel= ationship to me feels like an indication of this failure. For that matter, = I feel that the first output of the group should be an architecture documen= t that takes the concerns from all the relevant stakeholders/actors in.=C2= =A0

We should also be cognizant of the access=C2= =A0control models like ABAC. For that, decoupling of identity (=3D set of c= laims) assertion and authorization is a necessity. We could optimize it but= the base case should take care of it. (In this respect, I am feeling that = OIDC has perhaps over-optimized.) So, I feel that at least as the first ste= p, TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity asse= rtions (authenticated identity in ISO/IEC 24760 speak) including ID Token, = SAML Assertion, DID Verifiable Credentials, X.509 certificates (such as in = eIDAS and Japanese National ID scheme)=C2=A0 etc. We are not going to get t= o a unified identity world anytime soon.=C2=A0

Che= ers,=C2=A0

Nat Sakimura

=
On Wed= , Mar 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.iet= f.org> wrote:
I believe it's significant that four people have expressed concern= s with including digital identity in the charter (the only concerns voiced = as far as I can tell).=C2=A0 At a minimum, I believe that that warrants mak= ing the inclusion or exclusion of digital identity a discussion topic durin= g the upcoming virtual BoF, before adopting any charter.

It would be my proposal to initially charter without digital identity and s= ee how far we get with our energies intentionally focused in that way.=C2= =A0 If the working group decides to recharter to include digital identity, = that can always happen later, after the authorization-focused work has matu= red, and once there's a clear case to actually do so.

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

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net&= gt;; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had i= nitially not included it, I was convinced that the kind of identity protoco= l that we=E2=80=99re looking at here is a minor addition to the authorizati= on and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems with O= Auth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved those pro= blems internally, then OIDC would be much, much simpler and smaller. We=E2= =80=99re now starting at a base where those problems don=E2=80=99t exist, b= ut we don=E2=80=99t yet know what other problems there might be.

The market has shown us that the most common application of OAuth 2 is far = and away access to identity information along side access to an API. I thin= k we need to pay attention to that and not make this separate just because = we did it that way before. And some of the proposed innovations, including = getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and specification s= tructure of the components, nor does it specify the publication order or ti= ming of any documents. I personally think that the identity layer should be= separable to an extent, to the point of publishing that layer in its own s= pec alongside the core authorization delegation system. However, that does = not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol = that we will explicitly cover, then I would welcome you to suggest an amend= ed text to the charter. However, I believe there is enough interest within = the community to work on identity in the context of this protocol, includin= g a large number of people being OK with it in the charter, that it would n= ot be a reasonable thing to remove it.

=C2=A0=E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@d= marc.ietf.org> wrote:
>
> 1.=C2=A0 Do you support the charter text provided at the end of this e= mail?=C2=A0 Or do you have major objections, blocking concerns or feedback = (if so please elaborate)?
>
> I share the concerns about including identity in the charter that were= expressed by Torsten and agreed with by David Skaife.=C2=A0 I'll note = that Kim Cameron previously expressed concerns about including identity in = his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2Ca= hE/.
>
> I'm fine with refactoring the authorization protocol.=C2=A0 But id= entity should be decoupled from the TxAuth work to focus its scope on areas= where innovation is being proposed.=C2=A0 Digital identity can always be a= dded as a layer if needed, just as OpenID Connect layered identity onto OAu= th 2.0.
>
> Please revise the charter to remove digital identity from the scope of= the work.
>
> 2.=C2=A0 Are you willing to author or participate in the development o= f the drafts of this WG?
>
> Yes
>
> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt > Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.o= rg
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth W= G
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>: >>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed formation = of a TxAuth working group.=C2=A0 We=E2=80=99d like to more formally gauge i= nterest in proceeding with this work.=C2=A0 Please do so by responding to t= he following questions:
>>
>> 1.=C2=A0 Do you support the charter text provided at the end of th= is email?=C2=A0 Or do you have major objections, blocking concerns or feedb= ack (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly concerned= the scope of the charter is too broad, e.g. identify alone is a huge topic= .
>
> We need to keep an eye on this aspect in order to make sure, the group= is able to work effectively and the specs we will be producing are as simp= le as possible and foster interoperability.
>
>>
>> 2.=C2=A0 Are you willing to author or participate in the developme= nt of the drafts of this WG?
>
> yes
>
>>
>> 3.=C2=A0 Are you willing to help review the drafts of this WG?
>
> yes
>
>>
>> 4.=C2=A0 Are you interested in implementing drafts of this WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think that= the charter should be amended In a significant way, please reply on a sepa= rate thread.
>>
>> The feedback provided here will help the IESG come to a decision o= n the formation of a new WG. Given the constraints of the chartering proces= s, regardless of the outcome of this consensus call, we will be meeting in = Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation proto= col for authorization, identity, and API access. This protocol will allow a= n authorizing party to delegate access to client software through an author= ization server. It will expand upon the uses cases currently supported by O= Auth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support a= uthorizations scoped as narrowly as a single transaction, provide a clear f= ramework for interaction among all parties involved in the protocol flow, a= nd remove unnecessary dependence on a browser or user-agent for coordinatin= g interactions.
>>
>> The delegation process will be acted upon by multiple parties in t= he protocol, each performing a specific role. The protocol will decouple th= e interaction channels, such as the end user=E2=80=99s browser, from the de= legation channel, which happens directly between the client and the authori= zation server (in contrast with OAuth 2.0 which is initiated by the client = redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mech= anisms indicated by the protocol. This decoupling avoids many of the securi= ty concerns and technical challenges of OAuth 2.0 and provides a non-invasi= ve path for supporting future types of clients and interaction channels. >>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single in= teraction
>> - Separation between the party authorizing access and the party op= erating the client requesting access
>> - A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to allow = for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof of= possession
>> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other= pieces of information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding= resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the delega= tion process (including identity)
>>
>> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will= attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new= protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, an= d as such will focus on new technological solutions not necessarily compati= ble with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be= developed in the OAuth Working Group, including functionality back-ported = from the protocol developed here to OAuth 2.0.
>>
>> The group is chartered to develop mechanisms for applying cryptogr= aphic methods, such as JOSE and COSE, to the delegation process. This group= is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication betwee= n the client and the authorization server, taking advantage of optimization= features of HTTP2 and HTTP3 where possible, and will strive to enable simp= le mapping to other protocols such as COAP when doing so does not conflict = with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for TLS= , detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


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

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat= _en
--0000000000002c3e5805a1871306-- From nobody Mon Mar 23 12:26:19 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA1C3A0DBF for ; Mon, 23 Mar 2020 12:25:53 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_FILL_THIS_FORM_SHORT=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 tEHNHvFh-Dsq for ; Mon, 23 Mar 2020 12:25:51 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650107.outbound.protection.outlook.com [40.107.65.107]) (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 077223A0DAE for ; Mon, 23 Mar 2020 12:25:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gcWwy+oSSPRfbCJRB1cVaY55lHSIZs1ZFKMRkDojYQlZuURFrJ9W8+dCYkh1FupnbsM1MGJedMgIRkooy8mHp7bLx3X3p++aK8C3siR1T1oKPHOQq8lxLJuMSwwthV/m8iLFxK9K0fybCEdclbArpJWsVNL6cUBSrNkNyAAGO3eVqHpOMhcwaOdIwJ9AoVY2/fKIG+59TdhdcyhKcwUbSRh3MskEJpFGTf8FkcZEpLGR8ckLyiRp7rMBuXa8eC8WeGwU+7GiJ32QQTwjE0+Q2WKx6ehbCrGtX+3zjvZRlS+YGrQM7oP5eUIrxjAeOBYFhBe1Y93Ntd/7PWHXk+Lm1A== 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=QQlH+yMbWwQTBmfVhg5ZkyiGXGYzA7Bbdy9iT1ImtuQ=; b=gGm70gQKDLNeoFQpCWiJRxolleSJT3xGTcx9Otwwl/dM6FRSIfKwVgX/7futV8JqgpwMWRGrERic6adRpv22BR3YLuTqQYf+ZJH6TnRgNvAX0JbG3VWNPiscNEy4XzA4Ez5afzmHLjDos+RhM/tNmpHYZTlZnHw2Us3r1VTVy/kETEDntQGGrtYL0GaY6IzkJZMx5ONVCZ/V1ZNpvMyRgREIQx57Kz97FiLg1wLfRloerGbn6v/mysdlEVftI0ep/n++gf2cH9TTr4TF7fm47S6qzY+7rPQJ2E8rP5XLWOj15WHKyJpy/Ae62FhboPQf4mecUgAXsvVJDtNK4gyviQ== 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=QQlH+yMbWwQTBmfVhg5ZkyiGXGYzA7Bbdy9iT1ImtuQ=; b=LLdYMm69obWw7HMnFgauR5VUdu95DxW60ofBELdUMszGRt2/4xPDMIk8AdTJgi/GarL0+GnTG7hcSN+PA+Ikk0EyUhDZzIPaEeLWqcTRcBNtwOUynzQ5BI1O9naJ1mDbs7vpdr5R8p8kgIIVfY9FsNjzlGyN0kTuyApFyBppSmI= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0712.namprd00.prod.outlook.com (2603:10b6:610:ad::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2885.0; Mon, 23 Mar 2020 19:25:48 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9%7]) with mapi id 15.20.2885.000; Mon, 23 Mar 2020 19:25:48 +0000 From: Mike Jones To: Dick Hardt , Kim , Filip Skokan , Torsten Lodderstedt CC: "txauth@ietf.org" Thread-Topic: [Txauth] Proposed TxAuth charter Text Thread-Index: AdYBSNlLYSRuyZ2ESkCgbJ/dIfunHw== Date: Mon, 23 Mar 2020 19:25:48 +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_ActionId=f77b69fe-e4af-476c-857a-0000f5db2109; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-23T19:18:43Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d50bfc7c-b4f5-4d66-825e-08d7cf5ffe15 x-ms-traffictypediagnostic: CH2PR00MB0712: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(39860400002)(136003)(396003)(346002)(366004)(376002)(199004)(71200400001)(5660300002)(66446008)(10290500003)(110136005)(186003)(2906002)(966005)(26005)(8990500004)(316002)(8936002)(52536014)(4326008)(478600001)(81156014)(6506007)(66946007)(81166006)(76116006)(33656002)(8676002)(64756008)(66476007)(66556008)(53546011)(7696005)(9686003)(66574012)(55016002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0712; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: l3XNI7Uuw+wxqwmlGsipJRTH6tm06thW5ICULE0VvuEzaIAKMU1AhCzy5CUEo+BpBIw0MTjcAjJ8k4MAPwAoONdBs2Ta3PLlNuFdY2yaBBzhtemHXJ4sE5K6jp5qgR5mo0VzgP8+Av95MgvtOqfYXQA50SBs1MVpKgZj72X2z9Px23h61v8o9FOfJgV1+12CMMWSK10EP7GMUje3MnSC7ISVfMs0g4q8h/9D0KkfR8p9L1zEd0tV23LCH65mLhOzS6u6MGR6R1SPJbbIowBWTUGmrW2EXfQJBtcgBPCFbqplonGN6aaD9yuXQyBc780rDtrLP4tWanMvHnhawvmMO9AtsPGHAxYustthKcJ0vaONSi84OfCYsBklkhze1gq9BpN2kJWDwKrQCj/4O7JPDxUfn3rKH137BYcun/edl+jwk9FbsdAGBHpb6y4k1rp3i/Yr3YjjXIO4seibplT6SmAbh+3oZx9XnnguYOwvbwPksI6/qaX7cthnr035hbx3riHf9pTsHTsH7dYi2hUhyg== x-ms-exchange-antispam-messagedata: hP8JxEi+63IE2kLBhbDy4dw4ixN5EshE+v3USd50FmQfAkOTCDRJTxw33mim6QXsyVElv5wtbsNNh1O4gq4ZN1K5gPP2zUyVmJQiAgZtxAQW6TTfw9izhu0UoOK7+HU/NbY2FQ1jJ7zfSY/1Ng+J9Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679CA588E2197B105FD2ED4F5F00CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d50bfc7c-b4f5-4d66-825e-08d7cf5ffe15 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 19:25:48.6207 (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: Z67suUwPYLEoznG258WwX1qgZMgHPfr1Vv/ItEBwt2z+aNjsh8tgbA8CywcxVWK7QdbuH6S5a5UgDBH3B17jJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0712 Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 19:26:17 -0000 --_000_CH2PR00MB0679CA588E2197B105FD2ED4F5F00CH2PR00MB0679namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoZSB1cGRhdGVzIHJlcHJlc2VudCBzb21lIHByb2dyZXNzLiAgSeKAmWQg bGlrZSB0byB0aWdodGVuIHRoZSBzdGF0ZW1lbnQgYWJvdXQgd2hhdCB0aGUgZ3JvdXAgaXMgbm90 IGNoYXJ0ZXJlZCB0byBkbyB0byBhZGQgbmV3IHJlZ2lzdHJpZXMgZm9yIGlkZW50aXR5IGNsYWlt cyBhcmUgYWxzbyBvdXQgb2Ygc2NvcGUuICBJIHByb3Bvc2UgdGhhdCByZXZpc2UgdGhlIHN0YXRl bWVudCBiZWxvdyBwZXIgbXkgdGV4dCBpbiByZWQ6DQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQg dG8gZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBjb252ZXlpbmcgaWRlbnRpdHkgaW5mb3JtYXRpb24g d2l0aGluIHRoZSBwcm90b2NvbCBpbmNsdWRpbmcgaWRlbnRpZmllcnMgKHN1Y2ggYXMgZW1haWwg YWRkcmVzc2VzLCBwaG9uZSBudW1iZXJzLCB1c2VybmFtZXMsIGFuZCBzdWJqZWN0IGlkZW50aWZp ZXJzKSBhbmQgYXNzZXJ0aW9ucyAoc3VjaCBhcyBPcGVuSUQgQ29ubmVjdCBJRCBUb2tlbnMsIFNB TUwgQXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMpLiBUaGUgZ3JvdXAgaXMg bm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBmb3JtYXRzIGZvciBpZGVudGlmaWVycyBvciBh c3NlcnRpb25zLCBub3IgaXMgdGhlIGdyb3VwIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIHNjaGVtYXMg Zm9yIHVzZXIgaW5mb3JtYXRpb24sIHByb2ZpbGVzLCBvciBvdGhlciBpZGVudGl0eSBhdHRyaWJ1 dGVzLCBvciBuZXcgcmVnaXN0cmllcyBmb3IgbGlzdGluZyBzdWNoIHNjaGVtYSBlbGVtZW50cyBv ciBpZGVudGl0eSBhdHRyaWJ1dGVzLCB1bmxlc3MgYSB2aWFibGUgZXhpc3RpbmcgZm9ybWF0IGlz IG5vdCBhdmFpbGFibGUuDQoNCkxpa2UgVG9yc3RlbiwgS2ltLCBhbmQgb3RoZXJzLCBJ4oCZZCBz dGlsbCByYXRoZXIgdGhhdCB3ZSB0YWNrbGVkIGlkZW50aXR5IHNlcGFyYXRlbHksIGlmIGF0IGFs bC4gIE15IHByb3Bvc2FsIGFib3ZlIGlzIG15IGZhbGxiYWNrIHBvc2l0aW9uIGlmIHdlIGNhbuKA mXQgZ2V0IGNvbnNlbnN1cyB0byByZW1vdmUgaWRlbnRpdHkgZnJvbSB0aGUgY2hhcnRlci4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTZW50OiBT YXR1cmRheSwgTWFyY2ggMjEsIDIwMjAgMTI6NTYgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+OyBLaW0gPGtpbUBpZGVudGl0eWJsb2cuY29tPjsgRmlsaXAg U2tva2FuIDxwYW52YS5pcEBnbWFpbC5jb20+OyBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldD4NCkNjOiB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhh dXRoXSBQcm9wb3NlZCBUeEF1dGggY2hhcnRlciBUZXh0DQoNCihyZXBseWluZyB3aXRoIHRob3Nl IHRoYXQgaGFkIGV4cHJlc3NlZCBjb25jZXJucyBhYm91dCB0aGUgY2hhcnRlciBvbiB0aGUgVG86 IGxpc3QgdG8gYnJpbmcgaXQgdG8gdGhlIHRvcCBvZiB0aGVpciBpbmJveCkNCg0KTWlrZSwgS2lt LCBUb3JzdGVuLCBGaWxpcDogYXJlIHlvdXIgY29uY2VybnMgYWRkcmVzc2VkIHdpdGggdGhlIGNo YW5nZXMgYmVsb3c/DQoNCihhcG9sb2dpZXMgdG8gYW55b25lIEkgbWlzc2VkIGluIHRoZSBUbzog bGlzdCkNCg0KT24gU2F0LCBNYXIgMjEsIDIwMjAgYXQgMTI6NDEgUE0gSnVzdGluIFJpY2hlciA8 anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkFmdGVyIHNv bWUgZ3JlYXQgZGlzY3Vzc2lvbnMgb24gdGhlIGxpc3QgaW4gdGhlIGxhc3Qgd2VlaywgWWFyb24s IERpY2ssIGFuZCBJIGhhdmUgcHVsbGVkIHRvZ2V0aGVyIGEgbmV3IHByb3Bvc2VkIGNoYXJ0ZXIu IEkgdGhpbmsgdGhpcyBpcyB2ZXJzaW9uIDUuMD8gQnV0IEkgZm9yZ2V0IGV4YWN0bHkuIDopDQoN CknigJl2ZSBoaWdobGlnaHRlZCB0aGUgbmV3IGxpbmVzIGluIGJvbGQgaGVyZSwgIGZvciB0aG9z ZSByZWFkaW5nIHRoaXMgZW1haWwgaW4gSFRNTC4gVGhlcmXigJlzIGEgZGlmZiBhdmFpbGFibGUg b25saW5lIGF0ICBodHRwOi8vd3d3Lm1lcmdlbHkuY29tL1JlaG9KSnZXLyAgKG5vdGU6IGdvIHRv IHZpZXctPndvcmQgd3JhcCB0byBiZSBhYmxlIHRvIHJlYWQgaXQgYmV0dGVyKS4gSeKAmW0gYXR0 YWNoaW5nIHRoZSAuRElGRiBmaWxlIGdlbmVyYXRlZCBieSBNZXJnZWx5IGFzIHdlbGwsIGZvciB0 aG9zZSBvZiB1cyBjcnVzdHkgb2xkIHVuaXggdHlwZSBmb2xrcyB3aG8gbGlrZSB0byBzZWUgdGhh dC4NCg0KDQoNCg0KDQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmluZS1n cmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6YXRpb24sIGlkZW50aXR5LCBh bmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBh cnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRo b3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbCBleHBhbmQgdXBvbiB0aGUgdXNlcyBjYXNlcyBjdXJy ZW50bHkgc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QgKGl0c2VsZiBh biBleHRlbnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25zIHNjb3Bl ZCBhcyBuYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBhIGNsZWFyIGZy YW1ld29yayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52b2x2ZWQgaW4gdGhl IHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3NhcnkgZGVwZW5kZW5jZSBvbiBhIGJy b3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0aW9ucy4NCg0KVGhl IGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVsdGlwbGUgcGFydGll cyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNwZWNpZmljIHJvbGUuIFRoZSBw cm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBpbnRlcmFjdGlvbiBjaGFubmVscywgc3VjaCBhcyB0 aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwgd2hp Y2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0aCAyLjAgd2hpY2ggaXMgaW5pdGlhdGVk IGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzIGJyb3dzZXIpLiBUaGUgY2xp ZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UgYW4gYXV0aG9yaXphdGlvbiBk ZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluZGlj YXRlZCBieSB0aGUgcHJvdG9jb2wuIFRoaXMgZGVjb3VwbGluZyBhdm9pZHMgbWFueSBvZiB0aGUg c2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzIG9mIE9BdXRoIDIuMCBh bmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlw ZXMgb2YgY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQoNCkFkZGl0aW9uYWxseSwg dGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCg0KLSBGaW5lLWdyYWluZWQg c3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCi0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8g aWRlbnRpdHkgY2xhaW1zDQotIEFwcHJvdmFsIG9mIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJj ZXMgYW5kIEFQSXMgaW4gYSBzaW5nbGUgaW50ZXJhY3Rpb24NCi0gU3VwcG9ydCBmb3IgbXVsdGlw bGUgYWNjZXNzIHRva2VucyBpbiBhIHNpbmdsZSByZXF1ZXN0DQotIFN1cHBvcnQgZm9yIGRpcmVj dGVkLCBhdWRpZW5jZS1yZXN0cmljdGVkIGFjY2VzcyB0b2tlbnMNCi0gU2VwYXJhdGlvbiBiZXR3 ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVyYXRpbmcg dGhlIGNsaWVudCByZXF1ZXN0aW5nIGFjY2Vzcw0KLSBBIHZhcmlldHkgb2YgY2xpZW50IGFwcGxp Y2F0aW9ucywgaW5jbHVkaW5nIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIGludGVyYWN0 aW9uLWNvbnN0cmFpbmVkIGFwcGxpY2F0aW9ucw0KDQpUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0 ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkg aW4gYXJlYXMgaW5jbHVkaW5nOg0KDQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywg bWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0KLSBVc2VyIGludGVy YWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzDQotIE1l Y2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0aW9uLCBhbmQg b3RoZXIgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lv bnMNCi0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2VydmVy cyBhbmQgYmluZGluZyByZXNvdXJjZSByZXF1ZXN0cyB0byB0b2tlbnMgYW5kIGFzc29jaWF0ZWQg Y3J5cHRvZ3JhcGhpYyBrZXlzDQotIE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRkaXRpb25hbCBp bmZvcm1hdGlvbiB0aHJvdWdoIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MgKGluY2x1ZGluZyBhc3Nl cnRlZCBpZGVudGl0eSBjbGFpbXMpDQoNCkFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJv dmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZlY3ljbGUg aW5jbHVkaW5nOg0KDQotIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCi0g UmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zDQotIE1lY2hhbmlzbXMgZm9yIHRoZSBBUyBhbmQg UlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2VzcyBncmFudGVkIGJ5IGFuIGFjY2VzcyB0b2tlbg0K DQpBbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBv ciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBvciBP cGVuSUQgQ29ubmVjdCwgdGhlIGdyb3VwIHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlmeSBtaWdyYXRp bmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRoZSBuZXcgcHJvdG9jb2wg d2hlcmUgcG9zc2libGUuDQoNClRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9w IGV4dGVuc2lvbnMgdG8gT0F1dGggMi4wLCBhbmQgYXMgc3VjaCB3aWxsIGZvY3VzIG9uIG5ldyB0 ZWNobm9sb2dpY2FsIHNvbHV0aW9ucyBub3QgbmVjZXNzYXJpbHkgY29tcGF0aWJsZSB3aXRoIE9B dXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxkcyBkaXJlY3RseSBvbiBPQXV0aCAyLjAg d2lsbCBiZSBkZXZlbG9wZWQgaW4gdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAsIGluY2x1ZGluZyBm dW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRldmVsb3BlZCBoZXJl IHRvIE9BdXRoIDIuMC4NCg0KVGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1lY2hh bmlzbXMgZm9yIGFwcGx5aW5nIGNyeXB0b2dyYXBoaWMgbWV0aG9kcywgc3VjaCBhcyBKT1NFIGFu ZCBDT1NFLCB0byB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdyb3VwIGlzIG5vdCBjaGFy dGVyZWQgdG8gZGV2ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2RzLg0KDQpUaGUgZ3JvdXAg aXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgY29udmV5aW5nIGlkZW50aXR5 IGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wgaW5jbHVkaW5nIGlkZW50aWZpZXJzIChz dWNoIGFzIGVtYWlsIGFkZHJlc3NlcywgcGhvbmUgbnVtYmVycywgdXNlcm5hbWVzLCBhbmQgc3Vi amVjdCBpZGVudGlmaWVycykgYW5kIGFzc2VydGlvbnMgKHN1Y2ggYXMgT3BlbklEIENvbm5lY3Qg SUQgVG9rZW5zLCBTQU1MIEFzc2VydGlvbnMsIGFuZCBWZXJpZmlhYmxlIENyZWRlbnRpYWxzKS4g VGhlIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgZm9ybWF0cyBmb3IgaWRl bnRpZmllcnMgb3IgYXNzZXJ0aW9ucywgbm9yIGlzIHRoZSBncm91cCBjaGFydGVyZWQgdG8gZGV2 ZWxvcCBzY2hlbWFzIGZvciB1c2VyIGluZm9ybWF0aW9uLCBwcm9maWxlcywgb3Igb3RoZXIgaWRl bnRpdHkgYXR0cmlidXRlcywgdW5sZXNzIGEgdmlhYmxlIGV4aXN0aW5nIGZvcm1hdCBpcyBub3Qg YXZhaWxhYmxlLg0KDQpUaGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUCBm b3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciwgdGFraW5nIGFkdmFudGFnZSBvZiBvcHRpbWl6YXRpb24gZmVhdHVyZXMgb2YgSFRU UDIgYW5kIEhUVFAzIHdoZXJlIHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlIHNp bXBsZSBtYXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVAgd2hlbiBkb2luZyBz byBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoZSBwcmltYXJ5IGZvY3VzLg0KDQpNaWxlc3RvbmVz IHRvIGluY2x1ZGU6DQotIENvcmUgZGVsZWdhdGlvbiBwcm90b2NvbA0KLSBLZXkgcHJlc2VudGF0 aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2NvbCBmb3IgVExTLCBkZXRh Y2hlZCBIVFRQIHNpZ25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KLSBJZGVu dGl0eSBhbmQgYXV0aGVudGljYXRpb24gY29udmV5YW5jZSBtZWNoYW5pc21zDQotIEd1aWRlbGlu ZXMgZm9yIHVzZSBvZiBwcm90b2NvbCBleHRlbnNpb24gcG9pbnRzDQoNCg0KDQoNCi0tDQpUeGF1 dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo= --_000_CH2PR00MB0679CA588E2197B105FD2ED4F5F00CH2PR00MB0679namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFncmVlIHRoYXQgdGhlIHVwZGF0ZXMgcmVw cmVzZW50IHNvbWUgcHJvZ3Jlc3MuJm5ic3A7IEnigJlkIGxpa2UgdG8gdGlnaHRlbiB0aGUgc3Rh dGVtZW50IGFib3V0IHdoYXQgdGhlIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZG8gdG8gYWRk IG5ldyByZWdpc3RyaWVzIGZvciBpZGVudGl0eSBjbGFpbXMgYXJlIGFsc28gb3V0IG9mIHNjb3Bl LiZuYnNwOyBJIHByb3Bvc2UgdGhhdA0KIHJldmlzZSB0aGUgc3RhdGVtZW50IGJlbG93IHBlciBt eSB0ZXh0IGluIHJlZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZl bG9wIG1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyBpZGVudGl0eSBpbmZvcm1hdGlvbiB3aXRoaW4g dGhlIHByb3RvY29sIGluY2x1ZGluZyBpZGVudGlmaWVycyAoc3VjaCBhcyBlbWFpbCBhZGRyZXNz ZXMsIHBob25lIG51bWJlcnMsIHVzZXJuYW1lcywgYW5kIHN1YmplY3QgaWRlbnRpZmllcnMpIGFu ZCBhc3NlcnRpb25zIChzdWNoIGFzIE9wZW5JRCBDb25uZWN0DQogSUQgVG9rZW5zLCBTQU1MIEFz c2VydGlvbnMsIGFuZCBWZXJpZmlhYmxlIENyZWRlbnRpYWxzKS4gVGhlIGdyb3VwIGlzIG5vdCBj aGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgZm9ybWF0cyBmb3IgaWRlbnRpZmllcnMgb3IgYXNzZXJ0 aW9ucywgbm9yIGlzIHRoZSBncm91cCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBzY2hlbWFzIGZvciB1 c2VyIGluZm9ybWF0aW9uLCBwcm9maWxlcywgb3Igb3RoZXIgaWRlbnRpdHkgYXR0cmlidXRlcywN CjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPm9yIG5ldyByZWdpc3RyaWVzIGZvciBsaXN0aW5nIHN1 Y2ggc2NoZW1hIGVsZW1lbnRzIG9yIGlkZW50aXR5IGF0dHJpYnV0ZXMsDQo8L3NwYW4+dW5sZXNz IGEgdmlhYmxlIGV4aXN0aW5nIGZvcm1hdCBpcyBub3QgYXZhaWxhYmxlLjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+TGlrZSBUb3JzdGVuLCBLaW0sIGFuZCBvdGhlcnMsIEnigJlk IHN0aWxsIHJhdGhlciB0aGF0IHdlIHRhY2tsZWQgaWRlbnRpdHkgc2VwYXJhdGVseSwgaWYgYXQg YWxsLiZuYnNwOyBNeSBwcm9wb3NhbCBhYm92ZSBpcyBteSBmYWxsYmFjayBwb3NpdGlvbiBpZiB3 ZSBjYW7igJl0IGdldCBjb25zZW5zdXMgdG8gcmVtb3ZlIGlkZW50aXR5IGZyb20gdGhlIGNoYXJ0 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5j b20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMjEsIDIwMjAgMTI6NTYg UE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSZndDs7IEtpbSAmbHQ7a2ltQGlkZW50aXR5YmxvZy5jb20mZ3Q7OyBGaWxpcCBTa29rYW4g Jmx0O3BhbnZhLmlwQGdtYWlsLmNvbSZndDs7IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gdHhhdXRoQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVHhhdXRoXSBQcm9wb3NlZCBUeEF1dGggY2hhcnRlciBU ZXh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihyZXBseWluZyB3aXRo IHRob3NlIHRoYXQgaGFkIGV4cHJlc3NlZCBjb25jZXJucyBhYm91dCB0aGUgY2hhcnRlciBvbiB0 aGUgVG86IGxpc3QgdG8gYnJpbmcgaXQgdG8gdGhlIHRvcCBvZiB0aGVpciBpbmJveCk8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pa2UsIEtpbSwgVG9yc3Rl biwgRmlsaXA6IGFyZSB5b3VyIGNvbmNlcm5zIGFkZHJlc3NlZCB3aXRoIHRoZSBjaGFuZ2VzIGJl bG93PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4oYXBvbG9naWVzIHRvIGFueW9uZSBJIG1pc3NlZCBpbiB0aGUgVG86IGxpc3QpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTWFy IDIxLCAyMDIwIGF0IDEyOjQxIFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpq cmljaGVyQG1pdC5lZHUiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFm dGVyIHNvbWUgZ3JlYXQgZGlzY3Vzc2lvbnMgb24gdGhlIGxpc3QgaW4gdGhlIGxhc3Qgd2Vlaywg WWFyb24sIERpY2ssIGFuZCBJIGhhdmUgcHVsbGVkIHRvZ2V0aGVyIGEgbmV3IHByb3Bvc2VkIGNo YXJ0ZXIuIEkgdGhpbmsgdGhpcyBpcyB2ZXJzaW9uIDUuMD8gQnV0IEkgZm9yZ2V0IGV4YWN0bHku IDopPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZdmUg aGlnaGxpZ2h0ZWQgdGhlIG5ldyBsaW5lcyBpbiBib2xkIGhlcmUsICZuYnNwO2ZvciB0aG9zZSBy ZWFkaW5nIHRoaXMgZW1haWwgaW4gSFRNTC4gVGhlcmXigJlzIGEgZGlmZiBhdmFpbGFibGUgb25s aW5lIGF0ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cubWVyZ2VseS5jb20vUmVob0pKdlcvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5tZXJnZWx5LmNvbS9SZWhvSkp2Vy88L2E+Jm5ic3A7 IChub3RlOiBnbyB0byB2aWV3LSZndDt3b3JkDQogd3JhcCB0byBiZSBhYmxlIHRvIHJlYWQgaXQg YmV0dGVyKS4gSeKAmW0gYXR0YWNoaW5nIHRoZSAuRElGRiBmaWxlIGdlbmVyYXRlZCBieSBNZXJn ZWx5IGFzIHdlbGwsIGZvciB0aG9zZSBvZiB1cyBjcnVzdHkgb2xkIHVuaXggdHlwZSBmb2xrcyB3 aG8gbGlrZSB0byBzZWUgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhvcml6 YXRpb24sIGlkZW50aXR5LCBhbmQgQVBJIGFjY2Vzcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93 IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdh cmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gSXQgd2lsbA0KIGV4cGFuZCB1cG9u IHRoZSB1c2VzIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVu SUQgQ29ubmVjdCAoaXRzZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQg YXV0aG9yaXphdGlvbnMgc2NvcGVkIGFzIG5hcnJvd2x5IGFzIGEgc2luZ2xlIHRyYW5zYWN0aW9u LCBwcm92aWRlIGEgY2xlYXIgZnJhbWV3b3JrIGZvciBpbnRlcmFjdGlvbiBhbW9uZyBhbGwgcGFy dGllcyBpbnZvbHZlZCBpbg0KIHRoZSBwcm90b2NvbCBmbG93LCBhbmQgcmVtb3ZlIHVubmVjZXNz YXJ5IGRlcGVuZGVuY2Ugb24gYSBicm93c2VyIG9yIHVzZXItYWdlbnQgZm9yIGNvb3JkaW5hdGlu ZyBpbnRlcmFjdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1 cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHByb3RvY29sLCBlYWNoIHBlcmZvcm1pbmcg YSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50ZXJhY3Rp b24gY2hhbm5lbHMsIHN1Y2ggYXMgdGhlIGVuZCB1c2Vy4oCZcyBicm93c2VyLCBmcm9tIHRoZSBk ZWxlZ2F0aW9uIGNoYW5uZWwsIHdoaWNoIGhhcHBlbnMNCiBkaXJlY3RseSBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Qgd2l0aCBPQXV0 aCAyLjAgd2hpY2ggaXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVz ZXLigJlzIGJyb3dzZXIpLiBUaGUgY2xpZW50IGFuZCBBUyB3aWxsIGludm9sdmUgYSB1c2VyIHRv IG1ha2UgYW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRl cmFjdGlvbg0KIG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4gVGhpcyBkZWNv dXBsaW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2Fs IGNoYWxsZW5nZXMgb2YgT0F1dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRo IGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBj aGFubmVscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWRkaXRpb25hbGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9y OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIGFjY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBBcHByb3ZhbCBvZiBBUyBhdHRlc3Rh dGlvbiB0byBpZGVudGl0eSBjbGFpbXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gQXBwcm92YWwgb2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291 cmNlcyBhbmQgQVBJcyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+LSBTdXBwb3J0IGZvciBtdWx0aXBs ZSBhY2Nlc3MgdG9rZW5zIGluIGEgc2luZ2xlIHJlcXVlc3Q8L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4tIFN1cHBvcnQgZm9yIGRpcmVj dGVkLCBhdWRpZW5jZS1yZXN0cmljdGVkIGFjY2VzcyB0b2tlbnM8L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFNlcGFyYXRpb24gYmV0d2Vl biB0aGUgcGFydHkgYXV0aG9yaXppbmcgYWNjZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRo ZSBjbGllbnQgcmVxdWVzdGluZyBhY2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQSB2YXJpZXR5IG9mIGNsaWVudCBhcHBsaWNhdGlvbnMs IGluY2x1ZGluZyBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBpbnRlcmFjdGlvbi1jb25z dHJhaW5lZCBhcHBsaWNhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMg Zm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1 ZGluZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywg YW5kIHByb29mIG9mIHBvc3Nlc3Npb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGlu Y2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBNZWNoYW5pc21zIGZvciBjb252ZXlpbmcgdXNl ciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyIHBpZWNlcyBvZiBpbmZvcm1hdGlv biB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcg dG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVzb3VyY2UgcmVxdWVzdHMg dG8gdG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5czxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBPcHRpbWl6ZWQgaW5jbHVz aW9uIG9mIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9j ZXNzIChpbmNsdWRpbmcmbmJzcDs8Yj5hc3NlcnRlZDwvYj4mbmJzcDtpZGVudGl0eSZuYnNwOzxi PmNsYWltczwvYj4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21z IGZvciBtYW5hZ2VtZW50IG9mIHRoZSBwcm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIERpc2Nv dmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5z PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4t IE1lY2hhbmlzbXMgZm9yIHRoZSBBUyBhbmQgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2VzcyBn cmFudGVkIGJ5IGFuIGFjY2VzcyB0b2tlbjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3IgdGhp cyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBh dGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRoZSBncm91cCB3aWxsIGF0 dGVtcHQgdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29u bmVjdCB0byB0aGUgbmV3IHByb3RvY29sIHdoZXJlIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdyb3VwIGlzIG5vdCBj aGFydGVyZWQgdG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2gg d2lsbCBmb2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5 IGNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGly ZWN0bHkgb24gT0F1dGggMi4wIHdpbGwgYmUgZGV2ZWxvcGVkIGluIHRoZSBPQXV0aA0KIFdvcmtp bmcgR3JvdXAsIGluY2x1ZGluZyBmdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHBy b3RvY29sIGRldmVsb3BlZCBoZXJlIHRvIE9BdXRoIDIuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGFwcGx5aW5nIGNyeXB0b2dyYXBoaWMgbWV0aG9kcywg c3VjaCBhcyBKT1NFIGFuZCBDT1NFLCB0byB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzLiBUaGlzIGdy b3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRob2Rz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5UaGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgY29udmV5 aW5nIGlkZW50aXR5IGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wgaW5jbHVkaW5nIGlk ZW50aWZpZXJzIChzdWNoIGFzIGVtYWlsIGFkZHJlc3NlcywgcGhvbmUgbnVtYmVycywgdXNlcm5h bWVzLCBhbmQgc3ViamVjdCBpZGVudGlmaWVycykgYW5kIGFzc2VydGlvbnMgKHN1Y2ggYXMgT3Bl bklEIENvbm5lY3QNCiBJRCBUb2tlbnMsIFNBTUwgQXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGUg Q3JlZGVudGlhbHMpLiBUaGUgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBm b3JtYXRzIGZvciBpZGVudGlmaWVycyBvciBhc3NlcnRpb25zLCBub3IgaXMgdGhlIGdyb3VwIGNo YXJ0ZXJlZCB0byBkZXZlbG9wIHNjaGVtYXMgZm9yIHVzZXIgaW5mb3JtYXRpb24sIHByb2ZpbGVz LCBvciBvdGhlciBpZGVudGl0eSBhdHRyaWJ1dGVzLCB1bmxlc3MgYSB2aWFibGUNCiBleGlzdGlu ZyBmb3JtYXQgaXMgbm90IGF2YWlsYWJsZS4mbmJzcDs8L2I+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbml0aWFsIHdvcmsgd2lsbCBm b2N1cyBvbiB1c2luZyBIVFRQIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXph dGlvbiBmZWF0dXJlcyBvZiBIVFRQMiBhbmQgSFRUUDMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxs IHN0cml2ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXINCiBwcm90b2NvbHMgc3Vj aCBhcyBDT0FQIHdoZW4gZG9pbmcgc28gZG9lcyBub3QgY29uZmxpY3Qgd2l0aCB0aGUgcHJpbWFy eSBmb2N1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TWlsZXN0b25lcyB0byBpbmNsdWRlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2w8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gS2V5IHByZXNl bnRhdGlvbiBtZWNoYW5pc20gYmluZGluZ3MgdG8gdGhlIGNvcmUgcHJvdG9jb2wgZm9yIFRMUywg ZGV0YWNoZWQgSFRUUCBzaWduYXR1cmUsIGFuZCBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSWRlbnRp dHkgYW5kIGF1dGhlbnRpY2F0aW9uIGNvbnZleWFuY2UgbWVjaGFuaXNtczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBHdWlkZWxpbmVzIGZvciB1 c2Ugb2YgcHJvdG9jb2wgZXh0ZW5zaW9uIHBvaW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0K VHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB0679CA588E2197B105FD2ED4F5F00CH2PR00MB0679namp_-- From nobody Mon Mar 23 12:30:31 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942ED3A0E0F for ; Mon, 23 Mar 2020 12:30:11 -0700 (PDT) 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=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 T4AUtMLDrgv5 for ; Mon, 23 Mar 2020 12:30:07 -0700 (PDT) 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 6BA253A0DEF for ; Mon, 23 Mar 2020 12:30:06 -0700 (PDT) Received: from [192.168.1.5] (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 02NJTxde032760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2020 15:30:00 -0400 From: Justin Richer Message-Id: <9F777947-8BFE-4FC6-AB06-3F5618EB7EED@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_958DE9C9-1108-4978-862A-9CAD3BEB94CC" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Mar 2020 15:29:59 -0400 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , Torsten Lodderstedt , Mike Jones , "txauth@ietf.org" To: Nat Sakimura References: <5541DB6B-0780-434C-A0EE-DF5466555606@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Call for charter consensus - TxAuth WG X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 19:30:29 -0000 --Apple-Mail=_958DE9C9-1108-4978-862A-9CAD3BEB94CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nat, To reiterate, my objection was not to the document but to including it = as a formal deliverable. I think that these kinds of things are = incredibly valuable if used well, and I would envision a wiki page to = handle the content that could be evolved over time. =E2=80=94 Justin > On Mar 23, 2020, at 11:08 AM, Nat Sakimura wrote: >=20 > Thanks, Dick.=20 >=20 > Just one point on the "Architecture" document. Perhaps "Architecture" = was a way too loaded word.=20 > What I wanted to say was that documenting in a way or another who/what = are the stakeholders/actors and what are the requirements laid out by = them.=20 >=20 > For example, in OAuth 2.0 context, we tend to collapse Authentication = Server and Authorization Server in one, but in the federated = authorization case, clearly delineating them helps a lot. This can be = captured in a use-case document or in a more abstract document and = should have impacts on the actual protocol to be written.=20 >=20 > Another example is to list and consider stakeholder concerns. For = example, in OAuth 2.0, we have not been explicitly considering the needs = of the who undertakes the monitoring for example. They may not end up in = the protocol that we will be writing, but if there is something that = protocol can help their work, we should perhaps consider them. However, = if we did not document them at all, it would be difficult to consider = them systematically during the protocol design.=20 >=20 > It could even be just a wiki page, but I thought that kind of = document, whatever it is called, is a useful side document to have = handy.=20 >=20 > On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt > wrote: > Nat: thanks for chiming in. Useful insights as always! >=20 > Vittorio: I'll reinterpret your statement about "marketing" the work, = to be that we should solve real problems that people don't have = solutions for today.=20 >=20 > AS<->RS relationship >=20 > TL;DR: I think the charter misses the mark in the AS<->RS relationship = being in scope and we should expand it. >=20 > In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast = to OAuth 1.0, but the interactions / communication between the AS and = the RS were out of scope, as the uses cases at the time had the AS and = RS operated by the same entity. New use cases have a weaker coupling = between the AS and RS, and to enable interop, extensions have been = written for Token Introspection, and JWT Profile for OAuth 2.0 Access = Tokens .=20 >=20 > The TxAuth charter includes introspection: > =20 > - Query of token rights by resource servers=20 >=20 > -- but does not include the common design pattern where the RS can = directly interpret the token. >=20 > Here is proposed updated text to the line above to be broader in scope = than just a query: >=20 > - communication of token attributes between the authorization server = and resource server >=20 >=20 > Architecture and Use Case documents >=20 > TL;DR: Yes to use case doc, no to architecture doc. >=20 > I agree with Justin that an architecture document is unlikely to prove = useful long term. I disagree with him on the use cases. I don't think = the use cases need to be exhaustive, but example use cases helps = everyone understand everyone else's primary use cases. If your use case = is not similar to others, then you should write it up and the WG can = decide if it is in scope or not. If it is, it gets added to the use case = document. I would consider this a living document while working on the = core protocol. It would NOT be a use case document that scopes the WG = work. The charter does that. It would be a companion document to the = core protocol. I strongly think a use case document resolves many of the = miscommunications that happen where people are talking past each other, = because they don't understand each other's use case. >=20 > Reusing Existing Technology >=20 > TL;DR: we should be reusing existing specifications where ever = possible. >=20 > Reading between the lines, I think the concern around identity may be = that the TxAuth charter implies that the WG is going to create = yet-another-identity-representation and ignore all the previous efforts. = I think creating yet-another-identity-representation to solve use cases = that are already solved with existing representations would be misguided = effort. My own interest in TxAuth is being able to use one protocol to = request and receive any existing and future identity representation. One = of my motivations for writing the XAuth document was to show how = different representations could be requested and received, as this was = missing in XYZ. If a use case requires a new representation, then = perhaps TxAuth may be a place for that work to happen, but I think it is = more likely to happen in other forums. >=20 > It is not clear to me how, or if, reusing existing technology fits = into the charter, but I do strongly think it should be a tenet of the = WG. >=20 > On a related note, I also strongly think that the existing OAuth 2.0 = scopes should be easily used in requests and responses. XAuth shows an = example of how that can be done. >=20 > /Dick=20 >=20 >=20 >=20 >=20 > On Fri, Mar 20, 2020 at 6:39 AM Justin Richer > wrote: > I agree with a lot of that argument. Let me see if I can more clearly = restate what I was trying to say earlier in this thread: the = relationships between the different parties are separable and depend on = the kind of deployments and use cases that are being addressed by = people. So in an OAuth/OIDC-style world, we=E2=80=99ve got three = components (ignoring people), and three relationships between them: >=20 > C<->AS >=20 > C<->RS >=20 > AS<->RS >=20 > For authorization, these map to =E2=80=9Chow to get a token=E2=80=9D, = =E2=80=9Chow to use a token=E2=80=9D, and =E2=80=9Chow to interpret a = token=E2=80=9D. For authentication, it=E2=80=99s additionally =E2=80=9Chow= do I get the authentication info=E2=80=9D, =E2=80=9Chow do I ask for a = profile=E2=80=9D, and =E2=80=9Chow do I know whose profile this is=E2=80=9D= . I still believe this is a good separation of concerns. The client = doesn=E2=80=99t need to know what=E2=80=99s in the access token, or if = it=E2=80=99s a reference or self-contained, or really concern itself at = all with what the RS does with it. Are there overlaps? Certainly =E2=80=94= the client needs to know how to ask for a token that the RS will accept = for what the client is going to do, and to do that the client needs to = be able to describe what it wants to do in a way that the AS can = interpret and map to a set of rights that the RS will eventually = interpret.=20 >=20 > I believe the proposed charter already covers this split with the = following items: >=20 > - Fine-grained specification of access > - Approval of access to multiple resources and APIs in a single = interaction > - Separation between the party authorizing access and the party = operating the client requesting access > - Revocation of active tokens > - Query of token rights by resource servers >=20 > It=E2=80=99s the combination of the rich request and the lifecycle = management that puts the AS and RS in scope. I think things like = declaring a single token format are absolutely out =E2=80=94 if you want = to use JWT, or CWT, or UUID=E2=80=99s, that=E2=80=99s all just fine. = However, something that I think is in scope is defining a structure for = what a token represents. And I think that if we can do that in this WG = in a general way, then that=E2=80=99s useful. Because then that = structure can be represented by mapping to a token format or an = introspection response or a database entry. I think Nat=E2=80=99s = comments on ABAC are important: we are going to need a place to put = those attributes. Whether they=E2=80=99re communicated to the RS through = the token itself or through some other channel is, I strongly believe, a = matter of deployment choice. >=20 > So, what can the charter say to make this more clear? >=20 > All that said, I=E2=80=99m against having an architecture document as = a working group output. In my experience, when a WG puts its effort into = a formal architecture doc as a deliverable, there is a lot of = conjectural energy that goes into what might be a good idea, and then = not all of it works out when you try to hammer the details of making = that architecture into a real engineered thing.You end up baking in = assumptions and abstractions that don=E2=80=99t make sense anymore, and = then trying to engineer solutions around those when they don=E2=80=99t = fit right. If the architecture can=E2=80=99t change in light of new = information, which is the case with an RFC, then it becomes a shackle = instead of a scaffold. But a malleable document that the group can use = as a guide while engineering the actual parts =E2=80=94 yes, that makes = sense. The architecture can be refactored and changed as decisions are = made and things come into focus. I feel the same about use case = documents as formal artifacts.=20 >=20 > Thanks, Nat. > =E2=80=94 Justin >=20 >> On Mar 20, 2020, at 2:19 AM, Nat Sakimura > wrote: >>=20 >> I thought I should keep my mouth shut as anything I say may be deemed = biased as my other hat is the chairman of OIDF, but here is my 2c.=20 >>=20 >> As Torsten indicated, there is much to be desired to standardize the = AS - RS communication patterns. You may say that the charter includes = it, but I cannot read it out of the charter just like Torsten could not. = As a new protocol, it would be good to include it.=20 >>=20 >> In this respect, I am not sure if we should start off from OAuth 2.0 = and OIDC model. If we are creating a new protocol, I feel that we should = architect is more fully. Not mentioning AS - RS relationship to me feels = like an indication of this failure. For that matter, I feel that the = first output of the group should be an architecture document that takes = the concerns from all the relevant stakeholders/actors in.=20 >>=20 >> We should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme) etc. We are not = going to get to a unified identity world anytime soon.=20 >>=20 >> Cheers,=20 >>=20 >> Nat Sakimura >>=20 >>=20 >> On Wed, Mar 18, 2020 at 7:06 AM Mike Jones = > wrote: >> I believe it's significant that four people have expressed concerns = with including digital identity in the charter (the only concerns voiced = as far as I can tell). At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter. >>=20 >> It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way. If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: Justin Richer >=20 >> Sent: Tuesday, March 17, 2020 2:20 PM >> To: Mike Jones > >> Cc: Yaron Sheffer >; Torsten Lodderstedt = >; = txauth@ietf.org >> Subject: Re: [Txauth] Call for charter consensus - TxAuth WG >>=20 >> While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things. >>=20 >> As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.=20 >>=20 >> The market has shown us that the most common application of OAuth 2 = is far and away access to identity information along side access to an = API. I think we need to pay attention to that and not make this separate = just because we did it that way before. And some of the proposed = innovations, including getting and sending VC=E2=80=99s, are all about = identity. >>=20 >> Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere. >>=20 >> If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it. >>=20 >> =E2=80=94 Justin >>=20 >> > On Mar 17, 2020, at 1:12 PM, Mike Jones = > wrote: >> >=20 >> > 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >> >=20 >> > I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife. I'll note = that Kim Cameron previously expressed concerns about including identity = in his earlier charter critique at = https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/ = . >> >=20 >> > I'm fine with refactoring the authorization protocol. But identity = should be decoupled from the TxAuth work to focus its scope on areas = where innovation is being proposed. Digital identity can always be = added as a layer if needed, just as OpenID Connect layered identity onto = OAuth 2.0. >> >=20 >> > Please revise the charter to remove digital identity from the scope = of the work. >> >=20 >> > 2. Are you willing to author or participate in the development of = the drafts of this WG? >> >=20 >> > Yes >> >=20 >> > 3. Are you willing to help review the drafts of this WG? >> >=20 >> > Yes >> >=20 >> > 4. Are you interested in implementing drafts of this WG? >> >=20 >> > Not at this time. >> >=20 >> > -- Mike >> >=20 >> > -----Original Message----- >> > From: Txauth > On Behalf Of Torsten Lodderstedt >> > Sent: Saturday, March 7, 2020 7:18 AM >> > To: Yaron Sheffer > >> > Cc: txauth@ietf.org >> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG >> >=20 >> > Hi, >> >=20 >> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer = >: >> >>=20 >> >> =EF=BB=BFHi Everyone, >> >>=20 >> >> It appears that momentum is forming around the proposed formation = of a TxAuth working group. We=E2=80=99d like to more formally gauge = interest in proceeding with this work. Please do so by responding to = the following questions: >> >>=20 >> >> 1. Do you support the charter text provided at the end of this = email? Or do you have major objections, blocking concerns or feedback = (if so please elaborate)? >> >=20 >> > I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic. >> >=20 >> > We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability. >> >=20 >> >>=20 >> >> 2. Are you willing to author or participate in the development of = the drafts of this WG? >> >=20 >> > yes >> >=20 >> >>=20 >> >> 3. Are you willing to help review the drafts of this WG? >> >=20 >> > yes >> >=20 >> >>=20 >> >> 4. Are you interested in implementing drafts of this WG? >> >=20 >> > yes >> >=20 >> > best regards, >> > Torsten. >> >=20 >> >>=20 >> >> The call will run for two weeks, until March 21. If you think that = the charter should be amended In a significant way, please reply on a = separate thread. >> >>=20 >> >> The feedback provided here will help the IESG come to a decision = on the formation of a new WG. Given the constraints of the chartering = process, regardless of the outcome of this consensus call, we will be = meeting in Vancouver as a BoF. >> >>=20 >> >> Thanks, >> >> Yaron and Dick >> >>=20 >> >> --- Charter Text Follows --- >> >>=20 >> >> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >> >>=20 >> >> The delegation process will be acted upon by multiple parties in = the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >> >>=20 >> >> Additionally, the delegation process will allow for: >> >>=20 >> >> - Fine-grained specification of access >> >> - Approval of AS attestation to identity claims >> >> - Approval of access to multiple resources and APIs in a single = interaction >> >> - Separation between the party authorizing access and the party = operating the client requesting access >> >> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >> >>=20 >> >> The group will define extension points for this protocol to allow = for flexibility in areas including: >> >>=20 >> >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >> >> - User interaction mechanisms including web and non-web methods >> >> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions >> >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys >> >> - Optimized inclusion of additional information through the = delegation process (including identity) >> >>=20 >> >> Additionally, the group will provide mechanisms for management of = the protocol lifecycle including: >> >>=20 >> >> - Discovery of the authorization server >> >> - Revocation of active tokens >> >> - Query of token rights by resource servers >> >>=20 >> >> Although the artifacts for this work are not intended or expected = to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group = will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to = the new protocol where possible. >> >>=20 >> >> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >> >>=20 >> >> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.=20 >> >>=20 >> >> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >> >>=20 >> >> Milestones to include: >> >> - Core delegation protocol >> >> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures >> >> - Identity and authentication conveyance mechanisms >> >> - Guidelines for use of protocol extension points >> >>=20 >> >>=20 >> >> --=20 >> >> Txauth mailing list >> >> Txauth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/txauth = >> > --=20 >> > Txauth mailing list >> > Txauth@ietf.org >> > https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en --Apple-Mail=_958DE9C9-1108-4978-862A-9CAD3BEB94CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Nat,

To reiterate, = my objection was not to the document but to including it as a formal = deliverable. I think that these kinds of things are incredibly valuable = if used well, and I would envision a wiki page to handle the content = that could be evolved over time.

 =E2=80=94 Justin

On Mar 23, 2020, at 11:08 AM, Nat Sakimura <sakimura@gmail.com> = wrote:

Thanks, Dick. 

Just one point on the = "Architecture" document. Perhaps "Architecture" was a way too loaded = word. 
What I wanted to say was that = documenting in a way or another who/what are the stakeholders/actors and = what are the requirements laid out by them. 
For example, in OAuth 2.0 context, we = tend to collapse Authentication Server and Authorization Server in one, = but in the federated authorization case, clearly delineating them helps = a lot. This can be captured in a use-case document or in a more abstract = document and should have impacts on the actual protocol to be = written. 

Another example is to list and consider stakeholder concerns. = For example, in OAuth 2.0, we have not been explicitly considering the = needs of the who undertakes the monitoring for example. They may not end = up in the protocol that we will be writing, but if there is something = that protocol can help their work, we should perhaps consider them. = However, if we did not document them at all, it would be difficult to = consider them systematically during the protocol design. 

It could even be just a = wiki page, but I thought that kind of document, whatever it is called, = is a useful side document to have handy. 

On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Nat: thanks for chiming in. Useful insights as = always!

Vittorio: I'll reinterpret your statement about "marketing" = the work, to be that we should solve real problems that people don't = have solutions for today. 

AS<->RS = relationship

TL;DR: I think the charter misses the mark in the = AS<->RS relationship being in scope and we should expand it.

In OAuth 2.0 (RFC6749)l, the = AS and RS were separate roles in contrast to OAuth 1.0, but the = interactions / communication between the AS and the RS were out of = scope, as the uses cases at the time had the AS and RS operated by the = same entity. New use cases have a weaker coupling between the AS and RS, = and to enable interop, extensions have been written for Token = Introspection, and JWT Profile for OAuth 2.0 Access Tokens = . 

The = TxAuth charter includes introspection:
 
-= Query of token rights by resource = servers 

-- but does not include the common = design pattern where the RS can directly interpret the token.

Here is proposed = updated text to the line above to be broader in scope than just a = query:

- communication of token = attributes between the authorization server and resource = server


Architecture and Use Case = documents

TL;DR: Yes to use case doc, no to architecture doc.

I agree with Justin that = an architecture document is unlikely to prove useful long term. I = disagree with him on the use cases. I don't think the use cases need to = be exhaustive, but example use cases helps everyone understand everyone = else's primary use cases. If your use case is not similar to others, = then you should write it up and the WG can decide if it is in scope or = not. If it is, it gets added to the use case document. I would consider = this a living document while working on the core protocol. It would NOT = be a use case document that scopes the WG work. The charter does that. = It would be a companion document to the core protocol. I strongly think = a use case document resolves many of the miscommunications that happen = where people are talking past each other, because they don't understand = each other's use case.

Reusing Existing = Technology

TL;DR: we should be reusing = existing specifications where ever possible.

Reading between the lines, I think the = concern around identity may be that the TxAuth charter implies that the = WG is going to create yet-another-identity-representation and ignore all = the previous efforts. I think = creating yet-another-identity-representation to solve use cases = that are already solved with existing representations would be misguided = effort. My own interest in TxAuth is being able to use one protocol to = request and receive any existing and future identity representation. One = of my motivations for writing the XAuth document was to show how = different representations could be requested and received, as this was = missing in XYZ.  If a use case requires a new representation, then = perhaps TxAuth may be a place for that work to happen, but I think it is = more likely to happen in other forums.

It is not clear to me how, or if, = reusing existing technology fits into the charter, but I do strongly = think it should be a tenet of the WG.

On a related note, I = also strongly think that the existing OAuth 2.0 scopes should be easily = used in requests and responses. XAuth shows an example of how that can = be done.

/Dick 




On Fri, Mar = 20, 2020 at 6:39 AM Justin Richer <jricher@mit.edu> wrote:
I agree with a lot of = that argument. Let me see if I can more clearly restate what I was = trying to say earlier in this thread: the relationships between the = different parties are separable and depend on the kind of deployments = and use cases that are being addressed by people. So in an = OAuth/OIDC-style world, we=E2=80=99ve got three components (ignoring = people), and three relationships between them:

C<->AS

C<->RS

AS<->RS

For authorization, these map to =E2=80=9C= how to get a token=E2=80=9D, =E2=80=9Chow to use a token=E2=80=9D, and = =E2=80=9Chow to interpret a token=E2=80=9D. For authentication, it=E2=80=99= s additionally =E2=80=9Chow do I get the authentication info=E2=80=9D, = =E2=80=9Chow do I ask for a profile=E2=80=9D, and =E2=80=9Chow do I know = whose profile this is=E2=80=9D. I still believe this is a good = separation of concerns. The client doesn=E2=80=99t need to know what=E2=80= =99s in the access token, or if it=E2=80=99s a reference or = self-contained, or really concern itself at all with what the RS does = with it. Are there overlaps? Certainly =E2=80=94 the client needs to = know how to ask for a token that the RS will accept for what the client = is going to do, and to do that the client needs to be able to describe = what it wants to do in a way that the AS can interpret and map to a set = of rights that the RS will eventually interpret. 

I believe the proposed = charter already covers this split with the following items:

- Fine-grained = specification of access
- Approval of access to multiple = resources and APIs in a single interaction
- Separation = between the party authorizing access and the party operating the client = requesting access
- = Revocation of active tokens
- Query of token rights by = resource servers

It=E2=80=99s the combination of the = rich request and the lifecycle management that puts the AS and RS in = scope. I think things like declaring a single token format are = absolutely out =E2=80=94 if you want to use JWT, or CWT, or UUID=E2=80=99s= , that=E2=80=99s all just fine. However, something that I think is in = scope is defining a structure for what a token represents. And I think = that if we can do that in this WG in a general way, then that=E2=80=99s = useful. Because then that structure can be represented by mapping to a = token format or an introspection response or a database entry. I think = Nat=E2=80=99s comments on ABAC are important: we are going to need a = place to put those attributes. Whether they=E2=80=99re communicated to = the RS through the token itself or through some other channel is, I = strongly believe, a matter of deployment choice.

So, what can the charter say to make = this more clear?

All that said, I=E2=80=99m against having an architecture = document as a working group output. In my experience, when a WG puts its = effort into a formal architecture doc as a = deliverable, there is a lot of conjectural energy that goes into = what might be a good idea, and then not all of it works out when you try = to hammer the details of making that architecture into a real engineered = thing.You end up baking in assumptions and abstractions that don=E2=80=99t= make sense anymore, and then trying to engineer solutions around those = when they don=E2=80=99t fit right. If the architecture can=E2=80=99t = change in light of new information, which is the case with an RFC, then = it becomes a shackle instead of a scaffold. But a malleable document = that the group can use as a guide while engineering the actual parts =E2=80= =94 yes, that makes sense. The architecture can be refactored and = changed as decisions are made and things come into focus. I feel the = same about use case documents as formal artifacts. 

Thanks, = Nat.
 =E2=80=94 Justin

On Mar 20, 2020, at 2:19 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

I thought I should keep my = mouth shut as anything I say may be deemed biased as my other hat = is the chairman of OIDF, but here is my 2c. 

As Torsten indicated, there is much to = be desired to standardize the AS - RS communication patterns. You may = say that the charter includes it, but I cannot read it out of the = charter just like Torsten could not. As a new protocol, it would be good = to include it. 

In this respect, I am not sure if we should start off from = OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel that = we should architect is more fully. Not mentioning AS - RS relationship = to me feels like an indication of this failure. For that matter, I feel = that the first output of the group should be an architecture document = that takes the concerns from all the relevant stakeholders/actors = in. 

We = should also be cognizant of the access control models like ABAC. = For that, decoupling of identity (=3D set of claims) assertion and = authorization is a necessity. We could optimize it but the base case = should take care of it. (In this respect, I am feeling that OIDC has = perhaps over-optimized.) So, I feel that at least as the first step, = TxAuth should concentre on the Access Control. If I were to go one step = further, it should be modelled so that it can consume various identity = assertions (authenticated identity in ISO/IEC 24760 speak) including ID = Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates = (such as in eIDAS and Japanese National ID scheme)  etc. We are not = going to get to a unified identity world anytime soon. 

Cheers, 

Nat Sakimura


On Wed, Mar = 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
I = believe it's significant that four people have expressed concerns with = including digital identity in the charter (the only concerns voiced as = far as I can tell).  At a minimum, I believe that that warrants = making the inclusion or exclusion of digital identity a discussion topic = during the upcoming virtual BoF, before adopting any charter.

It would be my proposal to initially charter without digital identity = and see how far we get with our energies intentionally focused in that = way.  If the working group decides to recharter to include digital = identity, that can always happen later, after the authorization-focused = work has matured, and once there's a clear case to actually do so.

                    =             -- Mike

-----Original Message-----
From: Justin Richer <jricher@mit.edu>
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten = Lodderstedt <torsten@lodderstedt.net>; txauth@ietf.org
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I = had initially not included it, I was convinced that the kind of identity = protocol that we=E2=80=99re looking at here is a minor addition to the = authorization and delegation end of things.

As you know, much of what=E2=80=99s in OIDC is there to fix problems = with OAuth 2 when it=E2=80=99s used for identity. If OAuth 2 had solved = those problems internally, then OIDC would be much, much simpler and = smaller. We=E2=80=99re now starting at a base where those problems = don=E2=80=99t exist, but we don=E2=80=99t yet know what other problems = there might be.

The market has shown us that the most common application of OAuth 2 is = far and away access to identity information along side access to an API. = I think we need to pay attention to that and not make this separate just = because we did it that way before. And some of the proposed innovations, = including getting and sending VC=E2=80=99s, are all about identity.

Furthermore, this charter does not specify the document and = specification structure of the components, nor does it specify the = publication order or timing of any documents. I personally think that = the identity layer should be separable to an extent, to the point of = publishing that layer in its own spec alongside the core authorization = delegation system. However, that does not mean that it should be = developed elsewhere.

If there is better language to tighten the aspects of an identity = protocol that we will explicitly cover, then I would welcome you to = suggest an amended text to the charter. However, I believe there is = enough interest within the community to work on identity in the context = of this protocol, including a large number of people being OK with it in = the charter, that it would not be a reasonable thing to remove it.

 =E2=80=94 Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
>
> 1.  Do you support the charter text provided at the end of = this email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
>
> I share the concerns about including identity in the charter that = were expressed by Torsten and agreed with by David Skaife.  I'll = note that Kim Cameron previously expressed concerns about including = identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXS= nshX2CahE/.
>
> I'm fine with refactoring the authorization protocol.  But = identity should be decoupled from the TxAuth work to focus its scope on = areas where innovation is being proposed.  Digital identity can = always be added as a layer if needed, just as OpenID Connect layered = identity onto OAuth 2.0.
>
> Please revise the charter to remove digital identity from the scope = of the work.
>
> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>
> Yes
>
> 3.  Are you willing to help review the drafts of this WG?
>
> Yes
>
> 4.  Are you interested in implementing drafts of this WG?
>
> Not at this time.
>
>                  =              -- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Torsten Lodderstedt
> Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <yaronf.ietf@gmail.com>
> Cc: txauth@ietf.org
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - = TxAuth WG
>
> Hi,
>
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>
>> =EF=BB=BFHi Everyone,
>>
>> It appears that momentum is forming around the proposed = formation of a TxAuth working group.  We=E2=80=99d like to more = formally gauge interest in proceeding with this work.  Please do so = by responding to the following questions:
>>
>> 1.  Do you support the charter text provided at the end of = this email?  Or do you have major objections, blocking concerns or = feedback (if so please elaborate)?
>
> I=E2=80=98m in although I have to admit I=E2=80=98m slightly = concerned the scope of the charter is too broad, e.g. identify alone is = a huge topic.
>
> We need to keep an eye on this aspect in order to make sure, the = group is able to work effectively and the specs we will be producing are = as simple as possible and foster interoperability.
>
>>
>> 2.  Are you willing to author or participate in the = development of the drafts of this WG?
>
> yes
>
>>
>> 3.  Are you willing to help review the drafts of this = WG?
>
> yes
>
>>
>> 4.  Are you interested in implementing drafts of this = WG?
>
> yes
>
> best regards,
> Torsten.
>
>>
>> The call will run for two weeks, until March 21. If you think = that the charter should be amended In a significant way, please reply on = a separate thread.
>>
>> The feedback provided here will help the IESG come to a = decision on the formation of a new WG. Given the constraints of the = chartering process, regardless of the outcome of this consensus call, we = will be meeting in Vancouver as a BoF.
>>
>> Thanks,
>> Yaron and Dick
>>
>> --- Charter Text Follows ---
>>
>> This group is chartered to develop a fine-grained delegation = protocol for authorization, identity, and API access. This protocol will = allow an authorizing party to delegate access to client software through = an authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.
>>
>> The delegation process will be acted upon by multiple parties = in the protocol, each performing a specific role. The protocol will = decouple the interaction channels, such as the end user=E2=80=99s = browser, from the delegation channel, which happens directly between the = client and the authorization server (in contrast with OAuth 2.0 which is = initiated by the client redirecting the user=E2=80=99s browser). The = client and AS will involve a user to make an authorization decision as = necessary through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.
>>
>> Additionally, the delegation process will allow for:
>>
>> - Fine-grained specification of access
>> - Approval of AS attestation to identity claims
>> - Approval of access to multiple resources and APIs in a single = interaction
>> - Separation between the party authorizing access and the party = operating the client requesting access
>> - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications
>>
>> The group will define extension points for this protocol to = allow for flexibility in areas including:
>>
>> - Cryptographic agility for keys, message signatures, and proof = of possession
>> - User interaction mechanisms including web and non-web = methods
>> - Mechanisms for conveying user, software, organization, and = other pieces of information used in authorization decisions
= >> - Mechanisms for presenting tokens to resource servers and = binding resource requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information through the = delegation process (including identity)
>>
>> Additionally, the group will provide mechanisms for management = of the protocol lifecycle including:
>>
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>>
>> Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.
>>
>> This group is not chartered to develop extensions to OAuth 2.0, = and as such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth = 2.0.
>>
>> The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.
>>
>> The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus.
>>
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol for = TLS, detached HTTP signature, and embedded HTTP signatures
>> - Identity and authentication conveyance mechanisms
>> - Guidelines for use of protocol extension points
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
= > --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


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

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


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

= --Apple-Mail=_958DE9C9-1108-4978-862A-9CAD3BEB94CC-- From nobody Mon Mar 23 12:32:28 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0646C3A0D44 for ; Mon, 23 Mar 2020 12:32:23 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 aAjl8xXMqskK for ; Mon, 23 Mar 2020 12:32:19 -0700 (PDT) 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 75D133A0CE9 for ; Mon, 23 Mar 2020 12:32:18 -0700 (PDT) Received: from [192.168.1.5] (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 02NJWB6t000954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Mar 2020 15:32:11 -0400 From: Justin Richer Message-Id: <81F2A493-6F7D-4B66-B675-016B40551315@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_23B42A15-1868-4E0C-96BD-138576F068ED" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Mar 2020 15:32:11 -0400 In-Reply-To: Cc: Dick Hardt , Kim , Filip Skokan , Torsten Lodderstedt , "txauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 19:32:25 -0000 --Apple-Mail=_23B42A15-1868-4E0C-96BD-138576F068ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mike, A registry is a specific implementation for publishing a schema, and so = I don=E2=80=99t think it=E2=80=99s appropriate to list it in the charter = as either preferred or prohibited when the real goal is to define the = boundaries and touchpoints of this protocol. =E2=80=94 Justin > On Mar 23, 2020, at 3:25 PM, Mike Jones = wrote: >=20 > I agree that the updates represent some progress. I=E2=80=99d like to = tighten the statement about what the group is not chartered to do to add = new registries for identity claims are also out of scope. I propose = that revise the statement below per my text in red: > =20 > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, or new registries for listing such schema elements or = identity attributes, unless a viable existing format is not available. > =20 > Like Torsten, Kim, and others, I=E2=80=99d still rather that we = tackled identity separately, if at all. My proposal above is my = fallback position if we can=E2=80=99t get consensus to remove identity = from the charter. > =20 > -- Mike > =20 > From: Dick Hardt >=20= > Sent: Saturday, March 21, 2020 12:56 PM > To: Mike Jones >; Kim >; Filip Skokan >; Torsten Lodderstedt = > > Cc: txauth@ietf.org > Subject: Re: [Txauth] Proposed TxAuth charter Text > =20 > (replying with those that had expressed concerns about the charter on = the To: list to bring it to the top of their inbox) > =20 > Mike, Kim, Torsten, Filip: are your concerns addressed with the = changes below? > =20 > (apologies to anyone I missed in the To: list) > =20 > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer > wrote: > After some great discussions on the list in the last week, Yaron, = Dick, and I have pulled together a new proposed charter. I think this is = version 5.0? But I forget exactly. :) > =20 > I=E2=80=99ve highlighted the new lines in bold here, for those = reading this email in HTML. There=E2=80=99s a diff available online at = http://www.mergely.com/RehoJJvW/ = (note: go to view->word wrap to be able to read it better). I=E2=80=99m = attaching the .DIFF file generated by Mergely as well, for those of us = crusty old unix type folks who like to see that. > =20 > =20 > =20 > =20 > =20 > This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 > =20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. > =20 > Additionally, the delegation process will allow for: > =20 > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Support for multiple access tokens in a single request > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party = operating the client requesting access > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications > =20 > The group will define extension points for this protocol to allow for = flexibility in areas including: > =20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation = process (including asserted identity claims) > =20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: > =20 > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an = access token > =20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. > =20 > This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. > =20 > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. > =20 > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 > =20 > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. > =20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, = detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > =20 > =20 > =20 > =20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_23B42A15-1868-4E0C-96BD-138576F068ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mike,

A = registry is a specific implementation for publishing a schema, and so I = don=E2=80=99t think it=E2=80=99s appropriate to list it in the charter = as either preferred or prohibited when the real goal is to define the = boundaries and touchpoints of this protocol.

 =E2=80=94 Justin

On Mar 23, 2020, at 3:25 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I agree that the updates = represent some progress.  I=E2=80=99d like to tighten the statement = about what the group is not chartered to do to add new registries for = identity claims are also out of scope.  I propose that revise the = statement below per my text in red:
 
The group is chartered to develop mechanisms = for conveying identity information within the protocol including = identifiers (such as email addresses, phone numbers, usernames, and = subject identifiers) and assertions (such as OpenID Connect ID Tokens, = SAML Assertions, and Verifiable Credentials). The group is not chartered = to develop new formats for identifiers or assertions, nor is the group = chartered to develop schemas for user information, profiles, or other = identity attributes, or new registries for listing such schema elements or = identity attributes, unless a viable = existing format is not available.
 
Like = Torsten, Kim, and others, I=E2=80=99d still rather that we tackled = identity separately, if at all.  My proposal above is my fallback = position if we can=E2=80=99t get consensus to remove identity from the = charter.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Dick Hardt <dick.hardt@gmail.com> 
Sent: Saturday, March 21, 2020 = 12:56 PM
To: Mike Jones <Michael.Jones@microsoft.com>; Kim <kim@identityblog.com>; = Filip Skokan <panva.ip@gmail.com>; = Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: txauth@ietf.org
Subject: Re: [Txauth] Proposed = TxAuth charter Text
 
(replying with those that had expressed = concerns about the charter on the To: list to bring it to the top of = their inbox)
 
Mike, Kim, Torsten, Filip: are your concerns addressed with = the changes below?
 
(apologies to anyone I missed in the To: list)
 
On Sat, Mar 21, 2020 at = 12:41 PM Justin Richer <jricher@mit.edu> wrote:
After = some great discussions on the list in the last week, Yaron, Dick, and I = have pulled together a new proposed charter. I think this is version = 5.0? But I forget exactly. :)
 
I=E2=80=99ve highlighted the new lines in bold here, =  for those reading this email in HTML. There=E2=80=99s a diff = available online at  http://www.mergely.com/RehoJJvW/  (note: go to = view->word wrap to be able to read it better). I=E2=80=99m attaching = the .DIFF file generated by Mergely as well, for those of us crusty old = unix type folks who like to see that.
 
 
 
 
 
This = group is chartered to develop a fine-grained delegation protocol for = authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. 
 
The delegation process will be acted = upon by multiple parties in the protocol, each performing a specific = role. The protocol will decouple the interaction channels, such as the = end user=E2=80=99s browser, from the delegation channel, which happens = directly between the client and the authorization server (in contrast = with OAuth 2.0 which is initiated by the client redirecting the user=E2=80= =99s browser). The client and AS will involve a user to make an = authorization decision as necessary through interaction mechanisms = indicated by the protocol. This decoupling avoids many of the security = concerns and technical challenges of OAuth 2.0 and provides a = non-invasive path for supporting future types of clients and interaction = channels.
 
Additionally, the delegation process will allow for:
 
- Fine-grained specification of = access
- Approval of AS attestation to = identity claims
- Approval of access to multiple = resources and APIs in a single interaction
- Support for multiple access tokens in a = single request
- Support for directed, = audience-restricted access tokens
- Separation between the party authorizing access and the = party operating the client requesting access
- A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications
 
The group will define extension points = for this protocol to allow for flexibility in areas including:
 
- Cryptographic agility for keys, = message signatures, and proof of possession 
- User interaction mechanisms including web and non-web = methods
- Mechanisms for conveying user, = software, organization, and other pieces of information used in = authorization decisions
- Mechanisms for = presenting tokens to resource servers and binding resource requests to = tokens and associated cryptographic keys
- Optimized inclusion of additional information through the = delegation process (including asserted identity claims)
 
Additionally, the group will provide = mechanisms for management of the protocol lifecycle including:
 
- Discovery of the authorization = server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate = the access granted by an access token
 
Although the artifacts for this work = are not intended or expected to be backwards-compatible with OAuth 2.0 = or OpenID Connect, the group will attempt to simplify migrating from = OAuth 2.0 and OpenID Connect to the new protocol where possible.
 
This group is not chartered to develop = extensions to OAuth 2.0, and as such will focus on new technological = solutions not necessarily compatible with OAuth 2.0. Functionality that = builds directly on OAuth 2.0 will be developed in the OAuth Working = Group, including functionality back-ported from the protocol developed = here to OAuth 2.0.
 
The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods.
 
The group is chartered to = develop mechanisms for conveying identity information within the = protocol including identifiers (such as email addresses, phone numbers, = usernames, and subject identifiers) and assertions (such as OpenID = Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The = group is not chartered to develop new formats for identifiers or = assertions, nor is the group chartered to develop schemas for user = information, profiles, or other identity attributes, unless a viable = existing format is not available. 
 
The initial work will focus on using = HTTP for communication between the client and the authorization server, = taking advantage of optimization features of HTTP2 and HTTP3 where = possible, and will strive to enable simple mapping to other protocols = such as COAP when doing so does not conflict with the primary focus.
 
Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol = for TLS, detached HTTP signature, and embedded HTTP signatures
- Identity and authentication conveyance mechanisms
- Guidelines for use of protocol extension points
 
 
 
 
-- 
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_23B42A15-1868-4E0C-96BD-138576F068ED-- From nobody Mon Mar 23 12:39:05 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB273A0CCB for ; Mon, 23 Mar 2020 12:39:02 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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=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 oQGZiz4YzCm7 for ; Mon, 23 Mar 2020 12:38:59 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-dm3nam06on071a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe56::71a]) (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 0249E3A0D4C for ; Mon, 23 Mar 2020 12:38:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IYhev9aqiSOXnODdTEi9quYFnHkeLhm49qQ1nBNL0ZFkB8vI9agXiV5888C7isfBMzFNJv+WMl0k8UVB0RrmS0SKusjvFKCxvdslwh+n3F/0LuFTVscN4EKNE1vvg7xy2wp100COE0PLBnz/zvHc90HwFsn8/4QxzcFocDGVsvl/IGl+PdiMxLEgWadYycdIYX/ENZO89PplvULuYXEEX2A8xBKMDIOZ8Gkn/s1ReRgSOQaI4Q1yN+wcrp2dHGExqAe+MTje7f172ZP8YcVN4eagFkKuIfSVU5N2zVUzIITOBkMd4PM1RoMok0+Ks4IpkeTvssz8wuoMg+vWhgkxsg== 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=wLczw3Mj6Of2OhzCvOHxbN2pLTBUhEO11X4Of8rzJ+c=; b=dbXtX3SfOmk/eJclBRm3PDP7JwTI9bVhR0Ac3wByjzKlrliNll+lLQKRDLBAkDQbtwdIBwX73OWMp6gGKs+nIXHVPUwX2fNBOSRzsdwyxPFnDvxsnsmhkwsy2DHxO5n0i8Mx6JLUfpAArnlP2PZ1R892pjP0IBHPC8A3p7CpPoLOHzZYrmqaLCd36+YrrU0bdwp9GhoFJRe2J4zywzAD1mMrJlU3619pWks2IFZtseIiv2aicX86gtCgn1faGlkb19HC6uj7b3dglD+ArU//97G1p4VpoR8MLqGXROHiAVekkxvWxyRPPDv3f1TBPl1KiSi1HzkYah909N8HZClO7g== 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=wLczw3Mj6Of2OhzCvOHxbN2pLTBUhEO11X4Of8rzJ+c=; b=aJyqbTotY0VBYoBHA7lwgtGHi5LOU63BStlRJkjnNfPJGOXGHQe6faO0i86L8c254TqJYGQkpEDpYxyAXD7Tx9CenpxwDV9ltZIW77LDQqM/3VoQa7a9Zu7cOolNt6siy4Y/tJeLaDr29MAQ75in/4ErfCntkKHkh9r/1NoGZoI= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0793.namprd00.prod.outlook.com (2603:10b6:610:6f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2885.0; Mon, 23 Mar 2020 19:38:57 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9%7]) with mapi id 15.20.2885.000; Mon, 23 Mar 2020 19:38:57 +0000 From: Mike Jones To: David Skaife , Justin Richer CC: Yaron Sheffer , "txauth@ietf.org" , Dick Hardt Thread-Topic: [Txauth] WG name: TxAuth? XAuth? Something else? Thread-Index: AdYBSqgmJZVhTdCyQFaGbi6iv7UfjA== Date: Mon, 23 Mar 2020 19:38:56 +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_ActionId=32370322-a450-4741-b2a7-0000b79a8ce0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-23T19:29:12Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 41ff9185-52fe-4a80-94cd-08d7cf61d3f7 x-ms-traffictypediagnostic: CH2PR00MB0793: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(346002)(376002)(366004)(39860400002)(136003)(396003)(199004)(33656002)(76116006)(66476007)(66556008)(8676002)(64756008)(81156014)(66946007)(81166006)(6506007)(861006)(86362001)(7696005)(53546011)(55016002)(9686003)(66574012)(110136005)(71200400001)(5660300002)(66446008)(54906003)(10290500003)(8936002)(52536014)(8990500004)(316002)(478600001)(4326008)(186003)(2906002)(966005)(26005)(76236002)(99710200001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0793; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ByB/Nfjhe5hC/TVsMWeAjxVrdAlOPhPme24yv5Lwwv8mDlVenLsCf6GVdGKQXtE/yUd+8dtoX33ZUb4HUextlgr/eWw+xgc54rmAPVGmmhydUVaIvtRFwusLm1wNdrPkyfjdhPhQ3t4OewvVfSsoNrsJLf+ssY6waFBF3j1pSVX9X2yVqpGjOizPX0r6fVh6OPeHMQNjaPH1ipmWNvs3FdBY4n5XwxDspEVaR469ZwQco7KuF8BgULfmjW/a+67OwpQVIrwubG+oXgyzVIYkcqTxniOW49MplWjlLWPX2muofCEuHMHfB+T+Kmwfq4GITt4RY7guvwcRg5RkkV7QS5KWX6DKdj5tnguOKSno4j+DbkrBezbW6xypWx5ni+0us7vanU6CbqCA2UyomqAw+y7IiHAGz31Y/PDau4Sm2toiiszhuot2Z4uwHeDJ/6INceZfVlUavJccud/jqySPbZr8QSSFZQ3lSDY1jDQvJmymtNk7iBEyeJRgSzcJOVB/Ad/LBOPl3IjyyphPej0UryXrN7+hV2HYAqeilRsgiPTp0vrrU+k7FodkZyt0cONlJb75BlMIjQ4z8ZNMl6SYpw== x-ms-exchange-antispam-messagedata: 2Iy4b6HvQAKIhldFCDnYsG8X6ZZeUeF2xiZoldSg0rH9fN5uohsShAJY0jO5n/UJHtGDas/S2409WrcrJh5GV1ZW7MF+VwxiOXY78FsVX1cFt4E6Ib8zkxKK365CHKj70Zg4dL0bTHgRiGSZT2b1MA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679FE99B1703FA111BBCADEF5F00CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41ff9185-52fe-4a80-94cd-08d7cf61d3f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 19:38:56.9427 (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: fiFFF+kAgQGCwGSlErEwnrTDwBE0VhAoacUWTVxeIAAN6qx4SxY6BzN/XZp4jySmB9pDXX8326iStv2g/0CpUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0793 Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 19:39:03 -0000 --_000_CH2PR00MB0679FE99B1703FA111BBCADEF5F00CH2PR00MB0679namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gYnJhaW5zdG9ybWluZyBtb2Rl4oCmDQoNCiAgKiAgIERpc2FnZ3JlZ2F0ZWQgQXV0aG9yaXph dGlvbiAoRGlzQXV0aCkNCiAgKiAgIENvbXBvbmVudGl6ZWQgQXV0aG9yaXphdGlvbiAoQ29tcEF1 dGgpDQogICogICBCdWlsZC1Zb3VyLU93biBBdXRob3JpemF0aW9uIChCWU9BdXRoKQ0KICAqICAg RG8tSXQtWW91cnNlbGYgQXV0aG9yaXphdGlvbiAoRElZQXV0aCkNCiAgKiAgIFJlZmFjdG9yZWQg QXV0aG9yaXphdGlvbiAoUmVBdXRoIG9yIFJlZkF1dGgpDQoNCkFuZCBmb3IgZnVu4oCmDQoNCiAg KiAgIERpc21lbWJlcmVkIEF1dGhvcml6YXRpb24NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVHhhdXRoIDx0 eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIERhdmlkIFNrYWlmZQ0KU2VudDog U2F0dXJkYXksIE1hcmNoIDIxLCAyMDIwIDExOjIyIEFNDQpUbzogSnVzdGluIFJpY2hlciA8anJp Y2hlckBtaXQuZWR1Pg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47 IHR4YXV0aEBpZXRmLm9yZzsgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTdWJq ZWN0OiBSZTogW1R4YXV0aF0gV0cgbmFtZTogVHhBdXRoPyBYQXV0aD8gU29tZXRoaW5nIGVsc2U/ DQoNCkkgdGhpbmsgd2UncmUgc2F5aW5nIHRoZSBzYW1lIHRoaW5nIHdpdGggcmVnYXJkcyB0byB0 aGUgd29ya2luZyBncm91cCBuYW1lIC0gSSB3YXMgc2F5aW5nIGl0IGlzbid0IHBhcnRpY3VsYXJs eSBpbXBvcnRhbnQgaW4gY29tcGFyaXNvbiB0byB0aGUgbmFtZSBvZiB0aGUgcHJvdG9jb2wgKHdo aWNoIG9idmlvdXNseSBpcyB2ZXJ5IGltcG9ydGFudCkuDQoNCk9uIFNhdCwgTWFyIDIxLCAyMDIw IGF0IDY6MTggUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVy QG1pdC5lZHU+PiB3cm90ZToNCkkgZGlzYWdyZWUgb24gdGhlIHdvcmtpbmcgZ3JvdXAgbmFtZSBi ZWluZyBzdXBlciBpbXBvcnRhbnQuIE5vYm9keSBrbm93cyB0aGF0IHRoZSBPQXV0aCBXRyBpcyBh Y3R1YWxseSBuYW1lZCDigJxUaGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV29ya2luZyBH cm91cOKAnSwgYW5kIG5vYm9keSBjYXJlcy4NCg0KTXkgcHJvcG9zYWwgaXMgdGhhdCB3ZSBuYW1l IHRoZSBwcm90b2NvbCB3ZSB3b3JrIG9uIOKAnFR4QXV0aOKAnSAoYW5kIGtlZXAgdGhlIG1haWxp bmcgbGlzdCksIGFuZCB0aGF0IHdlIG5hbWUgdGhlIHdvcmtpbmcgZ3JvdXAgc29tZXRoaW5nIGxp a2Ug4oCcTmV4dCBHZW5lcmF0aW9uIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29s4oCdIHRvIHNh eSB3aGF0IHdl4oCZcmUgZG9pbmcuDQoNCiAtLSBKdXN0aW4NCg0KDQpPbiBNYXIgMjEsIDIwMjAs IGF0IDI6MDggUE0sIERhdmlkIFNrYWlmZSA8Ymx1ZS5yaW5nZWQub2N0b3B1cy5ndXlAZ21haWwu Y29tPG1haWx0bzpibHVlLnJpbmdlZC5vY3RvcHVzLmd1eUBnbWFpbC5jb20+PiB3cm90ZToNCg0K SnVzdCB0byB0aHJvdyBpbiBhbm90aGVyIHN1Z2dlc3Rpb24sIHRvIGFkZHJlc3MgWWFyb24ncyBw b2ludCBhYm91dCBzb21lIHBlb3BsZSBtaXN0YWtlbmx5IHRoaW5raW5nIHRoYXQgIkF1dGgiIHN0 YW5kcyBmb3IgYXV0aGVudGljYXRpb24gcmF0aGVyIHRoYW4gYXV0aG9yaXphdGlvbiwgaG93IGFi b3V0IG5hbWluZyB0aGUgd29ya2luZyBncm91cCBBdXRoWg0KTmljZSBhbmQgc2ltcGxlLCBhbmQg aXQgbWFrZXMgaXQgY2xlYXIgd2hhdCB0aGUgZ3JvdXAgaXMgZm9jdXNlZCBvbi4NCg0KSSB0aGlu ayB0aGUgbmFtZSBvZiB0aGUgYWN0dWFsIHByb3RvY29sIHRoYXQgd2UgcHJvZHVjZSBpcyBmYXIs IGZhciBtb3JlIGltcG9ydGFudCB0aGF0IHRoZSBuYW1lIG9mIHRoZSB3b3JraW5nIGdyb3VwIC0g YW5kIHRoZSBuYW1lIG9mIHRoYXQgcHJvdG9jb2wgZG9lc24ndCBuZWVkIHRvIGNvcnJlbGF0ZSB0 byB0aGUgV0cgbmFtZS4gQWxzbywgd2UgaGF2ZSBtdWNoIG1vcmUgdGltZSBiZWZvcmUgd2UgbmVl ZCB0byBkZWNpZGUgb24gdGhlIG5hbWUgb2YgdGhhdCBwcm90b2NvbCwgZXZlbiBpZiB0aGUgaW5p dGlhbCBkcmFmdCBkb2N1bWVudHMgdGhhdCB3ZSBwcm9kdWNlIGVuZCB1cCB1c2luZyBhIHBsYWNl aG9sZGVyIG5hbWUuDQoNCk9uIFNhdCwgTWFyIDIxLCAyMDIwIGF0IDU6NDQgUE0gSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkFz IHlvdSBjYW4gc2VlIGluIHRoZSBlbWFpbCB5b3UgcmVwbGllZCB0bywgdGhhdCBpcyBub3QgZXZl biBjbG9zZSB0byB3aGF0IEkgc2FpZC4gSSBiZWxpZXZlIGl0IGlzIGEgdHJhbnNhY3Rpb24sIGFu ZCB0aGVyZWZvcmUsIEkgZG8gbm90IGFncmVlIHRoYXQgaXTigJlzIG5vdCBhIHRyYW5zYWN0aW9u Lg0KDQpCdXQgaWYgd2UgdGFrZSDigJxUcmFuc2FjdGlvbmFs4oCdIG91dCBvZiB0aGUgV0cgdGl0 bGUsIEkgd29u4oCZdCBiZSBvZmZlbmRlZC4gSWYgd2UganVzdCBjYWxsIGl0IOKAnFR4QXV0aOKA nSB3aXRob3V0IGV4cGFuc2lvbiwgdGhlbiB0aGF04oCZcyBmaW5lLg0KDQpJIGRvIG5vdCBsaWtl IGNhbGxpbmcgaXQg4oCcWEF1dGjigJ0uIFRoZSB0ZXJtIOKAnFRBdXRoIiB3YXMgZmxvYXRlZCBk dXJpbmcgbmFtaW5nIHRoZSBsaXN0LCBidXQgcmVqZWN0ZWQgYmVjYXVzZSAoYW1vbmcgb3RoZXIg cmVhc29ucykgaXQgd291bGQgbGlrZWx5IGJlIGF3a3dhcmRseSBwcm9ub3VuY2VkIGFzIOKAnHRv d3Ro4oCdIG9yIHNvbWV0aGluZy4gVHhBdXRoIHJlYWRzIGFzIOKAnFRlZSAtIGV4IC0gb3Ro4oCd IG1vcmUgbmF0dXJhbGx5LCB3aGljaCB3YXMgdGhlIGludGVudC4NCg0KU28gaG93IGFib3V0IHdl IHRha2UgYSBwYWdlIGZyb20gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgYW5kIG5hbWUgaXQ6DQoN ClR4QXV0aCAtIE5leHQgR2VuZXJhdGlvbiBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwDQoNCg0KIOKAlCBKdXN0aW4NCg0KDQpPbiBNYXIgMjEsIDIwMjAsIGF0IDE6MTUg UE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpUbyBjbGFyaWZ5IC0tIHlvdSBhZ3JlZSBpdCBpcyBub3QgYSB0 cmFuc2FjdGlvbiwgYW5kIHdlIHdpbGwgdGFrZSB0aGUgd29yZCB0cmFuc2FjdGlvbiBvdXQgb2Yg dGhlIFdHIHRpdGxlPw0KDQpPbiBGcmksIE1hciAyMCwgMjAyMCBhdCA1OjUzIFBNIEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpE aWNrLCB0aGFua3MgZm9yIHB1bGxpbmcgdGhlIGRlZmluaXRpb25zIHVwOg0KDQo+IGEgY29tbXVu aWNhdGl2ZSBhY3Rpb24gb3IgYWN0aXZpdHkgaW52b2x2aW5nIHR3byBwYXJ0aWVzIG9yIHRoaW5n cyB0aGF0IHJlY2lwcm9jYWxseSBhZmZlY3Qgb3IgaW5mbHVlbmNlIGVhY2ggb3RoZXINCg0KVGhp cyBpcyB0aGUga2luZCBvZiB0aGluZyB0aGF0IEkgaGFkIGluIG1pbmQuIFRoZSBjbGllbnQgYW5k IHRoZSBBUyBhcmUgaW4gYSBjb252ZXJzYXRpb24gb3ZlciB0aW1lIHRoYXQgZWFjaCBvbmUgY29u dHJpYnV0ZXMgdG8gYW5kIGVhY2ggY2hhbmdlcy4NCg0KQWxzbyDigJQgd2UgY2FuIGp1c3QgYXMg ZWFzaWx5IGRlY2lkZSB0aGF0IOKAnFR4QXV0aOKAnSBkb2VzbuKAmXQgc3RhbmQgZm9yIOKAnFRy YW5zYWN0aW9uYWwgQXV0aOKAnSBtdWNoIHRoZSBzYW1lIHdheSB3ZSBkZWNpZGVkIHRoYXQgdGhl IOKAnE/igJ0gaW4g4oCcT0F1dGjigJ0gZG9lc27igJl0IHN0YW5kIGZvciDigJxPcGVu4oCdIGFu eW1vcmUuDQoNCk5vbmUgb2YgdGhlIGFyZ3VtZW50cyBiZWxvdyBpbiBmYXZvciBvZiBYQXV0aCBo YXZlIG1hZGUgbWUgbGlrZSB0aGF0IG5hbWUgYmV0dGVyLiBJZiBpdOKAmXMganVzdCBhIOKAnHBs YWNlaG9sZGVy4oCdIG5hbWUsIHRoZW4gd2h5IGNvbWUgdXAgd2l0aCBzb21ldGhpbmcgbmV3Pw0K DQog4oCUIEp1c3Rpbg0KDQoNCk9uIE1hciAyMCwgMjAyMCwgYXQgMzozMiBQTSwgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3Jv dGU6DQoNCg0KDQoNCm5vdCBhIHRyYW5zYWN0aW9uIC0gdGhlcmUgYXJlIG11bHRpcGxlIHRyYW5z YWN0aW9ucw0KDQpiYWNrY2hhbm5lbCBpbm5vdmF0aW9uIGlzIGNvbWJpbmF0aW9uIG9mIGhlcmUg aXMgd2hvIEkgYW0sIGFuZCBoZXJlIGlzIHdoYXQgSSB3YW50IHRvIGRvDQoNCg0KY2hpbGRob29k IHRyYXVtYSB0aGVyYXB5IGdyb3VwDQoNCg0KDQpPbiBNb24sIE1hciAxNiwgMjAyMCBhdCA2OjU2 IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1 Pj4gd3JvdGU6DQpZZXMsIG5hbWluZyB0aGluZ3MgaXMgaGFyZCDigJQgYnV0IEkgc3RpbGwgYmVs aWV2ZSBpbiB0aGUgbmFtZSBUeEF1dGguIFdl4oCZcmUgbW92aW5nIGJleW9uZCBPQXV0aCwgYW5k IHRha2luZyB0aGUgcHJvY2VzcyBvZiBnZXR0aW5nIGFuIGF1dGhvcml6YXRpb24gZGVsZWdhdGVk IHRvIHRoZSBjbGllbnQgc29mdHdhcmUgYXMgYSBtdWx0aS1zdGVwLCBtdWx0aS1wYXJ0eSB0cmFu c2FjdGlvbiBpcywgSSBiZWxpZXZlLCB0aGUga2V5IGluc2lnaHQgdGhhdOKAmXMgbGV0dGluZyB1 cyBtb3ZlIGJleW9uZCBPQXV0aOKAmXMgbGltaXRhdGlvbnMgaGVyZS4gSXTigJlzIG5vdCBqdXN0 IGFib3V0IGdvaW5nIHRvIHRoZSBBUyBmaXJzdCDigJQgd2UgaGFkIHRoYXQgaW4gT0F1dGggMSBh bmQgd2XigJlyZSBwYXRjaGluZyB0aGF0IGludG8gT0F1dGggMiB3aXRoIFBBUi4gSSByZWFsbHkg dGhpbmsgaXTigJlzIGFib3V0IHRoZSB0cmFuc2FjdGlvbiBhdCB0aGUgY29yZS4uDQoNCk9BdXRo IDIuMCBoYWQgbXVsdGktc3RlcCwgbXVsdGktcGFydHkuIFR4QXV0aCBleHRlbmRzIHRoYXQuDQoN CkkgdGhpbmsgdGhlIGJpZyBzaGlmdCBpcyBnb2luZyB0byB0aGUgQVMuIFRoaXMgZW5hYmxlcyB0 aGUgcmVxdWVzdCB0byBiZSByaWNoZXIgd2l0aCBKU09OLCBpbnN0ZWFkIG9mIG5hbWUvdmFsdWUg cGFpcnMgcGFyYW1ldGVycyBpbiBhIFVSSS4gSXQgYWxsb3dzIHRoZSBjbGllbnQgYW5kIEFTIHRv IG5lZ290aWF0ZSwgYW5kIHRvIHNob3J0IGNpcmN1aXQgaGF2aW5nIHRvIHJlZGlyZWN0IHRoZSB1 c2VyIHRvIHRoZSBBUy4gUEFSIGRvZXMgc29tZSBvZiB0aGlzLCBidXQgaXQgaXMgY29uc3RyYWlu ZWQgYnkgaGF2aW5nIHRvIGRvIGl0IGluIHRoZSBPQXV0aCAyLjAgY29udGV4dC4NCg0KTXkgY29u Y2VybiBpcyB0aGF0IHRoZSBwcm90b2NvbCBpcyBNVUNIIE1PUkUgdGhhbiBhIHRyYW5zYWN0aW9u LiBXaGlsZSB0aGUgaW5pdGlhbCBpbnRlcmFjdGlvbiBiZXR3ZWVuIGNsaWVudCwgQVMsIHVzZXIg YW5kIFJPIGlzIGEgdHJhbnNhY3Rpb24uIFRoZSBwcm90b2NvbCBhbHNvIGNvdmVycyB0aGUgY2xp ZW50IGFuZCBSUyBpbnRlcmFjdGlvbnMuIFRoZSBhY2Nlc3MgdG9rZW4gcmVmcmVzaGVzLiBBY2Nl c3MgdG9rZW4gcmV2b2NhdGlvbi4gQWNjZXNzIHRva2VuIGludHJvc3BlY3Rpb24uIEFzIGRlc2Ny aWJlZCBpbiB0aGUgY2hhcnRlciwgdGhlcmUgaXMgYSB3aG9sZSBsaWZlY3ljbGUsIHRoYXQgY29u c2lzdHMgb2YgbXVsdGlwbGUgdHJhbnNhY3Rpb25zLg0KDQpGcm9tIGh0dHBzOi8vd3d3Lm1lcnJp YW0td2Vic3Rlci5jb20vZGljdGlvbmFyeS90cmFuc2FjdGlvbjoNCg0KRGVmaW5pdGlvbiBvZiB0 cmFuc2FjdGlvbg0KMWE6IHNvbWV0aGluZyB0cmFuc2FjdGVkPGh0dHBzOi8vd3d3Lm1lcnJpYW0t d2Vic3Rlci5jb20vZGljdGlvbmFyeS90cmFuc2FjdGVkPmVzcGVjaWFsbHkgOiBhbiBleGNoYW5n ZSBvciB0cmFuc2ZlcjxodHRwczovL3d3dy5tZXJyaWFtLXdlYnN0ZXIuY29tL2RpY3Rpb25hcnkv dHJhbnNmZXI+IG9mIGdvb2RzLCBzZXJ2aWNlcywgb3IgZnVuZHNlbGVjdHJvbmljIHRyYW5zYWN0 aW9ucw0KYjogdHJhbnNhY3Rpb25zIHBsdXJhbCA6IHRoZSBvZnRlbiBwdWJsaXNoZWQgcmVjb3Jk IG9mIHRoZSBtZWV0aW5nIG9mIGEgc29jaWV0eSBvciBhc3NvY2lhdGlvbg0KMmE6IGFuIGFjdCwg cHJvY2Vzcywgb3IgaW5zdGFuY2Ugb2YgdHJhbnNhY3Rpbmc8aHR0cHM6Ly93d3cubWVycmlhbS13 ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5L3RyYW5zYWN0aW5nPg0KYjogYSBjb21tdW5pY2F0aXZlIGFj dGlvbiBvciBhY3Rpdml0eSBpbnZvbHZpbmcgdHdvIHBhcnRpZXMgb3IgdGhpbmdzIHRoYXQgcmVj aXByb2NhbGx5IGFmZmVjdCBvciBpbmZsdWVuY2UgZWFjaCBvdGhlcg0KDQpDYWxsaW5nIHRoZSBw cm90b2NvbCBhIHRyYW5zYWN0aW9uIHdpbGwgY29uZnVzaW5nIHRvIHBlb3BsZS4NCg0KDQpIYXZp bmcgY29tZSBvZiBhZ2UgaW4gdGhlIDE5OTDigJlzLCBJIGhhdmUgcGFydGljdWxhciBkaXNsaWtl IGZvciBYQXV0aC4gSXQgc291bmRzIHRvbyDigJxYLVRSRU1F4oCdIGFuZCDigJxYLUNJVElOR+KA nSwgYW5kIGlmIHlvdSByZWFkIGVpdGhlciBvZiB0aG9zZSB3aXRoIGEgZ3Jvd2xpbmcgeWVsbCBp biB5b3VyIGhlYWQgdGhlbiB5b3Uga25vdyBleGFjdGx5IHdoYXQgSeKAmW0gdGFsa2luZyBhYm91 dC4NCg0KSW4gY2FzZSB5b3UgYXJlIGNvbmZ1c2VkLCB0aGlzIGlzIG5vdCBhIGNoaWxkaG9vZCB0 cmF1bWEgc3VwcG9ydCBncm91cC4gIDopDQoNClVubGlrZSAiWC1UUkVNRSIgb3IgIlgtQ0lUSU5H IiwgWEF1dGggaXMgdXNpbmcgdGhlICJYIiBhcyBhIHBsYWNlaG9sZGVyLiBYLU1lbiwgWGJveCwg WC1GYWN0b3IsIFgtZmlsZXMuDQoNCmh0dHBzOi8vd3d3LmJ1c2luZXNzaW5zaWRlci5jb20vdGhl LWluZGlzcHV0YWJsZS1wb3dlci1vZi1icmFuZC14LTIwMTItNA0KDQpodHRwczovL2VuZ2xpc2gu c3RhY2tleGNoYW5nZS5jb20vcXVlc3Rpb25zLzM1ODE4MS93aGF0cy10aGUtcHVycG9zZS1vZi11 c2luZy1sZXR0ZXIteC1vci14LWFzLWEtc3VmZml4LWluLWJyYW5kLW5hbWVzDQoNCg0KQW5kIHRv IERpY2vigJlzIHJhdGlvbmFsZSBmb3IgdGhlIG5hbWUgYmVsb3csIEkgYWJzb2x1dGVseSBkbyBO T1Qgc2VlIHRoaXMgd29yayBhcyDigJxPQXV0aCB3aXRoIGFsbCB0aGUgZXh0cmEgZmVhdHVyZXPi gJ0uIEkgdGhpbmsgdGhhdCBkb2VzIGEgZGlzc2VydmljZSB0byB0aGUga2luZCBvZiBjaGFuZ2Ug d2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0byBtYWtlIGhlcmUuDQoNCkZyb20gdGhlIGNoYXJ0ZXIN Cg0KIkl0IHdpbGwgZXhwYW5kIHVwb24gdGhlIHVzZXMgY2FzZXMgY3VycmVudGx5IHN1cHBvcnRl ZCBieSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IChpdHNlbGYgYW4gZXh0ZW5zaW9uIG9m IE9BdXRoIDIuMCkiDQoNCldoaWNoIHNvdW5kcyBwcmV0dHkgc2ltaWxhciB0byDigJxPQXV0aCB3 aXRoIGFsbCB0aGUgZXh0cmEgZmVhdHVyZXPigJ0NCg0KV2hpbGUgSSB0aGluayBYQXV0aCBjYXB0 dXJlcyB3aGF0IHdlIGFyZSBkb2luZywgYSBwbGFjZWhvbGRlciBuYW1lIHdvdWxkIGJlIHByZWZl cmFibGUgdG8gYW4gaW5jb3JyZWN0IGRlc2NyaXB0aXZlIG5hbWUgc3VjaCBhcyBUeEF1dGguDQoN CkZvciBleGFtcGxlLCBYWVogaXMgYSBnb29kIHBsYWNlaG9sZGVyIG5hbWUuIE9yIFhZWkF1dGgu IExldCdzIG5vdCBtaXNsZWFkIHBlb3BsZS4NCg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIE1hciAx NiwgMjAyMCwgYXQgNzowNCBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhlbGxvIGV2ZXJ5b25lDQoNCkkg cHJvbXB0ZWQgYSB0aHJlYWQgYXJvdW5kIHRoZSBuYW1lIG9mIHRoZSBwcm90b2NvbCBhIHdoaWxl IGJhY2s6DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoL1pW UVZiSHQ0QURxZWhLckJEWE9yVHJfc193Yy8NCg0KQXMgSnVzdGluIHN0YXRlZCAibmFtaW5nIGlz IGhhcmQiDQoNCldlYXJpbmcgbXkgbWFya2V0aW5nIGhhdCBJIHdhbnQgdG8gZW5zdXJlIHRoYXQg dGhlIG5hbWUgd2lsbCBiZSBwZXJjZWl2ZWQgcHJvcGVybHkgaW4gdGhlIGJyb2FkZXIgY29tbXVu aXR5Lg0KDQpBIHJlY2VudCBleGFtcGxlIHRoYXQgY29tZXMgdG8gbWluZCBhcmUgdGhlIHByaXZh Y3kgcmVsYXRlZCB3b3JrcyBvbiB0aGUgYnJvd3NlciBzdG9yYWdlIEFQSS4gR2l2ZW4gdGhhdCBu YW1lLCBvbmUgd291bGQgdGhpbmsgdGhhdCBpdCBpcyBsb2NhbCBzdG9yYWdlLiBJdCBpcyBhY3R1 YWxseSBhYm91dCBicm93c2VyIGNvb2tpZXMuDQoNCkp1c3RpbiBkaXNjdXNzZWQgaGlzIHJlYXNv bnMgZm9yIFR4QXV0aCBpbiB0aGUgdGhyZWFkIGFib3ZlIChhbmQgSSdtIHN1cmUgaW4gb3RoZXIg cGxhY2VzKQ0KDQpJIGNob3NlIFhBdXRoIGluIG15IGRyYWZ0IHRvIHJlZmxlY3QgdGhlIGVYdGVu c2liaWxpdHkgZ29hbCB0aGF0IHdlIGhhdmUgb3ZlciBPQXV0aCAtLSBhbmQgWEF1dGggaXMgT0F1 dGggYnV0IHdpdGggYW4gWCB0byByZWZsZWN0IGFsbCB0aGUgZXh0cmEgZmVhdHVyZXMuID0pDQoN Ck90aGVyIHN1Z2dlc3Rpb25zPw0KDQpUaGlzIHdpbGwgYmUgYW4gYWdlbmRhIGl0ZW0gaW4gdGhl IEJvRiAtLSBidXQgdGhlIG5hbWUgd2lsbCBOT1QgYmUgYW4gb3BlbiBkaXNjdXNzaW9uIGl0ZW0g LS0gd2Ugd2lsbCBzdW1tYXJpemUgd2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQgb24gdGhlIGxpc3Qg YW5kIHBlcmhhcHMgZG8gYSBwb2xsIG9mIG9wdGlvbnMgcHJlc2VudGVkIHVubGVzcyBjb25zZW5z dXMgaXMgb2J2aW91cyBmcm9tIHRoaXMgdGhyZWFkLg0KDQovRGljaw0KDQoNCg0KDQoNCuGQpw0K DQoNCg0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhh dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGgNCg0K --_000_CH2PR00MB0679FE99B1703FA111BBCADEF5F00CH2PR00MB0679namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpHYWR1Z2k7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAy IDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTppbmhlcml0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KaDINCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhl YWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMyRjU0OTY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6MzE0MTg4ODEyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczo2MjkxNDgxMDggNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6NjI2MzQ5NjA0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTU0MzU1NDI2IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SW4g YnJhaW5zdG9ybWluZyBtb2Rl4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJjb2xvcjojMDAyMDYwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+DQpEaXNhZ2dyZWdhdGVkIEF1dGhvcml6YXRpb24gKERpc0F1dGgpPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkNvbXBvbmVudGl6ZWQgQXV0 aG9yaXphdGlvbiAoQ29tcEF1dGgpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCkJ1aWxkLVlvdXItT3duIEF1dGhvcml6YXRpb24gKEJZT0F1dGgpPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOiMw MDIwNjA7bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkRvLUl0LVlv dXJzZWxmIEF1dGhvcml6YXRpb24gKERJWUF1dGgpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOiMwMDIwNjA7bWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NClJlZmFjdG9yZWQgQXV0aG9yaXphdGlvbiAoUmVBdXRo IG9yIFJlZkF1dGgpPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkFuZCBmb3Ig ZnVu4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjoj MDAyMDYwO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpEaXNtZW1i ZXJlZCBBdXRob3JpemF0aW9uPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUeGF1dGggJmx0O3R4YXV0aC1i b3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5EYXZpZCBTa2FpZmU8YnI+ DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1hcmNoIDIxLCAyMDIwIDExOjIyIEFNPGJyPg0KPGI+ VG86PC9iPiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7OyB0eGF1dGhA aWV0Zi5vcmc7IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1R4YXV0aF0gV0cgbmFtZTogVHhBdXRoPyBYQXV0aD8gU29tZXRo aW5nIGVsc2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsg d2UncmUgc2F5aW5nIHRoZSBzYW1lIHRoaW5nIHdpdGggcmVnYXJkcyB0byB0aGUgd29ya2luZyBn cm91cCBuYW1lIC0gSSB3YXMgc2F5aW5nIGl0DQo8Yj5pc24ndDwvYj4gcGFydGljdWxhcmx5IGlt cG9ydGFudCBpbiBjb21wYXJpc29uIHRvIHRoZSBuYW1lIG9mIHRoZSBwcm90b2NvbCAod2hpY2gg b2J2aW91c2x5IGlzIHZlcnkgaW1wb3J0YW50KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTWFyIDIxLCAyMDIwIGF0IDY6MTggUE0gSnVzdGlu IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQu ZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaXNhZ3JlZSBvbiB0aGUgd29ya2luZyBncm91 cCBuYW1lIGJlaW5nIHN1cGVyIGltcG9ydGFudC4gTm9ib2R5IGtub3dzIHRoYXQgdGhlIE9BdXRo IFdHIGlzIGFjdHVhbGx5IG5hbWVkIOKAnFRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBX b3JraW5nIEdyb3Vw4oCdLCBhbmQgbm9ib2R5IGNhcmVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcHJvcG9zYWwgaXMgdGhhdCB3ZSBuYW1lIHRoZSBw cm90b2NvbCB3ZSB3b3JrIG9uIOKAnFR4QXV0aOKAnSAoYW5kIGtlZXAgdGhlIG1haWxpbmcgbGlz dCksIGFuZCB0aGF0IHdlIG5hbWUgdGhlIHdvcmtpbmcgZ3JvdXAgc29tZXRoaW5nIGxpa2Ug4oCc TmV4dCBHZW5lcmF0aW9uIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29s4oCdIHRvIHNheSB3aGF0 IHdl4oCZcmUgZG9pbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyMSwgMjAyMCwgYXQgMjowOCBQTSwgRGF2 aWQgU2thaWZlICZsdDs8YSBocmVmPSJtYWlsdG86Ymx1ZS5yaW5nZWQub2N0b3B1cy5ndXlAZ21h aWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Ymx1ZS5yaW5nZWQub2N0b3B1cy5ndXlAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5KdXN0IHRvIHRocm93IGluIGFub3RoZXIgc3VnZ2VzdGlvbiwgdG8gYWRkcmVzcyBZYXJv bidzIHBvaW50IGFib3V0IHNvbWUgcGVvcGxlIG1pc3Rha2VubHkgdGhpbmtpbmcgdGhhdCAmcXVv dDtBdXRoJnF1b3Q7IHN0YW5kcyBmb3IgYXV0aGVudGljYXRpb24gcmF0aGVyIHRoYW4gYXV0aG9y aXphdGlvbiwgaG93IGFib3V0IG5hbWluZyB0aGUgd29ya2luZyBncm91cA0KPGI+QXV0aFo8L2I+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmljZSBhbmQgc2lt cGxlLCBhbmQgaXQgbWFrZXMgaXQgY2xlYXIgd2hhdCB0aGUgZ3JvdXAgaXMgZm9jdXNlZCBvbi48 YnI+DQo8YnI+DQpJIHRoaW5rIHRoZSBuYW1lIG9mIHRoZSBhY3R1YWwgcHJvdG9jb2wgdGhhdCB3 ZSBwcm9kdWNlIGlzIGZhciwgZmFyIG1vcmUgaW1wb3J0YW50IHRoYXQgdGhlIG5hbWUgb2YgdGhl IHdvcmtpbmcgZ3JvdXAgLSBhbmQgdGhlIG5hbWUgb2YgdGhhdCBwcm90b2NvbCBkb2Vzbid0IG5l ZWQgdG8gY29ycmVsYXRlIHRvIHRoZSBXRyBuYW1lLiBBbHNvLCB3ZSBoYXZlIG11Y2ggbW9yZSB0 aW1lIGJlZm9yZSB3ZSBuZWVkIHRvIGRlY2lkZSBvbiB0aGUgbmFtZQ0KIG9mIHRoYXQgcHJvdG9j b2wsIGV2ZW4gaWYgdGhlIGluaXRpYWwmbmJzcDtkcmFmdCBkb2N1bWVudHMgdGhhdCB3ZSBwcm9k dWNlIGVuZCB1cCB1c2luZyBhIHBsYWNlaG9sZGVyIG5hbWUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgTWFyIDIxLCAyMDIwIGF0 IDU6NDQgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVk dSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIHlvdSBjYW4gc2VlIGluIHRoZSBlbWFpbCB5b3UgcmVwbGllZCB0bywgdGhhdCBpcyBub3Qg ZXZlbiBjbG9zZSB0byB3aGF0IEkgc2FpZC4gSSBiZWxpZXZlIGl0IGlzIGEgdHJhbnNhY3Rpb24s IGFuZCB0aGVyZWZvcmUsIEkgZG8gbm90IGFncmVlIHRoYXQgaXTigJlzIG5vdCBhIHRyYW5zYWN0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGlm IHdlIHRha2Ug4oCcVHJhbnNhY3Rpb25hbOKAnSBvdXQgb2YgdGhlIFdHIHRpdGxlLCBJIHdvbuKA mXQgYmUgb2ZmZW5kZWQuIElmIHdlIGp1c3QgY2FsbCBpdCDigJxUeEF1dGjigJ0gd2l0aG91dCBl eHBhbnNpb24sIHRoZW4gdGhhdOKAmXMgZmluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3QgbGlrZSBjYWxsaW5nIGl0IOKAnFhB dXRo4oCdLiBUaGUgdGVybSDigJxUQXV0aCZxdW90OyB3YXMgZmxvYXRlZCBkdXJpbmcgbmFtaW5n IHRoZSBsaXN0LCBidXQgcmVqZWN0ZWQgYmVjYXVzZSAoYW1vbmcgb3RoZXIgcmVhc29ucykgaXQg d291bGQgbGlrZWx5IGJlIGF3a3dhcmRseSBwcm9ub3VuY2VkIGFzIOKAnHRvd3Ro4oCdIG9yIHNv bWV0aGluZy4gVHhBdXRoIHJlYWRzIGFzIOKAnFRlZSAtIGV4IC0gb3Ro4oCdIG1vcmUgbmF0dXJh bGx5LA0KIHdoaWNoIHdhcyB0aGUgaW50ZW50LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBob3cgYWJvdXQgd2UgdGFrZSBhIHBh Z2UgZnJvbSB0aGUgT0F1dGggd29ya2luZyBncm91cCBhbmQgbmFtZSBpdDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHhBdXRoIC0gTmV4dCBH ZW5lcmF0aW9uIFdlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTWFyIDIxLCAyMDIwLCBhdCAxOjE1IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVm PSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0 QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VG8gY2xhcmlmeSAtLSB5b3UgYWdyZWUgaXQgaXMgbm90IGEgdHJhbnNh Y3Rpb24sIGFuZCB3ZSB3aWxsIHRha2UgdGhlIHdvcmQgdHJhbnNhY3Rpb24gb3V0IG9mIHRoZSBX RyB0aXRsZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgTWFyIDIwLCAyMDIwIGF0IDU6NTMgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpY2ssIHRoYW5rcyBmb3IgcHVsbGluZyB0aGUgZGVmaW5p dGlvbnMgdXA6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMwMzMzNjtsZXR0ZXItc3BhY2luZzou MTVwdCI+YSBjb21tdW5pY2F0aXZlIGFjdGlvbiBvciBhY3Rpdml0eSBpbnZvbHZpbmcgdHdvIHBh cnRpZXMgb3IgdGhpbmdzIHRoYXQgcmVjaXByb2NhbGx5IGFmZmVjdCBvciBpbmZsdWVuY2UgZWFj aCBvdGhlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBpcyB0aGUga2luZCBvZiB0aGluZyB0aGF0IEkgaGFkIGluIG1pbmQu IFRoZSBjbGllbnQgYW5kIHRoZSBBUyBhcmUgaW4gYSBjb252ZXJzYXRpb24gb3ZlciB0aW1lIHRo YXQgZWFjaCBvbmUgY29udHJpYnV0ZXMgdG8gYW5kIGVhY2ggY2hhbmdlcy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbyDigJQg d2UgY2FuIGp1c3QgYXMgZWFzaWx5IGRlY2lkZSB0aGF0IOKAnFR4QXV0aOKAnSBkb2VzbuKAmXQg c3RhbmQgZm9yIOKAnFRyYW5zYWN0aW9uYWwgQXV0aOKAnSBtdWNoIHRoZSBzYW1lIHdheSB3ZSBk ZWNpZGVkIHRoYXQgdGhlIOKAnE/igJ0gaW4g4oCcT0F1dGjigJ0gZG9lc27igJl0IHN0YW5kIGZv ciDigJxPcGVu4oCdIGFueW1vcmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vbmUgb2YgdGhlIGFyZ3VtZW50cyBiZWxvdyBpbiBm YXZvciBvZiBYQXV0aCBoYXZlIG1hZGUgbWUgbGlrZSB0aGF0IG5hbWUgYmV0dGVyLiBJZiBpdOKA mXMganVzdCBhIOKAnHBsYWNlaG9sZGVy4oCdIG5hbWUsIHRoZW4gd2h5IGNvbWUgdXAgd2l0aCBz b21ldGhpbmcgbmV3PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMjAsIDIwMjAsIGF0IDM6MzIgUE0sIERpY2sgSGFyZHQg Jmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm90IGEgdHJhbnNhY3Rpb24g LSB0aGVyZSBhcmUgbXVsdGlwbGUgdHJhbnNhY3Rpb25zPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iYWNrY2hhbm5lbCBpbm5vdmF0aW9uIGlzIGNvbWJpbmF0 aW9uJm5ic3A7b2YgaGVyZSBpcyB3aG8gSSBhbSwgYW5kIGhlcmUgaXMgd2hhdCBJIHdhbnQgdG8g ZG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5jaGlsZGhvb2QgdHJhdW1hIHRoZXJhcHkgZ3JvdXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWFyIDE2LCAyMDIwIGF0 IDY6NTYgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVk dSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlllcywgbmFtaW5nIHRoaW5ncyBpcyBoYXJkIOKAlCBidXQgSSBzdGlsbCBiZWxpZXZlIGluIHRo ZSBuYW1lIFR4QXV0aC4gV2XigJlyZSBtb3ZpbmcgYmV5b25kIE9BdXRoLCBhbmQgdGFraW5nIHRo ZSBwcm9jZXNzIG9mIGdldHRpbmcgYW4gYXV0aG9yaXphdGlvbiBkZWxlZ2F0ZWQgdG8gdGhlIGNs aWVudCBzb2Z0d2FyZSBhcyBhIG11bHRpLXN0ZXAsIG11bHRpLXBhcnR5IHRyYW5zYWN0aW9uIGlz LCBJIGJlbGlldmUsDQogdGhlIGtleSBpbnNpZ2h0IHRoYXTigJlzIGxldHRpbmcgdXMgbW92ZSBi ZXlvbmQgT0F1dGjigJlzIGxpbWl0YXRpb25zIGhlcmUuIEl04oCZcyBub3QganVzdCBhYm91dCBn b2luZyB0byB0aGUgQVMgZmlyc3Qg4oCUIHdlIGhhZCB0aGF0IGluIE9BdXRoIDEgYW5kIHdl4oCZ cmUgcGF0Y2hpbmcgdGhhdCBpbnRvIE9BdXRoIDIgd2l0aCBQQVIuIEkgcmVhbGx5IHRoaW5rIGl0 4oCZcyBhYm91dCB0aGUgdHJhbnNhY3Rpb24gYXQgdGhlIGNvcmUuLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PQXV0aCAyLjAgaGFkIG11bHRpLXN0ZXAsIG11bHRpLXBhcnR5LiBUeEF1dGggZXh0ZW5kcyB0 aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHRoaW5rIHRoZSBiaWcgc2hpZnQgaXMgZ29pbmcgdG8gdGhlIEFTLiBUaGlzIGVuYWJsZXMg dGhlIHJlcXVlc3QgdG8gYmUgcmljaGVyIHdpdGggSlNPTiwgaW5zdGVhZCBvZiBuYW1lL3ZhbHVl IHBhaXJzIHBhcmFtZXRlcnMgaW4gYSBVUkkuIEl0IGFsbG93cyB0aGUgY2xpZW50IGFuZCBBUyB0 byBuZWdvdGlhdGUsIGFuZCB0byBzaG9ydCBjaXJjdWl0IGhhdmluZyB0byByZWRpcmVjdCB0aGUg dXNlciB0byB0aGUNCiBBUy4gUEFSIGRvZXMmbmJzcDtzb21lIG9mIHRoaXMsIGJ1dCBpdCBpcyBj b25zdHJhaW5lZCBieSBoYXZpbmcgdG8gZG8gaXQgaW4gdGhlIE9BdXRoIDIuMCBjb250ZXh0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBj b25jZXJuIGlzIHRoYXQgdGhlIHByb3RvY29sIGlzIE1VQ0ggTU9SRSB0aGFuIGEgdHJhbnNhY3Rp b24uIFdoaWxlIHRoZSBpbml0aWFsIGludGVyYWN0aW9uIGJldHdlZW4gY2xpZW50LCBBUywgdXNl ciBhbmQgUk8gaXMgYSB0cmFuc2FjdGlvbi4gVGhlIHByb3RvY29sIGFsc28gY292ZXJzIHRoZSBj bGllbnQmbmJzcDthbmQgUlMgaW50ZXJhY3Rpb25zLiBUaGUgYWNjZXNzIHRva2VuIHJlZnJlc2hl cy4gQWNjZXNzDQogdG9rZW4gcmV2b2NhdGlvbi4gQWNjZXNzIHRva2VuIGludHJvc3BlY3Rpb24u IEFzIGRlc2NyaWJlZCBpbiB0aGUgY2hhcnRlciwgdGhlcmUgaXMgYSB3aG9sZSBsaWZlY3ljbGUs IHRoYXQgY29uc2lzdHMgb2YgbXVsdGlwbGUgdHJhbnNhY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cubWVycmlhbS13ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5L3RyYW5zYWN0aW9uIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cubWVycmlhbS13ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5 L3RyYW5zYWN0aW9uPC9hPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8aDIgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O2xpbmUt aGVpZ2h0OjE5LjVwdDt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE2LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjY1NjY3O2xldHRlci1zcGFjaW5nOi4yNXB0Ij5EZWZpbml0aW9uIG9mJm5ic3A7 PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE2LjVwdDtmb250LWZhbWlseTppbmhl cml0O2NvbG9yOiMyNjU2Njc7bGV0dGVyLXNwYWNpbmc6LjI1cHQ7Ym9yZGVyOm5vbmUgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+dHJhbnNhY3Rpb248L3NwYW4+PC9lbT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE2LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjY1NjY3O2xldHRlci1zcGFjaW5nOi4yNXB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L2gyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90 dG9tOjE4Ljc1cHQ7Ym94LXNpemluZzpib3JkZXItYm94Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5l Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5O2xldHRlci1zcGFjaW5nOi4xNXB0 O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjFhPC9zcGFuPjwvYj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTppbmhlcml0O2NvbG9y OiMzMDMzMzY7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBw dDtwYWRkaW5nOjBpbiI+OiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzMwMzMzNjtsZXR0ZXItc3BhY2luZzouMTVwdDtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIj5zb21ldGhpbmcmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5tZXJyaWFt LXdlYnN0ZXIuY29tL2RpY3Rpb25hcnkvdHJhbnNhY3RlZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjojMjY1NjY3Ij50cmFuc2FjdGVkPC9zcGFuPjwvYT48aT5lc3BlY2lhbGx5 PC9pPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5O2xldHRlci1zcGFjaW5n Oi4xNXB0O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPiZuYnNwOzwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTppbmhlcml0 O2NvbG9yOiMyMTI1Mjk7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBpbiI+OiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIxMjUyOTtsZXR0ZXItc3BhY2luZzouMTVwdDtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6MGluIj5hbg0KIGV4Y2hhbmdlIG9yJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly93d3cubWVycmlhbS13ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5L3RyYW5zZmVyIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyNjU2NjciPnRyYW5zZmVyPC9zcGFuPjwvYT4mbmJz cDtvZiBnb29kcywgc2VydmljZXMsIG9yIGZ1bmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyMjVGNzM7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiI+ZWxlY3Ryb25pYyZuYnNwOzxpPnRyYW5zYWN0aW9uczwvaT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOTtsZXR0ZXItc3BhY2luZzouMTVwdDti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTYuNXB0O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMjEyNTI5O2xldHRlci1zcGFjaW5nOi4xNXB0O2JvcmRlcjpub25lIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4iPmI6Jm5ic3A7dHJhbnNhY3Rpb25zPC9zcGFuPjwvYj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5O2xldHRlci1zcGFjaW5nOi4xNXB0O2JvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPiZuYnNwO3BsdXJhbDwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjUyOTtsZXR0ZXItc3BhY2luZzouMTVwdDti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj4mbmJzcDs8L3NwYW4+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6aW5oZXJpdDtjb2xvcjoj MzAzMzM2O2xldHRlci1zcGFjaW5nOi4xNXB0O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4iPjombmJzcDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMz MDMzMzY7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjBpbiI+dGhlDQogb2Z0ZW4gcHVibGlzaGVkIHJlY29yZCBvZiB0aGUgbWVldGluZyBv ZiBhIHNvY2lldHkgb3IgYXNzb2NpYXRpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox My41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzIxMjUyOTtsZXR0ZXItc3BhY2luZzouMTVwdDtib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGluIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWJvdHRvbToxNS4wcHQ7Ym94LXNpemluZzpib3JkZXItYm94Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O3ZlcnRp Y2FsLWFsaWduOmJhc2VsaW5lIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyNTI5O2xl dHRlci1zcGFjaW5nOi4xNXB0O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzow aW4iPjJhPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTppbmhlcml0O2NvbG9yOiMzMDMzMzY7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5v bmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+OiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzMwMzMzNjtsZXR0ZXItc3BhY2luZzouMTVwdDtib3JkZXI6bm9u ZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj5hbg0KIGFjdCwgcHJvY2Vzcywgb3IgaW5z dGFuY2Ugb2YmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5tZXJyaWFtLXdlYnN0ZXIuY29tL2Rp Y3Rpb25hcnkvdHJhbnNhY3RpbmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 IzI2NTY2NyI+dHJhbnNhY3Rpbmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMjEyNTI5O2xldHRlci1zcGFjaW5nOi4xNXB0O2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowaW4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQ7dmVydGljYWwt YWxpZ246YmFzZWxpbmUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTI1Mjk7bGV0dGVy LXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+ Yjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 aW5oZXJpdDtjb2xvcjojMzAzMzM2O2xldHRlci1zcGFjaW5nOi4xNXB0O2JvcmRlcjpub25lIHdp bmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjombmJzcDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMzMDMzMzY7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+YQ0KIGNvbW11bmljYXRpdmUgYWN0aW9uIG9yIGFj dGl2aXR5IGludm9sdmluZyB0d28gcGFydGllcyBvciB0aGluZ3MgdGhhdCByZWNpcHJvY2FsbHkg YWZmZWN0IG9yIGluZmx1ZW5jZSBlYWNoIG90aGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMyMTI1Mjk7bGV0dGVyLXNwYWNpbmc6LjE1cHQ7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYWxsaW5nIHRo ZSBwcm90b2NvbCBhIHRyYW5zYWN0aW9uIHdpbGwgY29uZnVzaW5nIHRvIHBlb3BsZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhhdmluZyBjb21lIG9mIGFnZSBpbiB0aGUgMTk5MOKAmXMsIEkgaGF2ZSBw YXJ0aWN1bGFyIGRpc2xpa2UgZm9yIFhBdXRoLiBJdCBzb3VuZHMgdG9vIOKAnFgtVFJFTUXigJ0g YW5kIOKAnFgtQ0lUSU5H4oCdLCBhbmQgaWYgeW91IHJlYWQgZWl0aGVyIG9mIHRob3NlIHdpdGgg YSBncm93bGluZyB5ZWxsIGluIHlvdXIgaGVhZCB0aGVuIHlvdSBrbm93IGV4YWN0bHkgd2hhdCBJ 4oCZbSB0YWxraW5nIGFib3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNhc2UgeW91IGFyZSBj b25mdXNlZCwgdGhpcyBpcyBub3QgYSBjaGlsZGhvb2QmbmJzcDt0cmF1bWEgc3VwcG9ydCBncm91 cC4mbmJzcDsgOik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VW5saWtlICZxdW90O1gtVFJFTUUmcXVvdDsgb3IgJnF1b3Q7WC1DSVRJTkcmcXVv dDssIFhBdXRoIGlzIHVzaW5nIHRoZSAmcXVvdDtYJnF1b3Q7IGFzIGEgcGxhY2Vob2xkZXIuIFgt TWVuLCBYYm94LCBYLUZhY3RvciwgWC1maWxlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmJ1c2luZXNzaW5zaWRlci5jb20vdGhlLWluZGlzcHV0YWJsZS1wb3dlci1vZi1icmFuZC14 LTIwMTItNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmJ1c2luZXNzaW5zaWRlci5jb20v dGhlLWluZGlzcHV0YWJsZS1wb3dlci1vZi1icmFuZC14LTIwMTItNDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly9lbmdsaXNoLnN0YWNrZXhjaGFuZ2UuY29tL3F1ZXN0aW9ucy8zNTgxODEvd2hhdHMtdGhlLXB1 cnBvc2Utb2YtdXNpbmctbGV0dGVyLXgtb3IteC1hcy1hLXN1ZmZpeC1pbi1icmFuZC1uYW1lcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZW5nbGlzaC5zdGFja2V4Y2hhbmdlLmNvbS9xdWVzdGlv bnMvMzU4MTgxL3doYXRzLXRoZS1wdXJwb3NlLW9mLXVzaW5nLWxldHRlci14LW9yLXgtYXMtYS1z dWZmaXgtaW4tYnJhbmQtbmFtZXM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCB0 byBEaWNr4oCZcyByYXRpb25hbGUgZm9yIHRoZSBuYW1lIGJlbG93LCBJIGFic29sdXRlbHkgZG8g Tk9UIHNlZSB0aGlzIHdvcmsgYXMg4oCcT0F1dGggd2l0aCBhbGwgdGhlIGV4dHJhIGZlYXR1cmVz 4oCdLiBJIHRoaW5rIHRoYXQgZG9lcyBhIGRpc3NlcnZpY2UgdG8gdGhlIGtpbmQgb2YgY2hhbmdl IHdlIGhhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gbWFrZSBoZXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZyb20gdGhlIGNoYXJ0ZXImbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0l0IHdpbGwg ZXhwYW5kIHVwb24gdGhlIHVzZXMgY2FzZXMgY3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAy LjAgYW5kIE9wZW5JRCBDb25uZWN0IChpdHNlbGYgYW4gZXh0ZW5zaW9uIG9mIE9BdXRoIDIuMCkm cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggc291bmRzIHByZXR0eSBzaW1p bGFyIHRvJm5ic3A74oCcT0F1dGggd2l0aCBhbGwgdGhlIGV4dHJhIGZlYXR1cmVz4oCdPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIEkg dGhpbmsgWEF1dGggY2FwdHVyZXMgd2hhdCB3ZSBhcmUgZG9pbmcsIGEgcGxhY2Vob2xkZXIgbmFt ZSB3b3VsZCBiZSBwcmVmZXJhYmxlIHRvIGFuIGluY29ycmVjdCBkZXNjcmlwdGl2ZSBuYW1lIHN1 Y2ggYXMgVHhBdXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkZvciBleGFtcGxlLCBYWVog aXMgYSBnb29kIHBsYWNlaG9sZGVyIG5hbWUuIE9yIFhZWkF1dGguIExldCdzIG5vdCBtaXNsZWFk IHBlb3BsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAxNiwgMjAyMCwgYXQgNzow NCBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIGV2ZXJ5b25l PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHByb21wdGVk IGEgdGhyZWFkIGFyb3VuZCB0aGUgbmFtZSBvZiB0aGUgcHJvdG9jb2wgYSB3aGlsZSBiYWNrOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC9aVlFWYkh0 NEFEcWVoS3JCRFhPclRyX3Nfd2MvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy90eGF1dGgvWlZRVmJIdDRBRHFlaEtyQkRYT3JUcl9zX3djLzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QXMgSnVzdGluIHN0YXRlZCAmcXVvdDtuYW1pbmcgaXMgaGFyZCZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWFyaW5nIG15IG1hcmtl dGluZyBoYXQgSSB3YW50IHRvIGVuc3VyZSB0aGF0IHRoZSBuYW1lIHdpbGwgYmUgcGVyY2VpdmVk Jm5ic3A7cHJvcGVybHkgaW4gdGhlIGJyb2FkZXIgY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHJlY2VudCBleGFtcGxlIHRo YXQgY29tZXMgdG8gbWluZCBhcmUgdGhlIHByaXZhY3kgcmVsYXRlZCB3b3JrcyBvbiB0aGUgYnJv d3NlciBzdG9yYWdlIEFQSS4gR2l2ZW4gdGhhdCBuYW1lLCBvbmUgd291bGQgdGhpbmsgdGhhdCBp dCBpcyBsb2NhbCBzdG9yYWdlLiBJdCBpcyBhY3R1YWxseSBhYm91dCBicm93c2VyIGNvb2tpZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1 c3RpbiBkaXNjdXNzZWQgaGlzIHJlYXNvbnMgZm9yIFR4QXV0aCBpbiB0aGUgdGhyZWFkIGFib3Zl IChhbmQgSSdtIHN1cmUgaW4gb3RoZXIgcGxhY2VzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGNob3NlIFhBdXRoIGluIG15IGRyYWZ0IHRv IHJlZmxlY3QgdGhlIGVYdGVuc2liaWxpdHkgZ29hbCB0aGF0IHdlIGhhdmUgb3ZlciBPQXV0aCAt LSBhbmQgWEF1dGggaXMgT0F1dGggYnV0IHdpdGggYW4gWCB0byByZWZsZWN0IGFsbCB0aGUgZXh0 cmEgZmVhdHVyZXMuID0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk90aGVyIHN1Z2dlc3Rpb25zPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdpbGwgYmUgYW4gYWdlbmRhIGl0ZW0g aW4gdGhlIEJvRiAtLSBidXQgdGhlIG5hbWUgd2lsbCBOT1QgYmUgYW4gb3BlbiBkaXNjdXNzaW9u IGl0ZW0gLS0gd2Ugd2lsbCBzdW1tYXJpemUmbmJzcDt3aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBv biB0aGUgbGlzdCBhbmQgcGVyaGFwcyBkbyBhIHBvbGwgb2Ygb3B0aW9ucyBwcmVzZW50ZWQgdW5s ZXNzIGNvbnNlbnN1cyBpcyBvYnZpb3VzIGZyb20gdGhpcyB0aHJlYWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3R5bGU9IndpZHRoOi4wMTA0 aW47aGVpZ2h0Oi4wMTA0aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9v Z2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjA9JmFt cDt0eXBlPXplcm9jb250ZW50JmFtcDtndWlkPWIyMWEyYTZkLWQ3ZTMtNDVmYS1iN2E4LTg0NzY4 YTFiZDJlYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtH YWR1Z2kmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhh dXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB0679FE99B1703FA111BBCADEF5F00CH2PR00MB0679namp_-- From nobody Mon Mar 23 12:50:51 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364353A0E59 for ; Mon, 23 Mar 2020 12:50:28 -0700 (PDT) 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 ua0LGwGxELIs for ; Mon, 23 Mar 2020 12:50:24 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 CBA963A0BDA for ; Mon, 23 Mar 2020 12:50:23 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id u12so16079658ljo.2 for ; Mon, 23 Mar 2020 12:50:23 -0700 (PDT) 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=WzwJdfC5wPCQka+h2v3gTgBNQbWRSR1HRhmW0s+CKMA=; b=Co5pmX1AanrnZxAQoCOG0XjsI0EULWqSdJgvzBT6m6W6/HWPRoyhKE9xc6CKiry8Ko vuJRNl1ye7QS9CpASKsCYzwzDsvOF5rzouc6pwcN94Pt+b0GQOtXL7PUaq8cWJvxWM3v QVTkyTqUc4pGm47mjEN9lHUWW1wPj54J/52uapKEPR7DpYnlk3CFZEoi9liZ5kB2afbW 7vVMTSVfnEi9UZssM8l0cfpQ0c4TzWxJyT274j6hZSpUnNxSlXjlnRWocEiJP4rOe5EL XGO0KtThD5PvHww6DhPQEuZdU6r/hvwlPzVZ7dYMFHEVWm6Emvq/t+u8cma1fWMk1va3 L/kA== 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=WzwJdfC5wPCQka+h2v3gTgBNQbWRSR1HRhmW0s+CKMA=; b=mDRCPquWgaZgqABV1NVdM2X450JCjSeti/UmECvM3FhStNk3Nz1NuaaKsQTsmeOrry CSb9zIv37C8pNHprHcI9hi897ioTkwf8Z1Gn9HKjyEKjcD49QLobE+rIvXFrVKQadDRs +wsPYpJVoU423wD7WqSKM56Cg3+t38zmD/zoNLk0bygZSllv4n2xq9VCzKN2oZAnYa6Z ZXn8WmFd619AJa7ucMN9VzbXdSoX7CRdYha0qAi/6KqNswTBK+jH3je5kTSubF9VgOr4 gGZ8nG9wQf3Nr3jqSkz9ND1AHMqAm9cDt4SAznIHcJAiTMtUFdu6pfxniYBD8PmAC48m kpmA== X-Gm-Message-State: ANhLgQ1Xkhk2qfg30UWtXkN4r32vz9rVszuk6OemNFRwdn+NSNQJ0q1N qsql8gr0EsVrsnkkpWFzYY727pbLj6ZarYULE4TSKx+/DH98TXbkjUdL8FryAWFnCwC+cgegbMv qvARK7ifzjCM2Wq4= X-Google-Smtp-Source: ADFU+vuwH6vGsRoHjWfD9Hs208rakkER5raigzjEgFbnRcX5r5IAc4QOEyIHgXXYRIgFGfmCjM346a8Y+qabJxon1dk= X-Received: by 2002:a2e:b8c1:: with SMTP id s1mr3389531ljp.0.1584993021702; Mon, 23 Mar 2020 12:50:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Mon, 23 Mar 2020 13:49:55 -0600 Message-ID: To: Mike Jones Cc: David Skaife , Justin Richer , Yaron Sheffer , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="00000000000007da2605a18af262" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 19:50:48 -0000 --00000000000007da2605a18af262 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable YAAAAS - Yet Another Authorization And Authentication Specification On Mon, Mar 23, 2020 at 1:39 PM Mike Jones wrote: > In brainstorming mode=E2=80=A6 > > - Disaggregated Authorization (DisAuth) > - Componentized Authorization (CompAuth) > - Build-Your-Own Authorization (BYOAuth) > - Do-It-Yourself Authorization (DIYAuth) > - Refactored Authorization (ReAuth or RefAuth) > > > > And for fun=E2=80=A6 > > - Dismembered Authorization > > > > -- Mike > > > > *From:* Txauth *On Behalf Of *David Skaife > *Sent:* Saturday, March 21, 2020 11:22 AM > *To:* Justin Richer > *Cc:* Yaron Sheffer ; txauth@ietf.org; Dick Hardt = < > dick.hardt@gmail.com> > *Subject:* Re: [Txauth] WG name: TxAuth? XAuth? Something else? > > > > I think we're saying the same thing with regards to the working group nam= e > - I was saying it *isn't* particularly important in comparison to the > name of the protocol (which obviously is very important). > > > > On Sat, Mar 21, 2020 at 6:18 PM Justin Richer wrote: > > I disagree on the working group name being super important. Nobody knows > that the OAuth WG is actually named =E2=80=9CThe Web Authorization Protoc= ol Working > Group=E2=80=9D, and nobody cares. > > > > My proposal is that we name the protocol we work on =E2=80=9CTxAuth=E2=80= =9D (and keep the > mailing list), and that we name the working group something like =E2=80= =9CNext > Generation Web Authorization Protocol=E2=80=9D to say what we=E2=80=99re = doing. > > > > -- Justin > > > > On Mar 21, 2020, at 2:08 PM, David Skaife < > blue.ringed.octopus.guy@gmail.com> wrote: > > > > Just to throw in another suggestion, to address Yaron's point about some > people mistakenly thinking that "Auth" stands for authentication rather > than authorization, how about naming the working group *AuthZ* > > Nice and simple, and it makes it clear what the group is focused on. > > I think the name of the actual protocol that we produce is far, far more > important that the name of the working group - and the name of that > protocol doesn't need to correlate to the WG name. Also, we have much mor= e > time before we need to decide on the name of that protocol, even if the > initial draft documents that we produce end up using a placeholder name. > > > > On Sat, Mar 21, 2020 at 5:44 PM Justin Richer wrote: > > As you can see in the email you replied to, that is not even close to wha= t > I said. I believe it is a transaction, and therefore, I do not agree that > it=E2=80=99s not a transaction. > > > > But if we take =E2=80=9CTransactional=E2=80=9D out of the WG title, I won= =E2=80=99t be offended. > If we just call it =E2=80=9CTxAuth=E2=80=9D without expansion, then that= =E2=80=99s fine. > > > > I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAuth= " was floated during > naming the list, but rejected because (among other reasons) it would like= ly > be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D or something. TxAuth r= eads as =E2=80=9CTee - ex > - oth=E2=80=9D more naturally, which was the intent. > > > > So how about we take a page from the OAuth working group and name it: > > > > TxAuth - Next Generation Web Authorization Protocol Working Group > > > > > > =E2=80=94 Justin > > > > On Mar 21, 2020, at 1:15 PM, Dick Hardt wrote: > > > > To clarify -- you agree it is not a transaction, and we will take the wor= d > transaction out of the WG title? > > > > On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: > > Dick, thanks for pulling the definitions up: > > > > > a communicative action or activity involving two parties or things that > reciprocally affect or influence each other > > > > This is the kind of thing that I had in mind. The client and the AS are i= n > a conversation over time that each one contributes to and each changes. > > > > Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80=9D= doesn=E2=80=99t stand for > =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that th= e =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D > doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. > > > > None of the arguments below in favor of XAuth have made me like that name > better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then w= hy come up with something > new? > > > > =E2=80=94 Justin > > > > On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: > > > > > > > > > > not a transaction - there are multiple transactions > > > > backchannel innovation is combination of here is who I am, and here is > what I want to do > > > > > > childhood trauma therapy group > > > > > > > > On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: > > Yes, naming things is hard =E2=80=94 but I still believe in the name TxAu= th. We=E2=80=99re > moving beyond OAuth, and taking the process of getting an authorization > delegated to the client software as a multi-step, multi-party transaction > is, I believe, the key insight that=E2=80=99s letting us move beyond OAut= h=E2=80=99s > limitations here. It=E2=80=99s not just about going to the AS first =E2= =80=94 we had that > in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR. I reall= y think > it=E2=80=99s about the transaction at the core.. > > > > OAuth 2.0 had multi-step, multi-party. TxAuth extends that. > > > > I think the big shift is going to the AS. This enables the request to be > richer with JSON, instead of name/value pairs parameters in a URI. It > allows the client and AS to negotiate, and to short circuit having to > redirect the user to the AS. PAR does some of this, but it is constrained > by having to do it in the OAuth 2.0 context. > > > > My concern is that the protocol is MUCH MORE than a transaction. While th= e > initial interaction between client, AS, user and RO is a transaction. The > protocol also covers the client and RS interactions. The access token > refreshes. Access token revocation. Access token introspection. As > described in the charter, there is a whole lifecycle, that consists of > multiple transactions. > > > > From https://www.merriam-webster.com/dictionary/transaction: > > > Definition of *transaction* > > *1a**: *something transacted > *especially* *: *a= n > exchange or transfer of > goods, services, or fundselectronic *transactions* > > *b: transactions** plural* *: *the often published record of the meeting > of a society or association > > *2a**: *an act, process, or instance of transacting > > > *b**: *a communicative action or activity involving two parties or things > that reciprocally affect or influence each other > > > > Calling the protocol a transaction will confusing to people. > > > > > > Having come of age in the 1990=E2=80=99s, I have particular dislike for X= Auth. It > sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and = if you read either of those with a > growling yell in your head then you know exactly what I=E2=80=99m talking= about. > > > > In case you are confused, this is not a childhood trauma support group. = :) > > > > Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. > X-Men, Xbox, X-Factor, X-files. > > > > https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 > > > > > https://english.stackexchange.com/questions/358181/whats-the-purpose-of-u= sing-letter-x-or-x-as-a-suffix-in-brand-names > > > > > > And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT s= ee this > work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think that= does a disservice > to the kind of change we have an opportunity to make here. > > > > From the charter > > > > "It will expand upon the uses cases currently supported by OAuth 2.0 and > OpenID Connect (itself an extension of OAuth 2.0)" > > > > Which sounds pretty similar to =E2=80=9COAuth with all the extra features= =E2=80=9D > > > > While I think XAuth captures what we are doing, a placeholder name would > be preferable to an incorrect descriptive name such as TxAuth. > > > > For example, XYZ is a good placeholder name. Or XYZAuth. Let's not mislea= d > people. > > > > > > =E2=80=94 Justin > > > > On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: > > > > Hello everyone > > > > I prompted a thread around the name of the protocol a while back: > > > > https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/ > > > > As Justin stated "naming is hard" > > > > Wearing my marketing hat I want to ensure that the name will be > perceived properly in the broader community. > > > > A recent example that comes to mind are the privacy related works on the > browser storage API. Given that name, one would think that it is local > storage. It is actually about browser cookies. > > > > Justin discussed his reasons for TxAuth in the thread above (and I'm sure > in other places) > > > > I chose XAuth in my draft to reflect the eXtensibility goal that we have > over OAuth -- and XAuth is OAuth but with an X to reflect all the extra > features. =3D) > > > > Other suggestions? > > > > This will be an agenda item in the BoF -- but the name will NOT be an ope= n > discussion item -- we will summarize what has been discussed on the list > and perhaps do a poll of options presented unless consensus is obvious fr= om > this thread. > > > > /Dick > > > > > > > > > > > > =E1=90=A7 > > > > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 [image: Ping Identity] Brian Campbell Distinguished Engineer bcampbell@pingidentity.com w: +1 720.317.2061 c: +1 303.918.9415 Connect with us: [image: Glassdoor logo] [image: LinkedIn logo] [image: twitter logo] [image: facebook logo] [image: youtube logo] [image: Blog logo] *If you=E2=80=99re not a current customer, click here for a more relevant offer.* --=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._ --00000000000007da2605a18af262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
YAAAAS - Yet Another Authorization And Authentication Spec= ification



--
If you=E2=80=99re not a current customer, click= =C2=A0here=C2=A0for a more relevant offer.<= /div>

<= 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. --00000000000007da2605a18af262-- From nobody Mon Mar 23 12:53:34 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB53A0E64 for ; Mon, 23 Mar 2020 12:53:07 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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=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 LzXgrKMmV6cT for ; Mon, 23 Mar 2020 12:53:05 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640107.outbound.protection.outlook.com [40.107.64.107]) (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 23DA13A0E60 for ; Mon, 23 Mar 2020 12:53:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RYmdqwC1hgy9SKtc3baTI+WgWT2VubUaZznIzCsWSEAGFq+BeBmiAKrKU7cLRFsr2upHlQEE8Oa8Qg3T8OSfUQEf9Ug20P5aHA2Qy+TiCZ+kbTeqXHRV7c9C3s8elh/0PlYpV0TWHUTShay0szCbk04HnGcZ+VF86kQavAKTerERlJ+lYF20UwGO5/PFOq0qA3CSO69pn6fhwHkf4PF9oY0x6BtPMBroQVgZkm1+AfdePurzO3/N4gSrgLN3VZr83Y3B8b43OSaTBkeXbYNkqEGzCd6JxjvW04QlG4KCl5LWH2hhPfP5kXK5+96qJu+639A/uF7zoWnIeJVw10CiqQ== 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=PpUtaGxImPhY8bT08oly4Or9svvjUFBwm/s1MMPW7mQ=; b=RY9I1tchUQbL/deywk3s+MOdtoUNBuWIdjoeKFiKFTKcZK6u5LPCZ0jb/tG3WiDhMnDgLm55PuiAMA8Rkai7Kt07Nbn8TONRpkji1xp4LDrwzGub4js23pwK+ovHVjLYH95WxkenaOZVTZ/DewLFO7HkeUGvO2O777XpaHfTAZbMd3cjlPcNjDyYVQTp1rR949Dqpx0Cvp7dhtZPKf/PNPNPJYCMcAXBDwFS6USksyN1JNQx8QPRMx8hGZPA74lmjJYaw3yb5tzJd0GNOF3z+KBMKws58YuNRkY+7CfpBvC6kQU0tw6oqZ7Ae7cfS0dQc6533DPpu9Eyn5o6Z6/yvA== 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=PpUtaGxImPhY8bT08oly4Or9svvjUFBwm/s1MMPW7mQ=; b=Ts9nYun9EDawqXDbfjAzGIauPyzWzXvMVSIlBRdTV+QotR4SRliN3bUYLJzCiXfou3hBmSYfxGeaYhmOwWVxWrJKVK2vF/dbRPKwN/xL+tqy8V/faFjGqzS4PVDHmetyKJE/q8jlt7OQfeOMdIdtHHFRRzUrfYKqtIMEwXWdqI4= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0664.namprd00.prod.outlook.com (2603:10b6:610:ac::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2892.0; Mon, 23 Mar 2020 19:53:03 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9%7]) with mapi id 15.20.2885.000; Mon, 23 Mar 2020 19:53:03 +0000 From: Mike Jones To: Dick Hardt , "txauth@ietf.org" CC: Justin Richer Thread-Topic: [EXTERNAL] Re: [Txauth] XYZ vs XAuth - 5 differences Thread-Index: AQHV/vTRwl0oE+Nf40mVwMZ4DzinyKhWmdKQ Date: Mon, 23 Mar 2020 19:53:03 +0000 Message-ID: References: In-Reply-To: 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_ActionId=e65bf248-bf9b-4a96-8a03-0000a4645ce2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-23T19:47:23Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f253bee4-4b3e-4875-5583-08d7cf63cc86 x-ms-traffictypediagnostic: CH2PR00MB0664: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(136003)(396003)(39860400002)(346002)(376002)(199004)(76116006)(316002)(76236002)(55016002)(2906002)(66946007)(26005)(8676002)(86362001)(66556008)(66446008)(64756008)(186003)(66476007)(5660300002)(9686003)(110136005)(7696005)(966005)(8936002)(71200400001)(10290500003)(478600001)(33656002)(53546011)(81166006)(81156014)(6506007)(8990500004)(52536014)(4326008)(99710200001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0664; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C2Zy3E5x2XrBxhJxY7UzQqocn9Ur9fJr26ETed+OkYVGAqMsAfsvBSFGRdBWQRyipxNlkQ44FhibiV80dpwy+GHRp1RriS9fCiZs9Uo7nuR6wOirL+gboxesRxbnGj+ktaDm8GfabYKwG26Q5mpBdQrw/vUz4g7Hpyu+n18WF4BAfjnfqIF4o18zrmiNrG8wtGqMqia0J3NGzt7dtF8q6q/L6U9wuJHpNGYzH5csu4rVIZDffmkx5BH1KQ7itWfGUciJVCSuVlUOGgWSQwGNVuuEskN7usI7PRpMQyO/GXfswrFU/JEq861udGAkom+4aJ9VzoDAyvXsPA/jH4dmPWddubKw+ehEsEAjbPU2fMxmyi3U8jozkKqNL60ZTa/Luuzm23j8B+/YuNPzAP27S1zyRr8kll3k++gDzHNEdCuLYUOJsic/SUkOxYlfhlMZMg71zPTPlSNDjxEgOIxKScSfJwdgqYGkkTJhMXhKqs4qZJpGioHoL9U7ZeFctaBR/kVPzLCAzKLPQke0t3olBHG9BblkU4YSCM77U6KRxFbHqprkSG4HTC8BFaWO4B4lo4agcmyv0JyNg4Dz/kpLeQ== x-ms-exchange-antispam-messagedata: Z7jMbX46Cvxi/PTUUdd5n4VooSKtl6PSJzspuIsw1fp+6UOVtTY45jC6cATEG3+ZT7H1I7vrOdlQrgLUTYjB7NArVaM5w8N2GRyJxE6n6MeWlc3SQz1UBL4nHPNDOj2Z5JB5UGFdhcFuvzd1IA0ZMw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679992DE281E9AEC2BDDBB8F5F00CH2PR00MB0679namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f253bee4-4b3e-4875-5583-08d7cf63cc86 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 19:53:03.4758 (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: 1Idggql6Nr2qV7Tj2jcgxp0HzBiFBPWmiTkTkGp61uERL3somGUy1ot5oqzrY6rShmx0pKx9Hkw9GvT8fTyT3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0664 Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 19:53:32 -0000 --_000_CH2PR00MB0679992DE281E9AEC2BDDBB8F5F00CH2PR00MB0679namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBwcmVmZXIgWEF1dGggYXMgYSBzdGFydGluZyBwb2ludCBvdmVyIFhZWiBiZWNhdXNl IFhBdXRoIGlzIGNsZWFybHkgdHJ5aW5nIHRvIHJldXNlIGV4aXN0aW5nIGlkZW50aXR5IHJlcHJl c2VudGF0aW9ucywgd2hlcmVhcyBYWVogaXMgY3JlYXRpbmcgYSBuZXcgb25lLg0KDQpZb3UgY2Fu IHNlZSBYQXV0aOKAmXMgcmV1c2UsIGZvciBpbnN0YW5jZSwgYXQgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTA2I3NlY3Rpb24tNC42LjYuDQoN CllvdSBjYW4gc2VlIFhZWuKAmXMgaW52ZW50aW9uIG9mIGEgbmV3IGlkZW50aXR5IHNjaGVtYSBh dCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwt YXV0aHotMDYjc2VjdGlvbi0yLjcuICBZZXMsIGl04oCZcyBzaW1pbGFyIHRvIHNvbWUgb3RoZXJz IGJ1dCBub3QgdGhlIHNhbWUsIGFuZCByYXRoZXIgdGhhbiByZXVzaW5nIGV4aXN0aW5nIHJlZ2lz dGVyZWQgY2xhaW1zLCBpdOKAmXMgY3JlYXRpbmcgaXRzIG93biB1bmlxdWUgc2V0Lg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg RGljayBIYXJkdA0KU2VudDogRnJpZGF5LCBNYXJjaCAyMCwgMjAyMCAxOjE4IFBNDQpUbzogdHhh dXRoQGlldGYub3JnDQpDYzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KU3ViamVj dDogW0VYVEVSTkFMXSBSZTogW1R4YXV0aF0gWFlaIHZzIFhBdXRoIC0gNSBkaWZmZXJlbmNlcw0K DQpBQ1RJT04gUkVNSU5ERVINCg0KUGxlYXNlIHdlaWdoIGluIHdpdGggeW91ciBwcmVmZXJlbmNl LCB5b3VyIHJhdGlvbmFsZSwgYXMgd2VsbCBhcyBhbnkgcHJvcyBhbmQgY29ucyBub3QgZGVzY3Jp YmVkLg0KDQpZYXJvbiBhbmQgSSB3ZXJlIGhvcGVmdWwgdGhhdCB3ZSB3b3VsZCBnZXQgbW9yZSBm ZWVkYmFjayBvbiB0aGVzZSB0b3BpY3MsIGFzIGl0IHdvdWxkIGhlbHAgZGV0ZXJtaW5lIGlmIGVp dGhlciB0aGUgWFlaIG9yIFhBdXRoIGRvY3VtZW50cyBhcmUgcm91Z2hseSBhbGlnbmVkIHdpdGgg dGhlIGNvbnNlbnN1cyBkaXJlY3Rpb24gb2YgdGhlIGdyb3VwIHNvIHRoYXQgd2UgaGF2ZSBhIHN0 YXJ0aW5nIGRvY3VtZW50Lg0KDQpXZSB3aWxsIE5PVCBiZSBhYmxlIHRvIGRvIGh1bXMgaW4gdGhl IEJvRiAuLi4gc28gd2Ugd2lsbCBub3QgYmUgYWJsZSB0byB1c2UgdGhhdCB0byBqdWRnZSByb3Vn aCBjb25zZW5zdXMuDQoNCi9EaWNrDQoNCk9uIE1vbiwgTWFyIDE2LCAyMDIwIGF0IDQ6MDQgUE0g RGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwu Y29tPj4gd3JvdGU6DQpIZWxsbyBldmVyeW9uZQ0KDQpKdXN0aW4gYW5kIEkgaGF2ZSBoYWQgc29t ZSBlbWFpbHMgYmFjayBhbmQgZm9ydGggY29tcGFyaW5nIGFuZCBjb250cmFzdGluZyBYWVogYW5k IFhBdXRoLiBJJ20gZ29pbmcgdG8gcG9zdCBhIG1lc3NhZ2UgZm9yIGVhY2ggb2YgdGhlIG1ham9y IHBvaW50cywgd2l0aCBKdXN0aW4ncyByYXRpb25hbGUgYW5kIG15IHJhdGlvbmFsZSBmb3Igb3Vy IHJlc3BlY3RpdmUgZGVzaWduIGRlY2lzaW9ucy4gRmVlbCBmcmVlIHRvIGFzayBjbGFyaWZ5aW5n IHF1ZXN0aW9ucyBpbiB0aG9zZSB0aHJlYWRzLg0KDQpQbGVhc2Ugd2VpZ2ggaW4gd2l0aCB5b3Vy IHByZWZlcmVuY2UsIHlvdXIgcmF0aW9uYWxlLCBhcyB3ZWxsIGFzIGFueSBwcm9zIGFuZCBjb25z IG5vdCBkZXNjcmliZWQuDQoNCldlIHdvdWxkIGxpa2UgdG8gZ2V0IGEgc2Vuc2UgZm9yIHRoZSBn cm91cCdzIHZpZXdzIG9uIHRoZXNlIHRvcGljcyBmb3IgdGhlIHZpcnR1YWwgQm9GIGluIGEgd2Vl ay4NCg0KVGhlIGxhdGVzdCBkcmFmdHMgYXJlOg0KDQpYWVo6IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wNg0KDQpYQXV0aDogaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTA1DQoN ClRoYW5rcyENCg0KL0RpY2sNCuGQpw0K --_000_CH2PR00MB0679992DE281E9AEC2BDDBB8F5F00CH2PR00MB0679namp_ 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 MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+SSB3b3VsZCBwcmVmZXIgWEF1dGg8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4gYXMgYSBzdGFydGluZyBwb2ludCBvdmVyIFhZWiBiZWNhdXNlIFhBdXRoIGlzIGNsZWFy bHkgdHJ5aW5nIHRvIHJldXNlIGV4aXN0aW5nIGlkZW50aXR5IHJlcHJlc2VudGF0aW9ucywgd2hl cmVhcyBYWVogaXMgY3JlYXRpbmcgYSBuZXcgb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+WW91IGNhbiBzZWUgWEF1dGjigJlzIHJldXNlLCBmb3IgaW5zdGFuY2UsIGF0 DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgt cHJvdG9jb2wtMDYjc2VjdGlvbi00LjYuNiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDYjc2VjdGlvbi00LjYuNjwvYT4uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5Zb3UgY2FuIHNlZSBYWVrigJlzIGludmVudGlv biBvZiBhIG5ldyBpZGVudGl0eSBzY2hlbWEgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wNiNzZWN0aW9uLTIu NyI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9u YWwtYXV0aHotMDYjc2VjdGlvbi0yLjc8L2E+LiZuYnNwOyBZZXMsIGl04oCZcyBzaW1pbGFyIHRv IHNvbWUgb3RoZXJzIGJ1dCBub3QgdGhlIHNhbWUsIGFuZCByYXRoZXIgdGhhbiByZXVzaW5nIGV4 aXN0aW5nIHJlZ2lzdGVyZWQgY2xhaW1zLCBpdOKAmXMgY3JlYXRpbmcgaXRzIG93biB1bmlxdWUg c2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPkRpY2sgSGFyZHQ8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBNYXJjaCAyMCwgMjAyMCAxOjE4IFBNPGJyPg0KPGI+VG86PC9iPiB0eGF1dGhAaWV0 Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW1R4YXV0aF0gWFlaIHZzIFhB dXRoIC0gNSBkaWZmZXJlbmNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BQ1RJT04gUkVNSU5ERVI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UGxlYXNlIHdlaWdoIGluIHdpdGggeW91ciBwcmVmZXJl bmNlLCB5b3VyIHJhdGlvbmFsZSwgYXMgd2VsbCBhcyBhbnkgcHJvcyBhbmQgY29ucyBub3QgZGVz Y3JpYmVkLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllhcm9uIGFuZCBJIHdlcmUgaG9wZWZ1bCZuYnNwO3Ro YXQgd2Ugd291bGQgZ2V0IG1vcmUgZmVlZGJhY2sgb24gdGhlc2UgdG9waWNzLCBhcyBpdCB3b3Vs ZCBoZWxwIGRldGVybWluZSBpZiBlaXRoZXIgdGhlIFhZWiBvciBYQXV0aCBkb2N1bWVudHMgYXJl IHJvdWdobHkgYWxpZ25lZCB3aXRoIHRoZSBjb25zZW5zdXMgZGlyZWN0aW9uIG9mIHRoZSBncm91 cCBzbyB0aGF0IHdlIGhhdmUgYSBzdGFydGluZyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwgTk9UIGJlIGFibGUgdG8gZG8gaHVt cyBpbiB0aGUgQm9GIC4uLiBzbyB3ZSB3aWxsIG5vdCBiZSBhYmxlIHRvIHVzZSB0aGF0IHRvIGp1 ZGdlIHJvdWdoIGNvbnNlbnN1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+L0RpY2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAxNiwgMjAyMCBhdCA0OjA0 IFBNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBldmVyeW9u ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0aW4gYW5k IEkgaGF2ZSBoYWQgc29tZSBlbWFpbHMgYmFjayBhbmQgZm9ydGggY29tcGFyaW5nIGFuZCBjb250 cmFzdGluZyBYWVogYW5kIFhBdXRoLiBJJ20gZ29pbmcgdG8gcG9zdCBhIG1lc3NhZ2UgZm9yIGVh Y2ggb2YgdGhlIG1ham9yIHBvaW50cywgd2l0aCBKdXN0aW4ncyByYXRpb25hbGUgYW5kIG15IHJh dGlvbmFsZSBmb3Igb3VyIHJlc3BlY3RpdmUgZGVzaWduIGRlY2lzaW9ucy4mbmJzcDtGZWVsIGZy ZWUNCiB0byBhc2sgY2xhcmlmeWluZyBxdWVzdGlvbnMgaW4gdGhvc2UgdGhyZWFkcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UGxlYXNl IHdlaWdoIGluIHdpdGggeW91ciBwcmVmZXJlbmNlLCB5b3VyIHJhdGlvbmFsZSwgYXMgd2VsbCBh cyBhbnkgcHJvcyBhbmQgY29ucyBub3QgZGVzY3JpYmVkLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB3b3VsZCBsaWtl IHRvIGdldCBhIHNlbnNlIGZvciB0aGUgZ3JvdXAncyB2aWV3cyBvbiB0aGVzZSB0b3BpY3MgZm9y IHRoZSB2aXJ0dWFsIEJvRiBpbiBhIHdlZWsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBsYXRlc3QgZHJhZnRzIGFyZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WFlaOiZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rp b25hbC1hdXRoei0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wNjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WEF1dGg6Jm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29s LTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhh cmR0LXhhdXRoLXByb3RvY29sLTA1PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9 IjAiIHdpZHRoPSIxIiBoZWlnaHQ9IjEiIHN0eWxlPSJ3aWR0aDouMDEwNGluO2hlaWdodDouMDEw NGluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNv bS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwPSZhbXA7dHlwZT16ZXJvY29u dGVudCZhbXA7Z3VpZD05OWM4YWY0NC0yMDFjLTQ0MDctYjk2MC1iYWJmMTk3NjgxNGMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CH2PR00MB0679992DE281E9AEC2BDDBB8F5F00CH2PR00MB0679namp_-- From nobody Mon Mar 23 13:27:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB61C3A0E17 for ; Mon, 23 Mar 2020 13:27:05 -0700 (PDT) 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 ahA5GSo4AnlV for ; Mon, 23 Mar 2020 13:27:03 -0700 (PDT) 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 9680A3A0E48 for ; Mon, 23 Mar 2020 13:26:26 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id q9so15817229iod.4 for ; Mon, 23 Mar 2020 13:26:26 -0700 (PDT) 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=Q1oT2D1gIL2ySE5iQQqCKQBkNXHPOW2qcdQOTbxx2Rg=; b=k+0A2ZVIyEKe2ef0VWacPpNo4ZYvRggbPepFnW6Byg5RkUy+jX+6xxbf1KjGJc+hvW +zjELG3qi7WFR0oxe7KVlNUcQZASmRyfz4FrV8Lm4/FI4zpNU9jLQ395RlPU5MkQrd/y Ti4+CMWQTJiGwu8I0jj5CHLuMtISW/nq2FafKYBUD33gEDjmJAorOLAcuN1a6ccmF2s4 6GoeLBiKEDqAzgmtFPFOKg46lw3E9zEDohnDepXT29/9uGBydmOD7SgvWwXNUlwm7QDH 5j5rOTMQPAhQg4t/tRxAqG4d2xn2eGfHqXk1edkDWMDPaUoXNYqf1NZYwGWaTV39PQq/ 4W1Q== 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=Q1oT2D1gIL2ySE5iQQqCKQBkNXHPOW2qcdQOTbxx2Rg=; b=FKffWZWA5kanSt/4YbmjQ4qjKrFz1Lr/m2eiCmSjYHBtMN/BbPfusr9XCau5WR2IYk BTu8cR720okWahswOrOiNGMo7UXPTJIEUhyrkoN39XHc1J7ERWEQdF6phfaARwM3cb2b 2eFn1dCsn1qsQJ/7S9I/jXo2iUiWPGFrVaijF1zj3du1NvMU0SDLxoWsq/v8OyKfOnqR PQ7n55sfVB6iQ1l85UdIGDDtjuPWrmmIoBaHn6bWdzOgPTM2c+AZ1y/0Ipj1TyVn7sMW nK06UW/rVDPU85eZY5or3Cpw/umZ4bhVaGk+vYV8CKDcI1wmdmcM6qqAVSmkiKMHHYny C6vw== X-Gm-Message-State: ANhLgQ10eb4XN7783rxYuPUZFWN09EMhGBnwSO9e/5ccLVzebC5T5Ofw cB1fhpdDtmirlKXe6pHA7sacvBMRKVcwj8e3NAg= X-Google-Smtp-Source: ADFU+vuG4nREh9VdoLamtmZjUPmaNXcrMCV5gLg9MZM1Kmwy0KC3u6EJxhHzIuUmO4joe8I22Huvvxpt6mHa/K7lFrw= X-Received: by 2002:a05:6638:e94:: with SMTP id p20mr15147962jas.15.1584995185613; Mon, 23 Mar 2020 13:26:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijay IETF Date: Tue, 24 Mar 2020 01:56:14 +0530 Message-ID: To: Dick Hardt Cc: David Skaife , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000025fb905a18b736a" Archived-At: Subject: Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 20:27:06 -0000 --000000000000025fb905a18b736a Content-Type: text/plain; charset="UTF-8" Hi Dick, Bluetooth in my mind is a protocol. And it has profiles for various applications. I was merely suggesting a way to satisfy different applications (in various environments) of the client/server protocol without having to specify a "global" default at the protocol layer that *must* be implemented by all to be compliant. Aside if two implementations of Bluetooth choose to implement the protocol, say Link Management Protocol in the controller stack for instance differently in a non-compliant manner, then profile or not there can be no interop between those implementations. So I am a bit lost on the distinction you make between frameworks and protocols and using that to make the case to have a default for interop. Your initial post in this series was to elicit preference among others. My preference is for XYZ's rationale on this topic. I'll leave it there :-) Cheers! --- Vijay On Sun, 22 Mar 2020 at 00:16, Dick Hardt wrote: > Hi Vijay > > Profiles are needed for *frameworks*, since no interop is required -- > both parties need to support the same profile to interop. > > The current charter is developing a *protocol*, which requires interop. > > For example, SCIM does not specify which mechanism to use for the client > to authenticate, which makes SCIM deployments more challenging to setup. I > started the FastFed WG in the OpenID Foundation to deal with getting > enterprise federations setup because there is no MTI, and missing discovery > mechanisms. > > I hear your concerns for constrained environments of not wanting any more > code than is needed, and that a given mechanism that is the better choice > for mobile and PCs may be problematic for a constrained environment. > > > > On Sat, Mar 21, 2020 at 11:03 AM Vijay IETF wrote: > >> Hi Dick, >> >> Thanks. I think I understand the concern now. Response inline. >> >> On Sat, 21 Mar 2020 at 22:52, Dick Hardt wrote: >> >>> Hi Vijay >>> >>> >>> >>> If there is no default or minimum to implement (MTI) requirement, then >>> for interop to be guaranteed between a client and an AS, one of the parties >>> will need to support all of the choices since the other party could choose >>> to support only one of the choices. In this work, we have tended to push >>> complexity to the AS, so the AS would need to implement all choices to be >>> compliant. >>> >>> If there is a default, then only the default MUST be implemented by both >>> parties to be compliant. >>> >> >> I get it. >> >> IMHO, your concern if it were to be the case is a lazy/inefficient way to >> handle/attain interop compliance. I believe there is another way. We could >> take inspiration from [Bluetooth Profiles]( >> https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles). Each profile >> could then specify the defaults that client and AS need to agree on. >> >> >>> >>> Of course, any bespoke implementation can do whatever they want. >>> >>> While you may not personally be a fan of general purpose software, >>> others are, and as a group we need to anticipate the implications for all >>> implementors. >>> >>> >>> >> I hear you. I just didn't have any better way to state my bias towards >> XYZ's rationale in this instance. And I don't agree with a "global" default >> being the normative recommendation. >> >> --- >> Vijay >> > --000000000000025fb905a18b736a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,

Bl= uetooth in my mind is a protocol. And it has profiles for various applicati= ons. I was merely suggesting a way to satisfy different applications (in va= rious environments) of the client/server protocol without having to specify= a "global" default at the protocol layer that *must* be implemen= ted by all to be compliant.

Aside if two imple= mentations of Bluetooth choose to implement the protocol, say Link Manageme= nt Protocol in the controller stack for instance differently in a non-compl= iant manner, then profile or not there can be no interop between those impl= ementations.=C2=A0

So I am a bit lost on the = distinction you make between frameworks and protocols and using that to mak= e the case to have a default for interop.

Your ini= tial post in this series was to elicit preference among others. My preferen= ce is for XYZ's rationale on this topic. I'll leave it there :-)

Cheers!
---
Vijay
<= div>

On Sun, 22 Mar 2020 at 00:16, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Vijay
Profiles are needed for frameworks, since no interop= is required -- both parties need to support the same profile to interop.

The current charter is=C2=A0developing a protoco= l, which requires interop.=C2=A0

For example, = SCIM does not specify which mechanism to use for the client to authenticate= , which makes SCIM deployments more challenging to setup. I started the Fas= tFed WG in the OpenID Foundation to deal with getting enterprise federation= s setup because there is no MTI, and missing discovery mechanisms.

I hear your concerns for constrained environments of not w= anting any more code than is needed, and that a given mechanism that is the= better choice for mobile and PCs may be problematic for a constrained envi= ronment.=C2=A0



On Sat, Mar 21, 2020 at 1= 1:03 AM Vijay IETF <vijay.ietf@gmail.com> wrote:
Hi Dick,

Thanks. I think I understand the concern now. Respo= nse inline.

On Sat, 21 Mar 2020 at 22:52, Dick Hardt <dick.hardt@gmail.com= > wrote:
Hi Vijay

<snip>

<= div>If there is no default or minimum to implement (MTI) requirement, then = for interop to be guaranteed between a client and an AS, one of the parties= will need to support all of the choices since the other party could choose= to support only one of the choices. In this work, we have tended to push c= omplexity to the AS, so the AS would need to implement all choices to be co= mpliant.=C2=A0

If there is a default, then only th= e default MUST be implemented by both parties to be compliant.
<= /blockquote>

I get it.

IMH= O, your concern if it were to be the case is a lazy/inefficient way to hand= le/attain interop compliance. I believe there is another way. We could take= inspiration from [Bluetooth Profiles](https://en.wikipedia.org= /wiki/List_of_Bluetooth_profiles). Each profile could then specify the = defaults that client and AS need to agree on.=C2=A0
=C2=A0
=
Of course, any bespoke implementation can do whatever they want= .=C2=A0

While you may not personally be a fan of g= eneral purpose software, others are, and as a group we need to anticipate t= he implications for all implementors.



I hear you. I just didn't have any= better way to state my bias towards XYZ's rationale in this instance. = And I don't agree with a "global" default being the normative= recommendation.

---
Vijay
--000000000000025fb905a18b736a-- From nobody Mon Mar 23 13:32:48 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABC83A0E70 for ; Mon, 23 Mar 2020 13:32:45 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 hZjtc_DH7MTc for ; Mon, 23 Mar 2020 13:32:41 -0700 (PDT) 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 DF1C53A0E69 for ; Mon, 23 Mar 2020 13:32:34 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id 7so1255882ill.2 for ; Mon, 23 Mar 2020 13:32:34 -0700 (PDT) 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=Jw1mJ4EhgGdbtCabX6uMEFpimLuSSGpi030OeWVkpjk=; b=q+77IRMSPFwspMlrdYzBXjL5DTv00hcBfXH1kIoepMo/ydglqQRzAZmZ+EZ0nRMNFF EamcrSWDhqYC/A9Gl+QFSd+3bsSD36bQUZRNn7oNUooRUVLckDhYYZ7YL6LBvwh+TJdk ymDrUflHScG68XaersewptlLzVxyFiJuohLlUl4trwlNrF/4lKPVWKJfsTJEKah+JZU7 tS3nfz5t3ZZG06kWWKhmqDMiPB0REJKUS8ibaNgETauQN4g5qAnvI8dmWFM/6LqoASAh Np8jDnQHzDz6OO7CCO3rfW9JPDhNzTWkm4ZfqCAHvrjFT1/ggKTebFAXw2tARkE8nCzG gzmw== 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=Jw1mJ4EhgGdbtCabX6uMEFpimLuSSGpi030OeWVkpjk=; b=QN9lspP0RqIC83eph/BQx5enqjEeiwuaqVjHDdrOMQIFby1e79EuqcfAJmaljnSnQm EcQX/CdDUJ7lnb5egrwNQ51k1e4He+m+MtiyfgTO7ANaYsXUf4tY/1fbSbuO+LUpMLwY 3OkHNfb+Ezg5nsdHrHVYK9QO45zQ7ZRaUPBB9Odte1ReO7/aSZNY0wsiTp4NRsOFlXqZ K/Mfu2hkTUuidKMgQmtp9IEZb5szACZAMp5oZOoKCDkhkTEysA1GSsN86YmKuV99gC/J bQcZE6HTMMYrSg9XtehBm8Cgg+qwiM83VmZOH6UUR8y6DHhlgc7bXwZfz1cQaQMMo5zj V/MQ== X-Gm-Message-State: ANhLgQ1lelyLe+9jhyWfhShwxpnTiHIvRNjydBOB9iayyv1l4JGN/7z0 Wd0jmA8JYofL1tjX3fjiRY2AMYMK2qj9Vs9lNCk= X-Google-Smtp-Source: ADFU+vu+7MiPLKlHkfLCLPIB/MbWLRhHCJAq1zj9S7GYt7SMKNlsRCykxpyD143Ng6qUv/zJ1QeiXCzlFu288WvrW0Y= X-Received: by 2002:a92:b606:: with SMTP id s6mr21721725ili.123.1584995554039; Mon, 23 Mar 2020 13:32:34 -0700 (PDT) MIME-Version: 1.0 References: <81F2A493-6F7D-4B66-B675-016B40551315@mit.edu> In-Reply-To: <81F2A493-6F7D-4B66-B675-016B40551315@mit.edu> From: Vijay IETF Date: Tue, 24 Mar 2020 02:02:22 +0530 Message-ID: To: Justin Richer Cc: Mike Jones , Kim , Torsten Lodderstedt , "txauth@ietf.org" , Filip Skokan , Dick Hardt Content-Type: multipart/alternative; boundary="000000000000f81bf105a18b8832" Archived-At: Subject: Re: [Txauth] Proposed TxAuth charter Text X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 20:32:46 -0000 --000000000000f81bf105a18b8832 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 --- Vijay On Tue, 24 Mar 2020 at 01:02, Justin Richer wrote: > Mike, > > A registry is a specific implementation for publishing a schema, and so I > don=E2=80=99t think it=E2=80=99s appropriate to list it in the charter as= either preferred > or prohibited when the real goal is to define the boundaries and > touchpoints of this protocol. > > =E2=80=94 Justin > > On Mar 23, 2020, at 3:25 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I agree that the updates represent some progress. I=E2=80=99d like to ti= ghten the > statement about what the group is not chartered to do to add new registri= es > for identity claims are also out of scope. I propose that revise the > statement below per my text in red: > > *The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new format= s > for identifiers or assertions, nor is the group chartered to develop > schemas for user information, profiles, or other identity attributes, or > new registries for listing such schema elements or identity > attributes, unless a viable existing format is not available.* > > Like Torsten, Kim, and others, I=E2=80=99d still rather that we tackled i= dentity > separately, if at all. My proposal above is my fallback position if we > can=E2=80=99t get consensus to remove identity from the charter. > > -- Mike > > *From:* Dick Hardt > *Sent:* Saturday, March 21, 2020 12:56 PM > *To:* Mike Jones ; Kim ; > Filip Skokan ; Torsten Lodderstedt < > torsten@lodderstedt.net> > *Cc:* txauth@ietf.org > *Subject:* Re: [Txauth] Proposed TxAuth charter Text > > (replying with those that had expressed concerns about the charter on the > To: list to bring it to the top of their inbox) > > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes > below? > > (apologies to anyone I missed in the To: list) > > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer wrote: > > After some great discussions on the list in the last week, Yaron, Dick, > and I have pulled together a new proposed charter. I think this is versio= n > 5.0? But I forget exactly. :) > > I=E2=80=99ve highlighted the new lines in bold here, for those reading t= his email > in HTML. There=E2=80=99s a diff available online at > http://www.mergely.com/RehoJJvW/ (note: go to view->word wrap to be able > to read it better). I=E2=80=99m attaching the .DIFF file generated by Mer= gely as > well, for those of us crusty old unix type folks who like to see that. > > > > > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > *- Support for multiple access tokens in a single request* > *- Support for directed, audience-restricted access tokens* > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including *asserted* identity *claims*) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > *- Mechanisms for the AS and RS to communicate the access granted by an > access token* > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > *The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new format= s > for identifiers or assertions, nor is the group chartered to develop > schemas for user information, profiles, or other identity attributes, > unless a viable existing format is not available. * > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol for TLS, > detached HTTP signature, and embedded HTTP signatures > - Identity and authentication conveyance mechanisms > - Guidelines for use of protocol extension points > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000f81bf105a18b8832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1
---
Vijay

<= br>
On Tue,= 24 Mar 2020 at 01:02, Justin Richer <jricher@mit.edu> wrote:
Mike,

A registry is a specific implementation for publishing a schema, an= d so I don=E2=80=99t think it=E2=80=99s appropriate to list it in the chart= er as either preferred or prohibited when the real goal is to define the bo= undaries and touchpoints of this protocol.

=C2=A0= =E2=80=94 Justin

On Mar 23, 2020= , at 3:25 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc= .ietf.org> wrote:

I agree that the updates represent some progr= ess.=C2=A0 I=E2=80=99d like to tighten the statement about what the group i= s not chartered to do to add new registries for identity claims are also ou= t of scope.=C2=A0 I propose that revise the statement below per my text in = red:
=C2=A0
The group is chartered to de= velop mechanisms for conveying identity information within the protocol inc= luding identifiers (such as email addresses, phone numbers, usernames, and = subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML= Assertions, and Verifiable Credentials). The group is not chartered to dev= elop new formats for identifiers or assertions, nor is the group chartered = to develop schemas for user information, profiles, or other identity attrib= utes,=C2=A0or new registries for lis= ting such schema elements or identity attributes,=C2=A0= unless a viable existing format is not available.
=C2=A0
Like Torsten, Kim, and others= , I=E2=80=99d still rather that we tackled identity separately, if at all.= =C2=A0 My proposal above is my fallback position if we can=E2=80=99t get co= nsensus to remove identity from the charter.
=C2=A0
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke
<= u>=C2=A0
Fro= m:=C2=A0Dick Hardt <dick.= hardt@gmail.com>=C2=A0
Sent:=C2=A0Saturday, March 21, 2020 12:56 PM
To:=C2=A0Mike Jo= nes <Michael.Jones@microsoft.com>; Kim <kim@identityblog.com>; = Filip Skokan <panva.ip@gmail.com>; To= rsten Lodderstedt <torsten@lodderstedt.= net>
Cc:=C2=A0txauth= @ietf.org
Subject:=C2=A0Re: [Txauth] Proposed Tx= Auth charter Text
=C2=A0
(replying with those that had expressed concerns about t= he charter on the To: list to bring it to the top of their inbox)=
=C2=A0
Mik= e, Kim, Torsten, Filip: are your concerns addressed with the changes below?=
=C2=A0
(apologies to anyone I missed in the To: list)
=C2=A0
On = Sat, Mar 21, 2020 at 12:41 PM Justin Richer <jr= icher@mit.edu> wrote:
= After some great discussions on the list in the last week, Yaron, Dick, and= I have pulled together a new proposed charter. I think this is version 5.0= ? But I forget exactly. :)
=C2=A0<= u>
I=E2=80=99ve highlighted the new lines in = bold here, =C2=A0for those reading this email in HTML. There=E2=80=99s a di= ff available online at =C2=A0http://www.= mergely.com/RehoJJvW/=C2=A0 (note: go to view->word wrap to be able = to read it better). I=E2=80=99m attaching the .DIFF file generated by Merge= ly as well, for those of us crusty old unix type folks who like to see that= .
=C2=A0
=C2=A0
=C2=A0=
=C2=A0
= =C2=A0
This group is char= tered to develop a fine-grained delegation protocol for authorization, iden= tity, and API access. This protocol will allow an authorizing party to dele= gate access to client software through an authorization server. It will exp= and upon the uses cases currently supported by OAuth 2.0 and OpenID Connect= (itself an extension of OAuth 2.0) to support authorizations scoped as nar= rowly as a single transaction, provide a clear framework for interaction am= ong all parties involved in the protocol flow, and remove unnecessary depen= dence on a browser or user-agent for coordinating interactions.=C2=A0
=C2=A0
The delegation process will be acted upon by multiple parties in the= protocol, each performing a specific role. The protocol will decouple the = interaction channels, such as the end user=E2=80=99s browser, from the dele= gation channel, which happens directly between the client and the authoriza= tion server (in contrast with OAuth 2.0 which is initiated by the client re= directing the user=E2=80=99s browser). The client and AS will involve a use= r to make an authorization decision as necessary through interaction mechan= isms indicated by the protocol. This decoupling avoids many of the security= concerns and technical challenges of OAuth 2.0 and provides a non-invasive= path for supporting future types of clients and interaction channels.
=C2=A0
Additionally, the delegation process will allow for:<= /div>
=C2=A0
= - Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a s= ingle interaction
- Support for = multiple access tokens in a single request
- Support for directed, audience-restricted access tokens
- Separation between the party au= thorizing access and the party operating the client requesting access
- A variety of client applications, incl= uding Web, mobile, single-page, and interaction-constrained applications=
=C2=A0
=
The group will define extension points for this protocol to allow= for flexibility in areas including:
- Cryptographic agility fo= r keys, message signatures, and proof of possession=C2=A0
- User interaction mechanisms including web and non-= web methods
- Mechanisms for convey= ing user, software, organization, and other pieces of information used in a= uthorization decisions
- Mechanisms= for presenting tokens to resource servers and binding resource requests to= tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegati= on process (including=C2=A0asserted=C2=A0identity=C2=A0claims= )
=C2=A0
<= div>
Additionally, the group will provide mechanisms for managemen= t of the protocol lifecycle including:
=C2=A0
- Discovery of the autho= rization server
- Revocation of act= ive tokens
- Mechanisms for the = AS and RS to communicate the access granted by an access token
=C2=A0
Although the artifacts for this work are not intended or expected to be= backwards-compatible with OAuth 2.0 or OpenID Connect, the group will atte= mpt to simplify migrating from OAuth 2.0 and OpenID Connect to the new prot= ocol where possible.
=C2=A0<= u>
This group is not chartered to develop ext= ensions to OAuth 2.0, and as such will focus on new technological solutions= not necessarily compatible with OAuth 2.0. Functionality that builds direc= tly on OAuth 2.0 will be developed in the OAuth Working Group, including fu= nctionality back-ported from the protocol developed here to OAuth 2.0.
=C2=A0
The group is chartered to develop mechanisms for applying cryptogra= phic methods, such as JOSE and COSE, to the delegation process. This group = is not chartered to develop new cryptographic methods.
<= /div>
=C2=A0
The g= roup is chartered to develop mechanisms for conveying identity information = within the protocol including identifiers (such as email addresses, phone n= umbers, usernames, and subject identifiers) and assertions (such as OpenID = Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group = is not chartered to develop new formats for identifiers or assertions, nor = is the group chartered to develop schemas for user information, profiles, o= r other identity attributes, unless a viable existing format is not availab= le.=C2=A0
=C2=A0<= /div>
The initial work will focus on using HTTP for com= munication between the client and the authorization server, taking advantag= e of optimization features of HTTP2 and HTTP3 where possible, and will stri= ve to enable simple mapping to other protocols such as COAP when doing so d= oes not conflict with the primary focus.
=C2=A0
Milestones to include:=
- Core delegation protocol<= u>
- Key presentation mechanism bindings to t= he core protocol for TLS, detached HTTP signature, and embedded HTTP signat= ures
- Identity and authentication = conveyance mechanisms
- Guidelines = for use of protocol extension points
=C2=A0
=C2=A0=
=C2=A0
=C2=A0
--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= br>--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000f81bf105a18b8832-- From nobody Mon Mar 23 14:58:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE733A0F01 for ; Mon, 23 Mar 2020 14:57:58 -0700 (PDT) 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, 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 uapJdhFCH_hS for ; Mon, 23 Mar 2020 14:57:57 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0D73A0F8F for ; Mon, 23 Mar 2020 14:57:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 5982BA4E3104 for ; Mon, 23 Mar 2020 16:57:52 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQgVbG31Xr_9 for ; Mon, 23 Mar 2020 16:57:51 -0500 (CDT) Received: from [172.16.1.18] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 93223A4E30FB for ; Mon, 23 Mar 2020 16:57:51 -0500 (CDT) From: "Pete Resnick" To: txauth@ietf.org Date: Mon, 23 Mar 2020 16:57:51 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Txauth] Working through differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 21:58:27 -0000 I mentioned this in the jabber chat during the BOF and Bron suggested I post it to the list: I suggest that we have a poll for the differences between XYZ and XAUTH with the following choices for each difference: A. One of these choices is seriously problematic for these reasons... B. I prefer the XYZ/XAuth choice for this one, but could live with either C. Couldn't care less You might end up with an obvious choice to at least start with until someone finds a showstopper. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Mar 23 14:59:53 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711D33A0FAE for ; Mon, 23 Mar 2020 14:59:26 -0700 (PDT) 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=sunet.se 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 N389l6Y8T7LP for ; Mon, 23 Mar 2020 14:59:24 -0700 (PDT) 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 7E9A13A0F68 for ; Mon, 23 Mar 2020 14:59:23 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id n17so6102495lji.8 for ; Mon, 23 Mar 2020 14:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OxjM36sFc8eeK2n6Xz9sM092+m+PnlkIZ8k6sIYNko8=; b=byyvxaGzedQjofB1YJW4t0LCRwLZcfXf9ECs5gxA6pbXEorzPREY7c2sNiA1S1TDJB dmK2YMKPropOhaB8lZYGS72m6PzGsugajwkAWmX/Pk9JoGhjkwyDHhsABquAMVvFQN/y oQ72csP7BwL2QqyXpIMjE8QbtwP0Nrp5Z20vCbUnOELiWf4rfvKQ3VmLWMZI2ZyLxY1Q ND6/894XNWx8SaWkEB0jyLcyKHI94BhbYcVNHNEZ3ihN8cCBDaeoQBtHhit7UaY9dj60 Jmg5pNogUFl4No7RbFMabGpdY087bLYM5OXSgLDyyka4uqO16/CooJIVVIGLqXydwFX1 HUyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OxjM36sFc8eeK2n6Xz9sM092+m+PnlkIZ8k6sIYNko8=; b=WhlxjDEpUl96WGKJWNBfetiW0jD8SOvbFQ8VPmus4GnFGDyqkkVAn4DN8EsZEdBOh8 AF7LEvwLlp1XMrvTG7LE6MKFvZvIKlrasqdMsPcXlnp/HQQOr2q9bCELQla9ftyucisz 5wssXVGcYfCy8rMC/sW9zIn1x1gCz8GeH8Fd7wWgQU9XKSL+cTHInVJNkBpxI5LnfsLr rVSQy5D3f1XvjnXEG23AIdgTsCclqrd48lbba+DdQazijNb2jppMTXHVs5vbRwG4jke3 F+aliGjxp4ilc7L9AuMyoxPc+vM7L5v9zAnjaP+9G28gW4rTdnTR2nWBgYTo4lciTbH5 BP3A== X-Gm-Message-State: ANhLgQ0LY5zoqM1t7ftVZ0155s/eXzAgBjWmLeRlcV50Bl9U7tHp5ZvW RbzvNmE/FlFS6LHneGUkDR3e8aiLNjIZIg== X-Google-Smtp-Source: ADFU+vsLWscI/XZ+1CWUKnMz7dU28YaG5JZGFiuR4GyYwUuGwsNP6nR2TWemuGr8cWTEpuLmaTc2Jg== X-Received: by 2002:a2e:95da:: with SMTP id y26mr5425351ljh.26.1585000761027; Mon, 23 Mar 2020 14:59:21 -0700 (PDT) Received: from [10.0.0.129] (h-98-128-229-152.NA.cust.bahnhof.se. [98.128.229.152]) by smtp.gmail.com with ESMTPSA id k1sm9020156lji.43.2020.03.23.14.59.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Mar 2020 14:59:19 -0700 (PDT) To: txauth@ietf.org References: From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA== Message-ID: <6e077f48-aa6b-3534-df15-28bb8117e5c9@sunet.se> Date: Mon, 23 Mar 2020 22:59:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 21:59:52 -0000 On 2020-03-23 20:49, Brian Campbell wrote: > YAAAAS - Yet Another Authorization And Authentication Specification > Son of OAuth - soauth From nobody Mon Mar 23 15:03:54 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E03A0F4A for ; Mon, 23 Mar 2020 15:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 owIiDVWXdpGi for ; Mon, 23 Mar 2020 15:03:22 -0700 (PDT) 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 C7A233A0EFF for ; Mon, 23 Mar 2020 15:03:19 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02NM3F2p023677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 23 Mar 2020 18:03:18 -0400 Date: Mon, 23 Mar 2020 15:03:15 -0700 From: Benjamin Kaduk To: txauth@ietf.org Message-ID: <20200323220315.GP50174@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Txauth] brainstorming about "layer session management on top of txauth" X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:03:48 -0000 Hi all, We spent a long time talking about what we mean by identity and what should be in scope for us to do vs. reuse, and I had an idea that I wanted to get some feedback on, relating to how we might layer identity/session-management on top of XYZ. (I am not sure yet if it would apply to XAuth or not.) If we talk about how some of the claims conveyed from AS to client relate to who the user is, but as Mike notes this starts to look like a "login" event, and once you have that you want to know about the "logout" event as well. Would it be possible to build something that has the client ask for a resource of "tell me when the user logs out"? We'd of course need to define some way to indicate how the AS would convey that to the client, but on first glance at least it seems like it could work to layer the session-management on top of claims with semantics like that. Whether the resulting set of claims would still look pretty is another matter, though... -Ben From nobody Mon Mar 23 15:06:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC623A0F8B for ; Mon, 23 Mar 2020 15:05:44 -0700 (PDT) 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=outer-planes-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 RHXVpQtEqYEG for ; Mon, 23 Mar 2020 15:05:41 -0700 (PDT) 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 76D783A0F50 for ; Mon, 23 Mar 2020 15:05:41 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id q128so16053887iof.9 for ; Mon, 23 Mar 2020 15:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R2I45DKS5wYBCuvvFw2LQx29id/yjUkvnWZIbUKG0+w=; b=Tv5YsH5Wun1xmQpzG9Q+uu/TMH+yREEVq2nW/axzVVHrdXfoDzBf6UM9r6cZWx1LMA CNbZ/ZwDY4B8RVm6ostxSIMDcG497NiPhO1zlef7qp7jYywWyYePtFVES4RS+tSQ1q9K Rq7YiaKnjo3H12ANrkBV3Vu1bfVwxcXJPN6zWEba3IpuzZewVu6Us6UD6GcF8Pq6jjaF lyXgXso6jU3/akVik47KjU/o8+CQ0l/7icubUdHdCFqVfRGIzwSmmGK7Ox6D4hc2U58L QLbt/tsEDK6CMIToNm+Ba2sZ1bad4KovWXnGElBrQrEbdDtddXaikEMGx5dXxMdYF1EA dlGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R2I45DKS5wYBCuvvFw2LQx29id/yjUkvnWZIbUKG0+w=; b=XvbY/+uJMUmzmjVxfOafRueU92wgo9emYpc2F/r9Isjjyqu8+CEQbE7roeRqJ/QHIN nVvWEWKIu0GpSYTUXqLPyrguwZE4f1FYbWcPsFkXslUaWiyTkelpYYjXDSWIcwVqgeK+ bZb45QEvmMFuCYK07c5FVAGcSWTKQCc4Y4lQY27FvZu8MteBaqKG2h5AKwms3vmEQwOg Det3mcL5YSR9zQzeuYe/DjYHPKQzgzdAc7MLhcBm4OFqxEm+hlr1WCbRX89d2QQp8/Fq uMH6x5pd1RSl+1ed24t9+pG8rq7VccJ9wjEenfzCSp6+7sN/l5AvmGgAeOPaDpLJ4koH Linw== X-Gm-Message-State: ANhLgQ2Xd4eGVyEwB1olHUbgpriVqn3kbeGa4+CsgIQ2PK8t25BYcYW3 sI/ebgu8t22Rsoiz2hKyczeg/pV7TohU9Q== X-Google-Smtp-Source: ADFU+vumKjyOZup9W6k8zSJL1lRNN1h9tcuTHt/57hTb0mRPxCNTqOSdLw1WPOHP44fJOuNuPDD+qg== X-Received: by 2002:a6b:2c0c:: with SMTP id s12mr21324378ios.51.1585001140078; Mon, 23 Mar 2020 15:05:40 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:a47d:717a:3e0a:de03]) by smtp.gmail.com with ESMTPSA id d27sm5672815ilg.13.2020.03.23.15.05.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Mar 2020 15:05:39 -0700 (PDT) To: txauth@ietf.org References: From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <97f48bc7-4970-0ef3-3c90-430eeb36d241@outer-planes.net> Date: Mon, 23 Mar 2020 16:05:37 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:06:08 -0000 On 20/03/23 13:49, Brian Campbell wrote: > YAAAAS - Yet Another Authorization And Authentication Specification > +1 - m&m Matthew A. Miller > On Mon, Mar 23, 2020 at 1:39 PM Mike Jones > > wrote: > > In brainstorming mode…____ > > * Disaggregated Authorization (DisAuth)____ > * Componentized Authorization (CompAuth)____ > * Build-Your-Own Authorization (BYOAuth)____ > * Do-It-Yourself Authorization (DIYAuth)____ > * Refactored Authorization (ReAuth or RefAuth)____ > > __ __ > > And for fun…____ > > * Dismembered Authorization____ > > __ __ > >                                                        -- Mike____ > > __ __ > > *From:* Txauth > *On Behalf Of *David Skaife > *Sent:* Saturday, March 21, 2020 11:22 AM > *To:* Justin Richer > > *Cc:* Yaron Sheffer >; txauth@ietf.org > ; Dick Hardt > > *Subject:* Re: [Txauth] WG name: TxAuth? XAuth? Something else?____ > > __ __ > > I think we're saying the same thing with regards to the working > group name - I was saying it *isn't* particularly important in > comparison to the name of the protocol (which obviously is very > important).____ > > __ __ > > On Sat, Mar 21, 2020 at 6:18 PM Justin Richer > wrote:____ > > I disagree on the working group name being super important. > Nobody knows that the OAuth WG is actually named “The Web > Authorization Protocol Working Group”, and nobody cares.____ > > __ __ > > My proposal is that we name the protocol we work on “TxAuth” > (and keep the mailing list), and that we name the working group > something like “Next Generation Web Authorization Protocol” to > say what we’re doing.____ > > __ __ > >  -- Justin____ > > > > ____ > > On Mar 21, 2020, at 2:08 PM, David Skaife > > wrote:____ > > __ __ > > Just to throw in another suggestion, to address Yaron's > point about some people mistakenly thinking that "Auth" > stands for authentication rather than authorization, how > about naming the working group *AuthZ*____ > > Nice and simple, and it makes it clear what the group is > focused on. > > I think the name of the actual protocol that we produce is > far, far more important that the name of the working group - > and the name of that protocol doesn't need to correlate to > the WG name. Also, we have much more time before we need to > decide on the name of that protocol, even if the > initial draft documents that we produce end up using a > placeholder name.____ > > __ __ > > On Sat, Mar 21, 2020 at 5:44 PM Justin Richer > > wrote:____ > > As you can see in the email you replied to, that is not > even close to what I said. I believe it is a > transaction, and therefore, I do not agree that it’s not > a transaction.____ > > __ __ > > But if we take “Transactional” out of the WG title, I > won’t be offended. If we just call it “TxAuth” without > expansion, then that’s fine.____ > > __ __ > > I do not like calling it “XAuth”. The term “TAuth" was > floated during naming the list, but rejected because > (among other reasons) it would likely be awkwardly > pronounced as “towth” or something. TxAuth reads as “Tee > - ex - oth” more naturally, which was the intent. ____ > > __ __ > > So how about we take a page from the OAuth working group > and name it:____ > > __ __ > > TxAuth - Next Generation Web Authorization Protocol > Working Group____ > > __ __ > > __ __ > >  — Justin____ > > > > ____ > > On Mar 21, 2020, at 1:15 PM, Dick Hardt > > > wrote:____ > > __ __ > > To clarify -- you agree it is not a transaction, and > we will take the word transaction out of the WG > title?____ > > __ __ > > On Fri, Mar 20, 2020 at 5:53 PM Justin Richer > > wrote:____ > > Dick, thanks for pulling the definitions up:____ > > __ __ > > > a communicative action or activity involving > two parties or things that reciprocally affect > or influence each other____ > > __ __ > > This is the kind of thing that I had in mind. > The client and the AS are in a conversation over > time that each one contributes to and each > changes. ____ > > __ __ > > Also — we can just as easily decide that > “TxAuth” doesn’t stand for “Transactional Auth” > much the same way we decided that the “O” in > “OAuth” doesn’t stand for “Open” anymore. ____ > > __ __ > > None of the arguments below in favor of XAuth > have made me like that name better. If it’s just > a “placeholder” name, then why come up with > something new?____ > > __ __ > >  — Justin____ > > > > ____ > > On Mar 20, 2020, at 3:32 PM, Dick Hardt > > wrote:____ > > __ __ > > __ __ > > __ __ > > __ __ > > not a transaction - there are multiple > transactions____ > > __ __ > > backchannel innovation is combination of > here is who I am, and here is what I want to > do____ > > __ __ > > __ __ > > childhood trauma therapy group____ > > __ __ > > __ __ > > __ __ > > On Mon, Mar 16, 2020 at 6:56 PM Justin > Richer > wrote:____ > > Yes, naming things is hard — but I still > believe in the name TxAuth. We’re moving > beyond OAuth, and taking the process of > getting an authorization delegated to > the client software as a multi-step, > multi-party transaction is, I believe, > the key insight that’s letting us move > beyond OAuth’s limitations here. It’s > not just about going to the AS first — > we had that in OAuth 1 and we’re > patching that into OAuth 2 with PAR.. I > really think it’s about the transaction > at the core.. ____ > > __ __ > > OAuth 2.0 had multi-step, multi-party. > TxAuth extends that.____ > > __ __ > > I think the big shift is going to the AS. > This enables the request to be richer with > JSON, instead of name/value pairs parameters > in a URI. It allows the client and AS to > negotiate, and to short circuit having to > redirect the user to the AS. PAR does some > of this, but it is constrained by having to > do it in the OAuth 2.0 context.____ > > __ __ > > My concern is that the protocol is MUCH MORE > than a transaction. While the initial > interaction between client, AS, user and RO > is a transaction. The protocol also covers > the client and RS interactions. The access > token refreshes. Access token revocation. > Access token introspection. As described in > the charter, there is a whole lifecycle, > that consists of multiple transactions.____ > > __ __ > > From https://www.merriam-webster.com/dictionary/transaction:____ > > __ __ > > > Definition of /transaction/____ > > *1a**: *something transacted > /especially/ *: *an > exchange or transfer >  of > goods, services, or > fundselectronic /transactions/____ > > *b: transactions*/ plural/ *: *the often > published record of the meeting of a society > or association____ > > *2a**: *an act, process, or instance > of transacting > ____ > > *b**: *a communicative action or activity > involving two parties or things that > reciprocally affect or influence each other____ > > __ __ > > Calling the protocol a transaction will > confusing to people.____ > >  ____ > > __ __ > > Having come of age in the 1990’s, I have > particular dislike for XAuth. It sounds > too “X-TREME” and “X-CITING”, and if you > read either of those with a growling > yell in your head then you know exactly > what I’m talking about.____ > > __ __ > > In case you are confused, this is not a > childhood trauma support group.  :)____ > > __ __ > > Unlike "X-TREME" or "X-CITING", XAuth is > using the "X" as a placeholder. X-Men, Xbox, > X-Factor, X-files. ____ > > __ __ > > https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4____ > > __ __ > > https://english.stackexchange.com/questions/358181/whats-the-purpose-of-using-letter-x-or-x-as-a-suffix-in-brand-names____ > > __ __ > >  ____ > > And to Dick’s rationale for the name > below, I absolutely do NOT see this work > as “OAuth with all the extra features”. > I think that does a disservice to the > kind of change we have an opportunity to > make here. ____ > > __ __ > > From the charter ____ > > __ __ > > "It will expand upon the uses cases > currently supported by OAuth 2.0 and > OpenID Connect (itself an extension of > OAuth 2.0)"____ > > __ __ > > Which sounds pretty similar to “OAuth with > all the extra features”____ > > __ __ > > While I think XAuth captures what we are > doing, a placeholder name would be > preferable to an incorrect descriptive name > such as TxAuth.____ > > __ __ > > For example, XYZ is a good placeholder name. > Or XYZAuth. Let's not mislead people.____ > >  ____ > > __ __ > >  — Justin____ > > > > ____ > > On Mar 16, 2020, at 7:04 PM, Dick > Hardt > > wrote:____ > > __ __ > > Hello everyone____ > > __ __ > > I prompted a thread around the name > of the protocol a while back:____ > > __ __ > > https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc/____ > > __ __ > > As Justin stated "naming is hard"____ > > __ __ > > Wearing my marketing hat I want to > ensure that the name will be > perceived properly in the broader > community.____ > > __ __ > > A recent example that comes to mind > are the privacy related works on the > browser storage API. Given that > name, one would think that it is > local storage. It is actually about > browser cookies.____ > > __ __ > > Justin discussed his reasons for > TxAuth in the thread above (and I'm > sure in other places)____ > > __ __ > > I chose XAuth in my draft to reflect > the eXtensibility goal that we have > over OAuth -- and XAuth is OAuth but > with an X to reflect all the extra > features. =)____ > > __ __ > > Other suggestions?____ > > __ __ > > This will be an agenda item in the > BoF -- but the name will NOT be an > open discussion item -- we will > summarize what has been discussed on > the list and perhaps do a poll of > options presented unless consensus > is obvious from this thread.____ > > __ __ > > /Dick____ > > __ __ > > __ __ > > __ __ > > __ __ > > __ __ > > ᐧ____ > > __ __ > > __ __ > > __ __ > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth____ > > __ __ > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > > -- > Ping Identity > Brian Campbell > Distinguished Engineer > bcampbell@pingidentity.com > w: +1 720.317.2061 > c: +1 303.918..9415 > > Connect with us: Glassdoor logo > > LinkedIn logo twitter logo > facebook logo > youtube logo > Blog logo > > > > > /If you’re not a current customer, click here >  for > a more relevant offer./ > > /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 Mar 23 15:11:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9729A3A0C0D for ; Mon, 23 Mar 2020 15:11:32 -0700 (PDT) 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 s_mYEd1u8XZ7 for ; Mon, 23 Mar 2020 15:11:28 -0700 (PDT) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 94F9C3A0E35 for ; Mon, 23 Mar 2020 15:11:28 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id g15so5770490ilj.10 for ; Mon, 23 Mar 2020 15:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=C4b5MYVMoA8s1cS4laHHgEfTvqo0yctrHHVHJdIywAc=; b=JAnMjuw50eXtRPLHHwW7JVCCxnHuaonT4X5Yv914q+ra31dYPnt08eBpcYgAjl3UUj R86+E7GOz4ZZOf0Z8340bRES4whZrzDd8OvjvXlxnlEtprTIIEjTNOTKS19GtL2XE0QP kiXeGexplBEvW8ormPcWKqfECDn7165rhRL+SIEH4Fx71iXLIV6PJ2Ad5ouSat5tkIIq +J9z61ZvNROgIjK4aTmr6B8UEJ1BQg2EVVelzPc6L1FmIIjWBSgB5EL+FIR1zt8w9gth iMjyH3pO+dVLK4BsG2rvHA/4mO+4Os9jy7d1Wr3hbK2GHUXh1VFtcNF2rjMhyUlLgYYX Lv4g== 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:reply-to :from:date:message-id:subject:to:cc; bh=C4b5MYVMoA8s1cS4laHHgEfTvqo0yctrHHVHJdIywAc=; b=nZJlNpuTrOPym6gvlq5xljs3aUvI4tUNmZ5xa6vQM8NW6EIrVy2eHUEMCWgogc2qfZ rMGbm6gdLevWTrefHEtqwxC8cQOJF1KSIdRr5dK8GmmCsSolpnxj6g0HaBDHlojz638U 8OMA4CsLOdUirzeOQKSSltpx3i3zg6LnVrTAgfN3IUAuN8hY8rfCq57fhFw7pe0CstyY yQDkNy2YQ7bGd5F+B6yzAEMcdzRtar1yuaXjrlilv/w0BnJibgGCe4ar+TVds53RQFnK MSTvjY8tR4ohnb0tuFkBoDndCzYpPpafym0g77JeDGvGZMu3RBJ2Ag2QlJcaT7DbBJf6 rGgw== X-Gm-Message-State: ANhLgQ2PJI18dQPtD+ahjjepLw6A3B/oxk7+haVrwxdSlP4Sf47nlsp4 Vqr8SlSMD5BlCR+yeuKzb1zlmyUN1xlMG4a0832f3w== X-Google-Smtp-Source: ADFU+vvWK7K13an3QT9abdOursTP7VzmhlC6bbgtpDiFo17T+wb5zjHx1fTdSveQLL0TOgtkHbUvu+8S4APseQt+Nks= X-Received: by 2002:a05:6e02:60f:: with SMTP id t15mr12180172ils.277.1585001487427; Mon, 23 Mar 2020 15:11:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Mon, 23 Mar 2020 15:11:14 -0700 Message-ID: To: Brian Campbell Cc: Mike Jones , Yaron Sheffer , Dick Hardt , "txauth@ietf.org" , Justin Richer , David Skaife Content-Type: multipart/alternative; boundary="000000000000a0b2c705a18ceaf4" Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:11:55 -0000 --000000000000a0b2c705a18ceaf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to YAAAS :) On Mon, Mar 23, 2020 at 12:52 PM Brian Campbell wrote: > YAAAAS - Yet Another Authorization And Authentication Specification > > On Mon, Mar 23, 2020 at 1:39 PM Mike Jones 40microsoft.com@dmarc..ietf.org <40microsoft.com@dmarc.ietf.org>> wrote: > >> In brainstorming mode=E2=80=A6 >> >> - Disaggregated Authorization (DisAuth) >> - Componentized Authorization (CompAuth) >> - Build-Your-Own Authorization (BYOAuth) >> - Do-It-Yourself Authorization (DIYAuth) >> - Refactored Authorization (ReAuth or RefAuth) >> >> >> >> And for fun=E2=80=A6 >> >> - Dismembered Authorization >> >> >> >> -- Mike >> >> >> >> *From:* Txauth *On Behalf Of *David Skaife >> *Sent:* Saturday, March 21, 2020 11:22 AM >> *To:* Justin Richer >> *Cc:* Yaron Sheffer ; txauth@ietf.org; Dick Hardt >> >> *Subject:* Re: [Txauth] WG name: TxAuth? XAuth? Something else? >> >> >> >> I think we're saying the same thing with regards to the working group >> name - I was saying it *isn't* particularly important in comparison to >> the name of the protocol (which obviously is very important). >> >> >> >> On Sat, Mar 21, 2020 at 6:18 PM Justin Richer wrote: >> >> I disagree on the working group name being super important. Nobody knows >> that the OAuth WG is actually named =E2=80=9CThe Web Authorization Proto= col Working >> Group=E2=80=9D, and nobody cares. >> >> >> >> My proposal is that we name the protocol we work on =E2=80=9CTxAuth=E2= =80=9D (and keep >> the mailing list), and that we name the working group something like =E2= =80=9CNext >> Generation Web Authorization Protocol=E2=80=9D to say what we=E2=80=99re= doing. >> >> >> >> -- Justin >> >> >> >> On Mar 21, 2020, at 2:08 PM, David Skaife < >> blue.ringed.octopus.guy@gmail.com> wrote: >> >> >> >> Just to throw in another suggestion, to address Yaron's point about some >> people mistakenly thinking that "Auth" stands for authentication rather >> than authorization, how about naming the working group *AuthZ* >> >> Nice and simple, and it makes it clear what the group is focused on. >> >> I think the name of the actual protocol that we produce is far, far more >> important that the name of the working group - and the name of that >> protocol doesn't need to correlate to the WG name. Also, we have much mo= re >> time before we need to decide on the name of that protocol, even if the >> initial draft documents that we produce end up using a placeholder name. >> >> >> >> On Sat, Mar 21, 2020 at 5:44 PM Justin Richer wrote: >> >> As you can see in the email you replied to, that is not even close to >> what I said. I believe it is a transaction, and therefore, I do not agre= e >> that it=E2=80=99s not a transaction. >> >> >> >> But if we take =E2=80=9CTransactional=E2=80=9D out of the WG title, I wo= n=E2=80=99t be offended. >> If we just call it =E2=80=9CTxAuth=E2=80=9D without expansion, then that= =E2=80=99s fine. >> >> >> >> I do not like calling it =E2=80=9CXAuth=E2=80=9D. The term =E2=80=9CTAut= h" was floated during >> naming the list, but rejected because (among other reasons) it would lik= ely >> be awkwardly pronounced as =E2=80=9Ctowth=E2=80=9D or something. TxAuth = reads as =E2=80=9CTee - ex >> - oth=E2=80=9D more naturally, which was the intent. >> >> >> >> So how about we take a page from the OAuth working group and name it: >> >> >> >> TxAuth - Next Generation Web Authorization Protocol Working Group >> >> >> >> >> >> =E2=80=94 Justin >> >> >> >> On Mar 21, 2020, at 1:15 PM, Dick Hardt wrote: >> >> >> >> To clarify -- you agree it is not a transaction, and we will take the >> word transaction out of the WG title? >> >> >> >> On Fri, Mar 20, 2020 at 5:53 PM Justin Richer wrote: >> >> Dick, thanks for pulling the definitions up: >> >> >> >> > a communicative action or activity involving two parties or things >> that reciprocally affect or influence each other >> >> >> >> This is the kind of thing that I had in mind. The client and the AS are >> in a conversation over time that each one contributes to and each change= s. >> >> >> >> Also =E2=80=94 we can just as easily decide that =E2=80=9CTxAuth=E2=80= =9D doesn=E2=80=99t stand for >> =E2=80=9CTransactional Auth=E2=80=9D much the same way we decided that t= he =E2=80=9CO=E2=80=9D in =E2=80=9COAuth=E2=80=9D >> doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymore. >> >> >> >> None of the arguments below in favor of XAuth have made me like that nam= e >> better. If it=E2=80=99s just a =E2=80=9Cplaceholder=E2=80=9D name, then = why come up with something >> new? >> >> >> >> =E2=80=94 Justin >> >> >> >> On Mar 20, 2020, at 3:32 PM, Dick Hardt wrote: >> >> >> >> >> >> >> >> >> >> not a transaction - there are multiple transactions >> >> >> >> backchannel innovation is combination of here is who I am, and here is >> what I want to do >> >> >> >> >> >> childhood trauma therapy group >> >> >> >> >> >> >> >> On Mon, Mar 16, 2020 at 6:56 PM Justin Richer wrote: >> >> Yes, naming things is hard =E2=80=94 but I still believe in the name TxA= uth. >> We=E2=80=99re moving beyond OAuth, and taking the process of getting an >> authorization delegated to the client software as a multi-step, multi-pa= rty >> transaction is, I believe, the key insight that=E2=80=99s letting us mov= e beyond >> OAuth=E2=80=99s limitations here. It=E2=80=99s not just about going to t= he AS first =E2=80=94 we >> had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PA= R.. I >> really think it=E2=80=99s about the transaction at the core.. >> >> >> >> OAuth 2.0 had multi-step, multi-party. TxAuth extends that. >> >> >> >> I think the big shift is going to the AS. This enables the request to be >> richer with JSON, instead of name/value pairs parameters in a URI. It >> allows the client and AS to negotiate, and to short circuit having to >> redirect the user to the AS. PAR does some of this, but it is constraine= d >> by having to do it in the OAuth 2.0 context. >> >> >> >> My concern is that the protocol is MUCH MORE than a transaction. While >> the initial interaction between client, AS, user and RO is a transaction= . >> The protocol also covers the client and RS interactions. The access toke= n >> refreshes. Access token revocation. Access token introspection. As >> described in the charter, there is a whole lifecycle, that consists of >> multiple transactions. >> >> >> >> From https://www.merriam-webster.com/dictionary/transaction: >> >> >> Definition of *transaction* >> >> *1a**: *something transacted >> *especially* *: *= an >> exchange or transfer >> of goods, >> services, or fundselectronic *transactions* >> >> *b: transactions** plural* *: *the often published record of the meeting >> of a society or association >> >> *2a**: *an act, process, or instance of transacting >> >> >> *b**: *a communicative action or activity involving two parties or >> things that reciprocally affect or influence each other >> >> >> >> Calling the protocol a transaction will confusing to people. >> >> >> >> >> >> Having come of age in the 1990=E2=80=99s, I have particular dislike for = XAuth. It >> sounds too =E2=80=9CX-TREME=E2=80=9D and =E2=80=9CX-CITING=E2=80=9D, and= if you read either of those with a >> growling yell in your head then you know exactly what I=E2=80=99m talkin= g about. >> >> >> >> In case you are confused, this is not a childhood trauma support group. >> :) >> >> >> >> Unlike "X-TREME" or "X-CITING", XAuth is using the "X" as a placeholder. >> X-Men, Xbox, X-Factor, X-files. >> >> >> >> https://www.businessinsider.com/the-indisputable-power-of-brand-x-2012-4 >> >> >> >> >> https://english.stackexchange.com/questions/358181/whats-the-purpose-of-= using-letter-x-or-x-as-a-suffix-in-brand-names >> >> >> >> >> >> And to Dick=E2=80=99s rationale for the name below, I absolutely do NOT = see this >> work as =E2=80=9COAuth with all the extra features=E2=80=9D. I think tha= t does a disservice >> to the kind of change we have an opportunity to make here. >> >> >> >> From the charter >> >> >> >> "It will expand upon the uses cases currently supported by OAuth 2.0 and >> OpenID Connect (itself an extension of OAuth 2.0)" >> >> >> >> Which sounds pretty similar to =E2=80=9COAuth with all the extra feature= s=E2=80=9D >> >> >> >> While I think XAuth captures what we are doing, a placeholder name would >> be preferable to an incorrect descriptive name such as TxAuth. >> >> >> >> For example, XYZ is a good placeholder name. Or XYZAuth. Let's not >> mislead people. >> >> >> >> >> >> =E2=80=94 Justin >> >> >> >> On Mar 16, 2020, at 7:04 PM, Dick Hardt wrote: >> >> >> >> Hello everyone >> >> >> >> I prompted a thread around the name of the protocol a while back: >> >> >> >> https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_s_wc= / >> >> >> >> As Justin stated "naming is hard" >> >> >> >> Wearing my marketing hat I want to ensure that the name will be >> perceived properly in the broader community. >> >> >> >> A recent example that comes to mind are the privacy related works on the >> browser storage API. Given that name, one would think that it is local >> storage. It is actually about browser cookies. >> >> >> >> Justin discussed his reasons for TxAuth in the thread above (and I'm sur= e >> in other places) >> >> >> >> I chose XAuth in my draft to reflect the eXtensibility goal that we have >> over OAuth -- and XAuth is OAuth but with an X to reflect all the extra >> features. =3D) >> >> >> >> Other suggestions? >> >> >> >> This will be an agenda item in the BoF -- but the name will NOT be an >> open discussion item -- we will summarize what has been discussed on the >> list and perhaps do a poll of options presented unless consensus is obvi= ous >> from this thread. >> >> >> >> /Dick >> >> >> >> >> >> >> >> >> >> >> >> =E1=90=A7 >> >> >> >> >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > > -- > [image: Ping Identity] > > Brian Campbell > Distinguished Engineer > bcampbell@pingidentity.com > w: +1 720.317.2061 > c: +1 303.918..9415 > Connect with us: [image: Glassdoor logo] > [image: > LinkedIn logo] [image: twitter > logo] [image: facebook logo] > [image: youtube logo] > [image: Blog logo] > > > > > > > > *If you=E2=80=99re not a current customer, click here > for > a more relevant offer.* > > *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.*-- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a0b2c705a18ceaf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to YAAAS :)

On Mon, Mar 23, 2020 at 12:52 PM Brian C= ampbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
YAAAAS - Yet Another Au= thorization And Authentication Specification

On Mon, Mar 23, 2020 at 1:= 39 PM Mike Jones <Michael.Jones=3D40microsoft.com@dmarc..ietf.org> wrote= :

In brainstorming = mode=E2=80=A6

  • Disaggregated Authorization (DisAuth)
  • Componentized Authorization (CompAuth)
  • Build-Your-Own Authorization (BYOAuth)
  • Do-It-Yourself Authorization (DIYAuth)
  • Refactored Authorization (ReAuth or RefAuth)

=C2=A0<= /u>

And for fun=E2=80= =A6

  • Dismembered Authorization

=C2=A0<= /u>

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

=C2=A0<= /u>

From: Txauth <txauth-bounces@ietf.org> On Beha= lf Of David Skaife
Sent: Saturday, March 21, 2020 11:22 AM
To: Justin Richer <jricher@mit.edu>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; txauth@ietf.org; Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else?=

=C2=A0

I think we're saying the same thing with regards= to the working group name - I was saying it isn't particularly important in comparison to the name of the pr= otocol (which obviously is very important).

=C2=A0

On Sat, Mar 21, 2020 at 6:18 PM Justin Richer <jricher@mit.edu> = wrote:

I disagree on the working group name being super imp= ortant. Nobody knows that the OAuth WG is actually named =E2=80=9CThe Web A= uthorization Protocol Working Group=E2=80=9D, and nobody cares.

=C2=A0

My proposal is that we name the protocol we work on = =E2=80=9CTxAuth=E2=80=9D (and keep the mailing list), and that we name the = working group something like =E2=80=9CNext Generation Web Authorization Pro= tocol=E2=80=9D to say what we=E2=80=99re doing.

=C2=A0

=C2=A0-- Justin



On Mar 21, 2020, at 2:08 PM, David Skaife <blue.ringe= d.octopus.guy@gmail.com> wrote:

=C2=A0

Just to throw in another suggestion, to address Yaro= n's point about some people mistakenly thinking that "Auth" s= tands for authentication rather than authorization, how about naming the wo= rking group AuthZ

Nice and simple, and it makes it clear what the grou= p is focused on.

I think the name of the actual protocol that we produce is far, far more im= portant that the name of the working group - and the name of that protocol = doesn't need to correlate to the WG name. Also, we have much more time = before we need to decide on the name of that protocol, even if the initial=C2=A0draft documents that we produce= end up using a placeholder name.

=C2=A0

On Sat, Mar 21, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> = wrote:

As you can see in the email you replied to, that is = not even close to what I said. I believe it is a transaction, and therefore= , I do not agree that it=E2=80=99s not a transaction.

=C2=A0

But if we take =E2=80=9CTransactional=E2=80=9D out o= f the WG title, I won=E2=80=99t be offended. If we just call it =E2=80=9CTx= Auth=E2=80=9D without expansion, then that=E2=80=99s fine.

=C2=A0

I do not like calling it =E2=80=9CXAuth=E2=80=9D. Th= e term =E2=80=9CTAuth" was floated during naming the list, but rejecte= d because (among other reasons) it would likely be awkwardly pronounced as = =E2=80=9Ctowth=E2=80=9D or something. TxAuth reads as =E2=80=9CTee - ex - o= th=E2=80=9D more naturally, which was the intent.=C2=A0

=C2=A0

So how about we take a page from the OAuth working g= roup and name it:

=C2=A0

TxAuth - Next Generation Web Authorization Protocol = Working Group

=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 21, 2020, at 1:15 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

To clarify -- you agree it is not a transaction, and= we will take the word transaction out of the WG title?

=C2=A0

On Fri, Mar 20, 2020 at 5:53 PM Justin Richer <jricher@mit.edu> = wrote:

Dick, thanks for pulling the definitions up:<= u>

=C2=A0

>=C2=A0a communi= cative action or activity involving two parties or things that reciprocally= affect or influence each other

=C2=A0

This is the kind of thing that I had in mind. The cl= ient and the AS are in a conversation over time that each one contributes t= o and each changes.=C2=A0

=C2=A0

Also =E2=80=94 we can just as easily decide that =E2= =80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9CTransactional Auth= =E2=80=9D much the same way we decided that the =E2=80=9CO=E2=80=9D in =E2= =80=9COAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymo= re.=C2=A0

=C2=A0

None of the arguments below in favor of XAuth have m= ade me like that name better. If it=E2=80=99s just a =E2=80=9Cplaceholder= =E2=80=9D name, then why come up with something new?

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

not a transaction - there are multiple transactions<= u>

=C2=A0

backchannel innovation is combination=C2=A0of here i= s who I am, and here is what I want to do

=C2=A0

=C2=A0

childhood trauma therapy group

=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 16, 2020 at 6:56 PM Justin Richer <jricher@mit.edu> = wrote:

Yes, naming things is hard =E2=80=94 but I still bel= ieve in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the = process of getting an authorization delegated to the client software as a m= ulti-step, multi-party transaction is, I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2=80=99s limi= tations here. It=E2=80=99s not just about going to the AS first =E2=80=94 w= e had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR= .. I really think it=E2=80=99s about the transaction at the core..=C2=A0=

=C2=A0

OAuth 2.0 had multi-step, multi-party. TxAuth extend= s that.

=C2=A0

I think the big shift is going to the AS. This enabl= es the request to be richer with JSON, instead of name/value pairs paramete= rs in a URI. It allows the client and AS to negotiate, and to short circuit= having to redirect the user to the AS. PAR does=C2=A0some of this, but it is constrained by having to do it i= n the OAuth 2.0 context.

=C2=A0

My concern is that the protocol is MUCH MORE than a = transaction. While the initial interaction between client, AS, user and RO = is a transaction. The protocol also covers the client=C2=A0and RS interacti= ons. The access token refreshes. Access token revocation. Access token introspection. As described in the charter,= there is a whole lifecycle, that consists of multiple transactions.=

=C2=A0

=C2=A0

Definition of=C2=A0transaction

1a:=C2=A0something=C2=A0transactedespecially=C2=A0:=C2=A0an exchange or=C2=A0transfer=C2=A0of goods, services, or fundselectronic=C2=A0transaction= s

b:=C2=A0transactions=C2=A0plural=C2=A0:=C2=A0the often published record of the meeting of a society or association

2a:=C2=A0an act, process, or instance of=C2=A0transacting

b= :=C2=A0a communicative action or activity involving two parties or things that reci= procally affect or influence each other

=C2=A0

Calling the protocol a transaction will confusing to= people.

=C2=A0

=C2=A0

Having come of age in the 1990=E2=80=99s, I have par= ticular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you read either of those with a growling ye= ll in your head then you know exactly what I=E2=80=99m talking about.

=C2=A0

In case you are confused, this is not a childhood=C2= =A0trauma support group.=C2=A0 :)

=C2=A0

Unlike "X-TREME" or "X-CITING", = XAuth is using the "X" as a placeholder. X-Men, Xbox, X-Factor, X= -files.=C2=A0

=C2=A0

=C2=A0

=C2=A0

And to Dick=E2=80=99s rationale for the name below, = I absolutely do NOT see this work as =E2=80=9COAuth with all the extra feat= ures=E2=80=9D. I think that does a disservice to the kind of change we have= an opportunity to make here.=C2=A0

=C2=A0

From the charter=C2=A0

=C2=A0

"It will expand upon the uses cases currently s= upported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0)= "

=C2=A0

Which sounds pretty similar to=C2=A0=E2=80=9COAuth w= ith all the extra features=E2=80=9D

=C2=A0

While I think XAuth captures what we are doing, a pl= aceholder name would be preferable to an incorrect descriptive name such as= TxAuth.

=C2=A0

For example, XYZ is a g= ood placeholder name. Or XYZAuth. Let's not mislead people.

=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Hello everyone

=C2=A0

I prompted a thread around the name of the protocol = a while back:

=C2=A0

=C2=A0

As Justin stated "naming is hard"

=C2=A0

Wearing my marketing hat I want to ensure that the n= ame will be perceived=C2=A0properly in the broader community.=

=C2=A0

A recent example that comes to mind are the privacy = related works on the browser storage API. Given that name, one would think = that it is local storage. It is actually about browser cookies.

=C2=A0

Justin discussed his reasons for TxAuth in the threa= d above (and I'm sure in other places)

=C2=A0

I chose XAuth in my draft to reflect the eXtensibili= ty goal that we have over OAuth -- and XAuth is OAuth but with an X to refl= ect all the extra features. =3D)

=C2=A0

Other suggestions?

=C2=A0

This will be an agenda item in the BoF -- but the na= me will NOT be an open discussion item -- we will summarize=C2=A0what has b= een discussed on the list and perhaps do a poll of options presented unless= consensus is obvious from this thread.

=C2=A0

/Dick

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

=C2=A0

=C2=A0

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

=C2=A0

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth


--
=
<= span style=3D"color:rgb(230,29,60);display:inline-block;margin-bottom:3px;f= ont-family:arial,helvetica,sans-serif;font-weight:bold;font-size:14px">Bria= n Campbell
Distinguished Engineer
= bcampbell@pingidentity.com <= br> w: +1 720.317.2061
c: +1 303.918= .9415
= =
Connect with us: 3D"Glassdoor 3D"LinkedIn <= a href=3D"https://twitter.com/pingidentity" style=3D"text-decoration:none;m= argin-right:16px" title=3D"Ping on Twitter" target=3D"_blank">3D"twitter 3D"facebook 3D"youtube = 3D"Blog
3D"Ping = =
Brian Campbell <= br> Distinguished Engineer
bcampbell@pingidentity.com
w: +1 720.31= 7.2061
c: +1 303.918..9415
Connect with us: 3D"Glassdoor 3D"LinkedIn 3D"twitter 3D"facebook 3D"youtube = 3D"Blog
=
If you=E2=80=99re not a current customer, click=C2=A0here=C2=A0for a more relevant offer.

<= 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 th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you.--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000a0b2c705a18ceaf4-- From nobody Mon Mar 23 15:32:12 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA3A3A0E8C for ; Mon, 23 Mar 2020 15:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 q0_ePSFF9mzl for ; Mon, 23 Mar 2020 15:31:40 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650120.outbound.protection.outlook.com [40.107.65.120]) (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 4B84E3A0DD5 for ; Mon, 23 Mar 2020 15:31:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dj2okLlX4n1VeQtxs89KZPdbROO49nlA9lgUy5uQbIjCIgsV3P0cl3bnF+0/WM/QFqh7QTNlXUtDEBUSVUwPnB2uyzw3B0aJoZV4WZsfG63ygAJi+VjcnBTXBs5QnC6tnwIf0I+2rwi7UFLfaJTPevaWty+RdkUidy7D+MLsTxe0OIPJFcHX5yQkAfvzm5uE+ZT2UMe06OQ5GTGWTwqEhHUghmWR/jwJIy5ir7851tu8nbGZOD6qhDaRV4h9/jydw640zxhwqF9fM56urooP+4XegKNNJ8LkE608q1Mn69kFzQSowWAL8TSKfJckKj1w5UJO+SqiHO1IbRXzchK+iQ== 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=f/a02x9aw6HGycG/oaEnqsNCcTGX65k8ArhOTeKKXOY=; b=e/qeNN4c/oy2PexzqqjZ8Rxah2oYak/uTR1yUFupAWlVogrXd2qqp4PaBLFbz1cu76lSlnHxKQKHqLOYPQ7ABeruWz9H09ggWVu4sGOODgFrpZu1c5uPxHwbXTHY8D0Owdltc+e28xjjmOhfnAuosqrNA+sFbQTVHDotFsDzPXibl/jy17lNdUuzhDzXGhpclzYkByy4cc08OSdSjYN1+lkqLbjFDygBcYdaaXcVaOcAZzhEywd0M+2dib7dJExmFcSc65hqQ3bStQR40hd9e8EmsGdV+9C5srTzngT6eR4z3ZVCbPFWPNrN8k9PmSup6Gk1gzZ5Gh8fhqj3FRcJyg== 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=f/a02x9aw6HGycG/oaEnqsNCcTGX65k8ArhOTeKKXOY=; b=W+sxSoNsTwO9qxgAKu0AtvIRrXMsetrOWUys8J5WzmL7bfjSrIz51ZgR+6mmoGi2XaN9mGq2dfSpWB/PlWMcHIzrseYJQxTzzeKGqmH2kQG+Ue1HkgfI7wu/uuE6QajxiGYkjTxvXTPw+68RDfa/lv+9VOqfOGNss8+jKbU7w7Q= Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0844.namprd00.prod.outlook.com (2603:10b6:610:6f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2892.0; Mon, 23 Mar 2020 22:31:32 +0000 Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::cc18:572e:ac38:e7d9%7]) with mapi id 15.20.2885.000; Mon, 23 Mar 2020 22:31:32 +0000 From: Mike Jones To: "Matthew A. Miller" , "txauth@ietf.org" Thread-Topic: [Txauth] WG name: TxAuth? XAuth? Something else? Thread-Index: AdYBYswpvqPARuhMRS2DgRw1Uv+wAA== Date: Mon, 23 Mar 2020 22:31:32 +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_ActionId=2c170396-48a8-4889-a4e1-00003bbdccd1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-23T22:30:52Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e2b2cb21-d78f-475f-98b4-08d7cf79f083 x-ms-traffictypediagnostic: CH2PR00MB0844: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2150; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6029001)(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(110136005)(81166006)(316002)(9686003)(478600001)(8676002)(53546011)(6506007)(5660300002)(52536014)(186003)(55016002)(30864003)(966005)(33656002)(2906002)(10290500003)(8990500004)(26005)(8936002)(7696005)(71200400001)(86362001)(76116006)(66574012)(66946007)(66476007)(64756008)(66556008)(66446008)(81156014)(365024005)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR00MB0844; H:CH2PR00MB0679.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NTidMs7uNO+VrqxfhWm/w/Dwj+CosdMmEFUhd9UVeCIp5BONB8ztTkpjhgaqilHIr5qKAtyfxhGzT0zE57dFYWPlZeuPPPaYelCvBGGqwM57Zejcct/QBLvanNpYgb3AtkCKo5+XkmXrcXLQKKSz7Z/BnlM5YDm5im4QOvrB1tddFQuJmtZeHFT5AwEL2JRxczFgcbjC4MujT0eBuu+3JfoxKaAvHYkZ2MxTL4CC6INKKg24dba0X4AxRnMmIZH+5d8wakajIL5ODVS2wy9/rWivRzyjOEAgdFKfyg2vPK6p27UqpegI3cnleIlY2b4mUSGDw0mlNh0kUPJo4e1HdiDfoATmTeZwkBB/sNA8sSZyepSEwLiY9EndyMykd27gH+WkTzv57HBUWO+F8JjwsdzrkVU8EfdVt2pFB4x3YYdC55FLi1CwBFgdRvrFaIribKYORz77mtY6AX98N2fV46ZDzgB28cBV/V5goCKO4A4hVdYsqKZreI11+9419Hpzi4I5N3Vp+THS4ZFxTw0eiu+ZNVM2PNmYcJO9dN8r3ulK3jZADQ+1zGwQKvp6qMnq x-ms-exchange-antispam-messagedata: l/RvbHonBRMnlJY+hlbUzXk+Q1ju2DJt6Mu0bHzKoxO0tr29KWmEnBguGuKqIDyDlJ2ofaLdlQfKYBetyYuLvL5W62lKXRhPIiwsTEYiH6wnXgQ5/d4DDVDMEelr8jL0KZ1dzHchqM+Z7XVL4tTLKA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2b2cb21-d78f-475f-98b4-08d7cf79f083 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 22:31:32.7819 (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: YoCBkhUwtH/OwAaavF4Z6QT3oP95oKpX2tWVM/kxzBAB1wY18LeBjD7MLfKv9BIZKmgIH9E1eWu+FQraX/097Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0844 Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:32:10 -0000 KzEgdG8gWUFBQUFTDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUeGF1dGgg PHR4YXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWF0dGhldyBBLiBNaWxsZXIN ClNlbnQ6IE1vbmRheSwgTWFyY2ggMjMsIDIwMjAgMzowNiBQTQ0KVG86IHR4YXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFdHIG5hbWU6IFR4QXV0aD8gWEF1dGg/IFNvbWV0aGlu ZyBlbHNlPw0KDQpPbiAyMC8wMy8yMyAxMzo0OSwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+IFlB QUFBUyAtIFlldCBBbm90aGVyIEF1dGhvcml6YXRpb24gQW5kIEF1dGhlbnRpY2F0aW9uIFNwZWNp ZmljYXRpb24NCj4gDQoNCisxDQoNCg0KLSBtJm0NCg0KTWF0dGhldyBBLiBNaWxsZXINCg0KPiBP biBNb24sIE1hciAyMywgMjAyMCBhdCAxOjM5IFBNIE1pa2UgSm9uZXMgDQo+IDxNaWNoYWVsLkpv bmVzPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy4uaWV0Zi5vcmcNCj4gPG1haWx0bzo0MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4gDQo+ICAgICBJbiBicmFpbnN0b3JtaW5n IG1vZGXigKZfX19fDQo+IA0KPiAgICAgICAqIERpc2FnZ3JlZ2F0ZWQgQXV0aG9yaXphdGlvbiAo RGlzQXV0aClfX19fDQo+ICAgICAgICogQ29tcG9uZW50aXplZCBBdXRob3JpemF0aW9uIChDb21w QXV0aClfX19fDQo+ICAgICAgICogQnVpbGQtWW91ci1Pd24gQXV0aG9yaXphdGlvbiAoQllPQXV0 aClfX19fDQo+ICAgICAgICogRG8tSXQtWW91cnNlbGYgQXV0aG9yaXphdGlvbiAoRElZQXV0aClf X19fDQo+ICAgICAgICogUmVmYWN0b3JlZCBBdXRob3JpemF0aW9uIChSZUF1dGggb3IgUmVmQXV0 aClfX19fDQo+IA0KPiAgICAgX1/CoF9fDQo+IA0KPiAgICAgQW5kIGZvciBmdW7igKZfX19fDQo+ IA0KPiAgICAgICAqIERpc21lbWJlcmVkIEF1dGhvcml6YXRpb25fX19fDQo+IA0KPiAgICAgX1/C oF9fDQo+IA0KPiAgICAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIC0tIE1pa2VfX19fDQo+IA0KPiAgICAgX1/CoF9fDQo+IA0KPiAgICAgKkZyb206 KiBUeGF1dGggPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnR4YXV0aC1i b3VuY2VzQGlldGYub3JnPj4gKk9uIEJlaGFsZiBPZiAqRGF2aWQgU2thaWZlDQo+ICAgICAqU2Vu dDoqIFNhdHVyZGF5LCBNYXJjaCAyMSwgMjAyMCAxMToyMiBBTQ0KPiAgICAgKlRvOiogSnVzdGlu IFJpY2hlciA8anJpY2hlckBtaXQuZWR1IDxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4NCj4gICAg ICpDYzoqIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbQ0KPiAgICAgPG1haWx0 bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+PjsgdHhhdXRoQGlldGYub3JnDQo+ICAgICA8bWFpbHRv OnR4YXV0aEBpZXRmLm9yZz47IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tDQo+ICAg ICA8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtU eGF1dGhdIFdHIG5hbWU6IFR4QXV0aD8gWEF1dGg/IFNvbWV0aGluZyANCj4gZWxzZT9fX19fDQo+ IA0KPiAgICAgX1/CoF9fDQo+IA0KPiAgICAgSSB0aGluayB3ZSdyZSBzYXlpbmcgdGhlIHNhbWUg dGhpbmcgd2l0aCByZWdhcmRzIHRvIHRoZSB3b3JraW5nDQo+ICAgICBncm91cCBuYW1lIC0gSSB3 YXMgc2F5aW5nIGl0ICppc24ndCogcGFydGljdWxhcmx5IGltcG9ydGFudCBpbg0KPiAgICAgY29t cGFyaXNvbiB0byB0aGUgbmFtZSBvZiB0aGUgcHJvdG9jb2wgKHdoaWNoIG9idmlvdXNseSBpcyB2 ZXJ5DQo+ICAgICBpbXBvcnRhbnQpLl9fX18NCj4gDQo+ICAgICBfX8KgX18NCj4gDQo+ICAgICBP biBTYXQsIE1hciAyMSwgMjAyMCBhdCA2OjE4IFBNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdQ0KPiAgICAgPG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZTpfX19fDQo+IA0KPiAg ICAgICAgIEkgZGlzYWdyZWUgb24gdGhlIHdvcmtpbmcgZ3JvdXAgbmFtZSBiZWluZyBzdXBlciBp bXBvcnRhbnQuDQo+ICAgICAgICAgTm9ib2R5IGtub3dzIHRoYXQgdGhlIE9BdXRoIFdHIGlzIGFj dHVhbGx5IG5hbWVkIOKAnFRoZSBXZWINCj4gICAgICAgICBBdXRob3JpemF0aW9uIFByb3RvY29s IFdvcmtpbmcgR3JvdXDigJ0sIGFuZCBub2JvZHkgY2FyZXMuX19fXw0KPiANCj4gICAgICAgICBf X8KgX18NCj4gDQo+ICAgICAgICAgTXkgcHJvcG9zYWwgaXMgdGhhdCB3ZSBuYW1lIHRoZSBwcm90 b2NvbCB3ZSB3b3JrIG9uIOKAnFR4QXV0aOKAnQ0KPiAgICAgICAgIChhbmQga2VlcCB0aGUgbWFp bGluZyBsaXN0KSwgYW5kIHRoYXQgd2UgbmFtZSB0aGUgd29ya2luZyBncm91cA0KPiAgICAgICAg IHNvbWV0aGluZyBsaWtlIOKAnE5leHQgR2VuZXJhdGlvbiBXZWIgQXV0aG9yaXphdGlvbiBQcm90 b2NvbOKAnSB0bw0KPiAgICAgICAgIHNheSB3aGF0IHdl4oCZcmUgZG9pbmcuX19fXw0KPiANCj4g ICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgwqAtLSBKdXN0aW5fX19fDQo+IA0KPiANCj4g DQo+ICAgICAgICAgX19fXw0KPiANCj4gICAgICAgICAgICAgT24gTWFyIDIxLCAyMDIwLCBhdCAy OjA4IFBNLCBEYXZpZCBTa2FpZmUNCj4gICAgICAgICAgICAgPGJsdWUucmluZ2VkLm9jdG9wdXMu Z3V5QGdtYWlsLmNvbQ0KPiAgICAgICAgICAgICA8bWFpbHRvOmJsdWUucmluZ2VkLm9jdG9wdXMu Z3V5QGdtYWlsLmNvbT4+IHdyb3RlOl9fX18NCj4gDQo+ICAgICAgICAgICAgIF9fwqBfXw0KPiAN Cj4gICAgICAgICAgICAgSnVzdCB0byB0aHJvdyBpbiBhbm90aGVyIHN1Z2dlc3Rpb24sIHRvIGFk ZHJlc3MgWWFyb24ncw0KPiAgICAgICAgICAgICBwb2ludCBhYm91dCBzb21lIHBlb3BsZSBtaXN0 YWtlbmx5IHRoaW5raW5nIHRoYXQgIkF1dGgiDQo+ICAgICAgICAgICAgIHN0YW5kcyBmb3IgYXV0 aGVudGljYXRpb24gcmF0aGVyIHRoYW4gYXV0aG9yaXphdGlvbiwgaG93DQo+ICAgICAgICAgICAg IGFib3V0IG5hbWluZyB0aGUgd29ya2luZyBncm91cCAqQXV0aFoqX19fXw0KPiANCj4gICAgICAg ICAgICAgTmljZSBhbmQgc2ltcGxlLCBhbmQgaXQgbWFrZXMgaXQgY2xlYXIgd2hhdCB0aGUgZ3Jv dXAgaXMNCj4gICAgICAgICAgICAgZm9jdXNlZCBvbi4NCj4gDQo+ICAgICAgICAgICAgIEkgdGhp bmsgdGhlIG5hbWUgb2YgdGhlIGFjdHVhbCBwcm90b2NvbCB0aGF0IHdlIHByb2R1Y2UgaXMNCj4g ICAgICAgICAgICAgZmFyLCBmYXIgbW9yZSBpbXBvcnRhbnQgdGhhdCB0aGUgbmFtZSBvZiB0aGUg d29ya2luZyBncm91cCAtDQo+ICAgICAgICAgICAgIGFuZCB0aGUgbmFtZSBvZiB0aGF0IHByb3Rv Y29sIGRvZXNuJ3QgbmVlZCB0byBjb3JyZWxhdGUgdG8NCj4gICAgICAgICAgICAgdGhlIFdHIG5h bWUuIEFsc28sIHdlIGhhdmUgbXVjaCBtb3JlIHRpbWUgYmVmb3JlIHdlIG5lZWQgdG8NCj4gICAg ICAgICAgICAgZGVjaWRlIG9uIHRoZSBuYW1lIG9mIHRoYXQgcHJvdG9jb2wsIGV2ZW4gaWYgdGhl DQo+ICAgICAgICAgICAgIGluaXRpYWzCoGRyYWZ0IGRvY3VtZW50cyB0aGF0IHdlIHByb2R1Y2Ug ZW5kIHVwIHVzaW5nIGENCj4gICAgICAgICAgICAgcGxhY2Vob2xkZXIgbmFtZS5fX19fDQo+IA0K PiAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgIE9uIFNhdCwgTWFyIDIxLCAy MDIwIGF0IDU6NDQgUE0gSnVzdGluIFJpY2hlcg0KPiAgICAgICAgICAgICA8anJpY2hlckBtaXQu ZWR1IDxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6X19fXw0KPiANCj4gICAgICAgICAg ICAgICAgIEFzIHlvdSBjYW4gc2VlIGluIHRoZSBlbWFpbCB5b3UgcmVwbGllZCB0bywgdGhhdCBp cyBub3QNCj4gICAgICAgICAgICAgICAgIGV2ZW4gY2xvc2UgdG8gd2hhdCBJIHNhaWQuIEkgYmVs aWV2ZSBpdCBpcyBhDQo+ICAgICAgICAgICAgICAgICB0cmFuc2FjdGlvbiwgYW5kIHRoZXJlZm9y ZSwgSSBkbyBub3QgYWdyZWUgdGhhdCBpdOKAmXMgbm90DQo+ICAgICAgICAgICAgICAgICBhIHRy YW5zYWN0aW9uLl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAg ICAgICAgICAgICBCdXQgaWYgd2UgdGFrZSDigJxUcmFuc2FjdGlvbmFs4oCdIG91dCBvZiB0aGUg V0cgdGl0bGUsIEkNCj4gICAgICAgICAgICAgICAgIHdvbuKAmXQgYmUgb2ZmZW5kZWQuIElmIHdl IGp1c3QgY2FsbCBpdCDigJxUeEF1dGjigJ0gd2l0aG91dA0KPiAgICAgICAgICAgICAgICAgZXhw YW5zaW9uLCB0aGVuIHRoYXTigJlzIGZpbmUuX19fXw0KPiANCj4gICAgICAgICAgICAgICAgIF9f wqBfXw0KPiANCj4gICAgICAgICAgICAgICAgIEkgZG8gbm90IGxpa2UgY2FsbGluZyBpdCDigJxY QXV0aOKAnS4gVGhlIHRlcm0g4oCcVEF1dGgiIHdhcw0KPiAgICAgICAgICAgICAgICAgZmxvYXRl ZCBkdXJpbmcgbmFtaW5nIHRoZSBsaXN0LCBidXQgcmVqZWN0ZWQgYmVjYXVzZQ0KPiAgICAgICAg ICAgICAgICAgKGFtb25nIG90aGVyIHJlYXNvbnMpIGl0IHdvdWxkIGxpa2VseSBiZSBhd2t3YXJk bHkNCj4gICAgICAgICAgICAgICAgIHByb25vdW5jZWQgYXMg4oCcdG93dGjigJ0gb3Igc29tZXRo aW5nLiBUeEF1dGggcmVhZHMgYXMg4oCcVGVlDQo+ICAgICAgICAgICAgICAgICAtIGV4IC0gb3Ro 4oCdIG1vcmUgbmF0dXJhbGx5LCB3aGljaCB3YXMgdGhlIGludGVudC7CoF9fX18NCj4gDQo+ICAg ICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICBTbyBob3cgYWJvdXQg d2UgdGFrZSBhIHBhZ2UgZnJvbSB0aGUgT0F1dGggd29ya2luZyBncm91cA0KPiAgICAgICAgICAg ICAgICAgYW5kIG5hbWUgaXQ6X19fXw0KPiANCj4gICAgICAgICAgICAgICAgIF9fwqBfXw0KPiAN Cj4gICAgICAgICAgICAgICAgIFR4QXV0aCAtIE5leHQgR2VuZXJhdGlvbiBXZWIgQXV0aG9yaXph dGlvbiBQcm90b2NvbA0KPiAgICAgICAgICAgICAgICAgV29ya2luZyBHcm91cF9fX18NCj4gDQo+ ICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICBfX8KgX18NCj4g DQo+ICAgICAgICAgICAgICAgICDCoOKAlCBKdXN0aW5fX19fDQo+IA0KPiANCj4gDQo+ICAgICAg ICAgICAgICAgICBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgIE9uIE1hciAyMSwgMjAy MCwgYXQgMToxNSBQTSwgRGljayBIYXJkdA0KPiAgICAgICAgICAgICAgICAgICAgIDxkaWNrLmhh cmR0QGdtYWlsLmNvbSA8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCj4gICAgICAgICAg ICAgICAgICAgICB3cm90ZTpfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0K PiANCj4gICAgICAgICAgICAgICAgICAgICBUbyBjbGFyaWZ5IC0tIHlvdSBhZ3JlZSBpdCBpcyBu b3QgYSB0cmFuc2FjdGlvbiwgYW5kDQo+ICAgICAgICAgICAgICAgICAgICAgd2Ugd2lsbCB0YWtl IHRoZSB3b3JkIHRyYW5zYWN0aW9uIG91dCBvZiB0aGUgV0cNCj4gICAgICAgICAgICAgICAgICAg ICB0aXRsZT9fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAg ICAgICAgICAgICAgICAgICBPbiBGcmksIE1hciAyMCwgMjAyMCBhdCA1OjUzIFBNIEp1c3RpbiBS aWNoZXINCj4gICAgICAgICAgICAgICAgICAgICA8anJpY2hlckBtaXQuZWR1IDxtYWlsdG86anJp Y2hlckBtaXQuZWR1Pj4gDQo+IHdyb3RlOl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgIERpY2ssIHRoYW5rcyBmb3IgcHVsbGluZyB0aGUgZGVmaW5pdGlvbnMgDQo+IHVwOl9fX18N Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgPsKgYSBjb21tdW5pY2F0aXZlIGFjdGlvbiBvciBhY3Rpdml0eSBpbnZvbHZp bmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgdHdvIHBhcnRpZXMgb3IgdGhpbmdzIHRoYXQg cmVjaXByb2NhbGx5IGFmZmVjdA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBvciBpbmZsdWVu Y2UgZWFjaCBvdGhlcl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0K PiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyBpcyB0aGUga2luZCBvZiB0aGluZyB0 aGF0IEkgaGFkIGluIG1pbmQuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBjbGllbnQg YW5kIHRoZSBBUyBhcmUgaW4gYSBjb252ZXJzYXRpb24gb3Zlcg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICB0aW1lIHRoYXQgZWFjaCBvbmUgY29udHJpYnV0ZXMgdG8gYW5kIGVhY2gNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgY2hhbmdlcy7CoF9fX18NCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgQWxzbyDigJQg d2UgY2FuIGp1c3QgYXMgZWFzaWx5IGRlY2lkZSB0aGF0DQo+ICAgICAgICAgICAgICAgICAgICAg ICAgIOKAnFR4QXV0aOKAnSBkb2VzbuKAmXQgc3RhbmQgZm9yIOKAnFRyYW5zYWN0aW9uYWwgQXV0 aOKAnQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICBtdWNoIHRoZSBzYW1lIHdheSB3ZSBkZWNp ZGVkIHRoYXQgdGhlIOKAnE/igJ0gaW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAg4oCcT0F1 dGjigJ0gZG9lc27igJl0IHN0YW5kIGZvciDigJxPcGVu4oCdIGFueW1vcmUuwqBfX19fDQo+IA0K PiAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgIE5vbmUgb2YgdGhlIGFyZ3VtZW50cyBiZWxvdyBpbiBmYXZvciBvZiBYQXV0aA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICBoYXZlIG1hZGUgbWUgbGlrZSB0aGF0IG5hbWUgYmV0dGVy LiBJZiBpdOKAmXMganVzdA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBhIOKAnHBsYWNlaG9s ZGVy4oCdIG5hbWUsIHRoZW4gd2h5IGNvbWUgdXAgd2l0aA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICBzb21ldGhpbmcgbmV3P19fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIF9f wqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgwqDigJQgSnVzdGluX19fXw0KPiAN Cj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBfX19fDQo+IA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgT24gTWFyIDIwLCAyMDIwLCBhdCAzOjMyIFBNLCBEaWNrIEhhcmR0 DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGljay5oYXJkdEBnbWFpbC5jb20NCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+ PiB3cm90ZTpfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IGEgdHJhbnNh Y3Rpb24gLSB0aGVyZSBhcmUgbXVsdGlwbGUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRyYW5zYWN0aW9uc19fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8Kg X18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiYWNrY2hhbm5lbCBpbm5vdmF0 aW9uIGlzIGNvbWJpbmF0aW9uwqBvZg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaGVy ZSBpcyB3aG8gSSBhbSwgYW5kIGhlcmUgaXMgd2hhdCBJIHdhbnQgdG8NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGRvX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNoaWxkaG9vZCB0cmF1bWEgdGhlcmFweSBncm91 cF9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPbiBN b24sIE1hciAxNiwgMjAyMCBhdCA2OjU2IFBNIEp1c3Rpbg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUmljaGVyIDxqcmljaGVyQG1pdC5lZHUNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6X19fXw0KPiANCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBZZXMsIG5hbWluZyB0aGluZ3MgaXMgaGFyZCDigJQg YnV0IEkgc3RpbGwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWxpZXZlIGlu IHRoZSBuYW1lIFR4QXV0aC4gV2XigJlyZSBtb3ZpbmcNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBiZXlvbmQgT0F1dGgsIGFuZCB0YWtpbmcgdGhlIHByb2Nlc3Mgb2YNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnZXR0aW5nIGFuIGF1dGhvcml6YXRpb24gZGVs ZWdhdGVkIHRvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGNsaWVudCBz b2Z0d2FyZSBhcyBhIG11bHRpLXN0ZXAsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbXVsdGktcGFydHkgdHJhbnNhY3Rpb24gaXMsIEkgYmVsaWV2ZSwNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0aGUga2V5IGluc2lnaHQgdGhhdOKAmXMgbGV0dGluZyB1cyBt b3ZlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmV5b25kIE9BdXRo4oCZcyBs aW1pdGF0aW9ucyBoZXJlLiBJdOKAmXMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBub3QganVzdCBhYm91dCBnb2luZyB0byB0aGUgQVMgZmlyc3Qg4oCUDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgd2UgaGFkIHRoYXQgaW4gT0F1dGggMSBhbmQgd2XigJlyZQ0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhdGNoaW5nIHRoYXQgaW50byBPQXV0 aCAyIHdpdGggUEFSLi4gSQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYWxs eSB0aGluayBpdOKAmXMgYWJvdXQgdGhlIHRyYW5zYWN0aW9uDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYXQgdGhlIGNvcmUuLsKgX19fXw0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9B dXRoIDIuMCBoYWQgbXVsdGktc3RlcCwgbXVsdGktcGFydHkuDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBUeEF1dGggZXh0ZW5kcyB0aGF0Ll9fX18NCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ IHRoaW5rIHRoZSBiaWcgc2hpZnQgaXMgZ29pbmcgdG8gdGhlIEFTLg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGhpcyBlbmFibGVzIHRoZSByZXF1ZXN0IHRvIGJlIHJpY2hlciB3aXRo DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKU09OLCBpbnN0ZWFkIG9mIG5hbWUvdmFs dWUgcGFpcnMgcGFyYW1ldGVycw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gYSBV UkkuIEl0IGFsbG93cyB0aGUgY2xpZW50IGFuZCBBUyB0bw0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbmVnb3RpYXRlLCBhbmQgdG8gc2hvcnQgY2lyY3VpdCBoYXZpbmcgdG8NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHJlZGlyZWN0IHRoZSB1c2VyIHRvIHRoZSBBUy4gUEFS IGRvZXPCoHNvbWUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9mIHRoaXMsIGJ1dCBp dCBpcyBjb25zdHJhaW5lZCBieSBoYXZpbmcgdG8NCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGRvIGl0IGluIHRoZSBPQXV0aCAyLjAgY29udGV4dC5fX19fDQo+IA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTXkgY29uY2VybiBpcyB0aGF0IHRoZSBwcm90b2NvbCBpcyBNVUNIIE1PUkUNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHRoYW4gYSB0cmFuc2FjdGlvbi4gV2hpbGUgdGhlIGluaXRp YWwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludGVyYWN0aW9uIGJldHdlZW4gY2xp ZW50LCBBUywgdXNlciBhbmQgUk8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGEg dHJhbnNhY3Rpb24uIFRoZSBwcm90b2NvbCBhbHNvIGNvdmVycw0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGhlIGNsaWVudMKgYW5kIFJTIGludGVyYWN0aW9ucy4gVGhlIGFjY2Vzcw0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG9rZW4gcmVmcmVzaGVzLiBBY2Nlc3MgdG9r ZW4gcmV2b2NhdGlvbi4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFjY2VzcyB0b2tl biBpbnRyb3NwZWN0aW9uLiBBcyBkZXNjcmliZWQgaW4NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoZSBjaGFydGVyLCB0aGVyZSBpcyBhIHdob2xlIGxpZmVjeWNsZSwNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHRoYXQgY29uc2lzdHMgb2YgbXVsdGlwbGUgDQo+IHRyYW5z YWN0aW9ucy5fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJvbcKgDQo+IGh0dHBzOi8vd3d3Lm1l cnJpYW0td2Vic3Rlci5jb20vZGljdGlvbmFyeS90cmFuc2FjdGlvbjpfX19fDQo+IA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBEZWZpbml0aW9uIG9mwqAvdHJhbnNhY3Rpb24vX19fXw0KPiANCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICoxYSoqOsKgKnNvbWV0aGluZ8KgdHJhbnNhY3Rl ZA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3Lm1lcnJpYW0td2Vi c3Rlci5jb20vZGljdGlvbmFyeS90cmFuc2FjdGVkPi9lc3BlY2lhbGx5L8KgKjrCoCphbg0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZXhjaGFuZ2Ugb3LCoHRyYW5zZmVyDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cubWVycmlhbS13ZWJzdGVyLmNvbS9k aWN0aW9uYXJ5L3RyYW5zZmVyPsKgb2YNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdv b2RzLCBzZXJ2aWNlcywgb3INCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZ1bmRzZWxl Y3Ryb25pY8KgL3RyYW5zYWN0aW9ucy9fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKmI6wqB0cmFuc2FjdGlvbnMqL8KgcGx1cmFsL8KgKjrCoCp0aGUgb2Z0ZW4NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHB1Ymxpc2hlZCByZWNvcmQgb2YgdGhlIG1lZXRpbmcg b2YgYSBzb2NpZXR5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvciBhc3NvY2lhdGlv bl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqMmEqKjrCoCphbiBhY3Qs IHByb2Nlc3MsIG9yIGluc3RhbmNlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZsKg dHJhbnNhY3RpbmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiA8aHR0cHM6Ly93 d3cubWVycmlhbS13ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5L3RyYW5zYWN0aW5nPl9fX18NCj4gDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqYioqOsKgKmEgY29tbXVuaWNhdGl2ZSBhY3Rp b24gb3IgYWN0aXZpdHkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludm9sdmluZyB0 d28gcGFydGllcyBvciB0aGluZ3MgdGhhdA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cmVjaXByb2NhbGx5IGFmZmVjdCBvciBpbmZsdWVuY2UgZWFjaCANCj4gb3RoZXJfX19fDQo+IA0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2FsbGluZyB0aGUgcHJvdG9jb2wgYSB0cmFuc2FjdGlvbiB3aWxsDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25mdXNpbmcgdG8gcGVvcGxlLl9fX18NCj4g DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoF9fX18NCj4gDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEhhdmluZyBjb21lIG9mIGFnZSBpbiB0aGUgMTk5MOKAmXMsIEkgaGF2ZQ0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcnRpY3VsYXIgZGlzbGlrZSBmb3IgWEF1 dGguIEl0IHNvdW5kcw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvbyDigJxY LVRSRU1F4oCdIGFuZCDigJxYLUNJVElOR+KAnSwgYW5kIGlmIHlvdQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHJlYWQgZWl0aGVyIG9mIHRob3NlIHdpdGggYSBncm93bGluZw0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHllbGwgaW4geW91ciBoZWFkIHRoZW4g eW91IGtub3cgZXhhY3RseQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoYXQg SeKAmW0gdGFsa2luZyBhYm91dC5fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW4gY2FzZSB5b3Ug YXJlIGNvbmZ1c2VkLCB0aGlzIGlzIG5vdCBhDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjaGlsZGhvb2TCoHRyYXVtYSBzdXBwb3J0IGdyb3VwLsKgIDopX19fXw0KPiANCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFVubGlrZSAiWC1UUkVNRSIgb3IgIlgtQ0lUSU5HIiwgWEF1dGggaXMNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHVzaW5nIHRoZSAiWCIgYXMgYSBwbGFjZWhvbGRlci4gWC1N ZW4sIFhib3gsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBYLUZhY3RvciwgWC1maWxl cy7CoF9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCj4gaHR0cHM6Ly93d3cuYnVzaW5lc3NpbnNp ZGVyLmNvbS90aGUtaW5kaXNwdXRhYmxlLXBvd2VyLW9mLWJyYW5kLXgtMjAxMg0KPiAtNF9fX18N Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCj4gaHR0cHM6Ly9lbmdsaXNoLnN0YWNrZXhjaGFuZ2UuY29t L3F1ZXN0aW9ucy8zNTgxODEvd2hhdHMtdGhlLXB1cnBvc2Utbw0KPiBmLXVzaW5nLWxldHRlci14 LW9yLXgtYXMtYS1zdWZmaXgtaW4tYnJhbmQtbmFtZXNfX19fDQo+IA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg wqBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCB0byBEaWNr 4oCZcyByYXRpb25hbGUgZm9yIHRoZSBuYW1lDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYmVsb3csIEkgYWJzb2x1dGVseSBkbyBOT1Qgc2VlIHRoaXMgd29yaw0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFzIOKAnE9BdXRoIHdpdGggYWxsIHRoZSBleHRyYSBm ZWF0dXJlc+KAnS4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHRoaW5rIHRo YXQgZG9lcyBhIGRpc3NlcnZpY2UgdG8gdGhlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAga2luZCBvZiBjaGFuZ2Ugd2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0bw0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIG1ha2UgaGVyZS7CoF9fX18NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGcm9tIHRoZSBjaGFydGVywqBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICJJdCB3 aWxsIGV4cGFuZCB1cG9uIHRoZSB1c2VzIGNhc2VzDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLjAgYW5kDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgT3BlbklEIENvbm5lY3QgKGl0c2VsZiBhbiBleHRlbnNp b24gb2YNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCAyLjApIl9fX18N Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBXaGljaCBzb3VuZHMgcHJldHR5IHNpbWlsYXIgdG/CoOKAnE9B dXRoIHdpdGgNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsbCB0aGUgZXh0cmEgZmVh dHVyZXPigJ1fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hpbGUgSSB0aGluayBYQXV0aCBjYXB0 dXJlcyB3aGF0IHdlIGFyZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9pbmcsIGEg cGxhY2Vob2xkZXIgbmFtZSB3b3VsZCBiZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cHJlZmVyYWJsZSB0byBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpdmUgbmFtZQ0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3VjaCBhcyBUeEF1dGguX19fXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IEZvciBleGFtcGxlLCBYWVogaXMgYSBnb29kIHBsYWNlaG9sZGVyIG5hbWUuDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBPciBYWVpBdXRoLiBMZXQncyBub3QgbWlzbGVhZCBwZW9wbGUu X19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKgX19fXw0KPiANCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgwqDigJQgSnVzdGluX19fXw0KPiANCj4gDQo+IA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIF9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE9uIE1hciAxNiwgMjAyMCwgYXQgNzowNCBQTSwgRGljaw0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5j b20NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpkaWNrLmhh cmR0QGdtYWlsLmNvbT4+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdy b3RlOl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBf Xw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGVsbG8gZXZlcnlv bmVfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18N Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEkgcHJvbXB0ZWQgYSB0 aHJlYWQgYXJvdW5kIHRoZSBuYW1lDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG9mIHRoZSBwcm90b2NvbCBhIHdoaWxlIGJhY2s6X19fXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy90eGF1dGgvWlZRVmJIdDRBRHFlaEtyQkRYT3JUcl9zXw0KPiB3Yy9fX19fDQo+IA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFzIEp1c3RpbiBzdGF0ZWQgIm5hbWluZyBpcyANCj4g aGFyZCJfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8Kg X18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdlYXJpbmcgbXkg bWFya2V0aW5nIGhhdCBJIHdhbnQgdG8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgZW5zdXJlIHRoYXQgdGhlIG5hbWUgd2lsbCBiZQ0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwZXJjZWl2ZWTCoHByb3Blcmx5IGluIHRoZSBicm9hZGVyDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbW11bml0eS5fX19fDQo+IA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEEgcmVjZW50IGV4YW1wbGUgdGhhdCBjb21lcyB0 byBtaW5kDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFyZSB0aGUgcHJp dmFjeSByZWxhdGVkIHdvcmtzIG9uIHRoZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBicm93c2VyIHN0b3JhZ2UgQVBJLiBHaXZlbiB0aGF0DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG5hbWUsIG9uZSB3b3VsZCB0aGluayB0aGF0IGl0IGlzDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxvY2FsIHN0b3JhZ2UuIEl0IGlz IGFjdHVhbGx5IGFib3V0DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJy b3dzZXIgY29va2llcy5fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1 c3RpbiBkaXNjdXNzZWQgaGlzIHJlYXNvbnMgZm9yDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFR4QXV0aCBpbiB0aGUgdGhyZWFkIGFib3ZlIChhbmQgSSdtDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1cmUgaW4gb3RoZXIgcGxhY2VzKV9fX18N Cj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSSBjaG9zZSBYQXV0aCBpbiBteSBk cmFmdCB0byByZWZsZWN0DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo ZSBlWHRlbnNpYmlsaXR5IGdvYWwgdGhhdCB3ZSBoYXZlDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG92ZXIgT0F1dGggLS0gYW5kIFhBdXRoIGlzIE9BdXRoIGJ1dA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIGFuIFggdG8gcmVmbGVjdCBh bGwgdGhlIGV4dHJhDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZlYXR1 cmVzLiA9KV9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9f wqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3RoZXIgc3Vn Z2VzdGlvbnM/X19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg X1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzIHdp bGwgYmUgYW4gYWdlbmRhIGl0ZW0gaW4gdGhlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEJvRiAtLSBidXQgdGhlIG5hbWUgd2lsbCBOT1QgYmUgYW4NCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb3BlbiBkaXNjdXNzaW9uIGl0ZW0gLS0gd2Ugd2ls bA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdW1tYXJpemXCoHdoYXQg aGFzIGJlZW4gZGlzY3Vzc2VkIG9uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHRoZSBsaXN0IGFuZCBwZXJoYXBzIGRvIGEgcG9sbCBvZg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBvcHRpb25zIHByZXNlbnRlZCB1bmxlc3MgY29uc2Vuc3VzDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIG9idmlvdXMgZnJvbSB0aGlz IHRocmVhZC5fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBf X8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC9EaWNrX19f Xw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIOGQp19fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg X1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAg ICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAtLSANCj4gICAgICAgICAg ICAgICAgIFR4YXV0aCBtYWlsaW5nIGxpc3QNCj4gICAgICAgICAgICAgICAgIFR4YXV0aEBpZXRm Lm9yZyA8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCj4gICAgICAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoX19fXw0KPiANCj4gICAgICAgICBf X8KgX18NCj4gDQo+ICAgICAtLSANCj4gICAgIFR4YXV0aCBtYWlsaW5nIGxpc3QNCj4gICAgIFR4 YXV0aEBpZXRmLm9yZyA8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCj4gICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo+IA0KPiANCj4gDQo+IC0tIA0KPiA8 aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbT5QaW5nIElkZW50aXR5IDxodHRwczovL3d3dy5w aW5naWRlbnRpdHkuY29tPgkJDQo+IEJyaWFuIENhbXBiZWxsCQ0KPiBEaXN0aW5ndWlzaGVkIEVu Z2luZWVyCQ0KPiBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSA8bWFpbHRvOmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPgkNCj4gdzogKzEgNzIwLjMxNy4yMDYxCQ0KPiBjOiArMSAzMDMuOTE4 Li45NDE1CQ0KPiANCj4gQ29ubmVjdCB3aXRoIHVzOiAJR2xhc3Nkb29yIGxvZ28NCj4gPGh0dHBz Oi8vd3d3LmdsYXNzZG9vci5jb20vT3ZlcnZpZXcvV29ya2luZy1hdC1QaW5nLUlkZW50aXR5LUVJ X0lFMzgwOQ0KPiAwNy4xMSwyNC5odG0+IExpbmtlZEluIGxvZ28gPGh0dHBzOi8vd3d3Lmxpbmtl ZGluLmNvbS9jb21wYW55LzIxODcwPiANCj4gdHdpdHRlciBsb2dvDQo+IDxodHRwczovL3R3aXR0 ZXIuY29tL3BpbmdpZGVudGl0eT4JZmFjZWJvb2sgbG9nbw0KPiA8aHR0cHM6Ly93d3cuZmFjZWJv b2suY29tL3BpbmdpZGVudGl0eXBhZ2U+CXlvdXR1YmUgbG9nbw0KPiA8aHR0cHM6Ly93d3cueW91 dHViZS5jb20vdXNlci9QaW5nSWRlbnRpdHlUVj4gQmxvZyBsb2dvDQo+IDxodHRwczovL3d3dy5w aW5naWRlbnRpdHkuY29tL2VuL2Jsb2cuaHRtbD4JDQo+IA0KPiA8aHR0cHM6Ly93d3cuZ29vZ2xl LmNvbS91cmw/cT1odHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tL2NvbnRlbnQvZGFtDQo+IC9w aW5nLTYtMi1hc3NldHMvQXNzZXRzL2ZhcXMvZW4vY29uc3VtZXItYXR0aXR1ZGVzLXBvc3QtYnJl YWNoLWVyYS0zMzcNCj4gNS5wZGY/aWQlM0RiNjMyMmE4MC1mMjg1LTExZTMtYWMxMC0wODAwMjAw YzlhNjYmc291cmNlPWdtYWlsJnVzdD0xNTQxNg0KPiA5MzYwODUyNjAwMCZ1c2c9QUZRakNOR0Js NWNQSENVQVZLR1pfTm5wdUZqNVBIR1NVUT48aHR0cHM6Ly93d3cucGluZ2lkDQo+IGVudGl0eS5j b20vZW4vZXZlbnRzL2QvaWRlbnRpZnktMjAxOS5odG1sPjxodHRwczovL3d3dy5waW5naWRlbnRp dHkuY28NCj4gbS9jb250ZW50L2RhbS9waW5nLTYtMi1hc3NldHMvQXNzZXRzL01pc2MvZW4vMzQ2 NC1jb25zdW1lcnN1cnZleS1leGVjcw0KPiB1bW1hcnkucGRmPjxodHRwczovL3d3dy5waW5naWRl bnRpdHkuY29tL2VuL2V2ZW50cy9lL3JzYS5odG1sPjxodHRwczovDQo+IC93d3cucGluZ2lkZW50 aXR5LmNvbS9lbi9ldmVudHMvZS9yc2EuaHRtbD48aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmMN Cj4gb20vZW4vbHAvZS9lbmFibGluZy13b3JrLWZyb20taG9tZS13aXRoLU1GQS5odG1sPg0KPiAN Cj4gL0lmIHlvdeKAmXJlIG5vdCBhIGN1cnJlbnQgY3VzdG9tZXIsIGNsaWNrwqBoZXJlIA0KPiA8 aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9lbi9scC9lL3dvcmstZnJvbS1ob21lLXNzby1t ZmEuaHRtbD91dG1fDQo+IHNvdXJjZT1FbWFpbCZ1dG1fY2FtcGFpZ249V0YtQ09WSUQxOS1OZXct RU1TSUc+wqBmb3IgYSBtb3JlIHJlbGV2YW50IA0KPiBvZmZlci4vDQo+IA0KPiAvQ09ORklERU5U SUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIA0K PiBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJl Y2lwaWVudChzKS4gQW55IA0KPiByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1 cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IA0KPiBwcm9oaWJpdGVkLi7CoCBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSANCj4gbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5k IGFueSANCj4gZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4v DQo+IA0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0K From nobody Mon Mar 23 16:38:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE23A0EE4 for ; Mon, 23 Mar 2020 16:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 JprZOeFtjcat for ; Mon, 23 Mar 2020 16:38:19 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (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 AC04A3A0E6A for ; Mon, 23 Mar 2020 16:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1585006700; x=1616542700; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=rFsQN3hhD/qNok14cUwRqPwv9JPqIfYA+4lxVaOyEBg=; b=bbZo6M5TW1o6c9+51bvhRP09mSsxmknq71ScVAotreepOWaG+wbXVwIa PkeIERVHqqa0DZL4l+58HlY/DmRoOTFCDQ3x58v8dLjegfU6PFXtrWOOg Z8o5+X8eKwEiT2vpIedFK47wR2SKNlPSjuu2RYNpCuuLVBI9Kj4IKmNFw E=; IronPort-SDR: WzSzg79p2phudU8apGhsF14gFbcFkavn04sAUCoGy9lrKwjkZN/25wZLDvOc4fpXVOI6rgHRSv JsxEHuwoyPhA== X-IronPort-AV: E=Sophos;i="5.72,298,1580774400"; d="scan'208";a="24674579" Thread-Topic: [Txauth] Multiple Access Tokens in XYZ Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 23 Mar 2020 23:38:17 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com (Postfix) with ESMTPS id F21FDA24D8; Mon, 23 Mar 2020 23:38:14 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Mar 2020 23:38:13 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Mar 2020 23:38:13 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Mon, 23 Mar 2020 23:38:13 +0000 From: "Richard Backman, Annabelle" To: Torsten Lodderstedt CC: Dick Hardt , Justin Richer , "txauth@ietf.org" Thread-Index: AQHV/D2pNyaLF7VPskmHhMHMOPJA4KhP7p4AgAGo3wCAADzqAP//rgcAgAGCqACAA2VSgA== Date: Mon, 23 Mar 2020 23:38:13 +0000 Message-ID: <29FF8555-0E99-4604-8122-BF548D04A4EA@amazon.com> References: <8966AC86-A51E-4E3A-A0D1-9DF407EA71B4@mit.edu> <2D373529-AA1C-450E-8F7D-955437F9CC4B@lodderstedt.net> <325684E9-590E-4095-8C58-E0B7CD9AF467@lodderstedt.net> <8C28432D-E110-40B1-B9D4-61777D1953C4@mit.edu> <140C2C24-2CCE-4848-AC4A-E16154CF17B7@mit.edu> <1B67E92E-8344-4AEB-8ED6-1A6D36722EE1@mit.edu> <32B3E525-B4C1-4791-8DD9-B5327B418E0B@lodderstedt.net> In-Reply-To: <32B3E525-B4C1-4791-8DD9-B5327B418E0B@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.173] Content-Type: text/plain; charset="utf-8" Content-ID: <1667BC0760F4644E8FD1313003579537@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Multiple Access Tokens in XYZ X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 23:38:22 -0000 DQoNCu+7vz4gT24gMy8yMS8yMCwgNTo0NyBBTSwgIlRvcnN0ZW4gTG9kZGVyc3RlZHQiIDx0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6DQo+DQo+PiBPbiAyMC4gTWFyIDIwMjAsIGF0IDIx OjQyLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbT4gd3Jv dGU6DQo+Pg0KPj4gSSBhbSBhbHNvIG9wcG9zZWQgdG8gcmVxdWlyaW5nIENsaWVudHMgdG8gc3Vw cG9ydCBhcmJpdHJhcmlseSBzcGxpdCBhY2Nlc3MgdG9rZW5zLiBJZiB3ZSBhcmUgdG8gc3VwcG9y dCBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zLCB3ZSBuZWVkIHRvIGRvIHNvIGluIGEgd2F5IHRoYXQg ZG9lcyBub3QgYWR2ZXJzZWx5IGltcGFjdCB0aGUgbWFueSBkZXBsb3ltZW50cyBmb3Igd2hpY2gg dGhleSBhcmUgYW4gdW5uZWNlc3NhcnkgY29tcGxpY2F0aW9uLiBTZWNvbmRpbmcgRGlja+KAmXMg Y29tbWVudCB0aGF0IOKAnHNwbGl0X3Rva2Vuc+KAnSBpcyBvdmVybHkgY29tcGxleC4gSXQgZmVl bHMgdG8gbWUgbGlrZSB0aGUgc29ydCBvZiBvcHRpb24gdGhhdCB3b3VsZCBodXJ0IGludGVyb3Bl cmFiaWxpdHkgaW4gdGhlIGxvbmcgcnVuLg0KPj4NCj4+IEkgd2FudCB0byBtYWtlIHN1cmUgd2Ug YXJlIG5vdCBwb3NpdGlvbmluZyBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIGFzIGEgbmVjZXNzYXJ5 IHJlcXVpcmVtZW50IGZvciBBU2VzIHRoYXQgc3VwcG9ydCBtdWx0aXBsZSBSU2VzLiBUaGVyZSBh cmUgb3RoZXIgd2F5cyB0byBkbyB0aGF0LCBlYWNoIHdpdGggZGlmZmVyZW50IHByb3MgYW5kIGNv bnMgdGhhdCBjYW7igJl0IGJlIHByb3Blcmx5IGV2YWx1YXRlZCBvdXRzaWRlIHRoZSBjb250ZXh0 IG9mIGFuIGFjdHVhbCBwcm90b2NvbCwgYW5kIGV2ZW4gdGhlbiBkaWZmZXJlbnQgZGVwbG95bWVu dHMgbWF5IHdlaWdoIHRob3NlIHByb3MgYW5kIGNvbnMgZGlmZmVyZW50bHkuDQo+DQo+IEkgZGlk IG5vdCBwcm9wb3NlIHRvIG1ha2Ugc3VwcG9ydCBmb3IgUlMtc3BlY2lmaWMgYWNjZXNzIHRva2Vu cyBhIHJlcXVpcmVtZW50IGZvciBBU3MsIEkgc3VnZ2VzdGVkIHRvIGdpdmUgQVNzIHRoaXMgYWRk aXRpb25hbCBvcHRpb24gYW5kIG1ha2UgdGhhdCBhIGZpcnN0IGNsYXNzIGNpdGl6ZW4gaW4gdGhl IHByb3RvY29sLiBPdGhlcndpc2UsIHRoZSDigJxvbmUgYWNjZXNzIHRva2VucyBpcyBzdWZmaWNp ZW504oCdIHN0YXRlbWVudCB3aWxsIGJlIGEgc2VsZiBmdWxmaWxsaW5nIHByb3BoZWN5IGFuZCB3 aWxsIGZvcmNlIGRlcGxveW1lbnRzIHdpdGggcmVxdWlyZW1lbnRzIHRoYXQgY2Fubm90IGJlIGZ1 bGZpbGxlZCB1c2luZyBzaW5nbGUgdG9rZW4gKyB0b2tlbiBpbnRyb3NwZWN0aW9uIHRvIGdvIHBy b3ByaWV0YXJ5Lg0KDQpJIHNhaWQgSSBhbSBhZ2FpbnN0IG1ha2luZyB0aGlzIGEgcmVxdWlyZW1l bnQgZm9yIENsaWVudHMsIG5vdCBBU2VzLiBJIGFtIGZ1bGx5IG9uIGJvYXJkIHdpdGggc3VwcG9y dGluZyBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zLCBidXQgaWYgYW4gQVMgY2FuIGFyYml0cmFyaWx5 IGRlY2lkZSB0byBzcGxpdCB0aGUgZ3JhbnQgaW50byBtb3JlIHRva2VucyB0aGFuIHRoZSBDbGll bnQgcmVxdWVzdGVkLCB0aGVuIGJvdGggbXVsdGlwbGUgdG9rZW5zIGFuZCBhcmJpdHJhcnkgdG9r ZW4gc3BsaXR0aW5nIGJlY29tZSBNVEkgZm9yIGFueSBDbGllbnQgdGhhdCBpc24ndCBjb3VwbGVk IHRvIGEgc3BlY2lmaWMgc2V0IG9mIEFTZXMgdGhhdCB0aGUgQ2xpZW50IGNhbiB0cnVzdCBub3Qg dG8gc3BsaXQgdG9rZW5zLiBNdWx0aXBsZSB0b2tlbiBzdXBwb3J0IG9uIGl0cyBvd24gYWRkcyBj b21wbGV4aXR5IGZvciB0aGUgQ2xpZW50OyBhcmJpdHJhcnkgdG9rZW4gc3VwcG9ydCBldmVuIG1v cmUgc28uDQoNCj4NCj4+DQo+PiBTaW1pbGFybHksIHdlIHNob3VsZCBub3QgYmUgY29uc3RyYWlu aW5nIGhvdyBBU2VzIGFuZCBSU2VzIHNoYXJlIGluZm9ybWF0aW9uLg0KPg0KPiBUaGUgcHJvcG9z YWwgaXMgdG8gY29uc2lkZXIgdGhpcyBpbnRlcmZhY2UgYXMgaXQgaXMgbW9yZSBvciBsZXNzIGNv bXBsZXRlbHkgdW5kZWZpbmVkIGluIE9BdXRoIDIgYW5kIHRoZSBjdXJyZW50IFRYQXV0aCBjaGFy dGVyLiBUaGlzIGNhdXNlcyBsb3Qgb2YgbWlzY29uY2VwdGlvbnMgYW5kIGZ1bmN0aW9uYWwgZ2Fw cy9kaWZmZXJlbmNlcyBpbiBwcm9kdWN0cy9saWJyYXJpZXMuIEkgdGhpbmsgd2UgYXJlIGFibGUs IGluIHRoZSBzYW1lIGFzIGZvciBjbGllbnQsIHRvIGRlZmluZSByYWlscyB0byBmb3N0ZXIgaW50 ZXJvcGVyYWJpbGl0eSB3aGlsZSBhbGxvd2luZyBmb3IgYSBicm9hZCByYW5nZSBvZiBpbXBsZW1l bnRhdGlvbiBvcHRpb25zLg0KDQpNeSBjb21tZW50IGlzIGEgcmVzcG9uc2UgdG8geW91ciBzdGF0 ZW1lbnQgdGhhdCB5b3Ugd2FudCAiaW50ZXJvcGVyYWJsZSBwcm90b2NvbCBzdXBwb3J0IGZvciB1 c2Ugb2YgUlMtc3BlY2lmaWMgc2VsZi1jb250YWluZWQgYWNjZXNzIHRva2VucyBpbiBtdWx0aS1S UyBkZXBsb3ltZW50cywiIGFuZCBNaWtlJ3Mgc3Vic2VxdWVudCBzdGF0ZW1lbnQgdGhhdCBoZSBh Z3JlZXMgIndpdGggVG9yc3RlbidzIHBvaW50IHRoYXQgdGhlIGFjY2VzcyB0b2tlbnMgc2hvdWxk IGJlIHNlbGYtY29udGFpbmVkIHdpdGggZXZlcnl0aGluZyB0aGF0IHRoZSByZXNvdXJjZSBuZWVk cy4iIEkgd291bGQgc3VwcG9ydCBkZWZpbmluZyBhbiBvcHRpb25hbCBBUy9SUyBpbnRlcmZhY2Ug cHJvdmlkZWQgdGhhdCBpdCBpcyBub3QgTVRJLCBhbmQgdGhhdCBwcm90b2NvbCBmZWF0dXJlcyBs aWtlIG11bHRpLVJTIG9yIG11bHRpcGxlIHRva2VuIHN1cHBvcnQgZG8gbm90IHJlcXVpcmUgaXQu DQoNCj4NCj4+IEFnYWluLCBkaWZmZXJlbnQgZGVwbG95bWVudHMgd2lsbCBjYWxsIGZvciBkaWZm ZXJlbnQgYXBwcm9hY2hlcy4NCj4NCj4gSSB0aGluayB3ZSBzaG91bGQgZGlzY3VzcyBleGFjdGx5 IHRoaXMgZGlmZmVyZW50IGFwcHJvYWNoZXMgKGV4cGVyaWVuY2VzKSB0byBnZXQgYSBzZW5zZSBv ZiB0aGUgc2l6ZSBvZiB0aGUgcGxheWluZyBmaWVsZC4NCj4NCj4+IEkgZG8gbGlrZSBKdXN0aW7i gJlzIHN1Z2dlc3Rpb24gKHBlcmhhcHMgb24gYW5vdGhlciB0aHJlYWQ/KSBvZiBzdGFuZGFyZGl6 aW5nIGEgc2NoZW1hIHRoYXQgdG9rZW4gY2xhaW1zLCBBUEkgcmVzdWx0cywgZXRjLiBjb3VsZCBh ZGhlcmUgdG8uDQo+Pg0KPg0KPiBUaGF0IG1pZ2h0IGJlIGEgcmVzdWx0LCBJIHBlcnNvbmFsbHkg bGlrZSBOYXTigJlzIGlkZWEgb2Ygd3JpdGluZyB1cCBhbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQg Zmlyc3QuIEkgdGhpbmsgdGhlIFdHIChhbmQgaW1wbGVtZW50ZXJzKSB3b3VsZCBiZW5lZml0IGZy b20gc29tZSBkb2N1bWVudGVkIGFyY2hpdGVjdHVyYWwgYXNzdW1wdGlvbnMuDQo+DQoNCkFncmVl ZC4NCiANCuKAkw0KQW5uYWJlbGxlIEJhY2ttYW4gKHNoZS9oZXIpDQpBV1MgSWRlbnRpdHkNCmh0 dHBzOi8vYXdzLmFtYXpvbi5jb20vaWRlbnRpdHkvDQoNCg== From nobody Tue Mar 24 01:25:44 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27513A0874 for ; Tue, 24 Mar 2020 01:25:43 -0700 (PDT) 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=swissre.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 W1OEOqflkSQZ for ; Tue, 24 Mar 2020 01:25:40 -0700 (PDT) Received: from esa7.hc1106-67.c3s2.iphmx.com (esa7.hc1106-67.c3s2.iphmx.com [139.138.36.37]) (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 A4EB93A10CB for ; Tue, 24 Mar 2020 01:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=swissre.com; i=@swissre.com; q=dns/txt; s=srprod19; t=1585038340; x=1616574340; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=WZo69J8sr0Ikx+itbK7cZPq2wtshkBycrk91+O5fDOk=; b=IG3/dRiQHgDYyPiKbApvFUO7OuUdekJ6oq+yqc4bkNfRzwvFm/1NnxQr UxOwZJl8RJvVAGHF64/tQFayI/n4n1oJdWxUSrSNH9Lx3EZoCZSQg566S XAdJPjzgEOiIL+r8OoHk6nvKBfw5jhdI3Dq13gC2xFktDbcszqTGmooQW iIdLRu3apKJiuoDRVDxy3FZ9shUu5Ra8/S4CoAoip98L9xOfhirMsq/31 GR2vvmzCK6VXiZ9biVx38BNxeZlXE/J9taSSAC/iD4pa4I23B6nIdGSsw 7K+qFlYDUpZkw36k9YxVxmxDRkPUwtbZo5KSm+BGgrsb0MQzfGL6c47iR Q==; IronPort-SDR: KdHosw5mfwf3Xa/ZZqmehRdYxCpLp3YuuFLAiESDQ09LG6ReCKeDJ7dBWtMuA1/Tx5zjgtGAaY ZiHvSfXKDedfLVa794G05n/WULH4krbvBu40N+FSlXnJeKrtXoYmspKB2SN84Dx4BlqP0N3h84 QYQD8sRPljM6wOcXtVjZzoGqV3A1v/KtD+FBzCG3g7aaOTB2FRF+feE4ph8mFWZCBRQyrydTP7 Uf5LRIQUBR9CMf7I8ujmMJ5z+rNh9Bva3FbDs6Mwm/EcPz9Ehph9Ov8B7HOrULh8n+qEVS9uMh 8/M= X-Amp-Result: SKIPPED(no attachment in message) Received: from edge.swissre.com ([193.246.239.103]) by esa7.hc1106-67.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 24 Mar 2020 08:25:23 +0000 Received: from CHRP5014.corp.gwpnet.com (10.53.3.186) by edge.swissre.com (193.246.239.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 09:25:22 +0100 Received: from CHRP5009.corp.gwpnet.com (10.53.1.44) by CHRP5014.corp.gwpnet.com (10.53.3.186) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 09:25:21 +0100 Received: from CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6]) by CHRP5009.corp.gwpnet.com ([fe80::39a1:59b8:2e6a:5da6%15]) with mapi id 15.00.1497.006; Tue, 24 Mar 2020 09:25:21 +0100 From: Lee McGovern To: "Matthew A. Miller" , "txauth@ietf.org" Thread-Topic: [Txauth] WG name: TxAuth? XAuth? Something else? Thread-Index: AQHWAWMe6RUwbTvzvEGsPeAPc9t2nahXaGog Date: Tue, 24 Mar 2020 08:25:21 +0000 Message-ID: <2ebd1c3e4b844a8195649cf83546b749@CHRP5009.corp.gwpnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Enabled=True; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SiteId=45597f60-6e37-4be7-acfb-4c9e23b261ea; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Owner=Lee_McGovern@swissre.com; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_SetDate=2020-03-24T08:25:20.2448166Z; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Name=Internal; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Application=Microsoft Azure Information Protection; MSIP_Label_90c2fedb-0da6-4717-8531-d16a1b9930f4_Extended_MSFT_Method=Automatic; Sensitivity=Internal x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.62.28.9] x-rcom-deduphash: 58cf1225-820c-419d-aabf-b8a746a4827e Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-GBS-PROC: NlZb6SSb3rIQOquSs+1yeVzouvt+XvvjcunSyWPe8XI= Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 08:25:44 -0000 WUFBUCANCg0KWWV0IGFub3RoZXIgYXV0aFggcHJvdG9jb2wNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIE1hdHRoZXcgQS4gTWlsbGVyDQpTZW50OiBNb25kYXksIE1hcmNoIDIzLCAyMDIwIDM6 MDYgUE0NClRvOiB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBXRyBuYW1l OiBUeEF1dGg/IFhBdXRoPyBTb21ldGhpbmcgZWxzZT8NCg0KT24gMjAvMDMvMjMgMTM6NDksIEJy aWFuIENhbXBiZWxsIHdyb3RlOg0KPiBZQUFBQVMgLSBZZXQgQW5vdGhlciBBdXRob3JpemF0aW9u IEFuZCBBdXRoZW50aWNhdGlvbiBTcGVjaWZpY2F0aW9uDQo+IA0KDQorMQ0KDQoNCi0gbSZtDQoN Ck1hdHRoZXcgQS4gTWlsbGVyDQoNCj4gT24gTW9uLCBNYXIgMjMsIDIwMjAgYXQgMTozOSBQTSBN aWtlIEpvbmVzIA0KPiA8TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuLmlldGYu b3JnDQo+IDxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+ IA0KPiAgICAgSW4gYnJhaW5zdG9ybWluZyBtb2Rl4oCmX19fXw0KPiANCj4gICAgICAgKiBEaXNh Z2dyZWdhdGVkIEF1dGhvcml6YXRpb24gKERpc0F1dGgpX19fXw0KPiAgICAgICAqIENvbXBvbmVu dGl6ZWQgQXV0aG9yaXphdGlvbiAoQ29tcEF1dGgpX19fXw0KPiAgICAgICAqIEJ1aWxkLVlvdXIt T3duIEF1dGhvcml6YXRpb24gKEJZT0F1dGgpX19fXw0KPiAgICAgICAqIERvLUl0LVlvdXJzZWxm IEF1dGhvcml6YXRpb24gKERJWUF1dGgpX19fXw0KPiAgICAgICAqIFJlZmFjdG9yZWQgQXV0aG9y aXphdGlvbiAoUmVBdXRoIG9yIFJlZkF1dGgpX19fXw0KPiANCj4gICAgIF9fwqBfXw0KPiANCj4g ICAgIEFuZCBmb3IgZnVu4oCmX19fXw0KPiANCj4gICAgICAgKiBEaXNtZW1iZXJlZCBBdXRob3Jp emF0aW9uX19fXw0KPiANCj4gICAgIF9fwqBfXw0KPiANCj4gICAgIMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAtLSBNaWtlX19fXw0KPiANCj4gICAg IF9fwqBfXw0KPiANCj4gICAgICpGcm9tOiogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9y Zw0KPiAgICAgPG1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4+ICpPbiBCZWhhbGYgT2Yg KkRhdmlkIFNrYWlmZQ0KPiAgICAgKlNlbnQ6KiBTYXR1cmRheSwgTWFyY2ggMjEsIDIwMjAgMTE6 MjIgQU0NCj4gICAgICpUbzoqIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdSA8bWFpbHRv OmpyaWNoZXJAbWl0LmVkdT4+DQo+ICAgICAqQ2M6KiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb20NCj4gICAgIDxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj47IHR4YXV0 aEBpZXRmLm9yZw0KPiAgICAgPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+OyBEaWNrIEhhcmR0IDxk aWNrLmhhcmR0QGdtYWlsLmNvbQ0KPiAgICAgPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+ DQo+ICAgICAqU3ViamVjdDoqIFJlOiBbVHhhdXRoXSBXRyBuYW1lOiBUeEF1dGg/IFhBdXRoPyBT b21ldGhpbmcgDQo+IGVsc2U/X19fXw0KPiANCj4gICAgIF9fwqBfXw0KPiANCj4gICAgIEkgdGhp bmsgd2UncmUgc2F5aW5nIHRoZSBzYW1lIHRoaW5nIHdpdGggcmVnYXJkcyB0byB0aGUgd29ya2lu Zw0KPiAgICAgZ3JvdXAgbmFtZSAtIEkgd2FzIHNheWluZyBpdCAqaXNuJ3QqIHBhcnRpY3VsYXJs eSBpbXBvcnRhbnQgaW4NCj4gICAgIGNvbXBhcmlzb24gdG8gdGhlIG5hbWUgb2YgdGhlIHByb3Rv Y29sICh3aGljaCBvYnZpb3VzbHkgaXMgdmVyeQ0KPiAgICAgaW1wb3J0YW50KS5fX19fDQo+IA0K PiAgICAgX1/CoF9fDQo+IA0KPiAgICAgT24gU2F0LCBNYXIgMjEsIDIwMjAgYXQgNjoxOCBQTSBK dXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHUNCj4gICAgIDxtYWlsdG86anJpY2hlckBtaXQu ZWR1Pj4gd3JvdGU6X19fXw0KPiANCj4gICAgICAgICBJIGRpc2FncmVlIG9uIHRoZSB3b3JraW5n IGdyb3VwIG5hbWUgYmVpbmcgc3VwZXIgaW1wb3J0YW50Lg0KPiAgICAgICAgIE5vYm9keSBrbm93 cyB0aGF0IHRoZSBPQXV0aCBXRyBpcyBhY3R1YWxseSBuYW1lZCDigJxUaGUgV2ViDQo+ICAgICAg ICAgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3Vw4oCdLCBhbmQgbm9ib2R5IGNh cmVzLl9fX18NCj4gDQo+ICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgIE15IHByb3Bvc2Fs IGlzIHRoYXQgd2UgbmFtZSB0aGUgcHJvdG9jb2wgd2Ugd29yayBvbiDigJxUeEF1dGjigJ0NCj4g ICAgICAgICAoYW5kIGtlZXAgdGhlIG1haWxpbmcgbGlzdCksIGFuZCB0aGF0IHdlIG5hbWUgdGhl IHdvcmtpbmcgZ3JvdXANCj4gICAgICAgICBzb21ldGhpbmcgbGlrZSDigJxOZXh0IEdlbmVyYXRp b24gV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2zigJ0gdG8NCj4gICAgICAgICBzYXkgd2hhdCB3 ZeKAmXJlIGRvaW5nLl9fX18NCj4gDQo+ICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgIMKg LS0gSnVzdGluX19fXw0KPiANCj4gDQo+IA0KPiAgICAgICAgIF9fX18NCj4gDQo+ICAgICAgICAg ICAgIE9uIE1hciAyMSwgMjAyMCwgYXQgMjowOCBQTSwgRGF2aWQgU2thaWZlDQo+ICAgICAgICAg ICAgIDxibHVlLnJpbmdlZC5vY3RvcHVzLmd1eUBnbWFpbC5jb20NCj4gICAgICAgICAgICAgPG1h aWx0bzpibHVlLnJpbmdlZC5vY3RvcHVzLmd1eUBnbWFpbC5jb20+PiB3cm90ZTpfX19fDQo+IA0K PiAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgIEp1c3QgdG8gdGhyb3cgaW4g YW5vdGhlciBzdWdnZXN0aW9uLCB0byBhZGRyZXNzIFlhcm9uJ3MNCj4gICAgICAgICAgICAgcG9p bnQgYWJvdXQgc29tZSBwZW9wbGUgbWlzdGFrZW5seSB0aGlua2luZyB0aGF0ICJBdXRoIg0KPiAg ICAgICAgICAgICBzdGFuZHMgZm9yIGF1dGhlbnRpY2F0aW9uIHJhdGhlciB0aGFuIGF1dGhvcml6 YXRpb24sIGhvdw0KPiAgICAgICAgICAgICBhYm91dCBuYW1pbmcgdGhlIHdvcmtpbmcgZ3JvdXAg KkF1dGhaKl9fX18NCj4gDQo+ICAgICAgICAgICAgIE5pY2UgYW5kIHNpbXBsZSwgYW5kIGl0IG1h a2VzIGl0IGNsZWFyIHdoYXQgdGhlIGdyb3VwIGlzDQo+ICAgICAgICAgICAgIGZvY3VzZWQgb24u DQo+IA0KPiAgICAgICAgICAgICBJIHRoaW5rIHRoZSBuYW1lIG9mIHRoZSBhY3R1YWwgcHJvdG9j b2wgdGhhdCB3ZSBwcm9kdWNlIGlzDQo+ICAgICAgICAgICAgIGZhciwgZmFyIG1vcmUgaW1wb3J0 YW50IHRoYXQgdGhlIG5hbWUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgLQ0KPiAgICAgICAgICAgICBh bmQgdGhlIG5hbWUgb2YgdGhhdCBwcm90b2NvbCBkb2Vzbid0IG5lZWQgdG8gY29ycmVsYXRlIHRv DQo+ICAgICAgICAgICAgIHRoZSBXRyBuYW1lLiBBbHNvLCB3ZSBoYXZlIG11Y2ggbW9yZSB0aW1l IGJlZm9yZSB3ZSBuZWVkIHRvDQo+ICAgICAgICAgICAgIGRlY2lkZSBvbiB0aGUgbmFtZSBvZiB0 aGF0IHByb3RvY29sLCBldmVuIGlmIHRoZQ0KPiAgICAgICAgICAgICBpbml0aWFswqBkcmFmdCBk b2N1bWVudHMgdGhhdCB3ZSBwcm9kdWNlIGVuZCB1cCB1c2luZyBhDQo+ICAgICAgICAgICAgIHBs YWNlaG9sZGVyIG5hbWUuX19fXw0KPiANCj4gICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAg ICAgICAgICBPbiBTYXQsIE1hciAyMSwgMjAyMCBhdCA1OjQ0IFBNIEp1c3RpbiBSaWNoZXINCj4g ICAgICAgICAgICAgPGpyaWNoZXJAbWl0LmVkdSA8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdy b3RlOl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICBBcyB5b3UgY2FuIHNlZSBpbiB0aGUgZW1h aWwgeW91IHJlcGxpZWQgdG8sIHRoYXQgaXMgbm90DQo+ICAgICAgICAgICAgICAgICBldmVuIGNs b3NlIHRvIHdoYXQgSSBzYWlkLiBJIGJlbGlldmUgaXQgaXMgYQ0KPiAgICAgICAgICAgICAgICAg dHJhbnNhY3Rpb24sIGFuZCB0aGVyZWZvcmUsIEkgZG8gbm90IGFncmVlIHRoYXQgaXTigJlzIG5v dA0KPiAgICAgICAgICAgICAgICAgYSB0cmFuc2FjdGlvbi5fX19fDQo+IA0KPiAgICAgICAgICAg ICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgQnV0IGlmIHdlIHRha2Ug4oCcVHJh bnNhY3Rpb25hbOKAnSBvdXQgb2YgdGhlIFdHIHRpdGxlLCBJDQo+ICAgICAgICAgICAgICAgICB3 b27igJl0IGJlIG9mZmVuZGVkLiBJZiB3ZSBqdXN0IGNhbGwgaXQg4oCcVHhBdXRo4oCdIHdpdGhv dXQNCj4gICAgICAgICAgICAgICAgIGV4cGFuc2lvbiwgdGhlbiB0aGF04oCZcyBmaW5lLl9fX18N Cj4gDQo+ICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICBJIGRv IG5vdCBsaWtlIGNhbGxpbmcgaXQg4oCcWEF1dGjigJ0uIFRoZSB0ZXJtIOKAnFRBdXRoIiB3YXMN Cj4gICAgICAgICAgICAgICAgIGZsb2F0ZWQgZHVyaW5nIG5hbWluZyB0aGUgbGlzdCwgYnV0IHJl amVjdGVkIGJlY2F1c2UNCj4gICAgICAgICAgICAgICAgIChhbW9uZyBvdGhlciByZWFzb25zKSBp dCB3b3VsZCBsaWtlbHkgYmUgYXdrd2FyZGx5DQo+ICAgICAgICAgICAgICAgICBwcm9ub3VuY2Vk IGFzIOKAnHRvd3Ro4oCdIG9yIHNvbWV0aGluZy4gVHhBdXRoIHJlYWRzIGFzIOKAnFRlZQ0KPiAg ICAgICAgICAgICAgICAgLSBleCAtIG90aOKAnSBtb3JlIG5hdHVyYWxseSwgd2hpY2ggd2FzIHRo ZSBpbnRlbnQuwqBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAg ICAgICAgICAgICAgU28gaG93IGFib3V0IHdlIHRha2UgYSBwYWdlIGZyb20gdGhlIE9BdXRoIHdv cmtpbmcgZ3JvdXANCj4gICAgICAgICAgICAgICAgIGFuZCBuYW1lIGl0Ol9fX18NCj4gDQo+ICAg ICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICBUeEF1dGggLSBOZXh0 IEdlbmVyYXRpb24gV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wNCj4gICAgICAgICAgICAgICAg IFdvcmtpbmcgR3JvdXBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAg ICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgwqDigJQgSnVzdGlu X19fXw0KPiANCj4gDQo+IA0KPiAgICAgICAgICAgICAgICAgX19fXw0KPiANCj4gICAgICAgICAg ICAgICAgICAgICBPbiBNYXIgMjEsIDIwMjAsIGF0IDE6MTUgUE0sIERpY2sgSGFyZHQNCj4gICAg ICAgICAgICAgICAgICAgICA8ZGljay5oYXJkdEBnbWFpbC5jb20gPG1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbT4+DQo+ICAgICAgICAgICAgICAgICAgICAgd3JvdGU6X19fXw0KPiANCj4gICAg ICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgVG8gY2xh cmlmeSAtLSB5b3UgYWdyZWUgaXQgaXMgbm90IGEgdHJhbnNhY3Rpb24sIGFuZA0KPiAgICAgICAg ICAgICAgICAgICAgIHdlIHdpbGwgdGFrZSB0aGUgd29yZCB0cmFuc2FjdGlvbiBvdXQgb2YgdGhl IFdHDQo+ICAgICAgICAgICAgICAgICAgICAgdGl0bGU/X19fXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgT24gRnJpLCBNYXIgMjAs IDIwMjAgYXQgNTo1MyBQTSBKdXN0aW4gUmljaGVyDQo+ICAgICAgICAgICAgICAgICAgICAgPGpy aWNoZXJAbWl0LmVkdSA8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IA0KPiB3cm90ZTpfX19fDQo+ IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBEaWNrLCB0aGFua3MgZm9yIHB1bGxpbmcgdGhl IGRlZmluaXRpb25zIA0KPiB1cDpfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBf X8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgID7CoGEgY29tbXVuaWNhdGl2ZSBh Y3Rpb24gb3IgYWN0aXZpdHkgaW52b2x2aW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIHR3 byBwYXJ0aWVzIG9yIHRoaW5ncyB0aGF0IHJlY2lwcm9jYWxseSBhZmZlY3QNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgb3IgaW5mbHVlbmNlIGVhY2ggb3RoZXJfX19fDQo+IA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIFRo aXMgaXMgdGhlIGtpbmQgb2YgdGhpbmcgdGhhdCBJIGhhZCBpbiBtaW5kLg0KPiAgICAgICAgICAg ICAgICAgICAgICAgICBUaGUgY2xpZW50IGFuZCB0aGUgQVMgYXJlIGluIGEgY29udmVyc2F0aW9u IG92ZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAgdGltZSB0aGF0IGVhY2ggb25lIGNvbnRy aWJ1dGVzIHRvIGFuZCBlYWNoDQo+ICAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5nZXMuwqBf X19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgIEFsc28g4oCUIHdlIGNhbiBqdXN0IGFzIGVhc2lseSBkZWNpZGUgdGhh dA0KPiAgICAgICAgICAgICAgICAgICAgICAgICDigJxUeEF1dGjigJ0gZG9lc27igJl0IHN0YW5k IGZvciDigJxUcmFuc2FjdGlvbmFsIEF1dGjigJ0NCj4gICAgICAgICAgICAgICAgICAgICAgICAg bXVjaCB0aGUgc2FtZSB3YXkgd2UgZGVjaWRlZCB0aGF0IHRoZSDigJxP4oCdIGluDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgIOKAnE9BdXRo4oCdIGRvZXNu4oCZdCBzdGFuZCBmb3Ig4oCcT3Bl buKAnSBhbnltb3JlLsKgX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9f DQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICBOb25lIG9mIHRoZSBhcmd1bWVudHMgYmVs b3cgaW4gZmF2b3Igb2YgWEF1dGgNCj4gICAgICAgICAgICAgICAgICAgICAgICAgaGF2ZSBtYWRl IG1lIGxpa2UgdGhhdCBuYW1lIGJldHRlci4gSWYgaXTigJlzIGp1c3QNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgYSDigJxwbGFjZWhvbGRlcuKAnSBuYW1lLCB0aGVuIHdoeSBjb21lIHVwIHdp dGgNCj4gICAgICAgICAgICAgICAgICAgICAgICAgc29tZXRoaW5nIG5ldz9fX19fDQo+IA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgIMKg4oCUIEp1c3Rpbl9fX18NCj4gDQo+IA0KPiANCj4gICAgICAgICAgICAgICAgICAgICAg ICAgX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9uIE1hciAyMCwgMjAy MCwgYXQgMzozMiBQTSwgRGljayBIYXJkdA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PGRpY2suaGFyZHRAZ21haWwuY29tDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFp bHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6X19fXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG5vdCBhIHRyYW5zYWN0aW9uIC0gdGhlcmUgYXJlIG11bHRpcGxlDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0cmFuc2FjdGlvbnNfX19fDQo+IA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYmFja2NoYW5uZWwgaW5ub3ZhdGlvbiBpcyBjb21iaW5hdGlvbsKgb2YNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGhlcmUgaXMgd2hvIEkgYW0sIGFuZCBoZXJlIGlzIHdoYXQg SSB3YW50IHRvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb19fX18NCj4gDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjaGls ZGhvb2QgdHJhdW1hIHRoZXJhcHkgZ3JvdXBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9f DQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgT24gTW9uLCBNYXIgMTYsIDIwMjAgYXQgNjo1NiBQTSBKdXN0 aW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJpY2hlciA8anJpY2hlckBtaXQuZWR1 DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+ IHdyb3RlOl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWVzLCBu YW1pbmcgdGhpbmdzIGlzIGhhcmQg4oCUIGJ1dCBJIHN0aWxsDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYmVsaWV2ZSBpbiB0aGUgbmFtZSBUeEF1dGguIFdl4oCZcmUgbW92aW5n DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmV5b25kIE9BdXRoLCBhbmQgdGFr aW5nIHRoZSBwcm9jZXNzIG9mDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2V0 dGluZyBhbiBhdXRob3JpemF0aW9uIGRlbGVnYXRlZCB0bw0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRoZSBjbGllbnQgc29mdHdhcmUgYXMgYSBtdWx0aS1zdGVwLA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG11bHRpLXBhcnR5IHRyYW5zYWN0aW9uIGlzLCBJ IGJlbGlldmUsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGtleSBpbnNp Z2h0IHRoYXTigJlzIGxldHRpbmcgdXMgbW92ZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGJleW9uZCBPQXV0aOKAmXMgbGltaXRhdGlvbnMgaGVyZS4gSXTigJlzDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IGp1c3QgYWJvdXQgZ29pbmcgdG8gdGhlIEFT IGZpcnN0IOKAlA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdlIGhhZCB0aGF0 IGluIE9BdXRoIDEgYW5kIHdl4oCZcmUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBwYXRjaGluZyB0aGF0IGludG8gT0F1dGggMiB3aXRoIFBBUi4uIEkNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICByZWFsbHkgdGhpbmsgaXTigJlzIGFib3V0IHRoZSB0cmFuc2Fj dGlvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF0IHRoZSBjb3JlLi7CoF9f X18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBPQXV0aCAyLjAgaGFkIG11bHRpLXN0ZXAsIG11bHRpLXBh cnR5Lg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHhBdXRoIGV4dGVuZHMgdGhhdC5f X19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSSB0aGluayB0aGUgYmlnIHNoaWZ0IGlzIGdvaW5nIHRv IHRoZSBBUy4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMgZW5hYmxlcyB0aGUg cmVxdWVzdCB0byBiZSByaWNoZXIgd2l0aA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SlNPTiwgaW5zdGVhZCBvZiBuYW1lL3ZhbHVlIHBhaXJzIHBhcmFtZXRlcnMNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGluIGEgVVJJLiBJdCBhbGxvd3MgdGhlIGNsaWVudCBhbmQgQVMg dG8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZ290aWF0ZSwgYW5kIHRvIHNob3J0 IGNpcmN1aXQgaGF2aW5nIHRvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZWRpcmVj dCB0aGUgdXNlciB0byB0aGUgQVMuIFBBUiBkb2VzwqBzb21lDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBvZiB0aGlzLCBidXQgaXQgaXMgY29uc3RyYWluZWQgYnkgaGF2aW5nIHRvDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkbyBpdCBpbiB0aGUgT0F1dGggMi4wIGNvbnRl eHQuX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE15IGNvbmNlcm4gaXMgdGhhdCB0aGUgcHJvdG9j b2wgaXMgTVVDSCBNT1JFDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGFuIGEgdHJh bnNhY3Rpb24uIFdoaWxlIHRoZSBpbml0aWFsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpbnRlcmFjdGlvbiBiZXR3ZWVuIGNsaWVudCwgQVMsIHVzZXIgYW5kIFJPDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpcyBhIHRyYW5zYWN0aW9uLiBUaGUgcHJvdG9jb2wgYWxzbyBj b3ZlcnMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBjbGllbnTCoGFuZCBSUyBp bnRlcmFjdGlvbnMuIFRoZSBhY2Nlc3MNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRv a2VuIHJlZnJlc2hlcy4gQWNjZXNzIHRva2VuIHJldm9jYXRpb24uDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBY2Nlc3MgdG9rZW4gaW50cm9zcGVjdGlvbi4gQXMgZGVzY3JpYmVkIGlu DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgY2hhcnRlciwgdGhlcmUgaXMgYSB3 aG9sZSBsaWZlY3ljbGUsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IGNvbnNp c3RzIG9mIG11bHRpcGxlIA0KPiB0cmFuc2FjdGlvbnMuX19fXw0KPiANCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IEZyb20NCj4gaHR0cHM6Ly93d3cubWVycmlhbS13ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5L3RyYW5z YWN0aW9uOl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4g DQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlZmluaXRpb24gb2bCoC90 cmFuc2FjdGlvbi9fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKjFhKio6 wqAqc29tZXRoaW5nwqB0cmFuc2FjdGVkDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 aHR0cHM6Ly93d3cubWVycmlhbS13ZWJzdGVyLmNvbS9kaWN0aW9uYXJ5L3RyYW5zYWN0ZWQ+L2Vz cGVjaWFsbHkvwqAqOsKgKmFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleGNoYW5n ZSBvcsKgdHJhbnNmZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxodHRwczovL3d3 dy5tZXJyaWFtLXdlYnN0ZXIuY29tL2RpY3Rpb25hcnkvdHJhbnNmZXI+wqBvZg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZ29vZHMsIHNlcnZpY2VzLCBvcg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZnVuZHNlbGVjdHJvbmljwqAvdHJhbnNhY3Rpb25zL19fX18NCj4gDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqYjrCoHRyYW5zYWN0aW9ucyovwqBwbHVyYWwv wqAqOsKgKnRoZSBvZnRlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHVibGlzaGVk IHJlY29yZCBvZiB0aGUgbWVldGluZyBvZiBhIHNvY2lldHkNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIG9yIGFzc29jaWF0aW9uX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICoyYSoqOsKgKmFuIGFjdCwgcHJvY2Vzcywgb3IgaW5zdGFuY2UNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG9mwqB0cmFuc2FjdGluZw0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQo+IDxodHRwczovL3d3dy5tZXJyaWFtLXdlYnN0ZXIuY29tL2RpY3Rpb25hcnkv dHJhbnNhY3Rpbmc+X19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICpiKio6 wqAqYSBjb21tdW5pY2F0aXZlIGFjdGlvbiBvciBhY3Rpdml0eQ0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaW52b2x2aW5nIHR3byBwYXJ0aWVzIG9yIHRoaW5ncyB0aGF0DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZWNpcHJvY2FsbHkgYWZmZWN0IG9yIGluZmx1ZW5jZSBl YWNoIA0KPiBvdGhlcl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8Kg X18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYWxsaW5nIHRoZSBwcm90b2Nv bCBhIHRyYW5zYWN0aW9uIHdpbGwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbmZ1 c2luZyB0byBwZW9wbGUuX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIMKg X19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGF2aW5nIGNvbWUgb2YgYWdlIGluIHRo ZSAxOTkw4oCZcywgSSBoYXZlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFy dGljdWxhciBkaXNsaWtlIGZvciBYQXV0aC4gSXQgc291bmRzDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdG9vIOKAnFgtVFJFTUXigJ0gYW5kIOKAnFgtQ0lUSU5H4oCdLCBhbmQg aWYgeW91DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVhZCBlaXRoZXIgb2Yg dGhvc2Ugd2l0aCBhIGdyb3dsaW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg eWVsbCBpbiB5b3VyIGhlYWQgdGhlbiB5b3Uga25vdyBleGFjdGx5DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgd2hhdCBJ4oCZbSB0YWxraW5nIGFib3V0Ll9fX18NCj4gDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJbiBjYXNlIHlvdSBhcmUgY29uZnVzZWQsIHRoaXMgaXMgbm90IGENCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNoaWxkaG9vZMKgdHJhdW1hIHN1cHBvcnQgZ3JvdXAu wqAgOilfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVW5saWtlICJYLVRSRU1FIiBvciAiWC1DSVRJ TkciLCBYQXV0aCBpcw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXNpbmcgdGhlICJY IiBhcyBhIHBsYWNlaG9sZGVyLiBYLU1lbiwgWGJveCwNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFgtRmFjdG9yLCBYLWZpbGVzLsKgX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiBo dHRwczovL3d3dy5idXNpbmVzc2luc2lkZXIuY29tL3RoZS1pbmRpc3B1dGFibGUtcG93ZXItb2Yt YnJhbmQteC0yMDEyDQo+IC00X19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiBodHRwczovL2Vu Z2xpc2guc3RhY2tleGNoYW5nZS5jb20vcXVlc3Rpb25zLzM1ODE4MS93aGF0cy10aGUtcHVycG9z ZS1vDQo+IGYtdXNpbmctbGV0dGVyLXgtb3IteC1hcy1hLXN1ZmZpeC1pbi1icmFuZC1uYW1lc19f X18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICDCoF9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQW5kIHRvIERpY2vigJlzIHJhdGlvbmFsZSBmb3IgdGhlIG5hbWUNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZWxvdywgSSBhYnNvbHV0ZWx5IGRvIE5PVCBz ZWUgdGhpcyB3b3JrDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXMg4oCcT0F1 dGggd2l0aCBhbGwgdGhlIGV4dHJhIGZlYXR1cmVz4oCdLg0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEkgdGhpbmsgdGhhdCBkb2VzIGEgZGlzc2VydmljZSB0byB0aGUNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBraW5kIG9mIGNoYW5nZSB3ZSBoYXZlIGFuIG9w cG9ydHVuaXR5IHRvDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWFrZSBoZXJl LsKgX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyb20gdGhlIGNoYXJ0ZXLCoF9fX18NCj4gDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIkl0IHdpbGwgZXhwYW5kIHVwb24gdGhlIHVzZXMgY2FzZXMNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50bHkgc3VwcG9ydGVkIGJ5IE9B dXRoIDIuMCBhbmQNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPcGVuSUQgQ29u bmVjdCAoaXRzZWxmIGFuIGV4dGVuc2lvbiBvZg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE9BdXRoIDIuMCkiX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdoaWNoIHNvdW5kcyBw cmV0dHkgc2ltaWxhciB0b8Kg4oCcT0F1dGggd2l0aA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYWxsIHRoZSBleHRyYSBmZWF0dXJlc+KAnV9fX18NCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBX aGlsZSBJIHRoaW5rIFhBdXRoIGNhcHR1cmVzIHdoYXQgd2UgYXJlDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBkb2luZywgYSBwbGFjZWhvbGRlciBuYW1lIHdvdWxkIGJlDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwcmVmZXJhYmxlIHRvIGFuIGluY29ycmVjdCBkZXNjcmlw dGl2ZSBuYW1lDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdWNoIGFzIFR4QXV0aC5f X19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRm9yIGV4YW1wbGUsIFhZWiBpcyBhIGdvb2QgcGxhY2Vo b2xkZXIgbmFtZS4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIFhZWkF1dGguIExl dCdzIG5vdCBtaXNsZWFkIHBlb3BsZS5fX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgwqBfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBf Xw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDCoOKAlCBKdXN0aW5fX19f DQo+IA0KPiANCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX19fXw0KPiAN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gTWFyIDE2LCAyMDIwLCBh dCA3OjA0IFBNLCBEaWNrDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhh cmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgd3JvdGU6X19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBIZWxsbyBldmVyeW9uZV9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSSBwcm9tcHRlZCBhIHRocmVhZCBhcm91bmQgdGhlIG5hbWUNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIHByb3RvY29sIGEgd2hpbGUgYmFjazpf X19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4g DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPiBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3R4YXV0aC9aVlFWYkh0NEFEcWVoS3JCRFhPclRyX3Nf DQo+IHdjL19fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9f wqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXMgSnVzdGlu IHN0YXRlZCAibmFtaW5nIGlzIA0KPiBoYXJkIl9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgV2VhcmluZyBteSBtYXJrZXRpbmcgaGF0IEkgd2FudCB0bw0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbnN1cmUgdGhhdCB0aGUgbmFtZSB3aWxsIGJl DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBlcmNlaXZlZMKgcHJvcGVy bHkgaW4gdGhlIGJyb2FkZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y29tbXVuaXR5Ll9fX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQSByZWNl bnQgZXhhbXBsZSB0aGF0IGNvbWVzIHRvIG1pbmQNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgYXJlIHRoZSBwcml2YWN5IHJlbGF0ZWQgd29ya3Mgb24gdGhlDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJyb3dzZXIgc3RvcmFnZSBBUEkuIEdpdmVu IHRoYXQNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmFtZSwgb25lIHdv dWxkIHRoaW5rIHRoYXQgaXQgaXMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbG9jYWwgc3RvcmFnZS4gSXQgaXMgYWN0dWFsbHkgYWJvdXQNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYnJvd3NlciBjb29raWVzLl9fX18NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSnVzdGluIGRpc2N1c3NlZCBoaXMgcmVhc29ucyBmb3INCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHhBdXRoIGluIHRoZSB0aHJlYWQg YWJvdmUgKGFuZCBJJ20NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Vy ZSBpbiBvdGhlciBwbGFjZXMpX19fXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBJIGNob3NlIFhBdXRoIGluIG15IGRyYWZ0IHRvIHJlZmxlY3QNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdGhlIGVYdGVuc2liaWxpdHkgZ29hbCB0aGF0IHdlIGhhdmUN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3ZlciBPQXV0aCAtLSBhbmQg WEF1dGggaXMgT0F1dGggYnV0DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHdpdGggYW4gWCB0byByZWZsZWN0IGFsbCB0aGUgZXh0cmENCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgZmVhdHVyZXMuID0pX19fXw0KPiANCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgX1/CoF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBPdGhlciBzdWdnZXN0aW9ucz9fX19fDQo+IA0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFRoaXMgd2lsbCBiZSBhbiBhZ2VuZGEgaXRlbSBpbiB0aGUNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQm9GIC0tIGJ1dCB0aGUgbmFtZSB3aWxs IE5PVCBiZSBhbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvcGVuIGRp c2N1c3Npb24gaXRlbSAtLSB3ZSB3aWxsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHN1bW1hcml6ZcKgd2hhdCBoYXMgYmVlbiBkaXNjdXNzZWQgb24NCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGxpc3QgYW5kIHBlcmhhcHMgZG8gYSBwb2xs IG9mDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbnMgcHJlc2Vu dGVkIHVubGVzcyBjb25zZW5zdXMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaXMgb2J2aW91cyBmcm9tIHRoaXMgdGhyZWFkLl9fX18NCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgL0RpY2tfX19fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX1/C oF9fDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4g DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg4ZCnX19fXw0KPiANCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBfX8KgX18NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgICAgICAg ICAgICAgIC0tIA0KPiAgICAgICAgICAgICAgICAgVHhhdXRoIG1haWxpbmcgbGlzdA0KPiAgICAg ICAgICAgICAgICAgVHhhdXRoQGlldGYub3JnIDxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KPiAg ICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGhfX19fDQo+IA0KPiAgICAgICAgIF9fwqBfXw0KPiANCj4gICAgIC0tIA0KPiAgICAgVHhhdXRo IG1haWxpbmcgbGlzdA0KPiAgICAgVHhhdXRoQGlldGYub3JnIDxtYWlsdG86VHhhdXRoQGlldGYu b3JnPg0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgN Cj4gDQo+IA0KPiANCj4gLS0gDQo+IDxodHRwczovL3d3dy5waW5naWRlbnRpdHkuY29tPlBpbmcg SWRlbnRpdHkgPGh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20+CQkNCj4gQnJpYW4gQ2FtcGJl bGwJDQo+IERpc3Rpbmd1aXNoZWQgRW5naW5lZXIJDQo+IGJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tIDxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+CQ0KPiB3OiArMSA3MjAuMzE3 LjIwNjEJDQo+IGM6ICsxIDMwMy45MTguLjk0MTUJDQo+IA0KPiBDb25uZWN0IHdpdGggdXM6IAlH bGFzc2Rvb3IgbG9nbw0KPiA8aHR0cHM6Ly93d3cuZ2xhc3Nkb29yLmNvbS9PdmVydmlldy9Xb3Jr aW5nLWF0LVBpbmctSWRlbnRpdHktRUlfSUUzODA5DQo+IDA3LjExLDI0Lmh0bT4gTGlua2VkSW4g bG9nbyA8aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvMjE4NzA+DQo+IHR3aXR0ZXIg bG9nbw0KPiA8aHR0cHM6Ly90d2l0dGVyLmNvbS9waW5naWRlbnRpdHk+CWZhY2Vib29rIGxvZ28N Cj4gPGh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9waW5naWRlbnRpdHlwYWdlPgl5b3V0dWJlIGxv Z28NCj4gPGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvUGluZ0lkZW50aXR5VFY+IEJsb2cg bG9nbw0KPiA8aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9lbi9ibG9nLmh0bWw+CQ0KPiAN Cj4gPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vdXJsP3E9aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5 LmNvbS9jb250ZW50L2RhbQ0KPiAvcGluZy02LTItYXNzZXRzL0Fzc2V0cy9mYXFzL2VuL2NvbnN1 bWVyLWF0dGl0dWRlcy1wb3N0LWJyZWFjaC1lcmEtMzM3DQo+IDUucGRmP2lkJTNEYjYzMjJhODAt ZjI4NS0xMWUzLWFjMTAtMDgwMDIwMGM5YTY2JnNvdXJjZT1nbWFpbCZ1c3Q9MTU0MTYNCj4gOTM2 MDg1MjYwMDAmdXNnPUFGUWpDTkdCbDVjUEhDVUFWS0daX05ucHVGajVQSEdTVVE+PGh0dHBzOi8v d3d3LnBpbmdpZA0KPiBlbnRpdHkuY29tL2VuL2V2ZW50cy9kL2lkZW50aWZ5LTIwMTkuaHRtbD48 aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvDQo+IG0vY29udGVudC9kYW0vcGluZy02LTItYXNz ZXRzL0Fzc2V0cy9NaXNjL2VuLzM0NjQtY29uc3VtZXJzdXJ2ZXktZXhlY3MNCj4gdW1tYXJ5LnBk Zj48aHR0cHM6Ly93d3cucGluZ2lkZW50aXR5LmNvbS9lbi9ldmVudHMvZS9yc2EuaHRtbD48aHR0 cHM6Lw0KPiAvd3d3LnBpbmdpZGVudGl0eS5jb20vZW4vZXZlbnRzL2UvcnNhLmh0bWw+PGh0dHBz Oi8vd3d3LnBpbmdpZGVudGl0eS5jDQo+IG9tL2VuL2xwL2UvZW5hYmxpbmctd29yay1mcm9tLWhv bWUtd2l0aC1NRkEuaHRtbD4NCj4gDQo+IC9JZiB5b3XigJlyZSBub3QgYSBjdXJyZW50IGN1c3Rv bWVyLCBjbGlja8KgaGVyZSANCj4gPGh0dHBzOi8vd3d3LnBpbmdpZGVudGl0eS5jb20vZW4vbHAv ZS93b3JrLWZyb20taG9tZS1zc28tbWZhLmh0bWw/dXRtXw0KPiBzb3VyY2U9RW1haWwmdXRtX2Nh bXBhaWduPVdGLUNPVklEMTktTmV3LUVNU0lHPsKgZm9yIGEgbW9yZSByZWxldmFudCANCj4gb2Zm ZXIuLw0KPiANCj4gL0NPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGFuZCANCj4gcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUg dXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSANCj4gcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSANCj4gcHJvaGli aXRlZC4uwqAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2UgDQo+IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgDQo+IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3Vy IGNvbXB1dGVyLiBUaGFuayB5b3UuLw0KPiANCg0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4 YXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGgNCgoKVGhpcyBlLW1haWwsIGluY2x1ZGluZyBhdHRhY2htZW50cywgaXMgaW50ZW5kZWQgZm9y IHRoZSBwZXJzb24ocykgb3IgY29tcGFueSBuYW1lZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGFuZC9vciBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24uCgpVbmF1dGhvcml6ZWQg ZGlzY2xvc3VyZSwgY29weWluZyBvciB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBtYXkgYmUgdW5s YXdmdWwgYW5kIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBub3RpZnkgdGhlIHNlbmRlci4K QWxsIGluY29taW5nIGFuZCBvdXRnb2luZyBlLW1haWwgbWVzc2FnZXMgYXJlIHN0b3JlZCBpbiB0 aGUgU3dpc3MgUmUgRWxlY3Ryb25pYyBNZXNzYWdlIFJlcG9zaXRvcnkuCklmIHlvdSBkbyBub3Qg d2lzaCB0aGUgcmV0ZW50aW9uIG9mIHBvdGVudGlhbGx5IHByaXZhdGUgZS1tYWlscyBieSBTd2lz cyBSZSwgd2Ugc3Ryb25nbHkgYWR2aXNlIHlvdSBub3QgdG8gdXNlIHRoZSBTd2lzcyBSZSBlLW1h aWwgYWNjb3VudCBmb3IgYW55IHByaXZhdGUsIG5vbi1idXNpbmVzcyByZWxhdGVkIGNvbW11bmlj YXRpb25zLgo= From nobody Tue Mar 24 06:21:13 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8B83A0A1A for ; Tue, 24 Mar 2020 06:21:11 -0700 (PDT) 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 b1bx-nFpDwgi for ; Tue, 24 Mar 2020 06:21:09 -0700 (PDT) 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 867AD3A0A18 for ; Tue, 24 Mar 2020 06:21:09 -0700 (PDT) Received: from [192.168.1.5] (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 02ODL6pZ000793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 09:21:07 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <6e077f48-aa6b-3534-df15-28bb8117e5c9@sunet.se> Date: Tue, 24 Mar 2020 09:21:06 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <096C7C93-143F-4E39-A4BA-792E374FEF27@mit.edu> References: <6e077f48-aa6b-3534-df15-28bb8117e5c9@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 13:21:12 -0000 So =E2=80=A6. OAuth 3? :) > On Mar 23, 2020, at 5:59 PM, Leif Johansson wrote: >=20 > On 2020-03-23 20:49, Brian Campbell wrote: >> YAAAAS - Yet Another Authorization And Authentication Specification >>=20 >=20 > Son of OAuth - soauth >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 24 06:29:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9177D3A0593 for ; Tue, 24 Mar 2020 06:29:57 -0700 (PDT) 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, 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=amanjeev.com header.b=kbSUxXKs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nqQn3RGa 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 5r2ci2WnV20A for ; Tue, 24 Mar 2020 06:29:55 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE0D3A0542 for ; Tue, 24 Mar 2020 06:29:54 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CC0A7497; Tue, 24 Mar 2020 09:29:53 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute2.internal (MEProxy); Tue, 24 Mar 2020 09:29:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amanjeev.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=n+IRs vW8lf/oLb/7IGXEl5KAe5NfbALkFj76sCQnOIk=; b=kbSUxXKsYCaCeGDP5q2Gi JermZDps+eviRu/6mbEVl+7YTQupf2lxQwJoJ8XTZMHSmmXhlbZ18YToKdyoH63A HDb5Hc+TVVfzNL5RXSj7/NWXOVwUE7NveUvxYiBGQbaFLqzqotNk8G1r7vsJiySJ C/GnD6snMYxzAnBLhDfWaXfiXHe92EOEAdNXB5QbRo8HfVTNzZh8U2qtBHEPYE3n 6v5MyGbwLvQV/k5mok1hTzvxAbWg5pobSTndsw/P/M9hDDtdNCC5qiKwDyEC9yw1 /z7DX7zJzut5fQ0y8sgad7Ze7wOuVILTBmiTMMsy07av5Nyr5o/tBxkxSRrAtA7d w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=n+IRsvW8lf/oLb/7IGXEl5KAe5NfbALkFj76sCQnO Ik=; b=nqQn3RGajzwWLjKZjG6Zk5gcvR6ixciksulJu6Q52zcXyV3GOK4eg+Z9K 5NrwRuo5B1bTaVJXt/SFURbCcEwc0tMR9XGeF0NgxCcuAppgoB/oLLPmuZxbCiv4 GnGKzizOPLqVua4PhwKH1DKs1np7XVbc5gv6Z7uRFHqHAn0GYVkd3mTEKucu2BsE Uc8tTci6IQ1Z4Se5OHqtSUO28KcCGBhPKz/+vVx4bczQDL5MnZupLzQpiAtShkW6 KL3oOyi/gql9pW4Cpt8hjDxWczq6oqpdx9dKseDoA3/X0xXazjojQPJ7JX1tILW/ HbDAsb7sffng4zwLuUSyERzFLBjrA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehuddgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehm rghnjhgvvghvucfuvghthhhifdcuoegrjhesrghmrghnjhgvvghvrdgtohhmqeenucffoh hmrghinhepmhgvrhhrihgrmhdqfigvsghsthgvrhdrtghomhdpsghushhinhgvshhsihhn shhiuggvrhdrtghomhdpshhtrggtkhgvgigthhgrnhhgvgdrtghomhdpihgvthhfrdhorh hgpdhpihhnghhiuggvnhhtihhthidrtghomhdpghhlrghsshguohhorhdrtghomhdplhhi nhhkvgguihhnrdgtohhmpdhtfihithhtvghrrdgtohhmpdhfrggtvggsohhokhdrtghomh dphihouhhtuhgsvgdrtghomhdpghhoohhglhgvrdgtohhmnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghjsegrmhgrnhhjvggvvhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9F693520093; Tue, 24 Mar 2020 09:29:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <2ebd1c3e4b844a8195649cf83546b749@CHRP5009.corp.gwpnet.com> References: <2ebd1c3e4b844a8195649cf83546b749@CHRP5009.corp.gwpnet.com> Date: Tue, 24 Mar 2020 09:29:32 -0400 From: "Amanjeev Sethi" To: "Lee McGovern" , "Matthew A. Miller" , "txauth@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 13:29:58 -0000 TOI (as in french you): TxAuth's OAuth's Improvement On Tue, Mar 24, 2020, at 4:25 AM, Lee McGovern wrote: > YAAP=20 >=20 > Yet another authX protocol >=20 >=20 > -----Original Message----- > From: Txauth On Behalf Of Matthew A. Miller > Sent: Monday, March 23, 2020 3:06 PM > To: txauth@ietf.org > Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else? >=20 > On 20/03/23 13:49, Brian Campbell wrote: > > YAAAAS - Yet Another Authorization And Authentication Specification > >=20 >=20 > +1 >=20 >=20 > - m&m >=20 > Matthew A. Miller >=20 > > On Mon, Mar 23, 2020 at 1:39 PM Mike Jones=20 > > > > wrote: > >=20 > > In brainstorming mode=E2=80=A6____ > >=20 > > * Disaggregated Authorization (DisAuth)____ > > * Componentized Authorization (CompAuth)____ > > * Build-Your-Own Authorization (BYOAuth)____ > > * Do-It-Yourself Authorization (DIYAuth)____ > > * Refactored Authorization (ReAuth or RefAuth)____ > >=20 > > __=C2=A0__ > >=20 > > And for fun=E2=80=A6____ > >=20 > > * Dismembered Authorization____ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike____ > >=20 > > __=C2=A0__ > >=20 > > *From:* Txauth > > *On Behalf Of *David Skaife > > *Sent:* Saturday, March 21, 2020 11:22 AM > > *To:* Justin Richer > > > *Cc:* Yaron Sheffer > >; txauth@ietf.org > > ; Dick Hardt > > > > *Subject:* Re: [Txauth] WG name: TxAuth? XAuth? Something=20 > > else?____ > >=20 > > __=C2=A0__ > >=20 > > I think we're saying the same thing with regards to the working > > group name - I was saying it *isn't* particularly important in > > comparison to the name of the protocol (which obviously is very > > important).____ > >=20 > > __=C2=A0__ > >=20 > > On Sat, Mar 21, 2020 at 6:18 PM Justin Richer > > wrote:____ > >=20 > > I disagree on the working group name being super important. > > Nobody knows that the OAuth WG is actually named =E2=80=9CTh= e Web > > Authorization Protocol Working Group=E2=80=9D, and nobody ca= res.____ > >=20 > > __=C2=A0__ > >=20 > > My proposal is that we name the protocol we work on =E2=80=9C= TxAuth=E2=80=9D > > (and keep the mailing list), and that we name the working gr= oup > > something like =E2=80=9CNext Generation Web Authorization Pr= otocol=E2=80=9D to > > say what we=E2=80=99re doing.____ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0-- Justin____ > >=20 > >=20 > >=20 > > ____ > >=20 > > On Mar 21, 2020, at 2:08 PM, David Skaife > > > > wrote:____ > >=20 > > __=C2=A0__ > >=20 > > Just to throw in another suggestion, to address Yaron's > > point about some people mistakenly thinking that "Auth" > > stands for authentication rather than authorization, how= > > about naming the working group *AuthZ*____ > >=20 > > Nice and simple, and it makes it clear what the group is= > > focused on. > >=20 > > I think the name of the actual protocol that we produce = is > > far, far more important that the name of the working gro= up - > > and the name of that protocol doesn't need to correlate = to > > the WG name. Also, we have much more time before we need= to > > decide on the name of that protocol, even if the > > initial=C2=A0draft documents that we produce end up usin= g a > > placeholder name.____ > >=20 > > __=C2=A0__ > >=20 > > On Sat, Mar 21, 2020 at 5:44 PM Justin Richer > > > wrote:____ > >=20 > > As you can see in the email you replied to, that is = not > > even close to what I said. I believe it is a > > transaction, and therefore, I do not agree that it=E2= =80=99s not > > a transaction.____ > >=20 > > __=C2=A0__ > >=20 > > But if we take =E2=80=9CTransactional=E2=80=9D out o= f the WG title, I > > won=E2=80=99t be offended. If we just call it =E2=80= =9CTxAuth=E2=80=9D without > > expansion, then that=E2=80=99s fine.____ > >=20 > > __=C2=A0__ > >=20 > > I do not like calling it =E2=80=9CXAuth=E2=80=9D. Th= e term =E2=80=9CTAuth" was > > floated during naming the list, but rejected because= > > (among other reasons) it would likely be awkwardly > > pronounced as =E2=80=9Ctowth=E2=80=9D or something. = TxAuth reads as =E2=80=9CTee > > - ex - oth=E2=80=9D more naturally, which was the in= tent.=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > So how about we take a page from the OAuth working g= roup > > and name it:____ > >=20 > > __=C2=A0__ > >=20 > > TxAuth - Next Generation Web Authorization Protocol > > Working Group____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0=E2=80=94 Justin____ > >=20 > >=20 > >=20 > > ____ > >=20 > > On Mar 21, 2020, at 1:15 PM, Dick Hardt > > > > > wrote:____ > >=20 > > __=C2=A0__ > >=20 > > To clarify -- you agree it is not a transaction,= and > > we will take the word transaction out of the WG > > title?____ > >=20 > > __=C2=A0__ > >=20 > > On Fri, Mar 20, 2020 at 5:53 PM Justin Richer > > >=20 > > wrote:____ > >=20 > > Dick, thanks for pulling the definitions=20 > > up:____ > >=20 > > __=C2=A0__ > >=20 > > >=C2=A0a communicative action or activity in= volving > > two parties or things that reciprocally affe= ct > > or influence each other____ > >=20 > > __=C2=A0__ > >=20 > > This is the kind of thing that I had in mind= . > > The client and the AS are in a conversation = over > > time that each one contributes to and each > > changes.=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > Also =E2=80=94 we can just as easily decide = that > > =E2=80=9CTxAuth=E2=80=9D doesn=E2=80=99t sta= nd for =E2=80=9CTransactional Auth=E2=80=9D > > much the same way we decided that the =E2=80= =9CO=E2=80=9D in > > =E2=80=9COAuth=E2=80=9D doesn=E2=80=99t stan= d for =E2=80=9COpen=E2=80=9D anymore.=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > None of the arguments below in favor of XAut= h > > have made me like that name better. If it=E2= =80=99s just > > a =E2=80=9Cplaceholder=E2=80=9D name, then w= hy come up with > > something new?____ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0=E2=80=94 Justin____ > >=20 > >=20 > >=20 > > ____ > >=20 > > On Mar 20, 2020, at 3:32 PM, Dick Hardt > > > > wrote:___= _ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > not a transaction - there are multiple > > transactions____ > >=20 > > __=C2=A0__ > >=20 > > backchannel innovation is combination=C2= =A0of > > here is who I am, and here is what I wan= t to > > do____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > childhood trauma therapy group____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > On Mon, Mar 16, 2020 at 6:56 PM Justin > > Richer > > wrote:____ > >=20 > > Yes, naming things is hard =E2=80=94= but I still > > believe in the name TxAuth. We=E2=80= =99re moving > > beyond OAuth, and taking the process= of > > getting an authorization delegated t= o > > the client software as a multi-step,= > > multi-party transaction is, I believ= e, > > the key insight that=E2=80=99s letti= ng us move > > beyond OAuth=E2=80=99s limitations h= ere. It=E2=80=99s > > not just about going to the AS first= =E2=80=94 > > we had that in OAuth 1 and we=E2=80=99= re > > patching that into OAuth 2 with PAR.= . I > > really think it=E2=80=99s about the = transaction > > at the core..=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > OAuth 2.0 had multi-step, multi-party. > > TxAuth extends that.____ > >=20 > > __=C2=A0__ > >=20 > > I think the big shift is going to the AS= . > > This enables the request to be richer wi= th > > JSON, instead of name/value pairs parame= ters > > in a URI. It allows the client and AS to= > > negotiate, and to short circuit having t= o > > redirect the user to the AS. PAR does=C2= =A0some > > of this, but it is constrained by having= to > > do it in the OAuth 2.0 context.____ > >=20 > > __=C2=A0__ > >=20 > > My concern is that the protocol is MUCH = MORE > > than a transaction. While the initial > > interaction between client, AS, user and= RO > > is a transaction. The protocol also cove= rs > > the client=C2=A0and RS interactions. The= access > > token refreshes. Access token revocation= . > > Access token introspection. As described= in > > the charter, there is a whole lifecycle,= > > that consists of multiple=20 > > transactions.____ > >=20 > > __=C2=A0__ > >=20 > > From > > https://www.merriam-webster.com/dictionary/transaction:____ > >=20 > > __=C2=A0__ > >=20 > >=20 > > Definition of=C2=A0/transaction/____= > >=20 > > *1a**:=C2=A0*something=C2=A0transacted > > /especially/=C2=A0*:=C2=A0*an > > exchange or=C2=A0transfer > > =C2=A0of > > goods, services, or > > fundselectronic=C2=A0/transactions/____ > >=20 > > *b:=C2=A0transactions*/=C2=A0plural/=C2=A0= *:=C2=A0*the often > > published record of the meeting of a soc= iety > > or association____ > >=20 > > *2a**:=C2=A0*an act, process, or instanc= e > > of=C2=A0transacting > > =20 > > ____ > >=20 > > *b**:=C2=A0*a communicative action or ac= tivity > > involving two parties or things that > > reciprocally affect or influence each=20= > > other____ > >=20 > > __=C2=A0__ > >=20 > > Calling the protocol a transaction will > > confusing to people.____ > >=20 > > =C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > Having come of age in the 1990=E2=80= =99s, I have > > particular dislike for XAuth. It sou= nds > > too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you > > read either of those with a growling= > > yell in your head then you know exac= tly > > what I=E2=80=99m talking about.____ > >=20 > > __=C2=A0__ > >=20 > > In case you are confused, this is not a > > childhood=C2=A0trauma support group.=C2=A0= :)____ > >=20 > > __=C2=A0__ > >=20 > > Unlike "X-TREME" or "X-CITING", XAuth is= > > using the "X" as a placeholder. X-Men, X= box, > > X-Factor, X-files.=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > =20 > > https://www.businessinsider.com/the-indisputable-power-of-brand-x-20= 12 > > -4____ > >=20 > > __=C2=A0__ > >=20 > > =20 > > https://english.stackexchange.com/questions/358181/whats-the-purpose= -o > > f-using-letter-x-or-x-as-a-suffix-in-brand-names____ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0____ > >=20 > > And to Dick=E2=80=99s rationale for = the name > > below, I absolutely do NOT see this = work > > as =E2=80=9COAuth with all the extra= features=E2=80=9D. > > I think that does a disservice to th= e > > kind of change we have an opportunit= y to > > make here.=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > From the charter=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > "It will expand upon the uses cases > > currently supported by OAuth 2.0 and= > > OpenID Connect (itself an extension = of > > OAuth 2.0)"____ > >=20 > > __=C2=A0__ > >=20 > > Which sounds pretty similar to=C2=A0=E2=80= =9COAuth with > > all the extra features=E2=80=9D____ > >=20 > > __=C2=A0__ > >=20 > > While I think XAuth captures what we are= > > doing, a placeholder name would be > > preferable to an incorrect descriptive n= ame > > such as TxAuth.____ > >=20 > > __=C2=A0__ > >=20 > > For example, XYZ is a good placeholder n= ame. > > Or XYZAuth. Let's not mislead people.___= _ > >=20 > > =C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0=E2=80=94 Justin____ > >=20 > >=20 > >=20 > > ____ > >=20 > > On Mar 16, 2020, at 7:04 PM, Dic= k > > Hardt > > > > wrote:____ > >=20 > > __=C2=A0__ > >=20 > > Hello everyone____ > >=20 > > __=C2=A0__ > >=20 > > I prompted a thread around the n= ame > > of the protocol a while back:___= _ > >=20 > > __=C2=A0__ > >=20 > > =20 > > https://mailarchive.ietf.org/arch/msg/txauth/ZVQVbHt4ADqehKrBDXOrTr_= s_ > > wc/____ > >=20 > > __=C2=A0__ > >=20 > > As Justin stated "naming is=20 > > hard"____ > >=20 > > __=C2=A0__ > >=20 > > Wearing my marketing hat I want = to > > ensure that the name will be > > perceived=C2=A0properly in the b= roader > > community.____ > >=20 > > __=C2=A0__ > >=20 > > A recent example that comes to m= ind > > are the privacy related works on= the > > browser storage API. Given that > > name, one would think that it is= > > local storage. It is actually ab= out > > browser cookies.____ > >=20 > > __=C2=A0__ > >=20 > > Justin discussed his reasons for= > > TxAuth in the thread above (and = I'm > > sure in other places)____ > >=20 > > __=C2=A0__ > >=20 > > I chose XAuth in my draft to ref= lect > > the eXtensibility goal that we h= ave > > over OAuth -- and XAuth is OAuth= but > > with an X to reflect all the ext= ra > > features. =3D)____ > >=20 > > __=C2=A0__ > >=20 > > Other suggestions?____ > >=20 > > __=C2=A0__ > >=20 > > This will be an agenda item in t= he > > BoF -- but the name will NOT be = an > > open discussion item -- we will > > summarize=C2=A0what has been dis= cussed on > > the list and perhaps do a poll o= f > > options presented unless consens= us > > is obvious from this thread.____= > >=20 > > __=C2=A0__ > >=20 > > /Dick____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > =E1=90=A7____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth____ > >=20 > > __=C2=A0__ > >=20 > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > >=20 > >=20 > >=20 > > --=20 > > Ping Identity =09 > > Brian Campbell=09 > > Distinguished Engineer=09 > > bcampbell@pingidentity.com =09 > > w: +1 720.317.2061=09 > > c: +1 303.918..9415=09 > >=20 > > Connect with us: Glassdoor logo > > > 07.11,24.htm> LinkedIn logo = > > twitter logo > > facebook logo > > youtube logo > > Blog logo > > =09 > >=20 > > > /ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3= 37 > > 5.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=3Dgmail&ust=3D= 15416 > > 93608526000&usg=3DAFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ> > entity.com/en/events/d/identify-2019.html> > m/content/dam/ping-6-2-assets/Assets/Misc/en/3464-consumersurvey-exe= cs > > ummary.pdf> > /www.pingidentity.com/en/events/e/rsa.html> > om/en/lp/e/enabling-work-from-home-with-MFA.html> > >=20 > > /If you=E2=80=99re not a current customer, click=C2=A0here=20 > > > source=3DEmail&utm_campaign=3DWF-COVID19-New-EMSIG>=C2=A0for a more = relevant=20 > > offer./ > >=20 > > /CONFIDENTIALITY NOTICE: This email may contain confidential and=20 > > privileged material for the sole use of the intended recipient(s). A= ny=20 > > review, use, distribution or disclosure by others is strictly=20 > > prohibited..=C2=A0 If you have received this communication in error,= please=20 > > notify the sender immediately by e-mail and delete the message and a= ny=20 > > file attachments from your computer. Thank you./ > >=20 >=20 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 > This e-mail, including attachments, is intended for the person(s) or=20= > company named and may contain confidential and/or legally privileged=20= > information. >=20 > Unauthorized disclosure, copying or use of this information may be=20 > unlawful and is prohibited. If you are not the intended recipient,=20 > please delete this message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re=20= > Electronic Message Repository. > If you do not wish the retention of potentially private e-mails by=20 > Swiss Re, we strongly advise you not to use the Swiss Re e-mail accoun= t=20 > for any private, non-business related communications. > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > From nobody Tue Mar 24 06:41:36 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355793A0943 for ; Tue, 24 Mar 2020 06:41:34 -0700 (PDT) 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, 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 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 LAE7e66BDftM for ; Tue, 24 Mar 2020 06:41:28 -0700 (PDT) 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 DE9C13A07B3 for ; Tue, 24 Mar 2020 06:41:27 -0700 (PDT) Received: from [192.168.1.5] (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 02ODfBsa006814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 09:41:12 -0400 From: Justin Richer Message-Id: <0B76D049-5FCD-4677-9F9D-828F7D67CC34@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E8EFB5-697E-4A6A-9840-063883B5D439" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Mar 2020 09:41:11 -0400 In-Reply-To: Cc: Dick Hardt , "txauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [EXTERNAL] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 13:41:35 -0000 --Apple-Mail=_E8E8EFB5-697E-4A6A-9840-063883B5D439 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I mentioned this on the call yesterday, but this is an incredibly weak = argument to pick one draft over another, especially at such an early = stage. I would consider everything XYZ malleable, especially what the = fields get named. It=E2=80=99s short sighted to throw out an entire = specification because of the names of fields that were added very = recently to the draft.=20 In other words, I think it=E2=80=99s too early to judge based on things = like this, and it shows blindness to the rest of the draft. It=E2=80=99s = true that Dick and I have taken a very different approach to re-use, but = both have re-use. XYZ does re-use many elements from OAuth 2, OIDC, and = XYZ, but they=E2=80=99ve been translated into a system that=E2=80=99s = internally consistent in a way that the source material is not. Dick has = said several times that =E2=80=9CXYZ doesn=E2=80=99t use OAuth 2 = scopes=E2=80=9D which is blatantly not true =E2=80=94 we designed the = system explicitly so that you could do that. However, we didn=E2=80=99t = just put in a field labeled =E2=80=9Coauth_scopes=E2=80=9D because, as = we=E2=80=99ve found in defining RAR in OAuth 2, it gets complicated = quickly trying to combine them if you have different layers of semantics = within the protocol. XYZ puts the scope style requests at the same level = as the rich requests. So let=E2=80=99s say you wanted to do a full mapping of an OIDC request, = just swapping out OAuth 2 for XYZ, it=E2=80=99d look something like = this: { "keys": "client-id-1234556", "resources": ["openid", "profile", "email", "phone", "address"], "claims": { "oidc_id_token": true }, "interact": { "redirect": true, "callaback": { "url": "https://client.example/redirect_uri", "nonce": "1233455" } } } This would get you back an OIDC id token and access token with the OIDC = scopes tied to the server=E2=80=99s UserInfo Endpoint. But as I=E2=80=99ve= been saying, I don=E2=80=99t think it=E2=80=99s within the purview of = this working group to define that level of detail. What we should do is = define what the =E2=80=9Cresources=E2=80=9D field means, what the = =E2=80=9Cclaims=E2=80=9D field means, and put a few buckets in there for = common identifiers and assertions so that people do things the same way. = And I=E2=80=99ll repeat that I would personally prefer the simple = identity mapping layer be in a separate document from the core = delegation protocol =E2=80=94 but that=E2=80=99s a matter for the WG to = decide.=20 I=E2=80=99ll also repeat my argument that I don=E2=80=99t think we = should just blindly re-use OIDC=E2=80=99s names for things, but that is = not me saying that we should, of necessity, invent new things entirely = "just because=E2=80=9D. Every choice we make, including what we name = fields, needs to have a good reason.=20 And if the WG does end up creating new names for some things? That=E2=80=99= s not the end of the world. When we were working on OIDC, there was an = opportunity to re-use field names from LDAP (specifically, to use = inetOrgPerson and/or eduOrgPerson as the schema), but as you (Mike) = know, we decided not to, and the world is OK for that even though it = meant people had to write a simple translator when wrapping their LDAP = servers with OIDC capabilities (and complained about it at the time).=20 Re-use does not just mean copying. It means examining what is there and = pulling the best from it =E2=80=94 and that is going to include sources = beyond OAuth2 and OIDC. At this point we should be looking at what = features we like from the entire ecosystem, including the two proposed = drafts, and decide what we want to bring forward into TxAuth. And in = terms of flexibility, stability, simplicity, and consistency, I believe = that XYZ makes a much stronger base for building on.=20 =E2=80=94 Justin > On Mar 23, 2020, at 3:53 PM, Mike Jones = wrote: >=20 > I would prefer XAuth as a starting point over XYZ because XAuth is = clearly trying to reuse existing identity representations, whereas XYZ = is creating a new one. > =20 > You can see XAuth=E2=80=99s reuse, for instance, at = https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6 = .= > =20 > You can see XYZ=E2=80=99s invention of a new identity schema at = https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.= 7 = . Yes, it=E2=80=99s similar to some others but not the same, and = rather than reusing existing registered claims, it=E2=80=99s creating = its own unique set. > =20 > -- Mike > =20 > From: Txauth On Behalf Of Dick Hardt > Sent: Friday, March 20, 2020 1:18 PM > To: txauth@ietf.org > Cc: Justin Richer > Subject: [EXTERNAL] Re: [Txauth] XYZ vs XAuth - 5 differences > =20 > ACTION REMINDER > =20 > Please weigh in with your preference, your rationale, as well as any = pros and cons not described. > =20 > Yaron and I were hopeful that we would get more feedback on these = topics, as it would help determine if either the XYZ or XAuth documents = are roughly aligned with the consensus direction of the group so that we = have a starting document. > =20 > We will NOT be able to do hums in the BoF ... so we will not be able = to use that to judge rough consensus. > =20 > /Dick > =20 > On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt > wrote: > Hello everyone > =20 > Justin and I have had some emails back and forth comparing and = contrasting XYZ and XAuth. I'm going to post a message for each of the = major points, with Justin's rationale and my rationale for our = respective design decisions. Feel free to ask clarifying questions in = those threads. > =20 > Please weigh in with your preference, your rationale, as well as any = pros and cons not described. > =20 > We would like to get a sense for the group's views on these topics for = the virtual BoF in a week. > =20 > The latest drafts are: > =20 > XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 = > =20 > XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 = > =20 > Thanks! > =20 > /Dick > =E1=90=A7 --Apple-Mail=_E8E8EFB5-697E-4A6A-9840-063883B5D439 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = mentioned this on the call yesterday, but this is an incredibly weak = argument to pick one draft over another, especially at such an early = stage. I would consider everything XYZ malleable, especially what the = fields get named. It=E2=80=99s short sighted to throw out an entire = specification because of the names of fields that were added very = recently to the draft. 

In other words, I think it=E2=80=99s too early to judge based = on things like this, and it shows blindness to the rest of the draft. = It=E2=80=99s true that Dick and I have taken a very different approach = to re-use, but both have re-use.  XYZ does re-use many elements = from OAuth 2, OIDC, and XYZ, but they=E2=80=99ve been translated into a = system that=E2=80=99s internally consistent in a way that the source = material is not. Dick has said several times that =E2=80=9CXYZ doesn=E2=80= =99t use OAuth 2 scopes=E2=80=9D which is blatantly not true =E2=80=94 = we designed the system explicitly so that you could do that. However, we = didn=E2=80=99t just put in a field labeled =E2=80=9Coauth_scopes=E2=80=9D = because, as we=E2=80=99ve found in defining RAR in OAuth 2, it gets = complicated quickly trying to combine them if you have different layers = of semantics within the protocol. XYZ puts the scope style requests at = the same level as the rich requests.

So let=E2=80=99s say you wanted to do a = full mapping of an OIDC request, just swapping out OAuth 2 for XYZ, = it=E2=80=99d look something like this:


{
  "keys": = "client-id-1234556",
  "resources": ["openid", = "profile", "email", "phone", "address"],
  = "claims": { "oidc_id_token": true },
  = "interact": {
"redirect": true,
= "callaback": {
"url": "https://client.example/redirect_uri",
= "nonce": "1233455"
= }
  }
}

This would get you back = an OIDC id token and access token with the OIDC scopes tied to the = server=E2=80=99s UserInfo Endpoint. But as I=E2=80=99ve been saying, I = don=E2=80=99t think it=E2=80=99s within the purview of this working = group to define that level of detail. What we should do is define what = the =E2=80=9Cresources=E2=80=9D field means, what the =E2=80=9Cclaims=E2=80= =9D field means, and put a few buckets in there for common identifiers = and assertions so that people do things the same way. And I=E2=80=99ll = repeat that I would personally prefer the simple identity mapping layer = be in a separate document from the core delegation protocol =E2=80=94 = but that=E2=80=99s a matter for the WG to decide. 

I=E2=80=99ll also repeat = my argument that I don=E2=80=99t think we should just blindly re-use = OIDC=E2=80=99s names for things, but that is not me saying that we = should, of necessity, invent new things entirely "just because=E2=80=9D. = Every choice we make, including what we name fields, needs to have a = good reason. 

And if the WG does end up creating new names for some things? = That=E2=80=99s not the end of the world. When we were working on OIDC, = there was an opportunity to re-use field names from LDAP (specifically, = to use inetOrgPerson and/or eduOrgPerson as the schema), but as you = (Mike) know, we decided not to, and the world is OK for that even though = it meant people had to write a simple translator when wrapping their = LDAP servers with OIDC capabilities (and complained about it at the = time). 

Re-use does not just mean copying. It means examining what is = there and pulling the best from it =E2=80=94 and that is going to = include sources beyond OAuth2 and OIDC. At this point we should be = looking at what features we like from the entire ecosystem, including = the two proposed drafts, and decide what we want to bring forward into = TxAuth. And in terms of flexibility, stability, simplicity, and = consistency, I believe that XYZ makes a much stronger base for building = on. 

 =E2=80=94 Justin


On Mar 23, 2020, at 3:53 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

I would = prefer XAuth as a = starting point over XYZ because XAuth is clearly trying to reuse = existing identity representations, whereas XYZ is creating a new = one.
 
You can see = XAuth=E2=80=99s reuse, for instance, at https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#secti= on-4.6.6.
 
You can see = XYZ=E2=80=99s invention of a new identity schema at https://tools.ietf.org/html/draft-richer-transactional-authz-06= #section-2.7.  Yes, it=E2=80=99s similar to some others but not = the same, and rather than reusing existing registered claims, it=E2=80=99s= creating its own unique set.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Friday, March 20, 2020 1:18 = PM
To: txauth@ietf.org
Cc: Justin Richer = <jricher@mit.edu>
Subject: [EXTERNAL] Re: [Txauth] XYZ = vs XAuth - 5 differences
 
ACTION REMINDER
 
Please weigh in with your preference, your = rationale, as well as any pros and cons not described.
 
Yaron and I were = hopeful that we would get more feedback on these topics, as it = would help determine if either the XYZ or XAuth documents are roughly = aligned with the consensus direction of the group so that we have a = starting document.
 
We will NOT be able to do hums in the BoF ... so we will not = be able to use that to judge rough consensus.
 
/Dick
 
On Mon, Mar 16, 2020 at = 4:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello = everyone
 
Justin and I have had some = emails back and forth comparing and contrasting XYZ and XAuth. I'm going = to post a message for each of the major points, with Justin's rationale = and my rationale for our respective design decisions. Feel free to = ask clarifying questions in those threads.
 
Please weigh in with your = preference, your rationale, as well as any pros and cons not = described.
 
We would like to get a sense for the group's views on these = topics for the virtual BoF in a week.
 
The latest drafts are:
 
XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06=
 
 
Thanks!
 
/Dick
=E1=90=A7

= --Apple-Mail=_E8E8EFB5-697E-4A6A-9840-063883B5D439-- From nobody Tue Mar 24 06:42:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C53A0762 for ; Tue, 24 Mar 2020 06:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 1ZzrU-PHOo45 for ; Tue, 24 Mar 2020 06:42:31 -0700 (PDT) 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 E018A3A07A8 for ; Tue, 24 Mar 2020 06:42:30 -0700 (PDT) Received: from [192.168.1.5] (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 02ODgGRe007234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 09:42:17 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 24 Mar 2020 09:42:16 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Pete Resnick X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Working through differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 13:42:40 -0000 I like this idea think it could help us organize thoughts and opinions = on it. =E2=80=94 Justin > On Mar 23, 2020, at 5:57 PM, Pete Resnick = wrote: >=20 > I mentioned this in the jabber chat during the BOF and Bron suggested = I post it to the list: >=20 > I suggest that we have a poll for the differences between XYZ and = XAUTH with the following choices for each difference: >=20 > A. One of these choices is seriously problematic for these reasons... > B. I prefer the XYZ/XAuth choice for this one, but could live with = either > C. Couldn't care less >=20 > You might end up with an obvious choice to at least start with until = someone finds a showstopper. >=20 > pr > --=20 > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 24 06:47:43 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E39B3A0B07 for ; Tue, 24 Mar 2020 06:47:26 -0700 (PDT) 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 zyv437jQcQhO for ; Tue, 24 Mar 2020 06:47:21 -0700 (PDT) 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 E837F3A0A4A for ; Tue, 24 Mar 2020 06:47:10 -0700 (PDT) Received: from [192.168.1.5] (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 02ODl8mB008952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 09:47:09 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <20200323220315.GP50174@kduck.mit.edu> Date: Tue, 24 Mar 2020 09:47:08 -0400 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200323220315.GP50174@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] brainstorming about "layer session management on top of txauth" X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 13:47:39 -0000 I agree that the kind of identity info that we=E2=80=99re looking at = Login events are pretty well understood and have been solved with some = pretty solid patterns for years. Logout (and session management in = general) turns out to be much, much, much harder. I don=E2=80=99t buy = the argument that they are required to go together, especially because = OIDC was not published with session management and logout functionality. = There=E2=80=99s a non-final draft, but it was was last updated 3 years = ago and does not have wide adoption.=20 Regardless, I think that there is going to be a space to add advanced = identity concepts on top of TxAuth =E2=80=94 though likely outside of = the TxAuth working group, we should design with some of this in mind and = leave space and structure for it. But to spitball an idea on top of XYZ, I think it=E2=80=99s a short step = to ask for a session management handle to give to the client. This is an = artifact that the AS would know how to dereference to let the client = push a =E2=80=9Clogout=E2=80=9D event to the AS. But the client could = also, in the same request, register a =E2=80=9Clogout=E2=80=9D callback = at the AS, using some variety of mechanisms. So maybe something like = this: { "session": { "logout_callback": { "url": "https://client.example/logout", "nonce": "0948134" } } } And the server responds with something like: { "session_handle": { "url": "https://server.example/logout", "handle": "0948134", "type": "bearer" } } But again, I don=E2=80=99t think that this is necessary for a simple = login system or even in scope for TxAuth. Identity is indeed huge, but = we don=E2=80=99t need to solve everything in order to solve something = universally useful. =E2=80=94 Justin > On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk wrote: >=20 > Hi all, >=20 > We spent a long time talking about what we mean by identity and what = should > be in scope for us to do vs. reuse, and I had an idea that I wanted to = get > some feedback on, relating to how we might layer > identity/session-management on top of XYZ. (I am not sure yet if it = would > apply to XAuth or not.) >=20 > If we talk about how some of the claims conveyed from AS to client = relate > to who the user is, but as Mike notes this starts to look like a = "login" > event, and once you have that you want to know about the "logout" = event as > well. Would it be possible to build something that has the client ask = for > a resource of "tell me when the user logs out"? We'd of course need = to > define some way to indicate how the AS would convey that to the = client, but > on first glance at least it seems like it could work to layer the > session-management on top of claims with semantics like that. Whether = the > resulting set of claims would still look pretty is another matter, > though... >=20 > -Ben >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 24 07:48:24 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817F43A0AB4 for ; Tue, 24 Mar 2020 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8lbmQAbvRsz1 for ; Tue, 24 Mar 2020 07:48:10 -0700 (PDT) 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 A478C3A0881 for ; Tue, 24 Mar 2020 07:48:09 -0700 (PDT) Received: from [192.168.1.5] (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 02OEm4Wg029581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 10:48:04 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8780D9DD-70CA-4D1D-B942-53A3BFE1140F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Mar 2020 10:48:03 -0400 In-Reply-To: <0B76D049-5FCD-4677-9F9D-828F7D67CC34@mit.edu> Cc: "txauth@ietf.org" , Dick Hardt To: Mike Jones References: <0B76D049-5FCD-4677-9F9D-828F7D67CC34@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] [EXTERNAL] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 14:48:22 -0000 --Apple-Mail=_8780D9DD-70CA-4D1D-B942-53A3BFE1140F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Two quick notes I missed: > On Mar 24, 2020, at 9:41 AM, Justin Richer wrote: >=20 > I mentioned this on the call yesterday, but this is an incredibly weak = argument to pick one draft over another, especially at such an early = stage. I would consider everything XYZ malleable, especially what the = fields get named. It=E2=80=99s short sighted to throw out an entire = specification because of the names of fields that were added very = recently to the draft.=20 >=20 > In other words, I think it=E2=80=99s too early to judge based on = things like this, and it shows blindness to the rest of the draft. = It=E2=80=99s true that Dick and I have taken a very different approach = to re-use, but both have re-use. XYZ does re-use many elements from = OAuth 2, OIDC, and XYZ, but they=E2=80=99ve been translated into a = system that=E2=80=99s internally consistent in a way that the source = material is not. Dick has said several times that =E2=80=9CXYZ doesn=E2=80= =99t use OAuth 2 scopes=E2=80=9D which is blatantly One correction =E2=80=94 I meant to say =E2=80=9COAuth 2, OIDC, and = others like UMA,=E2=80=9D. :) > not true =E2=80=94 we designed the system explicitly so that you could = do that. However, we didn=E2=80=99t just put in a field labeled = =E2=80=9Coauth_scopes=E2=80=9D because, as we=E2=80=99ve found in = defining RAR in OAuth 2, it gets complicated quickly trying to combine = them if you have different layers of semantics within the protocol. XYZ = puts the scope style requests at the same level as the rich requests. >=20 > So let=E2=80=99s say you wanted to do a full mapping of an OIDC = request, just swapping out OAuth 2 for XYZ, it=E2=80=99d look something = like this: >=20 >=20 > { > "keys": "client-id-1234556", > "resources": ["openid", "profile", "email", "phone", "address"], > "claims": { "oidc_id_token": true }, > "interact": { > "redirect": true, > "callaback": { > "url": "https://client.example/redirect_uri = ", > "nonce": "1233455" > } > } > } >=20 > This would get you back an OIDC id token and access token with the = OIDC scopes tied to the server=E2=80=99s UserInfo Endpoint. But as = I=E2=80=99ve been saying, I don=E2=80=99t think it=E2=80=99s within the = purview of this working group to define that level of detail. What we = should do is define what the =E2=80=9Cresources=E2=80=9D field means, = what the =E2=80=9Cclaims=E2=80=9D field means, and put a few buckets in = there for common identifiers and assertions so that people do things the = same way. And I=E2=80=99ll repeat that I would personally prefer the = simple identity mapping layer be in a separate document from the core = delegation protocol =E2=80=94 but that=E2=80=99s a matter for the WG to = decide.=20 >=20 > I=E2=80=99ll also repeat my argument that I don=E2=80=99t think we = should just blindly re-use OIDC=E2=80=99s names for things, but that is = not me saying that we should, of necessity, invent new things entirely = "just because=E2=80=9D. Every choice we make, including what we name = fields, needs to have a good reason.=20 >=20 > And if the WG does end up creating new names for some things? That=E2=80= =99s not the end of the world. When we were working on OIDC, there was = an opportunity to re-use field names from LDAP (specifically, to use = inetOrgPerson and/or eduOrgPerson as the schema), but as you (Mike) = know, we decided not to, and the world is OK for that even though it = meant people had to write a simple translator when wrapping their LDAP = servers with OIDC capabilities (and complained about it at the time).=20 >=20 > Re-use does not just mean copying. It means examining what is there = and pulling the best from it =E2=80=94 and that is going to include = sources beyond OAuth2 and OIDC. At this point we should be looking at = what features we like from the entire ecosystem, including the two = proposed drafts, and decide what we want to bring forward into TxAuth. = And in terms of flexibility, stability, simplicity, and consistency, I = believe that XYZ makes a much stronger base for building on.=20 >=20 And an addition =E2=80=94 if you want to just keep using OAuth 2 and = back port functionality to OAuth2 in a compatible way, that work should = be done in the OAuth 2 working group. Here, we=E2=80=99re trying to move = forward, not just rest on what=E2=80=99s been done. That=E2=80=99s not = an argument to invent everything from whole cloth, it=E2=80=99s an = argument to build things better wherever we can. I=E2=80=99m really glad = to have the deep experience of so many participants feeding into this = group for exactly that reason! =E2=80=94 Justin > =E2=80=94 Justin >=20 >=20 >> On Mar 23, 2020, at 3:53 PM, Mike Jones > wrote: >>=20 >> I would prefer XAuth as a starting point over XYZ because XAuth is = clearly trying to reuse existing identity representations, whereas XYZ = is creating a new one. >> =20 >> You can see XAuth=E2=80=99s reuse, for instance, at = https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6 = .= >> =20 >> You can see XYZ=E2=80=99s invention of a new identity schema at = https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.= 7 = . Yes, it=E2=80=99s similar to some others but not the same, and = rather than reusing existing registered claims, it=E2=80=99s creating = its own unique set. >> =20 >> -- Mike >> =20 >> From: Txauth > On Behalf Of Dick Hardt >> Sent: Friday, March 20, 2020 1:18 PM >> To: txauth@ietf.org >> Cc: Justin Richer >> Subject: [EXTERNAL] Re: [Txauth] XYZ vs XAuth - 5 differences >> =20 >> ACTION REMINDER >> =20 >> Please weigh in with your preference, your rationale, as well as any = pros and cons not described. >> =20 >> Yaron and I were hopeful that we would get more feedback on these = topics, as it would help determine if either the XYZ or XAuth documents = are roughly aligned with the consensus direction of the group so that we = have a starting document. >> =20 >> We will NOT be able to do hums in the BoF ... so we will not be able = to use that to judge rough consensus. >> =20 >> /Dick >> =20 >> On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt > wrote: >> Hello everyone >> =20 >> Justin and I have had some emails back and forth comparing and = contrasting XYZ and XAuth. I'm going to post a message for each of the = major points, with Justin's rationale and my rationale for our = respective design decisions. Feel free to ask clarifying questions in = those threads. >> =20 >> Please weigh in with your preference, your rationale, as well as any = pros and cons not described. >> =20 >> We would like to get a sense for the group's views on these topics = for the virtual BoF in a week. >> =20 >> The latest drafts are: >> =20 >> XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 = >> =20 >> XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 = >> =20 >> Thanks! >> =20 >> /Dick >> =E1=90=A7 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_8780D9DD-70CA-4D1D-B942-53A3BFE1140F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Two = quick notes I missed:

On Mar 24, 2020, at 9:41 AM, = Justin Richer <jricher@mit.edu> wrote:

I mentioned this on = the call yesterday, but this is an incredibly weak argument to pick one = draft over another, especially at such an early stage. I would consider = everything XYZ malleable, especially what the fields get named. It=E2=80=99= s short sighted to throw out an entire specification because of the = names of fields that were added very recently to the draft. 

In other words, I think = it=E2=80=99s too early to judge based on things like this, and it shows = blindness to the rest of the draft. It=E2=80=99s true that Dick and I = have taken a very different approach to re-use, but both have re-use. =  XYZ does re-use many elements from OAuth 2, OIDC, and XYZ, but = they=E2=80=99ve been translated into a system that=E2=80=99s internally = consistent in a way that the source material is not. Dick has said = several times that =E2=80=9CXYZ doesn=E2=80=99t use OAuth 2 scopes=E2=80=9D= which is blatantly

One correction =E2=80=94 I meant to say =E2=80=9COAu= th 2, OIDC, and others like UMA,=E2=80=9D. :)

not true =E2=80=94 we = designed the system explicitly so that you could do that. However, we = didn=E2=80=99t just put in a field labeled =E2=80=9Coauth_scopes=E2=80=9D = because, as we=E2=80=99ve found in defining RAR in OAuth 2, it gets = complicated quickly trying to combine them if you have different layers = of semantics within the protocol. XYZ puts the scope style requests at = the same level as the rich requests.

So let=E2=80=99s say you wanted to do a = full mapping of an OIDC request, just swapping out OAuth 2 for XYZ, = it=E2=80=99d look something like this:


{
  "keys": = "client-id-1234556",
  "resources": ["openid", = "profile", "email", "phone", "address"],
  = "claims": { "oidc_id_token": true },
  = "interact": {
"redirect": true,
= "callaback": {
"url": "https://client.example/redirect_uri",
= "nonce": "1233455"
= }
  }
}

This would get you back = an OIDC id token and access token with the OIDC scopes tied to the = server=E2=80=99s UserInfo Endpoint. But as I=E2=80=99ve been saying, I = don=E2=80=99t think it=E2=80=99s within the purview of this working = group to define that level of detail. What we should do is define what = the =E2=80=9Cresources=E2=80=9D field means, what the =E2=80=9Cclaims=E2=80= =9D field means, and put a few buckets in there for common identifiers = and assertions so that people do things the same way. And I=E2=80=99ll = repeat that I would personally prefer the simple identity mapping layer = be in a separate document from the core delegation protocol =E2=80=94 = but that=E2=80=99s a matter for the WG to decide. 

I=E2=80=99ll also repeat = my argument that I don=E2=80=99t think we should just blindly re-use = OIDC=E2=80=99s names for things, but that is not me saying that we = should, of necessity, invent new things entirely "just because=E2=80=9D. = Every choice we make, including what we name fields, needs to have a = good reason. 

And if the WG does end up creating new names for some things? = That=E2=80=99s not the end of the world. When we were working on OIDC, = there was an opportunity to re-use field names from LDAP (specifically, = to use inetOrgPerson and/or eduOrgPerson as the schema), but as you = (Mike) know, we decided not to, and the world is OK for that even though = it meant people had to write a simple translator when wrapping their = LDAP servers with OIDC capabilities (and complained about it at the = time). 

Re-use does not just mean copying. It means examining what is = there and pulling the best from it =E2=80=94 and that is going to = include sources beyond OAuth2 and OIDC. At this point we should be = looking at what features we like from the entire ecosystem, including = the two proposed drafts, and decide what we want to bring forward into = TxAuth. And in terms of flexibility, stability, simplicity, and = consistency, I believe that XYZ makes a much stronger base for building = on. 


And an addition =E2=80=94 if you want to just keep = using OAuth 2 and back port functionality to OAuth2 in a compatible way, = that work should be done in the OAuth 2 working group. Here, we=E2=80=99re= trying to move forward, not just rest on what=E2=80=99s been done. = That=E2=80=99s not an argument to invent everything from whole cloth, = it=E2=80=99s an argument to build things better wherever we can. I=E2=80=99= m really glad to have the deep experience of so many participants = feeding into this group for exactly that reason!

 =E2=80=94 Justin

 =E2=80=94 = Justin


On Mar 23, 2020, at 3:53 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

I would = prefer XAuth as a = starting point over XYZ because XAuth is clearly trying to reuse = existing identity representations, whereas XYZ is creating a new = one.
 
You can see = XAuth=E2=80=99s reuse, for instance, at https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#secti= on-4.6.6.
 
You can see = XYZ=E2=80=99s invention of a new identity schema at https://tools.ietf.org/html/draft-richer-transactional-authz-06= #section-2.7.  Yes, it=E2=80=99s similar to some others but not = the same, and rather than reusing existing registered claims, it=E2=80=99s= creating its own unique set.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Friday, March 20, 2020 1:18 = PM
To: txauth@ietf.org
Cc: Justin Richer <jricher@mit.edu>
Subject: [EXTERNAL] Re: [Txauth] XYZ = vs XAuth - 5 differences
 
ACTION REMINDER
 
Please weigh in with your preference, your = rationale, as well as any pros and cons not described.
 
Yaron and I were = hopeful that we would get more feedback on these topics, as it = would help determine if either the XYZ or XAuth documents are roughly = aligned with the consensus direction of the group so that we have a = starting document.
 
We will NOT be able to do hums in the BoF ... so we will not = be able to use that to judge rough consensus.
 
/Dick
 
On Mon, Mar 16, 2020 at = 4:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello = everyone
 
Justin and I have had some = emails back and forth comparing and contrasting XYZ and XAuth. I'm going = to post a message for each of the major points, with Justin's rationale = and my rationale for our respective design decisions. Feel free to = ask clarifying questions in those threads.
 
Please weigh in with your = preference, your rationale, as well as any pros and cons not = described.
 
We would like to get a sense for the group's views on these = topics for the virtual BoF in a week.
 
The latest drafts are:
 
XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06=
 
 
Thanks!
 
/Dick
=E1=90=A7

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_8780D9DD-70CA-4D1D-B942-53A3BFE1140F-- From nobody Tue Mar 24 08:19:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06603A0A1F for ; Tue, 24 Mar 2020 08:18:56 -0700 (PDT) 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=sunet.se 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 aOfy7VP2VCdZ for ; Tue, 24 Mar 2020 08:18:54 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 9BDB33A0C9E for ; Tue, 24 Mar 2020 08:18:53 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id r24so19063841ljd.4 for ; Tue, 24 Mar 2020 08:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GO/VHPPyZGTpujvs2DuF2GKwW8NE5CUAY1jfhXxUJEo=; b=EPnXsQa6ujMp2B/Zsvumxycc/opGCuYyGqIR6Nva4/CZo7zpQ6EcFhrvvg+XWAW6ED M4rpCAQ3PwThL2BvgzCZmIhmydeoXU5niXdsVl4sTKe2Wi+nuR+O9DJj7M6Wh8BUHKm0 V4G24vkUoUqmfPI798N/tQxFHXNRULSsXymV7eHtCg9MHd0x6e+xWWszOUpFT3NZSaFD tKuEqpnuGeFMEZFmB4FKrG893vIWHlo0Varl1IUfYUhQriHk9XJze9UXOpuMoQqnCwfb UbU6QVo/WV71vWz7oOJKGytLwZmf3oNUVKSi7jrycFfJ2DlUUsMxprRAg0H5XyFm+w1j kXwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GO/VHPPyZGTpujvs2DuF2GKwW8NE5CUAY1jfhXxUJEo=; b=YHOJVDz22ogtp8ijudMYtYm7GTVMIcl36caHDTcP0R232viQjRdYSVlmH5h6Inb+87 LXWmkW0u521DsrcIqPcO81lvDeWeZUzbHWp5dhWyWSSo8w4v3/sAiRN5Gr2xo8EnBjVf mPeZuZUXkneTS6T4u9h8m1BJux1M2tGezWp4r/o3I1qN/MGT4kpF0KOV2onPvPlo2ODW 2Answ6hci9z9bNK3tmPcOf3nTvQmaZWFicTArI18B8cNH8tseKc68kq7DD6CJnNae2Xu u5C3Ccnv9Gi3KhZ19o/hho01R45Z4t6ETpk/MshoExhqGQQUAPyfETNo26gb/kPcBoTY u5gg== X-Gm-Message-State: ANhLgQ1AaydhPX0EV4c+voB4shfmYVBlyrtLYhaG2ONl8KXX8s65hhgI NCAOaBpP2eLm5PxOq0fTsr3G12r6rn798A== X-Google-Smtp-Source: ADFU+vu/gMaP+vurs1TnzebYSHIiUVoV1ybB6y7Il7dgLTe15IT8D0rdhHTcg9jkoR2hn2CP62G2Uw== X-Received: by 2002:a2e:884d:: with SMTP id z13mr210738ljj.158.1585063130593; Tue, 24 Mar 2020 08:18:50 -0700 (PDT) Received: from [10.0.0.129] (h-98-128-229-152.NA.cust.bahnhof.se. [98.128.229.152]) by smtp.gmail.com with ESMTPSA id r7sm10147986ljc.3.2020.03.24.08.18.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Mar 2020 08:18:49 -0700 (PDT) To: txauth@ietf.org References: From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA== Message-ID: <6e9ee67d-5e72-d6f0-00bb-9a85cbc3b31d@sunet.se> Date: Tue, 24 Mar 2020 16:18:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Txauth] [EXTERNAL] Re: XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 15:19:16 -0000 On 2020-03-23 20:53, Mike Jones wrote: > *I would prefer XAuth*as a starting point over XYZ because XAuth is clearly trying to reuse existing identity representations, whereas XYZ is creating a new one. > I wish somebody would have made that argument in favor of reusing OID URNs from SAML in OIDC :-) Cheers Leif From nobody Tue Mar 24 11:35:27 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77C23A123C for ; Tue, 24 Mar 2020 11:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 A2b86uSN8xTW for ; Tue, 24 Mar 2020 11:35:04 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640122.outbound.protection.outlook.com [40.107.64.122]) (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 D2E8C3A122C for ; Tue, 24 Mar 2020 11:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vq4gysBNUiUkUR30joaZsgG3OWwlkqonPeAnTLejrLh/vAoMgZ6AZEltvx8dY7stsODZ35VDGSR/RE0jgL/8Y0Idn2gBu4sOBFFkE782r5LciPQ9S9IRLA16IUTSdS+WAhBncSOmx6ZaAZ4JAGNdO1ujoefD7+RwBhaJ74Uo6Ti8nP25OADIm6ON//y31MUfEIIQSQ36yndtyvOjLwcnzSJJz2xvZxt7KfVfeo76NPlX60MUrNQ/q+6J5rdtDKrLInlWCujT5gIw0IhMSoFGipK1XB0Jh0Ny9UUBHT5O93JsDUFPK4BTisWUiVjqSKg6JahOq/NPm+hCsYnohVqGKg== 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=AzS43xTaUoxMj+gZ71WmWh8+KqvCoSWVYBNufppTgKU=; b=OLmNoviCSh5L8bj+XAfSI39X9rRPkBfCx6uy+VcN/6QPvPe9fVC4mZ84PVT+EFj82eKLIqJg2hXBriJKhjHSCYvSJtq/hpMyJa8jPidBO6q+xjH+Fpdvi/pLw6pAjhSBf5hzkUHV0PEX5R0TYO1yGx4d/2Ssqv8XWlh4XRjDq9VGv49PneecbND0rWb9DwTsmm4Ughh7ku4BONXH7WI6eJ8lSCg9dIqPE6pSgGIWs5h+uO2DS+JNzrVTXpnNUu/tn9RyawIZXQbFy+h8Wh38zE47nDZtQvais/U4vKeoUTq/ifv+3BfI1CW8hYi5+mB0Nz7OH10aY363aVxNeeMYTw== 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=AzS43xTaUoxMj+gZ71WmWh8+KqvCoSWVYBNufppTgKU=; b=ErmCCxe4wB9J5atnsC4lLU8vZ8vo2wscw2hFz14Kz5ymnRV+yucbdnLUxm/OAkQk164/IzatCIZ0CCml/ssIhJ5eXqkPfdDoI1cFkos0mV+nl2YRcTBJDHDDbq6JWTX8CHxrTMEXGGS1Fycwa9M/0yvY976I1qwUL0MU4mjwnGo= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (10.255.224.141) by MN2PR00MB0463.namprd00.prod.outlook.com (20.178.240.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2877.0; Tue, 24 Mar 2020 18:35:01 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2097:d2a0:b135:ee4d]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2097:d2a0:b135:ee4d%8]) with mapi id 15.20.2895.000; Tue, 24 Mar 2020 18:35:01 +0000 From: Mike Jones To: Leif Johansson , "txauth@ietf.org" Thread-Topic: [Txauth] Re: XYZ vs XAuth - 5 differences Thread-Index: AdYCCuud6RTiHFAyTgGoYyGBTBiiaw== Date: Tue, 24 Mar 2020 18:35:00 +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_ActionId=2fed21ef-2795-4293-a058-00002e1c569f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-24T18:13:51Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 37df98d7-7091-49e2-530b-08d7d0220ff3 x-ms-traffictypediagnostic: MN2PR00MB0463: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(136003)(376002)(39860400002)(366004)(396003)(10290500003)(478600001)(26005)(2906002)(52536014)(33656002)(186003)(55016002)(8936002)(9686003)(76116006)(316002)(66476007)(66556008)(64756008)(66446008)(110136005)(66946007)(7696005)(81156014)(8990500004)(86362001)(71200400001)(966005)(8676002)(81166006)(6506007)(5660300002)(53546011); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Vi9pVOLZan2r9X60/YX5V0MHWN8RpSrBqyD9LTDAWKKvJQIsr+Go1zjFNWFPxgaJjAXkOggm3M76pQnPy5a/EehmzBe8mihgm0mCM7hpVVT3SCZGb8g4hVqwu6Ap9QnIE0eCCuwk4CUI3o3OOukraCUc+jhk6MYfD+VSweuGVbUjpfXttwAEkmf2C0xMkgau1bzof6Yg5Bi4IE8QpuxIWcMBfeDAFmLC4/V4c7RpPtU26+EPE1kJ25ay2USYMczk/3bABJLjqNwdBSCjjM20vQqkf5EKWZwdm1usyyYKH5DqIXnJA0QvsJXSGeR8wDszhWuKj2HK4l/Ote6YQY6C8jSU5nEz4yg6oR6qPpJrtDDzSlkOIoDy4RV1ziglBhejTTm/ot+aUrzj3/ehYJNbsHbk7LToo8Ekx7uDKpnjEjt0NHitl5FEY+d2d42RXpK2dMCZdJ+MxpShl4yQU0yxqLNy7STCwA0Vh8ckvGWVzanynEqif/RgIjv/5IlAWVxk1RMbUAx9S+2rImvfFioWBA== x-ms-exchange-antispam-messagedata: zXNqt6D8zmqQabqaLWgB+jvEg5M2kp/otgVw/3Vz70aC7eo2iAiAx6LhVWsWImePPWGZuyr23bxzLhNvyMZLsO2QuGXO5SPxh/nh6GRk0920miW7e5X8slpNzrnTshYzZfL89lp5P5ARPUcxxpm9gQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37df98d7-7091-49e2-530b-08d7d0220ff3 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 18:35:00.9373 (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: XSDLwAHb8Bpn6diz0isepwUD7Fscz4b2GX2GIwX0QnFVIx8hLSSg3PHMnSx79AYZmKHJnCaAjgSKtxXyHBz1NA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0463 Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 18:35:24 -0000 Taking Leif's comment seriously, for the record, here's some of the histori= cal context on why OpenID Connect created new short JSON claim names. Firs= t, we actually did seriously consider reusing existing SAML attribute name = URNs. But at the time, developers were voting with their feet, rejecting X= ML and SOAP for JSON and REST, and we wanted the result to be something tha= t developers would embrace. =20 Also, remember that Facebook Connect already existed, which used short JSON= claim names like "email" and "id". At the time, Facebook was actively con= tributing to OpenID Connect and together we consciously embraced short simp= le claim names like those used in Facebook Connect, as developers seemed to= like them. But we created the IANA JSON Web Token Claims Registry to make= them part of an open, extensible set of standards. At least we were right that developers would gravitate towards the intentio= nally simple design OpenID Connect if they wanted a standards-based identit= y solution. (See the large set of certified implementations at https://ope= nid.net/certification/ as one data point quantifying this success.) Yes, w= e could have done many things differently, but on the whole, the choices se= em to have worked out well in the marketplace of ideas and implementations. Cheers, -- Mike -----Original Message----- From: Txauth On Behalf Of Leif Johansson Sent: Tuesday, March 24, 2020 8:19 AM To: txauth@ietf.org Subject: Re: [Txauth] Re: XYZ vs XAuth - 5 differences On 2020-03-23 20:53, Mike Jones wrote: > *I would prefer XAuth*as a starting point over XYZ because XAuth is clear= ly trying to reuse existing identity representations, whereas XYZ is creati= ng a new one. >=20 I wish somebody would have made that argument in favor of reusing OID URNs = from SAML in OIDC :-) Cheers Leif --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 24 11:54:37 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2613A124C for ; Tue, 24 Mar 2020 11:54:21 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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_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=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 mb2GFlApesAv for ; Tue, 24 Mar 2020 11:54:18 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe55::70e]) (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 9020D3A122D for ; Tue, 24 Mar 2020 11:54:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dNqna5yw2xgPBmOv9WdwzFYmg8ppXd5BJoqD20EbO3oGAYJjai9OeyspbVQXOfuO9l4iw7B2Hnf4Yc2U5tVLY/hRCfDv0dwgUo1bQclBuakSzuEOppnO9q2xgeeiJkTPYDPsCwNrrZXrs/eki+zS3Kue4IWSPB4+6vfiNHRC3wdLcviHXOwuTfRG0Ptwpjz3u2kS9NtYAAsUlm2EqffR+0TsXulNLuYxVJfC0n7IYSkjU1uxy/xLw8nEdW3sAbAPFkoepP3ax3C45EfTNjuNJ5fCv36yhg4zXDxvM3TsnUs7XiwLTzKCual1z09NDH3pjmdMe34yssEDwsPCz7pK5w== 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=4m9eASij1oM2X26DdkcsD9GG+VZOK+E5PHKCPy4k2MI=; b=R5YttCChebGhOeJx2bylxIk3qNWs467P666nZpy6ZIYL3uy+AdhS0V2EUknbGd6ous1AYK6HxwEpdyXraiX27kkB7CtmmOf/Q8GmUFTfzsd0Q5Wu+LR1ZCdJ7teSFof0C1ZSLKmq+4a/uI0zi8lcIqe1K8547Whs8nRgfutpC0a275uRs+jedUwgb2QOFqHttGY7eBvRzte6CXGVJyoRbSUSyzkFfxjQAbynMXQ5xYgAM/wEGsmjewhRSoBdFde+9qCntUry1h0PFpIIv5i+yt89dQMYDkzHpugQmZMd1K0hdTj+4/zbySvj3xtrGY8GB0mwzVCXA5C1nVu2LG5NfQ== 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=4m9eASij1oM2X26DdkcsD9GG+VZOK+E5PHKCPy4k2MI=; b=HOGwbRMrWCCRe2XGwYKBpeGElKScJ3jANeD9Qv8oqxDLmKa7d2qccAP/TyM3wuxqGX2y2bVHgZRCqjK1v4qw87LCatYvszzVmLxKwVNgNxVeFNt7g0O0VEcA9lHOIIBgMXm/GnCcbjYKAek1kjSkSxXzUe9EJjcUjGzV1cr/jIc= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (10.255.224.141) by BL0PR00MB0769.namprd00.prod.outlook.com (52.135.44.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2895.0; Tue, 24 Mar 2020 18:54:16 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2097:d2a0:b135:ee4d]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2097:d2a0:b135:ee4d%8]) with mapi id 15.20.2895.000; Tue, 24 Mar 2020 18:54:16 +0000 From: Mike Jones To: Justin Richer CC: "txauth@ietf.org" , Dick Hardt Thread-Topic: [Txauth] XYZ vs XAuth - 5 differences Thread-Index: AdYCDZkAZ64w/91WQbiCW+dmgz6tZA== Date: Tue, 24 Mar 2020 18:54:16 +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_ActionId=1051bd1d-01f5-47de-ad39-0000824ad191; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-24T18:37:03Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cdfabe37-5a9f-4439-f37e-08d7d024c0af x-ms-traffictypediagnostic: BL0PR00MB0769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(346002)(136003)(376002)(366004)(39860400002)(396003)(6916009)(55016002)(81166006)(9686003)(8936002)(81156014)(86362001)(71200400001)(8676002)(10290500003)(186003)(966005)(54906003)(4326008)(53546011)(7696005)(6506007)(52536014)(2906002)(26005)(76236002)(33656002)(5660300002)(66946007)(478600001)(66446008)(66556008)(316002)(66476007)(64756008)(8990500004)(861006)(76116006)(99710200001); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Sk3VUcgEb1pPlrVwVDIGqw7qUswEyz0F8785GeF24tqfmq5JCFP+tmI8c6cNiGW5WbnkJrzjc9rE2/CK7Ijc7cb9aRh727Q6hhB5cymdiqyYGOqkLCP0lL0/1HHvO2SFFYYCW+/BPwPLH+S/y7mHelZfDRiJVAxrgiUrktZV6Nb+QUTC4Z9zUDVyLtF7MVUqIHWd2l2SNC5S6zEi3Ah5u6IkHOnpslvPH+5N5hvx+jZOlFAqEl1N5ZKWbL+LaeiW6ZWB3Yy+IU9OHiQHGF2ubiJm8vJU7Ejhei9DyH/x8acbckciNcKKwjuqgsKRHPGPXVQ/smfFcAvwbRxlO9fCnoGRLh2Z1bi7cDitQWR1TEpxvP2rVjJ44fx2FUBSyEbFK/Dd9DxRR8ORQqCBKKuNftIjre3BjXy3drOgPVABuh0dNZ95c7lJbN35EEfT4stRYD4nSyWNZbAqs6h3tYa39w8reBwoZ4QvpQXDAqNMG/u5N2T+9xF0DRJ8Gn75fIy4Ljz5Rl7+d0YHxhXiufYGnc+dZte3NnCUoshYXkbOV7rCDLNkU8gdMA+IkD5EG1SZ x-ms-exchange-antispam-messagedata: HLF0l7GcW8HMtOn7cqnO2jf8N1Gk5NEMOz9wwIHmZDYq/chfCiioxkUcim86urylKNiLgjF+OvSlGpKCPvQJXk4AEwgvi9rATUlerdrTsJHZSnnTDDn7xcvSKDGL0eLKhNxc4KwSCldBFu0mqD2CcQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB06861DFFC8C6A909B7AADD9FF5F10MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdfabe37-5a9f-4439-f37e-08d7d024c0af X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 18:54:16.5395 (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: O3UVSx638KM/0jhcQghWqXcVJEDEkxgEPC3zjJBAt1ULQ8DSnwEjGMhA3OoDc1FxH5NJh3PGghOTvf+H+E9guA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0769 Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 18:54:36 -0000 --_000_MN2PR00MB06861DFFC8C6A909B7AADD9FF5F10MN2PR00MB0686namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLCBpZiB5b3Ugd2FudCB0byB0YWtlIHRoZSBpZGVudGl0eSBjbGFpbXMgcmV1c2UgYXJn dW1lbnQgb2ZmIHRoZSB0YWJsZSwgcHVibGlzaCBhIG5ldyBkcmFmdCBvZiBkcmFmdC1yaWNoZXIt dHJhbnNhY3Rpb25hbC1hdXRoeiBpbiB3aGljaCB5b3UgYWRkIHNvbWV0aGluZyBsaWtlIHRoaXMg bGFuZ3VhZ2UgdG8gdGhlIENsYWltcyBzZWN0aW9uIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wNiNzZWN0aW9uLTIuNzoNCg0K VGhlIHJlcXVlc3RlZCBjbGFpbSBuYW1lcyBoZXJlIGFuZCB0aG9zZSBpbiB0aGUgY29ycmVzcG9u ZGluZyByZXNwb25zZSBhcmUgaW50ZW5kZWQgdG8gY29tZSBmcm9tIHRoZSBJQU5BIOKAnEpTT04g V2ViIFRva2VuIENsYWltc+KAnSBSZWdpc3RyeSBbSUFOQS5KV1QuQ2xhaW1zXS4gIFdoZXJlIHRo aXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIG5ldyBjbGFpbXMsIGl0IHJlZ2lzdGVycyB0aGVtIGlu IHRoaXMgcmVnaXN0cnkuDQoNCkFuZCB0aGVuIHBvcHVsYXRlIHRoZSBJQU5BIENvbnNpZGVyYXRp b25zIHNlY3Rpb24gb2YgdGhlIG5ldyBkcmFmdCB0byByZWdpc3RlciBuZXcgY2xhaW1zIHRoYXQg dGhlIGRvY3VtZW50IHVzZXMgdGhhdCBhcmUgbm90IGFscmVhZHkgcmVnaXN0ZXJlZCwgc3VjaCBh cyDigJxzdWJqZWN04oCdLg0KDQpJ4oCZbGwgYmUgd2F0Y2hpbmcgdG8gc2VlIHdoZXRoZXIgeW91 IGRvIHRoaXMgYXMgYSBzdGF0ZW1lbnQgb2YgaW50ZW50IHRvIHJldXNlIG9mIGV4aXN0aW5nIGlk ZW50aXR5IGNsYWltcyBvciB3aGV0aGVyIHlvdSBjaG9vc2Ugbm90IHRvLg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVzdCB3aXNoZXMs DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0gTWlrZQ0KDQpQLlMuICBUaGUgSUFOQSBKV1QgQ2xhaW1zIFJlZ2lzdHJ5IFtJQU5BLkpXVC5D bGFpbXNdIGlzIG9mIGNvdXJzZSBhdCBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9q d3QvLg0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpTZW50OiBUdWVz ZGF5LCBNYXJjaCAyNCwgMjAyMCA3OjQ4IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPg0KQ2M6IHR4YXV0aEBpZXRmLm9yZzsgRGljayBIYXJkdCA8ZGljay5o YXJkdEBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gWFlaIHZzIFhBdXRoIC0gNSBk aWZmZXJlbmNlcw0KDQpUd28gcXVpY2sgbm90ZXMgSSBtaXNzZWQ6DQoNCg0KT24gTWFyIDI0LCAy MDIwLCBhdCA5OjQxIEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpy aWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQpJIG1lbnRpb25lZCB0aGlzIG9uIHRoZSBjYWxsIHll c3RlcmRheSwgYnV0IHRoaXMgaXMgYW4gaW5jcmVkaWJseSB3ZWFrIGFyZ3VtZW50IHRvIHBpY2sg b25lIGRyYWZ0IG92ZXIgYW5vdGhlciwgZXNwZWNpYWxseSBhdCBzdWNoIGFuIGVhcmx5IHN0YWdl LiBJIHdvdWxkIGNvbnNpZGVyIGV2ZXJ5dGhpbmcgWFlaIG1hbGxlYWJsZSwgZXNwZWNpYWxseSB3 aGF0IHRoZSBmaWVsZHMgZ2V0IG5hbWVkLiBJdOKAmXMgc2hvcnQgc2lnaHRlZCB0byB0aHJvdyBv dXQgYW4gZW50aXJlIHNwZWNpZmljYXRpb24gYmVjYXVzZSBvZiB0aGUgbmFtZXMgb2YgZmllbGRz IHRoYXQgd2VyZSBhZGRlZCB2ZXJ5IHJlY2VudGx5IHRvIHRoZSBkcmFmdC4NCg0KSW4gb3RoZXIg d29yZHMsIEkgdGhpbmsgaXTigJlzIHRvbyBlYXJseSB0byBqdWRnZSBiYXNlZCBvbiB0aGluZ3Mg bGlrZSB0aGlzLCBhbmQgaXQgc2hvd3MgYmxpbmRuZXNzIHRvIHRoZSByZXN0IG9mIHRoZSBkcmFm dC4gSXTigJlzIHRydWUgdGhhdCBEaWNrIGFuZCBJIGhhdmUgdGFrZW4gYSB2ZXJ5IGRpZmZlcmVu dCBhcHByb2FjaCB0byByZS11c2UsIGJ1dCBib3RoIGhhdmUgcmUtdXNlLiAgWFlaIGRvZXMgcmUt dXNlIG1hbnkgZWxlbWVudHMgZnJvbSBPQXV0aCAyLCBPSURDLCBhbmQgWFlaLCBidXQgdGhleeKA mXZlIGJlZW4gdHJhbnNsYXRlZCBpbnRvIGEgc3lzdGVtIHRoYXTigJlzIGludGVybmFsbHkgY29u c2lzdGVudCBpbiBhIHdheSB0aGF0IHRoZSBzb3VyY2UgbWF0ZXJpYWwgaXMgbm90LiBEaWNrIGhh cyBzYWlkIHNldmVyYWwgdGltZXMgdGhhdCDigJxYWVogZG9lc27igJl0IHVzZSBPQXV0aCAyIHNj b3Blc+KAnSB3aGljaCBpcyBibGF0YW50bHkNCg0KT25lIGNvcnJlY3Rpb24g4oCUIEkgbWVhbnQg dG8gc2F5IOKAnE9BdXRoIDIsIE9JREMsIGFuZCBvdGhlcnMgbGlrZSBVTUEs4oCdLiA6KQ0KDQoN Cm5vdCB0cnVlIOKAlCB3ZSBkZXNpZ25lZCB0aGUgc3lzdGVtIGV4cGxpY2l0bHkgc28gdGhhdCB5 b3UgY291bGQgZG8gdGhhdC4gSG93ZXZlciwgd2UgZGlkbuKAmXQganVzdCBwdXQgaW4gYSBmaWVs ZCBsYWJlbGVkIOKAnG9hdXRoX3Njb3Blc+KAnSBiZWNhdXNlLCBhcyB3ZeKAmXZlIGZvdW5kIGlu IGRlZmluaW5nIFJBUiBpbiBPQXV0aCAyLCBpdCBnZXRzIGNvbXBsaWNhdGVkIHF1aWNrbHkgdHJ5 aW5nIHRvIGNvbWJpbmUgdGhlbSBpZiB5b3UgaGF2ZSBkaWZmZXJlbnQgbGF5ZXJzIG9mIHNlbWFu dGljcyB3aXRoaW4gdGhlIHByb3RvY29sLiBYWVogcHV0cyB0aGUgc2NvcGUgc3R5bGUgcmVxdWVz dHMgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgdGhlIHJpY2ggcmVxdWVzdHMuDQoNClNvIGxldOKAmXMg c2F5IHlvdSB3YW50ZWQgdG8gZG8gYSBmdWxsIG1hcHBpbmcgb2YgYW4gT0lEQyByZXF1ZXN0LCBq dXN0IHN3YXBwaW5nIG91dCBPQXV0aCAyIGZvciBYWVosIGl04oCZZCBsb29rIHNvbWV0aGluZyBs aWtlIHRoaXM6DQoNCg0Kew0KICAia2V5cyI6ICJjbGllbnQtaWQtMTIzNDU1NiIsDQogICJyZXNv dXJjZXMiOiBbIm9wZW5pZCIsICJwcm9maWxlIiwgImVtYWlsIiwgInBob25lIiwgImFkZHJlc3Mi XSwNCiAgImNsYWltcyI6IHsgIm9pZGNfaWRfdG9rZW4iOiB0cnVlIH0sDQogICJpbnRlcmFjdCI6 IHsNCiAgICAgICAgICAgICAgInJlZGlyZWN0IjogdHJ1ZSwNCiAgICAgICAgICAgICAgImNhbGxh YmFjayI6IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICJ1cmwiOiAiaHR0cHM6Ly9jbGll bnQuZXhhbXBsZS9yZWRpcmVjdF91cmkiLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIm5v bmNlIjogIjEyMzM0NTUiDQogICAgICAgICAgICAgIH0NCiAgfQ0KfQ0KDQpUaGlzIHdvdWxkIGdl dCB5b3UgYmFjayBhbiBPSURDIGlkIHRva2VuIGFuZCBhY2Nlc3MgdG9rZW4gd2l0aCB0aGUgT0lE QyBzY29wZXMgdGllZCB0byB0aGUgc2VydmVy4oCZcyBVc2VySW5mbyBFbmRwb2ludC4gQnV0IGFz IEnigJl2ZSBiZWVuIHNheWluZywgSSBkb27igJl0IHRoaW5rIGl04oCZcyB3aXRoaW4gdGhlIHB1 cnZpZXcgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGRlZmluZSB0aGF0IGxldmVsIG9mIGRldGFp bC4gV2hhdCB3ZSBzaG91bGQgZG8gaXMgZGVmaW5lIHdoYXQgdGhlIOKAnHJlc291cmNlc+KAnSBm aWVsZCBtZWFucywgd2hhdCB0aGUg4oCcY2xhaW1z4oCdIGZpZWxkIG1lYW5zLCBhbmQgcHV0IGEg ZmV3IGJ1Y2tldHMgaW4gdGhlcmUgZm9yIGNvbW1vbiBpZGVudGlmaWVycyBhbmQgYXNzZXJ0aW9u cyBzbyB0aGF0IHBlb3BsZSBkbyB0aGluZ3MgdGhlIHNhbWUgd2F5LiBBbmQgSeKAmWxsIHJlcGVh dCB0aGF0IEkgd291bGQgcGVyc29uYWxseSBwcmVmZXIgdGhlIHNpbXBsZSBpZGVudGl0eSBtYXBw aW5nIGxheWVyIGJlIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQgZnJvbSB0aGUgY29yZSBkZWxlZ2F0 aW9uIHByb3RvY29sIOKAlCBidXQgdGhhdOKAmXMgYSBtYXR0ZXIgZm9yIHRoZSBXRyB0byBkZWNp ZGUuDQoNCknigJlsbCBhbHNvIHJlcGVhdCBteSBhcmd1bWVudCB0aGF0IEkgZG9u4oCZdCB0aGlu ayB3ZSBzaG91bGQganVzdCBibGluZGx5IHJlLXVzZSBPSURD4oCZcyBuYW1lcyBmb3IgdGhpbmdz LCBidXQgdGhhdCBpcyBub3QgbWUgc2F5aW5nIHRoYXQgd2Ugc2hvdWxkLCBvZiBuZWNlc3NpdHks IGludmVudCBuZXcgdGhpbmdzIGVudGlyZWx5ICJqdXN0IGJlY2F1c2XigJ0uIEV2ZXJ5IGNob2lj ZSB3ZSBtYWtlLCBpbmNsdWRpbmcgd2hhdCB3ZSBuYW1lIGZpZWxkcywgbmVlZHMgdG8gaGF2ZSBh IGdvb2QgcmVhc29uLg0KDQpBbmQgaWYgdGhlIFdHIGRvZXMgZW5kIHVwIGNyZWF0aW5nIG5ldyBu YW1lcyBmb3Igc29tZSB0aGluZ3M/IFRoYXTigJlzIG5vdCB0aGUgZW5kIG9mIHRoZSB3b3JsZC4g V2hlbiB3ZSB3ZXJlIHdvcmtpbmcgb24gT0lEQywgdGhlcmUgd2FzIGFuIG9wcG9ydHVuaXR5IHRv IHJlLXVzZSBmaWVsZCBuYW1lcyBmcm9tIExEQVAgKHNwZWNpZmljYWxseSwgdG8gdXNlIGluZXRP cmdQZXJzb24gYW5kL29yIGVkdU9yZ1BlcnNvbiBhcyB0aGUgc2NoZW1hKSwgYnV0IGFzIHlvdSAo TWlrZSkga25vdywgd2UgZGVjaWRlZCBub3QgdG8sIGFuZCB0aGUgd29ybGQgaXMgT0sgZm9yIHRo YXQgZXZlbiB0aG91Z2ggaXQgbWVhbnQgcGVvcGxlIGhhZCB0byB3cml0ZSBhIHNpbXBsZSB0cmFu c2xhdG9yIHdoZW4gd3JhcHBpbmcgdGhlaXIgTERBUCBzZXJ2ZXJzIHdpdGggT0lEQyBjYXBhYmls aXRpZXMgKGFuZCBjb21wbGFpbmVkIGFib3V0IGl0IGF0IHRoZSB0aW1lKS4NCg0KUmUtdXNlIGRv ZXMgbm90IGp1c3QgbWVhbiBjb3B5aW5nLiBJdCBtZWFucyBleGFtaW5pbmcgd2hhdCBpcyB0aGVy ZSBhbmQgcHVsbGluZyB0aGUgYmVzdCBmcm9tIGl0IOKAlCBhbmQgdGhhdCBpcyBnb2luZyB0byBp bmNsdWRlIHNvdXJjZXMgYmV5b25kIE9BdXRoMiBhbmQgT0lEQy4gQXQgdGhpcyBwb2ludCB3ZSBz aG91bGQgYmUgbG9va2luZyBhdCB3aGF0IGZlYXR1cmVzIHdlIGxpa2UgZnJvbSB0aGUgZW50aXJl IGVjb3N5c3RlbSwgaW5jbHVkaW5nIHRoZSB0d28gcHJvcG9zZWQgZHJhZnRzLCBhbmQgZGVjaWRl IHdoYXQgd2Ugd2FudCB0byBicmluZyBmb3J3YXJkIGludG8gVHhBdXRoLiBBbmQgaW4gdGVybXMg b2YgZmxleGliaWxpdHksIHN0YWJpbGl0eSwgc2ltcGxpY2l0eSwgYW5kIGNvbnNpc3RlbmN5LCBJ IGJlbGlldmUgdGhhdCBYWVogbWFrZXMgYSBtdWNoIHN0cm9uZ2VyIGJhc2UgZm9yIGJ1aWxkaW5n IG9uLg0KDQoNCkFuZCBhbiBhZGRpdGlvbiDigJQgaWYgeW91IHdhbnQgdG8ganVzdCBrZWVwIHVz aW5nIE9BdXRoIDIgYW5kIGJhY2sgcG9ydCBmdW5jdGlvbmFsaXR5IHRvIE9BdXRoMiBpbiBhIGNv bXBhdGlibGUgd2F5LCB0aGF0IHdvcmsgc2hvdWxkIGJlIGRvbmUgaW4gdGhlIE9BdXRoIDIgd29y a2luZyBncm91cC4gSGVyZSwgd2XigJlyZSB0cnlpbmcgdG8gbW92ZSBmb3J3YXJkLCBub3QganVz dCByZXN0IG9uIHdoYXTigJlzIGJlZW4gZG9uZS4gVGhhdOKAmXMgbm90IGFuIGFyZ3VtZW50IHRv IGludmVudCBldmVyeXRoaW5nIGZyb20gd2hvbGUgY2xvdGgsIGl04oCZcyBhbiBhcmd1bWVudCB0 byBidWlsZCB0aGluZ3MgYmV0dGVyIHdoZXJldmVyIHdlIGNhbi4gSeKAmW0gcmVhbGx5IGdsYWQg dG8gaGF2ZSB0aGUgZGVlcCBleHBlcmllbmNlIG9mIHNvIG1hbnkgcGFydGljaXBhbnRzIGZlZWRp bmcgaW50byB0aGlzIGdyb3VwIGZvciBleGFjdGx5IHRoYXQgcmVhc29uIQ0KDQog4oCUIEp1c3Rp bg0KDQoNCiDigJQgSnVzdGluDQoNCg0KDQpPbiBNYXIgMjMsIDIwMjAsIGF0IDM6NTMgUE0sIE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkkgd291bGQgcHJlZmVyIFhBdXRoIGFzIGEgc3Rh cnRpbmcgcG9pbnQgb3ZlciBYWVogYmVjYXVzZSBYQXV0aCBpcyBjbGVhcmx5IHRyeWluZyB0byBy ZXVzZSBleGlzdGluZyBpZGVudGl0eSByZXByZXNlbnRhdGlvbnMsIHdoZXJlYXMgWFlaIGlzIGNy ZWF0aW5nIGEgbmV3IG9uZS4NCg0KWW91IGNhbiBzZWUgWEF1dGjigJlzIHJldXNlLCBmb3IgaW5z dGFuY2UsIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14YXV0aC1w cm90b2NvbC0wNiNzZWN0aW9uLTQuNi42Lg0KDQpZb3UgY2FuIHNlZSBYWVrigJlzIGludmVudGlv biBvZiBhIG5ldyBpZGVudGl0eSBzY2hlbWEgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LTA2I3NlY3Rpb24tMi43LiAgWWVzLCBp dOKAmXMgc2ltaWxhciB0byBzb21lIG90aGVycyBidXQgbm90IHRoZSBzYW1lLCBhbmQgcmF0aGVy IHRoYW4gcmV1c2luZyBleGlzdGluZyByZWdpc3RlcmVkIGNsYWltcywgaXTigJlzIGNyZWF0aW5n IGl0cyBvd24gdW5pcXVlIHNldC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYg T2YgRGljayBIYXJkdA0KU2VudDogRnJpZGF5LCBNYXJjaCAyMCwgMjAyMCAxOjE4IFBNDQpUbzog dHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+DQpDYzogSnVzdGluIFJpY2hl ciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+Pg0KU3ViamVjdDogW0VY VEVSTkFMXSBSZTogW1R4YXV0aF0gWFlaIHZzIFhBdXRoIC0gNSBkaWZmZXJlbmNlcw0KDQpBQ1RJ T04gUkVNSU5ERVINCg0KUGxlYXNlIHdlaWdoIGluIHdpdGggeW91ciBwcmVmZXJlbmNlLCB5b3Vy IHJhdGlvbmFsZSwgYXMgd2VsbCBhcyBhbnkgcHJvcyBhbmQgY29ucyBub3QgZGVzY3JpYmVkLg0K DQpZYXJvbiBhbmQgSSB3ZXJlIGhvcGVmdWwgdGhhdCB3ZSB3b3VsZCBnZXQgbW9yZSBmZWVkYmFj ayBvbiB0aGVzZSB0b3BpY3MsIGFzIGl0IHdvdWxkIGhlbHAgZGV0ZXJtaW5lIGlmIGVpdGhlciB0 aGUgWFlaIG9yIFhBdXRoIGRvY3VtZW50cyBhcmUgcm91Z2hseSBhbGlnbmVkIHdpdGggdGhlIGNv bnNlbnN1cyBkaXJlY3Rpb24gb2YgdGhlIGdyb3VwIHNvIHRoYXQgd2UgaGF2ZSBhIHN0YXJ0aW5n IGRvY3VtZW50Lg0KDQpXZSB3aWxsIE5PVCBiZSBhYmxlIHRvIGRvIGh1bXMgaW4gdGhlIEJvRiAu Li4gc28gd2Ugd2lsbCBub3QgYmUgYWJsZSB0byB1c2UgdGhhdCB0byBqdWRnZSByb3VnaCBjb25z ZW5zdXMuDQoNCi9EaWNrDQoNCk9uIE1vbiwgTWFyIDE2LCAyMDIwIGF0IDQ6MDQgUE0gRGljayBI YXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4g d3JvdGU6DQpIZWxsbyBldmVyeW9uZQ0KDQpKdXN0aW4gYW5kIEkgaGF2ZSBoYWQgc29tZSBlbWFp bHMgYmFjayBhbmQgZm9ydGggY29tcGFyaW5nIGFuZCBjb250cmFzdGluZyBYWVogYW5kIFhBdXRo LiBJJ20gZ29pbmcgdG8gcG9zdCBhIG1lc3NhZ2UgZm9yIGVhY2ggb2YgdGhlIG1ham9yIHBvaW50 cywgd2l0aCBKdXN0aW4ncyByYXRpb25hbGUgYW5kIG15IHJhdGlvbmFsZSBmb3Igb3VyIHJlc3Bl Y3RpdmUgZGVzaWduIGRlY2lzaW9ucy4gRmVlbCBmcmVlIHRvIGFzayBjbGFyaWZ5aW5nIHF1ZXN0 aW9ucyBpbiB0aG9zZSB0aHJlYWRzLg0KDQpQbGVhc2Ugd2VpZ2ggaW4gd2l0aCB5b3VyIHByZWZl cmVuY2UsIHlvdXIgcmF0aW9uYWxlLCBhcyB3ZWxsIGFzIGFueSBwcm9zIGFuZCBjb25zIG5vdCBk ZXNjcmliZWQuDQoNCldlIHdvdWxkIGxpa2UgdG8gZ2V0IGEgc2Vuc2UgZm9yIHRoZSBncm91cCdz IHZpZXdzIG9uIHRoZXNlIHRvcGljcyBmb3IgdGhlIHZpcnR1YWwgQm9GIGluIGEgd2Vlay4NCg0K VGhlIGxhdGVzdCBkcmFmdHMgYXJlOg0KDQpYWVo6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wNg0KDQpYQXV0aDogaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3RvY29sLTA1DQoNClRoYW5r cyENCg0KL0RpY2sNCuGQpw0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYu b3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aA0KDQo= --_000_MN2PR00MB06861DFFC8C6A909B7AADD9FF5F10MN2PR00MB0686namp_ 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 MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFi LXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5KdXN0 aW4sIGlmIHlvdSB3YW50IHRvIHRha2UgdGhlIGlkZW50aXR5IGNsYWltcyByZXVzZSBhcmd1bWVu dCBvZmYgdGhlIHRhYmxlLCBwdWJsaXNoIGEgbmV3IGRyYWZ0IG9mIGRyYWZ0LXJpY2hlci10cmFu c2FjdGlvbmFsLWF1dGh6IGluIHdoaWNoIHlvdSBhZGQgc29tZXRoaW5nIGxpa2UgdGhpcyBsYW5n dWFnZSB0byB0aGUgQ2xhaW1zIHNlY3Rpb24gYXQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hl ci10cmFuc2FjdGlvbmFsLWF1dGh6LTA2I3NlY3Rpb24tMi43Ij5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDYjc2VjdGlvbi0yLjc8 L2E+OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDIwNjAiPlRoZSByZXF1ZXN0ZWQgY2xhaW0gbmFtZXMgaGVyZSBhbmQgdGhvc2UgaW4gdGhl IGNvcnJlc3BvbmRpbmcgcmVzcG9uc2UgYXJlIGludGVuZGVkIHRvIGNvbWUgZnJvbSB0aGUgSUFO QSDigJxKU09OIFdlYiBUb2tlbiBDbGFpbXPigJ0gUmVnaXN0cnkgW0lBTkEuSldULkNsYWltc10u Jm5ic3A7IFdoZXJlIHRoaXMgc3BlY2lmaWNhdGlvbg0KIGRlZmluZXMgbmV3IGNsYWltcywgaXQg cmVnaXN0ZXJzIHRoZW0gaW4gdGhpcyByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPkFuZCB0aGVuIHBvcHVsYXRlIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNl Y3Rpb24gb2YgdGhlIG5ldyBkcmFmdCB0byByZWdpc3RlciBuZXcgY2xhaW1zIHRoYXQgdGhlIGRv Y3VtZW50IHVzZXMgdGhhdCBhcmUgbm90IGFscmVhZHkgcmVnaXN0ZXJlZCwgc3VjaCBhcyDigJxz dWJqZWN04oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SeKAmWxsIGJl IHdhdGNoaW5nIHRvIHNlZSB3aGV0aGVyIHlvdSBkbyB0aGlzIGFzIGEgc3RhdGVtZW50IG9mIGlu dGVudCB0byByZXVzZSBvZiBleGlzdGluZyBpZGVudGl0eSBjbGFpbXMgb3Igd2hldGhlciB5b3Ug Y2hvb3NlIG5vdCB0by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlAuUy4mbmJzcDsgVGhlIElBTkEgSldU IENsYWltcyBSZWdpc3RyeQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5bSUFO QS5KV1QuQ2xhaW1zXTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+IGlzIG9mIGNv dXJzZSBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0LyI+ aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0LzwvYT4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSnVzdGluIFJpY2hlciAm bHQ7anJpY2hlckBtaXQuZWR1Jmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2gg MjQsIDIwMjAgNzo0OCBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdHhhdXRoQGlldGYub3JnOyBE aWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtUeGF1dGhdIFhZWiB2cyBYQXV0aCAtIDUgZGlmZmVyZW5jZXM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlR3byBxdWljayBub3RlcyBJIG1pc3NlZDo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAyNCwgMjAy MCwgYXQgOTo0MSBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJA bWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1lbnRpb25lZCB0aGlzIG9uIHRoZSBjYWxs IHllc3RlcmRheSwgYnV0IHRoaXMgaXMgYW4gaW5jcmVkaWJseSB3ZWFrIGFyZ3VtZW50IHRvIHBp Y2sgb25lIGRyYWZ0IG92ZXIgYW5vdGhlciwgZXNwZWNpYWxseSBhdCBzdWNoIGFuIGVhcmx5IHN0 YWdlLiBJIHdvdWxkIGNvbnNpZGVyIGV2ZXJ5dGhpbmcgWFlaIG1hbGxlYWJsZSwgZXNwZWNpYWxs eSB3aGF0IHRoZSBmaWVsZHMgZ2V0IG5hbWVkLiBJdOKAmXMgc2hvcnQNCiBzaWdodGVkIHRvIHRo cm93IG91dCBhbiBlbnRpcmUgc3BlY2lmaWNhdGlvbiBiZWNhdXNlIG9mIHRoZSBuYW1lcyBvZiBm aWVsZHMgdGhhdCB3ZXJlIGFkZGVkIHZlcnkgcmVjZW50bHkgdG8gdGhlIGRyYWZ0LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3RoZXIgd29y ZHMsIEkgdGhpbmsgaXTigJlzIHRvbyBlYXJseSB0byBqdWRnZSBiYXNlZCBvbiB0aGluZ3MgbGlr ZSB0aGlzLCBhbmQgaXQgc2hvd3MgYmxpbmRuZXNzIHRvIHRoZSByZXN0IG9mIHRoZSBkcmFmdC4g SXTigJlzIHRydWUgdGhhdCBEaWNrIGFuZCBJIGhhdmUgdGFrZW4gYSB2ZXJ5IGRpZmZlcmVudCBh cHByb2FjaCB0byByZS11c2UsIGJ1dCBib3RoIGhhdmUgcmUtdXNlLiAmbmJzcDtYWVogZG9lcyBy ZS11c2UNCiBtYW55IGVsZW1lbnRzIGZyb20gT0F1dGggMiwgT0lEQywgYW5kIFhZWiwgYnV0IHRo ZXnigJl2ZSBiZWVuIHRyYW5zbGF0ZWQgaW50byBhIHN5c3RlbSB0aGF04oCZcyBpbnRlcm5hbGx5 IGNvbnNpc3RlbnQgaW4gYSB3YXkgdGhhdCB0aGUgc291cmNlIG1hdGVyaWFsIGlzIG5vdC4gRGlj ayBoYXMgc2FpZCBzZXZlcmFsIHRpbWVzIHRoYXQg4oCcWFlaIGRvZXNu4oCZdCB1c2UgT0F1dGgg MiBzY29wZXPigJ0gd2hpY2ggaXMgYmxhdGFudGx5DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uZSBjb3JyZWN0aW9uIOKAlCBJIG1lYW50IHRvIHNheSDigJxPQXV0aCAyLCBPSURDLCBh bmQgb3RoZXJzIGxpa2UgVU1BLOKAnS4gOik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5vdCB0cnVlIOKAlCB3ZSBkZXNpZ25lZCB0 aGUgc3lzdGVtIGV4cGxpY2l0bHkgc28gdGhhdCB5b3UgY291bGQgZG8gdGhhdC4gSG93ZXZlciwg d2UgZGlkbuKAmXQganVzdCBwdXQgaW4gYSBmaWVsZCBsYWJlbGVkIOKAnG9hdXRoX3Njb3Blc+KA nSBiZWNhdXNlLCBhcyB3ZeKAmXZlIGZvdW5kIGluIGRlZmluaW5nIFJBUiBpbiBPQXV0aCAyLCBp dCBnZXRzIGNvbXBsaWNhdGVkIHF1aWNrbHkgdHJ5aW5nIHRvIGNvbWJpbmUgdGhlbQ0KIGlmIHlv dSBoYXZlIGRpZmZlcmVudCBsYXllcnMgb2Ygc2VtYW50aWNzIHdpdGhpbiB0aGUgcHJvdG9jb2wu IFhZWiBwdXRzIHRoZSBzY29wZSBzdHlsZSByZXF1ZXN0cyBhdCB0aGUgc2FtZSBsZXZlbCBhcyB0 aGUgcmljaCByZXF1ZXN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U28gbGV04oCZcyBzYXkgeW91IHdhbnRlZCB0byBkbyBhIGZ1bGwgbWFw cGluZyBvZiBhbiBPSURDIHJlcXVlc3QsIGp1c3Qgc3dhcHBpbmcgb3V0IE9BdXRoIDIgZm9yIFhZ WiwgaXTigJlkIGxvb2sgc29tZXRoaW5nIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ezxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90O2tleXMm cXVvdDs6ICZxdW90O2NsaWVudC1pZC0xMjM0NTU2JnF1b3Q7LDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZxdW90O3Jlc291cmNlcyZx dW90OzogWyZxdW90O29wZW5pZCZxdW90OywgJnF1b3Q7cHJvZmlsZSZxdW90OywgJnF1b3Q7ZW1h aWwmcXVvdDssICZxdW90O3Bob25lJnF1b3Q7LCAmcXVvdDthZGRyZXNzJnF1b3Q7XSw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmcXVv dDtjbGFpbXMmcXVvdDs6IHsgJnF1b3Q7b2lkY19pZF90b2tlbiZxdW90OzogdHJ1ZSB9LDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZx dW90O2ludGVyYWN0JnF1b3Q7OiB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+JnF1b3Q7cmVkaXJlY3QmcXVvdDs6IHRydWUsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+JnF1b3Q7Y2FsbGFiYWNr JnF1b3Q7OiB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQomcXVvdDt1cmwmcXVvdDs6ICZxdW90OzxhIGhy ZWY9Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUvcmVkaXJlY3RfdXJpIj5odHRwczovL2NsaWVudC5l eGFtcGxlL3JlZGlyZWN0X3VyaTwvYT4mcXVvdDssPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQomcXVvdDtu b25jZSZxdW90OzogJnF1b3Q7MTIzMzQ1NSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPn08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3b3VsZCBnZXQgeW91IGJh Y2sgYW4gT0lEQyBpZCB0b2tlbiBhbmQgYWNjZXNzIHRva2VuIHdpdGggdGhlIE9JREMgc2NvcGVz IHRpZWQgdG8gdGhlIHNlcnZlcuKAmXMgVXNlckluZm8gRW5kcG9pbnQuIEJ1dCBhcyBJ4oCZdmUg YmVlbiBzYXlpbmcsIEkgZG9u4oCZdCB0aGluayBpdOKAmXMgd2l0aGluIHRoZSBwdXJ2aWV3IG9m IHRoaXMgd29ya2luZyBncm91cCB0byBkZWZpbmUgdGhhdCBsZXZlbCBvZiBkZXRhaWwuDQogV2hh dCB3ZSBzaG91bGQgZG8gaXMgZGVmaW5lIHdoYXQgdGhlIOKAnHJlc291cmNlc+KAnSBmaWVsZCBt ZWFucywgd2hhdCB0aGUg4oCcY2xhaW1z4oCdIGZpZWxkIG1lYW5zLCBhbmQgcHV0IGEgZmV3IGJ1 Y2tldHMgaW4gdGhlcmUgZm9yIGNvbW1vbiBpZGVudGlmaWVycyBhbmQgYXNzZXJ0aW9ucyBzbyB0 aGF0IHBlb3BsZSBkbyB0aGluZ3MgdGhlIHNhbWUgd2F5LiBBbmQgSeKAmWxsIHJlcGVhdCB0aGF0 IEkgd291bGQgcGVyc29uYWxseSBwcmVmZXIgdGhlIHNpbXBsZQ0KIGlkZW50aXR5IG1hcHBpbmcg bGF5ZXIgYmUgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBmcm9tIHRoZSBjb3JlIGRlbGVnYXRpb24g cHJvdG9jb2wg4oCUIGJ1dCB0aGF04oCZcyBhIG1hdHRlciBmb3IgdGhlIFdHIHRvIGRlY2lkZS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SeKAmWxsIGFsc28gcmVwZWF0IG15IGFyZ3VtZW50IHRoYXQgSSBkb27igJl0IHRoaW5rIHdl IHNob3VsZCBqdXN0IGJsaW5kbHkgcmUtdXNlIE9JREPigJlzIG5hbWVzIGZvciB0aGluZ3MsIGJ1 dCB0aGF0IGlzIG5vdCBtZSBzYXlpbmcgdGhhdCB3ZSBzaG91bGQsIG9mIG5lY2Vzc2l0eSwgaW52 ZW50IG5ldyB0aGluZ3MgZW50aXJlbHkgJnF1b3Q7anVzdCBiZWNhdXNl4oCdLiBFdmVyeSBjaG9p Y2Ugd2UgbWFrZSwgaW5jbHVkaW5nIHdoYXQNCiB3ZSBuYW1lIGZpZWxkcywgbmVlZHMgdG8gaGF2 ZSBhIGdvb2QgcmVhc29uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgaWYgdGhlIFdHIGRvZXMgZW5kIHVwIGNyZWF0aW5nIG5l dyBuYW1lcyBmb3Igc29tZSB0aGluZ3M/IFRoYXTigJlzIG5vdCB0aGUgZW5kIG9mIHRoZSB3b3Js ZC4gV2hlbiB3ZSB3ZXJlIHdvcmtpbmcgb24gT0lEQywgdGhlcmUgd2FzIGFuIG9wcG9ydHVuaXR5 IHRvIHJlLXVzZSBmaWVsZCBuYW1lcyBmcm9tIExEQVAgKHNwZWNpZmljYWxseSwgdG8gdXNlIGlu ZXRPcmdQZXJzb24gYW5kL29yIGVkdU9yZ1BlcnNvbg0KIGFzIHRoZSBzY2hlbWEpLCBidXQgYXMg eW91IChNaWtlKSBrbm93LCB3ZSBkZWNpZGVkIG5vdCB0bywgYW5kIHRoZSB3b3JsZCBpcyBPSyBm b3IgdGhhdCBldmVuIHRob3VnaCBpdCBtZWFudCBwZW9wbGUgaGFkIHRvIHdyaXRlIGEgc2ltcGxl IHRyYW5zbGF0b3Igd2hlbiB3cmFwcGluZyB0aGVpciBMREFQIHNlcnZlcnMgd2l0aCBPSURDIGNh cGFiaWxpdGllcyAoYW5kIGNvbXBsYWluZWQgYWJvdXQgaXQgYXQgdGhlIHRpbWUpLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZS11 c2UgZG9lcyBub3QganVzdCBtZWFuIGNvcHlpbmcuIEl0IG1lYW5zIGV4YW1pbmluZyB3aGF0IGlz IHRoZXJlIGFuZCBwdWxsaW5nIHRoZSBiZXN0IGZyb20gaXQg4oCUIGFuZCB0aGF0IGlzIGdvaW5n IHRvIGluY2x1ZGUgc291cmNlcyBiZXlvbmQgT0F1dGgyIGFuZCBPSURDLiBBdCB0aGlzIHBvaW50 IHdlIHNob3VsZCBiZSBsb29raW5nIGF0IHdoYXQgZmVhdHVyZXMgd2UgbGlrZSBmcm9tIHRoZSBl bnRpcmUNCiBlY29zeXN0ZW0sIGluY2x1ZGluZyB0aGUgdHdvIHByb3Bvc2VkIGRyYWZ0cywgYW5k IGRlY2lkZSB3aGF0IHdlIHdhbnQgdG8gYnJpbmcgZm9yd2FyZCBpbnRvIFR4QXV0aC4gQW5kIGlu IHRlcm1zIG9mIGZsZXhpYmlsaXR5LCBzdGFiaWxpdHksIHNpbXBsaWNpdHksIGFuZCBjb25zaXN0 ZW5jeSwgSSBiZWxpZXZlIHRoYXQgWFlaIG1ha2VzIGEgbXVjaCBzdHJvbmdlciBiYXNlIGZvciBi dWlsZGluZyBvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGFuIGFk ZGl0aW9uIOKAlCBpZiB5b3Ugd2FudCB0byBqdXN0IGtlZXAgdXNpbmcgT0F1dGggMiBhbmQgYmFj ayBwb3J0IGZ1bmN0aW9uYWxpdHkgdG8gT0F1dGgyIGluIGEgY29tcGF0aWJsZSB3YXksIHRoYXQg d29yayBzaG91bGQgYmUgZG9uZSBpbiB0aGUgT0F1dGggMiB3b3JraW5nIGdyb3VwLiBIZXJlLCB3 ZeKAmXJlIHRyeWluZyB0byBtb3ZlIGZvcndhcmQsIG5vdCBqdXN0IHJlc3Qgb24gd2hhdOKAmXMg YmVlbg0KIGRvbmUuIFRoYXTigJlzIG5vdCBhbiBhcmd1bWVudCB0byBpbnZlbnQgZXZlcnl0aGlu ZyBmcm9tIHdob2xlIGNsb3RoLCBpdOKAmXMgYW4gYXJndW1lbnQgdG8gYnVpbGQgdGhpbmdzIGJl dHRlciB3aGVyZXZlciB3ZSBjYW4uIEnigJltIHJlYWxseSBnbGFkIHRvIGhhdmUgdGhlIGRlZXAg ZXhwZXJpZW5jZSBvZiBzbyBtYW55IHBhcnRpY2lwYW50cyBmZWVkaW5nIGludG8gdGhpcyBncm91 cCBmb3IgZXhhY3RseSB0aGF0IHJlYXNvbiE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1 c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1hciAyMywgMjAyMCwgYXQgMzo1MyBQTSwgTWlrZSBKb25lcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSB3b3VsZCBw cmVmZXIgWEF1dGg8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5hcyBhIHN0YXJ0aW5nIHBvaW50IG92ZXIgWFlaIGJlY2F1c2Ug WEF1dGggaXMgY2xlYXJseSB0cnlpbmcgdG8gcmV1c2UNCiBleGlzdGluZyBpZGVudGl0eSByZXBy ZXNlbnRhdGlvbnMsIHdoZXJlYXMgWFlaIGlzIGNyZWF0aW5nIGEgbmV3IG9uZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PllvdSBjYW4gc2VlIFhBdXRo4oCZcyByZXVzZSwgZm9yIGluc3RhbmNlLCBhdDxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZHQteGF1dGgtcHJvdG9jb2wtMDYjc2VjdGlvbi00 LjYuNiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmR0LXhhdXRoLXByb3Rv Y29sLTA2I3NlY3Rpb24tNC42LjY8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+WW91IGNhbiBzZWUgWFla4oCZcyBp bnZlbnRpb24gb2YgYSBuZXcgaWRlbnRpdHkgc2NoZW1hIGF0PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wNiNzZWN0aW9uLTIuNyI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1 dGh6LTA2I3NlY3Rpb24tMi43PC9hPi4mbmJzcDsNCiBZZXMsIGl04oCZcyBzaW1pbGFyIHRvIHNv bWUgb3RoZXJzIGJ1dCBub3QgdGhlIHNhbWUsIGFuZCByYXRoZXIgdGhhbiByZXVzaW5nIGV4aXN0 aW5nIHJlZ2lzdGVyZWQgY2xhaW1zLCBpdOKAmXMgY3JlYXRpbmcgaXRzIG93biB1bmlxdWUgc2V0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2Vz QGlldGYub3JnIj50eGF1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+RGljaw0KIEhhcmR0 PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkZyaWRheSwgTWFyY2ggMjAsIDIwMjAgMToxOCBQTTxicj4NCjxiPlRvOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnR4YXV0aEBpZXRmLm9yZyI+dHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SnVzdGlu IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQu ZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W0VYVEVSTkFMXSBSZTogW1R4YXV0aF0gWFlaIHZzIFhB dXRoIC0gNSBkaWZmZXJlbmNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BQ1RJT04gUkVNSU5ERVI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UGxlYXNlIHdlaWdoIGluIHdpdGggeW91ciBwcmVm ZXJlbmNlLCB5b3VyIHJhdGlvbmFsZSwgYXMgd2VsbCBhcyBhbnkgcHJvcyBhbmQgY29ucyBub3Qg ZGVzY3JpYmVkLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pllhcm9uIGFuZCBJIHdlcmUgaG9wZWZ1bCZuYnNwO3RoYXQgd2Ugd291bGQgZ2V0IG1vcmUgZmVl ZGJhY2sgb24gdGhlc2UgdG9waWNzLCBhcyBpdCB3b3VsZCBoZWxwIGRldGVybWluZSBpZiBlaXRo ZXIgdGhlIFhZWiBvciBYQXV0aCBkb2N1bWVudHMgYXJlIHJvdWdobHkgYWxpZ25lZCB3aXRoIHRo ZSBjb25zZW5zdXMgZGlyZWN0aW9uIG9mIHRoZSBncm91cCBzbyB0aGF0IHdlIGhhdmUgYSBzdGFy dGluZyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwgTk9UIGJlIGFibGUgdG8g ZG8gaHVtcyBpbiB0aGUgQm9GIC4uLiBzbyB3ZSB3aWxsIG5vdCBiZSBhYmxlIHRvIHVzZSB0aGF0 IHRvIGp1ZGdlIHJvdWdoIGNvbnNlbnN1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L0Rp Y2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAxNiwgMjAy MCBhdCA0OjA0IFBNIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gZXZl cnlvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdGluIGFuZCBJIGhhdmUgaGFkIHNvbWUgZW1haWxz IGJhY2sgYW5kIGZvcnRoIGNvbXBhcmluZyBhbmQgY29udHJhc3RpbmcgWFlaIGFuZCBYQXV0aC4g SSdtIGdvaW5nIHRvIHBvc3QgYSBtZXNzYWdlIGZvciBlYWNoIG9mIHRoZSBtYWpvciBwb2ludHMs IHdpdGggSnVzdGluJ3MgcmF0aW9uYWxlIGFuZCBteSByYXRpb25hbGUgZm9yIG91ciByZXNwZWN0 aXZlIGRlc2lnbiBkZWNpc2lvbnMuJm5ic3A7RmVlbCBmcmVlDQogdG8gYXNrIGNsYXJpZnlpbmcg cXVlc3Rpb25zIGluIHRob3NlIHRocmVhZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PlBsZWFzZSB3ZWlnaCBpbiB3aXRoIHlvdXIgcHJlZmVyZW5jZSwgeW91ciByYXRpb25hbGUsIGFz IHdlbGwgYXMgYW55IHByb3MgYW5kIGNvbnMgbm90IGRlc2NyaWJlZC48L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd291bGQgbGlrZSB0byBnZXQgYSBzZW5zZSBmb3Ig dGhlIGdyb3VwJ3Mgdmlld3Mgb24gdGhlc2UgdG9waWNzIGZvciB0aGUgdmlydHVhbCBCb0YgaW4g YSB3ZWVrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbGF0ZXN0IGRyYWZ0cyBhcmU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlhZWjombmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDYiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRy YW5zYWN0aW9uYWwtYXV0aHotMDY8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlhBdXRo OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkdC14 YXV0aC1wcm90b2NvbC0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1oYXJkdC14YXV0aC1wcm90b2NvbC0wNTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vRGljazxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBz dHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3Jj PSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMD0mYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9OTljOGFmNDQtMjAx Yy00NDA3LWI5NjAtYmFiZjE5NzY4MTRjIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR00MB06861DFFC8C6A909B7AADD9FF5F10MN2PR00MB0686namp_-- From nobody Tue Mar 24 12:12:47 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4843A0CF5 for ; Tue, 24 Mar 2020 12:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 NiYSIo5rcFvw for ; Tue, 24 Mar 2020 12:12:42 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650091.outbound.protection.outlook.com [40.107.65.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 146883A0DA7 for ; Tue, 24 Mar 2020 12:12:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VitnXrWJ4dYsyb35kNLe3I52tbfCQTraphNUN8HlvWM2poyYbt+tPCm2uaGqazFj0omGEUXMA1bRh5bLnqRlsRJkq12aSz4lJGbm2Ckm+CYwgw31+WtbTO14SZe2oeo8KBmrq5BOyTT1SmU/9zHp+B4VcaWravBO9/cZLKW+Al+5DFmzrTj40FoxomemsIgDFxLHyb1fIfT3t9ZIE8lPbxN87/ot4uGFSy/iY6emFKwCrEUmBiuJItV/3YP2+vkTTcp2MTlqVv5tMhccJAUhAoFW+Jy3GDm9ZGZMh0RiUVbWwFlzVwR+2UMdjvpaTzwQHt28Uq84nyVIrDD3E/hbww== 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=pyv+6aMUPBv7u1ILE8DXPYs0wcZqRzsLow2dulENAbY=; b=c38iXdpJCFR/gdypvJw+jdCQ6rOeFgu5/F3PsHnibg1+itcFgVkoayXt4MVHFrZ1TP5T9JUpIO5pkml+ZuE/Dshn4ZEBwAlbenv/g8wHJXvcLvragM0yFiJpJlk4g7OvJ6Jc1izxChhxjvtiZk7QtsMRAFZ7H3OXYh7YBnZQaUSq1Qc/FzHkdbW4yPW8D4UzV5s5vYgYY/I15inq0R9LC0r/bDSFNOIvBwr6pePxlU5AXUuZxCkpzW7kFcoDdOOAM4X93XCqwf+t6XvGdmnCKMvKxQqV/l9ouQTTpLGraaz1RbGFCQsOaaNCxBLmBCYdbngS6PGkd26mf0k8ma7Ueg== 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=pyv+6aMUPBv7u1ILE8DXPYs0wcZqRzsLow2dulENAbY=; b=JFHI4LWD2fQUpdXaByZBzs7g6OrHYleOMZu8Yozad2a7YvHlgeMLnXGebl37nsksYkTAw4jVnJgqj6paVLRKuMxl0Fm9dn4FcYAeXSZAIqPINty2s4ZiUQrZtqwMCXNLBtw1ElQIAq5ELRxIDq4jcqCMRCG1Fe+urLOMWw4hElw= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (10.255.224.141) by MN2PR00MB0461.namprd00.prod.outlook.com (20.178.240.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2877.0; Tue, 24 Mar 2020 19:12:39 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2097:d2a0:b135:ee4d]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::2097:d2a0:b135:ee4d%8]) with mapi id 15.20.2895.000; Tue, 24 Mar 2020 19:12:39 +0000 From: Mike Jones To: Justin Richer , Benjamin Kaduk CC: "txauth@ietf.org" Thread-Topic: [Txauth] brainstorming about "layer session management on top of txauth" Thread-Index: AdYCECuNvtFr6OFWTBmOXPNBgMaBsg== Date: Tue, 24 Mar 2020 19:12:39 +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_ActionId=cf4be134-1ce0-41b1-b7d6-000098dad599; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-03-24T18:56:36Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 683aecca-9736-4f20-6d3c-08d7d027520a x-ms-traffictypediagnostic: MN2PR00MB0461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10001)(10019020)(4636009)(396003)(376002)(136003)(39860400002)(346002)(366004)(86362001)(66476007)(66556008)(64756008)(66446008)(10290500003)(8990500004)(316002)(110136005)(66946007)(4326008)(76116006)(26005)(55016002)(71200400001)(9686003)(81166006)(81156014)(8676002)(2906002)(5660300002)(52536014)(8936002)(53546011)(33656002)(7696005)(6506007)(478600001)(186003)(966005); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ytCUcuctiSfU7u/nkgo+9dhzbcWbqP1fRDkt6BDX8G22boWPNw4H8ynN7EdTHm30G0lzElAE69/Tq1bljY3ORTPNsrZnsX/vFLPmOrFCE56cIi8LB7NkkzhJgmq3mcCZvtOs70sOCs9qExnYr8NXIQCR/CxNkzkNKUuDwwjh4wR9IkRcwWoUGfQumOo7QbKm6PTCd8qviis5vXZeVKFVXKdYxgSlOowlezYSA+IxYozwxrOJ8cYDMqA13WRqdZmB9tisjtapdlsNEsOGXveyda0Zqtk2JtZ7723y0RftO/uwq3D5lH15s+kw78f+ulkkAIE1UFPv4oxvBhlsN7af+Su4/oN59FN2G9s+ra5hqbqNglozn3Tc5LKqeKOT2noZXBBzBJ+LBsPWKX/KjI4vy6CXGqqWfEwA5rj4Xd8RldYWoF5yh34PoVSt/FcsXKtMyWra+6vjUYl/eE6IXaRSWmtWSHq+i6J23z7BGowtZ4kGRYS8MyZA82TYf49fY2DFBXq5+QW9hUmBGxAnJTjTWlmEb+6Zvx+6dNqEKKu8czg8uMdXHVVRW7O8nys/8QBxXr3dZARDVDfuoKszlO3xEg== x-ms-exchange-antispam-messagedata: E6G6HNrsx1NYOg9Joq0yy6sKqNq9KZ2kRpY1KydBa7coEsms0zTGek9aotdSkV8114N5K4bgjdD/87NSrlvZoN6BqXR7Dnp7vvvhojHNwB1Yd2sdptSNdRKh6zTYFB+3Oyox9toJRovCzPYAwFPupw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 683aecca-9736-4f20-6d3c-08d7d027520a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 19:12:39.4075 (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: wdEzZ9azgjifAuyTOlxEu/qc4W9TTFBXH+P/0VQOW7y1J65AC4+eXPbeE3IZ3xxO0LiUcyfZtlZy8XJLKGoWQQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0461 Archived-At: Subject: Re: [Txauth] brainstorming about "layer session management on top of txauth" X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 19:12:45 -0000 SSBhZ3JlZSB0aGF0IHRoZXJlIGhhcyB0byBiZSBhIHNwYWNlIGZvciBhZHZhbmNlZCAoYW5kIHNp bXBsZSkgaWRlbnRpdHkgY29uY2VwdHMgb24gdG9wIG9mIFR4QXV0aCwgaW5jbHVkaW5nIGxvZ2dl ZC1pbiBzZXNzaW9ucywgd2hpY2ggY2FuIGJlIHJlZnJlc2hlZCB0aHJvdWdoIG9uZ29pbmcgdXNl IGFuZCBjYW4gYmUgbG9nZ2VkIG91dC4gIEFuc3dlcmluZyBCZW4ncyBxdWVzdGlvbiwgSSBhZ3Jl ZSB0aGF0IHRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgYSB3YXkgdG8gbGF5ZXIgInRlbGwgbWUgd2hl biB0aGUgdXNlciB3YW50cyB0byBsb2cgb3V0IiBub3RpZmljYXRpb25zLiAgQXMgSnVzdGluIHNh eXMsIGFuZCBhcyB3ZSBsZWFybmVkIGZyb20gdGhlIFNBTUwgZXhwZXJpZW5jZSwgZGlmZmVyZW50 IHVzZSBjYXNlcyBtYXkgcmVxdWlyZSBkaWZmZXJlbnQgc3VjaCBraW5kcyBvZiBub3RpZmljYXRp b25zLCBmb3IgaW5zdGFuY2UsIHNvbWUgb3ZlciB0aGUgZnJvbnQgY2hhbm5lbCBhbmQgc29tZSBp biB0aGUgYmFjayBjaGFubmVsLiAgQm90aCB0aGUgU0FNTCBhbmQgT3BlbklEIENvbm5lY3QgZXhw ZXJpZW5jZXMgcHJvdmlkZSBkYXRhIHBvaW50cyB0aGF0IHRoZXJlJ3Mgbm90IGEgb25lLXNpemUt Zml0cy1hbGwgbG9nb3V0IG1lY2hhbmlzbSBvbiB0aGUgV2ViIGFzIHdlIGtub3cgaXQgdG9kYXku DQoNClRoZSBzYW1lIGtpbmQgb2YgbGF5ZXJpbmcgc2hvdWxkIGFsc28gYXBwbHkgdG8gbG9naW4u ICBTb21lIGF1dGhvcml6YXRpb24gcmVxdWVzdHMgYXJlIGFsc28gYXV0aGVudGljYXRpb24gKGxv Z2luKSByZXF1ZXN0cyBhbmQgc29tZSBhcmUgbm90LiAgVGhlcmUgbmVlZHMgdG8gYmUgYSBjbGVh ciBtZWNoYW5pc20gaW4gdGhlIHJlcXVlc3QgZm9yIGluZGljYXRpbmcgd2hpY2ggaXMgd2hpY2gu ICBPcGVuSUQgQ29ubmVjdCBzaWduYWxlZCB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3Qg d2FzIGFsc28gdG8gcGVyZm9ybSBhIGxvZ2luIGJ5IGluY2x1ZGluZyBhbiAib3BlbmlkIiBzY29w ZSB2YWx1ZS4gIE90aGVyIHN5bnRheGVzIHdvdWxkIGFsc28gYmUgZmluZS4NCg0KVGhlIGtleSBw b2ludCBpcyB0aGF0LCBpZiB0aGUgVHhBdXRoIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgYXJlIGV4 dGVuc2libGUsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBkZWZpbmUgYm90aCB0aGUgbG9naW4g YW5kIGxvZ291dCBzeW50YXhlcyBhbmQgc2VtYW50aWNzIHVzaW5nIHRoZXNlIGV4dGVuc2lvbiBt ZWNoYW5pc21zIC0gcHJvYmFibHkgaW4gZGlzdGluY3Qgc3BlY2lmaWNhdGlvbnMgZnJvbSB0aGUg VHhBdXRoIGNvcmUuICBUeEF1dGggY2FuIGJlIGRlc2lnbmVkIHdpdGggdGhlc2UgcG9zc2liaWxp dGllcyBpbiBtaW5kIGJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiB0aGF0IHRoZXJlJ3MgYSBjb21wZWxs aW5nIGFyZ3VtZW50IHRvIGluY2x1ZGUgdGhlbSB0aGUgY29yZSBzcGVjLg0KDQpQYXJhcGhyYXNp bmcgQmVuLCBpdCBzaG91bGQgYmUgc3RyYWlnaHRmb3J3YXJkIHRvICJsYXllciBpZGVudGl0eSBt YW5hZ2VtZW50IG9uIHRvcCBvZiB0eGF1dGgiLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIEp1c3RpbiBSaWNoZXINClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI0LCAyMDIw IDY6NDcgQU0NClRvOiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtAbWl0LmVkdT4NCkNjOiB0eGF1dGhA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBicmFpbnN0b3JtaW5nIGFib3V0ICJsYXll ciBzZXNzaW9uIG1hbmFnZW1lbnQgb24gdG9wIG9mIHR4YXV0aCINCg0KSSBhZ3JlZSB0aGF0IHRo ZSBraW5kIG9mIGlkZW50aXR5IGluZm8gdGhhdCB3ZeKAmXJlIGxvb2tpbmcgYXQgTG9naW4gZXZl bnRzIGFyZSBwcmV0dHkgd2VsbCB1bmRlcnN0b29kIGFuZCBoYXZlIGJlZW4gc29sdmVkIHdpdGgg c29tZSBwcmV0dHkgc29saWQgcGF0dGVybnMgZm9yIHllYXJzLiBMb2dvdXQgKGFuZCBzZXNzaW9u IG1hbmFnZW1lbnQgaW4gZ2VuZXJhbCkgdHVybnMgb3V0IHRvIGJlIG11Y2gsIG11Y2gsIG11Y2gg aGFyZGVyLiBJIGRvbuKAmXQgYnV5IHRoZSBhcmd1bWVudCB0aGF0IHRoZXkgYXJlIHJlcXVpcmVk IHRvIGdvIHRvZ2V0aGVyLCBlc3BlY2lhbGx5IGJlY2F1c2UgT0lEQyB3YXMgbm90IHB1Ymxpc2hl ZCB3aXRoIHNlc3Npb24gbWFuYWdlbWVudCBhbmQgbG9nb3V0IGZ1bmN0aW9uYWxpdHkuIFRoZXJl 4oCZcyBhIG5vbi1maW5hbCBkcmFmdCwgYnV0IGl0IHdhcyB3YXMgbGFzdCB1cGRhdGVkIDMgeWVh cnMgYWdvIGFuZCBkb2VzIG5vdCBoYXZlIHdpZGUgYWRvcHRpb24uIA0KDQpSZWdhcmRsZXNzLCBJ IHRoaW5rIHRoYXQgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBzcGFjZSB0byBhZGQgYWR2YW5jZWQg aWRlbnRpdHkgY29uY2VwdHMgb24gdG9wIG9mIFR4QXV0aCDigJQgdGhvdWdoIGxpa2VseSBvdXRz aWRlIG9mIHRoZSBUeEF1dGggd29ya2luZyBncm91cCwgd2Ugc2hvdWxkIGRlc2lnbiB3aXRoIHNv bWUgb2YgdGhpcyBpbiBtaW5kIGFuZCBsZWF2ZSBzcGFjZSBhbmQgc3RydWN0dXJlIGZvciBpdC4N Cg0KQnV0IHRvIHNwaXRiYWxsIGFuIGlkZWEgb24gdG9wIG9mIFhZWiwgSSB0aGluayBpdOKAmXMg YSBzaG9ydCBzdGVwIHRvIGFzayBmb3IgYSBzZXNzaW9uIG1hbmFnZW1lbnQgaGFuZGxlIHRvIGdp dmUgdG8gdGhlIGNsaWVudC4gVGhpcyBpcyBhbiBhcnRpZmFjdCB0aGF0IHRoZSBBUyB3b3VsZCBr bm93IGhvdyB0byBkZXJlZmVyZW5jZSB0byBsZXQgdGhlIGNsaWVudCBwdXNoIGEg4oCcbG9nb3V0 4oCdIGV2ZW50IHRvIHRoZSBBUy4gQnV0IHRoZSBjbGllbnQgY291bGQgYWxzbywgaW4gdGhlIHNh bWUgcmVxdWVzdCwgcmVnaXN0ZXIgYSDigJxsb2dvdXTigJ0gY2FsbGJhY2sgYXQgdGhlIEFTLCB1 c2luZyBzb21lIHZhcmlldHkgb2YgbWVjaGFuaXNtcy4gU28gbWF5YmUgc29tZXRoaW5nIGxpa2Ug dGhpczoNCg0Kew0KICAic2Vzc2lvbiI6IHsNCgkibG9nb3V0X2NhbGxiYWNrIjogew0KCSAgInVy bCI6ICJodHRwczovL2NsaWVudC5leGFtcGxlL2xvZ291dCIsDQoJICAibm9uY2UiOiAiMDk0ODEz NCINCgl9DQogIH0NCn0NCg0KQW5kIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCBzb21ldGhpbmcg bGlrZToNCg0Kew0KICAic2Vzc2lvbl9oYW5kbGUiOiB7DQogIAkidXJsIjogImh0dHBzOi8vc2Vy dmVyLmV4YW1wbGUvbG9nb3V0IiwNCgkiaGFuZGxlIjogIjA5NDgxMzQiLA0KCSJ0eXBlIjogImJl YXJlciINCiAgICB9DQp9DQoNCkJ1dCBhZ2FpbiwgSSBkb27igJl0IHRoaW5rIHRoYXQgdGhpcyBp cyBuZWNlc3NhcnkgZm9yIGEgc2ltcGxlIGxvZ2luIHN5c3RlbSBvciBldmVuIGluIHNjb3BlIGZv ciBUeEF1dGguIElkZW50aXR5IGlzIGluZGVlZCBodWdlLCBidXQgd2UgZG9u4oCZdCBuZWVkIHRv IHNvbHZlIGV2ZXJ5dGhpbmcgaW4gb3JkZXIgdG8gc29sdmUgc29tZXRoaW5nIHVuaXZlcnNhbGx5 IHVzZWZ1bC4NCg0KIOKAlCBKdXN0aW4NCg0KPiBPbiBNYXIgMjMsIDIwMjAsIGF0IDY6MDMgUE0s IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4g DQo+IFdlIHNwZW50IGEgbG9uZyB0aW1lIHRhbGtpbmcgYWJvdXQgd2hhdCB3ZSBtZWFuIGJ5IGlk ZW50aXR5IGFuZCB3aGF0IA0KPiBzaG91bGQgYmUgaW4gc2NvcGUgZm9yIHVzIHRvIGRvIHZzLiBy ZXVzZSwgYW5kIEkgaGFkIGFuIGlkZWEgdGhhdCBJIA0KPiB3YW50ZWQgdG8gZ2V0IHNvbWUgZmVl ZGJhY2sgb24sIHJlbGF0aW5nIHRvIGhvdyB3ZSBtaWdodCBsYXllciANCj4gaWRlbnRpdHkvc2Vz c2lvbi1tYW5hZ2VtZW50IG9uIHRvcCBvZiBYWVouICAoSSBhbSBub3Qgc3VyZSB5ZXQgaWYgaXQg DQo+IHdvdWxkIGFwcGx5IHRvIFhBdXRoIG9yIG5vdC4pDQo+IA0KPiBJZiB3ZSB0YWxrIGFib3V0 IGhvdyBzb21lIG9mIHRoZSBjbGFpbXMgY29udmV5ZWQgZnJvbSBBUyB0byBjbGllbnQgDQo+IHJl bGF0ZSB0byB3aG8gdGhlIHVzZXIgaXMsIGJ1dCBhcyBNaWtlIG5vdGVzIHRoaXMgc3RhcnRzIHRv IGxvb2sgbGlrZSBhICJsb2dpbiINCj4gZXZlbnQsIGFuZCBvbmNlIHlvdSBoYXZlIHRoYXQgeW91 IHdhbnQgdG8ga25vdyBhYm91dCB0aGUgImxvZ291dCIgDQo+IGV2ZW50IGFzIHdlbGwuICBXb3Vs ZCBpdCBiZSBwb3NzaWJsZSB0byBidWlsZCBzb21ldGhpbmcgdGhhdCBoYXMgdGhlIA0KPiBjbGll bnQgYXNrIGZvciBhIHJlc291cmNlIG9mICJ0ZWxsIG1lIHdoZW4gdGhlIHVzZXIgbG9ncyBvdXQi PyAgV2UnZCANCj4gb2YgY291cnNlIG5lZWQgdG8gZGVmaW5lIHNvbWUgd2F5IHRvIGluZGljYXRl IGhvdyB0aGUgQVMgd291bGQgY29udmV5IA0KPiB0aGF0IHRvIHRoZSBjbGllbnQsIGJ1dCBvbiBm aXJzdCBnbGFuY2UgYXQgbGVhc3QgaXQgc2VlbXMgbGlrZSBpdCANCj4gY291bGQgd29yayB0byBs YXllciB0aGUgc2Vzc2lvbi1tYW5hZ2VtZW50IG9uIHRvcCBvZiBjbGFpbXMgd2l0aCANCj4gc2Vt YW50aWNzIGxpa2UgdGhhdC4gIFdoZXRoZXIgdGhlIHJlc3VsdGluZyBzZXQgb2YgY2xhaW1zIHdv dWxkIHN0aWxsIA0KPiBsb29rIHByZXR0eSBpcyBhbm90aGVyIG1hdHRlciwgdGhvdWdoLi4uDQo+ IA0KPiAtQmVuDQo+IA0KPiAtLQ0KPiBUeGF1dGggbWFpbGluZyBsaXN0DQo+IFR4YXV0aEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQot LQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0K From nobody Tue Mar 24 12:17:30 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A63A0C4A for ; Tue, 24 Mar 2020 12:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 oOdUybIV_-g6 for ; Tue, 24 Mar 2020 12:17:25 -0700 (PDT) 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 1D5A33A0C5E for ; Tue, 24 Mar 2020 12:17:24 -0700 (PDT) Received: from [192.168.1.5] (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 02OJHMi6028902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 15:17:23 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 24 Mar 2020 15:17:22 -0400 Cc: Benjamin Kaduk , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1BB3B226-9D8E-49B7-AF8A-95F169B66821@mit.edu> References: To: Mike Jones X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] brainstorming about "layer session management on top of txauth" X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 19:17:29 -0000 I agree that identity claims probably shouldn=E2=80=99t be in the core = spec and have said as much many times. That doesn=E2=80=99t put them out = of scope of the working group, or conversely make them deliverable at = the same time as the core protocol. I have even written the charter text = to cater to that flexibility in enumerating the deliverables for = identity separately.=20 - Justin > On Mar 24, 2020, at 3:12 PM, Mike Jones = wrote: >=20 > I agree that there has to be a space for advanced (and simple) = identity concepts on top of TxAuth, including logged-in sessions, which = can be refreshed through ongoing use and can be logged out. Answering = Ben's question, I agree that there would need to be a way to layer "tell = me when the user wants to log out" notifications. As Justin says, and = as we learned from the SAML experience, different use cases may require = different such kinds of notifications, for instance, some over the front = channel and some in the back channel. Both the SAML and OpenID Connect = experiences provide data points that there's not a one-size-fits-all = logout mechanism on the Web as we know it today. >=20 > The same kind of layering should also apply to login. Some = authorization requests are also authentication (login) requests and some = are not. There needs to be a clear mechanism in the request for = indicating which is which. OpenID Connect signaled that the = authorization request was also to perform a login by including an = "openid" scope value. Other syntaxes would also be fine. >=20 > The key point is that, if the TxAuth requests and responses are = extensible, it should be possible to define both the login and logout = syntaxes and semantics using these extension mechanisms - probably in = distinct specifications from the TxAuth core. TxAuth can be designed = with these possibilities in mind but that doesn't mean that there's a = compelling argument to include them the core spec. >=20 > Paraphrasing Ben, it should be straightforward to "layer identity = management on top of txauth". >=20 > -- Mike >=20 > -----Original Message----- > From: Txauth On Behalf Of Justin Richer > Sent: Tuesday, March 24, 2020 6:47 AM > To: Benjamin Kaduk > Cc: txauth@ietf.org > Subject: Re: [Txauth] brainstorming about "layer session management on = top of txauth" >=20 > I agree that the kind of identity info that we=E2=80=99re looking at = Login events are pretty well understood and have been solved with some = pretty solid patterns for years. Logout (and session management in = general) turns out to be much, much, much harder. I don=E2=80=99t buy = the argument that they are required to go together, especially because = OIDC was not published with session management and logout functionality. = There=E2=80=99s a non-final draft, but it was was last updated 3 years = ago and does not have wide adoption.=20 >=20 > Regardless, I think that there is going to be a space to add advanced = identity concepts on top of TxAuth =E2=80=94 though likely outside of = the TxAuth working group, we should design with some of this in mind and = leave space and structure for it. >=20 > But to spitball an idea on top of XYZ, I think it=E2=80=99s a short = step to ask for a session management handle to give to the client. This = is an artifact that the AS would know how to dereference to let the = client push a =E2=80=9Clogout=E2=80=9D event to the AS. But the client = could also, in the same request, register a =E2=80=9Clogout=E2=80=9D = callback at the AS, using some variety of mechanisms. So maybe something = like this: >=20 > { > "session": { > "logout_callback": { > "url": "https://client.example/logout", > "nonce": "0948134" > } > } > } >=20 > And the server responds with something like: >=20 > { > "session_handle": { > "url": "https://server.example/logout", > "handle": "0948134", > "type": "bearer" > } > } >=20 > But again, I don=E2=80=99t think that this is necessary for a simple = login system or even in scope for TxAuth. Identity is indeed huge, but = we don=E2=80=99t need to solve everything in order to solve something = universally useful. >=20 > =E2=80=94 Justin >=20 >> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk wrote: >>=20 >> Hi all, >>=20 >> We spent a long time talking about what we mean by identity and what=20= >> should be in scope for us to do vs. reuse, and I had an idea that I=20= >> wanted to get some feedback on, relating to how we might layer=20 >> identity/session-management on top of XYZ. (I am not sure yet if it=20= >> would apply to XAuth or not.) >>=20 >> If we talk about how some of the claims conveyed from AS to client=20 >> relate to who the user is, but as Mike notes this starts to look like = a "login" >> event, and once you have that you want to know about the "logout"=20 >> event as well. Would it be possible to build something that has the=20= >> client ask for a resource of "tell me when the user logs out"? We'd=20= >> of course need to define some way to indicate how the AS would convey=20= >> that to the client, but on first glance at least it seems like it=20 >> could work to layer the session-management on top of claims with=20 >> semantics like that. Whether the resulting set of claims would still=20= >> look pretty is another matter, though... >>=20 >> -Ben >>=20 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Mar 24 12:42:31 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334D23A0D47 for ; Tue, 24 Mar 2020 12:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, 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 QOq2ULQZFwUM for ; Tue, 24 Mar 2020 12:42:19 -0700 (PDT) Received: from mail.alkaline-solutions.com (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 2D6A03A1258 for ; Tue, 24 Mar 2020 12:42:05 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 60AA63853E6; Tue, 24 Mar 2020 19:41:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1585078917; 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=HvfGp0gj7ad/EQ+kFRraLhzZYOhsq4mPrOZnsJsQpss=; b=Zhlr1xA/dogtioiUTf+zRUlNeV/4qWd6vkd+IPRyc7hwCcgTgXjhJfEIeyNKWnhv6R25oA fEvNax4bWhgsZZDcZZTwWEfCbyaG2X+xi+n8IV2UUizsbJpogOnWRGi8D3DJoOqv/quzDm ftbLur6yv+Pk/ovcrtN1aPkaWLKFXYE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 From: David Waite In-Reply-To: Date: Tue, 24 Mar 2020 13:41:55 -0600 Cc: Leif Johansson , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Jones ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1585078918; 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=HvfGp0gj7ad/EQ+kFRraLhzZYOhsq4mPrOZnsJsQpss=; b=UJunAWH3IGSgZTRgwhNNGpF+oGmnDhKnScL3JtL6kq9ePljSvSDk/AgmJXFq6yvnkazQ7E N2+wXJ1pk+xgsrYddRrZ/AzCxcA8MF75syRtNOxzvyxPZu/Yh3NlrVUMhtJzSNMo2Sutja iyDhhu8KPzQbEdKhjCXQ0g1T/BJsUHs= ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1585078918; a=rsa-sha256; cv=none; b=dccUY+Ux2Ub1jo6XUHUffjJ9GML9qCZWW9PykcdNT2KZU+agnWgDwefma6s2s4DwrGxO5x EifHGyq44niEqXqQuFomFLrpcjdu75OanlB44RsC1cl4noZV4xSWqDBqmDR8mHZuf5nFsR /RVEckQShSXclXzzN9BrbG0uCK/vryM= ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 19:42:28 -0000 > On Mar 24, 2020, at 12:35 PM, Mike Jones = wrote: >=20 > Taking Leif's comment seriously, for the record, here's some of the = historical context on why OpenID Connect created new short JSON claim = names. First, we actually did seriously consider reusing existing SAML = attribute name URNs. But at the time, developers were voting with their = feet, rejecting XML and SOAP for JSON and REST, and we wanted the result = to be something that developers would embrace. =20 The simple registration claim names with OpenID 2 were also short text = names, with a fair amount of overlap. Some changes like =E2=80=9Cdob=E2=80= =9D -> =E2=80=9Cbirthdate=E2=80=9D make me think this was subconscious, = though. -DW From nobody Tue Mar 24 13:11:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D176F3A0C66 for ; Tue, 24 Mar 2020 13:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 xlzIv0CK4NWG for ; Tue, 24 Mar 2020 13:11:03 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 6CF613A041D for ; Tue, 24 Mar 2020 13:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1585080663; x=1616616663; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=nx4uSoMobTRSVBXizlYW7Da5mxAWXg1Z3KGfienQMEs=; b=ecwM1KodgxiWUkN3YXEkJRRxKMw15QyoxVKmX4QJUs2Ym8X9N/7BWZVQ MEKyB5sjUWEDPCPTEC1pM7UGW76PcKZPnx9LMr/lF9HsiRk4vzS+u5+Nz p1ZPwqaittAyvSAzKVUK4Fm4DMyI/fUZ56ygdfvCkfbYzyY7xLgdjdoU3 0=; IronPort-SDR: aEQ8TuFIhqnN/oezSavfzayQRJbngFj2zsrtgPpzYf5oifkkpTf+W4c8X5hryatm8TDuzfLHmc 4hBSZOZE64RQ== X-IronPort-AV: E=Sophos;i="5.72,301,1580774400"; d="scan'208";a="22576374" Thread-Topic: [Txauth] Working through differences Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-55156cd4.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP; 24 Mar 2020 20:10:49 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-55156cd4.us-west-2.amazon.com (Postfix) with ESMTPS id D4920A248D; Tue, 24 Mar 2020 20:10:48 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 24 Mar 2020 20:10:48 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 20:10:48 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Tue, 24 Mar 2020 20:10:48 +0000 From: "Richard Backman, Annabelle" To: Justin Richer , Pete Resnick CC: "txauth@ietf.org" Thread-Index: AQHWAWAyudOE18CN/UKBa4NKRuyFNahXwU8A///3NIA= Date: Tue, 24 Mar 2020 20:10:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.90] Content-Type: text/plain; charset="utf-8" Content-ID: <8B1082DE8BF8E94D93094D46E0C84291@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Working through differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 20:11:05 -0000 V2hpbGUgWFlaIGFuZCBYQXV0aCBoYXZlIGJlZW4gdmVyeSBoZWxwZnVsIGluIGdldHRpbmcgcGVv cGxlIHRhbGtpbmcgYW5kIHRoaW5raW5nIGFib3V0IHRoaXMgc3BhY2Ug4oCTIGFuZCB0aGFuayB5 b3UsIEp1c3RpbiBhbmQgRGljaywgZm9yIHdyaXRpbmcgdGhlbSEg4oCTIEkgd29ycnkgdGhhdCBh dCB0aGlzIHBvaW50IHRoZXkgYXJlIGRpc3RyYWN0aW5nIHVzIGZyb20gZmluYWxpemluZyB0aGUg Y2hhcnRlci4gVGhlcmUgc2VlbXMgdG8gc3RpbGwgYmUgc2lnbmlmaWNhbnQgY29udGVudGlvbiBh cm91bmQgYXQgbGVhc3QgYSBjb3VwbGUgb2YgaXNzdWVzLg0KDQpJIGFsc28gdGhpbmsgZGlzY3Vz c2lvbnMgb2YgcHJvdG9jb2wgcHJvcG9zYWxzIHdpbGwgYmUgbXVjaCBtb3JlIHByb2R1Y3RpdmUg aWYgd2UgaGF2ZSBhIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSB1c2UgY2FzZXMgd2UgYXJl IHRyeWluZyB0byBhZGRyZXNzLiBJdCdzIGEgbG90IGVhc2llciB0byBldmFsdWF0ZSBkaWZmZXJl bnQgc29sdXRpb25zIHdoZW4gd2UgYWdyZWUgb24gd2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0K4oCT DQpBbm5hYmVsbGUgQmFja21hbiAoc2hlL2hlcikNCkFXUyBJZGVudGl0eQ0KaHR0cHM6Ly9hd3Mu YW1hem9uLmNvbS9pZGVudGl0eS8NCiANCg0K77u/T24gMy8yNC8yMCwgNjo0MyBBTSwgIlR4YXV0 aCBvbiBiZWhhbGYgb2YgSnVzdGluIFJpY2hlciIgPHR4YXV0aC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBqcmljaGVyQG1pdC5lZHU+IHdyb3RlOg0KDQpJIGxpa2UgdGhpcyBpZGVhIHRo aW5rIGl0IGNvdWxkIGhlbHAgdXMgb3JnYW5pemUgdGhvdWdodHMgYW5kIG9waW5pb25zIG9uIGl0 Lg0KDQog4oCUIEp1c3Rpbg0KDQo+IE9uIE1hciAyMywgMjAyMCwgYXQgNTo1NyBQTSwgUGV0ZSBS ZXNuaWNrIDxyZXNuaWNrQGVwaXN0ZW1lLm5ldD4gd3JvdGU6DQo+DQo+IEkgbWVudGlvbmVkIHRo aXMgaW4gdGhlIGphYmJlciBjaGF0IGR1cmluZyB0aGUgQk9GIGFuZCBCcm9uIHN1Z2dlc3RlZCBJ IHBvc3QgaXQgdG8gdGhlIGxpc3Q6DQo+DQo+IEkgc3VnZ2VzdCB0aGF0IHdlIGhhdmUgYSBwb2xs IGZvciB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiBYWVogYW5kIFhBVVRIIHdpdGggdGhlIGZvbGxv d2luZyBjaG9pY2VzIGZvciBlYWNoIGRpZmZlcmVuY2U6DQo+DQo+IEEuIE9uZSBvZiB0aGVzZSBj aG9pY2VzIGlzIHNlcmlvdXNseSBwcm9ibGVtYXRpYyBmb3IgdGhlc2UgcmVhc29ucy4uLg0KPiBC LiBJIHByZWZlciB0aGUgWFlaL1hBdXRoIGNob2ljZSBmb3IgdGhpcyBvbmUsIGJ1dCBjb3VsZCBs aXZlIHdpdGggZWl0aGVyDQo+IEMuIENvdWxkbid0IGNhcmUgbGVzcw0KPg0KPiBZb3UgbWlnaHQg ZW5kIHVwIHdpdGggYW4gb2J2aW91cyBjaG9pY2UgdG8gYXQgbGVhc3Qgc3RhcnQgd2l0aCB1bnRp bCBzb21lb25lIGZpbmRzIGEgc2hvd3N0b3BwZXIuDQo+DQo+IHByDQo+IC0tDQo+IFBldGUgUmVz bmljayBodHRwczovL3d3dy5lcGlzdGVtZS5uZXQvDQo+IEFsbCBjb25uZWN0aW9ucyB0byB0aGUg d29ybGQgYXJlIHRlbnVvdXMgYXQgYmVzdA0KPg0KPiAtLQ0KPiBUeGF1dGggbWFpbGluZyBsaXN0 DQo+IFR4YXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3R4YXV0aA0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQo= From nobody Tue Mar 24 13:14:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28583A0C56 for ; Tue, 24 Mar 2020 13:13:59 -0700 (PDT) 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, 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 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 LBKw8euoOmOd for ; Tue, 24 Mar 2020 13:13:57 -0700 (PDT) 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 AFC823A0C66 for ; Tue, 24 Mar 2020 13:13:56 -0700 (PDT) Received: from [192.168.1.5] (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 02OKDrgq016090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 16:13:54 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7CE7AACD-BDE8-4D87-B21E-3B494243450F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Mar 2020 16:13:53 -0400 In-Reply-To: Cc: "txauth@ietf.org" , Dick Hardt To: Mike Jones References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 20:14:00 -0000 --Apple-Mail=_7CE7AACD-BDE8-4D87-B21E-3B494243450F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My intent with a small portion of an individual draft is irrelevant, to = be honest. It will be up to the working group to decide the source for = all the syntactical elements of the protocol, and whether those will be = managed by an existing registry or a new registry or a semantic schema = document or something else is all up for debate. Yes, that is all very = important to decide-- But it=E2=80=99s not important to decide at this = stage, and I would argue even premature to do so with no intent of = possibly changing later. I think you are taking the current state of one part of the I-D to mean = too much.=20 =E2=80=94 Justin > On Mar 24, 2020, at 2:54 PM, Mike Jones = wrote: >=20 > Justin, if you want to take the identity claims reuse argument off the = table, publish a new draft of draft-richer-transactional-authz in which = you add something like this language to the Claims section at = https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.= 7 = : > =20 > The requested claim names here and those in the corresponding response = are intended to come from the IANA =E2=80=9CJSON Web Token Claims=E2=80=9D= Registry [IANA.JWT.Claims]. Where this specification defines new = claims, it registers them in this registry. > =20 > And then populate the IANA Considerations section of the new draft to = register new claims that the document uses that are not already = registered, such as =E2=80=9Csubject=E2=80=9D. > =20 > I=E2=80=99ll be watching to see whether you do this as a statement of = intent to reuse of existing identity claims or whether you choose not = to. > =20 > Best wishes, > -- Mike > =20 > P.S. The IANA JWT Claims Registry [IANA.JWT.Claims] is of course at = https://www.iana.org/assignments/jwt/ = . > =20 > From: Justin Richer =20 > Sent: Tuesday, March 24, 2020 7:48 AM > To: Mike Jones > Cc: txauth@ietf.org; Dick Hardt > Subject: Re: [Txauth] XYZ vs XAuth - 5 differences > =20 > Two quick notes I missed: >=20 >=20 > On Mar 24, 2020, at 9:41 AM, Justin Richer > wrote: > =20 > I mentioned this on the call yesterday, but this is an incredibly weak = argument to pick one draft over another, especially at such an early = stage. I would consider everything XYZ malleable, especially what the = fields get named. It=E2=80=99s short sighted to throw out an entire = specification because of the names of fields that were added very = recently to the draft.=20 > =20 > In other words, I think it=E2=80=99s too early to judge based on = things like this, and it shows blindness to the rest of the draft. = It=E2=80=99s true that Dick and I have taken a very different approach = to re-use, but both have re-use. XYZ does re-use many elements from = OAuth 2, OIDC, and XYZ, but they=E2=80=99ve been translated into a = system that=E2=80=99s internally consistent in a way that the source = material is not. Dick has said several times that =E2=80=9CXYZ doesn=E2=80= =99t use OAuth 2 scopes=E2=80=9D which is blatantly > =20 > One correction =E2=80=94 I meant to say =E2=80=9COAuth 2, OIDC, and = others like UMA,=E2=80=9D. :) >=20 >=20 > not true =E2=80=94 we designed the system explicitly so that you could = do that. However, we didn=E2=80=99t just put in a field labeled = =E2=80=9Coauth_scopes=E2=80=9D because, as we=E2=80=99ve found in = defining RAR in OAuth 2, it gets complicated quickly trying to combine = them if you have different layers of semantics within the protocol. XYZ = puts the scope style requests at the same level as the rich requests. > =20 > So let=E2=80=99s say you wanted to do a full mapping of an OIDC = request, just swapping out OAuth 2 for XYZ, it=E2=80=99d look something = like this: > =20 > =20 > { > "keys": "client-id-1234556", > "resources": ["openid", "profile", "email", "phone", "address"], > "claims": { "oidc_id_token": true }, > "interact": { > "redirect": true, > "callaback": { > "url": "https://client.example/redirect_uri = ", > "nonce": "1233455" > } > } > } > =20 > This would get you back an OIDC id token and access token with the = OIDC scopes tied to the server=E2=80=99s UserInfo Endpoint. But as = I=E2=80=99ve been saying, I don=E2=80=99t think it=E2=80=99s within the = purview of this working group to define that level of detail. What we = should do is define what the =E2=80=9Cresources=E2=80=9D field means, = what the =E2=80=9Cclaims=E2=80=9D field means, and put a few buckets in = there for common identifiers and assertions so that people do things the = same way. And I=E2=80=99ll repeat that I would personally prefer the = simple identity mapping layer be in a separate document from the core = delegation protocol =E2=80=94 but that=E2=80=99s a matter for the WG to = decide.=20 > =20 > I=E2=80=99ll also repeat my argument that I don=E2=80=99t think we = should just blindly re-use OIDC=E2=80=99s names for things, but that is = not me saying that we should, of necessity, invent new things entirely = "just because=E2=80=9D. Every choice we make, including what we name = fields, needs to have a good reason.=20 > =20 > And if the WG does end up creating new names for some things? That=E2=80= =99s not the end of the world. When we were working on OIDC, there was = an opportunity to re-use field names from LDAP (specifically, to use = inetOrgPerson and/or eduOrgPerson as the schema), but as you (Mike) = know, we decided not to, and the world is OK for that even though it = meant people had to write a simple translator when wrapping their LDAP = servers with OIDC capabilities (and complained about it at the time).=20 > =20 > Re-use does not just mean copying. It means examining what is there = and pulling the best from it =E2=80=94 and that is going to include = sources beyond OAuth2 and OIDC. At this point we should be looking at = what features we like from the entire ecosystem, including the two = proposed drafts, and decide what we want to bring forward into TxAuth. = And in terms of flexibility, stability, simplicity, and consistency, I = believe that XYZ makes a much stronger base for building on.=20 > =20 > =20 > And an addition =E2=80=94 if you want to just keep using OAuth 2 and = back port functionality to OAuth2 in a compatible way, that work should = be done in the OAuth 2 working group. Here, we=E2=80=99re trying to move = forward, not just rest on what=E2=80=99s been done. That=E2=80=99s not = an argument to invent everything from whole cloth, it=E2=80=99s an = argument to build things better wherever we can. I=E2=80=99m really glad = to have the deep experience of so many participants feeding into this = group for exactly that reason! > =20 > =E2=80=94 Justin >=20 >=20 > =E2=80=94 Justin > =20 >=20 >=20 > On Mar 23, 2020, at 3:53 PM, Mike Jones > wrote: > =20 > I would prefer XAuth as a starting point over XYZ because XAuth is = clearly trying to reuse existing identity representations, whereas XYZ = is creating a new one. > =20 > You can see XAuth=E2=80=99s reuse, for instance, at = https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6 = .= > =20 > You can see XYZ=E2=80=99s invention of a new identity schema at = https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.= 7 = . Yes, it=E2=80=99s similar to some others but not the same, and = rather than reusing existing registered claims, it=E2=80=99s creating = its own unique set. > =20 > -- Mike > =20 > From: Txauth > On Behalf Of Dick Hardt > Sent: Friday, March 20, 2020 1:18 PM > To: txauth@ietf.org > Cc: Justin Richer > > Subject: [EXTERNAL] Re: [Txauth] XYZ vs XAuth - 5 differences > =20 > ACTION REMINDER > =20 > Please weigh in with your preference, your rationale, as well as any = pros and cons not described. > =20 > Yaron and I were hopeful that we would get more feedback on these = topics, as it would help determine if either the XYZ or XAuth documents = are roughly aligned with the consensus direction of the group so that we = have a starting document. > =20 > We will NOT be able to do hums in the BoF ... so we will not be able = to use that to judge rough consensus. > =20 > /Dick > =20 > On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt > wrote: > Hello everyone > =20 > Justin and I have had some emails back and forth comparing and = contrasting XYZ and XAuth. I'm going to post a message for each of the = major points, with Justin's rationale and my rationale for our = respective design decisions. Feel free to ask clarifying questions in = those threads. > =20 > Please weigh in with your preference, your rationale, as well as any = pros and cons not described. > =20 > We would like to get a sense for the group's views on these topics for = the virtual BoF in a week. > =20 > The latest drafts are: > =20 > XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 = > =20 > XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 = > =20 > Thanks! > =20 > /Dick > =E1=90=A7 > =20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_7CE7AACD-BDE8-4D87-B21E-3B494243450F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = intent with a small portion of an individual draft is irrelevant, to be = honest. It will be up to the working group to decide the source for all = the syntactical elements of the protocol, and whether those will be = managed by an existing registry or a new registry or  a semantic = schema document or something else is all up for debate. Yes, that is all = very important to decide-- But it=E2=80=99s not important to decide at = this stage, and I would argue even premature to do so with no intent of = possibly changing later.

I think you are taking the current state of one part of the = I-D to mean too much. 

 =E2=80=94 Justin

On Mar = 24, 2020, at 2:54 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Justin, if you want to take = the identity claims reuse argument off the table, publish a new draft of = draft-richer-transactional-authz in which you add something like this = language to the Claims section at https://tools.ietf.org/html/draft-richer-transactional-authz-06= #section-2.7:
 
The = requested claim names here and those in the corresponding response are = intended to come from the IANA =E2=80=9CJSON Web Token Claims=E2=80=9D = Registry [IANA.JWT.Claims].  Where this specification defines new = claims, it registers them in this registry.
 
And then = populate the IANA Considerations section of the new draft to register = new claims that the document uses that are not already registered, such = as =E2=80=9Csubject=E2=80=9D.
 
I=E2=80=99ll = be watching to see whether you do this as a statement of intent to reuse = of existing identity claims or whether you choose not to.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  = The IANA JWT Claims Registry [IANA.JWT.Claims] is of course at https://www.iana.org/assignments/jwt/.
 
From: Justin Richer <jricher@mit.edu> 
Sent: Tuesday, March 24, 2020 = 7:48 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: txauth@ietf.org; Dick = Hardt <dick.hardt@gmail.com>
Subject: Re: [Txauth] XYZ vs XAuth - = 5 differences
 
Two quick notes I missed:


On Mar 24, 2020, at 9:41 AM, Justin Richer <jricher@mit.edu> wrote:
 
I mentioned this on the call yesterday, = but this is an incredibly weak argument to pick one draft over another, = especially at such an early stage. I would consider everything XYZ = malleable, especially what the fields get named. It=E2=80=99s short = sighted to throw out an entire specification because of the names of = fields that were added very recently to the draft. 
 
In other words, I think it=E2=80=99s = too early to judge based on things like this, and it shows blindness to = the rest of the draft. It=E2=80=99s true that Dick and I have taken a = very different approach to re-use, but both have re-use.  XYZ does = re-use many elements from OAuth 2, OIDC, and XYZ, but they=E2=80=99ve = been translated into a system that=E2=80=99s internally consistent in a = way that the source material is not. Dick has said several times that = =E2=80=9CXYZ doesn=E2=80=99t use OAuth 2 scopes=E2=80=9D which is = blatantly
 
One correction =E2=80=94 I meant to say =E2=80=9COAuth 2, = OIDC, and others like UMA,=E2=80=9D. :)


not true =E2=80=94 we designed the system explicitly so that = you could do that. However, we didn=E2=80=99t just put in a field = labeled =E2=80=9Coauth_scopes=E2=80=9D because, as we=E2=80=99ve found = in defining RAR in OAuth 2, it gets complicated quickly trying to = combine them if you have different layers of semantics within the = protocol. XYZ puts the scope style requests at the same level as the = rich requests.
 
So let=E2=80=99s say you wanted to do a full mapping of an = OIDC request, just swapping out OAuth 2 for XYZ, it=E2=80=99d look = something like this:
 
 
{
  "keys": "client-id-1234556",
  "resources": ["openid", "profile", "email", "phone", = "address"],
  "claims": { "oidc_id_token": = true },
  "interact": {
        &= nbsp;     "redirect": = true,
        &= nbsp;     "callaback": {
        &= nbsp;           &nb= sp;      "url": "https://client.example/redirect_uri",
        &= nbsp;           &nb= sp;      "nonce": = "1233455"
        &= nbsp;     }
  }
}
 
This would get you back an OIDC id = token and access token with the OIDC scopes tied to the server=E2=80=99s = UserInfo Endpoint. But as I=E2=80=99ve been saying, I don=E2=80=99t = think it=E2=80=99s within the purview of this working group to define = that level of detail. What we should do is define what the = =E2=80=9Cresources=E2=80=9D field means, what the =E2=80=9Cclaims=E2=80=9D= field means, and put a few buckets in there for common identifiers and = assertions so that people do things the same way. And I=E2=80=99ll = repeat that I would personally prefer the simple identity mapping layer = be in a separate document from the core delegation protocol =E2=80=94 = but that=E2=80=99s a matter for the WG to decide. 
 
I=E2=80=99ll also repeat my argument = that I don=E2=80=99t think we should just blindly re-use OIDC=E2=80=99s = names for things, but that is not me saying that we should, of = necessity, invent new things entirely "just because=E2=80=9D. Every = choice we make, including what we name fields, needs to have a good = reason. 
 
And if the WG does end up creating new names for some things? = That=E2=80=99s not the end of the world. When we were working on OIDC, = there was an opportunity to re-use field names from LDAP (specifically, = to use inetOrgPerson and/or eduOrgPerson as the schema), but as you = (Mike) know, we decided not to, and the world is OK for that even though = it meant people had to write a simple translator when wrapping their = LDAP servers with OIDC capabilities (and complained about it at the = time). 
 
Re-use does not just mean copying. It means examining what is = there and pulling the best from it =E2=80=94 and that is going to = include sources beyond OAuth2 and OIDC. At this point we should be = looking at what features we like from the entire ecosystem, including = the two proposed drafts, and decide what we want to bring forward into = TxAuth. And in terms of flexibility, stability, simplicity, and = consistency, I believe that XYZ makes a much stronger base for building = on. 
 
 
And an addition =E2=80=94 if you want to just keep using = OAuth 2 and back port functionality to OAuth2 in a compatible way, that = work should be done in the OAuth 2 working group. Here, we=E2=80=99re = trying to move forward, not just rest on what=E2=80=99s been done. = That=E2=80=99s not an argument to invent everything from whole cloth, = it=E2=80=99s an argument to build things better wherever we can. I=E2=80=99= m really glad to have the deep experience of so many participants = feeding into this group for exactly that reason!
 
 =E2=80=94 Justin


 =E2=80=94 Justin
 


On Mar 23, 2020, at 3:53 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
I would prefer XAuth as a starting point over XYZ because XAuth is clearly trying = to reuse existing identity representations, whereas XYZ is creating a = new one.
 
You can see XAuth=E2=80=99s reuse, for = instance, at https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#secti= on-4.6.6.
 
You can see XYZ=E2=80=99s invention of a new = identity schema at https://tools.ietf.org/html/draft-richer-transactional-authz-06= #section-2.7.  Yes, it=E2=80=99s similar to some others but not = the same, and rather than reusing existing registered claims, it=E2=80=99s= creating its own unique set.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Friday, March 20, 2020 1:18 = PM
To: txauth@ietf.org
Cc: Justin Richer <jricher@mit.edu>
Subject: [EXTERNAL] Re: [Txauth] XYZ = vs XAuth - 5 differences
 
ACTION REMINDER
 
Please weigh in with your = preference, your rationale, as well as any pros and cons not = described.
 
Yaron and I were = hopeful that we would get more feedback on these topics, as it = would help determine if either the XYZ or XAuth documents are roughly = aligned with the consensus direction of the group so that we have a = starting document.
 
We will NOT be able to do hums in the = BoF ... so we will not be able to use that to judge rough consensus.
 
/Dick
 
On Mon, Mar 16, 2020 at = 4:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello everyone
 
Justin and I have had some = emails back and forth comparing and contrasting XYZ and XAuth. I'm going = to post a message for each of the major points, with Justin's rationale = and my rationale for our respective design decisions. Feel free to = ask clarifying questions in those threads.
 
Please weigh in with your = preference, your rationale, as well as any pros and cons not = described.
 
We would like to get a sense for the = group's views on these topics for the virtual BoF in a week.
 
The latest drafts are:
 
XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06=
 
XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05
 
Thanks!
 
/Dick
=E1=90=A7
<= /div>
 

= --Apple-Mail=_7CE7AACD-BDE8-4D87-B21E-3B494243450F-- From nobody Tue Mar 24 13:50:32 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EE83A0E63 for ; Tue, 24 Mar 2020 13:50:30 -0700 (PDT) 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, 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 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 ZVCD9o9k4_zR for ; Tue, 24 Mar 2020 13:50:27 -0700 (PDT) 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 C27B23A0E5A for ; Tue, 24 Mar 2020 13:50:26 -0700 (PDT) Received: from [192.168.1.5] (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 02OKoNHw011887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Mar 2020 16:50:23 -0400 From: Justin Richer Message-Id: <4A214D9D-038D-4B7F-A4F4-82D71D8EE342@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_2B76C4D1-D1C5-42CF-90E0-D9C29A6C1D55" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Mar 2020 16:50:22 -0400 In-Reply-To: Cc: "txauth@ietf.org" , Dick Hardt To: Mike Jones References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 20:50:31 -0000 --Apple-Mail=_2B76C4D1-D1C5-42CF-90E0-D9C29A6C1D55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK, so =E2=80=94 I=E2=80=99m not comfortable pointing to a specific = external registry for this kind of thing in the draft (unless we=E2=80=99r= e directly using it), but in fact I didn=E2=80=99t really point to ANY = registry in the draft at this point for a lot of things that will = probably ultimately have registries. I can add language to the various = extensible sections (such as the claims request and claims response) = that point to a =E2=80=9Cfuture TBD registry=E2=80=9D for the set of = fields. That=E2=80=99s a fairly small text change that I hope will help = us move forward. =E2=80=94 Justin > On Mar 24, 2020, at 4:13 PM, Justin Richer wrote: >=20 > My intent with a small portion of an individual draft is irrelevant, = to be honest. It will be up to the working group to decide the source = for all the syntactical elements of the protocol, and whether those will = be managed by an existing registry or a new registry or a semantic = schema document or something else is all up for debate. Yes, that is all = very important to decide-- But it=E2=80=99s not important to decide at = this stage, and I would argue even premature to do so with no intent of = possibly changing later. >=20 > I think you are taking the current state of one part of the I-D to = mean too much.=20 >=20 > =E2=80=94 Justin >=20 >> On Mar 24, 2020, at 2:54 PM, Mike Jones > wrote: >>=20 >> Justin, if you want to take the identity claims reuse argument off = the table, publish a new draft of draft-richer-transactional-authz in = which you add something like this language to the Claims section at = https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.= 7 = : >> =20 >> The requested claim names here and those in the corresponding = response are intended to come from the IANA =E2=80=9CJSON Web Token = Claims=E2=80=9D Registry [IANA.JWT.Claims]. Where this specification = defines new claims, it registers them in this registry. >> =20 >> And then populate the IANA Considerations section of the new draft to = register new claims that the document uses that are not already = registered, such as =E2=80=9Csubject=E2=80=9D. >> =20 >> I=E2=80=99ll be watching to see whether you do this as a statement of = intent to reuse of existing identity claims or whether you choose not = to. >> =20 >> Best wishes, >> -- Mike >> =20 >> P.S. The IANA JWT Claims Registry [IANA.JWT.Claims] is of course at = https://www.iana.org/assignments/jwt/ = . >> =20 >> From: Justin Richer >=20 >> Sent: Tuesday, March 24, 2020 7:48 AM >> To: Mike Jones > >> Cc: txauth@ietf.org ; Dick Hardt = > >> Subject: Re: [Txauth] XYZ vs XAuth - 5 differences >> =20 >> Two quick notes I missed: >>=20 >>=20 >> On Mar 24, 2020, at 9:41 AM, Justin Richer > wrote: >> =20 >> I mentioned this on the call yesterday, but this is an incredibly = weak argument to pick one draft over another, especially at such an = early stage. I would consider everything XYZ malleable, especially what = the fields get named. It=E2=80=99s short sighted to throw out an entire = specification because of the names of fields that were added very = recently to the draft.=20 >> =20 >> In other words, I think it=E2=80=99s too early to judge based on = things like this, and it shows blindness to the rest of the draft. = It=E2=80=99s true that Dick and I have taken a very different approach = to re-use, but both have re-use. XYZ does re-use many elements from = OAuth 2, OIDC, and XYZ, but they=E2=80=99ve been translated into a = system that=E2=80=99s internally consistent in a way that the source = material is not. Dick has said several times that =E2=80=9CXYZ doesn=E2=80= =99t use OAuth 2 scopes=E2=80=9D which is blatantly >> =20 >> One correction =E2=80=94 I meant to say =E2=80=9COAuth 2, OIDC, and = others like UMA,=E2=80=9D. :) >>=20 >>=20 >> not true =E2=80=94 we designed the system explicitly so that you = could do that. However, we didn=E2=80=99t just put in a field labeled = =E2=80=9Coauth_scopes=E2=80=9D because, as we=E2=80=99ve found in = defining RAR in OAuth 2, it gets complicated quickly trying to combine = them if you have different layers of semantics within the protocol. XYZ = puts the scope style requests at the same level as the rich requests. >> =20 >> So let=E2=80=99s say you wanted to do a full mapping of an OIDC = request, just swapping out OAuth 2 for XYZ, it=E2=80=99d look something = like this: >> =20 >> =20 >> { >> "keys": "client-id-1234556", >> "resources": ["openid", "profile", "email", "phone", "address"], >> "claims": { "oidc_id_token": true }, >> "interact": { >> "redirect": true, >> "callaback": { >> "url": = "https://client.example/redirect_uri = ", >> "nonce": "1233455" >> } >> } >> } >> =20 >> This would get you back an OIDC id token and access token with the = OIDC scopes tied to the server=E2=80=99s UserInfo Endpoint. But as = I=E2=80=99ve been saying, I don=E2=80=99t think it=E2=80=99s within the = purview of this working group to define that level of detail. What we = should do is define what the =E2=80=9Cresources=E2=80=9D field means, = what the =E2=80=9Cclaims=E2=80=9D field means, and put a few buckets in = there for common identifiers and assertions so that people do things the = same way. And I=E2=80=99ll repeat that I would personally prefer the = simple identity mapping layer be in a separate document from the core = delegation protocol =E2=80=94 but that=E2=80=99s a matter for the WG to = decide.=20 >> =20 >> I=E2=80=99ll also repeat my argument that I don=E2=80=99t think we = should just blindly re-use OIDC=E2=80=99s names for things, but that is = not me saying that we should, of necessity, invent new things entirely = "just because=E2=80=9D. Every choice we make, including what we name = fields, needs to have a good reason.=20 >> =20 >> And if the WG does end up creating new names for some things? = That=E2=80=99s not the end of the world. When we were working on OIDC, = there was an opportunity to re-use field names from LDAP (specifically, = to use inetOrgPerson and/or eduOrgPerson as the schema), but as you = (Mike) know, we decided not to, and the world is OK for that even though = it meant people had to write a simple translator when wrapping their = LDAP servers with OIDC capabilities (and complained about it at the = time).=20 >> =20 >> Re-use does not just mean copying. It means examining what is there = and pulling the best from it =E2=80=94 and that is going to include = sources beyond OAuth2 and OIDC. At this point we should be looking at = what features we like from the entire ecosystem, including the two = proposed drafts, and decide what we want to bring forward into TxAuth. = And in terms of flexibility, stability, simplicity, and consistency, I = believe that XYZ makes a much stronger base for building on.=20 >> =20 >> =20 >> And an addition =E2=80=94 if you want to just keep using OAuth 2 and = back port functionality to OAuth2 in a compatible way, that work should = be done in the OAuth 2 working group. Here, we=E2=80=99re trying to move = forward, not just rest on what=E2=80=99s been done. That=E2=80=99s not = an argument to invent everything from whole cloth, it=E2=80=99s an = argument to build things better wherever we can. I=E2=80=99m really glad = to have the deep experience of so many participants feeding into this = group for exactly that reason! >> =20 >> =E2=80=94 Justin >>=20 >>=20 >> =E2=80=94 Justin >> =20 >>=20 >>=20 >> On Mar 23, 2020, at 3:53 PM, Mike Jones > wrote: >> =20 >> I would prefer XAuth as a starting point over XYZ because XAuth is = clearly trying to reuse existing identity representations, whereas XYZ = is creating a new one. >> =20 >> You can see XAuth=E2=80=99s reuse, for instance, at = https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6 = .= >> =20 >> You can see XYZ=E2=80=99s invention of a new identity schema at = https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.= 7 = . Yes, it=E2=80=99s similar to some others but not the same, and = rather than reusing existing registered claims, it=E2=80=99s creating = its own unique set. >> =20 >> -- Mike >> =20 >> From: Txauth > On Behalf Of Dick Hardt >> Sent: Friday, March 20, 2020 1:18 PM >> To: txauth@ietf.org >> Cc: Justin Richer > >> Subject: [EXTERNAL] Re: [Txauth] XYZ vs XAuth - 5 differences >> =20 >> ACTION REMINDER >> =20 >> Please weigh in with your preference, your rationale, as well as any = pros and cons not described. >> =20 >> Yaron and I were hopeful that we would get more feedback on these = topics, as it would help determine if either the XYZ or XAuth documents = are roughly aligned with the consensus direction of the group so that we = have a starting document. >> =20 >> We will NOT be able to do hums in the BoF ... so we will not be able = to use that to judge rough consensus. >> =20 >> /Dick >> =20 >> On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt > wrote: >> Hello everyone >> =20 >> Justin and I have had some emails back and forth comparing and = contrasting XYZ and XAuth. I'm going to post a message for each of the = major points, with Justin's rationale and my rationale for our = respective design decisions. Feel free to ask clarifying questions in = those threads. >> =20 >> Please weigh in with your preference, your rationale, as well as any = pros and cons not described. >> =20 >> We would like to get a sense for the group's views on these topics = for the virtual BoF in a week. >> =20 >> The latest drafts are: >> =20 >> XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 = >> =20 >> XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 = >> =20 >> Thanks! >> =20 >> /Dick >> =E1=90=A7 >> =20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_2B76C4D1-D1C5-42CF-90E0-D9C29A6C1D55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK, = so =E2=80=94 I=E2=80=99m not comfortable pointing to a specific external = registry for this kind of thing in the draft (unless we=E2=80=99re = directly using it), but in fact I didn=E2=80=99t really point to ANY = registry in the draft at this point for a lot of things that will = probably ultimately have registries. I can add language to the various = extensible sections (such as the claims request and claims response) = that point to a =E2=80=9Cfuture TBD registry=E2=80=9D for the set of = fields. That=E2=80=99s a fairly small text change that I hope will help = us move forward.

 =E2=80=94 Justin

On Mar = 24, 2020, at 4:13 PM, Justin Richer <jricher@mit.edu> wrote:

My intent with a small = portion of an individual draft is irrelevant, to be honest. It will be = up to the working group to decide the source for all the syntactical = elements of the protocol, and whether those will be managed by an = existing registry or a new registry or  a semantic schema document = or something else is all up for debate. Yes, that is all very important = to decide-- But it=E2=80=99s not important to decide at this stage, and = I would argue even premature to do so with no intent of possibly = changing later.

I = think you are taking the current state of one part of the I-D to mean = too much. 

 =E2=80=94 Justin

On Mar = 24, 2020, at 2:54 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Justin, if you want to take = the identity claims reuse argument off the table, publish a new draft of = draft-richer-transactional-authz in which you add something like this = language to the Claims section at https://tools.ietf.org/html/draft-richer-transactional-authz-06= #section-2.7:
 
The = requested claim names here and those in the corresponding response are = intended to come from the IANA =E2=80=9CJSON Web Token Claims=E2=80=9D = Registry [IANA.JWT.Claims].  Where this specification defines new = claims, it registers them in this registry.
 
And then = populate the IANA Considerations section of the new draft to register = new claims that the document uses that are not already registered, such = as =E2=80=9Csubject=E2=80=9D.
 
I=E2=80=99ll = be watching to see whether you do this as a statement of intent to reuse = of existing identity claims or whether you choose not to.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       Best wishes,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  = The IANA JWT Claims Registry [IANA.JWT.Claims] is of course at https://www.iana.org/assignments/jwt/.
 
From: Justin Richer <jricher@mit.edu> 
Sent: Tuesday, March 24, 2020 = 7:48 AM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: txauth@ietf.org; Dick = Hardt <dick.hardt@gmail.com>
Subject: Re: [Txauth] XYZ vs XAuth - = 5 differences
 
Two quick notes I missed:


On Mar 24, 2020, at 9:41 AM, Justin Richer <jricher@mit.edu> wrote:
 
I mentioned this on the call yesterday, = but this is an incredibly weak argument to pick one draft over another, = especially at such an early stage. I would consider everything XYZ = malleable, especially what the fields get named. It=E2=80=99s short = sighted to throw out an entire specification because of the names of = fields that were added very recently to the draft. 
 
In other words, I think it=E2=80=99s = too early to judge based on things like this, and it shows blindness to = the rest of the draft. It=E2=80=99s true that Dick and I have taken a = very different approach to re-use, but both have re-use.  XYZ does = re-use many elements from OAuth 2, OIDC, and XYZ, but they=E2=80=99ve = been translated into a system that=E2=80=99s internally consistent in a = way that the source material is not. Dick has said several times that = =E2=80=9CXYZ doesn=E2=80=99t use OAuth 2 scopes=E2=80=9D which is = blatantly
 
One correction =E2=80=94 I meant to say =E2=80=9COAuth 2, = OIDC, and others like UMA,=E2=80=9D. :)


not true =E2=80=94 we designed the system explicitly so that = you could do that. However, we didn=E2=80=99t just put in a field = labeled =E2=80=9Coauth_scopes=E2=80=9D because, as we=E2=80=99ve found = in defining RAR in OAuth 2, it gets complicated quickly trying to = combine them if you have different layers of semantics within the = protocol. XYZ puts the scope style requests at the same level as the = rich requests.
 
So let=E2=80=99s say you wanted to do a full mapping of an = OIDC request, just swapping out OAuth 2 for XYZ, it=E2=80=99d look = something like this:
 
 
{
  "keys": "client-id-1234556",
  "resources": ["openid", "profile", "email", "phone", = "address"],
  "claims": { "oidc_id_token": = true },
  "interact": {
        &= nbsp;     "redirect": = true,
        &= nbsp;     "callaback": {
        &= nbsp;           &nb= sp;      "url": "https://client.example/redirect_uri",
        &= nbsp;           &nb= sp;      "nonce": = "1233455"
        &= nbsp;     }
  }
}
 
This would get you back an OIDC id = token and access token with the OIDC scopes tied to the server=E2=80=99s = UserInfo Endpoint. But as I=E2=80=99ve been saying, I don=E2=80=99t = think it=E2=80=99s within the purview of this working group to define = that level of detail. What we should do is define what the = =E2=80=9Cresources=E2=80=9D field means, what the =E2=80=9Cclaims=E2=80=9D= field means, and put a few buckets in there for common identifiers and = assertions so that people do things the same way. And I=E2=80=99ll = repeat that I would personally prefer the simple identity mapping layer = be in a separate document from the core delegation protocol =E2=80=94 = but that=E2=80=99s a matter for the WG to decide. 
 
I=E2=80=99ll also repeat my argument = that I don=E2=80=99t think we should just blindly re-use OIDC=E2=80=99s = names for things, but that is not me saying that we should, of = necessity, invent new things entirely "just because=E2=80=9D. Every = choice we make, including what we name fields, needs to have a good = reason. 
 
And if the WG does end up creating new names for some things? = That=E2=80=99s not the end of the world. When we were working on OIDC, = there was an opportunity to re-use field names from LDAP (specifically, = to use inetOrgPerson and/or eduOrgPerson as the schema), but as you = (Mike) know, we decided not to, and the world is OK for that even though = it meant people had to write a simple translator when wrapping their = LDAP servers with OIDC capabilities (and complained about it at the = time). 
 
Re-use does not just mean copying. It means examining what is = there and pulling the best from it =E2=80=94 and that is going to = include sources beyond OAuth2 and OIDC. At this point we should be = looking at what features we like from the entire ecosystem, including = the two proposed drafts, and decide what we want to bring forward into = TxAuth. And in terms of flexibility, stability, simplicity, and = consistency, I believe that XYZ makes a much stronger base for building = on. 
 
 
And an addition =E2=80=94 if you want to just keep using = OAuth 2 and back port functionality to OAuth2 in a compatible way, that = work should be done in the OAuth 2 working group. Here, we=E2=80=99re = trying to move forward, not just rest on what=E2=80=99s been done. = That=E2=80=99s not an argument to invent everything from whole cloth, = it=E2=80=99s an argument to build things better wherever we can. I=E2=80=99= m really glad to have the deep experience of so many participants = feeding into this group for exactly that reason!
 
 =E2=80=94 Justin


 =E2=80=94 Justin
 


On Mar 23, 2020, at 3:53 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
I would prefer XAuth as a starting point over XYZ because XAuth is clearly trying = to reuse existing identity representations, whereas XYZ is creating a = new one.
 
You can see XAuth=E2=80=99s reuse, for = instance, at https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#secti= on-4.6.6.
 
You can see XYZ=E2=80=99s invention of a new = identity schema at https://tools.ietf.org/html/draft-richer-transactional-authz-06= #section-2.7.  Yes, it=E2=80=99s similar to some others but not = the same, and rather than reusing existing registered claims, it=E2=80=99s= creating its own unique set.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Friday, March 20, 2020 1:18 = PM
To: txauth@ietf.org
Cc: Justin Richer <jricher@mit.edu>
Subject: [EXTERNAL] Re: [Txauth] XYZ = vs XAuth - 5 differences
 
ACTION REMINDER
 
Please weigh in with your = preference, your rationale, as well as any pros and cons not = described.
 
Yaron and I were = hopeful that we would get more feedback on these topics, as it = would help determine if either the XYZ or XAuth documents are roughly = aligned with the consensus direction of the group so that we have a = starting document.
 
We will NOT be able to do hums in the = BoF ... so we will not be able to use that to judge rough consensus.
 
/Dick
 
On Mon, Mar 16, 2020 at = 4:04 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hello everyone
 
Justin and I have had some = emails back and forth comparing and contrasting XYZ and XAuth. I'm going = to post a message for each of the major points, with Justin's rationale = and my rationale for our respective design decisions. Feel free to = ask clarifying questions in those threads.
 
Please weigh in with your = preference, your rationale, as well as any pros and cons not = described.
 
We would like to get a sense for the = group's views on these topics for the virtual BoF in a week.
 
The latest drafts are:
 
XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06=
 
XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05
 
Thanks!
 
/Dick
=E1=90=A7
<= /div>
 

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_2B76C4D1-D1C5-42CF-90E0-D9C29A6C1D55-- From nobody Tue Mar 24 15:26:16 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915263A0440 for ; Tue, 24 Mar 2020 15:26:14 -0700 (PDT) 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=sunet.se 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 rJt-QohSguZe for ; Tue, 24 Mar 2020 15:26:12 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 ADE783A040C for ; Tue, 24 Mar 2020 15:26:11 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v16so363532ljk.13 for ; Tue, 24 Mar 2020 15:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=to:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R+rPh3KsFYvd/D8CqQEMjl4vjQYFIEIeTAhNKr+r9bo=; b=ci3McVlzGOm3e9dKtXrj38z41u8Tpsj3pazU9BKZx7eCS15stKkvjsTK6Mtco9zy+b YZ2YMGB7EJnVpUJ3ACsm1CBY6y+QDK6S9scf90/6d4wzGDnqCF1aMKkatF2nvyLRQI6X SNJHDG2Uqg48lTtZ2Z5jBashp09/rtn1u0ZfdSuzUBYASwhiyV8d9zGGtefMIhtqr1Rv MzwoymoQggLOMEm9cv2RZUIGS77tb5yTX/Ry4fhVvA00XKQhVhhYkkvgFcwiGOs+hSVs F/uI5QDRHdIAOilmB50v61pNWKHnAR7AQRB3BUvMBzFHzRJZu3ovCZ6Fjt43MJByC+Ow +zuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R+rPh3KsFYvd/D8CqQEMjl4vjQYFIEIeTAhNKr+r9bo=; b=cmXHfugAprrFwTIP/PLNa4BamvGTTC7f4npzqGJZx4yIaJjS5WxC0wv48iHZCWIw12 Y6wjn4mvyzheLF9j3+uedv54ynMfazUAN8UNvXxElkCnd6V4bkgQ9U0sS8M3HRuf83uM yAbwllVKGdQ6K+WvDFY2To6+8TeV0qmvNLOaS4O+uSfaiA7APxwGsUKD+SEIrDmq33aT sWVfkaGGAnJb6NcpOsI0kFOAtesxcwf65KR81m29EIXt1Trdhg7BRhVsGYkoTZaatKdH s4HqWd0sqSRBfppbwq7LAQiEqJEXWnQJ5HW1HFSRFJ/CNz7WygOpqfV7h6kG8sLX43lx qIvQ== X-Gm-Message-State: ANhLgQ2PV6+BNeGCmbWv7oCRChIfg0DHPPbgVh8g8TmOCjOmwHoGr36R FauexZAsTB69pFJS8d2Nlk6W1pT+UQV36g== X-Google-Smtp-Source: ADFU+vvzG69bpV2bj8Z6r8RMU4Orhx3Nqyg5z73OmzZuZCYR7Vvc7rqyAIWLJOpH6R7riEXBOCt0PQ== X-Received: by 2002:a2e:99c9:: with SMTP id l9mr19394803ljj.79.1585088768913; Tue, 24 Mar 2020 15:26:08 -0700 (PDT) Received: from [10.0.0.129] (h-98-128-229-152.NA.cust.bahnhof.se. [98.128.229.152]) by smtp.gmail.com with ESMTPSA id y124sm477009lff.48.2020.03.24.15.26.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Mar 2020 15:26:07 -0700 (PDT) To: txauth@ietf.org References: From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA== Message-ID: <965b2926-6dc0-d93b-1d38-a291a52fa17d@sunet.se> Date: Tue, 24 Mar 2020 23:26:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Txauth] XYZ vs XAuth - 5 differences X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 22:26:15 -0000 On 2020-03-24 19:35, Mike Jones wrote: > Taking Leif's comment seriously, for the record, here's some of the historical context on why OpenID Connect created new short JSON claim names. First, we actually did seriously consider reusing existing SAML attribute name URNs. But at the time, developers were voting with their feet, rejecting XML and SOAP for JSON and REST, and we wanted the result to be something that developers would embrace. > It was meant to be taken sort of seriously. Your description of history also shows how something as silly as "short" became the primary design criterion for developing schema. The fact that OIDC succeeded only means somebody is bound to do the same thing all over again and one shouldn't point fingers is all I meant to say... Cheers Leif From nobody Wed Mar 25 10:56:29 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9B3A09F7 for ; Wed, 25 Mar 2020 10:56:16 -0700 (PDT) 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 dlSox9n5mWjX for ; Wed, 25 Mar 2020 10:56:10 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 BE6643A091D for ; Wed, 25 Mar 2020 10:56:09 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id t21so2568550lfe.9 for ; Wed, 25 Mar 2020 10:56:09 -0700 (PDT) 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=kiLxXfS5uZ9GUH2Ts2zd0kbzYT9kzZHBHJQLjUb7vOU=; b=gwmD/XyaRyxES2mKnhuu46F32DrAv2livNj3xdULopN3n+CM+enAdSjQQpq+fxP5bq B6p5zx/gQkWBDMERinKjtJ4dJbCr1Ao1ro7fEFcJlgvEbgU24ga9TFw3Nrud7Fs8LHge cxW6edPfwOnpXY1zM0ZRKg7eygWtc6aWgDhENOT99Grdcjp/XEfa7S9mKwTxCWSaRTQk rtdfrWuGcpHxtqM20aGju+UwIIgjJtY5ifzH1zegdYkyLxxw2GOUkQ/H0VhXoi8pWLRU 2P+g4rAkV4CeMKnH2Z680OYNymZ8HiSkae6eRG6V37IUjrNpoCDkl9WQmOGJflaGk7ns bSsw== 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=kiLxXfS5uZ9GUH2Ts2zd0kbzYT9kzZHBHJQLjUb7vOU=; b=t6jDrr1/xxfQPVHYk+nHOZmjdWhoVEkeHlDQaDehoHnaNkdKnny7wyx96sd21dvYhx DydL4Rdqdbe3imvk96UqHMZPbkyoq+EtE4TlajqWnYUm79s4+t/yB+iBADhf/HJ8pAY/ lmfnRWtq6y85pGLMka8xK7r5PludWhKCfLAUwGT63Nff5ictY44lqedpJKQ1MqhmQWi0 Rk5/UQx6VfuPGiCSCWQP4U/55Kh2gImJiwV2lmt+052JrSkeNgRyyy13TCeWyii3B7Kl AffbjK4dSk6WEXJDG+q1OSIZjmeE48PsiIDjU5d59NJYABwW7vcvq7EgiRv4ixMQYBrr +h4w== X-Gm-Message-State: ANhLgQ1VNzaqsNwT79odquyi8HoDLH9SnM2LXMvqXW9vm73J+xQ8Eppf +E3L4JnitoWBjCBkWcL12E5tNEhI65iOQR+Mplc= X-Google-Smtp-Source: ADFU+vsopkccAQavMkIaBqeoLgpG1MrzLQdVgFhWKwrnMjT1BPz44e85VRn22qMdkmBrFEcfD9OlfFZbkXY3AocvqU4= X-Received: by 2002:ac2:41c2:: with SMTP id d2mr3056262lfi.164.1585158965992; Wed, 25 Mar 2020 10:56:05 -0700 (PDT) MIME-Version: 1.0 References: <1BB3B226-9D8E-49B7-AF8A-95F169B66821@mit.edu> In-Reply-To: <1BB3B226-9D8E-49B7-AF8A-95F169B66821@mit.edu> From: Dick Hardt Date: Wed, 25 Mar 2020 10:55:39 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Benjamin Kaduk , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000014a06c05a1b19576" Archived-At: Subject: Re: [Txauth] brainstorming about "layer session management on top of txauth" X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 17:56:17 -0000 --00000000000014a06c05a1b19576 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We had a short thread on this list of using TxAuth to bootstrap a session management protocol. For example, the AS could return a Session URI that the Client could poll using SecEvent to receive and send security events about the user to/from the AS. I would not expect TxAuth to reinvent SecEvent, but it including a URI for the Client to use in the response looks like a useful integration point. On Tue, Mar 24, 2020 at 12:17 PM Justin Richer wrote: > I agree that identity claims probably shouldn=E2=80=99t be in the core sp= ec and > have said as much many times. That doesn=E2=80=99t put them out of scope = of the > working group, or conversely make them deliverable at the same time as th= e > core protocol. I have even written the charter text to cater to that > flexibility in enumerating the deliverables for identity separately. > > - Justin > > > On Mar 24, 2020, at 3:12 PM, Mike Jones > wrote: > > > > I agree that there has to be a space for advanced (and simple) identity > concepts on top of TxAuth, including logged-in sessions, which can be > refreshed through ongoing use and can be logged out. Answering Ben's > question, I agree that there would need to be a way to layer "tell me whe= n > the user wants to log out" notifications. As Justin says, and as we > learned from the SAML experience, different use cases may require differe= nt > such kinds of notifications, for instance, some over the front channel an= d > some in the back channel. Both the SAML and OpenID Connect experiences > provide data points that there's not a one-size-fits-all logout mechanism > on the Web as we know it today. > > > > The same kind of layering should also apply to login. Some > authorization requests are also authentication (login) requests and some > are not. There needs to be a clear mechanism in the request for indicati= ng > which is which. OpenID Connect signaled that the authorization request w= as > also to perform a login by including an "openid" scope value. Other > syntaxes would also be fine. > > > > The key point is that, if the TxAuth requests and responses are > extensible, it should be possible to define both the login and logout > syntaxes and semantics using these extension mechanisms - probably in > distinct specifications from the TxAuth core. TxAuth can be designed wit= h > these possibilities in mind but that doesn't mean that there's a compelli= ng > argument to include them the core spec. > > > > Paraphrasing Ben, it should be straightforward to "layer identity > management on top of txauth". > > > > -- Mike > > > > -----Original Message----- > > From: Txauth On Behalf Of Justin Richer > > Sent: Tuesday, March 24, 2020 6:47 AM > > To: Benjamin Kaduk > > Cc: txauth@ietf.org > > Subject: Re: [Txauth] brainstorming about "layer session management on > top of txauth" > > > > I agree that the kind of identity info that we=E2=80=99re looking at Lo= gin > events are pretty well understood and have been solved with some pretty > solid patterns for years. Logout (and session management in general) turn= s > out to be much, much, much harder. I don=E2=80=99t buy the argument that = they are > required to go together, especially because OIDC was not published with > session management and logout functionality. There=E2=80=99s a non-final = draft, but > it was was last updated 3 years ago and does not have wide adoption. > > > > Regardless, I think that there is going to be a space to add advanced > identity concepts on top of TxAuth =E2=80=94 though likely outside of the= TxAuth > working group, we should design with some of this in mind and leave space > and structure for it. > > > > But to spitball an idea on top of XYZ, I think it=E2=80=99s a short ste= p to ask > for a session management handle to give to the client. This is an artifac= t > that the AS would know how to dereference to let the client push a =E2=80= =9Clogout=E2=80=9D > event to the AS. But the client could also, in the same request, register= a > =E2=80=9Clogout=E2=80=9D callback at the AS, using some variety of mechan= isms. So maybe > something like this: > > > > { > > "session": { > > "logout_callback": { > > "url": "https://client.example/logout", > > "nonce": "0948134" > > } > > } > > } > > > > And the server responds with something like: > > > > { > > "session_handle": { > > "url": "https://server.example/logout", > > "handle": "0948134", > > "type": "bearer" > > } > > } > > > > But again, I don=E2=80=99t think that this is necessary for a simple lo= gin > system or even in scope for TxAuth. Identity is indeed huge, but we don= =E2=80=99t > need to solve everything in order to solve something universally useful. > > > > =E2=80=94 Justin > > > >> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk wrote: > >> > >> Hi all, > >> > >> We spent a long time talking about what we mean by identity and what > >> should be in scope for us to do vs. reuse, and I had an idea that I > >> wanted to get some feedback on, relating to how we might layer > >> identity/session-management on top of XYZ. (I am not sure yet if it > >> would apply to XAuth or not.) > >> > >> If we talk about how some of the claims conveyed from AS to client > >> relate to who the user is, but as Mike notes this starts to look like = a > "login" > >> event, and once you have that you want to know about the "logout" > >> event as well. Would it be possible to build something that has the > >> client ask for a resource of "tell me when the user logs out"? We'd > >> of course need to define some way to indicate how the AS would convey > >> that to the client, but on first glance at least it seems like it > >> could work to layer the session-management on top of claims with > >> semantics like that. Whether the resulting set of claims would still > >> look pretty is another matter, though... > >> > >> -Ben > >> > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000014a06c05a1b19576 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We had a short thread on this list of using TxAuth to boot= strap a session management protocol.

For example, the AS= could return a Session URI that the Client could poll using SecEvent to re= ceive=C2=A0and send security events about the user to/from the AS.=C2=A0

I would not expect TxAuth to reinvent SecEvent, but = it including=C2=A0a URI for the Client to use in the response looks like a = useful integration point.



On Tue, Mar 24= , 2020 at 12:17 PM Justin Richer <jri= cher@mit.edu> wrote:
I agree that identity claims probably shouldn=E2=80=99t be in t= he core spec and have said as much many times. That doesn=E2=80=99t put the= m out of scope of the working group, or conversely make them deliverable at= the same time as the core protocol. I have even written the charter text t= o cater to that flexibility in enumerating the deliverables for identity se= parately.

=C2=A0- Justin

> On Mar 24, 2020, at 3:12 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
>
> I agree that there has to be a space for advanced (and simple) identit= y concepts on top of TxAuth, including logged-in sessions, which can be ref= reshed through ongoing use and can be logged out.=C2=A0 Answering Ben's= question, I agree that there would need to be a way to layer "tell me= when the user wants to log out" notifications.=C2=A0 As Justin says, = and as we learned from the SAML experience, different use cases may require= different such kinds of notifications, for instance, some over the front c= hannel and some in the back channel.=C2=A0 Both the SAML and OpenID Connect= experiences provide data points that there's not a one-size-fits-all l= ogout mechanism on the Web as we know it today.
>
> The same kind of layering should also apply to login.=C2=A0 Some autho= rization requests are also authentication (login) requests and some are not= .=C2=A0 There needs to be a clear mechanism in the request for indicating w= hich is which.=C2=A0 OpenID Connect signaled that the authorization request= was also to perform a login by including an "openid" scope value= .=C2=A0 Other syntaxes would also be fine.
>
> The key point is that, if the TxAuth requests and responses are extens= ible, it should be possible to define both the login and logout syntaxes an= d semantics using these extension mechanisms - probably in distinct specifi= cations from the TxAuth core.=C2=A0 TxAuth can be designed with these possi= bilities in mind but that doesn't mean that there's a compelling ar= gument to include them the core spec.
>
> Paraphrasing Ben, it should be straightforward to "layer identity= management on top of txauth".
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf Of Justin Richer
> Sent: Tuesday, March 24, 2020 6:47 AM
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: txauth@ietf.o= rg
> Subject: Re: [Txauth] brainstorming about "layer session manageme= nt on top of txauth"
>
> I agree that the kind of identity info that we=E2=80=99re looking at L= ogin events are pretty well understood and have been solved with some prett= y solid patterns for years. Logout (and session management in general) turn= s out to be much, much, much harder. I don=E2=80=99t buy the argument that = they are required to go together, especially because OIDC was not published= with session management and logout functionality. There=E2=80=99s a non-fi= nal draft, but it was was last updated 3 years ago and does not have wide a= doption.
>
> Regardless, I think that there is going to be a space to add advanced = identity concepts on top of TxAuth =E2=80=94 though likely outside of the T= xAuth working group, we should design with some of this in mind and leave s= pace and structure for it.
>
> But to spitball an idea on top of XYZ, I think it=E2=80=99s a short st= ep to ask for a session management handle to give to the client. This is an= artifact that the AS would know how to dereference to let the client push = a =E2=80=9Clogout=E2=80=9D event to the AS. But the client could also, in t= he same request, register a =E2=80=9Clogout=E2=80=9D callback at the AS, us= ing some variety of mechanisms. So maybe something like this:
>
> {
>=C2=A0 "session": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"logout_callback": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"url": "https://cl= ient.example/logout",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"nonce": "0948134"= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 }
> }
>
> And the server responds with something like:
>
> {
>=C2=A0 "session_handle": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"url": "https://server.ex= ample/logout",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"handle": "0948134",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"type": "bearer"
>=C2=A0 =C2=A0 }
> }
>
> But again, I don=E2=80=99t think that this is necessary for a simple l= ogin system or even in scope for TxAuth. Identity is indeed huge, but we do= n=E2=80=99t need to solve everything in order to solve something universall= y useful.
>
> =E2=80=94 Justin
>
>> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>
>> Hi all,
>>
>> We spent a long time talking about what we mean by identity and wh= at
>> should be in scope for us to do vs. reuse, and I had an idea that = I
>> wanted to get some feedback on, relating to how we might layer >> identity/session-management on top of XYZ.=C2=A0 (I am not sure ye= t if it
>> would apply to XAuth or not.)
>>
>> If we talk about how some of the claims conveyed from AS to client=
>> relate to who the user is, but as Mike notes this starts to look l= ike a "login"
>> event, and once you have that you want to know about the "log= out"
>> event as well.=C2=A0 Would it be possible to build something that = has the
>> client ask for a resource of "tell me when the user logs out&= quot;?=C2=A0 We'd
>> of course need to define some way to indicate how the AS would con= vey
>> that to the client, but on first glance at least it seems like it =
>> could work to layer the session-management on top of claims with <= br> >> semantics like that.=C2=A0 Whether the resulting set of claims wou= ld still
>> look pretty is another matter, though...
>>
>> -Ben
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000014a06c05a1b19576-- From nobody Wed Mar 25 14:11:17 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8063A0C56 for ; Wed, 25 Mar 2020 14:11:14 -0700 (PDT) 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, 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 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 36TqPJZmlVZj for ; Wed, 25 Mar 2020 14:11:11 -0700 (PDT) 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 64EE53A0C02 for ; Wed, 25 Mar 2020 14:11:10 -0700 (PDT) Received: from [192.168.1.5] (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 02PLB8iB006829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Mar 2020 17:11:08 -0400 From: Justin Richer Message-Id: <0ACC8115-D5D2-40DC-B9E8-ABB589BB8784@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_359BA9AB-BFD2-40EC-B73E-93A609B01E6F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 25 Mar 2020 17:11:07 -0400 In-Reply-To: Cc: Mike Jones , Benjamin Kaduk , "txauth@ietf.org" To: Dick Hardt References: <1BB3B226-9D8E-49B7-AF8A-95F169B66821@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] brainstorming about "layer session management on top of txauth" X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 21:11:15 -0000 --Apple-Mail=_359BA9AB-BFD2-40EC-B73E-93A609B01E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And I think =E2=80=9Cusing TxAuth to bootstrap a protocol=E2=80=9D is = the right way to look at how this protocol will fit in the wider world. = TxAuth can be the basis for a LOT of different things, even more than = OAuth is the basis for a lot of things. We can discuss these kinds of = protocols and be aware of them as we=E2=80=99re designing, b ut that = doesn=E2=80=99t mean we need to be the ones to hammer out all of the = details of things like sessions. Getting the identifier for the current user for login purposes is such = an incredibly common use case that I still think it should be in scope = for us to handle in the group -- but limited to just that kind of thing, = and in my opinion probably in a secondary document once the group is = choosing where to put content.=20 =E2=80=94 Justin > On Mar 25, 2020, at 1:55 PM, Dick Hardt wrote: >=20 > We had a short thread on this list of using TxAuth to bootstrap a = session management protocol. >=20 > For example, the AS could return a Session URI that the Client could = poll using SecEvent to receive and send security events about the user = to/from the AS.=20 >=20 > I would not expect TxAuth to reinvent SecEvent, but it including a URI = for the Client to use in the response looks like a useful integration = point. >=20 >=20 >=20 > On Tue, Mar 24, 2020 at 12:17 PM Justin Richer > wrote: > I agree that identity claims probably shouldn=E2=80=99t be in the core = spec and have said as much many times. That doesn=E2=80=99t put them out = of scope of the working group, or conversely make them deliverable at = the same time as the core protocol. I have even written the charter text = to cater to that flexibility in enumerating the deliverables for = identity separately.=20 >=20 > - Justin >=20 > > On Mar 24, 2020, at 3:12 PM, Mike Jones > wrote: > >=20 > > I agree that there has to be a space for advanced (and simple) = identity concepts on top of TxAuth, including logged-in sessions, which = can be refreshed through ongoing use and can be logged out. Answering = Ben's question, I agree that there would need to be a way to layer "tell = me when the user wants to log out" notifications. As Justin says, and = as we learned from the SAML experience, different use cases may require = different such kinds of notifications, for instance, some over the front = channel and some in the back channel. Both the SAML and OpenID Connect = experiences provide data points that there's not a one-size-fits-all = logout mechanism on the Web as we know it today. > >=20 > > The same kind of layering should also apply to login. Some = authorization requests are also authentication (login) requests and some = are not. There needs to be a clear mechanism in the request for = indicating which is which. OpenID Connect signaled that the = authorization request was also to perform a login by including an = "openid" scope value. Other syntaxes would also be fine. > >=20 > > The key point is that, if the TxAuth requests and responses are = extensible, it should be possible to define both the login and logout = syntaxes and semantics using these extension mechanisms - probably in = distinct specifications from the TxAuth core. TxAuth can be designed = with these possibilities in mind but that doesn't mean that there's a = compelling argument to include them the core spec. > >=20 > > Paraphrasing Ben, it should be straightforward to "layer identity = management on top of txauth". > >=20 > > -- Mike > >=20 > > -----Original Message----- > > From: Txauth > On Behalf Of Justin Richer > > Sent: Tuesday, March 24, 2020 6:47 AM > > To: Benjamin Kaduk > > > Cc: txauth@ietf.org > > Subject: Re: [Txauth] brainstorming about "layer session management = on top of txauth" > >=20 > > I agree that the kind of identity info that we=E2=80=99re looking at = Login events are pretty well understood and have been solved with some = pretty solid patterns for years. Logout (and session management in = general) turns out to be much, much, much harder. I don=E2=80=99t buy = the argument that they are required to go together, especially because = OIDC was not published with session management and logout functionality. = There=E2=80=99s a non-final draft, but it was was last updated 3 years = ago and does not have wide adoption.=20 > >=20 > > Regardless, I think that there is going to be a space to add = advanced identity concepts on top of TxAuth =E2=80=94 though likely = outside of the TxAuth working group, we should design with some of this = in mind and leave space and structure for it. > >=20 > > But to spitball an idea on top of XYZ, I think it=E2=80=99s a short = step to ask for a session management handle to give to the client. This = is an artifact that the AS would know how to dereference to let the = client push a =E2=80=9Clogout=E2=80=9D event to the AS. But the client = could also, in the same request, register a =E2=80=9Clogout=E2=80=9D = callback at the AS, using some variety of mechanisms. So maybe something = like this: > >=20 > > { > > "session": { > > "logout_callback": { > > "url": "https://client.example/logout = ", > > "nonce": "0948134" > > } > > } > > } > >=20 > > And the server responds with something like: > >=20 > > { > > "session_handle": { > > "url": "https://server.example/logout = ", > > "handle": "0948134", > > "type": "bearer" > > } > > } > >=20 > > But again, I don=E2=80=99t think that this is necessary for a simple = login system or even in scope for TxAuth. Identity is indeed huge, but = we don=E2=80=99t need to solve everything in order to solve something = universally useful. > >=20 > > =E2=80=94 Justin > >=20 > >> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk > wrote: > >>=20 > >> Hi all, > >>=20 > >> We spent a long time talking about what we mean by identity and = what=20 > >> should be in scope for us to do vs. reuse, and I had an idea that I=20= > >> wanted to get some feedback on, relating to how we might layer=20 > >> identity/session-management on top of XYZ. (I am not sure yet if = it=20 > >> would apply to XAuth or not.) > >>=20 > >> If we talk about how some of the claims conveyed from AS to client=20= > >> relate to who the user is, but as Mike notes this starts to look = like a "login" > >> event, and once you have that you want to know about the "logout"=20= > >> event as well. Would it be possible to build something that has = the=20 > >> client ask for a resource of "tell me when the user logs out"? = We'd=20 > >> of course need to define some way to indicate how the AS would = convey=20 > >> that to the client, but on first glance at least it seems like it=20= > >> could work to layer the session-management on top of claims with=20 > >> semantics like that. Whether the resulting set of claims would = still=20 > >> look pretty is another matter, though... > >>=20 > >> -Ben > >>=20 > >> -- > >> Txauth mailing list > >> Txauth@ietf.org > >> https://www.ietf.org/mailman/listinfo/txauth = > >=20 > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_359BA9AB-BFD2-40EC-B73E-93A609B01E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And = I think =E2=80=9Cusing TxAuth to bootstrap a protocol=E2=80=9D is the = right way to look at how this protocol will fit in the wider world. = TxAuth can be the basis for a LOT of different things, even more than = OAuth is the basis for a lot of things. We can discuss these kinds of = protocols and be aware of them as we=E2=80=99re designing, b ut that = doesn=E2=80=99t mean we need to be the ones to hammer out all of the = details of things like sessions.

Getting the identifier for the current user for login = purposes is such an incredibly common use case that I still think it = should be in scope for us to handle in the group -- but limited to just = that kind of thing, and in my opinion probably in a secondary document = once the group is choosing where to put content. 

 =E2=80=94 = Justin

On Mar 25, 2020, at 1:55 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

We had a short thread on this = list of using TxAuth to bootstrap a session management protocol.

For example, the AS = could return a Session URI that the Client could poll using SecEvent to = receive and send security events about the user to/from the = AS. 

I = would not expect TxAuth to reinvent SecEvent, but it including a = URI for the Client to use in the response looks like a useful = integration point.



On Tue, Mar = 24, 2020 at 12:17 PM Justin Richer <jricher@mit.edu> wrote:
I agree that identity claims = probably shouldn=E2=80=99t be in the core spec and have said as much = many times. That doesn=E2=80=99t put them out of scope of the working = group, or conversely make them deliverable at the same time as the core = protocol. I have even written the charter text to cater to that = flexibility in enumerating the deliverables for identity separately.

 - Justin

> On Mar 24, 2020, at 3:12 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>
> I agree that there has to be a space for advanced (and simple) = identity concepts on top of TxAuth, including logged-in sessions, which = can be refreshed through ongoing use and can be logged out.  = Answering Ben's question, I agree that there would need to be a way to = layer "tell me when the user wants to log out" notifications.  As = Justin says, and as we learned from the SAML experience, different use = cases may require different such kinds of notifications, for instance, = some over the front channel and some in the back channel.  Both the = SAML and OpenID Connect experiences provide data points that there's not = a one-size-fits-all logout mechanism on the Web as we know it today.
>
> The same kind of layering should also apply to login.  Some = authorization requests are also authentication (login) requests and some = are not.  There needs to be a clear mechanism in the request for = indicating which is which.  OpenID Connect signaled that the = authorization request was also to perform a login by including an = "openid" scope value.  Other syntaxes would also be fine.
>
> The key point is that, if the TxAuth requests and responses are = extensible, it should be possible to define both the login and logout = syntaxes and semantics using these extension mechanisms - probably in = distinct specifications from the TxAuth core.  TxAuth can be = designed with these possibilities in mind but that doesn't mean that = there's a compelling argument to include them the core spec.
>
> Paraphrasing Ben, it should be straightforward to "layer identity = management on top of txauth".
>
>                  =              -- Mike
>
> -----Original Message-----
> From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Justin Richer
> Sent: Tuesday, March 24, 2020 6:47 AM
> To: Benjamin Kaduk <kaduk@mit.edu>
> Cc: txauth@ietf.org
> Subject: Re: [Txauth] brainstorming about "layer session management = on top of txauth"
>
> I agree that the kind of identity info that we=E2=80=99re looking = at Login events are pretty well understood and have been solved with = some pretty solid patterns for years. Logout (and session management in = general) turns out to be much, much, much harder. I don=E2=80=99t buy = the argument that they are required to go together, especially because = OIDC was not published with session management and logout functionality. = There=E2=80=99s a non-final draft, but it was was last updated 3 years = ago and does not have wide adoption.
>
> Regardless, I think that there is going to be a space to add = advanced identity concepts on top of TxAuth =E2=80=94 though likely = outside of the TxAuth working group, we should design with some of this = in mind and leave space and structure for it.
>
> But to spitball an idea on top of XYZ, I think it=E2=80=99s a short = step to ask for a session management handle to give to the client. This = is an artifact that the AS would know how to dereference to let the = client push a =E2=80=9Clogout=E2=80=9D event to the AS. But the client = could also, in the same request, register a =E2=80=9Clogout=E2=80=9D = callback at the AS, using some variety of mechanisms. So maybe something = like this:
>
> {
>  "session": {
>       "logout_callback": {
>         "url": "https://client.example/logout",
>         "nonce": "0948134"
>       }
>  }
> }
>
> And the server responds with something like:
>
> {
>  "session_handle": {
>       "url": "https://server.example/logout",
>       "handle": "0948134",
>       "type": "bearer"
>    }
> }
>
> But again, I don=E2=80=99t think that this is necessary for a = simple login system or even in scope for TxAuth. Identity is indeed = huge, but we don=E2=80=99t need to solve everything in order to solve = something universally useful.
>
> =E2=80=94 Justin
>
>> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>
>> Hi all,
>>
>> We spent a long time talking about what we mean by identity and = what
>> should be in scope for us to do vs. reuse, and I had an idea = that I
>> wanted to get some feedback on, relating to how we might layer =
>> identity/session-management on top of XYZ.  (I am not sure = yet if it
>> would apply to XAuth or not.)
>>
>> If we talk about how some of the claims conveyed from AS to = client
>> relate to who the user is, but as Mike notes this starts to = look like a "login"
>> event, and once you have that you want to know about the = "logout"
>> event as well.  Would it be possible to build something = that has the
>> client ask for a resource of "tell me when the user logs = out"?  We'd
>> of course need to define some way to indicate how the AS would = convey
>> that to the client, but on first glance at least it seems like = it
>> could work to layer the session-management on top of claims = with
>> semantics like that.  Whether the resulting set of claims = would still
>> look pretty is another matter, though...
>>
>> -Ben
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
= >
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_359BA9AB-BFD2-40EC-B73E-93A609B01E6F-- From nobody Thu Mar 26 13:13:13 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675A73A0DC3 for ; Thu, 26 Mar 2020 13:12:14 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 KZHAO1xSasRC for ; Thu, 26 Mar 2020 13:12:06 -0700 (PDT) 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 F31993A0C96 for ; Thu, 26 Mar 2020 13:12:05 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id i20so7838265ljn.6 for ; Thu, 26 Mar 2020 13:12:05 -0700 (PDT) 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=CsjJ5a9s7Ec7laoKJbVT1uyOv4VjQnkkgLg6Y2cPCag=; b=h6/ZAV1ejiZDeZKo2BgmvBpiisW9MZkhjwZNl+W9cGSrdAvOQOJ5+tW74mIGlIltCR lIUo5pvCW+5AUC0zTdS0v/gClDjKzKZXBUJTuctVqXYOMbf/RJCTz6/KsyaWPDFwxrt9 jL23y/FN6HvESuuf5D4JHkzrKhwkiaHfewihScn5pk3yeDCl+zvcfRYbxIeCnI6hcjYk bPU/UkNG1H4LOC2KbCYVnG9ddwaz3ImQSgNIHVhEkFov85+JSs7ib5qB3yVMwZNW1IwE zyCibqMxr458cmuKf08m2NS3ajpVpcqJgoCug8niieviJWhm0IHLqUgWh8ifriey9bbH pU8w== 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=CsjJ5a9s7Ec7laoKJbVT1uyOv4VjQnkkgLg6Y2cPCag=; b=AM61VwCKL+szUaCwkt3uIIS9Qqx7XSKJSwfrmOxSgBaAfvXU8IClwFXaxyMYd3Vrk1 1XGO6zVc7sXgRgXGUlvpuMLrA2Ici2sS6h+p7d9Ih2aFwddbssDm0o+0IVcKhpLekofK CsQFvRjHXkGrC4FlcjikYmDHZ/BK2ScCw5viMp8oE2rX51LDyQ2hb1pdFYzRO6XpWnvO 7KG126ivZwyMuS64e4tZ039lyLl68pScuww81ohXyJFkDkvkWIKyb+Ab94kNUOnD3HzC RPPxAOGzgcuMHH26195FaCkCEVCV3fh+3wRCMl0myWa+hAUK9TrHMYsoapK/MDCLJFHU zH5g== X-Gm-Message-State: AGi0PubYJ3mlInkT61BFzobOcS/OK0wWi+lcJ3z29EqC0U+3IIKXxbzA 5QFJ8BDwu9sYU25BK/8WrIWofZv+QV81H9e1Ck8L8wGBh7U= X-Google-Smtp-Source: ADFU+vuT7buHoLq/HAMZNZVts6OpH+gbSMwM7SyFkJDdzqu8NSSDvbXeZqgMXsFOcTKTvnE65d7ROao+kjwi2ucu/hY= X-Received: by 2002:a2e:9b8e:: with SMTP id z14mr6303519lji.150.1585253523165; Thu, 26 Mar 2020 13:12:03 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Thu, 26 Mar 2020 13:11:37 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer , Yaron Sheffer Content-Type: multipart/alternative; boundary="00000000000020980c05a1c799c9" Archived-At: Subject: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 20:12:33 -0000 --00000000000020980c05a1c799c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for all the great discussion in the virtual call Monday. Justin has made additional changes to the charter with input from myself and Yaron. Most of the changes are scoping "identity" in the charter. Actual text changes highlighted below, semantically it amounts to: - inclusion of interop statement - clarifying that =E2=80=9Cidentity=E2=80=9D is about identifier claims, a= ssertions, and the carriers for those - explicit call out of multi-access-token (and multi-RS) use cases - explicit call out of token model/schema for as-rs agreement - statement that we aren=E2=80=99t going to be creating assertion formats = of user profile schemas or things like that (within this group) Diff available online at http://www.mergely.com/RehoJJvW/?wl=3D1 and in the attached file. This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user=E2=80=99s browser, from the dele= gation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which is initiated by the client redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels. *The group will define interoperability for this protocol between different parties, including* * - client and authorization server;* * - client and resource server; and* * - authorization server and resource server.* Additionally, the delegation process will allow for: - Fine-grained specification of access - Approval of AS attestation to *identifiers and other* identity claims - Approval of access to multiple resources and APIs in a single interaction - *Support for multiple access tokens in a single request and response* *- Support for directed, audience-restricted access tokens* - Separation between the party authorizing access and the party operating the client requesting access - A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications The group will define extension points for this protocol to allow for flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of possession - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation process (*including identifiers and identity assertions*) Additionally, the group will provide mechanisms for management of the protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens *- Mechanisms for the AS and RS to communicate the access granted by an access token* Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. *The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. * The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol *including* TLS, detached HTTP signature, and embedded HTTP signatures *- Conveyance mechanisms for identifiers and assertions* - Guidelines for use of protocol extension points --00000000000020980c05a1c799c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for all the great discussion in the virtual call Mo= nday. Justin has made additional changes to the charter with input from mys= elf and Yaron. Most of the changes are scoping "identity" in the = charter.

Actual text changes highlighted below, semantic= ally it amounts to:

=C2=A0- inclusion of interop stateme= nt
=C2=A0- clarifying that =E2=80=9Cidentity=E2=80=9D is about id= entifier claims, assertions, and the carriers for those
=C2=A0- e= xplicit call out of multi-access-token (and multi-RS) use cases
= =C2=A0- explicit call out of token model/schema for as-rs agreement
=C2=A0- statement that we aren=E2=80=99t going to be creating assertion = formats of user profile schemas or things like that (within this group)

Diff available online at=C2=A0http://www.mergely.com/RehoJ= JvW/?wl=3D1=C2=A0and in the attached file.

This group is chartered to develop a fine-grained delegati= on protocol for authorization, identity, and API access. This protocol will= allow an authorizing party to delegate access to client software through a= n authorization server. It will expand upon the uses cases currently suppor= ted by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to s= upport authorizations scoped as narrowly as a single transaction, provide a= clear framework for interaction among all parties involved in the protocol= flow, and remove unnecessary dependence on a browser or user-agent for coo= rdinating interactions.=C2=A0

The delegation proce= ss will be acted upon by multiple parties in the protocol, each performing = a specific role. The protocol will decouple the interaction channels, such = as the end user=E2=80=99s browser, from the delegation channel, which happe= ns directly between the client and the authorization server (in contrast wi= th OAuth 2.0 which is initiated by the client redirecting the user=E2=80=99= s browser). The client and AS will involve a user to make an authorization = decision as necessary through interaction mechanisms indicated by the proto= col. This decoupling avoids many of the security concerns and technical cha= llenges of OAuth 2.0 and provides a non-invasive path for supporting future= types of clients and interaction channels.

The= group will define interoperability for this protocol between different par= ties, including
=C2=A0- client and authorization server;
=C2=A0- client and resource server; and
= =C2=A0- authorization server and resource server.

<= div>Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS at= testation to=C2=A0identifiers and other=C2=A0identity claims
- Approval of access to multiple resources and APIs in a single interact= ion
-=C2=A0Support for multiple access tokens in a single requ= est and response
- Support for directed, audience-restrict= ed access tokens
- Separation between the party authorizing a= ccess and the party operating the client requesting access
- A va= riety of client applications, including Web, mobile, single-page, and inter= action-constrained applications

The group will def= ine extension points for this protocol to allow for flexibility in areas in= cluding:

- Cryptographic agility for keys, message= signatures, and proof of possession=C2=A0
- User interaction mec= hanisms including web and non-web methods
- Mechanisms for convey= ing user, software, organization, and other pieces of information used in a= uthorization decisions
- Mechanisms for presenting tokens to reso= urce servers and binding resource requests to tokens and associated cryptog= raphic keys
- Optimized inclusion of additional information throu= gh the delegation process (including identifiers and identity assertions= )

Additionally, the group will provide mechani= sms for management of the protocol lifecycle including:

- Discovery of the authorization server
- Revocation of act= ive tokens
- Mechanisms for the AS and RS to communicate the a= ccess granted by an access token

Although the = artifacts for this work are not intended or expected to be backwards-compat= ible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify m= igrating from OAuth 2.0 and OpenID Connect to the new protocol where possib= le.

This group is not chartered to develop extensi= ons to OAuth 2.0, and as such will focus on new technological solutions not= necessarily compatible with OAuth 2.0. Functionality that builds directly = on OAuth 2.0 will be developed in the OAuth Working Group, including functi= onality back-ported from the protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. Th= is group is not chartered to develop new cryptographic methods.
<= br>
The group is chartered to develop mechanisms for conveying= identity information within the protocol including identifiers (such as em= ail addresses, phone numbers, usernames, and subject identifiers) and asser= tions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Cr= edentials). The group is not chartered to develop new formats for identifie= rs or assertions, nor is the group chartered to develop schemas for user in= formation, profiles, or other identity attributes, unless a viable existing= format is not available.=C2=A0

The initial wo= rk will focus on using HTTP for communication between the client and the au= thorization server, taking advantage of optimization features of HTTP2 and = HTTP3 where possible, and will strive to enable simple mapping to other pro= tocols such as COAP when doing so does not conflict with the primary focus.=

Milestones to include:
- Core delegatio= n protocol
- Key presentation mechanism bindings to the core prot= ocol=C2=A0including=C2=A0TLS, detached HTTP signature, and embedded = HTTP signatures
- Conveyance mechanisms for identifiers and as= sertions
- Guidelines for use of protocol extension points
--00000000000020980c05a1c799c9-- From nobody Thu Mar 26 13:45:26 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FF53A0C96 for ; Thu, 26 Mar 2020 13:45:24 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 NV6PP3CeL1e3 for ; Thu, 26 Mar 2020 13:45:21 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 D87683A0C97 for ; Thu, 26 Mar 2020 13:45:20 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id j17so6055529lfe.7 for ; Thu, 26 Mar 2020 13:45:20 -0700 (PDT) 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=lbDSwNtO+7CxqdUhBx7UyXsOIDRt0PdLiYRzPQ/xb/Q=; b=pZsUhmYrz5pmj2IqtOFR4J/yXoRtqdVWzCag0u1O57iWLMP3PNWDLJM9mTIdSwb11T JqGZj6s+YBjpXzEIlMG3/lffkNhGgArAX83jLbnH37lQ1YAbZS8Q5gvJT4BNFD6zYtBu pkEL9RtNRzVI8cTMVLai/W3bx5Ik7WKNeFEieFAOuGsV/lCI3sUyiT30KsHxAjENWoo5 SUMbAAZ6uazsOU9lYDoOeybbmuzkQ1o/XlESkMaaD6uac9fmLu93pIpJFFOTf/n3Gxxk xuN+GGEpks/AxcUJFlYE/TtZ7bKjrjjtFJOoobyD/8Dhs/cfDK3VhD69h6Tia/7AZ9zg k3cA== 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=lbDSwNtO+7CxqdUhBx7UyXsOIDRt0PdLiYRzPQ/xb/Q=; b=qDdODZ9bCcWfK4lW0myo4v0UsBmg+ZdnkFdgqB2Q1bCCwGdUCKuW0VglgeGvV8fLhJ TL2zURWrpK4TeXfrY2akUduyR73X7yP08z68f8fVf/mwVRh77xtHEcQfnFMZuWPfs9km KJuZRtagA/KhXtPPmrLE0Dq/lbC7xgmi9IaPzYOcNguLShbY1FgnWEYRpD6dsYrwysdQ H95Lw/WleXMILjrSN8Z5AQihb1whN6KZx49YjRhDxAFLGPHSJqXO+tcqelJH617JR7fT ROkNkAR9rsX1T7PSs6vO8XTps37xdRvKqC6H9DSBJ538yY17Bq77UJE4mTOuubQEbx80 fMXw== X-Gm-Message-State: ANhLgQ0+/Po6/IXparMLHipyBQQDZwyjak8yPQlZKbX5rewG2oNzlG+A i/jEZLc0aD6RGezaBWguzPaVmODeERI6ygmQISYJT+MI9uU= X-Google-Smtp-Source: ADFU+vv6zfg9ovCmiB/809nzsl+w5YoUm4MTwYNeFqYtWuQqPOyhm+9jvvwmqbT/+Qe/1c2xg5YVdtNNtEz6IY54OJw= X-Received: by 2002:ac2:44bb:: with SMTP id c27mr7099119lfm.91.1585255518348; Thu, 26 Mar 2020 13:45:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 26 Mar 2020 13:44:52 -0700 Message-ID: To: txauth@ietf.org Cc: Justin Richer , Yaron Sheffer Content-Type: multipart/alternative; boundary="0000000000000ca8b205a1c810e6" Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 20:45:25 -0000 --0000000000000ca8b205a1c810e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had the correct merge link, but the wrong text (we made a change to the first paragraph as well wrt. identity). Here is the correct text: This group is chartered to develop a fine-grained delegation protocol for authorization and API access, *as well as requesting and providing user identifiers and claims*. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user=E2=80=99s browser, from the dele= gation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which is initiated by the client redirecting the user=E2=80=99s browser). The client and AS will involve a u= ser to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels. *The group will define interoperability for this protocol between different parties, including* * - client and authorization server;* * - client and resource server; and* * - authorization server and resource server.* Additionally, the delegation process will allow for: - Fine-grained specification of access - Approval of AS attestation to *identifiers and other* identity claims - Approval of access to multiple resources and APIs in a single interaction - *Support for multiple access tokens in a single request and response* *- Support for directed, audience-restricted access tokens* - Separation between the party authorizing access and the party operating the client requesting access - A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications The group will define extension points for this protocol to allow for flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of possession - User interaction mechanisms including web and non-web methods - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation process (*including identifiers and identity assertions*) Additionally, the group will provide mechanisms for management of the protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens *- Mechanisms for the AS and RS to communicate the access granted by an access token* Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. *The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. * The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol *including* TLS, detached HTTP signature, and embedded HTTP signatures *- Conveyance mechanisms for identifiers and assertions* - Guidelines for use of protocol extension points On Thu, Mar 26, 2020 at 1:11 PM Dick Hardt wrote: > Thanks for all the great discussion in the virtual call Monday. Justin ha= s > made additional changes to the charter with input from myself and Yaron. > Most of the changes are scoping "identity" in the charter. > > Actual text changes highlighted below, semantically it amounts to: > > - inclusion of interop statement > - clarifying that =E2=80=9Cidentity=E2=80=9D is about identifier claims,= assertions, and > the carriers for those > - explicit call out of multi-access-token (and multi-RS) use cases > - explicit call out of token model/schema for as-rs agreement > - statement that we aren=E2=80=99t going to be creating assertion format= s of user > profile schemas or things like that (within this group) > > Diff available online at http://www.mergely.com/RehoJJvW/?wl=3D1 and in t= he > attached file. > > > This group is chartered to develop a fine-grained delegation protocol for > authorization, identity, and API access. This protocol will allow an > authorizing party to delegate access to client software through an > authorization server. It will expand upon the uses cases currently > supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth > 2.0) to support authorizations scoped as narrowly as a single transaction= , > provide a clear framework for interaction among all parties involved in t= he > protocol flow, and remove unnecessary dependence on a browser or user-age= nt > for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, each performing a specific role. The protocol will decouple the > interaction channels, such as the end user=E2=80=99s browser, from the de= legation > channel, which happens directly between the client and the authorization > server (in contrast with OAuth 2.0 which is initiated by the client > redirecting the user=E2=80=99s browser). The client and AS will involve a= user to > make an authorization decision as necessary through interaction mechanism= s > indicated by the protocol. This decoupling avoids many of the security > concerns and technical challenges of OAuth 2.0 and provides a non-invasiv= e > path for supporting future types of clients and interaction channels. > > *The group will define interoperability for this protocol between > different parties, including* > * - client and authorization server;* > * - client and resource server; and* > * - authorization server and resource server.* > > Additionally, the delegation process will allow for: > > - Fine-grained specification of access > - Approval of AS attestation to *identifiers and other* identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - *Support for multiple access tokens in a single request and response* > *- Support for directed, audience-restricted access tokens* > - Separation between the party authorizing access and the party operating > the client requesting access > - A variety of client applications, including Web, mobile, single-page, > and interaction-constrained applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (*including identifiers and identity assertions*) > > Additionally, the group will provide mechanisms for management of the > protocol lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > *- Mechanisms for the AS and RS to communicate the access granted by an > access token* > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the ne= w > protocol where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as > such will focus on new technological solutions not necessarily compatible > with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be > developed in the OAuth Working Group, including functionality back-ported > from the protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not chartered to develop new cryptographic methods. > > *The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new format= s > for identifiers or assertions, nor is the group chartered to develop > schemas for user information, profiles, or other identity attributes, > unless a viable existing format is not available. * > > The initial work will focus on using HTTP for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP2 and HTTP3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol *including* TL= S, > detached HTTP signature, and embedded HTTP signatures > *- Conveyance mechanisms for identifiers and assertions* > - Guidelines for use of protocol extension points > --0000000000000ca8b205a1c810e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I had the correct merge link, but the wrong text (we made = a change to the first paragraph as well wrt. identity). Here is the correct= text:

This group is chartered to develop a fine-grained= delegation protocol for authorization and API access,=C2=A0as well as r= equesting and providing user identifiers and claims. This protocol will= allow an authorizing party to delegate access to client software through a= n authorization server. It will expand upon the uses cases currently suppor= ted by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to s= upport authorizations scoped as narrowly as a single transaction, provide a= clear framework for interaction among all parties involved in the protocol= flow, and remove unnecessary dependence on a browser or user-agent for coo= rdinating interactions.=C2=A0

The delegat= ion process will be acted upon by multiple parties in the protocol, each pe= rforming a specific role. The protocol will decouple the interaction channe= ls, such as the end user=E2=80=99s browser, from the delegation channel, wh= ich happens directly between the client and the authorization server (in co= ntrast with OAuth 2.0 which is initiated by the client redirecting the user= =E2=80=99s browser). The client and AS will involve a user to make an autho= rization decision as necessary through interaction mechanisms indicated by = the protocol. This decoupling avoids many of the security concerns and tech= nical challenges of OAuth 2.0 and provides a non-invasive path for supporti= ng future types of clients and interaction channels.

The group will define interoperability for this protocol between diff= erent parties, including
=C2=A0- client and authorization = server;
=C2=A0- client and resource server; and
<= div>=C2=A0- authorization server and resource server.

=
Additionally, the delegation process will allow for:
<= br>
- Fine-grained specification of access
- Approval o= f AS attestation to=C2=A0identifiers and other=C2=A0identity claims<= /div>
- Approval of access to multiple resources and APIs in a single i= nteraction
-=C2=A0Support for multiple access tokens in a sing= le request and response
- Support for directed, audience-r= estricted access tokens
- Separation between the party author= izing access and the party operating the client requesting access
- A variety of client applications, including Web, mobile, single-page, an= d interaction-constrained applications

The group w= ill define extension points for this protocol to allow for flexibility in a= reas including:

- Cryptographic agility for keys, = message signatures, and proof of possession=C2=A0
- User interact= ion mechanisms including web and non-web methods
- Mechanisms for= conveying user, software, organization, and other pieces of information us= ed in authorization decisions
- Mechanisms for presenting tokens = to resource servers and binding resource requests to tokens and associated = cryptographic keys
- Optimized inclusion of additional informatio= n through the delegation process (including identifiers and identity ass= ertions)

Additionally, the group will provide = mechanisms for management of the protocol lifecycle including:
- Discovery of the authorization server
- Revocation= of active tokens
- Mechanisms for the AS and RS to communicat= e the access granted by an access token

Althou= gh the artifacts for this work are not intended or expected to be backwards= -compatible with OAuth 2.0 or OpenID Connect, the group will attempt to sim= plify migrating from OAuth 2.0 and OpenID Connect to the new protocol where= possible.

This group is not chartered to develop = extensions to OAuth 2.0, and as such will focus on new technological soluti= ons not necessarily compatible with OAuth 2.0. Functionality that builds di= rectly on OAuth 2.0 will be developed in the OAuth Working Group, including= functionality back-ported from the protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for ap= plying cryptographic methods, such as JOSE and COSE, to the delegation proc= ess. This group is not chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for co= nveying identity information within the protocol including identifiers (suc= h as email addresses, phone numbers, usernames, and subject identifiers) an= d assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifi= able Credentials). The group is not chartered to develop new formats for id= entifiers or assertions, nor is the group chartered to develop schemas for = user information, profiles, or other identity attributes, unless a viable e= xisting format is not available.=C2=A0

The ini= tial work will focus on using HTTP for communication between the client and= the authorization server, taking advantage of optimization features of HTT= P2 and HTTP3 where possible, and will strive to enable simple mapping to ot= her protocols such as COAP when doing so does not conflict with the primary= focus.

Milestones to include:
- Core de= legation protocol
- Key presentation mechanism bindings to the co= re protocol=C2=A0including=C2=A0TLS, detached HTTP signature, and em= bedded HTTP signatures
- Conveyance mechanisms for identifiers= and assertions
- Guidelines for use of protocol extension po= ints




On Thu, Mar 26= , 2020 at 1:11 PM Dick Hardt <di= ck.hardt@gmail.com> wrote:
Thanks for all the great discussion in t= he virtual call Monday. Justin has made additional changes to the charter w= ith input from myself and Yaron. Most of the changes are scoping "iden= tity" in the charter.

Actual text changes highlight= ed below, semantically it amounts to:

=C2=A0- inclusion = of interop statement
=C2=A0- clarifying that =E2=80=9Cidentity=E2= =80=9D is about identifier claims, assertions, and the carriers for those
=C2=A0- explicit call out of multi-access-token (and multi-RS) use= cases
=C2=A0- explicit call out of token model/schema for as-rs = agreement
=C2=A0- statement that we aren=E2=80=99t going to be cr= eating assertion formats of user profile schemas or things like that (withi= n this group)

Diff available online at=C2=A0http://www.= mergely.com/RehoJJvW/?wl=3D1=C2=A0and in the attached file.
<= br>

This group is chartered to develop a fine= -grained delegation protocol for authorization, identity, and API access. T= his protocol will allow an authorizing party to delegate access to client s= oftware through an authorization server. It will expand upon the uses cases= currently supported by OAuth 2.0 and OpenID Connect (itself an extension o= f OAuth 2.0) to support authorizations scoped as narrowly as a single trans= action, provide a clear framework for interaction among all parties involve= d in the protocol flow, and remove unnecessary dependence on a browser or u= ser-agent for coordinating interactions.=C2=A0

The= delegation process will be acted upon by multiple parties in the protocol,= each performing a specific role. The protocol will decouple the interactio= n channels, such as the end user=E2=80=99s browser, from the delegation cha= nnel, which happens directly between the client and the authorization serve= r (in contrast with OAuth 2.0 which is initiated by the client redirecting = the user=E2=80=99s browser). The client and AS will involve a user to make = an authorization decision as necessary through interaction mechanisms indic= ated by the protocol. This decoupling avoids many of the security concerns = and technical challenges of OAuth 2.0 and provides a non-invasive path for = supporting future types of clients and interaction channels.

=
The group will define interoperability for this protocol betw= een different parties, including
=C2=A0- client and author= ization server;
=C2=A0- client and resource server; and
=C2=A0- authorization server and resource server.
<= div>
Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Ap= proval of AS attestation to=C2=A0identifiers and other=C2=A0identity= claims
- Approval of access to multiple resources and APIs in a = single interaction
-=C2=A0Support for multiple access tokens i= n a single request and response
- Support for directed, au= dience-restricted access tokens
- Separation between the part= y authorizing access and the party operating the client requesting access
- A variety of client applications, including Web, mobile, single-= page, and interaction-constrained applications

The= group will define extension points for this protocol to allow for flexibil= ity in areas including:

- Cryptographic agility fo= r keys, message signatures, and proof of possession=C2=A0
- User = interaction mechanisms including web and non-web methods
- Mechan= isms for conveying user, software, organization, and other pieces of inform= ation used in authorization decisions
- Mechanisms for presenting= tokens to resource servers and binding resource requests to tokens and ass= ociated cryptographic keys
- Optimized inclusion of additional in= formation through the delegation process (including identifiers and iden= tity assertions)

Additionally, the group will = provide mechanisms for management of the protocol lifecycle including:

- Discovery of the authorization server
- Re= vocation of active tokens
- Mechanisms for the AS and RS to co= mmunicate the access granted by an access token

Although the artifacts for this work are not intended or expected to be b= ackwards-compatible with OAuth 2.0 or OpenID Connect, the group will attemp= t to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc= ol where possible.

This group is not chartered to = develop extensions to OAuth 2.0, and as such will focus on new technologica= l solutions not necessarily compatible with OAuth 2.0. Functionality that b= uilds directly on OAuth 2.0 will be developed in the OAuth Working Group, i= ncluding functionality back-ported from the protocol developed here to OAut= h 2.0.

The group is chartered to develop mechanism= s for applying cryptographic methods, such as JOSE and COSE, to the delegat= ion process. This group is not chartered to develop new cryptographic metho= ds.

The group is chartered to develop mechanism= s for conveying identity information within the protocol including identifi= ers (such as email addresses, phone numbers, usernames, and subject identif= iers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, an= d Verifiable Credentials). The group is not chartered to develop new format= s for identifiers or assertions, nor is the group chartered to develop sche= mas for user information, profiles, or other identity attributes, unless a = viable existing format is not available.=C2=A0

The initial work will focus on using HTTP for communication between the cl= ient and the authorization server, taking advantage of optimization feature= s of HTTP2 and HTTP3 where possible, and will strive to enable simple mappi= ng to other protocols such as COAP when doing so does not conflict with the= primary focus.

Milestones to include:
-= Core delegation protocol
- Key presentation mechanism bindings t= o the core protocol=C2=A0including=C2=A0TLS, detached HTTP signature= , and embedded HTTP signatures
- Conveyance mechanisms for ide= ntifiers and assertions
- Guidelines for use of protocol exte= nsion points
--0000000000000ca8b205a1c810e6-- From nobody Thu Mar 26 13:49:50 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A629B3A0EB8 for ; Thu, 26 Mar 2020 13:49:33 -0700 (PDT) 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_FILL_THIS_FORM_SHORT=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 fn7oy-FeQGRo for ; Thu, 26 Mar 2020 13:49:31 -0700 (PDT) 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 47C333A0E5B for ; Thu, 26 Mar 2020 13:49:30 -0700 (PDT) Received: from [192.168.1.5] (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 02QKnRLn005591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Mar 2020 16:49:28 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_34E6E32F-B641-4BD3-8E10-EF77C9D5A2B2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 26 Mar 2020 16:49:27 -0400 In-Reply-To: Cc: txauth@ietf.org, Yaron Sheffer To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 20:49:49 -0000 --Apple-Mail=_34E6E32F-B641-4BD3-8E10-EF77C9D5A2B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Also, here=E2=80=99s the .diff file if you want to look over the changes = more directly. This can also be downloaded from link given in the first = email. Please note that this is a comparison against the charter that Yaron had = mailed out for comment on March 6, 2020 and not the ones I had sent out = in the interim. Thanks to everyone for your inputs and the chairs for putting this up! =E2=80=94 Justin > On Mar 26, 2020, at 4:44 PM, Dick Hardt wrote: >=20 > I had the correct merge link, but the wrong text (we made a change to = the first paragraph as well wrt. identity). Here is the correct text: >=20 > This group is chartered to develop a fine-grained delegation protocol = for authorization and API access, as well as requesting and providing = user identifiers and claims. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. It will expand upon the uses cases currently supported by OAuth = 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support = authorizations scoped as narrowly as a single transaction, provide a = clear framework for interaction among all parties involved in the = protocol flow, and remove unnecessary dependence on a browser or = user-agent for coordinating interactions.=20 >=20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >=20 > The group will define interoperability for this protocol between = different parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identifiers and other identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party = operating the client requesting access > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation = process (including identifiers and identity assertions) >=20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an = access token >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >=20 > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 >=20 > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol including = TLS, detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions > - Guidelines for use of protocol extension points >=20 >=20 >=20 >=20 > On Thu, Mar 26, 2020 at 1:11 PM Dick Hardt > wrote: > Thanks for all the great discussion in the virtual call Monday. Justin = has made additional changes to the charter with input from myself and = Yaron. Most of the changes are scoping "identity" in the charter. >=20 > Actual text changes highlighted below, semantically it amounts to: >=20 > - inclusion of interop statement > - clarifying that =E2=80=9Cidentity=E2=80=9D is about identifier = claims, assertions, and the carriers for those > - explicit call out of multi-access-token (and multi-RS) use cases > - explicit call out of token model/schema for as-rs agreement > - statement that we aren=E2=80=99t going to be creating assertion = formats of user profile schemas or things like that (within this group) >=20 > Diff available online at http://www.mergely.com/RehoJJvW/?wl=3D1 = and in the attached file. >=20 >=20 > This group is chartered to develop a fine-grained delegation protocol = for authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions.=20 >=20 > The delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels. >=20 > The group will define interoperability for this protocol between = different parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of access > - Approval of AS attestation to identifiers and other identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party = operating the client requesting access > - A variety of client applications, including Web, mobile, = single-page, and interaction-constrained applications >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation = process (including identifiers and identity assertions) >=20 > Additionally, the group will provide mechanisms for management of the = protocol lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an = access token >=20 > Although the artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the = new protocol where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as = such will focus on new technological solutions not necessarily = compatible with OAuth 2.0. Functionality that builds directly on OAuth = 2.0 will be developed in the OAuth Working Group, including = functionality back-ported from the protocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic methods. >=20 > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available.=20 >=20 > The initial work will focus on using HTTP for communication between = the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol including = TLS, detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions > - Guidelines for use of protocol extension points --Apple-Mail=_34E6E32F-B641-4BD3-8E10-EF77C9D5A2B2 Content-Type: multipart/mixed; boundary="Apple-Mail=_D58552EC-958A-4D38-90B3-C15BA7894827" --Apple-Mail=_D58552EC-958A-4D38-90B3-C15BA7894827 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Also,= here=E2=80=99s the .diff file if you want to look over the changes more = directly. This can also be downloaded from link given in the first = email.

Please note = that this is a comparison against the charter that Yaron had mailed out = for comment on March 6, 2020 and not the ones I = had sent out in the interim.

Thanks to everyone for your inputs and = the chairs for putting this up!

 =E2=80=94 Justin

= --Apple-Mail=_D58552EC-958A-4D38-90B3-C15BA7894827 Content-Disposition: attachment; filename="RehoJJvW(4).diff" Content-Type: application/octet-stream; x-unix-mode=0666; name="RehoJJvW(4).diff" Content-Transfer-Encoding: 7bit 1c1 < This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. --- > This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. 4a5,9 > The group will define interoperability for this protocol between different parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. > 8c13 < - Approval of AS attestation to identity claims --- > - Approval of AS attestation to identifiers and other identity claims 9a15,16 > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens 19c26 < - Optimized inclusion of additional information through the delegation process (including identity) --- > - Optimized inclusion of additional information through the delegation process (including identifiers and identity assertions) 25c32 < - Query of token rights by resource servers --- > - Mechanisms for the AS and RS to communicate the access granted by an access token 32a40,41 > The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. > 37,38c46,47 < - Key presentation mechanism bindings to the core protocol for TLS, detached HTTP signature, and embedded HTTP signatures < - Identity and authentication conveyance mechanisms --- > - Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions --Apple-Mail=_D58552EC-958A-4D38-90B3-C15BA7894827 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 26, 2020, at 4:44 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I had the correct merge link, but = the wrong text (we made a change to the first paragraph as well wrt. = identity). Here is the correct text:

This group is chartered to develop a = fine-grained delegation protocol for authorization and API = access, as well as requesting and providing user = identifiers and claims. This protocol will allow an authorizing = party to delegate access to client software through an authorization = server. It will expand upon the uses cases currently supported by OAuth = 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support = authorizations scoped as narrowly as a single transaction, provide a = clear framework for interaction among all parties involved in the = protocol flow, and remove unnecessary dependence on a browser or = user-agent for coordinating interactions. 

The = delegation process will be acted upon by multiple parties in the = protocol, each performing a specific role. The protocol will decouple = the interaction channels, such as the end user=E2=80=99s browser, from = the delegation channel, which happens directly between the client and = the authorization server (in contrast with OAuth 2.0 which is initiated = by the client redirecting the user=E2=80=99s browser). The client and AS = will involve a user to make an authorization decision as necessary = through interaction mechanisms indicated by the protocol. This = decoupling avoids many of the security concerns and technical challenges = of OAuth 2.0 and provides a non-invasive path for supporting future = types of clients and interaction channels.

The group will define = interoperability for this protocol between different parties, = including
 - client and = authorization server;
 - = client and resource server; and
 - authorization server and resource = server.

Additionally, the delegation process will allow = for:

- = Fine-grained specification of access
- Approval of = AS attestation to identifiers and = other identity claims
- Approval of access = to multiple resources and APIs in a single interaction
- Support for multiple access tokens in a = single request and response
- = Support for directed, audience-restricted access tokens
- Separation between the party authorizing access and the = party operating the client requesting access
- A = variety of client applications, including Web, mobile, single-page, and = interaction-constrained applications

The group will define extension points = for this protocol to allow for flexibility in areas including:

- Cryptographic agility = for keys, message signatures, and proof of possession 
- User interaction mechanisms including web and non-web = methods
- Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated = cryptographic keys
- Optimized inclusion of = additional information through the delegation process (including identifiers and identity assertions)

Additionally, the group = will provide mechanisms for management of the protocol lifecycle = including:

- = Discovery of the authorization server
- Revocation = of active tokens
- Mechanisms for the = AS and RS to communicate the access granted by an access = token

Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.

This group is not chartered to develop = extensions to OAuth 2.0, and as such will focus on new technological = solutions not necessarily compatible with OAuth 2.0. Functionality that = builds directly on OAuth 2.0 will be developed in the OAuth Working = Group, including functionality back-ported from the protocol developed = here to OAuth 2.0.

The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic = methods.

The group is chartered to develop mechanisms for conveying = identity information within the protocol including identifiers (such as = email addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not = available. 

The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key = presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded = HTTP signatures
- Conveyance = mechanisms for identifiers and assertions
- = Guidelines for use of protocol extension points




On Thu, Mar = 26, 2020 at 1:11 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Thanks = for all the great discussion in the virtual call Monday. Justin has made = additional changes to the charter with input from myself and Yaron. Most = of the changes are scoping "identity" in the charter.

Actual text changes highlighted below, = semantically it amounts to:

 - inclusion of interop statement
 - clarifying that =E2=80=9Cidentity=E2=80=9D is about = identifier claims, assertions, and the carriers for those
 - explicit call out of multi-access-token (and = multi-RS) use cases
 - explicit call out of = token model/schema for as-rs agreement
 - = statement that we aren=E2=80=99t going to be creating assertion formats = of user profile schemas or things like that (within this = group)

Diff = available online at http://www.mergely.com/RehoJJvW/?wl=3D1 and in the = attached file.


This = group is chartered to develop a fine-grained delegation protocol for = authorization, identity, and API access. This protocol will allow an = authorizing party to delegate access to client software through an = authorization server. It will expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth = 2.0) to support authorizations scoped as narrowly as a single = transaction, provide a clear framework for interaction among all parties = involved in the protocol flow, and remove unnecessary dependence on a = browser or user-agent for coordinating interactions. 

The delegation process = will be acted upon by multiple parties in the protocol, each performing = a specific role. The protocol will decouple the interaction channels, = such as the end user=E2=80=99s browser, from the delegation channel, = which happens directly between the client and the authorization server = (in contrast with OAuth 2.0 which is initiated by the client redirecting = the user=E2=80=99s browser). The client and AS will involve a user to = make an authorization decision as necessary through interaction = mechanisms indicated by the protocol. This decoupling avoids many of the = security concerns and technical challenges of OAuth 2.0 and provides a = non-invasive path for supporting future types of clients and interaction = channels.

The group will define interoperability for this protocol = between different parties, including
 - client and authorization server;
 - client and resource server; = and
 - authorization server = and resource server.

Additionally, the delegation process will allow = for:

- = Fine-grained specification of access
- Approval of = AS attestation to identifiers and = other identity claims
- Approval of access = to multiple resources and APIs in a single interaction
- Support for multiple access tokens in a = single request and response
- = Support for directed, audience-restricted access tokens
- Separation between the party authorizing access and the = party operating the client requesting access
- A = variety of client applications, including Web, mobile, single-page, and = interaction-constrained applications

The group will define extension points = for this protocol to allow for flexibility in areas including:

- Cryptographic agility = for keys, message signatures, and proof of possession 
- User interaction mechanisms including web and non-web = methods
- Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated = cryptographic keys
- Optimized inclusion of = additional information through the delegation process (including identifiers and identity assertions)

Additionally, the group = will provide mechanisms for management of the protocol lifecycle = including:

- = Discovery of the authorization server
- Revocation = of active tokens
- Mechanisms for the = AS and RS to communicate the access granted by an access = token

Although the artifacts for this work are not intended or = expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, = the group will attempt to simplify migrating from OAuth 2.0 and OpenID = Connect to the new protocol where possible.

This group is not chartered to develop = extensions to OAuth 2.0, and as such will focus on new technological = solutions not necessarily compatible with OAuth 2.0. Functionality that = builds directly on OAuth 2.0 will be developed in the OAuth Working = Group, including functionality back-ported from the protocol developed = here to OAuth 2.0.

The group is chartered to develop mechanisms for applying = cryptographic methods, such as JOSE and COSE, to the delegation process. = This group is not chartered to develop new cryptographic = methods.

The group is chartered to develop mechanisms for conveying = identity information within the protocol including identifiers (such as = email addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not = available. 

The initial work will focus on using HTTP for communication = between the client and the authorization server, taking advantage of = optimization features of HTTP2 and HTTP3 where possible, and will strive = to enable simple mapping to other protocols such as COAP when doing so = does not conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key = presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded = HTTP signatures
- Conveyance = mechanisms for identifiers and assertions
- = Guidelines for use of protocol extension points

= --Apple-Mail=_D58552EC-958A-4D38-90B3-C15BA7894827-- --Apple-Mail=_34E6E32F-B641-4BD3-8E10-EF77C9D5A2B2-- From nobody Thu Mar 26 13:58:07 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDA03A0C0B for ; Thu, 26 Mar 2020 13:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 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, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=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 Ny9PeaP7hUsm for ; Thu, 26 Mar 2020 13:57:45 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 4750B3A0E96 for ; Thu, 26 Mar 2020 13:57:45 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id z5so8591025wml.5 for ; Thu, 26 Mar 2020 13:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=cRYuuJIfRu9Tot6wA8IjJJoJlmA7nXXrVg1pBKJF9ic=; b=fGLK6Suj+6e2X6FCVkD57OsGBLaVjv06wb6GY2ypRkioKxSJx6tnVTEqj2/XR+/ZO9 /QF/wr94u6W1Jiasv5axMdOp048f89Wjlr5HzbeksifVA8jw5pbfAN1HkU/XC1+ifJe8 Oh8R1bBZyUHNhxFVDjLIQBmDVB/UpILB8zCQA1M+iH+HZw9xfwps4sgCV8D513I1dDaZ vpFRxQ42vY9TsVfh9Niew/ZMzmN+SOuBie+EuGl1IzigibtV2zflYbO2co3UMiD1luvI rmx8EqLwRc4FOzK2K2Sv2NCCJAqSaEo9zGTfBg43/ZYfTFBchN537NZPP/rWzM1TcL0I fHlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=cRYuuJIfRu9Tot6wA8IjJJoJlmA7nXXrVg1pBKJF9ic=; b=O5x6oI6b4MO3myuBhojFLR0quhBSAqd1VSLRSrBHOpjDaWXf/JXEryeWQ0jzgK+5lo DuJyLt+kfN/jxOzqVQ4FcO2cR7VUHbwyX0HS13GJNf0VSJHEvcumlUBh6DkDvSbj9Nih JGbOZD8zQ8osteY4bqAFQT0ZszZrvuH87VbALgTni47xOiwzDNHumAC6GCrus/0tbv0T BU+foDLSupi8bNWEWg4uAdEo5KSgLhJ6s0GUx8wKra/2BSReQZdnH1yH+d8agwxEclyH OEPO119g3//MuDySCvH/hD54O9U6AvEN3myGKPbl9yI5r3/ZRzupzKGFUnTqXftA8rtd qRbw== X-Gm-Message-State: ANhLgQ3a7x6+J9jqYzVQT62udXo2KRIZFhGBAQIdmvU0IRBwWkqkXHyr rux01PHyJxPmlYiesu4h9VYVZaNJ X-Google-Smtp-Source: ADFU+vurbhZ14GfdzG2HOdCaLLjYD0KBQEzX6EZrD2nRvBhdUN5tyKWc3DnxvVrtu0U2TJ4frQSBSQ== X-Received: by 2002:a1c:b144:: with SMTP id a65mr2026034wmf.54.1585256263438; Thu, 26 Mar 2020 13:57:43 -0700 (PDT) Received: from [10.0.0.157] (bzq-79-178-60-210.red.bezeqint.net. [79.178.60.210]) by smtp.gmail.com with ESMTPSA id y187sm5393483wmd.0.2020.03.26.13.57.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2020 13:57:42 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Thu, 26 Mar 2020 22:57:40 +0200 From: Yaron Sheffer To: "txauth@ietf.org" Message-ID: <1D25B77D-7B4D-4D94-B19C-B9DAFCA71675@gmail.com> Thread-Topic: TxAuth at IETF-107, draft minutes Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3668108262_2166032833" Archived-At: Subject: [Txauth] TxAuth at IETF-107, draft minutes X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2020 20:58:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3668108262_2166032833 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I have uploaded the minutes from Etherpad here [1]. =20 Please note that I have formatted the text but did not edit it. If you feel= that something was omitted or misunderstood, please say so and we will make= corrections. A recording is available now at [2]. =20 Many thanks to the minutes takers: Bron Gondwana, Lee McGovern and Rob Wilt= on. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 [1] https://datatracker.ietf.org/meeting/107/materials/minutes-107-txauth-0= 0 [2] https://www.youtube.com/watch?v=3DTtLB51dD8QQ =20 --B_3668108262_2166032833 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I have uplo= aded the minutes from Etherpad here [1].

 

Please note that I have formatted the = text but did not edit it. If you feel that something was omitted or misunder= stood, please say so and we will make corrections. A recording is available = now at [2].

 

Many thanks to the minutes takers: Bron Gondwana, Lee McGovern and = Rob Wilton.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

[1] https://datatracker= .ietf.org/meeting/107/materials/minutes-107-txauth-00<= /p>

[2] https://www.youtube.com/watch?v=3DTtLB51dD8= QQ

 

--B_3668108262_2166032833-- From nobody Fri Mar 27 00:43:23 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1403A0F06 for ; Fri, 27 Mar 2020 00:43:21 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 4mz8zjTE5RvL for ; Fri, 27 Mar 2020 00:43:20 -0700 (PDT) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) (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 4CADE3A0F04 for ; Fri, 27 Mar 2020 00:43:20 -0700 (PDT) Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id Hje9jN1VaYFmaHjeAjyeJh; Fri, 27 Mar 2020 00:43:19 -0700 X-CMAE-Analysis: v=2.3 cv=doil9Go4 c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=ayghzAiDbuAreiuGkU8A:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 X-SECURESERVER-ACCT: vladimir@connect2id.com To: Dick Hardt , txauth@ietf.org Cc: Yaron Sheffer , Justin Richer References: From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: Date: Fri, 27 Mar 2020 09:43:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060309010503070109060508" X-CMAE-Envelope: MS4wfB2VbMdUr/A+Qaw4knKhi4Q4WRMGsRcVKJOW95uDojyMAmrtbmMzzuYxhmbod9lm/VV3edkp8LtWWPzYdmHQo1iiA+c/JkSJy939891d5CL63Kj/awtE vbQ+DisR+Pa1cLNrzBY8usqVC7hcUhgF377YOHfgjsKSxAkYQ+Cfew/WDp8/YPim8V++PBOLuzQTVL3urZQ7u0vqzepzS1K+07uu++7t0uzoz7W/ar4zks3I 80AVhfrgHVgA+EgadkyvNVtk0YZPS60iYo7bixHQfcc= Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 07:43:22 -0000 This is a cryptographically signed message in MIME format. --------------ms060309010503070109060508 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US What is the opinion about using formal analysis to back up the design process? Given the experience with OAuth 2.0 I think we can gain if we find a way and resources to involve formal analysis early on. So we don't end up in a regrettable situation to have to patch up the protocol after the fact. If there's general agreement on this I suggest it's included in the charter. Vladimir --------------ms060309010503070109060508 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMjcwNzQzMTdaMC8G CSqGSIb3DQEJBDEiBCDryUvVdp+ter9ppC6byoV75FzHOy/idKoLaUkMlm9gKDBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAJLlMmZpB0p9Gn+q4FAghFqGfKrU0pMaOErkjoW3q8VwQxyl fwxkthzyAx3ueDMBlktHe3KhMpGV1GILnXQIcqg36Rt9PdZzxBPY9oCw6OlddeK82krYwdow OfwuLlYCirgWxg4kWDQ9vxoE7PmcS3UUUr9MzT7f37AVJjcmOoHMcbOb+4P3yryGUnh6cW69 ytgk1toVTA84/GB5boaOQ0UaCsSl7NRuDJeV7bXiGTQRIQl8vGxRKGJvJAj7ArKi4AcJB6Fw HyNsrtnhpZjvqaEo7D/WzCjB2Wq+Lt1Ju7NBMZm4f1RtBcWbv/0nD0ueRhy4QihfHLnB/zcK 3UGqM6wAAAAAAAA= --------------ms060309010503070109060508-- From nobody Fri Mar 27 10:50:59 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F93A0FE4 for ; Fri, 27 Mar 2020 10:50:47 -0700 (PDT) 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 S2EIbWAW9XQG for ; Fri, 27 Mar 2020 10:50:46 -0700 (PDT) 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 B8C313A0F6D for ; Fri, 27 Mar 2020 10:50:37 -0700 (PDT) Received: from [192.168.1.5] (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 02RHoUaE008437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Mar 2020 13:50:31 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Fri, 27 Mar 2020 13:50:30 -0400 Cc: Dick Hardt , txauth@ietf.org, Yaron Sheffer Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 17:50:57 -0000 =46rom my perspective, it=E2=80=99s a valuable tool for the WG to use, = but putting it in the charter doesn=E2=80=99t make sense since it=E2=80=99= s not a deliverable and it=E2=80=99s not a problem space. The charter is = meant to guide what the WG works on (and doesn=E2=80=99t), not really = define how the WG works on it. The same as the automated testing that = Torsten was talking about =E2=80=94 still a very good thing, but not = really something appropriate for the charter. This is an argument to make with the chairs of the newly-chartered = group, when it=E2=80=99s formed. If this is something that we can build = into the group=E2=80=99s culture from early days, then it can really = help us a lot going forward, like automated testing and use case wikis = and things like that. =E2=80=94 Justin > On Mar 27, 2020, at 3:43 AM, Vladimir Dzhuvinov = wrote: >=20 > What is the opinion about using formal analysis to back up the design > process? >=20 > Given the experience with OAuth 2.0 I think we can gain if we find a = way > and resources to involve formal analysis early on. So we don't end up = in > a regrettable situation to have to patch up the protocol after the = fact. > If there's general agreement on this I suggest it's included in the > charter. >=20 > Vladimir >=20 >=20 From nobody Fri Mar 27 11:31:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94A03A0D26 for ; Fri, 27 Mar 2020 11:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 AKtG7fTRFw1w for ; Fri, 27 Mar 2020 11:31:43 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (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 C81A13A0D21 for ; Fri, 27 Mar 2020 11:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1585333904; x=1616869904; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=x4GCaBYO/6BxOe463nn+JvbQWGu2FxV8h3cJ5D2Diu4=; b=m5zLRCh8IbIkW6wihPwTYFcbgoD6wNJd4rEAr+01c0Y0e9DCMgq8JbZ2 85Up6trSeDPNewQki78E3GHnm2YmrSkTz6u0OAhBqEjhlbvCFhLk9IAzd WoEEMHZ6VnJ260fg0sMyMwhhIL6X5sIiknaBAkwKNfrAu9mf34p7/GII9 Y=; IronPort-SDR: nHDiyV4ppckl85iJESUFP4O3li0Cv2ArSL6aWE35M59vufqhjw2xe9TPvknk/mpMshVX6AU7vk PuIT2krzaTNQ== X-IronPort-AV: E=Sophos;i="5.72,313,1580774400"; d="scan'208";a="24483981" Thread-Topic: [Txauth] TxAuth Charter Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 27 Mar 2020 18:31:21 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-16acd5e0.us-east-1.amazon.com (Postfix) with ESMTPS id 35041A2D4F; Fri, 27 Mar 2020 18:31:18 +0000 (UTC) Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 27 Mar 2020 18:31:18 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Mar 2020 18:31:18 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Fri, 27 Mar 2020 18:31:18 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Vladimir Dzhuvinov , Yaron Sheffer , "txauth@ietf.org" , Dick Hardt Thread-Index: AQHWA6tJAV6nbc7F0UCa6BcAq8W2EKhbV3UAgAC39oCAAKmnAIAAC2YX Date: Fri, 27 Mar 2020 18:31:17 +0000 Message-ID: <4320E483-B581-4D53-93DC-A99EE2ABBD79@amazon.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 18:31:54 -0000 VGhlcmUgbWF5IGJlIHJvb20gaW4gdGhlIGNoYXJ0ZXIgdG8gaW5jbHVkZSB0ZXN0YWJpbGl0eSBh cyBhIHNlY29uZGFyeSBnb2FsLiBJbiBvdGhlciB3b3Jkcywgd2Ugc2hvdWxkIHN0cml2ZSB0byBw cm92aWRlIHRlc3RhYmxlIHNvbHV0aW9ucywgYnV0IG5vdCBhdCB0aGUgZXhwZW5zZSBvZiBmdW5j dGlvbmFsIHJlcXVpcmVtZW50cy4gSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBwcmVzY3JpYmUg c3BlY2lmaWMgdGVzdGluZyBtZXRob2RvbG9neSwgYXMgZGlmZmVyZW50IHRlY2huaWNhbCBzb2x1 dGlvbnMgbWF5IHJlcXVpcmUgZGlmZmVyZW5jZSBjaG9pY2VzIHRoZXJlLg0KDQrigJQNCkFubmFi ZWxsZSBCYWNrbWFuIChzaGUvaGVyKQ0KQVdTIElkZW50aXR5DQoNCj4gT24gTWFyIDI3LCAyMDIw LCBhdCAxMDo1MiBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCj4g DQo+IEZyb20gbXkgcGVyc3BlY3RpdmUsIGl04oCZcyBhIHZhbHVhYmxlIHRvb2wgZm9yIHRoZSBX RyB0byB1c2UsIGJ1dCBwdXR0aW5nIGl0IGluIHRoZSBjaGFydGVyIGRvZXNu4oCZdCBtYWtlIHNl bnNlIHNpbmNlIGl04oCZcyBub3QgYSBkZWxpdmVyYWJsZSBhbmQgaXTigJlzIG5vdCBhIHByb2Js ZW0gc3BhY2UuIFRoZSBjaGFydGVyIGlzIG1lYW50IHRvIGd1aWRlIHdoYXQgdGhlIFdHIHdvcmtz IG9uIChhbmQgZG9lc27igJl0KSwgbm90IHJlYWxseSBkZWZpbmUgaG93IHRoZSBXRyB3b3JrcyBv biBpdC4gVGhlIHNhbWUgYXMgdGhlIGF1dG9tYXRlZCB0ZXN0aW5nIHRoYXQgVG9yc3RlbiB3YXMg dGFsa2luZyBhYm91dCDigJQgc3RpbGwgYSB2ZXJ5IGdvb2QgdGhpbmcsIGJ1dCBub3QgcmVhbGx5 IHNvbWV0aGluZyBhcHByb3ByaWF0ZSBmb3IgdGhlIGNoYXJ0ZXIuDQo+IA0KPiBUaGlzIGlzIGFu IGFyZ3VtZW50IHRvIG1ha2Ugd2l0aCB0aGUgY2hhaXJzIG9mIHRoZSBuZXdseS1jaGFydGVyZWQg Z3JvdXAsIHdoZW4gaXTigJlzIGZvcm1lZC4gSWYgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCB3ZSBj YW4gYnVpbGQgaW50byB0aGUgZ3JvdXDigJlzIGN1bHR1cmUgZnJvbSBlYXJseSBkYXlzLCB0aGVu IGl0IGNhbiByZWFsbHkgaGVscCB1cyBhIGxvdCBnb2luZyBmb3J3YXJkLCBsaWtlIGF1dG9tYXRl ZCB0ZXN0aW5nIGFuZCB1c2UgY2FzZSB3aWtpcyBhbmQgdGhpbmdzIGxpa2UgdGhhdC4NCj4gDQo+ IOKAlCBKdXN0aW4NCj4gDQo+PiBPbiBNYXIgMjcsIDIwMjAsIGF0IDM6NDMgQU0sIFZsYWRpbWly IER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+IHdyb3RlOg0KPj4gDQo+PiBXaGF0 IGlzIHRoZSBvcGluaW9uIGFib3V0IHVzaW5nIGZvcm1hbCBhbmFseXNpcyB0byBiYWNrIHVwIHRo ZSBkZXNpZ24NCj4+IHByb2Nlc3M/DQo+PiANCj4+IEdpdmVuIHRoZSBleHBlcmllbmNlIHdpdGgg T0F1dGggMi4wIEkgdGhpbmsgd2UgY2FuIGdhaW4gaWYgd2UgZmluZCBhIHdheQ0KPj4gYW5kIHJl c291cmNlcyB0byBpbnZvbHZlIGZvcm1hbCBhbmFseXNpcyBlYXJseSBvbi4gU28gd2UgZG9uJ3Qg ZW5kIHVwIGluDQo+PiBhIHJlZ3JldHRhYmxlIHNpdHVhdGlvbiB0byBoYXZlIHRvIHBhdGNoIHVw IHRoZSBwcm90b2NvbCBhZnRlciB0aGUgZmFjdC4NCj4+IElmIHRoZXJlJ3MgZ2VuZXJhbCBhZ3Jl ZW1lbnQgb24gdGhpcyBJIHN1Z2dlc3QgaXQncyBpbmNsdWRlZCBpbiB0aGUNCj4+IGNoYXJ0ZXIu DQo+PiANCj4+IFZsYWRpbWlyDQo+PiANCj4+IA0KPiANCj4gLS0NCj4gVHhhdXRoIG1haWxpbmcg bGlzdA0KPiBUeGF1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90eGF1dGgNCg== From nobody Fri Mar 27 12:50:03 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8873A07B3 for ; Fri, 27 Mar 2020 12:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 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, MALFORMED_FREEMAIL=1.713, MIME_QP_LONG_LINE=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 YFQ-s6NJHQlu for ; Fri, 27 Mar 2020 12:49:59 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 598F43A07AD for ; Fri, 27 Mar 2020 12:49:59 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id s18so1093123qvn.1 for ; Fri, 27 Mar 2020 12:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=wOC7nDINO7r4dWjV2cRiUUJasnvy0f+VfgJ41Mg7Ay4=; b=WRIZjb64XKLkKh/CjLOibGZ4PDSPVHZZthsj4+KCgHhQtF83OqTzd7RO4BibIKVq0i 6F4La+dfpqGVN5x1Mhfz1cdmLHO4OXb90XnxS9OpENZ4rV2cZXCUpTP2UOGtbJKvtSev kY6hVhhld3nC8x05pJgr0bxKQIfbym5fo1wYRTvU9nwFiJR+D8I5SFNTvuRufGbFT7lb CIZSbLx5/8O4EKHqA2pzN4nky23OW0mYV+XVzTzGS0+orr6amRxJcp4Lv8mAWkrcjNrE V32N2buJsCcA0YZ6YpfuU0i0VtP5Ks2nPyf4CNgKUYcre0cDuLju0FPjqLiC8mwCnkam GjKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=wOC7nDINO7r4dWjV2cRiUUJasnvy0f+VfgJ41Mg7Ay4=; b=IsTR/iu3WUYqOnNoicr1A8qpzqiWVxgWafB9lgcOIpjKvjdT2j6NKOzuPi+vju7LZn MnnBeJJUDC638a+SOFly20zmHiyxSFENtMvkQ0K0Pn73RR6py1Q9yIW9OxB/qheQiHIe BxXXgy1YTvG9y262pEFr1w2wpYSIZkmnVo5Ikue6ha9djg/2BMNqMe3/kq33giE9UNPK d6PU6kDrQCv8YPfsNK1roLc8TTXKN6K+p56vqoWiFuqR3jRjjfBzw08xDfEC25IidRMc 3LU+D9FfjzOKopapfgwpLuItyKoofNQET4gurE0fw1Xw8yOJOQr8wZd29NuTTuEFd8wd 7N1g== X-Gm-Message-State: ANhLgQ29pUikHIaEiimFzV3DMmZOMIkdTbLEaqsMU5WUqqFO7vRNG6nF /mabjoGeuJSMVpiQqrCj+wA= X-Google-Smtp-Source: ADFU+vvbN/h7ko5vRrDIrP8WwB22tBavasDo2TwhRvGScvzvI0CHprZz/x4sC952STdqGuEK5XFmgw== X-Received: by 2002:a0c:f647:: with SMTP id s7mr964258qvm.4.1585338598224; Fri, 27 Mar 2020 12:49:58 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id x37sm4695276qtc.90.2020.03.27.12.49.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2020 12:49:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.35.20030802 Date: Fri, 27 Mar 2020 22:49:51 +0300 From: Yaron Sheffer To: "Richard Backman, Annabelle" , Justin Richer CC: Vladimir Dzhuvinov , "txauth@ietf.org" , Dick Hardt Message-ID: Thread-Topic: [Txauth] TxAuth Charter References: <4320E483-B581-4D53-93DC-A99EE2ABBD79@amazon.com> In-Reply-To: <4320E483-B581-4D53-93DC-A99EE2ABBD79@amazon.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 19:50:02 -0000 TLS 1.3 is much more credible because they insisted on thorough formal anal= ysis of the protocol. I'm very much for encouraging such analysis. But I'm o= n the fence when it comes to adding it to the charter, because it's an exter= nal dependency: we would need to get external experts (=3Dacademy) interested = and wait for them to complete what is often lengthy and complicated analysis= . Thanks, Yaron =EF=BB=BFOn 3/27/20, 21:31, "Richard Backman, Annabelle" wr= ote: There may be room in the charter to include testability as a secondary = goal. In other words, we should strive to provide testable solutions, but no= t at the expense of functional requirements. I don=E2=80=99t think we should presc= ribe specific testing methodology, as different technical solutions may requ= ire difference choices there. =20 =E2=80=94 Annabelle Backman (she/her) AWS Identity =20 > On Mar 27, 2020, at 10:52 AM, Justin Richer wrote: >=20 > From my perspective, it=E2=80=99s a valuable tool for the WG to use, but pu= tting it in the charter doesn=E2=80=99t make sense since it=E2=80=99s not a deliverable = and it=E2=80=99s not a problem space. The charter is meant to guide what the WG wo= rks on (and doesn=E2=80=99t), not really define how the WG works on it. The same a= s the automated testing that Torsten was talking about =E2=80=94 still a very good= thing, but not really something appropriate for the charter. >=20 > This is an argument to make with the chairs of the newly-chartered gr= oup, when it=E2=80=99s formed. If this is something that we can build into the gro= up=E2=80=99s culture from early days, then it can really help us a lot going forwa= rd, like automated testing and use case wikis and things like that. >=20 > =E2=80=94 Justin >=20 >> On Mar 27, 2020, at 3:43 AM, Vladimir Dzhuvinov wrote: >>=20 >> What is the opinion about using formal analysis to back up the desig= n >> process? >>=20 >> Given the experience with OAuth 2.0 I think we can gain if we find a= way >> and resources to involve formal analysis early on. So we don't end u= p in >> a regrettable situation to have to patch up the protocol after the f= act. >> If there's general agreement on this I suggest it's included in the >> charter. >>=20 >> Vladimir >>=20 >>=20 >=20 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth =20 From nobody Sat Mar 28 02:09:56 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3523A0E31 for ; Sat, 28 Mar 2020 02:09:54 -0700 (PDT) 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, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.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 Ky483Ry2rfBZ for ; Sat, 28 Mar 2020 02:09:53 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53FCF3A0E37 for ; Sat, 28 Mar 2020 02:09:53 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 94D141CF5 for ; Sat, 28 Mar 2020 09:09:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1585386591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EbanQx9kH9+qS71JT3dReH4AhknQYK/z0zl4anXaTyI=; b=R3dCqkYS2alqLPpWuCaw4ihsBMWpnKJb9xNGpPwB0QueAW4t/QSonYWifB0xHSCQrM8Dwt xA51k+CbxyAE2W4Vlrvt2bejKNERH1ezfZB1D+jQrVfq8GG51q3o8427/bjJOYauzS70rp ivhkAEqfcloHMlzTXliYXbn3cTOgSpU= To: txauth@ietf.org References: <4320E483-B581-4D53-93DC-A99EE2ABBD79@amazon.com> From: Daniel Fett Message-ID: <5580e7c4-bc78-c559-35ff-d7fcc07c046f@danielfett.de> Date: Sat, 28 Mar 2020 10:08:24 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF7515811E2FEA5729FF035E" Content-Language: de-AT-frami ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1585386591; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EbanQx9kH9+qS71JT3dReH4AhknQYK/z0zl4anXaTyI=; b=VepB8Sewu2L42YduVlATXVj/xteCqkZgQ4b4oRa4tuWdP16wr+Xj1z0u1vzzMNyWtCHRie CLI2f8hcFwlH8NW7SuVrYw8X5A5sCFfF7atdpQ6XOQOjAskbOQAOeLxHHMqpDW3r59zM+b rRo3BbfEm7CimzCSdfi37akxPagsZ+Q= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1585386591; a=rsa-sha256; cv=none; b=VHhRLdW71QHGl4w6h3fddK0d6Bz1iDzXGvVYqBLmezpdji0rMXXGeNVzLafY5522Brxbhv Gaa6YeHkfEdrBX9qGjfziTKuAz51lolxkVfkgpJhET5NlH1ZDMRYiX72NJUcXVz2ayaZ5F vekaWpVoP7mp9a4kiMelxRUERv8oBbs= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 09:09:55 -0000 This is a multi-part message in MIME format. --------------DF7515811E2FEA5729FF035E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Am 27.03.20 um 20:49 schrieb Yaron Sheffer: > TLS 1.3 is much more credible because they insisted on thorough formal analysis of the protocol. I'm very much for encouraging such analysis. But I'm on the fence when it comes to adding it to the charter, because it's an external dependency: we would need to get external experts (=academy) interested and wait for them to complete what is often lengthy and complicated analysis. I think that any new, sufficiently complex protocol should come with a formal security analysis. (To the suprise of no one ;-) .) Experience with other protocols has shown that it is just too easy to overlook even simple security flaws. To be effective, a formal analysis must not stand at the end of the protocol design process. For TLS 1.3, researchers were involved from the very beginning and they influenced key decisions in the design of the protocol. (As a side effect, they enforced a clearly written specification, as ambiguous phrasing makes formal analysis much harder.) Formal analysis takes time, particularly so in the Web and mobile application setting. As of today, there are no software tools that are suitable for an in-depth analysis of web and mobile application protocols. Pen-and-paper proofs are detailed, often easier to comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web Infrastructure Model"). I share the sentiments of Yaron regarding the charter. I propose to put it into the charter as something that the group aims to do, but not as a MUST, i.e., "The group seeks the cooperation with researchers for a formal verification of the security of the protocol." (or "should seek" or something) If there is sufficient support in this group for such a cooperation (be it written in the charter or not), I am willing to lead these efforts and to get in touch with the respective research groups. -Daniel --------------DF7515811E2FEA5729FF035E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 27.03.20 um 20:49 schrieb Yaron Sheffer:
TLS 1.3 is much more credible because they insisted on thorough formal analysis of the protocol. I'm very much for encouraging such analysis. But I'm on the fence when it comes to adding it to the charter, because it's an external dependency: we would need to get external experts (=academy) interested and wait for them to complete what is often lengthy and complicated analysis.

I think that any new, sufficiently complex protocol should come with a formal security analysis. (To the suprise of no one ;-) .)

Experience with other protocols has shown that it is just too easy to overlook even simple security flaws.

To be effective, a formal analysis must not stand at the end of the protocol design process. For TLS 1.3, researchers were involved from the very beginning and they influenced key decisions in the design of the protocol. (As a side effect, they enforced a clearly written specification, as ambiguous phrasing makes formal analysis much harder.) Formal analysis takes time, particularly so in the Web and mobile application setting. As of today, there are no software tools that are suitable for an in-depth analysis of web and mobile application protocols. Pen-and-paper proofs are detailed, often easier to comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web Infrastructure Model").

I share the sentiments of Yaron regarding the charter. I propose to put it into the charter as something that the group aims to do, but not as a MUST, i.e.,

"The group seeks the cooperation with researchers for a formal verification of the security of the protocol." (or "should seek" or something)


If there is sufficient support in this group for such a cooperation (be it written in the charter or not), I am willing to lead these efforts and to get in touch with the respective research groups.

-Daniel


--------------DF7515811E2FEA5729FF035E-- From nobody Sat Mar 28 08:20:09 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5463D3A0995 for ; Sat, 28 Mar 2020 08:20:08 -0700 (PDT) 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 gIRUkXDVxYMV for ; Sat, 28 Mar 2020 08:20:06 -0700 (PDT) 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 A3E563A0E13 for ; Sat, 28 Mar 2020 08:20:04 -0700 (PDT) Received: from [192.168.1.13] (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 02SFJxRt029587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Mar 2020 11:20:00 -0400 From: Justin Richer Message-Id: <69D5A43F-C4B4-4795-82DE-27D9685728ED@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_91A58CA6-D72A-4E3E-B545-171D090F454B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 28 Mar 2020 11:19:59 -0400 In-Reply-To: <5580e7c4-bc78-c559-35ff-d7fcc07c046f@danielfett.de> Cc: txauth@ietf.org To: Daniel Fett References: <4320E483-B581-4D53-93DC-A99EE2ABBD79@amazon.com> <5580e7c4-bc78-c559-35ff-d7fcc07c046f@danielfett.de> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 15:20:08 -0000 --Apple-Mail=_91A58CA6-D72A-4E3E-B545-171D090F454B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that the more analysis we can do on this protocol from an early = stage the better off we=E2=80=99ll be in the end. So many of OAuth 2=E2=80= =99s problems come from a feature or option inadvertently opening up a = hole that we might have been able to see coming. This is hindsight = conjecture, of course, but it would be silly of us to do the same thing = and expect different results. :) I=E2=80=99m still not keen on making it a requirement in the charter for = the reasons stated before. However, I would be amenable to such language = as =E2=80=9CThe group will seek=E2=80=A6=E2=80=9D so as to show intent = and not requirement tied to a deliverable. The same way we=E2=80=99ll = seek to make things not horrible for porting to COAP or other protocol = stacks, if someone wants to do that in the future (which I think likely = as well). Big thanks to Daniel offering to lead this effort! =E2=80=94 Justin > On Mar 28, 2020, at 5:08 AM, Daniel Fett wrote: >=20 > Am 27.03.20 um 20:49 schrieb Yaron Sheffer: >> TLS 1.3 is much more credible because they insisted on thorough = formal analysis of the protocol. I'm very much for encouraging such = analysis. But I'm on the fence when it comes to adding it to the = charter, because it's an external dependency: we would need to get = external experts (=3Dacademy) interested and wait for them to complete = what is often lengthy and complicated analysis. > I think that any new, sufficiently complex protocol should come with a = formal security analysis. (To the suprise of no one ;-) .) >=20 > Experience with other protocols has shown that it is just too easy to = overlook even simple security flaws. >=20 > To be effective, a formal analysis must not stand at the end of the = protocol design process. For TLS 1.3, researchers were involved from the = very beginning and they influenced key decisions in the design of the = protocol. (As a side effect, they enforced a clearly written = specification, as ambiguous phrasing makes formal analysis much harder.) = Formal analysis takes time, particularly so in the Web and mobile = application setting. As of today, there are no software tools that are = suitable for an in-depth analysis of web and mobile application = protocols. Pen-and-paper proofs are detailed, often easier to = comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth = 2.0 both took about 6 months using the "Web Infrastructure Model"). >=20 > I share the sentiments of Yaron regarding the charter. I propose to = put it into the charter as something that the group aims to do, but not = as a MUST, i.e.,=20 >=20 > "The group seeks the cooperation with researchers for a formal = verification of the security of the protocol." (or "should seek" or = something) >=20 >=20 >=20 > If there is sufficient support in this group for such a cooperation = (be it written in the charter or not), I am willing to lead these = efforts and to get in touch with the respective research groups. >=20 > -Daniel >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_91A58CA6-D72A-4E3E-B545-171D090F454B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I agree that the more analysis we can do on this protocol = from an early stage the better off we=E2=80=99ll be in the end. So many = of OAuth 2=E2=80=99s problems come from a feature or option = inadvertently opening up a hole that we might have been able to see = coming. This is hindsight conjecture, of course, but it would be silly = of us to do the same thing and expect different results. :)

I=E2=80=99m still not keen on making it = a requirement in the charter for the reasons stated before. However, I = would be amenable to such language as =E2=80=9CThe group will seek=E2=80=A6= =E2=80=9D so as to show intent and not requirement tied to a = deliverable. The same way we=E2=80=99ll seek to make things not horrible = for porting to COAP or other protocol stacks, if someone wants to do = that in the future (which I think likely as well).

Big thanks to Daniel offering to lead = this effort!

 =E2=80=94 Justin

On Mar = 28, 2020, at 5:08 AM, Daniel Fett <fett@danielfett.de> = wrote:

=20
Am 27.03.20 um 20:49 schrieb Yaron Sheffer:
TLS 1.3 is much more =
credible because they insisted on thorough formal analysis of the =
protocol. I'm very much for encouraging such analysis. But I'm on the =
fence when it comes to adding it to the charter, because it's an =
external dependency: we would need to get external experts (=3Dacademy) =
interested and wait for them to complete what is often lengthy and =
complicated analysis.

I think that any new, sufficiently = complex protocol should come with a formal security analysis. (To the suprise of no one ;-) = .)

Experience with other protocols has shown that it = is just too easy to overlook even simple security flaws.

To be effective, a formal analysis must not stand = at the end of the protocol design process. For TLS 1.3, researchers were involved from the very beginning and they influenced key decisions in the design of the protocol. (As a side effect, they enforced a clearly written specification, as ambiguous phrasing makes formal analysis much harder.) Formal analysis takes time, particularly so in the Web and mobile application setting. As of today, there are no software tools that are suitable for an in-depth analysis of web and mobile application protocols. Pen-and-paper proofs are detailed, often easier to comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web Infrastructure Model").

I share the sentiments of Yaron regarding the = charter. I propose to put it into the charter as something that the group aims to do, but not as a MUST, i.e.,

"The group seeks the cooperation with researchers = for a formal verification of the security of the protocol." (or "should seek" or something)


If there is sufficient support in this group for = such a cooperation (be it written in the charter or not), I am willing to lead these efforts and to get in touch with the respective research groups.

-Daniel


--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_91A58CA6-D72A-4E3E-B545-171D090F454B-- From nobody Sat Mar 28 08:45:41 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2B3A0ED0 for ; Sat, 28 Mar 2020 08:45:38 -0700 (PDT) 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_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=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 gQmIDgJHm0x7 for ; Sat, 28 Mar 2020 08:45:36 -0700 (PDT) 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 D5FC53A0ECF for ; Sat, 28 Mar 2020 08:45:35 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id r24so13324937ljd.4 for ; Sat, 28 Mar 2020 08:45:35 -0700 (PDT) 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=Hb4ihXNVy1dJlJZhJBVTGJooanjOukafyovu8PX95ts=; b=rFm/av2u0hkVEPTFqRL8oGrRF2ppq5VEk5hVZdCS88jK/IiFfu1fhGwJaBYx0e2qNC Uo9kLGW1Hh1J3HQS/3cQG8D2CWd3IY72PXlmTuaE0rLf8FRMCrNHJ3U8SBtgvRmfW6IB xGnqVxuFvK1oejCXevakntS+BAn/EygCpDOwCFygFB/rtg4AsZE2D4NnZjV0vEuqIjui 1+/wGzOmW3X1wLQvkF1Nx/qct0U0WICxPwE/DIqtaQDl4GnAtZiqZAF86zKCooouSy11 T0E5/O9y4z5ZE4kiHoyekXUQhG1JJR46unjAsTMDbjlR8HNUBl2KXr13yFBalQyXSww6 8hfA== 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=Hb4ihXNVy1dJlJZhJBVTGJooanjOukafyovu8PX95ts=; b=W7yKpkEEXxUlnsRoxtEKvmQj/C32syuwdHwq7001CyhFXBXhrwzL3dmMenTwGwbzRk XD7L3YtMr8cEFy5UE2mPFTiYdBn2Pr2vi3kY/Xi2fKndM9STSpJPgrgz4DyvxZqQBtmq Dn8Wb5t8d2r9kspmnZ8hWdzP2a3GTpDz8Q2avASp6gjlg4zCeu4S93NeFu8jmYXUQtHV j5buTmHI7YXAc3PanFRNOv+cTf/MFW1lokYDK1UyUVP/lHV8FpAbvSslqms1eDNJTTW2 QqqO4LGY3aAogx6iENW7LlPHbOcMgzyoQm2swJFRFrBvXPpjK5qJoVz4/LdjvYGOZljf vG/w== X-Gm-Message-State: AGi0PuZ4yxX509eDWIN7NEgBsSyVxgasK1jjd2VJosl3Lfnzln2iWn0N whvsn8EWAAdC0I1XXVFypCzfoIZhqkrC2l0BMdYMoK9v X-Google-Smtp-Source: APiQypJN/+idG9VMrMDoaZZviEEv/JCVxy+4CyfXJfooC1B2angJ4nriQmIncjh4GLd76adOt6LbnX+0QHJoFLbW2s4= X-Received: by 2002:a2e:988c:: with SMTP id b12mr2547043ljj.138.1585410333305; Sat, 28 Mar 2020 08:45:33 -0700 (PDT) MIME-Version: 1.0 References: <4320E483-B581-4D53-93DC-A99EE2ABBD79@amazon.com> <5580e7c4-bc78-c559-35ff-d7fcc07c046f@danielfett.de> <69D5A43F-C4B4-4795-82DE-27D9685728ED@mit.edu> In-Reply-To: <69D5A43F-C4B4-4795-82DE-27D9685728ED@mit.edu> From: Dick Hardt Date: Sat, 28 Mar 2020 08:45:07 -0700 Message-ID: To: Justin Richer Cc: Daniel Fett , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000bd712f05a1ec1bee" Archived-At: Subject: Re: [Txauth] TxAuth Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 15:45:39 -0000 --000000000000bd712f05a1ec1bee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to adding the intention of formal analysis to the charter Thanks Daniel for volunteering to lead the effort! =E1=90=A7 On Sat, Mar 28, 2020 at 8:20 AM Justin Richer wrote: > I agree that the more analysis we can do on this protocol from an early > stage the better off we=E2=80=99ll be in the end. So many of OAuth 2=E2= =80=99s problems > come from a feature or option inadvertently opening up a hole that we mig= ht > have been able to see coming. This is hindsight conjecture, of course, bu= t > it would be silly of us to do the same thing and expect different results= . > :) > > I=E2=80=99m still not keen on making it a requirement in the charter for = the > reasons stated before. However, I would be amenable to such language as > =E2=80=9CThe group will seek=E2=80=A6=E2=80=9D so as to show intent and n= ot requirement tied to a > deliverable. The same way we=E2=80=99ll seek to make things not horrible = for > porting to COAP or other protocol stacks, if someone wants to do that in > the future (which I think likely as well). > > Big thanks to Daniel offering to lead this effort! > > =E2=80=94 Justin > > On Mar 28, 2020, at 5:08 AM, Daniel Fett wrote: > > Am 27.03.20 um 20:49 schrieb Yaron Sheffer: > > TLS 1.3 is much more credible because they insisted on thorough formal an= alysis of the protocol. I'm very much for encouraging such analysis. But I'= m on the fence when it comes to adding it to the charter, because it's an e= xternal dependency: we would need to get external experts (=3Dacademy) inte= rested and wait for them to complete what is often lengthy and complicated = analysis. > > I think that any new, sufficiently complex protocol should come with a > formal security analysis. (To the suprise of no one ;-) ..) > > Experience with other protocols has shown that it is just too easy to > overlook even simple security flaws. > > To be effective, a formal analysis must not stand at the end of the > protocol design process. For TLS 1.3, researchers were involved from the > very beginning and they influenced key decisions in the design of the > protocol. (As a side effect, they enforced a clearly written specificatio= n, > as ambiguous phrasing makes formal analysis much harder.) Formal analysis > takes time, particularly so in the Web and mobile application setting. As > of today, there are no software tools that are suitable for an in-depth > analysis of web and mobile application protocols. Pen-and-paper proofs ar= e > detailed, often easier to comprehend, and thorough, but take a lot of tim= e > (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web > Infrastructure Model"). > > I share the sentiments of Yaron regarding the charter. I propose to put i= t > into the charter as something that the group aims to do, but not as a MUS= T, > i.e., > > "The group seeks the cooperation with researchers for a formal > verification of the security of the protocol." (or "should seek" or > something) > > > If there is sufficient support in this group for such a cooperation (be i= t > written in the charter or not), I am willing to lead these efforts and to > get in touch with the respective research groups. > > -Daniel > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000bd712f05a1ec1bee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to adding the intention of formal analysis to the chart= er

Thanks Daniel for volunteering to lead the effort= !
=E1=90=A7

On Sat, Mar 28, 2020 at 8:20 AM Jus= tin Richer <jricher@mit.edu> w= rote:
I agree that the more analysis we can = do on this protocol from an early stage the better off we=E2=80=99ll be in = the end. So many of OAuth 2=E2=80=99s problems come from a feature or optio= n inadvertently opening up a hole that we might have been able to see comin= g. This is hindsight conjecture, of course, but it would be silly of us to = do the same thing and expect different results. :)

I=E2= =80=99m still not keen on making it a requirement in the charter for the re= asons stated before. However, I would be amenable to such language as =E2= =80=9CThe group will seek=E2=80=A6=E2=80=9D so as to show intent and not re= quirement tied to a deliverable. The same way we=E2=80=99ll seek to make th= ings not horrible for porting to COAP or other protocol stacks, if someone = wants to do that in the future (which I think likely as well).

Big thanks to Daniel offering to lead this effort!

=C2=A0=E2=80=94 Justin

On = Mar 28, 2020, at 5:08 AM, Daniel Fett <fett@danielfett.de> wrote:

=20
Am 27.03.20 um 20:49 schrieb Yaron Sheffer:
TLS 1.3 is much more credible because they insisted on thorough =
formal analysis of the protocol. I'm very much for encouraging such ana=
lysis. But I'm on the fence when it comes to adding it to the charter, =
because it's an external dependency: we would need to get external expe=
rts (=3Dacademy) interested and wait for them to complete what is often len=
gthy and complicated analysis.

I think that any new, sufficiently complex protocol sho= uld come with a formal security analysis. (To the suprise of no one ;-) ..)

Experience with other protocols has shown that it is just too easy to overlook even simple security flaws.

To be effective, a formal analysis must not stand at the end of the protocol design process. For TLS 1.3, researchers were involved from the very beginning and they influenced key decisions in the design of the protocol. (As a side effect, they enforced a clearly written specification, as ambiguous phrasing makes formal analysis much harder.) Formal analysis takes time, particularly so in the Web and mobile application setting. As of today, there are no software tools that are suitable for an in-depth analysis of web and mobile application protocols. Pen-and-paper proofs are detailed, often easier to comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web Infrastructure Model").

I share the sentiments of Yaron regarding the charter. I propose to put it into the charter as something that the group aims to do, but not as a MUST, i.e.,

"The group seeks the cooperation with researchers for a for= mal verification of the security of the protocol." (or "should = seek" or something)


If there is sufficient support in this group for such a cooperation (be it written in the charter or not), I am willing to lead these efforts and to get in touch with the respective research groups.

-Daniel


--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000bd712f05a1ec1bee-- From nobody Sat Mar 28 19:47:10 2020 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A83A0E9B for ; Sat, 28 Mar 2020 19:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 DfOqy80AAlU3 for ; Sat, 28 Mar 2020 19:47:04 -0700 (PDT) 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 AF9643A0E99 for ; Sat, 28 Mar 2020 19:47:04 -0700 (PDT) Received: from [192.168.1.13] (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 02T2l23P025835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 28 Mar 2020 22:47:03 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_892BCA64-B104-408D-A792-ED1D88E6E41F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: References: <158544959207.7396.11734868070230309987@ietfa.amsl.com> To: txauth@ietf.org Date: Sat, 28 Mar 2020 22:47:02 -0400 X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] Fwd: New Version Notification for draft-richer-transactional-authz-07.txt X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 02:47:09 -0000 --Apple-Mail=_892BCA64-B104-408D-A792-ED1D88E6E41F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As requested in another thread, I did a quick revision to the XYZ draft = to mark that the fields on the various parts of the draft as being = controlled by some registry mechanism, the details TBD. Hopefully this = clarifies the intent of the draft as not to create a single, static = means of defining everything, but instead to create a baseline on which = to build new functionality in a number of different directions. For = TxAuth, it=E2=80=99s possible that the WG will choose to re-use an = existing registry for some of these as well. XYZ isn=E2=80=99t trying to = make that decision one way or the other right now. =E2=80=94 Justin > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-richer-transactional-authz-07.txt > Date: March 28, 2020 at 10:39:52 PM EDT > To: "Justin Richer" >=20 >=20 > A new version of I-D, draft-richer-transactional-authz-07.txt > has been successfully submitted by Justin Richer and posted to the > IETF repository. >=20 > Name: draft-richer-transactional-authz > Revision: 07 > Title: Transactional Authorization > Document date: 2020-03-28 > Group: Individual Submission > Pages: 34 > URL: = https://www.ietf.org/internet-drafts/draft-richer-transactional-authz-07.t= xt > Status: = https://datatracker.ietf.org/doc/draft-richer-transactional-authz/ > Htmlized: = https://tools.ietf.org/html/draft-richer-transactional-authz-07 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-richer-transactional-authz > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-richer-transactional-authz-07 >=20 > Abstract: > This document defines a mechanism for delegating authorization to a > piece of software, and conveying that delegation to the software. >=20 >=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 --Apple-Mail=_892BCA64-B104-408D-A792-ED1D88E6E41F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = requested in another thread, I did a quick revision to the XYZ draft to = mark that the fields on the various parts of the draft as being = controlled by some registry mechanism, the details TBD. Hopefully this = clarifies the intent of the draft as not to create a single, static = means of defining everything, but instead to create a baseline on which = to build new functionality in a number of different directions. For = TxAuth, it=E2=80=99s possible that the WG will choose to re-use an = existing registry for some of these as well. XYZ isn=E2=80=99t trying to = make that decision one way or the other right now.

 =E2=80=94 Justin

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-richer-transactional-authz-07.txt
Date: = March 28, 2020 at 10:39:52 PM = EDT
To: = "Justin Richer" <ietf@justin.richer.org>


A new version = of I-D, draft-richer-transactional-authz-07.txt
has been = successfully submitted by Justin Richer and posted to the
IETF repository.

Name: = draft-richer-transactional-authz
Revision: 07
Title:= = Transactional Authorization
Document date: = 2020-03-28
Group: Individual Submission
Pages:= = 34
URL: =            https://www.ietf.org/internet-drafts/draft-richer-transactional= -authz-07.txt
Status: =         https://datatracker.ietf.org/doc/draft-richer-transactional-aut= hz/
Htmlized:       https://tools.ietf.org/html/draft-richer-transactional-authz-07=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richer-transactiona= l-authz
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-richer-transactional-= authz-07

Abstract:
=   This document defines a mechanism for delegating = authorization to a
  piece of software, and = conveying that delegation to the software.





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



= --Apple-Mail=_892BCA64-B104-408D-A792-ED1D88E6E41F--
On Mon, Mar 23, 2020 at 1:39 PM Mike Jones <Michael.Jone= s=3D40microsoft.com@dmarc= .ietf.org> wrote:

In brainstorming = mode=E2=80=A6

  • Disaggregated Authorization (DisAuth)
  • Componentized Authorization (CompAuth)
  • Build-Your-Own Authorization (BYOAuth)
  • Do-It-Yourself Authorization (DIYAuth)
  • Refactored Authorization (ReAuth or RefAuth)

=C2=A0<= /u>

And for fun=E2=80= =A6

  • Dismembered Authorization

=C2=A0<= /u>

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

=C2=A0<= /u>

From: Txauth <txauth-bounces@ietf.org> On Beha= lf Of David Skaife
Sent: Saturday, March 21, 2020 11:22 AM
To: Justin Richer <jricher@mit.edu>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; txauth@ietf.org; Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Txauth] WG name: TxAuth? XAuth? Something else?=

=C2=A0

I think we're saying the same thing with regards= to the working group name - I was saying it isn't particularly important in comparison to the name of the pr= otocol (which obviously is very important).

=C2=A0

On Sat, Mar 21, 2020 at 6:18 PM Justin Richer <jricher@mit.edu> = wrote:

I disagree on the working group name being super imp= ortant. Nobody knows that the OAuth WG is actually named =E2=80=9CThe Web A= uthorization Protocol Working Group=E2=80=9D, and nobody cares.

=C2=A0

My proposal is that we name the protocol we work on = =E2=80=9CTxAuth=E2=80=9D (and keep the mailing list), and that we name the = working group something like =E2=80=9CNext Generation Web Authorization Pro= tocol=E2=80=9D to say what we=E2=80=99re doing.

=C2=A0

=C2=A0-- Justin



On Mar 21, 2020, at 2:08 PM, David Skaife <blue.ringe= d.octopus.guy@gmail.com> wrote:

=C2=A0

Just to throw in another suggestion, to address Yaro= n's point about some people mistakenly thinking that "Auth" s= tands for authentication rather than authorization, how about naming the wo= rking group AuthZ

Nice and simple, and it makes it clear what the grou= p is focused on.

I think the name of the actual protocol that we produce is far, far more im= portant that the name of the working group - and the name of that protocol = doesn't need to correlate to the WG name. Also, we have much more time = before we need to decide on the name of that protocol, even if the initial=C2=A0draft documents that we produce= end up using a placeholder name.

=C2=A0

On Sat, Mar 21, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> = wrote:

As you can see in the email you replied to, that is = not even close to what I said. I believe it is a transaction, and therefore= , I do not agree that it=E2=80=99s not a transaction.

=C2=A0

But if we take =E2=80=9CTransactional=E2=80=9D out o= f the WG title, I won=E2=80=99t be offended. If we just call it =E2=80=9CTx= Auth=E2=80=9D without expansion, then that=E2=80=99s fine.

=C2=A0

I do not like calling it =E2=80=9CXAuth=E2=80=9D. Th= e term =E2=80=9CTAuth" was floated during naming the list, but rejecte= d because (among other reasons) it would likely be awkwardly pronounced as = =E2=80=9Ctowth=E2=80=9D or something. TxAuth reads as =E2=80=9CTee - ex - o= th=E2=80=9D more naturally, which was the intent.=C2=A0

=C2=A0

So how about we take a page from the OAuth working g= roup and name it:

=C2=A0

TxAuth - Next Generation Web Authorization Protocol = Working Group

=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 21, 2020, at 1:15 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

To clarify -- you agree it is not a transaction, and= we will take the word transaction out of the WG title?

=C2=A0

On Fri, Mar 20, 2020 at 5:53 PM Justin Richer <jricher@mit.edu> = wrote:

Dick, thanks for pulling the definitions up:<= u>

=C2=A0

>=C2=A0a communicative action or activity involving two parties or things that = reciprocally affect or influence each other

=C2=A0

This is the kind of thing that I had in mind. The cl= ient and the AS are in a conversation over time that each one contributes t= o and each changes.=C2=A0

=C2=A0

Also =E2=80=94 we can just as easily decide that =E2= =80=9CTxAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9CTransactional Auth= =E2=80=9D much the same way we decided that the =E2=80=9CO=E2=80=9D in =E2= =80=9COAuth=E2=80=9D doesn=E2=80=99t stand for =E2=80=9COpen=E2=80=9D anymo= re.=C2=A0

=C2=A0

None of the arguments below in favor of XAuth have m= ade me like that name better. If it=E2=80=99s just a =E2=80=9Cplaceholder= =E2=80=9D name, then why come up with something new?

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 20, 2020, at 3:32 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

not a transaction - there are multiple transactions<= u>

=C2=A0

backchannel innovation is combination=C2=A0of here i= s who I am, and here is what I want to do

=C2=A0

=C2=A0

childhood trauma therapy group

=C2=A0

=C2=A0

=C2=A0

On Mon, Mar 16, 2020 at 6:56 PM Justin Richer <jricher@mit.edu> = wrote:

Yes, naming things is hard =E2=80=94 but I still bel= ieve in the name TxAuth. We=E2=80=99re moving beyond OAuth, and taking the = process of getting an authorization delegated to the client software as a m= ulti-step, multi-party transaction is, I believe, the key insight that=E2=80=99s letting us move beyond OAuth=E2=80=99s limi= tations here. It=E2=80=99s not just about going to the AS first =E2=80=94 w= e had that in OAuth 1 and we=E2=80=99re patching that into OAuth 2 with PAR= . I really think it=E2=80=99s about the transaction at the core..=C2=A0<= /u>

=C2=A0

OAuth 2.0 had multi-step, multi-party. TxAuth extend= s that.

=C2=A0

I think the big shift is going to the AS. This enabl= es the request to be richer with JSON, instead of name/value pairs paramete= rs in a URI. It allows the client and AS to negotiate, and to short circuit= having to redirect the user to the AS. PAR does=C2=A0some of this, but it is constrained by having to do it i= n the OAuth 2.0 context.

=C2=A0

My concern is that the protocol is MUCH MORE than a = transaction. While the initial interaction between client, AS, user and RO = is a transaction. The protocol also covers the client=C2=A0and RS interacti= ons. The access token refreshes. Access token revocation. Access token introspection. As described in the charter,= there is a whole lifecycle, that consists of multiple transactions.=

=C2=A0

=C2=A0

Definition of=C2=A0transaction

1a:=C2=A0something=C2=A0transactedespecially=C2=A0:=C2=A0an exchange or=C2=A0transfer=C2=A0of goods, services, or fundselectronic=C2=A0transactions

b:=C2=A0transactions=C2=A0plural= =C2=A0:=C2=A0the often published record of the meeting of a society or association

2a:=C2=A0an act, process, or instance of=C2=A0transacting

b:=C2=A0a communicative action or activity involving two parties or things that reci= procally affect or influence each other

=C2=A0

Calling the protocol a transaction will confusing to= people.

=C2=A0

=C2=A0

Having come of age in the 1990=E2=80=99s, I have par= ticular dislike for XAuth. It sounds too =E2=80=9CX-TREME=E2=80=9D and =E2= =80=9CX-CITING=E2=80=9D, and if you read either of those with a growling ye= ll in your head then you know exactly what I=E2=80=99m talking about.

=C2=A0

In case you are confused, this is not a childhood=C2= =A0trauma support group.=C2=A0 :)

=C2=A0

Unlike "X-TREME" or "X-CITING", = XAuth is using the "X" as a placeholder. X-Men, Xbox, X-Factor, X= -files.=C2=A0

=C2=A0

=C2=A0

=C2=A0

And to Dick=E2=80=99s rationale for the name below, = I absolutely do NOT see this work as =E2=80=9COAuth with all the extra feat= ures=E2=80=9D. I think that does a disservice to the kind of change we have= an opportunity to make here.=C2=A0

=C2=A0

From the charter=C2=A0

=C2=A0

"It will expand upon the uses cases currently s= upported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0)= "

=C2=A0

Which sounds pretty similar to=C2=A0=E2=80=9COAuth w= ith all the extra features=E2=80=9D

=C2=A0

While I think XAuth captures what we are doing, a pl= aceholder name would be preferable to an incorrect descriptive name such as= TxAuth.

=C2=A0

For example, XYZ is a g= ood placeholder name. Or XYZAuth. Let's not mislead people.

=C2=A0

=C2=A0

=C2=A0=E2=80=94 Justin



On Mar 16, 2020, at 7:04 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Hello everyone

=C2=A0

I prompted a thread around the name of the protocol = a while back:

=C2=A0

=C2=A0

As Justin stated "naming is hard"

=C2=A0

Wearing my marketing hat I want to ensure that the n= ame will be perceived=C2=A0properly in the broader community.=

=C2=A0

A recent example that comes to mind are the privacy = related works on the browser storage API. Given that name, one would think = that it is local storage. It is actually about browser cookies.

=C2=A0

Justin discussed his reasons for TxAuth in the threa= d above (and I'm sure in other places)

=C2=A0

I chose XAuth in my draft to reflect the eXtensibili= ty goal that we have over OAuth -- and XAuth is OAuth but with an X to refl= ect all the extra features. =3D)

=C2=A0

Other suggestions?

=C2=A0

This will be an agenda item in the BoF -- but the na= me will NOT be an open discussion item -- we will summarize=C2=A0what has b= een discussed on the list and perhaps do a poll of options presented unless= consensus is obvious from this thread.

=C2=A0

/Dick

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

=C2=A0

=C2=A0

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

=C2=A0

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth